# adding "good" IMU data causes troubles to robot_pose_ekf

Hi,

I am using a MMP for navigation and mapping. I got trouble while rotating with move_base and debugged the robot_pose_ekf data. Here are my strange results :

• when imu_used : false in the ekf.yaml file, I sent a move_base goal of 90 degrees to the left and the robot rotated 90 degrees to the left, and /encoder topic gave expected quaternions. Looked fine.
• Then I set imu_used: true and I sent the move_base goal of 90 degrees to the left (after restarting the roscore to set the new parameter). The robot rotated about 170 degrees -instead of 90- but the quaternions in /imu/data and /robot_pose_ekf/odom are fine (I mean expected data).
• I created a node to rotate 90 degrees using only IMU data and the robot rotated 90 degrees as expected.

Can the error be from parameters in move_base? I checked the frames, looks fine too.

Here is the husky_ekf.yaml :

freq: 10.0
output_frame: "odom"
sensor_timeout: 1.0
publish_tf: true
odom_used: true
imu_used: true


The gps is disabled

And here is the launch file:

<launch>
<node pkg="robot_pose_ekf" type="robot_pose_ekf" name="robot_pose_ekf" output="screen">
<remap from="gps" to="gps/fix"/>
<remap from="imu_data" to="imu/data"/>
<remap from="odom" to="encoder"/>
</node>
</launch>

edit retag close merge delete

Sort by » oldest newest most voted

Perhaps the transform from /base_footprint to /imu_link is wrong. Did you try visualizing the transforms in RViz? If you select /odom (or odom_combined, or however it's called) as the fixed frame, and visualize the transform to /base_footprint, does everything behave as expected? I.e., is the z axis of /base_footprint up, and does the frame yaw correctly when the robot yaws?

more

Hi Martin, thanks for your answer.Yes,I checked all of that,but there is still one thing I don't understand :I tried to rotate the IMU frame in the tf_broadcaster, but then it rotated the odom frame too even if I didn't change it.Then the laser frame,base_footprint and everything was wrong.Any idea?

( 2015-02-17 03:58:46 -0500 )edit

With respect to what is your odom frame rotated? I thought it was the root of your tf tree (for now) and your fixed frame in RViz.

( 2015-02-17 04:13:39 -0500 )edit

Also: what's the tf_broadcaster you're talking about broadcasting? The transform from base_footprint to imu_link, correct? Assuming this is the case, that's what happens: robot_pose_ekf determines the absolute orientation of the imu_link from the imu message, ...

( 2015-02-17 04:16:21 -0500 )edit

... and then adjusts the tf from /odom_combined -> /base_footprint so that the orientation of the imu_link (wrt. a virtual world frame, where z points up) matches the one from the imu message. This is why the correct orientation of imu_link wrt. base_footprint matters.

( 2015-02-17 04:19:16 -0500 )edit

But if all of that is working correctly, we've ruled out robot_pose_ekf as the source of the error.

( 2015-02-17 04:22:28 -0500 )edit
1

If you rotate the /base_footprint -> /imu_link tf, the /odom_combined -> /base_footprint tf should rotate to compensate for this. Since the laser_link is presumably attached via a fixed tf to /base_footprint, it's expected that it rotates as well.

( 2015-02-18 04:16:43 -0500 )edit
1

It makes sense, because presumably the orientation in the IMU msg didn't change, so the tf from /odom_combined -> /imu_link shouldn't change. If the /base_footprint -> imu_link tf rotates (i.e. the IMU is rotating on the robot), the only way to make sense of this is that the robot rotated.

( 2015-02-18 04:19:03 -0500 )edit

Hi Martin, the tf transform is definitely fine. Do you have any other idea where it could be from? It could be from magnetometer calibration. What is strange is that odom and IMU work "fine" separately, even if the IMU data is not really stable

( 2015-02-22 06:54:09 -0500 )edit