AP_GPS Undulation is opposite common convention causing incorrect ellipsoid height

[Ryanf55]

Bug report

Issue details

ArduPilot's idea of undulation is not following common convention. It's been this way since it was first implemented, and we have seen PR's come through to correct device drivers undulation, when in fact, ArduPilot was using the wrong definition.

See here for a report:

Ardupilot GPS Issue - PUBLIC3.pdf

If you use ellipsoid height for an algorithm, you may run into large offsets on some GPS's.

Version
Every version of ardupilot that publishes GPS_RAW_INT and dataflash logs to report UND, including master.

Platform
[x] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
All

Hardware type
A few GPS's have been tested

Logs
N/A

[tpwrules]

After some experimentation and private discussion with Ryan it appears that (fortunately!) this issue does not affect the common use case of DroneCAN, UBX, or NMEA GPSes. When using these GPSes, whether through AP_Periph or a flight controller, the ellipsoid height is correct over MAVLink GPS_RAW_INT and/or DroneCAN's uavcan.equipment.gnss.Fix2 message. So the issue in these cases is only visible in dataflash GPA.Und.

This makes a fix a lot more palatable for me personally and I do think it is important for users of other GPSes.