Drift accumulates
Each alignment carries a small error. Errors compound over thousands of scans, so a corridor walked for ten minutes can end up bent by metres even though every individual step looked fine.
LiDAR SLAM
What is LiDAR SLAM?
SLAM stands for simultaneous localisation and mapping. A sensor moves through an unknown space and, from the same stream of measurements, works out both what the space looks like and where it is inside it. With LiDAR the measurements are laser range returns, tens of thousands per scan.
The chicken and egg problem
To place a scan correctly in a map you need to know where the sensor was. To know where the sensor was you need a map to compare the scan against. SLAM solves both at once: each new scan is aligned to the map built so far, that alignment updates the estimated pose, and the aligned scan then extends the map. Repeat a few thousand times and you have a trajectory and a point cloud.
This is why stacking raw PointCloud2 frames on top of each other does not produce a map. Every frame is in sensor coordinates at a different moment. Without pose estimation, the result is a smear.
Scan · Align · Accumulate
Why it is hard
Loop closure is the fix
When the sensor revisits a place, the system can recognise it and add a constraint that pulls the whole trajectory back into shape. Miss the loop and the drift stays baked into the map.
Degenerate geometry
A long featureless tunnel, an empty car park, a snowy field: scans that look identical from many positions cannot constrain motion along the ambiguous axis. This is where IMU data earns its place.
Open-source engines worth knowing
There is no single best LiDAR SLAM package. These four cover most of what teams actually deploy, and they trade off differently between compute cost, tuning effort, and global consistency.
GLIM
A globally consistent LiDAR-inertial mapping framework from Kenji Koide at AIST. Uses GPU-accelerated matching and global trajectory optimisation, which is why it holds up well on long recordings with loops. This is the engine LidarFlow runs.
GLIM on GitHubFAST-LIO
A tightly coupled LiDAR-inertial odometry system built around an iterated Kalman filter. Very fast and light enough to run onboard, which makes it a common choice for real-time use on drones and small robots.
FAST-LIO on GitHubLIO-SAM
A factor-graph LiDAR-inertial system with loop closure and GPS factors. Well documented, widely deployed, and a solid baseline when you want a system that many people have already debugged before you.
LIO-SAM on GitHubKISS-ICP
Deliberately minimal point-to-point ICP odometry with almost nothing to tune. No IMU required. A good sanity check when you want to know how much of your result comes from the data rather than from parameter choices.
KISS-ICP on GitHubWhere LidarFlow fits
Running any of the engines above means building it, matching CUDA and ROS versions, wiring the topics, and tuning until the map stops folding. If that work is not the point of your project, upload the recording instead. LidarFlow runs GLIM, credited to Kenji Koide and the GLIM project, and returns the reconstructed map.
What you upload
- ·
.mcapor ROS1.bag - · LiDAR PointCloud2 or ROS1 Livox CustomMsg topic (required)
- · IMU and GNSS topics (optional, auto-detected)
What you get back
- ·
output.pcd, the mapped point cloud - ·
map.ply, full-fidelity export - ·
slam_trajectory.txt, the sensor path - ·
metadata.json, settings and validation
Frequently asked questions
What is the difference between SLAM and just recording GPS positions?
GPS tells you roughly where the sensor was, at metre-level accuracy and only outdoors. It says nothing about the shape of the world around it. SLAM builds geometry from the LiDAR returns and estimates a centimetre-level trajectory through that geometry, indoors included. In practice the two are complementary: SLAM gives local accuracy, GNSS anchors the result to global coordinates.
What causes a SLAM map to collapse or come out wrong?
Usually one of four things: degenerate geometry such as a long featureless corridor or an open field where scans cannot constrain motion, movement faster than the scan rate can track, a missing or badly calibrated IMU, or a loop that never gets recognised so drift is never corrected. Dynamic scenes full of moving vehicles or people also inject wrong constraints.
Which open-source SLAM package should I use?
It depends on the tradeoff you want. FAST-LIO is fast and light on compute. LIO-SAM is a well-proven tightly coupled LiDAR-inertial system with loop closure. KISS-ICP is deliberately minimal and needs almost no tuning. GLIM focuses on globally consistent maps with GPU-accelerated matching. All four are legitimate choices. LidarFlow runs GLIM.
Can I get a SLAM map without installing ROS?
Yes. Upload a .bag or .mcap recording and the reconstruction runs on our side, returning output.pcd, map.ply, and the estimated trajectory. Nothing is installed locally and no parameters need tuning.
Free while we are testing
Upload a LiDAR recording. Get a reconstructed map back.