INSIGHTS
"Infrastructure-free" has become one of those phrases in autonomous robotics that sounds good in a sales deck and means almost nothing without context. Every company seems to claim it. Few explain what it actually requires, what it actually delivers, and — most importantly — what it actually costs when it's done wrong.
This is our attempt to make the term mean something again.
At Thoro, infrastructure-free navigation is a core architectural commitment, not a marketing position. It shapes every decision we make about sensing, compute, localization, and deployment. Understanding what it actually requires is the most useful thing we can share with technical evaluators, OEM partners, and operators trying to make sense of an increasingly crowded market.
What "infrastructure" means in this context
To understand infrastructure-free navigation, you first need to understand what it's replacing.
Traditional automated guided vehicles (AGVs) are still very common in manufacturing and heavy logistics. They require some form of physical infrastructure to tell the robot where it is and where to go. The classic approaches are:
Magnetic tape or embedded wires. A path is literally laid out on the floor. The robot follows it. Simple, reliable, and completely inflexible. Want to change the route? Pull up the tape. Every facility modification is a project.
Reflective markers or QR code grids. Better than tape, but still requires someone to install markers throughout the facility at precise intervals. In a real warehouse, where forklifts bump into things, shelving gets reconfigured, and walls get painted. Thus, maintaining that marker grid is a continuous operational burden.
Fixed reference points (LiDAR beacons). A step further: install retroreflective targets or active beacons at known positions. More accurate than markers, but the infrastructure cost is real. Typically $50,000–$200,000 for a medium-sized facility, and the same maintenance problem applies.
Infrastructure-free navigation eliminates this entire category of problem.
How it actually works: the sensor stack
Infrastructure-free navigation requires the robot to understand its environment entirely from onboard sensors — no external references. The robot has to answer two questions constantly, simultaneously: where am I? and what's around me?
The way we approach this at Thoro uses a multi-modal sensor fusion architecture. The core components:
3D LiDAR. A spinning or solid-state laser scanner that generates a dense point cloud of the environment at high frequency. The robot sees a full 360-degree representation of everything within range: walls, shelving, pallets, people, other machines. This is the primary localization sensor and the primary obstacle detection sensor. The same hardware that tells the robot where it is also tells it what's in the way.
The key advantage of 3D over 2D LiDAR is what it sees when objects are partially occluded. A 2D scanner at a fixed height sees nothing below or above its scan plane. A pallet positioned at an unusual height, a low obstacle on the floor, a raised dock plate. These can be invisible to a 2D scanner. 3D LiDAR eliminates these potential blindspots.
Depth camera (RGB-D). A camera that captures both color and depth information for every pixel. Where LiDAR excels at geometric structure at range, a depth camera provides dense, high-resolution detail at close range. The combination is particularly important for task-level awareness: recognizing pallet entry points, identifying dock doors, reading scene context that LiDAR alone can't resolve.
IMU. A 6-axis sensor measuring acceleration and rotation rate. The IMU doesn't tell the robot where it is, it tells the robot how it's moving, at very high frequency. When a wheel slips, when the robot hits a floor crack, when it accelerates through a turn. The IMU catches these events and helps the localization algorithm stay coherent between sensor updates.
AI vision models. Sensor data alone isn't enough to understand what the robot is looking at. We run purpose-built, production-validated AI models on top of the sensor data for specific recognition tasks: pallet corner detection for pickup alignment, person detection for dynamic safety zones, ground plane detection for traversability assessment. These are trained on real warehouse data and continuously refined through deployment.
The key word in all of this is fusion. Any one of these sensors alone is insufficient. Together, with a localization algorithm that knows how to weight each source appropriately and handle sensor noise, they produce a coherent, robust understanding of the robot's position and environment.
SLAM: the algorithm that ties it together
The localization and mapping algorithm we use is a variant of Simultaneous Localization and Mapping (SLAM). The name describes the core challenge: how do you build a map of an environment you don't know while simultaneously using that map to figure out where you are in it?
SLAM is a well-studied problem in robotics, with decades of research behind it. The novel work isn't in the algorithm's basic structure, it's in making it work reliably in the specific, messy conditions of real warehouses: dynamic environments where people and machines are constantly moving, facilities that change their layout seasonally, floors with reflective surfaces that confuse LiDAR, dense shelving that creates long corridors with geometric ambiguity.
Our multi-modal approach uses both LiDAR and camera data in a tightly coupled system. LiDAR provides the geometric structure that anchors localization. Camera data provides the texture and appearance information that disambiguates scenes that look geometrically similar. An empty aisle on the east side of the building looks a lot like an empty aisle on the west side. Unless you're also looking at the signs on the shelves, the ceiling features, the subtle environmental differences that a camera captures and LiDAR doesn't.
On-edge compute: why the robot can't phone home
Here's a design decision that matters more than it sounds: all of this processing runs on the robot itself, not in the cloud.
This is what "on-edge" means in practice. The LiDAR processing, the sensor fusion, the SLAM algorithm, the AI model inference, the path planning, the obstacle detection. Every safety-critical decision the robot makes happens on the compute hardware mounted to the machine. Our platform uses NVIDIA Jetson Orin-based compute, which gives us enough onboard processing power to run the full autonomy stack at the update rates real-time navigation requires.
Why does this matter? Three reasons.
Reliability. Wireless networks in warehouses are notoriously unreliable. In certain facilities, getting consistent, quality WiFi coverage can be genuinely difficult. A robot that depends on cloud connectivity for navigation decisions will stop or behave erratically when connectivity drops. A robot that runs autonomy on-edge keeps moving regardless of network conditions.
Latency. Safety decisions happen in milliseconds. When a person steps in front of a moving robot, the robot needs to respond in tens of milliseconds, not hundreds. Round-trip latency to a cloud server is too slow for safety-critical responses. On-edge compute eliminates latency as a safety risk.
Deployment simplicity. If your robot requires a specific network configuration, VPN access, cloud account setup, and connectivity validation before it can operate, your 1–3 day deployment becomes a 3–6 week IT project. On-edge compute means the robot can operate from day one in any environment, on any network, and cloud features layer in afterward without blocking go-live.
What this means for deployment economics
The combination of infrastructure-free navigation and on-edge compute changes the fundamental economics of an autonomous deployment.
No upfront infrastructure cost. No tape. No markers. No beacons. No modification to the physical facility.
No ongoing infrastructure maintenance. The hidden cost of infrastructure-dependent systems is the long tail of maintenance (markers that need replacing, beacon batteries that die, tape damaged by forklifts, calibration that drifts). Infrastructure-free systems don't have this cost category.
Faster adaptation to facility change. When a facility reconfigures its layout, a Thoro-powered robot can easily re-map rather than requiring a full re-survey. The operational cost of change is dramatically lower.
A shared map that compounds. Because our localization isn't tied to external infrastructure, the map the robot builds is portable. A new machine type dropped into an existing deployment inherits the existing map immediately.
What it doesn't mean
It's worth being direct about what infrastructure-free navigation doesn't solve, because honest technical communication is more useful than marketing.
It doesn't mean zero setup. Every deployment requires an initial mapping session (typically 30min - 1 hour of the robot moving through the facility building its initial understanding of the space). This is faster than installing physical infrastructure, but it's not zero.
And it doesn't mean the rest of the deployment is trivial. The sensor stack and localization are the foundation, but workflow integration, WMS connectivity, operator training, and ongoing support are what determine whether a deployment actually changes the operation.
Infrastructure-free isn't a feature. It's a prerequisite for building autonomy that actually scales.
