SLAM

SLAM is localization without the gift of a finished map. You must invent the walls while you use them as evidence. That is the chicken and the egg: you need a pose to put a scan in the world, and you need a map to correct the pose. The algorithms differ in how they keep that joint story consistent as time goes on.

EKF SLAM stuffs robot pose and landmark positions into one big Gaussian. Convenient in a textbook, painful as landmarks multiply: the covariance is dense because everything you ever saw is correlated through your past pose. Particle approaches (FastSLAM-style) factor the problem: each particle is a pose hypothesis with its own easier map. Graph SLAM keeps poses (and maybe landmarks) as nodes and measurements as edges, then relaxes the rubber band when a loop says “you are back.”

Loop closure is the dramatic act. You recognize a place and add a constraint that the two poses are the same place. If the recognition is right, the whole trajectory can snap into a consistent building. If it is wrong, you fold the building in half. This is why feature quality, uniqueness, and the willingness to reject a match matter more here than in a single-frame homework.

Teach SLAM as bookkeeping plus humility. Front-end: odometry, scan matching, place recognition. Back-end: the estimator that swallows those relative measurements. A class that only tunes a back-end on perfect simulated loops has not done SLAM. A class that only runs a package and screenshots a map has not either. Do one tiny 2D landmark example by hand — two poses, two features — and feel the correlation appear.

Then stop. A modern lidar SLAM stack is a career, not a Friday. This masterclass owes you the problem statement, the three families, and a pointer back to the book. The chapter source is SLAM.tex. Read it. Do not ask this site to be the compiled text.