ROBOTC Competition Switch Bug

We’ve noticed a strange bug with testing our autonomous programs in ROBOTC. When we use the Programming Kit connected to our controller and switch between “Disabled” and “Autonomous” on the debugger window in ROBOTC, our autonomous program will fail exactly after a second of running.

This happens every OTHER time though, making it still possible to run the program. But it is consistently every other time that it fails. This has been happening for about eight months with pretty much every file, cortex, and version of ROBOTC we have used. It doesn’t appear to be a code issue. We do use IMEs along with an LCD to pick our autonomous program if that may be a factor in the issue. We are running ROBOTC 4.06.

Another bug (that isn’t as annoying), is that when we click on Driver Control when in the Autonomous mode, the robot will run its autonomous once again, making it really fun when one of our team members is nearby… :wink:

Does anyone have any feedback on these issues?

I’ve had almost an identical issue, also using the IMEs and LCD. Using RobotC 3.62 however.

Could you describe more clearly what you mean by “failing”? Does the autonomous code stop altogether, execute incorrectly, or lock up with motors running at the last set value?

Posting your code might help any ROBOTC experts to isolate a problem.

Perhaps you could make a new file with just a main function, something like this:

void main()
{
	while (1)
	{
		if (nVexRCReceiveState & vrAutonomousMode)
			writeDebugStream("Auton  ");
		else
			writeDebugStream("Driver ");

		if (nVexRCReceiveState & vrDisabled)
			writeDebugStreamLine("Disabled");
		else
			writeDebugStreamLine("Enabled");

		wait1Msec(15);
	}
}

Then open the debug window while running the robot so you can see what mode the robot thinks it’s in. That way you can start to get an idea of what’s wrong.

I set up a program with the code you provided and it confirmed the issue. Every other time I switch from “Disabled” to “Autonomous”, the Debug Stream will show “Auton Enabled” for about a second and then automatically switch to “Driver Enabled” without me clicking any button. What do you think causes this?

Almost definitely a RobotC bug. The emulator just sends the cortex a message which says, “Hey cortex, switch into autonomous mode.” So, it looks like the emulator is sending a second message to go back to driver for some reason. I don’t use RobotC so I can’t confirm the issue myself, but I believe you :).

I would sent them a bug report, but looks like the RobotC website is down.

If you really need a working switch vitally for some reason, PM me and I’ll send you a competition switch emulator I wrote as a proof of concept as part of a bigger project. But only if you really need it; It was just a proof of concept so I’d need to clean it up a little.

You could always make a switch while the bug is being fixed. This is the schematic for the competition switch http://content.vexrobotics.com/docs/VEXnet%20Comp%20Sw%20Diagram.pdf
This is an example of what a completed one looks like https://vexforum.com/showpost.php?p=235768&postcount=9

Let me try and explain what is happening and why ROBOTC has less control over this than you may think.

There are only two messages that are sent using the programming cable that can control the competition mode.

  1. A message that toggles the disabled/enabled state. Every time this message is sent the current state is changed, if the robot is disabled then it will be enabled, if the robot is enabled then it will be disabled. If the robot is not in game mode then the first message will place the robot into the disabled state.

  2. A message that toggles the autonomous/driver control flag. Each time this message is sent the robot will change modes.

Put this information aside for a moment and consider the architecture of the cortex. As we have discussed many times, the cortex contains two micro-controllers that we have referred to as the master processor and user processor. ROBOTC (and EasyC, ConVEX and PROS) runs on the user processor, the master processor controls the USB port, either in tethered mode or with VEXnet, the motors and competition state. The user processor communicates periodically with the master processor, the user processor sends motor speeds for motor ports 1 through 9 and receives the joystick and other status. One of the status bytes contains two flags (bits within the byte) that indicate what the competition state is, that is, is the robot disabled or enabled and is it in autonomous or driver control. These two flags are read by ROBOTC and used to set the variables that can be read by the code as bIfiRobotDisabled and bIfiAutonomousMode. They are also sent back to the PC when we are debugging and displayed in the system parameters window as well as being used by the competition switch simulation. There is a major issue with these two flags, the auton/driver control flag does not indicate the correct status when the robot is disabled.

So what happens with ROBOTC.

We push the Autonomous button, ROBOTC sends the message to toggle the competition disabled/enabled state but does not know for certain if the robot will enter autonomous or driver control. ROBOTC checks to see if the robot is enabled and also the auton/driver status, if it finds that the robot has entered the driver control mode then it sends the message to toggle auton/driver control. This is why when you start either mode, auton or driver, you may find the robot briefly starts in the wrong one and then changes.

With only three buttons it’s very easy to get ROBOTC out of sync with the actual operation of the robot.

My advice, don’t use the competition switch simulation and always use a real competition switch.

ROBOTC V4.06 has an additional bug where the auton/driver flag seems to be changing state on it’s own. This is a new bug that was not present in the V3.6X versions and needs to be fixed.

Thanks for explaining this issue so clearly. We will start using a real competition switch from now on.