|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#7
|
|||||
|
|||||
|
Re: Rockwell sensor as a encoder/counter
We are using the Allen Bradley sensor that was used for line tracking in 2011. We put two small pieces of retroreflective tape on our shooter wheel, and use the sensor as a Counter (in Java). We spin the wheel at ~5500RPM, which gives us about 180 pulses per second (~90 revs per second * 2 rising edges per rev). We use the "getRate()" function (which measures the time between consecutive edges) to get our speed value. We are *very* satisfied with the fidelity we are seeing. The only downfall of this method so far is that when we have a low battery and are running a lot of motors, we can brownout the sensor (since its voltage is unregulated). I think in a 2 minute match with a properly charged battery this won't be an issue, however.
The key is to find a "sweet spot" between instantaneous speed readings and getting something that is smooth. There are two ways to do this: (a) using the FPGA timer and a "getRate()" function to measure time between pulses, (b) counting the pulses and dividing by a unit time. Both ways can work. If you go with method (a) like we are, it is crucial that you LIMIT the number of pulses per second. We run a 200Hz control loop on our shooter; we don't need 20,000 speed measurements per second! We will settle for ~200 *GOOD* speed readings. If the rate is too high, you will see more noise (a nonsmooth output) because the rise/fall time of the sensor and timer inaccuracies will have a bigger effect. By triggering your timer less often but over greater periods of time, you are basically applying a low pass averaging filter to your speed measurement. Method (b) also works. In this case, you have the opposite problem - get as many counts as you can! If you only have 2 pulses per revolution on a 90 RPS wheel, and you calculate the speed 200 times per second, you will always see a speed of either "0", "1", or "2" ticks per time interval. This is horrible resolution. If you have 250 counts per revolution and sample at 200 Hz with the same 90RPS wheel, you will see answers that fall into the 112/113 ticks per unit time range. That's a lot more "bins" for finer measurement and control. We went with method (a) for the following reasons: 1. Easier (for us) than mounting an encoder to a very high speed transmission with no COTS encoder mounts. 2. Theoretically our speed measurement accuracy is limited by the timer, which is likely to be much better than the resolution you can obtain by sampling and dividing by unit time. 3. The FPGA has a limit on the number of counts per second it can handle. I believe it is in the range of 39,000. We don't want to test that limit. 4. We already have a ton of 2011 sensors, and encoders that can spin at >5k rpm often require ball bearings and can be expensive. Last edited by Jared Russell : 16-02-2012 at 11:42. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|