Revision history [back]

I think now I understand why amcl publishes the map to odom transform. This is explained in the Transforms section of the amcl documention. 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 this post also helped me cement this understanding - How to broadcast a transform between /map and /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.

I think now I understand why amcl publishes the map to odom transform. This is explained in the Transforms section of the amcl documentiondocumentation. 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 this post also helped me cement this understanding - How to broadcast a transform between /map and /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. frame.

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 this post these posts also helped me cement this understanding - 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.