Livox Driver Changes

This page explains the changes that were intentionally added in livox_ros_driver2 for this FYP.

1. Upstream Source

Upstream repository:

• https://github.com/Livox-SDK/livox_ros_driver2

The key FYP-specific addition here is the synchronization path used by the MID-360 + camera pipeline.

2. Main Goal Of The Changes

The main objective was to make the Livox data stream fit a pipeline that also depends on camera input.

In this project, the driver is expected to provide a synchronized or aligned data flow that downstream FAST-LIVO2 configuration can consume more reliably.

3. Added Synchronization Node

The clearest custom addition is:

• livox_ros_driver2/src/sync_node.cpp

This file does not exist in the upstream repository. It is an FYP-specific addition.

The node:

• subscribes to image and Livox topics
• keeps a short image buffer
• uses LiDAR packets as the timing anchor
• searches for the nearest image in time
• republishes aligned outputs

The aligned output topic defaults in the current implementation are:

• /camera/image_aligned
• /livox/lidar_aligned

These names are important because the current FAST-LIVO2 MID-360 configuration expects:

• FAST-LIVO2/config/MID360.yaml

with:

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

So the synchronization node is part of the topic contract used by the later mapping pipeline.

4. Added Sync Launch Entry

There is also a dedicated launch file:

• livox_ros_driver2/launch_ROS1/msg_MID360_sync.launch

This file is also not present in the upstream repository.

Its role is to expose the synchronization path as a runnable ROS1 launch entry, so the FYP bringup can start both:

• the normal MID-360 driver
• the synchronization path used by the LiDAR-camera workflow

This is why:

• fastlivo2_bringup/launch/fastlivo2_full.launch

starts both:

• msg_MID360.launch
• msg_MID360_sync.launch

5. Build-System Changes

The FYP version of livox_ros_driver2 also changes the build configuration:

• livox_ros_driver2/CMakeLists.txt

Compared with upstream, the modified package:

• adds message_filters as a dependency
• builds an additional executable named sync_node

This is necessary because the synchronization path is not just a launch-level wrapper. It introduces a real extra ROS node.

6. Why These Changes Were Needed

These changes exist for practical reasons:

• the upstream driver is not enough by itself for the MID-360 + D455 fusion path used here
• the mapping pipeline expects aligned topics, not only raw topics
• the project needs a ROS1 build path that can include the extra synchronization node

In short, the Livox driver in this FYP is not only a sensor driver. It is part of the data-preparation layer for the full LiDAR-camera mapping pipeline.