Published field note · Research note
· 5 min read
Cloud versus edge is the wrong robotics question
Place each robot operation by its deadline, data boundary, disconnect tolerance, and failure consequence instead of choosing one home for the whole robot.
Relay, a fictional mobile manipulator in a workshop tool crib, is closing a drawer when its wide-area connection disappears. The motor drive must keep current inside its limit. The local controller must finish or cancel the admitted motion. The perception stack may continue with reduced capability. A semantic planner can wait. Camera logs can remain on disk until the link returns. Asking whether Relay is “a cloud robot” or “an edge robot” gives one answer to five different failure problems.
Placement becomes useful only after the operation has a name. For each operation, ask four things: its latest acceptable completion time; the bandwidth or private data it consumes; how long it may tolerate disconnection; and what physical or operational consequence follows from lateness. Placement is the decision that follows from those constraints. It is not an identity assigned once to the machine.
A five-rung placement ladder
At the bottom, hard local safety and control owns current limits, watchdogs, protective stops, and fast stabilization. Its allowed latency is measured against the physical hazard, often microseconds to milliseconds, and disconnect behavior is “continue enforcing the local boundary or stop protectively.” Intrinsic’s technical specifications state a useful first-party boundary: its services do not override or replace robot-controller safety systems, and configured motion limits are not substitutes for the robot’s safety configuration. That is a vendor system boundary, not a comparative safety study.
One rung up, on-device perception handles observations whose age directly affects collision checking, localization, or grasp correction. It may use a camera, encoder, or local accelerator and operate within a millisecond-to-tens-of-milliseconds budget. If connectivity disappears, it continues locally, degrades to a declared sensor set, or withdraws the motion that depended on missing state.
Next, on-device policy and bounded skills can turn fresh observations into short action chunks or execute a validated trajectory. Their budgets may span tens to hundreds of milliseconds, but their output still passes local admission. Google DeepMind’s Gemini Robotics 2 announcement describes separate action, embodied-reasoning, and on-device model roles, including an on-device VLA intended for network-constrained operation. It shows one first-party model-family decomposition; it is not independent evidence that those models meet Relay’s deadlines or safety needs.
The fourth rung is near-edge service: a site server shared by several robots for heavier perception, map fusion, or policy inference. It can win when the site network has engineered tail latency, shared accelerators improve utilization, and every robot retains bounded fallback. A network partition should expire the remote lease or goal rather than silently extending it. Near-edge is remote compute with a shorter, observable failure path, not a synonym for local authority.
At the top, asynchronous cloud analysis and training receives logs, evaluates candidates, trains models, and prepares fleet updates. Seconds, hours, or days may be acceptable because no immediate actuator action waits for the result. Viam’s data-sync documentation describes local capture, buffering while offline, and resumed synchronization when connectivity returns. That is a concrete deferred-data pattern, not a fleet-reliability study; disk capacity, privacy, completeness, lineage, and rollout safety remain the operator’s work.
The strongest countercase is a controlled workcell with a private, redundant site network and a server that meets a measured deadline more reliably than a thermally constrained onboard computer. Placing perception or planning offboard may reduce robot heat, power draw, and hardware cost. The ladder does not say “closer is always safer.” It says that the offboard service must meet the operation’s deadline and partition contract, while hazards requiring faster independent enforcement stay below it.
What this does not prove
This note does not prove that cloud inference is unsafe, that on-device inference is deterministic, or that any cited vendor stack is production-validated for Relay. The five rungs are book synthesis, not an industry standard. They expose a reviewable decision: place each operation where its deadline, data boundary, disconnect behavior, and consequence of lateness can actually be enforced.
Which operation in your robot is placed by compute convenience today even though its failure consequence points somewhere else?
Open question
What I'm testing
Which operation in your robot is placed by compute convenience today even though its failure consequence points somewhere else?
Evidence boundary
Sources and boundaries
A linked source supports only its named role below. This note connects and tests ideas; the note itself is not evidence.
- production reportGoogle DeepMind Gemini Robotics 2 announcement
First-party description of action, embodied-reasoning, and on-device model roles; it demonstrates one disclosed product-family split, not independent deployment validation.
- official specIntrinsic technical specifications
States that Intrinsic services do not override or replace robot-controller safety systems; it defines a vendor boundary rather than comparing safety outcomes.
- official specViam data synchronization documentation
Documents local capture, offline buffering, and synchronization after connectivity returns; it is product behavior, not a study of fleet reliability or data completeness.