Minimum Flywheel Encoder CPR
 

My team was considering buying cheap 20 CPR encoders for our shooter, reasoning that the encoder on a high-speed flywheel can get away with having less resolution without hurting performance. All the other encoders we have worked with have had 4092 CPR (or 512 CPR on a quadrature), so 20 CPR encoders seemed kinda sketchy to me.

What is a good rule of thumb for minimum CPR for a flywheel of a specific maximum velocity?

Re: Minimum Flywheel Encoder CPR
 

Assuming you're measuring off of the flywheel:

A single cycle per revolution on a slow flywheel would still get you at least 2000/60 = 33 cycles per second. This might be a bit low for a tight control loop, but you could definitely work with it.

I say this is ok because it means you get information on each edge of the encoder, so 66 times per second. This means the fastest it makes sense to fully evaluate your control algorithm more than ever 1/66th of a second (about 15ms or so, which is on par with most algorithms).

Now, in general, it's better to get a handful of samples and average them, but you could still get by without it in many cases....

So, basically any encoder. The worse limit is having a very high CPR, and generating frequencies beyond the sampling limits of the controller. Still, the RIO samples at 40MHz, so this would still be hard to violate.

Re: Minimum Flywheel Encoder CPR
 

If I recall correctly, in 2012 we had 1 count per revolution on our shooter wheel. The trick then becomes smoothing the counts with a low pass filter.

This year, you may want a little higher resolution (due to trying to shoot more balls per second), but I'd imagine 20 counts per revolution would work just fine.

Re: Minimum Flywheel Encoder CPR
 

Highly recommended if using a one-count-per-rev sensor: use the FPGA to measure the period between the last 2 counts. Do not filter that value, since it represents an entire revolution... and there is no issue with noise due to physical edge location since it's the same edge being measured each time.

Re: Minimum Flywheel Encoder CPR
 

Note that if you're planning on using the Talon SRX to run your control loop, it has a fixed definition of quadrature counts per 100ms as the velocity definition. And it actually runs the control loop at 1kHz. I'm not entirely certain how they bridge that gap, though.

Re: Minimum Flywheel Encoder CPR
 

We're using the Armabot RS7 encoder (advertised "12 CPR") with the Talon SRX. In our Java code, we called the method "talon.setEncoderCodesPerRev" to be 1/4th of the CPR (so....3 :) ) in order for the velocity to be true (we tested with a tachometer. After you set that number, you can use "talon.set(rpm)" to have the motor run at that RPM without any other math.

Re: Minimum Flywheel Encoder CPR
 

This is what we are doing with great success.

Re: Minimum Flywheel Encoder CPR
 

Sorry to change the topic but has anybody used a SRX Mag Encoder on a flywheel?

Re: Minimum Flywheel Encoder CPR
 

The Talon SRX Software Reference Manual uses that for all of their examples (and the CTRE GitHub page too)

Re: Minimum Flywheel Encoder CPR
 

We did, in our preseason project.

It worked just fine.

Re: Minimum Flywheel Encoder CPR
 

jojoguy: I'm having a hard time working through the math that gets me to "setting CPR to 3 let's me specify setpoint in RPM". Can you lead me through the math?

we're off for 3 night (exams!), so I can't fiddle with it in the lab.

Re: Minimum Flywheel Encoder CPR
 

The talon SRX library completely changes its unit handling (for some functions, but not others!) if you specify your encoder CPR (or if you use an input device for which it knows the CPR, i.e. the CTRE mag encoder).

I, for one, think this is terrible design.

Re: Minimum Flywheel Encoder CPR
 

It depends on whether the advertised CPR is cycles per revolution or edges per revolution - these differ by a factor of 4.

The config method wants the former, despite all the native units being calculated using the latter.

Yes, this is confusing and bad and should be changed :(

Re: Minimum Flywheel Encoder CPR
 

That works.

We started the build season with a different encoder, and for a reason I can't recall, it got swapped. I'm remembering that the encoder was noisy, and needed to be debounced. The students didn't want to rewrite all of their code, so I gave them the band-aid. Our shooter wheel was very consistent that year, unfortunately the foam basket balls weren't.

Re: Minimum Flywheel Encoder CPR
 

Ah, now I *think* I understand. Once I say .ConfigEncoderCodesPerRev(3) [which is correct, 12 transitions per rev is 3 cycles or counts per rev), then the .set() method works in RPM.

If I don't call .ConfigEncoderCodesPerRev(), then .set() works in the silly transitions / 100ms units.

Do I have that correct?