Updating Robots in the Field — David BensoussanUpdating Robots in the Field

Updating robots by hand works at five. What happens at fifty, and why you must fix it before you get there.<br>August 11, 2026 · 6 min<br>Robot FleetDeploymentsRos2Ask a robotics company, especially a young one, how software gets onto a robot that&rsquo;s already at a customer site, and the answer usually is someone driving there, accessing the robot, pulling the code and getting it to run, watching the robot move for a minute, then moving on to the next one.<br>The reason is lack of awareness rather than carelessness. How many robotics companies have a DevOps engineer on the team? Most are led by roboticists and researchers who can make anything happen on a few robots. So a great deal of sophisticated software gets written, and then moved around manually.<br>The idea rarely crosses their mind; they have other problems to chase. Between roboticists, application engineers, hardware engineers and the hardware itself, the margin is thin. It&rsquo;s why so many robotics companies die when scaling. And here I am, suggesting you add one more engineer to it. Funny, right?<br>I&rsquo;m suggesting it because the payback is faster than it sounds, and if you don&rsquo;t do it at the right time, you will pay a heavy price. As soon as your company starts scaling, you will need:<br>Compliance: prove what is running where, to a customer&rsquo;s security team or a regulator<br>Speed: ship a fix to the whole fleet the day you have it, not the month you have it<br>Security: know which keys open which robot, and sign what you install<br>Control: stop a rollout, roll one back, and know the state of every machine<br>Visibility: know a robot is degrading before the customer phones you about it<br>That&rsquo;s the subject of this series: what it takes to get from manual deployments to multiple fleets where software ships on its own.

Figure 1. The same fleet twice. On the left, updated by hand: every machine on its own version, reached one after another, and no way to tell which one is broken. On the right, one known state, every machine traceable to a single origin, and the fault visible at a glance.We will cover:<br>The architecture: from a developer&rsquo;s push to a controlled rollout<br>Update planes: ship application and OS changes separately, roll either back<br>Data collection at the edge: get system and ROS data off the robot<br>Logging: find out what happened, during and afterwards<br>Alerting: get paged for what stops the robot, and nothing else<br>Predictive maintenance: catch a failing part before the customer calls<br>Connectivity: pick the link that fits the site and the budget<br>Hardware-in-the-loop testing: catch it in CI, not at a customer site<br>Signing releases and keeping secrets: only builds you approved reach a robot<br>Image hardening: ship less attack surface than the distribution handed you<br>Compliance (SBOM and more): answer the audit without reconstructing history<br>Tooling and training: let every engineer deploy without asking you<br>How most robot fleets actually get updated<br>Most companies run some blend of three.<br>The first is pure SSH . Someone connects to each machine and updates it. It fails quietly, so nobody ever decides it needs patching. It just slips. Some time later the fleet runs four versions and nobody can say which machine has which. Keeping a mixed fleet in a known state is the problem the fleet-management literature keeps circling back to (IEEE, December 2024).<br>The second looks better and often isn&rsquo;t. An Ansible playbook, or a pile of bash from the founders&rsquo; time, still runs and still reports success. It just isn&rsquo;t what&rsquo;s on the robots any more, because a patch was applied by hand at one site and never added to the playbook. That&rsquo;s worse than nothing, because it looks like a solution.<br>The third is the OS, which usually has no story at all. The application changes weekly and the customer notices when it breaks. The operating system changes rarely, nobody notices it not changing, and the robot keeps running whatever it shipped with. That part is measurable. One scan found 643 public-facing DDS services across 34 countries, some of them running implementations with disclosed, unpatched vulnerabilities (Alias Robotics, 2022). Looking at firmware more broadly, manufacturers left outdated libraries in place in 67.3% of the 6,900 images examined (AutoFirm, arXiv, June 2024).<br>What manual fleet updates really cost<br>Doing it by hand costs hours, and that&rsquo;s the smallest of it.<br>Control is knowing the state of every machine and being able to change it. Today that answer lives in a spreadsheet somebody updates when they remember.<br>Visibility is knowing a machine is going wrong before anyone tells you.<br>Security is knowing who can change what a robot runs, and proving it was you. Keys get dropped on machines by hand, never rotated, never revoked, and nothing is signed. An assessment of the humanoid ecosystem scored three shipping robots between 39.9% and...