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


  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....

  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.