GPS vs. Dead Reckoning
So, I decided to try the bare minimum first, then add complexity as needed. It turned out that dead-reckoning worked pretty well. With some refinements, I think it will work REALLY well. Also I came to the conclusion that heavy reliance on GPS will doom any bot to slow speeds. The location error and slow refresh rates make it useless for speeds like 30+ mph (which is my goal). I understand that the speed and direction improve at higher speeds. I guess my point is that if you rely too heavily (or completely) on it, and it only updates at 1 Hz (or even at 10 Hz), you will be into the wall before you know where you are. There has to be some degree of location estimation between updates to keep you on course (at least on a tight course like the sparkfun parking lot).
Steering
Steering was simply proportional to the angle between the current heading and the waypoint, with a 90 deg. limit. (next time I'll make it proportional to speed, or yaw rate limited). I used a nominal setting for "straight", then just added or subtracted from that depending on the direction. The one problem I had with this is that my "straight" setting changed at some point, so the bot would very slightly pull to one side. As it would approach the waypoint, it would eventually get close enough to realize that there was a significant error in heading and swerve a bit right before the waypoint. Maybe a real PI controller, emphasis on the I would help correct that.
Throttle
The throttle was even more embarrassingly crude. It was open loop, with a fast and slow setting. Within a certain radius of the waypoint it would kick down to slow to navigate the turn, then kick back up to fast for long distances. Since I have an encoder on the transmission, I could have easily incorporated a PID controller (actually probably just proportional) and controlled the speed really well. I actually wrote that code, but didn't have time to test it.
GPS
Chassis
My car, BTW is a Losi XXX graphite. I had bought one as a roller a while back and though it would be perfect for this application. I also thought of using my emaxx, but its plush suspension rolls a lot during turns, which, if I understand correctly, will add error to my gyro. I figured I had to keep the gyro as close to parallel to the ground as possible.
In regards to wheel slip and dead reckoning, I haven't figured out how much I have to worry about pushing through turns. If the front wheels slip a bit, will it matter? Will the gyro data still be valid? Obviously if the rear wheels slip, then I've got a problem, because that's where my odometer is.
Odometer
One other issue that I meant to address was wheel expansion and it's effect on the odometry. I could come up with a simple multiplier that is proportional to the speed: simple curve fit. There's lot's-o-stuff I never got around to.
Comments
> GPS at most will give you a 5Hz update rate
If you have the cash you can get a 'real' GPS with 20Hz (or even 100Hz) outputs, but interpolating with the help of odometer, compass, magnetometer, and 3D accelerometers sounds a great idea.
Simon
Hi Nathan!
The UAVDevBoard actually uses dead reckoning algorithm to give you position updates at 40Hz. These estimates are corrected by gps at 1Hz. (Thanks again, Bill!!). I think this might be a solution to your problem of GPS vs. dead reckoning.
You can find more info on the UDB and the dead reckoning algorithm on their website (http://code.google.com/p/gentlenav/).
Greetings,
Wouter
Yeah, you've pretty much hit the nail. GPS at most will give you a 5Hz update rate. And with addition of relative/differential GPS you can get down to 5-10cm precision, but time-based accuracy is still gong to be way off.
Adding info from the odometer, compass, magnetometer, and 3D accelerometers will get you what your looking for up to the point of external tracking, which is what all the Universities are using (mocap systems) for precision acrobatics.