search

ros-geographic-info / geographic_info

ROS packages for geographic information
http://ros.org/wiki/geographic_info
66 stars 62 forks source link

geodesy: add support for conversions to and from ECEF #18

Open jack-oquin opened 7 years ago

jack-oquin commented 7 years ago

This is needed to support the earth frame ID, as described in REP-0105, "Coordinate Frames for Mobile Platforms".

xref:

TSC21 commented 7 years ago

I'm looking for this also @jack-oquin so to update https://github.com/mavlink/mavros/pull/691. Any plans to get this in soon? Thanks

jack-oquin commented 7 years ago

I probably won't have time to work on this any time soon.

A pull request adding it would be good, if anyone has a chance to work on it.

TSC21 commented 7 years ago

What would the implementation include? Can't we just create msgs with ECEF as the coordinate system?

TSC21 commented 7 years ago

Or probably we can add an enumeration to the msg structure and a variable that defines what is the coordinate system we are using (ECEF, WGS 84, ...)

jack-oquin commented 7 years ago

It's been a while since I've looked at this code. It's been pretty stable.

I'd start by looking at the WGS-84 implementation and adding similar classes, headers, tests, etc for ECEF.

TSC21 commented 7 years ago

Still can't understand why we are expecting to add the conversions. Can't that be done by another node/ros app? Can't we just decide what frame we want to use on the msg we are sending?

jack-oquin commented 7 years ago

The main goal for these (and almost all) ROS messages is to allow data exchange between packages provided by different developers.

The consensus of the original reviewers what that the geographic messages should be self-describing and unambiguous. The sending and receiving nodes can take responsibility for translating the data to and from whatever units they prefer. The geodesy package is provided to make it easy for nodes to do some common conversions. They are not required to use it.

TSC21 commented 7 years ago

Ok so we area already doing this on MAVROS side (using GeographicLib). I thought the msg was going to receive an update and not geodesy. So I suppose that the geographic_msgs will keep their current units.

jack-oquin commented 7 years ago

I would think so, yes.

jack-oquin commented 7 years ago

Still, ECEF conversions would be nice to have.

TSC21 commented 7 years ago

I think this may help: http://mathforum.org/library/drmath/view/51832.html; https://stackoverflow.com/questions/19478200/convert-latitude-and-longitude-to-ecef-coordinates-system

jack-oquin commented 7 years ago

Thanks for the link. Looks helpful!

TSC21 commented 7 years ago

On MAVROS case, we are using the GeographicLib capabilities to convert heights above geoid to above the ellipsoid and vice-versa, and also to compute the ECEF<->LLA transformations. We also compute ECEF<->ENU to be used on situations where we want to transform to NED frame (for aerospace control).

matteopantano commented 5 years ago

Here a simple workaround: convert_ecef_to_llh