One of the hardest lessons I’ve learned in robotics occurred on an eighth-floor slab in Austin, Texas, on a morning when the temperature dropped to about 23 degrees Fahrenheit.
One of our autonomous mobile robots was performing layout marking for a facade installation, the work that determines where each panel of the building will land. In the middle of the shift, the robotic arm stopped. It was a collaborative arm, built to stop the instant it detects contact with a person or an obstacle. Nothing touched him. The cold had hardened the lube inside his joints and the arm’s force sensors adding resistance felt exactly like a collision. The arm came to an emergency stop, again and again, with one part extended near the edge of the slab, on top of the building.
Our field engineers spent the next two to three hours working on the problem. They manually repositioned the arm using controlled mechanical assistance under the supervision of the field team, walked the base from the edge, and recovered the robot without incident. Then came the most expensive decision. We replaced this arm across our entire fleet with one with a much 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 discount. Our robots have now logged more than 5,000 hours of semi-autonomous operation on 18 construction projects, working six- to eight-hour shifts 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 implement, learn from what the field is doing to your machines, and bring those lessons back to the fleet faster than the next site can surprise you.
The site will find the fine print on your spec sheet
All components of our robots were chosen by engineers capable of reading data sheets (operating temperature ranges, ingress protection ratings, vibration tolerances). On paper, the machines were ready for anything.
Austin’s cold strike proved otherwise, and he wasn’t alone. Another cold morning, this time in Nashville, a robot fell for a different reason. Our chassis is waterproof and insulated, and we had treated that as enough. But the rapid cooling caused condensation inside the sealed enclosure, and that moisture froze on a circuit board, shorting its electrical lines. The enclosure kept the weather out, but sealing the box did nothing to control the air trapped inside.
The solution was no more sealing. We had to accept that an airtight case is not a controlled environment and that we had to actively manage the temperature and humidity inside the chassis, not just around it.
Looking for quick answers on construction and engineering topics?
Try Ask ENR, our new intelligent AI search tool.
Ask ENR →
No one was careless in either failure. The engineers read the data sheets correctly, but they were described for a laboratory environment. A component that works perfectly at 20 degrees in a clean installation has told you next to nothing about an exposed slab in January. Lab conditions are a floor, not a ceiling.
Perception fails silently, so design for human capture
The most dangerous failures in autonomy are the ones the robot doesn’t know it’s having.
On one project, our arm came within inches of hitting a 1-inch pipe running overhead. A field operator saw it unfold and hit the emergency stop. When we reviewed the incident, the disturbing part was not what the robot did but what it saw. We removed the perception channel and the space where the pipe hung was empty. cleaning As far as the robot was concerned, there was nothing to avoid.
Physics explained it. Lidar builds its picture of the world from discrete laser returns, and a thin, shiny, curved surface reflects these beams away or slides between them entirely. The sensor was not malfunctioning. It was working exactly according to the spec against an object that the spec never contemplated. No simulation ticked this off, because our simulated worlds contained the obstacles we intended to model, but the workplace contained ones we hadn’t anticipated.
Two changes followed. Technically, we started to merge the depth camera data with the lidar, because the cameras resolve small features that are missed by the laser returns. The most profound change was philosophical. One person caught this near-accident, and instead of treating their intervention as a failure of autonomy, we started treating it as a designed layer of the system. Our robots operate semi-autonomously with trained field operators for a reason. In a live workplace, with workers below and live systems above, human capture is a permanent part of the design, not a crutch we’re 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. Send board in, wait for diagnosis, wait for replacement. On a build schedule, that is, a week or more of an idle robot while general condition costs run.
Instead, our field engineer pulled a spare board from the kit on site, swapped it out, and had the robot running again within hours.
This was not luck, it was a prior decision about what reliability means. Marketers like to quote mean time between failures. The number that matters in a schedule-based project is the mean time to recovery. Machines will fail and 5,000 hours of operation make that a certainty. What separates a robot that belongs on a jobsite from one that belongs in a demo video is whether the people next door can diagnose and repair it, with parts on the truck, the same day. Contractors already instinctively apply this standard to excavators, asking about parts availability and service responsiveness before ever asking about horsepower. Robotics should face the same questions, but most marketers haven’t been around long enough to ask them.
What the hours add up to
The clearest validation came in Memphis. A facade contractor, JR Butler, had executed his most quality-critical scope, the design of a commercial facade installation, using manual methods. A month later, after installing two floors of unitary panels, the team discovered a compositional error in the design. All the panels had to come off the structure and the design had to be restarted from scratch (over $100,000 in rework, with the project now behind schedule and over budget).
We were hired to take on the scope of the rest 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. This result comes from a machine and equipment modeled after each previous failure, including components specified for real site conditions rather than laboratory conditions, perception designed with redundancy, empowered operators to intervene, and repairs performed with spare parts on site.
The only way to climb is through the countryside
Every lesson we’ve learned shares a lineage. The arm that now survives the cold was respecified because Austin froze the old one. The depth cameras run next to the LiDAR because a pipe was hidden there. The chassis manages its own moisture because Nashville taught us that sealing is not controlled. The spare boards are in the site kit as we needed them one morning. None of this came from the lab, and none of it could have. The simulation only covers the conditions we already knew how to model. Everything else we learned by operating in real places.
This is the real argument of these 5,000 hours. Autonomy in heavy industry doesn’t scale through longer development cycles or more impressive demos. It scales through deployment speed. How quickly you can get machines to real sites, how honestly you diagnose what the site is doing to them, and how quickly the solution gets to every robot in the fleet. Each failure went from a field incident to a fleet-wide change in weeks, not quarters. This loop matters more than any single sensor or algorithm.
There’s an easy way to see if a salesperson’s loop is spinning. In a demo, watch their field engineers instead of the robot. If the engineers seem bored, the hard lessons have already been learned and fixed. If they are pending and strained, the system is still learning those lessons, possibly in your project. Then ask the seller what went wrong in the field and what changed because of it. An unresponsive salesperson has not deployed enough to earn a place in your workplace. Almost every response we got came from the field, and every failure improved the fleet.
Rishabh Aggarwal is Chief Technology Officer and Principal Inventor, Raise Robotics, a San Francisco-based company that builds autonomous systems for heavy industry.
