Skip to content
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

Open
jack-oquin opened this issue Apr 15, 2017 · 14 comments
Open

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

jack-oquin opened this issue Apr 15, 2017 · 14 comments

Comments

@jack-oquin
Copy link
Member

jack-oquin commented Apr 15, 2017

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

xref:

@TSC21
Copy link

TSC21 commented May 27, 2017

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

@jack-oquin
Copy link
Member Author

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
Copy link

TSC21 commented May 31, 2017

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

@TSC21
Copy link

TSC21 commented May 31, 2017

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
Copy link
Member Author

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
Copy link

TSC21 commented May 31, 2017

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
Copy link
Member Author

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
Copy link

TSC21 commented Jul 4, 2017

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
Copy link
Member Author

I would think so, yes.

@jack-oquin
Copy link
Member Author

Still, ECEF conversions would be nice to have.

@jack-oquin
Copy link
Member Author

Thanks for the link. Looks helpful!

@TSC21
Copy link

TSC21 commented Jul 4, 2017

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
Copy link

Here a simple workaround: convert_ecef_to_llh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants