Friday, April 10, 2009

Final Days Before Robot Competition

The Hardware is (mostly) done but as usual Software is holding up the show. Lateness is the nature of software; it's worse with robots because given the choice between finishing the hardware and finishing the software, you work on the hardware first: the software can't get around without a body. Then you try to get all the software done in the final 10% of the schedule. I told my team (only half joking) that the first time it runs the whole course, if it runs it, will be at the starting line at the competition!

Testing the GPS is particularly challenging because you have to be outside in a big area to test it well. It's been unseasonably (brutally) cold here some days, mixed with many other forms of inclement weather, so I haven't wanted to walk around outside with a circuit board and laptop, especially at night which is the only time I have to really work on things. Luckily I'm off work today on a three day weekend; I'm going to need every minute of it.

When I did a cursory test of the GPS in a park several weeks ago, I tried to test the minimum resolution of the GPS by standing in a location, and walking a few meters to see how much it changed per every meter. That proved to be futile, so I tried standing in one place, walking several meters away, and then returning to where the GPS coordinates said I should be in the same starting location. Inevitably, I ended up nowhere near where I started, even though the coordinates were the same.



Today I realized that if you leave the GPS unit facing a window long enough, it will eventually get a fix, even though you may be indoors. The picture above plots all the results returned by the GPS over a 20 minute period. (Use the cars in the picture to judge scale.) My incorrect assumption had been that the GPS might be off by several meters, but that you could compensate for that and get a stead progression of readings. The problem is that the amount it is off varies from one reading to the next, even if you are standing still. What you really get is a cluster of points near your real location. Now, the center of that cluster as a whole might be off a fixed amount, and you can compensate for that a bit, but you can't take any individual reading and apply a fixed offset and say "ah, this is where I am". It's more like darts shot at a dart board. Also, the cluster as a whole eventually shifts over time - twenty minutes after this screenshot was taken, the GPS began giving readings further down and to the right.

So, where does this leave our navigation algorithm? Since the data is statistical, maybe our control routine should be as well. Instead of doing 90 degree turns and full stops every time a new reading puts us 10 meters left or right of where we thought we were, maybe lots of readings should have an aggregate effect on the direction of travel. For instance, if we're heading N, the first time we get a reading indicating we should really got E, we won't head directly east but instead shift our heading slightly NE. Maybe the next reading comes in affirming a northerly course, at which point we head N again; it would not be until several readings confirm "go east" that we completely turn N -> NNE -> NE -> E.

Oh and did I mention the compass sensor that tells us whether we actually are going north or east is also not 100% accurate? Guesses stacked on top of guesses...