NED quaternion to ENU quaternion

[mattbrown11]

I see that a conversion is done from the NED quaternion returned from the INS into an ENU quaternion expected by ROS by swapping the x/y components and negating z. If we consider the NED quaternion to represent the orientation of the INS frame (printed on the body of the INS) relative to NED, then the resulting ENU conversion does not provide a quaternion representing the orientation of the INS frame relative to ENU. You can see this simply by looking at an identity NED quaternion, which with the current conversion maps to an identity ENU quaternion, but the INS frame (printed on the body) cannot be aligned with both ENU and NED. I believe the conversion that is being done results in a quaternion that represents a right/front/up coordinate system relative to ENU. I suppose this is fine in some cases if you know that is what is being returned, but in my case where I have programmed in camera orientations relative to the INS body frame, it caused some confusion.

[bsb808]

Thank you for for the note - that is indeed an undocumented gotcha that should be added the the documentation. I'll try to take some pictures to help make our use-case overt.

Also happy if you want to add some documentation on how you are using the driver. Hopefully it is helpful.

[mattbrown11]

Yes, your package has been very helpful. Thanks.

[jwag]

I was just wondering if you could clarify this point about the transformed coordinate frame. I am attempting to use the ahrs data from a gx5_25 device with the robot_localizaiton package to add in wheel encoder odometry to my odometry estimate, but am having some trouble with the orientation quaternion. I believe robot_localization assumes that the orientation data on the imu_msg is in ENU, if they follow REP 145. When @mattbrown11 said that the quaternion is actually in right/front/up does that mean that the frame is actually rotated -90 deg about the up/z of the ENU frame?

[mattbrown11]

It has been a while since I looked at this, but let me see what I can piece back together. An identity NED quaternion (0,0,0,1) emitted from the device indicates that the INS frame (printed on the body of the INS) is oriented with its x-axis pointing north, y-axis pointing east, and z-axis pointing down. The true conversion from a NED quat to an ENU one would be,

quat_enu = quaternion_multiply([sqrt(2)/2,sqrt(2)/2,0,0], quat_ned)

With this library (last time I checked), the conversion to ENU swaps the x/y components and negates z, which for an identity NED would become an identity ENU (0,0,0,1). However, an identity ENU quaternion implies that the INS frame is aligned with x-axis pointing east, y-axis pointing north, and z-axis pointing up. Therefore, I would assume that if you mount the INS so that its body-printed coordinates axes point with x-axis along vehicle front, y-axis along vehicle right, and z-axis vehicle down, the ENU output from this library will give the orientation of the vehicle's right/front/up.

[bsb808]

The way we've used this driver is to mount the device such that...

• The y-axis printed on the device is pointing forward on the robot (towards the bow)
• The x-axis printed on the device is pointing to the left of the robot (towards the port side)

This results in an orientation that is ENU.

The method of swapping x/y and negating z is non-ideal, but it seems to work for our use cases. I haven't had much time lately to work on adding more functionality, but if someone was interested in adding other methods for conversion, perhaps we could add a configuration parameter to allow for different methods.