8000 Clarify AMSL Geoid and WGS-84 Ellipsoid Height · Issue #2167 · mavlink/mavlink · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Clarify AMSL Geoid and WGS-84 Ellipsoid Height #2167

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Ryanf55 opened this issue Nov 6, 2024 · 3 comments
Open

Clarify AMSL Geoid and WGS-84 Ellipsoid Height #2167

Ryanf55 opened this issue Nov 6, 2024 · 3 comments
Assignees
@hamishwillee

Comments

@Ryanf55
Copy link
Ryanf55 commented Nov 6, 2024 •
edited
Loading

As I understand it mavlink only specifies AMSL for all but a few cases (i.e. wherever you're using a global frame MAV_FRAME_GLOBAL. That's a reference independent of the standard ellipsoids. It is supported by most GPS modules, though whether they support it in the same way is unknown (to me).

A few messages such as GPS_RAW_INT specify lat/lon in (WGS84, EGM96 ellipsoid) and there are fields for AMSL and alt above above WGS84, EGM96 ellipsoid.

Originally posted by @hamishwillee in #256 (comment)

Background; I'm working with a few different people trying to use ROS 2 which uses WGS-84 ellipsoid height as a convention in the standard messages. It's super confusing trying to convert from MAVLink, even for me.

Here are some examples of confusion:

  • In GPS_RAW_INT.lat, it says latitude is in WGS84, EGM96 ellipsoid. EGM96 is NOT an ellipsoid, it's a geoid.
  • In GPS_RAW_INT.alt, it says alt is in MSL but does not specify which geoid. I assume EGM-96. This is the only field in the message that needs to clarify which geoid.
  • In GPS_RAW_INT.alt_ellipsoid, it says Altitude (above WGS84, EGM96 ellipsoid). Again, EGM96 is a geoid, not an ellipsoid.
  • In GLOBAL_POSITION_INT.at, it says alttidue is in MSL, but does not say which geoid is used.

ROS 2 has a convention to use WGS-84 ellipsoid height for its geographic coordinates, which is more portable.
https://github.com/ros-geographic-info/geographic_info/blob/ros2/geographic_msgs/msg/GeoPoint.msg

Just saying "AMSL" is vague

Without specifying which datum the autopilot uses, when it publishes its state estimate in global coordinates, it's impossible to convert to a GeoPoint without making assumptions.

Not all GPS's use EGM96. Not all terrain data is in EGM96. Some use EGM2008.

What I am hoping to clarify in this ticket is:

  • Should we make it more clear that MSL is only supported on the EGM96 geoid, or should we tell integrators they need to check across their systems they use the same geoid
  • Can we remove the mixups of calling EGM96 an ellipsoid?
  • Can we come up with a design on how a ROS developer populates a GeoPoint message for the vehicle location given the existing mavlink data from the autopilot?
@Ryanf55
Copy link
Author
Ryanf55 commented Nov 6, 2024 •
edited
Loading

Tangentionally related to

@Ryanf55
Copy link
Author
Ryanf55 commented Nov 6, 2024

MAVROS handles it here:
https://github.com/mavlink/mavros/blob/b49095727a6ff160e1e913b90a4ce50e383e8863/mavros/src/plugins/global_position.cpp#L289C71-L289C96

It hard codes the geoid to EGM-96:
https://github.com/mavlink/mavros/blob/b49095727a6ff160e1e913b90a4ce50e383e8863/mavros/include/mavros/mavros_uas.hpp#L163

@hamishwillee hamishwillee mentioned this issue Nov 7, 2024
Closed
@hamishwillee
Copy link
Collaborator

@Ryanf55 Thanks for posting. I support the goal - we should be precise where possible. Whether we can do it largely depends on whether

  • this will break assumptions that are made by existing users
  • the information is actually available to allow conversion to a consistent format.

Currently the assumption is that GPS modules output MSL and this is calculated by some consistent formula.
If MSL is always a proxy for EGM96 we're fine. IF not, then we need to think a bit more about what we are expecting implementers to actually do here, and what implications that would have on drones/SDKs that have been getting the data in some other format.

Let's discuss this in the PR #2168

(note, I'm just pulling people together, I have no idea the answers to this question).

@Ryanf55 Ryanf55 mentioned this issue Dec 5, 2024
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hamishwillee hamishwillee

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hamishwillee @Ryanf55
0