[ros-users] costmap_2d questions

[Jack O'Quin]

On Tue, Sep 21, 2010 at 1:33 PM, Eitan Marder-Eppstein
<eitan at willowgarage.com> wrote:
> On Mon, Sep 20, 2010 at 6:36 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
>> On Mon, Sep 20, 2010 at 1:13 PM, Eitan Marder-Eppstein
>> <eitan at willowgarage.com> 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