Localization Overview: Why Self-Localization Comes First

Let’s look at Localization (self-position estimation) — the most fundamental yet also the trickiest area in autonomous racing. Knowing where your car is on the track is the single starting point for all of the perception, planning, and control that follow.

Why Localization Matters So Much

Almost every module in the racing stack implicitly assumes it knows “where am I on the track right now.” So when localization wobbles, that error quietly propagates all the way down to the modules behind it.

This is exactly where simulation and reality diverge.

• In simulation you can know the ground-truth pose, so you can test planning/control algorithms cleanly, free of position error.
• But a real vehicle has no ground truth. Localization error flows straight into detection → prediction → planning → control, so you can’t even tell whether a failure came from a bad planning algorithm or from a wrong position. In other words, if localization is shaky, you can’t even evaluate the upstream algorithms.

How widely does it reach? Unless you drive purely reactively (e.g., reacting only to the walls), almost no module avoids consuming the pose.

• Detection — to split inside/outside the track with a map, as in Grid Filter, your pose must be accurate. A wrong pose shifts the whole map, mistaking a real obstacle for a wall / a wall for an obstacle.
• Representation (frame) — the $(s, d)$ of Frenet coordinates is computed from your position on the reference line. If the pose drifts, “ahead/behind” and “inside/outside” judgments shift wholesale.
• Global / Local Planning — to follow a pre-optimized racing line you must know where you are on that line, and local decisions like avoidance/overtaking are ultimately made relative to your own position.

In short, localization is the layer that sits at the very bottom of the stack. Even a few centimeters of position error gets amplified down the pipeline, so “before you build anything else well, you must be able to trust your position” is the first principle of the racing stack.

The Prerequisite for Localization: Map and SLAM

To localize, you need a map as prior knowledge, and to build that map you first have to run SLAM. SLAM stands for Simultaneous Localization And Mapping — a technique where the robot estimates its own position while simultaneously building a map of the surroundings. In the racing context, you can simply think of it as mapping.

The map you build determines, by its format, which localization algorithm you can use afterward.

Map Formats and Their Localization Methods

The three map formats commonly used in 2D racing, and the localization method that matches each.

Occupancy Grid (.png + .yaml)

The most common map format, dividing space into a grid and marking each cell as occupied/free. It’s mostly used with Particle Filter–family localization (AMCL, etc.). → Particle Filter (Motion model), Particle Filter (Measurement model)

Submap (.pbstream)

The submaps produced during SLAM, accumulated and aligned. Used with Cartographer- or slam_toolbox-based localization.

Point Cloud (.pcd)

The point cloud of LiDAR points accumulated as-is. Mostly used with scan-matching–family localization (ICP, NDT, etc.).

Wrap-up

Localization is the layer whose trustworthiness must be secured first in the racing stack. Position error quietly propagates into detection, planning, and control, dragging down (or even making it impossible to evaluate) everything else no matter how well it’s built.

• Prerequisite: you need a map, and the map is built by SLAM (mapping).
• Choice: the map format (Occupancy Grid / Submap / Point Cloud) decides the downstream localization algorithm (Particle Filter / Cartographer / Scan Matching).

The posts that follow cover each approach — mapping, Particle Filter, Cartographer, and 2D ICP — one by one in detail.