Optical sensor for use with retroflective tape

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.

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.

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.

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

http://www.alliedelec.com/search/productdetail.aspx?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?

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.

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.

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

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…





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.

For the 42EF-D1MNAK-a PhotoSwitch the data sheet states: “Response Time 1ms typical”. There is no definition of response time on the data sheet. We have used these sensors with great success to detect game pieces and to detect the gaffers tape on the rug when line following. The 1ms response time was fine for those applications. If you are trying to detect events at frequencies above 100Hz I would be careful.

Last year we used the banner sensors because we had a bunch on hand, but we had also done some testing with a sensor used to detect paper in a copy machine. It was only $10, but we accidentally ordered the wrong one which wasn’t rated for the speed we were using it at. When we got to 4k RPM, it melted and almost caught fire. Before we hit the max switching frequency it worked quite well, so if you can find one rated for a higher speed, I would recommend one.

We did this also. We epoxied a cylindrical magnet to the end of the wheel shaft. We got pulses that looked good on the oscilloscope though we got better readings when we added a low pass filter so I suspect there was some high frequency noise on the output. This solution cost us maybe $5.00 in parts.

Last year we used the KOP light/dark sensors and a piece of retro reflective tape as sort of a home brew optical encoder… We picked up a couple grayhill optical encoder with maximum 10k RPM from Digikey for about 75 bucks to switch to, but never ended up using them. This year we are looking into magnetic gear tooth sensors, one capable of 20k RPM is available on Digikey for 25 bucks.

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?

Lightfoot26: recommendation for a part number?

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.

…and Al, do you recall the part number?

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.

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