I am experiencing issues with the depth readings in cockpit, as it suddenly change—for example, showing 80 m and then jumping to 160 m,before returning to normal or not returning to normal. (it would appear sometimes to recalibrate on the seabed, and doubles the depth it is actually working in)
I initially thought the issue might have been due to system overload from saving video through BlueOS or cockpit, so I cleaned all stored files off both BlueOs and Cockpit, but that did not resolve the issue.
I also suspected a faulty depth sensor, so I replaced it with a new one. The following dive appeared normal, but on the second dive the same issue occurred again and as I deployed the ROV, the depth readings became erratic (e.g. 3 m, then 40 m, then 4 m, etc.).
I have tried recalibrating the sensor after retreiving the ROV to the surface, which resolved the issue for part of the next dive, but then the readings would become unstable again, showing 38 m and then jumping to 1,300–1,400 m (or similar high values or nothing near the depth I was working in).
Basically the depth reading became so unstable I had to abort the ROV survey.
I had been working with the ROV/Cockpit/BlueOS for 3 days prior to this depth reading issue, then for some reason it went faulty without me doing any change to any of the settings.
Has anyone else had similar experiences? and if yes, were you able to resolve it ?
Please share a vehicle .bin log from the log browser page in BlueOS that shows this issue. Are you using a Blue ROV2 ? Have you extended or modified the wires going to the sensor in any way? You may try re-routing the sensor cable in the enclosure to keep it farther away from the power bus bars and ESCa if possible.
If you continue to have issues, as always the help center is the correct place to tryout issues with a product that may require replacement.
Please find the Bin logs for the day I was operating the ROV and having depth sensor readings issues, I hope that these are the correct logs as the time does not seem to fully correspond to the time with when the ROV was having the issues issues .
I came across this topic and I seem to experience the same issues sometimes with Cockpit V1.17.
Looking at your two log files you provided, is it true that you’ve actually been to a depth around 14m and 19m? Atleast that’s from what I read from your log files.
The reason I’m asking is because my own log files are displaying the right depths etc throughut the dives, but cockpit is just not displaying them right. So it’s not a hardware issue, or an Ardupilot Firmware related issue, but really just an issue with how Cockpit V1.17 is handling that Depth Data to display.
@tony-white Could you verify that the log file depths are all working properly, but it’s just Cockpit V1.17 having issues with handling the depth data?
They use different sources of information, and the relative altitude indicator is generally not intended for use underwater.
There seems to be quite limited data in both of them, but especially in the first one. In both though it seems the vehicle is losing its depth and altitude estimates for extended periods, so it’s possible there’s some problem with your sensors (or perhaps that you were turning things off throughout the testing period - it’s possible the logs continue where they left off if it wasn’t overly long since the last one ended).
What kind of log files are you looking at? Can you share one?
What widget(s) are you using to display the depth?
Which values is Cockpit displaying?
This is not a problem we’re aware of, and it definitely seems like something we would have noticed during testing if it was a consistent issue. Please share more information about your setup and how you’re testing so we can advise on potential issues or try to replicate and fix the behaviour you’re seeing.
I’ll share one of my .bin files tomorrow! But also looking at @Mac1 his log files, I see that his Barometer values are not having any weird jumps in there.
I’ve been using the stock depth indicator mini widget in the bottom bar in Cockpit, so not a generic indicator with a attached data lake variable or something. Allthough I found out that when a weird depth is displayed at the depth indicator, VFR_HUD_ALT is tweaking as well and is exactly the same weird value the depth indicator is displaying (from what I can see in the Data-Lake). Although when I’m looking into the log file (.bin) of that exact moment, the barometer values seems to be accurate, giving me the absolute depth ratings.
For example, I’ve been testing in a freshwater tank which is about 120cm deep. First few minutes, nothing crazy happened, but all of a sudden the depth indicator bumps to, for example, -8.3m depth. It would not jump weirdly or whatever, but it seems that there appears a random offset all of a sudden.
Can I assume that the VFR_HUD_ALT is the correct variable that the actual Depth indicator and the HUD Depth widgets are using?
I’m currently not at my ROV setup, but I possibly have a screen recording of it happening somewhere with a corresponding log file!
Do you have some kind of positioning system, outside of just the barometer?
They technically use the AHRS2 message’s .alt field, but depending on your firmware version VFR_HUD (if it is being sent by the autopilot) should include the same data in its .alt field.
Note that the relative altitude indicator uses GLOBAL_POSITION_INT.relative_alt.
@sietse please download this temporary release and open it. Go to /menu/settings/dev and click the “Start” button to generate a MAVLink dump. 10 seconds are enough. Download the file and send here so we can check it. This way we can understand what Cockpit is receiving and why the values being shown are not correct.
PS: that link is for the Windows version. If you’re on Linux or macOS, please find your version here.
I do have a GPS and a DVL attached, but the EKF3_SRC_POSZ parameters are all set to Baro.
Check! Yeah I displayed the VFR_HUD_ALT one day when I was having the issues, and that VFR_HUD_ALT gave me the exact same values as the Depth Indicator Widget and the HUD Depth widget, so that makes sense. Allthough the Barometer (1) values were always absolute and correct values in my .bin files at that time. So that’s why I’m sceptical about the way how Cockpit actually reads / handles the data.
cockpit-mavlink-dump-2026-05-06T06-55-56-825Z.json (425.1 KB)
Cockpit gave me a .jsonl file. The forum doesn’t allow .jsonl files, so I editted the extension to be just .json so I could upload it here. Hope it doesn’t mess things up for you! I hope you could find something in the Mavlink Dump file!
EDIT:
Doing further investigation on my logfiles, I came across the following:
I’ve been displaying the Baro[1].alt, and this one seems to be always correct. No weird jumps, nothing.
Although AHR2.Alt is having some weird jumps here and there. Some of those random offset jumps are displayed here in the following photo’s.
EDIT 2:
I just did another test. Cockpit kept displaying 0m for the whole dive. In this following log, you can see Baro[1].alt is doing the right thing again. AHR2.alt is shifting a couple of times.
@sietse my friend @williangalvani, which is the ArduSub maintainer, has asked you to update your vehicle firmware to the latest stable (4.5.7). He said there were fixes around the altitude values between 4.5.3 and 4.5.7 that can be the solution here.
I’m so sorry for the JSONL log. I had it running while the ROV was surfaced (read: on the table).
I’m gonna make a new Mavlink Dump JSONL in a few hours!
We’re actually running ArduSub 4.5.7! Recently I got a client with the exact same issue going on, and he confirmed he was running 4.5.7 aswell.
The .bin logfiles of the dive, stated that there indeed has been proper depth readings by BARO[1].alt. Down below one of the log files is showed. It had the right absolute values in there etc. AHR2.Alt seems to start off properly but will shift by 4 ish meters like showing below:
I’m hoping this is an easy problem. (BlueOS 1.4.3 fwiw).
We have a BlueROV with an older Red pressure sensor. I believe the sensor gives a good absolute pressure reading all the time (e.g., it’s not swinging wildly or dropping out).
On ROV startup, the “calibrated at” value is reasonable and the calculated depth also makes sense:
We can click “calibrate” and it will momentarily show a new value, but the depth is still not correct and soon after the configure screen will show the 979hPa value. The BARO2_GND_ PRESS parameter never changes when we “calibrate” and I cannot change it through the parameter editor.
With some further checking we discovered the system continued to calculate a correct “depth” of -40m which does vary correctly as the ROV moves.
May be related to the relative vintage of the pressure sensor?
I’ve moved your post here, because it may be on the same topic.
It’s worth noting that
Could you provide a DataFlash (.bin) log from the autopilot (e.g. fetched from the “Log Browser” page), so we can try to determine whether the sensor is giving noisy readings that are causing the jumps, or something else is afoot?
Others in this thread seem to be having issues with the autopilot’s depth estimate jumping away from the estimate of the barometer, but from your description yours may be more confined to the handling/driver of the sensor itself.
@EliotBR ahha. I had discounted a faulty sensor or I2C comms error because I couldn’t see how that would change the calibration, but that now makes sense.
I’ve attached a sample BIN – the ROV was stationary in the bench, so minimal EMI – and it does have spurious pressure values for the baro[1].press
I can try some of the mitigations. Just from the nature of the outliers, any guesses on whether its a failing sensor or an I2C error. Are these consistent with a rare single bit error in the I2C stream?
