Problem with turtlebot and costmap update

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

Stefano Primatesta
402 ●18 ●20 ●25

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

<launch>

  <node pkg="hokuyo_node" type="hokuyo_node" name="hokuyo_node">
  </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>

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

</launch>

costmap_common_params.yaml

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

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

local_costmap_params.yaml

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

move_base_params.yaml

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

thanks!

edit retag flag offensive close merge delete

add a comment

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

jorge

2284 ●40 ●71 ●78 https://github.com/corot

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

Hello,

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:

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

Didn't test it, but lgtm.

Comments

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