ROS Robot Localization

While working as a summer intern, I discovered a bug in the widely used ROS Robot Localization Package. I developed then submitted a simple solution to the issue, and now my code is live on potentially thousands of robots around the world.

The software I contributed to performs the complex tasks of sensor fusion and state estimation. Sensor fusion is the art of combining “bad” measurements from multiple sensors to create one “good” measurement. Every sensor will have error, but if you can characterize the error and use multiple sensors with different strengths, the combined knowledge from all of them can be quite accurate. State estimation tracks these readings over time to develop an even more accurate prediction of where a mobile robot is and how it is moving.

For example, a gyroscope can provide accurate measurements of angular velocity, but numerically integrating these measurements over time to predict orientation will result in errors called drift. An accelerometer can be used to measure the direction of gravity and improve the orientation measurement.

Similarly, encoders in the wheels of a robot can be used to predict its motion (a process called dead reckoning), but errors from the wheels slipping will accumulate over time to cause drift. A GPS is not subject to drift, but each individual measurement is fairly inaccurate. By using encoders for short-term estimation, and using many averaged GPS readings to correct long-term drift, you can get the best of both.

The specific bug I found was in how the software generates the initial calibration between GPS and IMU (an accelerometer, gyroscope, and magnetometer combined) sensors. When starting on uneven terrain, such as a sloped street in Pittsburgh, the calibration was flawed and the entire tracked trajectory would pivot such that it assumed you started on an even slope. This can produce huge errors for even small slopes once you move from your starting point, which produces issues when combining the prediction with GPS measurements.

Due to the policies of the project I was working on, I couldn’t use data I had collected at my internship to share this issue with the community, and I also couldn’t use customer time to submit a fix. Instead I recreated the issue in my personal time using simulation and developed a solution by modifying the source code of the package.

After a month, the PR was approved and my source code was merged into the main branch of the robot localization package. Four months later, it was officially released as part of an incremental update of ROS and likely made its way onto some of the millions of robots that use ROS.

You can see my PR on GitHub.

Image taken from Robot Localization Documentation