hi CD!
we are thinking about the idea of a flywheel for our robot, spinning at about 2000-3000 RPM (not entirely sure about this number) and we want to see how fast he is spinning, and we tried to use this encoder:
this encoder couldn’t measure the speed of the wheel fast enough…
how can we measure the speed of our wheel to know how fast he is spinning?
thanks guys 
That’s an absolute position encoder:
Product Overview:
This kit contains one encoder and one encoder cable. The MA3 is a miniature rotary absolute shaft encoder that reports the shaft position
Select an encoder that’s designed to measure speed.
Also, it has a sleeve bushing and the rated max speed is 100 rpm.
The datasheet is available via a link at the AndyMark page you posted. Download it and take a look. You may not understand all of it, but take a look anyway. It’s a great way to start learning.
*
The best solution is an encoder meant to handle higher speeds, such as the Grayhill 63R series. It can handle up to 5000 RPM and we have found them to be reliable.
There are different resolutions available, so be aware which part number you are buying. Lower resolutions such as 63R32 and 63R64 will work for high speed flywheels such as yours. The high resolution 63R256 is better suited to drivetrain and other places where speeds are lower but you want more precise measurement at those lower speeds.
For checking the RPM of parts you have not put an encoder on, a laser tachometer is a very useful tool to have.
Try the MACH Engineering Touchless Encoder: https://www.chiefdelphi.com/forums/showthread.php?t=153808
It was specifically designed for applications like this. You don’t need extremely high resolution, there are no bearings to worry about, and mounting is a breeze!
I can also recommend the CTRE magnetic encoder:
http://www.ctr-electronics.com/sensors/srx-magnetic-encoder.html
As well as the CUI AMP 10 series of encoders:
http://www.cui.com/catalog/components/encoders/incremental/modular
We have successfully speed-controlled high speed wheels with both of these encoders directly connected to a Talon SRX.
Both encoders are available from AndyMark.
We use the CUI AMT-103 encoders, they are super nice because they are robust and have an adjustable resolution.
I’ll 2nd the CUI AMT102 or 103. We have used them for the last 3 years and they have been rock solid. We got the AMT102 on the shooter Sunday hooked into a Talon SRX at 512 resolution. Testing done at 4100 to 4300 rpm. Using FPID looks very good but the graphs show that we need a fly wheel. CRE has done a good job. Proud of the programmers. They studied the CRE manual and got it up and running in a couple hours. This is not easy but with CUI and CRE we are getting there.
A more basic approach might be to use a reflective object sensor, such as a QRD1114 (or OPB706A, or any of a wide range of IR reflective sensors) and a bit of reflective tape on your wheel. If your wheel is already reflective, then use non-reflective tape… anything so you have part of the wheel reflective (shiny, white) and part of it non-reflective (dull, black). The non-reflective part could also consist of a hole in the wheel… anything that doesn’t reflect IR light back into the sensor. You have to add a couple resistors to the QRD1114, but you’ll find plenty of tutorials on how to do it.
This way you’ll get one pulse per revolution… just use the RoboRio to time the interval between pulses and you’re set. You can achieve the same thing by looking at the shaft… paint half of the shaft flat black, and leave the other half shiny.
Do note that the effective range of the QRD1114 is about 1mm. And that it has 1114 in it’s name. If it’s 1114, that means it’s got to be good, right?
Jason
Just highlighting this for emphasis. For a one-per-rev sensor, do not count pulses and divide by time.
Just for future thread browsers, if that is the wrong way to do it, is this the correct way to count a one rev sensor as you suggest (obviously with some of the values changed)? It is similar to how we currently do it, and it seems to work well for high speeds. (Team476 example):
[strike]I do not have a LabVIEW installation, so you’ll need to answer some questions before I can answer yours.
Please post a screenshot of LabVIEW’s help file for CounterGet.[/strike]
I just checked Team 358’s excellent LabVIEW examples web pages, and it looks like CounterGet returns the period (seconds/count). So yes, that appears to be using the FPGA to measure the elapsed time between counts.
It is similar to how we currently do it, and it seems to work well for high speeds.
How exactly do you do it? And are you using a one-per-rev counter? And how high is “high speed”.
That’s actually an old 358 example from 2010.
You don’t need the Counter Start anymore.
Here’s the Counter Get Help.
The period is the average of 5 samples in this example.
Thanks Mark. Where does it say 5 samples in that snippet? And how would you change that so it returns just the most recent period (which would be appropriate for a one-per-rev sensor)?
*I added the link in Mark’s original quote above.
*
*
The “5” feeding into the Counter Config Timer is the number of samples to average over, so just make that “1”.
In the original use of that example the 5 was meant to represent if you stuck 5 pieces of reflective tape onto your spinning wheel, so 5 samples represented a full revolution.
The example then drifted a bit over the years.
I hadn’t realized that the 5 for averaging correlated to how many ticks there were per RPM, thought it was just a sort of buffer. The setting used for 1 ‘tick’ is the “CountsPerRev” division after each counter get period (see attachment). We are running a shooter wheel off of a CIM motor between 3800 RPM and 5000 depending on our setpoints (still tweaking what works best). At full throttle, it reads around 5000, which matches up with what I would expect from a CIM motor.
It is currently a photoeye looking at 50% reflective tape, and 50% not, contiguously around the wheel. We are considering getting better resolution by breaking it up into 4 or 8 equally dispersed chunks, in which case “CountsPerRev” would be increased to this number when we read “Period(sec)” from the CounterGet VI.
The other cases shown are just overrides in case of shooter sensor failure to simply pipe a percentage value to the motor (detects a small setpoint, which means a throttle value is desired instead of RPM).
3800 rpm = 63.33 revs/sec = 15.8 ms/ rev.
If you are running your speed control loop at 20ms, you’ll get a fresh reading every iteration.
And, there’s an advantage of using only one piece of tape: there is no noise due to tape positioning tolerance since you are always reading the same edge.
If your CIM is geared 1:1 to the flywheel, you will not not able to control the flywheel speed at 5000 rpm. There is no voltage headroom for your control algorithm to work.
I use the *Number of Samples to Average *to account for placement error of the reflective strips. One full average always equals the same start/stop rising edge.
of strips (thought about it some more)
By the way, in the last code example the *In Range and Coerce *function has it’s upper limit disabled (by default).
That’s why it’s a clear box, rather than a filled box like the lower limit has.
Right-click on the function and choose Include upper limit
Good advice, we were not planning on running at 5000, closer to 4000 at realistic max. We have had around 30%-40% headroom roughly. I was just testing how fast it would go. It does seem to work with 1 tape segment, I just overheard someone in another thread suggesting more resolution for a similar application.
The averaging of samples to number of ticks in one revolution makes sense now, thanks! Of course, with 1 tick, having a few averages shouldn’t hurt, but really shouldn’t be necessary now that I think about it.
Now just to properly tune the PID so that it gets to the correct speed quickly without oscillation (hint to anyone with this problem, an additional offset added to the output can help get up to the proper speed range without cranking P too hard into oscillation territory) That’s tomorrow’s project.
Thanks for the advice.