It's all about feedback control and modular control functions. Once you have these two things in place, you are free to develop autonomous motion routines at a very fast and efficient pace.
Feedback control allows you to change the way you control your robot from something very abstract, such as PWM values and time intervals, to something very simple and easy to grasp, such as absolute velocity and position. So, you tell the robot what to do (ex: travel at 7 ft/s) and the brains of the bot handles the rest. Popular control structures, like PID, make it possible for you to be able to tune your system to respond as quickly and efficiently as you like.
Once your robot has the capability to be controlled via feedback, you will want to develop some modular control functions. These functions should be able to be called globally, and have complete control over the robots hardware. Some control functions I have found useful in the past are:
- DriveDistance(inches)
- TurnToHeading(radians)
- LockDrivetrain()
- Drive(velocity, turn rate)
These functions are pretty self explanatory, and really allow you to do some cool stuff you wouldn't have been able to do beforehand. Because controlling the output of your robot is now entirely simple, you can create different pieces of code that access these control functions in different places with the same end result. Your resulting control code will be much simpler and much more reliable.
For example, you would like to create an autonomous mode that drives 5 feet forward, turns 45 degrees, then drives another 10 feet. Using a dead reckoning approach, this would be hard to achieve with a high level of accuracy and repeatability. You would have to worry about battery level, efficiency of each side of the drivetrain, obstacles you may run into, etc. With a modular feedback control system in place, you can create this routine in 3 commands. Every time the robot goes out on the field, it will run through these commands, correcting itself as it goes. Because you have spent so much time perfecting the "back end" of the system, the "front end" becomes much simpler and much more efficient.
You can also start moving into much more complex control schemes as well. You can create code to make your robots motion command based, where on the successful execution of one command, the robot will move on and execute the next. You can create a database on your robot of possible command scripts. You can even goes as far as storing them on an SD card or syncing them via serial. Now, you can create software on a computer that generates scripts for the robot to run.
Last year, my team took the route I have described and were very successful. Once we had the feedback control system in place, we created a command parser on the robot which would read a "script" stored in EEPROM. This "script" was handled by another piece of code on the robot which synced it with commands sent over a serial cable. On the other side of the serial cable, we had a Windows application running on a pocket PC which allowed us to draw out our path on the field (via way points), add functionality, and simply send a set of commands to the bot. The source code on the robot never changed when we wanted to change autonomous modes, which made for a very robust system.
If you have any further questions, don't hesitate to ask. Good luck!