Voxel maps not working with Turtlebot2 bumpers (Updated)
Hello,
I have a Turtlebot 2 (Kobuki + Kinect) that I'm working on a navigation system for.
I am currently having a problem with getting move_base to behave safely in the event of a collision.
For obstacles that the Kinect can see, this is not a problem, but there are many things (the bases on office chairs, glass doors, short items, the list goes on...) that the Kinect can not account for.
To solve this problem, I have changed the gmapping local costmap to a voxel map, so I have an obstacle layer for the Kinect and a separate obstacle layer for the bumpers. However, this solves very little. If the robot is moving and hits something that causes the bumper to depress, it acts as though nothing happened and keeps trying to go forward.
In an attempt to narrow the cause of this problem down, I have verified the following:
I can use
rostopic echo mobile_base/events/bumperto see that the bumpers respond to being pressed.In rviz, I can see that when the robot is sitting still, I can press the bumpers and the local costmap will be updated to show an obstacle in front of the robot. Letting go of the bumper will not clear the obstacle, and if I send the robot a goal, it will try to navigate around the "obstacle" created by pressing the bumper.
Also in rviz, if I send the robot a goal to move forward, and I jump in its path so that the Kinect can see me, the robot will steer around me.
However, if I get in the robot's way by depressing the bumper but staying out of the sight of the Kinect, the robot will simply try to aggressively push through my hand.
After having played with this configuration for a while, I have noticed that the bumpers are inserting obstacles into the costmap, but it looks like it's not doing it fast enough for the robot to change its behavior. In other words, by the time the obstacle shows up in rviz, it is either directly underneath the robot, or behind it. My guess is that is why the robot doesn't reroute -- because it doesn't think the obstacle is in its path.
Does anyone have any comment on this? Am I right in my hypothesis for why this happens? If so, how would I go about remedying this? Perhaps writing code in my application to raise an interrupt on bumper pressing, sending a cancel to move_base, making the robot back up a few inches, and resending the goal?
Or am I missing something else that would cause the bumpers to work properly without the need for making drastic changes?
I have taken a video capture of the above happening in rviz. If that would be helpful, I will try to upload it to YouTube or something.
The steps I take to get this problem are as follows:
roslaunch turtlebot_bringup minimal.launch
roslaunch ...
The local costmap update frequency can be configured in local_cost_map_params. Try to configure update_frequecny in local_costmap_params.yaml. Reference : http://wiki.ros.org/navigation/Tutorials/RobotSetup If it does not work, could you share the video? I am just curious how it behaves..
Thanks for the response! I've already made a modified version of kobuki_safety_controller that seems to work, but I'm still looking into it. I may try your suggestion, though I'm wary of bogging down the computer (gmapping seems to crash a lot running multiple processes). I'll update when possible.
Only once I increased the frequency to 20Hz (high!) did it work with the default safety controller. Gmapping froze once so it may be too much for my CPU. Still, this is a good answer. In the future, I'll test this against what I did (changing safety_controller) to see which works better. Thanks!
I attached the video for you. At least, I think I did, but I can't seem to find where it shows.