Posted by firstname.lastname@example.org on 07 Apr, 2017
A very after-the-fact robot update from late 2016: GPS works. This is perhaps more awesome than it sounds.
First, if you want a good rant about how GPS communication is terrible, check out this article. It's a magnificent rant about how you never really get your true state or know what time a particular state refers to with GPS, due to a pretty nonstandard standard (NMEA), which itself was due to the "N" in "NMEA" standing for "Nautical." Boats just don't need the same data as the rest of us, it turns out.
Other fine folks have attempted to solve this problem, and one approach is a GPS/NMEA processing daemon for Linux called GPSD. This monitors the serial communication, processes it to standardize vendor differences and sentence-order differences, and then makes it all available via UDP. Very cool, you can poll this when you want it. If you want to be notified as soon as new data comes in, I think you may still be out of luck, however. I'm anticipating my GPS error range will be more than my timing error range, so it should not matter too much. In my robot, GPS is not designed to be a precision sensor (yet).
But GPS isn't just terrible, it's also awesome. I have code that runs on my robot pi to listen to the GPS, and convert that lat/lng info into a local x/y plane, and then run a Kalman filter on it, and push each successive state out to the telemetry web application (also served by the robot) over a Redis backplane. Eventually this will host a maps view of the current estimated position, error ranges, etc.
Next steps are to read from the Inertial Measurement Unit (IMU) and do sensor fusion to integrate that with the GPS data (in progress), which has its own set of fun challenges. Stay tuned.