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
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 :-).
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 :-)
Place the detector sensor facing forward nose first on the blimp
First command to blimp is rotate about its own axis recording the signals receceived
Second rotate until receiving the coded beacon required
Will need the front facing detector to consist of two extra detectors offset by a few degrees to be able to home on the beacon
to offset bounced signals record the signals received with the same code noting the stronget as valid
stop rotating when facing the stong signal
nav using the offset beacons to control drift
this was used in a type of homing missile in the 70s
See the workings of the sidewinder missile and the gun sight helmet used in the Rooivolk helicopter
I assume this method would indeed require a central beacon scheduling microprocessor to avoid different beacons transmitting at the same time.
Thanks very much--that's really helpful. The question is whether we'll still be able to determine direction (highest s/n ratio) if we're modulating with the intention of actually reading the data, as you suggest. We've found the two requirements to be in opposition.
This (scroll down) is the schematic for the Pololu IR transceiver, which we're using as a test beacon. If we make our own, we'll probably use an Arduino rather than a PIC, and we would only need the transmitting bits (IR LEDs), not the receivers,
I presume you mean 200 samples/sec, not 200k. Yes?
-
1
-
2
-
3
-
4
of 4 Next