panda's profile - activity

thanks, so I should build the map with hectorslam, and put the map into AMCL for localization, right?

is there any way to load a saved map in hector slam and locate init position? similar question on ros answers is 3 year ago, and I want to know is there any progress.

this feature may need loop closure, which hector slam didn't support for now. so I don't know how to do next

any help?

by the way , does gmapping support load map and find init position?

thank you a lot, I have tuned the params, and figure out the robot should turn slowly when building map in few feature environment. could you give me any idea about loop closure in hector slam?

your question is about hectorslam,not gmapping. rplidar has a default launch file with hectorslam that can run without any configuration, it locate at here

download it it your catkin_ws/src , and put hectorslam sourcefiles there too.

catkin_make
roslaunch rplidar view_slam.launch

that would probably works.

about ROS :just follow the Tutorials at wiki.ros.org

about SLAM : if you are doing laser 2D slam, you need to learn how to using gmapping and hectorslam. just search it on ros. they were two best laser slam algorithm.

in addition,gmapping needs odometer(motor encoder data and IMU),while hectorslam not. it's better for you to improve your own code on the base of gmapping or hectorslam.

recently SLAM research are mostly in visual slam field and 3D laser slam.

for 3D laser slam, you can find it on youtube. it's similar to 2D laser slam. for Vslam, there is a lot new things to learn. mostly computer vision related. popular direction includes: RGBD slam (with kinect depth data), stereo slam, Monocular slam.

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.

EDIT:

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

check more info here and add the code below to your launch file

<node pkg="tf" type="static_transform_publisher" name="link1_broadcaster" args="1 0 0 0 0 0 base_link laser 100"/>

notice the args

hector_mapping\launch\mapping_default.launch you can look into the src code to understand all the param meaning