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:
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_costmap: 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
local_costmap: 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
TrajectoryPlannerROS: #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!
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.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.
For the local costmap, the most common parametrization is
global_frame: odom
androbot_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...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.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.)In addition, I just noticed that the launch file you linked to is not for
amcl
but formove_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 wordvalue
is misspelled, so ...)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.
Interesting. According to your tf tree, AMCL is not doing anything. (It should be broadcasting the
map
toodom
transform.) Actually, there is noodom
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.