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

Why does AMCL post-date tf (~transform_tolerance)?

asked 2015-10-08 11:05:12 -0500

Stephan gravatar image

A comment in the code says

    // We want to send a transform that is good up until a
    // tolerance time so that odom can be used

And the wiki page says

~transform_tolerance (double, default: 0.1 seconds) Time with which to post-date the transform that is published, to indicate that this transform is valid into the future.

I still don't understand why AMCL needs to pretend to be able to see the future.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2018-07-30 09:32:26 -0500

Chrisando gravatar image

I've been trying to understand this for quite some time already, please correct me if I am wrong.

The whole tf tree is as "old" as the oldest tf update from any frame in the entire tree. For example: odom -> base_link transform updates at frequency of 100hz (encoder + imu), but map -> odom is only updated with frequency of 10hz (amcl). Position of the robot in the map frame has update frequency of 10hz (so amcl is the bottleneck).

Now if the amcl algorithm update takes 1s to compute new position, our tf broadcaster will not publish anything for 1s (since it's computing a new update and amcl run in the same loop as tf broadcaster). Therefor we need to stamp map->odom transform "in the future" (aprox as much as it takes for amcl algorithm to calculate new position update). Otherwise, we would introduce a lag in the system due to this amcl processing time, and map->base_link tf will not be updated.

Am I missing something in my reasoning? Is there any way to make a map->odom tf always true until new measurement comes in?

edit flag offensive delete link more


That could explain it. When looking up the "latest" map->base_link, the TF library looks for the latest common time of map->odom and odom->base_link. So if map->odom is old (not future-dated), we don't get the most recent odom->base_link in that lookup.

Stephan gravatar image Stephan  ( 2018-07-30 09:58:35 -0500 )edit

Great explanation. One supplement: the assumption to the TF transform map->odom is: it's stable, as it shouldn't change much in a short time. So it is OK for the AMCL node to publish such a "predicted" transformation. gravatar image  ( 2019-10-14 14:23:46 -0500 )edit

The way to make a transform valid until updated is to use a static transform broadcaster. The reason AMCL does not use it is unclear to me.

Rufus gravatar image Rufus  ( 2020-05-05 03:08:22 -0500 )edit

Most likely because it was not available at the time the AMCL wrapper nodes were written?

gvdhoorn gravatar image gvdhoorn  ( 2020-05-05 03:09:17 -0500 )edit

Why didn't they use ros::Time::now() ?

N.N.Huy gravatar image N.N.Huy  ( 2022-09-14 02:58:57 -0500 )edit

answered 2018-04-26 22:48:52 -0500

EwingKang gravatar image

According to amcl_node.cpp:1380 the tf stamp is actually based on the time stamp of the laser scan plus transform_tolerance.
I would say that this transform_tolerance parameter is actually the estimation of AMCL calculation time and have nothing to do with tf availability.

edit flag offensive delete link more


Still, as the pose that amcl computes is based on the scan, it is as old as the scan itself. If I have a laser scan at time t and need dt_compute to compute the pose, that pose should have t as stamp and not t + dt_compute. The latter would mean AMCL predicts the pose of the future.

Stephan gravatar image Stephan  ( 2018-07-06 03:22:35 -0500 )edit

@Stephan Ahh now that you've mentioned that,it seems more reasonable :p. Frankly I don't know the exact reason, maybe that is a parameter that loose its function over time. The time stamp of estimation from encoder update doesn't seem to have any problem and does not involve that param.

EwingKang gravatar image EwingKang  ( 2018-07-23 03:00:25 -0500 )edit

Question Tools



Asked: 2015-10-08 11:05:12 -0500

Seen: 1,378 times

Last updated: Jul 30 '18