|You are here: RoboFlag Main Page > Course Resources > Technical Information > Infrared Robot Beacon|
Infrared Robot Beacon
The infrared robot beacon is a critical part of the RoboFlag project and is one of the most important aspect of the competition. This document outlines the design considerations involved with the PIC-based infrared robot beacon specification, and explains how you would design and build a beacon.
Each beacon consists of multiple emitters (an encoder chip and LEDs) and detectors (detectors and decoder chips) connected to a small microcontroller. The beacons work within line-of-sight, don't detect their own signal, don't interfere with most commercially available IR navigation sensors, and transmit up to four bits of data to other beacons.
This document is broken down into the following sections:
Introduction and Design Objectives
One of the most challenging aspects of the RoboFlag project is the detection of other robots.
It would be extremely difficult for robots to detect each other without active communication. Sure, a defending robot could stay still and use a motion detector to 'watch' the surroundings, but who's to say that the other team's offensive robot couldn't just move slowly? Other detection methods like vision systems, heat detectors, and etc, would be much too difficult to implement for this course.
So each robot needs to emit a signal - to actively broadcast its
location - and each robot needs to be able to detect this signal.
The design objectives for the beacon are as follows:
Infrared Light & Associated Problems
Infrared radiation lies between the visible and microwave portions of
the electromagnetic spectrum. We'll be using a detector that has peak
sensitivity at a wavelength of 940nm, so we'll use IR LEDs that emit at
However, there are a number of problems with an infrared signal:
It's important to use modulated IR light to avoid interference from other IR sensors and from lights, the sun, etc. For example, if we were using plain infrared light (ie: we emitted light at 940nm), it would be very difficult to determine the difference between another robot or a desk lamp. Modulated IR is commonly used in IR distance sensors.
To avoid conflicting with IR navigation sensors, we will be modulating
our infrared signal at 38.0kHz. Since we're interfacing with digital
devices (and we're not doing any mixing, filtering, etc), we'll use a
square-wave signal. So our modulated IR signal would look something like
There's still the problem of infrared signals bouncing off the arena
walls, which is difficult to address. If we use a material that doesn't
reflect infrared light then the infrared distance sensors won't work.
The solution? There isn't really one. Even slowly moving robots wouldn't
see an infrared reflection from another robot for very long, so it won't
be too bad.
Robots which do see the reflection of another robot's beacon can obviously use this to their advantage. The scenario above shows the robot on the right seeing the signal from the robot on the left (and vice versa). Remember that both robots won't be able to tell whether or not the other robot is in the original location, or the mirrored location (shown in red).
The Technical Specification
The technical specification is based around the design objectives of the
The RoboTag project (2000/2001 academic year) used a custom-designed encoding/decoding scheme that was fast, but very complicated. It wasn't possible to quickly and accurately detect which other robot you had detected. This solution is documented here.
This year, it was important that the beacons identify which robot a particular beacon signal belongs to. In order to achieve this goal, the beacon specification has been re-designed to use commercially available encoder and decoder ICs. These chips unfortunately increase the detection time to a whopping maximum time of 1.7 seconds.
Holtek makes a line of ICs that include the HT12A encoder and HT12D decoder. Understanding how these ICs work, and how they interface with the detectors and emitters, is critical for understanding how the infrared robot beacon works.
The Panasonic PNA4612M infrared detection module is a complex device that captures and returns the modulation signal transmitted with a fixed (38kHz) carrier signal. It's similar to last year's LITEON module. The operation of the PNA4612M is shown below.
The Holtek HT12D decoder plugs directly into the Panadonic module, shown above, and looks for three consecutive "words" before latching the data stored in the words. The structure of the words is shown below, and consists of 12 blank 'header' bits, one synchronization cycle, eight address bits, and four data bits. Each bit is represented by three clock cycles, as shown.
Note that one decoder is required for each detector.
The encoder and decoder have an internal clock cycle of approximately 2.4kHz, so each cycle takes 416us, and each word (73 cycles) requires 30.4ms. Seven words (explained below) requires 213ms.
So we need to ensure at least three consecutive words get from the transmitting beacon to the receiving beacon. If we weren't operating in such short distances with the possibilty of all four robots being within sight of each other, our task would be simple. The problem is as follows: if all four robots transmit their "word" (essentially their ID) in the same space in the same time, they won't be able to detect each other at all! The detectors wouldn't see the correct timing sequence, because there would definitely not be a 14.9ms blank 'header' period.
Each robot needs to take turns transmitting its signal and 'listening' for signals from other robots. Because these robots aren't synchronized, this problem is more complicated - who knows when to start transmitting and stop listening?
Due to reflections, it's also pretty clear that when the beacon is transmitting, it won't reliably detect other beacons that are also transmitting! (ie: the beacon can't 'talk' and 'listen' at the same time) We have a real timing problem now.
The timing solution (shown below) works if you consider the following worst-case scenario: assume all four robots are within line-of-sight of each other. Assume that, by luck, the first collection of 'words' are transmitted at the same time and none of the robots detect each other. By changing the time between this first burst and a second burst (ie: each robot waits a different amount of time before sending out another collection of 'words'), we can ensure that each robot will detect ALL the others, with a worst-case detection time of 1.7s.
This can be shown in a chart form as follows:
The coloured blocks indicate when the particular robot is transmitting, and the white blocks indicate when the robot is 'looking'.
The above chart shows each robot transmitting from 0 to 213ms, then 'looking' for an amount of time before transmitting another 213ms pulse. This allows us to have four robots in the same area that will ALWAYS detect each other within 1.7s.
But there's another problem. Because we're guaranteed not to have synchronization, we could run into the timing problem shown below, when robots #2 and #3 are perfectly unsynchronized.
But because the HT12D decoder requires three consecutive words, we must ensure that the information transmitted in "a" or "b", shown above, includes those three required consecutive words. It's clear, then, that we must transmit seven consecutive words in each "block" shown in the timing diagram. In the almost-perfect overlap shown above, the space shown in "a" might contain 3.0 words, and the space in "b" might contain 4.0 words. Time slice "a" may or may not trigger the decoder to latch the data values, but the information received in time slice "b" definitely will.
SO: now it's clear why we need 1.7 seconds to have four robots transmitting seven-word "blocks" of data. The transmission of this information is detailed below.
The Holtek HT12A encoder can easily be connected to the high-power infrared LEDs specified below. This encoder chip transmits an encoded signal whenever one of the four data lines is pulled to a logic zero. The encoder will always finish transmitting the "word" after the data lines return to logic one, so in order to transmit seven words, we must hold the data lines low for the duration of 6.5 words, or approximately 198ms.
The Lumex OED-EL-1L2 infrared LED is a high-power, wide-angle LED that transmits at our desired wavelength of 940nm. This device has a forward voltage drop of 1.7V, can pass 100mA of continuous current, and has a 60-degree beam width.
Address and Data Lines
Both the HT12A encoder and the HT12D decoder have an 8-bit address - this is so multiple devices can transmit to each other without crossing wires, so to speak. We will use the common address 11001100, or: AD0=AD1=0 and AD4=AD5=0, and AD2=AD3=AD6=AD7 floating high.
The encoder has four data lines, D8-D11, and the decoder has four corresponding data lines, D8-D11. The decoder also has a "valid transmission" output pin, VT, which should be sampled to detect when three consecutive (and valid) words have been received.
These four data lines contain the bits of information that can be passed back and forth between the robots. For our purposes, we'll use the 3-bit robot id numbers supplied by the course coordinator, and we'll discard the fourth bit (D11).
ie: if your robot ID is 6, you'll use the binary number 110. This translates to D8=0, D9=D10 floating high. Remember that your encoder will ONLY transmit when one of the input data pins is pulled low.
So the technical specification of the beacon is as follows:
An Example Solution
My proof-of-concept solution features a single detector and single emitter. You will obviously want to extend my work to handle multiple IR LEDs (additional hardware), multiple receivers (additional hardware and software), and a microcontroller. You should consider using a fast (20MHz) PIC with lots of pins to interface with more than one detector.
The detector schematic, below, shows how the PNA4612M plugs almost directly into the HT12D decoder. A 3904 is used to invert the logic pulses from the Panasonic detector. Note that the address is set to 11001100, as specified above, and that the fourth data output (D11) is left unconnected. The three data bits with the detected robot's ID and the valid transmission pin should connect through to your PIC or other microcontroller.
The transmitter schematic, below, shows how the HT12A encoder connects via the three input data pins (D8-D10) to your PIC or other microcontroller. This schematic shows how you can use a high-power darlington pair (I suggest the ZTX603) to drive a number of IR LEDs in series. Calculate the resistor value, R, with the diode's forward current in mind: you'll probably want to limit yourself to 100mA for the specified LEDs.
You will need to interface a PIC (or other microcontroller) to the emitter and detector circuits shown above. Your PIC will need to calculate the timing required for your particular robot (you MUST have the option of changing your transmission slot), and signals the encoder to transmit during the appropriate timing slot.
While transmitting, your PIC should ignore the data received from your detectors (to avoid detecting your own signal bouncing off walls). Once your transmission is complete, the PIC will need to resume 'listening' to the detectors and notifying the HandyBoard as to what robots are in the viscinity.
Depending on how complicated your design is, you may want to think about a number of options:
Miscellaneous Advice and Recommended Parts
Making the encoder/decoder work is not difficult. The range requirements are 12+ feet, but you should design the maximum range you can achieve. To help, I've put together the following recommendations.
Selecting the best parts for the IR beacon is important. If you're using an IR LED that doesn't transmit at 940nm, for example, the PNA4612M receiver module won't work as well.
The parts I've used in my lab tests (and which I recommend), are:
Holmate Technology Corp.
48531 Warm Springs Boulevard, Suite 413, Fremont, CA 94539
The shipping costs are considerable from Holmate, so I suggest you coordinate a group-buy. You will need one HT12D per detector, and one HT12A per emitter.