We are planning on using an encoder on our shooter design to determine actual RPMs. Do I need to worry about interrupt load on the processor if I have the combination of a fast (~5000RPM) shaft and a high resolution encoder. I was thinking of trying to get a reduction gear in there to reduce the RPM and then go with a low res (32 ticks/rev) encoder.
Are the considerations the same if I connect the encoder to the Talon SRX instead of the Rio??
I believe that the FPGA hardware takes care of processing the encoder pulses which minimizes the need for interrupt processing on the main processor.
I don’t remember what the limit on the number of pulses the FPGA can handle is but it’s in the tens and maybe even hundreds of thousand pulses per second. Try it for yourselves.
The roboRIO FPGA can track encoder edges at 25 ns from edge to edge. It will also calculate and report rates at the same resolution. I suspect this is more capability than any team needs, but I’m always interested to hear about teams pushing the boundaries.
There was a very lengthy discussion about jitter, sampling, and RPM calculation in 2012. To make a long discussion short, if you are using the period function in LabVIEW, you may actually be better off with a 1 count per rotation encoder to maximize the period and make your RPM calculation more accurate. We used it very successfully in 2012, and 2013. This will also eliminate any worries you may have about loading the roborio.
This is somewhat counter-intuitive if you are thinking about calculating RPM using “number of ticks” divided by time.
Joe, do you know exactly what the pulses per second rating for encoders/counters in the FPGA is? I remember that the cRIO was right around 40,000, and I remember hearing that the RoboRIO was in the realm of 100,000, but I would like to know for sure. It would also be nice to have this documented somewhere if possible.
EDIT: Nevermind. I didn’t see the 25ns number above. Does that mean that that the RoboRIO can take 40,000,000 edge to edge pulses per second, or am I screwing my math up somewhere. That number just seems incredibly high, but I could see it being that high.
If you look at “roboRIO Specifications” linked from here, in the Digital I/O section on page 4, it references “minimum pulse width”. That’s the hardware limit. The FPGA implementation uses a 40 MHz clock as the timebase to run the decoder logic and the I/O logic. That means the FPGA is the limiting factor by a small margin. There are complications (discussed earlier) with respect to the sampling and ensuring no two edges are detected in the same sample period. To ensure that is avoided, divide the rate by 2. That means 20,000,000 edges per second should be guaranteed to decode. That edge rate would mean 5,000,000 rising edges on the A encoder output per second (assuming very small phase error in your encoder both A to B and rising to falling).
It is incredibly high… by comparison to the previous system anyway.
Hello My team is trying to use the VersaPlanetary Integrated Encoder to reach about 12000 rpm. The documentation on vex pro says 15000 rpm max but looking at the talon SRX software documentation says 10000 rpm max and we seem to be maxing out the rpm.