We recently had a really great collaborative experience on our forums I wanted to share.  It demonstrates the power of open source software.  The story unfolds in two parts: the touchy feely part (which I’ll share first) and the slightly more technical part and how we solved the problem (which I’ll dive into, being the nerd I am).

The Problem

As you may or may not know, the GoPiGo robot comes with a few ports for adding sensors.  The system is based off the Grove system of sensors.  One of the projects we originally wrote was how to connect a GPS to the GoPiGo (the dream: an autonomous pizza delivering robot that could navigate the streets of Chennai India).

The Grove system is open source, and when we did our project, we simply copied their code for the GPS system (honoring the license of course!), wrote our own program around it, and we had a robot that logged GPS coordinates.  We tested it, didn’t see anything particularly off about it, and published it.

Months later, on our forums, a collaborator using the GoPiGo brought up that his GPS coordinates were off.  “About 44.1 miles driving according to Google maps.”

The Collaboration

So we scratched our heads, referred back to Seeed, and tried to think of what might be causing the problem.  It seemed unlikely there was a problem with the GPS unit.  They’ll usually fail in a catastrophic way . . . they just stop working if they fail.

Amongst ourselves we thought of some exotic answers (emf from the wheels messing with the GPS sensor) and some practical answers (maybe just not seeing enough of the horizon to have an accurate fix).

The Solution

In the end, we solved it, together.  And you can see the code push here, just in time for everyone to attach GPS sensors to their GoPiGo and take them to the beach.  Yay open source software!  The dream is alive!  Open source collaboration works.

Behind The Technical Curtains: A Lesson in Coordinates

The problem was a slightly obscure and technical one.  The problem lay in the fact that there’s more than one way to represent GPS coordinates.  There are actually a few, and mixing them up can result in errors of 40 miles (or more, depending on how far you are from the poles).

The Grove GPS module works by spitting out a string of data that carries the coordinates.  Over a serial line, it simply spits out an ASCII string of data often called a GPRMC string.

A GPRMC string looks something like this:

$GPRMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68

Each piece of data is separated by a comma.  The “$GPRMC” stays constant, it’s a marker in the string.  The next number in the string represents time, the A represents whether the GPS receiver is getting a good signal.

Position is in the next four numbers.  Latitude and then longitude.  This is where the secret coordinates are hidden.  In the example above “4916.45” means, in coordinates “49 degrees, 16.5 minutes”.  The format is DDMM.MM, where D is degrees and M is minutes.

If you take the GPRMC string number, and simply divide by 100 and plug it into Google Maps, you’re going to have a bad time.  You’re going to be about 40 miles off.

49.1645,-123.1112

Takes us to the middle of Vancouver.  looking at the two map shots below, it seems like a slightly random place to map to.  Probably not the right destination.

So how do we get to the correct location on Google Maps? Google Maps looks for coordinates that are in DD.DDDD, where D is Decimal.  Sometimes this format is referred to as Decimal Degrees.  If you convert the GPRMC string coordinates into Decimal Degrees, we need to take the MM.MM of the GPRMC string, and divide by 60.  If the number from the GPS looks like DDZA.BC, we use this formula to calculate everything to the right of the decimal point:

d = ZA.BC / 60

Thus our string

4916.45,-12311.12 Converts to

49.27416666 , -123.18533333

Which, when we paste into Google Maps, is the right place in Vancouver: a beautiful dock on the seaside!