0
$\begingroup$

Rosanswers logo

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: https://www.youtube.com/watch?v=oYihWi8htt0

Thanks in advance, Simon


Originally posted by SimonDahrs on ROS Answers with karma: 1 on 2019-12-12

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by stevemacenski with karma: 8272 on 2019-12-12

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by SimonDahrs on 2019-12-12:
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.

Comment by stevemacenski on 2019-12-17:
This appears to be issues with localization or positioning, not move base.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.