Falcon 500 Closed Loop Velocity

Technical Programming
1

Hello.

I am using basically exactly what is on CTRE github for doing the closed loop velocity. I changed the 4096 to 2048 to match the encoder resolution in the falcons. When I set the velocity to 200.00 RPM, I calculate 500 rpm out of the tuner. I get about 1700 units/100ms which is ~500RPM. Any help would be appreciated.

2 Likes
2

If you zero out your “P” gain and you are still getting 500 when you set 200, then your feed forward term is too high.

1 Like
3

So is the idea then to vary kf based on desired rpm?

1 Like
4

The kF value should not be “tuned”. You can use the frc-characterization tool to determine the proper relationship between voltage and velocity and get an appropriate kF (along with a kS and kA) from that (you’ll have to do some unit conversions from SI units to Talon units).

Alternatively, a less accurate method of obtaining a kF value would be to print the current motor voltage and velocity from the Talon FX, multiply the voltage by 1023 / 12 and divide by the velocity in native units per 100 ms. This will get you close enough to the setpoint and feedback should be able to take care of the rest.

1 Like
5

No. kF is a constant value. The concept is that given your input - let’s say 200 RPM, the kF is a gain that will make the output spin at roughly 200 RPM. Now there are some caveats to that. Often, you’ll find that it only works over a certain range. For instance, if you set your kF such that at a setpoint of 200 RPM you get 200 RPM, you may find that as it approaches significantly different values your error will increase. In a perfect world, where there wasn’t voltage sag or other ineffiencies, your output would be accurate over your entire RPM range with kF set to the right value.

The frc-characterization is one way to determine a kF. The mathematical estimation provided by CTRE’s instructions is another. Experimentally obtaining kF by changing your setpoint RPM’s in your target range and selecting a kF that gets the correct RPM’s in that range is another. Each is just a different way to accomplish the same thing.

6

So for minor adjustments I agree that KF is constant… but, if we are varrying by 1000 rpm depending on shot distance, there might be a reason to change it, to “take the pressure” off of Kp?

7

Prateek,

Using the characterization data, how would you estimate / calcuate kF? I don’t see it as being part of the tool, though I may have missed it in my quick perusal or it may be that it’s easily calculated from one of the other terms.

8

Here is how explained PID should work.

9

The kF term on most motor controllers (i.e. Talon SRX, Talon FX, Spark MAX) is multiplied by the velocity setpoint and added to the feedback output. This operation (kF * setpoint) is similar to the kV * \dot{d} (where \dot{d} is the velocity setpoint) in the characterization equation.

Assuming your characterization is done with SI units, your kV will have units of volt seconds per meter. This makes sense because multiplying a quantity with units of volt seconds per meter by a speed setpoint (with units of m/s) will result in units of volts, which corresponds to a typical motor signal.

Since this thread deals with Falcon 500, I’ll explain how to convert the kV from the characterization tool into a kF for the Falcon 500; however, similar dimensional analysis will apply for any other motor controller.

CTRE motor controllers require kF to be in units of output units / native units per decisecond, where output units are scaled in the interval [-1023, 1023]. As an example, I will use a Kv of 0.115 from the characterization tool on a mechanism with a gear reduction of 1:9.09 and wheel radius of 0.0762 meters.

\frac{0.115 Vs}{1 m} \times \frac{10 ds}{1 s} \times \frac{1023 \text{ output units}}{12 V} \times \frac{2 * \pi * 0.0762 m}{1\text{ output rotation}} \times \frac{1 \text{ output rotation}}{9.09 \text{ input rotations}} \times \frac{1 \text{ input rotation}}{2048 \text{ native units}}
= 0.00252 \frac{\text{output units * ds}}{\text{native units}}

In the calculations above, a native unit is one tick reported by the Falcon 500 internal encoder.

6 Likes
10

Fantastic. Thank you.

1 Like
11

Before I would consider essentially gain-scheduling kF, I would verify that I have voltage compensation set on the motor with a suitable voltage so that voltage sag is not effecting you. This will help to make the response more linear with less error. I suspect that is most of non-linearity on most shooters.

1 Like
12

can Talons(FXs) run in voltage compensation AND closed loop velocity? is this one of the reasons to forgo onboard PID vs wpilib PID?

13

Yes, you can use voltage compensation with closed loop control. Make sure you do all your tuning with voltage compensation turned on or it will cause errors.

2 Likes
14

For the case of the Falcon, would we have put in 1ms for the update period when generating the kV via the tool?

15

Those fields are for generating feedback gains. The feedforward gains are determined purely from the data. Everything on the right side of the window has to do with feedback.

1 Like
16

Does this assume we allow the characterization tool to get up to full speed with the flywheel? Do we also need to run the other subsystems at their expected rates as well? It is easy enough to modify the characterization code to spin a few things up if need be.

Running through @Prateek_M’s conversion, the resulting kF is 30% higher than what was experimentally determined to be the correct value for our slowest target speed, and I wonder if voltage sag is why.

17

I can’t really say since we don’t currently use the characterization tool.

18

You could also just set the arbitrary feedforward parameter. This would make it easier to convert units and allows kS and kA to be applied as well.

Example:

public void setClosedLoopVelocity(double velocityMetresPerSecond) {
    falconMotor.set(
        ControlMode.Velocity,
        velocityMetresPerSecond * kRotationsPerMetre * 2048 * 0.1,
        DemandType.ArbitraryFeedForward,
        simpleMotorForward.calculate(velocityMetresPerSecond) / 12.0
    );
}
2 Likes
19

Note that if voltage compensation is not enabled, you will want to divide by your actual voltage rather than assuming your current voltage is 12V.

1 Like
20

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