Laser Scan Matcher at low speeds

Question

Hi, I'm trying to use the laser scan matcher package in my mobile robot. So I've performed numerous simulations on gazebo and everything worked great.

Now i'm performing the first tests with the physical robot, and a problem occurred, at high speeds (linear or angular) i't gives very good results but when traveling at low speeds it tends to drift allot, is this a issue that is to be expected because of the signal to noise ratio at slow speeds or my parameters wrong (mostly default). The environment is a normal office with the particularity that two office cabinets don't reflect the laser but other than that it's standard and with plenty of features for the icp . Tomorrow I gonna perform tests in a more controlled environment (less cluttered) so I can rule that out. If anybody had or has a similiar problem please let me know.

Thanks

---

Originally posted by fmarques on ROS Answers with karma: 92 on 2012-04-01

Post score: 0

Answer 1

As the laser scanmatcher only matches the current scan with the preceding one, drift over time can't be avoided when using noisy sensor data (which always is the case in the real world). Depending on your needs you could use a SLAM system like gmapping and generate the needed odometry using laser scan matcher. /edit: See this question/answers for details.

Alternatively (shameless plug ahead) you can have a look at hector_mapping. Here, there is no need for odometry information and scans are matched against the existing map. For this reason, there is not drift when standing still.

---

Originally posted by Stefan Kohlbrecher with karma: 24361 on 2012-04-01

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by fmarques on 2012-04-10:
I'm using your stack and it's great but I've run into a problem, sometimes when performing in place rotation all the map turns with the robot. Is this because the scan doesn't have enough features????

Comment by Stefan Kohlbrecher on 2012-04-11:
If the scan indeed does not contain enough features, this explains the behavior. Can you make a screenshot? Also, which LIDAR are you using and how fast are you turning your robot around?

Comment by fmarques on 2012-04-11:
It happens when I turn fast, and not in the beginning of the rotation. This only happens when using no odometry information, when I replace gmapping it works fine. I'll try to take a screenshot. I didn't try it in the physical robot yet (gazebo only) , I try to test in the robot today(sick lms111Hz)

Comment by Yue on 2016-10-06:
@fmarques, I have a same problem with yours. I'm trying gmapping+laser_scan_matcher+turtlebot, the robot drifts away, even when I only let it rotate....Do you have some idea to this kind of issue?