The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Hello again,
to my knowledge the hector devs use 40hz long range high precision lidars, so you might indeed need to change a couple of things. Since they actually have 8 callbacks where you have one i'd change the max searchdir of 0.2 to something higher (maybe to 0.2*8) in lines 209 to 215 of https://github.com/tu-darmstadt-ros-pkg/hector_slam/blob/master/hector_mapping/include/hector_slam_lib/matcher/ScanMatcher.h You can also increase the number of iterations, however this will most likely not help because if it gets stuck in a local minima, well, its stuck.
Also I guess that the lidar on your vacuum cleaner is not that precise, so you might have to live with imperfect results. If increaseng the searchdir limit doesn't yield acceptable results you could try gmapping which uses a particle filter which can deal better with the problem you are facing than a "simple" scanmatcher. Additionally, once you have a good map (gained for example by not doing sharp turns), you could also just localize your robot without mapping, since your map will be mostly static. To do so you can either use amcl, or see if hector slam can work with given maps. around half a year ago that was not possible, but maybe someone added that feature. if not you can of course also do so yourself, the hector slam code is well written and understandable.
| | 2 | No.2 Revision |
Hello again,
to my knowledge the hector devs use 40hz long range high precision lidars, so you might indeed need to change a couple of things. Since they actually have 8 callbacks where you have one i'd change the max searchdir of 0.2 to something higher (maybe to 0.2*8) in lines 209 to 215 of https://github.com/tu-darmstadt-ros-pkg/hector_slam/blob/master/hector_mapping/include/hector_slam_lib/matcher/ScanMatcher.h You can also increase the number of iterations, however this will most likely not help because if it gets stuck in a local minima, well, its stuck.
Also I guess that the lidar on your vacuum cleaner is not that precise, so you might have to live with imperfect results. If increaseng the searchdir limit doesn't yield acceptable results you could try gmapping which uses a particle filter which can deal better with the problem you are facing than a "simple" scanmatcher. Additionally, once you have a good map (gained for example by not doing sharp turns), you could also just localize your robot without mapping, since your map will be mostly static. To do so you can either use amcl, or see if hector slam can work with given maps. around half a year ago that was not possible, but maybe someone added that feature. if not you can of course also do so yourself, the hector slam code is well written and understandable.
@appendix1: well, seeing that you have a 360deg lidar i wouldn't decrease the threshold for the angular map update trigger ;). On the contrary, my intuition would be that turning shouldn't trigger updating the map at all shrug. That decreasing the map resolution on the other hand helps is intuitive since it sort of reduces the impact of noisy readings. You could try increasing the number maps used in parallel, i.e. increase 2 in
<param name="map_multi_res_levels" value="2" />
what this does is performing the registration on courser grained maps in parallel to your original map resolution. The purpose is preventing to get stuck in local minimas, which is whats happening in your case.
| | 3 | No.3 Revision |
Hello again,
to my knowledge the hector devs use 40hz long range high precision lidars, so you might indeed need to change a couple of things. Since they actually have 8 callbacks where you have one i'd change the max searchdir of 0.2 to something higher (maybe to 0.2*8) in lines 209 to 215 of https://github.com/tu-darmstadt-ros-pkg/hector_slam/blob/master/hector_mapping/include/hector_slam_lib/matcher/ScanMatcher.h You can also increase the number of iterations, however this will most likely not help because if it gets stuck in a local minima, well, its stuck.
Also I guess that the lidar on your vacuum cleaner is not that precise, so you might have to live with imperfect results. If increaseng the searchdir limit doesn't yield acceptable results you could try gmapping which uses a particle filter which can deal better with the problem you are facing than a "simple" scanmatcher. Additionally, once you have a good map (gained for example by not doing sharp turns), you could also just localize your robot without mapping, since your map will be mostly static. To do so you can either use amcl, or see if hector slam can work with given maps. around half a year ago that was not possible, but maybe someone added that feature. if not you can of course also do so yourself, the hector slam code is well written and understandable.
@appendix1:
well, seeing that you have a 360deg lidar i wouldn't decrease the threshold for the angular map update trigger ;). On the contrary, my intuition would be that turning shouldn't trigger updating the map at all shrug. all.
That decreasing the map resolution on the other hand helps is intuitive since it sort of reduces the impact of noisy readings.
You could try increasing the number maps used in parallel, i.e. increase 2 in
<param name="map_multi_res_levels" value="2" />
what this does is performing the registration on courser grained maps in parallel to your original map resolution. The purpose is preventing to get stuck in local minimas, which is whats happening in your case.
| | 4 | No.4 Revision |
Hello again,
to my knowledge the hector devs use 40hz long range high precision lidars, so you might indeed need to change a couple of things. Since they actually have 8 callbacks where you have one i'd change the max searchdir of 0.2 to something higher (maybe to 0.2*8) in lines 209 to 215 of https://github.com/tu-darmstadt-ros-pkg/hector_slam/blob/master/hector_mapping/include/hector_slam_lib/matcher/ScanMatcher.h You can also increase the number of iterations, however this will most likely not help because if it gets stuck in a local minima, well, its stuck.
Also I guess that the lidar on your vacuum cleaner is not that precise, so you might have to live with imperfect results. If increaseng the searchdir limit doesn't yield acceptable results you could try gmapping which uses a particle filter which can deal better with the problem you are facing than a "simple" scanmatcher. Additionally, once you have a good map (gained for example by not doing sharp turns), you could also just localize your robot without mapping, since your map will be mostly static. To do so you can either use amcl, or see if hector slam can work with given maps. around half a year ago that was not possible, but maybe someone added that feature. if not you can of course also do so yourself, the hector slam code is well written and understandable.
@appendix1: well, seeing that you have a 360deg lidar i wouldn't decrease the threshold for the angular map update trigger ;). On the contrary, my intuition would be that turning shouldn't trigger updating the map at all. That decreasing the map resolution on the other hand helps is intuitive since it sort of reduces the impact of noisy readings. You could try increasing the number maps used in parallel, i.e. increase 2 in
<param name="map_multi_res_levels" value="2" />
what this does is performing the registration on courser grained maps in parallel to your original map resolution. The purpose is preventing to get stuck in local minimas, which is whats happening in your case.
@appendix2: Hmm, I never used hector slam with quick rotations, so I don't know from experience how well it can cope with those. Concerning "gmapping requires tf": I think you got your vocabulary wrong :). Tf stands from transform, and in ros this refers to a description/link between frames. Thus you don't just need tf for gmapping but also for hector slam. you should already have something like world/map->odom->base_footprint->base_stabilized->base_link->laser_link. What you do "need" for gmapping is odometry, which is /rpm i guess? Even if not, you can use a scanmatcher in place of wheel odometry.
@comments: The issue with higher (integer) values for multi_res_level making no map appear is pretty weird. Have no clue what that is about. You did just set it to 3/4/5 and didn't go all-out here right? It's a shame though because my guess is that a higher number here would have allowed you to maintain a reasonable minimum resolution. Did you take what I previously said about the rotation threshold into consideration? Also, as stefan more or less suggested, try limiting the distance the robot is allowed to move per iteration, by doing something similar like they do with the angle, but with the distance travelled.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.