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:

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

why not rotate the IR reciever, using the peaks as a position (like sonar). have the transmitters do a long pulse (like a haf second to a second) and then pulse their ID and then repeat. Its a bit of math and a few algoritms. Use 1 IR sensor to detect these peaks. It should see something like this in a full 360.

_---_--^-__-^-_-^-_____-^---_

Note the 5 peaks. the lower peak is noise in the environment. If it sees one, it should expect that the following detectors sees it in relatively the same place, only shifted in the directtion on the cartesian plane that the blimp is moving or the ID (hopefully). If a peak doens't give an ID over hte lapse of a certain time, it is then decidedly ignored. Once the ID peaks are all identified and the blimp filters out the noise, you should get what you want.

_______*____*___*_______*____

if you save their locations (direction technically, until you get 2 or three readings from different angles, then cross the direction of the peak and the intersection will the be location, though not accurate) on an absolute cartesian plane, and move your blimp around on it, you get to have your ID and your location too. I guess the only things you would need to add is a regular motor with a rotation sensor.

then again, i am not sure of the detection angle and quality of your IR, soooo...yeah...

You need to be a member of diydrones to add comments!

Join diydrones

Comments

3D Robotics

Chris Anderson 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.
Howard Gordon 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

Chris Anderson 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.
Howard Gordon 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

Chris Anderson 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,
Alec June 21, 2008 at 11:30am

oops, yes.
Howard Gordon 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.
Genesis Factor June 20, 2008 at 11:21pm

why not rotate the IR reciever, using the peaks as a position (like sonar). have the transmitters do a long pulse (like a haf second to a second) and then pulse their ID and then repeat. Its a bit of math and a few algoritms. Use 1 IR sensor to detect these peaks. It should see something like this in a full 360.

_---_--^-__-^-_-^-_____-^---_

Note the 5 peaks. the lower peak is noise in the environment. If it sees one, it should expect that the following detectors sees it in relatively the same place, only shifted in the directtion on the cartesian plane that the blimp is moving or the ID (hopefully). If a peak doens't give an ID over hte lapse of a certain time, it is then decidedly ignored. Once the ID peaks are all identified and the blimp filters out the noise, you should get what you want.

_______*____*___*_______*____

if you save their locations (direction technically, until you get 2 or three readings from different angles, then cross the direction of the peak and the intersection will the be location, though not accurate) on an absolute cartesian plane, and move your blimp around on it, you get to have your ID and your location too. I guess the only things you would need to add is a regular motor with a rotation sensor.

then again, i am not sure of the detection angle and quality of your IR, soooo...yeah...
3D Robotics

Chris Anderson June 20, 2008 at 9:12pm

Alec,

I presume you mean 200 samples/sec, not 200k. Yes?
Alec June 20, 2008 at 8:53pm

there is a fixed-point FFT library around somewhere on the internet, apparently giving around 7.6k samples/s. If you modulate your beacons at 100hz, nyquest sampling theory says you'll need 200k samples/s, leaving plenty of spare processing power. I suppose you can assume that the IR noise is white noise, so it'll show up evenly (ish) distributed in the FFT, which will allow you to work with fairly low S/N ratios (5 should be easily enough).

of 5

This reply was deleted.