Flywheel Characterization

[jhajel]

We want to do a velocity control for our flywheel. The wpilib characterization does not have a specific setting for flywheels. Has anyone done this? If so, do you have any advice?

Thanks,

JMH

[Prateek_M]

The “Simple Motor” setting can be used to characterize a flywheel shooter.

[pietroglyph]

Just to give some more info: the simple motor characterization tools can characterize any single output shaft subsystem, like a flywheel, swerve module, or turret. It supports one (or more) motors physically connected together as long as they have an encoder on them.

If you’ve already installed/updated frc-characterization then all you need to do is frc-characterization simple-motor new to start the process. You use it pretty much like any of the other characterization tools; following the driver characterization docs will get you pretty far, but there’s no dedicated simple motor documentation (sorry). I wrote the tool in the middle of build season so time was a little short and I never got to docs.

Here’s some of the data I collected on our prototype shooter when I was writing the tool:

[dan]

We currently use the “velocity” control mode of the Talon SRX to close-loop control the velocity of our shooter. We want to apply the kS and and kA gains from the characterization “simple motor”, calculate a feedforward value using these gains and the SimpleMotorFeedforward WPILib class. Then we’ll call the SimpleMotorFeedforward.calculate method and pass its value to the Talon SRX using “arbitrary feedforward” option.
We looked at the RamseteCommand for inspiration and there the acceleration passed to calculate is calculated by (current velocity setpoint - previous velocity setpoint) / dt.
In the RamseteCommand the velocity setpoint changes constantly and the septoint acceleration changes too.
However, the problem in the shooter is that the velocity setpoint does not change a lot if the robot shoots while staying still. In that case the difference mentioned above will be 0 after the first iteration.
What acceleration should we use in the feedforward calculation?
Thank you!

[jdaming]

I am not sure if this shooter characterization is right it looks different than the picture above.

We have two 775pros 2:1 with a Rev Through Bore encoder. Is that supposed to be listed as 2048 in the config? I also tried 8192 but that didn’t seem to work either.

[Oblarg]

That noise is a pattern we’ve only ever seen with magnetic encoders, whose root cause is not yet known. How close are your motors to your encoder?

[jdaming]

Guessing here but I would say 6 inches. We have a pulley on the motor shaft running a belt to another pulley on the shaft with all of the wheels.

Now the encoder is only supported in one direction to the shooter structure so I wouldn’t describe it as rigidly mounted (I would call it secure) but I didn’t expect that to matter for through bore encoder?

[Oblarg]

It may well matter; one of our suspected mechanisms is eccentricity in the magnet motion. If the thing is wobbling, this could cause the case to flex, introducing such eccentricity. Try securing the encoder more rigidly and see what happens.

[medjed]

Hi, we ran the characterization and successfully and got kS, kV, kA etc., so how do we go about actually implementing/utilizing these values? It’s our first time using simple motor characterization. Thanks! : )

[pietroglyph]

https://docs.wpilib.org/en/latest/docs/software/advanced-control/controllers/feedforward.html#simplemotorfeedforward

[JesseK]

Doesn’t this imply that you’re doing the control loop on the RIO? I suppose there’s no way to calculate the static kF that the current vendors support in order to offload the control to a faster controller?

[Prateek_M]

@JesseK

I suppose there’s no way to calculate the static kF that the current vendors support in order to offload the control to a faster controller?

It’s just a matter of converting the units. See my post here for more details:

Falcon 500 Closed Loop Velocity

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 (wi…

You will have to add in the Ks term via the arbitrary feedforward feature that most motor controllers support. The Ka term can be ignored for a shooter because the reference (setpoint) is constant.

[Oblarg]

@Prateek_M

You will have to add in the KsKs term via the arbitrary feedforward feature that most motor controllers support. The KaKa term can be ignored for a shooter because the reference (setpoint) is constant.

Rather than doing this, it’s probably cleaner to use the SimpleMotorFeedforward class and just pass the calculated feedforward voltage in through the arbitrary feedforward parameter.

[JesseK]

In this use case, isn’t the SimpleMotorFeedforward class effectively a kF gain scheduler?

We’ll poke around with a few different methods in the next couple of weeks.

[Amicus1]

I would call it kf calculator but basically yes.

[burakdemirelli]

Our data looks very similar as well. Were you able to fix it by mounting it more securely? Or what was the fix for you?

[jdaming]

What type of encoder are you using? I saw that @Oblarg made a PSA about this so we continued there.

[burakdemirelli]

Thanks for the direction! We are using a redline encoder to read data.

[jdaming]

Should be similar but remember to account for the 1024 CPR vs the 2048 of the throughbore