Ask Your Question
0

Extrapolation Error looking up robot pose ... when looking up transform from frame [base_footprint] to frame [map]

asked 2017-02-06 19:28:49 -0500

j_salfity gravatar image

Hi All,

This is one of my first posts, please go easy on me.. To start: Working with the navigation stack in ROS Indigo, on Turtlebot with Xbox Kinect Camera. The Turtlebot is using an NVIDIA TK1 board, roscore is running on a HP Elitebook laptop. Viewing rviz on the HP Elitebook and running all the code locally on the TK1

The launch file looks like this:

<include file="$(find turtlebot_bringup)/launch/minimal.launch"/>
<include file="$(find kobuki_auto_docking)/launch/minimal.launch"/>
<include file="$(find turtlebot_navigation)/launch/amcl_demo.launch"/>
<node pkg="robot_pose_publisher" name="robot_pose_publisher" type="robot_pose_publisher"/>

Pretty simple, right?

Then i'm opening up rviz like this:

roslaunch turtlebot_rviz_launchers view_navigation.launch

I'm then choosing the 2D nav_goal in rviz and moving my robot around the map. The robot will move generally well, but when it gets stuck in tight places, I keep getting this error message:

Extrapolation Error looking up robot pose: Lookup would require extrapolation into the past.  Requested time 1486427903.748853431 but the earliest data is at time 1486427905.883079467, when looking up transform from frame [base_footprint] to frame [map]

When this error message comes up, the command rosrun tf tf_echo /map /base_footprint implies that it cannot find the transformation, which is what the error message is showing

I've looked at some other ROS questions and answers regarding this error message like this. I took the recommendation and set the transform tolerance lower and also set the frequency for local and global cost map lower, all with the intent of trying not to overload the CPU.

One thing I noticed was in rviz I kept noticing was my /scan topic timing out, with the error message:

For frame [/camera_depth_frame]: No transform to fixed frame [map]. TF error: [Lookup would require extrapolation into the future. Requested time is xxxxx but the latest data is at time xxxx, when looking up transform from frame [camera_depth_frame] to frame [map]

Okay! Looks like a /tf problem on two fronts, then I ran rosrun tf tf_monitor and saw this: RESULTS: for all Frames

Frames:
Frame: base_footprint published by unknown_publisher Average Delay: -0.0257666 Max Delay: 0
Frame: base_link published by unknown_publisher Average Delay: -0.52515 Max Delay: 0
Frame: camera_depth_frame published by unknown_publisher Average Delay: -0.525171 Max Delay: 0
Frame: camera_depth_optical_frame published by unknown_publisher Average Delay: -0.525185 Max Delay: 0
Frame: camera_link published by unknown_publisher Average Delay: -0.525198 Max Delay: 0
Frame: camera_rgb_frame published by unknown_publisher Average Delay: -0.525206 Max Delay: 0
Frame: camera_rgb_optical_frame published by unknown_publisher Average Delay: -0.525241 Max Delay: 0
Frame: caster_back_link published by unknown_publisher Average Delay: -0.525249 Max Delay: 0
Frame: caster_front_link published by unknown_publisher Average Delay: -0.525257 Max Delay: 0
Frame: cliff_sensor_front_link published by unknown_publisher Average Delay: -0.525262 Max Delay: 0
Frame: cliff_sensor_left_link published by unknown_publisher Average Delay: -0.52528 Max Delay: 0
Frame: cliff_sensor_right_link published by unknown_publisher Average Delay: -0.525287 Max Delay: 0
Frame: gyro_link published by unknown_publisher Average Delay: -0.525295 Max Delay: 0
Frame: odom ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2017-02-07 04:58:13 -0500

gvdhoorn gravatar image

Viewing rviz on the HP Elitebook and running all the code locally on the TK1

Just a hunch: have you synchronised the clocks of the two PCs involved? If not, that is probably the cause of your problems.

See wiki/ROS/NetworkSetup - Timing issues, TF complaining about extrapolation into the future?.

edit flag offensive delete link more

Comments

On the host machine, 'ntpdate -q REMOTE_IP' shows 0 for statum, offest and delay.

On the remote machine, 'ntpdate -q HOST_IP' shows: stratum 10, offset 0.002018, delay 0.05362

Chrony installed on both machnies, wifi connected, I cannot tell if this delay is too long and causing the errors. Thanks!

j_salfity gravatar imagej_salfity ( 2017-02-17 16:42:24 -0500 )edit

@gvdhoorn any thoughts?

j_salfity gravatar imagej_salfity ( 2017-03-06 18:23:35 -0500 )edit

Not immediately. As I wrote: it was just a hunch. Half a second delay (in your tf_monitor output) is quite a lot, and I can imagine that your problems are due to that.

Just as a test: does anything change if you put your TK1 "in the future" (by changing the clock)?

gvdhoorn gravatar imagegvdhoorn ( 2017-03-07 02:11:54 -0500 )edit
1

Btw:

The robot will move generally well, but when it gets stuck in tight places,

this could point to a performance problem on the TK1: CPU utilisation will go up (dramatically) when there are a lot of (re)planning requests. That could lead to TFs being starved.

gvdhoorn gravatar imagegvdhoorn ( 2017-03-07 02:13:16 -0500 )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: 2017-02-06 19:28:49 -0500

Seen: 1,076 times

Last updated: Feb 07 '17