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
It also occurs to me that if we used 38Khz IR modules, we could use a standard TV remote as a remote control for the blimp. This would save the cost of the RF gear. I converted a standard RC car to be controlled using an IR remote as described briefly here. http://profmason.com/?p=392 (Near the bottom)
is the idea fixed to use 4 ground beacons??
or do you just need some procedure for navigation???
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.
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.
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" :-)
-
1
-
2
-
3
-
4
of 4 Next