Ask Your Question
0

Repeated sideways jumps in gmapping with Hokuyo

asked 2014-09-29 15:08:06 -0500

BlitherPants gravatar image

updated 2014-09-29 15:53:31 -0500

Hi,

I'm using a Turtlebot 2 on ROS Hydro on Ubuntu 12.04 64-bit. Recently I replaced my bot's Kinect with a Hokuyo URG-04LX. Since then, I've been getting much better maps of my office building in terms of where hallways and cubicles should be. However, there is a weird new phenomenon I haven't been able to isolate the cause of.

Namely, walls that should be straight are a series of short parallel line segments that are all off by some angle. This happens for even a simple test where I drove the robot in a straight line down a hallway: image description

I had thought maybe there was something wrong with the numbers on the transform from the base to the Hokuyo that I was manually publishing, but now I'm not sure; if I run RViz while playing the same bagfile, set the global fixed frame to /odom, turn off the map, and set the LaserScan decay to 300, I can get a "map" that actually looks very good, like so:

image description

Note that, in this image, the map has a perfectly straight hallway. This is the result of using the same arguments to the static transform publisher (shown in the script window). So if I'm correct (am I...?), the fact that this map looks good rules out bad transform arguments as well as bad odometry.

Watching the GMapping process in RViz, I can see that as the robot drives forward, every few seconds, its pose seems to consistently jump to the left, which is why the output gets that skewed map. It doesn't look like I'm allowed to post videos here, but if it helps, I can go create a YouTube account and share a recording of what this looks like.

I've tried several things, including slowing the bagfile down 10x, changing the map resolution (delta), and throttling the scans in GMapping. Nothing really changes the consistent jumping. My GMapping launch file is as follows (currently using the default arguments):

<launch>
  <arg name="scan_topic" default="scan" />
  <arg name="srr" default="0.01"/>
  <arg name="srt" default="0.02"/>
  <arg name="str" default="0.01"/>
  <arg name="stt" default="0.02"/>
  <arg name="lU" default="0.5"/>
  <arg name="aU" default="0.436"/>
  <arg name="mU" default="20"/>



  <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
    <param name="base_frame" value="base_footprint"/>
    <param name="odom_frame" value="odom"/>
    <param name="map_update_interval" value="$(arg mU)"/>
    <param name="maxUrange" value="3.5"/>
    <param name="maxRange" value="8"/>
    <param name="sigma" value="0.05"/>
    <param name="kernelSize" value="1"/>
    <param name="lstep" value="0.05"/>
    <param name="astep" value="0.05"/>
    <param name="iterations" value="5"/>
    <param name="lsigma" value="0.075"/>
    <param name="ogain" value="3.0"/>
    <param name="lskip" value="0"/>
    <param name="srr" value="$(arg srr)"/>
    <param name="srt" value="$(arg srt)"/>
    <param name="str" value="$(arg str)"/>
    <param name="stt" value="$(arg stt)"/>
    <param name="linearUpdate" value="$(arg lU)"/>
    <param name="angularUpdate" value ...
(more)
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
1

answered 2014-10-03 03:01:10 -0500

jorge gravatar image

Take a look at this ROS answer, can have interesting information for you. Specially, setting the minimumScore parameter to something like 100 or higher should avoid the jumps. The answer itself and the gmapping ROS wiki give you an explanation of what's going on. Also this PR can help.

Btw, the minimumScore has been edited on TB2's gmapping demo ( https://github.com/turtlebot/turtlebo... ) but I think only on indgo

edit flag offensive delete link more

Comments

I had already tried setting minimumScore to the ballpark of 1000 but just now I tried it at 1000000 and the behavior still didn't change. Strangely enough, I don't see any scan matching fails in the gmapwindow. Stranger, if I set str, etc to 0 and particles to 1 to remove SLAM it still jumps...

BlitherPants gravatar imageBlitherPants ( 2014-10-03 08:41:01 -0500 )edit

OK so, after allowing the ROS packages to update for the first time in a few months, I can get the scan matching to fail. Putting a really high score does make it rely only on odometry now, and while that does make the straight line maps look great, mapping a large building doesn't work...

BlitherPants gravatar imageBlitherPants ( 2014-10-07 09:57:41 -0500 )edit
0

answered 2014-09-30 04:21:17 -0500

bvbdort gravatar image

updated 2014-09-30 04:22:27 -0500

Change below params

 <arg name="str" default="0.005"/><!-- how much rotation from linear movement -->
<arg name="lU" default="0.05"/> <!-- Update map for movement of 5 cm-->
<arg name="aU" default="0.08726"/> <!-- Update map for rotation of 5 deg -->

hope these values will improve result.

try hector mapping it gives better result .

edit flag offensive delete link more

Comments

I tried it but it doesn't seem to help much. Thanks for the answer though.

BlitherPants gravatar imageBlitherPants ( 2014-09-30 10:13:56 -0500 )edit

i recommend hector slam its work fine without bothering about motion model of your robot.

bvbdort gravatar imagebvbdort ( 2014-09-30 12:37:16 -0500 )edit

also you can share your bag file

bvbdort gravatar imagebvbdort ( 2014-09-30 12:38:02 -0500 )edit

I just tried hector_slam. For the map of the entire building, it fails to isolate the hallways properly, so even with the angle problem, gmapping is still better for that case...

BlitherPants gravatar imageBlitherPants ( 2014-09-30 15:51:30 -0500 )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

2 followers

Stats

Asked: 2014-09-29 15:08:06 -0500

Seen: 1,360 times

Last updated: Oct 03 '14