Robotics StackExchange | Archived questions

Extrapolation error when sending goals to the robot via navigation stack

Hi there,

I am using the P3DX robot to navigate an indoor environment using the SICK 500 LIDAR. I have brought up the robot using rosarnl.

I have defined my yaml parameters as follows:

For some reason, when I send goals via the actionlib simple action client to move_base/goal, I get the following errors:

``` ERROR] [1468101998.962293754]: Global Frame: base_link Plan Frame size 205: map

      [ WARN] [1468101998.962348736]: Could not transform the global plan to the frame of the controller
      [ERROR] [1468101999.060938901]: Extrapolation Error: Lookup would require extrapolation into the future.   Requested time 1468102000.826297045 but the latest data is at time 1468102000.823431077, when looking up transform  from frame [base_link] to frame [map]

     [ERROR] [1468101999.061004147]: Global Frame: base_link Plan Frame size 205: map

     [ WARN] [1468101999.061030274]: Could not transform the global plan to the frame of the controller

``` EDIT 1: v0.1 tag contains the correct code The amcl launch script is here if it helps.

Thanks guys!

Asked by lakehanne on 2016-07-09 17:12:25 UTC

Comments

Not sure if related, but these looks suspicious to me: global_frame: base_link, robot_base_frame: laser_frame (local costmap) Your costmaps' update_frequency is also quite low.

Asked by spmaniato on 2016-07-09 20:59:41 UTC

I reduced the update freqs because I was having a lookup transform error in the tf bringup.Reducing the rates of updating the maps seemed to eliminate that error. As for the base_link to laser_frame, those are the parent and child frame_ids of rosarnl.

Asked by lakehanne on 2016-07-09 21:52:33 UTC

For the local costmap, the most common parametrization is global_frame: odom and robot_base_frame: base_link This is probably not related your tf issue, but it did catch my eye. Take a look at this answer: http://answers.ros.org/question/227137/?answer=227142#post-id-227142

Asked by spmaniato on 2016-07-09 22:21:38 UTC

When I change the local_cost_params to your suggests, it spills: Timed out waiting for transform from base_link to odom> I have ran ntpdate on both machines, described here.

Asked by lakehanne on 2016-07-10 13:19:59 UTC

Interesting. Could you please upload your tf tree? (You can get that by running rosrun tf view_frames when everything is launched. Then please upload the pdf/image that this command will generate.)

Asked by spmaniato on 2016-07-10 13:41:27 UTC

In addition, I just noticed that the launch file you linked to is not for amcl but for move_base. Moreover, one of the last line reads: <param name="use_sim_time" vaue="true" /> which is incorrect if you're running this on a real robot. (Although the word value is misspelled, so ...)

Asked by spmaniato on 2016-07-10 13:42:36 UTC

I made a comment on the original post showing the correct omni.launch file. I do not have enough pts to upload a file but here is a link to the tf you asked.

Asked by lakehanne on 2016-07-10 14:28:26 UTC

Interesting. According to your tf tree, AMCL is not doing anything. (It should be broadcasting the map to odom transform.) Actually, there is no odom frame at all, which explains the errors when you used that as a frame for the local costmap. I'm out of ideas, sorry. Not sure how ARNL works.

Asked by spmaniato on 2016-07-10 15:55:11 UTC

Answers