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

incorrect orientation when tf_ned_to_enu=false #19

Open
FletcherFT opened this issue Aug 13, 2018 · 4 comments
Open

incorrect orientation when tf_ned_to_enu=false #19

FletcherFT opened this issue Aug 13, 2018 · 4 comments

Comments

@FletcherFT
Copy link

Related to #13 , from what I can tell from main.cpp, the tf_ned_to_enu parameter is meant to output the orientation of the um7 in an ENU configuration for ROS, which I think was fixed by the OP in #13 . This issue is for when tf_ned_to_enu=false, the orientation, angular velocities and accelerations should be referenced to the um7's axes (which is in a NED configuration when the um7 is placed sticker side up).

While visualising the um7 orientation in RVIZ by running a simple tf2_ros broadcaster node between "odom" and "imu_link" frames and a tf2 static_transform_broadcaster node publishing "imu_link"->"imu_link_ned" transform, I found that rotating the um7 about its axes would produce incorrect NED rotations in rviz.

Setup

static_tf_broadcaster (converts from NED to ENU
rosrun tf2_ros static_transform_publisher 0 0 0 0.70710678118 0.70710678118 0 0 imu_link imu_link_ned
tf broadcast node (broadcasts odom->imu_link)
imu_transform_broadcaster.py.zip

rviz visualiation
imu_rviz.rviz.zip

Let me know if I've messed up the tf in static_tf_broadcaster or in the broadcast node, but I'm pretty sure it's the right conversion.

The tf in main.cpp that works for this configuration (line 238 - 241) is:

imu_msg.orientation.w = r.quat.get_scaled(0);
imu_msg.orientation.x = r.quat.get_scaled(2);
imu_msg.orientation.y = r.quat.get_scaled(1);
imu_msg.orientation.z = -r.quat.get_scaled(3);

First time I've really spent playing around with quaternions and tfs, but from my perspective the changes from #13 and this one makes sure that the um7 is conforming to REP145.

@rdockterjr
Copy link

@FletcherFT I get the impression this repo is not being maintained actively any longer? Last commit was 2 years ago. Should one of us fork this repo elsewhere and incorporate these changes?

@FletcherFT
Copy link
Author

I forked the repo here and incorporated the changes on the kinetic branch, though I haven't done merged the changes onto any of the other branches. My UM7 has been deployed and I probably won't get it back for a while, so my dev time is gone. I can add you as a collaborator if you'd like, or you can just fork mine and continue the struggle.

@tonybaltovski
Copy link
Member

@FletcherFT according to the datesheet the current order is correct. Are you using an UM7-LT by any chance?

@tonybaltovski
Copy link
Member

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