SLAM solves a chicken-and-egg loop: to know where you are you need a map, but to build a map you need to know where you are. Every algorithm below is one historical answer to that loop. Each comes with a step-by-step player — press play, or click through frame by frame, and watch the math happen.
The whole field really moves along two axes: how you represent uncertainty (filter vs. optimize a graph) and what sensor feeds it (range/odometry vs. camera vs. LiDAR vs. learned features). Read top to bottom and you're reading history.
| Algorithm | Family | Back-end (math engine) | Front-end (sensing) | Scales to | The one idea it added |
|---|
Drift is unavoidable — every step adds a little error. The cure is recognizing a place you've already been and snapping the whole trajectory back into agreement. This interactive shows the same path with and without the closing constraint.
As the robot moves, the back-end keeps a chain of relative constraints (“I moved forward 1m, turned 12°…”). Small errors in each link compound into large absolute error — that bend you see is accumulated drift.
When a place-recognition module says “I’ve seen this exact spot before,” it injects a new constraint linking a late pose back to an early one. Now the graph is over-determined: it has more constraints than freedoms.
The optimizer redistributes the contradiction across every pose in the loop — like tightening a slack necklace until the clasp meets. The error doesn't vanish at one point; it's spread thin over the whole trajectory, and the map becomes globally consistent.
This is the heart of every modern system — ORB-SLAM, LOAM, Cartographer all do exactly this on the back-end.