Navigation 2: dealing with bumper obstacles

asked 2020-08-17 22:43:02 -0500

Leonti
62 ●9 ●14 ●14

I'm trying to add a bumper to my robot and I implemented the following solution based on Kobuki bumper2pc:

I have left and right bumpers on my robot which emit custom Bumper events. Another package is subscribing to the events and sends a PointCloud2 events accordingly: bumper2pc

When a bumper is pressed it will put a point in front of the robot, when the bumper is released it will put a point far away from it. By monitoring the PointCloud2 in RViz I can see that it's working.

Obstacle layer in Navigation is configured to use both scan and pointcloudsources as described here: https://index.ros.org/p/nav2_costmap_2d/ ("How to use multiple sensor sources" section). This also seems to work - when I press the bumper a new obstacle would appear in local cost map.

However, this seems to be not enough for Navigation stack - it continues to push forward as if the obstacle wasn't there or it would attempt to spin right away without backing up.

What I ideally like to have is this:
1. When the bumper is pressed, navigation detects it as an obstacle and remembers its position (this seems to be working).
2. Then it tells the robot to back up 2/3 cm (otherwise the bumper keeps being pressed).
3. Calculate a new path around the obstacle.

Can this be done with Navigation 2 stack alone or do I have to do step 2 myself?
I'm happy to back up the robot myself on a bumper event, but what do I have to send to Navigation 2 to pause the navigation in the meantime and how to tell it to calculate a new path afterwards?

Comments

we got the same issue, so really thank your bumper2pc solution, it could really solves the majority of the issue. We were wondering if you've solved the rest of problems as mentioned in your 1. / 2. / 3.

To our knowledge, 2. could be solved by using Kobuki safety control. 3. could be solved by an exploration planner. But we don't know how did you overcome 1.

Hope to hear your expertise!

lukelu ( 2020-09-29 13:01:15 -0500 )edit

add a comment

answered 2020-08-18 02:34:00 -0500

billy
1850 ●24 ●87 ●47

I can tell you how I have solved this:

When a bumper is activated

low level state machine immediately stops motion and begins a cycle of ignoring cmd_vel coming from ROS
bumper input is communicated to ROS and added to cost map via point cloud (as you are doing)
low level SW backs the robot up a certain distance
low level SW pauses for 1 second or so at end of move to allow move_base to replan for the new position and new obstacle on cost map
low_level state_machine goes back to normal operation reacting to ROS cmd_vel.

In this setup 'low level' means C code running on uC between ROS PC and robot HW. move_base does not seem to get frustrated at all by the apparent willfulness of the robot to simply stop listening for 4 seconds or so.

If you don't have a uC running interference you could implement similar code in the PC, but the more quickly you stop the motor drive, the less risk there is to odom related issues from wheels spinning against an obstacle.

edit flag offensive delete link

Comments

Thanks @billy! This sounds like a good solution. My setup is a Raspberry Pi which listens to /cmd_vel and send it to Arduino via serial port.
It also interprets velocity data from Arduino and sends Twist messages.
Bumper events are processed via RPi directly.

The first things I will try is to try to do back out logic in Rpi where it communicates with Arduino - I can ignore /cmd_vel commands there and also I have access to bumper events there as well. If it's not fast enough I might need to replicate your solution fully and do this in Arduino ;)

Do you happen to have your code available on Github?

Thanks again, it seems like now I know what to do ;)

Leonti ( 2020-08-18 22:24:53 -0500 )edit

So I did it as I planned in the python "bridge" between Arduino, and ROS and the performance is acceptable :)

However, I can't make Navigation to properly go around an obstacle. @billy do you have any guidance on how far to place the pointcloud point from the robot and at which angle? My robot diameter is 22cm. I tried different values and the navigation either ignores them or makes adjustment in the wrong direction. For example, the left bumper is pressed, but the adjusted path goes in the left direction as opposed to turning right first to avoid an obstacle. I know I have to play with the distance of the point and an angle, but it's hard to find good starting values...

Leonti ( 2020-09-07 07:15:24 -0500 )edit

I have three switches - front, left and right. If any of the three switches is bumped I include the front point cloud, and then for if left or right switch is hit, I also include left or right. So every bumper event includes putting the front point in the cost map in front of the robot. This assures the planner can't just tell it to go straight ahead. Immediately in front of the robot is always blocked.

As for locations of the points in my setup:

Vertically: 1 cm above the floor - do not put them on the floor or robot will drive over them. I think 2 or 10 would work also. I have mine set at 1cm (0.01m) and it works.

Angled from the X axis: Front: angle = 0 radians Left: angle = 0.32 radians Right: angle = - 0.32 radians

When bumper is active: Distance from ...(more)

billy ( 2020-09-10 18:56:25 -0500 )edit

add a comment

Navigation 2: dealing with bumper obstacles

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Navigation 2: dealing with bumper obstacles edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Navigation 2: dealing with bumper obstacles