hi Ross,

Did you ever find a parameter setting for gmapping that produced the
behavior that you want?  Did you try karto
(http://www.ros.org/wiki/karto)?

	brian.

On Sat, Nov 27, 2010 at 1:18 PM, Ross A Knepper <rak@ri.cmu.edu> wrote:
> Greetings,
>
> I am trying to build a map of a fairly large (tens of meters) indoor area
> using slam_gmapping.  My robot uses the StarGazer localization system from
> Hagiosonic, which provides an absolute pose with small error bounds.  The
> robot is also equipped with a Hokuyo URG-04LX-UG01 ladar, which has a
> range of only 4 meters and sizeable error on its range readings.  This
> situation is opposite to the assumption made by gmapping, which expects
> large odometry error and small laser error.  I have tried tweaking various
> parameters, but every map I've tried to collect looks terrible.  The
> trouble seems to be that there are parts of the room from which walls
> cannot be seen with such short range.  The laser does pick up many
> furniture legs, but scan-matching of these between iterations introduces a
> lot of rotational error.  I perviously mapped the space just fine using a
> SICK and the StarGazer (with minimal tweaking of parameters).
>
> What I need to know:
> In principle, what are the right parameters to be looking at?  Some of
> them are not extremely well documented on the ROS site
> (http://www.ros.org/wiki/gmapping).  The site that page points to
> (http://openslam.org/gmapping.html) is at this point largely useless, as
> the links are either broken or point back to the same page.  So at this
> point, it seems the only decent documentation is the academic paper.
> This is a shame because many people would be unwilling to digest it (nor
> should they have to become a SLAM expert just to build a decent map).
>
> What I have tried:
> I have set the parameters srr, srt, stt, and str to zero or near-zero, to
> reflect the fact that the minimal amount of odometry error is not
> cumulative.  I would like the SLAM software to rely strongly on the
> localization data and only very weakly on the ladar scan-matching results.
> I therefore increased the parameters sigma and lsigma (which I presume to
> be standard deviations related to scan-matching).  These adjustments
> actually made the map much worse (it turned a complete 180 degrees so I
> saw the same features at both ends of the mapped room).
>
> My transforms are as follows:
> base_laser->base_link (static)
> base_link->odom (provided by the a Kalman Filter that fuses StarGazer and odometry data)
>
> I performed the following experiment to verify the quality of the
> StarGazer fused odometry.  If I broadcast a static null-transform
> map->odom, then I can watch in rviz as the robot smoothly drives across
> the screen.  Turning on a long Decay Time, I see that the laser readings
> are as consistent while driving as they are while standing still.  If, on
> the other hand, I run slam_gmapping and let it broadcast the map->odom
> transform, then driving the robot causes it to jump around quite a bit in
> rviz.  So I'm fairly sure that gmapping is relying too heavily on
> scan-matching instead of localization.
>
> At a high level, this seems like a silly problem because what I'm trying
> to do is much easier than the hard problem that slam_gmapping is solving.
> Yet it has caused me a lot of trouble.  Is there a better tool for the
> job?
>
> Any pointers and tips would be appreciated!
>
>  -ross
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>