# Confused with amcl map to odom transform

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 close merge delete

Sort by » oldest newest most voted

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.

Additionally these posts also helped me cement this understanding:

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.
more