ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

Confused with amcl map to odom transform

asked 2018-08-20 04:35:33 -0500

Subodh Malgonde gravatar image

updated 2018-08-20 04:36:39 -0500

I am using amcl for localizing my robot in Gazebo in a known map. My robot has an IMU and a laser on it.

I was going through the amcl docs and I noticed this.

Published Topics 
...
tf (tf/tfMessage) 
Publishes the transform from odom (which can be remapped via the ~odom_frame_id parameter) to map.

According to REP-105, both odom & map are world fixed frames. So why does amcl publish a transform from map to odom? Shouldn't this transform be static?

Note: Although it is not relevant to this question, but if you are wondering - I am generating the odometry data using package robot_localization, which takes as input the IMU data. amcl requires odometry and laser scan data to localize the robot.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
5

answered 2018-08-21 02:18:57 -0500

Subodh Malgonde gravatar image

updated 2018-08-21 02:27:28 -0500

I think now I understand why amcl publishes the map to odom transform. This is explained in the Transforms section of the amcl documentation. Reproducing it here with the relevant emphasis:

amcl transforms incoming laser scans to the odometry frame (~odom_frame_id). So there must exist a path through the tf tree from the frame in which the laser scans are published to the odometry frame.

An implementation detail: on receipt of the first laser scan, amcl looks up the transform between the laser's frame and the base frame (~base_frame_id), and latches it forever. So amcl cannot handle a laser that moves with respect to the base.

The drawing below shows the difference between localization using odometry and amcl. During operation amcl estimates the transformation of the base frame (~base_frame_id) in respect to the global frame (~global_frame_id) but it only publishes the transform between the global frame and the odometry frame (~odom_frame_id). Essentially, this transform accounts for the drift that occurs using Dead Reckoning.

image description

Additionally these posts also helped me cement this understanding:

  1. How to broadcast a transform between /map and /odom
  2. transform base_link to base_laser,map,odom

So to summarize:

  1. Both odom and map are world fixed frames
  2. However the pose in odom frame will drift due to dead reckoning
  3. To fix this you publish a map to odom transform, which essentially fixes the pose of the robot in the map frame.
edit flag offensive delete link more

Question Tools

3 followers

Stats

Asked: 2018-08-20 04:35:33 -0500

Seen: 4,888 times

Last updated: Aug 21 '18