Encoder getRate question

[AsianRookie]

Originally Posted by F22Rapture

Nope. DistancePerPulse is the distance in units that your robot travels, per pulse. So what you need to do is take the circumference of your wheels and divide that by the resolution of your encoder (usually 360 or 250) to give you the distance that your robot will travel forward for every "pulse" of the encoder.

So if you're using 6" wheels, that would give you a circumference of ~18.85 inches. For every turn of your robot's wheels, your robot will travel roughly that distance. So you take the number of pulses per revolution of the encoder, and divide 18.849556 by that number, to give you the distance per pulse of the encoder.

I don't think gear ratio factors into it, since I'm 99% sure the encoder shaft is linked to the output shaft rather than the input gears. This can be fairly trivially tested though I suppose. Or just look up the gearbox manual.

Well, the encoder is on a different shaft than the motor because we didnt have a way to mount it directly to the motor shaft. Thanks for the clearing though.

Originally Posted by Ether

You do not want to use getRate() with a 360 CPR encoder with 4X decoding at shooter wheel speeds.

Do this instead:

1) Connect only Channel A of the encoder to the DSC, and use an up/down counter (from the Counter class) set to count up only. Leave Channel B disconnected.

2) Set the FPGA sampling ring buffer size to 120.

3) Use the counter class's getPeriod() to get the period, then calculate rpm = 60/(360*period)

Thanks for the tip, I will try that when I get in my school on Monday.

[Ether]

Originally Posted by AsianRookie

Well, the encoder is on a different shaft than the motor because we didnt have a way to mount it directly to the motor shaft.

So what speed is your encoder spinning at? And is this for a shooter wheel (as the code seems to imply) or a drivetrain wheel?

[AsianRookie]

I did not receive the gear ratio from the person who was in charge of the shooter, but it is a higher teeth count on the motor and a lower teeth count for the wheel. And yes, this is for the shooter. Also the encoder wheel has 250 ticks.

[JefferMC]

On encoders for shooting wheels, you may wish to watch out for the maximum RPM the encoder can handle. There are both electrical and physical issues there.

You can also approach the granularity of the VxWorks timer, which I believe has a resolution of 6 us. Since GetRate() gives you the inverse of the time between the last two ticks, with a resolution of about 6 us, this caused us some issues with oscillation between two substantially different returned values for RPS. Using the FPGA with the ring buffer may help with this, but we opted for the x1 resolution.

[Ether]

Originally Posted by JefferMC

On encoders for shooting wheels, you may wish to watch out for the maximum RPM the encoder can handle. There are both electrical and physical issues there.

For US Digital E4P encoders, the limit is 60,000 rpm or 3,600,000/CPR, whichever is less.

You can also approach the granularity of the VxWorks timer, which I believe has a resolution of 6 us.

The FPGA handles encoders. Vxworks is not involved.

Since GetRate() gives you the inverse of the time between the last two ticks, with a resolution of about 6 us, this caused us some issues with oscillation between two substantially different returned values for RPS.

For a high-speed one-direction application like a shooter wheel, do not use getRate(). Use getPeriod() from the Counter class. Make sure you physically connect only Channel A. Leave Channel B disconnected. Create an up/down counter counting rising edges only.

See the attached example calculation of a 250 CPR encoder set up this way and spinning at 5000 rpm, showing the effect of the 6us polling period of the FPGA when the ring buffer is set to 125 samples (1/2 of a revolution).

Using the FPGA with the ring buffer may help with this, but we opted for the x1 resolution.

1X decoding of an encoder still requires detecting the rising edges of both channels, which limits your speed.

[JefferMC]

Originally Posted by Ether

For US Digital E4P encoders, the limit is 60,000 rpm or 3,600,000/CPR, whichever is less.

Due to an inventory issue, we were forced to use a 360 CPR encoder to attempt to measure our shooting wheel. We exceeded the CPR limit. Frustrating to watch the RPM graph drop to zero as the wheel accelerates. Other solutions were found.

The FPGA handles encoders. Vxworks is not involved.

According the the documentation, the FPGA is only used when the counter type is set to k4x, not for k2x and/or k1x. From what I can see from perusing the code, this is correct.

For a high-speed one-direction application like a shooter wheel, do not use getRate(). Use getPeriod() from the Counter class. Make sure you physically connect only Channel A. Leave Channel B disconnected. Create an up/down counter counting rising edges only.

getRate() is a derivative of getPeriod(). getPeriod suffers from the same problem, i.e. the period of time between two "clicks" is approaching the resolution of the clock by which those clicks are measured.

The reason we had quad-encoding on this encoder was that at one point we were going to reload discs back through the barrel of the gun, causing us to run the motors backwards and wanting to be sure we knew they were running backwards.

Also, I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.

See the attached example calculation of a 250 CPR encoder set up this way and spinning at 5000 rpm, showing the effect of the 6us polling period of the FPGA when the ring buffer is set to 125 samples (1/2 of a revolution).

1X decoding of an encoder still requires detecting the rising edges of both channels, which limits your speed.

I never found that the handling the second channel caused an appreciable issue for the cRIO. However, the point is well taken that it is extra interrupts and unneeded effort.

[joelg236]

Originally Posted by JefferMC

Also, I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.

The PIDController class only needs a PIDSource and PIDOutput. Counter does not implement PIDSource, but you could always extend it and implement PIDSource.

[Ether]

Originally Posted by JefferMC

According the the documentation, the FPGA is only used when the counter type is set to k4x, not for k2x and/or k1x.

What documentation are you referring to?

I seem to recall that the PID classes wanted an Encoder and would not accept a Counter. I may be wrong about that.

Many teams are successfully using home-brew one-count-per-rev counters on their one-directional shooter wheels. Also, PID is not the only game in town.

I never found that the handling the second channel caused an appreciable issue for the cRIO.

Perhaps you did but didn't realize it:

Originally Posted by JefferMC

we were forced to use a 360 CPR encoder to attempt to measure our shooting wheel. We exceeded the CPR limit.

However, the point is well taken that it is extra interrupts and unneeded effort.

There are no interrupts involved. The FPGA polls the DIO at ~153KHz

[AsianRookie]

A made a modified Counter class, to be used with PIDController and has 120 samples to average. It works wonderful. Thank you Ether.

[Ether]

Originally Posted by AsianRookie

A made a modified Counter class, to be used with PIDController and has 120 samples to average. It works wonderful. Thank you Ether.

And thank you for the follow-up post.

Would you be willing to post your modified Counter class? It would be a service to the FRC community. There are other teams/individuals who need some help figuring out how to do this.

[otherguy]

In case anyone else was looking for a source code example...

Looks like Joe Ross posted a patch to the Encoder and Counter classes for Java.
http://firstforge.wpi.edu/sf/go/artf...v=1&_pagenum=1