Talon SRX Drive with encoders Speed feedback plus distance

Hey Everyone,

I was wondering, is it common to use Talon SRXs with speed feedback using encoders on the drive train? Do you see great improvement in drive and control versus just the plain vanilla PWM fire and forget?

Also, do you use the same encoders to track distance? Do the Talons provide this data (I can’t find anything) or will we need to somehow split the encoder single to connect to a counter & the Talon-SRXs or add a second encoder to the shaft?

Any thoughts and ideas would be awesome.


As for your first question, the only input I can provide is that my team hasn’t tried speed based control.

For your second, you can definitely read sensor data from the Talon SRX over the CAN bus. I’m familiar with how to do it in LabVIEW and can show you how if you provide a little more information about your setup, but someone else will have to comment if you’re using Java/C++.

Our team used the RoboRIO for drive PID last year/offseason, and switched to talons this season. The difference in performance is very noticeable.

There are several threads discussing this, but the main effect is that the very fast control loop on the talons allows you to take a fundamentally different approach to tuning than is possible with PID control on the RoboRIO - namely, the proportional gain can be cranked up to very high levels without sacrificing stability (where, with a slower loop, one would have to rely on integral gain to push them to the setpoint, which is much slower to respond).

The improved performance is particularly noticeable as an inner loop in cascading control (in particular, with an angle control loop running on the RoboRio) - using a simple P loop with a bit of fiddling (we added a small minimum output and a deadzone around the setpoint), we can turn to within 1-degree tolerance quickly and with no overshoot, and a gyro-assisted drive straight command very happily responds to being kicked by tracking right back to the original direction. Neither of these functionalities worked particularly well with our previous speed control.

Thanks for your responses!

Our team is currently using Java (first year, we were using Labview since the beginning).

I’ll have to look deeper on how to read the encoder values so I can track distance while also running speed control on the drivetrain. That would be nice.

So, Talons provide very fast PID control and you highly recommend this as opposed to running the PID loop on the RoboRio, which is slow. In addition, the drive performance is much better using speed control than without it (open-loop control) & additional improvements can be made using a gyro to have the robot drive straighter during autonomous and telop modes. Are there examples integrating the gyro with drive correction?

You can look at our code, if you’d like - just do a google search for “frc 449 github.” It won’t exactly be possible to just copy snippets of code, unfortunately, since all of our stuff is written using our own sort of idiosyncratic framework, but it could be helpful for getting ideas of how to implement it.

To be honest, though, I think example code is less-useful than just conceptually understanding what it is that you’re trying to do. The idea behind using both velocity control and gyro to do drive correction (or turn-to-angle) is that, if you already have velocity control implemented on your drive, it is best to do a “cascading” PID controller to control your angle where the output from the angle control loop is fed as a setpoint to the velocity loop, rather than directly as a voltage to the motors.

Using talons, this is sort of implemented by default - if your standard drive subroutines are already using a talon in closed loop speed control mode, then any PID loop that outputs to your drive subroutines is going to be a cascaded loop.

So, take for instance our turn-to-angle loop: we implement this as a PIDCommand, whose usePIDOutput method calls the main drive method of our drive subsystem, sending the positive output to one side of the drive and negative to the other. Since our drive method then calls set() on a talon in closed-loop velocity control mode, this is cascaded control - the PIDCommand is the “outer loop,” and the velocity loop on the talons is the “inner loop.”

The upshot is that the “inner loop” (which you have already tuned, because you’re using it for your ordinary driving) ends up doing a lot of the “grunt work” of making the thing run smoothly, allowing you to have a comparatively simple “outer loop” (in our case, a simple P loop sufficed, albeit with a bit of tinkering to deal with stiction - though, adding a bit of integral gain to our inner loop can also achieve the same thing, though it behaves a bit differently and we like the other method better).

Drive correction is essentially the same as turn-to-angle, only the signal sent to the motors is the commanded throttle plus the output of the PID loop, rather than just the latter.

Thanks for the advice. I agree, it’s better to understand conceptually what you’re trying to do before using example code.

We’ll take a look, do some experiments, see how well we can get this to work and post some of our results for reference.