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!
Very cool. But one question. With sensors as a way of communication, doesn't that mean that most robots with this system would be immobile? Because otherwise it would require wires and therefore traveling robots can go only as far as the wire allows them.
ReplyDeletehttp://abcde13-abcde13.blogspot.com/
It could also mean that multiple NXTs are in the same robot.
ReplyDeleteDon't worry about the blinking light! Led's don't deteriorate fast enough for it to be a concern, that's why they are used for fibre links!
ReplyDeleteSo am I right to think that your messages don't have recipients? but are broadcast to all? so you are not sending message 36 to nxt no3 but instead each robot does its own thing for message 36, ie 4 do nothing and 1 does an action, and another plays a sound.
so effectively each nxt has a different instruction book, for common messages. Thats very much like an orchestra where each musician has different music and are all cue'd by the conductor.
I probably would have had all the slaves Identically programmed but instead gone down the addressed message route, whereby address 01 is a message for nxt1 only, address 0A is for NXT2 & NXT4 and FF is for all 8 nxts.
That is a great idea! (too bad I only came up with it like, 1 day after you did ;)) I know how much bluetooth is a hassle.
ReplyDeleteNow I wonder if this can compare with bluetooth for simple 2-NXT robots? When does it get to the stage (i.e 3 NXT's, 4) when it is a better alternative to bluetooth.
What if Mindsensors or Hitechinc came up with a 'communication sensor' based on this design that had 4 or so female plugs and inside the same setup that you have, but obviously smaller. Perhaps even with faster LED's and even a NXT-G block...
Just whims.. (no need to answer anything)
Parax, you are correct, the message is broadcast to all NXTs. Whether or not a NXT uses the message is all in the programming. Your example of an orchestra is right on the money. As an example, when the robot says "hello", a job number is first broadcasted. The "face" NXT does a routine where the mouth and eyes move. The "arm" NXT lifts the arm as if "waving hello." The "driving" NXT might move the robot forward a few inches. etc etc.
ReplyDeletesqiddster, I thing it would be much easier with only two NXTs. I don't think you would necessarily have to set up a binary code to send messages. You could just set it up so that the time that the light is on could be interpreted as a message. And by the way, the PF LED lights turn on and off MUCH faster than the lights on the sensor. I found that it takes about 40ms for the light on the sensor to go completely out, whereas the light on the PF light goes out in just a few milliseconds.
Actually talking of communication I read a piece about serial connecting NXT's A long while back.. suppose I should have mentioned it sooner.. ooops
ReplyDeleteanyway read up on the RS485 Connection more here:
Xander Soldaat has a way of using RS485 too. He told me a little about it, but for some reason I wanted to stick with using Light.
ReplyDeleteHere is a robot he did using that technique.
http://mightor.wordpress.com/2010/01/07/current-project-giant-robot-arm/
Xanders rs485 solution worked perfect.
ReplyDeleteAnd thats why al the other Robots in the warehouse communicate by light
give some program in RobotC whit this light communication
ReplyDelete