On Tue, Sep 21, 2010 at 1:33 PM, Eitan Marder-Eppstein wrote: > On Mon, Sep 20, 2010 at 6:36 PM, Jack O'Quin wrote: >> On Mon, Sep 20, 2010 at 1:13 PM, Eitan Marder-Eppstein >> wrote: >> > You're right in your recollection about max_range readings being treated >> > as >> > unknown. If you want the costmap to use this information differently, >> > you'll >> > have to write a laser filter that takes max_range values in your laser >> > scan >> > and assigns them slightly less than max_range values. When we've done >> > this, >> > we typically set up one observation_source that only puts marking >> > information into the costmap that uses the unfiltered scan and one >> > observation_source that clears obstacle information in the costmap and >> > uses >> > the filtered scan topic. In this way, we don't put max range hits in as >> > obstacles, but we do use them to clear obstacles out. >> >> That helps. I don't think I could have figured that out from the docs. >> It would help if there were an explicit statement that cells traversed >> by max range readings are unknown. >> >> What is the rationale for not treating max range reading as clearing >> intervening cells? Is it mostly a performance issue due to the ray >> tracing overhead? > > The rationale is that you can't actually tell the difference between an > error and max_range with a laser range finder. Points that come back as > max_range may, for example, have actually hit a black surface. So, treating > them as valid hits may actually be unsafe and cause you to clear obstacles > out that shouldn't. While that can happen, we have not found it to be a big problem with our devices (Velodyne HDL-64E point cloud for long ranges, Sick LMS200 for short ranges). When phantom scans occur, the occupancy map usually does a good job of filtering them out before they become a problem. We need to track relatively fast-moving moving vehicles. If we do not clear cells traversed by max range headings, cars will leave a long trail of false-positive "occupied" cells behind them. There often will not be another obstacle in range behind the moving car to clear out those cells. So, maybe we do need to filter the input as you suggest. That sounds like it might be a lot of extra overhead. Is there any possibility to add clearing of max_range readings as a Costmap2D option? I have not studied the implementation, but would be willing to attempt a patch if there is any interest in adding that feature. --  joq