There was already a message here which showed how to do some simple state-based autonomous code. THIS IS THE RIGHT WAY TO DO THINGS.
Your autonomous code effectively moves through a series of states. You stay in a state until ready to transition out of this state. Each state have have specific outputs (like a "Moore machine") or have outputs which directly depend on inputs (like a "Mealey/Mealy machine"). There is no reason to have to make your outputs entirely Mealy. Add a state variable -- it really does help.
A simple example can also be found in one of our team's (1014) code:
http://www.osufirst.org/twiki/bin/vi...04RegionalCode
If you look in the user_routines_fast.c in the autonomous section, you'll see the whole thing is based on state. Because we have position feedback, we transit out of states once we reach a particular position. However, this could just as easily be time.
In general, it's nice to setup an interrupted-based timer that keeps a moderately real-time clock running on your machine and to use that as feedback timing your operations and calculating important characteristics like speed.
Keep your code in terms of state and you'll have a much nicer time coding, especially when adding states, maintaining states, and doing simple things like stopping.
Sorry that the 1014 autonomous code has little commenting -- one of the nice things about the states (and the speed controllers) is that we could write our autonomous code on the fly at competition and it was easy to debug there. We never intended to have autonomous code... we just felt it was good to add it in since so few robots at our regional had any.