Brian Goldfain Food, drink, robotics


Why 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 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


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 before (drive itself very fast). From my experience, the single largest factor determining success for robotics projects is to start with solid hardware and software infrastructure. This includes properly set up test space, a reliable platform, and core software to abstract out hardware interaction, data routing, and visualization. I will admit that my perspective is skewed toward software. As mentioned in an earlier post, we are building our system using ROS, which a great example of how core technologies enable successful project development. Just take a look at all the awesome projects people are listing on the ROS website.

I estimate that upwards of 80% of the time on my current project is dedicated to infrastructure development and testing. We could have used a more balanced time allocation approach and pushed early on for a fully autonomous demo, but it would have been a shell. Further, that would slow the overall progress of the project beyond that demo. Corners cut in the drive to the specific goal leaves important components in shambles and inoperable under all but ideal conditions requiring constant tuning.

I don't believe this is how successful long-term robotics projects should progress, and I keep that in mind every week when I plan. I believe that taking the time to develop bulletproof infrastructure in the beginning leads to awesome, repeatable demos later. As the saying goes, there is no shortcut to success.

Filed under: Robotics No Comments

Using QT in a ROS Catkin Package

This post is a brief account of how to compile a QT GUI as part of a ROS catkin package.

I spent the past week migrating a ROS project to the latest release, ROS Groovy. A major change with this release is the deprecation of the build system rosbuild in favor of a new build system, catkin. Catkin is a light-weight wrapper for CMake. Overall, the migration went smoothly, but it took significantly longer than anticipated (which I probably should have anticipated). One sticking point was compiling our Operator Control Station (OCS) GUI, designed in QT4. The problems were related to the removal of QT-specific rosbuild macros for the CMakeLists.txt and the use of out of source builds by catkin.

The Setup

I used qt_ros to generate a QT form, an accompanying QMainWindow derived class, and a ROS interface class as the basis for the OCS. The original CMakeLists.txt was based on rosbuild and modifications for the transition to catkin. I relied on a variety of resources for the migration, since none of them seemed to have all the information I needed: catkin's CMakeLists.txt overview, using CMake to build QT, rosbuild to catkin migration guide, and this post about using CMake with QT.

The Skinny

The OCS took significantly more work to catkinize than the rest of the nodes. The migration guide specifies how to transition many rosbuild macros to catkin, but the qt-specific ones are absent, specifically:

rosbuild_prepare_qt4(QtCore QtGui)

Using information from the first three of the above sources, I found a replacement to include the QT components I need:

find_package(Qt4 REQUIRED COMPONENTS QtCore QtGui)

The next problem involved catkin's transition to out of source builds. A QT .ui file must be turned into an associated header file to be included in a project. All of the files built during a catkin build are placed in the build/ directory of the catkin workspace, not CMake's current working directory. For someone trying to include a ui header file from an in source location, the standard include will fail because the ui's header file ends up in buid/.

Once I figured this out, I found the last source, and the addition to the CMakeLists.txt was simple:


Now everything compiles and installs properly. The new CMakeLists are closer to pure CMake.


Below is the CMakeLists.txt I use to compile the OCS. Not included are some catkin and project dependencies passed in from parent directories. I want to offer this as a basic outline to compile and install a QT GUI using catkin and ROS Groovy because I was not able to find it anywhere else.

cmake_minimum_required(VERSION 2.8.3)
find_package(catkin REQUIRED COMPONENTS roscpp image_transport)
find_package(Qt4 REQUIRED COMPONENTS QtCore QtGui)




add_executable(ocs ${QT_SOURCES} ${QT_RESOURCES_CPP} ${QT_FORMS_HPP} ${QT_MOC_HPP})
target_link_libraries(ocs ${QT_LIBRARIES} ${ROS_LIBRARIES} ${catkin_LIBRARIES})

install(TARGETS ocs