Edge vs Cloud for Robots: What Runs Where

Anything that decides how the robot moves belongs on the robot, and the cloud earns the work that can wait: training, fleet data, dashboards. Networks stall without warning, and a robot waiting on a reply keeps its last command through the stall, so the loop stays on the machine under ROS 2 or HORUS alike. That flips when the model will not fit on the robot at all. This post is for someone building a robot around a model and deciding which parts to host and which to ship on the machine.

The demo worked in your office. A frame goes up to a hosted model, a plan comes back, the arm does the thing, and the room claps. Then you carried the robot to a different building, and the same demo hesitated in the middle of a reach, held still with the gripper half closed, and finished the motion as though nothing had happened. Nobody said the word network out loud, but that is what everyone watched.

So you started logging, and most of the time everything looked ordinary, with the trouble showing up rarely and never while you were watching. You added a retry. Then you added a timeout, and found you had no idea what the robot should do when the timeout fires, because the plan it was following came from somewhere that is no longer answering. Meanwhile the hosting bill grows with every camera, and someone has started asking whether this works without Wi-Fi, in a customer's building, on a floor you have never seen.

Underneath all of that sits a question you have not answered on purpose: which parts of this robot are allowed to depend on a network, and which are not.

Should a robot's thinking run on the robot or in the cloud?

The deciding that moves the robot runs on the robot, and the cloud takes the work that can be late without anyone getting hurt. That line is not a preference, it is the shape of the situation: a robot is a body in a room, and a body cannot pause halfway through a motion while a server thinks about it. The moment any part of the motion depends on a reply from elsewhere, the robot's behaviour becomes a property of a network you do not control. That is survivable for a demo and not survivable for a product, because networks in real buildings are worse than networks in offices, and they fail in the least convenient way, which is briefly and at random rather than obviously and forever. The useful framing is not edge against cloud as a technology argument, and it is not about which computer is bigger. It is a question about consequences: what happens to the machine during the seconds when the answer does not arrive. Sort every piece of your system by that one question and the split mostly writes itself.

What do edge and cloud actually mean for a robot?

Edge means the computer answering the question travels with the machine, and cloud means the computer answering it lives somewhere the machine has to reach across a network. Those two words hide a third case that catches people out, which is a server in the same building on the same local network — physically near, still on the other side of a cable and a switch that can drop. For a robot, the honest distinction is not distance but dependency. Anything the robot can do with the network unplugged is on-board. Everything else, however close the machine is, is something you are trusting a link to deliver. Most robots end up with three tiers whether or not anyone planned them: a microcontroller nearest the motors that never asks anyone anything, a computer on the robot that does the sensing and the deciding, and somewhere off the robot where training, storage and dashboards live. The interesting design work is deciding what belongs in the middle tier, because that is where everything ambiguous ends up by default.

What are the real ways to split work between a robot and a server?

There are about seven arrangements people actually ship, and they differ only in where the line between must-happen-now and can-happen-later sits. You can run one program on the robot and use no server at all. You can run ROS 2 on the robot and treat the cloud as a place to send logs and receive updates, which is what most fielded machines do. You can run HORUS on the robot, an open-source real-time robotics middleware for Rust, Python and C++ under Apache-2.0, where the three languages share the same shared-memory ring buffers, so a Python model process and a compiled control loop on the same machine exchange messages without serialising them between processes, and keep the server for training and fleet data. You can split the brain, planning remotely while reflexes stay local. You can host everything and treat the robot as a remote body. You can put a companion computer beside the robot on a local network. Or you can upload nothing live and batch everything after the run. Read the table as situations, not as a ranking.

Which split fits a solo builder with one robot?

Keep everything on the robot and use a server only for storage, because a solo builder has no capacity for a second failure domain. Every hosted piece adds an account, a key, a deployment path, an outage you cannot fix and a cost that arrives monthly whether or not the robot ran. On one machine you can put the whole system in front of you, restart it, and know what changed. The exception is training, which nobody should do on the robot, and which is naturally offline anyway: gather data, take it to a bigger computer, bring a model back. That workflow needs no live connection at all, which means no part of the running robot depends on the network being up. If you want an assistant model in the loop for planning, treat that as a nice-to-have layered on top of a robot that already works without it, so a bad Wi-Fi day costs you a feature and not the machine. Whether your robot should run one computer or several is the same question asked one level down.

What if the computer on the robot is a small board?

A small board changes what you can carry, not where the line goes, so keep the deciding local and shrink the model rather than exporting the loop. Builders hit this early: the board handles the wheels and the camera comfortably, then a model is added and everything on the machine starts competing for one modest processor. The instinct is to move the model off the robot, and for the largest models that is right. Before that, check the cheaper fixes, because most small boards are not short of processing so much as busy with work nobody asked for — frames copied several times on their way between programs, a graphical tool left running, logging that interrupts the loop it is logging. A board that stutters under a camera stream will usually stutter under the same stream after an upgrade, just less often. And if the model does have to leave, the split is not negotiable in one direction: whatever keeps the robot safe stays on the board, however small the board is, because that code has to run when nothing else answers.

What if you need a working demo in a few weeks?

Host everything, get the demo working, and write down plainly that this is a demo rather than a product. A short timeline is not the moment to design a failure story for a network you have not met yet, and a hosted model behind a simple call is the shortest path from an idea to something moving on video. Take the shortcut deliberately, with two conditions attached. First, keep one boundary honest: whatever talks to the motors is the only thing that talks to the motors, and it can refuse a command that arrives too late or looks wrong. That single rule is what lets you move the brain later without rewriting the robot. Second, tell your audience what they are watching, because a demo that quietly depends on your office network will be believed as a product, and the belief will be tested in a building where it does not hold. Demos that hide their dependencies do not fail on stage, they fail in the deal after the stage.

What if you come from web and model work rather than robotics?

Expect the network assumptions you have built a career on to be exactly the ones that break, because a web request that arrives late is slow while a robot command that arrives late is wrong. In web work, retries, queues and eventual consistency are good answers. On a machine with mass and momentum, a retry means the arm carried on doing the previous thing for another moment, and a queue means the robot is acting on a picture of a room that has since changed. The mental shift is that lateness is a behaviour, not a delay. The habits that transfer well are the good ones: versioning, observability, treating deployment as a first-class problem, and refusing to let anything run only on one person's laptop. The habits that transfer badly are the assumption that the network is basically up, and the assumption that you can fix a bad state after the fact. Robots do not have an after the fact. What sits between the model and the motor is worth reading before you design your first split.

What does a bad split look like when it fails?

A bad split fails as hesitation rather than as an error, which is why it survives so long undiagnosed. The robot does not crash and no exception is logged. It reaches, pauses mid-motion with the gripper open, then completes the reach into a space where the object no longer is. Or it repeats the last command it was given, gently and continuously, which on a mobile base means driving into something at walking pace while every dashboard reports healthy. The signature to watch for is a fault that appears in one building and not another, or on one day and not the next, or that disappears the moment somebody sits down to observe it with a laptop on the same access point. Another tell is that the fix that helped was a longer timeout, which never fixes anything and only widens the window in which the robot is behaving on stale information. When a failure looks like this, stop tuning and ask a design question instead: what was this machine supposed to be doing while it waited, and who decided that.

What changes as the robot gets more demanding?

The line moves inward, not outward: as a robot does more, more of its work turns out to be time-critical, and things you happily hosted start coming home. A slow inspection robot can afford to ask a server what it is looking at. Give the same platform an arm, and grasping cannot wait for a round trip, because the object is being touched and the world is changing under the plan. Add people nearby and the safety behaviour must be local by law and by conscience. Add a fleet and you gain a genuinely cloud-shaped problem for the first time, which is learning across machines. That is the usual arc, and it is worth designing for early because it is cheap to move work outward later and painful to bring it back. The teams who suffer are the ones whose first product hosted the decision loop and whose second product had to be faster, at which point the network dependency is threaded through every feature they shipped in between.

What do you give up by keeping everything on the robot?

You give up the biggest models, cheap upgrades and a single place to look when something goes wrong, and all three are real costs. A model on the robot is bounded by what the robot can carry, power and cool, which means choosing something smaller than the one you would use in a browser. You give up the ability to improve every machine by redeploying a service, and inherit the harder problem of updating software on hardware that is somewhere else, possibly asleep, possibly with a customer standing next to it. You give up centralised observability unless you build the pipe for it, so debugging becomes an exercise in getting logs off a machine after the fact rather than watching them live. You also give up some of the economics, since a rented processor is shared and a carried processor is bought once and idles when the robot is parked. None of that changes the verdict for the control path. It does mean an all-on-board design needs deliberate answers for updates and logs, which teams routinely forget until the first field deployment.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the robot needs software that already exists, and for a machine spanning several computers it is the default for good reasons. If the robot must build a map and navigate to a point on that map, use ROS 2, because mapping and navigation are years of work sitting there under a permissive licence. If your sensors ship ROS 2 drivers and nothing else, the decision was made when you bought them. If the robot is genuinely distributed across a robot, a companion box and a workstation on one local network, that is the shape ROS 2 was designed for, and rebuilding the discovery, tooling and recording that come with it is a project of its own. If you are hiring, ROS 2 is what candidates know. HORUS is not the answer in any of those cases, and choosing it there costs you the packages that were the point. Where the leaner path wins is narrower and specific: one machine, a model and a control loop, large data crossing between them constantly.

Will a faster network make this split stop mattering?

No, and here is why: the problem was never the average, it was the pauses. Better connectivity raises what a link does most of the time and does very little about the moments it stops answering, and those moments are what a robot's behaviour is decided by. A wireless link contends with every other device in the building; a mobile link hands between cells; a corporate network reroutes at times nobody publishes. Each of these produces a gap, and a gap is exactly the event your robot has no plan for. Notice also what happens to your incentives when a link is usually good: you push more into the hosted side because it seems to work, so the pause gets more expensive when it comes. The right response to a good network is not to depend on it more, it is to enjoy the extra headroom for the work that is allowed to be late — telemetry, models, replays, fleet data. Why ROS 2 breaks on normal Wi-Fi shows how the same assumption bites even without the internet involved.

Is the cloud cheaper than putting a real computer on the robot?

Partly, but not the way you think. Renting is genuinely cheaper while you have one robot and an idea, because you pay for the moments you use and skip the money and the weeks that a carried computer costs. The maths inverts quietly as machines multiply, since a robot that runs all day is a steady bill forever while the same processor bought once keeps working after it is paid off. But the real cost is rarely the invoice. It is the engineering you have to do because the deciding lives elsewhere: the fallback behaviour, the timeout policy, the reconnect logic, the state machine for what the robot does while blind, the security review because a machine that can move now has an open door to the internet. That work is invisible on a spreadsheet and it is where the months go. Weigh it as a design decision that happens to have a bill attached, and price both sides. Middleware for robots that run a model on board covers the other half of the same question.

How do you decide what runs where?

Take every part of your system and ask one question about each: if this answer arrives late, does a motor do the wrong thing? That single sort does most of the work. Anything that answers yes stays on the machine, no exceptions and no clever tricks with timeouts, because a timeout only tells you that you are late, not what to do about it. Anything that answers no can live anywhere convenient, and the cloud is usually the convenient place. Two follow-ups settle the rest. Ask what the robot does during a total outage, and if you cannot describe that behaviour in a sentence, you have not finished designing the system. Then ask whether the model you want genuinely will not fit on the machine, and be honest that a smaller model on board frequently beats a larger one that is sometimes unreachable. Why demos with hosted models fail at home is the field report for exactly this decision going wrong.

Decide by consequence rather than by architecture fashion:

• If a late answer would move a motor at the wrong moment -> keep that part on the robot, because no network promises to be on time.
• If a late answer would only annoy an engineer -> put that part on a server, because the computer riding on the robot has better uses.
• If the model will not fit on anything the robot can carry -> plan remotely and keep local reflexes, so the machine stays safe when plans stop arriving.
• If the robot never leaves a building you control -> a companion computer on the local network is a fair middle, provided the robot survives losing it.
• If you are still proving the idea -> host everything and say out loud that this is a demo, not a product.

When the choice gets serious, weigh it on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target and licence. No scores, just the option that loses on the fewest axes for the machine you are actually building. And if that machine keeps ending up as one computer carrying a model, a control loop and a camera stream that has to reach both, star HORUS on GitHub so it is in your list when you start building.