Ask Your Question
0

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

nemesis gravatar image

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

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

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_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 flag offensive close merge delete

Comments

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

Procópio gravatar imageProcópio ( 2017-11-21 02:26:56 -0500 )edit

@Procopio Updated my question. Thanks!

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

2 Answers

Sort by » oldest newest most voted
0

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

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

Comments

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

nemesis gravatar imagenemesis ( 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.

nemesis gravatar imagenemesis ( 2017-12-05 17:39:16 -0500 )edit
0

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

Procópio gravatar image

Try to set the global_frame of your local costmap to odom

edit flag offensive delete link more

Comments

Thank you. This hasn't helped, unfortunately.

nemesis gravatar imagenemesis ( 2017-12-05 17:57:37 -0500 )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

2 followers

Stats

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

Seen: 470 times

Last updated: Nov 24 '17