Optical Sensors Used as Encoders?

I’m sure on past robots teams have tried to use their optical sensors as an encoder by placing bits of reflective tape on a wheel/sprocket and counting the number of times a sensor mounted to read the pieces of tape was ‘activated’ (I’m not a programmer so I don’t exactly know the correct terms).

Our team is considering pursuing this idea once we uncrate our robot at regionals, having the programs pre-written. We are planning on putting 8 evenly spaced pieces of reflective tape on the rims of our back wheels, and mounting two optical sensors to appropriately interact with the pieces.

I was wondering if any teams in the past have had success (or lack of) with this procedure, and if so, what the optimal setup(s) are (tape spacing, distance from sensor to wheel, etc…). Our programmers are very good at what they do, so I don’t think that will be a problem. Any advice would be greatly appreciated!

we put 2 pieces of tape on the black couplings between the motor and the gear box, and we have one banner sensor on each side. lol we just need the code, because it works perfctly electricly… the light blink, the osiliscope has a beutifull trace. i was planing on using intrupts to count revolutions, and then every 10 program loops compare counts and adust PWMs accordingly. if you find any good code PLEASE post! thanks

I dont think this use of tape is allowed by the rules. Last year we used some white paint on a black gear. This year we drilled holes in the gear and put an aluminum plate behind the hole opposite the sensor. It works very well (and we took some weight off doing that :))

As for code… Wire the sensors to interrupts (digital pins 1 and 2). You can find some examples in the IR beacon tracker code. Last year I polled the sensors every program cycle and it did not work too well (not fast enough). The interrupt method works perfectly.

And dont forget to use the normally high output of the sensors

lets not over interpet the rules here… the “tape” in question is special 3m opto reflective tape that is not making any mechanical connections with anything else. therefore it can be said to be decrotive.

anyway. yeah i get to have fun learning how intrupts work the day we get down to reagonals. what great fun

we are using this method on both wheel units and our lifter…

our sprockets have holes milled in them and the banner senor reads off the alluminum on our wheel units

and for our lifter we have electrical tape on the black connecter for the chip motor and that works fine…

if you need some code i can see what i can do about getting it…

RAGE used optical sensors and retroreflective tape pieces for their autonomous last year and it worked well enough (watch video of 2003 UTC Regional and 2003 Newton Division Elims for a demo)… the optical sensors are very hard to deal with at times (they have random spats during which they don’t work)… Good luck with them.

any help would be greatly appreciated :ahh:

Really, the code to this is not that hard. I would not use interrupts, only because getting them to interface correctly with the code can sometimes be a problem. Now, i forget whether the Banner sensors Run at full speed or not, but this is how i would code this segment. Note: If banner sensors do run correctly In FAST mode, place this code in the user_routines_fast.c, otherwise, just put it in your regular segment

Assumes banner sensors are wired as Normally Closed, and are wired to rc_dig_in01&02, and pwm01&pwm02 are the left and right wheels respectively. If you got questions, ask away.

FIRST: at the header (for variable data)


int leftcount=0,rightcount=0;//note, is signed to care for backward variables
unsigned char leftlast=0,rightlast=0,roundcount=0;//only cause we dont have a bool class

Second:(its kinda apparent)


void Process_Data_From_Local_IO(void)
{
	if(rc_dig_in01==1 &&leftlast==0)//left wheel counter 
		if(pwm01>127)
			leftcount++;
		else if(pwm01<127)
			leftcount--;
	leftlast=rc_dig_in01;		


	if(rc_dig_in02==1 &&rightlast==0)//right wheel counter
		if(pwm02>127)
			rightcount++;
		else if(pwm02<127)
			rightcount--;
	rightlast=rc_dig_in02;

	if(roundcount>12)
	{
		if(leftcount>rightcount)
			//whatever you want
		else if(rightcount<leftcount)
			//whatever you want
		else
			//take a guess?
		
		rightcount=leftcount=roundcount=0;
	}



	roundcount++;

}

Thats the quick, easy, and fun way to do it.

side note, i wrote this just right now, so if you find a problem with it, just post a correction below. Anyone may use this however they want, think of it as a mixture between the OpenSource in me and the Gracious Professionalism. As another side note, if anyone else needs coding help, i have become quite good at it, just send your questions my way.

We did this exact thing last year and ot worked out pretty well. We split the coupling on our motor with tape. (half tape) and then made a quadrature encoder by using two optical Banners at 90 degrees from each other. THis way we knew of the wheel was spinning forward or reverse.

This worked out well, and given the ratio of this motor coupling to the output wheels, we had about a 3" resolution on out drive position.

It all worked out pretty well, but the thing that killed us was momentum when we stopped driving the motor. We had much overshoot at first, and much oscillation when we tried to impliment feedback.

Good luck,
-Quentin

Just me 2 cents, but if you are going to go through the trouble to do all this, then why not just use encoders or gear tooth counters?

If you use reflective tape and banner sensors, it will work, but i don;t see how you can possibly get much resolution.

Mostly because our team has a serious lack of $$$ and time, and since we have the banner sensors and can easily acquire some tape or white paint to put on our wheels, it’s worth the try. And we’re hoping that with enough ‘markers’ we can get it accurate enough for our purposes…

Thank you everyone for all of your help…

Q/A:

ID: 657
Q: I’m looking for clarification on the question about using reflective tape to count wheel revolutions. You said this was OK, but since the rules say electrical tape only, I’m wondering if other kinds of tape would be OK for this same use?
A: Other kinds of tape are okay for this use only.

Personally, I think unless the bot is very slow, the extra resolution wont matter. You still cant stop the bot :slight_smile: theres just too much inertia. And we are not using the sensor on the actual wheel. We have it on a gear that is in a ratio of about 18:1 to the wheel. So that increases the resolution. And about the tape… The rules say “no adhesive-backed tape on the robot. The only exception is electrical tape, and it can only be used as as insulator”. So a “decorative” explanation might not go over with the inspectors too well. White paint works very well, and is completely legal.

We used Banner sensors last year for wheel encoders and have included them this year as well. We use a custom wheel so when the wheel was being assembled we just slipped a piece of dark papaer between the spokes of the wheel. By using two encoders (outlined above) you can tell direction and distance traveled. Last year we were able to get accurate down to at least an inch which made auto mode pretty easy. You need to couple the wheel sensors with a direction device to really know where you are.

Last year we used banner sensors and tape marks, but this year we went ahead and spent a whopping $80 for shaft encoders (300 clicks per revolution … as opposed to the 8 at best we had before). :smiley:

Not counting slop in the chains, I’m predicting .3 in resoulition We will be testing and codeing on a drive mock up built with some unused but gorgeous double bearing blocks and last years Cim motors. Hopefully we can make it all work in our “Drive system lab”

I read all the First Questions and answers last night and they said that reflective tape for pulse generation is legal. As long as they don’t change their minds like they did with the yaw rate sensors life will be good.

lol we dont need 1/4 degree resoluton. we need to know GENRALY how many times the wheels have turned…

Well, it shouldnt be hard to figure out w/ the code example i posted. Let me know if it comes in handy

We tested the banner sensors to measure RPM’s, and from what I saw it worked quite well, but our team decided to go with shaft encoders.

We also were going to use a potentiometer to measure the position of our arm, but also went with shaft encoders for that since the potentiometers from RadioShack were only responsive over about 180 degrees of their range, and we needed the full 270 degrees. We could have geared down the potentiometer, or gone with higher quality potentiometer, but we already had the shaft encoders.