3D Robotics
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?

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • 3D Robotics
    A: Quick answer to the "morse code" suggestions, which we've considered but don't think will work. The problem is that we need to determine both direction and ID. Since IR bounces all over the place and the background levels are high, the only way to determine direction that we've discovered is to pulse random data and detect the direction with the highest signal-to-noise ratio. We have found no way to both get pure data and direction--it's the ratio of noise that differentiates between direction and reflected signal.

    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).
  • Phase shift keying is how it's done on noisy wireless connections. Wonder how many people have enough indoor space to buy a blimp and if they do have enough space, why someone that wealthy wouldn't be willing to spend more on a full rotorcraft.
  • This may seem more complicated, but is much more reliable and flexible:
    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
  • This may be old school, but can you pulse the beacons? If so, can you pulse them in Morse Code? The numbers 1 through 9 are all done with a set of 5 pulses, either dashes or dots, but always in sets of 5. Your idea for the base pulse and length would be good to identify start and end points, then read a set of 5 pulses and translate to a number between 1 and 9. Potentially up to 9 beacons using that method. You would need to work out a way to 'steer' a receiver on the blimp so it could look at a single beacon at a time. Lots of pitfalls in this approach but maybe the thought will trigger an idea in another direction.
This reply was deleted.