Non-Line-Of-Sight Distance Sensors

Other Hardware Sensors
1

Hey Guys,

I am working on a project and need help with one of the sensors. I have a car (4 feet by 5 feet) that starts off at a docking station and without user input moves around avoiding obstacles. One of my constraints is that I have to stay within a certain distance (about 150m/500 feet) of the docking station. I have discounted sonar and IR sensors because they require the two objects to be in the line-of-sight of another and in most scenarios there will be obstructions between the car and the docking station (also I haven’t found sonar sensors with 500 feet range).

After doing a lot of research, I have come to believe that using RF transceivers is the best option for this task. What I intend on doing is having one transceiver 1 on the docking station and transceiver 2 on the car. I will send out a ping (a byte with a unique bit combination) from transceiver 1 and transceiver 2 will pick up the ping. As soon as transceiver 2 picks up the ping it will send a ping of its own with a different bit combination and this time transceiver 1 will pick it up. As soon as transceiver 1 picks up the ping it will calculate distance between the two objects using the time it took between initially sending out the first ping and receiving the second one (I will of course have to experimentally find the ping speed).

I am using an Arduino and am not sure what kind of transceiver to use for this purpose. After some research, I understand that RFM69CW and RFM12B are viable options but I have no idea how to use them, but before I buy them has anybody here who has worked with them know what other hardware I would need to get them working?
And how about programming? Does anybody have sketches for these boards? Also, of the three which frequency is most reliable? I will be using the car in a residential area, and was wondering if someone has experience with the three and could relate.

Summary of my challenges:

  1. Is there an easier way than RF transceivers of finding distance between two objects not in line-of-sight of one another?
  2. Are the RFM69CW and RFM12B the best options for me? If not then what are some worth considering?
  3. What other hardware would I need along with these boards to get them going?
  4. Does anybody have Arduino sketches for using these boards?

Thanks very much for your help!

2

Not possible Im afraid.
The propagation time of radio is 300 metres per microsecond, so 150 metres is 500 ns.
That far less than the time it will take the Arduinos radio to actually receive the signal, forward it to the Arduino to
process it , and for the Arduino to send the ping back.
ie the processing time of the 2 pings is far more than what you are trying to measure.

3

mauried is right. Radio signals travel at almost the speed of light. Trying to measure the time taken to get from one to the other is like measuring the speed of a car on the highway by use of a calendar.

4
5

To put it simply, the main part is an exact stopwatch, which measures time with a resolution in
nanoseconds

Note a nano second is a BILLIONTH of a second so this could work BUT

The stopwatch contains a crystal with a clock rate of 30 Megahertz

That crystal creates 30 ticks every MILLIONTH of a second (note the 'M' not 'B').
So how can it have a resolution of nanoseconds. It's like having a clock that only clicks every 5 minutes and expecting it to be accurate to the nearest second.

This solution doesn't involve an arduino so there's no "processing" involved. Even so there will be some latency on the logic gates involved. I assure you it will NOT give the accuracy that is being inferred.

As soon as you put any processing into the equation, it just becomes totally useless.

6

Just some random thoughts:

The Arduino Due's clock is 84MHz which is 11.9ns / cycle = 3.57 meters resolution.

If we have 2 Due's with wireless transceivers placed close together, they main Due could send a ping and recieve the 2nd Due's MCLK reading. The difference in both MCLK readings would be the reference (calibration point) for 0 meters.

If the 2nd Due is moved 100 meters away, the MCLK reading it sends back should differ from the calibration point by 333 ns or 28 clock cycles.

If you're trying to keep something within 500 meter range, 3.6 meter resolution should be quite good. Multiple measurements averaged should yield better resolution.

Drifting in MCLK frequencies would probably be an issue, especially over time. A method of periodic auto-calibration might be necessary.

7

The article is utter rubbish.
Radio Transmitters and Receivers are full of electronics which requires a finite time to modulate and demodulate whatever signals they are trying to transmit or receive.
In the case of those cheap 433 Mhz modules, the transmitter is a keyed oscillator which starts oscillating when a logic one is applied, but the oscillator has a finite key up time which is a function of the Q of the crystal or SAW resonater thats used to determine the frequency.
Same goes for the receivers, but the time delay thru the receiver, ie how long it takes to receive a carrier wave , demodulated it and present that demodulated data at its data output, depends on the bandwidth of the receivers IF filter,the bandwidth of its demodulator, and its AGC attack time .
The delays in the Transmitter and Receiver will be many orders of magnitude longer that the delay thats being measured.
The only way currently to measure distances using radio is Radar which has distance limitations at both the very short and long range ends, primarily due to the laws of physics.

8

Thanks guys for all the responses.

I am beginning to see the problem with my approach. The RF signals traverse at speeds which are much too fast for an arduino processor to handle.

Also I am assuming there are no other sensor that are capable of calculating distance between two objects not in line-of-sight of one another.

I will be recollecting my thoughts and looking for a new approach to my project and hopefully I can figure something else out. If I need help, I know many experienced enthusiasts are right here on this forum :slight_smile:

9

GPS works :slight_smile:

Bear95:
Also I am assuming there are no other sensor that are capable of calculating distance between two objects not in line-of-sight of one another.

GPS works.

10

Bear95:
I am working on a project and need help with one of the sensors. I have a car (4 feet by 5 feet) that starts off at a docking station and without user input moves around avoiding obstacles. One of my constraints is that I have to stay within a certain distance (about 150m/500 feet) of the docking station. I have discounted sonar and IR sensors because they require the two objects to be in the line-of-sight of another and in most scenarios there will be obstructions between the car and the docking station (also I haven’t found sonar sensors with 500 feet range).

You are describing an autonomous robot with obstacle avoidance capability. So you have some kind of sensing mechanism. If you know which direction you are moving (via a compass or something) and can keep track of your odometry (via wheel sensors or such) to know (very roughly) where you are and what direction you are pointing, then you have enough information to implement a specific kind of algorithm - called a SLAM (Simultaneous Localization and Mapping) algorithm. If you can add GPS into the mix, even better.

If you want a crash course into SLAM - this MOOC is very, very helpful:

https://www.udacity.com/course/cs373

Basically - once you can map your environment and localize inside of it, you can always find your way back, and you can easily gauge your distance. There is a minor caveat, however: You will never know -exactly- where you are using this method, because the world, your robot, and your sensors can never give you an exact value that matches with reality. This is known as "noise", and is inherent in all robotic systems (outside of simulations and idealize thought experiments, of course). The goal of SLAM is to be able to take this information into account, and be able to map and localize within the environment to a certain level of probability.

Needless to say, if you are fuzzy on your linear algebra and/or stats/probability knowledge - implementation of such algorithms will not be easy or intuitive (ask me how I know this...); furthermore, given the data and processing requirements of such a system, you won't likely be able to implement a SLAM algorithm (except for maybe something really, really simple) on an Arduino. Generally, the more processing power and memory capability you can throw at these algos, the better they work.

11

Have a look at differential GPS.

This technique can improve dramatically the accuracy of normal GPS , with an increase in complexity of the GPS receiver in the moving object, and an additional fixed GPS receiver at an accurately surveyed location.
You also need a short range telemetry link between the 2 GPS receivers.

12

mauried:
Have a look at differential GPS.

mauried, these are too expensive and unfortunately out of my budget.

I have been toying around with this idea: that instead of using the RF transceivers what if I use two stations with a mic and speaker each. Send out a high frequency ping from the first station and the mic on the second station receives it. Then the second station sends out a ping of its own and the mic on first station receives it. The time difference can be used to calculate the distance.

Sound travels approx 330m/s so my processor will be fast enough to pick it up. What do you guys think? Am I just beating my head against the wall? or is there a way to implement this?

13

Bear95:
mauried, these are too expensive and unfortunately out of my budget.

I have been toying around with this idea: that instead of using the RF transceivers what if I use two stations with a mic and speaker each. Send out a high frequency ping from the first station and the mic on the second station receives it. Then the second station sends out a ping of its own and the mic on first station receives it. The time difference can be used to calculate the distance.

Sound travels approx 330m/s so my processor will be fast enough to pick it up. What do you guys think? Am I just beating my head against the wall? or is there a way to implement this?

Provided there are no obstacles between the transmitter(s) and receiver(s), and no other surfaces beyond, etc - in theory it would work. However, in the real world, you are likely to get reflections and asorbptions, and will have to deal with that. For instance - from the ground or floor, at minimum. But it might be worth trying.

14

@cr0sh, I am going to attempt this. Thanks for the motivation.

To my understanding, most speakers are capable of emitting high frequency. However, the mic is the concern. What is my criteria for buying it? Also, how can I use the arduino and the mic to determine the frequency of sound?

15

Have you tried a weak radio signal that you can sense the location and strength of?

Just my twopenny worth.

16

Bear95:
To my understanding, most speakers are capable of emitting high frequency.

I suppose that would depend on your definition of "high frequency". In general, high frequencies within the range of human hearing are done with tweeters:

There is a particular class of tweeters, designed to go over 20 kHz (generally accepted upper-limit of human hearing):

Over 20 kHz, though, you are in ultrasonic territory - and should look into ultrasonic transducers. For long distances, you also need more power (wattage) to drive the transducer (whether a standard tweeter or ultrasonic).

Finally realize that sound is transmitted in a "cone" pattern, and the lower the frequency, the wider the cone spreads (in general - it is also a function of time); ultrasonic transducers typically have narrower "spreads" than non-ultrasonic transducers.

Bear95:
However, the mic is the concern. What is my criteria for buying it?

Well, your main criteria is that it can respond to the frequency range that you'll be generating, and have a peak detection centered around your generated frequency.

Bear95:
Also, how can I use the arduino and the mic to determine the frequency of sound?

You shouldn't really need or want to do this; instead, you tune your transmitter and receiver amplifiers for a particular frequency, ideally centered at the peak of the generation of the transducer being used on the transmitter - and if your receiver "mic" is in the same area, that amp should be tuned for that as well. Then, the receiving end should simply output a HIGH or LOW value you detect with the Arduino.

You would need a way to signal the receiver that you just transmitted a ping (use RF or light), so you can measure the time delay and get distance. Lastly, you would want a minimum of three transmitters (spaced around the work area of the robot platform) in order to triangulate and calc the distance.

17

Thanks again guys for your inputs. I have come across this tutorial: http://www.instructables.com/id/Arduino-Audio-Input/?ALLSTE

Please let me know what you guys think. Should I go ahead, buy the equipment, and give it a shot? Or are there certain aspects that the author is overlooking?

Any input is much appreciated.

Thanks :slight_smile:

18

Here's three suggestions:

(a) a fixed grid of laser beams across your space, each modulated differently, so when your devices crosses a laser beam it can determine which beam it has crossed.

(b) Make some boards with large simple shapes painted a uniform colour, around your space. Have a rotating camera on the top of your car. From the direction and apparent size of the easily detectable shapes, you can determine your position.

(c) Use the arduino to sequential open the trapdoors of a dovecote on top of your car, releasing a flock of carrier pigeons.

19

michinyon:
(c) Use the arduino to sequential open the trapdoors of a dovecote on top of your car, releasing a flock of carrier pigeons.

You would need to release the carrier pigeons sequentially, otherwise once the flock has gone, the vehicle would have no reference to find it's way home.

Maybe a turnstyle type system.