I have a minor problem with the ping data related to how gain is controlled during a dive with ardusub and this create a mismatch between ROV depth and Sonar reading. My Sonar is direclty connected to the pixhawk so I can’t manipulated the setting (gain / ping frequency) with this configuration. Changes are cause by ardusub manipulation and I would like to understand what is going on here.
The graph below show the problem with real data. The graph show the depth of my ROV (Blue dot) and the Sonar data (Green dot). At the beginning of the graph, the ROV is at the surface (0.1m) and the sonar reads about 17.5m. I then dive to the bottom and we gradually see the rov depth increase while Sonar depth decrease. So far so good. They also match when I paused at about 5m.
When the ROV reach 15m and the sonar read about 2.8 from the bottom, the Ping reading suddenly shift reaching >20m. Of course this is impossible since I was near the bottom. It’s clearly a gain or offset effect.
In red is my attempt to correct the data. Essentially, I added an offset to the data and the result (red line) is realistic. I guess.
Ardusub 4.0.3. before someone ask
Most likely the altitude distance was too short for the sonar to detect with its configured scanning range and gain, in which case the next strongest response is likely after the ping has reflected up off the bottom, down off the surface, and back up off the bottom again:
The ArduPilot ping library doesn’t seem to do any configuration of the settings, so the sonar will be operating in its default automatic mode.
I would expect the profile data to show usable signal at the range you were at, but its possible the distance estimator could be struggling there and start searching further away, especially if there are weak reflections from things like plants, fish, and particulate matter between the bottom and the sonar.
I also think it can achieve better result. During the same run, it was measuring 0.8m in shallow water. In fact I mapped almost all the lake from the surface and obtained a nice bathymetric survey. It just behave like this when I dive and reach the bottom.
And do you know what it is doing in this mode?
Can I set the unit in another mode (using ping viewer once) and assume it will use this mode all the time after that?
In other word, can it retain a configuration in it’s non-volatile memory and reproduce it at any boot up?
Fair enough. I suspect there may have been some issues with the surface and/or water conditions in the area where it missed the initial return, but it’s hard to say for sure.
I don’t have access to the source code, so not really beyond what’s in our public documentation, which is that automatic mode tries to automatically determine the appropriate gain and scan range based on the measurements it’s receiving.
No. I just tried this (with our Python library) and while Ping Viewer will remember the previous configuration of a device and re-request that when it connects, the Ping Sonar itself does not maintain its configuration across power cycles - it reverts to its default settings.
That depends on the rate it’s sending profiles, which in auto mode depends partially on the distances being measured.
It’s perhaps worth noting that if you want only the distance measurements (no profiles) but with some manually specified settings, you can use Ping Viewer (or a Python script) to connect to the sonar and set the desired settings on startup, and from there just allow the BlueOS Pings service (available from BlueOS 1.1.0-beta.9) to send MAVLink messages with the distances. The device settings are maintained until they are manually changed or the sonar is powered off.
