Ask Your Question

hector_mapping stage simulation

asked 2012-12-06 04:37:41 -0600

JSantos gravatar image


I'm trying to implement a small simulation of hector_mapping package using stage on Ubuntu 11.10 with ROS Fuerte. I changed the launch file within this package in order to be compatible with stage.

Original Launch file:

  <arg name="tf_map_scanmatch_transform_frame_name" default="scanmatcher_frame"/>
  <arg name="base_frame" default="base_footprint"/>
  <arg name="odom_frame" default="nav"/>
  <arg name="pub_map_odom_transform" default="true"/>
  <arg name="scan_subscriber_queue_size" default="5"/>
  <arg name="scan_topic" default="scan"/>
  <arg name="map_size" default="2048"/>

Modified Launch file:

  <arg name="tf_map_scanmatch_transform_frame_name" default="scanmatcher_frame"/>
  <arg name="base_frame" default="base_link"/> <!-- /base_footprint to /base_link -->
  <arg name="odom_frame" default="odom"/> <!-- /nav to /odom -->
  <arg name="pub_map_odom_transform" default="true"/>
  <arg name="scan_subscriber_queue_size" default="5"/>
  <arg name="scan_topic" default="base_scan"/> <!-- /scan to /base_scan -->
  <arg name="map_size" default="2048"/>

However, the results aren't the best. It seems that the robot loses its location and the map is built incorrectly. I would expect the map to be almost perfect, since I am using Stage's built-in odometry. The results can be seen here in this video:

youtube [.dot] com [dash] watch?v=ghQpwf5gYY4 (Sorry I haven't got enough karma to post a video)

In the beginning you can see how I am running the system; and by 3m45s you can see how the map is incorrectly alligned.

Please, can someone help me out? If anything else is needed, I will gladly post it later.

Thanks in advance :)

edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2012-12-06 06:56:07 -0600

hector_mapping doesn't use odometry data. That's very nice if you have a real world system that provides no or very bad odometry. If you have perfect odometry in stage on the other hand and can't use it, this can be a disadvantage. In the video, the map breaks when the robot rotates very fast in place, so it appears the scanmatcher can't keep up there, as the change in shape from one scan to the next is too large. Generally, high update rate and high range LIDARs work best.

edit flag offensive delete link more



Thanks! I'm fascinated with your work, it's very interesting. However I have a few questions. I have implemented this package with teleoperation in a robotic platform which has a Hokuyo URG-04LX-UG01 Laser Rangefinder with an update rate of 10Hz.

JSantos gravatar imageJSantos ( 2012-12-09 07:48:58 -0600 )edit

I know that isn't the best update rate for this package, but I'm doing slow rotations. I did some experiences and the resulting mapping was exceptional, although this is happening: It seems like a V shape laser dead zone and it’s very strange. Also, this happens in stage too.

JSantos gravatar imageJSantos ( 2012-12-09 07:49:20 -0600 )edit

This looks like the missing laser points are closer to the LIDAR than the value specified in the "laser_min_dist" parameter. It defaults to 0.4, so setting it to a lower value should resolve the issue.

Stefan Kohlbrecher gravatar imageStefan Kohlbrecher ( 2012-12-13 19:48:40 -0600 )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: 2012-12-06 04:37:41 -0600

Seen: 571 times

Last updated: Dec 06 '12