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:

  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?

Views: 4654

Comment by G Bulmer on July 29, 2008 at 11:57am
There was a neat technique explained in a recent Scientific American on Robotics (May 2008, "An Army of Small Robots", by R Grabowski, L E Navarro-Serment and P K Khosla, This looks like a plausible reference: http://portal.acm.org/citation.cfm?id=591812)

They used a combination of ultrasonics and wireless (in your case wireless is IR). They rely on the different propagation speed of sound and light. This may be too complex and costly for your purposes , but I'll recount it anyway - it may inspire a better approach.

The idea is to simultaneously 'shout' with sound and IR, and the propagation delay at the receivers between sound and light gives a measure of distance. I believe the rise time on IR is way under 1 microsecond, so it is at the limits of an Arduino timer (using IrDA may be an easy path for prototyping).

If the beacons could detect and time the ultrasonic sample to 10KHz (4 cycles), it'd give roughly 277 metres/second/10,000 = 0.027 metres resolution (about an inch). At a more believable 2KHz, it'd be 5 inches. Each beacon reports (over IR) with the time (distance) between the sound and light.

This would give the blimps distance from each beacon, which is probably a good start. By combining this with unique, per beacon IR ID's the blimp could work out where to go by moving a few feet and shouting again.

But, by co-ordinating the beacons to do the same sound+light 'shouting' trick, they could report (over IR) their relative distances from each other too and you have a bunch of distances between the beacons, so you have a pretty good map of the whole layout. (the beacons don't need to be sampled often as they aren't moving :-)

I haven't thought this through adequately, but I think some of the errors/delays may be determined (consistently) by the electronics/hardware, and hence could be accounted for during an initial setup, so you may be able to get much closer to the 1 inch resolution.

As I said, this is regurgitated Scientific American, so please check it your self. Also it may be too costly to add ultrasonic transducers (though I see some for a $/pair at eBay). Or they may have a patent out. But it might inspire a better solution :-)
Comment by G Bulmer on July 29, 2008 at 12:18pm
Ooops - forgot to add ...

An approach to common bus arbitration is solved by CAN bus, and is described here:
http://en.wikipedia.org/wiki/Controller_Area_Network
look a the Technology heading.

I have *not* used with this protocol, but I have noticed most micro-controller families include CAN bus interfaces, so it may turn out to be relatively cheap and simple to implement.

Your common medium is IR and not a shared wire, but I think the principles still hold. It would need an IR emitter and sensor in every beacon so that they can detect when something 'more dominant' is broadcasting, but that should be feasible with a suitable mechanical arrangement of LEDs and sensors.

There is still the problem of allocating unique ID's to the beacons, but that could be set up once and stored in EEPROM; e.g. introduce each sensor to the blimp's controller in 'teach' mode, and the blimp controller hands out ID's one at a time.

By allocating unique ID's to blimps too, you could have more than one in a room competing (and hence you sell many more blimps :-).

3D Robotics
Comment by Chris Anderson on July 29, 2008 at 12:21pm
Thanks for the suggestion. I was hoping to have a passive IR package onboard the blimp, but perhaps the merits of the method you describe make it worth having both IR receivers and transmitters onboard. But we've run out of I/O pins on the Arduino, so the transmitters would have to be always on, which could create problems of interference with the receivers (since we can't synchronize them out of phase) and power consumption issues.

3D Robotics
Comment by Chris Anderson on July 29, 2008 at 12:24pm
And as for your earlier suggestion of sound vs light velocity, that's brilliant. I just wonder if we'd be able to tell the difference between direct prorogation and reflected signals off walls, floor etc.
Comment by G Bulmer on July 29, 2008 at 12:49pm
I assume you're concerned about telling the difference between direct sound and a reflection of a wall?
It is probably a combination of techniques, including, at least:
1. If only one device at a time shouts, and they leave a big gap every receiver knows that there is only one 'shout' and any secondary signal is an echo. This may happen during an initial track set up/initialisation. The blimp or a central controller takes charge and makes everything obey the rules.
2. During this initialisation, every beacon will hear echo's, and so can measure delay between shout and echo, so they may be able to agree on a minimum repeat period between shouts to ensure no echo falls into the shout 'window'. This relies on beacons being a reasonable distance from walls, and so may be too constrained to be the primary or only approach. A clever approach may reduce the impact of echo's by remembering the time delay between shouts and echo's during set up so that fixed beacons can filter echoes out by timing when the signal seems to coincide with an echo. I'd have to think more about that.

3. A modulated 'shout' (i.e. includes a little piece of ID at the end of the shout) could be recognised as an echo (you hear the same thing twice). I think "Hello, hello, ..." is different enough from "Tom, ... Fred" :-)

3D Robotics
Comment by Chris Anderson on July 29, 2008 at 1:12pm
Yes, that's what I meant. I think your suggestion would probably work well for the ultrasonic side of the equation, but the IR spectrum is so noisy that we've found it very hard to tell the difference between signal, reflected signal, and background noise. Basically it's all we can do to say which of the four IR sensors seems to have the highest s/n ratio. If we put data in the signal (like unique ID) we can read it, but then we lose the ability to tell where it's coming from. Heisenberg uncertainty principle ;-).

I think that you're right that time-division multiplexing, sequenced by a central controller, is the way to go. We'll just have to try a few of these techniques in the real world to see which works best.
Comment by G Bulmer on July 29, 2008 at 2:32pm
Testing in real conditions beats theories to a pulp. Oh, if only politicians realised this :-)

I've had a further thought. I am no expert so I apologise for consuming your valuable time if this has already been considered and thrown out.

In 'maze-solving' robot mice, some effort is put into shielding sensors from IR noise. This is often just a mechanical 'shade' or tube to reduce noise from overhead.

Have you been able to build something that helps, or is it just too difficult when the orientation of the blimp changes so much? I'm wondering if a set of shades (or light baffles) would isolate each sensor more strongly so that the noise is reduced, and the signal strength from reflected beacons is reduced dramatically, it may help to find the signal among the noise.

One approach may be to use polarised filters in front of the detectors and adjust it to reduce reflected IR noise, so line of sight signals are relatively much stronger. This might also reduce some of the background noise. When I was (much) younger, polarised plastic sheet was pretty cheap, and the sensors only need pieces a few millimeters in diameter to shield them, so that could be a low cost experiment to try.
Comment by Nick Wagner on September 25, 2008 at 4:36pm
Speaking of the beacons... Have you made your own yet? I know its probably a minor concern at this point, but I was designing a 555 timer based beacon in async mode but I've not decided on a good duty cycle which would send a recordable pulse as well as allow enough time for the LED to cool off. Any ideas on how much current we need to run through a standard 5mm IR led to get the distance we need or how long the pulse needs to be, to be recorded?
Comment by bGatti on September 25, 2008 at 9:23pm
The Company ITT had a similar problem, They make a wireless security system;
Each beacon transmits their id several times with a delay based on their ID. Sometimes they collide, but the delay separates them.

You might try to:
Send a brief ID on frequency, followed by a series of pulses increasingly off-frequency. The cut-off filter in each IR receiver will cause the system to lose sensitivity as the function of frequency excursion. The number of pings from each detector can be used to vector the signal.

This permits very rapid signal acquisition, and so permits sparse signalling.
You might also consider diffusing the detectors so there is some overlap in the field of view. That overlap will allow for rational vectors, in which the signal strength of adjacent detectors can be used to determine the vector with a higher degree of specificity than just the four corners.

Good luck
Comment by HugePanic on September 25, 2008 at 11:35pm
one question:

is the idea fixed to use 4 ground beacons??

or do you just need some procedure for navigation???

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service