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).
  • Because a blimp will inflict a lot less property and bodily damage indoors than a rotorcraft.
  • 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.
  • Chris -

    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.
  • 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
  • Similar to what Frank suggests, you can modulate a bit pattern with the LED's. With my robots, I used an 8-bit pattern which allowed me to use the IR link for data transfer. The data is quite noisy, but you can take lots of samples, and will eventually read a clean signal. The basic issue is that you'll have to add some logic to the beacon to generate the bit pattern. Easiest approach is probably to use a simple processor, and set up a jumper header on each beacon in order to program the ID. However, you could use some discrete logic such as a 74LV165 parallel-to-serial shift registerto control the pattern output.
  • 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.