hector_mapping stage simulation

Question

Hello,

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

---

Originally posted by JSantos on ROS Answers with karma: 55 on 2012-12-06

Post score: 2

Answer 1

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.

---

Originally posted by Stefan Kohlbrecher with karma: 24361 on 2012-12-06

This answer was ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by JSantos on 2012-12-09:
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.

Comment by JSantos on 2012-12-09:
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: http://goo.gl/kGWG4 It seems like a V shape laser dead zone and it’s very strange. Also, this happens in stage too.

Comment by Stefan Kohlbrecher on 2012-12-13:
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.