How can we make IR beacons with unique IDs for Blimpduino?

Jordi and I are slightly stuck at the last part of our Blimpduino project. We've got the blimp itself all sorted, from electronics to mechanical assembly, and are ready to move into mass production on that. We intend to ship it with a single ground-based IR beacon, around which it can navigate, and that's done, too. But ultimately, we want it to be able to navigate to multiple beacons, and that's where we've run into a problem. Let me describe the issue, and maybe some of you will have some ideas.

To keep Blimpduino as cheap and simple as possible, it navigates by looking for signals from a ground-based IR beacons in any one of four directions. There are four IR detectors (N,S,E,W) on the blimp and the ground-based beacons are nothing more than an IR LED transmitting random 1s and 0s at 56KHZ. This being IR, they bounce all over the room and there is loads of IR noise from other sources, but the IR receiver that records the highest number of 1s (highest signal-to-noise ratio) is considered the direction that the beacon is transmitting directly from and we steer accordingly. (This is also the way the Pololu IR beacon/transceiver pairs work)

That's easy for one beacon. But when we want to introduce multiple beacons, each with a unique ID, it gets more complicated. We can't transmit at different light frequencies, because we'd need to add matching IR receivers on the blimp for each beacon we added. We can't use TV remote control codes, because then we can't tell where they're coming from (it's the ratio of signal to noise that tells us direction, but the codes are all signal and work as well if they're bouncing off a wall as when they're aimed directly).

Our instinct is to have a central beacon controller (another Arduino--see diagram above) and sequence them so that you'd be able to tell which beacon is transmitting by when in the beacon sequence you got the signal. But that requires us to synchronize the blimp and the beacons to a common clock, and we're debating how to do that.

My proposal is to do the following, 10 times a second:

  1. For the first 1-50ms in each cycle: all beacons go on for 30ms, then all off for 20ms ("clock sync pulse").
  2. 50-60ms: Beacon 1 on
  3. 60-70ms: Beacon 2 on
  4. 70-80ms: Beacon 3 on
  5. 80-90ms: Beacon 4 on
  6. 90-100ms: Beacon 5 on
  7. Repeat...

The beacon hub controller would just schedule that sequence. The blimp, meanwhile, would have to detect both the direction of signals and how long they're on. If they're on for 30ms and then off for 20ms, that's the start of a cycle. Then depending on when in the cycle it detects the next signals, it knows which beacon that is.

Jordi's not convinced this will work, and thinks we'll need an RF link to communicate between blimp and beacons, which strikes me as expensive, complicated and unnecessary. What do you guys think?

Is there a better way to have a blimp distinguish between different IR beacons?

Views: 4654

Comment by Howard Gordon on June 21, 2008 at 6:14am
Chris -

I was looking for the IR beacon circuit, not the receiver, just to consider how it might be easily modified.

There are some interesting suggestions above. They need to take into consideration that the underlying modulation frequency for the IR emitters of 36kHz (or 38kHz) is fixed (the IR receivers need this to filter out background noise), so any signaling schemes will be on top of that fixed frequency. In any case, transmitting different burst widths from each beacon will probably be easiest to decode.
Comment by Alec on June 21, 2008 at 11:30am
oops, yes.

3D Robotics
Comment by Chris Anderson on June 21, 2008 at 12:24pm
Howard,

This (scroll down) is the schematic for the Pololu IR transceiver, which we're using as a test beacon. If we make our own, we'll probably use an Arduino rather than a PIC, and we would only need the transmitting bits (IR LEDs), not the receivers,
Comment by Howard Gordon on June 21, 2008 at 1:50pm
You'll have a programmable processor in any case, so you can generate any waveform you want. Once you build the new beacon, I'd suggest using a header block with pins attached to the processor GPIO input for programming the beacon ID - this would be cheaper than a DIP switch block.

In the interim, you should be able to test a beacon ID scheme by cutting the trace from RC5 to Q1 and add a timer circuit (555 or equivalent) and switch to modulate the IR LED output. The timing pattern will ideally produce a relatively short ON pulse and longer OFF pulse to minimize overlap between different beacons. On the receiving side, you won't need anything nearly as complex as an FFT to extract the modulation frequency.

3D Robotics
Comment by Chris Anderson on June 21, 2008 at 2:00pm
Howard,

Thanks very much--that's really helpful. The question is whether we'll still be able to determine direction (highest s/n ratio) if we're modulating with the intention of actually reading the data, as you suggest. We've found the two requirements to be in opposition.
Comment by Howard Gordon on June 21, 2008 at 2:09pm
Right - you'll have to modify your decoding scheme to measure actual pulse widths rather than just counting 1's on each receive channel, since the pulse energy from each beacon will be different. The decoding isn't complicated - I can show you code to do this if you're uncertain, since that's similar to the way we currently decode the Maxbotics ultrasonic module pulses.

3D Robotics
Comment by Chris Anderson on June 21, 2008 at 2:37pm
So even if all four sensors are receiving the data (at differing quality) from a single IR transmitter (because it's bouncing around the room) we'd be able to distinguish which signal is the strongest with this method, along with the ID of the beacon? If so, yes please on the code sample!

I assume this method would indeed require a central beacon scheduling microprocessor to avoid different beacons transmitting at the same time.
Comment by Howard Gordon on June 21, 2008 at 4:07pm
You don't need any scheduling, as long as the interval between beacons bursts is random or the beacon pulse widths are different (just avoid using frequencies which are harmonics).

Here's code I wrote for the ARM7 with decodes an 11-bit pattern send by a set of IR emitters. In this case, all beacons transmit at the same frequency, but the bit patterns are different, which is someone more complicated than just using different pulse widths. You can see this in operation with 4 robots, where one acts as a beacon and the other 3 try to locate it.

4bot-beacon.mov

/*****************************************************************************
*
* Description:
* read IR - return direction counts in upper 16 bits, data in lower 8 bits
*
****************************************************************************/
unsigned int
listenIR(unsigned int max_wait)
{
unsigned int ix, jx, kx, t0, count;
unsigned int nleft, nright, nforward, nback;
unsigned int start[11];

t0 = TIMER0_TC;
jx = 0; // accumulator for received bits
kx = 0; // bit counter - 11 bits per character
nleft = 0; // nleft, nright, nforward, nback won't exceed 11
nright = 0;
nforward = 0;
nback = 0;
count = 0;
for (ix=0; ix<11; ix++)
start[ix] = 0;

while (((TIMER0_TC - t0) < max_wait) && (kx < 11))
{
count++;
delayUs(28);
ix = IOPIN0 & IR_RECV;
if (ix != IR_RECV)
{
start[kx] = count;
if ((ix & IR_R_FORWARD) == 0)
nforward++;
if ((ix & IR_R_LEFT) == 0)
nleft++;
if ((ix & IR_R_BACK) == 0)
nback++;
if ((ix & IR_R_RIGHT) == 0)
nright++;
while ((IOPIN0 & IR_RECV) != IR_RECV)
{
count++;
delayUs(28);
}
kx++;
}
}

jx = 0x00000400; // highest bit is always set, since that's how we located the signal
t0 = start[0]; // note: there are 20 * 28usec pulse periods in each bit
for (ix=1; ix
{
start[ix] -= t0;
//printNumber(10, 6, FALSE, ' ', start[ix]);
if ((start[ix] > 30) && (start[ix] < 220))
jx |= 0x00000400 >> ((start[ix]+10)/20);
}

jx |= (nforward 28) | (nleft 24) | (nback 20) | (nright 16);

return jx;
}

3D Robotics
Comment by Chris Anderson on June 21, 2008 at 5:14pm
Excellent. We'll give it a shot. Many thanks!
Comment by ian powell on June 26, 2008 at 1:02am
First let the beacons have there own code.
Place the detector sensor facing forward nose first on the blimp
First command to blimp is rotate about its own axis recording the signals receceived
Second rotate until receiving the coded beacon required
Will need the front facing detector to consist of two extra detectors offset by a few degrees to be able to home on the beacon

to offset bounced signals record the signals received with the same code noting the stronget as valid

stop rotating when facing the stong signal
nav using the offset beacons to control drift
this was used in a type of homing missile in the 70s
See the workings of the sidewinder missile and the gun sight helmet used in the Rooivolk helicopter

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service