Localization issue using gmapping and odom data

Question

Hi all,

I do have a problem with my localization! I use gmapping to build a map and to determine the robots position. Apparently my map (base_frame: /map) and my costmap (base_frame: /odom) do not correlate. Unforeseeable jumps appear. As soon as new space is explored, the map is not really extended, but the robot is shifted to the opposite direction. After a while, the robots position is redetermined and the costmap is shifted back to its "real" position. This seems to be weird and mess up my map. Additionally my robots position is also not correct which is a problem for further processing!

as you see in the screenshot ... mapping works fine and also the costmap was right. Then the robot rotates and as soon as new space (beneath the robot) is explored, the costmap makes a jump to the top!! Instead of expanding the underlying map, the costmap is shifted and the robots position is wrongly determined!! The real Position is close to the "/map" tf (same offset as robot to "/odom" tf).

Here is my tf tree:

Accuracy of my odom data seem to bee right ...

---

Here is a link to a video showing the problem. Hopefully this helps to understand the problem which appears. It can be seen that no /odom /map problems appear as long as the robot moves to the front or backwards, but immediately when it starts to rotate, the mapping gets screwed up and "/map" and "/odom" differ.

https://www.dropbox.com/s/v4y6i7s5l0jhy7r/mapping.mpeg

Here is my gmapping.launch file:

  <param name="xmin" value="-5.0"/>
  <param name="ymin" value="-5.0"/>
  <param name="xmax" value="5.0"/>
  <param name="ymax" value="5.0"/>
  <param name="delta" value="0.05"/>
  <param name="llsamplerange" value="0.01"/>
  <param name="llsamplestep" value="0.01"/>
  <param name="lasamplerange" value="0.005"/>
  <param name="lasamplestep" value="0.005"/>
</node>

FYI, I do not face processing problems due to high update rates. I just want the map to be updated continuously. CPU load is at 60% when running all nodes.

Has anyone experienced some similar problems?

BR Daniel

---

Originally posted by dneuhold on ROS Answers with karma: 205 on 2014-01-09

Post score: 1

---

Original comments

Comment by Ben_S on 2014-01-09:
Is your laser scanner mounted in a somewhat unusual position? (Like facing backwards, seen from positive x of your base_link) What are your transforms from base_link to laser? Would it be possible to post your launch file(s) and maybe a small bag recording?

Comment by dneuhold on 2014-01-10:
Thanks for your hint, but the laser scanner is mounted correctly. Which launch file do you mean ... if it is an tf issue, I did not change anything there. The more I turn the robot the more "/map" and "/odom" differ.

Comment by Stefan Kohlbrecher on 2014-01-10:
Some difference between "map" and "odom" is expected (this is what SLAM approaches are supposed to correct). If there is a large discrepancy, this could mean that SLAM/localization is failing, or odometry is bad (or not well calibrated). Have you checked the accuracy of the odometry you´re getting?

Comment by dneuhold on 2014-01-10:
Thanks Stefan for you tip. Do you know another way how to get the accuracy of the odom data instead of having a look at the /odom topic (as I did in the picture above?). I do also think that my SLAM/localization is failing ... but I do not have any approach how to mitigate this.

Comment by Stefan Kohlbrecher on 2014-01-10:
Have a look at this question and related answers: http://answers.ros.org/question/9480/is-there-a-good-way-to-verify-my-odometry-data-is-sensible/#808

Comment by dneuhold on 2014-01-12:
Well it seems that my accuracy is quite ok. But even if there is a larger discrepancy, how to reconfigure the gyro on an turtlebot with kobuki base? So my suggestion is also that SLAM/ localization fails. Do you have any ideas how to configure it better?

Comment by Ben_S on 2014-01-14:
Thanks for the additional informations. Would it be possible to post a similar video while having the fixed frame set to /odom?

Answer 1

From the video the fault definitely looks like a SLAM issue. It appears as soon as just a flat wall is visible in the simulated LIDAR scan (with no corner, which previously served to make the match non-ambiguous) the scanmatcher provides wrong matches. I thought this really shouldn´t happen, as gmapping should rely on odometry in cases like this. There appears to be no parameter that allows you to tell the system "trust odometry more" directly, as this probably is easier thought of than done. Editing your original question and providing the config you use for gmapping might help people to make an educated guess on what parameters you could tweak, however.

---

Originally posted by Stefan Kohlbrecher with karma: 24361 on 2014-01-13

This answer was NOT ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by dneuhold on 2014-01-13:
I agree with you. This is what I already thought of. So does anyone have experience on the field of SLAM? Because that would really help to get the system running stable. The actual configuration is posted in my question above (gmapping.launch file).

I already thought of using gmapping without odometry data? Do you think this is worth to try?

Comment by Stefan Kohlbrecher on 2014-01-14:
Well it´s the odometry that would help with the problem (if gmapping would trust it more as opposed to following the wrong scanmatching), so it doesn´t appear to be a good idea to try to not use odometry. Can you increase the particle count? A particle count of 1 means there is just one pose and map estimate, which means this you´re not really using a particle filter.

Answer 2

You made some really large (and some even absurd) changes to some of the gmapping parameters, which may lead to the observed behaviour...

<param name="linearUpdate" value="0.01"/>
<param name="angularUpdate" value="0.01"/>
<param name="temporalUpdate" value="0.1"/>

These settings will force an update with almost every new scan and benefit the accumulation of even small errors in scan matching. This may be the main culprit and what makes your odometry mostly meaningless.

Try setting these parameters closer to the default like linear 0.2, angular 0.3 and especially temporal to something like 5-10 (or even -1 to turn it off completely).

<param name="particles" value="1"/>

Now regarding the "even absurd" part of your config. GMapping is a particle filter based SLAM approach. So it needs some particles with each representing one "guess" of the current position and traveled path. When setting particles to 1 you are in fact doing dead reckoning based on scan matching, odometry and even some (intentionally!) added noise. You should set particles to at least the default value of 30 or even better higher! (Whatever your CPU can support. We typically use between 50 and 80 particles.)

In general i would advise you to start of with the default GMapping config and change only those parameters you really need and even then not by a factor of over 30 to begin with...

---

Originally posted by Ben_S with karma: 2510 on 2014-01-14

This answer was NOT ACCEPTED on the original site

Post score: 3

---

Original comments

Comment by Stefan Kohlbrecher on 2014-01-14:
Good points, never used gmapping so the weird values didn´t catch my eye ..The "1" particle count did, though :)

Comment by dneuhold on 2014-01-15:
Well the reason for these "absurd" values is for the purpose of updating the map continuously. Particle values of 10 to 20 are rather ok but everything above slows the speed of map creation tremendously down. Which is not applicable for my application. Therefore I experimented with the parameters and figured out that there is absolutely no purpose for setting the particles value to a higher number. Localisation is performed wrong, also for a particle value of 100, update rates of 20 secs and temporalUpdate -1 (The rest is based on the default configuration for gmapping).

Is it possible that some other topics mess the localisation up? Following is started: turtlebot_bringup minimal.launch and turtlebot_navigation gmapping.launch

Answer 3

I found the reason for my localization error. Even if i increased my "particle" value to a number of 100, localization is still wrongly estimated. But if I decrease my resolution to 0.01 (e.g. 1 cm grid size), the localization works perfectly and the estimation error (occurs very rarely) is in the range of 2-4 cm.

So maybe that may help you ...

Here is my actual configuration:

<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="0.5"/>
<param name="maxUrange" value="16.0"/>
<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="0.01"/>
<param name="srt" value="0.02"/>
<param name="str" value="0.01"/>
<param name="stt" value="0.02"/>
<param name="linearUpdate" value="0.01"/>
<param name="angularUpdate" value="0.01"/>
<param name="temporalUpdate" value="-1.0"/>
<param name="resampleThreshold" value="0.5"/>
<param name="particles" value="10"/>

<param name="xmin" value="-4.0"/>
<param name="ymin" value="-4.0"/>
<param name="xmax" value="4.0"/>
<param name="ymax" value="4.0"/>

<param name="delta" value="0.01"/>
<param name="llsamplerange" value="0.01"/>
<param name="llsamplestep" value="0.01"/>
<param name="lasamplerange" value="0.005"/>
<param name="lasamplestep" value="0.005"/>
<remap from="scan" to="$(arg scan_topic)"/>
</node>

BR, Daniel

---

Originally posted by dneuhold with karma: 205 on 2014-01-19

This answer was ACCEPTED on the original site

Post score: 2