search

ros-drivers / microstrain_mips

Other
25 stars 107 forks source link

NED quaternion to ENU quaternion #4

Open mattbrown11 opened 7 years ago

mattbrown11 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Yes, your package has been very helpful. Thanks.

jwag commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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.