Skip to the lesson
FixTheRobot Explore Robotics / Localization & SLAM / M8 Advanced SLAM and Research / M8-T9

Localization & SLAM · Theory · M8

M8-T9 — Current Research Directions

A field is easier to join if you know which parts are settled, which are promising and which are unsolved, and how to tell them apart in a paper.

  • Lesson 9 of 9
  • Module 8: Advanced SLAM and Research
  • Theory · research
  • About 9 minutes to read

This is the last theory lesson of the advanced module. It is not a list of papers to memorise, because any such list is dated within months. It is a map: which parts of SLAM can be treated as engineering, which are research with real but limited evidence, and which are genuinely open, with the primary sources for each. It ends with a checklist for reading a SLAM paper critically, since that skill outlasts any particular method.

Learning objectives

After this lesson, you should be able to:

  • Classify a SLAM technique as established, demonstrated in research, or open, and justify the classification with evidence.
  • Describe the main open problems: guarantees, long-term operation, uncertainty, robustness and evaluation.
  • Explain what certifiable back ends and foundation-model priors are aiming at, and what is shown so far.
  • Read a SLAM paper critically using a checklist and avoid common misreadings of benchmark results.

The problem and the intuition

Cadena et al. (2016) described three ages of SLAM: the classical age (1986 to 2004: probabilistic formulations and filters), the algorithmic-analysis age (2004 to 2015: sparsity, observability, convergence, the pose-graph and factor-graph machinery of Module 4), and proposed that the field was entering a robust-perception age: operating for long periods, at scale, in difficult and changing conditions, with performance guarantees and with task-driven representations. The decade since has been spent partly on this agenda and partly on the arrival of learning, which neither fits one of the earlier ages nor replaces them.

A practical way to find your place: a technique is established if independent groups use it in products or long field campaigns and its failure modes are documented. It is demonstrated if several research groups reproduce benefits on standard benchmarks. It is open if the basic question (when does it work? how do I know it has failed?) lacks an accepted answer. The same name, “SLAM”, covers all three.

Judge a claim by the evidence for it: deployed and documented, reproduced on benchmarks, or shown once. Open problems are those where we cannot yet say when the method will fail.

Established practice and the research frontierThree bands from the bottom: established practice that is widely deployed, demonstrated research systems, and open problems. Items move upwards in maturity over time.Established and deployedpose graphs · EKF/VIO · ORB-SLAM · LOAM family · Nav2 + SLAM Toolbox Demonstrated in researchlearned features · DROID-SLAM · distributed multi-robot · Gaussian-splatting SLAM Open problemslifelong change · uncertainty and guarantees · scale · failure prediction · evaluation maturity
A rough map of maturity; items drift upwards as evidence accumulates.

The map: established, demonstrated, open

Problem. Place techniques on the maturity scale, identify the open questions, and read new work critically.

Assumptions. The classification below reflects the literature to the time of writing and the authors’ reading of it; it is a judgement, not a measurement. Check the dates and the newest evaluations before relying on it.

Established (deployed, documented, failure modes known)

  • Factor-graph and pose-graph back ends with sparse solvers (g2o, GTSAM, Ceres; Kümmerle et al., 2011; Dellaert and Kaess, 2017).
  • Filter and sliding-window visual-inertial odometry (MSCKF, OKVIS, VINS-Mono, OpenVINS; M6-T7).
  • Feature-based visual SLAM with loop closing and relocalisation (ORB-SLAM family; Campos et al., 2021).
  • LiDAR odometry and mapping (LOAM and descendants, LIO-SAM, FAST-LIO2; M5).
  • 2D SLAM with SLAM Toolbox or Cartographer and navigation stacks (M7).
  • Standard metrics and benchmarks (M8-T8).

Demonstrated in research (reproduced benefits, limited deployment)

  • Learned front-end components: keypoints, matchers, place recognition, depth priors (M8-T6).
  • Dynamic- and semantic-aware SLAM (M8-T1, M8-T2).
  • Decentralised multi-robot SLAM with robust outlier rejection (M8-T3).
  • Degeneracy-aware registration (M8-T4).
  • Neural-field and Gaussian-splatting SLAM with RGB-D input on small scenes (M8-T7).
  • Differentiable and learned bundle adjustment (DROID-SLAM).

Open problems

1. Guarantees. Most back ends solve a nonconvex problem by local descent and can converge to wrong minima without notice. Certifiable methods address this for specific problems: SE-Sync (Rosen et al., 2019) solves pose-graph optimisation with a semidefinite relaxation and returns a certificate of global optimality when the relaxation is tight, under moderate noise. Extending certifiable estimation to outliers, to the full SLAM problem with landmarks and to real-time use is active (Rosen et al., 2021, give a survey).

2. Long-term and lifelong operation. Maps made on one day fail on another: seasons, lighting, furniture, construction. Experience-based approaches (Churchill and Newman, 2013) keep several “experiences” of a place; map maintenance and change detection (M8-T1) are young. There is no accepted benchmark for years-long deployments.

3. Uncertainty and failure prediction. Estimators’ covariances are often over-confident; learned components give miscalibrated confidence; the system rarely knows that it has failed. Detecting failure (degeneracy in M8-T4, inconsistency in M8-T8) in a principled, real-time way is open.

4. Scale and resource limits. City-scale and building-scale maps with dense semantic content strain memory and bandwidth (M7-T8, M8-T3). Resource-aware, task-aware representations are being explored.

5. Representations for tasks. What a robot needs from a map depends on the task (navigation, manipulation, interaction). Scene graphs and metric-semantic hierarchies (Hughes et al., 2022) are one direction; neural fields (M8-T7) another; there is no consensus.

6. Foundation models. Large pretrained vision models supply features and priors that transfer across domains. For example, AnyLoc (Keetha et al., 2023) uses self-supervised foundation features for universal place recognition, and models such as DUSt3R (Wang et al., 2024) predict dense pointmaps and relative poses from image pairs, which later systems use as priors for SLAM. These results are recent, impressive on benchmarks, and not yet characterised for failure behaviour or long-term operation; treat them as research.

7. Evaluation. Benchmarks are few, small and prone to over-tuning; protocols vary (M8-T8). Standards for reporting failures, uncertainty and task-level performance are lacking.

paired comparison over sequences k
dk=ATEnew(k)−ATEbase(k);d_{k}=\mathrm{ATE}_{\text{new}}(k)-\mathrm{ATE}_{\text{base}}(k);
report median⁡(d), #{k: dk<0}K, and the spread of dk\text{report}\,\operatorname{median}(d),\,\frac{\#\{k:\,d_{k}<0\}}{K},\,\text{and the spread of}\,d_{k}
certifiable
an algorithm that returns an a posteriori proof that its solution is globally optimal (when it is).
lifelong SLAM
mapping and localisation over very long periods in a changing environment.
scene graph
a hierarchical map of objects, places and rooms with relations.
foundation model
a large model pretrained on broad data and adapted to many tasks.

How to read a SLAM paper critically

A checklist for reading SLAM papers
QuestionWhat to look for
What is the claim, and what evidence supports it?Controlled comparison against strong baselines, on several datasets, with ablations
What are the assumptions?Static scene, known calibration, GPU, scale known, ground truth available at test time
Is the protocol fair?Same alignment, same data, tuned baselines, same hardware, repeated runs, failures counted (M8-T8)
What fails?Failure cases shown; limitations section; sequences where the method loses tracking
Is it reproducible?Code and configuration released; independent reproductions
What is the cost?Compute, memory, latency, power, training data
Does it matter for a task?Task metrics (navigation success), not only trajectory error

A worked example: classifying a claim

  1. The claim. A new paper reports that a Gaussian-splatting SLAM system “outperforms ORB-SLAM3 by 40% in ATE” on seven indoor RGB-D sequences.
  2. Check the protocol. Is ORB-SLAM3 run in RGB-D mode or monocular? Is ATE computed with the same alignment? Are the numbers averaged over runs, and is a failed run counted? The result is much weaker if the baseline is run in a mode it was not designed for, or if only the best of five runs is reported for the new method.
  3. Check the assumptions. RGB-D input, a desktop GPU, short sequences (hundreds of frames), small rooms, static scenes. The claim holds in that setting. It says nothing about outdoor, long, or dynamic operation, which is where classical systems have years of evidence.
  4. Classify. Several groups have reproduced Gaussian-splatting SLAM results on the same datasets: “demonstrated in research”. No long-term or large-scale field evidence: not established. Whether it fails safely: open.
  5. Decide. For a product that needs a dense appearance map of an office, evaluate it with your sensor and a geometric check. For navigation, keep a classical tracker and use the neural map as an additional layer (M8-T7).
  6. A statistical sanity check. If the improvement is 40% on seven sequences with per-sequence differences ranging from −20% to +80%, the variation between sequences is as large as the average gain: a larger or paired test is needed before concluding. Report medians and the number of sequences where it is worse.

The capstone report in the last module asks you to apply this checklist to your own results.

Engineering implications and limitations

Engineering implications

  • Build on established components, and isolate research components behind interfaces and monitors, so that they can be replaced or disabled.
  • Prototype research ideas on your own data before committing; keep the baseline you trust running in parallel.
  • Invest in evaluation and logging. The ability to measure failure rate on your own data is worth more than any single algorithm choice.
  • Prefer methods with failure indicators (degeneracy, inlier counts, consistency) over those that fail silently.
  • Track the literature through surveys and benchmarks and prefer independent re-evaluations to self-reported tables.
  • Plan for change. Models, datasets and libraries move fast; pin versions and record them with every result.

Limits

This classification is a snapshot and a judgement; others may place techniques differently. The pace of change in learning-based and foundation-model SLAM means that statements about their limits may be out of date quickly. The sources cited are surveys and primary papers up to the time of writing; for current results consult recent proceedings (ICRA, IROS, RSS, CVPR, ICCV, ECCV, T-RO, IJRR) and check for later independent evaluations.

Common misconceptions

“SLAM is solved.”

Specific settings (static indoor, good sensors) are mature; long-term, large-scale, dynamic, failure-aware operation is not.

“Newer is better.”

Newer systems often win on a benchmark at the cost of compute and robustness; established systems have wider evidence.

“A certifiable method is a better SLAM.”

It gives optimality guarantees for specific formulations; it does not fix bad data association or sensor failure.

“Foundation models make geometry unnecessary.”

They provide strong priors, but geometric verification remains the way to check them.

Engineering takeaways

  1. Classify a technique by its evidence: established and deployed, demonstrated in research, or open.
  2. Established: factor-graph back ends, VIO, feature-based visual SLAM, LiDAR-inertial odometry, 2D SLAM with Nav2. Demonstrated: learned front ends, semantic and dynamic-aware methods, decentralised multi-robot SLAM, neural-field SLAM on small scenes. Open: guarantees, lifelong operation, uncertainty and failure prediction, scale, task-driven representations, evaluation.
  3. Certifiable estimation (SE-Sync) offers proofs of optimality in restricted settings.
  4. Foundation-model priors are promising and unproven for long-term, failure-aware operation.
  5. Use a checklist: claim, assumptions, protocol, failures, reproducibility, cost, task relevance.

References and further reading

Surveys and primary papers. The lists in the text separate established, demonstrated and open items; check for later work.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

Question 1

A paper claims a new SLAM beats a baseline by 30% on one dataset. Name three questions to ask before accepting it.

Explanation

Is the baseline run in its intended mode and tuned? Is the evaluation protocol identical (alignment, runs, failures)? Do the assumptions (sensor, hardware, scene type, sequence length) match mine? Also: is there more than one dataset and are failure cases shown?

Question 2

What does a certifiable back end like SE-Sync offer that a standard Gauss–Newton pose-graph solver does not, and what does it not fix?

Explanation

It returns a certificate that the solution is the global optimum when the relaxation is tight, so a wrong local minimum is detectable. It does not fix wrong data association, outlier loop closures or sensor failure; those corrupt the problem it solves.

Question 3

Why is “lifelong mapping” still classified as open, even though people have mapped the same building many times?

Explanation

Repeated mapping with fresh maps is easy; maintaining one map consistently through years of change, with unattended operation, detection of change and a benchmark to compare methods, is unsolved. The evidence is limited and there is no accepted evaluation protocol.

What’s next

The labs of this module apply these ideas on small problems: removing dynamic objects from a map, evaluating trajectories fairly, handling a feature-poor corridor and reporting degradation under controlled failures.

Next lesson

M9-T1 — End-to-End SLAM System Architecture

Design a complete SLAM architecture from sensor choice to evaluation and deployment.

Nothing below is required to finish this lesson.