This is exactly how we did our autonomous code this year (in Java). Basically, we decided that the "iterative"-style template makes the most intuitive sense for teleoperation, but that the "simple robot"-style sequential template leads to easier-to-understand-and-debug autonomous operation.
As a result, we used the iterative template, but created a separate class - AutonomousThread - that is kicked off by autonomousInit() (and killed by disabledInit() or teleopInit() ).
Here's where it gets cool - when the AutonomousThread starts, it is passed an array of type "Action", which is a custom interface that we made. Each Action has an "execute()" and a "cancel()" method. The convention is that every Action will return from "execute()" when it is done (e.g. DriveDistance would return when the robot has covered the desired distance) or when it has been canceled. We implemented "cancel()" as a method that would set a flag inside the Action that would then be polled within the "execute()" loop, since there really isn't a good/safe way to kill threads from afar otherwise.
So AutonomousThread looks a little bit like this:
Code:
public void run()
{
for( int i = 0; i < mActions.length; i++ )
{
mCurrentAction = i;
if( !mCancelled )
{
mActions[i].execute();
}
}
}
public synchronized void cancel()
{
mCancelled = true;
mActions[mCurrentAction].cancel();
}
Ain't polymorphism grand? (Even though this is Java, the same technique would work fine in C++).
Now, where it gets REALLY cool is where you can serialize Actions to a file on a PC, FTP it to the cRIO, and load a new autonomous mode without re-deploying...
If there is sufficient interest, I'll post our team's code at the end of the season.