This is my first post on this site, so forgive me if I posted in the wrong forum.
My question is about Operator Control mode (teleoperated) and Autonomous mode. My team is #2484, and we are using easyC for the coding. I have read somewhere that there will be a main computer at the competition controlled by FIRST, and that main computer will control what mode your program is in, and that the computer calls the functions every 26.2 milliseconds.
Assuming I’ve correctly understood what I’ve read, does this mean that the main computer will call the autonomous() function every 26.2 milliseconds for the first 15 seconds of the competition, and then start calling the operatorcontrol() function every 26.2 milliseconds for teleoperated mode? We’ve been using a while loop to make our program run continuously, so would we have to change it for the actual competition? Do we not use a while loop at the competition?
For EasyC programming you can ignore the whole 26ms timing. It’s hidden from you by EasyC. The code is actually looping as fast as it possibly can, maybe 100,000 times per second.
The Autonomous block will only be called once, so you need your while(1) loop to stay in there and keep going. [correction]The Operator block repeats even if you don’t use a while(1) loop, but repeats very fast and isn’t restricted by the 26ms timing either.
Your code should be the same at home as at the competition.
EasyC questions are best asked in the EasyC Pro sub-forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=164). It might confuse you to read solutions that apply only to the several other methods of programming our robots. Just be careful when you read posts and understand that they may be assuming the use of a different programming method (MPLAB w/IFI default code, MPLAB w/ Watson default code, EasyC, RobotC).
There is much documentation covering the robot and operator interface. The “Full-Size RC Reference Guide”, section 1, discusses the 2 microcontrollers in the Robot Controller - Master Processor and User Processor. Section 13 discusses autonomous mode. Also see “2004 Programming Reference Guide”, sections 1.1 and 6.4.
The User Processor calls user_routines_fast / User_Autonomous_Code every 26.2 millisec in autonomous mode. It calls user_routines / Process_Data_From_Master_uP every 26.2 millisec in user mode.
To test autonomous mode, best is to build a Competition Port Adapter, discussed in “Operator Interface Reference Guide”, section 6. Include the disable switch!
If your code is taking too long, you’ll get the Code Error red light of death on your robot, and it’ll stop running. Believe me, you’ll know. So if it’s working okay when you test it, don’t worry.
Whether or not you need a While loop depends on whether or not you’re using EasyC. The Default Code and Kevin’s code, to the best of my knowledge, call the teleoperated and hybrid method repeatedly on their own, and a while loop will mess them up. I don’t know for sure about EasyC, but our team is using WPILib, which should work similarly. With WPILib, Autonomous gets called once, and Teleoperated repeatedly, so you would only need the while loop for autonomous.
It depends on the build environment… but you asked about the EasyC environment which is the same as the MPLAB/WPILIB build environment.
*<main "loop" in _startup EasyC & Mplab/WPILIB>*
Loop:
if (IsAutonomous())
{
Autonomous();
while (IsAutonomous());
}
OperatorControl();
goto Loop;
You can see that if you don’t have a while loop in Autonomous, it pops out and will sit waiting for the autonomous period to end. You must have a while loop in Autonomous() to make it work the way you want it too in these build environments. When the autonomous period ends, the WPILIB will pop the call stack and force a return into the main loop above where you’ll drop into operator control. You could have a while loop - or not - in operator control and it will work. The Getdata/Putdata to update the packet number etc. to prevent the RLOD due to long code paths is done in the background at interrupt level in these environments.
In IFI/Kevin build environments, the while loop is built into main()
*<IFI code base>*
:
.
while (1) /* This loop will repeat indefinitely. */
{
if (statusflag.NEW_SPI_DATA) << when a new data packet arrives from the master processor
{
Process_Data_From_Master_uP(); << this routine does the Getdata/Putdata once per new data packet
if (autonomous_mode)
{
User_Autonomous_Code();
}
}
Process_Data_From_Local_IO(); << this will run every as fast as the code path allows and is run whether there is new data or not
} /* while (1) */
The Getdata/Putdata is done in Process_Data_From_Master_uP() in IFI and in the main() loop in Kevin’s code. If the code execution path is too long and the Putdata isn’t called, then the master processor keeps getting data packets with the same packet number. Too many of these in a row and the master processor does something like assert the MCLR (master clear) of the user processor halting it. In these environments you don’t want a while loop in the autonomous or operator/teleop functions because that will keep the processor from getting back to the main routine to do the needed Putdata call in a timely fashion and you could get the RLOD.
Putdata is where the packet number is typically bumped. The high priority interrupt service routine is the code that is constantly sending/recieving the txdata/rxdata packets from the master processor. It doesn’t care if they are updated or not - it has a schedule to keep and keeps on sending/recieving data completing a data packet transfer every 26.2ms.