Talon control mode when encoder dies

We are running a talon srx on our proto bot elevator. We are using closed loop velocity control mode. It has been running for a few weeks. We recently pushed the same code on to our comp bot with identical hardware and the elevator runs down wayyyy too fast.

We discovered the proto bot had no encoder values being reported. However the comp bot did have good encoder values.


If the Talon SRX is configured as closed loop velocity but has no valid encoders, what happens?
Does it revert to %Vbus mode?

Is that in the manual anywhere? I didnt see it.

Any help would be great.


I don’t believe the controller has any way to tell the difference between an encoder that’s missing and one that’s reporting zero velocity, so it doesn’t revert to anything, it just uses zero in its calculations.

If the encoder reported zero speed in closed loop velocity mode, wouldn’t that cause the Talon to go to maximum output?

That’s been our experience.

If encoder cable gets cut then both encoder signals A and B will be the same (both hi or both low) which is an error condition. Does the Talon recognize this?

What does the Talon do in this case?

No, in normal operation the quadrature signal goes through all four states.

The TalonSRX wont revert to %Vbus mode if no signal is given. Assuming the lack if sensor reports 0 for position amd velocity, I would expect it to run much faster without it, as the error is unchanging.

Have you plotted the data you are receiving with Phoenix Tuner? Specifically the %Output, Velocity, Position and Closed loop error.
That should help visualize the differences between the 2 bots.

As Buchanan stated, it is valid for both of the encoder outputs to be in the same state in normal operation. In your case, if the cable is broken or disconnected, it causes the Talon to interpret this input state as the encoder shaft is not rotating at all.

The ultimate solution may be to add a layer of software that does a sanity check on the sensor values received and then taking “appropriate action”.

If I recall correctly, one of our local powerhouse teams sat dead on Einstein because a sensor became unplugged and their software could never get the sensor value it needed to end a loop.

Thank all of you for the feedback.

Still trying to determine why we got reasonable movements from our elevator which was running closed loop velocity with no encoder feedback.

Looking at the bolded text it appears like your proto bot’s gains were tuned either with just f or p and f, so the motor output will be consistent based on the desired velocity, how did you tune the original system without any sensor feedback to confirm the closed-loop error was within reasonable levels?

If I had to guess, the elevator moves faster probably because the sensor is out of phase, and you have a runaway velocity (As you command a negative velocity, the motor moves in the negative direction and the sensor reports a positive velocity, so the PID controller compensates by applying more negative power). Following the Motor Controller Sensor Bringup section in the documentation would reveal this, or a self-test while the elevator was running would reveal it with the “Sensor out of phase” fault.

Next time you get access to the robot, I suggest following these steps to confirm the sensor’s not out of phase:

It’s also worth following those steps on the proto-bot so that you know what to do next time you get access to the competition robot.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.