IR Sensor questions

OK my team is looking into assembling and possibly using them but first and foremost I can’t seem to find the schematics to the IR sensors or the Current sensors. Where might these be located. And secondly a kind of programming question, what does FIRST’s standard default on the IR sensors tell the robot to do?? (if you can diagram it it would be helpful). I ask this b/c it’s the difference between line following and the sensor that we want to measure (as to how fast each is) if any team has completed trials of this and would like to post results they would be most appreciated. Thank You :confused: :cool:

We built the beacons. We loaded the EDU RC with the beacon code. We built a servo-mounted tracker. We loaded the competition RC with the tracker code. We turned it on. We got the IR detectors plugged into the right digital inputs.

It worked.

BUT the biggest problem we had with the system was reflected IR. The tracker would lock on and track the beacon beautifully. It would also lock on and track reflections of the beacon just as beautifully. Imagine a flashlight in a house of mirrors. The tracker was happy to track any one of at least two dozen different points in the room.

This was in a normal room with normal walls and furniture. I can’t imagine what would happen with gobs of aluminium diamond plate and robots thrown into the mix.

The bottom line for our team was that the system is not reliable enough to use on its own. It could be helpful if used in tandem with some other sensor package. We will probably use an IR tracker but it will have to agree with our odometry and our angular rate sensor before our software believes what it’s telling us.


Reason I ask is we will have to design a whole new custom circuit with the gyro in order to turn that sensitively if the IR beacon is not reliable and that takes alot more time than I would like to devote to doing that… :rolleyes:

You can find the build directions on the FIRST website. When you build the beacon, reverse pins 2 and 3 of Q1 because the schematic is incorrect. A known good schematic can be found on my website. While tweaking the navigation software for the kick-off demo, we could consistantly get to the beacon in 10 or 11 seconds.


This is a problem that can be solved with some creative engineering. I found out early on that if I placed the sensor at the same height as the beacon and severly limited the sensors view to areas above and below the beacon, the tracker worked really, really well.


Thanks for the tip, Kevin. We’ll keep tweaking our “blinders”. We’re planning on using one or two trackers as a backup/sanity check for our odometry.



Any hints on how to “severly limit” the sensors’ view above and below. I don’t see evidence from the pictures on your website.

Anyone have any pictures of the workin IR beacon circutry

If the sensors rotate in a plane that includes the beacon, the tracker will work just fine if it can’t see (reflections) above or below that plane. Our original prototype looked like a side-by-side shotgun mounted to the servo. Imagine looking through a long, dark piece of tube while you slowly spin around a dark room that also has a friend holding an LED flashlight at the same height as the tube. As you spin around, what are the chances that you’ll see a reflection off of any surface? Pretty slim because the point of reflection must also reside on that idealized plane. The chances are also made even slimmer when you realize that not only does the point of origin have to reside on the plane, but the photon must also pass through one specific spot on the plane: your eye.

We found this setup to work pretty well until the servo had to try to keep up with a moving target. So we had a minor epiphany and realized that if we cut a slit down the tubes such that one of the sensors would always have a view of the beacon, we would always know which direction to move the servo to catch up. This greatly simplified the tracking state-machine to this:

Right Left
Sensor Sensor Action
0 0 Search until one sensor sees the beacon
0 1 Rotate left
1 0 Rotate right
1 1 Do nothing

0 = Beacon “quality” == 0
1 = Beacon “quality” > 0

Hope this helps.


I don’t know if it’s been said already, but it would be worth saying it twice. Thanks for all the hard work, Kevin. It is much appreciated. I wish you could have seen the faces in our shop when we got the tracker working.


Thank You all this information will really help (and maybe we won’t end up redesigning that particular pain of a circuit…). If I can come up with any more ideas on this I’ll be sure to post them. Thanks again for all the help. :]

Our team tried out the IR beacon, and it tracks alright… But there’s some flaws to the IR… If the IR bounces off metal or something shiny, it screws up the way it tracks the beacon… Any Ideas to solve that? The only thing we tried are paper tubes, and yet, the IR could bounce off metal objects like a desk for example and screws it up… Any sugestions?

Joel, that last sentence made it all worthwhile. Thank you.


Can someone help me interpret the comment at the top of tracker.c?
IR sensor 1 is the left sensor on the left tracker
IR sensor 2 is the right sensor on the left tracker
IR sensor 3 is the left sensor on the right tracker
IR sensor 4 is the right sensor on the right tracker
This seems to make some design assumptions that I have not read somewhere? If I were to diagram this looking at the robot from the top - would it look something like this?




No, each servo motor has two infrared sensors mounted on them. Each one of these assemblies is called a “tracker”. You’ll need at least two trackers, spaced as far apart as you can get them, before you can triangulate a heading and distance to the beacon(s). This is from the FAQ:

Q: Got any photos of an example tracking assembly?
A: Glad you asked. Have a look here.


Kevin - thanks for the clarification. Does anyone have a suggestion on a good way to power the IR beacons and use the EDU-RC for developing tracking code? Can this be done - or can we only do one or the other?

Yes, the beacon and tracking code was designed to work on a single EDU-RC (in fact it was developed on a single EDU-RC). Have a look at this thread. Look for Mark McLeod’s code that does exactly what you want.