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
1. Ground Beacon will be place up on the wall.
2. Blimp transmitting signal to the Ground Beacon and the RSSI will determine the approximate distance between the blimp and the Ground Beacon
3. A triangular distance measurement will be obtain, using the hypotenuse length to determine the distance
4. The higher the RSSI, it means the blimp is nearer.
Would this method work?? We are not able to use the timer method as it is too simple. Any advise to this suggestion would be much appreciated. Thanks!
Place an IR transmitter ( IR strobe using CAT3224, max forward voltage accommodation 4.2v ) on the Blimp. This strobes every, say, 1 minute. No coding, just a simple flash.
Each ground beacon will transmit and receive. Transmission will be triggered by detecting the Blimp mounted strobe but will be delayed by a settable (e.g. by switches or simple jumpers) period.
The strobe from the Blimp triggers all beacons, each of which will respond with a simple non-ID coded reply for a brief period after the set delay. The beacon's delay times are set so that the transmission periods (constant for all beacons) are non-overlapping and with dead-time between them.
An IR receiver on the Blimp will detect transmissions from the beacons as it does now but only listens within a given time-slot.
As an example then:
The Blimp has reached waypoint 8 and will now search for waypoint (beacon) 9.
The Blimp strobe fires.
All beacons receive the Blimp transmission and start their timeout delay.
The beacon for waypoint 9 transmits in the ninth time slot.
The Blimp receiver listens during time-slot 9 and identifies the direction of beacon 9.
etc ...
We don't need highly accurate or synchronised clocks on either the beacons or the Blimp, just a simple delay.
The Blimp only detects one beacon at a time so no need for complex discrimination etc.
Ultrasound propagates a bit like the light from an electric torch- not very focussed and only kind of directional. But you can time it to a whisker. It moves at a SNAIL'S PACE in electronic terms. Using the ceiling as a kind of ionosphere would I think give a beacon quite a useful range regardless of the direction of the blimp, for optimal results you would want the blimp flying as near to the floor as is consistant with not bumping into the furniture.
Ultrasound propagates best through air at 38 kHz, the same frequency as your IR modulation. You would have to modify your beacon to do a 'ping' to an ultrasound transducer. You probably wouldn't need to use a transistor even. Just an ultrasound transducer; they work as transmitters or receivers.
I'm assuming the beacon runs off a microcontroller so that just means writing a bit of code to do a 38 KHz pulse on an unused output pin. You can check if it's working by connecting another transducer to an oscilloscope. You won't need an amplifier or anything. Just the transducer & two bits of wire.
You would need to get your beacon to do some kind of unique IR pulse which means 'sending ping now'. Then you would need to write a ping-detecting & timing routine for your blimp which would give it an exact (triangular) distance from the ultrasound transmitter on the floor.
If you got that to work you could add a second ultrasound transmitter to another pin of your beacon microcontroller; then it would be necessary to devise another IR pulse which would mean 'sending ping on the other ultrasound transmitter now'.
You now have one IR beacon with two ultrasound beacons attached to it by two lengths of wire. Assuming you place the ultrasound beacons a known distanca apart (say about ten feet) this should give your blimp its exact position anywhere it is withinn range of both beacons.
Ultrasound is very easy to work with. Much easier than you would think.
This way, if you want to code in a course or map of the beacons, you could optimise the blimp transmits towards the beacons of choice which would also save on a number of resources.
You might look for N20's that are wound for higher voltage. Based on what I saw in your video, the motors are running faster (and therefore drawing more current) than you really need for a blimp this size.
Also, I hadn't noticed before that you're using 56kHz IR detectors. I'm in process of redesigning the SRV-1 robot controller to return to using IR instead of the lasers (original version of the SRV-1 used Vishay 36kHz IR parts), and had planned to use 38kHz parts, but it might be cool if the robots could function as moving beacons for your blimps, so I'll look seriously at using 56kHz.
BTW, N20 motors are in a lot of toys, including toy blimps. Basically any small motor will do and you can balance the thrust with the other one in the code.
Great progress on IR stuff. We can remote control the blimp using the IR remote and software is written to do this. Tests were made and we can consistently control the blimp to a distance of four meters in any direction. Limited control goes out to six meters. Unfortunately we burned out one of the motors, so the video just shows one motor spinning up and down and the servo vectoring. Students will be searching the LA basin looking for N20 motors this weekend.
We have made good progress on the multiple beacons. Software is written to decode the IR stream for a universal remote. We can cycle through the 4 sensors and discriminate between two remotes emitting different codes and which sensor is picking up which code. There is a LOT of overhead to do this right now, so we are only updating the motors and servos at 15Hz. We are still testing, but you can see our latest progress at:
mtsacflight.blogspot.com
Next up is to navigate first to one remote transmitting one code while the second is transmitting a different code. Once it reaches the first remote, switch to navigating to the second remote and then repeat. (back and forth. I hope that makes sense.)
-
1
-
2
-
3
-
4
-
5
of 5 Next