bluerobotics / bluerobotics/cockpit
Add calculated depth variable to overcome problems on ArduSub
- Dominant language
- TypeScript
- Stars
- 198
- Forks
- 63
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 57
Description
_Originally posted by @ES-Alexander in https://github.com/bluerobotics/cockpit/pull/2725#discussion_r3270431735_
It turns out MAVLink has no concept of "pressure altitude"/"baro altitude", just positions relative to the earth (mean sea level) or to the user-specified home location. I don't like it, but we _can_ provide pressure depth as an option by [calculating it](https://github.com/ArduPilot/ardupilot/blob/Sub-4.5/libraries/AP_Baro/AP_Baro.cpp#L938) ourselves using information from the autopilot - it's just a bit messy to do so.
Pseudocode as follows, assuming we don't care if the data exists, and just try to access it and give NaN results or similar if it doesn't:
```ts
{
title: 'baro2.pressure_alt`
value: '/mavlink/1/1/SCALED_PRESSURE2/press_abs',
toMeters: (rawPressure) => (vehicleParams['BARO2_GND_PRESS'] - rawPressure) / 9800 / vehicleParams['BARO_SPEC_GRAV'] + vehicleParams['BARO_ALT_OFFSET'],
},
{
title: 'baro3.pressure_alt`
value: '/mavlink/1/1/SCALED_PRESSURE3/press_abs',
toMeters: (rawPressure) => (vehicleParams['BARO3_GND_PRESS'] - rawPressure) / 9800 / vehicleParams['BARO_SPEC_GRAV'] + vehicleParams['BARO_ALT_OFFSET'],
},
]
```
If we can / need to do existence checks:
1. neither option should be available if `BARO_SPEC_GRAV` doesn't exist or is <= 0, or if `SCALED_PRESSURE2` messages are not being received
2. the second option should also not be available if `SCALED_PRESSURE3` messages are not being received
3. if we do decide to do such checks, it makes sense to use the `BARO_PRIMARY` parameter to determine which one is the external one and only display a single `external_baro.pressure_alt` variable
- this could maybe even be used as the default variable, though doing so may require waiting for an autopilot connection before setting things up 🤷♂️
- if this only conditionally exists, we could potentially make it the first one so it's used as the default if it's found (though I'm unsure whether the default variable selection would have already happened before the extra value gets added to the list
---
IIRC we currently only have access to autopilot parameters in the vehicle store. Some of the potential error handling / edge cases here may be slightly easier to implement if we first implement at least the readable aspect of #1848, so param values (or lack thereof) can go via the data lake instead of needing to properly check if a parameter exists on an autopilot that may not currently be connected 🤷♂️
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.