Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DepthHUD working as intended? Adding a surface GPS introduces strange behaviour #1683

Open
samuel-reedy opened this issue Feb 10, 2025 · 1 comment

Comments

@samuel-reedy
Copy link

I’m seeking clarification on the behaviour of the Depth HUD and Depth Mini-widget after we’ve noticed a discrepancy when attaching a surface GPS to the BlueROV2.

  • Without the GPS both Depth HUD and Depth Mini-widget read 0 at the surface.
  • With a surface GPS attached the DepthHUD appears to show 0 on the graticule but shows a large negative number on the surface (see screencapture). While Depth Mini-widget still shows 0.

Closer examination of the code for the DepthHUD and Depth Mini-Widget shows both using the same value from altitude.msl but treating these differently:

  • For the Depth Mini-Widget, the depth is set to 0 for values before 0.01. Meaning in a body of water above sea level, the depth always gets set to 0.
  • Whereas the Depth HUD does not have this same limitation and always displays the depth, even if the ROV is far above sea level.

Can you clarify what the intention is here? Our assumption is that the depthHUD (due to its name) would always show depth below a waterline. So, whether that’s operating in the sea at sea level or up in a lake at an altitude above sea level, it would show depth below the waterline. Is that the correct intention?

Wouldn’t Relative Altitude (e.g. GLOBAL _POSITION_INT.relative_alt) be a better option? This is the altitude above Home. If we interpret Home as being on the surface of the water (i.e if set at start of a mission), isn’t that exactly what’s needed? Would that not better meet the need for displaying depth irrespective of the altitude of the body of water you’re deployed in?

We found this Ardupilot documentation on interpretation of altitude but it doesn’t include the Sub use case. I’m assuming that Cockpit is currently a Sub-only implementation but with eye to make it more general purpose for drone use, right? In which case a separate AltitudeHUD widget would be required?

Keen to get to the bottom of this as trying to get the surface GPS + DVL solution working smoothly - showing and logging correct depth values. So, understanding the direction here would be super useful.

Image

@rafaellehmkuhl
Copy link
Member

rafaellehmkuhl commented Feb 13, 2025

Hey @samuel-reedy! Sorry for the delayed response.

You're correct on assuming it should only show values below 0, yes.

Regarding using GLOBAL_POSITION_INT.relative_alt instead of AHRS2.altitude, it really depends on the situation. For me right now (~800m above sea level), the first shows a value around -200 m while the second gives me around 0 m.

We are currently using AHRS2.altitude there because it is what sub users usually use, indeed, because it zeroes on boot and is populated by a water pressure sensor (when available), so you will generally have a good value for the water depth.

All that said, let me tell you about our plans: some months ago we introduced a new system on Cockpit called DataLake, where all sorts of variables are stored. What we are in the process of doing is to migrate all the widgets to this system, so people will be able to select which source of information they want to have for each widget. That means you will be able to decide if you want the DepthHUD to show AHRS2.altitude or if you prefer to use GLOBAL_POSITION_INT.relative_alt, or maybe even populate the widget with an external sensor that is not integrated to Ardupilot (you can do that through a JavaScript action + a DataLake variable + a VeryGenericIndicator widget today).

About the problem you're having, below the water level, are both widgets showing the correct value?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants