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!
Did you ever solve this?
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.
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.
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.
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?
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!
z ~ -9.9 when the board is on a flat table facing its flat side (not the one containing the components)
What does it read if you use the Phidgets software, and not the ROS driver?