LiDAR SLAM Algorithms Compared for Indoor Mobile Robots

Each major LiDAR SLAM algorithm family (filter-based, matching-based, graph optimization-based, and emerging deep learning-based) makes different tradeoffs in accuracy, compute, and robustness that determine how well it performs in real indoor environments, and understanding those tradeoffs is the practical key to choosing the right one.

Why indoor LiDAR SLAM is harder than it looks

Every mobile robot navigating a warehouse floor, hospital corridor, or office building needs to answer two questions at once: where the robot is, and what the space looks like. Long featureless corridors, symmetric cubicle rows, stairwells, and pedestrians moving unpredictably through the sensor's field of view all conspire against the algorithm's basic assumptions. LiDAR earns its place in this fight because it doesn't care about lighting, and its ranging accuracy beats camera-based approaches by a wide margin. But that strength has a specific counterweight: when the environment offers no distinguishing geometry, or when that geometry repeats itself symmetrically, a LiDAR-only system loses its ability to pin down the robot's full six-degree-of-freedom motion. That's a significant failure mode with wide-reaching consequences. It's the central design constraint that every algorithm on this list has to work around. Single-sensor dead reckoning compounds the problem by letting small errors accumulate unchecked, and multi-sensor fusion has become the default architecture rather than an optional upgrade. LeGO-LOAM, LiLi-OM, LINS, and LIO-SAM, all established, widely cited algorithms, failed outright on the Hilti benchmark's narrow-staircase sequences. Most of the head-to-head numbers referenced here come from 2024 through 2026 literature, and ATE RMSE (absolute trajectory error, root mean square) is the common yardstick used across nearly all of it.

How the four algorithm families divide the design space

A 2025 review in Remote Sensing by Ran and colleagues sorts 2D LiDAR SLAM into four families: filter-based, matching-based, graph optimization-based, and deep learning-based. Each one answers the same underlying question differently: how do you turn a stream of noisy, incremental sensor readings into one map that holds together globally?

Filter-based methods propagate a probability distribution over the robot's possible poses in real time. They're fast and their memory footprint stays bounded, but the approximations baked into that speed compound over long runs. Matching-based methods skip the probabilistic model and align successive scans against each other directly, which keeps things lightweight but leaves drift unchecked unless a loop-closure step gets bolted on. Graph optimization-based methods build a pose graph, add constraints whenever the robot revisits a place, and solve the whole thing globally, buying the highest accuracy ceiling of the four at the cost of heavier computation. Deep learning-based methods try to learn priors from data rather than hand-code them, chasing generalization across environment types that trip up the other three, though that promise comes bundled with a training-data dependency that most indoor deployments aren't set up to support.

Few production systems stick to one family in isolation. A filter-based front end feeding a graph-based back end is common enough that the four-family split describes emphasis, not a hard boundary, more a statement of which tradeoff a given system leans into. One more split matters before getting into specific algorithms: 2D LiDAR SLAM is cheaper and dominates indoor wheeled robots, while 3D adds real richness to the map at the cost of pricier sensors and heavier compute.

Filter-based SLAM: what particle filters buy you

GMapping uses Rao-Blackwellized particle filters, and its intelligent resampling (only resampling when necessary) reduces memory consumption and prevents particle depletion. The whole design points toward one goal: real-time performance and fast 2D map construction on hardware that doesn't have much horsepower to spare.

That efficiency comes at a cost, though, and comparative studies show it: GMapping tends to produce inaccurate maps once the environment gets complex. The particle representation is fundamentally an approximation, and approximations trade fidelity for speed. Where does that leave GMapping as a practical choice? In simple, low-clutter spaces, on hardware-constrained platforms, or in situations where a rough map is genuinely good enough, it still holds up. What it doesn't offer is any inherent loop-closure mechanism, so accumulated drift in large or geometrically repetitive buildings remains a known, well-documented weak point. Matching-based methods exist partly as a response to this, trying to sidestep the particle approximation altogether by aligning scans against each other directly instead of maintaining a probabilistic swarm.

Matching-based SLAM: Hector SLAM's odometry-free design and its limits

Hector SLAM takes a different route entirely. It uses Newton-Gauss scan matching and needs no wheel odometry at all, because the scan matcher itself generates the motion estimate. An IMU can be folded in optionally, and without one, the algorithm is particularly well suited to lightweight devices and small UAVs, platforms where wheel encoders aren't even an option. Pairing a modest 2D LiDAR with an IMU gives you a budget-friendly hardware profile that's practical for service robots, warehouse robots, and low-speed mobile platforms working in controlled environments.

The performance numbers back up the reputation. In a comparison of ten ROS-based SLAM systems by Filipenko and Afanasyev, published in January 2025, Hector SLAM and Cartographer tied for the most accurate indoor trajectories, both landing an ATE RMSE of 0.024 meters against ground truth Filipenko & Afanasyev (arXiv:2501.09490). That result came from an office environment, structured and reasonably feature-rich, a space where a scan matcher has plenty of geometry to lock onto Filipenko & Afanasyev (arXiv:2501.09490). Take away that structure, drop the robot into a featureless corridor or a scene full of moving people, or ask it to handle a fast rotation, and the scan matcher loses convergence fast. That's the tradeoff matching-based methods make: lightweight and odometry-free when things go well, fragile when the geometry disappears.

The idea keeps evolving on newer middleware, too. In the 2026 ICICC Springer study comparing GMapping, Cartographer, and SLAM Toolbox on ROS2, SLAM Toolbox achieved the highest overall mapping accuracy in both simulation and real environments, extending the matching/graph hybrid idea onto a modern middleware stack.

Graph optimization-based SLAM: Cartographer, LIO-SAM, and FAST-LIO2 in structured benchmarks

Graph-based SLAM treats robot poses as nodes and relative measurements, whether from scan matching or an IMU, as edges connecting them. A back-end optimizer then minimizes the total constraint violation across the whole graph at once, which is what makes loop-closure correction possible in the first place. That global view is the entire selling point of this family.

Google's Cartographer is probably the best-known implementation Filipenko & Afanasyev (arXiv:2501.09490). It blends local probabilistic sub-map updates with global loop-closure optimization, performs well across both 2D and select 3D configurations, and carries one notable limitation: it estimates a full six-degree-of-freedom pose but still can't produce a complete 3D map.

LIO-SAM represents the tightly coupled LiDAR-inertial branch of this family, fusing odometry into a factor graph, and it's become something of a standard baseline in the field. On a hospital indoor sequence from the MSSP benchmark platform, LIO-SAM scored an absolute pose error of 0.076913 meters, respectable, though it failed entirely on the Hilti benchmark's narrow-staircase sequences, a result that lines up with the broader pattern of degeneracy failures covered later MSSP platform (arXiv:2407.14102).

FAST-LIO2 takes a related but distinct approach: tightly coupled 3D LiDAR and IMU fusion running through an iterated extended Kalman filter front end. On that same hospital sequence, it posted 0.067032 meters, edging out LIO-SAM MSSP platform (arXiv:2407.14102). Its close relatives tell an interesting story about how much variation exists even within a supposedly similar algorithm class: Faster-LIO scored 0.082596 meters, and Voxel-Map came in at 0.059928 meters, the best of that entire cluster on the hospital scenario MSSP platform (arXiv:2407.14102). The lesson there isn't subtle. Sharing a family label doesn't mean sharing a performance tier.

A separate comparison published in IET Cyber-Systems and Robotics in 2025 backs this up: A-LOAM diverged furthest from ground truth, while LIO-SAM, LeGO-LOAM, and FAST-LIO2 stayed closer but still showed meaningful deviation, confirming FAST-LIO2's edge without overselling it as some kind of universal answer.

Loop closure gets its own spotlight in a comparison of SC-LIO SAM against Cartographer from October 2024. It successfully detected and corrected for revisited locations across most test sequences. SC-LeGO LOAM, tested alongside it, also closed loops successfully on the KITTI dataset, but drifted substantially on one sequence where the robot never actually revisited a previous location, a useful reminder that loop closure only helps when there's a loop to close.

KISS-SLAM, presented at IEEE/RSJ IROS 2025, deliberately keeps things simple, running LiDAR-only graph SLAM with little to no parameter tuning required, and still achieves competitive pose accuracy. That result matters because it shows a carefully engineered graph pipeline, without any sensor fusion at all, can generalize across different environments, sensors, and motion profiles. None of this comes free, though. Full graph optimization on a large map is heavier computationally than either filter-based or pure matching approaches, and methods like SC-LIO SAM are explicitly trading memory and CPU cycles for that global consistency. Cartographer's 0.024 m ATE RMSE (Filipenko & Afanasyev, arXiv:2501.09490) ties it with Hector SLAM as the best-performing system in that ten-algorithm office comparison (Filipenko & Afanasyev, arXiv:2501.09490) Filipenko & Afanasyev (arXiv:2501.09490). Point-LIO recorded 0.249101 m, notably worse on that scenario. A-LOAM recorded 0.584886 m and LeGO-LOAM recorded 1.459633 m, both substantially worse, showing not all graph-adjacent methods are equal.

RTAB-Map and multi-sensor fusion: when you need LiDAR and RGB-D together

RTAB-Map, short for Real-Time Appearance-Based Mapping, was built from the ground up for multi-sensor fusion, and it can process visual and LiDAR data at the same time. Among the algorithms covered in the current literature, it stands alone as the only one built to use RGB-D and LiDAR sensors concurrently. That's a genuinely distinct capability.

The numbers show it, too. RTAB-Map gets cited as one of the strongest performers by RMSE for mobile robot localization in homogeneous indoor office environments, which happens to be precisely the feature-sparse scenario where pure LiDAR scan matching starts to struggle. In the Filipenko and Afanasyev comparison, the stereo variant of RTAB-Map also turned in encouraging trajectory results, adding further weight to the case for fusion.

Compute cost climbs relative to LiDAR-only pipelines, though GPU acceleration, on NVIDIA's edge platforms for instance, can bring execution time back down to something workable for autonomous mobile robot deployment. Fusion is one way researchers are working around these failure modes. Teaching the system to learn priors about its environment is the other, and that's the deep learning route. For environments mixing open offices (texturally rich) with long corridors (geometrically degenerate), RGB-D + LiDAR fusion hedges against both failure modes. Multi-sensor fusion is one mitigation, and the other research direction is teaching the system to learn environment priors, which is what deep learning-based SLAM attempts.

Deep learning-based SLAM: what learned priors add

Deep learning-based SLAM trains networks on collected datasets to handle scan matching, odometry estimation, or loop-closure detection, tasks that hand-crafted geometric features often can't manage once the environment gets weird enough. Ran and colleagues name it as the fourth family in their 2025 review, though they're careful to flag it as still emerging relative to the more established filter and graph methods when it comes to actual indoor deployment.

A learned model can pull signal from intensity patterns and semantic context that pure geometry throws away, and in principle it needs less environment-specific tuning than a hand-built pipeline. The downside is just as real. Training these systems demands large labeled datasets, running inference on embedded hardware isn't trivial, and behavior outside the training distribution is far harder to predict than it is for a deterministic algorithm that at least fails in consistent, characterizable ways.

IaNDT-SLAM, published in April 2026, offers a useful middle path. It augments Normal Distributions Transform matching with per-point intensity data, a hybrid that leans on learned intensity priors without going full end-to-end deep learning. That targets a specific, well-known gap: most existing methods ignore per-point intensity entirely, which causes registration to fail in unstructured environments where geometric features run thin. The field's actual state deserves plain description. Across the 2024 through 2026 benchmark literature, purely deep learning-based LiDAR SLAM hasn't displaced graph optimization methods on standard indoor accuracy metrics. More often it appears as one component inside a larger pipeline, handling loop closure or degeneracy detection, rather than replacing the whole system.

The three indoor failure modes that benchmarks underreport

The first is geometric degeneracy: corridors, tunnels, and staircases. A long straight corridor gives a LiDAR unit nothing to distinguish one scan from the next, so the system can't fully estimate its own six-degree-of-freedom motion. LeGO-LOAM, LiLi-OM, LINS, and LIO-SAM all failed outright, and even FAST-LIO2, Faster-LIO, and Point-LIO, algorithms that otherwise perform reasonably well, posted unusually large pose errors, making the Hilti staircase result the sharpest evidence available. No algorithm currently deployed solves corridor degeneracy on its own, without leaning on an IMU, fixed landmarks, or visual features to fill in what the geometry can't provide.

The second is dynamic objects, pedestrians and moving equipment being the obvious indoor examples. Most LiDAR SLAM methods start from an assumption of a static world, and that assumption breaks constantly in warehouses, hospitals, and any corridor that sees foot traffic. The Ran et al. review names dynamic object handling as one of the two most active research problems in 2D LiDAR SLAM today, which tells you it's still unsolved rather than merely inconvenient.

The third is feature sparsity paired with repetitive structure. Most algorithms lean entirely on geometric features, and when those features are sparse or absent, registration fails, precisely the gap IaNDT-SLAM's intensity data is meant to close.

A hospital ward is dynamic, has long corridors, and has repetitive room geometry, making it the hardest single-environment combination.

Current mitigation approaches and the specific problems each one fixes

QR-code landmark fusion, described in a Scientific Reports paper, tackles the degeneracy and repetition problems directly rather than trying to out-engineer them algorithmically. The architecture pairs an EKF-based LiDAR-IMU odometry front end with a back-end factor graph that tightly couples LiDAR, IMU, loop-closure, and QR-code landmark factors into one shared state space. Placing QR codes at intervals gives the system a form of persistent global anchoring precisely where it needs it most: long corridors and repetitive floor plans, hitting failure modes one and three at the same time. The tradeoff is straightforward. It requires placing QR codes before deployment, which is a reasonable ask in a controlled warehouse or hospital wing but a poor fit for anywhere ad hoc or frequently reconfigured.

IaNDT-SLAM approaches the same underlying problem from a different angle, addressing feature sparsity by augmenting Normal Distributions Transform matching with point-intensity data instead of relying on external infrastructure. It's a hybrid rather than a full learned pipeline, and that's arguably its strength: it captures some of what deep learning offers without inheriting the training-data burden or the unpredictable out-of-distribution behavior that comes with an end-to-end neural approach.

Between these two mitigation strategies and the broader family comparisons above, a consistent shape appears in the results. No single algorithm currently on the table solves geometric degeneracy, dynamic objects, and feature sparsity simultaneously. Cartographer and Hector SLAM excel in structured offices. Among this group, Faster-LIO scored 0.082596 m and Voxel-Map scored 0.059928 m, with Voxel-Map performing best of this group on hospital indoor sequences MSSP platform (arXiv:2407.14102). RTAB-Map earns its place the moment the environment mixes textures and geometry within the same building. QR-code fusion and intensity-augmented matching each patch one specific gap rather than replacing the underlying algorithm. Choosing among them isn't about finding a universal winner. It's about matching the algorithm's particular tradeoffs to the particular geometry, traffic pattern, and repetition profile of the building the robot actually has to work in. Intensity-augmented matching is exemplified by IaNDT-SLAM (April 2026).