Go Down

Topic: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 (Read 129 times) previous topic - next topic

Human

I put my HC-SR04 sensor in the mail to Tim today. Hopefully it'll tighten the test cycle and benefit others who have HC-SR04 sensors. :)

My backup HC-SR04 is definitely less reliable than the one I shipped out, but it still "works" (for some value of "work"). I have digital filters in place to try to determine if a reading is true or not, so this mitigates the inherent issues with the sensor.

My code base can also create a virtual sensor from N actual sensors, and I was planning to do this to work around the unreliability, since it seemed unlikely that two sensors would be unreliable at the same moment in time (unless there are common environmental or power factors that cause this).  If the HY-SRF05 is more reliable, then I can probably start trusting the data more and tune the digital filters to be more lenient.

Is there any demand for virtual sensors as I described?  If so, I can work on turning what I have into a subclass of NewPing. It sounded like other people are using multiple sensors in non-redundant ways, and if the reliability solution really is "just buy an HR-SRF05" then maybe that effort would be wasted.

teckel


I put my HC-SR04 sensor in the mail to Tim today. Hopefully it'll tighten the test cycle and benefit others who have HC-SR04 sensors. :)

My backup HC-SR04 is definitely less reliable than the one I shipped out, but it still "works" (for some value of "work"). I have digital filters in place to try to determine if a reading is true or not, so this mitigates the inherent issues with the sensor.

My code base can also create a virtual sensor from N actual sensors, and I was planning to do this to work around the unreliability, since it seemed unlikely that two sensors would be unreliable at the same moment in time (unless there are common environmental or power factors that cause this).  If the HY-SRF05 is more reliable, then I can probably start trusting the data more and tune the digital filters to be more lenient.

Is there any demand for virtual sensors as I described?  If so, I can work on turning what I have into a subclass of NewPing. It sounded like other people are using multiple sensors in non-redundant ways, and if the reliability solution really is "just buy an HR-SRF05" then maybe that effort would be wasted.


Can't wait to get the sensor and figure out what's going on.  I hope to test and send back ASAP.

With properly working sensors, a virtual sensor from multiple sensors should not be required.  Sensors that actually work are very reliable and give consistent and accurate readings all the time.  I also have sensors that "work" but are clearly not 100% functional (this is with any library).  Mine having a problem seem to work to around 50cm, then get all wonky.

While I find that my SRF05 and SRF06 are more reliable, online I've also found at least two totally different kinds of SRF05 sensors.  Both have the same model number on them, but each are electronically different with different pinouts.  So, I don't want to totally endorse the SRF05 as superior, as it appears they're made my multiple manufactures with different specs.  Which is probably why there's some HC-SR04 sensors that "work" and probably why the HC-SR04 sensors you have don't work with my library, as they're made by a bunch of different manufactures, with different specs or quality control.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Human


Can't wait to get the sensor and figure out what's going on.  I hope to test and send back ASAP.

I'm still amazed you're volunteering to do this :) That's dedication!

If you find that the SR04 that I sent you behaves significantly differently than the ones you have, I would be happy for you to keep it for regression testing purposes. (I could potentially help write a regression test, too, although I've never tried making one for an Arduino library, and it couldn't be fully automated due to its nature.) I have a spare SR04 anyway, and they're cheap enough that I could just order more if I wanted more.


With properly working sensors, a virtual sensor from multiple sensors should not be required.  Sensors that actually work are very reliable and give consistent and accurate readings all the time.  I also have sensors that "work" but are clearly not 100% functional (this is with any library).  Mine having a problem seem to work to around 50cm, then get all wonky.

The sensor I'm sending you works up to 100cm (I didn't try longer distances), but it occasionally throws in an outlier of some kind, whether it's an in-range but wrong value while something is in the sensor's range, an out-of-range value while something is in range, or an in-range value while nothing is in range. I agree that if a sensor is working properly, it shouldn't do this. My original idea was to use virtual sensors to combat inherent unreliability issues with these cheap sensors (much like RAID was created to create reliability out of unreliable cheap parts), but if there are reliable sensors in the same family for the same price, I think I should just use those :)


While I find that my SRF05 and SRF06 are more reliable, online I've also found at least two totally different kinds of SRF05 sensors.  Both have the same model number on them, but each are electronically different with different pinouts.  So, I don't want to totally endorse the SRF05 as superior, as it appears they're made my multiple manufactures with different specs.  Which is probably why there's some HC-SR04 sensors that "work" and probably why the HC-SR04 sensors you have don't work with my library, as they're made by a bunch of different manufactures, with different specs or quality control.

Hmm. Any such variations with the SRF06 sensors?

teckel


Hmm. Any such variations with the SRF06 sensors?


It doesn't appear there's different types of SRF06 sensors.  But, I wouldn't be surprised if there were multiple manufactures.  Also, the SRF06 won't work using one pin unless you put a cap across the trigger and echo pins, and, even that doesn't work with the Teensy.  The ability to use only one pin is a huge advantage as in many projects multiple sensors are used and pins can be in short supply.  For that reason, I'd lean towards the SRF05, which for at least one manufacture is actually designed to be used with only one pin.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

teckel



Can't wait to get the sensor and figure out what's going on.  I hope to test and send back ASAP.

I'm still amazed you're volunteering to do this :) That's dedication!

If you find that the SR04 that I sent you behaves significantly differently than the ones you have, I would be happy for you to keep it for regression testing purposes. (I could potentially help write a regression test, too, although I've never tried making one for an Arduino library, and it couldn't be fully automated due to its nature.) I have a spare SR04 anyway, and they're cheap enough that I could just order more if I wanted more.


Got your sensor today and had to plug it in to see what happens.  Connected to the Teensy 2.0, it works perfectly with both 2 and 1 pins.  Don't have a connector on this computer to connect to the Arduino R3, but I'll try it tomorrow on my primary system.  Turning out to be quite a good puzzle this is.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

karan2012singh

hii,..i m using hc-sr04 ultrasonic sensor,..i m using the lastest version of ping,...all my connections are fine,,... and the code i m running is..
// ---------------------------------------------------------------------------
// Getting a reliable ping every 50 milliseconds isn't possible with other ping or ultrasonic libraries.
// These kinds of speeds work perfectly with the NewPing library. Even at the maximum sensor distance of
// 500cm, distance measurements can be done 20 times a second! If you set the maximum distance to 200cm
// as we have in this example sketch, even faster pings can be achieved. I suggest waiting at least 37
// milliseconds between pings to avoid previous ping echo issues, that translates to a maximum ping rate
// of around 27 times per second. Much better than the sometimes 1 ping a second with other libraries.
//

#include <NewPing.h>

#define TRIGGER_PIN 12 // Arduino pin tied to trigger pin on ping sensor.
#define ECHO_PIN 13// Arduino pin tied to echo pin on ping sensor.
#define MAX_DISTANCE 200
// Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.

unsigned int pingSpeed = 50; // How frequently are we going to send out a ping (in milliseconds). 50ms would be 20 times a second.
unsigned long pingTimer = 75; // Holds the next ping time, start at 75ms to give time for the Arduino pins to stabilize.

void setup() {
Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results.
}

void loop() {
// Notice how there's no delays in this sketch to allow you to do other processing in-line while doing distance pings.
if (millis() >= pingTimer) { // pingSpeed milliseconds since last ping, do another ping.
pingTimer += pingSpeed; // Set the next ping time.
Serial.print("Ping: ");
int cm = sonar.ping_cm(); // Send out the ping, get the results in centimeters.
Serial.print(cm); // Print the result (0 = outside the set distance range, no ping echo)
Serial.println("cm");
}
}
and the output coming is..
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
and continue....
i dont know why,..the sensor is just giving this output
plzz help

teckel


hii,..i m using hc-sr04 ultrasonic sensor,..i m using the lastest version of ping,...all my connections are fine,,... and the code i m running is..
// ---------------------------------------------------------------------------
// Getting a reliable ping every 50 milliseconds isn't possible with other ping or ultrasonic libraries.
// These kinds of speeds work perfectly with the NewPing library. Even at the maximum sensor distance of
// 500cm, distance measurements can be done 20 times a second! If you set the maximum distance to 200cm
// as we have in this example sketch, even faster pings can be achieved. I suggest waiting at least 37
// milliseconds between pings to avoid previous ping echo issues, that translates to a maximum ping rate
// of around 27 times per second. Much better than the sometimes 1 ping a second with other libraries.
//

#include <NewPing.h>

#define TRIGGER_PIN 12 // Arduino pin tied to trigger pin on ping sensor.
#define ECHO_PIN 13// Arduino pin tied to echo pin on ping sensor.
#define MAX_DISTANCE 200
// Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.

unsigned int pingSpeed = 50; // How frequently are we going to send out a ping (in milliseconds). 50ms would be 20 times a second.
unsigned long pingTimer = 75; // Holds the next ping time, start at 75ms to give time for the Arduino pins to stabilize.

void setup() {
Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results.
}

void loop() {
// Notice how there's no delays in this sketch to allow you to do other processing in-line while doing distance pings.
if (millis() >= pingTimer) { // pingSpeed milliseconds since last ping, do another ping.
pingTimer += pingSpeed; // Set the next ping time.
Serial.print("Ping: ");
int cm = sonar.ping_cm(); // Send out the ping, get the results in centimeters.
Serial.print(cm); // Print the result (0 = outside the set distance range, no ping echo)
Serial.println("cm");
}
}
and the output coming is..
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
Ping: 0cm
and continue....
i dont know why,..the sensor is just giving this output
plzz help


Try connecting it to pins 5 and 6 instead of 12 and 13.  Also, is there a clear shot in front of your sensors?  No wires or stuff in the way?  Sensor at the edge of your breadboard?  A user sent me a sensor that experienced the same problem on his Arduino, but on mine it works just fine.  So, I'm starting to think it's how it's being wired or what the environment is.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

teckel


I'm still amazed you're volunteering to do this :) That's dedication!


Can't get your sensor to fail.  Works perfect no matter what I try (works better than my 3 semi-working sensors).  See my private message to start from the begining as we must be missing something basic here.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Human

I don't mind posting this in public, since it may benefit others, but I was accidentally using a Duemilenove (2009) board instead of an Uno R3  :smiley-red:

With the 2009 board, the sensor will send a ping, and status output goes to the serial port, but the distance reported is always 0cm.  Swapping out the board for an Uno R3 makes it all work with NewPing, and the 2009 board works fine with the code I linked to.  I assume that it's something about how NewPing compiles for the 2009's architecture.

I don't know *why* the 2009 board would have this issue, but at least this explains why my HC-SR04 *appeared* to be acting strangely.

To sum up:

2009 + NewPing + HC-SR04 = 0cm always
2009 + NewPing + HY-SRF05 = 0cm always
2009 + primitive code + HC-SR04 = works
2009 + primitive code + HY-SRF05 = works
UnoR3 + NewPing + HC-SR04 = works
UnoR3 + NewPing + HY-SRF05 = works
UnoR3 + primitive code + HC-SR04 = works
UnoR3 + primitive code + HY-SRF05 = works

teckel


I don't mind posting this in public, since it may benefit others, but I was accidentally using a Duemilenove (2009) board instead of an Uno R3  :smiley-red:

With the 2009 board, the sensor will send a ping, and status output goes to the serial port, but the distance reported is always 0cm.  Swapping out the board for an Uno R3 makes it all work with NewPing, and the 2009 board works fine with the code I linked to.  I assume that it's something about how NewPing compiles for the 2009's architecture.

I don't know *why* the 2009 board would have this issue, but at least this explains why my HC-SR04 *appeared* to be acting strangely.

To sum up:

2009 + NewPing + HC-SR04 = 0cm always
2009 + NewPing + HY-SRF05 = 0cm always
2009 + primitive code + HC-SR04 = works
2009 + primitive code + HY-SRF05 = works
UnoR3 + NewPing + HC-SR04 = works
UnoR3 + NewPing + HY-SRF05 = works
UnoR3 + primitive code + HC-SR04 = works
UnoR3 + primitive code + HY-SRF05 = works



I guess this is good news, as before it was quite a mystery.  My guess is that the Duemilanove 2009 board is somehow different with port registers.  Since NewPing uses all port register access and the primitive code uses all built-in high-level pin access commands the two are quite different.  Did the Duemilanove 2009 come in both ATmega168 and ATmega328?  Which do you have?

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Human


I guess this is good news, as before it was quite a mystery.  My guess is that the Duemilanove 2009 board is somehow different with port registers.  Since NewPing uses all port register access and the primitive code uses all built-in high-level pin access commands the two are quite different.  Did the Duemilanove 2009 come in both ATmega168 and ATmega328?  Which do you have?


Reading the chip silkscreening itself indicates that it's an ATmega328, which is consistent with the behavior in the IDE.

teckel



I guess this is good news, as before it was quite a mystery.  My guess is that the Duemilanove 2009 board is somehow different with port registers.  Since NewPing uses all port register access and the primitive code uses all built-in high-level pin access commands the two are quite different.  Did the Duemilanove 2009 come in both ATmega168 and ATmega328?  Which do you have?


Reading the chip silkscreening itself indicates that it's an ATmega328, which is consistent with the behavior in the IDE.


So, the exact same processor as the Uno, darn...  I'm thinking that I'll create a couple different test libraries if you're willing to try each.  Probably one that replaces the ping echo detection with pulseIn to isolate the problem, then a few variations that do it a little differently.

Let me know if you're willing to do this, should be really quick and simple.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Human


So, the exact same processor as the Uno, darn...  I'm thinking that I'll create a couple different test libraries if you're willing to try each.  Probably one that replaces the ping echo detection with pulseIn to isolate the problem, then a few variations that do it a little differently.

Let me know if you're willing to do this, should be really quick and simple.

Even if it's not quick and simple, I'd be happy to help.

piratadelestrecho

#148
Jul 10, 2012, 06:42 pm Last Edit: Jul 10, 2012, 06:44 pm by piratadelestrecho Reason: 1
Hello Teckel.

First of all thanks a mil for your library I think is a lot of job and you are really kind sharing it with us.

I'm new to arduino and I have recently acquired a HC-SR04 sensor and I have donwloaded and installed your library for a test that I'm doing.

This is the little sketch that I'm running and I don't know if it's because I did something wrong but from time to time the sensor returns a 0 value.

Code: [Select]

#include <NewPing.h>

#define TRIGGER_PIN  7  
#define ECHO_PIN     6  
#define MAX_DISTANCE 200

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE);
int Range=200;
boolean Alarm=false;
int Counter = 1;
void setup() {
 Serial.begin(9600);
}

void loop() {
 
 Range = sonar.ping_cm();

delay(20);
 
 if (Range < 10) {

   Alarm = true;  
   Counter = 1;    
 }
 else if (Counter == 11) {
   Alarm = false;          
   Counter = 1;
 }
 
 if (Alarm)
   AlarmOn();
 
}

void AlarmOn(){
Serial.print("Intruso en:");  
Serial.println(Range);
Serial.print("Valor del contador:");  
Serial.println(Counter);  
 Counter++;
 
}


looking at the serial output I see that from time to time the sensor gets a 0 value and I don't know if it's a problem with my sketch or with the sensor itself...

Quote
Valor del contador:8
Intruso en:40
Valor del contador:9
Intruso en:40
Valor del contador:10
Intruso en loop:0
Intruso en:0
Valor del contador:1
Intruso en:39
Valor del contador:2
Intruso en:39
Valor del contador:3



I hope you can help thanks ;)

Human


from time to time the sensor gets a 0 value


This seems to be an issue inherent to this family of sensors. I have worked with two HC-SR04s and one HY-SRF05, and each of them sometimes throws anomalous results. I have applied a "digital filter" to compensate for this behavior. Basically, wait for N similar results in a row before trusting the value. The sensors do lie occasionally, and your code should compensate for that.

Go Up