Optical sensor for use with retroflective tape

[Tom Line]

I know many teams used retroreflective tape and an optical sensor to measure wheel rpm last year. I'm curious if the ones who did found a good low-cost sensor. We're in a space crunch (as I suspect everyone is!) and don't have any way to attach encoders to the drive shaft.

I've found a few optical sensors that are retroreflective. Some are either ridiculous-expensive. For instance, $100 for a banner sensor. Others are nice and cheap in the $12 range, but don't list a maximum switching frequency! We're looking at rpm's that may range up to 10,000.

[dellagd]

Originally Posted by Tom Line

I know many teams used retroreflective tape and an optical sensor to measure wheel rpm last year. I'm curious if the ones who did found a good low-cost sensor. We're in a space crunch (as I suspect everyone is!) and don't have any way to attach encoders to the drive shaft.

I've found a few optical sensors that are retroreflective. Some are either ridiculous-expensive. For instance, $100 for a banner sensor. Others are nice and cheap in the $12 range, but don't list a maximum switching frequency! We're looking at rpm's that may range up to 10,000.

Here's what we (And I believe 341) did to track their shooter RPM.

Get out one of those photoswitch sensors (Unfortunately they're out of FIRST Choice) and attach it about a centimeter away from your rotating object.

Attach a piece of retroreflective tape to the rotating object and adjust the photoswitch so that it only triggers when the wheel passes.

After this its just programming. I believe we used the hardware counters (I cant remember exactly what its called) available on the CRIO to count the super fast pulses the sensor gives at those speeds. Our readings were just as accurate as any of those handheld tachometers you can buy.

[apalrd]

We used a Banner red-light or IR light adjustable object sensor and an aluminum wheel with black gaffer's tape lines. It worked really well. We had one of each sensor, so the practice bot got one and the comp bot got the other. We had a 4-line disc with very uneven dark/light spacing and not terribly accurate angular spacing, but if we setup the counter to average 12 samples then any phase error between the lines would cancel out and we got a really nice clean signal.

We were running our wheel up to 2800rpm last year. If we were dropping pulses, we could have made a half black half aluminum disc and still had plenty of resolution due to the extremely high speed.

For cheaper sequencing object detection, we found some really nice, light sensors made by Sick that could detect balls easily. They look kinda like the Banner ones but they're not adjustable and have a clear housing. We weighed them at 28g including cable (1m or so) and plastic locking nut. By comparison, the 2011 KOP and FIRST Choice ones weighted around 1/3rd lb EACH including cable. I don't think we found a speed spec for the SICK sensor, but it was perfect for detecting balls.

[Ether]

Originally Posted by apalrd

We had a 4-line disc with very uneven dark/light spacing and not terribly accurate angular spacing, but if we setup the counter to average 12 samples then any phase error between the lines would cancel out and we got a really nice clean signal.

If you had only 4 pulses per rev, why would you need 12 samples to average out the spacing error? Or am I misinterpreting your intended meaning?

[Ether]

Originally Posted by apalrd

We had a 4-line disc with very uneven dark/light spacing and not terribly accurate angular spacing, but if we setup the counter to average 12 samples then any phase error between the lines would cancel out and we got a really nice clean signal.

With 4 pulses per rev, you need only 4-sample averaging to completely cancel out the jitter due to the inaccuracy of the pulse spacing.

Increasing it to 12 helps to further cancel out the jitter due to the 6.5us resolution due to the rate at which the FPGA looks for pulses.

[sanddrag]

Can the cRio process fast enough to read something like a standard 250 count encoder at 7200 RPM? I'm just curious.

[Ether]

Originally Posted by sanddrag

Can the cRio process fast enough to read something like a standard 250 count encoder at 7200 RPM? I'm just curious.

AIUI, the 250 CPR encoder has 500 edge transitions (rising+falling) per channel per rev. At 7200 RPM, that would be 7200/60*500 = 60,000 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 7200 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 1400 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 approx 11 RPM p-p.

[WizenedEE]

Last year we attached two magnets in opposite directions on opposite sides of our shooter wheel, and put a latching hall effect sensor on to read them. It worked extremely well with our speed getting up to 3300 rpm.

[AllenGregoryIV]

We used these last year with just white gaffers tape on the wheel.

http://www.alliedelec.com/search/pro...x?SKU=70048630

They are much cheaper than the Banner sensors that all the veteran teams still have around from the old KoP.

[AdamHeard]

Originally Posted by AllenGregoryIV

We used these last year with just white gaffers tape on the wheel.

http://www.alliedelec.com/search/pro...x?SKU=70048630

They are much cheaper than the Banner sensors that all the veteran teams still have around from the old KoP.

What rpm did you run them at and w/ how many ticks per rot?

[AllenGregoryIV]

Originally Posted by AdamHeard

What rpm did you run them at and w/ how many ticks per rot?

1 tick per rotation at about 4,000+ RPM.

We had to space the sensor about 6 inches away from the tape to get it to read. They don't have the nice light that the Banner sensors have to tell you when it's reading and they also don't have a calibration screw. I think they will work much better with retro-reflective tape.

[Al Skierkiewicz]

In the past on our crab modules, we have used standard LED/photo transistor devices from Digikey. We manufactured a stamped plate that mounted to the side of the wheel. The plate was a sandwich of two pieces of aluminum with black construction paper between. The Digikey sensor then illuminated the plate and produced an output when it reflected from the shiny surface but not when facing the black paper. If you look through the catalog you can find these in a single housing with four leads. I think they were about $1. Put two on and you get quadrature outputs. We stamped 8 openings as I remember to give us a count. Retro-reflective not needed.

[Tom Line]

Originally Posted by AllenGregoryIV

We used these last year with just white gaffers tape on the wheel.

http://www.alliedelec.com/search/pro...x?SKU=70048630

They are much cheaper than the Banner sensors that all the veteran teams still have around from the old KoP.

Thanks - at that price, we'll give this a try first. I really don't want to put the sensors 6 inches away, so we'll use retroreflective tape and put it on 1/2 the wheel. That should help detection.

Thanks for the suggestions everyone. Our second fallback will be the photoswitches in the 2011 KOP: Jared confirmed that is what 341 used. If we need the weight, we'll drop the money on the banner sensors. At 2 sensors per robot, they'll end up being the second most expensive thing on board (minus the cRIO).

[jonboy]

We had an off season activity to demonstrate feedback to control the speed of a CIM and needed a sensor to sense shaft speed. It was canning season so I got a canning jar lid, removed the rubber sealing matl, hammered it flat, drilled a hole in the center, and put 8 notches in the edge with a paper hole punch. Mounted the lid on the CIM shaft with hot melt glue. Got an opt switch out of a printer, mounted it on a vector board with two resistors and connected it up to the DIO. See pic attached. Has worked fine for months and is a great way to demonstrate feedback control to our team. Worked like a charm. Compact, lightweight, very low cost, ultimate in recycling/reuse...

[Dan Oelke]

I just ordered a couple of hall effect sensors off Automation Direct.
I ordered Part - AE1-AN-2A. I figure these can be set up to sense a bolt head on the wheel. However - I worry about getting it consistently 2mm away and not having a collision between the sensor and the bolt head.

I have been playing with the idea of using the photoeye from 2 years ago. These Rockwell (or Allen-Bradley) ones. However - they don't list a frequency.

So - those who have used these sensors - what kind of frequency were you able to get out of them?

One other question - since we are all probably looking at these for speed control of a shooting disk. How often do you set up your loop to measure the speed and adjust the power level to the motor? To often and you won't have enough counts to stay accurate. Not often enough and you don't zero in on the right speed quick enough.