Could not transform the global plan to the frame of the controller

Question

Hello,

I am using the husky mobile base with ros kinetic. I am using hector_mapping for getting the map and using move_base for sending simple 2D navigation goal. I additionally tried using the map_server to save the map and use the map with amcl and move_base. I am assuming this is mostly coming from move_base. However In either case whenever I pass a 2D navigation goal. I start receiving:

[ INFO] [1538375948.914403476]: Got new plan
[ERROR] [1538375948.914494414]: Extrapolation Error: Lookup would require extrapolation into the future.  Requested time 1538375948.918941058 but the latest data is at time 1538375948.914756447, when looking up transform from frame [odom] to frame [map]

[ERROR] [1538375948.914534395]: Global Frame: odom Plan Frame size 50: map

[ WARN] [1538375948.914546917]: Could not transform the global plan to the frame of the controller
[ERROR] [1538375948.914558586]: Could not get local plan

I came across couple of posts: like this one . I synced the clock. Here is tf_monitor output:

base_link to odom:

RESULTS: for base_link to odom
Chain is: base_link -> odom
Net delay     avg = -0.0313133: max = 0.0478765

odom to map RESULTS: for odom to map Chain is: odom -> map Net delay avg = -0.0281289: max = 0.000102856

Frames:

All Broadcasters:
Node: unknown_publisher 85.9467 Hz, Average Delay: -0.00285203 Max Delay: 0.339757
Node: unknown_publisher(static) 1e+08 Hz, Average Delay: 0 Max Delay: 0

base_link to map

RESULTS: for base_link to map
Chain is: base_link -> odom -> map
Net delay     avg = -0.0273669: max = 0
Frames:
Frame: base_link published by unknown_publisher Average Delay: 0.00281878 Max Delay: 0.0196072

Also attached is the tf tree for move_base and amcl.tf_tree rqt_graph

costmap_common.yaml

footprint: [[-0.5, -0.33], [-0.5, 0.33], [0.5, 0.33], [0.5, -0.33]]
footprint_padding: 0.01

robot_base_frame: base_link
update_frequency: 4.0
publish_frequency: 3.0
transform_tolerance: 0.5

resolution: 0.05

obstacle_range: 1.5
raytrace_range: 6.0

#layer definitions
static:
    map_topic: /map
    subscribe_to_updates: true

obstacles_laser:
    observation_sources: laser
    laser: {data_type: LaserScan, clearing: true, marking: true, topic: /r2000_node/scan, inf_is_valid: true}

inflation:
    inflation_radius: 1.0
cribe_to_updates: true

obstacles_laser:
    observation_sources: laser
    laser: {data_type: LaserScan, clearing: true, marking: true, topic: /r2000_node/scan, inf_is_valid: true}

inflation:
    inflation_radius: 1.0

I have not changed much in the other config files that are under husky_navigation.

Any suggestion is greatly appreciated

---

Originally posted by arunavanag on ROS Answers with karma: 277 on 2018-10-01

Post score: 4

---

Original comments

Comment by Subodh Malgonde on 2018-10-30:
I don't think that this is the reason for your error but obstacle_layer is misspelt as obstacles_laser in costmap_common.yaml. And the section is repeated twice.

Comment by Subodh Malgonde on 2018-10-30:
Also, were you able to figure this one out? I have been struggling with this for the past 3 days.

Answer 1

I was also getting the "Extrapolation into the future" errors when using move_base with amcl. I switched to a faster localization package, MIT's Particle Filter, and it fixed these errors for me.

EDIT: I just realized that the faster localization package did not fix these errors for me. I made one more change along with using another localization package. I set the global_frame of local_costmap_params.yaml to map, earlier it was set to odom. This fixed these errors. No matter what localization package I use, if I set global_frame to odom then I get these errors.

---

Originally posted by Subodh Malgonde with karma: 512 on 2018-11-01

This answer was NOT ACCEPTED on the original site

Post score: 8

---

Original comments

Comment by stevemartin on 2019-01-22:
@Subodh Malgonde I also had this issue and changed to map and it worked. But is this correct?

Comment by itaouil on 2020-04-05:
I also changed the global_frame from odom to map and I don't have localization issues anymore.

Comment by JunTuck on 2020-10-27:
Worked for me too! Thanks!! :)

Comment by Tristan9497 on 2020-11-26:
Thanks man, it worked! Searched for a solution way to long before giving it a try...

Answer 2

I think the most proper way to solve this problem is

increase param transform_tolerance in amcl.

Without change source code, and no need to set the global frame to map in local_costmap which may result in oscillation during navigation.

This problem bothered me from time to time in the last three months.

---

Originally posted by tianb03 with karma: 710 on 2020-10-26

This answer was NOT ACCEPTED on the original site

Post score: 4

---

Original comments

Comment by Johart24 on 2022-03-31:
Which is a good value? how do you define it ?

Comment by tianb03 on 2022-04-06:
Simply increasing the transform tolerance to there is no warning should be fine, as long as the robot won't collide with obstacles.

Comment by mgrallos on 2023-01-25:
do I also increase the tolerance in the costmap.yaml?

Comment by tianb03 on 2023-02-06:
If there is no warning then no need to increase.

Comment by violasrq on 2023-06-27:
you can increase the tolerance in the amcl.launch

Answer 3

Rufus was almost correct. In some cases if you using low freq. laser sensors like 10-12Hz (Sick S300), AMCL will publish transform with same freq. If you using global planner quite frequently 1-2Hz, randomly you will face with this problem.

If all this is correct for you, then local base planner has a bug for you. But the line causing this is not (108 as Rufus mentioned), but this line (base_local_planner/src/goal_functions.cpp): 113 tf.transform(global_pose, robot_pose, plan_pose.header.frame_id);

For me is difficult to understand why they did not put timeout for this line, unlike 108 (which is fine). There is no logic in this. Why they did this unblocking/instant.

So to solve this issue need to add timeout to line 113, it will look like that: tf.transform(global_pose, robot_pose, plan_pose.header.frame_id, ros::Duration(0.1));

Timeout duration will depend on your particular case, but usually 0.1 is more than you need.

---

Originally posted by Maksim Sokolov with karma: 21 on 2021-11-03

This answer was NOT ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by hunterlineage1 on 2023-05-10:
This worked perfectly

Answer 4

Changing odom to map in local_costmap_params.yaml does not tackle the root of the problem.

The error is likely caused by the frequency / timing mismatch in publishing for your tf /map -> /odom and the rest of the tree. Take a look at this answer.

In my case, I solved this by making my /map -> /odom transform valid by adding a bit of buffer time to the transform.header.stamp (i.e. making the transform slightly from the future) like so:

    map_to_odom_msg.header.stamp = now + ros::Duration(1.0);

It sure seems hacky, but it worked for me... It'd be great if someone could correct me if there's a more proper way of synchronizing tfs.

For reference, the error message stems from this line of code. I suspect that line is missing a waitForTransform but I'm no expert in the ROS source code..

---

Originally posted by Rufus with karma: 1083 on 2020-01-06

This answer was NOT ACCEPTED on the original site

Post score: 3

---

Original comments

Comment by adsasine on 2021-04-08:
It's pretty crazy that the local planner can't work without a localization system that post-dates the transforms. Even amcl has a similar parameter (transform_tolerance)