Protecting against runaway PID

[SuperBK]

This is in C++. What are some ways to prevent runaway of the motor when using the PID controller with an encoder when the encoder is not plugged in, it fails or the wire comes loose? The only thing I can think of is monitoring the encoder for changes over time and if the motor is driving beyond a certain threshhold and the encoder is not changing, turn off the motor. The PID controller could be applying a small amount of power to hold the arm still but in this case the encoder would probably be changing small amounts, as its not being held perfectly still.

Also, we could have a limit switch connected to the jaguar to turn it off if the arm reaches its limits. Plus safe mechanical stops.

Thanks,
Brian

[Matt Krass]

I would use the limit switch, along with safe mechanical stops. I believe you can poll the limit switch inputs on the Jaguars over CAN (assuming you're using it) and you could have the robot program check that periodically, if you see it set, you can tag a flag in your program, display an alert indicator on the Dashboard and switch to some kind of backup Vbus control mode or something.

I'd definitely put the limit switches in, the only way to keep a closed loop control system safe is to keep the loop closed, even if its just barely closed by a limit switch.

Matt

[virtuald]

If you're using the PIDController class in WPILib, instead of using the motor as a PIDOutput directly, we have used an intermediate class that checks to see if the motor is being manually overriden, and if so to not allow the PID controller to send output to the motor. Something like..

void PIDWrite(float output)
{
    if (!m_motor_overridden)
        m_motor.Set( output );
}

This year we're using the CAN mode of the Jaguars, and you can switch control modes from position mode to manual mode, and back. However, we didn't get enough testing time, and we had a bit of trouble getting the position mode to work [even just by itself, without the manual mode] because of what we suspect may be a faulty encoder... so we'll be playing with that soon before our competition in April. But we have shown that you can successfully switch modes.

We also have limit switches hooked up to prevent our arm from traveling too far.