[Ken Streeter]

Originally Posted by Bruno#1382

ok,but the encoder don't work well because when he works in high rotation he skip a lot os pulses

I keep hearing reports like this and always wonder whether or not I should try to stop the misinformation. Usually Ether jumps in to do so, but this time I figured I'd have a go...

The USDigital Sensors that have come in the Kit of Parts in recent years and the FPGA in the cRIO are fully capable of keeping up with very high rate encoders or counters.

The limiting factor for the maximum rate will be the lesser of the limits for the encoder and the cRIO.

First, the USDigital encoder:

There are two separate constraints for the USDigital encoder: (1) The mechanical limit for the USDigital E4P encoder is 60,000RPM. (2) The maximum count frequency is 60kHz. Accordingly, the maximum RPM due to the maximum 60kHz count frequency is 3,600,000/CPR. For the 250 count disks that were provided in the kit in recent years, this means the maximum RPM is 14,400 RPM. Even a 360 count disk will allow 10,000 RPM.

Next, the cRIO:

The cRIO is fully able to measure such high rate encoders with the use of the FPGA counter. The input sample period is 6.5usec, which is 153 kHz, giving a permissible encoder rate of up to 38.4k counts per second. For a 250-count disk, this is about 9200rpm.

OK, so rates of up to 9200rpm should be possible. But, what about practical experience?

For 1519's shooter wheels last year (Rebound Rumble 2012), we used a 250-count optical disk in the USDigital E7P encoder and had no problems with this setup being driven at over 4000rpm and measured by the cRIO using an encoder object with 1x sampling in Java.

One caveat that may lead to misinformation that teams were having problems with encoders at high RPMs is that the getRate() function will have excessive jitter at high RPMs, but this isn't due to missing counts. Instead, this jitter is due to the way the getRate() function works in WPILib. getRate() determines the rate by measuring the period of a single pulse (with 6.5usec resolution) and then taking the reciprocal to determine a rate. This isn't accurate at very high pulse frequencies, due to the discretization of the measurement of the period of a pulse. Instead, what can be done is to periodically sample the number of counts, determine how many counts have occurred since the prior sample, and then divide by the time since the prior sample, to determine a rate in counts per second.

Converting counts per second to RPM is achieved by multiplying by 60 seconds / 1 minute and dividing by 250 counts per 1 rotation (for a 250 CPR disk). We did this last year and received very stable RPM information for controlling our shooter wheel speeds via a PID control loop.