Should Your Robot Run One Computer or Several?

Start with one computer, plus a microcontroller for the motors, and add a second computer only when a physical constraint forces it. Extra machines buy isolation and placement freedom, and charge for it in wiring, clock drift and network faults. That flips when sensors sit too far apart to wire to one board, or when the work simply will not fit, on ROS 2 or HORUS alike. This post is for a team drawing boxes on a whiteboard and trying to decide how many of those boxes need their own hardware.

Somebody drew the architecture diagram, and it has four boxes in it. Perception on one, planning on another, control on a third, and a fourth for the interface, because that felt right. Nobody in the room has said out loud that each box is a separate computer, but the diagram is drawn that way, and the parts order is due on Friday.

The arguments in the room are all reasonable. If perception has its own machine, the vision work cannot starve the control loop. If control has its own machine, a crash in the planner cannot take down the motors. If there is a spare board, the new person can work without touching the robot everybody else is using.

Then someone asks how the boards will talk to each other, and the room goes quiet for a moment. Ethernet, probably. Or Wi-Fi, which would be tidier. Someone mentions timestamps. Somebody else remembers a previous project where two machines disagreed about what time it was, and the whole system behaved strangely for a fortnight until they found it.

Should your robot run one computer or several?

One computer, for almost every robot, with a microcontroller alongside it for anything with a hard deadline on the motors. That arrangement covers most wheeled robots, most arms, most inspection and delivery machines and virtually every prototype, because a modern compute board holds more work than teams expect and because everything on one board can share memory, share a clock and start in a known order.

Several computers become correct when something physical demands it. Sensors mounted too far apart to wire to one place. An actuator that must be driven from a board bolted next to it. A safety function that is required to keep working when the main computer is rebooting. A workload that genuinely will not fit, proven by measurement rather than by fear.

What is not a reason is tidiness. A diagram with four boxes does not need four computers; it needs four programs, and programs are free. The instinct comes from cloud architecture, where machines are rented by the hour and appear on request. On a robot, every machine is a physical object with a power budget, a cable, a boot sequence and a way of failing at an inconvenient moment.

What does one computer or several actually mean on a robot?

It means how many independent machines, each with its own processor and its own clock, your software is spread across. The distinction that matters is not how many programs you run but how many places those programs cannot simply hand each other a pointer to the same memory. Two programs on one board can look at the same data. Two programs on two boards must pack it up, send it over something, unpack it at the far end, and agree on what time it was made.

Most robots are already split even when people describe them as having one computer. A Linux board runs perception and planning, a microcontroller runs the motor loop, and a motor driver has its own small processor that nobody thinks about. That is three machines by any honest count, and nobody calls it distributed because the boundaries were chosen by physics rather than preference.

The question in front of you is therefore narrower than it sounds. It is not whether to distribute at all, but whether to add another general-purpose computer to a robot that already has one, and what you gain for the cables.

What does it look like when a robot has been split wrongly?

It looks like a robot whose faults move around. A behaviour fails on Tuesday, works on Wednesday, and comes back on Thursday when someone opens a video stream on their laptop. Nobody can reproduce it deliberately, and every engineer has a different theory because each is looking at a different machine and seeing half the story.

The tells are worth memorising. Logs from the two boards cannot be lined up, because their clocks disagree by an amount nobody has measured. A sensor reading arrives with a timestamp that makes it look newer or older than it is, so the fusion step quietly produces nonsense at exactly the moments the robot is moving fastest. Startup order matters, and the robot needs to be powered on in a particular sequence that lives in one person's head.

And the giveaway: adding a listener changes the robot's behaviour. Someone opens a monitoring tool and the arm becomes less precise. That means the link between machines is carrying more than it comfortably can, and the control path is sharing it. Why ROS 2 struggles on ordinary Wi-Fi covers the worst version of this.

What are your actual options for laying out the compute?

There are eight layouts worth considering, and they do not form a ladder from worse to better. The simplest is one board running one program, which is right for a first robot. Next is one board running several programs under a middleware, where most robots live and where that choice starts to matter. Then comes the split almost everyone adopts eventually: a Linux board for perception and planning plus a microcontroller for the motor loop, which separates the deadline-critical work cheaply and without a network.

Beyond that the options get more expensive. Two Linux boards. A robot board plus an off-board laptop. A robot plus a server for work that can wait. Several microcontrollers on a shared bus, which is how machines with many joints are wired.

On the middleware question, ROS 2 and HORUS answer differently. The first was designed for a graph that spans machines, handling discovery and transport across them. The second is an open-source real-time robotics middleware for Rust, Python and C++ that share the same shared-memory ring buffers, so programs on one board exchange messages without serialising them, published under Apache-2.0 and validated in simulation. Shared memory ends at one machine's edge, so a robot spanning boards still needs a network transport between them.

How do these layouts compare side by side?

Read the last column first. Most teams can eliminate half the table in a minute, and the real argument is usually between the third row and the fourth.

Are you one person, a small team, or a company shipping units?

If you are one person, use one computer. A single maintainer pays the entire cost of every extra machine and receives none of the benefit, because the main thing a second computer buys is the ability for two people to work without colliding, and there is no second person. Every hour spent on boot ordering and clock alignment is an hour not spent on the robot's actual job.

A team of three to eight is where a second machine can earn its place, and also where it is most often added for the wrong reason. The right reason is that two subsystems have different owners and different release rhythms. The wrong reason is that the diagram looks cleaner. Ask which person owns each box; if the same person owns two of them, they do not need separate machines.

If you are shipping units, every extra computer multiplies across the fleet: more cost per robot, more connectors that vibrate loose, more firmware to update in the field, more ways for a customer's robot to fail where you cannot watch. Whether a stack scales to a commercial product is the right companion read before committing.

What hardware are you actually choosing between?

Start with the physical layout of the robot rather than the software. Walk the machine and note where every sensor and every actuator physically sits, then ask how long a cable would have to be to reach one central board. If every cable is short and nothing moves through a joint that would flex it, one board is viable and probably correct. If a sensor sits at the end of a rotating arm, or a camera is in a head that turns, the wiring argument may decide this for you before any software argument gets a hearing.

Then look at what your compute board actually has. Many boards now carry more processing capacity than a mid-size robot uses, and teams add a second machine while the first sits half idle. Check before you buy.

Power and heat matter more than people expect. A second board draws current from your battery budget, adds heat inside an enclosure that was already warm, and needs its own protection when the supply sags as the motors pull. What else runs on a robot besides your own code is a useful inventory before you assume there is room.

How long until this has to work in front of someone?

With a demo in two weeks, use one computer, full stop. A second machine introduces exactly the class of problem that ruins demos: an intermittent link, a boot order nobody wrote down, a clock that drifts during the presentation. If something does not fit on the one board, cut the something rather than adding hardware. Turn the camera resolution down, drop a feature, run the heavy analysis afterwards from a recording.

With a couple of months, you have room to test a split properly, which means deliberately abusing the link. Unplug the cable mid-run. Saturate the network with a video stream while the robot is moving. Power the boards up in the wrong order. If the robot handles all three, the split is real; if not, you have found the work the diagram hid.

With a year or more, decide by where the product is going. A robot that will grow more sensors along a physical structure is heading towards a bus and distributed microcontrollers regardless of what you do now. A robot that will stay compact is better served by one strong board and a smaller number of things to certify, update and support.

What does your team already know how to do?

If nobody on the team has debugged a network in anger, a second computer will cost more than you think. The skills are specific and not interchangeable with general software ability: reading a packet capture, recognising a multicast problem, knowing what happens to a queue when a link saturates, keeping two clocks aligned closely enough that fused sensor data means anything. A team without them does not lack intelligence, it lacks the reflexes, and it will acquire them at the worst possible moment.

If your team is comfortable with embedded work, the microcontroller split is nearly free and you should take it early. Firmware people are rigorous about timing in a way application developers are not, and that rigour is what a motor loop wants.

If your team is mostly Python, a single board keeps the whole system inside one debugger and one log file, which is worth more than architectural elegance. Mixed-language teams should think about where the Python and the C++ meet, because a language boundary and a machine boundary in one place is two hard problems stacked together. Whether to use one language or several goes deeper on that.

What do you give up by adding a second computer?

You give up the shared clock, and this is the cost people underestimate most. On one machine, every timestamp comes from the same source and comparing two readings is trivial. Across two machines, the clocks drift apart continuously, and every piece of fused data now depends on how well you have aligned them. Sensor fusion built on misaligned clocks does not fail loudly; it produces plausible answers that are subtly wrong when the robot moves quickly.

You give up the ability to hand another program a pointer. Anything crossing the link is packed and unpacked, which puts a floor under how quickly data can move and adds a queue that can back up under load.

You give up simple startup and simple failure. Two machines means a boot order, a reconnection story, and a decision about what the robot does when one half stops answering. Nobody writes that decision down early, so the robot makes it by accident, usually by driving on with data that stopped updating a moment ago.

And you give up one log file. Debugging across two machines with unaligned clocks is a distinct skill.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever your robot genuinely spans more than one machine, and HORUS is not the answer for a system whose hard problem lives on the network between boards. ROS 2 was designed for a graph distributed across computers: discovery, addressing, transport and the tooling to inspect all of it from anywhere on the network. Rebuilding that yourself is a project, not a task.

Choose ROS 2 when your robot has an off-board component, when a fleet reports to a server, when you need mapping or navigation or arm motion planning, and when your sensors arrive with vendor drivers already written for it. Choose ROS 2 when you are hiring, because the vocabulary is shared and a new engineer can be useful in their first week. Choose ROS 2 when the packages are most of what you need, which is true more often than the people arguing about transports like to admit.

The counter-case is narrow and specific: several programs on a single board, passing large messages every cycle, with a control loop that is late because of it. That is a same-machine problem, and a same-machine tool is the right shape of answer.

Does a second computer give you more compute?

No, and here is why: the work does not become smaller when you spread it out, and the act of spreading it adds work of its own. Data that used to move between two programs by reference now has to be packed, sent, received and unpacked, and that packing happens on both machines. A robot that was short of capacity is now short of capacity in two places while also spending some of what it has on the link.

There is a second effect that surprises people. Splitting a workload across machines often makes the timing worse rather than better, because the path a decision travels now includes a network whose behaviour changes with load. The control loop was competing with perception before; now it is competing with perception and waiting on a queue.

If the diagnosis is genuinely that one board cannot do the work, the honest options are a better board, less work, or moving the deadline-critical piece to a microcontroller. Check first whether the bottleneck is the board at all, because it is often the traffic between programs on it rather than the processor.

Does splitting the robot make it fail less often?

Partly, but not the way you think: separation contains some failures and creates a new category of its own. The genuine benefit is real and worth naming. If the planner crashes on its own machine, the motor controller keeps holding the arm still rather than going down with it. A watchdog on a separate processor can stop the robot when the main computer stops answering, and that is exactly why safety functions live on separate hardware in serious machines.

What you get in exchange is a link, and links fail in ways that single machines do not. A cable works loose. A switch reboots. A network saturates and packets that used to arrive start arriving late or not at all. Worse, these failures are usually partial: the link is up but slow, so both halves believe they are fine while the robot behaves as though it is drunk.

The useful rule is that separation helps when the boundary is chosen to contain a specific, named failure. Separation hurts when the boundary was drawn on a whiteboard because the diagram looked balanced.

How do you decide how many computers your robot needs?

Decide by starting at one and requiring evidence to add another. Write down every reason someone has given for a second machine, then sort each into three buckets. Physical: a cable cannot reach, or a sensor must sit where a board cannot. Capacity: the work has been measured and does not fit. Organisational: two teams need to release independently. Anything fitting none of these is tidiness, and tidiness is not worth a cable.

For the physical bucket, ask whether a microcontroller or a smart sensor would do instead of a full computer. For the capacity bucket, insist that someone actually run the workload on the board before ordering parts. Teams are wrong about this more often than they are right, and the wrongness is nearly always in the direction of underestimating the board.

For the organisational bucket, remember that separate processes already give you most of what you want. Two teams can own two programs on one machine without touching each other's code. Why robot projects outgrow their first framework is the pattern to watch for as this evolves, and sim-to-real trouble frequently turns out to be a timing problem created by a split nobody questioned.

Here is the whole decision in six lines.

• If you are one person building a first robot -> one board, because every extra machine costs more than it gives.
• If anything has a hard motor deadline -> one board plus a microcontroller, because that boundary is chosen by physics.
• If a sensor cannot physically reach a central board -> a second machine, because no software decision beats a cable length.
• If two teams release on different schedules -> separate processes first, and separate machines only if that is not enough.
• If a demo is close -> whatever you already have running, because links and boot orders are what ruin demos.
• If programs on one board pass large messages every cycle -> the messaging layer before the hardware, because that is the one case where it is the culprit.

The HORUS Fit Framework compresses the software side onto five axes you can score any option against: ecosystem size, setup effort, team size fit, deployment target, and licence. Deployment target does most of the work here, because a one-board robot and a robot spread across three machines want different foundations.

When your robot settles on a single board and the traffic between its programs is what holds the loop back, the useful thing is having the option on your shelf rather than starting a search under deadline. Put HORUS on that shelf now: star it so it is in your list when you start building.