# imu filter madguick - is it possible to get enu orientation from ned IMUs? [closed]

I'm using a phidgets spatial 3/3/3 IMU 1042, for localization purpose. Since I needed the orientation for pose estimation I use the imu_filter_madguick package to get imu/data from imu/data_raw topic. I was looking at this discussion and so many other questions and issues talking about IMUs but I'm still confused. yet I was doing the steps described in an answer for the previous question:

angular_velcocity: Rotation about the Y axis (pitch motion) is positive in the nose down direction. Rotation about the X axis (roll motion) is positive for right side down motion. Rotation about the Z axis (yaw) is positive for CCW rotation looking down on the vehicle. linear_acceleration: When stationary, x and y are around 0, z is around +9.8. All increase when turned into the direction of their respective axis.

But I'm getting strange values! the following folder contains some data samples, The raw data when the IMU is not moving, the data when turning the IMU CCW & when the selected world_frame is NED and when turning the IMU CCW & when the selected world_frame is ENU. And also the published transforms from the filter. well "turning the IMU " in my case is "turning the robot".

I'm really confused since the IMU's fixed frame axes are some how inverted the Z axis is pointing up and so on, I've been thinking if the IMU is mounted in its neutral position or inverted some how, but it is buried inside the robot and I can't get it out or check how it is really mounted at least for these couple of days. And if it is so , could this be fixed using a static transform or with the IMU's mounting description on the robot's urdf? And regarding the filter, is it giving correct orientation when ENU is used as world_frame ? I do really need to use ENU to get the robot_localization package working! I really don't get it, is reporting data in NED, ENU or NWU hardware stuff or it depends only on the orientation calculation. Any help would be appreciated!

edit retag reopen merge delete

### Closed for the following reason the question is answered, right answer was accepted by Jasmin close date 2017-09-11 12:05:01.777231

Did you ever solve this?

( 2017-07-20 04:22:38 -0600 )edit

No, I didn't. I'm not familiar with IMUs. I do really need your help on this Tom. I've tried so many things then but after that I was obliged to work on S.Th else for a while. but I'm managing to get back to this next week.

( 2017-07-26 07:21:02 -0600 )edit

Please correct me if I'm wrong... In my understanding: robot_localisation implies the IMU frame to be ENU and expect adding a tf from bl to imu_link describing the mounting of the IMU on the robot. If the used IMU is not ENU then an other tf from ned -> enu should be added.

( 2017-07-26 07:22:49 -0600 )edit

I'm not sure but the used filter seems to be publishing the needed tf if it asked to do so. The package does also imply the z axis to be pointing up, so if it is not the case , for example in Phidgets IMU I think that the z axis is pointing down in its neutral position.

( 2017-07-26 07:24:03 -0600 )edit

So I can't really help with the madgwick package, as I am not the maintainer, but r_l may have mistaken assumptions about the gravity vector, which is something I am currently investigating. What does your raw IMU data say for Z acceleration when the sensor is flat on the table?

( 2017-07-26 07:28:04 -0600 )edit

So should I mount it upside down or just invert it with tfs? I'm really confused! Sorry for being too chatty. your help would be appreciated!

( 2017-07-26 07:28:15 -0600 )edit

z ~ -9.9 when the board is on a flat table facing its flat side (not the one containing the components)

( 2017-07-26 07:39:10 -0600 )edit

What does it read if you use the Phidgets software, and not the ROS driver?

( 2017-07-26 07:40:35 -0600 )edit

Sort by » oldest newest most voted

The Phidgets IMU conforms to the right-hand rule when mounted on the board chips side (the side with the axis drawing on top), (I was initially getting "weird" measurements because it was mounted on the flat side) Also the driver is taking the ROS standards into consideration allowing every axis to read +1G when it's facing up. So it behaves as an enu IMU when mouted as described above, and it's reporting enu orientation. Everything should work fine with r_l package when setting the imu_filter_madguick parameter world_frame to enu.

This confusion was not due to a problem in the used hardware or software but it was due to lack of understanding of some ROS and localization basics.

Thanks for your help Tom!

more

1

You're welcome. Thanks for updating the question.

( 2017-10-11 02:56:13 -0600 )edit

## Stats

Asked: 2017-02-27 11:14:40 -0600

Seen: 1,164 times

Last updated: Sep 11 '17