We found our Xbee packets!

We tracked down our missing Xbee packets months ago, but it took me a while to write this up. We no longer rely on the hex-to-string hack to keep the Xbee message payload limited to ASCII letters and numbers. That hack did not completely solve the problem and took more bandwidth to transmit a message. Working with my hunch that pre-processing was still being performed on the serial data, I found the solution poking through the serial code of the IMU driver we use, which was forked from KumarRobotics imu_3dm_gx4. I only set the c_lflag member of the termios structure for the serial port, but I also need the following line to disable all output pre-processing using the c_oflag member: port_settings.c_oflag &= ~OPOST; All packets received by the Xbee are now successfully received by our serial interface with this addition to the serial interface code. Next up for the serial interface code will be a cleanup and update of the documentation....
Read More

Where do our XBee packets go?

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...
Read More

Infrastructure

Half of the summer is gone with little research to show. What I do have is a test track for the robot, a second generation robot under development, and full autonomy tests on the horizon for the current platform. At the end of every week I look at my progress and ask one question: what should I work on next week? What follows is how I try to balance and make sense of the daily logistics requirements, ongoing infrastructure development, and the need for research progress on my current robotics project. How to answer this question is more important than ever to me because I start a new program in the fall. As a PhD student, my job is to solve important unsolved problems in my field to increase human knowledge by some measurable amount. I think these illustrations put it into perspective. Concerning my weekly work, I try to  maximize the likelihood that my robot will do something no other robot has done...
Read More