always_send_full_costmap cause aborting of move_base
Hi,
I'm working with TIAGo from PAL. I have personalized the configuration of the movebase to launch a "mapless" 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
Asked by bach on 2021-07-29 13:42:51 UTC
Comments
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.
Asked by schizzz8 on 2021-07-30 01:09:15 UTC
Yes, without the console output and proper error message, it's hard to suggest.
Asked by saikishor on 2021-07-30 02:07:55 UTC
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.
Asked by bach on 2021-07-30 04:32:20 UTC
It's better to leave it closed and reopen it, when you face the issue.
Asked by saikishor on 2021-07-30 04:57:40 UTC
Ok, thank you guys! I will re-open in case of issues.
Asked by bach on 2021-07-30 05:35:53 UTC