APRIL-ZJU / lidar_IMU_calib

[IROS 2020] Targetless Calibration of LiDAR-IMU System Based on Continuous-time Batch Estimation
GNU General Public License v3.0
927 stars 224 forks source link

Reference frame of generated IMU-centric spline trajectories #26

Closed alexmora-sr closed 3 years ago

alexmora-sr commented 3 years ago

Hello,

I have used li_calib to calibrate individual LiDAR-IMU pairs on my robotic platform successfully. However, the sensor configuration I work with features multiple LiDAR sensors (all of them VLP-16 models, compatible with the provided software implementation). I have developed a simple method to interpolate these trajectories at some given timestamps (for visualization and debugging purposes), and I have come across a doubt while doing that.

If we assume that we are using a system with two LiDARs, L1 and L2, and a common IMU, I1, we could generate two IMU-centric trajectories: one through the L1-I1 pair calibration, and another one through the L2-I1 calibration. Then, in li_calib's paper, at the end of section III - Trajectory Representation and Notation, below Equations 6 and 7, one can find the following claim: [...] As described in the above equations, we set the first IMU frame{I0} as the reference frame for the IMU trajectory, [...] Thus, I would expect that, given the same set of IMU data (from I1), both LiDAR-IMU trajectories should share a common origin / reference frame. Furthermore, were the LiDAR-IMU calibrations an exact representation of the physical system, the two trajectories would overlap on top of each other.

xyz_trajectories rpy_trajectories These plots have been generated using evo (https://github.com/MichaelGrupp/evo)

However, as you can see in the images above, the origin pose of the trajectories produced by the L1-I1 and L2-I1 is not the same. The fact that the trajectories' shape does not coincide is (at least partially) explained by the fact that the L2-I1 calibration in this run was not accurate.

Could you please help me understand if my assumptions are correct? In case they are not, how can I indicate to the TrajectoryEstimator that there is a common sensor (in this case, I1) to constrain the trajectory estimation?

Thank you for your time.