GPS and global_position altitude (NavSatFix - WGS84; MAVLink - AMSL)

[mantelt]

Hi

I just tried to figure out in which system the altitude is published for gps and global_position messages. As far as I can tell, the altitude of gps_raw_int and global_position_int are only scaled to meters and published in NavSatFix messages in their respective ROS topics.

BUT: while the mavlink specification states that the altitude is in AMSL, the ROS specification for NavSatFix states that it should be published relative to the WGS84 ellipsoid (which to my knowledge is in general not the same).

Any thoughts?

[vooon]

Oh, yes, i missed that problem.

[mantelt]

I also almost forgot about my issue here. I again looked at the code and think this needs a fix for consistency with the definitions. Are you looking into this?

I was thinking to fix this using GeographicLib, using this function. But I guess it would not be an optimal solution, since it adds a dependency?

[vooon]

I'm not sure when i can deal with this issue, but at least now the bug is known.

[TSC21]

@mantelt can you please issue a PR on this if you have found the solution?

[mantelt]

Unfortunately, I did not fix this yet. A quick search revealed either the solution posted above using GeographicLib, or basically re-implementing that method using the publicly available data of the geoid / ellipsoid to calculate the undulations (see http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html) or even calculate them whenever needed (code can be found online, e.g. http://stackoverflow.com/questions/22196714/wgs84-geoid-height-altitude-offset-for-external-gps-data-on-ios).

I would vote for using an already implemented library, but I don't know how the (main) developers (i.e. @vooon) would feel about this. I guess it can be seen as quite an overkill using a big library such as geographic lib just to do the conversion from height above geoid to height above ellipsoid. On the other hand, it would be a nice one liner to do the correction... (+ some include of course)

BTW; Some easy to understand description of the problem can be found here: http://www.esri.com/news/arcuser/0703/geoid1of3.html

[TSC21]

@mantelt thanks for the research. At my understanding, a standalone function to do the calculation is the best way in this case, so to not overwhelm the dependencies of a library like that, unless there are other functions that can be useful to us. Do you find any other function on GeographicLib that can be useful for our use case? @vooon that do you think?

[mantelt]

GeographicLib does a lot of nice things besides of getting undulations. For instance, they also have a really nice interface to transform between global (e.g. wgs84) and local coordinates.

If implementing this as a standalone function that interpolates on existing data within Mavros, keep in mind that the low resolution file available (resulting in max 1cm error) already uses around 100 MB. I don't know about the processing time to calculate everything online.

[TSC21]

Are you able to implement both ways and check it's performance? The best way is to use rostopic hz to check the publish frequency of the topic. It would be awesome if you could then launch a PR. You can add the aditional code to gps_conversions.h or the lib to src/lib. Still betting that a standalone function would be better. We already have a function to convert to local units but if you see any improvements on getting the other implementation, we can apply the lib. Adding dependencies is only justifiable if there is an increase an increase of performance/functionality.

[mantelt]

Sorry, maybe my comments were misleading. For the time being, this issue here is not a priority on my side, so I was only writing down my findings from a year ago, when I first raised the issue. I personally would favor the GeographicLib solution as it would be a quick thing. Everything else needs more time for implementation and testing. But of course I see the issue:

Still betting that a standalone function would be better.

Adding dependencies is only justifiable if there is an increase an increase of performance/functionality.

[TSC21]

Ok nice. Do you have some time to dedicate to this and issue a PR?

[TSC21]

Also we will need the same implementation here https://github.com/mavlink/mavros/pull/684/files#diff-d6d9379eca06dca47c809d24983a3e28R137 and here https://github.com/mavlink/mavros/pull/684/files#diff-d6d9379eca06dca47c809d24983a3e28R161, which will be the inverse (WGS84 to AMSL). Thanks

[TSC21]

Solved in #693

[vooon]

Not merged — not solved!

[TSC21]

693 now merged and solved. @mantelt thanks for pointing this out. MAVROS now uses GeographicLib.

[chngdickson]

Not Solved in Ros2 2023, NavSatFix still uses WGS84