NED vs ENU vs whatever we have now..

[Randy Mackay]

     Jason, Leonard and I have been dicussing the new nav controllers a bit and the question of axis conventions has come up.

     Traditionally our navigation code has all be lat-lon-alt based but the new inertial navigation (including the AP_InertialNav lib, throttle, loiter and waypoint controllers) are currently NEU.  In aerospace NED is the most common convention so we should move to use that.

     ..but for communicating with the ground station and user, the lat-lon-alt is still the most easily understood method.  So after the change, what you will see is the code internally will use 3D vectors for representing position, velocity or acceleration and these will always be in NED.  At touch points with the groundstation you will use Location structures (lat-lon-alt) or accessor functions will be provided so you can get the lat, lon or alt in a human/groundstation recognizable format.

     This change is fairly significant and we only want to do it once so we will make this change after we merge the library based loiter + wp controllers that leonard and I have been working on into master (if you want to see what the new library looks like you can find it in the rmackay9-ardupilot clone's wpnavlib branch).

     For reference here's the wiki page re axis conventions:

              http://en.wikipedia.org/wiki/Axes_conventions

     All feedback welcome!

-Randy

[Meier Lorenz]

Hi Randy,

I did these surveys already a few times, and in the UAV / MAV / aerospace world its always NED. Even a share of the robotics researchers use it (e.g. we do, U.S. universities are a bit split between NED and ENU).

I would not know anyone using NEU, and technically lat/lon/alt aren't NEU either, so your proposal to move to NED seems sensible.

Coordinate frame conventions should never been influenced by UI design, the UI should at any rate just display a human-readable thing, which not always translates well to elegant math operations.

So by all means, I think your proposal is very sensible.

-Lorenz

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.

[Shital Shah]

One of the problem is that most of the ROS stack is ENU. How do people normally deal with this? Do they just convert to ENU when using things in ROS (RViz, for example)?

On Saturday, April 6, 2013 at 2:16:45 PM UTC-7, Lorenz Meier wrote:

Hi Randy,

I did these surveys already a few times, and in the UAV / MAV / aerospace world its always NED. Even a share of the robotics researchers use it (e.g. we do, U.S. universities are a bit split between NED and ENU).

I would not know anyone using NEU, and technically lat/lon/alt aren't NEU either, so your proposal to move to NED seems sensible.

Coordinate frame conventions should never been influenced by UI design, the UI should at any rate just display a human-readable thing, which not always translates well to elegant math operations.

So by all means, I think your proposal is very sensible.

-Lorenz

On 6 Apr 2013, at 04:44, Randy Mackay <rmac...@yahoo.com<mailto:rmack...@yahoo.com>> wrote:


     Jason, Leonard and I have been dicussing the new nav controllers a bit and the question of axis conventions has come up.

     Traditionally our navigation code has all be lat-lon-alt based but the new inertial navigation (including the AP_InertialNav lib, throttle, loiter and waypoint controllers) are currently NEU.  In aerospace NED is the most common convention so we should move to use that.

     ..but for communicating with the ground station and user, the lat-lon-alt is still the most easily understood method.  So after the change, what you will see is the code internally will use 3D vectors for representing position, velocity or acceleration and these will always be in NED.  At touch points with the groundstation you will use Location structures (lat-lon-alt) or accessor functions will be provided so you can get the lat, lon or alt in a human/groundstation recognizable format.

     This change is fairly significant and we only want to do it once so we will make this change after we merge the library based loiter + wp controllers that leonard and I have been working on into master (if you want to see what the new library looks like you can find it in the rmackay9-ardupilot clone's wpnavlib branch).

     For reference here's the wiki page re axis conventions:
              http://en.wikipedia.org/wiki/Axes_conventions

     All feedback welcome!

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

[George ZP]

I agree that the NED frame is the formal and mathematically straightforward thing to do, with most of the literature supporting it. This will make it especially easier to port mathematical methodologies into software algorithms.

ROS might indeed favour ENU, but it was developed mostly with rovers in mind, not aerospace applications. ROS will have to bend to the will of existing mathematical theory, not vice versa.

As for the UI, generally conversions between WGS84, UTM and NED are trivial and well-known. Just don't forget to set h = -z ! ;)