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?
Comments
So even if we used Morse Code, we'd only be getting ID. We wouldn't be able to also get direction. (For those of you who were physics majors, this is like Heisenberg's Uncertainty Principle: you can get ID or direction, but not both at the same time).
The FFT idea is one that we've also been toying with, but it's been a long time since I programmed one and I wasn't sure the ATmega could handle it. Good to know it can! I think that, being intrinsically analog and thus a mix of signal and noise, may be able to handle direction + ID at the same time and is well worth considering.
Jack, blimps are a much easier test platform for aerial robotics: intrinsically autonomous, rapid real-world test cycles, impossible to hurt regardless of failure. The blimps are just 52" and any living room, even just 15 or 20' square, is big enough. The envelopes are designed for $30 indoor toys.
Our IR receiver circuit schematic is here (at bottom).
Do you have the circuit for the beacon posted anywhere ?
By the way, what you're basically looking for is a way to modulate the IR data. There actually are many modulation options for digital data -
http://en.wikipedia.org/wiki/Modulation
and some are pretty exotic.
Give each beacon a unique pulse frequency (a pure sine wave is easiest), fourier transform the input from the IR receiver, and look for the peak value, this will correspond to the beacon you're looking at. Best of all it won't matter if the IR receiver can see two beacons, the fourier transforms sum, and you'll see two big peaks.
Best of all an ATMega can handle Fast Fourier Transforms!
Refs: http://elm-chan.org/works/akilcd/report_e.html - a spectrum analyser using FFT
http://en.wikipedia.org/wiki/Fast_Fourier_transform
http://en.wikipedia.org/wiki/Fourier_transform