2004 FRC Infrared Beacon & Tracking Frequently-Asked-Questions

Q: Where can I find more information about the infrared sensor?
A: See the Vishay TSOP34840 data sheet.

Q: I can't find the TSOP34840 sensor in stock anywhere. Is there an alternative device?
A: Yes, use the virtually identical Vishay TSOP4840, which is available at Mouser and Newark (where for some strange reason it's incorrectly listed as a resistor).

Q: Is there a data sheet for the infrared beacon LED?
A: It's a Lumex OED-EL-1L2.

Q: So what do the beacon waveforms look like?
A: Good question. Here's an illustration (PDF).

Q: How many times a second does each beacon flash?
A: They flash 100 times a second.

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

Q: I merged the code from the tracker codebase into my code for non-autonomous driving, including dropping the replacement user_routines_fast.c in place of the default one, and things got weird. The trackers would run okay, but the motors, connected to PWM 13 and PWM 15, started running and stopping with a jerking motion. Having read that there is something different about PWMs 13 through 16, I connected my motors to PWM 10 and PWM 11, turned all the tracking code back on, and everything worked nicely! Can you tell me why changing the motors from 13 and 15 to 10 and 11 changed the behavior from erratic to normal? What's going on here?
A: PWMs 13 through 16 are different because they're controlled by the user processor. I saw the wacky behavior you described while developing the receiver and tracking code. The problem isn't with my code (as far as I know). The IFI folks know about this and wrote it up.

Q: We're seeing wacky behavior like that described above, but we're not using PWMs 13 through 16. What's up?
A: Your interrupt handler(s) might not be saving enough context information. I altered the code to be more conservative in this regard. Get the latest version of the code or just alter the #pragma interruptlow line in user_routines_fast.c to look like this:

#pragma interruptlow InterruptHandlerLow save=PROD,section("MATH_DATA"),section(".tmpdata")

If this change causes problems for you (e.g. your encoders stop working correctly), there are other options that you can try. Read section 2.9.2 of the PIC18 compiler user's guide for more information.

Q: We've assembled the beacon described in the FIRST documentation, but it doesn't seem to work. Got any ideas?
A: The documentation included in the kit and the document "Infrared_Beacon_Wiring_Diagram.pdf, dated 1-16-04, on FIRST's web site has an error in the design. You need to switch pins 2 and 3 of the MOSFET labeled Q1. Here's a known good beacon schematic. The location of the pins is documented in page 8 of the IRL3103 data sheet. Update: The latest document on FIRSTs web site, dated 1-27-04, is correct. Here's a local copy.

Q: We fragged our IRL3103s. Where can we get more?
A: Digi-Key has 'em in stock. Search for part number IRL3103-ND.

Q: We reversed the leads on our infrared LEDs. Where can we get more?
A: Digi-Key has 'em in stock. Search for part number 67-1001-ND.

Q: Where do the sensors get plugged in?
A: It depends on which version of receiver.c you're using. Read the header at the top of receiver.c for the information.

Q: Our sensors will only detect the beacon from a few inches away. Why?
A: I wish I knew. I've heard this from several sources now. The only clue that I have is one team who said that the sensors worked fine until they applied some heat-shrink tubing, which leads me to believe that the sensors are getting fragged by too much heat. If this is the case, please don't use uncle clyde's 40 year-old weller soldering gun that he used to make the stained-glass windows with (yeah, the one that dims the lights throughout the house when the trigger get pulled). Please go to Radio Shack and buy a ~25 watt soldering iron for your soldering needs.

Q: Which infrared transmission signal, Type-1 or Type-0, will be transmitted from the beacon on the side of the field with the red moveable goal at match start? Which will be transmitted from the beacon on the side with the blue goal?
A: 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.

Q: When we power the detector with 5V and ground and look at the voltage at the detector output, that is the output is not connected to the RC, just the meter, we seem to detect a change from 5 V when there is no signal from the beacon and 4.4V when there is a signal. Is this right? Can you explain what is going on?
A: Hey, this is very cool because this is exactly what you should be seeing. With the beacon present, the meter is averaging the the output of the sensor over time. An ideal meter when measuring a +5 volt pulse train will register a voltage equal to 5 * (on time/total time). The output of the sensor, when viewing the type-0 beacon, is on for 9.0ms of every 10ms. plugging this in to the equation results in a voltage of 4.5. On the other hand, the output of the sensor, when viewing the type-1 beacon, is on for 8.0ms of every 10ms. plugging this in to the equation results in a voltage of 4.0. I'll bet your sensor was pointed at the type-0 beacon when you measured your 4.4 volts. If both beacons are in view of the sensor, the voltage will be even lower (3.5v). You can find an illustration of the sensor output here.

Q:The tracker acts erratically and behaves as though it was trying to avoid the beacon. What's with your psycho software?
A: Open tracker.h and change the sign of the number beside INITIAL_SERVO_STEP_SIZE and try it again.

Q: The infrared tracker doesn't stop when it views the beacon, but instead oscillates back and fourth in the general direction of the beacon. Why can't it make up it mind?
A: Make sure that then the sensors are pointed at the beacon, that they both can "see" the beacon.
If there is no overlap (a few degrees) in the sensors view of the beacon, the software cannot track the beacon and you'll observe this erratic behavior in the servo motors motion.

Q: Shouldn't the beacon tracking and navigation code be called from User_Autonomous_Code() rather than Process_Data_From_Local_IO(). What gives?
A: Yes, if you use the Navigate() or Track_Beacon() functions, they need to be called from User_Autonomous_Code(), not Process_Data_From_Local_IO(). The code was written this way because we needed to be able to start the kick-off demonstration by pressing a switch on the joystick.

Q: Once the sensors lock onto the beacon, how do I determine the angle of the infrared sensors with respect to the beacon so that I can calculate the distance and heading to the beacon?
A: You first check to see if the two trackers are locked-on to the beacon and then using the current commanded servo motor positions, you should be able to calculate a heading and distance to the beacon. An example of how to do this is documented in frc_tracker.zip / user_routines_fast.c / Process_Data_From_Local_IO():

if ((Tracker_Data[LEFT].Status == BOTH_IN_VIEW) && (Tracker_Data[RIGHT].Status == BOTH_IN_VIEW))
{
// both trackers have an angular solution; calculate beacon vector
// here using the known baseline distance between the trackers and
// angles derived from the two Tracker_Data[].Position variables

// calculate new drive motor PWM values here
}

Q: In receiver.c, for each sensor interrupt, in case "WAITING_FOR_UP_EDGE", where you are handling the rising-edge interrupt, you increment the Sensor_Stats[i].Beacon_Count[j] for both pulse types.  However, for pulse type 0, you also increment Sensor_Stats[i].Beacon_Quality[0], but you do not do that for type 1.  I'm a little thrown off by this.  It seems to me that Beacon_Quality does not need to be incremented at this point in the logic in either case (beacon type 0 or 1), since it will be set properly every 26 ms from Timer 1.  Is that one line of code to increment Beacon_Quality for pulse type 1 just an extraneous line that is not needed or is there a reason for it being there?
A: This is a bug. Okay, it's not much of a bug and I can't imagine it negatively effecting the operation of the code, but it's a bug nonetheless. If you want to, find the four instances of code (one in each of the interrupt handlers) that looks like this:

if ((Int_1_Period >= BEACON_0_LOWER_BOUND) && (Int_1_Period <= BEACON_0_UPPER_BOUND))
{
Sensor_Stats[0].Beacon_Count[0]++;
Sensor_Stats[0].Beacon_Quality[0]++;
}

And make it look like this:

if ((Int_1_Period >= BEACON_0_LOWER_BOUND) && (Int_1_Period <= BEACON_0_UPPER_BOUND))
{
Sensor_Stats[0].Beacon_Count[0]++;
}

Thanks go to Bob Beckley for catching this. I'm surprised this wasn't caught earlier; There has to be more than a few programmers out there playing the let's-find-a-bug-in-the-NASA-guy's-code-and-publicly-flog-him-over-it game <grin>.

Q: So how did the bug, described above, effect the operation of the tracker?
A: It didn't, really. At best, it incremented the "Beacon_Quality" variable one extra time before the Track_Beacon() function used it. Because Track_Beacon() only cares if the Beacon_Quality variable is zero or greater than zero, it didn't negatively effect the normal operation of the tracker.

Q: We plugged the sensors into the robot controller and then used a printf() statement to tell us what the sensor is sending to the controller. The problem is that when we point the beacon at the sensor, we see lots of 0s and 1s. Why is it doing this?
A: When the beacon is in view of one of the sensors, the sensor doesn't emit a continuous 1 or 0. The code in receiver.c is designed to decode the signals for you. The fact that you did see some 0s is probably good news because the sensors emits a 0 when the beacon flashes. Does the sensors emit a continuous logic 1 when the beacon is turned-off and then a bunch of 0s and 1s when the beacon is then turned-on? If yes, I'd say your beacon and sensor(s) are working. Your next step is to build a tracking assembly to see if it's really working.

Q: We attached the sensors to the PWM cable the way it's illustrated in FIRST's "Photo-detector Diagram" document, yet it doesn't seem to work. Got any ideas why?
A: Yes, the document is wrong and has sensor pins 1 and 3 swapped. Build it using the instructions below. Update: The document dated 1-29-04 is the corrected version. Here's a local copy.

Q: How do we build the infrared sensor assemblies?
A: One way to do it is to cut the male end off of a PWM cable, strip some insulation off each of the three wires, and then solder the white or yellow wire to pin 1 of the sensor, the black wire to pin 2 and the red wire to pin 3. Make sure to insulate the connections to prevent shorting. A diagram of the sensor with pin assignments can be found on the first page of the TSOP34840 data sheet.

Q: How many LEDs does the official infrared beacon use?
A: Seven, arranged in a partial circle.

Q: What is the height of the beacon LEDs above the field?
A: 44" ± 1".

Q: What does the beacon radiating pattern look like?
A: Except for shadows created by the stuff in the center of the field, each beacon will flood the entire playing field to a height of around 44"

Q: Why only 44"?
A: This is a good thing. The crack FIRST engineering team designed the beacon housing with an aluminum plate that juts out over the LEDs to suppress beacon reflections from surfaces outside the playing field.

Q: Is there an optimum height to place the infrared sensors?
A: Yes, the height of the infrared sensor plane-of-rotation should match the height of the beacon LEDs. This will give you the maximum sensitivity and, more importantly, allow you to design an infrared sensor housing that will limit the view of the sensors to only include the plane the beacon LEDs are radiating in. This will help prevent beacon reflection problems from below (e.g., the diamond plate sprinkled around the field) and above. Additional information about beacon reflection problems can be found below.

Q: What's to prevent some evildoer from sitting out in the audience with a beacon to disrupt the competition?
A: Yes, there's always some miscreant who is capable of doing stuff like this. This is another good reason to limit the view of your infrared sensors to the plane the infrared beacons are radiating in. BTW, I know the FIRST engineering team has anticipated this potential problem and will have crafted a way to find people doing this.

Q: We've assembled everything and it works pretty well except the infrared trackers are tracking beacon reflections off of reflective surfaces. What do we do?
A: You think like an engineer and find a creative way to solve the problem. Didn't you see the flawless demonstration performed at the kick-off? If so, you know it can be done.

Q: Okay, we're four weeks into the build and we're spazing because we're too wired on Mountain Dew, not getting enough sleep and we really don't need flippant answers like the one above. So what's the deal with reflections? Don't make us come over there and steal the plastic pink flamingos from your front yard!
A: <sigh> Okay, 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:

Q: I still don't think it's going to work because when I fire-up the beacon in my bedroom, the tracker still sees reflections from the walls, the carpet, and my chihuahua.
A: Okay, I know it's convenient to build and test gizmos in one's bedroom, and instead of driving out to the desert, I would love to bring home the odd prototype Mars rover for testing in my bedroom, where I'm near an ample supply of Diet Pepsi and tools. Sure, it makes a lot of sense to design and initially test stuff in the lab (or bedroom), but before you make a final judgment on how well your gizmo works, you've got to test it in it's intended environment, which, in this case, is a FIRST robotics playing field. Here are a few of the differences:

1) When your bedroom was built, I'll bet that little thought was put into the suppression of infrared beacon energy. Update: Okay, so a few of you do have infrared energy-suppressing bedrooms. Please stop e-mailing me because you're creeping me out.
2) The ambient light level is too low for the amount of infrared energy that's being transmitted. The infrared sensor has a built-in AGC (Automatic Gain Circuit) that greatly amplifies the output of the infrared photo diode when the noise level (ambient light) is low. With the gain on the amplifier cranked-up, the sensor is going to be able to sense (and react to) the faintest reflection. Add to this an infrared beacon designed to blast enough energy to fill a full-size 48' x 24' playing field and it shouldn't be any wonder the the tracker tracks your chihuahua. Either reduce the amount of transmitted energy with a filter, increasing the value of the current-limiting resistors, etc. or increase the amount of ambient light in the room. As an example of just how well these sensors can detect the infrared beacon, while testing the receiver code, I setup a beacon LED next to a very bright flashlight and had no problem tracking it from a foot away or across the room. For extra credit, at night, fire-up the beacon in your bedroom after turning-off the lights, duct-taping the cracks around the door(s), etc. Pretty dark, right? Now, turn-on a camcorder or digital camera that has a LCD viewfinder. Unless, your camera has a built-in infrared filter, you should see the room through the viewfinder as thought it were dimly lit. This is how the sensor "sees" your room.
3) Your bedroom probably isn't the size of the Georgia Dome. The chances of a reflection making its way back to the sensor with enough energy to be detected, is reduced in large spaces because of the inverse square law of light brightness, which states that the amount of light energy deposited on a fixed area is inversely proportional to the square of the distance traveled. As an example, the reflection off the bulb in your bedrooms table lamp has on the order of one-hundred times more energy than one returned from the bulb in the fixture on the ceiling of the Georgia Dome.

Q: We noticed that the sensor can sometimes detect the beacon even when the little window isn't pointed at it. Is this a problem?
A: Yes, I can see where you might think the little hemisphere window is where the infrared light must enter to be detected. Actually, the entire epoxy package, that the sensor is embedded within, is transparent to infrared light. I've noticed that unless I shield everything except that window, the sensor will detect the beacon from just about any angle. This is why you'll see the sensor in my example tracking assembly is covered by dark gray heat shrink tubing.

Q: In the infrared sensor documentation I noticed Vishay recommends using a filter on the power going to the sensor. Do we need to add this?
A: I'm not sure it's necessary in this application because the sensor is not being used to receive complex commands, where timing is very important. Even if the sensors output "glitches" because of noise, the software in receiver.c should do a really good job of discriminating against such noise. If you do notice that the tracker acts weird in the presence of noise sources (e.g., motors), consider routing the sensor cable(s) away from the motors, victor 884s and the cabling between them. If you still have problems, consider installing a small ceramic (not tantalum) ~0.1 uF capacitor on the power leads of the sensor.

Q: What variable do we read if we just want to see if a sensor sees the beacon?
A: The variable to check is Sensor_Stats[i].Beacon_Quality[j], where i indicates the sensor number (use 0 for sensor 1, 1 for sensor 2,..., 3 for sensor 4) and j indicates which beacon you want data for (use 0 for type-0, 1 for type-1). If the beacon indicated by j isn't in view of the sensor, this value will be 0. If the beacon indicated by j is in view, this value will be >0 (usually 2 or 3). When the receiver.c code is running, this variable is updated around 38 times a second. The sensor_stats structure is defined in receiver.h.

Q: Can I drive the infrared beacon LEDs with a frequency generator, set at 40 KHz, 50% duty cycle, and then observe the infrared sensor's output change state?
A: Yes (and mostly no). You'll see a brief low-going pulse when you turn on the frequency generator and then, mysteriously, nothing. You'll see a note on page five of the data sheet that says the device will discriminate against continuous 40KHz signals. To get a continuous stream of output pulses from the sensor you're going to have send it bursts of modulated infrared light, like the beacon does.

Q: Does the infrared Beacon transmit differently on the left versus the right side of the playing field?
A: Yes, the type-0 beacon will be on one side of the field, the type-1 beacon will be on the other side. The FIRST engineering crew will assign which side they'll be on.

Q: Is it the intent of FIRST to have us build the IR drivers on the Vector board, with two sets of transmitters, each connected to PWM1 and PWM2 on an EDU-RC?
A: Yes. In practice, you may really only need to build one beacon because your 'bot will only be seeking one type of beacon at a time.

Q: How does the code in beacon.c generate the waveforms?
A: Beacon.c just initializes the two CCP/PWM modules to generate a 40KHz, 50% square wave. Timer 0 is then used to periodically call a software state machine that does two things: Controls which, if any, PWM channel is allowed to oscillate and then sets the delay, via timer 0, before the state machine is called again. This is the sequence of events within the beacon state machine:

1) The type-0 beacon is allowed to flash for 1ms. As the carrier frequency is 40KHz, this means the LED will flash on and off 40 times.
2) A delay of 3.5ms where both LEDs are off. This allows reflections to die off before...
3) The type-1 beacon (on the other side of the field) is allowed to flash for 2ms, which means the LED will flash on and off 80 times.
4) Another 3.5ms delay is inserted where the LEDs aren't flashed before the state machine starts all over again at #1 above.

If you add up all of the periods (1ms + 3.5ms + 2ms +3.5ms), you'll see that the total time needed to flash the beacons is 10ms, which means the beacons flash at a 100Hz rate.

Q: Where on the EDU-RC do we attach the cable to the beacon transmitter circuit(s)?
A: PWM output 1 for beacon type-0, PWM output 2 for beacon type-1.

Q: Would it be correct to say that the code in receiver.c does the job (among other things) of distinguishing between the beacons by measuring the burst time duration.
A: Yes, the interrupt handlers in receiver.c each take a snapshot of a free-running 2.5MHz system clock on the falling-edge of the sensors output pulse and then calculates elapsed time when the interrupt handler is again called in response to the rising-edge of the pulse. If the pulse period is within +/-25% of the expected period of one of the two different beacons, it's counted as that type of beacon, otherwise it's discarded.

Q: Where are the interrupt inputs on the FRC robot controller?
A: They're there, they just aren't marked. The PIC18F8520 port b interrupts, available and marked on the EDU-RC, map to the first six digital inputs of the FRC robot controller. In other words, interrupt 1 on the EDU-RC is the same as digital input 1 on the FRC-RC, interrupt 2 on the EDU-RC is the same as digital input 2 on the FRC-RC,..., interrupt 6 on the EDU-RC is the same as digital input 6 on the FRC-RC.

Q: In the kick-off code you use interrupts 1, 2, 4 and 5 why did you skip interrupt 3 as a sensor input? Can't you count like normal people do?
A: At the time the code was written, I only had 3x2 connector housings that precluded the use of the pin between the connectors so I just used the pins I could plug into.

Q: Now I'm really convinced you have some serious learning deficiency because you "fixed" the code by using interrupt 3, but now you've skipped interrupts 1 and 2. What gives?
A: Okay, so I finally got the correct connectors and decided, for consistency, to use interrupts 3 through 6 because they all behave the same way (i.e., they're each inherently sensitive to both types of edges without extra programming). I also thought that some teams might want to use the encoder code that I wrote, which works better when the interrupt input is sensitive to only one type of edge, like interrupts 1 and 2 are.

Q: I can't find the function user_routines_fast( ) in the source code. Where is it?
A: It was an error in the documentation that should have read "user_routines_fast.c / InterruptHandlerLow()". The documentation within the source code has been updated with this change.

Q: Who are Bryan, Gail, Patricia and Patrick?
A: My oldest son, my wife, my mom and my youngest son.

Q: We know our beacon and infrared sensors are working correctly and connected to the correct pins on the robot controllers, but the servo motors never stop rotating even though the beacon is well within the view of the sensors. Have any ideas why?
A: If you don't put a switch on digital input 7 of the FRC-RC to select the type of beacon you want to track, it defaults to beacon type 1, which is present on PWM output 2 of the EDU-RC. If you've only built one of the beacon transmitters, make sure it's plugged into PWM output 2 on the EDU-RC. Because you'll need it for the competition, I'd suggest building the switch too.

Q: How do you select the type of beacon the trackers are to follow?
A: Wire a switch to digital input 7 of the FRC-RC. If the tracking software reads a logic 0 (gnd) on this digital input, it will track beacon type-0. Conversely, a logic 1 (+5v) on this digital input will cause the software to track beacon type-1.

Q: The servos don't rotate and the robot just spins in circles. What are we doing wrong?
A: It sounds like you're using the code in navigate.zip. The code in navigate.c centers the servos, blindly drives the 'bot away from the diamond plate several inches, and then starts a counter-clockwise turn-in-place until the beacon comes into view of one of the sensors. Only then do the servos start tracking and the 'bot drives toward the beacon. The turn-in-place is done to ensure that the beacon would be well within the servos range of travel before they were allowed to track. This sounds like the behavior you're seeing. If all you want to do is try the trackers, upload tracker.hex (found in frc_tracker.zip) instead of navigate.hex.

Q: We know our beacon and infrared sensors are working, the servo motors are plugged into PWM outputs 1 and 2, but they don't rotate. Have any ideas why?
A: Yes, to power servo motors, you need to attach a 7.2 volt battery to the FRC-RCs battery connector.

Q: Okay, where can we get the 7.2 volt battery?
A: You can purchase a battery from Innovation First or build your own from a 7.2 volt rechargeable battery that can be found at many hobby stores. If you choose the latter solution, you'll need to purchase a new connector housing (P/N A1411-ND) and female contacts (P/N A25562-ND) from Digi-Key. BTW, if you'd like to build a battery extension cable, Digi-Key has the mating connector housing (P/N A1410-ND) and male contacts (P/N A25561-ND) too.

Q: Which connectors did you use to connect to the sensors?
A: Amp connector housing P/N 87499-5 and female contact P/N 102548-6. Digi-Key has 'em. Search on P/N A3012-ND for the connector housing and P/N A25979-ND for the contacts. If you decide to build cables using these connectors, make sure you have a good set of needle-nose pliers for crimping. I also recommend a very small dab of solder for a good connection. 26 gauge wire works pretty well too.

Q: Which connectors did you use to connect to the robot controller?
A: If you really, really want to build your own cables and haven't consumed any caffeine in the last week, use Amp connector housing P/N 530554-2 and female contact P/N 530553-7. Digi-Key has 'em. Search on P/N 530554-2-ND for the connector housing and P/N 530553-5-ND for the contacts. If you decide to build cables using this connector, make sure you have a good set of needle-nose pliers for crimping. I also recommend a very small dab of solder for a good connection. Though these connectors are less robust and harder to use than the connectors above, I think they'll also connect to the sensors.

Q: Geez, this FAQ is lame 'cause my question isn't answered.
A: I'm not a mind reader, so e-mail the question to me and I'll try to answer it

Q: What's the deal with Janet Jackson?
A: Beats me. I do know one thing: Every engineer I know purposely avoids punching holes in their body with sharp objects.

Q: So, how many times have you typed the word "infrared" since January 10th?
A: Shouldn't you be building a 'bot?

Last Update: 11/7/2004 at 10:30 AM PST
Copyright ©2003-2004 R. Kevin Watson