Article
Edge AI in robotics
Edge AI means running computation on the robot itself rather than sending data to a server. For anything safety-relevant this is not optional: a machine that needs a network round trip before deciding to stop is unsafe in a building whose connection is imperfect, and every real building's connection is imperfect.
Written by Hybot technical lead, Technical lead, Hyrcan-Tech · · 5 min read
Where Hybot stands
Hybot does not run inference of any kind — on the edge or in the cloud. What Hybot does have is the architectural split this article is about: a per-site Core RMS that runs inside the venue and holds the map, the task queue and the robots, and a Central Platform above it that oversees every project. Anything learned sits in the robot hardware, which is the manufacturer's domain.
The rule that decides where computation goes
One question: what is the worst thing that happens if this decision is two seconds late, or never arrives?
If the answer involves a machine failing to stop for a person, the computation has to be local. There is no architecture in which a stopping decision is worth a network round trip, and no building whose connectivity is good enough to make that a reasonable bet.
If the answer is "a dashboard is briefly stale", the cloud is fine and probably better.
The split in practice
| Layer | Examples | Tolerates delay? |
|---|---|---|
| On the robot | Obstacle detection, stopping, motion control | No |
| In the venue | Map, named points, task queue, assignment | Seconds at most |
| Central | Fleet view, health charts, configuration, campaigns | Yes |
Hybot's own structure follows the second and third rows. A single venue runs on its Core RMS and needs no central layer at all; the Central Platform becomes useful when there are several sites to oversee.
The consequence is worth stating plainly: a venue whose internet connection fails does not thereby lose its robots. It loses central oversight.
Connectivity as a monitored quantity
Because the boundary matters, connectivity itself is measured rather than assumed. Each project reports internet quality as client-to-project latency, charted over the last hour with weak, medium and strong bands, alongside service status and vendor API reachability — the monitoring article covers this.
A site with a marginal connection is then a known condition rather than a recurring mystery, and the intermittent-flicker pattern that produces "the robots are being weird" complaints becomes visible.
The cost side, briefly
Edge inference needs hardware on every robot, which costs money per unit and constrains what models can run. Cloud inference centralises that cost but introduces the dependency. Most real systems therefore split — and the useful question for a buyer is not which philosophy a supplier prefers, but which specific decisions they have put on which side.
Where to go next
Cluster hub: AI in robotics.
Frequently asked questions
Why can't perception run in the cloud?
- Because latency and connectivity are not negotiable for stopping behaviour. A robot that must consult a server before reacting to a person in its path will eventually meet a dropped connection at the worst possible moment. Immediate decisions have to be made locally.
What belongs in the cloud then?
- Anything that is not time-critical: fleet-wide coordination, historical counters, health monitoring, configuration and campaign scheduling. These tolerate a delay of seconds and benefit from seeing every site at once, which is exactly what a central layer is for.
What happens when a venue loses connectivity?
- The split is what determines the answer. Local decisions continue; central oversight degrades. In Hybot, internet quality is itself reported per project as client-to-project latency and charted over the last hour, so a site with a poor connection is visible rather than mysterious.
Where this fits
This page is part of AI in robotics: what is real and what is marketing. If you are working through the topic in order, these are the neighbouring pages.
Machine learning in robot navigation
Where learned models genuinely improve how a robot moves through a crowded venue, where classical planning still wins, and what Hybot actually uses.
Computer vision in robotics
What cameras and depth sensors are actually used for on a service robot, what they are bad at, and the privacy questions a venue should ask before installation.
Robot fleet monitoring and heartbeats
How a deployed site reports its own health — heartbeats, latency, service status and node redundancy — so problems are found before a customer reports them.
Take it further
If a question here applies to a venue you actually run, the specifics matter more than the general case.