Finding RPMs with encoder

[Sparx030]

I am trying to set up an encoder to tell me the RPM of a shooter, the encoder is a US digital s4t - 120 - 250 encoder and 4x decoding. I see the multiple ways to get information from an encoder (getRate(), getPeriod(), get()) but what should I use to find RPMs with this encoder. Also, I don't know what to set as my setDistanceperpulse(), is it asking for how far the motor will move per pulse and if so by what unit of measurement is it asking?

[RyanN]

Originally Posted by Sparx030

I am trying to set up an encoder to tell me the RPM of a shooter, the encoder is a US digital s4t - 120 - 250 encoder and 4x decoding. I see the multiple ways to get information from an encoder (getRate(), getPeriod(), get()) but what should I use to find RPMs with this encoder. Also, I don't know what to set as my setDistanceperpulse(), is it asking for how far the motor will move per pulse and if so by what unit of measurement is it asking?

S4T is the model... nothing interesting there.

120 is the Counts Per Revolution (CPR). That's the resolution of the encoder per 360 degrees of rotation. So it will provide 120 counts/pulses/ticks per 360 degrees... or one count per every 3 degrees.

I'm not sure what language you're using, but I'm only familiar with the LabVIEW libraries.

The getRate() function will provide you with a counts / second value while getPeriod() will return the inverse, seconds / count. I imagine get() returns the total counts since the encoder count value was reset. The setDistancePerPulse() function should take in either degrees or radians equal to 3 degrees.

Finally, 250 is rather boring to this control mentor. It's just the shaft size, 250 mils or 1/4" shaft diameter.

[FrankJ]

Originally Posted by RyanN

...Finally, 250 is rather boring to this control mentor. It's just the shaft size, 250 mils or 1/4" shaft diameter.

Might be boring, but it is useful information if you want your encoder to be more than a paper weight. And they make crappy paper weights.

[Sparx030]

Originally Posted by RyanN

S4T is the model... nothing interesting there.

120 is the Counts Per Revolution (CPR). That's the resolution of the encoder per 360 degrees of rotation. So it will provide 120 counts/pulses/ticks per 360 degrees... or one count per every 3 degrees.

I'm not sure what language you're using, but I'm only familiar with the LabVIEW libraries.

The getRate() function will provide you with a counts / second value while getPeriod() will return the inverse, seconds / count. I imagine get() returns the total counts since the encoder count value was reset. The setDistancePerPulse() function should take in either degrees or radians equal to 3 degrees.

Finally, 250 is rather boring to this control mentor. It's just the shaft size, 250 mils or 1/4" shaft diameter.

I am using Java but this information was very helpful. I wan't able to find whether or not the code used counts per second, per minuet, or anything.

Thank you for replying.

[Ether]

CPR is cycles per revolution. One cycle has a rising edge and a falling edge on each channel.

The number of "counts" per rev depends on the way you decode it.

Counting rising and falling edges on both channels will give you 480 counts per rev

Counting rising and falling edges on one channel only will give you 240 counts per rev

Counting only rising - or falling - edges on one channel only will give you 120 counts per rev

[Sparx030]

Originally Posted by Ether

CPR is cycles per revolution. One cycle has a rising edge and a falling edge on each channel.

The number of "counts" per rev depends on the way you decode it.

Counting rising and falling edges on both channels will give you 480 counts per rev

Counting rising and falling edges on one channel only will give you 240 counts per rev

Counting only rising - or falling - edges on one channel only will give you 120 counts per rev

Correct me if I'm wrong but would the 480 counts be for 4x, 240 for 2x, and 120 for 1x? Also, I have been told that 4x deciding is needlessly complicated for what I am doing (maintain RPM on a shooter with a PID) would you agree with that and if so what do you recommend?

[Ether]

Originally Posted by Sparx030

Correct me if I'm wrong but would the 480 counts be for 4x, 240 for 2x, and 120 for 1x?

That's my understanding of the WPILib code. But I'm not a WPILib guru.

Also, I have been told that 4x deciding is needlessly complicated for what I am doing (maintain RPM on a shooter with a PID) would you agree with that and if so what do you recommend?

To answer that, I need more information.

What make and model encoder are you planning to use?

Where do you intend to mount the encoder?

How fast will the encoder be spinning at your shooter operating point?

Is the motor output shaft directly connected to the wheel? If not, describe the transmission.

What motor and motor controller are you planning to use?

Will you be connecting the encoder to the RIO, or to the motor controller (if SRX)?

[Sparx030]

Where do you intend to mount the encoder

On the shooter wheel

How fast will the encoder be spinning at your shooter operating point?

This may change but let's just say 3000 RPM

Is the motor output shaft directly connected to the wheel? If not, describe the transmission.

It will be directly connected

What motor and motor controller are you planning to use?

AndyMark RS775-5 with a Victor controller

Will you be connecting the encoder to the RIO, or to the motor controller (if SRX)?

The RIO

Also, if possible, would you be able to provide a brief generalization of what each decoding type is used for?

[Ether]

Originally Posted by Sparx030

On the shooter wheel

This may change but let's just say 3000 RPM

It will be directly connected

AndyMark RS775-5 with a Victor controller

The RIO

Also, if possible, would you be able to provide a brief generalization of what each decoding type is used for?

Not that it matters that much, but Victor SP or 888 ??

And did you consider using bang-bang instead of PID? This is the perfect application for it. And there's no tuning required.

A 250 CPR encoder spinning at 3000 RPM is easily decoded by the roboRIO at 4X or 2X or 1X. It samples for edges much faster than the cRIO did, which removes many of the considerations which came into play in the cRIO days with high-RPM high-CPR encoder use. But, there are still some things you need to know to be successful.

I will expound on that and answer the rest of your questions in a few minutes.

EDIT: Oh, and what is the period of your control loop (e.g. 20ms, 10ms, etc).

[Sparx030]

Originally Posted by Ether

Not that it matters that much, but Victor SP or 888 ??

They are Victor 888.

And did you consider using bang-bang instead of PID? This is the perfect application for it. And there's no tuning required.

I have heard of it and got it to work very well but a PID might be used for other robot systems that I can't test right now and while those would be very different from this shooter I would still like to be comfortable with PIDs.

[Ether]

What is the period of your control loop (e.g. 20ms, 10ms, etc)?

[Sparx030]

Originally Posted by Ether

What is the period of your control loop (e.g. 20ms, 10ms, etc)?

20ms

[Ether]

Originally Posted by Sparx030

20ms

OK, doing the calculations for 1X decoding:

rpm=3000; CPR=250; X=1; secondsPerControlLoop=0.020;

edgesPerControlLoop: rpm * (1/60) * (X*CPR) * secondsPerControlLoop = 250

So 250 edges fly by every 20ms, which should be plenty enough to get a nice accurate and clean speed signal at 1X decoding. I recommend setting the FPGA sample size to something greater than the default value of "1"... say maybe 64.

If you like your code to be super efficient you can compute the edge period time once outside your control loop:

secondsPerEdge: float((1/rpm) * 60 * 1/(X*CPR)) = 80e-6

... and use that as the setpoint in your PID to compare to the getPeriod() process variable which returns the edge period in seconds.


When using PID to control shooter wheel speed there are some additional considerations to be aware of in order to be successful. Things like do you want to apply dynamic braking or reverse motor commands when wheel speed exceeds setpoint. I will leave it to shooter-wheel-PID gurus to fill in the details and recommendations.

You may be able to get better speed regulation at 10ms.