Use cases
Rollback that never needs to reach the robot.
The most dangerous release is the one that kills connectivity, because it takes out the channel you would fix it over. Every unit keeps a pinned known-good slot and reverts itself when the new image cannot prove it is healthy.
Remote rollback is a contradiction
Every OTA system has a rollback story. Most of them are a button in a console, which works precisely when it is least needed and fails exactly when it matters: the release that broke the modem, the driver that hung the boot, the config change that put the unit on a network it cannot see.
If recovery depends on reaching the device, then recovery does not cover the failures that make the device unreachable. Those are also the expensive ones, because they end in a truck roll.
So the decision has to be local. The device runs the new image on trial, judges it against real checks, and reverts itself if it cannot produce a positive result. The cloud finds out afterwards, and finding out afterwards is fine.
How a trial boot works
01Stage to the inactive slot
The agent writes the new image to the slot the unit is not running from, checks the signature, and touches nothing that is currently in use. A power loss here costs a download, not a robot.
02Switch atomically, boot on trial
One atomic write flips the active slot and sets a boot counter. The bootloader now expects to be told the boot succeeded, and will not take silence for an answer.
03Prove it, locally
The new image runs its own health suite: services up, mission metrics within bounds, and a successful call home. Clearing the boot counter takes a positive result, so failure is the default state.
04Revert unaided, report later
If the counter is not cleared, the bootloader falls back to the previous slot on the next reset. The unit comes back on the old build and reports the self-revert whenever it next has signal.
The device half of the file
verify: # runs ON the device, offline trial_boot: 3 attempts confirm_within: 15m checks: - service: nav-core healthy - metric: obstacle_response_ms < 200 - reachable: control-plane # killed the modem? revert on_failure: revert_and_report slots: layout: a_b # two full system slots, one active recovery: immutable # the update path cannot write to it power_loss: safe # switchover is a single atomic write
The reachable: control-plane check is the one that earns its place. It makes connectivity part of the health definition, so a release that breaks the network path fails its own trial and reverts, rather than surviving as a healthy-looking unit you can no longer talk to.
The immutable recovery image is separate from both slots and is not writable by the update path. It is what remains when both slots are somehow bad, and it exists so that the worst case is a technician with a known procedure rather than an RMA.
What this does not do
Worth being clear about
- It does not recover from hardware failure. A dead eMMC or a failed radio is a truck roll, and no update system changes that.
- It does not roll back your data. If a release migrated a local database or rewrote a map format, reverting the image does not undo that, and the migration needs to be backwards compatible for one release.
- It does not protect against a bad recovery image. That slot is verified and attested, but it is the floor of the system, and shipping a broken one is the one mistake with no automatic answer.
- It is not instant. Trial boot, health suite and confirmation take minutes, not seconds, which is the price of judging the release properly rather than optimistically.
Early access
Running robots in the field?
We are taking on a handful of fleets this year, in agriculture, inspection, drones and logistics. Few enough that you get direct engineering time rather than a support queue.
Founding customers get direct engineering time and a permanent founding rate.