|A messy workplace means a messy mind...|
I had tested my robot on a small scale course, half that of the race course. I didn't test the robot driving between buildings. Here's what I mean....
Reviewing logs for the last dozen runs, it appears that my supposedly rock solid GPS heading isn't. That throws quite a wrench in the works since that is my only reference to correct gyro bias at present.
Initial GPS heading wanders for the first second or so. For position estimation, no biggie, unless it throws things off later?
Did I mention yet that Octave has a bug where Gnuplot axis/mouse values are wrong? So I can't actually tell what the reported heading was without looking at the data. Yay! I have to plot everything straight in Gnuplot to get accurate info.
On the second leg, GPS heading is off by at least 2° based on reported course versus witnessed course. This is on most of the plots I've looked at so far.
Without going into the intricate details of how my heading estimation and position calculation works, it's safe to say this is, officially, a Bad Thing.
I've gone from the robot knowing where it is and doing nothing about it to the robot being delusional about its position and crashing. These heading errors don't matter as much on a small scale. They matter at the Sparkfun Building, though. I knew they would. Why didn't I test at Boulder months ago?
Incidentally on my two recent successful runs, the GPS heading looks smoother and agrees better with the rest of the data.The resulting estimate is a little better, too.
So what can I do about the problem? No, let me rephrase that. What changes do I stand a chance of successfully making in the next two days that in turn stand a better chance of improving performance than degrading it?
- Well, first I have to make sure I understand the problem(s)
- If the error were consistent I could simply move waypoints around to fudge it. It's not.
- Fuse the GPS heading 3-4 seconds after start so it has a chance to converge.
- Make sure the gyro estimated heading starts off correctly when the robot takes off
- I can add position filtering/estimation based on GPS position. It might help just enough
- Leave it alone and hope and pray it works better on race day
- Add a curb sensor and code to avoid curb collisions
I suppose it's possible that improving the initial few seconds of heading estimation may help later on in the run. I have a couple of ideas that are pretty simple to implement that might work. Meanwhile, it's a little late in the game to add position filtering. That's a pretty big, bug-prone undertaking.
I haven't made progress on collision avoidance. Last night I crashed hard. So, maybe tomorrow.
Weather forecast for Saturday shows 20% chance of precipitation in Boulder. Hm.