Skip to main content
Avanti Robotics
Join the waitlist
AVM-WR-002Path landing

How an Avanti robot works

The three states a robot is in — on its own, connected, and being updated.

Designed in Britain, answerable in Britain.

A connected robot that fails when the broadband drops is not a safe robot.

1On the device

The robot’s core runs on the robot. If your broadband dies tonight, it still does its job.

Navigation, patrol, monitoring, fall detection and the safety responses all execute on board. They need no connection and do not pause when one drops.

Avanti · on-device coreSimulationUplink live

Avanti · on-device core

Simulation. This console is a model of an Avanti robot’s core, running in this browser. It is not connected to a robot.

Type ‘help’ for the command list.

Run ‘offline’ to cut the uplink. Every command still answers except ‘ota’.

Press Enter to run. The Up and Down arrow keys recall previous commands.

Cut the uplink — every command still answers except ‘ota’, the one that needs the link.

2Connected

The connection makes the robot visible to you. It sends telemetry — health, status, events — and carries live video, alerts with thumbnails, and the commands you send back. A household sees the companion app; a fleet operator sees the dashboard.

Your data is processed and stored on UK servers, under UK law — designed in from the start.

3Over the air

When it is online, behaviours and intelligence arrive as signed updates — the robot you unbox is the robot at its least capable.

How a signed update reaches a robotAn elevation on a single ground line. On the left the platform is drawn as a building cut through in section, with three floors labelled compose the behaviour, sign it with a detached signature, and publish it per tenant and per robot. Between the building and the right of the sheet stands a heavy hatched wall marked trust boundary, with exactly one opening cut through it. Two lanes pass through that one opening: the signed document going out to the robot, and the robot's error rates coming back. Beside the building a ladder of four equal rungs shows the update going to one per cent of a fleet, then ten, then fifty, then a hundred. On the right of the wall the robot stands on the same ground line, drawn as an undimensioned outline, with a verify step in front of it: a good signature is applied, and a missing, wrong or altered one meets a hard stop marked refused, nothing is applied.GROUNDTHE PLATFORM1COMPOSEthe behaviour,as a document2SIGNdetached signature.No key, no deployment3PUBLISHper tenant, per robotSTAGED1%10%50%100%of a fleet, in that orderTRUSTBOUNDARYthe signed documentand nothing elseerror rates backand the platform rolls the update back by itselfwhen error rates climb past the threshold4VERIFYbefore anything runssignature goodapplied5REFUSEDsignature missing,wrong, or alterednothing is appliedTHE ROBOTENVELOPE ONLYform not decidedELEVATIONNOT TO SCALEUNDIMENSIONED
AVM-FIG-03How a signed update reaches a robot

An update is a behaviour document — a versioned definition of what the robot should do, not compiled code. The platform composes it, puts it into a canonical form and signs it. The signing step is not optional in the sense that matters: if the signing key is unavailable, the deployment fails. It does not go out unsigned.

The wall across the middle of this sheet is a trust boundary, and it is drawn as a wall because that is what it is: the platform's authority ends at it. Exactly one opening is cut through it, and only the signed document goes out through that opening. Everything else the platform might want to do to a robot has no way across.

Beyond the wall the robot verifies the signature itself. If the signature is missing, wrong, or over a document that has been altered, the robot refuses, and the refusal is drawn as a hard stop rather than described as a policy, because it is a real outcome and not a reassurance.

A fleet does not receive an update all at once. It goes to one per cent of the fleet, then ten, then fifty, then all of it — so a problem is found on a handful of robots rather than every robot. If error rates climb past the configured threshold, the platform rolls the update back without waiting to be asked. Those error rates are the second lane through the same opening; there is no second hole in the wall.

The four percentages are the only figures on this sheet, and they are proportions of a fleet. The ladder is drawn as four equal rungs rather than four bars of scaled length, so nothing here can be read as a quantity we have not stated.