-
Notifications
You must be signed in to change notification settings - Fork 62
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.
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
geodesy: add support for conversions to and from ECEF #18
Comments
I'm looking for this also @jack-oquin so to update mavlink/mavros#691. Any plans to get this in soon? Thanks |
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. |
What would the implementation include? Can't we just create msgs with ECEF as the coordinate system? |
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, ...) |
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. |
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? |
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 |
Ok so we area already doing this on MAVROS side (using GeographicLib). I thought the msg was going to receive an update and not |
I would think so, yes. |
Still, ECEF conversions would be nice to have. |
Thanks for the link. Looks helpful! |
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). |
Here a simple workaround: convert_ecef_to_llh |
This is needed to support the
earth
frame ID, as described in REP-0105, "Coordinate Frames for Mobile Platforms".xref:
The text was updated successfully, but these errors were encountered: