Go Down

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

#### duxiaoshi

#105
##### Jun 21, 2012, 10:29 amLast Edit: Jun 21, 2012, 10:57 am by duxiaoshi Reason: 1
yeah, it works when change PING_INTERVAL from 35 to 29.

And now one sonar in the front of bot is not assembled well. so I have only one sonar in the front and one sonar in the back.
I test two sonars on opposite sites of my bot,  with the PING_INTERVAL of 8 ms, and it work.
So i'll modify my code later to shorter the time.

and i have a question that where 35ms , 29ms,  8ms come from ,how it calulate.  The max distance is 2m, so the time of echo is  (2/340) * 2 = 12ms

#### teckel

#106
##### Jun 21, 2012, 03:19 pmLast Edit: Jun 21, 2012, 03:21 pm by teckel Reason: 1

yeah, it works when change PING_INTERVAL from 35 to 29.

And now one sonar in the front of bot is not assembled well. so I have only one sonar in the front and one sonar in the back.
I test two sonars on opposite sites of my bot,  with the PING_INTERVAL of 8 ms, and it work.
So i'll modify my code later to shorter the time.

and i have a question that where 35ms , 29ms,  8ms come from ,how it calulate.  The max distance is 2m, so the time of echo is  (2/340) * 2 = 12ms

The time calculations have nothing to do with what you set as the maximum ping distance.  Even if you set a max ping distance to 25cm, the sensor doesn't know that or do something differently.  All that happens is the library will only care about ping echo's within the 25cm range.  What still happens is the sensor sends out a ping and listens for an echo.  That ping echo can be detected from up to 400cm to 500cm away.

So, when one sensor sends out a ping, it can travel up to lets say a maximum of 500cm bounce, and come back and hit a different sensor that you may be reading for a ping echo at the time.  This would be cross-sensor echo.  When calculating the time, you always look at the sensor's maximum detection distance (lets say 500cm as that's what most spec).  500cm * 2 * 28.5uS/sec = 28,500 uS.  There's also around 450uS of delay before a ping starts with the SRF05, which works out to right around 29ms.  In theory, if a sensor is really only able to detect a ping at a maximum distance of 500cm, you could have two sensors right next to each other and ping at 29ms intervals and you should never get any misreadings from cross-sensor echo.

I typically say to ping every 33 to 35ms as a bit of a buffer, just to be sure.  Also, 33ms works out to 30 pings/second which is typically well faster than anyone needs for a single sensor.  Finally, thinking of the sketch being event-driven and doing other things, we'd want to give the ATmega other time to do other things in the sketch other than just ping the sensors.

Your situation is a bit different as you have so many sensors.  A complete sweep at 29ms would take 464ms, so you can only do about 2 sensor sweep cycles per second.  That may be fast enough, and allow time for your sketch to do the other things it needs to do.  Then again, maybe you need it to sweep faster.  The 8ms came from testing of a simple 2 sensor system (pointed in opposite directions) in a small room environment.  At 8ms, it still gave accurate readings without cross-sensor echo.  At 7ms, I started getting random results.  This test by no means is the final decision that 8ms between pings is safe.  It was just what I saw in my test.

For your robot, I would change the ping cycle to trigger the sensors on opposite sides of the robot and rotate around (like drawing a star).  That way, you could limit the possibility of cross-sensor echo and thereby lower the ping rate.  29ms should work really well and I doubt that you could get 8ms to work as reliably as 29ms.  But, maybe somewhere between 29 and 8 will work perfectly for your situation.  It also depends on how fast you need to cycle through the sensors.  If 2 sensor sweeps per second is fast enough, leave it at 29ms.  This gives your sketch more time to do other things than if you tried to make it 8ms.

Tim
My platforms Arduino, Teensy 3.2, Arduino Pro Mini, ATmega328
My libraries: NewPing, LCDBitmap, toneAC, toneAC2, NewTone, TimerFreeTone
My projects: https://dogblocker.com & https://baconorbeer.com
My beer: Great Lakes Brewing Co. Lake Erie Monster

#### teckel

#107
##### Jun 21, 2012, 11:38 pm
FYI, further testing and I'm having problems with the combination of a SRF06, using one pin, and using the Teensy hardware.  It works, but only about half the time.  I'm going to try a few things this evening and I'll let everyone know the results.  The plan is to post the new release in the forum for people to test before I release this version.  Specifically, testing it using only one Arduino pin.

Tim
My platforms Arduino, Teensy 3.2, Arduino Pro Mini, ATmega328
My libraries: NewPing, LCDBitmap, toneAC, toneAC2, NewTone, TimerFreeTone
My projects: https://dogblocker.com & https://baconorbeer.com
My beer: Great Lakes Brewing Co. Lake Erie Monster

#### snailshoe

#108
##### Jun 23, 2012, 06:20 am

Great work on the library! I thought I might use this thread for a bit of troubleshooting.

My HC-SR04 is doing some very bizarre things and I'm lost. When using newPing and it's included newpingexample sketch, the sensor returns "0 cm" and there is no reaction to changes in proximity to objects. I tried using the simplest code I could find which doesn't require libraries (pasted below), but the same thing happens, this time reporting strange negative distances (-39 through - 45). I've found that changing the voltage supply effects the numbers, but only once did I get it to correctly report distance and very briefly. Is it possible the sensor has been damaged in some way? I'm using an Uno Rev 3 and a macbook pro (10.6.8 ) for config.

If the unmodified NewPingExample sketch or the sketch you posted don't work, I would guess it's a faulty sensor.  It seems you're doing everything correctly.

Tim

I am having the same problem with two of my HC-SR04s. All I'm getting is a reading of 0cm regardless of what's in front of the sensor. These sensors both work with a different ultrasonic library. Does anyone have an idea of what may be causing this?

#### duxiaoshi

#109
##### Jun 23, 2012, 04:27 pm

yeah, it works when change PING_INTERVAL from 35 to 29.

And now one sonar in the front of bot is not assembled well. so I have only one sonar in the front and one sonar in the back.
I test two sonars on opposite sites of my bot,  with the PING_INTERVAL of 8 ms, and it work.
So i'll modify my code later to shorter the time.

and i have a question that where 35ms , 29ms,  8ms come from ,how it calulate.  The max distance is 2m, so the time of echo is  (2/340) * 2 = 12ms

The time calculations have nothing to do with what you set as the maximum ping distance.  Even if you set a max ping distance to 25cm, the sensor doesn't know that or do something differently.  All that happens is the library will only care about ping echo's within the 25cm range.  What still happens is the sensor sends out a ping and listens for an echo.  That ping echo can be detected from up to 400cm to 500cm away.

So, when one sensor sends out a ping, it can travel up to lets say a maximum of 500cm bounce, and come back and hit a different sensor that you may be reading for a ping echo at the time.  This would be cross-sensor echo.  When calculating the time, you always look at the sensor's maximum detection distance (lets say 500cm as that's what most spec).  500cm * 2 * 28.5uS/sec = 28,500 uS.  There's also around 450uS of delay before a ping starts with the SRF05, which works out to right around 29ms.  In theory, if a sensor is really only able to detect a ping at a maximum distance of 500cm, you could have two sensors right next to each other and ping at 29ms intervals and you should never get any misreadings from cross-sensor echo.

I typically say to ping every 33 to 35ms as a bit of a buffer, just to be sure.  Also, 33ms works out to 30 pings/second which is typically well faster than anyone needs for a single sensor.  Finally, thinking of the sketch being event-driven and doing other things, we'd want to give the ATmega other time to do other things in the sketch other than just ping the sensors.

Your situation is a bit different as you have so many sensors.  A complete sweep at 29ms would take 464ms, so you can only do about 2 sensor sweep cycles per second.  That may be fast enough, and allow time for your sketch to do the other things it needs to do.  Then again, maybe you need it to sweep faster.  The 8ms came from testing of a simple 2 sensor system (pointed in opposite directions) in a small room environment.  At 8ms, it still gave accurate readings without cross-sensor echo.  At 7ms, I started getting random results.  This test by no means is the final decision that 8ms between pings is safe.  It was just what I saw in my test.

For your robot, I would change the ping cycle to trigger the sensors on opposite sides of the robot and rotate around (like drawing a star).  That way, you could limit the possibility of cross-sensor echo and thereby lower the ping rate.  29ms should work really well and I doubt that you could get 8ms to work as reliably as 29ms.  But, maybe somewhere between 29 and 8 will work perfectly for your situation.  It also depends on how fast you need to cycle through the sensors.  If 2 sensor sweeps per second is fast enough, leave it at 29ms.  This gives your sketch more time to do other things than if you tried to make it 8ms.

Tim

really busy these days. I have test 8ms intervals, and these is no cross echo, works well. I ping the oppsite sensors one by one ,so 8ms is enoungh, and 14 sensors can
be read in a very very short time. Nice work!
I'd like to look through the NewPing library again after i finish my project this month. Really good library and thanks again.

#### snailshoe

#110
##### Jun 24, 2012, 05:10 amLast Edit: Jun 24, 2012, 04:32 pm by snailshoe Reason: 1

Great work on the library! I thought I might use this thread for a bit of troubleshooting.

My HC-SR04 is doing some very bizarre things and I'm lost. When using newPing and it's included newpingexample sketch, the sensor returns "0 cm" and there is no reaction to changes in proximity to objects. I tried using the simplest code I could find which doesn't require libraries (pasted below), but the same thing happens, this time reporting strange negative distances (-39 through - 45). I've found that changing the voltage supply effects the numbers, but only once did I get it to correctly report distance and very briefly. Is it possible the sensor has been damaged in some way? I'm using an Uno Rev 3 and a macbook pro (10.6.8 ) for config.

If the unmodified NewPingExample sketch or the sketch you posted don't work, I would guess it's a faulty sensor.  It seems you're doing everything correctly.

Tim

I am having the same problem with two of my HC-SR04s. All I'm getting is a reading of 0cm regardless of what's in front of the sensor. These sensors both work with a different ultrasonic library. Does anyone have an idea of what may be causing this?

Well, I tried the 15 sensor example, changed it for only one sensor, used different pins other than the default 12 and 13 and it works.  But the standard example one doesn't work for mine. Don't know why.

#### teckel

#111
##### Jun 25, 2012, 04:39 pmLast Edit: Jun 25, 2012, 05:49 pm by teckel Reason: 1

I am having the same problem with two of my HC-SR04s. All I'm getting is a reading of 0cm regardless of what's in front of the sensor. These sensors both work with a different ultrasonic library. Does anyone have an idea of what may be causing this?

First, try using the example sketch below, it's the new example that's being included with NewPing.  Be sure you have the trigger and echo pins wired correctly.  Don't change anything in the example, even the pins used.

Also, when you say you have a problem with two sensors, does that mean you have other sensors that work and two that do not?  I've found the SR04 sensors tend to have a terrible quality control.  Of the 4 that I have, only 1 I would say works correctly.  The other 3 work, but get all wonky at distances beyond 50cm.

Finally, just to make sure we're both using the same library, attached is my development version of NewPing (v1.4 pre-release).  Just replace these files with the ones already in the NewPing folder.

Tim
My platforms Arduino, Teensy 3.2, Arduino Pro Mini, ATmega328
My libraries: NewPing, LCDBitmap, toneAC, toneAC2, NewTone, TimerFreeTone
My projects: https://dogblocker.com & https://baconorbeer.com
My beer: Great Lakes Brewing Co. Lake Erie Monster

#### deverett

#112
##### Jun 28, 2012, 05:26 am

I've only been keeping up now and then on this thread; I have yet to try the library, but I have to say it seems like an awesome improvement. I was wondering, though, if you were planning on:

1) Adding the original PING sensor from Parallax to it
2) Add code for the Polaroid/Senscomp 6500 sensor

I believe the Parallax PING))) sensor would almost work with my library as-is.  The only difference would be that the trigger/echo pin would need to switch from input to output as the same pin is used for both.  I don't have the sensor to test this, but it appears software-wise the interface is identical except for using a unified pin for both trigger/echo.  It would only need a few lines of code modification, and it would be easy to automatically detect that it was a PING))) sensor when the same trigger and echo pin was specified.

If someone has this sensor, I'd be more than willing to make a slight modification to the library for you to test.

The Polaroid/Senscomp 6500 sensor also seems to be similar to the SR04.  It does appear that there could be a slight trigger difference (leave the trigger high while sensing?).  Again, I don't have this sensor to test.  But, this sensor also appears to be not nearly as popular.  I can't even find an Arduino library for it.

Maybe the Maxbotix sensors should be done instead...?

I believe the MaxBotix MaxSonar sensors use an analog, PWM, and serial interface.  None of which really match well with the current library interface method.  Serial (like I2C) would be out for sure, but it would be possible to implement an analog or PWM interface.  Again, I don't have this sensor so I can't really do much with it.  Someone have one willing to loan me for a couple weeks?

Also, there's other ultrasonic sensors that use the a I2C interface.  These I don't currently plan on supporting.  Not because there's anything wrong with them, but because each sensor's I2C commands are totally different.  Maybe a PingI2C library just for these sensors that are specialized with the proper commands for each sensor.

Tim

I have 8 sonars on my robot, all SRF05 which I want to use in single pin mode. I'd be happy to test out a single pin version of the new library.

Dave Everett

#### snailshoe

#113
##### Jun 28, 2012, 06:10 amLast Edit: Jun 28, 2012, 06:34 am by snailshoe Reason: 1

I am having the same problem with two of my HC-SR04s. All I'm getting is a reading of 0cm regardless of what's in front of the sensor. These sensors both work with a different ultrasonic library. Does anyone have an idea of what may be causing this?

First, try using the example sketch below, it's the new example that's being included with NewPing.  Be sure you have the trigger and echo pins wired correctly.  Don't change anything in the example, even the pins used.

Also, when you say you have a problem with two sensors, does that mean you have other sensors that work and two that do not?  I've found the SR04 sensors tend to have a terrible quality control.  Of the 4 that I have, only 1 I would say works correctly.  The other 3 work, but get all wonky at distances beyond 50cm.

Finally, just to make sure we're both using the same library, attached is my development version of NewPing (v1.4 pre-release).  Just replace these files with the ones already in the NewPing folder.

Tim

At the moment, I only have the two sensors. There seems to be something wrong with one sensor. It works fine by itself, but as soon as I apply power to the second sensor, the reading of the first sensor shows that something is 5cm away. If I take power away from the second, the first sensor then works fine. With the new library and example sketch, everything else seems to be working. I'll have to get some more of the HC-SR04s and try them out.

#### teckel

#114
##### Jun 28, 2012, 06:50 am

I have 8 sonars on my robot, all SRF05 which I want to use in single pin mode. I'd be happy to test out a single pin version of the new library.

I attached the version of the library that works with only one pin to the message right before your post.  Here's a link to that message (two links at the bottom of the message):

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

For testing, you may want to start with communicating directly to all the sensors without the rest of the bot sketch.  I have a sample 15 sensor sketch that you could easily modify to test your 8 sensors.  The sketch can be found here:

For 8 sensors, you would change SONAR_NUM to 8 and the "sonar" array to only have 8 NewPing objects.  To make them only use one sensor, simply make the trigger and echo pin numbers the same.  For example:

Code: [Select]
NewPing sonar[SONAR_NUM] = {
NewPing(3, 3, MAX_DISTANCE),
NewPing(4, 4, MAX_DISTANCE),
NewPing(5, 5, MAX_DISTANCE),
... complete for rest of sensors ...

After the test is complete, you could then update your full bot sketch to work with the NewPing library.  For a simple non-event-driven example of how to implement the NewPing library, see this very basic "hello world" sketch (again, make the trigger and echo pins the same for one pin wiring):

That is, unless your current bot sketch is already event-driven, in which case you may want to look more at the 15 sensor example sketch for how to implement it in your project.

Just so you know, I've tested this release with 5 sensors using only one Arduino pin each and it worked without a hitch.  The only exception is the SRF06 which needed a 0.1uf cap across trigger and echo.  So, if it works for 5 there's no reason it shouldn't work for 8 sensors.

Tim
My platforms Arduino, Teensy 3.2, Arduino Pro Mini, ATmega328
My libraries: NewPing, LCDBitmap, toneAC, toneAC2, NewTone, TimerFreeTone
My projects: https://dogblocker.com & https://baconorbeer.com
My beer: Great Lakes Brewing Co. Lake Erie Monster

#### teckel

#115
##### Jun 28, 2012, 06:58 am

At the moment, I only have the two sensors. There seems to be something wrong with one sensor. It works fine by itself, but as soon as I apply power to the second sensor, the reading of the first sensor shows that something is 5cm away. If I take power away from the second, the first sensor then works fine. With the new library and example sketch, everything else seems to be working. I'll have to get some more of the HC-SR04s and try them out.

You're not sharing pins to both sensors are you?  Or having the sensors face each other?

When you say as soon as you apply power to the second sensor, what exactly do you mean?  Do you have a sketch that's connected to these two sensors?  Could you share the sketch?

What it sounds to me like is that you're doing two things at once, or have two sensors connected together.  So each work on their own, but as soon as you try to use both there's a failure.  Seeing your sketch and how you have them wired up would help greatly.

For testing multiple sensors at once, I would suggest using the 15 sensors test sketch found here:

For 2 sensors you would change SONAR_NUM to 2, and the "sonar" array would be changed to something like this:

Code: [Select]
NewPing sonar[SONAR_NUM] = {     // Sensor object array.
NewPing(12, 11, MAX_DISTANCE), // Each sensor's trigger pin, echo pin, and max distance to ping.
NewPing(10, 9, MAX_DISTANCE)
}

Obviously, the pins would need to be correctly entered or changed to match.

Tim
My platforms Arduino, Teensy 3.2, Arduino Pro Mini, ATmega328
My libraries: NewPing, LCDBitmap, toneAC, toneAC2, NewTone, TimerFreeTone
My projects: https://dogblocker.com & https://baconorbeer.com
My beer: Great Lakes Brewing Co. Lake Erie Monster

#### deverett

#116
##### Jun 28, 2012, 03:43 pm

I have 8 sonars on my robot, all SRF05 which I want to use in single pin mode. I'd be happy to test out a single pin version of the new library.

I attached the version of the library that works with only one pin to the message right before your post.  Here's a link to that message (two links at the bottom of the message):

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

For testing, you may want to start with communicating directly to all the sensors without the rest of the bot sketch.  I have a sample 15 sensor sketch that you could easily modify to test your 8 sensors.  The sketch can be found here:

For 8 sensors, you would change SONAR_NUM to 8 and the "sonar" array to only have 8 NewPing objects.  To make them only use one sensor, simply make the trigger and echo pin numbers the same.  For example:

Code: [Select]
NewPing sonar[SONAR_NUM] = {
NewPing(3, 3, MAX_DISTANCE),
NewPing(4, 4, MAX_DISTANCE),
NewPing(5, 5, MAX_DISTANCE),
... complete for rest of sensors ...

After the test is complete, you could then update your full bot sketch to work with the NewPing library.  For a simple non-event-driven example of how to implement the NewPing library, see this very basic "hello world" sketch (again, make the trigger and echo pins the same for one pin wiring):

That is, unless your current bot sketch is already event-driven, in which case you may want to look more at the 15 sensor example sketch for how to implement it in your project.

Just so you know, I've tested this release with 5 sensors using only one Arduino pin each and it worked without a hitch.  The only exception is the SRF06 which needed a 0.1uf cap across trigger and echo.  So, if it works for 5 there's no reason it shouldn't work for 8 sensors.

Tim

Thanks Tim, I wasn't logged in before so I couldn't see the attachments. I'm currently rewiring with shielded cable to all the sensors so I hope to test the code late tomorrow. As you suggest it will be just the multi-sonar sketch trimmed down to 8.

I'll let you know the results.

Thanks again,
Dave Everett

#### deverett

#117
##### Jun 29, 2012, 07:11 am
Tim,
So far everything is working fine with the single pin version. I've only had time to wire up 2 of the sonars so far.

Dave

#### teckel

#118
##### Jun 29, 2012, 02:17 pm

Tim,
So far everything is working fine with the single pin version. I've only had time to wire up 2 of the sonars so far.

Dave

Basically, because the library is designed specifically to communicate with ultrasonic sensors instead of using stock commands like pulseIn, it waits for all the correct pin states between the trigger and echo stages.  So, it can both trigger and echo using the same Arduino pin because the output and input stages are clearly defined.

The idea came when I wired a sensors incorrectly (trigger and echo pins reversed) with no ill effect while looking at adding support for the Ping))) sensor which only uses 1 pin for both trigger and echo.  I knew it wouldn't break anything to try (from my incorrect wiring experience) and it also seemed logical that the sensor was only ever listening for a trigger during certain situations and only sending an echo output during other situations.  Sure enough, I believe 3 lines of code were modified and it worked perfectly.

On projects where you have multiple sensors (which many have) reducing the number of pins needed by half is huge.  Projects that at once needed a large Arduino Mega could be done with a thumbnail-sized Teensy 2.0.

Keep us updated!

Tim
My platforms Arduino, Teensy 3.2, Arduino Pro Mini, ATmega328
My libraries: NewPing, LCDBitmap, toneAC, toneAC2, NewTone, TimerFreeTone
My projects: https://dogblocker.com & https://baconorbeer.com
My beer: Great Lakes Brewing Co. Lake Erie Monster

#### Human

#119
##### Jun 29, 2012, 08:39 pmLast Edit: Jun 29, 2012, 09:16 pm by Human Reason: 1
I wanted to add that I have a HC-SR04 that doesn't work with NewPing 1.2, 1.3, or the 1.4 pre-release, using either the Simple NewPing Example Sketch or the 15-sensor example, modified for 1 HC-SR04.  It works fine with the example code at http://goo.gl/kJ8Gl though.

How can I help debug the library for the HC-SR04?

EDIT: Forgot to add that I'm using an Arduino Uno r3 with the v1.0 Arduino IDE.

EDIT2: I get 0cm like everyone else with an HC-SR04 reported. I even tried getting the raw timing data instead, in case it was an obscure bug in the distance conversion. Everything I get is 0.

EDIT3: In case it's helpful, I note that I can hear the HC-SR04 sending out its sonar pings when I try NewPing. So I would guess that the bug doesn't involve actually sending out the pings.

Go Up