IR sensors: dealing with reflections?

[gnormhurst]

So, 8:00 Saturday morning, after a day and a half at the Trenton Regional, we asked for permission to do some IR experiments on the playing field.

One reason we were given access is that we showed them that the 3/3/2004 update to the rules include a beacon-type location spec that was the opposite of what they had told us the day before:

3.2.5 IR Beacons
[...]The beacon nearest to the red moveable goal will transmit a Type-1 signal, and the one nearest the blue goal will be Type-0. [...]

The Trenton officials had made a beacon-type determination by unplugging pwm01 from the beacon controller and looking to see which beacon's visible LEDs had gone out -- pretty definitive. Which means that the field was set up incorrectly, so that anyone depending on the rules to set rc_dig_in07 (beacon type select) would have been SOL.

Given that we now knew which beacon was which, further experiments that morning determined that the sensors were picking up the selected beacon pretty much no matter which way they were pointed. I could put my hand in front of the sensor, making it scan, then remove my hand and watch it lock on the beacon in any of several directions. Only one of which was actually the beacon.

The big yellow 2X ball makes a nice reflector, and, being spherical, guarantees a reflection from almost anywhere. Maybe that's why, in one match, instead of turning towards the beacon, it just kept driving towards the movable goal, pushing it down the field.

Now, if the sensors were analog instead of digital, I could write some code to search for the strongest source of the beacon. I did increase the minimum pulse count from 1 to 2:

// original
//#define LEFT_SENSOR Sensor_Stats[Tracker_Data[Tracker].Left_Sensor_Stats_Index].Beacon_Quality[Tracker_Data[Tracker].Beacon_Type]

// new
#define LEFT_SENSOR ( 2 <= Sensor_Stats[Tracker_Data[Tracker].Left_Sensor_Stats_Index].Beacon_Quality[Tracker_Data[Tracker].Beacon_Type] )

but that's not a true sensitivity adjustment. And the total range of adjustment is "1" or "2" -- a pretty coarse adjustment.

To reduce triggering on stray IR, we have encased the trackers in black cans with a clear window. We have the recommended split heat-shrink tubing in place. It still sees reflections and tracks on them. My only remaining thought is to filter (attenuate) the IR coming in the window, to try to reduce reflected light to below the sensors' internal thresholds while still allowing them to trigger on the direct light from the beacon.

Actually, another thought is to use a polarizing filter in front of the sensors, since reflections are sometimes polarized differently than direct light. But this depends on many factors (angles) that would likely change during a match.

What might work much better would be to polarize the light from the beacons (put a polarizer in front of each beacon), then using a matched polarizer on the sensors. This might give very good discrimination between direct and reflected light. But this might(!) also be seen as modifying the playing field!

I know there's one team that modified the tracker.c algorithm to dither the servo back and forth to find the left and right edges of detectability, using the average as a better measure of direction. This is good, I think. Perhaps the difference might be a measure of signal strength? A strong IR signal might be "seen" over a wider range of angles than a weak IR signal?

I need a way to disciminate between direct and reflected IR! Any ideas?

-norm