teckel:
duxiaoshi:
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.