I'd like 1 circuit to be simple and very light. I'd like to measure distance up to 10m with 34cm accuracy. Will this work?
But different. Here is my modification...
My idea is to put the sender in the small airplane or helicopter. It will simply beep exactly every 0.1 or 1 second. The receiver will store the milliseconds and a number of milliseconds it's drifting per ping when it's 1m away not moving. This might be +-0.52ms, for example, which could be determined by waiting for 100 cycles or 100 seconds. All I need is an accurate clock that's small. Obviously the 2 clocks do not need to be in sync. One can even drift by 1%. As long as they are consistent. Can I use a 555 for the sender? Arduino Uno timer for receiver? Do you think I will get 34cm accuracy? Can I do better? Can I share the main helicopter battery? Or watch battery.
Sound is 343m/sec. So 1ms is about 34cm.
I realized this will not work for long. The code will have no way of knowing if it slowly moved away to 10m, or drifted 30ms over time. It will have to be reset to a known distance every few minutes?
Disregarding voltage and temp changes, it should continue to be accurate within 1%?
How much could it vary from 1sec to the next? I think much less than 1%.
Any better ideas? Please.
Update: Can I use the hardware in the first link together with a Nano or Picaxe to receive a ping and send one back after a short constant delay? Is there a complete piece of hardware that already exists to do this for the consumer market? Which idea do you like best so far?
Why not ping in response to an optical pulse?
Time of flight of optical pulse is negligible.
Your acoustic time of flight is affected by temperature and air pressure, so may need some compensation.
No, you can't measure distance by timing pulses, only speed: Doppler effect - Wikipedia
But you can use two ping sensors, one on the ground and second on the plane ( if it's small, and can't reflect enough signal from the body). Ping on the plane should be configured for retransmission back whatever pulse it receives. Than ground station calculate overall delay, and subtract known retransmission delay.
It will be easy to guess the temperature to get within 1-2%. 34cm/10m is about 3%. 34/5m is 6%. Mostly I want to know if it's moving further away or closer to keep it at a constant distance.
What is the advantage of optical compared to 2-way sound? The disadvantage is that light is much harder to point in the right direction from a moving rotating object.
@Magician - Great idea! Where have a I heard that?
You're correct, the timing between pulses will always be 1s for a slow moving object in my example. But it will be shifted compared to the clocks by 30ms at 10m, at the receiver. All I have to do is keep the clocks in sync. Or measure how they drift consistently without any movement/distance.
The optical pulse is there to trigger the acoustic pulse.
If the base station provides the trigger pulse, and you know the latency of the optical receiver to acoustic pulse generation, you simply time the delay before the base receives the acoustic pulse.
If you notice a difference in received frequency then it will be moving closer or farther.
You definitely want to have a 2-way ping instead of an on-time 1-way. Try and get two Arduino's to blink synchronously for half an hour if you don't know why.
Can you actually produce a clear enough sound to detect at that sort of range, bearing in mind that your airborne platform will be making a lot of noise?
If you can hear it, then I'd try using a radio link to trigger the pulse and try averaging the round-trip time over a number of samples. I don't know how many samples you'd need to average to get a consistent result - it might be dozens or hundreds, depending how long a pulse you need to be detectable and how quickly you can detect the start and end of the pulse. That would give you some indication of range. I doubt that it would be practical to detect doppler shift, but you could infer closing speed from the range change..
Actually if you made the ping sound using PWM and a piezo buzzer you could get very precise, sharp clicks as output. Picking them up might or might not be a problem. The higher the frequency the farther they might carry too. If the clicks are in very short bursts you wouldn't need to know the sound frequency, only the burst frequency.
It will probably not be reliable because the helicopter makes a lot of noise. The plane does not. This interference is why I suggested sending only from the craft using a clock to do it at a defined interval. It is not so loud at 2m away. I like the idea of a radio link! What circuit can I use? My first thought is XBee, but there is a variable delay in receiving a single byte. It has to be low mass.
@goforsmoke
I was thinking of making only 1 short click every 1 second. Possibly 0.1 second. You seem to have a different idea. Please explain. The distance wouldn't change much at 100hz, from one cycle to the next. I assume we're talking 1-way transmission now, without a clock?
With PWM you can make 1 click at pretty precise interval too. I took a few seconds to think before and wasn't working it all out. But still, relative movement will change the timing of the clicks the same way that doppler shifts frequencies. Clicks is the 'sonar' used by bats, btw, and good for more than 10 meters at flying speed, but they do have good ears and cortex processor.
There are totally blind people who walk around and even ride bicycles (including down mountain trails) using echo location from clicking their tongues.
As to the doppler, that's science. What you might be able to do with it is real. All I tried to do is make you aware of a possibility, not tell you you what to do.
Here's another possibility. With the radio pulse returned by sound from your vehicle (plane or copter) and 3+ base stations you could be able to get location instead of just distance. But... it would be a lot of work.
How often do you want to measure the distance? What is the variation of distance (aka speed) you want to be able to detect? That will determine the frequency of the pulses.
It is good to start just with a low frequency e.g. once per 5 seconds, so you can "visually" follow the code (add some serial debug statements) and tackle the problems you encounter step by step. First get the code right and then speed up works better than doing both simultaneously.
The most important problem to tackle is to detect the pulse. No experience how to do that in the noisy environment, the advice of a high sharp pulse sounds reasonable imho.
If you need to measure the distance every second than you must take into account that measurements get lost e.g. due to noise. Suppose that on average one in five pulses are not detected, you know that (on average, assuming errors are behaving in a nice way, spreading nicely) two pulses after each other are missed (1 in 5^2 = 25) three pulses missed (1 in 5^3 = 125) four pulses (1 in 5^4 = 625) five (1 in 5^5 ~=3000) six (1 in 5^6 ~= 15000) seven (75000) eight (350000)
So it you need one reading per second and accept one missed reading per hour, you should at make at least six readings per second. If you accept one misread per day you need at least 8 readings per second. This all under the assumption that errors are spread nicely, The bad news is they don't, they often come in bursts. Morale is that you need to design the flow of you sketch to handle missed readings. E.g. you can hold the last 10 readings in an array and calculate the expected distance, to handle it. (SOme GPS-navigation apps do that when loosing signal)
OK so I can make a repeating pulse with PWM() or a 555. Which is more stable? I understand what you said about missed readings. And how to calibrate it for temperature and humidity. One thing at a time, 3D comes later. We have decided that it will be difficult to receive a click on the helicopter due to all the high frequency clicks already in the blade linkages 3" away. I'm sending a repeating pattern of clicks from the helicopter? What am I measuring, the time between them? Please explain. It may only change by 50us. This way I can detect that it's coming or going. But it will give me no indication of its current position/distance? Assuming the angle is unchanging, can I get a rough idea of distance from the magnitude of the click?
Maybe I should use RF to trigger each click from the helicopter. What type of receiver can I use that is light weight?
So the blade linkages make your clicks?
Would the noise level from the copter provide range data? The decibels should fall off with distance in the open.
Unfortunately the frequency of the linkage clicks changes with RPM.
Even if I tried to keep a constant speed it would vary way too much, of course.
I like your idea it is so simple! Maybe there is a way to measure the energy level of each individual click from the linkage. It would be much easier to measure the total energy in a second. I can assume the RPM is roughly constant from 1 second to the next.
Distance = C / sqrt (sound energy level) ?
Do you think I might get 1 meter accuracy?
I believe it might work, out to 20m or more, if there was no other sounds.
