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

NED quaternion to ENU quaternion #4

Open
mattbrown11 opened this issue Jun 18, 2017 · 5 comments
Open

NED quaternion to ENU quaternion #4

mattbrown11 opened this issue Jun 18, 2017 · 5 comments

Comments

@mattbrown11
Copy link

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

bsb808 commented Jun 20, 2017

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

Yes, your package has been very helpful. Thanks.

@jwag
Copy link

jwag commented Aug 28, 2018

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

mattbrown11 commented Aug 29, 2018

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

bsb808 commented Aug 29, 2018

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.

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