Multi-robot communication

created 16/05/02 - updates 21/05/02 | 03/06/02

There is one special point that the RCX-software designers should add to a further firmware-release. This is to allow a reliable network-protocol for multi-robot applications. Networking exists for the open-source replacement firmware legOS, but not for lejOS.

We have already dealt with broadcasting, which means to send information to several RCXs avoiding any computer reaction to possible RCX-replies. Broadcasting is a one-way data-transfer, with no or only limited possibility to check whether the correct message has actually been received. We now propose a bi-directional data-transmission.

This is not evident at all. So there must be some explanations and restrictions. 

First of all the case we are studying here is the communication between the COMPUTER and one single RCX-n, all the others being active. As we will see later there are some side-effects which affect all the RCXs involved. But we want the computer and the specifyied RCX to exchange data without disturbing the work of the other RCXs.

For example, suppose there are two RCX playing soccer and the computer surveying the match via camera. The computer should download positioning data to the RCXs and they should upload some sensor-readings.

If you try this through normal infrared-communication, you'll get plenty of error-messages and garbage-data. The major problem comes from the master-slave communication system as we already explained earlier.

To solve the challenge, the principle idea is to sacrifice two global variables (we propose 21, 22 - remember that in Robolab variables 23-29 are used during datalogging and variable 31 during some of the remote-fill operations:

• send PING (opcode 0x10) to wake up the tower and reset the toggle-bit inside of the RCXs. (to learn more about opcodes chose http://mindstorms.lego.com/sdk2/default.asp)
• send immediate command SETVAR 21, 2, n (n = RCX ID-number) (opcode 0x14); this command could be extended with some additional code (bit-orientated messages to send more commands in one package, example RCX-7 turn on motor-A  would give something like SETVAR 21, 2, b'0000 0000 0001 0111' , the first three bits being reserved for the RCX ID-number -in this case b'111'=dec'7'. You can set-up your own command-codes.) Note: the computer-program must not toggle the third bit, so we use the Msg_to_string.vi explained at the Broadcast-page.
• the RCX should have been previously programmed to react on changes in variable 21. For instance a special event could be generated when the correct ID-number has been received. The RCX checks in the firmware whether the opcode is complete and correct. The opcode is not executed if an error occured during transmission.
• After reception, the RCX sends a special reply in function of the received opcode. This reply is normally verified by the computer. If anything went wrong at this moment, the computer retries the transmission a certain number of times. If the number of retries exceeds a certain threshold,  an error-message is generated and the computer-program is paused. (One could intervene at this place directly in the Robolab software and change parts of the original code, but this is not the subject here, since we want to do the job for didactical reasons to teach serial communications and NOT for hacking reasons.) We try to ignore the retries and error-code generating through the low-level custom computer-program. Important note: As several RCXs are involved, all of them will send a reply causing useless IR-garbage.
• If all is right until now, RCX-n  could execute some additional code, for example upload the current value of sensor_1 or do anything else. Upload could be done through activating the SendUARTdata-opcode (0xC2) for SETVAR 22, 9, 0 (remote fill variable 22 with sensor-value of sensor_1). RCX-n now would broadcast-send this data to all the involved RCXs AND the activated tower. Don't forget that the tower will pass to sleep mode after a while, so the upload should be executed when the tower is still alive. (By the way, Robolab 2.5 encodes the SETVAR to opcode 0x05, which is the new allround SET command.)
• The special computer-program will now verify the received bytes. If all of them and their complements, their checksum and its complement are correct, the program returns TRUE. Important note: Again the undesirable side-effect may be noticed at this moment. All the RCXs except the sending RCX will send a reply to the data-transmission, causing IR-noise to be ignored.

This sounds very difficult and in fact it is, but here some illustrations:

LASM-code delt 0 task 0 set 0,21,2,0 Label1002: chkl 2,1,3,0,21,Label1003 ping jmpl Label1002 Label1003: set 33,16,2,3 set 33,17,2,0 set 33,15,2,16 uart 15,1 wait 2,10 ---->continue

set 33,0,2,5 set 33,1,2,0 set 33,2,2,22 set 33,3,2,2 setv 31,9,0 andv 31,2,255 set 33,4,0,31 setv 31,9,0 divv 31,2,256 set 33,5,0,31 uart 0,6 wait 2,10 endt plays 5

The request-opcode 0x14 (SETVAR) has four parameters: 

• 0x15 (= dec21) selects the variable;
• 2 selects the source 2 - constant;
• 1 low-byte of value;
• 0 high-byte of value.

The upload-opcode 0x05 (SET) to be controlled by the computer-software has 5 parameters:

• 0 selects the target (0 - variable);
• 0x16 (= dec 22) selects the variable;
• 2 stands for constant-source (don't forget that the RCX-program reads sensor_1, then stores the value in temporary variable 31. This value is then considered as a constant in the SendUARTdata-procedure.)

Note the opcode-header 55 FF 00 and the alternation of code and complement, finally the checksum and its complement.

Download all the related files. 

21/5/2002 small bug fixed in Comm_Tower_RCX_Tower.vi

3/6/2002 

• bug fixed in fill_remote_container_custom.vi : if the former version is used twice in a program, you get an error like: only one land per jump
• connectors order changed in Comm_Tower_RCX_Tower.vi

IMPORTANT NOTE: 

The Robolab 2.5 original fill remote container.vi only works for positive numbers. Negative numbers are NOT transmitted correctly. We added a custom bug-free version which unfortunately uses another variable (local 32), and an auto-incrementing label, needed because of the jump.  Here an extract:

Main Page