there are 3 problem that are confirmed in my tests about hectorslam:
1, the corridor problem：hector slam think the robot is not moving when laser scan datas are almost the same at long corridor . This problem is stated clearly on ros answers, and because hector slam is not using odometer (exclude roll & pitch), the problem can not be solved
2, the quake problem: hector slam suffers when robot is during a body shake(probably when overcome an obstacle or uneven surface), it has a great possibility to messup the map(drift in yaw, the map direction is then changed) and can't recover since then. roll pitch data are introduced to solve this problem, it improves but not solved. drift happens sometimes; maybe there is some thing wrong with my system setting: imu update at 200hz, while imu_attitude_to_tf_node run at 10hz
3, the "angle too large" problem: hector slam raise "angle too large" warning when robot turns too much in a short time. however , the warning itself is unstable, I took some tests to determined how large angle will result in this, but got no pattern. and eveytime after this warning , the map drifts.
here are my answers for now:
1, the corridor problem is always a tricky area in laser slam, to solve this, a simple way is to replace your laser with a long range laser; a complex way is to witch using odometer in corridor, or confuse visual data;
2&3, because teamHector develop hector slam in a USAR environment, so the robot should better move as slow as their proto robot, I slow down my robot, all the two problems disappear.
any help will be appreciated
Post score: 2
Comment by Francis Dom on 2017-05-29:
Are you using the Hector slam in a ground robot or UAV