Ask Your Question

Problem with turtlebot and costmap update

asked 2014-07-10 07:06:12 -0500

Stefano Primatesta gravatar image

I've a problem with turtlebot and costmap update.

I use turtlebot with a Hokuyo URG-04LX laser. I'm not using kinect.

I simulate turtlebot in gazebo with amcl_demo.launch in a know map. It always works! Costmap is always update and if there is a dynamic obstacle, I can observe it in costmap (local and global). When obstacle there is no more there is no trace in costmap, because costmap is always in update.

The problem there is in real turtlebot. I use the same configuration. I can observe dynamic obstacle, but when obstacle there is no more, I can still see his trace in costmap.

I don't know why!

This is my amcl_demo.launch


  <node pkg="hokuyo_node" type="hokuyo_node" name="hokuyo_node">

<!-- static transformation between laser and base_link -->    
<node pkg="tf" type="static_transform_publisher" name="laser_tf" args="0 0 0 0 0 0 base_link laser 100" />

  <!-- Map server -->
  <arg name="map_file" default="$(find ompl_planner_rrt)/config/map/corridor.yaml"/>
  <node name="map_server" pkg="map_server" type="map_server" args="$(arg map_file)" />

  <arg name="initial_pose_x" default="0.0"/> 
  <arg name="initial_pose_y" default="0.0"/>
  <arg name="initial_pose_a" default="0.0"/>
  <include file="$(find turtlebot_navigation)/launch/includes/amcl.launch.xml">
    <arg name="initial_pose_x" value="$(arg initial_pose_x)"/>
    <arg name="initial_pose_y" value="$(arg initial_pose_y)"/>
    <arg name="initial_pose_a" value="$(arg initial_pose_a)"/>

  <include file="$(find turtlebot_navigation)/launch/includes/move_base.launch.xml"/>



max_obstacle_height: 0.60  # assume something like an arm is mounted on top of the robot
obstacle_range: 2.5
raytrace_range: 3.0
robot_radius: 0.18
inflation_radius: 0.50

# voxel map configuration; z-voxels 0 are filled by bumpers and 1 by laser scan (kinect)
map_type: voxel
origin_z: 0.0
z_resolution: 0.2
z_voxels: 2
publish_voxel_map: false

observation_sources: scan bump

scan: {data_type: LaserScan, topic: scan, marking: true, clearing: true, min_obstacle_height: 0.25, max_obstacle_height: 0.35}
bump: {data_type: PointCloud2, topic: mobile_base/sensors/bumper_pointcloud, marking: true, clearing: false, min_obstacle_height: 0.0, max_obstacle_height: 0.15}


   global_frame: /map
   robot_base_frame: /base_footprint
   update_frequency: 1.0
   publish_frequency: 0.5
   static_map: true
   transform_tolerance: 0.5


   global_frame: /map
   robot_base_frame: /base_footprint
   update_frequency: 5.0
   publish_frequency: 2.0
   static_map: false
   rolling_window: true
   width: 4.0
   height: 4.0
   resolution: 0.05
   transform_tolerance: 0.5


shutdown_costmaps: false

controller_frequency: 5.0
controller_patience: 3.0

planner_frequency: 1.0
planner_patience: 5.0

oscillation_timeout: 10.0
oscillation_distance: 0.2


edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2014-07-10 10:10:07 -0500

jorge gravatar image

updated 2014-07-11 02:39:52 -0500


First thing I would check is the content of the /scan topic. If I remember properly, at least on fuerte hokuyo_node reported 0 if there's no obstacles within laser range (~5 m in your case, I think). If the robot is in the middle of a big, empty room, you will get mostly 0s (or maybe nan, not sure) in the laser scan, I guess. If this is the case, costmap will not raytrace back and so will not clear existing obstacles.

The solution I did long time ago was just to patch hokuyo_node code to return the max distance (or any big distance above the max range) instead of 0 (or nan). But hopefully someone can give you a less shoddy solution!

Btw, which ROS version do you use?

UPDATE possible solution using laser_filters package: add a LaserScanRangeFilter with epsilon lower threshold:

- name: range
  type: LaserScanRangeFilter
    lower_threshold: 0.0001
    upper_threshold: .inf

Didn't test it, but lgtm.

edit flag offensive delete link more


Thanks! I think this is the problem! I tried to apply laser_filters package to limit range but the problem remains. I'm using Hydro. Have I to change hokuyo_node from source?

Stefano Primatesta gravatar image Stefano Primatesta  ( 2014-07-10 11:15:20 -0500 )edit

mmm.... never tried if, but looks like laser_filters package can help, if hokuyo_node reports 0s when no contact. I updated the answer.

jorge gravatar image jorge  ( 2014-07-11 02:41:21 -0500 )edit

relevant discussion regarding costmaps clearing with max_range scans...

Procópio gravatar image Procópio  ( 2016-02-02 10:12:32 -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

1 follower


Asked: 2014-07-10 07:06:12 -0500

Seen: 1,410 times

Last updated: Jul 11 '14