OTA Updates for Robot Fleets: Pushing Firmware, Model Weights, and Software Without a Full Stop

A phone that installs a bad update crashes, and you force-quit it. A pallet-carrying autonomous mobile robot (AMR) that installs a bad update can keep moving. That one difference — the payload drives actuators, not just pixels — is why over-the-air (OTA) updates for robot fleets are a harder engineering problem than app deployment, even when the plumbing looks identical. This is a field briefing on how fleets ship software, firmware, and model weights remotely without grounding the whole line, and where the real risk hides.

How do you update a live robot fleet without a full stop? You stage it. Every artifact is signed offline, pushed first to a 1% canary cohort, checked against health and safety signals, then promoted to larger cohorts or halted. “Automatic rollback” — the phrase in every OTA vendor deck — is a concrete mechanism, not a promise: an A/B partition scheme writes the new image to the inactive slot while the robot keeps running on the active one, switches the boot target only after verification, and reverts to the last-known-good slot if the boot or a post-boot health check fails. The download is the easy part. The hard part is knowing which robots are physically safe to touch right now, and making sure a machine mid-motion reaches a bounded safe stop before you swap the software driving it.

That gap — between “the server says the update is ready” and “this specific robot is safe to update” — is the whole discipline. It sits inside the wider practice of running a robot fleet — see our RobotOps explainer for how OTA fits alongside telemetry, incident response, and predictive maintenance — and it is where OTA borrows heavily from automotive, which has been forced to solve it under regulation.

What actually gets pushed to a robot over the air?

Three payload classes, in ascending order of pain:

• Application software — ROS 2 nodes, the navigation stack, task logic. Smallest and most frequent; usually a container or package swap.
• Firmware — low-level code on motor controllers, safety controllers, and sensor microcontrollers. Verified against a hardware root of trust; a bad flash here can brick a board that then needs a bench and a cable to recover.
• Model weights — the learned policy. This is the newest and heaviest payload, and the reason “robot model deployment” is now its own OTA sub-problem. A vision-language-action (VLA) model such as OpenVLA carries roughly 7 billion parameters; running it unquantized is commonly cited as needing on the order of 24 GB of VRAM. RT-2 (Google DeepMind, arXiv 2307.15818, July 2023) and NVIDIA’s Isaac GR00T N1 (announced March 18, 2025; open-weight GR00T-N1-2B checkpoint) are the same shape of problem — multi-gigabyte binaries, not a few-hundred-kilobyte app patch.

The practical consequence: a phone-app pipeline assumes small, quickly reversible payloads. A robot fleet routinely moves gigabyte-scale weight files to edge compute with fixed GPU memory. Bandwidth, storage headroom, and the time window a robot must sit still all change the math.

The three classes also carry genuinely different risk, and that should drive the schedule, not just the payload size. Model weights can ship often and roll back fast, so frequent canary iteration makes sense there. Controller and drive firmware should update rarely, in its own window, behind a stricter health gate and in smaller batches — it sits closest to real-time motion and is the hardest layer to walk back once flashed. Bundling all three layers into one “update” on one shared schedule is a common mistake that erases exactly these risk differences.

Why is a bad update on a robot riskier than on a phone?

Because the failure is kinetic, formal, and fleet-wide at once.

Kinetic: the two clearest public examples both come from robotaxis. In 2024, Cruise (GM) recalled all roughly 1,194 of its US Chevy Bolt robotaxis running Automated Driving System software released before May 14, 2024; NHTSA’s Office of Defects Investigation tied a software fault — unexpected hard braking when a cyclist or vehicle approached from the rear — to 10 crashes, 4 of which injured a vulnerable road user. Waymo’s parallel case ran longer: its software repeatedly failed to recognize stationary gates and chains as obstacles, contributing to at least 7 low-speed collisions (no injuries) between December 2022 and April 2024; NHTSA’s Office of Defects Investigation closed the case on May 1, 2025, after a fleet-wide software update fixed the behavior, in a recall covering roughly 1,212 vehicles.

Formal: Waymo shipped its fix as an OTA software update that reached the fleet before the paperwork caught up — yet US federal law still required the formal recall notice. There is no phone-app equivalent of that obligation. A safety-relevant defect in a physical machine triggers a reporting duty regardless of how fast the patch ships.

Fleet-wide: one signed artifact reaches every unit. That is the point of OTA and also its danger — the same pipeline that fixes a defect overnight can propagate one.

Dimension	Phone app update	Robot / AV fleet update
Worst realistic case	Crash, data loss, bricked personal device	Collision, injury, damaged goods, machine stuck mid-task
User recovery	Force-quit, uninstall, wait for a patch	Robot may keep moving; needs a bounded safe stop
Going “offline”	Close the app	A machine mid-task cannot simply terminate
Regulatory duty	None	Mandatory recall filing (e.g., NHTSA) even after the OTA fix ships
Blast radius	One user	The entire deployed fleet at once

How do you roll out to a live fleet without stopping it?

Staged, or canary, rollout: push to ~1% first, watch, then widen. It is the same canary-release pattern documented in general SRE practice, and commercial robot-fleet OTA platforms sell it as a feature. Be skeptical of the specific numbers in the marketing, though — figures like “25% of the fleet per hour” or “rollback in under two minutes” circulate widely but do not trace to a primary, checkable source. Treat them as illustrative, not as commitments.

What makes robot canary different from web canary is the extra gate: physical state. You are not only watching server and application health, you are gating on each unit’s task and pose. A robot carrying a load or crossing an aisle is not eligible for an update until it reaches a safe, idle state.

This is where a fleet-coordination standard earns its keep. VDA 5050 (version 2.1.0, shipped August 2024; a major revision, version 3.0.0, followed in March 2026) is a JSON-over-MQTT interface that standardizes how a master controller exchanges order, state, and connection messages with heterogeneous AGVs and AMRs from different vendors. It does not define the update mechanism — but it is the layer that tells the fleet manager which robots are idle, where they are, and which can be pulled out of service for a canary push without stranding a task. Our piece on mixed-fleet interoperability with VDA 5050 and Open-RMF goes deeper into how that coordination works across vendors.

How does automatic rollback actually work?

Through A/B (dual-slot) partitions — a named mechanism, not a buzzword.

The Mender OTA client (open source) uses dual rootfs partitions: it writes the new image to the inactive partition while the device keeps running on the active one, then switches after a reboot; if the boot or a health check fails, the bootloader reverts to the previously working partition. NVIDIA’s Jetson Linux does the same on real robot compute: the Jetson Orin series keeps two rootfs slots (APP and APP_b) plus paired bootloader slots, and after a configurable number of consecutive failed boots (default 3) it fails over to the other slot; if both fail, it drops to a recovery kernel. Jetson is widely used in AMRs, which makes this a directly citable, vendor-documented example of automatic rollback.

One caveat operators forget: A/B rollback catches an update that fails to boot or fails a health check. It does not catch an update that boots cleanly and then behaves worse — a model or policy regression that passes every technical check but drives the robot badly. That failure class is exactly what canary cohorts and real-world monitoring exist to catch. Rollback and staged rollout are complementary, not redundant.

What stops a corrupt or malicious update?

A signing chain anchored in hardware. Firmware and software images are signed offline with a private key; the device verifies each stage’s signature against a public key anchored in a hardware root of trust — often one-time-programmable fuses — before executing bootloader, then kernel, then application. X.509 certificates handle the hierarchical key management. This is standard, vendor-neutral embedded practice.

At the repository level, two frameworks dominate the reference literature. The Update Framework (TUF), a CNCF project that graduated in December 2019, separates signing roles (root, targets, snapshot, timestamp) so that compromise of one key does not let an attacker forge a full update, replay an old vulnerable one, or mix and match components. Uptane adapts TUF for vehicles by splitting the server into a Director and an Image repository, so a single compromised repository cannot silently redirect a robot to a malicious image; it was built by NYU, SwRI, and UMTRI and is reference-implemented via the aktualizr client in Automotive Grade Linux. Both target cars, and both transfer cleanly to robot fleets.

For a robotics-native reference, NVIDIA’s open-source Isaac ota-file-service shows the shape concretely: a daemon on the robot processes file-deployment jobs and reports state over MQTT (topics like ota/<robot_id>/deploy and ota/<robot_id>/state), backed server-side by Postgres, an MQTT broker, and S3-compatible object storage.

What do standards and regulators actually require?

Automotive OTA is the most mature precedent, and robotics engineers now borrow from it directly. UN Regulation No. 156 has, since 2022, required vehicle makers to run an audited Software Update Management System (SUMS), re-certified at least every three years, alongside UN R155 for cybersecurity; ISO 24089:2023 supplies the technical how-to that R156 deliberately leaves unspecified. The transferable concepts are exactly the OTA primitives above: staged rollout, update authorization, rollback capability, and auditability. UL 4600 (Edition 3, March 17, 2023) frames the whole thing as a safety case that must be re-validated whenever the autonomy software changes — not a one-time checklist.

Robotics standards have caught up. ISO 10218-1 and 10218-2, both revised in February 2025, now treat functional safety and cybersecurity as explicit normative requirements and fully absorb the collaborative-robot force-and-pressure limits formerly held separately in ISO/TS 15066 — see our robot safety standards explainer for what those requirements mean in practice. In the US, ANSI/RIA R15.08-1-2020 was the first standard to formally separate AGVs from AMRs and set requirements for perception and collision avoidance. The through-line for OTA: a firmware or software change to a certified robot can alter a validated safety function, so it is a safety-relevant change, not a routine push.

Lifecycle planning matters too. ROS 2 ships on staggered, LTS-style distributions — Jazzy Jalisco (2024) is supported until May 2029, Kilted Kaiju (released May 2025) has active support through December 31, 2026, and “Lyrical Luth” is expected around May 2026. That cadence forces phased middleware upgrades across a fleet rather than one-shot jumps.

Why does fleet scale make OTA non-optional?

Because the fleets are already enormous. Amazon reported reaching 1 million deployed warehouse robots in early July 2025 across 300-plus facilities, and said roughly 75% of its deliveries are now assisted in some way by a robot; it also announced DeepFleet, a generative-AI routing model aimed at about a 10% fleet-speed gain. The broader AMR market is multi-billion-dollar and growing at double-digit CAGR, though analyst estimates diverge enough (Grand View Research put 2025 near US$4.74B, Mordor Intelligence near US$4.49B) that no single figure should be treated as settled.

At six-plus figures of physical units, a manual update is not a plan. A pipeline that can sign, stage, canary, and roll back is the difference between patching a fleet-wide defect overnight and grounding the fleet to do it by hand.

What does a safe robot-fleet OTA pipeline need?

• Signed artifacts verified against a hardware root of trust, with role-separated repository signing (TUF/Uptane-style).
• A/B slots with automatic rollback on boot or health-check failure.
• Canary cohorts gated on physical and task state, not just server health — coordinated through a fleet layer such as VDA 5050.
• Real-world monitoring to catch policy regressions that boot fine but behave worse.
• A living safety case and a records trail, because a safety-relevant software change carries reporting duties an app never does.

OTA does not make a robot fleet safer by default. A disciplined OTA process does — and a sloppy one just gives you a faster way to break every machine at once. For the underlying terms used here, see the glossary.