SLAM

SLAM estimates the joint posterior over the entire trajectory and the map, $p(x_{1:t}, m \mid z_{1:t}, u_{1:t})$, from the same predict/update cycle as any Bayes filter — except now correcting the pose also has to correct every landmark correlated with it.

That coupling is exactly what lets a single loop closure retroactively fix an entire trajectory's drift.

Stacking the robot pose and all $n$ landmarks into one state vector makes the covariance matrix $(3+2n) \times (3+2n)$ (2-D case). Every update touches the full covariance, so each step costs $O(n^2)$.

This quadratic growth is why EKF-SLAM alone doesn't scale to large maps — FastSLAM factors the landmarks into per-particle, independent EKFs to avoid it, trading it for particle-count scaling instead.

Front-end: turns raw sensor data into constraints — detect and match features (or scans) frame to frame, estimate relative motion, and decide data association (is this the same landmark/place as before?).

Back-end: takes those constraints and produces a globally consistent trajectory/map — either recursive filtering (EKF-SLAM) or batch nonlinear optimization (pose-graph / bundle adjustment).

Odometry and scan matching alone accumulate error monotonically — the estimated path never closes a real loop. Recognizing a previously visited place (place recognition) adds a new constraint linking the current pose back to that earlier one.

In a pose graph, optimization then redistributes the accumulated error across every pose in the loop, not just the endpoint — a single correct loop closure can snap an entire map back into consistency.

Graph-based SLAM can't keep every past pose in the optimization forever — old poses are marginalized out (folded into a prior/factor over the remaining variables) so the optimization problem stays a bounded size instead of growing with total trajectory length.