You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: