Measuring motor speed
 

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

Re: Measuring motor speed
 

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/sh...92#post1114292

Re: Measuring motor speed
 

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

Re: Measuring motor speed
 

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

Re: Measuring motor speed
 

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

Re: Measuring motor speed
 

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.

Re: Measuring motor speed
 

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

Re: Measuring motor speed
 

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

Re: Measuring motor speed
 

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

Re: Measuring motor speed
 

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!

Re: Measuring motor speed
 

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.

Re: Measuring motor speed
 

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.

Re: Measuring motor speed
 

Excellent, thanks!

Re: Measuring motor speed
 

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.

Re: Measuring motor speed
 

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

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