How is velocity control supposed to work on the Talon SRX?

[Wasabi Fan]

I'm trying to use the closed-loop control on the Talon SRXs to run the motor at a specified velocity. I have successfully configured the encoders and they read in the units I want them to. However, I'm having trouble with the concept of velocity control as it currently stands.

In many cases, a PID(F) controller is used for position control, where the property of the system that the control variable is acting on is roughly the derivative of the error property (velocity -- which is roughly proportional to motor power -- is the derivative of position). In this case, however, the output of the controller will be roughly proportional to the input. That means that, when the error is zero (the motor is spinning at the desired velocity), output will fall to zero and by extension the motor will no longer be spinning at its target speed.

Intuitively, I expect this would result in the motor falling into a state of equilibrium where the error value corresponds to an output speed that sustains that error value. This behavior doesn't actually run the motor at the desired velocity, it runs it at an unpredictable velocity. The F parameter could be used to get closer to the target, but the P and D parameters still wouldn't be doing anything.

What is the proper way to handle this with the Talon's built-in velocity control? I would normally implement velocity PID by adding the output of the PID to a velocity accumulator, but in this case I can't do that because the closed-loop control logic is being run on the motor controller itself.

[Bryce2471]

Originally Posted by Wasabi Fan

I'm trying to use the closed-loop control on the Talon SRXs to run the motor at a specified velocity. I have successfully configured the encoders and they read in the units I want them to. However, I'm having trouble with the concept of velocity control as it currently stands.

In many cases, a PID(F) controller is used for position control, where the property of the system that the control variable is acting on is roughly the derivative of the error property (velocity -- which is roughly proportional to motor power -- is the derivative of position). In this case, however, the output of the controller will be roughly proportional to the input. That means that, when the error is zero (the motor is spinning at the desired velocity), output will fall to zero and by extension the motor will no longer be spinning at its target speed.

Intuitively, I expect this would result in the motor falling into a state of equilibrium where the error value corresponds to an output speed that sustains that error value. This behavior doesn't actually run the motor at the desired velocity, it runs it at an unpredictable velocity. The F parameter could be used to get closer to the target, but the P and D parameters still wouldn't be doing anything.

What is the proper way to handle this with the Talon's built-in velocity control? I would normally implement velocity PID by adding the output of the PID to a velocity accumulator, but in this case I can't do that because the closed-loop control logic is being run on the motor controller itself.

Very astute observations. I believe there is much debate about this topic. I agree with you that the output of the PID should be accumulated before being set as motor power. However, I think many in the chief Delphi community think that the P, I, D, and F values should just be tuned to get as close to the set speed as possible.
In the case of the talon, I do not have a lot of experience but I don't think there is a lot you can do. Like you say, the code you would like to edit is firmware on the talon itself.

[ozrien]

The general goal is calculate or tune a FeedForward gain so that the sensor velocity is near the target velocity. P (and potentially D/I) are then tuned to respond when the velocity error is nonzero. This allows for an aggressive closed-loop response with less overshoot caused by large changes in target velocity (let F do the heavy lifting).

To make this clearer we provide an velocity closed-loop walkthough in our documentation and examples on our site/GitHub.

Section 12.4 (Talon SRX Software reference manual)
http://www.ctr-electronics.com/talon...ical_resources

[Wasabi Fan]

The general goal is calculate or tune a FeedForward gain so that the sensor velocity is near the target velocity. P (and potentially D/I) are then tuned to respond when the velocity error is nonzero. This allows for an aggressive closed-loop response with less overshoot caused by large changes in target velocity (let F do the heavy lifting).

Using the F parameter to get close is a good policy, but it doesn't fix the problem. Using F as a crutch is no better than just setting a power target directly; the value produced by F doesn't change as the state of the system does. The issue here is that, as velocity PID is implemented in the Talons currently, P is useless. One must rely on the I term, because it is the only term which will actually help you get to your velocity goal based on changes in the system.

[GeeTwo]

Originally Posted by Wasabi Fan

One must rely on the I term, because it is the only term which will actually help you get to your velocity goal based on changes in the system.

This.

While I can usually be skipped when driving to a position, it is essential to tuning a velocity control PID for a realistic (can't control every variable) situation.

[R.C.]

Originally Posted by Wasabi Fan

Using the F parameter to get close is a good policy, but it doesn't fix the problem. Using F as a crutch is no better than just setting a power target directly; the value produced by F doesn't change as the state of the system does. The issue here is that, as velocity PID is implemented in the Talons currently, P is useless. One must rely on the I term, because it is the only term which will actually help you get to your velocity goal based on changes in the system.

We followed Omar's advice this season and used pdf control. We got our shooter speed to +-.50 rpm of our goal. This has been the cleanest we've ever gotten.

[Jared Russell]

Originally Posted by Wasabi Fan

The issue here is that, as velocity PID is implemented in the Talons currently, P is useless..

This is totally false in practice. Proof by counter-example:

254 used Talon-based velocity control on both our drive motors and our flywheel last season. In both cases, we used a PD+F controller and were able to track our setpoints to within +/- single digit RPM despite no integral action, even with varying battery voltage, system load, and (for the drive) while traversing defenses.

The reason why this works well is (a) feedforward, and (b) a really fast 1KHz control loop. Both of these factors let you crank up your feedback gains without sacrificing stability.

Feedforward helps because it deals with the nominal dynamics of the system so that feedback only needs to worry about dealing with modeling errors and disturbances. Usually this means that feedforward is doing most of the heavy lifting, so the feedback gains can be really aggressive because the disturbance is pretty small in magnitude. Likewise, a faster loop means that your P term can correct for the current error very quickly, so even if you overshoot by a little bit, a millisecond later you are compensating.

Our tuning methodology was to start with a nominal battery and load (e.g. flat floor and no other systems running) and tune F first, as recommended in the Talon SRX Software Reference Manual. Once this was working, we tuned our P gain until we oscillated (very quickly! 1KHz loop ) around the setpoint. Then we crank up D until the oscillation is no longer noticeable to your eye or in a plot of system response. For both of our systems last year, this meant a D gain on the order of 4-5x Kp.

I understand the sentiment around saying that integral gain is the only way to ensure that in the steady state (error=0), your system continues to operate at your desired setpoint. This is theoretically correct. But, with a sufficiently high Kp and Kd, you can react quickly to very, very small errors that are about the same magnitude as your velocity measurement error. In other words, more than good enough for FRC.