adding "good" IMU data causes troubles to robot_pose_ekf

Question

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">
  <rosparam command="load" file="$(find clearpath_tec_bringup)/config/husky_ekf.yaml"/>
  <remap from="gps" to="gps/fix"/>
  <remap from="imu_data" to="imu/data"/>
  <remap from="odom" to="encoder"/>
</node>
</launch>

---

Originally posted by est_CEAR on ROS Answers with karma: 170 on 2015-02-05

Post score: 1

Answer 1

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?

---

Originally posted by Martin Günther with karma: 11816 on 2015-02-17

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by est_CEAR on 2015-02-17:
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?

Comment by Martin Günther on 2015-02-17:
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.

Comment by Martin Günther on 2015-02-17:
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, ...

Comment by Martin Günther on 2015-02-17:
... 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.

Comment by Martin Günther on 2015-02-17:
But if all of that is working correctly, we've ruled out robot_pose_ekf as the source of the error.

Comment by Martin Günther on 2015-02-18:
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.

Comment by Martin Günther on 2015-02-18:
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.

Comment by est_CEAR on 2015-02-22:
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