First: Feel Free to Re-Organize IFI's Autonomous Code
You may want to back up a little bit. Note that the only reason that loop is 26.2 ms is because of that Getdata. You only need to call Getdata when that statusflag.NEW_SPI_DATA flag gets set. Thus, if you organize your code well, you can run much faster cycles in autonomous mode. That may or may not be helpful to you.
Additionally, someone's mentioned how you should put the Generate_Pwms in autonomous mode as well before the Putdata call. You might think about replacing the whole thing with Process_Data_From_Local_IO, and now that I think about it, you should probably put that P_D_F_L_IO outside the slow if( statusflag... ) block. That way you'll be able to respond to robot sensors much more quickly in the exact same fashion as you respond to sensors in non-autonomous mode.
Don't Use the 26.2 ms Cycles to Count Time
Now, that being the case, I would not recommend using the 26.2 ms flag for timing. If you wanted to, you could count down from 38, decrementing once a cycle, and every time you hit 0 you would have gone ABOUT 1 second. But there are better ways to doing things.
Use the PIC Counters to Keep Time for You (with Interrupts)
I'm fairly sure that the student who did most of the coding for the robot found instructions on IFI's website on how to configure the counters to keep time for the robot. Right now, I can't find where he found it, but I can show you the simple example in our own code:
http://www.osufirst.org/twiki/bin/vi...04RegionalCode
You'll see that WE MUST INCLUDE timers.h. This is a SYSTEM INCLUDE, so you'll have to include it with less-than and greater-than braces rather than quotes. After this, it's fairly easy to configure a timer which produces an interrupt every 100th of a second (you can change this to faster or slower rates, but our code is configured for 100ths of a second).
Look at the interrupt handler in user_routes_fast.c. You'll see that AT THE VERY BOTTOM OF IT, it increments an elapsedTime and also sets a timeUpdate. elapsedTime is our on-board "clock." Every second, it sees an increment of 100. timeUpdate is a variable we use to communicate that a new "count" just occurred, letting some of our other routines do some "sampling." That's another story.
We also had to add code to the Initialize routine to configure the counter.
After all this, it was about 5 lines of code, and we could count on (no pun intended) elapsedTime keeping an "on-board clock" for us. I'd recommend doing something like this in your setup.