Nuro: The Systems Engineering Complexity Behind Autonomous Delivery Vehicles

Nuro is not building a robotaxi. That distinction sounds obvious, but its implications for systems engineering run deep enough that the two categories of autonomous vehicle program have almost more differences than similarities. Where passenger AV companies spend enormous engineering effort protecting the people inside the vehicle, Nuro’s R-series vehicles carry no human occupants. The protection target flips entirely. The occupant safety case that drives the bulk of conventional automotive safety engineering — crashworthiness, airbags, seatbelts, structural integrity standards — is replaced by something harder to specify: a safety case centered on the people outside the vehicle.

That inversion touches almost every layer of the system. It shapes the physical design, the sensor placement, the failure mode taxonomy, the regulatory strategy, and the operational constraints the vehicle must enforce on itself. Understanding how Nuro navigated these problems offers a useful lens into what systems engineering for unconventional autonomous platforms actually requires.

What Nuro Built and Why It Matters

Nuro was founded in 2016 by Dave Ferguson and Jiajun Zhu, both former Google self-driving project engineers. Their founding thesis was that last-mile delivery, not passenger transport, was the near-term problem most tractable to full autonomy — and that the vehicle form factor should be designed specifically for that mission rather than adapted from a conventional automobile.

The R2, Nuro’s second-generation delivery robot, is roughly half the width of a standard passenger vehicle, stands about 1.8 meters tall, and operates at speeds below 25 mph. It has no steering wheel, no pedals, no seat. The cargo bays open from the side to allow customers to retrieve their groceries or pharmacy orders. The entire vehicle architecture was designed from a blank sheet with the delivery mission in mind, not adapted from an existing platform.

This matters for systems engineering because purpose-built design is an underappreciated advantage. Most automotive safety standards assume a vehicle architecture built around human occupants. When the occupant constraint is removed, an engineering team faces an unusual combination of freedom and uncertainty: freedom to make design choices that conventional vehicles cannot, and uncertainty about which standards and frameworks actually apply.

The Inverted Safety Case

In conventional automotive safety engineering, the primary safety obligation is Federal Motor Vehicle Safety Standards (FMVSS) compliance — a body of regulation that is almost entirely focused on protecting vehicle occupants. Crashworthiness requirements specify what happens when a vehicle hits something. Restraint system requirements specify how occupants are protected. Glazing requirements specify windshield integrity. The entire regulatory structure is built on the assumption that the people most at risk in a collision are inside the vehicle.

Nuro’s R2 has no occupants. FMVSS compliance, as written, was both inapplicable and inadequate as a safety framework. Inapplicable because many requirements assume an interior a human can occupy. Inadequate because the actual safety priority — pedestrian and cyclist safety — was not the focus of the existing standards.

This created a systems engineering challenge that was simultaneously a regulatory challenge: how do you construct a credible safety case for a vehicle type that existing standards were not written to address?

Nuro’s approach was to pursue a formal NHTSA exemption under 49 CFR Part 555, which allows manufacturers to seek temporary exemptions from FMVSS requirements when compliance would prevent the development of safety innovations that would benefit the public. The argument was direct: R2 cannot comply with occupant-focused FMVSS requirements because there are no occupants, and the vehicle’s purpose-built design — including a softer, yielding front-end structure specifically intended to reduce pedestrian injury in low-speed collisions — represents a net safety improvement over requiring it to meet standards written for a different vehicle category.

NHTSA granted the exemption in February 2020. It was the first autonomous vehicle exemption ever issued under that provision. The regulatory precedent it established has since informed how other unconventional AV developers think about their own FMVSS pathways.

What the Exemption Actually Required

Receiving an exemption did not mean escaping scrutiny — it meant constructing a safety argument rigorous enough to satisfy NHTSA that the exempted vehicle was safer in its operational context than a compliant vehicle would be.

The safety case Nuro submitted addressed pedestrian injury biomechanics directly. Low-speed vehicle-to-pedestrian collisions are survivable, but head injury from vehicle hood contact is a significant contributor to pedestrian fatalities. R2’s front-end design incorporated energy-absorbing materials and geometry intended to reduce peak deceleration on pedestrian head contact. Nuro had to argue, with supporting analysis, that this design produced better pedestrian safety outcomes than the FMVSS-compliant front-end geometry would.

This is an unusual requirement for a vehicle manufacturer: prove your vehicle is safer for people who are not in it. It required pedestrian biomechanical modeling, physical test data, and an operational context argument — the vehicle operates below 25 mph in defined urban and suburban environments, not on highways, which bounds the severity of plausible collisions.

The systems engineering lesson here is about what a safety case actually looks like when the conventional regulatory scaffolding does not fit. Nuro had to define the hazard model, select the relevant injury criteria, design to those criteria, and then demonstrate compliance with a standard they were in the process of arguing should apply. That is a substantially higher-order engineering task than demonstrating compliance with a pre-existing standard.

Operational Design Domain as a Systems Engineering Problem

The ODD — operational design domain — is the specified set of conditions under which an autonomous system is designed to operate. For Nuro, the ODD is defined by geography (specific urban and suburban service areas), speed (below 25 mph), weather (defined operational weather windows), and time of day. Staying inside the ODD is not a nice-to-have. For a vehicle operating without a human occupant, it is a hard safety requirement.

This creates a systems engineering boundary problem: the vehicle must not only perform well inside its ODD, it must correctly identify when it is approaching the boundary of the ODD and respond appropriately. That sounds like a perception and planning problem, but it is actually a system-level requirements problem first.

The ODD must be precisely specified before it can be enforced. “Urban environment” is not a specification. It requires defining the road types, intersection configurations, pedestrian traffic densities, construction zone handling protocols, and edge cases the system is expected to handle versus the conditions under which it must stop and request remote human intervention. Writing those requirements rigorously, maintaining traceability from high-level ODD definition down to sensor coverage requirements and decision logic specifications, and keeping that requirements set consistent as the ODD expands over time — that is a sustained systems engineering challenge.

Nuro’s ODD has expanded from initial deployments in the Houston and Scottsdale suburbs to multiple states and cities. Each expansion is not simply a software update. It requires ODD analysis for the new environment, gap analysis against existing sensor and behavior specifications, and safety case updates. The vehicle that operates safely in suburban Houston may encounter intersection geometries, pedestrian behavior patterns, or road surface conditions in a different city that require explicit requirements updates before deployment.

Remote Monitoring and the Human-Out-of-the-Loop Problem

Removing the human from the vehicle does not remove human oversight from the operation. Nuro’s vehicles operate with remote monitoring — human operators who can observe vehicle status and intervene in ambiguous situations. This is a different problem from the in-vehicle human-machine interface challenge that consumes much of passenger AV systems engineering, but it is not a simpler one.

Remote monitoring introduces latency. A human operator watching a camera feed is not reacting in the same time frame as a human driver watching a windshield. The systems engineering requirement that follows is that the vehicle must detect situations requiring human input early enough that latency does not compromise safety. That is a detection-and-prediction problem with tight requirements on lead time.

It also introduces the question of what the vehicle does while waiting for remote human input. Unlike a passenger vehicle where the human can simply take control, Nuro’s vehicles must execute a safe stop behavior autonomously when they cannot resolve a situation internally and must wait for remote guidance. Specifying those safe-stop behaviors rigorously, ensuring they are appropriate across the range of environments in the ODD, and verifying them against the failure modes that actually trigger them is a substantial V&V challenge.

How Nuro’s Engineering Approach Differs From Passenger AV Programs

The differences are structural, not just philosophical.

Sensor placement freedom. Without an occupant interior, sensor placement is unconstrained by human factors considerations. Nuro’s sensor suite — lidar, radar, cameras — can be positioned for optimal field coverage without the tradeoffs that passenger vehicles face when locating sensors on vehicles that humans also use and occupy.

No HMI engineering. Driver-assist and SAE Level 2/3 passenger vehicle programs dedicate enormous effort to the human-machine interface: how to communicate system state to the driver, how to manage handoff, how to prevent automation complacency. None of that applies to Nuro. The interaction design problem shifts to the customer retrieving goods from the cargo bay and to the remote operator interface.

Speed as a design parameter. Operating below 25 mph allows Nuro to constrain the severity of the worst-case collision scenarios in a way that highway-capable passenger AVs cannot. This simplifies parts of the safety case while creating its own constraints — the vehicle must enforce its speed limits reliably and must handle situations where road conditions or traffic pressure would incentivize higher speed operation.

Regulatory novelty as a continuous requirement. Because the regulatory framework for occupant-free AVs is still being written, Nuro’s regulatory affairs function is not simply tracking compliance with existing standards. It is actively engaged in shaping the standards that will eventually apply. That means systems engineering requirements are sometimes written ahead of final regulatory language, requiring explicit management of regulatory uncertainty as a requirements risk.

The Honest Assessment

Nuro’s engineering decisions reflect genuine clarity of purpose. The purpose-built vehicle design, the pedestrian-first safety case, and the NHTSA exemption strategy are not workarounds — they are coherent engineering choices that follow from the mission. The decision to operate below 25 mph, often criticized as a limitation, is better understood as an ODD constraint that makes the safety case tractable in a way that a highway-capable delivery robot’s safety case would not be.

The hard problems Nuro faces are the hard problems of any early-stage AV program at scale: ODD expansion across increasingly diverse environments, remote monitoring infrastructure that scales with fleet size, and the accumulation of real-world edge cases that stress-test safety case assumptions. None of those are unique to Nuro, but the absence of an occupant means there is no human fallback when the system encounters something outside its competence. The vehicle must either handle it autonomously or stop. That constraint keeps the requirements honest.

What Nuro built is not a simpler version of a passenger AV. It is a different category of autonomous system with its own requirements structure, its own failure mode taxonomy, and its own regulatory frontier. The systems engineering challenge is not easier — it is differently hard, in ways that are worth understanding for anyone working on autonomous systems where the conventional safety frameworks do not straightforwardly apply.