Rosanswers logo

This question is partly related to an earlier post of mine but is worth its own question. So I am getting the problem, that obviously occluded areas are getting updated through the obstacle_layer-plugin of the costmap_2d package. Since I do not have enough of these precious karma points I cannot post any screen shots but I can try to explain the situation in words.

To my understanding, the ObstacleLayer::updateBounds function in the mentioned plugin handles the area to be updated. This area is designed to be rectangular. In my case the laser scan reaches a bit behind the robot but far from an all around view (screen shot would help here). So the extreme points of the laser scan extend this update rectangle so far that the obstacle_layer updates areas behind the robot which he has never observed. It updates this area with the values of the prerecorded map but since the situation could have changed since then this behavior is not desirable.

Another strange behavior of this ObstacleLayer::updateBounds function is that it does not updates as far as the most far away laser scan recorded. It stops somewhere halfway and does update occluded regions but not the region I expect it to update.

Is there a way of cropping the ObstacleLayer::updateBounds to a meaningful frame without messing with the source code of the obstacle_layer? Or am I totally misunderstanding the concept of the obstacle_layer? Any help is appreciated. Thanks!


Now I can provide a screen shot. The rectangular represents the area, which the obstacle_layer updates the layered_costmap_ (aka. master costmap) with. The occluded room to the robot's right should clearly not be updated with either LETHAL_OBSTACLE nor FREE_SPACE since we simply do not know.

image description

If relevant: I use Hydro on an Ubuntu 12.04 LTS.

Originally posted by Luke_ROS on ROS Answers with karma: 116 on 2014-05-16

Post score: 1

Original comments

Comment by David Lu on 2014-05-20:
Are you using the packaged debian for Nav, or did you compile it yourself?

Comment by David Lu on 2014-05-20:
Also, is the robot's right our right? It looks the costmap should be updated on our right.

Comment by Luke_ROS on 2014-05-20:
Yes, packaged debian for Nav. And the robot's right is also our right. But I would like to avoid updating the occluded region behind the wall to the robot's right.

Comment by David Lu on 2014-05-21:
Is your problem that the occluded region shouldn't be updated at all, or that it should have a different value than is shown in your costmap?

Comment by Luke_ROS on 2014-05-21:
It should not be updated at all. To my understanding the obstacle_layer updates the layered_costmap_ in this region with either previously received data or, if never seen before, with values from the initialized map from the static_layer. Neither behavior is desirable in my eyes...


1 Answer 1


Rosanswers logo

I found a workaround. I created a new smart_obstacle_layer (more or less 1:1 copy of the obstacle_layer) which clears its map before each update step. The following lines of code did the main work:

    for( int i=0; i<size_x_*size_y_; i++) {
        costmap_[i] = NO_INFORMATION;

Originally posted by Luke_ROS with karma: 116 on 2014-06-26

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.