The Global Alignment: Reality Meets Reference

You have spent days capturing a pristine point cloud. Every curb is crisp, every pole vertical, the noise nearly nonexistent. You load it into the autonomy stack, initialize, and watch the diagnostic screen report that the robot is currently at latitude zero, longitude zero, the intersection of the Prime Meridian and the Equator, a spot in the Atlantic Ocean the engineers call Null Island.

This is the floating-map problem. A centimeter-perfect local point cloud is useless if it is not anchored to a global reference frame. Without that anchor, your robot knows exactly where the wall is relative to its bumper but has no idea that the wall is on a specific dock in a specific yard. Fleet coordination, traffic rules, and safety interlocks all require a shared answer to where.

The three layers that must agree

An HD map becomes executable only when three layers are in alignment:

Precision (the point cloud). Local, centimeter-accurate geometry from LiDAR. This answers what is physically there.

Semantics (the OSM vector layer). Labels that identify what each cluster of points means. A stop sign, a curb, a gate.

Topology (the Lanelet2 rules layer). How lanes connect, where the right-of-way changes, what the legal boundaries are.

If your precision is offset from your topology (if the point cloud says the stop line is at x=5.0 but the Lanelet2 rule says it is at x=5.5), the robot will plan a path that obeys the rule as written and drives right past the physical line. The rule was followed. The vehicle was not.

How maps end up in the wrong place

The most common alignment failures are not sensor failures. They are configuration errors in the transform pipeline:

Projection shift. Applying a UTM projection incorrectly offsets the entire map by a consistent distance, often 50 cm to several meters. The map looks perfect internally. Every feature is in the wrong place globally. And the robot does not know. It is perfectly localized in a wrong map: every scan matches, every landmark lines up, because the whole map moved together. It is the oneway=yes failure from Chapter 14 in spatial form. Confidence is not evidence of correctness.

Datum mismatch. Your GNSS uses one model of the earth’s shape (WGS84) but your local surveyor used another (NAD83). The resulting offset is small enough to miss during review and large enough to put a robot in a drainage ditch.¹

UTM zone mismatch. Selecting the wrong UTM zone for the site’s longitude can mirror or rotate the map. The warehouse appears on the wrong side of the access road.

Harbor Yard: the 50-centimeter disaster

At the Harbor Yard gate, a faded stop line crosses the pavement. A human might roll through it. A robot relies on the map’s topology to tell it where to stop.

If the map is shifted 50 cm to the left (a common artifact of a misapplied UTM projection), the robot’s internal stop position is now in the drainage ditch beside the road. The robot will drive, confidently, through the physical stop line and into the path of an oncoming cargo tug. It obeyed every rule in its map. The map was simply in the wrong place.

Diagnosing a floating map

When the robot reports a pose that contradicts physical reality, start with the coordinate metadata:

ros2 topic echo /gps/fix
header: {stamp: {sec: 171523400, nanosec: 0}, frame_id: "gps_link"}
status: {status: 0, service: 1}
latitude: 0.0000000
longitude: 0.0000000
altitude: 0.0

Two checks come before the coordinate metadata. First, is the GNSS driver publishing at all? The status: 0 field above means NO_FIX: the receiver has no solution, so the zeros point to an antenna or driver problem, not a projection one. Second, is the transform tree intact? Run ros2 run tf2_tools view_frames and confirm the map → odom → base_link chain has not collapsed; a missing transform strands the robot at the origin of whatever frame it has left. Only when both check out does a robot physically sitting in Ohio while reporting latitude 0.0, longitude 0.0 point to a collapsed coordinate system. Then check the EPSG codes and anchor points assigned to the data before you debug anything downstream.

Try this

[10 min] Harbor Yard sits at approximately 47.6°N, 122.3°W. Determine its UTM zone. Then imagine the map was processed with the UTM zone one number off in either direction. What would the approximate offset be? If the error is systematic (every feature shifted by the same vector), where should you look first in the configuration?

Footnotes

1. The 80/20 rule of global reference: 80% of mappers will use WGS84 and a correctly selected UTM zone and never see a datum shift. The 20% working across survey boundaries or legacy datasets will encounter NAD83, ETRS89 (the European Terrestrial Reference System 1989), or local datums. The symptom is always the same: a perfect map, consistently offset. The fix starts by comparing the EPSG code in your config to the one your surveyor used. ↩