bluerobotics / bluerobotics/cockpit
DepthHUD working as intended? Adding a surface GPS introduces strange behaviour
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 198
- Forks
- 63
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 57
Description
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/components/widgets/DepthHUD.vue and src/components/mini-widgets/DepthIndicator.vue, then compare how each uses altitude.msl. Review the linked MAVLink and ArduPilot altitude documentation before determining the intended surface-depth semantics. Done means the expected behavior is decided and the two widgets' handling is made consistent or the distinction is documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100