next topic »

[on:]

I am building a project which includes around 15 ultrasonic sensors as well as a large amount of other inputs and outputs. Since the ultrasonic sensors rely on time for distance readings (time from ping being sent to it being received) the execution of each ultrasonic sensor reading creates a large amount of delay and blocks all other inputs and outputs for that amount of time as the loop() is being held up.

What is the solution to this kind of a problem. Is there a way for me to have the sensors on their own control chip or on a separate system? Thanks.

[Reply #1 on:]

i am just looking a solution for the same problem..
only working thing is "so called" newping library, which has a 15 ultrasonic sensor example

[Reply #2 on:]

What is the solution to this kind of a problem.

It is to ping all the sensors at once and then pole round the receivers and note the millis() time you get the echos returned.
Rather in the same was as the blink without delay.
That will only work if your application can stand having all the emitters pinged at the same time.

[Reply #3 on:]

I am building a project which includes around 15 ultrasonic sensors as well as a large amount of other inputs and outputs. Since the ultrasonic sensors rely on time for distance readings (time from ping being sent to it being received) the execution of each ultrasonic sensor reading creates a large amount of delay and blocks all other inputs and outputs for that amount of time as the loop() is being held up.

What is the solution to this kind of a problem. Is there a way for me to have the sensors on their own control chip or on a separate system? Thanks.

The NewPing library has an example sketch that does exactly this, ping 15 sensors without locking you out from doing other things.  It does this with a combination of scheduled polling and timer interrupt pinging of each sensor.  The example sketch can be found here.

With this sketch, you still have plenty of processing time to do other things (it's like multitasking).  This sketch will ping each sensor with a 33ms delay, so all sensors will ping about twice a second and then arrive at the oneSensorCycle() function where you would process these results.  Due to the speed of sound and the output power of these sensors, that's about as fast as you can do this while guaranteeing no cross-sensor ping.  You could get creative by changing the order of the sensor triggers (for example, on opposite sides) that may allow you speed this up a bit.  But, you're really hitting the limit of acoustic physics here.  Triggering all the sensors at once sounds like a good idea, until you consider all the noise and echos you'll get.  It works, just not consistently reliable.

So, if getting ping results from all sensors twice a second is fast enough, the example sketch above will work just fine and give you enough processing time to do something with these results.

Keep in mind that this sketch is designed to ping each sensor and then process the results once every cycle.  If you want to process results after each ping, you would need a different sketch.  I've created a message that talks more about this and gives examples of different ways of processing the results including sketches that process results after each ping.  There's also more information about the 15 sensor sketch and other tips.  Please see the following message for detailed information:

http://arduino.cc/forum/index.php/topic,106043.msg1009294.html#msg1009294

Tim

[Reply #4 on:]

I just got ultrasonic sensors and just got one working. Maximum range is 4.5 meters. Sound at Standard Atmosphere temperature travels 340 m/s which is 26 msec (37.77~ reads a second possible) out and back but that's max range for mine. Closer in is faster. If I was to run 15 of them I would make sure they didn't have each have to read often but I would not fire up more than one at once to keep echoes from one falsing another.

Like Grumpy_Mike posted, your answer lies along the lines of Blink Without Delay. The very comparative slowness of those sensors to an Arduino should make them a lighter load on your MCU, not a heavier one.