Navigation goal overshoot (dd,amcl,move_base)

asked 2016-05-19 19:17:31 -0500

monkeyiq gravatar image

I'm bringing up a custom robot using ROS and the navigation stack. It's differential drive with a kinect for object avoidance and mapping. I have done the preliminary things making sure that the kinect data and odometer are sane, eg, moving towards a wall and seeing lagged laser data is written over itself and rotations in place rescan at the same place after a closed loop.

I have a static map made with gmapping and served with the map_server. amcl gives a reasonable posearray and tightens that up nicely when the robot moves around a bit. With map_server, amcl, and move_base all running I can teleop around the map just fine and the laser scan data does what it should, the local_costmap/costmap seems ok and is over the static map where it should be. In general things are refined to a point where everything makes sense as I move around.

Unfortunately, when I set a goal /move_base_simple/goal the robot overshoots the goal and keeps on going.It's a baby step goal, 1 meter forwards from the current pose (and tight poseArray from amcl). I stop things by lifting the robot off ground before impact with a wall. This second part is a worry as the local_costmap and laser data would surely indicate to move_base to halt anyway (don't hit the walls). Oddly, even after that, when I stop the robot running and check rviz I see the NavfnROS/plan still looks valid. It thinks the robot magically made it through the wall and wants to loop around the exterior of the building to the main entrance and then move to the goal.

Any thoughts on what I should be sniffing around to try to figure out what is causing the robot not to see it has approached and indeed run over the goal would be wonderful. I might try a U-turn goal to see if it just plows forwards or turns around and heads toward the goal before overshooting it.

edit retag flag offensive close merge delete


2 ideas comes in my mind: 1. Are you sure odometry and tf transformations are good? 2. You can try 2D Pose Estimate button in RVIZ before you give the target goal.

MariaKrgr gravatar image MariaKrgr  ( 2016-05-20 04:52:15 -0500 )edit

Starting with the simpler, the 2D pose estimate setting doesn't seem to help. I have the initial pose setup (initial_pose_x et al) in the amcl launch file. So the pose is about right relative to where the robot is at startup. Doing a post estimate as well doesn't help with the overrun.

monkeyiq gravatar image monkeyiq  ( 2016-05-26 07:13:40 -0500 )edit

Looking at the plans that are made, they seem fairly valid. I've disabled the actual motion in my robot base so I can just drop in goals and see the plans as they change and that all seems ok. I had thought that maybe the planner expects the wheels to be oriented rotated 1.57 from where they are.

monkeyiq gravatar image monkeyiq  ( 2016-05-26 07:15:50 -0500 )edit

The odom and tf stuff is all getting through ok, as seen both on the console and in rviz.

monkeyiq gravatar image monkeyiq  ( 2016-05-26 07:16:44 -0500 )edit