Motor.move_voltage() ignored after radio disconnect/reconnect

Programming Support
1

I’m experiencing a very strange issue with my PROS program after a disconnection and reconnection of the radio link.

I have a global variable containing a class that has a member pros::Task which controls the flywheel velocity via motor.move_voltage. The class can take signals from the user tasks (autonomous, opcontrol) via a member atomic variable to set the desired velocity.

This all works as expected throughout normal modes (disabled, opcontrol, autonomous, initialize) but if the robot loses and regains radio connection, the flywheel will stop moving even though I have verified that the task is still executing non-zero move_voltage commands for the motor (which return 1, no error).

The strange thing is that my drive train motors do respond to commands. Changing the flywheel velocity via the class increases the value sent to move_voltage yet has no effect.

I could not find any information on what happens when the radio link is lost (such as what internal pros function may be called). Clearly, the robot won’t move, but I found that disabled mode was not entered. What is up with that? Does anybody experience similar behavior? While it’s more likely to be user error, could there be a bug within PROS or Vex firmware?

I will post a minimal non-working example when I have access to a robot in a few hours.

3

I have confirmed the following procedure causes the issue:

  1. Start program
  2. Disconnect the radio’s smart port
  3. Reconnect the radio’s smart port

Alternatively, start the program and walk really far away until it disconnects, same result.

This makes the motor stop and not restart until the program is restarted.

#include "main.h"

void opcontrol() {
	pros::Motor motor(8);
	while (true) {
		motor.move_voltage(5000);
		pros::delay(20);
	}
}
4

That’s pretty much expected behavior, same thing would happen with a non-voltage command as well.

If the controller connection is lost, vexos will shutdown all motors, however, the user side code does not know about that and is also throttling messages to the motor. That is, if it thinks it just sent a similar message it does not send the same message again to reduce traffic on the serial bus. There’s no good workaround except to send a voltage command that’s sufficiently different (> 120mV I think) to get the motor moving again.

4 Likes
5

I take it this means that the actual control values that get sent to the motor for pwm are in the range [-100,100]?

1 Like
6

Is this a wontfix defect?

The workaround I used is like this:

// before loop
auto connectedPrev = pros::competition::is_connected();

// inside loop
if(connectedPrev != pros::competition::is_connected()){
      motor.move_voltage(std::numeric_limits<std::int32_t>::max());
}
connectedPrev = pros::competition::is_connected();

This works to jog the motor in a few seconds, but it only seems to kick in after the motor almost comes to a stop even if it is reconnected by then.

7

It’s been this way since vexos 1.0.0 in 2018, and this is the first time anyone has commented about it, so I’m not sure we consider it a defect. I may revisit all the logic surrounding this at some point, but the earliest anything like that would happen would be this summer.

I would probably monitor the controller connection status rather than competition status, but whatever works for you.

yes.

6 Likes
8

You are right about the controller status vs competition status, but I can’t edit my previous post.