ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Transform data too old when converting from odom to map

asked 2020-02-20 02:18:36 -0600

ninamwa gravatar image

updated 2020-02-21 02:36:15 -0600

Hi. I am running Navigation2 on Eloquent with my real robot. This worked fine earlier, but lately i have getting a lot of warnings like this:

[controller_server-4] [ERROR] [tf_help]: Transform data too old when converting from odom to map 
[controller_server-4] [ERROR] [tf_help]: Data time: 1582132944s 839526653ns, Transform time: 1582132944s 617414951ns
[controller_server-4] [ERROR] [controller_server]: Unable to transform robot pose into global plan's frame
[controller_server-4] [WARN] [controller_server_rclcpp_node]: [follow_path] [ActionServer] Aborting handle.

This happens every time I give a new goal, which means it seems to happen during the planning of the global plan. It always leads to the robot going into recovery behavior.

The transform between odom and map is, as far as i know, provided by AMCL. When listening to the '/tf' topic, i can see that the transform between odom-->base_footprint, which is provided by me, is published at a much higher rate than the map-->odom transform, which i guess is the reason to why the transform data is too old.

I have tried tuning the DWB parameter "transform_tolerance". I have changed it from 0.2 to 1.2, which helped a lot, but the error still happens multiple times during one run. I do not want to raise it any more, since I guess 1.2 is already pretty high. I never had a problem with this before, so i am unsure what is triggering this behaviour?

Since this transform is not provided by me, what can i do to solve the problem?




edit retag flag offensive close merge delete


What’s the rates of the map to odom, and odom to base link transforms, specifically.

stevemacenski gravatar image stevemacenski  ( 2020-02-20 09:24:43 -0600 )edit

Map to odom is between 16-20 Hz while odom to base footprint is 65-85 Hz. I updated my question with the view_frames image from two different runs (sorry for them beeing very big!).

ninamwa gravatar image ninamwa  ( 2020-02-21 02:37:45 -0600 )edit

I made a test with the default nav2 slam example, and in the tf, map->odom has average rate 51 and odom->base has 29 and everything works fine...

Zeckurbo gravatar image Zeckurbo  ( 2022-09-06 05:51:01 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2020-02-20 08:27:46 -0600

prefpkg21 gravatar image

You could try to reduce the controller frequency, lower the number of particles, tune the publish frequency. How is the CPU usage during planning?

edit flag offensive delete link more


I don’t think this is related. They’re describing TF problems which are unlikely to manifest from CPU restriction. They’d be seeing much different errors.

stevemacenski gravatar image stevemacenski  ( 2020-02-20 09:26:15 -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



Asked: 2020-02-20 02:18:36 -0600

Seen: 464 times

Last updated: Feb 21 '20