We encountered some problems when using the sonar. When the sonar operated in a 13.5×4.9 m (L×W) sump (with the sonar approximately 0.5 m above the liquid surface), it failed to detect the pool walls. An inspection confirmed no hardware damage to the sonar. In addition, the sonar was previously able to capture part of the outline when working in another facility at a height of about 0.4 m above the liquid surface.
Hi @raccoon -
The Ping360 is intended to work in a liquid! Perhaps when you had success in the past, above the liquid surface, you had set the sound speed to the sound speed of air, rather than whatever fluid you’re working with?
Otherwise, I would suspect the sonar was actually below the liquid surface in your previous successful test…
I apologize for the mistake in my earlier statement. The sonar operated below the liquid surface in both tests—approximately 0.5 m below the surface in one test and about 0.4 m below the surface in the other.
Additionally, I would like to ask if there is a specified minimum submersion depth (in meters) required for the sonar below the liquid level.
Hi @raccoon,
Are the liquids the same in both cases?
Pure liquids like water or oil should generally work fine, as long as the density is reasonably continuous, and close enough to that of water (albeit with a speed of sound correction if you need accurate distance estimates).
Have you tried running the sonar in water to see if you’re getting reasonable responses there? If that works fine then there’s likely an incompatibility between your liquid and scanning with a Ping360 (and/or with sonar technologies in general). If there are similar problems in normal water then there’s likely an issue with your sonar device, in which case I’d direct you to our product problems form, so you can discuss possible solutions with our support team (once Blue Robotics is back from holidays).
If you have a liquid with many density transitions (e.g. there are air bubbles, large amounts of debris particles / fat, and/or a collection of liquids that don’t dissolve into each other) then it’s quite possible the sonar beams get substantially reflected or absorbed by the liquid right next to it, and there’s not enough echo strength returning from the walls to register back at the device. It may be worth adjusting the advanced configuration parameters to increase the receiver sensitivity and/or transmit power/duration, but it’s also not guaranteed that will fix the problem.
No - it should work to some extent as long as the transducer head is submerged. That said, there may be some noise / performance differences if the sonar is close enough to the surface that its beam width partially bounces off the surface before it gets to a target.
As a side note, in your “normal sonar imaging” screenshot it looks like there is substantial warping from angle and position changes. If you have a heading estimate then you should be able to feed that in to Ping Viewer using the yaw field of ATTITUDE MAVLink messages, in which case it can perform heading compensation to reduce artefacts like the acute angle at the top.
If you also have a position estimate then it is theoretically possible to compensate for that too, although that functionality is not yet available as far as I’m aware.
Wishing you a Merry Christmas and a happy, healthy, and successful New Year ahead!
Our Ping360 sonar continues to operate and image normally underwater, so it is not a device issue. Setting aside the above circumstances, I would like to discuss the problem of varying imaging effects when measuring sediment at different submerged depths within the same liquid environment. As shown in the figures, in Image 1 (taken at 1.8m below the liquid surface), the bottom silt line appears clear, while in Image 2 (taken at 1.2m below the liquid surface), the silt line appears relatively blurred. What might be causing this difference, and are there any methods to address it? Thank you very much for your response. I look forward to your reply.
1 Like
Hi @raccoon -
As noted in the technical details on the product page for the Ping360, the vertical beam width is 25 degrees, and the horizontal beam width is 2 degrees. The side view sketch below illustrates that the distance from the bottom impacts the distance the beam will travel before having a chance to reflect - when you are farther from the bottom, you can’t see the sediment layer on the bottom of the tank because the beam is not reaching it!
The sketch assumes a 3m depth tank.
It’s also worth noting that the smaller the tank, the more multi-path reflections can add noise and artifacts to the sonar return, vs. use in the open ocean…
Can you share more about what that environment is?
As per my previous response, pure, constant density liquids should have minimal sonar losses throughout, in which case echo return strengths should be relatively independent of small changes in position.
If my understanding is correct, your sonar here is oriented sideways, so it scans above and below the device (instead of in a horizontal plane). Working from that assumption:
Comparing your two images, in the right one there is a reasonably strong response from the region around the sonar, which could indicate it is in a reflective / varying density fluid (like a region of foam or lots of particulate matter) that is blocking most of the sonar transmissions from getting far, so responses from further away are muted.
In the left image, which is labelled as occurring deeper, there is a very strong response just above the sonar, which indicates there is a density transition there - consistent with there being some kind of separate, floating layer of fluid at the top of the tank. In that case, it’s also possible the right image has reduced far echo responses because the density transition is reflecting some of the returning echo away from the sonar.
To clarify this, if you are sensing through multiple fluid regions you cannot assume there is a consistent speed of sound (which is what Ping Viewer does), so for accurate distance estimates you must instead measure the speed of sound of each region, then correct for it using the profile data, including angular lensing effects from the density transitions (which you can do using Snell’s Law).
When you mention sump, I think worth noting, that acoustics have to “ring” off the surface you’re trying to detect. Some plastics (at some frequencies) don’t ring.
I’m not sure how the ping works exactly, but my point being if your working in a high noise environment (small pool) with soft (not reinforced) plastic sides may run into a problem. In general pools are actually hard to do sonar testing in, because you often have confined geometries and a lot of transmitted sound bouncing all over the place and trying to parse the primary return from the subsequent creates a challenging signal processing problem.