Monthly Archives: February 2013

Some research on IR communication protocols

IR sender/receiver

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:

  1. Proximity detection
  2. Receive messages
  3. Send messages
  4. Decision making
  5. 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):

  1. Discovery: “The discovery procedure is used to determine the physical addresses of all devices that are within range.”
    1. “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.”
    2. “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.”
  2. 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).
  3. 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):

Programming multiple AVR/Arduino boards with XBee

Multi AVR programming using XBee

One of the major issues we have with the project is that we’re working with many robots (our goal is to make about 50 of them). Planning ahead, we thought it would be nice to be able to program them all at once to accelerate the development, especially towards the end of the project. We thus decided to experiment with multi-board wireless programming using XBees.

Step 1 : One-to-one wifi programming

There’s not much information on the web on how to program many AVR/Arduino using XBees but there is information on how to program one board. The first set of instructions we found are from LadyAda but we had better results with the instructions for the Arduino FIO.

The tutorial gives a detailed account of the different parameters that need to be set for the master (transmitter) and the slave (receiver). If you follow it step-by-step it should work fine. You can also check the extra tips they give if you run into trouble. We even tried with a very big program (50k!) and it works great.

The only thing we had trouble with is that the data transmission quality was bad and dropped quickly as we increased the distance between the XBees. This was likely caused by interferences with other wifi networks in the area. We solved this by changing to a different channel (the XBee CH parameter).

Step 2 : One-to-many wifi programming

In the Arduino FIO guide they mention: “Note: If you set the programmer’s destination address (DL) to FFFF, it will re-program all Fios in its PAN ID. To program one Fio at a time wirelessly while others are on, set the programmer’s DL to that Fio’s MY address.”

Basically, you have two choices: sequential or parallel programming. In the case of sequential programming, what you would do is more or less something like:

  1. Assign a unique MY address to each slave
  2. For each address do the following:
    1. Change the master’s DL to the slave’s address
    2. Upload the program

The advantage of this is that you get a chance to check that each board was programmed successfully before moving on. The disadvantage is that it takes as much time as there are boards: it just automates the switching from one board to the next for you.

(Notice that at this step we’re working with only two slaves.) We didn’t try that technique (yet). Instead we used the parallel programming trick. For this, you set the master/programmer’s DL address to FFFF. At first it didn’t work because all the slaves were sending data back to the master which seemed to overflood it. We tried to have only one slave return data back by setting it’s DL to the master’s MY address and by setting the other slave’s DL to an unexisting MY address, but this didn’t work well either.

We finally got it working by cutting the physical connection between the AVR first UART TX pin and the XBee’s TX. This worked great and seems stable, even for large programs and high baud rates (57600). We yet have to test it with more boards than two.

The files:

Simple XBee link quality test

Screenshot of the processing application for testing the XBee connection quality

Screenshot of the processing application for testing the XBee connection quality

We created a small Processing/Arduino program to check on the connection quality between two XBees (one linked to the computer and the other on an Arduino board). The Processing host just sends data packets (bytes) which are read and returned by the Arduino board. The host then compares the received packet to the one that was expected to establish the quality of the connection. It’s pretty simple but it works.

The files: