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

Costmap clearing of obstacles

asked 2012-03-19 18:04:26 -0500

weiin gravatar image

updated 2012-03-19 18:05:30 -0500

I am having the same issues as this:

Blue points are obstacles marked obstacles marked

Pink are the laser scans laser scans

I am using Hokuyo UHG-08LX. What I still do not understand is, why are the obstacles not seen by the laser still left behind? This is so even after a few minutes (with robot not moving).

If the laser could see the obstacles before, there should be scans which would pass through these points after the obstacle is removed. Raytracing should have been able to clear those paths. Or am I missing something?

edit retag flag offensive close merge delete

2 Answers

Sort by » oldest newest most voted

answered 2012-03-20 03:35:35 -0500

DimitriProsser gravatar image

If the laser scanner is seeing maximum range, it might not be able to clear your obstacles. Some laser scanners will fill a maximum range point with 0.0 instead of some value. No return means that the costmap cannot be cleared. In order to clear an obstacle, the costmap must receive a scan that raytraces through where the obstacle used to be and returns a value. This tells the costmap "since I have now received a scan point that is farther away than the previous one, there must no longer be an obstacle here". If you do not receive this farther point (because max range fills 0.0 or your raytrace_range parameter is too low), you cannot clear the map.

Based on your images, I'm guessing that the scenario I mentioned above is likely.

edit flag offensive delete link more


Yes, I was suspecting this as well when I echo the /scan topic and see quite a few 0.0 range readings. So the question is, what is the usual procedure to deal with out-of-range readings?

weiin gravatar image weiin  ( 2012-03-20 14:51:43 -0500 )edit

It seems odd that if a robot was sitting there doing nothing and something passes in front of it for a brief moment. The robot records it, and after a few minutes when the robot is asked to move off, it still assumes an obstacle is there.

weiin gravatar image weiin  ( 2012-03-20 14:53:55 -0500 )edit

I run the LaserScan through a custom filter (based on the laser_filters package) that replaces all values of 0.0 with max_range. Since the laser scanner hardware is actually incapable of measuring 0.0 (they have a minimum range), you can safely assume a 0.0 is a max range scan

DimitriProsser gravatar image DimitriProsser  ( 2012-03-21 04:46:42 -0500 )edit

Does anyone have a custom filter similar to the one Dimitri is talking about?

musiqsoulchild gravatar image musiqsoulchild  ( 2015-03-23 03:50:58 -0500 )edit

To customize the filter take the LaserScanRangeFilter from laser_filters and modify the header file (range_filter.h) so that instead of filtered_scan.ranges[i] = quiet_NaN(), make it filtered_scan.ranges[i] = max_value; where max_value is within your laser range max.

nbanyk gravatar image nbanyk  ( 2016-01-21 20:42:20 -0500 )edit

I have tried that solution, but still the laser scans with max range (or max_range + 1 as the current hydro-devel laser_filters apply) were not clearing the cells. This seems to be the desired behavior, as shown in the discussion below (see link in next comment)

Procópio gravatar image Procópio  ( 2016-02-02 10:01:50 -0500 )edit

Yes, in the end it was actually a value something slightly less than max that allowed for clearing.

nbanyk gravatar image nbanyk  ( 2016-02-02 11:55:07 -0500 )edit

answered 2017-04-21 03:57:39 -0500

mcarr gravatar image

I agree the issue is how the laser represents out of range values. I had success in setting the out of range values to slightly less than max_range by using a filter. I used the laser filters package and edited range_filter.h to replace with the value I wanted (4.9 was my replaced out of range value). Remember to catkin_make and source setup.bash after making these changes. Need to then add a remap from "scan" to "scan_filtered" in the launch file you're using.

The other important step is to check the raytrace_range parameter in costmap_common_params.yaml is greater than your replaced out of range value. As the previous answer mentioned, without this, your obstacles will not be cleared when detecting out of range.

Also check the the obstacle_range parameter, which is also in costmap_common_params.yaml is less than your raytrace_range parameter.

My config:

  • Laser: Neato XV_11 Lidar
  • Range: 0.06 to 5.0 m
  • Default out of range value: 0.05999 (this can be checked through rostopic echo /scan. Note - this value of 0.05999 will not clear obstacles behind it)
  • Parameters: replaced out of range value = 4.5, raytrace_range = 5.0, obstacle_range = 4.0.
edit flag offensive delete link more

Question Tools



Asked: 2012-03-19 18:04:26 -0500

Seen: 6,738 times

Last updated: Apr 21 '17