Should a Two-Person Team Adopt ROS 2?

Yes, adopt ROS 2 if two people need drivers, mapping and navigation they will never write; otherwise a smaller stack such as HORUS fits better. Two people can carry ROS 2's upkeep only when the ecosystem gives back more than it costs, and for most mobile robots the ecosystem does. The verdict flips when the robot is one computer running one loop and neither of you opens the catalogue. The rest of this post is for two-person teams making the call once, early, with no spare person to redo it a year later.

There are two of you. One does most of the software, the other does hardware and the rest of the software, and both of you have a day job or a thesis. The first month went somewhere. Not into the robot — into installing things, into a build error nobody on the internet seems to have had, into a tutorial written for a version that is not the version in your terminal. The robot has moved twice, both times by accident. What makes this worse with two people than with one is that your machines are not the same machine. A fix typed into one terminal on a Tuesday never reaches the other laptop, so the robot runs on exactly one computer in the house and neither of you is sure why. When something breaks, the person who did not break it loses the evening. Nobody is doing anything wrong; there is more surface here than two people can hold, and most of it belongs to a framework adopted in week one because every tutorial used it. The question underneath is not which tool is most capable. The question is which one you will still be running when the robot finally works.

Should two people adopt ROS 2, or start smaller?

Two people should adopt ROS 2 when the robot depends on parts the catalogue already contains, and should start smaller when it does not. That sounds like a dodge until you write the list down, at which point it decides itself in about five minutes. Put on paper every piece of your robot you were never going to write yourself: the lidar driver, the mapping, the path planner, the arm motion planner, the simulator, the visualiser. If that list is long and specific, adopt ROS 2 and accept the upkeep, because rebuilding those pieces is a multi-year project and there are two of you. If the list is short and vague — "probably some driver stuff" — then you are considering ROS 2 for reasons of respectability rather than need, and the upkeep gets charged to you regardless. The second question is how many computers will run your code once the robot works. One computer plus a short list is the case where a full framework contributes packaging and bills you evenings. Everything else on this page is elaboration on those two lists.

What is ROS 2 in plain terms, and what are you committing to?

ROS 2 is a message system, a build system and a package catalogue, sold as a single decision. The message system moves data between the programs that make up your robot and decides what happens when one of them is slow or gone. The build system expects your code arranged its way, in packages, with manifests, compiled by its own tool rather than the one your language normally uses. The catalogue is the several thousand packages other people wrote to those conventions — drivers, planners, mapping, simulation bridges, a visualiser that discovers what is running on its own. Adopting ROS 2 means adopting all three, because the catalogue only works if you accept the build system, and the build system only makes sense if you use the message system. That bundling is exactly why ROS 2 is worth so much when you use the catalogue and so expensive when you do not. The part small teams underestimate is the middle one: the build tool, the environment files, the version pinning. That is where the evenings go.

What are the actual options for a team of two?

There are five realistic options, and the shortlist is shorter than the internet suggests. The first is ROS 2 in full, which hands you the message layer, the build system, the catalogue and the tooling as one adoption. The second is a single-machine middleware such as HORUS, an open-source layer where Rust, Python and C++ share the same shared-memory ring buffers so messages are not serialised between processes on one computer — which suits a mixed-language robot living on one board, and brings none of the ROS package catalogue with it. The third is a general message library of the ZeroMQ or LCM sort, where you get delivery and then define every message shape, supervision rule and debugging tool yourself. The fourth is a broker such as MQTT, which is right for pushing status to a dashboard or a phone and wrong for anything the robot waits on. The fifth is no middleware at all: one program, one language, threads and a queue, which stays the correct answer far later into a project than people admit.

Which option matches which kind of two-person team?

The option that fits is the one whose assumptions match the robot you are building this year, not the one you might build after raising money.

Two rows at once is a normal end state: a stack on the robot, and a broker carrying status to a human.

What should you pick if you are two software engineers who have never built a robot?

Pick ROS 2, and pick it for the learning rather than for the architecture. Two engineers who have shipped web or backend software already have the habits that make robotics possible — version control, testing, reading other people's code — and are missing the vocabulary: frames, transforms, odometry, control loops, sensor timing. ROS 2 teaches that vocabulary because everything in the catalogue is written in it, and because when you get stuck, the error message has been asked about before. The alternative path, where you assemble a small stack of your own, teaches you your robot beautifully and teaches you nothing transferable. There is a second reason that has little to do with engineering: ROS 2 is what robotics job posts name, so months spent on it stay portable. Both of you will also lean on a coding assistant for the unfamiliar parts, which has a workflow and a set of failure modes of its own. The trap to watch for is adopting ROS 2 and then using none of the catalogue, which is the worst of both.

What if the whole robot runs on one small computer?

Then most of what ROS 2 does for you is machinery you carry and never use. A framework built to spread a graph across machines has to handle discovery, network transports and what happens when a remote peer vanishes mid-run; if every program lives on one board, none of those situations can occur, and you are still configuring for them. That describes more robots than people expect: desk arms, camera-to-motor pipelines, balancing machines, test rigs, most competition robots, a large share of research prototypes. The question that decides it is whether one computer stays true. If a workstation is coming to do perception, or a base station to collect logs, adopting a networked framework now is cheaper than migrating to one later. If nothing is coming, staying on one computer removes an entire category of problems — the ones where the robot works on the bench and comes apart the moment a wireless link is involved. That category eats a startling number of evenings, and two people do not have many to give.

What if you have three months before you have to show something?

Freeze the foundation and spend the three months on the robot. Three months is enough to build something that works and not enough to change what it is built on and still have something at the end, so if anything is running today, that is your answer. If nothing is running yet, choose by the same list as always: if the demo needs mapping and navigation, take ROS 2 and accept every rough edge; if the demo is one arm picking one object, take the smallest thing that moves messages and write the rest yourself. Then stop evaluating. Hours spent comparing options after the decision is made are hours the robot does not get, and no middleware choice has ever been the reason a demo went well. What decides demos is whether the robot stops safely when something unexpected happens, whether you can restart the whole thing in front of an audience without a laptop full of terminals, and whether a person watching can tell what the robot believes. Spend the three months there.

What if only one of you is comfortable on Linux?

Fix that before choosing anything, because the imbalance will decide the project for you. ROS 2 assumes Linux fluency from everyone who touches the robot: package managers, environment files, permissions on serial devices, service supervision, and a build tool with its own opinions. A team where one person can do all of that and the other cannot is a team with one developer and one person waiting to be unblocked, and the waiting person gradually stops contributing. The cheap intervention is a container image or a setup script written on the first day, so a blank machine becomes a working machine without the knowledgeable person in the room. If that script cannot be written, the stack is already larger than the team. The smaller options are gentler here — fewer moving parts to install means fewer ways for a second machine to differ — but no middleware choice rescues a pair where only one of them can operate the computer. Robotics is unusually hostile to that split, because the robot exists in exactly one place.

What does a two-person ROS 2 adoption look like when it goes wrong?

It goes wrong quietly, and the symptom is that the robot stops changing. Month one is installation and tutorials, which feels like progress and partly is. Month two is a build error specific to your combination of distribution, hardware and one third-party package, and it eats most of a fortnight. Month three, one of you upgrades something, the other's machine no longer matches, and there is now a canonical laptop that must be present for any demo. By month five the pair has a private folklore of workarounds, none written down at the moment of discovery, and a robot doing roughly what it did in month two. Nobody made a bad decision; the upkeep simply arrived before the capability did. The tell is the ratio of evenings: count how many of the last ten went to the tool and how many went to the robot. If the tool is winning and you are not drawing on the catalogue, the adoption is not paying for itself. It helps to know how long the learning curve honestly runs before deciding you are behind.

What do you give up by adopting ROS 2 as a team of two?

You give up evenings, and you give up the ability to rebuild your robot from a blank machine without thinking hard. Those are the real costs, and they are charged monthly rather than once. Concretely: a build tool you must learn well enough to debug, a distribution with an end-of-life date that will eventually force an upgrade you did not plan, an environment that drifts between two laptops, and a dependency surface large enough that some breakage will always be somebody else's. You also give up a certain clarity. In a small stack you can hold the whole message path in your head and reason about why a value arrived late; in a large one, the honest answer to many questions is that you would have to go and read the framework. None of this argues against adopting ROS 2 — it argues for adopting ROS 2 on purpose, with the catalogue as the stated reason, rather than by default. Teams who check what happens when a distribution reaches end of life before committing are rarely the ones caught out later.

When is ROS 2 the better choice?

ROS 2 is the better choice for any two-person team whose robot draws its value from parts other people already built. A mobile base with a lidar that must map a building and navigate it: ROS 2, with no argument, because that stack exists today and writing it is a career rather than a project. An arm using an established motion planner. Anything you want to test in a simulator that already speaks the same message types. Anything a third person will eventually touch — a student, a contractor, a co-founder — because the standard stack is the one they will already know. Anything spanning two computers by design, since HORUS is a single-machine middleware and shared memory stops at the edge of the board. And anything whose loops run at a rate where message handling costs are beside the point, which covers a great many working robots. In all of those, the catalogue and the shared vocabulary decide it, and a smaller stack offers nothing that compensates. Choosing small there costs a year and buys a property the robot never needed.

Is two people simply too few to run ROS 2?

No, and here is why: plenty of two-person teams run ROS 2 and ship, and the ones who struggle are usually not struggling with the size of the team. What sinks small teams is adopting an entire framework for the one package they needed, then paying upkeep on everything else forever. Two people are enough when two things hold. First, the catalogue is doing real work — you can name three packages you depend on and would never have written. Second, the setup is reproducible without either of you in the room, because a pair cannot afford a machine only one of them can rebuild. Teams meeting both do fine, and the framework does not care how many of you there are. Teams meeting neither would struggle on any stack, because the real problem is that the environment has become the project. Size is the wrong axis. The right one is whether the thing you adopted gives back more than it takes, and that is countable in evenings.

Will skipping ROS 2 mean rebuilding it yourself within a year?

Partly, but not the way you think. You will not rebuild the catalogue — nobody writes a navigation stack by accident. What you will rebuild, piece by piece and without noticing, is the unglamorous middle: a way to start six programs together and stop them together, a way to see what is flowing while the robot moves, a way to record a run and replay it at your desk, and a rule for what happens when one program dies while the motors are still powered. Teams who skip middleware entirely build all four badly over about a year, as a socket here and a supervisor script there, and finish with a private framework nobody else can debug. The way to avoid that is not to adopt the largest option available; it is to adopt something that already supplies the middle, whether that is a smaller middleware chosen for a two-person team or ROS 2 itself. The failure is not skipping ROS 2. The failure is skipping the decision.

How do you decide this in an afternoon?

Write three lists and let them decide for you. First: everything in the robot you were never going to write yourself, named specifically rather than by category. Second: how many computers run your code once the robot works, this year and next. Third: how many languages the robot will contain. A long first list means adopt ROS 2 whatever the other two say, because the catalogue is the only item on this page that takes years to replace. A short first list plus one computer means start smaller and keep the evenings. A short first list plus several computers means you want a networked message layer without the catalogue, which is a narrower field than either extreme. More than one language on one computer is the case where sharing memory across languages earns its keep. If the lists disagree, weight the first hardest. Then write the setup script before you write any robot code, and if you cannot write that script, you already have your answer about whether the stack fits two people.

A short version, by situation:

• If you are two people building a mobile base with a lidar -> ROS 2, because the mapping and navigation you need already exist and rewriting them is your whole year.
• If you are two people on a desk-sized robot that lives on one computer -> a smaller single-machine stack, because upkeep is your scarcest resource and none of the network machinery applies.
• If your robot mixes a compiled control loop with Python glue -> a middleware where both languages read the same buffers, because the alternative is a bridge you maintain forever.
• If a third person joins within the year -> ROS 2, because the stack they already know is worth more than any property of a smaller one.
• If neither of you can write the setup script today -> whichever option you can install from blank in one evening, because that is the one still running next spring.

When you want to compare options rather than symptoms, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. For two people, setup effort and team size fit outrank the rest, and licence quietly removes several candidates before you begin.

The repository is open source under Apache-2.0 and linked below. Star it so HORUS is in your list when you start building.