A quick IR sensor question

Technical Programming
1

Hi everyone,
I just have one quick question. We do our autonomous by dead reckoning, but have put one IR sensor on the robot (at the right height for the beacon, without a servo). All we want to be able to do at the end of our dead reckoning code, is to find a beacon (any one of the two) and go to it.I attached the sensor to digital input one, and here is what my code reads:

…
if(dig_in_01==0)
{
//drive left and right (to find the beacon)
}
else
{
//drive forward for 5 secs.(when find the beacon)
}

Will this code work. Also, will the digital input become 1 is it sees any of the two beacons, or I have to specify which beacon I want it to look for. If I have to specify the frequency or whatever, how do I do that. I don’t want to mess with all the complicated IR code out there to measure distance or anything. I just want to know when my sensor sees the beacon, thats it. We have a regional coming up, so any help would be appreciated.
Thanks,

2

Yes, that could possibly work, depending on how you do the stuff inside the conditionals. :slight_smile:

3

you have the right idea, but your code will work intermitently

the reason is the IR sensors see a pulse for either 1 or 2mS and the SW loops every 26mS - so there is a high probablility that the SW will be polling the input pin when the pulse is not there, even though the sensor is seeing the beacon

there is a very easy way to solve the problem and you DONT have to use interrrupts!!!

to fix it, rc_dig_in01 and 2 are both external interrupt pins, and they have logic that looks for the signal to change state, from a 0 to a 1, and when this happens a flag bit is set - so even though the pulse is too short for SW to always catch it by polling the pin, the flag will remain set until your code clears it. interrupts do NOT have to be enabled for this logic to do its thing with the flagbit

heres what we did - dont let the intr names scare you off - this code is not using interrupts - only looking at those flag bits:


	if (INTCON3bits.INT2IF)	/*578 interrupt flag polling */
	{
		INTCON3bits.INT2IF=0;   /*clear the intr flag*/
		if (DirFilterL==2) DiSeeL=1;	/*IR seen when intr2 3 times in a row*/
		else DirFilterL = DirFilterL+1;
	}
	else
	{
		DiSeeL=0;     	/*turn it off when no intr flagbit is seen*/
		DirFilterL=0;
	}

INTCON3bits.INT2IF is the flag bit that gets set when pin rc_dig_in01 sees a change from a 0 to 1 - which means the sensor saw something

(INTR 2 is on rc_dig_in01 and INTR 3 is on rc_dig_in02 - dont ask why - thats the way the RC is wired :c)

the only problem we noticed is sometimes the IR sensors trigger when no IR is present - its a very short pulse, around 100uS - so we put a filter in the code which requires the flag to get set three times in a row - you see the flag, you clear it, then 26mS later you see it again, and clear it again, then 26mS you see it again and you say OK this is real - set the DiSEEL bit to one (thats the output from this code - we have two on our bot, one L and one R)

it works very well - our auton code uses fixed sensors to the left and right so we can tell when we are passing the beacon - then we stop and back up, and turn towards the ball (we use a yaw rate sensor to measure our turns)

4

Thanks a lot, but I have one more question. So you are telling me that we should use DiSEEL in out if command used for navigation? So should it be like:
…
if(diSEEL==0)
{
//drive left and right (to find the beacon)
}
else
{
//drive forward for 5 secs.(when find the beacon)
}

But what if we have two sensors as you, one left and one right? We only have one variable, then what do we do? Also, can the sensor distinuish between the two beacons since they are on different frequencies?

Thanks a lot for your help.

5

the way I used them no you cant distinquish between the 1mS and 2mS pulse widths on the opposite sides of the field - our sensors point 90° left and right from the front, so we know which is which - when the right sensor goes off, turn right - you dont care which beacon type it really is, right?

if you want to use rc_dig_in02 for the other one, the inter flag bit is INTCON3bits.INT3IF instead, and make a second set of variables for the other side, like DiSeeR and DirFilterR - and make a copy of the code for the right side.

BTW i didnt mention that you have to declare the variables used in that code - I assumed you already knew that.

your code above looks correct (when DiSeeL==1) then that sensor is seeing the beacon

6

Hey, I didn’t know that they had different pulse widths!

slapped

Sorry, off topic. :wink:

7

Pay attention to your “optics”. On the playing field there is IR everywhere. We used crossed polarizers as an adjustable filter to try to reduce the sensitivity to reflections, and we narrowed the opening of the heat shrink tubing. We used 3/8" tubing shrunk down to 1/8" just at the end of the tube. Then we finally were able to discriminate beacon from reflection.

As a point of reference, Tom Watson (of IFI?) at the Phila. regional had a controller set up as an IR tester. Using a naked (no optics) IR sensor, and standing behind the control station tables maybe 25’ from the playing field, he could pick up the beacon on the far side of the field, as well as register the nearer beacon (that was facing away from us), presumably as a reflection off of something.

If your machine drives off into the sunset instead of to the beacon, you are plagued with reflections!

8

a naked IR sensor has an input angle close to 180° on both axis - so its impossible to ‘point’ it at anything

you need to enclose the sensor in something light tight, and only allow light in from one direction

I used the same code we have in our FRC in the EDU RC and a spare sensor in a plastic hobbie box from radioshack - somewhat like a pinhole camera - to scan the field at the buckeye regional - I didnt get any reflections - the code only registered when the sensor was pointed directly at a beacon

BTW we had one match were I though the beacon had reflected off a ref standing at the edge of the field. We had a team member filming all our matches from up in the stands, and reviewing the tape I could see that is NOT what happened - the bearings in one of our triwheel assembles had bound up and the bot veried to the left

I cant recommend using a camcorder on your bot - zoomed in close - enough.

the tapes were extreemly useful after the matches , esp for debugging auton mode.

but there is one thing we learned about the IR sensors - if you simply put a scope or an LED on the output, so it blinks when the sensor triggers, the sensors DO trigger ocassional when there is NO IR present - a short burst about 100uS long (the normal beacon pulse is 1 or 2mS long) so if you are only looking for the output pin to go low, and you dont measure the pulse width, you will get false indications when no IR light is present.

in our code we look for the sensor to be active during 3 consecutive SW loops, then we take it as valid. This works perfectly - the chances of the sensor glitching out a 100uS pulse every 26mS is practically zero - Ive played around with the sensors on my scope, the glitches happen maybe once every 5 ot 10 seconds- it might be something to do with the automatic gain control built into the device.