# 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?

For example, the following

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.

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" />

<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"/>
</node>


costmap_common_params.yaml

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

observation_sources: laser_scan_sensor

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


global_costmap_params.yaml

global_costmap:
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


local_costmap_params.yaml

local_costmap:
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


base_local_planner_params.yaml

 TrajectoryPlannerROS:
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 close merge delete

1

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...

( 2017-11-21 02:26:56 -0500 )edit

@Procopio Updated my question. Thanks!

( 2017-11-21 05:48:52 -0500 )edit

Sort by » oldest newest most voted

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.

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.

( 2017-11-25 02:52:07 -0500 )edit

@billyhttps://answers.ros.org/users/26871/b... 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.

( 2017-12-05 17:36:50 -0500 )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.

( 2017-12-05 17:39:16 -0500 )edit

Try to set the global_frame of your local costmap to odom

more

Thank you. This hasn't helped, unfortunately.

( 2017-12-05 17:57:37 -0500 )edit