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
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" :-)
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
Here's code I wrote for the ARM7 with decodes an 11-bit pattern send by a set of IR emitters. In this case, all beacons transmit at the same frequency, but the bit patterns are different, which is someone more complicated than just using different pulse widths. You can see this in operation with 4 robots, where one acts as a beacon and the other 3 try to locate it.
4bot-beacon.mov
/*****************************************************************************
*
* Description:
* read IR - return direction counts in upper 16 bits, data in lower 8 bits
*
****************************************************************************/
unsigned int
listenIR(unsigned int max_wait)
{
unsigned int ix, jx, kx, t0, count;
unsigned int nleft, nright, nforward, nback;
unsigned int start[11];
t0 = TIMER0_TC;
jx = 0; // accumulator for received bits
kx = 0; // bit counter - 11 bits per character
nleft = 0; // nleft, nright, nforward, nback won't exceed 11
nright = 0;
nforward = 0;
nback = 0;
count = 0;
for (ix=0; ix<11; ix++)
start[ix] = 0;
while (((TIMER0_TC - t0) < max_wait) && (kx < 11))
{
count++;
delayUs(28);
ix = IOPIN0 & IR_RECV;
if (ix != IR_RECV)
{
start[kx] = count;
if ((ix & IR_R_FORWARD) == 0)
nforward++;
if ((ix & IR_R_LEFT) == 0)
nleft++;
if ((ix & IR_R_BACK) == 0)
nback++;
if ((ix & IR_R_RIGHT) == 0)
nright++;
while ((IOPIN0 & IR_RECV) != IR_RECV)
{
count++;
delayUs(28);
}
kx++;
}
}
jx = 0x00000400; // highest bit is always set, since that's how we located the signal
t0 = start[0]; // note: there are 20 * 28usec pulse periods in each bit
for (ix=1; ix
{
start[ix] -= t0;
//printNumber(10, 6, FALSE, ' ', start[ix]);
if ((start[ix] > 30) && (start[ix] < 220))
jx |= 0x00000400 >> ((start[ix]+10)/20);
}
jx |= (nforward << 28) | (nleft << 24) | (nback << 20) | (nright << 16);
return jx;
}
-
1
-
2
-
3
-
4
-
5
of 5 Next