Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nav2_collision_monitor for rough terrain #4325

Open
xaru8145 opened this issue May 10, 2024 · 2 comments
Open

nav2_collision_monitor for rough terrain #4325

xaru8145 opened this issue May 10, 2024 · 2 comments
Labels
question Further information is requested

Comments

@xaru8145
Copy link

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
Copy link
Member

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

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 😄

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 SteveMacenski added the question Further information is requested label May 10, 2024
@SteveMacenski
Copy link
Member

Any follow up or is this good to close?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants