The RobotC competition template has been confusing for some students, I though I would try and demystify this and give an overview of how it works. Before diving into the code, it needs to be understood that any RobotC program can be used in competition mode whether using the competition template or not. Code should be downloaded with the “VEX Cortex download method” menu item set to “Download for competition”, although it also seems to work if “Download using VEXnet or USB” is selected also. These two download methods set an internal memory location inside the cortex to a different value depending on which is chosen. This value is read when the cortex is powered on and indicates whether, for example, the cortex should look for the VEXnet WiFI, however, the primary decision on whether to run in competition mode or not is determined by detecting the presence of the competition switch or field controller connected to the joystick.
If a competition switch (or field controller) is detected, the state of the enable/disable and autonomous/driver control switches are monitored. If the switch indicated disabled, the motors are also disabled and the joystick parameters (button presses and analog control) are ignored by the cortex. The user program on the cortex will continue to run but every item in the vexRT array will return 0 and any attempt to turn the motors will fail. Analog and digital IO will still work so, for example, sensor values can be read. When the competition switch is set to enable, the motors are also now enabled. The autonomous or driver control switch will now decide whether joystick data is allowed to be used by the cortex. The user program in the cortex can now control the motors but will still read 0 from the vextRT array if it is in autonomous mode. This functionality happens no matter what the user program tries to do and cannot be overridden, it has nothing to do with the code in the competition template and is part of the main cortex firmware.
The user program on the cortex can determine the state of the competition switch by reading two system parameters.
bIfiRobotDisabled is a Boolean that will indicate disabled if true and enabled if false.
bIfiAutonomousMode is a Boolean that will indicate that the robot is in autonomous mode if true and in driver control mode when false.
Any user program running on the cortex can monitor the state of these variables and take appropriate action based on their values.
So back to the competition template, how does it work? Well as we know every C program has to have a main function where the program first starts, in the case of RobotC every program has a main task that runs when the program is started. The competition template is simply a main task that monitors the state of the two variables above and runs either your autonomous or driver control code as an additional task. A simplified version (using some pseudo code) is as follows.
// mixture of C and pseudo code that monitors the competition switch state
// and starts either the autonomous or driver control tasks.
task main()
{
// initialize stuff
pre_auton();
// do forever
while(true)
{
// wait here for match to start
while( robot is disabled ) {
wait();
}
// are we in autonomous or user control phase
if( autonomous mode )
{
// run the autonomous code
StartTask( autonomous );
// wait for autonomous phase to end
while( autonomous_mode AND robot_is_enabled ) {
wait();
}
// stop all the motors and tasks
stop_all_motors();
stop_all_user_tasks();
}
else
{
// run the user control code
StartTask( usercontrol );
// wait for user control phase to end
while( user_control_mode AND robot_is_enabled ) {
wait();
}
// stop all the motors and tasks
stop_all_motors();
stop_all_user_tasks();
}
}
}
It can be seen that this task calls the “pre_auton” function and then enters a loop that monitors the state of the bIfiRobotDisabled flag. If the code detects that the robot has been enabled it checks the bIfiAutonomousMode flag and starts either the autonomous or driver control code as a second task. The code then continues to monitor both flags until either the robot is disabled or the control mode changes. When a change is detected the motors are all stopped (really just writing 0 to all motors) so that when the robot is re-enabled they will not have any old control data sent to them. In addition, all tasks except the main task are stopped including any tasks that the program may have started in addition to the autonomous or driver control.
The actual code is contained in the file Vex_Competition_Includes.c which is included by the Vex_Competition_Template.c file that is created for you. It’s very straightforward to create you own version that adds additional functionality whilst also checking the two competition state variables, for example, battery voltage could be monitored and an indication made if it is too low.
If the competition switch is not connected both bIfiRobotDisabled and bIfiAutonomousMode will be false causing the driver control code to execute.
Hopefully this gives some insight as to what is happening.
After the tournament we were able to look into it, and found out the joystick’s values are not read at all during the pre-autonomous or autonomous modes, unfortunately.
Wonder how soon it will be before we will see some accelerometer based driving in autonomous.