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

[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.