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.
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. 
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.
*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?
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.
[strike]What make and model encoder are you planning to use?[/strike]
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)?
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?
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).
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.
*What is the period of your control loop (e.g. 20ms, 10ms, etc)?
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.
alright, thanks for the help. I don’t have means for testing anything right now but all of this was very helpful.
Update: everything is working perfectly, thanks again for the help.
Not to be too pedantic, but what do you mean by “working perfectly”?
Could I talk you into posting a trace of your wheel speed vs time?
Others can maybe learn from it.
Thanks.
I managed to get the encoder to show me values in RPM as well as allow inputs to be in RPMs, my big issue was not getting values I wanted as well as not knowing what stood for what in the code. so my result was this…
RPM = 5000.0;
eShooter = new Encoder(1, 2, true, EncodingType.k1X);
eShooter.setDistancePerPulse(3);
eShooter.setPIDSourceType(PIDSourceType.kRate);
pidShooter = new PIDController(0, 0, 0, eShooter, mShooter);
pidShooter.setSetpoint(((RPM/60)*360)/3);
SmartDashboard.putNumber("Motor RPM ", ((eShooter.getRate()*3)/360)*60);
So to explain things best I can (because this is the actual code for this and most of what I wrote from this thread is on a piece of paper that would be less easy for me to explain) this allows you to put a desired RPM to set the wheel to that speed as well as tell you on the computer (SmartDashboard) what RPM it is moving at.
RPM = 5000.0;
eShooter = new Encoder(1, 2, true, EncodingType.k1X);
eShooter.setDistancePerPulse(3);
eShooter.setPIDSourceType(PIDSourceType.kRate);
pidShooter = new PIDController(0, 0, 0, eShooter, mShooter);
This has ‘RPM = 5000;’, what RPM you want the wheel to move at. ‘eShooter = new’ is creating the Encoder in the code with 1x decoding (EncodingType.k1X). ‘setDistancePerPulse(3);’ is the distance in degrees the wheel will move per pulse which with 1x decoding and a 120cpr encoder will be 1 pulse (or count) per 3 degrees. setPIDSourceType is to make the encoder read the rate as opposed to distance. ‘pidShooter = new’ creates a speed controller with P, I, and D variables and the encoder and the motor it is powering (this also has no values for P, I, or D these would have something in place to properly tune it).
That might have been lengthy and possibly unimportant for those who might look to this for learning about the RPM calculations but the ‘setDistancePerPulse’ was a big trouble of mine when trying to find what to put in there and is important to the code. 3 would not be the distance per pulse if this was not 1x decoding.
pidShooter.setSetpoint(((RPM/60)*360)/3);
SmartDashboard.putNumber("Motor RPM ", ((eShooter.getRate()*3)/360)*60);
setSetpoint wants an input in counts per second. To turn counts into pulses (with 1x decoding) will need you to turn desired RPM into RPS (into second) with ‘RPM/60’(RPM divided by 60) then turn it from revolutions to degrees ‘*360’(multiply by 360) and finally degrees per second to counts per second ‘/3’(divide by 3).
now for what the encoder tells you. getRate() in also in counts per second so it’s the exact opposite. the rate in counts per second multiplied by 3 to turn it into degrees, then divide by 360 to turn it into RPS(revolutions per second), and finally multiply by 60 to get RPMs.
This might have been a bad explanation or included too much rambling and not enough detail, especially with be just putting in the exact code, if that is the case I’m sorry I’m not much of a teacher, so if you want me to include more specific details let me know and I will say what I did, how I did it, and what value everything (related to this thread) intakes and outtakes.