ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

navigation problem inflation layer ?

asked 2018-05-16 03:48:26 -0500

kesuke gravatar image

updated 2018-05-18 05:44:52 -0500

hi, I'm trying to use the navigation stack on my own robot , i'm using the hokuyo laser and i already done all the stuff about the controller driver odometry and amcl , and for the navigation stack so the problem is that when i select a point de navigate on the map a trajectory is drawn and the robot start to move but in few meters the obstacle layer like shown on the second picture take all the place despite there is no obstacle and the robot start to turning around himself because he think the path is blocked why i'm getting this ?image description(/upfiles/15264603816267928.png)(/upfiles/15264603678948594.png) image description

Edit: @FrozenCh here is the local costmap i'm using :

 global_frame: /map   
 robot_base_frame: /base_link   
 update_frequency: 5.0   
 publish_frequency: 2.0    
 static_map: false    rolling_window:
 true    width: 4.0    height: 4.0   
 transform_tolerance: 0.5   
 resolution: 0.05    plugins:
     - {name: obstacle_layer,      type: "costmap_2d::VoxelLayer"}
     - {name: inflation_layer,     type: "costmap_2d::InflationLayer"}

here is the amcl setting that i used :

  <arg name="use_map_topic"   default="false"/>
  <arg name="scan_topic"      default="scan"/>
  <arg name="initial_pose_x"  default="0.0"/>
  <arg name="initial_pose_y"  default="0.0"/>
  <arg name="initial_pose_a"  default="0.0"/>
  <arg name="odom_frame_id"   default="odom"/>
  <arg name="base_frame_id"   default="base_link"/>
  <arg name="global_frame_id" default="map"/>

  <node pkg="amcl" type="amcl" name="amcl">
    <param name="use_map_topic"             value="$(arg use_map_topic)"/>
    <!-- Publish scans from best pose at a max of 10 Hz -->
    <param name="odom_model_type"           value="diff"/>
    <param name="odom_alpha5"               value="0.1"/>
    <param name="gui_publish_rate"          value="10.0"/>
    <param name="laser_max_beams"             value="60"/>
    <param name="laser_max_range"           value="12.0"/>
    <param name="min_particles"             value="500"/>
    <param name="max_particles"             value="2000"/>
    <param name="kld_err"                   value="0.05"/>
    <param name="kld_z"                     value="0.99"/>
    <param name="odom_alpha1"               value="0.2"/>
    <param name="odom_alpha2"               value="0.2"/>
    <!-- translation std dev, m -->
    <param name="odom_alpha3"               value="0.2"/>
    <param name="odom_alpha4"               value="0.2"/>
    <param name="laser_z_hit"               value="0.5"/>
    <param name="laser_z_short"             value="0.05"/>
    <param name="laser_z_max"               value="0.05"/>
    <param name="laser_z_rand"              value="0.5"/>
    <param name="laser_sigma_hit"           value="0.2"/>
    <param name="laser_lambda_short"        value="0.1"/>
    <param name="laser_model_type"          value="likelihood_field"/>
    <!-- <param name="laser_model_type" value="beam"/> -->
    <param name="laser_likelihood_max_dist" value="2.0"/>
    <param name="update_min_d"              value="0.25"/>
    <param name="update_min_a"              value="0.2"/>
    <param name="odom_frame_id"             value="$(arg odom_frame_id)"/>
    <param name="base_frame_id"             value="$(arg base_frame_id)"/>
    <param name="global_frame_id"           value="$(arg global_frame_id)"/>
    <param name="resample_interval"         value="1"/>
    <!-- Increase tolerance because the computer can get quite busy -->
    <param name="transform_tolerance"       value="1.0"/>
    <param name="recovery_alpha_slow"       value="0.0"/>
    <param name="recovery_alpha_fast"       value="0.0"/>
    <param name="initial_pose_x"            value="$(arg initial_pose_x)"/>
    <param name="initial_pose_y"            value="$(arg initial_pose_y)"/>
    <param name="initial_pose_a"            value="$(arg initial_pose_a)"/>
    <remap from="scan"                      to="$(arg scan_topic)"/>
edit retag flag offensive close merge delete


It looks like these is something wrong with the scan topic and your cost map just reflects to the bad data.

and besides, could you show us the cost map setting you made for obstacle layer?

FrozenCh gravatar image FrozenCh  ( 2018-05-16 04:38:58 -0500 )edit

It looks like you localisation is way off, this means that the LIDAR scan data is being added to the wrong part of the cost map and filling it with obstacles. I'd take a step back and get the localisation working first.

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-05-16 05:51:47 -0500 )edit

@PeteBlackerThe3rd thanks for answering , do you have any idea to check if the localisation is working well , i followed this tutorial and everthing seems to be right with the localization

kesuke gravatar image kesuke  ( 2018-05-16 07:11:33 -0500 )edit

i have some doubt about the updating map parameter

kesuke gravatar image kesuke  ( 2018-05-16 07:29:31 -0500 )edit

@kesuke to test the localisation you manually drive your robot around with the mapping system running and visual check using RVIZ that it builds a map correctly and shows the robot in roughly the right place.

PeteBlackerThe3rd gravatar image PeteBlackerThe3rd  ( 2018-05-16 07:38:05 -0500 )edit

i did and it builds map correctly and the robot seems to be on the right place

kesuke gravatar image kesuke  ( 2018-05-16 09:26:21 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2018-05-16 22:07:32 -0500

FrozenCh gravatar image

I agree with what @PeteBlackerThe3rd said, your scan points are not aligned with the wall on your map, so we see that as localization issue.

and for the cost map, you can do extra setting like

   global_frame: /map   
   robot_base_frame: /base_link   
   update_frequency: 5.0   
   publish_frequency: 2.0    
   static_map: false
   rolling_window: true
   width: 4.0
   height: 4.0   
   transform_tolerance: 0.5   
   resolution: 0.05 
       - {name: obstacle_layer,      type: "costmap_2d::VoxelLayer"}
       - {name: inflation_layer,     type: "costmap_2d::InflationLayer"}
       observation_sources: "base_scan"
       base_scan: {data_type: LaserScan, sensor_frame: /laser_link, clearing: true, marking: true, topic: /scan}
edit flag offensive delete link more


the part of obstacke_layer i used it on the costmap_common_param , maybe you right about localization knowing that i used hokuyo laser how should i know if the error come from odometry or laser data ?

kesuke gravatar image kesuke  ( 2018-05-17 07:45:03 -0500 )edit

Localization problem may be caused by amcl setting. Do you have proper setting about your odom model type?

<param name="odom_model_type" value="omni"/>


<param name="odom_model_type" value="diff"/>
FrozenCh gravatar image FrozenCh  ( 2018-05-17 21:22:19 -0500 )edit

@FrozenCh i'm using "diff model " you can have a look to the amcl setting that i used i had update my question , and @@PeteBlackerThe3rd you were right it's a problem of localization but how to know who causing the problem between odometry and the amcl settin

kesuke gravatar image kesuke  ( 2018-05-18 05:49:39 -0500 )edit

try this:

use_map_topic: true

FrozenCh gravatar image FrozenCh  ( 2018-05-21 04:39:53 -0500 )edit

@ it does not work , should i use "odom_model_type" ?

kesuke gravatar image kesuke  ( 2018-05-23 10:13:59 -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



Asked: 2018-05-16 03:48:26 -0500

Seen: 727 times

Last updated: May 18 '18