Check frame conversions (NED->ENU ROS)

[vooon]

Current implementation use this definitions av8n.com of NED and ENU. Conversion is just invert Y & Z axis (all right-handed).

But according to CoordinateFramConventions it is left-handed?

[tonybaltovski]

I did the same, inverting the Y & Z axis for orientation and acceleration. Don't forget to switch X and Y for the magnetometer and invert Z.

[vooon]

Why magnetometer use different conversion?

[ggregory8]

Normal NED <> ENU conversion is swap X and Y and invert Z.

What is the invert Y & Z conversion for?

[vooon]

Is it front not X? Or it is for body? I do rotation on X 180° => Y & Z inverts.

[tonybaltovski]

Acceleration and angular rates are related to the body frame itself so 180 degrees rotates it according to the body frame that is needed for ROS. Using ROS's standard X is forward, Y is left and Z is up. Using the absolute frame ENU, East is X and forward, North is Y and left and Up is Z and Up. So going from NED to ENU, those changes need to be made to follow the ROS standard. I have not tested the magnetometer since I use my APM unit in an area with magnetic interference but I will do so soon.

[vooon]

I can test, but don't know how to visualize it and where it should point (North?).

[tonybaltovski]

Hard to visualize. The maximum values for XYZ should be at ENU, so when X is pointing East it should be the largest value and West the smallest. For North and South, it should be zero. I can test later today.

[vooon]

Change conversion to swap X & Y, invert Z.
My test result:

---
header: 
  seq: 518
  stamp: 
    secs: 1405349368
    nsecs: 478252984
  frame_id: fcu
magnetic_field: 
  x: -101000.0
  y: 13000.0
  z: -369000.0
magnetic_field_covariance: [-1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

3DR GPS module arrow pointing to East, and x ~= 101000.0 when pointing to West.
QGC HUD compass match arrow (East) so i think APM:Plane properly configured.

[tonybaltovski]

I believe it is correct as well, I tested with my 3DR GPS/compass.

[mhkabir]

I need to know, what quaternion conventions are we using on the IMU data topics?

[vooon]

Invert Y & Z, then convert (tf:Quaternion.setRPY).

[vooon]

Released 0.6. This theme still opened for hotfix (if any).

[mhkabir]

I was checking this...

If I point the Pixhawk horizontally (flat), I get +9.8 on Z
If I point the Pixhawk right side up I get +9.8 on Y
If I point the Pixhawk top side up I get +9.8 on X

Is that correct??????? In ENU, will X be pointing forward and Y be pointing right?

[vooon]

Y must point to left. Try imu rviz plugin to check. In my case vector pointing up in all poses (see my screenshots in #33).

[vooon]

New question: how to convert quaternion?

[ggregory8]

What quaternion to euler angles?

https://www.dropbox.com/s/my1fvqr81rtfpoe/quaternion-rotations-tested_g.xls

On Thu, Jul 24, 2014 at 10:03 PM, Vladimir Ermakov <notifications@github.com

wrote:

New question: how to convert quaternion?

Reply to this email directly or view it on GitHub
#49 (comment).

Regards,
Glenn Gregory

M: +61 (0) 413 902 541

[vooon]

No, convert frame ENU→NED.

[tonybaltovski]

I believe it is:
NED -> ENU
X -> Y
Y -> X
Z -> -Z
W -> W

[TSC21]

@mhkabir and @ggregory8 I call your attention also to this.
Related to this issue:
Seems like the ENU<->NED conversion may not be ok. I have a downward facing camera in front of the quad. The right orientation in the case of the static transform between the camera and /vision (which is the fcu) should be a 90 degrees rotation in yaw and 90 degrees rotation in pitch. That gave me a proper orientation of /vision relative to /ar_marker8 (/local_origin). The orientation of /fcu relative to /vision seems to have a approximately +135 degrees in Yaw, as the following images seem to show:

Just /vision relative to /local_origin now: (which is ok)

Just /fcu relative to /local_origin: (which as a strange yaw rotation)

It seems a strange Yaw rotation. If it was a inverted axis or something I would comprehend, now a 135 degrees in yaw seems weird. My pixhawk is facing forward, as normal.
Any tips on this?

[TSC21]

I have a doubt regarding the conventions, which I need to clarify to add to my thesis:
NED, according to this is X axis points forward, the Y axis points left, and the Z axis points down.
ENU, according to this is X axis points left, the Y axis points forward, and the Z axis points up.
But ROS ENU is X axis points forward, the Y axis points left, and the Z axis points up, which means:

But why is the ROS ENU different? Can someone please explain me this?

[TSC21]

Or am I making a confusion between the body-frame and the absolute frame (known as inertial frame)?
From what I can see from the conversions, what I can understand is this:

Is this right?

[vooon]

Initially it confuse me too, but later I found that the x-forward refers to a body-fixed frames.
But you can ask at http://answers.ros.org some description.

[TSC21]

ok. but then the conversions below in the picture are right then, right?

[vooon]

Yes. At least i use that convention in code.

[mhkabir]

@TSC21 @vooon can either of you please draw an orientation trivector on the IMU and show it with respect to the front of the copter in ROS frame?

I'm still confused and a diagram would clear it.

[vooon]

@mhkabir Look at the diagram of the last TSC21's post for body-frame.

[mhkabir]

Thanks. Got it already :)
On Sep 21, 2014 8:53 PM, "Vladimir Ermakov" notifications@github.com
wrote:

@mhkabir https://github.com/mhkabir Look at the chart of the last
TSC21's post for body-frame.

—
Reply to this email directly or view it on GitHub
#49 (comment).

[ziyangli]

@vooon
I have the same question ---- Why magnetometer use different conversion?

[tonybaltovski]

The mag is absolute and the others are relative.

[supermice]

Hi, everyone
Does that means the attitude and position use the different base_coordinates in ROS? I tried to display the 'tf' data in ROS rviz use mavros . I find that the attitude's x axis is in red and when I move the aircraft along the attitude's x axis but the 'tf' shows move to right(-y direction). Is there any problem with the local_origin tf ?