I spent some time looking around for information on infrared communication protocols, especially in the context of multiple communicating nodes / robots.
e-Puck is an educational robot project developed at EPFL. The robots communicate between each other through IR in a very similar fashion to us. I’ve digged a bit into their code and they don’t seem to have a very elaborated communication protocol between their robots, appart from the format of the messages which use a CRC and a pre-defined packet size, which is similar to what we are doing. An interesting thing they do is that they use a queue to save their messages, which is something we should definitely do.
I found a great article on IR communication for swarm robotics. There are many things in that article and it’s definitely worth a read. One interesting thing is that they talk about using IR for detection of other robots, detection of obstacles (proximity) and communication. They suggest the following loop for the robots:
- Proximity detection
- Receive messages
- Send messages
- Decision making
- Behavioral commands
Finally I looked at the IrDA communication protocol. It’s definitely overkill for us but there are things we can use in terms of communication protocols. The IrDA protocol follows the following procedure (see fig. 10 on p. 8 for a summary of the procedure):
- Discovery: “The discovery procedure is used to determine the physical addresses of all devices that are within range.”
- “An initiator starts the discovery procedure by sending out an Exchange Station Information (XID) discovery frame. […] All devices within range will generate a random address and respond with an XID response frame.”
- “The Sniff-Open procedure allows a device to begin the discovery process while conserving power. A Sniffing device will periodically wake-up and check for any IR traffic. If any IR traffic is detected, the device will go back to sleep. If there currently no IR traffic detected, the device will send out an XID response frame to address 0xFFFFFFFF. The device will the wait for an XID command, an XID discovery frame or a Set Normal Response Mode (SNRM) frame, which begins normal connect procedures. If no frames are forthcoming, the device will go back to sleep and repeat the process later.”
- Connection: This is where the connection parameters are negotiated: baudrate, maximum turnaround time, data size, window size, etc. I don’t think we’re going to use that in our case because these parameters are known in advance. However the relationship between turnaround time, window size and transfer efficiency is useful (see p. 10).
- Information transfer: “Once connected, devices can either exchange data, reset or disconnect. Data can be sent using reliable, sequenced frames. Using the reliable (I) mode, data can span multiple frames with counters keeping track of the number of frames sent and the number of the next frame expected to be received. Data can also be sent using unreliable, expedited (U) service. In this case the data cannot span multiple frames.
If both devices agree, the connection can be reset, which clears the frame counters and retry counters but keeps the connection open. A connection can also be disconnected by either device. The disconnection does not require approval from both devices.”
More examples (on IR sensing):