adding "good" IMU data causes troubles to robot_pose_ekf

asked 2015-02-05 08:28:58 -0500

est_CEAR
170 ●13 ●19 ●27

updated 2015-02-18 05:56:24 -0500

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>

answered 2015-02-17 03:44:25 -0500

Martin Günther

11816 ●82 ●159 ●198 https://www.dfki.de/en...

updated 2015-02-17 03:45:14 -0500

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?

edit flag offensive delete link

Comments

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?

est_CEAR ( 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.

Martin Günther ( 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, ...

Martin Günther ( 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.

Martin Günther ( 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.

Martin Günther ( 2015-02-17 04:22:28 -0500 )edit

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.

Martin Günther ( 2015-02-18 04:16:43 -0500 )edit

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.

Martin Günther ( 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

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

add a comment

adding "good" IMU data causes troubles to robot_pose_ekf

1 Answer

Comments

Question Tools

Stats

Related questions

adding "good" IMU data causes troubles to robot_pose_ekf edit

1 Answer

Comments

Question Tools

Stats

Related questions

adding "good" IMU data causes troubles to robot_pose_ekf