Measuring motor speed

[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]

Originally Posted by pfreivald

We tried using this optical sensor 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]

Originally Posted by Teamcodeorange

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]

Originally Posted by pfreivald

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]

Originally Posted by pmangels17

I recommend gearing down the RPM as much as possible.

Originally Posted by 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.

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]

Originally Posted by fovea1959

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 averaging¹?

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


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

[iambujo]

Originally Posted by 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). ....

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]

Originally Posted by fovea1959

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]

Originally Posted by fovea1959

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.

Originally Posted by iambujo

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

[Ether]

Originally Posted by 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

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