The RobotC competition template

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.

1 Like

Are you sure that vexRT is blank while disabled?

I see no real reason for them to clear vexRT when you are disabled but not in autonomous (e.g. you want to debug code while it is not outputting).

The old processors (FRC and VEX PIC) did not clear the driver inputs while disabled, only during autonomous mode. I have not verified this either way, but I would prefer to get data while disabled.

Yes, there is no joystick data available when disabled either before or after a match. If you are in driver mode with buttons pressed or using the analog controls, as soon as the robot is disabled all values from vexRT will go to 0.

I agree that it would be useful to be able to select different functions on the robot while disabled, for example different autonomous modes, using the joystick. As far as I can tell this is a feature of the master firmware not the RobotC code. I did not get around to testing if the joystick or cortex disables this but assume it probably the cortex itself.

1 Like

We tried this early last year. I wrote the code for it, but we never really got to test it enough to figure out what wasn’t working, and one of our teams ended up using the new code that I wrote for the first match of a tournament that day, and were not able to run the whole match due to it. :stuck_out_tongue: 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.

~Jordan

So I just did a quick test to see where the joystick data is disabled, and it turns out that the joystick itself is doing the blocking and not the cortex.

Funny thing is (and perhaps I should not point this out) they forgot to block the accelerometer data in autonomous mode, you can read vexRT[AccelX] and vexRT[AccelY]. It is blocked however when the robot is disabled. Guess we will have a new firmware version now :frowning: Wonder how soon it will be before we will see some accelerometer based driving in autonomous.

1 Like

While this would definitely be useful, it’s only a short step away from having user control in autonomous. We’ll just have to make do with bump sensors and potentiometers for that purpose :slight_smile:

Regardless of it being possible, it’s still illegal…

(Quoted for those teams who will forget about this rule… :rolleyes:)

//Andrew

I just saw Andrew’s question about the competition template (which in my opinion can be modified as it has no effect on field control) which is perfectly timed as I plan to release an alternative for ROBOTC that anyone could choose to use.

This version has some of the features I wanted such as battery monitoring, persistent tasks and the ability to easily test autonomous code without the competition switch connected. Before I release this does anyone else have suggestions for additional features that could be built in?

1 Like

:slight_smile: I really like that idea… (in fact, I was toying with creating and releasing my own if modification is allowed)

I just have three requests:

  1. Built-in detection of a second controller would be neat. (I’ve never used two VEXnet controllers myself, but I can see some usage for it)
  2. Please remove those pesky “placeholder for testing” routines… I don’t like seeing those warnings all the time. (Between that and the “inline function” warning, I’ve never had warning-less code…)
  3. Whatever features are in it, please document what’s going on… The ROBOTC template isn’t commented clearly at all.

//Andrew

1 Like

That one is easy, there is already a variable ( nVexRCReceiveState ) built into ROBOTC (as of V3.04 on a cortex), I posted about that here. I’m not sure why a recent post in the ROBOTC tech forum said it cannot be done, I tested it and it works. I guess it could be checked in the main task and a simple boolean set to true or false to make it easier.

1 Like

Hmm… This leads me to think that ROBOTC has some powerful but undocumented features…

//Andrew

As is acknowledged in this post by jbflot.

I have licensed all three versions of RobotC, and I don’t think I have ever downloaded any code to the Vex Controller…

I look at the Documentation, but there seems like few features… But read the Include Files, and listen to the People that work with it, RobotC has a lot to offer…

On that note… is there some kind of a wiki somewhere? So people can share what they figured out stabbing in the dark and reading h-files, an of course find other ppl’s info?

Not that I know of, but there should be, and we have the Wiki to Host it… Some one needs to set it up, and the rest of us need to contribute to it…

CMU is working on a ROBOTC wiki, but from what I’ve seen so far it has the same information as in the help files just updated a bit. Last year I had a plan to assimilate all the information I had posted and publish it as a single document, but work got busier and I didn’t even start yet.

1 Like

Bumping an old thread here.

There are some limitations to the ROBOTC competition template and I wrote an alternative last year but did not release it. I’m posting it up here as a “work in progress” although it does work as is and I’m not really planning to do anything else with it. It more or less does what the standard template does but with the following differences.

pre_auton is replaced by a task called compPreflightEntry that runs with low priority. background processing that you want to be persistent across enable/disable or auton/driver could be placed here. It runs with priority 0, so very low.

the autonomous task is replaced by compAutonEntry, same functionality.

the usercontrol task is replaced by compDriverEntry, same functionality.

#define COMP_DISPLAY_STATUS

This enables a task called DisplayStatus that displays competition mode and battery status. Comment out if you have other plans for the LCD.

#define CHECK_BATTERY_1_LEVEL       7400
#define CHECK_BATTERY_BACKUP_LEVEL  8000
#define CHECK_BATTERY_2_LEVEL       7400
#define BATERY_2_PORT               in1

Definitions to set the threshold for low battery detection in mV, the DisplayStatus task flashes the LCD backlight if the battery is too low, comment out (or don’t define them) if you wish to disable this. For example, if you do not have a power expander then only use

#define CHECK_BATTERY_1_LEVEL       7400
#define CHECK_BATTERY_BACKUP_LEVEL  8000
#define COMP_MODE_TEST_AUTON
#define COMP_MODE_TEST_DRIVER

Use one or the other of these definitions for force this competition mode, for example, use COMP_MODE_TEST_AUTON to force the autonomous code to run when testing if you don’t have a competition switch connected.

If the template is used with the PC emulator then the LCD debug window buttons can be used to enable/disable (left button) or select auton/driver (center button) for testing.

A typical user program would look like this.

#define COMP_DISPLAY_STATUS
//#define COMP_MODE_TEST_AUTON
//#define COMP_MODE_TEST_DRIVER

#define CHECK_BATTERY_1_LEVEL       7400
#define CHECK_BATTERY_BACKUP_LEVEL  8000
#define CHECK_BATTERY_2_LEVEL       7400
#define BATERY_2_PORT               in1

#include "CompTemplate.c"

/*-----------------------------------------------------------------------------*/
/*                                                                             */

task compPreflightEntry()
{
    // Do any pre flight checks here

    // I like the backlight on
    bLCDBacklight = true;

    while(true )
        {
        // background processing like checking an emergency stop
        // button
        wait1Msec(1000);
        }
}


task compAutonEntry()
{
    //StopTask( compPreflightEntry );

    while( true )
        {
        // Autonomous code here
        wait1Msec( 25 );
        }
}

task compDriverEntry()
{
    //StopTask( compPreflightEntry );

    while( true )
        {
        // Driver code here
        wait1Msec( 25 );
        }
}

Anyway, here it is to do with as you wish. If you don’t understand it or have issues with it then don’t use it, you have been warned .

.
CompTemplate.c (14.6 KB)

1 Like

In some of the competitions, we have been so far, sometimes has a faulty switch.
Is there a way we can determine this programatically, like any switch we can use for some LED’s which we can connect to glow, so we know to notify the organizers of the same.

In one of our competition, the robot did not operate both in autonomous or in remote control mode.
It had worked in the previous fields on the same day just 30 min before. The moment we were off the field
it still worked. So what could have been wrong, and how to detect this programatically with some way to notify the players, to be able to convey the same to the game refree or so. This would avoid any kind of tampering.

Have a read though this thread.
https://vexforum.com/t/field-control-a-technical-analysis/25651/1
specifically this post.
https://vexforum.com/index.php/conversation/post/104233

You should pay attention to the leds on the driver interface and also the game led on your joystick and cortex.

1 Like

Thanks @jpearman!, that was a nice thread! got my answers. Thanks.

1 Like