TUMFTM/GMMCalib

More detailed guidance

Closed this issue · 7 comments

Recently, I've been focusing on the research of multi-radar calibration, according to your readme, the time-synchronized two lidar pcd file was placed in the data/sensor_1 and sensor_2 folder, but there are not right result out, The output is as follows. Maybe is there more detailed guidance?
`GMM Iteration: 93
GMM Iteration: 94
GMM Iteration: 95
GMM Iteration: 96
GMM Iteration: 97
GMM Iteration: 98
GMM Iteration: 99
Calibration Error:

[[ 9.99999101e-01 1.02013295e-03 8.70470902e-04 -2.00419349e-02]
[-1.02021259e-03 9.99999475e-01 9.10515112e-05 -6.24217816e-02]
[-8.70377561e-04 -9.19394947e-05 9.99999617e-01 1.67179780e-02]
[ 0.00000000e+00 0.00000000e+00 0.00000000e+00 1.00000000e+00]]`

Hi @sssolitude, the pcd files, currently in the folders, are real world ouster point clouds converted to pcd format. The resulting output that you posted is the calibration error between the two ouster sensors in the form of a homogeneous transform T. That's where this 4x4 matrix comes from.

are only ouster sensors supported? My sensor is livox.

It was tested on Ouster OS-1 and Innovusion Falcon Data and works for both. As long as you convert it to pcd, also livox should be fine.

Thanks for your reply. Is there a requirement for pcd quantity?

It is worth mentioning that calibration went error even if using the 3 pairs of sample pcds. Therefore I used 51 pcd files per sensor.

Thank you very much for the interest. As mentioned in the paper, GMMCalib becomes advantageous with a lot of data (in our case with a lot of LiDAR frames/pcd files). I used about 100 pcd files for the results shown there :) So there is no specific requirement. In my analysis with the Ouster LiDAR, the values converged at about 60 frames (to provide a ballpark figure), however, this depends on the sparsity of the point clouds.

A note was added to the README, to point out to use a higher number of frames. Thank you @sssolitude.