Saturday, March 6, 2010

MARVIN is Evolving

I have had a command decision. Much like Honda’s ASIMO evolved, MARVIN is evolving.



Here’s why. First and probably the biggest reason is that I am having difficulties with RobotC. I have hit a snag and I am not completely sure what is happening. Basically, when I change any part of the code, it doesn’t get downloaded correctly. I have been in contact with the development folks and I am told they are working on the problem. So while they are working on the program, I am putting the programming or MARVIN on hold.

Secondly, I as you may remember I purchased two more NXT 1.0 sets. So that means that I have increased capabilities. Yes, I am going to try to upgrade MARVIN to have six NXTs. I also have two RCXs lying around going unused, and I am considering throwing those in too, but that is a stretch. This means that the robot can be incredibly complicated both mechanically as well as programmatically. Communications will be a nightmare and I am investigating ways to accomplish this. Currently I use the PF LED and the light sensor and that will likely be how I do it again with more controllers.

Thirdly, after working with MARVIN for a few months, I have learned a ton of things. I have built some parts too weak and I want to upgrade them. The wheels can’t hold the massive weight of the robot and I am having problems getting him to move. The casters on the back aren’t sturdy enough to hold the weight either and those need to be beefed up. I also want to make the robot more modular, meaning when something goes wrong I want to be able to just take off the offending part and work on it away from the robot without having to disassemble the whole thing.

As I work on the robot, I am overwhelmed with all the ideas that I have had. When you have a very high number of motors, sensors and parts, the number of things you can do shoot thru the roof. I guess to give you an example, imagine taking several of the cool robots seen on blogs and on YouTube and mashing them all into one super massive bot. I want to spend some time investigating what I can do to accomplish this.

I am really enjoying working on MARVIN, and lots of people are interested in seeing the cool things he will be able to do, so I want to make sure I don’t disappoint. I am finding that this project really isn’t as difficult as you might imagine, but it takes lots of time to work thru the problems. To me, that is the fun part

2 comments:

  1. A word on communications - I don't know if it would work, but would it be possible, for dual-directional-NXT communication, to use two light sensors, so that they are placed facing each other, but one is upside-down? so the opposing LED's could send messages to the opposing sensors.

    Just a thought....

    ReplyDelete
  2. Using Light Sensors is a GREAT idea. (I say that jokingly because I thought up the same idea one day before your post ;) )

    I did try that out and I think it would work great. The light doesn't turn on and off as fast as the LED, but it is still very fast. I put two sensors on one brick and sent the times to the display and found that I can complete a binary signal in less than 100 ms, which is plenty fast.

    The next thing I am going to try to do is face all six light sensors in a circle and see if one sensor can be picked up by the other 5 sensors. I think it will work fine, the sensor light is very bright if I mask all other ambient light.

    This solution would be great because all six NXTs would be able to communicate effectively with no Bluetooth. Bluetooth is a big hassle when dealing with multiple NXTs. Plus that makes the robot capable of "turn it on an run it." If the NXT times out and turns off, I don't have to reset BT. I love the idea.

    ReplyDelete