The DARPA challenges offer a useful playbook for physical AI. They show how an impressive technical demonstration can help create an industry.
But they are not a timeline.
The first DARPA Grand Challenge for autonomous vehicles took place in 2004. DARPA launched the Robotics Challenge eight years later, in 2012, with the Finals taking place in 2015. It is tempting to conclude that physical AI is therefore eight or eleven years behind autonomous driving.
I don’t think that works.
Physical AI can reuse a lot of what autonomous driving has already built: simulation, data engines, validation methods, safety engineering and fleet operations. But robots also face different problems. They have more varied bodies, much less real-world training data, and a far wider range of physical interactions.
And in a factory (the lens I’m using), there is another constraint: the robot is part of a production system. If it stops for too long, the line may stop with it.
So the lesson from autonomous driving is not when physical AI will arrive. It is how a difficult physical technology moves from an impressive demo to something reliable and economically useful.
Two DARPA Challenges
The DARPA Grand Challenge started with a simple question: could a vehicle drive itself?
In 2004, DARPA asked autonomous vehicles to navigate a 142-mile desert course without a human driver. Fifteen vehicles started. None finished. The best one travelled only about 7.4 miles.
A year later, five vehicles completed the course. By 2007, DARPA had moved the challenge into an urban environment with intersections, traffic rules and other vehicles.
The DARPA Robotics Challenge asked a different question: could a robot operate in an environment built for humans?
Launched in 2012, it was motivated in part by the difficulty of sending people into disasters such as the Fukushima nuclear accident. Robots had to eventually perform tasks such as driving a vehicle, opening doors, turning valves, using tools, moving through debris and climbing stairs. At the 2015 Finals, 23 teams competed and only three completed all eight tasks.
The first challenge helped accelerate autonomous driving. The second helped accelerate what we now call physical AI.
The eight-year gap between their launches is interesting, but it is not a forecast.
Physical AI does not start where autonomous driving started in 2004. Today we have better compute, neural networks, foundation models, GPU simulation and cloud infrastructure. We also have twenty years of experience building and operating autonomous machines.
On the other hand, robots have to solve some problems cars largely avoid.
That is why the technologies can share a playbook without sharing a clock.
Physical AI is also much broader than factory automation. It will affect logistics, construction, healthcare, homes and many other environments.
But I will often use the factory as the reference point in this article. It is the environment I know best, and it is also a useful reality check. In a factory, a robot eventually has to do more than demonstrate a skill. It has to meet a cycle time, work safely around people, recover from failures and create an economic return.
What Physical AI Can Reuse From Autonomous Driving
The most useful comparison with autonomous driving is not the technology itself.
It is the infrastructure that grew around it.
Autonomous-driving companies learned early that making a vehicle drive once was not the hard part. The hard part was dealing with everything that happened after the first successful demonstration.
They built massive simulation and testing systems. A failure found on the road could be replayed thousands of times. New software could be tested against libraries of known scenarios before being deployed again.
Physical AI can do the same.
A robot failure in the real world should not just be repaired and forgotten. It should become a test case. The next software release should be tested against it, along with thousands of variations of the same problem.
Autonomous driving also developed sophisticated data engines. The objective was not simply to collect more video. It was to find the useful data: failures, unusual situations and cases where the system was uncertain.
The same loop applies to robots: deploy, identify failures, capture the relevant data, improve the skill, test it and redeploy.
Physical AI also benefits from what autonomous driving learned about safety. Learned behaviour can sit inside a broader deterministic system with limits, monitoring, fault detection and safe fallback behaviours.
And finally, autonomous-driving companies learned how to operate fleets. Remote assistance, software updates, maintenance, incident review and fleet learning are all part of the product.
These lessons matter because physical AI does not have to invent all of this again.
It can start further ahead.
But there is a catch.
Some of the fundamental inputs to that system are much harder to obtain for robots.
Where the Comparison Breaks
1. The Data Problem Is Much Harder
Autonomous driving benefited from an enormous source of data that already existed:
People driving cars.
Humans generate billions of miles of driving simply by going about their lives. Put cameras and sensors on a vehicle and normal driving produces useful observations of roads, traffic, weather, construction, unusual behaviour and edge cases.
There is no equivalent data source for physical AI.
A person assembling a product does not automatically generate a robot trajectory. A video of someone picking up an object can be useful, but it does not tell the robot everything it needs to know about force, contact, timing, joint position or what happened inside the hand.
And robot data is closely tied to the body generating it.
A human hand, a two-finger gripper and a dexterous robotic hand can accomplish the same task using very different motions and contact strategies.
Today, physical AI tries to close that gap in several ways. Simulation can generate huge amounts of experience, but contact physics still has to transfer to the real world. Internet video provides enormous diversity, but limited robot-native action data. Teleoperation and human demonstrations produce better data, but scale with human effort. Robot farms provide native data, but require robots, operators and physical environments.
Eventually, deployed robots themselves may become the best data source.
But that creates a chicken-and-egg problem: we need capable robots to generate the data that will make robots more capable.
ARK Invest recently illustrated another dimension of this problem by comparing the complexity of a humanoid robot with a robotaxi. Its analysis combines factors such as degrees of freedom, control frequency, object diversity, task diversity and environmental complexity, arriving at an illustrative ratio of roughly 200,000×.
I would not take 200,000× as a precise engineering number. The useful part is the direction.
A car mostly has to move itself through the world going forward, backward, left and right.
A general-purpose robot has to move itself and change the world around it.
It has to grasp, push, pull, insert, carry, turn, align and use tools. Small differences in pose, friction, geometry or compliance can completely change the interaction.
So physical AI may face an uncomfortable combination:
It may need more diverse data than autonomous driving while having access to dramatically less of it.
That may be one of the biggest bottlenecks in the industry.
2. Roads Standardize Motion. Robots Have to Deal With Contact.
It is easy to say that roads are structured while factories are unstructured.
That is not quite right.
Factories can be extremely structured. Parts have known locations. Workstations are designed. Processes are defined.
The bigger difference is the type of interaction.
Roads constrain vehicles to a relatively standardized set of behaviours. Cars move along surfaces, stay in lanes, follow traffic rules, accelerate, brake and steer.
Robots have to interact with things.
A factory robot may encounter boxes, bags, cables, machined parts, bins, tools, fixtures and deformable materials. It may need to push one object, precisely insert another and handle a third without damaging it.
The factory can be structured and the manipulation problem can still be difficult.
The useful distinction is therefore not structured roads versus unstructured factories.
It is standardized mobility versus diverse physical interaction.
3. In a Factory, Stopping Can Stop the System
There is another important difference between a car and a robot in a factory.
The robot is usually part of a process.
A self-driving car that is uncertain can slow down. It can stop. In some cases, it can pull aside and wait for help.
That may delay one passenger, but the transportation system normally continues operating around it.
A production line is different.
One station feeds the next station, which feeds the one after that.
There may be buffers between operations, but those buffers are finite. Once they are consumed, a failure at one station can propagate through the line.
If the robot is on the critical path, its recovery window may effectively be defined by the takt time of the process or the available buffer.
This changes what reliable means.
Imagine a robot that succeeds 99% of the time. That sounds excellent.
But suppose the remaining 1% creates a 20-minute interruption.
On a demonstration video, that robot looks almost perfect.
On a production line, it may be a bad production system.
The important questions become: How often does it stop? How quickly can it recover? Can it recover before the next station runs out of parts?
For autonomous driving, stopping can be the safest behaviour.
For an industrial robot, stopping can be safe for the robot and still be unacceptable for the factory.
That means industrial physical AI must optimize not only task success and safety, but also availability, cycle-time consistency and recovery time.
The objective is not merely to automate the task.
It is to keep production running.
4. Safety Has a Different Benchmark
Autonomous driving has one big advantage when discussing safety:
Humans provide a natural benchmark.
People already drive enormous distances, and we have statistics on crashes, injuries and fatalities. Autonomous-driving companies can eventually ask a relatively clear question: under comparable conditions, does the autonomous system cause fewer accidents than human drivers?
That comparison is much harder for physical AI.
What is the equivalent human baseline for a humanoid working in a factory?
It is not simply injuries caused by one worker to another. Workers are operators, collaborators, potential sources of accidents and potential victims of accidents at the same time.
Automation may also remove a person from an inherently dangerous task.
We can absolutely measure safety before and after automation for a specific application.
But there will probably not be a universal equivalent of accidents per million miles that applies across physical AI.
The safety case will be much more application-specific.
Humanoids introduce another complication.
Because they look and move like us, incidents involving them can be perceived differently from failures involving ordinary machinery.
If a conveyor malfunctions, we describe it as a machine failure.
When a humanoid appears to kick, strike or push someone, it is very easy to interpret what we see using human concepts such as agency, intention and blame.
That does not necessarily say anything about the statistical risk of the robot.
But it matters.
Humanoid safety will have to be more than engineered and measured. It will also have to be understandable.
People working around these machines need to know what they are likely to do, when they are uncertain, how they stop and what happens when something goes wrong.
Here again, autonomous driving gives physical AI an advantage.
The industry has already spent years learning how to validate probabilistic systems, monitor them, constrain their operating domain and put deterministic safety layers around learned behaviour.
Physical AI can benefit from that work.
What Will Matter in Production
The physical-AI industry will produce a lot of impressive videos over the next few years.
That is normal.
The more interesting question is how we separate a good demonstration from a good production system.
For industrial physical AI, I would watch five things:
- Availability: Can the robot keep producing for the full period when production needs it?
- Intervention and recovery: How often does someone need to help, and how quickly does the system recover when something goes wrong?
- Cycle-time consistency: Can it reliably stay inside the required takt time, not just achieve a good average?
- Deployment and skill-transfer cost: How much engineering and new data are required to make the same capability work at the next workstation or factory?
- Cost per useful output: Once hardware, deployment, supervision, maintenance and downtime are included, does the robot create better economics?
These metrics are not as exciting as a humanoid doing something new for the first time.
But they are how factories work.
The output of one station becomes the input of the next. What ultimately matters is whether the system delivers the required output, reliably and economically.
This is also where the autonomous-driving comparison becomes most useful.
Autonomous driving had to make the transition from “the car can drive” to “the system can operate reliably enough to provide a service.”
Physical AI has to make a similar transition.
From:
The robot can do the task.
To:
The robot can keep doing the task, under real conditions, at a cost that makes sense.
The Real Lesson From DARPA
The DARPA Grand Challenge did not create a commercial autonomous-driving industry overnight.
The DARPA Robotics Challenge did not create a commercial humanoid industry either.
What they did was make progress visible.
They forced teams to integrate complete systems. They exposed failures in public. They concentrated talent. They created shared infrastructure. And they helped turn difficult technical problems into credible industrial opportunities.
That is the useful comparison.
Physical AI can reuse much of the infrastructure autonomous driving had to invent: simulation, data engines, safety methods, fleet operations and disciplined operating domains. It can also benefit from the people who spent years solving autonomy problems for cars and are now applying that experience to robots.
That is a real head start.
But physical AI also faces a harder data problem and a much broader physical-interaction problem. And in factories, where we want to put this technology to work, reliability has a very practical definition:
The robot has to keep production running.
So I would not ask:
Can we use autonomous driving as an analogy to predict where we are on the path to autonomous robots?
The eight or eleven years separating the DARPA milestones do not answer that question.
The technologies share a playbook. They do not share a clock.
With the amount of money and talent flowing into the field, combined with rapid progress in AI models, compute, simulation, sensors and robot hardware, increasingly autonomous robots are coming.
The much harder question is when they will work reliably and economically enough to deploy at scale.
I’ve stopped trying to predict the future a few years ago…
But I am very confident about is the direction of travel.
The technology is converging. The industrial work is just beginning.
The post “Physical AI: The DARPA Legacy & the Road Ahead — The Parallel Playbook: What Autonomous Driving Can and Can’t Teach Physical AI” by [email protected] (Samuel Bouchard) was published on 08/11/2026 by blog.robotiq.com