- 🔓 2025-01-23: Code released!
- 🎉 2024-10-01: Accepted by T-RO '24!
- 🚀 2024-07-02: Conditionally accepted.
For further inquiries or assistance, please contact zhengcr@connect.hku.hk.
FAST-LIVO2 is an efficient and accurate LiDAR-inertial-visual fusion localization and mapping system, demonstrating significant potential for real-time 3D reconstruction and onboard robotic localization in severely degraded environments.
Developer: Chunran Zheng 郑纯然
Our accompanying video is now available on Bilibili and YouTube.
FAST-LIVO2: Fast, Direct LiDAR-Inertial-Visual Odometry
FAST-LIVO2 on Resource-Constrained Platforms
FAST-LIVO: Fast and Tightly-coupled Sparse-Direct LiDAR-Inertial-Visual Odometry
FAST-Calib: LiDAR-Camera Extrinsic Calibration in One Second
We open-source our handheld device, including CAD files, synchronization scheme, STM32 source code, wiring instructions, and sensor ROS driver. Access these resources at this repository: LIV_handhold.
Our associate dataset FAST-LIVO2-Dataset used for evaluation is also available online.
The FAST-Calib toolkit is recommended. Its output extrinsic parameters can be directly filled into the YAML file.
This is the ROS 2 version of FAST-LIVO2 (developed and tested on ROS 2 Humble).
Ubuntu 22.04 with ROS 2 Humble. ROS 2 Installation.
sudo apt install ros-$ROS_DISTRO-pcl-ros ros-$ROS_DISTRO-pcl-conversions \
ros-$ROS_DISTRO-cv-bridge ros-$ROS_DISTRO-image-transport \
ros-$ROS_DISTRO-tf2-ros ros-$ROS_DISTRO-octomap-serverPCL>=1.8, Follow PCL Installation.
Eigen>=3.3.4, Follow Eigen Installation.
OpenCV>=4.2, Follow Opencv Installation.
Not needed anymore. The small subset of Sophus::SE3 and of rpg_vikit (camera models,
image interpolation, Shi-Tomasi score) that FAST-LIVO2 uses is vendored inside this
package (include/utils/sophus_se3.h, include/vikit/, src/vikit/), because both
upstream projects are catkin-only.
Only required to feed the node with Livox CustomMsg data (preprocess.lidar_type: 1).
Build livox_ros_driver2 into the same
workspace; if it is absent the package still builds and supports every
sensor_msgs/PointCloud2 LiDAR (Velodyne, Ouster, Hesai XT32/Pandar128, RoboSense, L515).
mkdir -p ~/ros2_ws/src && cd ~/ros2_ws/src
git clone https://github.com/hku-mars/FAST-LIVO2
cd ~/ros2_ws
colcon build --packages-select fast_livo --cmake-args -DCMAKE_BUILD_TYPE=Release
source install/setup.bashDownload FAST-LIVO2-Dataset from Global-LVBA Section IV.
ros2 launch fast_livo mapping_avia.launch.py
ros2 bag play YOUR_DOWNLOADED_BAG # add --clock and use_sim_time:=true for recorded dataOther entry points: mapping_avia_marslvig.launch.py, mapping_hesaixt32_hilti22.launch.py,
mapping_ouster_ntu.launch.py, mapping_m20_sim.launch.py (DeepRobotics M20 in Isaac Sim,
see below), or the generic one:
ros2 launch fast_livo mapping.launch.py config_file:=avia.yaml \
camera_config_file:=camera_pinhole.yaml rviz:=trueROS 1 bags can be replayed after conversion with
rosbags (rosbags-convert).
config/m20_sim.yaml + config/camera_m20_sim.yaml match the M20 as it is set up in
OM1-ros2-sdk isaac_sim/configs/robots/m20.yaml: the two RTX OS0-128 LiDARs fused into
/lidar (base_link frame) by the om_common point_cloud_fusion node, the IMU on /imu, and
the RealSense colour camera on /camera/realsense2_camera_node/color/image_isaac_sim_raw.
OctoMap filtering is enabled by default there, because the simulated scenes contain walking
humans.
ros2 launch fast_livo mapping_m20_sim.launch.py # use_sim_time defaults to trueStart the simulator and the M20 sensor pipeline first, so that /lidar exists. If the fusion
node is not running, point common/lid_topic at a single LiDAR (e.g. /lidar_points_front)
and update extrin_calib for that sensor's frame.
The Isaac RTX LiDAR publishes plain XYZ clouds, which is what preprocess/lidar_type: 0
(generic sensor_msgs/PointCloud2) is for: it uses an optional float32 time/t field for
deskewing and disables deskewing when the cloud has none.
Moving objects (people, vehicles) leave smeared trails in the accumulated map. Following the
approach used in the ROS 2 FAST-LIO, the map can be filtered by an
octomap_server node: FAST-LIVO2 publishes each
undistorted scan in the sensor body frame on /cloud_registered_body together with the
camera_init -> body transform, and octomap_server ray casts from the sensor origin to every
point. Voxels a moving object has vacated are traversed by later rays and get cleared
probabilistically, so only static structure survives.
Enable it in the sensor YAML:
octomap:
enable: true # spawns octomap_server and switches map output/saving to the filtered cloud
resolution: 0.1 # OctoMap voxel size [m]
hit: 0.7 # occupied-endpoint probability update
miss: 0.4 # free-space probability update along the ray
min: 0.12 # clamping min
max: 0.97 # clamping max
max_range: -1.0 # ray casting range [m], -1 = unlimited
map_pub_period: 1.0With it enabled:
| topic / service | meaning |
|---|---|
/cloud_registered_body |
body-frame scan sent to octomap_server (input for ray casting) |
/octomap_point_cloud_centers |
octomap_server output, i.e. the cleared occupied voxels |
/Laser_map |
the same cleared map, republished by this node every map_pub_period |
/map_save (std_srvs/srv/Trigger) |
writes the cleared map to octomap.temp_map_file_path (default Log/pcd/octomap_map.pcd) |
ros2 service call /map_save std_srvs/srv/TriggerLower resolution keeps more detail at the cost of memory; a larger miss (closer to 0.5)
clears more conservatively, a smaller one removes dynamic points faster but is more likely to
erase thin static structure.
With octomap.enable: false (the default) the behaviour is unchanged from upstream: the raw
accumulated cloud is published and saved according to the pcd_save settings.
The source code of this package is released under the GPLv2 license. For commercial use, please contact me at zhengcr@connect.hku.hk and Prof. Fu Zhang at fuzhang@hku.hk to discuss an alternative license.