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?
-
Comment by Frank Cates on June 20, 2008 at 12:42pm
-
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.
-
Comment by Howard Gordon on June 20, 2008 at 2:58pm -
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.
-
Comment by Alec on June 20, 2008 at 3:05pm -
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
-
Comment by Howard Gordon on June 20, 2008 at 3:16pm
-
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.
-
Comment by Jack Crossfire on June 20, 2008 at 5:11pm -
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.
-
Comment by Howard Gordon on June 20, 2008 at 5:20pm
-
Because a blimp will inflict a lot less property and bodily damage indoors than a rotorcraft.
-
3D Robotics Comment by Chris Anderson on June 20, 2008 at 6:06pm -
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).
-
Comment by Alec on 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).
-
3D Robotics Comment by Chris Anderson on June 20, 2008 at 9:12pm -
Alec,
I presume you mean 200 samples/sec, not 200k. Yes?
-
Comment by Genesis Factor on 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...
Top Discussions
Groups
-
ArduBoat User Group
255 members
-
Indian DIY Drones User G…
54 members
-
ArduCopter Italian Group
201 members
© 2019 Created by Chris Anderson.
Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones