TL;DR: Physical AI is broader than robotics, but robotics is where the hard problems live. The outdoor location problem is largely solved. Indoors is a patchwork. The real challenge is the threshold between them — and the key insight is that SLAM, by default, is an entirely relative navigation skill. Decoupling the mapping and localization processes, and anchoring that map in a global frame with RTK, is how you fix it.
This is a recap of a recent Point One livestream with CEO Aaron Nathan and COO Tom Weeks. Watch the full conversation below.
Physical AI vs. Digital AI: Why the Context Layer Is Different
Most computing exists in a purely digital and deterministic world. The physical world operates differently — far less deterministic, much more complicated, and everything exists in the context of probabilities, statistics, and uncertainty.
Physical AI is any system that influences the physical world or represents it digitally. A map is the simplest example. A rideshare algorithm dispatching a human driver is another. What makes something Physical AI is the sensing, reasoning, and digitization happening in the control layer — not whether the action is taken by a motor or a person.
Large language models came on fast because the digital world was already organized. The second chapter is harder: interacting with and understanding a physical world that is not yet fully digitized, and certainly not in real time. Today’s most capable robotic systems are impressive within their immediate context — but the broader context layer, especially location, is still fragmented. That is the problem this post is about.
Location Is Context
The context window is what transforms a general-purpose LLM into something useful for a specific problem. Location does the same thing for a robot or autonomous system — it is a context layer for Physical AI.
Location is an amplifier. Once you know where you are, the problem shifts from “where am I” to “what do I do” — a much simpler problem. A robot that knows its precise position can return to exactly where it planted a seed months ago without ever sensing it again.
Every robot building its own isolated map is an inefficient architecture. A map that only one robot understands, in a coordinate system only that single robot uses, does not provide context to anyone else on the floor.
Outdoors Is Largely Solved. Indoors Is Not.
The outdoor location problem has a clean solution. GNSS provides a globally consistent coordinate system. RTK corrections amplify that to centimeter accuracy. The cost curve has followed everything else in the industry, unlocking agriculture, autonomous vehicles, delivery, construction, and more.
Indoors is a different story. Three robotic systems on the same warehouse floor often run three different maps, in three different coordinate systems, with no common reference frame. Each operates as an island. An autonomous mobile robot (AMR) — the kind that moves pallets or picks orders — knows where it is relative to its own starting point. The forklift knows the same. They cannot exchange precise position information without a common frame.
Most indoor localization is a patchwork — laser-based SLAM, UWB (Ultra-Wideband) beacons that use radio signals to estimate position, QR code grids — each working within its own domain and failing outside it. None produce a globally referenced coordinate or interoperate natively with the outdoor stack.
The most valuable and difficult capability to build is crossing the indoor/outdoor threshold seamlessly.
SLAM Is Relative by Default — and That Limits What It Can Do at Fleet Scale
SLAM — Simultaneous Localization and Mapping — builds a map of an environment while simultaneously figuring out where you are within it. It improves through loop closure: when a robot recognizes a previously visited location, it corrects accumulated drift in its position estimate. SLAM works entirely from the robot’s own sensors with no external positioning signal, which is both its strength and its core limitation.
By default, SLAM is an entirely relative navigation skill.
The robot starts at zero, zero and accumulates position deltas from that origin. A LiDAR-equipped robot — LiDAR being a sensor that measures distance by firing laser pulses and timing their return — tracks how wall scans shift as it moves, building up a picture of where it has been within its own frame. But that tells you nothing about global position.
With multiple robots operating, you have no global context. Each robot has its own relative frame and cannot merge maps or coordinate precisely without significant additional work.
Decoupling SLAM: How Global Frame Anchoring Works
Standard SLAM does two things at once: it builds a map and localizes against it simultaneously, in real time, as the robot moves. The insight behind decoupling is straightforward — you do not have to do both at the same time.
Instead, run SLAM once as a dedicated offline mapping pass to build the map: a human walking through the environment with a sensor, for example, coached to take a path that helps the algorithm converge well. You now have a static map. In production, the robot localizes against that pre-built map rather than building and localizing simultaneously.
The reason this matters: when SLAM runs as a dedicated offline pass, you can feed RTK GPS into it during that step. RTK provides outdoor centimeter-accurate positioning referenced to a global coordinate system. With RTK active during the mapping pass, every point in the map gets tagged with a global coordinate — latitude, longitude, altitude. The map is no longer relative. It is anchored to the same reference frame as the outdoor stack.
Separating — or “de-simultaneozing” — the localization and mapping processes also produces richer maps. Separating the two processes allows “a lot more richness in that map” and, critically, allows other inputs like RTK to be brought in.
Every robot that localizes against that globally anchored map inherits a globally referenced position. Multiple robots on the same map are automatically in the same coordinate frame — which is the prerequisite for fleet-level coordination.
The Threshold Problem
The hardest challenge is not building a good indoor map. It is aligning two different coordinate systems at centimeter accuracy when a robot crosses a doorway.
A perfectly square building mapped with SLAM will rarely produce a perfectly square map. Integration drift — the accumulation of small errors over distance — means the map comes out slightly twisted even after loop closure. Shifting that map to a latitude and longitude is not enough, because the map itself has internal distortion. You cannot align it to the global frame with a simple translation and rotation. You have to stretch it — warping the local map into the canvas of the global frame. It is like a twisted 3D print: the shape is approximately right, but the geometry has been subtly deformed.
That is hard to do correctly at centimeter-level accuracy. There are mathematically rigorous techniques and less sophisticated ones that work well enough for some cases. If you are building a whole robotic system, you will make a lot of those trades — there are a million other problems to solve at the same time.
What is becoming clearer: more companies are figuring out how to solve the threshold problem generically and make it useful for everyone.
The Multiplayer Superpower
Once every device in a fleet shares a globally referenced base map, robots can coordinate in real time with spatial precision without needing to perceive each other directly. An AMR heading toward aisle 7 knows the forklift is already there — not because it can see it, but because both machines report to the same coordinate system. Human workers in the same space can participate in the same frame. Safety margins become proactive rather than reactive.
This is what location as a shared context layer actually enables at fleet scale. Just as a shared context window gives multiple LLM calls a common understanding of the same problem, a shared globally referenced map gives every device in a fleet a common understanding of the same physical space.
Where the Market Needs to Go
The pieces exist: SLAM for map building, RTK for outdoor global anchoring, and decoupled localization pipelines that use that globally anchored map as their reference. What is missing is the infrastructure to solve the threshold problem generically — once — and make it available to every device in every fleet.
Right now every robot team solves this independently and ends up with incompatible systems that cannot share spatial context. The outdoor stack already got there — a globally consistent, centimeter-accurate coordinate system that any device can anchor to. That is what needs to happen indoors too, and at the threshold between them.
Point One’s RTK Network delivers the outdoor centimeter-accuracy foundation that makes global frame anchoring possible. Try it free.