A GNSS/INS/LiDAR Integration Scheme for UAV-Based Navigation in GNSS-Challenging Environments

Unmanned aerial vehicle (UAV) navigation has recently been the focus of many studies. The most challenging aspect of UAV navigation is maintaining accurate and reliable pose estimation. In outdoor environments, global navigation satellite systems (GNSS) are typically used for UAV localization. However, relying solely on GNSS might pose safety risks in the event of receiver malfunction or antenna installation error. In this research, an unmanned aerial system (UAS) employing the Applanix APX15 GNSS/IMU board, a Velodyne Puck LiDAR sensor, and a Sony a7R II high-resolution camera was used to collect data for the purpose of developing a multi-sensor integration system. Unfortunately, due to a malfunctioning GNSS antenna, there were numerous prolonged GNSS signal outages. As a result, the GNSS/INS processing failed after obtaining an error that exceeded 25 km. To resolve this issue and to recover the precise trajectory of the UAV, a GNSS/INS/LiDAR integrated navigation system was developed. The LiDAR data were first processed using the optimized LOAM SLAM algorithm, which yielded the position and orientation estimates. Pix4D Mapper software was then used to process the camera images in the presence of ground control points (GCPs), which resulted in the precise camera positions and orientations that served as ground truth. All sensor data were timestamped by GPS, and all datasets were sampled at 10 Hz to match those of the LiDAR scans. Two case studies were considered, namely complete GNSS outage and assistance from GNSS PPP solution. In comparison to the complete GNSS outage, the results for the second case study were significantly improved. The improvement is described in terms of RMSE reductions of approximately 51% and 78% for the horizontal and vertical directions, respectively. Additionally, the RMSE of the roll and yaw angles was reduced by 13% and 30%, respectively. However, the RMSE of the pitch angle was increased by about 13%.


Introduction
In unmanned air vehicle (UAV) navigation, the main challenge is to maintain accurate and robust estimation of the UAV position and orientation. Typically, global navigation satellite systems (GNSS) are used for UAV localization in outdoor environments. However, GNSS signals may suffer from degradation or outages due to a signal blockage or a malfunction, which leads to a vulnerable system if it relies exclusively on GNSS. Therefore, the navigation system must possess redundancy to ensure reliability and availability. This emphasizes the need for multi-sensor integration to achieve reliable autonomous navigation [1][2][3]. In addition, recent developments in sensor technology have increased the payload capabilities of UAVs to include multiple sensors, such as cameras and light detection and ranging (LiDAR). An inertial navigation system (INS) uses an inertial measurement unit (IMU) to measure the rotation rate and acceleration, which are used to obtain the UAV pose (i.e., LiDAR sensor (previously VLP-16), a Sony α7R II camera, and the Applanix APX-15 UAV GNSS/INS. The system implements a loosely-coupled integration that takes advantage of the LiDAR SLAM solution (latitude, longitude, altitude, pitch, roll, and yaw) to update the INS solution in a closed-error loop scheme using an EKF. The remainder of this paper is organized as follows: Section 2 presents the UAV data collection platform, data acquisition, and data preprocessing. The system architecture and models are explained in Section 3. Section 4 discusses the experimental results, and finally conclusions are presented in Section 5.

Data Acquisition
In this study, a UAV was used as the platform for data acquisition. The UAV consisted of a DJI Matrice 600 Pro carrying a Sony α7R II RGB camera, a Velodyne PUCK LiDAR sensor, and the Applanix APX-15 UAV GNSS/INS board. Figure 1 shows the system components and how the various sensors are rigidly fixed within the UAV platform. The Sony α7R II camera has a 42.4 MP spatial resolution with a 7952 × 5304 image size [34]. The images were acquired based on distance, rather than time interval, with an average frame rate of 0.5 Hz, and the number of captured images was 110 images. The Velodyne PUCK, on the other hand, consists of 16 laser beams with a 360 • horizontal field of view (FOV) and a 30 • vertical field of view. The PUCK maximum range measurement is 100 m with a 3 cm range accuracy [35]. The total number of acquired points was approximately 14 million points at a 10 Hz frame rate. The Applanix APX-15 UAV GNSS/INS unit was used in this study due to its low weight, compact size, and precise positioning and orientation information [36]. The GNSS data was collected at a 10 Hz, while the IMU data was collected at a 200 Hz frame rate. In order to cover the area of interest, the flight was performed at approximately 25 m above the ground, acquiring the data in 5 parallel flight lines. Figure 2 shows a top view of the flight trajectory over the area of interest. literature LiDAR SLAM algorithms. A similar approach to the one adopted in [33] will be used in this current study, albeit for an UAV navigation. In this study, an integrated UAV-based GNSS/INS/LiDAR SLAM navigation system is developed. The proposed approach is developed to overcome frequent and prolonged GNSS outages resulting from an unexpected antenna malfunction during data collection. The data has been collected using a DJI Matrice-600 UAV equipped with the Velodyne PUCK LiDAR sensor (previously VLP-16), a Sony α7R II camera, and the Applanix APX-15 UAV GNSS/INS. The system implements a loosely-coupled integration that takes advantage of the LiDAR SLAM solution (latitude, longitude, altitude, pitch, roll, and yaw) to update the INS solution in a closed-error loop scheme using an EKF. The remainder of this paper is organized as follows: Section 2 presents the UAV data collection platform, data acquisition, and data preprocessing. The system architecture and models are explained in Section 3. Section 4 discusses the experimental results, and finally conclusions are presented in Section 5.

Data Acquisition
In this study, a UAV was used as the platform for data acquisition. The UAV consisted of a DJI Matrice 600 Pro carrying a Sony α7R II RGB camera, a Velodyne PUCK LiDAR sensor, and the Applanix APX-15 UAV GNSS/INS board. Figure 1 shows the system components and how the various sensors are rigidly fixed within the UAV platform. The Sony α7R II camera has a 42.4 MP spatial resolution with a 7952 × 5304 image size [34]. The images were acquired based on distance, rather than time interval, with an average frame rate of 0.5 Hz, and the number of captured images was 110 images. The Velodyne PUCK, on the other hand, consists of 16 laser beams with a 360° horizontal field of view (FOV) and a 30° vertical field of view. The PUCK maximum range measurement is 100 m with a 3 cm range accuracy [35]. The total number of acquired points was approximately 14 million points at a 10 Hz frame rate. The Applanix APX-15 UAV GNSS/INS unit was used in this study due to its low weight, compact size, and precise positioning and orientation information [36]. The GNSS data was collected at a 10 Hz, while the IMU data was collected at a 200 Hz frame rate. In order to cover the area of interest, the flight was performed at approximately 25 m above the ground, acquiring the data in 5 parallel flight lines. Figure 2 shows a top view of the flight trajectory over the area of interest.

Data Preprocessing
Applanix POSPac UAV software [37] was used to process the collected GNSS/IMU data in differential mode to obtain the precise drone trajectory. Unfortunately, the software crashed after obtaining an error that exceeded 25 km. Investigating the reason revealed the fact that there were numerous prolonged GNSS signal outages due to a

Data Preprocessing
Applanix POSPac UAV software [37] was used to process the collected GNSS/IMU data in differential mode to obtain the precise drone trajectory. Unfortunately, the software crashed after obtaining an error that exceeded 25 km. Investigating the reason revealed the fact that there were numerous prolonged GNSS signal outages due to a malfunction, as shown in Figure 3. The software estimation filter could not handle the large drift of low-cost IMU. An attempt was made to process the GNSS-only data in differential mode, which also failed. The GNSS data was then processed in precise point positioning (PPP) mode using the Canadian Spatial Reference System PPP (CSRS-PPP) service by Natural Resources Canada (NRCan) [38], which was successful, but the obtained results were at dm-m level accuracy with many gaps. The PPP results indicated that the drone altitude was not uniform (with variation in the range of 5 m), which might have been caused by a mass imbalance in the UAS. Partial or complete reset of the ambiguity parameters were performed frequently, which indicates that the PPP results were essentially code-based, i.e., with degraded accuracy.

Data Preprocessing
Applanix POSPac UAV software [37] was used to process the collected GNSS/IMU data in differential mode to obtain the precise drone trajectory. Unfortunately, the software crashed after obtaining an error that exceeded 25 km. Investigating the reason revealed the fact that there were numerous prolonged GNSS signal outages due to a malfunction, as shown in Figure 3. The software estimation filter could not handle the large drift of low-cost IMU. An attempt was made to process the GNSS-only data in differential mode, which also failed. The GNSS data was then processed in precise point positioning (PPP) mode using the Canadian Spatial Reference System PPP (CSRS-PPP) service by Natural Resources Canada (NRCan) [38], which was successful, but the obtained results were at dm-m level accuracy with many gaps. The PPP results indicated that the drone altitude was not uniform (with variation in the range of 5 m), which might have been caused by a mass imbalance in the UAS. Partial or complete reset of the ambiguity parameters were performed frequently, which indicates that the PPP results were essentially code-based, i.e., with degraded accuracy.  As a result of POSPac crash and the unavailability of precise GNSS/INS solution, the camera images had to be processed using ground control points (GCPs) to enable a precise UAV trajectory, which can then serve as ground truth. Twelve checkerboard targets were deployed at the study site, as shown in Figure 4, The precise coordinates (centimeter-level) of the targets were determined using a dual-frequency SOKKIA GCX2 GPS receiver in the real-time kinematic (RTK) mode. The RGB images were processed with the four corner GCPs (green boxes) using Pix4D mapper software [39] to estimate the camera poses. The other eight points (blue boxes) were used as check points. Figure 5 shows the estimated poses of the camera using the Pix4D mapper software. Table 1 shows the absolute camera position and orientation error statistics. deployed at the study site, as shown in Figure 4, The precise coordinates (centimeter-level) of the targets were determined using a dual-frequency SOKKIA GCX2 GPS receiver in the real-time kinematic (RTK) mode. The RGB images were processed with the four corner GCPs (green boxes) using Pix4D mapper software [39] to estimate the camera poses. The other eight points (blue boxes) were used as check points. Figure 5 shows the estimated poses of the camera using the Pix4D mapper software. Table 1 shows the absolute camera position and orientation error statistics.   Finally, the LiDAR data were processed using the optimized LOAM SLAM algorithm based on LOAM [23,27]. optimized LOAM SLAM was adopted over GraphSLAM algorithms, as the latter are generally more computationally expensive, such that they of the targets were determined using a dual-frequency SOKKIA GCX2 GPS receiver in the real-time kinematic (RTK) mode. The RGB images were processed with the four corner GCPs (green boxes) using Pix4D mapper software [39] to estimate the camera poses. The other eight points (blue boxes) were used as check points. Figure 5 shows the estimated poses of the camera using the Pix4D mapper software. Table 1 shows the absolute camera position and orientation error statistics.   Finally, the LiDAR data were processed using the optimized LOAM SLAM algorithm based on LOAM [23,27]. optimized LOAM SLAM was adopted over GraphSLAM algorithms, as the latter are generally more computationally expensive, such that they Finally, the LiDAR data were processed using the optimized LOAM SLAM algorithm based on LOAM [23,27]. optimized LOAM SLAM was adopted over GraphSLAM algorithms, as the latter are generally more computationally expensive, such that they consider all pose estimates in the calculation process. By contrast, EKF-based SLAM methods consider the last pose only [40].
The improved LOAM SLAM consists of three sequentially performed steps: key point extraction, LiDAR odometry, and LiDAR mapping. In the first stage, the critical points are categorized based on their curvature as either edges or planar points. Planar points correlate to the smallest curvature, whereas edge points correspond to the highest curvature. In the LiDAR odometry stage, a modified version of the iterative closest point matching algorithm is employed to reconstruct the LiDAR motion between two consecutive frames. Depending on the feature type, the distance between a point and a line or a point and a plane can be calculated. Finally, the recovered motion is refined by projecting the current frame onto the existing map and comparing it to it. More details about the LOAM SLAM can be found in [23].
Optimized LOAM SLAM is an enhanced variant of LOAM. The execution time is shortened due to the utilization of C++ libraries and tools optimized for improved computational speed. In addition, the method is not dependent on hard-coded parameters and can be run on either robot operating system (ROS) or LiDARView software. In addition, it is more generalized so that it operates on multiple LiDAR sensors, including Velodyne sensors. However, it is essential to highlight that optimized LOAM SLAM neither currently conducts loop closure nor it incorporates IMU measurements in the scan matching of successive frames. In this research, the optimized LOAM SLAM algorithm was executed on ROS. Two Python nodes (pc saver and traj saver) were created to subscribe to the trajectory and point cloud topics and preserve their respective outputs. Figures 6 and 7 [41] show the LiDAR SLAM trajectory and the generated point cloud, respectively. about the LOAM SLAM can be found in [23].
Optimized LOAM SLAM is an enhanced variant of LOAM. The execution time is shortened due to the utilization of C++ libraries and tools optimized for improved computational speed. In addition, the method is not dependent on hard-coded parameters and can be run on either robot operating system (ROS) or LiDARView software. In addition, it is more generalized so that it operates on multiple LiDAR sensors, including Velodyne sensors. However, it is essential to highlight that optimized LOAM SLAM neither currently conducts loop closure nor it incorporates IMU measurements in the scan matching of successive frames. In this research, the optimized LOAM SLAM algorithm was executed on ROS. Two Python nodes (pc saver and traj saver) were created to subscribe to the trajectory and point cloud topics and preserve their respective outputs. Figures 6 and 7 [41] show the LiDAR SLAM trajectory and the generated point cloud, respectively. Figure 6. LiDAR SLAM trajectory generated using optimized LOAM SLAM algorithm [41]. Figure 6. LiDAR SLAM trajectory generated using optimized LOAM SLAM algorithm [41].
about the LOAM SLAM can be found in [23].
Optimized LOAM SLAM is an enhanced variant of LOAM. The execution time is shortened due to the utilization of C++ libraries and tools optimized for improved computational speed. In addition, the method is not dependent on hard-coded parameters and can be run on either robot operating system (ROS) or LiDARView software. In addition, it is more generalized so that it operates on multiple LiDAR sensors, including Velodyne sensors. However, it is essential to highlight that optimized LOAM SLAM neither currently conducts loop closure nor it incorporates IMU measurements in the scan matching of successive frames. In this research, the optimized LOAM SLAM algorithm was executed on ROS. Two Python nodes (pc saver and traj saver) were created to subscribe to the trajectory and point cloud topics and preserve their respective outputs. Figures 6 and 7 [41] show the LiDAR SLAM trajectory and the generated point cloud, respectively.

Data Synchronization
All collected data were synchronized through GPS time stamp and resampled to 10 Hz to ensure correct data correspondence which is essential for subsequent processing stages. As such, the IMU data were downsampled from 200 Hz to 10 Hz for the raw accelerometers and gyroscopes measurements. Conversely, the camera pose estimations produced by Pix4D Mapper were up-sampled from approximately 0.5 Hz to 10 Hz. The resampling was accomplished using linear interpolation.
Subsequently, coordinates transformation was performed to have all pose estimation in the same reference frame. The position and rotation transformations were executed using a homogenous transformation using 4 × 4 transformation matrices, which is computationally efficient. The LiDAR pose estimates were transformed from the local frame of the first point cloud of the Velodyne sensor stream into the WGS84 reference frame. Figure 8 depicts a graphical illustration of the sequence of transformations.
resampling was accomplished using linear interpolation.
Subsequently, coordinates transformation was performed to have all pose estimation in the same reference frame. The position and rotation transformations were executed using a homogenous transformation using 4 × 4 transformation matrices, which is computationally efficient. The LiDAR pose estimates were transformed from the local frame of the first point cloud of the Velodyne sensor stream into the WGS84 reference frame. Figure 8 depicts a graphical illustration of the sequence of transformations. Let denotes a point captured in the local frame of the LiDAR and let denotes the same point expressed in the WGS84 reference frame. The sequence of homogenous transformations is presented by Equations (1) and (2).
is the homogenous transformation matrix from the l-frame to the WGS84 frame, ( / ) is the homogenous transformation matrix from the b-frame to the l-frame, ( / ) is the homogenous transformation matrix from the LiDAR frame to the b-frame, is the rotation matrix from the LiDAR frame to the l-frame, and is the rotation matrix from the LiDAR frame to the b-frame.

System Architecture and Mathematical Models
A loosely coupled integration between the INS and the LiDAR SLAM is implemented using an EKF, which results in an integrated navigation solution. As shown in Figure 9, the raw IMU measurements are fed into a full IMU mechanization, which produces the position, velocity, and attitude angles of the inertial navigation system. The LiDAR scans are used as input to the optimized LOAM SLAM algorithm, which results in the position Let P Li denotes a point captured in the local frame of the LiDAR and let P ece f denotes the same point expressed in the WGS84 reference frame. The sequence of homogenous transformations is presented by Equations (1) and (2).
where (R/t) ece f l is the homogenous transformation matrix from the l-frame to the WGS84 frame, (R/t) l b is the homogenous transformation matrix from the b-frame to the l-frame, Li is the homogenous transformation matrix from the LiDAR frame to the b-frame, R l Li is the rotation matrix from the LiDAR frame to the l-frame, and R b Li is the rotation matrix from the LiDAR frame to the b-frame.

System Architecture and Mathematical Models
A loosely coupled integration between the INS and the LiDAR SLAM is implemented using an EKF, which results in an integrated navigation solution. As shown in Figure 9, the raw IMU measurements are fed into a full IMU mechanization, which produces the position, velocity, and attitude angles of the inertial navigation system. The LiDAR scans are used as input to the optimized LOAM SLAM algorithm, which results in the position and attitude of the UAV. These are used as the measurement update to the IMU mechanization output during the update stage of the EKF. The result is the integrated INS/LiDAR navigation solution. The updated errors are fed back into the IMU mechanization, which forms a closed-loop error scheme. Two case studies were considered. The first one is a complete absence of the GNSS signal throughout the full UAV trajectory. In this case, the measurement update is from the LiDAR SLAM only. The second case study, on the other hand, includes updates from the GNSS PPP solution every 20 s.
The EKF system model, measurement model, and other mathematical and stochastic equations are similar to [33]. In the prediction stage, the state vector is defined by Equation is the accelerometer bias error vector; δb g = δb gx δb gy δb gz T is the gyroscope bias error vector; φ imu−Li , λ imu−Li , h imu−Li are the measurement errors for the geodetic latitude, longitude and height; and p imu−Li , r imu−Li , y imu−Li are the measurement errors for the pitch, roll, and yaw angles.  The EKF system model, measurement model, and other mathematical and stochastic equations are similar to [33]. In the prediction stage, the state vector is defined by Equation (3). Subsequently, in the update stage, the measurement update vector is given by Equation (4).

First Case Study-Complete GNSS Outage
In this case study, a full GNSS signal outage is assumed along the whole trajectory of the UAV. Three navigation solutions were considered in this case study, namely, INSonly, LiDAR SLAM-only, and the integrated INS/LiDAR SLAM solution. The INS-only solution represents the solution obtained through IMU mechanization, while the LiDAR SLAM-only solution is the one produced using the optimized LOAM SLAM. Finally, the third solution is the integrated INS/LiDAR SLAM solution using EKF. The position and attitude of the three navigation solutions were compared to the ground truth, which is the interpolated camera solution. Figure 10 shows the position errors in the ENU local reference frame, while Figure 11 illustrates the errors of the attitude angles (roll, pitch, and yaw) for three navigation solutions. The error statistics of the position and attitude are shown in Table 2 for the three navigation solutions.

First Case Study-Complete GNSS Outage
In this case study, a full GNSS signal outage is assumed along the whole trajectory of the UAV. Three navigation solutions were considered in this case study, namely, INSonly, LiDAR SLAM-only, and the integrated INS/LiDAR SLAM solution. The INS-only solution represents the solution obtained through IMU mechanization, while the LiDAR SLAM-only solution is the one produced using the optimized LOAM SLAM. Finally, the third solution is the integrated INS/LiDAR SLAM solution using EKF. The position and attitude of the three navigation solutions were compared to the ground truth, which is the interpolated camera solution. Figure 10 shows the position errors in the ENU local reference frame, while Figure 11 illustrates the errors of the attitude angles (roll, pitch, and yaw) for three navigation solutions. The error statistics of the position and attitude are shown in Table 2 for the three navigation solutions.    Figure 11. Complete GNNS signal outage: errors of attitude angles (roll, pitch, and yaw). Figure 11. Complete GNNS signal outage: errors of attitude angles (roll, pitch, and yaw).  Figure 10 shows that the INS solution drifts significantly over time, indicating that it cannot be used solely for accurate navigation. However, in comparison with the INS solution, the integrated navigation system produced significantly less errors. Therefore, the integrated system was tuned to increase the weights of LiDAR SLAM position updates, while lowering those of the INS solution. As a result, the combined INS/LiDAR position solution was somewhat similar to the LiDAR SLAM solution. As shown in Figure 10 and Table 2, the up-direction error is significantly larger than the horizontal counterpart. The reason for this behavior is due to the nature of the collected point clouds, such that the distribution of the points is only in one direction (below the lidar sensor), which causes poor vertical geometry. Similar behavior was presented in [33], where the estimations for the up-direction from the LiDAR SLAM was sensitive to the geometry of the detected features.
In contrast, the integrated INS/LiDAR solution in Figure 11 was tuned to follow the INS solution for pitch and roll angles, which outperformed those of the LiDAR SLAM. However, the integrated system followed the yaw angle produced by the LiDAR SLAM, which was more accurate than that of the INS solution. It is worth mentioning that the IMU measures the vehicle's accelerations and angular rotations directly, after which the attitude was estimated, which leads to more accurate estimations for the attitude in comparison to position estimation. However, when the drone performs sharp turns, the yaw angles estimations from the IMU mechanization drifts significantly, in which case, the LiDAR SLAM estimates are better for the yaw. This behavior echoes with [33] for the pitch and roll angles, albeit not the yaw angle. The reason for this is due the different nature of the datasets, terrestrial in [33] versus UAV system in this paper. The yaw angle estimate from the IMU mechanization in case of UAV navigation will be more sensitive to turns because the UAV turns are typically drastically sharper than those of cars.
The RMSE of the integrated INS/LiDAR position errors and the yaw angle converged towards that of the LiDAR SLAM, while the RMSE of the pitch and roll angles were closer to that of the mechanization errors. In Figure 12, LiDAR SLAM and INS/LiDAR trajectories are compared to the ground truth for the first case study (complete GNSS signal outage).

Second Case Study-GNSS PPP Assistance
In the second case study, updates from the GNSS PPP solution were considered improve the LiDAR SLAM results, and thereby fill in the GNSS gaps, as mentioned Section 2. The GNSS position updates are fed into the EKF every 20 s, whenever they a available, while the filter continued to receive attitude updates from the LiDAR SLAM.
The same approach for the filter tuning was adopted as discussed in the first ca study. As a result, a similar performance can be observed for the position and attitud errors of the integrated system (Figures 13 and 14). However, as shown in Table 3, th errors are significantly reduced in comparison with the previous case study, which attributed to the GNSS updates. A comparison between LiDAR SLAM an GNSS/INS/LiDAR trajectories with respect to the ground truth for the second case stud is shown in Figure 15. As shown in Table 4, it is noticeable that the GNSS updates led a lower RMSE of approximately 51% and 78% in the horizontal and up direction respectively. Additionally, the reductions in the RMSE of the roll and yaw angles we roughly 13% and 28%, respectively. However, there existed no significant change in th pitch angle.

Second Case Study-GNSS PPP Assistance
In the second case study, updates from the GNSS PPP solution were considered to improve the LiDAR SLAM results, and thereby fill in the GNSS gaps, as mentioned in Section 2. The GNSS position updates are fed into the EKF every 20 s, whenever they are available, while the filter continued to receive attitude updates from the LiDAR SLAM.
The same approach for the filter tuning was adopted as discussed in the first case study. As a result, a similar performance can be observed for the position and attitude errors of the integrated system (Figures 13 and 14). However, as shown in Table 3, the errors are significantly reduced in comparison with the previous case study, which is attributed to the GNSS updates. A comparison between LiDAR SLAM and GNSS/INS/LiDAR trajectories with respect to the ground truth for the second case study is shown in Figure 15. As shown in Table 4, it is noticeable that the GNSS updates led to a lower RMSE of approximately 51% and 78% in the horizontal and up directions, respectively. Additionally, the reductions in the RMSE of the roll and yaw angles were roughly 13% and 28%, respectively. However, there existed no significant change in the pitch angle.           It is worth mentioning that the positioning accuracy for this case study mainly depends on that of the PPP solution. As mentioned in Section 2.2, the accuracy of the GNSS PPP solution was in the dm-m level accuracy. Should a higher precision PPP solution be available, the integrated solution will follow.

Conclusions
In this study, a GNSS/INS/LiDAR integrated navigation system was developed to overcome numerous and prolonged GNSS signal outages caused by a malfunctioning GNSS antenna during data collection. To recover the full trajectory of the UAV, the LiDAR data were processed using the optimized LOAM SLAM algorithm, which yielded position and rotation estimations of the sensor. The camera images were processed with the help of four corner GCPs using Pix4D Mapper software, which resulted in precise camera poses that served as ground truth. All collected sensor data were timestamped by the GPS time, and therefore all datasets were synchronized to match the same frequency of the LiDAR data. Two case studies were considered. In the first case study, a LC integration between the INS and the LiDAR SLAM solution was implemented using an EKF. The positioning accuracy of this case study depends mainly on the LiDAR SLAM accuracy, which yielded a larger error in the up direction in comparison with the horizontal direction. This is essentially caused by the poor vertical geometry. In contrast, the integrated INS/LiDAR solution was tuned to follow the INS solution for pitch and roll angles, which outperformed those of the LiDAR SLAM. However, the integrated system followed the yaw angle produced by the LiDAR SLAM, which was more accurate than that of the INS solution.
A similar integration was executed in the second case study, albeit with updates from the GNSS PPP solution every about 20 s. The same approach for filter tuning was adopted as in the first case study. It was shown that significant improvement in the latter case is obtained in the pose estimation compared to the full absence of GNSS. The positioning RMSE was reduced by 51% and 78% in the horizontal and up directions, respectively, while the RMSE of the roll and yaw angles was reduced by 13% and 28%, respectively. However, the RMSE of the pitch angle was increased by about 13%.

Data Availability Statement:
The data presented in this study are not publicly available.