Closed Tacoma closed 6 years ago
Hi @Tacoma thanks a lot for sharing your experience and these interesting results! I believe that can be very helpful for other people wanting to look into the region growing segmentation based on smoothness constraint. What did you use as a centroid_distance_threshold_m
for filtering the duplicates? https://github.com/ethz-asl/segmatch/blob/master/laser_mapper/launch/kitti/kitti_localization.yaml#L60
FYI maintenance of the target map and removal of these duplicates will be much more robust in the newer version of segmatch to be available soon.
I could not find the random forest with the shape descriptor on my machine (as we are not using it anymore). I will have a look asap to see if we have something in our backups. If you want you could think about designing a few simple descriptor for this tasks. I would imagine that information like length of the segment along the eigen vectors lying on the plane could help with the matching. Thanks again!
At the moment I'm using centroid_distance_threshold_m: 1.0
because some of the smaller features are rather close. But I might test larger values and see if the map gets better.
That sounds great, I understand that the map update was probably not the focus until now and am curious about the changes.
So I tested different values for the centroid_distance_threshold_m
and evaluated the transformation error for found loops. The results (figure) show that for small values a lot of wrong loops are found, like you already noticed. Then up to 2 meters, the results are constant with a slow decline. Visually most of the duplicates are removed from 1 meter onwards, higher values do not remove more. So I guess values between 1 and 2 are good for this kind of environment.
@Tacoma thank you for sharing this analysis! :-)
Hi, @Tacoma thanks very much for the sharing experience. May I ask do you use the raw point cloud (which is quite sparse) as the input, or do you use the densified point cloud? Thanks.
I accumulate one rotation and forward it to LaserSlam, so for SegMatch, the accumulated local map from LaserSlam is used. I'm not sure what you mean by densified point cloud. Looking at your issue, I also changed the accumulated_pointcloud_topic to the velodyneScan messages, but as I'm using the region growing, I can't comment on the other parameters.
@junzhang2016 fyi the following package can be helpful in order to accumulate the Velodyne point packets into a 360deg cloud by incorporating external odometry measurements: https://github.com/ethz-asl/laser_slam/tree/master/sensor_drivers/velodyne_assembler This is particularly relevant at high translational and rotational speeds.
Thank you, @Tacoma @rdube. I understood, the raw point cloud will be accumulated by laser_slam (especially, /laser_slam/tree/master/sensor_drivers/velodyne_assembler ), so that the input of segmatch will be the accumulated point cloud.
@junzhang2016 to be more precise. In the incremental version of segmatch the point cloud will be accumulated in a dynamic voxel grid. See: https://github.com/ethz-asl/segmap/blob/master/segmatch/include/segmatch/dynamic_voxel_grid.hpp
Hi everyone,
First of all, thanks for making the code available, I really liked the demonstrations and want to use SegMatch myself for indoor loop-closures. I already wrote some mails to @rdube, and got very helpful answers, thanks for the tips. Maybe someone else can benefit from my results, so I want to share where I got so far.
I am using simulated and real data from an VLP-16 and have disabled ICP, instead using the ground-truth trajectory (or cartographers trajectory for the real data) with some rotational drift. For the segmentation I have switched to the region-growing segmenter and changed some parameters. Although the segmentation is not yet perfect, I already have some good results as can be seen in the following:
As my dataset I use the corridor around a lecture hall, and its reconstructed mesh:
Here is one of the results
![loop_correct](https://user-images.githubusercontent.com/3283823/29776249-576a553e-8c08-11e7-858a-f29fb57cd68f.png)
So far I noticed that the repeating structures and symmetry is less of a problem than expected, because the segments are accumulated over a long time but consequently the overlapping trajectory must be large before the loop is detected. (The trajectory goes clockwise twice around the whole lecture hall, beginning slightly before the lower left corner)
The parameters for the region-growing segmenter itself work very well, however I had to change some other parameters to filter the pointcloud before segmenting to get good results:
minimum_point_number_per_voxel
to 2 or 3 andvoxel_size
to 0.08.distance_to_consider_fixed
anddistance_between_segmentations_m
to 20-30. It is important to keep the latter smaller or equal to the former, otherwise the filtering of cut segments at the border does not work and many incomplete duplicates are created.distance_between_segmentations_m
is too high, because large walls that are only scanned partially in the beginning will create many segments as they are observed over time. Setting the distance between segmentations to 0 helps to remove these duplicates although large walls still create multiple segments because they can not be completely observed or the simple map update can not match them.Even when the drift is completely disabled the resulting map still has some duplicates as can be seen here:![overlaying_segments](https://user-images.githubusercontent.com/3283823/29776592-5a0283b0-8c09-11e7-9d36-027b5f1a1bcf.png)
But still the resulting trajectory with loop-closures looks very nice and I hopefully can try to close some loops in different datasets. @rdube I would also like to try the shape descriptor if you still have the trained random forest and see, if loops can be found faster and with fewer segments with it.