Main Page
|
Course Admin
|
Course Resources
|
Rules & Regulations
|
Team Profiles
|
Photo Gallery
|
Contact Info
 
  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:

  • robots must be able to detect signals from up to 3 other robots
  • robots must be able to detect signals within 1.7 seconds
  • robots must not detect their own signal
  • the signal must contain at least 3 data bits
  • the signal should only work within line-of-sight
  • the signal must be detectable from 3 inches to 12 feet
  • the signal must not interfere with any other sensor
Therefore we can't use RF signals (they would penetrate the arena walls) and visible light signals would interfere with the lights in the room and the
visible flag beacon. An infrared signal is our best bet.



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 940nm.

However, there are a number of problems with an infrared signal:

  • a number of robots are using infrared navigation sensors
  • fluorescent lights, the sun, cameras, etc, emit large amounts of IR
  • infrared signals 'bounce' off surfaces
    • (which is how IR distance sensors work)

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 this:

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 beacon:

  • robots must be able to detect signals from up to 3 other robots
  • robots must be able to detect signals within 1.7 seconds
  • robots must not detect their own signal
  • the signal must contain at least 3 data bits
  • the signal should only work within line-of-sight
  • the signal must be detectable from 3 inches to 12 feet
  • the signal must not interfere with any other sensor
In the previous section we addressed the interference and line-of-sight requirements of the design and concluded that modulated infrared light is the best communication medium for the beacon.

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.


Technical Specification

So the technical specification of the beacon is as follows:

  • consecutively, each beacon must:
    • emit 213ms of modulated infrared light
      • comprised of seven encoded words
        (produced by giving data to the encoder for ~198ms)
      • consisting of 940nm light modulated at ~38.0kHz
      • emitted 360-degrees around the robot
        (minimum of 50% beam power in any direction)
      • must be detectable at 12+ feet with a standard device (50+mA/LED)
    • looks for infrared light from another robot
        (for N blocks of 213ms each, N is assigned by course coordinator)
    • emit 213ms of modulated infrared light (as spec'd above)
    • looks for infrared light from another robot
        (for 6-N blocks of 213ms each)
    • repeat the process



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:

  • running your 3-bit output from each HT12A into a D/A converter, generating an analog signal for each HT12A and connecting them each to an analog input on the HandyBoard
  • connecting the VT of all your HT12A's together in an OR gate, leading the output through to the HandyBoard, and having the HB sample the analog ports (above) every time VT goes high
  • connecting all HT12A outputs to a single PIC, then having that PIC communicate directly to the HandyBoard every time a robot is detected



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.

  • Don't drive the LEDs and the PNA4612M from the same power source, the PNA4612M really doesn't like the power supply fluctuations caused by the high current-drawing LEDs. You can drive the LEDs specified below with 12V and 2A, but it's not required -- a better idea would be to use your motor batteries (whatever the voltage) and aim for 100mA per LED. Calculate the current-limiting resistor, R, shown in the emitter schematic above.

  • Shield the PNA4612M from any overhead fluorescent lights, they'll put out enough IR that some will appear to the PNA4612M to be modulated at your frequency. Remember to shield all around the PNA4612M, even behind and to the sides. The metal casing doesn't completely block IR.

  • Don't let your LEDs shine anywhere near your PNA4612M. Even though I was transmitting and receiving at different times, the LEDs would 'flood' the PNA4612M when transmitting and the device wouldn't recover in time before the LEDs were transmitting again. If you shield the LEDs from the PNA4612M, the operating range increases.

  • Of course, drive the LEDs through transistors, as shown. Make sure your LED power supply can handle the current draw - four collections of LEDs will draw 400mA peak (200mA average).

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:

  • Panasonic 38.0kHz Infrared Receiver Module - PNA4612M (DigiKey: PNA4612M00YB-ND)
    detects the infrared signal, removes the 38kHz carrier, 1 per detector
  • Fairchild Semiconductor NPN Transistor - 2N3904 (DigiKey: 2N3904-ND)
    inverts & amplifies the PNA4612 output, 1 per detector
  • ECS International Ceramic Resonator (455kHz) - ZTB455E (DigiKey: X921-ND)
    provides a clock for the HT12A encoder, 1 per emitter
  • Zetex, Inc NPN Darlington Transistor - ZTX603 (DigiKey: ZTX603-ND)
    drives the IR emitting LEDs, 1 per bank of LEDs in emitter
  • Lumex Opto Infrared LED - OED-EL-1L2 (DigiKey: 67-1001-ND)
    emits infrared light at 940nm, n per bank of LEDs in emitter
You can order these parts from DigiKey, and they'll arrive very quickly and without any fuss. You cannot, however, order the Holtek HT12A encoder and HT12D decoder from DigiKey. You need to contact Holmate and purchase them directly.

Holmate Technology Corp.
48531 Warm Springs Boulevard, Suite 413, Fremont, CA 94539
Tel: 510-252-9880
Fax: 510-252-9885
Website:
http://www.holmate.com

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.


 
Main Page
|
Course Admin
|
Course Resources
|
Rules & Regulations
|
Team Profiles
|
Photo Gallery
|
Contact Info