# Fast Lidar Inertial Odometry and Mapping for Mobile Robot SE(2) Navigation
## 3 Methodology
### Point-Cloud De-Skewing
\begin{table}
\begin{tabular}{c c c c c c} \hline
**Dataset** & **Method** & **Max** & **Mean** & **Rmse** & **Std** \\ \hline \multirow{4}{*}{_Garden_} & FLOAM & 4.00 & 1.96 & 2.20 & 0.99 \\  & LeGO-LOAM & 0.60 & 0.24 & 0.26 & 0.10 \\  & LIO-SAM & 0.66 & 0.29 & 0.31 & 0.10 \\  & LIO-SAM\_FixZ & 0.61 & 0.27 & 0.29 & 0.10 \\ \hline \multirow{4}{*}{_Bumpy_} & FLOAM & 12.3 & 1.85 & 2.73 & 2.01 \\  & LeGO-LOAM & 0.62 & 0.25 & 0.28 & 0.13 \\  & LIO-SAM & 0.45 & 0.13 & 0.16 & 0.09 \\  & LIO-SAM\_FixZ & 0.27 & 0.13 & 0.15 & 0.08 \\ \hline \multirow{4}{*}{_Park_} & FLOAM & 47.95 & 25.25 & 28.51 & 13.26 \\  & LeGO-LOAM & 1.25 & 0.25 & 0.30 & 0.17 \\ \cline{1-1}  & LIO-SAM & 0.51 & 0.21 & 0.23 & 0.10 \\ \cline{1-1}  & LIO-SAM\_FixZ & 0.59 & 0.26 & 0.29 & 0.12 \\ \hline \end{tabular}
\end{table} 
Table 1: Results of absolute trajectory error. Figure 3: Trajectories built by different methods on the _Garden_, _Bumpy_, and public _Park_ datasets. For LIO-SAM_FixZ, we set the z axis of LIO-SAM to a fixed value. Recall rate and precision are two fundamental indicators for evaluating loop detection. For low-power embedded systems, we quantitatively analyzed the conditions required to trigger loop closure. The results were compared with existing place recognition algorithms generally applied in SLAM, such as SC [35] and ISC [36]. Table 3 lists the results. Compared to SC and ISC, our method only required hundreds of point clouds instead of tens of thousands to achieve highly competitive precision across all three datasets. The number of loops implied the high performance of the method for place recognition, even for challenging scenes, such as forward or reverse visits. More importantly, the smaller the number of point clouds required, the fewer memory resources are required; this can significantly relieve the load on the computation and memory of embedded devices in practice. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Parameter** & **Brief** & **Threshold** \\ \hline \(L_{max}\) & Maximum sensing range (m) & 70 \\ \(N_{s}\) & Number of sectors & 60 \\ \(N_{r}\) & Number of rings & 20 \\ \(\rho_{\tau}\) & Smoothness matching threshold & 0.3 \\ \(\rho_{c}\) & Smoothness threshold & 0.1 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Parameters related to the smoothness scan context. Figure 4: Loop closure based on our method, (**a**) Loop closure results for _Garden_, (**b**) Loop closure results for _Bumpy_, (**c**) Loop closure results for the public _Park_ dataset. The red dots represent keyframe nodes, and the solid black line connecting the two red dots represents the loop closure constraint detected by the system. We can see that the loop closure was successfully triggered when the robot moved a long distance and revisited the scenes that it had passed. ### Real-Time Performance

In the above experiments, we demonstrated that our method could achieve an accuracy in terms of pose estimation and loop closure that was competitive in relation to advanced methods. Next, we prove that the method proposed in this paper has more powerful advantages from a real-time perspective. As one of the most time-consuming core components in the system, the scan-matching module constructs local map constraints and solves keyframe poses via optimization methods. We ran different datasets to compare the run-time of the scan-matching modules in FLOAM, LeGO-LOAM, LIO-SAM, LIO-SAM_FixZ, and our method. The results for the time consumed by the four different scenarios are shown in Figure 5, where the data represent the run-times of the scan-matching modules and thus serve as a quantitative metric to compare and analyze the processes. It can be seen that in the more complex scenario _Bumpy_, the single optimization time of some methods reached the second level. Table 4 quantitatively shows the average run-times of the scan-matching modules. If we intuitively analyze the data in Table 4, then the optimization speed of FLOAM is undoubtedly the fastest.