Closed JaciBrunning closed 6 years ago
[1] This is the intent of the feature, and has been how it works since the beginning. [2] This is useful because you can disable the robot during operation and inspect the control mode. [3] When operating on robots, there must be an alert operator at the Driver Station disable. If you cannot ensure this, no amount of the software changes will ensure safe operation. [4] This is true for PWM motor controllers as well. [5] Feel free to neutral the motor controller in your disable loop.
We've been using the Talons for awhile now and did not know this was intended behavior, and as our code is now (awaiting a bot, of course) we would have found this "the hard way" soon.
I went through the docs in the repo, but didn't find any mention of this. Could we ask that the docs get updated to make this a bit more pronounced? I do agree with Jaci that, depending on the code it could cause unexpected operation and a safety issue.
I'm going to reemphasize this: every motor controller behaves this way, and has behaved this way since the 2003 (and likely before that). Perhaps FRC/WPILIB/NI should document this since this is a property of the control system, not the motor controller.
However, if you are not able to ensure a reliable DS operator is present when testing, and you are not willing to instruct your motors to neutral prior to sequential robot-teleop operations, you might consider using the motor-safety features of your desired language. At least this way the motor controller will be neutral-ed as a result of not calling the set routine periodically. This is by no means a proper alternative to the Driver State disable features.
Could you detail a little bit about what a recommended way to "instruct your motors to neutral prior to sequential robot-teleop operations" for the TalonSRX? Specifically looking to get the talon to clear any PID control that may be active between commands or moving to a disabled state back to an enabled state.. Examples might be:
_talon.set(ControlMode.PercentOutput, 0); _talon.set(ControlMode.Disabled, 0);
Either one of those examples are fine. When you change the Control Mode, you've unhooked the PIDF output from the hbridge. Are you having a problem where that seems insufficient? If so there might be something unique going on, or something you missed in your implementation, in which case contact support@ctr-electronics.com to get individual help.
One more note, for this to be done correctly, I think all motor controllers should do this, or none of them. If the argument is that the current implem is not safe, then changing some MCs and not others seems strange to me. Which means WPI would have to implement this for the PWM MCs (including PWMTalonSRX). So I suppose if WPI commits to this change, we would consider it so neutral-expectations are common everywhere.
When the talon is disabled, the Set() value is not cleared from the talons memory, so when activated again, it recalls this value. This is especially troublesome when a robot is disabled from teleop while a throttle is applied, and is then switched to the autonomous with a blank method body. This is a potential safety risk to users