No converging to planned trajectory during AUTO survey mission

[MatteoBucci (Matteo)]

Hi,
During a recent survey mission I observed that the vehicle is not correctly following the planned trajectory. As shown in the attached image, the vehicle does not converge back onto the planned line after the turn but instead remains consistently offset to the right of the intended path.

This behavior is unexpected, since in previous missions the vehicle was able to follow the survey lines accurately.

System configuration: Platform: BlueBoat | BlueOS version: 1.4.3 (stable release) | Cockpit version: 1.17.0 | Navigation mode: AUTO mission

Survey parameters: Line spacing: 2 m | Vehicle speed: 1.5 m/s

At this link : SwissTransfer - Send large files securely and free of charge

• the MAVLink parameter file

• the .bin log file from the mission

During this survey I was also operating a Cerulean Surveyor 240-16 MBeam. Normally my surveys are consistent and the outbound and return swaths match well. However, in this case, as shown in the attached figure, in some areas I observe a vertical offset between the outbound and return swaths of approximately 30–40 cm.

I would like to understand whether this discrepancy could be related to a sensor issue or a configuration parameter affecting the vehicle navigation or sensor integration.

For positioning I am using a Leica GNSS receiver in NRTK mode, so the expected positioning accuracy should be at the centimeter level.

Thank you in advance to anyone who can provide a prompt response, as this was my first commissioned survey project and I need to deliver results within a short timeframe.

[tony-white]

Hi @MatteoBucci -
Without sitting down to look at your logs (yet), I would guess that survey speed was a bit fast for the conditions - were strong winds, waves or currents present?
As for the multibeam data, it looks like your tracks are far enough apart that at that depth, you don’t have overlap?

Checking your compass calibration seems acurate from the compass page in vehicle setup would be a good idea! Assuming you’re using fancy GPS for only position…

[MatteoBucci (Matteo)]

Hi @tony-white

The survey was conducted in a lake (dimension around 80*160m), so there were no wind-driven currents or significant wind during the acquisition. The only disturbance present was a small wave pattern generated between the outbound and return lines, which tended to break near the shoreline. (At this link SwissTransfer - Send large files securely and free of charge you can also find a video showing the outbound and return passes of the BlueBoat during the survey)

Regarding the compass, we are currently using only one compass, and it has been calibrated. I am attaching a screenshot of the calibration status.

The multibeam image I previously shared was a side view of the seabed. To better explain the issue, I am attaching 3 additional images.

• In the second image (top view), the red swath represents the line approaching the right shoreline, while the yellow swath represents the line moving away from it.
• When looking at the data in side view, it becomes clearer that on the flat seabed the depths match quite well, but as soon as the slope begins the two swaths start to diverge, before converging again when the vehicle turns. The maximum vertical difference observed is approximately 40 cm.
• Additionally, I also performed a manual cross line, which you can see in the 4° figure in magenta.

Any insight into what might cause this behaviour would be greatly appreciated.

[tony-white]

Hi @MatteoBucci -
You may want to calibrate your compass again, the desired vs. actual yaw doesn’t look ideal to me at least?

I notice that every turn has a good degree of z-height oscillation as well - perhaps measuring it bouncing in its own wake?

It looks like your EK3_posZ source is correctly set to GPS at least, so no barometer interference from the hulls flexing!

As for the sonar data, I’m not sure if what you’re seeing is a symptom of GPS accuracy being poor in the z direction, or something related to the acoustic performance, or a combination of the two. @ljlukis may have some insights but 40cm doesn’t seem like much error to me - what was the water depth? It looks like the magenta data on the cross line more closely follows the yellow data taken as you moved away from shore?

[MatteoBucci (Matteo)]

Hi @tony-white ,

Thank you for the feedback. I will proceed with performing a new compass calibration as you suggested.
The lake’s depth reaches a maximum of approximately 8 and a half metres

Regarding the GNSS, during the entire survey the vertical (Z) values from the receiver show a maximum deviation of about 7 cm, so I do not think that the GNSS vertical accuracy alone could explain the discrepancy observed in the multibeam point cloud.

However, while analysing the data more carefully I noticed an interesting pattern.
On the left side of the sloping area, the outbound line (red) appears higher than the return line (yellow) (see Figure 1). On the right side of the slope, the situation seems to be reversed (see Figure 3).

This made me wonder whether the issue could be related to a temporal synchronization mismatch between the GPS data and the multibeam data?

Do you have any recommendations on how to verify whether there might be a time synchronization offset between the navigation data and the multibeam measurements?

Additionally, in other parts of the survey the cross line appears more centered between the two swaths, as shown in the figure.

Thank you again for your support.

[MatteoBucci (Matteo)]

Hi @tony-white ,
today I tried to recalibrate the compass as you suggested.

1. When I try to calibrate all three detected compasses (IST8308, MMC5883, AK09915), the calibration immediately fails with MAV_RESULT_FAILED, as shown in the attached pictures.

If I select only the IST8308, which should be the external compass on the GPS, the calibration starts and reaches about 98% with a fitness around 4 mGauss, but it never completes and eventually gets cancelled.

I also tried:

• rebooting the autopilot

• calibrating in an open area away from metal

• moving the vehicle through all axes

Additionally, until about 10 days ago we were running BlueOS 1.5.0-beta. Following your suggestion in the previous discussion, I downgraded to BlueOS 1.4.3, and these calibration attempts were done on that version.
At the moment, the only enabled compass is the IST8308. Do you have any idea what could be preventing the calibration from completing successfully?

2. Regarding the other issue (the offset between survey lines), I ran some additional tests today. The mismatch is visible in the passes that approach the bank perpendicularly and move away from it perpendicularly. I repeated the survey over the same area at different speeds: 2.0, 1.5, 1.0, and 0.6 m/s.
   I consistently observe that over flat bottom the adjacent lines match well, but as soon as the vehicle enters a sloped area, the lines start to separate. Specifically, the lines acquired in opposite directions of navigation begin to diverge. Then, when the vehicle slows down for the turn, they align again.
   The discrepancy increases with higher speed, but it is still present even at 0.6 m/s, although to a smaller extent.

Based on these tests, I do not think this is caused by incorrect sensor offsets, vehicle speed alone, or heading errors.

My suspicion is that the GNSS position and the Cerulean depth data may not be perfectly time-synchronized, as if there is a delay between them.

If I look at a section of the reservoir along the vehicle track, it looks as if the two bottom profiles are shifted along the direction of motion. Then during the turn they match again, likely because the vehicle is nearly stopped.
On the other hand, in areas where the survey lines are parallel to the bank, this problem does not appear.

I would also like to ask which parameters or logs I should check to verify whether there might be a time synchronization issue between the navigation data and the Cerulean depth measurements?
The GNSS currently used outputs position updates at 20 Hz.
Does EKF3 estimate the vehicle position continuously, or does it maintain an update rate tied to the incoming GNSS data?
Could a delay between the GNSS position and the Cerulean depth data cause the kind of spatial shift I am observing on sloped areas?

3. I would also like to ask if you know of other users integrating this system with high-precision GNSS and whether they are achieving consistent bathymetric geometry, for example with around 10 cm accuracy in water depths up to about 10 m?

Thank you if you can help with this.

[tony-white]

Hi @MatteoBucci -
The overall deviation in the log file for altitude is much greater than 7cm! See the second plot I shared from your log?
Can you share what version of SonarView you were running?

For your compass calibration, give the latest 1.5 beta install a go and try again. If possible, route any additional payload wires as far away from your compass as possible.

As for the delay you’re sensing, I don’t think it is caused by anything inherent to ArduSub and BlueOS, but perhaps some latency of the sonar itself? I wouldn’t recommend surveying faster than 1 to 1.2 m/s in general? Does the affect get worse as speed increases?

The EKF is running at 400hz, and take updates from the GPS at whatever rate.

Can you confirm what version of ArduRover you’re running (under Autopilot Firmware)

To better understand the potential accuracy of the system, please reach out to Cerulean Sonar. We’re not sonar (or survey) experts! Knowing the depth range you’re testing in would be helpful, as the accuracy is specified as a % of that range.

What ping-rate are you running the Surveyor at? Can you share a sonar log file that illustrates the issue?

[MatteoBucci (Matteo)]

Hi @tony-white ,

regarding the altitude value, we had already discussed this in another thread:
https://discuss.bluerobotics.com/t/bin-logs-gps-raw-data-and-ekf3-outputs/22320
From the logs it seemed that AHR2.Alt follows the barometer, while GLOBAL_POSITION_INT.alt follows the GPS Z value.
If I understood correctly, does this mean that the EKF still uses the GPS altitude as the vertical reference?

I am currently running SonarView 1.14.39 and ArduPilot 4.6.3 (stable)

For the compass calibration I will try again as suggested. At the moment the payload cables are already routed under the batteries, away from the compass.

Regarding the misalignment between survey lines, you are correct: the effect increases with speed, although it is still visible even at lower speeds.
In that survey area the maximum depth was about 8.5 m, and the Surveyor ping rate was set to 20 Hz.

At the following link SwissTransfer - Send large files securely and free of charge you can find the original SonarView files . svlz and a CloudCompare .bin file, where I separated the point clouds by survey lines in the two navigation directions and generated the corresponding surface mesh

I also attchaed a cross-section where a structure on the seabed clearly shows the discrepancy:
(yellow and red represent the two opposite survey directions)

Thank you in advance for your help.

[tony-white]

Hi @MatteoBucci -
The system used whatever is specified for for altitude by EK3_SRC1_POSZ in the EKF. If that is set to Baro, definitely change to GPS!

At 8.5m, the error should be, at best, 1cm for Surveyor range estimates. As the effect you’re observing increases with survey speed, it does seem tied to some sort of delay between measurement and location data…
I’ll checkout those sonarview logs, thanks!

[Scott_W]

@MatteoBucci

This image in particular looks like a multibeam transducer which isn’t aligned (particularly in the pitch where the data record looks like it is either racing or lagging i.e. pitched forward or backwards) , have you done a patch test (it is basically that image)

A multibeam patch test is performed to calculate the precise angular offsets (roll, pitch, yaw/heading) and time latency between the multibeam sonar head and the vessel’s motion/navigation sensors. It calibrates the system to remove systematic errors (biases) and ensure that multiple survey lines align perfectly, providing accurate seafloor depth and position data to Correct any Misalignment Even with precise installation, small angular differences (often ) exist between the sonar head and the Motion Reference Unit (MRU), which can create large depth errors at the edge of the swath

All of my multibeam work has been off larger vessels, but I am guessing on a smaller Blueboat the drag of the transducer at different speeds may also effect the magnitude of the error you are seeing (ie the speed changeing the pitich that the vessel sits on the water and thus changing the MB record)

@tony-white

As the effect you’re observing increases with survey speed

[tony-white]

Hi @Scott_W -
Thanks for the input! I could see that being related - however the pitch and roll of the Surveyor Multibeam is sensed by an onboard IMU, and it receives yaw from the BlueBoat’s Navigator IMU (or other navigational sources plumbed to the autopilot.)
I’m not sure if SonarView has any methods to tweak the alignment as you’re referencing…

[Scott_W]

Hi @tony-white

I totally understand that but typically the lower end IMU’s don’t give the performance really needed for Multibeams

@tony-white

Surveyor Multibeam is sensed by an onboard IMU, and it receives yaw from the BlueBoat’s Navigator IMU

I can dig around for some results showing results form a Hemisphere differential GPS with IMU compared with an upgrade to the same hardware system with a Advanced Navigation MEMS and FOG-based inertial navigation swapped in for the IMU, they were really obvious in the obtained results.

Either way any IMU (of any type, quality or accuracy) won’t correct a misaligned transducer head and that’s typically why you do a patch test every time you do a new set up, to find the offsets which then make the corrections in software (or accept a 7cm deviation remember 7cm in 8.5m of water is less than 1 degree of alignment)

Scott

[MatteoBucci (Matteo)]

Hi @tony-white,
The parameter EK3_SRC1_POSZ was and still is set to GPS, as you can see from the screenshot.

However, as you also noticed in the image, the value of AHR2.Alt seems to follow the barometer.

But as I mentioned, I did some tests (reported here: https://discuss.bluerobotics.com/t/bin-logs-gps-raw-data-and-ekf3-outputs/22320) where the Z value in GLOBAL_POSITION_INT seems to follow the GPS altitude.

So I was wondering: do you think that the coordinates sent to SonarView could still be using the barometer for the Z component?

Arianna

[MatteoBucci (Matteo)]

Hi @Scott_W ,
Thanks in advance for your feedback.

I agree that the BlueBoat pitch is not constant during the survey and varies with speed. Depending on speed, the boat tends to raise the bow, and then when it gets to around 1–2 m from the waypoint it slows down and pitches down, so we probably get the opposite effect there.

My assumption is that this effect should be reduced, at least partially, by the IMU mounted on the BlueBoat and by the IMU inside the Cerulean. Of course, as you said, since these are not high-performance IMUs, I would not expect them to minimize the error the way a FOG-based system could.

Based on your experience, what level of error do you think is realistic with this kind of setup, considering maximum depths of about 15–20 m? At the moment we are not even considering a sound velocity profile. For now, we only measure the temperature at the multibeam location, then we set a fixed sound speed in the software based on that temperature.

Also, the results shown in the previous images were not corrected with any patch test because, as Tony mentioned, this cannot currently be done inside SonarView. Do you have any suggestion for software that could be used to estimate how much the data might improve after applying patch test corrections?
And in your opinion, by performing these patch tests, is it realistic to reach a significantly better survey accuracy, or do you think that, given the instrumental limits you mentioned, the improvement would still be quite limited?

Another point I am not sure about is the following: the BlueBoat EKF takes the GPS position and fuses it with the other onboard sensors, including the BlueBoat IMU, to output a corrected navigation solution. Then the Cerulean also applies its own internal IMU compensation to the multibeam data.

In your opinion, is there any chance that this could lead to an overestimation of roll/pitch because some motion is effectively being compensated twice, or is this the correct approach because the first correction is for the vehicle/navigation solution and the second one is for the multibeam measurement itself?

Thanks again for your advice.

[tony-white]

Hi @MatteoBucci -
To clear some things up - the Surveyor multibeam is ONLY taking heading (yaw) and GPS data from the autopilot, not pitch and roll, so no chance for things being adjusted for twice.

SonarView does not use the AHRS altitude, it uses the global position as source.

Have you reached out to Cerulean Sonar? I would suspect that you’re pushing the limits of accuracy and precision possible with the hardware - it is not equivalent to a $60-100k + unit in performance, even if using a precision RTK GPS system! Depending on the conditions, the real-world sound velocity profile could also be impacting the data?

[Scott_W]

Hi @MatteoBucci

Happy to give a longer answer but I’m jumping in a car for a 8hr drive, so it will have to wait for a day or so

A sort of similar answer to Tony’s a good question you should ask is what accuracy do you actually need for the work your doing, a box mean (say 1m DEM) hides alot of noise in the signal.

A fuller answer in a day or so

Scott

Scott

[ljlukis (Larry Lukis)]

Not sure how I missed this thread, but we’ve been working on this issue via the Cerulean support forum. It appears that the position data coming through via the EKF in ardupilot can effectively appear to have a time delay. It’s on the order of a couple hundred msec, but if you look at the data going upwards vs downwards on a fairly steep slope, you can see the position error as shown above.

SonarView can now compensate the position for a fixed time delay in SonarView, and we incorporate this feature into a coming release.

[MatteoBucci (Matteo)]

Hi @tony-white , thank you for the useful information.

Yes, we are already in contact with the Cerulean team, and I would also like to thank them for being very responsive and quick in addressing the latency issue.
As @ljlukis mentioned, they worked on this, and I have already tested the new software version. It seems to have resolved the problem, thanks to the ability to apply a latency correction value even to data that were already acquired. Great work!

We are aware that we are pushing this system close to its limits, but that is exactly what we are trying to do in order to obtain the best possible data from this equipment, while fully understanding that it cannot be compared to survey systems in the $100k–$200k range.

Regarding the SVP, I completely agree with you. At the moment we are not using one because we are still at an early stage with this technology, and also because we are generally working in shallow freshwater environments. However, we are already looking into how to integrate it into our workflow in the future.

@Scott_W , you are absolutely right. In our case, we need to deliver both 3D models and cross-sections. For this first project, we generated the model using a 50 cm grid cell size, which of course helps reduce part of the noise, as you pointed out. At the same time, we would still like to better understand the actual accuracy of the data, so that we can better define the real capabilities of the survey and clearly understand what kind of product we are providing to the client.

Thank you all for the support and for the valuable feedback you have shared.

[Scott_W]

Hi @MatteoBucci

This may be a bit all over the place response

Right given a “standard” IMU (for example the IMU in the Navigator (ICM-20602 with a Gyroscope sensitivity error: ±1%) and assuming the Cerulean is using something similar then in 20m of water that is ±35cm on the seafloor just from the IMU. The Cerulean Along Track TX Beam Width4° so its (sort of projecting a cone of sound at the 20m depth of around 1.4m dia) and reflecting the 1^st strong bottom hit back what is the accuracy or depth at the exact GPS Location the IMU (potential patch test issue or the area the beam is hitting the seabed?)

Given this I would sort of say the best you should really be using the instrument at 20m is around the 1-1.5m box mean average DEM .

Speed of sound is not too much of an issue as you aren’t doing IMO S-44 Order 1A’s surveys the look table is great, but the quick easy way is to remember smiley and frowny faces over a relatively flat bottom look at the cross section of the seabed and what you are seeing in the displ ay

Convex Shape (“Smiley Face”): A “smiley face” distortion (convex) occurs when the sound speed profile used is higher than the real profile, causing the outer beams to appear too shall ow.

Concave Shape (“Frowny Face”): Conversely, if the sound velocity used is lower than the actual velocity, the swath will “frown” or curl downw a rd.

@MatteoBucci

Do you have any suggestion for software that could be used to estimate how much the data might improve after applying patch test corrections?

Likely for you the open source MBSystem MB-System • MBARI would be the way to go, other professional pieces of software can do post patch test corrections as was well if you have the $’s (As a side issue it can also be used to correct the “Latency: Test for timing offsets between GPS and sonar.” For the data already collected)

Scott