alegiaco:
Very good job, man!!!!
Two questions:
- is it possible to use multiple ultrasonic sensors? i.e 4 sensors?
- with multiple sensors and a distance between 10 and 20 cm how fast can be the readings?
Thanks
YES! The NewPing library is designed with multiple sensors in mind. It's one of the reasons I created the library. With the other ping/ultrasonic libraries, if there's no ping echo it waits a full second for the reply. During that time, the Arduino is doing nothing, it's like a delay(1000). Multiply that by 3 if you have 3 sensors. So, you're waiting for 3 full seconds doing nothing if there's no pings. Imagine an autonomous bot where you add a delay(3000) right in the middle of the sketch. A lot can happen in 3 full seconds, or the bot can just sit there for 3 seconds to figure out which way to go. Unacceptable.
I plan on creating a proper sample sketch using multiple sensors and also creating another library specifically optimized for 3 sensors. But, here's basically what you would do:
#include <NewPing.h>
NewPing sonar1(11, 12, 200); // Sensor 1: trigger pin, echo pin, maximum distance in cm
NewPing sonar2(9, 10, 200); // Sensor 2: same stuff
#define pingSpeed 100 // Ping frequency (in milliseconds), fastest we should ping is about 35ms per sensor
unsigned long pingTimer1, pingTimer2;
void setup() {
// Do other stuff here
pingTimer1 = millis() + pingSpeed; // Sensor 1 fires after 100ms (pingSpeed)
pingTimer2 = pingTimer1 + (pingSpeed / 2); // Sensor 2 fires 50ms later
}
void loop() {
if (millis() >= pingTimer1) {
pingTimer1 += pingSpeed; // Make sensor 1 fire again 100ms later (pingSpeed)
int in1 = sonar1.ping_in();
}
if (millis() >= pingTimer2) {
pingTimer2 = pingTimer1 + (pingSpeed / 2); // Make sensor 2 fire again 50ms after sensor 1 fires
int in2 = sonar2.ping_in();
// Both sensors pinged, process results here
}
// Do other stuff here, notice how there's no delays in this sketch, so you have processing cycles to do other things :)
}
The above code is incomplete and doesn't do anything with the ping results (ready to add your own code). But, it should give you an idea of what to do.
As to your second question, I suggest waiting at least 35ms between pings per sensor to avoid possible echo issues. This isn't a library limitation or something that can be made faster by setting a shorter maximum distance. The pinging frequency has to do with the speed of sound and the sensor specs. You can, however, get away with making this faster if you need to. My sensors are a little hard of hearing and can't detect the maximum 500cm. So, I've successfully pinged every 25ms without a problem. Never really tried to see how quickly it would work as typically in a real-world situation 10 times a second is plenty fast as your sketch is also doing other things too.
What you gain by setting the maximum distance to a lower value is not how fast you can ping. What you gain is how much time your sketch is off in limbo doing nothing waiting for the ping reply. This allows your sketch to do multiple things without waiting for the ping echo (like in the other ping and ultrasonic libraries out there). Here's an example. If you use the 500cm maximum distance, the Arduino could set idle for up to 34ms for each ping. If you only care about reading distances 20cm or less, the most the Arduino would wait for a ping would be 1.4ms. Therefore, the Arduino has time to do other things. Basically, the Arduino can better multitask if you set a shorter maximum distance. But, due to the speed of sound, and sensor specs, you can't ping faster even if you set the maximum distance to a very low value, you still need to wait for the previous ping to fade or you'll get echo readings.
Let me know if you have any other questions or issues.
Tim