I have noticed that the Ping2 mounted on my Blueboat has a time lag bug of about 1.5 to 2 seconds. I have a survey grade RTK GNSS (not ublox) mounted and it is connect to the navigator on the RP. I have attaced an image that illustrates the issue created when the ping sounding is attached to a GNSS location recored 1.5 - 2 seconds after the location of the sounding. boat travel speed is 1m/s.
Also, the ping2 using the simple ping2 survey app drops sounding at regular intervals?!
Hi @scriffij -
Welcome to the forums! Iâm excited youâre using the BlueBoat and to confirm, you used the Simple Ping Survey app to collect this data?
Can you share vehicle autopilot logs from the same mission this data was collected with, as well as BlueOS logs (found under the gear in the lower left of BlueOS)?
Iâm not sure I understand why you think the bathymetry is lagging the gps based on the âsawtoothâ pattern. To me it looks like artifacts from interpolation?
The extension is recording data at 2Hz, but this rate could be increased. Is your survey grade GPS configured for primary use in the vehicle? The extension is recording the lat/long used by the autopilot, which could be the default GPS if it is still connected and configured as the primary location source.
Thanks for the reply @tony-white
Yes we are using the Simple Ping Survey app to record the data.
We have disconnected the ublox gnss that came with the boat and disabled it in the Parameters. we use a Septentrio Asterx-m GNSS as the only GNSS connected and it receives RTK via missionplanner RTK inject.
I beleive that there is a lag in the recording of the soundings as when I reposition my depths by about 1.5 seconds in excel table, the saw tooth patten is all but gone.
@tony-white I have conducted some more testing and it apperas that when there are multiple functions happining, Simple Ping Survey Logging, Mission Planner logging, RTK inject⌠The lag in wtiting the sonar measurement to the record file is 1-1.5 seconds. when Mission Planner Logging is dissbaled and RTK inject is dissabled the lag in writing the sonar measures to the record files is about 0.25-0.5 seconds. please see the two images below.
There is a clear issuewith the performance of the RPi 4 running Ardupilot, Linix and Blue OS resources. is it possible to turn off the Blue OS system logging as well to remove as much of this lag as possible. or would a RPi 4B with 8MB ram work better?
@tony-white
I have replaced the RPi with an 8GB model and have it booting from a Samsung T7 SSD. I have also included an OEM powered USB 3.0 hub (taking power from the main rail) with four powered ports each receiving 2A. I have upgraded the the GNSS to a Holybro-H RTK with a Septentrio Mosaic-H chipset. GNSS is also getting power from main power rail not the navigator hat and the UBLOX GNSS is unplugged and dissabled.
Sequencial write speed difference:
before with SD card ~ 30000 bytes per second
now with SSD ~ 330000 bytes per second
I will be testing again either this week or next week but the RPi + SSD upgrade may have solved the issue. will confirm after testing.
Regards
Jason
We are encountering the same issue as @scriffij . During our first mission using the Ping2 with the internal software (Simple Ping), we noticed a latency of about 2 seconds.
For the second study, we connected the Ping2 to a LattePanda and performed the acquisition using Hydromagic. In this setup, the latency increased significantly to 8 seconds.
Could you help us understand the potential causes of this delay? Thanks!
Not sure whatâs causing the potential data delays, but secondary alignment of live data is a non-trivial problem which is typically best avoided where possible. One current alternative is to extract the data in post from the (timestamped) autopilot log files.
Delay getting data from the sensor itself or caused by the sensorâs internal temporal filtering is likely quite difficult to estimate (and accordingly to account for), but assuming[1] the autopilot is receiving the data without substantial latency then it will immediately write that to file with a timestamp, which itâs also doing with its positioning estimates, in which case it should be possible to get the position closest in time to each distance estimate, rather than independently fetching the latest position value at the time a distance estimate is being processed / recorded by the extension.
That same alignment avoidance should also be possible using ArduPilotâs WATER_DEPTH MAVLink message, which Iâve raised an Issue about here, but as that requires development itâs not possible for past data and thereâs no obvious timeline of whether/when it will be available.
If thereâs substantial latency between the sonar data arriving at the onboard computer and getting passed on to the autopilot then that may not be addressable without upgrading the system, although it may help to directly connect the echosounder to the autopilot (with relevant parameter configuration), rather than bridging the connection via the Ping Service. âŠď¸
Weâve been struggling with the BB for two years now. To get decent RTK we ended up replacing the Pi4/navi board with a Cube Orange and a pi 5. We replaced the entire power system with Mauch gear for dual batteries and that removed all the noise in the electronics and now get instant RTK on 4 constellations. We moved to a LattePanda Delta as well running Hydromagic and still had the delay. It varied timewise so we started using SV profiles in Hydromagic to see if that removed it rather than post process. Still have issues with the lag in soundings. We are about to replace the Ping2 (having tried two now) as that is the only thing that can be causing the problem. Its cost us hundreds of hours and a bucked load of money to testing and troubleshoot HW in this BB. What surprises me is that no one else is having this problem. It is so obvious when you produce a bathymetry DEM with contours.
We now have 4G and Starlink for remote connection running virtual machine software to connect to the windows and unix computers. I have and nice Radiomaster 16 with 2.4 and 900 for up to 5km direct control to the FC via ELRS tx and can be used as a joystick when out of range.
Some time this year we will replace the Ping2 with probably a Echologger (or similar) that is compatible with Hydromagic and has a built-in accelerometer for compensating for the boats roll and pitch.
Also the Lattepanda Delta starts throttling the CPU when it gets to about 65 degrees C inside the hull. We are moving to a different Windows SBC that can tolerate up to 80 degrees C but have not decided on which one yet.
Hi @scriffij -
Weâre still mystified by the supposed ânoiseâ issues youâve mentioned in the past, sorry you felt it necessary to re-do so much of your hardware! None of those changes should be necessary for an RTK upgrade, at least in our experience.
The most likely source for the lag in soundings is the Ping firmware - it is running a filter that inherently could cause delay. Weâve experimented with this, and an open source firmware is available that does not have this filter! It will likely fix your issue?
Roll and pitch compensation seems completely unnecessary given the 25 degree beam of the Ping - youâd have to be in pretty rough seas for the vehicle to be rolling/pitching that much!
Both the Pi 4 and Pi 5 donât have issues with thermal throttling in the BlueBoat, in our experience, even in tropical waters!
Any chance the Ping 2 is on serial interface and just isnât keeping up at 115kbaud? Ping Viewer runs it at 2Mbaud, but itâs very possible that Hydromagic does not.
As for âupgrading to Echologger,â have you considered Surveyor 240? It has integrated pitch and roll compensation, itâs supported directly by Hydromagic, and itâs a multibeam with 10x the coverage per ping, and much better resolution than the 25 degree beam width of the Ping. Available right here on The Reef.
Thanks for the tip on baudrate, in Hydromagic/LattePanda setup we indeed may have two latency sources that add up, explaining the increased total latency.
We have indeed bought the Surveyor 240, it arrived yesterday. We will soon assess its performance in a harbour with aknown bathymetry acquired by a Norbit WBMS.
