Rockwell sensor as a encoder/counter

[Dan Oelke]

Our design for the motors driving the shooter wheels didn't take into account and encoder - and I think we really should have one to get consistent speeds.

So - I was thinking that the Rockwell sensors from 2011 with a white/black disc (1/4 of a disc white / black) would work as an encoder. We are talking 5k RPMs so this would be about 10k pulses / sec.

Does this sound like a reasonable solution to anyone else? Has anyone else tried something like this?

I am having problems finding a good datasheet to see what the response time is for these sensors to see if they can do this high of a count rate.

[Ether]

Originally Posted by Dan Oelke

a white/black disc (1/4 of a disc white / black)

I'm not familiar with those. Does the disk look like this?

If so, how did you come up with 10,000 pulses/sec at 5,000 rpm?

We are talking 5k RPMs so this would be about 10k pulses / sec

[Dan Oelke]

Ugh - must be getting late for me. Yes - I was thinking a disc exactly like that. BUT I didn't carry my units thru as I did the math.

So - 5000RPM * (2 pulses/revolution) * (1 min/60sec) = 167 pulses / sec

[gpetilli]

I believe you are referring to the line sensors from last year - great idea. I dont think you need to add a wheel, just count the spokes of the flywheel as they scream by. If they work, you should make a new post so others could use this "free" technique.

[Dan Oelke]

Yes - the line following sensors from last year.

I thought about counting the spokes but was afraid that might not work consistently depending on if there is back-lighting shining thru or not.

We will be trying it hopefully in the next day or two and report back on how well it does (or doesn't) work.

[loafdog]

We are in the same boat, design of shooter didn't take mounting an encoder into account. Last night we mounted the rockwell sensor so it could see the shooter wheel spinning. The wheel is one of previous years wheels with dark spokes. As I spin the wheel by hand I can see the status leds on the sensor change state. When we run the shooter motor(a CIM) at full speed I can't tell if the sensor can see the spokes. The status led may be changing state but if so it is too fast to see with naked eye. We haven't connected the signal wire to digital sidecar or written any code to count spokes yet. Before we go further I'd like to know if anyone has gotten this working.

And thank you Dan for the great idea to use this sensor to measure rpm of shooter.

[Jared Russell]

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.

[Ether]

Originally Posted by Jared341

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).

Are you allowed to use 24V like last year?

Bottom of Page2 here.

[Jared Russell]

Good call - I hadn't even thought of that. I can't find anything that explicitly disallows it in the rules. In fact I can't find a comprehensive description of what is allowed to be connected to the Solenoid Breakout, period. I think I will pose a question in Q&A just to be sure.

[anthonyttu]

I would be careful to avoid ambient light. The stage lights used to light the field are much brighter a output a different spectrum then the lights in your build areas.
If the sensor is mounted up on the robot and not protected from the light properly it wont work correctly.

[Ether]

Originally Posted by Jared341

I think I will pose a question in Q&A just to be sure.

Make sure you remind them that they allowed it last year specifically to address the issue you are currently facing.

[ebarker]

Originally Posted by Jared341

(a) using the FPGA timer and a "getRate()" function to measure time between pulses

What does the code look like for doing this ?

Is this part of the counter class or something else?

I don't see it in the counter class.

[Jared Russell]

We use the "getPeriod()" method in the Counter class. Something (in Java) like:

public final static double kTicksPerRevolution = 2.0;
private Counter counter;

double getRPM()
{
   return 60.0/(counter.getPeriod()*kTicksPerRevolution);
}

The factor of 60 converts between revolutions per second and RPM.