One posterior, not a pipeline: conventional SLAM vs JVS-SLAM
Conventional feature-based SLAM is a relay race: a front-end decides data associations, then a back-end optimizes the graph it was handed. When the baton is dropped — one wrong match — the optimizer polishes a wrong map with full confidence. JVS-SLAM refuses to drop the baton: it keeps trajectory, map and associations inside one joint vector-set posterior, optimizes every plausible explanation, and lets Bayes decide the weights.
01The same robot, the same data — two philosophies
A robot drives one loop and comes home. Odometry has drifted, and near the start sit two look-alike landmarks (same appearance, different places). At the loop closure the robot gets two measurements: an ambiguous one, and a distant unambiguous one. Step through what each paradigm does with exactly the same evidence.
Conventional — decide, then optimize
JVS-SLAM — hypothesize, optimize, reweight
Use ← → arrow keys, the dots, or Play all. Steps 1–3 are identical on both sides — the paradigms only diverge once a decision is (or isn’t) made.
02The reweighting, in your hands
Step 8’s weights are not magic — each hypothesis is scored by how well it explains everything: geometry (least-squares fit), appearance (descriptors), and detection statistics (probability of detection pD, clutter rate λ). Move the sliders and watch probability mass flow between the three explanations.
03The animation, step by step
The eight steps above, in words — what happens, and why it is the crux of the paper.
04Side-by-side comparison
| Conventional SLAM | JVS-SLAM | |
|---|---|---|
| architecture | detect + describe → hard association → one factor graph | hypothesis set ⇄ graph optimizer ⇄ Bayes weights, in one posterior |
| philosophy | decide first, optimize second | sample, optimize and compare jointly |
| association | one-shot, local evidence (nearest neighbour / best descriptor); ties broken arbitrarily | multi-scan hypotheses kept as a random variable A₁:ₖ; global consistency arbitrates |
| map size | heuristic map management (spawn / delete rules) outside the estimator | map is a random finite set — landmark count is itself estimated (pD, clutter, birth in the likelihood) |
| wrong match | becomes a confident constraint; optimizer warps the map to satisfy it; residual gets averaged away | survives as a low-weight hypothesis (here w≈0.09) and can be revived or killed by later evidence |
| uncertainty | covariance of one linearization point — blind to association ambiguity | mixture over globally coherent explanations — multi-modal; calibration depends on the model |
| failure mode | confidently wrong; recovery requires outlier surgery (switchable constraints, RANSAC, …) | gracefully uncertain; weights shift as evidence arrives |
05Where this lives in the paper
JVS-SLAM maintains the joint density over the trajectory (a vector), the map (a labeled random finite set, so the number of landmarks is uncertain too), and the data associations. Summing over association histories gives the marginal trajectory–map posterior:
Here w(A) = p(A1:k = A | Z1:k), and the weights sum to one. Each association hypothesis A conditions a smooth estimation problem solved by nonlinear least squares (the familiar back-end); its weight w(A) comes from Bayes’ rule and folds in the optimized fit and the set-likelihood terms — detection probability pD, clutter intensity, landmark birth — that conventional pipelines relegate to front-end heuristics. In the animation: step 6 is the “population of hypotheses,” step 7 is the per-hypothesis least squares, step 8 is the reweighting. That is the whole idea: the front-end’s decisions become random variables of the back-end’s posterior.