I am really impressed how things are going since I decide to use light sensors to communicate. It turns out that once you get the programming and physical setup working, communicating with light is a very reliable way to talk. I am still using this basic setup.
The pros far outweigh the cons in my opinion.
Pro-
• No Bluetooth and all of those hassles, i.e. inconsistency, lockups, confusing code, etc.
• All NXTs can communicate equally as a master or a slave.
• As soon as the NXT is turned on and the program is initiated, the communications are ready to go. No handshaking is necessary.
• In theory, I can communicate with many NXTs, even more than the six that I am currently using.
• It makes a cool light show in the bowels of my robot.
• If NXT #1 is talking to NXT #2, all the other NXTs can “monitor” what is going on if needed.
• It is very easy to synchronize all the NXTs. Timing is no longer an issue. When the message is sent, automatically all the NXTs are synchronized by the initiating signal.
Con-
• It uses up a sensor port (I have 30 available, so who cares???)
• It’s slow compared to Bluetooth, taking up about 1/3 of second to send a message. But really, is 1/3 of a second really that slow?
• I am not sure, but it might be hard on the sensor light. There’s a heck of a lot of flashing going on and it might shorten the life of the sensor. But I haven’t had a problem yet.
I have even set it up so that there are two “mailboxes.” I can send “Jobs” or “Messages.” I differentiate them by the time that the initial blink of the light stays on. If the initial blink is about 50ms long, it’s a “job.” If the initial blink is about 100 ms long, it is a “message.” Each of these types of messages is handled differently in the programs. Technically, there is a third type of mailbox too. If the sensor light stays on for 250ms, it is an emergency stop, and all the bricks interrupt what they are doing and immediate halt in place. Any brick can stop the entire process if there is a problem.
The type of data that is sent is binary numbers. I can send number from 1 to 63 for each Job or Message. For example, the master NXT sends out a job number 39, and each of the other five NXTs along with the master do the respective task assigned to the number 39, in this case play some music.
I have set the programming up so there is a universal header file (a driver) that is used by all six bricks. That is extremely handy, change the code once, and it carries through all the programs.
I am certainly going to use this technique more in the future.
UPDATE:
Got picked up on
MAKE! Sweet!