Costmap prohibition layer doesn't show on local costmap

asked 2021-07-01 08:49:52 -0600

valness gravatar image

I am using this package to declare restricted areas as a costmap plugin for the robot in turtlebot3 home simulation environment, tested both in ros noetic and melodic: https://github.com/alex-arnal/costmap...

The areas can be observed on global map, the global planner recognizes them and draws the path outside of these areas. However in local map there are no prohibited areas and the DWA local planner draws without considering these. Yet the plugin is recorded as rosparam. Typing rosparam get /move_base/local_costmap/plugins results as follow:

- name: static_layer
  type: costmap_2d::StaticLayer
- name: obstacles_layer
  type: costmap_2d::ObstacleLayer
- name: prohibited_layer
  type: costmap_prohibition_layer_namespace::CostmapProhibitionLayer
- name: inflater_layer
  type: costmap_2d::InflationLayer

My costmap params files and the images with the situation is provided below. Is there something wrong with my configs?

global costmap: https://imgur.com/a/NEa4NE0

local costmap: https://imgur.com/a/pskrhL5

both costmaps: https://imgur.com/a/qAEVr1s

costmap_common_params.yaml

map_type: costmap
origin_z: 0.0
z_resolution: 1
z_voxels: 2

obstacle_range: 2.0
raytrace_range: 10.0

publish_voxel_map: false
transform_tolerance: 1.0
meter_scoring: true
always_send_full_costmap: true

footprint: [[-0.45,-0.30],[-0.45,0.30],[0.45,0.30],[0.45,-0.30]]
footprint_padding: 0.05

obstacles_layer:
  observation_sources: scan1 scan2
  scan1: {sensor_frame: base_link, data_type: LaserScan, topic: scan1, marking: true, inf_is_valid: true, clearing: true, min_obstacle_height: -2.0, max_obstacle_height: 2.0, obstacle_range: 5.0, raytrace_range: 5.5}
  scan2: {sensor_frame: base_link, data_type: LaserScan, topic: scan2, marking: true, inf_is_valid: true, clearing: true, min_obstacle_height: -2.0, max_obstacle_height: 2.0, obstacle_range: 5.0, raytrace_range: 5.5}

global_costmap_params.yaml

global_costmap:

   global_frame: map
   robot_base_frame: base_footprint
   update_frequency: 5.0
   publish_frequency: 5.0
   width: 40.0
   height: 40.0
   resolution: 0.1
   origin_x: -20.0
   origin_y: -20.0
   static_map: true
   rolling_window: false

   plugins:
   - {name: static_layer, type: "costmap_2d::StaticLayer"}
   - {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
   - {name: prohibited_layer, type: "costmap_prohibition_layer_namespace::CostmapProhibitionLayer"}
   - {name: inflater_layer, type: "costmap_2d::InflationLayer"}

   prohibited_layer:
      prohibition_areas:
         - []

   inflater_layer:
     inflation_radius: 1.0
     cost_scaling_factor: 10.0

local_costmap_params.yaml

local_costmap:
   global_frame: map
   robot_base_frame: base_footprint
   update_frequency: 4.0
   publish_frequency: 4.0
   width: 10.0
   height: 10.0 
   resolution: 0.1
   static_map: false
   rolling_window: true
   always_send_full_costmap: true

   plugins:
   - {name: static_layer, type: "costmap_2d::StaticLayer"}
   - {name: obstacles_layer, type: "costmap_2d::ObstacleLayer"}
   - {name: prohibited_layer, type: "costmap_prohibition_layer_namespace::CostmapProhibitionLayer"}
   - {name: inflater_layer, type: "costmap_2d::InflationLayer"}

   prohibited_layer:
      prohibition_areas:
         - []

   inflater_layer:
     inflation_radius: 0.8
     cost_scaling_factor: 2.0
edit retag flag offensive close merge delete

Comments

The wiki page claims you should be able to do this.

  1. Since you didn't show us, how are you creating the prohibited areas list? Have you verified the data actually present in both subtrees on the param server?
  2. Your indent in the .yaml file looks suspect - my prior experience is that each block level has to be indented exactly 2 spaces under its parent. (Yes, this is dumb. But it is what it is.)
Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-07-02 09:06:06 -0600 )edit

Regarding my comment about indent: I tried to re-create this bug on melodic using rosparam load, and was not able to do so. This must have been fixed at some point. Of course, this test assume roslaunch and rosparam behave identically.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2021-07-03 09:35:34 -0600 )edit