What 5,000 Autonomous Hours in Heavy Industry Taught Us

Our field engineers spent the next two to three hours working the problem. They manually repositioned the arm using a controlled mechanical assist under supervision of the field team, walked the base back from the edge, and recovered the robot without incident. Then came the more expensive decision. We replaced that arm across our fleet with one rated for a far wider temperature range.

I should say up front that I run a robotics company, so discount my optimism accordingly. What follows are the failures, which need no discounting. Our robots have now logged more than 5,000 semi-autonomous operating hours across 18 construction projects, running shifts of six to eight hours a day, including a completed 13-story project in Nashville. Those hours taught us one thing above all others. The only way to scale autonomy in heavy industry is to deploy, learn from what the field does to your machines, and fold those lessons back into the fleet faster than the next site can surprise you.

The Site Will Find the Fine Print in Your Spec Sheet

Every component on our robots was chosen by capable engineers reading datasheets (operating temperature ranges, ingress protection ratings, vibration tolerances). On paper, the machines were ready for anything.

The Austin cold snap proved otherwise, and it was not alone. On another cold morning, this time in Nashville, a robot went down for a different reason. Our chassis is waterproof and insulated, and we had treated that as sufficient. But rapid cooling caused condensation inside the sealed enclosure, and that moisture froze on a circuit board, shorting its power lines. The enclosure kept the weather out, but sealing the box did nothing to control the air trapped inside it.

The fix was not more sealing. We had to accept that an airtight box is not a controlled environment, and that we had to actively manage temperature and humidity inside the chassis, not just around it.

Nobody was careless in either failure. The engineers read the datasheets correctly, but the datasheets were described for a lab environment. A component that performs flawlessly at 20 degrees in a clean facility has told you almost nothing about an exposed slab in January. Lab conditions are a floor, not a ceiling.

Perception Fails Silently, So Design for the Human Catch

The most dangerous failures in autonomy are the ones the robot does not know it is having.

On one project, our arm came within inches of striking a 1-inch pipe running overhead. A field operator saw it developing and hit the emergency stop. When we reviewed the incident, the unsettling part was not what the robot did but what it saw. We pulled up the perception feed, and the space where the pipe hung was empty. Clean. As far as the robot was concerned, there was nothing there to avoid.

The physics explained it. Lidar builds its picture of the world from discrete laser returns, and a thin, shiny, curved surface reflects those beams away or slips between them entirely. The sensor was not malfunctioning. It was performing exactly to specification against an object the specification never contemplated. No simulation flagged it, because our simulated worlds contained the obstacles we thought to model, but the jobsite contained the ones we did not anticipate.

Two changes followed. Technically, we began fusing depth camera data with lidar, because cameras resolve small features that sparse laser returns miss. The deeper change was philosophical. That near miss was caught by a person, and rather than treating his intervention as a failure of autonomy, we started treating it as a designed layer of the system. Our robots run semi-autonomously with trained field operators for a reason. On a live jobsite, with workers below and live systems overhead, the human catch is a permanent part of the design, not a crutch we are waiting to remove.

Field recovery is the real uptime metric

When that circuit board shorted in Nashville, the textbook path was a return-to-manufacturer cycle. Ship the board, wait for diagnosis, wait for a replacement. On a construction schedule, that is a week or more of a robot standing idle while general conditions costs run.

Instead, our field engineer pulled a spare board from the on-site kit, swapped it, and had the robot running again within hours.

That was not luck, it was a prior decision about what reliability means. Vendors love to quote mean time between failures. The number that matters on a schedule-driven project is mean time to recovery. Machines will fail, and 5,000 hours of operation makes that a certainty. What separates a robot that belongs on a jobsite from one that belongs in a demo video is whether the people standing next to it can diagnose and repair it, with parts in the truck, the same day. Contractors already apply this standard instinctively to excavators, asking about parts availability and service response before they ever ask about horsepower. Robotics should face the same questions, but most vendors haven’t operated long enough to be asked.

What the Hours Add Up to

The clearest validation came in Memphis. A façade contractor, JR Butler, had run their most quality-critical scope, layout for a commercial façade installation, using manual methods. A month in, after two floors of unitized panels were installed, the team discovered a compounding error in the layout. Every panel had to come off the structure and the layout had to restart from scratch (more than $100,000 in rework, with the project now behind schedule and over budget).

We were contracted to take over the scope for the remainder of the project. The results were 1/16-inch accuracy, zero rework, a three-month payback period, and three workers redeployed from layout to higher-value installation work. That outcome came from a machine and a team shaped by every failure above, including components specified for real site conditions rather than lab conditions, perception designed with redundancy, operators empowered to intervene, and repairs completed from spares on site.

The Only Way to Scale is Through the Field

Every lesson we learned shares a lineage. The arm that now survives the cold was respecified because Austin froze the old one. The depth cameras ride alongside the LiDAR because a pipe hid from it. The chassis manages its own humidity because Nashville taught us that sealed is not controlled. The spare boards sit in the site kit because one morning we needed them. None of this came from the lab, and none of it could have. Simulation only covers the conditions we already knew to model. Everything else we learned by operating on real sites.

That is the real argument of these 5,000 hours. Autonomy in heavy industry does not scale through longer development cycles or more impressive demos. It scales through deployment velocity. How fast you can get machines onto real sites, how honestly you diagnose what the site does to them, and how quickly the fix reaches every robot in the fleet. Each failure went from field incident to fleet-wide change in weeks, not quarters. That loop matters more than any single sensor or algorithm.

There is a simple way to see whether a vendor’s loop is turning. At a demo, watch their field engineers rather than the robot. If the engineers look bored, the hard lessons have already been learned and fixed. If they are hovering and tense, the system is still learning those lessons, possibly on your project. Then ask the vendor what failed in the field and what changed because of it. A vendor with no answer has not deployed enough to have earned a place on your jobsite. Nearly every answer we have came from the field, and each failure made the fleet better.

Rishabh Aggarwal is chief technology officer and lead inventor, Raise Robotics, a San Francisco-based company building autonomous systems for heavy industry.