Competition Code Continues To Run If Robot Disconnects [PROS]

This weekend we experienced two instances where the robot disconnected from the controller, but continued to run the code we had programmed.

The first was during autonomous mode, the robot lost connection and we saw the red screen on the controller. After this point, the robot continued to move around the field in an uncontrolled fashion, the motors were not running at a constant speed, but were seemingly random (not what we had programmed it to do). In the end, I had to step onto the field to turn the robot off to make it stop. We showed the refs that the controller was connected to the field, but they ruled that it was our fault, and awarded autonomous to the other team. We then turned the robot back on, reconnected with the controller, and continued the match with no further issues.

The second was during driver control. The robot lost connection, and remained still for the rest of the match. After the end of driver control, however, we noticed that the robot was still trying to hold up its cap lifter (not just running the motors at a set power, but still running the proportional control loop we use for competition).

We won both matches regardless of these issues, but we want to figure out why this happens.

Here’s our theory:

Our code is split into several tasks, one for the drive, one for the lift, etc. In autonomous mode these tasks read flags set in the autonomous task and sensors to figure out how to move the motors.
Our best guess for why the robot drove around randomly in autonomous is that when the robot disconnected, the autonomous task was stopped, and the drive task was no longer able to read the gyro sensor correctly. Since the autonomous task decides when to terminate the drive move, and was stopped, the drive move never terminated. Since the task couldn’t read the gyro sensor properly the drive drove in an ever changing direction, giving the impression of random movement.
For the second instance, the lift task must have kept running, but was still able to read the motor encoders to set the motor speeds properly.

We are using the PROS 3.1.4, and are using wireless flashing with hot/cold linking enabled. All our tasks are in the opcontrol file. We did not experience this issue before the update, and have since seen it once in practice, and twice in competition.

Any explanation/fix would be greatly appreciated.

Not sure what is going on, but you could try to change your while loop from while(true) to while(!pros::competition::is_autonomous()) or while(pros::competition::is_autonomous()) depending on what you need.
Basically, a task will not automatically be stopped by anything, even if you start the task in opcontrol or autonomous.
Therefore, if you start a task in opcontrol and flip a competition switch back and forth, there will be multiple instances of the same task running at once.
Also, take a look at this, it might have something to do with it.
Alternatively, you could do what I do for tasks: global pointers.
I have a list of Task pointers, which at the beginning of the program start off as nullptr.

pros::Task* intakeTask_t = nullptr;
pros::Task* flywheelTask_t = nullptr;

Then, in initialize, I create those tasks dynamically

flywheelTask_t = new pros::Task(flywheelTask);
intakeTask_t = new pros::Task(intakeControlTask);

After that, I can pause and start the tasks in opcontrol or autonomous or disabled depending on the need. I wrote this function to help me with that:

/***   _____         _
*    |_   _|       | |
*      | | __ _ ___| | _____
*      | |/ _` / __| |/ / __|
*      | | (_| \__ \   <\__ \
*      \_/\__,_|___/_|\_\___/
 * Checks current task state and changes it if the state does not match the wanted state
 * @param taskPtr  pointer to the task
 * @param taskMode one of two options, TASK_STATE_SUSPENDED or TASK_STATE_RUNNING
void setTaskState(pros::Task* taskPtr, pros::task_state_e_t taskMode) {
  if(taskPtr != nullptr && taskPtr->get_state() != taskMode) { switch(taskMode) {
    case TASK_STATE_SUSPENDED: taskPtr->suspend(); break;
    case TASK_STATE_RUNNING: taskPtr->resume(); break;
default: {} } } }

This could help you, as you can stop all tasks in disabled then start them again in opcontrol.
Also, you could write a function that first checks to see if a task pointer is nullptr, then if yes create a task to that pointer. That way you can start tasks in opcontrol without worrying about duplicate tasks being started.
Hope this helps

controller disconnect should stop all motors, were you on vexos 1.0.5 ?

@theol0403 Thanks for your response.
I will try this when we get back to work on Monday.

I should mention that each instance of the issue happened on different bots, using different controller, but running the same code.

We start the tasks once when the robot starts up, and then never again, so there is only ever one instance running.

If we switch the game switch to disabled whilst the robot is in the middle of driving in autonomous then it does stop, implying that the task is at least paused (or the motors are disabled) when autonomous ends.
The issue is that the code doesn’t stop setting motor values if the robot and controller lose connection, at which point the robot will have no way of knowing it should be disabled

Looking at the PROS API, would something along the lines of:

if ( !controller.is_connected() ) motorSpeed = 0;

work to force the motors to stop if the controller lost signal?

@jpearman We are running 1.0.5 on both our bots

Did you lose connection briefly or for the whole of the autonomous period?

We lost connection for the remainder of the autonomous period the first time it happened. We had to turn the brain off to make it stop moving and reconnect whilst the other robots were all disabled.
The second time (different match, different bot) we lost connection for the remainder of driver control, and again had to turn the robot off to make it stop and to reconnect after the match.

are you able to reproduce this by just turning off or reseting the controller ? If so, I probably would want to get your code and try and duplicate. The robot should always be disabled if there is no connection to the controller.

We will try to reproduce this on Monday, but from what I remember, this has only every happened when losing connection and being connected to a field controller or game switch.
Turning the controller off has always quit the program running on the brain, but I will try resetting the controller to see if that causes the issue.
Should I also try unplugging the radio to force a connection loss?

It’s true.
China has just held a competition. There are more than 200 VEX-EDR teams participating in the competition.
I had the privilege of being a referee. I saw it all.
Whether vcs or pros, there is a chance that such a problem will occur.
Our team has field control.He had the same problem. v5 also upgrade to 1.05 .
In addition, the problem of frequent disconnection of “vision” disconnection has not been solved.

1 Like

I am the author of PROS/issue#102 and was a participant in the Asia Open.
I can not find any code be responsible for “motor control”. PROS DOES NOT shut down any motors in any time. PROS only controls 3 tasks(init, opcontrol and auton). PROS does not kill or suspend any tasks started by the user.
That’s mean if the brain disconnect with the controller, the VexOS will shut down all motors. I think it is a problem of VexOS or hardware. @MeMyselfAndI.

1 Like

it’s cool .
Are you in the Vex U group?

Yeah, tournament finalists in Asia Open.

Xi’an Jiaotong University? 2018 World Champion?

@jpearman I was able to recreate the problem by pushing the reset button on the back of the remote.
In my tests, it never stopped running motors when this happened, but the motor movements became irratic, as if they were being turned off for a small amount of time before being powered again

yes, thanks, we understand the issue and it will be fixed in vexos 1.0.6 due out shortly.