Let's Make Robots!

Reading multiple echoes with HC-SR04 ultrasonic sensors

Possibly helps to detect objects, walls and holes.
AttachmentSize
ChainedUltrasonic.txt1021 bytes

 Some fancy nice ultrasonic sensors can read multiple echoes of sent ultrasonic wave. Cheap senosrs register the first echo that arrived back. If we could listen more echoes we can tell if there space behind first detected object. I have some HC-sr4 ultrasonic sensors that cost only few dollars. It came to my mind that maybe second sensor could detect waves arriving after first one. This seemed to work! As after fast googleing it seemed nobody has shared something like this, I decided to go on with a this tip.

 

The picture shows the set up. This is first tests and nothin optimized but worked quite well. First sensor sends a pulse. When it echoes the pulse back, echo pin is connected to second sensors trigger. Second sensor (sends a pulse) starts listening. When the second wave cames back, it reports to another microcontroller pin.

I tried two different settings and managed to find both box and the wall behind it. If sending cone of second sensor isn't muted, objects that are further away than distance to closest object can't be detected because of pulse from the second sensor. This has however andvantace of not waiting so long the second wave. If I muted the second sensors transducer with my finger (hitec solution) i could listen echoes from far away. This setup can't tell you if there is emptynes beyond sensors range or if all the sound just echoed back from the first object detected. Arduino code attached.

EDIT: Changed the code a bit and got nice readings shown in this picture. First echos leght is added to second pulse duration. When there's no other echoes both readings are same. Now second value seems to report very exactly second object distance. Sensors are in the beginnig in front of box, when i move it sidewys and it reaches the edge, wall behind box comes visible :)

 

 

SPECULATIVE: I don't know if it were better to trigger second sensor with software because it takes time to wait echo signal read operation. One could this way decide how faraway obejts to listen by delaying second triggering.

Chaining the sensors could be useful for other reasons too, i am not sure. You don't have to trigger the sensors individually, just listen the inputs. Also could one make a self oscillating system by linking second (or nth) sensors echo to first trigger pin. Last echo should be protected with a diode because of original launching pulse from microcontroller.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hmm, I finally got around to read this, and nice one Mr BMP ;)

For the sake of sience i'll continue reporting studies of my laboratories in the ugly format of paint brush pictures :) This hobby doesn't take enough money to hire an art director. Is it enough i converted those bmp's or should i destroy originals and even write over the memory. Or can only puring holy purifying fire on my computer salve mea?

..and 'look' I'm not your father :P

As for art talent, you can always try and summon the spirit of Mr. Pratt to help you in that task :P

 

Clever.  Tell us more!  [You might have to surgically disable the xmit on the 2nd and 3rd ping sensors, so that only the receive part is functional.]  It will be tricky to trigger three in some sequence and get useful info out.  

Let's do a thought experiment.  S1 xmits ping at T1 and detects the return from the nearest object at T2.  S1 xmits ping at T3, S2 xmits a phantom ping at T3 + (T2 - T1) and is not ready to detect ping return at T4 which S1 does detect.  S2  starts listening right after T4 for the 2nd return echo at T5.

Q: How does the US Navy do sonar return signal processing?  probably bilateral or multilateral most of the time

Until we meet again: Happy Trails to You.

 

Thanks for input!

 

It starts to hurt my brain to think without paper all these echoes ping ponging around. When chained T2 is quite much same as T3 considering this devices working  is fast compared to soundspeed. Your experiment is missing what triggers second S1 ping?

However it shouldn't be very hard to detect pulses because there are coming from separate echo pins. Also triggering three devices ,two later of them muted, should easily detect second and third echo.

Haven't been experimenting much, this idea came yesterday :) I found today that it works even better than i tought yesterday. I mounted the sensors properly, and noticed that when i move box near and far that won't affect the readings from wall what is nice...

next thing could be  mount the system to a wandering bot and look if it finds it way through boxes using this method. Timeout should be added to second pulsein()

Wow!  If this hardware and sofware can be made to work correctly; I have thought of a fantastic challenge the robot could handle with some probability of success.  Anyone remember the hallways from the movies and video games with giant moving pistons going up and down, left and right with momentary(time limited) safe spots in the middle?  This improved sonar subsystem can accomplish that!

Allow me to clarify some fuzziness that was in the following statemnt:

 S1 xmits pingA at T3, S2 xmits a phantom ping at T3 + (T2 - T1) and is not ready to detect ping return at T4 which S1 does detect. 

with this expansion:

 S1 xmits pingB at T3 after all detectable echos from the pingA have become undetectable.  At T3 + (RoundTrip(pingA)) the uC tells S2 to xmit a nonfunctional ping.  While S2 is counting down to begin its "listen for return echo" mode, S1 will notify the uC of the RoundTrip(pingB) for the closest object which is almost exactly equal to time it took for RoundTrip(pingA) unless the robot is moving very quickly indeed!  That is redundant info if the two distances are equal.  So now when S2 reports a return echo at T4, we can compute the total time for the round trip to the object that is further away as .....  S1.RoundTrip(pingB) plus  S2.RoundTrip(pingB).

 Ping_Illustrated

I think that with 3 devices you can detect all the echoes.
Device1 is triggered and detects 1st echo.
Device2 is triggered and detects 2nd echo.
Device3 is triggered and detects 3rd echo.
Device2 is retriggered and detects 4th echo.
Device3 is retriggered and detects 5th echo.
and on and on and on...

basile

And this could be extended to some form of 'oscillator' that continually cycles between the two tx/rx pairs. Hmm!?

And this could be extended to some form of 'oscillator' that continually cycles between the two tx/rx pairs. Hmm!?