Inconsistent height usage for WGS84 and AMSL in mavlink app

[MariusBeul]

In mavlink_messages.cpp a message with title "GLOBAL_POSITION_SETPOINT_INT" is published. Although the Mavlink message "mavlink_global_position_setpoint_int_t" defines the heigth as "Altitude (WGS84), in meters * 1000 (positive for up)" the height is extracted from a "position_setpoint_triplet" which defines the height as "altitude AMSL, in m" This is only feasible with height(WGS84) == height(AMSL) which is not the case. Is the comment in mavlink_msg_global_position_setpoint_int.h wrong and the heigth is also in AMSL like in mavlink_msg_global_position_int.h

Please comment this issue...

[DrTon]

Just looked http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf. As I understand, WSG84 is orthogonal (XYZ, not spherical Lat/Lon/Alt) cordinate system with center in Earth's center of mass. Or I missed something? Could you clarify the difference and how should we implement coordinates (or fix comments/docs) to be consistent?

[MariusBeul]

It would be consistent when the altitude field in mavlink message "mavlink_set_global_position_setpoint_int_t" in "mavlink_msg_set_global_position_setpoint_int.h" would be in AMSL and not WGS84. The mavlink app interprets this field as AMSL...

[DrTon]

Let's figure out the difference between AMSL and WGS84. From this article: http://www.xcmag.com/2011/07/gps-versus-barometric-altitude-the-definitive-answer/

WGS84 defines the Earth as an ellipsoid: a squashed ball. This ellipsoid is a pretty good approximation to the mean sea level around the planet, but is recognised as having errors of between -100 m and +70 m with respect to the geoid, depending where you are on the planet.

So WGS84 == "simple ellipsoid", and AMSL == "ellipsoid with correction".

In the same time:

Significantly, even though we select the WGS84 datum (ellipsoid), some GPSs add the geoid correction to give geometric height and some don’t. To work out the amount of error for where you live, use the online calculator for the ellipsoid to geoid height for any point on the globe at http://sps.unavco.org/geoid. - See more at: http://www.xcmag.com/2011/07/gps-versus-barometric-altitude-the-definitive-answer/#sthash.eNHyymWk.dpuf

I suspect that what we really receive from UBX is corrected geoid, i.e. AMSL, because when I fly in 50m from the sea (Italy, corrected geoid - vs - ellipsoid error is ~40m) GPS shows altitude ~5m.

So you are right, it looks like we just need to fix mavlink comments. @LorenzMeier, any comments?

[LorenzMeier]

We will resolve this by referring to WGS84 altitude consistently and leaving it to the receiver to do the transformation if required. If you have pointers to a transformation library we could use, we could consider adding the conversion as library call in src/lib/geo.

[DrTon]

To clarify: WGS84 is geoid or ellipsoid model?

[thomasgubler]

@DrTon Given our experience and the whole discussion, I think it makes sense to use the geoid which is more natural for most purposes and is ok for those who don't want to struggle with setting QNH. So whenever we write wgs84_altitude we mean the geoid. Whenever we write amsl_altitude we mean QNH corrected altitude. (Please step forward if you have better naming ideas)

[pgiacalo]

@LorenzMeier IMO, the best way to resolve this is to include both the WGS84 altitude and the Geoid separation in GLOBAL_POSITION_INT messages. GPS NMEA message $GPGGA (Global Positioning System Fix Data) provides both the AMSL altitude and the Geoid Separation, in meters. By providing both values, it makes it easy for client code to determine the altitude for either basis (WGS84 and AMSL).

The altitude conversion is simple: WGS84 altitude = AMSL altitude + Geoid Separation see: http://webhelp.esri.com/arcpad/8.0/referenceguide/index.htm#gps_rangefinder/concept_gpsheight.htm

Determining the Geoid separation is a complex function of latitude and longitude. Better to have MAVlink include the value provided in the GPS message than to have to add that capability as a feature to MAVLink or MAVlink clients, imo.

BTW, I've recently checked the altitude provided in GLOBAL_POSITION_INT messages by the APM autopilot software. APM provides the AMSL altitude -- taken directly from the GPS message. This does not conform to the MAVLink documentation, obviously, which says the altitude should be WGS84. The MatrixPilot autopilot also does not provide WGS84. Rather, it provides the best estimate of altitude (AMSL), based on sensor fusion.

[LorenzMeier]

I think the conclusion is that most systems actually use AMSL and that essentially all GPS output AMSL already, with the appropriate corrections applied. So we might want to fix the MAVLink specs.

[pgiacalo]

Very true about amsl being the value in GPS messages and also commonly used in global position int messages. So it'll be good to get the mavlink documentation in sync with that.

However, it would still be very helpful for clients to have the geoid separation value in the mavlink message.

I'm working on a navigation system that uses wgs84 as the reference frame. This is not uncommon for such purposes. In this case, having the geoid separation is essential to convert amsl altitude to wgd84. Anyway, it would be nice to include it in the mavlink message, since the GPS system is already providing it, and calculating it is not simple.

[LorenzMeier]

The issue we're facing is that we can't add the field without breaking compatibility with existing systems, so it would require a completely new message. Since the geoid separation is a slowly changing quantity compared to GPS position, how about adding a new message just for it? It could be sent at a slower rate, e.g. 1 Hz and used to do the transition.

[pgiacalo]

Yes, that seems very reasonable, thanks.