Ambiguous altitude references

[hamishwillee]

Can we use specific frame rather than "Abs" in altitude references throughout - ie MSL, WGS84 and AGL?

For example, consider the waypoint altitude editor:

• "Abs" radio button becomes "WGS84"
  • Remove the comment no comment (minimally remove "Absolute" as this is redundant).
• For the AGL option it says calculated from terrain data / Abs Alt 530.00 m. However it is not clear whether the alt is MSL or WGS84. Would be better as (assuming MSL):

• MSL alt 530.00 m calculated from terrain data*

  

I do appreciate that the absolute reference can be determined from the comments, but users won't necessarily read those carefully enough. Better to remove any ambiguity early.

[markdjacobsen]

I strongly support this change. In the aviation world the term "absolute altitude" means AGL altitude. The mavlink ecosystem has used this term incorrectly for years to mean MSL or WGS84 (it is ambiguous which). The incorrect use of terminology will present an increasingly serious problem as UAS are integrated into national airspace systems, so now is the right time for QGC and other components of the ecosystem to adopt standard aviation conventions. Eliminating the word 'absolute' and replacing it with specific frames is an important step.

See: https://www.thebalancecareers.com/types-of-altitudes-in-aviation-282941.

[Antiheavy]

+1 for ditching "Abs" and replacing with "MSL".

However, this discussion could quickly expand into the differences between WGS84, "MSL", "amsl", EGM96, EGM2008, and other GNSS receiver specific altitude references. This is a complicated topic and the ambiguity may still remain. Importantly, different autopilot firmware and GNSS receivers use different altitude datums and assumptions. @priseborough any comments?

[DonLakeFlyer]

@AndKe I think it was you and I that had discussed this a bit and I seem to remember there were problems with QGS84 or something like that.

[AndKe]

@DonLakeFlyer please don't invent "QGS84", there are enough coordinate sustems as it is :) there were a long exchange about elevation, where this may be the best post to point you to: https://github.com/mavlink/qgroundcontrol/issues/6342#issuecomment-384250904

I think this really belong in a devcall for Ardupilot, we should aim to have same terminology across GCS's

[DonLakeFlyer]

please don't invent "QGS84"

That's just a typo on WGS84.

[AndKe]

I know, I was trying to be funny (hence the smiley that followed), ... and I failed.

[DonLakeFlyer]

Ah, now I get it. Duh!

[hamishwillee]

Hi @Antiheavy , @AndKe

+1 for ditching "Abs" and replacing with "MSL".

To be very precise, we want to replace Abs with whatever the global frame actually "is". In the example it is WGS84 (not MSL).

The complication here is that there are multiple possible frames that might be set - MAV_FRAME. So QGC probably needs to display some of these other alternatives, or select one and have some way of converting. It might do it differently based on whether it imports the mission item or is adding for the first time. I don't care, as long as we don't say "Abs", because Abs implies Absolute, which means "AGL" in manned flight.

There is no need to expand the discussion of frame time in this context because it is defined in the MAVLink specification MAV_FRAME.

I think this really belong in a devcall for Ardupilot, we should aim to have same terminology across GCS's

Absolutely. @auturgy is sharing the discussion on frames onwards from MAVLink dev call.

[DonLakeFlyer]

The complication here is that there are multiple possible frames that might be set - MAV_FRAME. So QGC probably needs to display some of these other alternatives, or select one and have some way of converting.

The QGC UI specifically does not expose all options for MAV_FRAME in order to keep things simple. It does this all over the place for mission commands. If the mission command being used doesn't fit this simple representation then QGC falls back to "Show All Values" which gives you direct access to all the mavlink insanity.

[hamishwillee]

The QGC UI specifically does not expose all options for MAV_FRAME in order to keep things simple. It does this all over the place for mission commands. If the mission command being used doesn't fit this simple representation then QGC falls back to "Show All Values" which gives you direct access to all the mavlink insanity.

That is good. As long as the actual altitude frame is displayed at the top level that is fine.

[DonLakeFlyer]

To be very precise, we want to replace Abs with whatever the global frame actually "is". In the example it is WGS84 (not MSL).

My original reasoning for Abs (and WGS84 shown below) was twofold:

• Since the concept or "Relative" exists "Absolute" is essentially the opposite of that
• WGS84 is incredibly techy and how many people really know what that means?

So I would say that if WGS84 is to become the top level radio. That below it in small text needs to be some additional explanation. @hamishwillee Any help with the small help text for that?

[AndKe]

To make matters worse, WGS84 is not really the "keyword" when it comes to altitude, the thing is that WGS84 is ellipsoid altitude, and one that we often correct to geoid altitude, which we like to think of as MSL, yet it is about that only on a very large scale... So maybe you could keep calling it "Abs or Absolute" , having a text telling it is the "Ellipsoid altitude from GNSS" ?

[markdjacobsen]

Whatever solution comes up, it cannot be called "Abs" or "Absolute" because this is an incorrect usage a term that has a specific meaning in the aviation world. Absolute altitude is height above ground level.

Another term I have seen for WGS84 is "height above ellipsoid" or HAE, but this is not common.

[hamishwillee]

As @jacobsenmd said, the problem is the use of the term "Abs" which means AGL. Even the differentiation between Absolute and Relative is unhelpful because every single altitude reference is relative to something. That is, after all the point :-)

We use WGS84 to mean the WGS84 reference ellipsoid right (not the various "realisations" ? In this case I think that what people understand this as is the height according to GPS - correct? Below assumes that.

Controversial proposal of the day - we get rid of Rel too. Let's make this "Home" or "Takeoff" and have a clean break. I like takeoff as an altitude reference because that is what it is 99% of the time and it makes sense to people who do not understand what "Home" means. I like Home, because presumably you can reset the altitude to something else other than takeoff, or you might arm and then move the vehicle.

@hamishwillee Any help with the small help text for that?

Yes. So for all options, here are my recommendations for discussion:

Radio: Home Text: Relative to Home (takeoff) altitude

Radio: AGL Text: Above ground level (from terrain data). WGS84: 530.00 m. //Note, I am assuming that this is WGS84?

Radio: WGS84 Text: WGS84 ellipsoid altitude (GPS altitude) //or maybe (Approx. GPS altitude)

@jacobsenmd - would this work for you?

[Antiheavy]

WGS84: 530.00 m. //Note, I am assuming that this is WGS84?

very dangerous assumption! I believe QGC is using Airmaps terrain database which I'm pretty sure is NOT wgs84, but maybe something closer to egm96? uBlox GPS receivers output an "amsl" value along side the wgs84 value. uBlox "amsl" is similar to egm96, but not exactly egm96. My understanding is PX4 uses the "amsl" value and not the wgs84 value (I'm not sure what APM does).

My understanding could be wrong here and I'd appreciate it if some developers could confirm/deny.

[DonLakeFlyer]

AirMap terrain heights are EGM96 which then leads me to believe terrain is all screwed up! Since it uses that to stuff into a WGS84 altitude in the mission item. Is all that wrong?

[DonLakeFlyer]

MAV_FRAME_GLOBAL says: Global coordinate frame, WGS84 coordinate system. First value / x: latitude, second value / y: longitude, third value / z: positive altitude over mean sea level (MSL).

Which leaves me thoroughly confused on all of this.

[DonLakeFlyer]

Does that mean lat/lon uses WGS84 reference system but the altittude field in MISSION_ITEM does not. Instead the altitude part of a MISSION_ITEM uses AMSL.

[hamishwillee]

Does that mean lat/lon uses WGS84 reference system but the altittude field in MISSION_ITEM does not. Instead the altitude part of a MISSION_ITEM uses AMSL.

Could mean that, or that MSL is a "typo" and altitude should be WGS84 ellipsoid altitude.

Either way, you are right that this is ambiguous. How have you been interpreting it?

[DonLakeFlyer]

How have you been interpreting it?

I was kind of under the assumption that everything (including altitude values, and terrain data) was WGS84 which I believe is wrong now. In reality, prior to the terrain feature it didn't really matter (at least to me) other than from a UI labeling standpoint. QGC is just a pass through of values the user enters. But for the terrain feature it does matter since the altitude value I calc may be in the wrong coord system.

[hamishwillee]

Looking at PX4 the code assumes that Z is AMSL. For example, when calculating relative altitudes it simply subtracts from the home position, which is AMSL (see https://mavlink.io/en/messages/common.html#HOME_POSITION)

I wonder if this is because the system takes altitude by default from a baro rather than GPS? @bkueng Anything you can add here?

[DonLakeFlyer]

I've pinged Lorez directly on Slack to first find out of my terrain code is screwed up. That should hopefully give me enough info to know what to do here as well.

[auturgy]

@tridge @wickedshell

On 26 Oct 2018, at 11:44 am, Don Gagne notifications@github.com wrote:

I've pinged Lorez directly on Slack to first find out of my terrain code is screwed up. That should hopefully give me enough info to know what to do here as well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hamishwillee]

Thanks. Assuming we can confirm that ArduPilot interprets MAV_FRAME_GLOBAL and MAV_FRAME_GLOBAL_INT in the same way I propose we change the descriptions:

Global coordinate frame, WGS84 coordinate system. First value / x: latitude, second value / y: longitude, third value / z: positive altitude over mean sea level (MSL).

TO

WGS84 coordinate frame but using MSL-relative altitude. First value / x: latitude, second value / y: longitude, third value / z: positive altitude over mean sea level (MSL).

OR

Global frame - WGS84 latitude/longitude + MSL altitude. First value / x: latitude, second value / y: longitude, third value / z: positive altitude over mean sea level (MSL).

[Antiheavy]

Does that mean lat/lon uses WGS84 reference system but the altittude field in MISSION_ITEM does not. Instead the altitude part of a MISSION_ITEM uses AMSL.

Yes, I believe this is correct. Because uBlox GPS receivers are so commonly used whatever uBlox spits out as "AMSL" is kind of the defacto standard. It is important to note that this is probably close to, but not exactly the egm96 standard.

(some people like to more accurately say WGS84+EGM96 since egm96 is an offset to wgs84).

[auturgy]

We need to align to a recognised standard, but what ublox spits out needs some analysis before assuming it’s the way to go. Drones may use ublox almost ubiquitously, but other airspace users don’t.

Regards,

James

On 26 Oct 2018, at 12:23 pm, Antiheavy notifications@github.com wrote:

Does that mean lat/lon uses WGS84 reference system but the altittude field in MISSION_ITEM does not. Instead the altitude part of a MISSION_ITEM uses AMSL.

Yes, I believe this is correct. Because uBlox GPS receivers are so commonly used whatever uBlox spits out as "AMSL" is kind of the defacto standard. It is important to note that this is probably close to, but not exactly the egm96 standard (some people like to more accurately say WGS84+EGM96 since egm96 is an offset to wgs84).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hamishwillee]

We need to align to a recognised standard, but what ublox spits out needs some analysis before assuming it’s the way to go.

Isn't it more the case that if everyone is interpreting this as AMSL we need to fix this message to say that unambigously? Then if there is a better frame to use we create a new frame for that?

[auturgy]

I don’t think this is just a reporting/presentation problem (although that is what your pr is addressing). In the first instance, yes, let’s make sure that descriptions match content, but let’s also have a deeper look.

Regards,

James

On 26 Oct 2018, at 12:54 pm, Hamish Willee notifications@github.com wrote:

We need to align to a recognised standard, but what ublox spits out needs some analysis before assuming it’s the way to go.

Isn't it more the case that if everyone is interpreting this as AMSL we need to fix this message to say that unambigously? Then if there is a better frame to use we create a new frame for that?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hamishwillee]

OK, so I have updated the frame descriptions in the messages https://github.com/mavlink/mavlink/pull/1012 to remove the confusion/ambiguity around MSL.

Not sure how to progress this now ...?

As I understand it the problem is that we've been referring to WGS84 altitude (meaning the WGS84 ellipsoid) and MSL altitude, when the actual altitude that is being used in most places is what is being spat out of uBlox for "amsl" ... and that is actually something different: WGS84+EGM96? Is that right?

So looking at the previous text, this bit is probably OK

Radio: Home
Text: Relative to Home (takeoff) altitude

But where we say WGS84 below we need to say something like WGS84+EGM96? So is below "accurate"?

Radio: AGL
Text: Above ground level (from terrain data).
WGS84+EGM96: 530.00 m 
(MSL altitude from uBlox GPS)

Radio: WGS84+EGM96
Text: MSL altitude from UBlox GPS

[DonLakeFlyer]

Still waiting to talk with Lorenz so I can be fully educated.

I'm a bit mixed on replacing Rel with Home.

[hamishwillee]

OK

I'm a bit mixed on replacing Rel with Home.

I'm not conflicted on this because I think that it will be easy for both current and new users to understand.

[Antiheavy]

+1 for “Home” vs “Rel”

+1 for “MSL” vs “Abs”

Tooltip or flavor text can state the specifics of egm96 or wgs84 or whatever the altitude datum really is. This is still a can or worms though so getting the firmware folks as well as terrain database folks to exact specify would be in everyone’s interests.

[DonLakeFlyer]

The problem with Home Versus Rel is that Rel is used other places where there is no room for additional explanation. And in those places it's going to be way confusing:

Changing that to "Alt-home" isn't going to work.

[AndKe]

We should not involve the word "home". Home, as RTL destination, can change, or we fly from one place and land another. Relating altitude to home (understood as 3D position) would only add to the confusion.

[DonLakeFlyer]

We should not involve the word "home". Home, as RTL destination, can change, or we fly from one place and land another. Relating altitude to home (understood as 3D position) would only add to the confusion.

All nice, but unavoidable. The default reference frame for altitudes is "relative to home altitude".

Just got off the phone with Lorenz on all of this. Let me digest and then I'll propose something based on all of the above.

[AndKe]

All nice, but unavoidable. The default reference frame for altitudes is "relative to home altitude".

I have to disagree a bit, more precisely, the default ref.frame altitudes are really: "relative to start/arming point" "home" point (as when used as RTL destination), can change during the mission, and moving home does not affect the "relative" altitude which is ... "relative to start point"

[DonLakeFlyer]

From the mavlink spec: MAV_FRAME_GLOBAL_RELATIVE_ALT Global coordinate frame, WGS84 coordinate system, relative altitude over ground with respect to the home position. First value / x: latitude, second value / y: longitude, third value / z: positive altitude with 0 being at the altitude of the home location.

[AndKe]

let me rephrase: I mean we should avoid referring to an navigation altitude to be relative to home, but rather to "point of arming/origin"
If I start at one place, follow an high voltage line next 100km , at some points the "home" is updated to other locations, finally the landing location. The current flightpath, being relative to home, does not go bananas as new home locations are set. So yes, the old terminology is "home" , ... "home" can be updated. The navigation does not really care for updated home's altitude, but works "relative to point of origin/arming"
At least, that's my perception of things, unless the navigation code is meant to convert relative altitudes, into new if a new home altitude is set..
-if you don't follow me on this, I won't argue anymore :)

[DonLakeFlyer]

Not according to the PX4 folks. It works as spec'ed. Which is it adjusts relative altitudes to the new home position.

[hamishwillee]

The problem with Home Versus Rel is that Rel is used other places where there is no room for additional explanation. And in those places it's going to be way confusing:

Changing that to "Alt-home" isn't going to work.

Changing it to Alt-rel-home though would be even better than alt-rel.

I appreciate that there might be other cases that can't be easily fixed.

The problem with alt-rel is that it only works if you know what "rel" is relative to.

Just got off the phone with Lorenz on all of this. Let me digest and then I'll propose something based on all of the above.

Cool. Happy to chat in real time if you find that helpful.

[AndKe]

@DonLakeFlyer - I stand corrected.

-I wish all the devs could agree on the same terminology. So that ArduPilot, ApmPlanner2, MAVProxy, QGC, MP, could all use the same terms.

[DonLakeFlyer]

I think the references to Abs should change to AMSL. Both in the Radio and the Terrain description. This is as close to an explanation of what it really is. I don't think Rel should change to Home. I don't see that as being any less confusing and possible could be more confusing in some case or possible require so much additional explanatory text in the UI that it makes it much too unwieldy. I think the concept of Relative altitude to home is just something that a user is going to have to continue to understand if they are concerned with tight altitude limits.

[Antiheavy]

I think the references to Abs should change to AMSL.

AMSL is definitely better than Abs.

[hamishwillee]

I think the references to Abs should change to AMSL. Both in the Radio and the Terrain description. This is as close to an explanation of what it really is.

OK - MSL is OK too. The text underneath will have to change too.

If we end up with a better text later for what is coming out of various systems we can use that.

I don't think Rel should change to Home.

I disagree - IMO Home will be significantly less confusing to new users, especially when Abs is gone.

But I can live with this if you insist on being wrong :-)

[hamishwillee]

PS Can we make the Abs and its subtext change sooner rather than later. If you need me to do that change I am happy to do that, but we'll need to agree what you want to in the subtext.