A practical guide to representing, mapping, and programming the physical world for autonomous machines.

A high-definition map is not a prettier Google Maps. It is a machine-readable description of a place, built so a robot can drive through it. Here is what makes a map ‘high definition,’ and why ordinary maps are not enough.

6 min read

Every autonomous machine answers the same four questions: Where am I? What is around me? Where can I go? What am I allowed to do? This mental model is the spine of the entire Handbook.

5 min read

There is no single map of a place. Geographic maps, point clouds, semantic maps, navigation maps, and 3D models all describe the same physical ground differently, each optimized for a different purpose. Understanding why is the conceptual unlock for everything that follows.

5 min read

The pipeline from reality to robot motion has seven stages: Reality, Capture, Representation, Semantics, Rules, Planning, and Motion. This is the master diagram for the entire Handbook. Understand it once and every chapter that follows will feel inevitable.

7 min read

Before a robot can answer ‘where am I,’ you have to decide what ‘where’ means. Coordinates are the address system underneath every HD map, and getting them wrong is the single most common source of catastrophic map failure.

9 min read

Datums, ellipsoids, UTM, and why your map is shifted by exactly 50 centimeters. A practical guide to choosing, configuring, and verifying the coordinate system underneath your HD map.

8 min read

Every HD map begins with a sensor that measures distance. Understanding how LiDAR works, what it captures, and what it does not is the first step in turning raw sensor data into a spatial map.

7 min read

Between the scanner and the first usable scan, someone has to plan the survey, calibrate the rig, capture the site, and verify coverage before the crew packs up. The field half of the pipeline, grounded in Harbor Yard.

10 min read

Precision, relative accuracy, absolute accuracy: what the three words mean in the field, how RTK delivers centimeter readings, and whether a map needs to agree with the earth at all. Grounded in the Harbor Yard survey nail.

8 min read

Back at the workstation: filtering noise and artifacts from the raw cloud, registering multiple scans into one, georeferencing it to world coordinates, and the five-minute quality check that gates the first traced vector.

7 min read

How a robot builds a map while figuring out where it is. SLAM is the chicken-and-egg problem of mobile robotics: the computational engine that turns raw sensor data into a registered point cloud.

4 min read

Every autonomous vehicle asks ‘where am I?’ ten times per second. This chapter explains how scan matching against a known map answers that question, what determines the accuracy of the answer, and what happens when the answer is wrong.

13 min read

A single stop line at Harbor Yard exists across four layers: OSM reference, reality scan, vector map, and custom assets. Understanding why no single layer can do all four jobs is the conceptual unlock for the entire Handbook.

6 min read

OSM is not a high-precision survey. It is the reference layer that gives you the rough layout of a site: roads, buildings, fences, vegetation. So you are not starting from a blank canvas.

4 min read

A robot cannot drive on a cloud of points. Turning raw LiDAR returns into a ground mesh gives the planner a surface it can push against, with normal vectors, traction estimates, and gravity compensation.

5 min read

Not all points are created equal. Separating signal from noise in a point cloud (keeping the rigid landmarks, discarding the parked cars and seasonal vegetation) is what makes localization fast and reliable.

4 min read

A centimeter-perfect local point cloud is useless if it is not anchored to the world. Aligning LiDAR scans to global coordinates is where precision meets position, and where most maps break.

5 min read

A point cloud shows you what is physically there. It cannot tell a robot where it is allowed to drive. The vector format you choose determines whether your map is a drawing or a contract.

8 min read

A point cloud tells a robot where the pavement is. It cannot tell the robot that crossing this particular line is illegal. Lanelet2 exists to answer the two hardest questions: where can I go, and what am I allowed to do along the way?

7 min read

A vector line placed by hand is a guess. A vector line traced from a LiDAR return is evidence. The difference determines whether your robot holds its lane or drifts across the border into oncoming traffic.

7 min read

Standard Lanelet2 is flexible enough to represent the same traffic light three different ways. Autoware cannot handle three different ways. Hardening the map means removing that flexibility and replacing it with a contract the stack can rely on.

5 min read

A precise 3D map of Harbor Yard tells the robot where the pavement ends. It is silent on the most critical part of driving: the rules. Regulatory elements encode the law of the yard into the geometry.

5 min read

A collection of lanelets is a drawing. A collection of lanelets with shared nodes, successor relations, and intersection logic is a map a robot can route through. Topology is the difference between the two.

5 min read

The seven-stage pipeline, now grounded in a repeatable workflow: capture, align, draw, annotate, connect, validate, export. Plus the validation discipline that catches errors before the robot does.

5 min read

A Lanelet2 map is a structured description of a place. What a robot does with it depends entirely on which stack is reading it. This chapter surveys the major autonomy stacks, the map formats they consume, and why this book pins its map-building practice to Autoware.

7 min read

Between your Lanelet2 file and the autonomy stack sits a piece of software that does not negotiate: the map loader. It reads the OSM XML, projects every coordinate into the robot’s local frame, and publishes a binary map the rest of the stack consumes. If it does not get what it expects, the map never reaches the robot.

13 min read

Two of the four questions that organize this book are answered by two subsystems that share a single input: the pointcloud map. Localization matches a live LiDAR scan against the map to place the vehicle. Perception runs a three-stage pipeline of detection, tracking, and prediction to find and forecast every moving thing in the scene.

15 min read

The Lanelet2 map you built finally meets the modules that read it directly: the behavior path planner generates a path from your lanelet geometry and constraints, and the control component turns that path into steering, throttle, and brake commands. Every map element you authored shapes the trajectory the vehicle follows.

9 min read

The robot is behaving strangely. The logs say ‘planner failed to generate trajectory.’ The real error is a lanelet boundary drawn a meter too wide, and it was made three weeks ago by someone who did not know the planner would trust it absolutely.

10 min read