Ask Your Question
0

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

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

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
1

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

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

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 gravatar imageStephan ( 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 gravatar imageskyofyao@gmail.com ( 2019-10-14 14:23:46 -0600 )edit
1

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

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

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 gravatar imageStephan ( 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 gravatar imageEwingKang ( 2018-07-23 03:00:25 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

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

Seen: 425 times

Last updated: Jul 30 '18