Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Sensors (http://www.chiefdelphi.com/forums/forumdisplay.php?f=173)
-   -   Finding RPMs with encoder (http://www.chiefdelphi.com/forums/showthread.php?t=143128)

Sparx030 03-02-2016 22:14

Finding RPMs with encoder
 
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 04-02-2016 08:15

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Sparx030 (Post 1534760)
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 04-02-2016 08:54

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by RyanN (Post 1534860)
...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 04-02-2016 09:08

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by RyanN (Post 1534860)
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 04-02-2016 09:39

Re: Finding RPMs with encoder
 

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 04-02-2016 11:17

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Ether (Post 1534897)

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 04-02-2016 12:41

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Sparx030 (Post 1534951)
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.


Quote:

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 04-02-2016 14:07

Re: Finding RPMs with encoder
 
Quote:

Where do you intend to mount the encoder
On the shooter wheel

Quote:

How fast will the encoder be spinning at your shooter operating point?
This may change but let's just say 3000 RPM

Quote:

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

Quote:

What motor and motor controller are you planning to use?
AndyMark RS775-5 with a Victor controller

Quote:

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 04-02-2016 14:36

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Sparx030 (Post 1535036)
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 04-02-2016 14:49

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Ether (Post 1535043)
Not that it matters that much, but Victor SP or 888 ??

They are Victor 888.

Quote:

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 04-02-2016 14:52

Re: Finding RPMs with encoder
 

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



Sparx030 04-02-2016 15:02

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Ether (Post 1535047)

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



20ms

Ether 04-02-2016 16:23

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Sparx030 (Post 1535051)
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.



Sparx030 04-02-2016 17:41

Re: Finding RPMs with encoder
 
alright, thanks for the help. I don't have means for testing anything right now but all of this was very helpful.

Sparx030 06-02-2016 14:55

Re: Finding RPMs with encoder
 
Quote:

Originally Posted by Sparx030 (Post 1535150)
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.


All times are GMT -5. The time now is 08:09.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi