Elevations

Andi Lamprecht ·2026-05-11· 8 min read· Accepted

Elevation and Altitude Handling in Uncrew

Context

This ADR recognizes that DroneUp frequently deals with vertical coordinates without clearly examining the problem domain and clearly naming the coordiante system these coordiantes pertain to.

On Vertical Datums

GPS works in the WGS84 ellipsoid reference, that is: both its horizontal and vertical frame of reference is the shape of the Earth expressed as an idealized ellipsoid.

To use the term “WGS84” as a vertical reference/datum is to say that the elevations reported in this reference are elevations above the WGS84 ellipsoid.

Meanwhile a GEOID is a gravitational equipotential (force of gravity is perpendicular to) surface that tracks the Mean Sea Level (MSL) better than the ellipsoid.

Should one stand on a beach in Ireland (where the GEOID bulges above the ellipsoid), with one’s feet wet, one’s GPS receiver is likely to show them that they are at 60m elevation, i.e.: 60m above the wgs84 ellipsoid. Meanwhile, one standing in similar circumstances in Sri Lanka (where the geoid dips below the ellipsoid), is likely to find their GPS receiver showing them -100m elevation.

This is why GPS units normally come with a GEOID model baked into the firmware and can, in addition to the WGS84 elevation, also report the elevation above that GEOID.

There are many competing geoids, some being evolutions of their predecessors (e.g.: EGM2008 succeeds EGM96), others serve to provide a better MSL tracking in specific regions (e.g.: NAVD88).

On MAVLINK and PX4

MAVLINK often mentions “MSL” and the vertical datum implicit in this term (confirmation pending) is: whatever the GEOID that the drone’s GPS unit happens to have installed.

Only on one ocasion MAVLINK deals with the WGS84 ellipsoid altitude and this when reporting the GPS_RAW_INT.

When commanding a drone, MAVLINK permits specifying local and global reference frames (MAV_FRAME) and so the drone can be told to:

• Climb to some specific MSL elevation;
• Climb to some specific elevation above its home position (where it took off).
• Climb to some specific AGL elevation - though support for this requires that the drone is equipped with a Digital Elevation Model so that it knows where the terarin is.

Notably, it does not have references for ellipsoid.

On UTM

UTM handles elevations in two contexts:

• By sporting a terrain service and offering a Digital Elevation Model. Its current vertical datum is NAVD88.

• By handling flight intents:

  • Accepting flight intent submissions (feet AGL);
  • Forwarding these intents to the DSS using metres WGS84;
  • Accepting flight telemetry so that it can track flight conformance against the previously submitted intents.
  • Forwarding flight telemetry to DSS using WGS84;

UTM offers (to Uncrew) NAVD88 DEM, but wishes to hear back WGS84 telemetry. This is a problem for UTM as accepting an AGL flight intent and having a NAVD88 terrain model they can translate the flight intent to NAVD88, but they need to translate it to WGS84.

On Uncrew

If there can be a disagreement between a GEOID used for planning (NAVD88) and the GEOID (EGM96) baked into the drone assigned to execute this plan, then Uncrew must not use MAV_FRAME_GLOBAL for commanding the drone. Please note that the NAVD88 altitude of waypoint W is different that EGM2008 altitude and so two different drones may intepret this plan differently and potentially collide with terrain or other drones.

Uncrew’s Mission Console shows the operator the MSL altitude of the drone. By doing so, it expressely states its best approximation of (altitude above) MSL. The utility of showing the operator MSL values is unclear, but if it’s there, Uncrew must continue to surface a GEOID-based altitude (MSL altitude) to operators.

The Console also shows the AGL altitude of the drone and it does so to give the operator situational awareness on the drone’s position relative to the ground. The drone cannot produce AGL values as it doesn’t know where the terrain is. The range finder knows how far down the nearest hard obstacle is, but that’s not AGL. Uncrew must calculate the AGL value and it must do it against a terrain model, whose vertical datum is in agreement with the datum of the altitude the drone reports.

The Mission Manager allows the suporvisor for reviewing the mission before assigning it to an operator.

One day it might want to show MSL for similar motives that it shows it to the operators. Or it might want to show a 3D view of the mission to its users.

When it does, the vertical datum of the plan must agree with the DEM used to render the base 3D map. Fortunatelly UTM does produce such (so called RGB) rasters and they are in vertical datum agreement with their terrain model.

Uncrew has to submit positional telemetry to UTM for all ongoing missions either using WGS84 vertical datum or such that allows UTM to convert it to WGS84. Uncrew is not in control of nor aware of the GEOID baked into the drone’s GPS unit, so it only has one other option: report altitude above takeoff to UTM. UTM tracks the positional telemetry against the previously sent flight intent, so as long as the drone takes off from the planned position, UTM can simply add its MSL altitude to any telemetry datapoint it receives. Let’s just remind ourselves why we do all this. Uncrew sends positional telemetry to UTM so that UTM can perform conformance monitoring, that is: monitor that the UAV flies as planned or alert when it doesn’t.

Now there should be and are many failsafes preventing the drone from taking off too far from its planned position. So there are failsafes preventing the drone from verging off its plan at any point during the flight. Yet, we still chose to conformance monitor our flight in case one of these failsafes flops. This is why it is not a good idea for UTM to accept altitude above (actual vs planned) takeoff.

On HubOps

Uncrew sends the mission plan to HubOps so that HubOps can render this plan in the browsers of their users so that, like Uber users, they can see the path the drone will follow to whererever they are. Neither HubOps nor Uber care to show the altitudes of this plan in any way and it’s unclear why they might.

Decisions

If there is a theme to this ADR, it is to expose the usage of WGS84 as a vertical datum in machine-2-machine coordination. If one thinks about it, drones don’t really care for where the sea is. They might care if that helped them coordinate with manned aviation, but it only uses MSL at cruising altitudes.

Pilots use altimeters, which measure the AGL, when the aircraft is flying at relatively low heights landing at an airport. But as the plane increases in altitude, the altimeter reading becomes less accurate. Once the plane reaches transition altitude, the aircraft uses the MSL along with air pressure readings to maintain level flight. [see]

Releative Altitude on C2

Until such time that it can be in control of the GEOIDs mounted on its drone fleet, Uncrew shall only use MAV_FRAME_GLOBAL_RELATIVE_ALT (altitudes above the home position) when controlling a drone. This applies both to planning missions and issuing MAV_CMD_DO_REPOSITION (goto) commands.

Only then the hypothentical difference between the GEOID used for planning and one mounted on the drone will be cancelled out. That is, the relative elevation of waypoint W is always the same independntly of the GEOID mounted on the drone.

Uncrew Publishing Positional Telemetry

Uncrew positional telemetry (today it’s this message) shall effectivelly look like so:

    // Horizontal position of the UAV in WGS84 frame of reference
    types.v1.Position2D position             = 1;

    // UAV's best approximation of its AMSL altitude.
    // The exact vertical datum will depend on the UAV's GPS positioning system.
    // Only use as an orientational value. Do not attempt to calculate AGL
    // as the vertical datum of your DEM may differ.
    units.v1.Meters altitude_amsl             = 2;

    // UAV's altitude above WGS84 ellipsoid
    units.v1.Meters altitude_wgs84_ellipsoid = 3;
}

Notably; GPSInfo cannot be used in lieu of positional telemetry, because it explicitly carries GPS readout unfused with visual odometry or dead reckoning.

Uncrew Preventing Takeoff from Unplanned Position.

Right now Uncrew prevents the takeoff if the first waypoint is further than 900m from the current drone’s position. That’s way too lenient and it should be shrunk to no more than 20m.

UTM WGS84 Terrain Model

Uncrew needs the UTM to offer its Digital Terrain Model in WGS84 so that it can correctly calculate the AGL in the Mission Console. We are not in control of the vertical datum used by drones to report their MSL altitude and thus subtracting this from NAVD88 terrain model yields an incorrect AGL. We can only be sure that all drones can and will report their altitude using WGS84.

It’s worth noting that the pathfinder doesn’t care about the vertical datum. It consumes a terrain model and produces waypoints decorated with absolute altitude coordinates. The vertical datum of the output is the same as the input.

Digital terrain models typically report MSL altutitudes and typically serve no data over the sea. The Mapbox frontend SDK will then interpret the absence of data as zero (sea level). If if we give it WGS84 data, it is likely to render a cliff on the - let’s say - continental shelf. Remember, Irish beaches are at 60m above the ellipsoid and this is what a WGS84 terrain model likely read there. Then it will abruptly end somewhere over the sea forming a cliff with level 0. If that’s undersirable, or if HubOps or Uncrew frontend will one day want to show MSL plan to their users UTM will have to expose a terrain service that supports a selection of GEOIDs.