So, on Sunday, my little girl and I went down to the school and we bumped up the speed incrementally to see what would happen. The results were... not pretty. These gps plots closely reflect reality.
|The GPS plots are close to Truth but shifted southwest about 2-3 meters|
The run in red was slowest and the robot was off at the Lois3 waypoint by 10 meters. Ack! The green run was faster but the path following lookahead distance was too long. The robot couldn't turn sharply enough, and missed the waypoint.
I discovered a bug in my heading initialization code that led to the blue run disaster, as well as some oddness I'd seen on several other runs. That's fixed now. The purple run was fastest but I can't explain why the robot turned late and wide after the Lois1 waypoint. More thinking and testing needed.
It's about time I worked on fusing GPS position with other sensor data. Data Bus is running a comparatively simple Kalman Filter for GPS and gyro heading, compensating for GPS lag. I can either run a separate filter for position, or add position to the existing filter and convert it to an Extended Kalman Filter to address the non-linear relationship between heading and position.
But I can't do any of this, yet. I've been using latitude and longitude for all my position calculation. I'll have to refactor to convert latitude and longitude into cartesian coordinates. I'm already doing something along those lines for my Processing script, so hopefully the change won't be too painful. It's still a lot of work to undertake with only a month left and so much else to work on.
I'm also at a point where PID control of the throttle will be helpful. To do that I will have to address the quantization error from the encoders. One option is dithering, which requires a source of (pseudo-)random numbers for dithering.
Leon's Mini Random Number Generator features an analog circuit that could be used to generate a near-random bitstream. This pdf presentation by Markus Dichtl and Jovan Golić describes a random number generator using all logic gates. Or, I could just use code for a pseudo-random number generator like this from Steve Park.
A simpler approach would measure the time between encoder ticks, possibly with a simple exponential filter to keep the interrupt handler lightweight.