Minimum Flywheel Encoder CPR

[rtse]

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?

[gerthworm]

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.

[efoote868]

Originally Posted by rtse

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?

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.

[Ether]

Originally Posted by efoote868

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.

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.

[Kevin Sevcik]

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.

[jojoguy10]

Originally Posted by Kevin Sevcik

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.

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.

[Type]

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

[jojoguy10]

Originally Posted by Type

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

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

[Oblarg]

Originally Posted by Type

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

We did, in our preseason project.

It worked just fine.

[fovea1959]

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.

[Oblarg]

Originally Posted by fovea1959

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.

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.

[Oblarg]

Originally Posted by fovea1959

I know it changes, but I still can't arrive at CPR = 3 (instead of the CPR = 12) ends up with "I'm working in RPM". I'm trying to understand why that works...

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

[fovea1959]

Originally Posted by Oblarg

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

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?

[notmattlythgoe]

Originally Posted by Ether

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.

This is what we are doing with great success.

[efoote868]

Originally Posted by Ether

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.

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.