Hi all,
I’ve come across some very unusual issues when using the Ping360s. We have developed a visualiser and probabilistic occupancy map using the intensity returns of two Ping360s mounted on poles underneath an ASV (we are developing autonomous obstacle detection/collision avoidance using lidars above-water and Ping360s below-water). I will discuss each of the issues we are experiencing below, showing the raw UDP packets and parsed PingMessages using the ping-python library.
Firstly, and most weirdly, I am finding that occasionally, for only one of the two Ping360s we are using, the first 128 bytes in the intensity spectrum should actually be the last 128 bytes.
To demonstrate this, please see the raw data of our left and right Ping360 below.
You can see clearly that the left sonar has close to 0 values on the inside, then a ring of red (high intensity returns), whereas the right has, as one would expect, the higher intensity red centre then lower intensity water returns. It looks like the actual pattern has been bulged out - I find if we shift the first 128 bytes to the last 128 bytes, the distribution looks fine.
The first instinct with this is to simply blame parsing (maybe I somehow flipped the first 128 bytes myself in unpacking) but I am as close to certain this is not the case as possible. Below I have screenshots of the raw UDP message we receive from the sensor, and the corresponding Ping message. You’ll notice there is no packet fragmentation - the packet is fully intact, able to be unparsed and the checksum passes. The first screenshot shows our right sonar, with the expected 0xff at the start (high intensity noise from the transducer ringing that we need to ignore up to 0.7m as has been indicated on this forum), and the second shows our left sonar, which starts with mainly 0x0s with some other small values (as to be expected when sampling water). I’ve highlighted in orange when the 0x00s and 0xffs start in each screenshot.
RIGHT SONAR (WORKING):
LEFT SONAR (128 BYTE SHIFT FROM END)
This issue happens rarely but repeatedly, and when it does start it usually continues for quite sometime (until a power cycle or quite a long gap between sending transducer requests).
Secondly, we have been noticing phantom ‘crop circles’ in our spectrums (see below screenshots). I thought this may be reflections off the surface of the water or the ground, but the trig rarely works out to numbers that would be reasonable for these figures. They also happen at very inconsistent distances, including at the end of the returns array, in the middle and towards the start. They are, as can be seen, very abrupt. One working theory we have is that this might be the sonar adjusting to try to tune out noise in the air (as sometimes the sonars are running for a few minutes in the air before they are deployed) then remembering that when they get deployed to the water. I’ve noticed some patterns before with the sonars that would suggest they try to filter out baseline reflection noise. Any advice as to how to get rid of these crop circles? They are probably the most common of these three issues (and the hardest to distinguish from actual obstacles).
We have a 3D view option in our Unity visualiser, and that shows just how abrupt (and erroneous) they seem. Are they possibly also the resuult of byte offsets? For context this was when our ASV was deployed to completely open ocean.
To be fair, the inside propagation pattern (inner cone of high intensity ringing noise) and the reflection from our ASV (which is a catamaran, hence the shape) seems consistent.
Thirdly, we also often find weird radial lines of near constant low intensity reflection, and also weirdly, often at the same time in each of our two sonars. The below screenshot shows a small section of our sonar playback with the radial line appearing.
Again, we can demonstrate this comes raw from the UDP message (see below). Again I’ve highlighted the start of the return array (the 0xffs) in the raw UDP bytes and the Ping message, and also indicated the start of the radial line of constant-ish values (0x14-0x18 for one sonar, 0x21-0x27 for the other) and end of the radial line. And only a single erroneous radial return will happen (as can be seen in the screenshot) then return to a normal pattern. This happens consistently, often once every minute or so, and power-cycling or giving the sonars a break between messages does not help.
I’m wondering if anyone has seen any of these issues before and if there is any advice for operation/processing/firmware that could address these issues. Thanks!