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!
Originally posted by Jasmin on ROS Answers with karma: 188 on 2017-02-27
Post score: 1
Original comments
Comment by Tom Moore on 2017-07-20:
Did you ever solve this?
Comment by Jasmin on 2017-07-26:
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.
Comment by Jasmin on 2017-07-26:
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.
Comment by Jasmin on 2017-07-26:
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.
Comment by Tom Moore on 2017-07-26:
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?
Comment by Jasmin on 2017-07-26:
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!
Comment by Jasmin on 2017-07-26:
z ~ -9.9 when the board is on a flat table facing its flat side (not the one containing the components)
Comment by Tom Moore on 2017-07-26:
What does it read if you use the Phidgets software, and not the ROS driver?
Comment by Tom Moore on 2017-07-26:
No, after looking at two different IMUs, I believe r_l makes the correct assumptions. We just needs the drivers to conform.
Comment by Jasmin on 2017-07-27:
Do you mean conform the ROS REP? so that its z is pointing up and so on or the hardware itself so that it has the same behavior and measurements than the sensor's software tools.
Comment by Tom Moore on 2017-07-27:
No, I believe the ROS driver is inverting all axes, so I want to look at the data outside of ROS, using the Phidgets GUI-based app.
Comment by Tom Moore on 2017-09-11:
@Jasmin, would you mind updating this question and/or marking it as closed?