Ask Your Question

When working with amcl why does the robot try to move closer to the wall in an open area rather than navigating more towards the goal?

asked 2017-11-20 20:28:06 -0600

nemesis gravatar image

updated 2017-11-21 05:47:55 -0600

For example, the following

image description

The robot is closer to the wall instead of following the path to the goal (green line).

I have noticed that happen all the time. Why is that so? Is there a particular parameter that influences this? As soon as the robot gets close to the wall it gets better at navigating straight to the goal I think. Or is it something related to amcl algorithm(s)?

Here is the robot shortly after reaching close to wall and then moving towards the goal again.

image description

What causes such a pattern/behavior?

Update Based on Comment:

Here are some of the config/params I am working with.

move_base node

<node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
    <rosparam file="$(find robot)/config/costmap_common_params.yaml" command="load" ns="global_costmap" />
    <rosparam file="$(find robot)/config/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find robot)/config/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find robot)/config/global_costmap_params.yaml" command="load" />
    <rosparam file="$(find robot)/config/base_local_planner_params.yaml" command="load" />

    <param name="controller_frequency" value="10.0"/>
    <param name="planner_frequency" value="10.0"/>

    <remap from="cmd_vel" to="cmd_vel"/>
    <remap from="odom" to="odom"/>
    <remap from="scan" to="robot/laser/scan"/>   


map_type: costmap

origin_z: 0.0 
z_resolution: 1
z_voxels: 2

obstacle_range: 2.5 
raytrace_range: 3.0 

publish_voxel_map: false
transform_tolerance: 0.5 
meter_scoring: true

robot_radius: 0.3 
inflation_radius: .6

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: hokuyo, data_type: LaserScan, topic: /robot/laser/scan, marking: true, clearing: true}


   global_frame: map 
   robot_base_frame: chassis
   update_frequency: 10.0
   publish_frequency: 5.0 
   width: 40.0
   height: 40.0
   resolution: 0.05
   origin_x: -20.0
   origin_y: -20.0
   static_map: true
   rolling_window: false


   global_frame: map 
   robot_base_frame: chassis
   update_frequency: 10.0
   publish_frequency: 5.0 
   width: 10.0
   height: 10.0
   resolution: 0.05
   static_map: false
   rolling_window: true


  max_vel_x: 0.5 
  min_vel_x: 0.1 

  max_vel_theta: 1.5 
  min_in_place_vel_theta: 0.314

  acc_lim_theta: 20.0
  acc_lim_x: 10.0
  acc_lim_y: 5.0 

  holonomic_robot: false
edit retag flag offensive close merge delete



This is not related to AMCL, which is a localization node. This is related to the navigation package and the planners you are using. Please post the config files you are using...

Procópio gravatar image Procópio  ( 2017-11-21 02:26:56 -0600 )edit

@Procopio Updated my question. Thanks!

nemesis gravatar image nemesis  ( 2017-11-21 05:48:52 -0600 )edit

2 Answers

Sort by » oldest newest most voted

answered 2017-11-22 00:49:48 -0600

billy gravatar image

I am in no way an expert about this but had a similar issue and was able to solve it. I'll share my experience. I had an issue that when the robot came close to a wall or corner it would stop, and then very slowly turn more towards the wall and then get hopelessly stuck trying not to hit the wall while turning towards it. Sometimes it would actually hit the wall, but not always. This was using the base navigation stack on Jade. If this sounds like the problem you're having, then read on.

To solve it I ended up increasing the inflation radius a bit more than should have been needed and then set the footprint radius to a value smaller than reality. With this, the robot would get closer to the wall than the nav stack would realize, but it also meant the nav stack would not try to avoid it unnecessarily. With those changes things clicked and started working. Maybe try setting the radius of your robot to 0.2 or the inflation radius to 0.7 and see if it improves.

edit flag offensive delete link more


smaller the local_costmap width and height should be help to this,if it is odom or wheel deviation.And up pdist_scale maybe also useful.

dyan gravatar image dyan  ( 2017-11-25 02:52:07 -0600 )edit

@billy Thanks for the response! But shouldn't increasing the inflation radius be a problem in narrower spaces? I have somewhat narrow hallways on my map, and increasing the inflation radius causes issues with that. Unless I am mistaken here.

nemesis gravatar image nemesis  ( 2017-12-05 17:36:50 -0600 )edit

@dyan Thanks! I will try those as well. I haven't messed around with any of the height/width/resolution parameters because I am unsure what kind of effects those changes will have. I have kind of patched things together, and there are too many things to tune here.

nemesis gravatar image nemesis  ( 2017-12-05 17:39:16 -0600 )edit

answered 2017-11-24 04:14:08 -0600

Procópio gravatar image

Try to set the global_frame of your local costmap to odom

edit flag offensive delete link more


Thank you. This hasn't helped, unfortunately.

nemesis gravatar image nemesis  ( 2017-12-05 17:57:37 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2017-11-20 20:28:06 -0600

Seen: 779 times

Last updated: Nov 24 '17