ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Move base navigation malfunctions

asked 2019-12-12 10:27:55 -0500

SimonDahrs gravatar image

updated 2019-12-17 05:07:06 -0500

Hi all,

I am developing a diff wheel autonomous robot using the move_base package. I use wheel encoders, a lidar sensor and AMCL to estimate the current pose. When I set a simple goal, 1 meter to the right of the initial pose which I manually set, the global plan of NavfnRos seems fine. However the local plan deviates from this plan, which causes the robot not to get to its goal. See the screenshot below. image description You see the upper green line is the path as retrieved from topic /move_base/TrajectoryPlannerROS/local_plan.
The other green line is the path as retrieved from topic /move_base/NavfnROS/plan. The rectangle is the robot's footprint, and the attached arrow the current pose.
Lastly, the lower arrow is the goal pose.

My question is: why does the local plan diverge from the global plan? It would make a lot more sense if the local plan would turn right instead of left.
Any help would be appreciated!

EDIT Here is an RVIZ capture video where you see the behaviour of the local path:

Thanks in advance, Simon

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-12-12 12:34:15 -0500

First off, your image isn't included. But I think your question boils down to this sentence

why does the local plan diverge from the global plan?

for which I do not need an image to answer. You could implement a local planner (controller) to follow a path directly. These are generally referred to as pure pursuit controllers and I'm sure you can find a couple online. Even DWB (the later version of DWA) can be tuned that way, given time.

There are several reasons why you may want a controller to deviate from a path, I'll mention a few intuitive ones.

  • The global planner in ROS is A* or Dijkstra that do straight graph search. They do not take into account the kinematics of the vehicle so paths do not meet the kinematic constraints of the robot itself. Deviating lets the robot actually follow it in some cases.

  • There may be situations where you would like to not replan often unless absolutely required. In that case, you would like your robot to be able to deviate from the route that it planned (lets say over 100 meters, around corners, where the robot can't possibly know the current state of the environment) so it can continue on its way.

  • Sometimes, stuff just happens. The local costmap generally updates faster and could be higher resolution than the planning space. In the case that something unexpected happens, its useful for the robot to be able to smoothly react to it (if possible) rather than stop dead in its tracks while it tries to replan.

edit flag offensive delete link more


Thanks for your answer! I changed my image link, hope it works now. Just to point something out: the robot does not only deviate from the global plan, but also it does not reach the goal while it is a very simple one: just +1 meters in x direction. So that is actually my main issue with the move_base package.

SimonDahrs gravatar image SimonDahrs  ( 2019-12-12 15:57:24 -0500 )edit

This appears to be issues with localization or positioning, not move base.

stevemacenski gravatar image stevemacenski  ( 2019-12-17 11:03:13 -0500 )edit

Question Tools

1 follower


Asked: 2019-12-12 10:27:55 -0500

Seen: 538 times

Last updated: Dec 17 '19