|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||||
|
|||||
|
IR sensors: dealing with reflections?
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: Code:
// 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] ) 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 |
|
#2
|
|||||
|
|||||
|
Re: IR sensors: dealing with reflections?
Thank you for the heads-up! None of us (except those who competed already) would know.
I would actually take the far Left/Right of the range (Depending on your direction) since the odds of reflections coming from that direction are much less than others. Of course, this means another switch on the Bot/OI. I can explain in more detail if necesary. |
|
#3
|
||||
|
||||
|
Re: IR sensors: dealing with reflections?
Two things...make sure you place the sensors in a holder that blocks off the sides. My other suggestion would be to add extra fixed sensors to test against. So if your rotating sensors pick up a signal and so do your fixed side sensors and they're not the same angle then ignore it.
|
|
#4
|
||||
|
||||
|
Re: IR sensors: dealing with reflections?
the sensors are very sensitive - btw they are analog and internally they have an automatic gain control that increases sensitivity to pick up weak signals while still being able to handle strong signals - the sensor needs to have a strong enough signal to recognize the 40kHz carrier, so looking at amplitude would not be easy to do.
We found the sensor picks up the beacon from all sides, the front and back - to get good directional discrimination we put them inside black radio shack 1x2x4" project boxes, with a slit at one end - the slit is vertical on the field and it acts like a pinhole camera - this greatly reduces the problem with reflections because it takes a stronger light dead ahead to reach the sensor inside the closed box through the little slit opening. We also look at the interrupts and wait till we get three in a row before accepting the light as valid. We have not been to a regional yet, but our confidence is high. Also, we do not use the supplied code, and we dont look at the mode 0 or 1 (or whatever its called) on the IR - we have a switch on our bot that tells the code to only look on the left side, or the right side. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Getting Fancy with Sensors | FadyS. | Programming | 30 | 10-03-2004 15:02 |
| Why not analog sensors?? | gnormhurst | Programming | 16 | 07-03-2004 16:14 |
| Interrupts and rotation sensors | kor | Programming | 3 | 12-02-2004 11:05 |
| wiring diagram for light sensors??? | pagemauck | Control System | 1 | 21-01-2004 16:32 |
| what type of sensors are good and convenient | magical hands | Programming | 7 | 04-01-2004 23:04 |