Ask Your Question
1

obstacle_layer updates areas out of sight

asked 2014-05-16 05:30:30 -0600

Luke_ROS gravatar image

updated 2014-05-20 03:24:39 -0600

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!


UPDATE

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.

edit retag flag offensive close merge delete

Comments

Are you using the packaged debian for Nav, or did you compile it yourself?

David Lu gravatar imageDavid Lu ( 2014-05-20 06:15:11 -0600 )edit

Also, is the robot's right our right? It looks the costmap should be updated on our right.

David Lu gravatar imageDavid Lu ( 2014-05-20 06:18:34 -0600 )edit

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.

Luke_ROS gravatar imageLuke_ROS ( 2014-05-20 21:21:11 -0600 )edit

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?

David Lu gravatar imageDavid Lu ( 2014-05-21 06:58:06 -0600 )edit

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...

Luke_ROS gravatar imageLuke_ROS ( 2014-05-21 22:14:35 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2014-06-26 08:19:34 -0600

Luke_ROS gravatar image

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;
    }
edit flag offensive delete link more
0

answered 2014-05-19 18:35:33 -0600

David Lu gravatar image

updated 2014-05-22 14:26:28 -0600

1) Try changing the combination method parameter in dynamic reconfigure.

2) What is the value of obstacle_range and clearing_range?

EDIT: The whole area is being updated because of the laser readings that are in the top right of the picture. Since the costmap only updates grid-aligned rectangles, you can't avoid updating that area too easily.

edit flag offensive delete link more

Comments

1) The value does not appear in `rqt_reconfigure`. I expected it to be in the `obstacle_layer` but it wasn't there. What am I missing here? 2) `obstacle_range` and `clearing_range` both work fine. Since I got more karma today I will post a screen shot to my question for clarifying my issue.

Luke_ROS gravatar imageLuke_ROS ( 2014-05-20 03:11:38 -0600 )edit

I see... And from the code it pretty much seems like I am bounded to that rectangular shape, right? Do you see a work around for what I would like to achieve?

Luke_ROS gravatar imageLuke_ROS ( 2014-05-26 04:49:45 -0600 )edit

That is correct. I don't see a workaround. Is this causing performance issues for you?

David Lu gravatar imageDavid Lu ( 2014-05-27 09:21:59 -0600 )edit
1

http://37.media.tumblr.com/d982259ecf49a74f1868951246bb866f/tumblr_mp77g8ihoz1qd5wumo2_250.gif

David Lu gravatar imageDavid Lu ( 2014-05-27 09:22:59 -0600 )edit

Gotta love Tony Stark :) Not really a performance issue. I rely on actual measurements for an algorithm I am working on. I have a workaround in mind with intercepting the pixels which update the master grid of the obstacle_layer based on incoming measurements and publish them separately.

Luke_ROS gravatar imageLuke_ROS ( 2014-05-28 22:49:35 -0600 )edit

Okay. Please let me know if you have more questions.

David Lu gravatar imageDavid Lu ( 2014-05-29 07:17:37 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2014-05-16 05:30:30 -0600

Seen: 950 times

Last updated: Jun 26 '14