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

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

1924 ●25 ●42 ●56

    // 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

add a comment

1

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

Chrisando
41 ●1 ●3 ●3

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

Comments

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 ( 2018-07-30 09:58:35 -0600 )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.

skyofyao@gmail.com ( 2019-10-14 14:23:46 -0600 )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 ( 2020-05-05 03:08:22 -0600 )edit

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

gvdhoorn ( 2020-05-05 03:09:17 -0600 )edit

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

N.N.Huy ( 2022-09-14 02:58:57 -0600 )edit

add a comment

1

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

EwingKang
78 ●3 ●6 ●11

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

Comments

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 ( 2018-07-06 03:22:35 -0600 )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 ( 2018-07-23 03:00:25 -0600 )edit

add a comment

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

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

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

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

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