min_obstacle_height seems ignored in costmap_2d with laserscan pointcloud

asked 2017-03-17 13:45:05 -0600

Pi Robot gravatar image

updated 2017-03-17 13:47:11 -0600


This problem is occurring in the latest ROS Indigo Debian install under Ubuntu 14.04.

I've been struggling with this for days both in Gazebo and with our real robot. We have a rotating lidar on the head of our robot that should be well suited for detecting objects on the ground that our fixed planar lidar might miss (because it is mounted about 0.2 m above the ground.)

So I have used a scan_to_cloud_filter_chain to filter the rotating lidar and turn it into a pointcloud. The filter chain limits the range of the laser and filters out the robot body (self filter). The result looks good in RViz as you can see in the image below. This is done in Gazebo and there is a coke can sitting in front of the robot. The red points are the pointcloud from the rotating head lidar and I placed a 20 second decay time in RViz so we can see it. Notice how the coke can is easily detected. The blue and yellow region on the ground is the local cost map since I am running the Navigation stack as well.

The problem is that the points on the ground surrounding the coke can should not be showing up in the cost map as blue and yellow because I have set the min_obstacle_height for the lidar pointcloud to be 0.1m. In fact, it does not seem to matter what I set the min_obstacle_height to be, the floor is always marked as an obstacle. (My max_obstacle_height parameter is set to 1.5m so it is not the ceiling that is being projected down to the floor.)

I have included my costmap_common_params.yaml file as well as my filter launch file below the image.

image description

Here is my laser filter launch file:


    <!-- Filter for rotating laser-->
    <node pkg="laser_filters" type="scan_to_cloud_filter_chain" respawn="true" name="lidar_scan_cloud_filter" output="screen">
        <remap from="scan" to="/sibot/rotating_lidar/scan" />
        <remap from="cloud_filtered" to="/sibot/rotating_lidar/cloud_filtered" />
        <param name="target_frame" value="/sibot/left_camera_optical_frame" />
        <param name="high_fidelity" value="true" />
        <rosparam command="load" file="$(find jr1_laser_filters)/config/rotating_scan_filter.yaml" />
        <rosparam command="load" file="$(find jr1_laser_filters)/config/point_cloud_footprint_filter.yaml" />

    <node pkg="laser_filters" type="scan_to_scan_filter_chain" name="base_laser_filter" output="screen">
        <remap from="scan" to="/sibot/base_scan" />
        <remap from="scan_filtered" to="/sibot/base_scan_filtered" />
        <param name="target_frame" value="/sibot/base_link" />
        <param name="high_fidelity" value="true" />
        <rosparam command="load" file="$(find jr1_laser_filters)/config/base_scan_filter.yaml" />


And here is my costmap_common_params.yaml file:

footprint: [[0.4, 0.3], [0.4, -0.3], [-0.4, -0.3], [-0.4, 0.3]]

# This key parameters greatly determines how much clearance the robot will give to obstacles.
# Set individually in local and global costmaps
footprint_padding: 0.0001

robot_base_frame: sibot/base_link

update_frequency: 5.0
transform_tolerance: 1.0

publish_frequency: 1.0
plugins: []

map_type: voxel

  enabled:                  true
  unknown_cost_value:        -1
  lethal_cost_threshold:     100
  map_topic:                 map
  subscribe_to_updates:      true

   enabled:              true

   observation_sources: base_scan rotating_head_scan_cloud 

      data_type:                LaserScan
      topic:                    /sibot/base_scan_filtered
      marking:                  true
      clearing:                 true
      observation_persistence:  0.0
      expected_update_rate:     0 ...
edit retag flag offensive close merge delete


Hi, have you found any solution for this? I am facing the same problem that the floor is always marked as an obstacle.

notinuse gravatar image notinuse  ( 2017-10-25 22:31:51 -0600 )edit

same problem here

Seb.Abhishek gravatar image Seb.Abhishek  ( 2018-06-14 04:59:24 -0600 )edit