Beacon suggestions

[Jeroen]

Hi,

I am looking for ideas to create a homing beacon for my bot. The problem here is that I have a few requirements that make the commonly used beacons like IR, unusable (I think):

- the terrain is not a flat surface, the difference in height can be 3 foot;
- the beacon does not reside on a fixed point in the terrain;
- it can happen that there are obstacles between the beacon and the bot;

Do you have any suggestions what technology I could apply here for a beacon? A sort of radio beacon looks obvious but this may require a lot of engineering which may be too much for me, and this will not work when in very short distance.

[BeanieBots]

From the most simple (IR LED) to the most complex (camera image recognition) methods that I have come across, all have the same limitation. No signal when sight is lost. Radio is an option but as you have already worked out, it is only effective at longer distances unless EXTREMELY high frequencies are used.
I've never tried it but, but consider using sound. Perhaps an ultrasound unit sending out a continuous stream of pulses. An ultrasound receiver is very directional, so there might be some scope worth exploring. Maybe two microphones could be combined to give direction just like our own ears can tell where a noise is comming from.

Edited by - beaniebots on 1/17/2006 2:11:07 PM

[Bloody-orc]

i agree with Beanybots

use a mic that is vaced up and a cone placed on top of it to send sound in all directions. and for hte bot use 2 or 3(better) microphones on top of it and mesure the sound. it's kinda like human ears but you use ultrasonic sound (you cant use normal cause of the ambiciant sound in the nature, that your bot is probbably going to run in). this works better outdoors not in small rooms cause sound bounces from walls as we all know...

[Technical]

Presume you are outside?
If so two GPS systems could send each other their positions over radio link? You would probably have to move to a more precise system once very close to each other...

http://www.rev-ed.co.uk/docs/flier_connect.pdf

[Jeremy Leach]

Picking up on the GPS idea ... what we're really saying is that if each unit knows their own corrdinates then they can share the data via radio link.

GPS is one way of determining coords.

Is this just 'general' terrain. Or is there a possiblity of putting any sort of grid of markers on the terrain so each unit can identify it's position?

If there were a pair of beacons that each unit could reliably triangulate to, then there'd be another solution.

One idea... How about if you had a low power laser mounted high up (a bit like a satellite!) that scanned the terrain and beamed coordinate information. e.g if beaming to first cell in grid then send code X1Y1. If beaming to adjacent cell send code X2Y1 etc.

The bot has some form of photodiode - in gimbals to keep it vertical, or probably better, a set of photodiodes pointing a number of directions - that can pick up the laser transmission.

Two servos to guide the laser. Would probably need lookup table for the maths in order to point the laser at the grid squares accurately. The spread of the laser beam could be adjusted with a fixed lens.

Could also use some arrangement of spinning disk (s)/ mirrors to project the laser beam.
The corrdinate system could be Polar not XY - it doesn't matter as long as each unit can locate itself.

Sounds a bit sci-fi but actually could work - I think ;-) Plus it might not cost that much.


Edited by - Jeremy Leach on 1/17/2006 3:46:55 PM

[xstamp]

There has been quite a lot of work in the field of biorobotics regarding sound location. For example Barbra Webbs’s simulation of cricket homing techniques. Basically, two microphones are used together with some hardware signal conditioning and software signal processing. Lots of details on Google under biorobotics + sound etc.

[Bloody-orc]

technical may i ask, when can i buy those thing shown in the flyer (like GPS module etc.)?

[BeanieBots]

OOOh..!..
PICAXE.net + GPS + ZBEE = robot that can be SENT anywhere FROM anywhere AND let you know it got there!

[Bloody-orc]

exactly my point!
picaxe to do the positioning and sensors and computer and brain to do something with the info... On Earth "Mars missions": HERE I COME!

[andypro]

If you want to do audio location, I would suggest researching an OWL's ears!! They're fascinating and absolutely incredible. They can determine a 3 dimensional "map" of what's around them with two stationary ears.

In effect, they have one ear "pointing" up and forward, another pointing down and back. The hairs that are in thier ears (actually the feathers around them) also play a large part by attenuating certain directions, relative to the ear. Correlation between the two ears allows the owl to "see" perfectly with jsut it's ears. Nothing complex, all passive, and all fixed.

When an owl actually attacks, the last moment before the strike it closes it's eyes and relys solely on the ability of it's ears and brain to map out everyhitng in front of them, and they jsut plain dont miss!

I've been looking into it, and would really like to incorporate a system similar to this into my robot, but nature is a much better engineer than I. I'm working on it though.

--Andy P

[Haxby]

Technical, I have been connecting GPS modules to picaxes for a while using serin commands. Is there a benefit to using the Xbee board and specified GPS module?

[Technical]

The items awill all be in the www.techsupplies.co.uk store in the next couple of days.

Haxby - the AXE210 Connect pcb just provides an easy way to physically interface to the GPS module, so if you have already build your own system to do that you might as well stick with it! However the recommended GPS module has variable baud rate which makes it easier than some others to interface to the PICAXE.

[Jeremy Leach]

I've been thinking about this, and maybe have a slightly different solution based on using sound. So I'm throwing it in for any comment. I've never tried ultrasound etc, so this is all speculation !

So the problem is : R is a roving robot and B is a beacon. R wants to determine it's distance from B.

My solution:
R and B have internal crystal oscillators of exactly the same frequency. B sends a repeated tone burst signal to R, at exact intervals. R and B both know exactly when the transmissions will occur. As R moves away from B, R receives the transmission later due to the delay of sound through air. This delay is translated into distance . R and B are initially placed together and the distance reading of R is zeroed. Any reflected sounds will arrive at R later than the direct sound between R and B (make interval between transmissions long enough for reflections to subside).

Solution (in practice):
Assume (for sake of explanation) R and B are both based on 28X PICAXEs with 4MHz crystal.

At startup both R and B run the servo command to start generating a background 2.25 ms pulse every 20ms on an output pin.

B, the beacon, has a 555 astable generating 50KHz signal (or maybe a crystal generated 50Khz signal, but I don't think it needs to be exact). B ANDs it's servo pulse with the Astable signal to generate 50kHz bursts, of 2.25ms duration at 20ms intervals. This signal is amplified by an op-amp and drives an Ultrasonic transducer, facing upwards with a smooth cone (as Bloody suggested) to send out the sound in all directions.

R, the robot, has a sensitive microphone (not sure of best type) or a set of microphones as already suggested, feeding an opamp and a 4046 phase locked loop with a narrow capture range of frequencies centred on 50kHz. The phase outputs of the PLL ar NORed to generate a 'locked' signal. As soon as the 50Khz pulse is received and the PLL has locked onto it, this signal goes high. The locked signal is ORed with R's servo signal. The Pulsin command is then used to measure the gap between pulses - which will indicate the distance R is from B. Speed of sound is 332 m/s at 0 degrees C. Pulsin measures to a resolution of 0.00001 seconds, which corresponds to 3.3 mm distance. The Pulsin command is run when R knows the transmission will have been made.

This solution relies on R being stationary when it is calculating it's distance, other wise doppler shift will mess up results. Also R probably needs a temperature sensor to adjust for how the speed of sound varies with temperature.

I think this would work in theory - I'd like to know if people think it wouldn't it practice. The crystal accuracy seems feasible to me. Could even have an audible sound version - the beacon chirping away. Or could make the beacon only chirp every 10 seconds or so.

Could have two beacons , known distance apart and transmitting at agreed timeslots, both at 50KHz (maybe electrically connected by long wire). R could then determine it's co-ordinates by triangulation.


Edited by - jeremy leach on 1/30/2006 6:20:19 AM

[BeanieBots]

Certainly a theory worthy of doing some further sums. Might even get around to playing around with some hardware but I'm dubiuos about a PICAXE being a suitable engine for it. If your suggested 3mm resolution really is achieveable, then it would make a really good robotics module for both homing and orientation.

[Rickharris]

Most of the positional systems I have seen either use GPS or some form of terrestrial triangulation.

[Gussy]

just a quick thought, lighthouses usuaslly have 2 lights, not one, if you had 2 rotating ultrasonic emmiters say 30deg apart, and they were very focused in the one direction, you might be able to work out the distance by the time between when the robot hears the first then second burst...

add in another 2 "lighthouse's" on different frequencies and you may be able to do some triangulation...

just a thought...

[andypro]

I would think the ultrasonic stuff would only work on very flat ground and rather close distances. Reflections from just about everyhitng could drive the US receivers crazy.

What if you switched from sound to radio waves? Less reflection problems and greater range.

A thought combining the two:

Use a slowishly rotating direcitonal antenna from the transmitter. It transmits it's rotational position as it slowly rotates.


You could use both the first recieved and last recieved rotational position transmition to do all of the directional calculations, and since the antenna beam pattern will be wider the farther away you are and you know the rotation rate of the beacon, the longer your recieving the signal the farther away you are.

This may require the math coprocessor to do the calcs, but it would work I think.

--Andy P

[Jeremy Leach]

My idea was basically measuring the phase shift of a signal from the beacon. There would be reflections, but I would have thought you could detect the arrival of the direct sound first, and do calculations on that.

I think maybe counter ICs could be used. A 4060 14-stage ripple counter has inputs for a crystal. This could be used to generate the tone-burst signal. Also could use a counter to detect the phase difference.

Anyway it's started me thinking - and it would be great to try some experiments when time ;-)

[xstamp]

Thought it might be useful at this stage to elaborate on the comment about sound location that I made earlier. This information is from a book on biorobotics by Barbra Webb & Thomas Consi (ISBN 0-262-73141-X).

Female crickets can walk or fly towards the calling song of a male over a distance of ten or twenty meters, whilst negotiating uneven vegetation –covered terrain, despite other sounds in the vicinity. The cricket song (beacon) consists of 10-30 mS bursts of a fairly pure tone of around 4-5KHz.

The female cricket detects this unique song using ears at the tips of her two front feet but lacks the processing power (like the picaxe!) to detect the uS phase differences needed to determine the targets direction. Instead the phase difference is physically converted to detect the amplitude difference. Things start to get rather involved now (an introduction covering the electronics developed to mimic this technique is provided in the above book) but it does seem that an audio approach to robot homing may well be worth investigating further.

[Jeremy Leach]

On the topic of ultrasound (just for interest, not exactly PicAxe related), I just have to post this link...<A href='http://www.dh.aist.go.jp/research/enabling/Ultrasonic3DTag/index-e.html' Target=_Blank>External Web Link</a>

Scroll down to the picture of their omnidirectional ultrasound unit - Now that IS awesome !

PS: Regarding my earlier idea ... still thiking about the detail, but one point is that using a phase-locked loop may not be the best idea because of the time it takes to lock to the incoming signal.

[BarryP]

While Looking into zigbee Stuff I Bumped into an interesting device with a Location Engine Built in.
<A href='http://www.chipcon.com/index.cfm?kat_id=2&amp;subkat_id=12&amp;dok_id=261' Target=_Blank>External Web Link</a>
Not Really a Picaxe solution tho. It has it's own 8051 core.