ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

global_planner fails to find a plan - It doesn't search certain regions on the map

asked 2016-11-11 13:51:18 -0500

zkytony gravatar image

updated 2016-11-15 16:10:17 -0500

RVIZ potential

Here is the situation in the above picture. The robot is between a sofa and a wall, and it is facing upwards. I am setting a goal in the bigger room (right part of the map), and global_planner fails to produce a path. The visualization of global_planner's potential shows that it didn't even search in the big room.

What led to this behavior, i.e. graph search doesn't cover the region involving the goal? How do we correct it?

Some info: use_dijlstra is set to true (default).

Thanks!

EDIT: My parameters:

move_base

# Choose planners                                            
base_local_planner: "dwa_local_planner/DWAPlannerROS"        
base_global_planner: "global_planner/GlobalPlanner"          

# Using default recovery behaviors                           

# Timeouts and frequencies                                   
controller_frequency: 10.0                                   
controller_patience: 15.0                                    

planner_frequency: 2.0 #global plan | 0.25 #2.0              
planner_patience: 5.0                                        

oscillation_timeout: 10.0                                    
oscillation_distance: 0.2                                    

# Other params                                               
shutdown_costmaps: false                                     

# global_planner params                                      
GlobalPlanner:                                               
  default_tolerance: 0.2                                     
  cost_factor: 0.5489                                        
  neutral_cost: 66                                           
  lethal_cost: 253

costmap

global_frame: /map
robot_base_frame: /base_footprint
map_type: voxel

# Robot definition
# Even wider
# footprint: [[-0.495, 0.145], [-0.105, 0.366], [0.154, 0.374], [0.357, 0.154], [0.357, -0.154], [0.154, -0.374], [-0.105, -0.366], [-0.495, -0.145]]
# Wider
# footprint: [[-0.483, 0.121], [-0.092, 0.343], [0.132, 0.343], [0.349, 0.136], [0.349, -0.136], [0.132, -0.343], [-0.090, -0.343], [-0.483, -0.121]]
# Narrower
footprint: [[-0.42951, -0.10764], [-0.08274, -0.30298], [0.11447, -0.30298], [0.30577, -0.12000], [0.30577, 0.12000], [0.11447, 0.30298], [-0.08407, 0.30298], [-0.42951, 0.10764]]

map_layer:
  map_topic: /map


nogo_layer:
  map_topic: /map_nogo


inflation_layer:
  inflation_radius: 1.75
  cost_scaling_factor: 2.58


obstacle_layer:
  max_obstacle_height: 2.0
  obstacle_range: 2.5
  raytrace_range: 3.0

  origin_z: -0.2
  z_resolution: 0.15
  z_voxels: 12
  unknown_threshold: 8
  mark_threshold: 0

  publish_voxel_map: true

  observation_sources: laser xtion_obstacles xtion_clear xtion_back_obstacles xtion_back_clear

  laser:           {topic: /scan, data_type: LaserScan, sensor_frame: laser_link, marking: true, clearing: true, min_obstacle_height: 0.25, max_obstacle_height: 0.35}
  xtion_obstacles: {topic: /xtion_qqvga/depth/points_clipped, data_type: PointCloud2, marking: true, clearing: false, min_obstacle_height: 0.1, max_obstacle_height: 0.9, observation_persistence: 0.0, obstacle_range: 2.0}
  xtion_clear:     {topic: /xtion_qqvga/depth/points_max, data_type: PointCloud2, marking: false, clearing: true, min_obstacle_height: -0.1, max_obstacle_height: 1.1, observation_persistence: 0.0, raytrace_range: 5.0}
  xtion_back_obstacles: {topic: /xtion_back_qqvga/depth/points_clipped, data_type: PointCloud2, marking: true, clearing: false, min_obstacle_height: 0.1, max_obstacle_height: 0.9, observation_persistence: 0.0, obstacle_range: 2.0}
  xtion_back_clear: {topic: /xtion_back_qqvga/depth/points_max, data_type: PointCloud2, marking: false, clearing: true, min_obstacle_height: -0.1, max_obstacle_height: 1.1, observation_persistence: 0.0, raytrace_range: 5.0}

local_costmap:
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 4.0
  height: 4.0
  resolution: 0.02
  plugins:  
    - {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
    - {name: inflation_layer, type: "costmap_2d::InflationLayer"}

global_costmap:
  update_frequency: 5.0
  static_map: true
  rolling_window: false
  plugins:  
    - {name: map_layer, type: "costmap_2d::StaticLayer"}
    - {name: nogo_layer, type: "costmap_2d::StaticLayer"}
    - {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
    - {name: inflation_layer, type: "costmap_2d::InflationLayer"}
edit retag flag offensive close merge delete

Comments

Have you experimented with the global_planner's allow_unknown and the costmap's (obstacle layer) track_unknown_space parameters?

spmaniato gravatar image spmaniato  ( 2016-11-15 17:43:10 -0500 )edit

I haven't. It may reduce search space if I set allow_unknown to be false. Theoretically they shouldn't affect whether a path could be found right? I did some experiment with cost_factor, neutral_cost and they seem to have an effect on whether a path could be found. But still, not consistent

zkytony gravatar image zkytony  ( 2016-11-15 18:04:00 -0500 )edit

Is the door to the big room wider than "2x circumscribed radius" ? (see http://wiki.ros.org/costmap_2d/hydro/... ) Related to this, have you tried reducing inflation_radius ? 1.75 looks very high to me. However, none of these would explain the funky shape of the potential around the door.

spmaniato gravatar image spmaniato  ( 2016-11-15 20:16:46 -0500 )edit
1

Hi spmaniato. The reason I set inflation radius to a quite high value is because I want the cost decay curve to be smoother. That way when the robot plans a path in a corridor, the path should be along the middle of the corridor.

zkytony gravatar image zkytony  ( 2016-11-17 18:24:49 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2017-02-05 01:04:39 -0500

asimay_y gravatar image

I don't know how you did this. but apparently, the parameter cost_factor and neutral_cost are not loaded in source code. they are invalid, except you changed the source code. Obviously, you should check the environment and your parameters settings, especially the inflation_radius. maybe too large to caculate the path.

edit flag offensive delete link more

Question Tools

4 followers

Stats

Asked: 2016-11-11 13:51:18 -0500

Seen: 1,687 times

Last updated: Feb 05 '17