Hello all, I am using the Ping-2 sonar for underwater Obstacle Avoidance in USVs. I was wondering if there is a way I can get the time delay between sending a pulse, and first strongest return through the APIs.
Hi @dskumar -
Your question is a bit confusing - the Ping sonar returns a distance measurement and confidence %. The distance measurement is calculated based on the time delay between pulse and first strongest return you describe. The frequency of this measurement depends on the device configuration - auto vs. manual, and what the maximum range has been set to in manual.
Have you operated the sonar in PingViewer to familiarize yourself with the data and available settings?
Yes, I am familiar with the Ping Viewer and everything it can do. I am not working with ping-viewer, rather I am using the cpp API you guys provide. I am essentially treating the Ping 2 as a blackbox, because I do not know what the algorithms are running inside the ping. Your documents do mention running a tracking algorithm, which I suspect is messing up the obstacle detection when mounted forward- facing on a moving USV. Hence I wanted to look at time delays, profile data etc to see if I can improve the obstacle detection algorithm on my end. Currently the sensor is connected to Rpi and talking over UART.
Currently, the sensor randomly sees high distances, if my boat is moving faster than 1.5 m/sec the sensor does see the obstacle in front but the detection is pretty slow. By slow I mean, within the time frame the sensor detects the obstacle with decent confidence(>20%) the boat has breached the 2m margin to the obstacle and ends up slamming into the obstacle. Yes, I can increase the margin, but we are more focused on operating with tighter margins.
I have tried to increase the sampling rate, by putting the sonar in manual mode, setting the ping frequency to 67ms. I would also appreciate any suggestions you may have to increase the sampling rate.
Hi @dskumar
You’re correct - the Ping firmware is filtering the measurements. Currently that is a closed-source firmware, but it will soon be made available for user customization!
Even once you can make modifications, I’d point out that the limitation you’re running into is likely more related to the speed and potential presence of bubbles near the sonar. It’s expected that at high speeds, or if the unit is too close to the surface, that turbulence and bubbles would greatly reduce the confidence in measurements because the sound reflection is getting wonky!
Yea, that’s what I thought, too. Any suggestions you may have to get a better sampling rate is appreciated.