ros2
[sensor_msgs] Proposal: Add Altitude.msg (scalar vertical position + variance)
Description
Add a new scalar message to sensor_msgs named Altitude.msg, containing a timestamped vertical position z in meters (positive up), with an optional uncertainty. This fills the gap between existing messages that either (a) embed altitude together with latitude/longitude (NavSatFix) or (b) represent barometric pressure or generic ranges rather than altitude itself. The proposed definition mirrors existing scalar messages (e.g., Temperature, Illuminance) that carry a variance field.
Motivation
Many robotics applications need a standardized, timestamped scalar for vertical position (z) that is independent of latitude/longitude. The most common sources are barometric altimeters (converting absolute air pressure to altitude using a reference such as QNH or a locally defined “home” level), radar/laser/ultrasonic altimeters that directly measure height above ground along a downward beam (AGL), and underwater pressure sensors that map hydrostatic pressure to depth; DVLs and single‑beam echosounders also report altitude above the seabed as a single range. Today these signals are typically published as FluidPressure, NavSatFix, or Range (or as community‑specific messages), which forces consumers to infer semantics, perform conversions, or carry unrelated fields. A minimal Altitude.msg, Header + altitude [m] (positive up, negative for depth) + variance [m²], would let drivers and estimators exchange vertical‑only observations with unambiguous units, frames, and uncertainty, reducing boilerplate conversions and improving interoperability in state‑estimation pipelines.
Why not Range? Range denotes along-beam distance from an active ranger and has different semantics/fields (min/max, FOV, radiation type). Many altitude sources are not active rangers (e.g., barometers), and even when they are (radar altimeters), the semantic intent is “vertical position”, not raw range.
Design / Implementation Considerations
Units & Sign (REP-103): meters, +Z up; negative altitude = depth (explicit in docstring). This keeps consistency with ROS axis conventions.
Uncertainty: follow scalar pattern → variance (float64, m²), where 0.0 = unknown, as in Temperature/FluidPressure/Illuminance.
Frame semantics (REP-105): header.frame_id declares the measurement frame (e.g., base_link, imu_link, map, or earth).
Additional Information
I’m opening this issue to quickly gauge community feedback on adding a minimal, source‑agnostic vertical position message to sensor_msgs; if there is support, I volunteer to author the PR (message and docs)
Your structure generally makes sense. If you can prototype of the converter which can convert all the different datatypes into the common one. And provide a demonstration of one of the state estimators or other potential downstream user that can demonstrate that the proposed message covers the needs on both sides.
This issue has been mentioned on Open Robotics Discourse. There might be relevant details there:
https://discourse.openrobotics.org/t/ros-pmc-minutes-for-october-14-2025/50533/1
Thanks, this seems reasonable to me.
However, I strongly advocate for a reference field which would specify the other frame against which you're measuring. It could be an enum, e.g. something like this:
0 = Unknown (anything not covered by the other enum values)
1 = MSL (mean sea level; whatever that means (this term seems to be not very well defined and some sources tell it is measurement-based))
2 = WGS84 ellipsoid (this is what GNSS receivers report)
3 = EGM96 geoid (should more or less coincide with MSL (but is a pure computational model); ublox can be configured to output this)
3 = LOCAL DATUM (some other local reference) (ideally, local data should be converted)
4 = SURFACE (general measurements of height relative to some surface (ground, seabed, actual sea surface...)
For differential barometric measurements, the reference should be the datum used by the reference station.
Theoretically, there's lots of ellipsoidal and geoid height models, so the message could instead be specified as:
int8 reference (0 = Unknown, 1 = Datum, 2 = Surface)
string datum (name of the used datum, maybe with a few predefined constants for MSL/WGS84/EGM96)
