We’ve been running into a recurring issue with the Ping2 sonar on your Blue Boat. We’ve used your sonar products on custom-built ASVs before and didn’t experience this, but with the Blue Boat, the logs are showing 0 values, like data drops. This happens consistently when we run the boats in shallow water (around 1 to 4 meters).
Both of our Blue Boats are running the latest stable firmware, and the issue shows up in the logs for both. I usually just interpolate over the 0 values, but I’d rather find a better solution if possible.
Could this be caused by something like shallow water reflections, interference, or maybe how the Blue Boat integrates with the sonar? If there’s a firmware update, hardware adjustment, or best practice that might help, I’d appreciate any guidance you can offer.
Sorry to hear you’re having issues with your sonar reading consistency.
This thread may provide some insight, and this comment discusses DVLs but is quite relevant to reflective sonar technology more generally.
As a starting point I’d recommend trying to look at the profile data in Ping Viewer to see whether there are indications of how/why it is losing its distance estimate. If you have a known maximum depth of water then you may be able to avoid some of the drop-outs by disabling auto mode and setting a maximum scan range so it doesn’t try to search outside of that
Hey Eliot,
Thank you for your response! I truly appreciate the insight and I’ll take a closer look at the post you mentioned. Interestingly, the issue seems to occur consistently across the datasets rather than being tied to a specific event.
I’ll attach screenshots from the UAV log viewer to provide additional context. For reference, this issue has been present since the initial deployment of both boats.
Let me know if you have any further thoughts or suggestions based on this information. Thanks again for your help!
Hi @BigBlue83 -
What survey speed are you operating at? Can you show a graph of the confidence estimate vs. time? This may not be in the .bin log, but if you use the simple ping survey extension it will be logged…
Are you using the standard mounting hardware for the sonar? How many batteries are on board, and do you have any other significant payload weight added?
Thanks for your response, and I apologize for the delayed reply. I’m usually out of town twice a week taking a modeling course for school.
This mission was fully autonomous.
Can you show a graph of the confidence estimate vs. time?
We’re not using the Simple Ping Survey extension yet. We’re currently pulling data directly from the .bin files collected during the mission. However, I’ve created a graph of the depth values and quality percentage over time for your reference:
Hi @BigBlue83 -
It looks like the sonar is reporting 0 confidence every time the measurement is bad - this should make filtering quite easy, as you can exclude all measurements without 90% confidence (or higher.)!
This is likely a fundamental limitation, but may be possible to tune out. The generally shallow depths don’t help the situation much… It would be interesting to see if the bad data coincides with the unit pivot turning - this can often cause some bubbles to be generated and pass under the sonar, impairing the measurement. The steering parameters could be tuned to make this less violent, but then the vehicle would navigate the route less strictly…
If extracting the data from the bin log is a hassle, the simple ping survey extension makes a great alternative!
Otherwise, checking out the raw ping data during a survey in realtime is the best troubleshooting step - you can use PingViewer or try the new Ping Viewer Next extension that’s recently been made available in the BlueOS extension manager! Manually setting the maximum range may help the unit lose confidence less frequently…
I’d be surprised if the issue were due to bubbles impairing the data. The data collection outputs wouldn’t consistently report a 0 value with 0% confidence in that case—I’d expect more erratic behavior instead.
From my experience, reflections caused by bubbles or proximity to objects typically result in drastic, fluctuating bathymetry changes rather than consistently settling at zero. I’ll definitely test this further the next time we put the boat in the water to see if it’s tied to any specific event.
We’ve done similar work before, even with our own autonomous systems using Blue Robotics components, and it’s surprising to see what looks like data packet drops. In the “Depth” parameter of the .bin file, these zero values appear to be amended. Interestingly, we’ve never encountered these issues when using RNFD.dist with the Ping system previously.
I wasn’t sure if your approach involves interpolating over those values or simply excluding low-confidence data entirely.
I also plan to install those extensions in the next couple of weeks. I think they’d be really helpful for new folks to visualize what the sonar is actually doing in real time.
I truly appreciate your patience and love exploring the science behind the amazing things you folks create.
Hi @BigBlue83 -
Happy to help! I’ve definitely seen a pivot turning BlueBoat exhibit this behavior of losing bottom lock and reporting 0 / 0 confidence… hence my suspicion!
The behavior may be different for rangefinder.dist, I’m not sure what filtering ArduRover may be doing with that…
I typically just drop values that have 0 confidence when making a map, as detailed in our guide.