Rosanswers logo

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


Originally posted by Stefano Primatesta on ROS Answers with karma: 402 on 2014-07-10

Post score: 1


1 Answer 1


Rosanswers logo


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.

Originally posted by jorge with karma: 2284 on 2014-07-10

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by Stefano Primatesta on 2014-07-10:
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?

Comment by jorge on 2014-07-11:
mmm.... never tried if, but looks like laser_filters package can help, if hokuyo_node reports 0s when no contact. I updated the answer.

Comment by Procópio on 2016-02-02:
relevant discussion regarding costmaps clearing with max_range scans...


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.