[Nav2] Best way of including "emergency stop" range/cliff sensors in nav2

asked 2022-07-13 18:57:02 -0600

Pepis
130 ●6 ●13 ●15

Hi everyone!

I'm currently working with a robot that has what I call cliff sensors. Though their configuration is a bit different they serve the same purpose as the cliff sensors usually embedded in cleaning robots like roombas: they are pointing to the floor constantly measuring the distance from the robot to the surface and are able to detect "cliffs" - When that distance is longer than usual - and prevent the robot from falling down the stairs, curbside, etc.

How cliff sensors work

I have tried to input their data after some post processing to nav2's range sensor layer by simulating a range reading in the place the cliff is, like if a solid obstacle was placed there, however this has failed. The sensors I'm using are able to detect cliffs that are ~40cm ahead of the robot's front but my guess is that since the robot I'm using is relatively big/heavy (>20kg) and runs at up to 1.5m/s more "responsiveness" is needed. I have set the deceleration values on the controller to very high amounts with little impact. Could this tackled by changing the nav2 configuration alone?

I have tried using a node independent from nav2 to hard-stop the robot (set the linear speed to 0) when a cliff is detected and this works much better.

With that in mind, I wanted to ask the community, has someone tried to do this? What would be the best way of integrating this to nav2 on a big robot? I would like to mark these obstacles on the costmap to prevent the robot from planning through that area, however I need to trigger a more "emergency stop"-like behavior that forces the robot to completely stop.

edit retag flag offensive close merge delete

add a comment

1

answered 2022-07-14 04:38:43 -0600

Per Edwardsson

501 ●14 ●58 ●31

Fascinating problem. It looks like you have a few points which could be failing.

Are you sure that the cliff is detected at the correct distance?
If it is, is the costmap updated correctly?
If it is, is the local planner not acting properly?

If all of the above work, I believe that some type of safety monitor is being introduced to the nav2 stack (see discourse).

Until then, I think the in-system way to solve something like this is to have a behavior(previously recovery) which looks for proximity to cliffs, and design the behavior tree such that it runs the follow_path unless the proximity_detector returns true, at which point it stops (and engages breaks, or actively publishes 0 velocity, or whatever).

edit flag offensive delete link

Comments

Thanks! I think I will pursue the behavior approach, seems more appropriate for achieving the instantaneous reaction that I'm looking for while still allowing to mark the obstacle in the costmap. The safety monitor looks interesting but I would have to convert the measurements to a pointcloud, which seems somehow less "clean" and is not merged yet with the main stack anyway. I may post an update in case someone is interesting to see how this goes in the future

Pepis ( 2022-07-14 14:07:07 -0600 )edit

add a comment

1

answered 2022-07-14 14:32:19 -0600

stevemacenski

8272 ●34 ●503 ●129 https://www.linkedin.c...

You may want to check out the new collision monitor that is in review currently https://github.com/ros-planning/navig... (and docs https://github.com/ros-planning/navig...)

That may be what you're essentially looking for. Inserting into your costmap will help slow the robot, but if you're looking for emergency stopping, that's different. Handling that at the lower level is pretty typical.

We do not yet have support for Range though, only Scans and PointCloud2's. But, that would be pretty trivial to add if you were willing to contribute the feature.

edit flag offensive delete link

Comments

Thanks Steve! that looks really interesting. Sorry if i missed this in the documentation, but is there any way of running recovery behaviors upon an emergency stop by the collision monitor? I was thinking this could be desirable in the specific case of cliff sensors because cliffs wont usually change their position (like a dynamic obstacle would do) but I don't really want the robot to remain stuck on the position of the cliff. It would be more appropriate to mark the obstacle on the costmap to prevent the robot from planning again over that area and run a recovery to resume the navigation (like moving a short distance backwards, etc)

Pepis ( 2022-07-18 13:41:54 -0600 )edit

add a comment

[Nav2] Best way of including "emergency stop" range/cliff sensors in nav2

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

[Nav2] Best way of including "emergency stop" range/cliff sensors in nav2 edit

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

[Nav2] Best way of including "emergency stop" range/cliff sensors in nav2