V5 motors store part of the configuration (direction, units, voltage/torque limits, …) inside the motor and part at the OS level. While truing to improve robustness of the autons, we have observed the behavior of the V5 motors under several disconnect/reconnect scenarios and found one annoying inconsistency:
If you start with a motor connected, configure it for reverse (or switch the units), unplug it and plug it again, it keeps the configuration OK and resumes the operation as expected (with lost position, but that can be dealt with).
But if your program starts w/o the motor (and your code still blindly blasts the commands to a port), then the motor, upon reconnection, starts working OK, though your initial attempted configuration is lost.
We have observed this under PROS, not sure if the behavior gets any different under VexCode.
I can imagine a host of technical reasons why is it so, though it is an unfortunate inconsistence.
For us, the course of action is for the code to validate all the subsystems upon startup, guide the operators through the troubleshooting and then request program restart (while runtime disconnects get handled differently by the telemetry subsystem), but it would be nice if the behavior was consistent.
It’s a feature (bug really) of PROS. vexos keeps the configuration for flags like reverse if the motor is not present when user code starts or is unplugged, however, PROS doesn’t send it though on startup if it thinks there is no motor, VEXcode however does. The things we keep backup values for are
One reason for keeping these values is safety, I didn’t want a motor running at full power when user code had asked for low current and the motor was disconnected and then reconnected.
@nenik, this may be overcome by the new VEXos release as the current pseudocode described by @jpearman. Only for complete reference, back in August @codec reported similar behavior when unplugging motors under PROS. Minor PROS or VEXos motor bug
This is very nice, but isn’t this true that V5 motor requests updated configuration values every cycle and VEXos gives it the values that it stores in its internal tables.
No, that isn’t how it works.
V5 motor sends a (16B) status message every so often, which the brain can either plainly ACK (with otherwise non-commanding 16B message), or reply with a 16B command or configuration packet. Command packet contains PID speed, pwm-speed and PID target position, depending on the mode you’re controlling the motor with. Configuration, only sent as needed, could change some of the internal configuration, like limits or the PID parameters.
But looking back at my notes, it seems that brake mode, for example, is sent in every command packet, while direction, units and gearset has no place on the motor level (they seem to be the VexOS only, sw-emulated comcepts).
My observation boils down to PROS gating the calls to the VexOS when the PROS port governor decides there’s no motor at that port…
That’s correct, the reverse flag is handled by vexos and not sent to the motor, it’s much easier to handle things like updating the current motor position when user code changes the reverse flag while the motor is running (why you would want to do that I don’t know, but some of these design decisions were taken more than 4 years ago and based on robotc functionality).
yea, PROS always validates the the correct type of device is on a given port before calling into vexos