nav2_collision_monitor for rough terrain

[xaru8145]

Is there any way to deal with rough terrains and steep slopes in the nav2_collision_monitor package?

We are using a 3d lidar as a source for collision detection and we want to use as much height range as possible to avoid missing any obstacle. But if we use a pointcloud min_height, let's say of 0.1, it is very likely that due to the terrain we detect a collision with the ground. What is the recommended way to deal with this?

1. Calculate the ground plane, publish a tf from base_frame to ground and set param base_frame_id: ground_frame?
2. Pre-process the lidar data and remove the ground points?
3. Any other option?

Thanks in advance!

[SteveMacenski]

Interestingly I had a conversation just this week on a call about this very topic :smile:

The collision monitor package currently takes in PC2, LaserScan, Range, and now Polygons - but we're not restricted to these inputs if there are others of interest. Cost maps or height terrain maps have been proposed as possible good additions for this reason. However, that may not be necessary (but open to it).

If you have some terrain solution that you're using for navigation, you can take that, process it for "no go"s (i.e. high slope, voids, etc) that you'd want for navigation anyway and then feed those points into the collision monitor as a PointCloud. The PointCloud data doesn't have to be raw sensor data at all :smile:

So your steps seems reasonable for a first-order starting point, but more generally:

1. Compute some terrain map (or just fit a ground plane in the most simple cases)
2. Compute slope/gradient/roughness/etc to identify areas that are not navigable or problematic (or just above/below the ground plane for very simple cases)
3. The grid tiles, mesh points, etc that represent the terrain that violate the navigability constraints get populated into a pointcloud and published for the collision monitor package to utilize

Exposing the cost map or terrain map message type within the collision monitor package would be slightly more ergonomic, but really the only difference boils down to populating a PC2 vs that message, since either way you'd have to do steps 1/2.

[SteveMacenski]

Any follow up or is this good to close?

[SteveMacenski]

Closing due to lack of response and answered: send over a PC2 of the segmented or detected non-ground for use.