Findings (so far)

Update: 7 February 2003

Below is some fairly straight-forward NQC code to communicate more than one byte at a time between two RCXs. Since at the firmware level each RCX can only send/receive one-byte messages, this code sends longer messages by wrapping them into "packets."

Each packet consists of a "start" byte (255), followed by the desired message(s), followed by a "stop" byte (254). So if you wanted to send a four-byte payload (say, encoder readings and directions for each of two wheels), the sending RCX would actually send six bytes to the receiving RCX, because it tacks a byte onto each end of the packet. This is done so that you can tell if you've missed any parts of the message.

The "comm.nqh" file provides the actual communications functions. I highly recommend looking at the HTML version of this file, as it is nicely colored so you can see exactly what's going on. Read all the comments if you want to understand exactly how the functions work.

The two sample files, "commtesta.nqc" and "commtestb.nqc" together demonstrate extremely simplistic communication between two RCXs. Both code files require comm.nqh to compile and run. The first file just sends a "ping" to the second RCX and beeps if it doesn't receive a response fast enough. The second file just listens for the ping and sends a response. They should be enough for you to understand the syntax, at least.

More code to follow.

Update: 11 August 2002

Now available: a diff-drive robot model!

Update: 18 July 2002

One goal of this project is to simplify RCX-to-RCX IR communication, to make it more intuitive. One thought for how to do this is to change the current communication in two ways:

• Add a preliminary "ID" byte. Each RCX would be assigned an ID number, and all communication to that RCX would be flagged with that ID. Messages sent to different ID numbers would be ignored.
• Provide for longer messages. That is, allow for messages for up to a specified length (which might be short; say 16 bytes), but that would allow for more sophisticated communication -- even ASCII text.

The most elegent solution to this would be to change the default IR packet. Unfortunately, that would involve hacking the firmware, and I'm not sure at this time that I'm interested in attempting that. Or, I could try to use legOS. However, another goal of this project is to provide simple but elegant communication methods for people who are NOT already C hackers. So switching to legOS would probably defeat the purpose.

I have also spent some time trying to develop a sound sensor. Knudsen's The Unofficial Guide to LEGO MINDSTORMS Robots and Dancing LED's have been most useful. Unfortunately, I think I might have blown out my microphone (accidently connected it backwards), so I may have to buy a new one.

Last note: I've started development of a mechanical base. Eventually I plan to learn MLCad to put the model online.

Initial Notes:

Setup: 1 RCX 1.0 (from a RIS 1.5 kit), 1 RCX 2.0, both with the 2.0 firmware. All programming currently being done on a Windows 2000 machine.

Preliminary, utterly un-scientific testing:

• Using NQC, I could get simple RCX-to-RCX communication beyond 22' in direct line-of-sight, low ambient light. At close range (about one foot), nearly any orientation of the receiver seems to work.
• LeJOS supposedly cannot do RCX-to-RCX communication. That would explain why I was getting flaky results...
• Having trouble getting LEGO RIS2.0 communication to work. No ideas as of yet.

LEGO, LEGO Mindstorms, Robotics Invention System, and RCX are registered trademarks of the LEGO Group, Inc.

This project is funded by Carnegie Mellon's Undergraduate Research Initiative. These results represent the views of the author and not those of Carnegie Mellon University.