search

SteveMacenski / slam_toolbox

Slam Toolbox for lifelong mapping and localization in potentially massive maps with ROS
GNU Lesser General Public License v2.1
1.68k stars 525 forks source link

Response to LIDAR return inf #625

Closed Steve-Li-1998 closed 1 year ago

Steve-Li-1998 commented 1 year ago

Feature description

Is it possible to add one or more parameters so that when the lidar returns inf, the relevant grid can be recognized as known?

Implementation considerations

One problem I've encountered is that when the area around the robot is so empty that there are no obstacles within the LiDAR's field of view, the mapping of the slam_toolbox will stop.

I understand that there are many possibilities for laser beams not returning, but would it be possible to set the maxUrange and maxRange parameters like gmapping or something similar, which could make the grids that these laser beams pass through to be set to a known area if necessary?

SteveMacenski commented 1 year ago

No, that would not be a good idea

Steve-Li-1998 commented 1 year ago

So is there a way to make the unreturned laser beam (aka inf in the message) mark the passing grid as known? For example, the following is a bad situation.

slam
SteveMacenski commented 1 year ago

Even if there was a way, which I don't think there is, it would not be wise to do so. Lack of returns != obstacles that you can raytrace into free space to imply anything about the environment from. That is not an appropriate method for mapping. If your laser scanner isn't long enough range to hit the walls, either you need to (1) use a better laser scanner (2) augment it with some other sensor modality like vision and/or (3) make sure your robot has excellent odometry so you can appropriately dead-reckon between zones of sensor feedback. This is no different from just pure localization - you'll run into the same problems so just faking it out for SLAM is an extremely poor choice.

Steve-Li-1998 commented 1 year ago

I don't think it's fake out, I think there's something positive to be said for that. I work on automated frontier-based robotic exploration, which greatly enhances the efficiency of robotic exploration, as well as avoids getting stuck in one position due to the small range of LIDAR detection. Currently, all the frontiers are spread out along the red line, but I'd prefer them to be spread out along the green line, because then each step would be longer and exploration would be more efficient! So I'd be very happy if there was an option to do so slam_1

Steve-Li-1998 commented 1 year ago

Especially when the wall is convex, this will cause a great difficulty, because the calculation of the frontier requires the use of /map, and nav2 cannot navigate the robot to unknown areas. So to some degree, it is useful to "pretend that those areas are free", and you can set the relevant parameter to be turned off by default.

AndyZe commented 10 months ago

Commenting that I also think this would be a nice feature.

If the lidar beam does not return from an obstacle within its range, then I think we could assume that space is free.

There might be some weird edge cases like glass, which lidar passes through. However, I think that would be a problem with the current approach, too.

SteveMacenski commented 10 months ago

@AndyZe Id be OK with that as a contribution if set as a parameterized option default to false

AndyZe commented 10 months ago

Maybe i'll get a chance to do that sometime. It would make mapping a lot faster for large, mostly-empty spaces like parking lots.

SteveMacenski commented 10 months ago

The problem is that your positioning is going to be degraded. If you can't see anything, you have no features to match, and thus its like navigating in a convention center by dim candlelight. Its not a silver bullet to do that, even if conceptually it seems like it would solve some problems. That assumes perfect positioning knowing that you have no information to help with positioning.

I imagine after you hit a wall and maybe things corrected, some of that free space would be corrected through a wall and overall reducing the quality of your overall map. There are several reasons why gmapping wasn't really great (this is one of the lessor ones, but one indeed_

If you find yourself in that situation, you probably need longer range sensors or another localization modality like vision

AndyZe commented 10 months ago

yeah, i get that and i've seen it first-hand.

The "issue" here (it's not a major issue) is that clearly-empty regions do not show up as empty until the lidar is able to bounce off some obstacle behind them. Here's an image. Note that the rays which strike the building on the right of the robot are quickly marked empty. The rays on the left of the robot are not marked at all, even though they're clearly empty.

lidar_empty_map

SteveMacenski commented 10 months ago

That seems like a sensor range issue IMO. If you're working in large outdoor spaces, you probably need to not be relying on a 5m range lidar for localization purposes :-)

For collision and planning purposes, that's totally fine, the costmaps handle free/occupied space on their own with sensor data where infs are inputted as marking up as clear space. Going into more detail about that probably justifies a call just to keep the keyboard tapping and walls of text to a minimum

AndyZe commented 10 months ago

Gotcha, thanks. The LIDAR range is set to 100m, there just are not many features in that direction. Anyway, I think we're talking about 2 different issues now.

Hao-Li-Bachelorarbeit commented 9 months ago

@AndyZe Id be OK with that as a contribution if set as a parameterized option default to false

I think this is a good idea. I am engaged in robot autonomous exploration. If this feature can be realized, it will improve the efficiency of exploration.