Nuro: Autonomous Delivery Vehicles and the Challenge of Low-Speed Safety

A Different Animal

The popular mental model for autonomous vehicles runs something like this: highway Autopilot, urban robotaxi, and somewhere further down the road, full driverless deployment. Nuro doesn’t fit that model at all, and that misfit is the point.

Nuro builds purpose-built autonomous delivery robots—compact, low-speed, occupant-free vehicles designed to move consumer goods through residential and light commercial streets. The third-generation vehicle, the R3, weighs roughly half of a compact car and is designed to travel at speeds that make a 25 mph school zone feel fast. It carries no human beings and never will. That single design constraint reshapes every safety obligation downstream.

Understanding what Nuro is actually building, and why the systems engineering behind it is harder than it looks, requires setting aside the robotaxi frame entirely.

What Nuro Is Actually Building

Founded in 2016 by former Google self-driving engineers Dave Ferguson and Jiajun Zhu, Nuro started from an observation that autonomous vehicle development was almost entirely oriented around moving people. The commercial opportunity in goods delivery—and the distinct engineering tractability of a vehicle not required to protect a human occupant at highway speed—was underexplored.

The R1 and R2 vehicles established the design language: narrow footprint, bilateral cargo compartments, no steering wheel, no pedals, no seat. A road user who encounters Nuro’s vehicle is not a passenger; they’re a pedestrian, cyclist, or another driver sharing the road. That population, not an in-cabin occupant, is the primary protected class in Nuro’s safety argument.

The R3, announced in 2023, extended that design philosophy with improved sensor redundancy, revised exterior geometry intended to minimize injury severity in the event of a pedestrian contact, and updated thermal and power management. Exterior soft geometry on contact surfaces—an explicit design choice to reduce injury severity rather than just avoid collisions—is an unusual feature for a road vehicle and illustrates how Nuro has embedded pedestrian safety at the hardware level, not just the software level.

Commercial partnerships have included Kroger, Walmart, Domino’s, and FedEx at various points, though deployment scale and geographic scope have shifted with regulatory approvals, operational learnings, and the broader AV industry’s recurring capital discipline cycles.

The Safety Case Is Inverted

Every major AV program has to argue, with evidence, that its vehicles are safer than a reasonable alternative. What changes dramatically between programs is who the vehicle is dangerous to, and under what conditions.

For a robotaxi operating at urban speeds, the safety case covers two populations roughly equally: occupants and road users. For a highway-capable system, occupant safety at crash speed dominates the engineering investment—crumple zones, airbags, and the entire Federal Motor Vehicle Safety Standards apparatus exist to protect the person inside.

Nuro has no occupant. The FMVSS framework, written to protect drivers and passengers, doesn’t map cleanly onto a vehicle that by design has neither. This is not a loophole—it’s a genuine regulatory gap that required formal engagement.

Nuro applied to NHTSA for an exemption from specific FMVSS requirements that presuppose occupant presence: requirements around steering columns, windshields, rearview mirrors, and occupant crash protection systems. NHTSA granted a limited exemption in 2020—the first ever granted for an autonomous vehicle—covering 2,500 units. That exemption was significant not just for Nuro but as a proof of concept that the FMVSS framework could accommodate occupant-free vehicle categories through the existing administrative process, without requiring Congressional action.

The regulatory engagement required Nuro to articulate an affirmative safety argument: not merely that it didn’t need certain occupant-protection features, but that it had compensating measures protecting road users more effectively than a conventional vehicle would. That argument covered sensor coverage, exterior geometry, speed operating limits, and the ODD constraints baked into deployment.

The exemption framework, rather than SAE level certification or any emerging federal AV standard, has been the operative regulatory pathway. That’s worth noting for any systems engineering team trying to understand how AV safety cases actually reach regulators—formal standards are still catching up to the deployment realities.

Low Speed Is Not Low Complexity

The instinctive reaction from engineers who haven’t worked low-speed AV programs is that slower means simpler. That instinct is wrong in the ways that matter.

Urban residential streets—the environment Nuro operates in—present an adversarial combination of uncontrolled actors, inconsistent infrastructure, and edge cases that are rare enough to be statistically undercounted but common enough to occur in regular operations. Children chasing a ball into the street. Elderly pedestrians with unpredictable gait. Cyclists occupying ambiguous lane positions. Delivery vehicles parked in ways that force ad hoc routing decisions. None of these are novel observations; every urban AV program deals with them.

What makes Nuro’s situation distinctive is the kinematic regime. At 25 mph or below, the vehicle has shorter stopping distances but also operates in environments where pedestrians and cyclists are more densely distributed and more likely to share the immediate roadway. A highway AV at 65 mph deals with fewer proximate road users but requires massive braking distance reserves. A Nuro vehicle at 15 mph might have a cyclist pull alongside mid-block, a dog off-leash at the curb, and a child on a scooter at an uncontrolled intersection, all simultaneously.

Sensor suite design reflects this. The vehicle’s perception system must maintain reliable coverage of the immediate surround—not just the path ahead—because the threat geometry is essentially omnidirectional at low speed in dense pedestrian environments. Blind spot management that matters primarily for highway lane changes becomes critical at sub-20 mph neighborhood intersections.

The operational consequence is that Nuro’s ODD definitions are highly granular. Not just “urban streets” but specific weather windows, street classifications, time-of-day constraints, and geographic geofences. Deploying inside a tightly defined ODD is both a safety strategy and an honest acknowledgment that corner cases outside the ODD are not yet validated.

The Systems Engineering Reality Behind Deployment

Running an autonomous delivery operation at commercial scale—even limited commercial scale—is not primarily a perception-and-planning problem by the time vehicles are in customer hands. It’s a systems integration and operational continuity problem.

Nuro’s vehicles operate as part of a wider sociotechnical system: the vehicle itself, a remote monitoring and assistance capability, a fleet management layer, a route-planning engine integrated with retailer order systems, and a field operations team managing maintenance and dispatch. Each of those layers has its own requirements, its own failure modes, and its own dependencies on the layers above and below.

The requirement traceability problem in this context is genuinely difficult. A safety requirement that reads “vehicle must stop safely when perception confidence falls below threshold X” fans out into hardware requirements on the sensor suite, software requirements on the perception stack, operational requirements on the remote monitoring response time, maintenance requirements on sensor calibration intervals, and environmental constraints on the ODD definition. Keeping those relationships coherent—and keeping them coherent as the vehicle design evolves across generations and as software updates deploy to a live fleet—is not a problem that spreadsheet-based requirement management handles gracefully.

This is the domain where modern systems engineering tooling earns its keep. Graph-based traceability—where a change to a safety requirement propagates visibly through its dependent hardware, software, and operational requirements—is qualitatively different from a document hierarchy where those dependencies are implicit. For a company like Nuro, where the safety case must be defensible to a federal regulator on an ongoing basis, the ability to demonstrate that a design change didn’t break the requirement chain is operationally significant, not just good practice.

Tools like Flow Engineering, which approach requirements as a connected model rather than a document set, are purpose-built for this kind of multi-layer traceability. The difference matters most exactly when programs are under pressure: when a software update changes a perception threshold, or when a new ODD condition requires re-validation of a safety argument built on prior assumptions. The question isn’t whether you can find the affected requirements—it’s whether you can find them before something ships rather than after something fails.

What the Safety Case Actually Looks Like for a Regulator

NHTSA’s exemption process required Nuro to produce something close to a preliminary safety case: a structured argument that the proposed vehicle, within its proposed ODD, achieves an acceptable level of risk for road users despite departing from conventional FMVSS requirements.

That argument had several components. The kinematic argument: lower mass and lower speed reduce kinetic energy at impact, reducing injury severity probability. The exterior geometry argument: the vehicle surface is designed to minimize head injury criteria on contact, consistent with pedestrian-protection engineering principles developed for conventional vehicle front-end design. The sensor argument: the coverage and redundancy of the perception system provides detection capability equivalent to or better than a human driver for the specific scenarios relevant to low-speed urban operation. The ODD argument: the operational constraints prevent the vehicle from encountering the scenarios for which the safety case would be weakest.

What makes this interesting from a systems engineering perspective is that the ODD argument is load-bearing. The safety case is not universal—it’s conditional on the vehicle operating within its defined domain. That’s a tighter constraint than it sounds. An ODD defined for dry, daylight, residential streets in mild climates requires active enforcement: geofencing, weather monitoring, and the organizational discipline to pull vehicles when conditions move outside the envelope.

That organizational discipline is itself a systems requirement. The system isn’t just the vehicle—it’s the vehicle plus the operational infrastructure that keeps the vehicle inside its validated boundary. Failure to enforce ODD constraints is a safety failure even if the vehicle hardware and software perform exactly as designed.

Honest Assessment

Nuro has built something genuinely novel and navigated genuinely novel regulatory territory to deploy it. The design philosophy—no occupant, low mass, purpose-built for last-mile goods delivery—is a coherent bet on a specific commercial niche with tractable safety engineering, and the NHTSA exemption work was real regulatory innovation, not just paperwork.

The challenges that remain are real too. Scaling past limited geofenced deployments requires expanding ODD coverage in ways that will stress the safety case. The commercial partnerships have been variable in longevity and scope, and the unit economics of autonomous delivery at low deployment density are still being worked out across the industry. The gap between technically demonstrated safety and public acceptance in residential neighborhoods—where residents have opinions about robots rolling down their streets—is not purely an engineering problem.

What Nuro has demonstrated is that low-speed, purpose-built AVs are a viable category with a coherent safety argument that differs fundamentally from the highway-speed and robotaxi cases. The systems engineering behind that argument—the requirement traceability, the ODD management, the safety case maintenance through iterative vehicle generations—is less visible than the vehicles themselves but equally demanding. Getting it right doesn’t generate press releases. Getting it wrong generates federal regulatory scrutiny. That asymmetry is a familiar one to anyone who has worked in safety-critical systems development, at any speed.