always_send_full_costmap cause aborting of move_base [closed]
Hi,
I'm working with TIAGo from PAL. I have personalized the configuration of the move_base to launch a "map_less" navigation (as suggested here). I have also set always_send_full_costmap: true
because I need to read the costmap. In noticed that, when always_send_full_costmap
is set to true, the move_base abort the task without attempting any motion, just after received the first goal.
What is the problem?
I attach also my configuration file:
Global costmap:
# Independent settings for the planner's costmap
global_costmap:
map_type: costmap
global_frame : odom
robot_base_frame: base_footprint
update_frequency : 10.0
publish_frequency: 10.0
transform_tolerance: 0.2
track_unknown_space: true
rolling_window: true
unknown_cost_value : 255
always_send_full_costmap: true #to avoid the use of updates
robot_radius: 0.35
#plugins are loaded on a separate file
obstacle_laser_layer:
enabled: true
observation_sources: base_scan
combination_method: 0 # can erase static layer
base_scan:
sensor_frame: base_laser_link
data_type: LaserScan
topic: scan
expected_update_rate: 0.3
observation_persistence: 1.0
inf_is_valid: true
marking: true
clearing: true
raytrace_range: 4.0
obstacle_range: 3.0
inflation_layer:
enabled : true
inflation_radius : 0.1
cost_scaling_factor: 25.0
Local Costmap
# Independent settings for the local costmap
local_costmap:
map_type: costmap
global_frame : base_footprint #odom
robot_base_frame: base_footprint
update_frequency : 10.0 #5.0
publish_frequency: 10.0 #1.0
static_map : false
track_unknown_space: true
rolling_window: true
width : 7.0 #4.0
height : 7.0 #4.0
resolution : 0.1 #0.025
always_send_full_costmap: true #to avoid the use of updates
robot_radius: 0.35
#plugins are loaded on a separate file
obstacle_laser_layer:
enabled: true
observation_sources: base_scan
combination_method: 0 # can erase static layer
base_scan:
sensor_frame: base_laser_link
data_type: LaserScan
topic: scan
expected_update_rate: 0.3
observation_persistence: 1.0
inf_is_valid: true
marking: true
clearing: true
raytrace_range: 4.0
obstacle_range: 3.0
obstacle_sonar_layer:
enabled: false
ns: ""
topics: ["/sonar_base"]
no_readings_timeout: 0.0
clear_threshold: 0.20
mark_threshold: 0.80
clear_on_max_reading: true
obstacle_rgbd_layer:
enabled: true
observation_sources: rgbd_scan
combination_method: 1
rgbd_scan:
sensor_frame: base_footprint
data_type: LaserScan
topic: rgbd_scan
expected_update_rate: 0.5
observation_persistence: 0.0
inf_is_valid: true
marking: true
clearing: true
raytrace_range: 3.5
obstacle_range: 3.2
blanking_range: 0.5
min_obstacle_height: -0.1
max_obstacle_height: 0.2
debug: true
inflation_layer:
enabled : true
inflation_radius : 0.2 #0.7
cost_scaling_factor: 50.0 #5.0
move_base
planner_frequency: 2.0
planner_patience : 0.1
controller_frequency: 10.0
controller_patience : 3.0
oscillation_timeout : 10.0
oscillation_distance: 0.2
recovery_behavior_enabled: false
shutdown_costmaps : false
search_alternative_goals: true
alternative_goals_thresh: 0.5
latch_xy_goal_tolerance: true
What is the error that you're getting from move_base? That is, the output you get in the console where you roslaunch the move_base.launch.
Yes, without the console output and proper error message, it's hard to suggest.
Well guys, you are right. But today I'm not able to reproduce the error. The system is working right now, with the same setting of yesterday. I really don't undestand this robot...
I keep the answer opened if the problem will appears in the near future.
It's better to leave it closed and reopen it, when you face the issue.
Ok, thank you guys! I will re-open in case of issues.