Simulation has become an indispensable tool for robotics engineers. It allows teams to evaluate designs before hardware exists, accelerate software development, and expose autonomous systems to thousands of scenarios that would be difficult or expensive to recreate in the physical world.

After nearly eight years deploying autonomous robots in commercial environments, I have also learned where simulation stops being enough. The most consequential engineering problems are often not the scenarios we anticipated during development. They are the conditions that emerge only after a robot encounters the complexity and variability of the real world. That is not an argument against simulation. It is a reason to think differently about what simulation is supposed to accomplish.

A simulation can only represent the assumptions built into it. Engineers decide which objects, environmental conditions, interactions and failure modes are important enough to model. As simulation becomes more sophisticated, those representations become increasingly realistic. But there will always be conditions that were not considered because no one had encountered them yet.

Commercial robotics makes that limitation particularly important. A robot may operate across different customers, facilities, weather conditions, layouts, equipment and surfaces, and around people who are inherently unpredictable. The environment is not a controlled test fixture. It changes continuously. The engineering challenge is to build a development and validation process that learns from what simulation could not predict.

Unexpected Failures in the Field

Early in deployments, Burro, a developer of autonomous mobile robots for agriculture and outdoor industrial work, encountered a problem involving stacks of pallets wrapped in reflective black plastic. The material was common in the environments where our robots operated, but its visual characteristics created an unexpected combination of sensing problems. Repeated patterns confused the camera, while the reflective surface produced inconsistent LiDAR returns. Together, the two sensing systems struggled to identify an obstacle directly in the robot's path.

Another deployment presented a very different problem. After weeks of flawless operation, the robot began experiencing severe GPS degradation. The eventual cause was standing water on a nearby plastic greenhouse roof, which created GPS multipath interference and disrupted localization.

These incidents required different responses. The reflective material led to improvements in perception and additional real-world training data. The GPS problem required us to change the system itself. We redesigned our GPS antenna configuration and incorporated specialized filtering based on what we observed in production.

READ MORE: Physical AI Needs a Paper Trail: Engineering Evidence at the Actuation Boundary

That distinction has become an important part of our engineering process. A failure in the field does not automatically mean the AI model needs to improve. Sometimes the right answer is more training data. In other cases, it is a different sensor, a mechanical change, additional redundancy or a change to the system architecture.

Determining which response is appropriate is difficult to do from simulation alone. It requires enough operating experience to understand what the system is actually encountering. Consider a robot operating in a grape vineyard. Long vines can hang directly in front of a robot, creating an unusual perception and mobility problem. The robot needs to learn that it can drive through the vegetation while still stopping when it encounters a rigid obstacle.

The challenge does not end with perception. Vines can wrap underneath a wheel or strike the robot's bumper bar, triggering a safety stop. The system is therefore dealing with deformable vegetation, vehicle dynamics, physical contact, perception and safety behavior at the same time. A more detailed simulation might reproduce some of those interactions, but the larger lesson is about how difficult it is to define the environment in the first place.

Validating Robots Across Changing Environments

Commercial customers rarely operate in standardized settings. In nurseries, for example, the robot encounters many different versions of trailers. In greenhouses, plant storage methods vary widely, as do the structures, ground coverings and layouts.

At one greenhouse, our robot operates on sand while plants hang several levels high on rails. As the plants grow, they occupy more of the robot's field of view, obscuring permanent structures such as walls. In other busy greenhouses, plants hang from the ceiling and trailers line the corridors. The floor may be one of the few relatively permanent features available to the robot.

This creates a different validation problem from the one engineer’s face in a controlled environment. We are not validating a robot against a single, fixed representation of a greenhouse. We are validating it against a class of environments that can vary from customer to customer and change within the same deployment.

That means field experience is not simply a final check on a design. It becomes a source of requirements for the next one.

Why the Long Tail Matters

Eight years of deployment has also changed how we think about unusual failures. At Burro, we sometimes refer to this as the “cockroach theory.” If you see one cockroach, there are probably more where that came from.

The point is not that every anomaly deserves an immediate redesign. The question is whether an event reveals a condition that the fleet will encounter often enough to become an engineering requirement.

We saw this with GPS interference near overhead power lines. Early deployments occasionally experienced localization problems in those environments, but relatively few robots were operating there, so we monitored the issue. As deployments expanded and more customers operated around power infrastructure, the failures became repeatable. At that point, we redesigned the GPS antenna configuration, added specialized filtering and validated the new architecture under those conditions. Deployment scale changed the engineering decision.

This is one reason the long tail matters so much in autonomous systems. A condition that appears once during development may look statistically insignificant. Across hundreds of deployed robots and thousands of operating hours, the same condition can become inevitable.

READ MORE: Machine Guarding: Coming Out of My Cage and I'm Doing Fine

Consider lighting. A particular reflection or lighting condition might occur for only 15 min. around sunrise. It could easily be missed during conventional testing. If every robot at a particular site encounters it every morning, however, it is no longer an edge case in any meaningful operational sense. The fleet provides the context needed to make that distinction.

Measuring Operational Reliability

This also changes how we measure reliability. Simulation benchmarks and controlled tests can tell us whether a robot is capable of completing a task. Fleet performance tells us whether it can do so consistently in the environments where customers actually use it.

One metric we have found useful is miles per fault. As failures become less frequent, their nature changes. Some reveal weaknesses in the system that can be addressed through engineering. Others result from genuinely unpredictable external events, such as infrastructure changes or unusual human interactions.

The useful question is not simply, "Did the robot fail?"

It is, "What does this failure tell us about the system?"

Was the robot missing information that another sensor could provide? Did the mechanical design create a failure mode? Did a safety system behave appropriately but too conservatively? Did the perception model misclassify an object, or did the overall architecture lack enough redundancy to handle uncertainty safely?

Those questions determine the response. A model improvement may solve one problem. A sensing upgrade, mechanical redesign, electrical change or new validation procedure may solve another. Operational data has driven all of those types of changes at Burro.

Learning from Human Intervention

The autonomous vehicle industry offers a useful comparison because it has spent years confronting the same fundamental challenge: Simulation can test enormous numbers of scenarios but it cannot capture every condition a vehicle will encounter on public roads.

One lesson worth adopting is the value of learning continuously from human intervention. Companies such as Tesla have demonstrated how interventions can become feedback about where autonomy falls short.

We apply a similar principle to our robots. Whenever an operator intervenes, remotely or in person, it tells us that the autonomous system encountered something it could not successfully handle on its own. Those interventions can become some of our most valuable training data because they identify conditions where the system needs to improve.

Simulation vs. Real-World Testing

There is another lesson industrial robotics should take seriously: A successful demonstration does not establish operational reliability.

A robot that performs flawlessly in a controlled environment with predictable layouts and carefully positioned objects has demonstrated capability. Commercial deployment introduces weather, changing infrastructure, growing plants, moving equipment and people who adapt their behavior around the robot.

The goal should not be to prove that an autonomous system works under ideal conditions. It should be to expose the system to enough variation that deployment continually improves the next version.

As foundation models and other AI capabilities improve, it is tempting to assume that physical testing will become less important. Our experience suggests that the opposite is closer to the truth.

More capable AI reduces some of the failures that once dominated testing. That allows engineers to spend more time on the harder remaining problems: unusual environmental conditions, unexpected human interactions, physical changes to the operating environment and combinations of events that were not represented in the original training or simulation data. The testing does not disappear. Its emphasis changes.

Simulation remains essential because it allows us to explore designs quickly, test dangerous or expensive scenarios safely, and evaluate systems before deploying hardware. But field operation provides something simulation cannot create on its own: evidence about which assumptions were wrong. That evidence should then flow back into development.

A field failure may lead to new training data. It may prompt a sensor change or mechanical redesign. It may expose a need for additional system redundancy. It may also reveal a scenario worth adding to simulation so that future versions can be tested before reaching the field. The result is a development loop in which each stage informs the next.

Building Better Physical AI Through Deployment Data

The most important lesson from eight years of deployment is not that simulation has limits. Engineers already understand that. The more consequential lesson is that real-world deployment should be treated as an engineering instrument.

Simulation should establish capability and allow teams to explore a broad range of conditions before deployment. Controlled testing should establish baseline reliability. Field deployment should reveal the assumptions that remain untested. Fleet data should help determine which discoveries are isolated anomalies and which represent requirements for the next system.

That process also changes how engineers think about the physical design of autonomous machines. A robot cannot be designed solely around the environments engineers expect to encounter. It has to accommodate uncertainty in sensing, terrain, objects, infrastructure and human behavior.

As physical AI becomes more capable, this distinction will become increasingly important. The companies that accumulate diverse operational data across industries and environments will have an advantage because that data captures interactions that cannot be fully authored in advance. Simulation will remain a critical part of building those systems. But the most valuable scenarios to simulate may increasingly come from the field.

Learning from Experience

The future of physical AI is therefore not simulation replacing real-world testing. It is a continuous engineering cycle in which simulation accelerates development, deployment reveals missing assumptions and operational data drives the next generation of hardware, sensing, AI and validation.

The systems that become commercially reliable will be the ones whose engineers learn fastest from what they could not predict.

More content from Takeover Week: Automation & Robotics.