FAST-LIVO2 Changes

This page explains how the upstream FAST-LIVO2 package was adapted for the FYP sensor setup and deployment workflow.

1. Upstream Source

Upstream repository:

• https://github.com/hku-mars/FAST-LIVO2

The FYP repository keeps the main FAST-LIVO2 structure, but it adds a dedicated MID-360 mode and changes several mapping-related details.

2. Main Goal Of The Changes

The upstream project is a general LiDAR-inertial-visual system. The FYP version narrows it to one concrete deployment target:

• Livox MID-360
• Intel RealSense D455
• the topic contract produced by the modified Livox driver

So the local changes are mainly about making FAST-LIVO2 runnable and stable on that exact sensor stack.

3. New MID-360 Configuration

The most obvious FYP addition is:

• FAST-LIVO2/config/MID360.yaml

This file does not exist in the upstream repository.

It defines:

• aligned image topic
• aligned LiDAR topic
• IMU topic
• LiDAR-camera extrinsics
• LiDAR-IMU extrinsics
• VIO/LIO settings
• PCD saving behavior

The current topic choices are:

img_topic: "/camera/image_aligned"
lid_topic: "/livox/lidar_aligned"
imu_topic: "/livox/imu"

These choices show that the FYP version is directly coupled to the modified livox_ros_driver2 synchronization path.

4. New D455 Camera File

The FYP version also adds:

• FAST-LIVO2/config/camera_D455.yaml

This stores the deployed RealSense D455 intrinsics used by the current project:

• camera model
• width and height
• focal lengths
• principal point
• distortion values

This is another sign that the local FAST-LIVO2 package has been turned into a deployment-specific package rather than kept as a generic example set.

5. New Launch Mode

A dedicated launch file was added:

• FAST-LIVO2/launch/mapping_mid360.launch

This launch file does not exist upstream.

Its role is straightforward:

• load MID360.yaml
• load camera_D455.yaml
• start the mapping node in a sensor-specific mode

This gives the FYP a direct entry point for MID-360 + D455 operation instead of requiring adaptation of upstream sample launches.

6. Mapper Changes

The main source differences are concentrated in:

• FAST-LIVO2/src/LIVMapper.cpp
• FAST-LIVO2/include/LIVMapper.h

The most reliable confirmed local change in this area is that the FYP version removes the old image_save -> cv::imwrite() automatic image-saving path from upstream.

This means the local version no longer depends on the upstream logic that periodically saves image files to disk from inside the mapper.

That change is important because if that path is not commented out or removed, the project cannot run correctly in the current FYP setup.

At the same time, the visual input path itself was not removed. The project still uses image input and cv_bridge; what was removed was the automatic image-export side path rather than the visual frontend itself.

7. Extrinsic And Sensor Assumptions

The current local configuration stores:

• LiDAR-IMU extrinsics under extrin_calib.extrinsic_T and extrin_calib.extrinsic_R
• LiDAR-camera extrinsics under Rcl and Pcl

In the current source, the mapper reads Rcl and Pcl and passes them to:

• setLidarToCameraExtrinsic

This means the current FYP code treats Rcl/Pcl as LiDAR-to-camera extrinsics, not just anonymous calibration values.

That decision is important for:

• calibration documentation
• camera-LiDAR alignment
• later reuse of the project by other students

8. PCD Saving As A Deployment Workflow

Another practical difference from the more general upstream style is that .pcd saving is part of the project workflow itself.

In this FYP:

• the mapping package is used to record a real deployment map
• the saved .pcd is reused by hdl_localization
• the same .pcd is then sliced into floor-specific 2D maps

So the modifications around PCD output are not incidental. They support the downstream reproduction and redeployment pipeline.

9. Why These Changes Were Needed

These local FAST-LIVO2 changes were made because the upstream package is too general for the concrete FYP system.

The project needed:

• a MID-360-specific launch path
• a D455-specific camera file
• direct compatibility with aligned LiDAR-camera topics
• a predictable map-recording workflow

Without those changes, the user would still have a strong upstream algorithm, but not a clean route from raw sensors to a reproducible robotics workflow.