Extrapolation error when sending goals to the robot via navigation stack

asked 2016-07-09 17:12:25 -0500

updated 2016-07-10 14:30:22 -0500

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:

  • Costmap_common_params.yaml

    obstacle_range: 0.1
    raytrace_range: 0.1
    #footprint: [[-115.375, -15.144], [-199.803, 93.368], [-7.863, 115.870], [58.644, -37.710]]
    robot_radius: 0.4699  #meters
    inflation_radius: 0.2048 #1 feet
    observation_sources: laser_scan_sensor point_cloud_sensor
    laser_scan_sensor: {sensor_frame: laser_frame, data_type: LaserScan, topic: /rosarnl_node/lms5XX_1_laserscan, marking: true, clearing: true}
     point_cloud_sensor: {sensor_frame: odom, data_type: PointCloud, topic: /rosarnl_node/lms5XX_1_pointcloud, marking: true, clearing: true}
  • global_costmap_params.yaml

     global_frame: map
     robot_base_frame: base_link
    update_frequency: 1.0
    publish_frequency: 5.0
    static_map: true
    sensor_frame: laser_frame
    width: 160.3
    height: 160.773
    origin_x: -77.702
    origin_y: -56.819
  • local_costmap_params.yaml

           global_frame: base_link #map 
           robot_base_frame: laser_frame
           update_frequency: 1.0
           publish_frequency: 5.0
           static_map: false
           rolling_window: true # must be set to false to use static map
           resolution: 0.5
           transform_tolerance: 0.5 #tolerable delay in seconds
           width: 160.3
           height: 160.773
           origin_x: -70.702
           origin_y: -66.819
  • base_local_planner_params.yaml

        #Robot Configuration Parameters
        max_vel_x: 1.2
       min_vel_x: 0.2
       max_vel_theta: 1.0
       min_in_place_vel_theta: 0.4
       acc_lim_theta: 1.2
       acc_lim_x: 1.5
       acc_lim_y: 1.5
       #Trajectory scoring parameters: http://wiki.ros.org/base_local_planner#Map_Grid
       escape_vel: -0.3 #speed for escaping when stuck
       meter_scoring: true
        sim_time: 0.5
        dwa: true #use dynamic window approach
        publish_cost_grid: true
        global_frame_id: base_link #Should be set to the same frame as the local costmap's global frame
        holonomic_robot: true

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!

edit retag flag offensive close merge delete


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.

spmaniato gravatar imagespmaniato ( 2016-07-09 20:59:41 -0500 )edit

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.

lakehanne gravatar imagelakehanne ( 2016-07-09 21:52:33 -0500 )edit

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/22713...

spmaniato gravatar imagespmaniato ( 2016-07-09 22:21:38 -0500 )edit

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.

lakehanne gravatar imagelakehanne ( 2016-07-10 13:19:59 -0500 )edit

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.)

spmaniato gravatar imagespmaniato ( 2016-07-10 13:41:27 -0500 )edit

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 ...)

spmaniato gravatar imagespmaniato ( 2016-07-10 13:42:36 -0500 )edit

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.

lakehanne gravatar imagelakehanne ( 2016-07-10 14:28:26 -0500 )edit

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.

spmaniato gravatar imagespmaniato ( 2016-07-10 15:55:11 -0500 )edit