An important component of our hardware is a pair of 900MHz XBee radios, one on the robot and the other at our operator control station. We use them as a second communications channel with the robot in addition to the WiFi. Among other messages, the XBee carries the RTK correction data from our base station GPS to the GPS unit on the robot. The XBee configuration also allows simultaneous communication with multiple robots while each robot runs its own contained ROS system.
The case of the dropped packets
Our issue, discovered while debugging the most recent updates to our XBee interface code, was that some of the packets sent from our operator control station XBee were never received from the robot XBee.
We use the XBee in API Mode 1 (no escaped characters), so we can broadcast messages to all XBees within range and target specific XBees as needed. In this mode, the user is responsible for assembling packets with a maximum payload of 72 bytes including our own header that encodes the message type and size. The correction data from the base station GPS is RTCM3.0 messages, many of which exceed the single packet payload size. For our purposes, the correction messages are viewed as raw binary data to transmit. We break the message into multiple packets before sending, then reassemble the correction messages on the robot before passing them on to the GPS.
During testing, we noticed messages with only ASCII letter and number characters (0-9, A-Z, a-z), were always received correctly, while many of the RTCM messages were never received by the robot XBee. With this evidence, we scoured documentation for any special characters that could affect packet transmission. From this article and the handy-dandy ASCII table, we identified XBee special characters (which are not fully used in our Mode 1 operation) 0x7E, 0x7D and software flow control characters 0x11, 0x13. As a test, we replaced all instances of these characters within our payload with the ‘A’ (0x41) character, but received message performance did not change. We did notice that changing all instances of 0x00, the null character, to any letter or number character greatly improved performance. Without exhaustive testing of ASCII characters, we concluded that there is likely a subset of ASCII characters used as special characters by at least one link in the transmission pipeline.
Our (temporary) Solution
We decided the best solution given our time constraints for testing, was to convert each payload byte to its 2-byte string equivalent: 0xF3 becomes the string ‘F3’, which restricts the payload characters to the ranges 0-9 and A-F. This requires roughly double the XBee packets to transmit, but results in much fewer, but still a non-zero number, of dropped packets. The remaining dropped packets may result from special characters popping up in our custom header inside of the payload, which is not being encoded in the described manner. The settings for the USB port on the computer were also investigated, but results in no change in packet loss behavior.
The issue will not be completely solved until I dive into the interaction of escaped characters for the USB port, the USB to serial device on the XBee carrier board, and the XBee as well as investigate the XBee API modes more thoroughly. Currently, the robot usually receives enough of the correction messages to stay RTK corrected, but sometimes it doesn’t. While the current solution is not very satisfying, it let’s us continue on our current testing push.
The Real Solution
When we have time to revisit the issue, I believe the complete solution will involve:
- Use XBee API Mode 2 (we still need API Mode functionality), and properly escape characters in the messages
- Identify and properly handle special characters for all components including XBee
- Keep payload data in the more compact binary form instead of converting to ASCII letter/number characters