Drones and delivery robots run their perception and control on board, because a decision that depends on a network is not a decision they can rely on. But every one of them eventually needs a human, a map update, a fleet instruction or a way to say it is stuck — and the interesting engineering is at that boundary rather than in the autonomy itself.
The split is not negotiable: anything with a safety consequence runs locally, and anything that benefits from a wider view runs remotely. Confusing the two produces a platform that stops when the network does.
| Signal | How | What it changes |
|---|---|---|
| Perceive | Cameras, LiDAR, radar and IMU fused on board | Latency and availability both rule this out of the network. It runs locally or it does not run |
| Decide | Path planning and obstacle response, on the platform | A decision that depends on a link is a decision that fails with the link |
| Report | Telemetry, position and health, continuously | Small, frequent, and tolerant of gaps — the fleet needs to know, not to control |
| Stream | Video for supervision or evidence, on demand | The largest data by far, and the first thing to sacrifice when the link degrades |
| Escalate | Handing control to a remote operator when the platform is stuck | Rare, and the hardest requirement in the system, because now latency is a safety parameter |
| Update | Maps, models and firmware across the fleet | Staged, verifiable and reversible, because a bad model reaches every unit at once |
The sensing is the solved part. These are what determine whether the deployment is still running in year three.
A delivery robot crosses from depot Wi-Fi to cellular and back several times a shift; a drone moves between cells at speed. Each transition is a moment where a session can drop. Designing for a single link technology is straightforward; designing for the seam between two is where the field failures come from, and it is rarely tested because it is hard to reproduce on a bench.
When a remote operator takes control, the glass-to-glass delay stops being a comfort question. The operator is steering a physical object from a picture that is already old, and the platform must behave predictably in the gap between command and effect. Systems that support teleoperation without a defined latency budget and a defined behaviour when it is exceeded are not finished.
The honest question is not what the platform does with connectivity but what it does without. Continue, hold, return, or stop safely — each is correct in some context and dangerous in others. It has to be specified per operation, implemented explicitly, and tested by actually removing the link rather than by simulating it.
Every watt of inference is range on a battery platform, and the enclosure is sealed against weather, so the heat has nowhere convenient to go. That constraint sets model size and frame rate before any accuracy target does, which is why quantisation and architecture choice belong at the start.
A perception model that regressed reaches every unit simultaneously unless the rollout is staged. Canary units, held-back cohorts, and a rollback path that works when the new build is the thing preventing connection — these are the difference between an update mechanism and a recovery plan.
GNSS drops in urban canyons, indoors and under structures. Dead reckoning drifts. Visual localisation fails on featureless surfaces. Every real platform fuses several sources and needs defined behaviour when the best one is unavailable, which is a design decision rather than a library setting.
Platforms that move, decide for themselves, and still need to be part of an operation.
Wi-Fi to cellular handover, teleoperation for edge cases, and pedestrian-safe degraded behaviour.
Video downlink and a separately designed command link, with BVLOS lost-link behaviour defined.
Dense Wi-Fi or private 5G, fleet orchestration, and safe interaction with people and equipment.
Mixed coverage, ruggedised compute, and long update cycles across a dispersed fleet.
Because latency and availability both rule it out. A platform that needs a network to avoid an obstacle stops being safe the moment coverage drops. Perception and control run on board; the network carries reporting, supervision and updates.
Handover. A robot crosses between depot Wi-Fi and cellular several times a shift, and each transition can drop a session. Designing for one link technology is straightforward; designing for the seam between two is where field failures come from, and it is rarely tested because it is hard to reproduce on a bench.
Low enough that an operator can steer a physical object from a picture that is already old — and, more importantly, with a defined behaviour when the budget is exceeded. A teleoperation system without a stated latency limit and a stated response to breaching it is not finished.
Whatever was specified for that operation: continue, hold position, return, or stop safely. Each is correct somewhere and dangerous elsewhere. The important part is that it is decided deliberately, implemented explicitly, and tested by removing the link rather than simulating it.
Power and heat. Every watt of inference is range on a battery, and a sealed weatherproof enclosure has nowhere convenient to put the heat. That sets model size and frame rate before any accuracy target does.
In stages, with canary units and held-back cohorts, and a rollback path that works even when the new build is what is preventing connection. A regressed perception model otherwise reaches the whole fleet at once.
The link, designed as two.
KNOWLEDGEGlass to glass, honestly.
PRODUCTCompute on the platform.
AIPosition from several sources.
KNOWLEDGEStaged update and rollback.
SOLUTIONThe adjacent discipline.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.