Too few neccessary correspondences

[hunkyu]

I used my own vlp16 pcd data and found it prompted Too few neccessary correspondences

[hunkyu]

Seeing that there are too many parameters, what parameters need to be adjusted?

vlp16 dataset.zip

[YuePanEdward]

Thanks for your feedback. It seems that there might be some problem with the feature points in the local map since the correspondence found for pillar and beam points are 0. I used the run_mills_reg.sh to test the pairwise registration of the two frames you provided (2451.pcd & 2452.pcd). The results are shown below:

Feature points extracted from target (2451.pcd) and source (2452.pcd) point cloud

Point cloud pair before and after the registration

with the following parameter setting:

--pca_neighbor_radius=1.2 \
--pca_neighbor_count=30 \
--gf_grid_size=2.0 \
--gf_in_grid_h_thre=0.25 \
--gf_neigh_grid_h_thre=1.2 \
--gf_ground_down_rate=8 \
--gf_nonground_down_rate=2 \
--linearity_thre=0.62 \
--planarity_thre=0.65 \
--curvature_thre=0.08 \

Maybe you can send me the data of more frames or the screenshoot of the feature viewer [Press F10] so that I can analyze the issue better.

[hunkyu]

OK, I send a complete packet https://drive.google.com/file/d/17yZCU8GtMpxWT_ZPLVYtuQcIrOVtHSWi/view?usp=sharing

[hunkyu]

test_data.zip

[YuePanEdward]

Thanks for your feedback and data. But unfortunately, MULLS cannot fit your data well at the moment due to the following reason:

1. The motion compensation is not accomplished because the point-wise timestamp is not provided. The point-wise timestamp can be calculated from the scan-line index and azimuth according to VLP16's specification (it is not involved in the codes right now). If the vehicle is moving fast and the registration algorithm is based on rigid transformation, the map just mess up with motion compensation.

2. The LiDAR is mounted very close to the ground and half the horizontal field of view (FoV) is blocked. I suppose it is mounted on the front hood of the vehicle. The limited FoV may lead to the loss of accuracy for the registration.

3. The vehicle is moving a bit too fast (>3m, >30 degree for 1 frame[0.1s] in some case). It will cause the failure of registration especially when the motion compensation is not done. Besides, one drawback of MULLS is that it is based on tiny rotation assumption. Though it works since the rotation estimated from the last iteration of ICP is generally small, its converge domain would be narrower than classical ICP.

Here's some example of the map built by MULLS using your data. The drift is quite large compared to the performance on KITTI and FORD. The drift on Z axis is still presented.

You may consider rename the filenames from something like 1.pcd to 00001.pcd so that they can be fed into the programme in the correct order. You can use batch_rename.sh.

For the parameter setting. For your dataset, consider to set:

#enable the scan-to-scan reg. before scan-to-map reg.
--scan_to_scan_module_on=true  
#increase the correspondence distance threshold 
--corr_dis_thre_init=4.0
--corr_dis_thre_min=1.0
#disable residual weighting because the residual would be quite large even with a good alignment when motion compensation is not done.
--corr_weight_strategy=1001

I will try to calculate the point-wise timestamp for VLP16 and apply motion compensation based on uniform motion. However, to make your life easier, it's better to try other L-SLAM algorithms for your dataset.

[hunkyu]

Thank you very much. I know what caused it. Because my current data set is also caused by key frame data, the distance between frames is relatively large. Usually, the wheel speed odometer provides motion prediction to have a better effect.