Gaussian-LIC2 fuses LiDAR, IMU and camera into one live Gaussian map

Gaussian-LIC2 treats pose estimation and scene rendering as one problem

Gaussian-LIC is a C++ ROS package that produces two outputs at once: a camera-to-world pose estimate and a photo-realistic 3D Gaussian map of the environment. The README describes the system as a photo-realistic LiDAR-Inertial-Camera Gaussian Splatting SLAM system that runs in real time, and it links two papers, an early arXiv version of Gaussian-LIC and a second paper for Gaussian-LIC2, plus a project page hosted on GitHub Pages. The audience is narrow. This is for robotics and computer vision engineers who already have a spinning or solid state LiDAR with an integrated IMU, a camera, and a Linux workstation with an NVIDIA GPU. It is not a general photogrammetry tool, not a consumer mapping application, and not something you point at a folder of images. The author reports testing on Ubuntu 20.04 with an NVIDIA RTX 3090 or 4090, and every dependency in the install path assumes a CUDA toolchain, so the hardware assumption is fixed rather than negotiable. Understanding that narrowness is the first step in deciding whether this belongs in your pipeline.

The OpenCV build is a hard prerequisite, not a package you can skip

The install steps in the README begin with leaving any Conda environment and preparing third party libraries following the Coco-LIC project. The heavy part is OpenCV 4.7.0, which has to be built from source with the matching opencv_contrib 4.7.0 module and CUDA support. The README is explicit that it must be compiled with CUDA and that no installation step is required for it, meaning the built tree is referenced in place rather than installed into a system prefix. Create the working directory and fetch both archives first.

mkdir -p ~/Software/opencv
cd ~/Software/opencv
wget https://github.com/opencv/opencv/archive/refs/tags/4.7.0.tar.gz && tar -zxvf 4.7.0.tar.gz && rm -rf 4.7.0.tar.gz

Then the contrib module, the build directory, and the CMake configuration that switches on CUDA, cuDNN, the DNN CUDA path and NVDEC video support.

wget https://github.com/opencv/opencv_contrib/archive/refs/tags/4.7.0.tar.gz && tar -zxvf 4.7.0.tar.gz && rm -rf 4.7.0.tar.gz
cd ~/Software/opencv/opencv-4.7.0
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=RELEASE -DWITH_CUDA=ON -DWITH_CUDNN=ON -DOPENCV_DNN_CUDA=ON -DWITH_NVCUVID=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda-11.7 -DOPENCV_EXTRA_MODULES_PATH="../../opencv_contrib-4.7.0/modules" -DBUILD_TIFF=ON -DBUILD_ZLIB=ON -DBUILD_JASPER=ON -DBUILD_CCALIB=ON -DBUILD_JPEG=ON -DWITH_FFMPEG=ON ..
make -j$(nproc)

The CUDA toolkit root is hard coded to /usr/local/cuda-11.7 in that configuration, and the README pairs CUDA 11.7 with cuDNN v8.9.7, so a machine set up for a newer CUDA release will need either a matching install or an edit to that line. This is a source build of a large library on the critical path, and it is the first place a new user loses an evening.

LibTorch and TensorRT arrive as prebuilt archives with no install step

The next two dependencies are deliberately treated as unpack and reference operations. The README states that no compilation or installation is required for either one, which keeps them out of the part of the build where most of the time goes. LibTorch is the inference runtime, fetched from the cu117 build of version 2.0.1.

cd ~/Software
wget https://download.pytorch.org/libtorch/cu117/libtorch-cxx11-abi-shared-with-deps-2.0.1%2Bcu117.zip
unzip libtorch-cxx11-abi-shared-with-deps-2.0.1+cu117.zip && rm -rf libtorch-cxx11-abi-shared-with-deps-2.0.1+cu117.zip

TensorRT follows, and the archive name shows an interesting mismatch worth noting before you download it: the file is the 8.6.1.6 Linux x86-64 package built for CUDA 11.8, while the rest of the stack targets CUDA 11.7.

cd ~/Software
wget https://developer.nvidia.com/downloads/compute/machine-learning/tensorrt/secure/8.6.1/tars/TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz
tar -zxvf TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz && rm -rf TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz

That version pairing is the kind of detail the README does not explain. If you hit a runtime error around TensorRT engine deserialisation, the CUDA 11.7 and CUDA 11.8 mismatch between the two archives is the first thing to check, not the last.

Two separate catkin workspaces keep Coco-LIC and Gaussian-LIC apart

The build uses the catkin workflow, and the repository listing shows a conventional ROS package layout with a package.xml, a CMakeLists.txt, a config directory, a launch directory, a ckpt directory and a src directory. Coco-LIC, the odometry front end that feeds it, is built in its own workspace because it is a separate repository with its own configuration files. That workspace first pulls in the Livox ROS driver.

mkdir -p ~/catkin_coco/src
cd ~/catkin_coco/src
git clone https://github.com/Livox-SDK/livox_ros_driver.git
cd ~/catkin_coco && catkin_make
cd ~/catkin_coco/src
git clone https://github.com/APRIL-ZJU/Coco-LIC.git
cd ~/catkin_coco && catkin_make

Gaussian-LIC then gets its own workspace in the same style.

mkdir -p ~/catkin_gaussian/src
cd ~/catkin_gaussian/src
git clone https://github.com/APRIL-ZJU/Gaussian-LIC.git
cd ~/catkin_gaussian && catkin_make

Two workspaces means two devel/setup.bash files to source and two terminals to keep alive during a run, which matters for anyone trying to reproduce a failure. It also means the version of Coco-LIC you build against is not pinned by the Gaussian-LIC clone itself, so if Coco-LIC has moved on since the README was written, the two halves can drift apart. The README checklist still lists release of the optimized Coco-LIC as pending, which is a hint that the pairing is expected to change.

TensorRT deployment is three shell scripts and one downloaded checkpoint

Running the Gaussian side at real time speed depends on a compiled TensorRT engine, and the README handles this as a separate deployment step after the workspace builds. The checkpoint file Large_300.pth has to be downloaded from Google Drive and placed into the ckpt directory of the cloned repository. Once it is there, three scripts run in order: one sets up the segmentation backbone, one exports to ONNX, and one builds the TensorRT engine.

cd ~/catkin_gaussian/src/Gaussian-LIC/ckpt
chmod +x setup_spnet.sh
./setup_spnet.sh
chmod +x export_onnx.sh
./export_onnx.sh
chmod +x build_trt.sh
./build_trt.sh

The ordering matters and the README does not say what happens if you skip a step. Each script is chmod'd and invoked individually rather than driven by a single make target, which means a partial failure leaves you in an unknown state with no documented reset. This is also the step most sensitive to the GPU in the machine, since the engine build targets the specific architecture of the card it runs on. Building the engine on the same RTX 3090 or 4090 class card that will run the system is the safer route, and if you intend to ship the engine elsewhere you should assume it will need a rebuild.

The quick start runs a FAST-LIVO2 sequence through a yaml bag path

The documented first run uses the sequence CBD_Building_01 from the FAST-LIVO2 dataset, and it needs a bag path edited into the Coco-LIC configuration file named config/ct_odometry_fastlivo2.yaml. The dataset links in the README point to the FAST-LIVO and FAST-LIVO2 collections on OneDrive, and to the R3LIVE, MCD and M2DGR datasets on GitHub and their project pages. Gaussian-LIC is launched first, and Coco-LIC is then launched with the configuration path passed on the command line.

cd ~/catkin_coco
source devel/setup.bash
roslaunch cocolic odometry.launch config_path:=config/ct_odometry_fastlivo2.yaml

The README adds a practical note for real time use and runtime analysis: the rviz node in odometry.launch should be commented out, otherwise visualisation competes with the pipeline. The Gaussian side is started from its own workspace with the fastlivo2 launch file, and the terminal prints a ready message once the node is up. Mapping and rendering output is written to the result directory inside the cloned Gaussian-LIC source tree. Note the division of labour: pose comes from Coco-LIC, the Gaussian map from Gaussian-LIC, and the coupling between them is a ROS launch plus a shared configuration file rather than a single fused binary.

The checklist shows five pieces of the release that are not there yet

The README ends with an open task list, and it is the most honest section of the document. Support for fast post optimization is unchecked, as is release of the optimized Coco-LIC. The dockerfile is listed as something still to be provided, which means there is no container image to pull and no reproducible environment defined. The meshing tools are also pending, so you cannot export the Gaussian map into a conventional mesh with the tooling provided here, and the Gaussian-LIC2 dataset is on the same list. On top of that, the repository has no GitHub releases, so there is no tagged version, no binary package and no changelog to track. The git history shows the last push was on 2026-08-08, and the news entries show that the enhanced version of the Gaussian-LIC code was released in July 2025 with the Gaussian-LIC2 release following in February 2026. Development is clearly still moving, but the release engineering around it is minimal, and that gap is what a adopting team inherits.

Licence and paper trail leave something for a legal reviewer to ask

The repository listing reports no licence identifier for this project, which is unusual for code meant to be built on. Nothing in the README grants redistribution rights or states terms for the derived work, so any team intending to publish results, embed the system in a product, or hand it to a contractor needs a written answer before going further. The only contact channel the README offers is an email address for Xiaolei Lang at the university domain, and questions about the paper itself are routed to the authors rather than an issue tracker. The academic trail is well documented for anyone wanting to understand the method: an arXiv PDF for each of the two versions, a project page with videos, and publication at ICRA 2025 for Gaussian-LIC and acceptance by the International Journal of Robotics Research for Gaussian-LIC2 in July 2026. Peer review tells you the method was taken seriously. It says nothing about licensing, and it is not a substitute for a support commitment.

Editorial conclusion

Gaussian-LIC2 suits research teams that already run ROS with a LiDAR, an IMU and a camera on Ubuntu 20.04 and an NVIDIA GPU, and that need a dense radiance-field map alongside their trajectory estimate. It is the wrong choice for production fleets, for teams without a CUDA-capable NVIDIA card, or for anyone needing a licence grant, because the repository listing gives no licence and the README checklist still leaves Docker packaging, meshing tools, the dataset and the optimised Coco-LIC release pending. Before committing, check three things: that your exact sensor rig matches the FAST-LIVO2 configuration in Coco-LIC, that the TensorRT export scripts run against the Large_300.pth checkpoint, and that the licence terms are settled with the authors directly, since the contact address given in the README is the only channel listed.

Frequently asked questions

Official sources

1. APRIL-ZJU/Gaussian-LIC on GitHub
2. Issues
3. README