Measuring motor speed

[fovea1959]

I'm struggling with a good way to measure motor speed for our shooter motors (probably Banebots, probably 10-20k rpm). I'll have a back shaft available for mounting.

Any one have any advice for something off the shelf? my priorities are available, reliable, simple to interface, easy to mount, and cheap, in that order. I'm trying to stay away from have to do any electronics design (I'd end up doing it myself, I suspect, which is not the point of this exercise!), want to use off the shelf if possible. Alternatively, something that we can put together on perfboard would be good.

If we're on our own, we're thinking either Hall Effect, or else opto (fairchild QRD1113/1114 with a black/white "plug" on the backshaft), but if someone has something simple that they know works, I'm all ears....

[iambujo]

Hello - Last year with my students and I designed a PCB for a US1881 Hall Latch. It has done very well for us. To use it, we just mount some good magnets in a hub, 180 degrees out of phase and at opposing poles. Each pole swap during rotation swaps the latch, creating a square wave on the digital signal. We have tested it up to about 5000 RPM on our shooter last year and this year. I am not sure how high it can go before missing latches, our goal was <= 5000 RPM, but the US1881 data sheet probably tells you. You need to make sure those magnets in the hub are secured well, you don't want them flying out!

For the magnets we have had great luck using the larger of the 2 magnets that spark fun sells. The smaller works too, but the larger one allows the sensor to be between a 1/4 and a 1/2 inch away from the magnets/spinning hub.

We actually just shipped 3 units to another FRC team and sold a few last year. If you are interested, private message me and we can hook you up with some for $20 a piece for an assembled sensor, you supply the magnets (we did a short run on the boards so they weren't cheap).

Here is the thread from last year:
http://www.chiefdelphi.com/forums/showthread.php?p=1114292#post1114292

[Ether]

I'm struggling with a good way to measure motor speed for our shooter motors (probably Banebots, probably 10-20k rpm).

At those high speeds, you can get good results with a one-pulse-per-rev device by putting one mark or one piece of reflective tape on your wheel and detecting it with an optical sensor.

Then use the GetPeriod() method in the Counter class to get the elapsed seconds between pulses, and convert that to RPM:

RPM = 60/period

[fovea1959]

software I can handle: need a recommendation for a easy to interface opto this is fast enough.

[Hugh Meyer]

The encoders that come in the kit of parts are very good for this. Run the wires to the cRIO or to a Jaguar. Both devices will give you speed. We mount directly to the CIM motors and they have no trouble keeping up with 5K rpm. It should go on up to 20K rpm without any trouble. If you are concerned about that you could get the lowest line count encoder. They are simple to install, cheap, reliable, and directly interface to two systems we use.

-Hugh

[fovea1959]

Hugh, thanks.

We may fall back to the USDigital, but we're trying to see if there are viable alternatives in the single pulse per rev range. Our experiments so far is that the US Digital are noisy and unreliable at these speeds (had a student plotting speed at constant power, flat with spikes of varying size above and below the line). Needed a fair amount of filtration to get something that looked decent.

If I can find something cheaper, less noisy, more robust, and sends sends fewer pulses to the poor cRIO, I want to explorer it. A 10000 rpm shaft on a 250 pulse /rev encoder is over 40000 pulses/s; depending on what numbers you believe, that's close to what the FPGA can handle.

[Hugh Meyer]

fovea1959,

Using the 100 line encoder with one channel rather than quad mode will reduce the pulses per second considerably.

If you are seeing noise you might want to check your mechanical arrangement. The signals we see are rock solid when all is properly aligned and constrained.

If you have something spinning that you could drill a hole in you could use a LED and photo transistor to sense the hole. A slot sensor is another option (HOA1405)

If you could mount a black and white sticker on the spinning shaft then a reflective sensor (OPB625) would work great.

Either of these devices can connect directly to the cRIO with only a few resistors.

Good luck. Please be sure to post your final solution. It is always interesting to see how others solve problems like this.

-Hugh

[fovea1959]

Hugh: thanks for the suggestions. Probably a mechanical alignment problem. Didn't think to just run one channel and use the encoder as a counter (though I had the encoder set up in SW as 1x), will detail student to run experiment tonight. Don't have a 100 count new encoder wheel around; not even sure if they make one small enough to go on the backshaft of a BaneBots...

is OPB625 reflective? looks transmissive to me. Was considering Optek 720s...

I'm seeing if we can find the parts to do a homebuilt Hall Effect on perf board tonight; just want to cobble something together so that programmers can get their feedback loop working, then take the time to determine what's reliable and swap it out closer to bag day. Will post what we do for interim, and what we end up with.

Programming is easy. Sensors are hard :)

[Ether]

A 10000 rpm shaft on a 250 pulse /rev encoder is over 40000 pulses/s; depending on what numbers you believe, that's close to what the FPGA can handle.

AIUI, the 250 CPR encoder has 500 edge transitions (rising+falling) per channel per rev. At 10,000 RPM, that would be 10,000/60*500 = 83,333 edges/sec which is acceptable because the FPGA polls each channel for edges at 153KHz.

If you do decide to use a 250 CPR encoder at 10,000 RPM to measure shooter wheel speed, you don't need both channels since you'll always be going in the same direction.

You can use the Counter class with only one channel of the encoder.

If you use the GetPeriod() method of the Counter class, you will get up to roughly 2770 RPM peak-to-peak jitter due to the 153KHz FPGA polling rate if you don't use the FPGA's built-in averaging capability.

In C++ or Java WPILib, you can make a small modification to counter.cpp (or counter.java) to tell the FPGA to return the elapsed time between the most recent N+1 rising edges (N<127), and WPILib will divide that by N, effectively averaging. If you set N to 125 for example, you'll be averaging over half a revolution and should get a nice clean signal with jitter roughly 22 RPM p-p.

Note that the 250 CPR E4P has a max speed of 14,400 RPM due to its 60kHz maximum count frequency (per page 3 of the datasheet).

[pfreivald]

We tried using this optical sensor (http://www.andymark.com/FIRST-Choice-p/fc13-057.htm) yesterday with a half-black, half-white wheel, and found that it didn't seem to refresh fast enough at frisbee-shooting speeds. (This is what was reported to me -- I wasn't there).

Does this seem like a legitimate problem for this sensor? And how would I go about determining whether or not any given sensor is suitable for these kinds of rates?

Thanks!

[Mark McLeod]

The responses time for that photo sensor is .5ms to 1ms depending on model, so calculate how fast your wheel changes states.
and make sure to power them off the solenoid bumper running fromn the protected 24v source, otherwise normal robot power dips will make them inoperable or flakey at best.

[Ether]

We tried using this optical sensor (http://www.andymark.com/FIRST-Choice-p/fc13-057.htm) yesterday with a half-black, half-white wheel, and found that it didn't seem to refresh fast enough at frisbee-shooting speeds. (This is what was reported to me -- I wasn't there).

Does this seem like a legitimate problem for this sensor? And how would I go about determining whether or not any given sensor is suitable for these kinds of rates?

This should work fine if you decode the signal the right way.

There are two different methods commonly used in FRC for decoding sensor pulses into RPM. Each has advantages and disadvantages.


Method1

Divide the pulse count by the elapsed time and convert to RPM


Method2

Measure the elapsed time between pulse counts and convert to RPM.


If you are using a low pulse-per-rev sensor (like you described above), you should used Method2. If you use Method1 you'll get a very noisy signal (lots of jitter).

For example, let's say your wheel speed is 5000 RPM and you are using Method1, and you are reading speed samples at 20ms (TeleOp speed).

At 20ms (50Hz), you'll sometimes get 2 pulse counts and sometimes only 1. So sometimes you'll read 6000 RPM and sometimes you'll read 3000 RPM, when your true speed is actually 5000 RPM. That's a lot of noise.

But if you use Method2 you can get a good signal. Use the GetPeriod() method of the Counter class. This will return the elapsed time between the most recent 2 pulses. This will give you a jitter of roughly 3 RPM. Much better.

[pfreivald]

Excellent, thanks!

[Alchemy99]

Why not just gear the encoder down... the shooter is spinning at 20k, gear it so the encoder is spinning at 5k. 4:1 ratio.

[protoserge]

Here's a relevant thread that discusses the Hall Effect solution.

http://www.chiefdelphi.com/forums/showthread.php?t=111375 (the big quote in post 2, picture in post #5)

[pmangels17]

I recommend gearing down the RPM as much as possible. You can use plastic gears for this if you have a weight concern, since they are virtually weightless. You could even use plastic sprockets and plastic 25 chain, if you don't want to worry as much about alignment.

[Teamcodeorange]

We tried using this optical sensor (http://www.andymark.com/FIRST-Choice-p/fc13-057.htm) yesterday with a half-black, half-white wheel, and found that it didn't seem to refresh fast enough at frisbee-shooting speeds. (This is what was reported to me -- I wasn't there).

Does this seem like a legitimate problem for this sensor? And how would I go about determining whether or not any given sensor is suitable for these kinds of rates?

Thanks!

We used one of these with a piece of retro-reflective tape and it worked beautifully at the free-speed of a CIM.

[fovea1959]

Working with Richard Wallace: put a plastic nut on the back shaft to use as a spacer, then superglued a K&J Magnetics diametrically magnetized ring magnetic (R424DIA, $0.61). He salvaged an Allego A3291 Hall Effect Latch from a washing machine motor. added a couple of filter caps and a pull up, and we put it on a scope. Beautiful square wave. Student wired up a harness to connect it to the side car, added the code to LABview to set up a counter, read width of last period, take the reciprocal, and plot the resultant revolutions/s. Rock steady with up to a full speed Banebots, about 310 rps (18600 rpm), and it work with about 1.5 or 2 cm from the face of the Hall Effect sensor to the edge of the ring magnet.

I imagine for the Hall Effect what we did was very similar to Team 2729's boards. The ring magnet just glued to the backshaft was pretty slick; K&J has a pretty neat selection.

Can't find the Allegro chip in a non-surface mount package, so ordered some UA1881 and UA5881 chips using our Digikey voucher, and we'll just use vectorboard to fab a couple up for the bot. Those chips are about a buck. We're gonna try a team 2729 board also.

So: I could use an encoder for this, but it looks like about $3 in parts and some sweat equity, we have get lots and lots of RPMs....

Will try to get a white paper detailing some comparisons between the various chips and doing this optically, but probably not until after bag day. Post here or PM if you want more information before then.

[pfreivald]

We used one of these with a piece of retro-reflective tape and it worked beautifully at the free-speed of a CIM.

They got it counting yesterday, now just need to figure out how to report rates. Thanks for the help, folks!

[fovea1959]

Freivald: one of our students licked it in LV with Hall Effect, should be same with opto. Set up a Counter, read the period from the Counter vi, take the reciprocal, and he had RPS.

[Ether]

They got it counting yesterday, now just need to figure out how to report rates. Thanks for the help, folks!

Use the GetPeriod() method in the Counter class. This will give you the elapsed time (in seconds) between the two most recent pulses*. Take that elapsed time (call it T) and use it in the following formula:

RPM = 60/(T*CPR),

... where CPR is the number of counts per rev (in your case, CPR=1).


*assuming you are not running in semi-period mode
and you haven't modified the FPGA sample averaging from its default value of 1

[Ether]

I recommend gearing down the RPM as much as possible.

Why not just gear the encoder down... the shooter is spinning at 20k, gear it so the encoder is spinning at 5k. 4:1 ratio.

Not recommended. Has the potential to introduce a lot of noise, which could make speed control more difficult.

If your speeds are so high that an encoder will exceed its mechanical or electrical limits, or will exceed the FPGA's maximum pulse detection rate, then consider a one-pulse-per-rev solution.

[Ether]

Post here or PM if you want more information before then.

Nice work. Thanks for posting this. Some questions:

1) I'm not familiar with that sensor and magnet. How many counts per rev are you getting with that setup?

2) What size did you have set for the FPGA's sample averaging1?

3) What are you going to use for your speed control algorithm, and at what rate will you run it?


1The default in C++ & Java is 1; I don't know about LabVIEW

[iambujo]

Working with Richard Wallace: put a plastic nut on the back shaft to use as a spacer, then superglued a K&J Magnetics diametrically magnetized ring magnetic (R424DIA, $0.61). ....

Very Cool, I haven't seen one of those magnets before. I am going to look into trying these with our Hall Effect board, thanks for the info! Great work sharing your results too!

[fovea1959]

Ether: we get one count per rev with that magnet. I believe the student had the averaging set to 1, and period length set to 1s (need to double check the Counter class myself, see if we can get something shorter). I am anticipating doing bang-bang, and frankly, I don't know how fast we'll run it. One of the students put together a test program just for the shooter; when we implement speed control, we'll leave the provision to vary parameters in real-time and run some experiments. I am really hoping to do this Saturday, depends on whether or not our Hall-Effect goodies show up. I'm going to get someone coding tonight so we are ready for Saturday.

iambujo: be interesting to see if you get comparable results with your boards. What sensor did you use?

[Ether]

Ether: we get one count per rev with that magnet. I believe the student had the averaging set to 1

The 6.525 us quantization of the FPGA timing of the period should give you about 38 RPM peak-to-peak jitter at 18,600 RPM with sample size set to 1. That's about 0.2% p-p. Pretty darn good.

I am anticipating doing bang-bang, and frankly, I don't know how fast we'll run it.

Nice thing about bang-bang is it doesn't care much if your control period has jitter. Since the bang-bang code is so minimal, you can run it fast without chewing up much CPU.

[iambujo]

iambujo: be interesting to see if you get comparable results with your boards. What sensor did you use?

Our board uses the US1881 Hall Latch. I hope to get it tested at higher speeds this weekend, with the ring magnets.

[pfreivald]

Another issue, if you'd indulge...

We have a variable representing our rate, that we want to plug into the PID constructor(?), but we don't know how to change the variable into a PIDSource.

The documentation we were able to find said that you should be able to make any sensor a PIDSource, but we can't find *how*. Here's a screen shot of the code and the errors.

Any help would be most appreciated!

[iambujo]

FYI - I just tested our Hall Latch sensor with a ring magnet on a Fisher Price 00801-0673 motor shaft. I got the motor up to max free speed (12V from a bench supply), and the sensor read 20220 RPMs, 337 Hz on my logic analyzer. The duty cycle was about 45% regardless of the motor speed so I figure that's based on the ring magnet's pole alignment. I feel the US1881 is an excellent device for measuring wheel/shooter/shaft speeds at pretty much any speed we could ever want. :)

Our board uses the US1881 Hall Latch. I hope to get it tested at higher speeds this weekend, with the ring magnets.

[Ether]

FYI - I just tested our Hall Latch sensor with a ring magnet on a Fisher Price 00801-0673 motor shaft. I got the motor up to max free speed (12V from a bench supply), and the sensor read 20220 RPMs

How were you decoding the sensor signal?
e.g. did you have the FPGA setup to measure rising edges only, or both rising and falling?


The duty cycle was about 45% regardless of the motor speed so I figure that's based on the ring magnet's pole alignment.

Most likely. Were you able to measure any jitter using the logic analyzer?

I feel the US1881 is an excellent device for measuring wheel/shooter/shaft speeds at pretty much any speed we could ever want.

Indeed:)