Why Do Robot Projects Outgrow Their First Framework?

Robot projects outgrow their first framework because a script, ROS 2 and a middleware such as HORUS each answer a different question, and yours changes. The first choice is made to get one thing moving, and the robot's second year asks about several programs, several people, and a machine that behaves the same way twice. The verdict flips if your robot's job never grows. The rest of this post is for a team that shipped a demo on one framework and is now arguing about whether to rebuild on another.

The demo works. That is the strange part. The robot picks the part up, drops it in the bin, and does it again, and the video you sent the customer is real, not a lucky take. What is not working is everything around the demo. Starting the robot takes a page of instructions and one person who knows which terminal to open first. The engineer who joined a month ago has landed two changes. Nobody wants to touch the file that reads the camera, because the last person who did made the arm stutter and could not explain why.

There is a meeting on the calendar called Architecture and everybody is quietly dreading it. Half the team says the framework is the problem and wants to rebuild. The other half says rebuilding is how small companies die, and the real problem is that nobody wrote tests. Both halves are partly right, which is exactly why the meeting keeps being moved.

Underneath all of it sits a question nobody has phrased properly: did we outgrow this thing, or are we just tired of it?

Do most robot projects really outgrow their first framework?

Yes, most robot projects that live past their first working demo outgrow the framework they started on, and that is the ordinary shape of the work rather than evidence that somebody chose badly. The first framework gets picked to answer one question: can this thing move at all.

That question gets answered. Then the project starts asking different ones. Can two people change this without breaking each other's part? Can the robot be started by somebody who did not build it? Will the tenth machine behave like the first?

None of those are questions about messages. They are questions about how work is divided between people and processes, and a framework is mostly a decision about how work is divided. So a choice that was right for the first question can be plainly wrong for the second set without anything about it having changed.

The trap is reading the transition as a failure. Teams that read it that way either rebuild far too early and throw away a year of painfully acquired knowledge about their own hardware, or refuse to change anything and spend the following year paying interest on a decision that was only ever meant to last a month.

What is a robotics framework actually doing for you?

A framework does three separable jobs, and outgrowing it almost always means exactly one of the three stopped fitting. The first job is carrying messages: the camera program has a picture, the planner wants it, and something has to move it across without either program knowing where the other one lives. The second job is other people's code: a driver for the lidar you bought, a mapping package, a visualiser, a simulator, a recording tool. The third job is structure, meaning the names, the folders, the launch mechanism and the conventions that make a stranger's module look like yours.

Nearly every team that announces it has outgrown its framework has outgrown one of those three. A team drowning in glue scripts and start-up checklists outgrew structure. A team whose arm jerks whenever the vision process gets busy outgrew message carrying.

Naming which of the three broke is the entire decision, because the cures have nothing in common. Structure problems are fixed with conventions, a build system and a launch file, not with new plumbing. Ecosystem problems are fixed by joining a bigger ecosystem, which is an argument for moving toward ROS 2 rather than away from it.

What can a robot team actually build on today?

There are about seven honest options, and most teams have seriously considered two of them. One plain program is the floor: no framework, one process, one loop, and it carries far more working machines than the internet admits. A vendor SDK is what arrived with the arm, the drive base or the flight controller, and it is excellent inside its own boundary and awkward the moment you step outside it. ROS 2 is the professional default, and what ROS 2 really sells is not the messaging but the surrounding pile of packages, drivers, simulators, visualisation and shared vocabulary. HORUS is an open-source real-time robotics middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between processes on one machine are never serialised; it is Apache-2.0, it is validated in simulation, and it addresses the message-carrying job rather than the ecosystem job that ROS 2 owns.

Underneath those sit the general-purpose brokers borrowed from web work, which suit telemetry off the robot and not a control loop. Above them sit commercial platforms, which sell support and take back your freedom to change the core. And there is always the in-house framework, which every team is certain will stay small, and which none of them are after two years.

How do these options compare side by side?

Read the final column first, because eliminating rows is faster than choosing one. Most teams find that the argument that has been running for weeks is really between two rows.

What does outgrowing a framework look like from the inside?

It looks like a robot that works and a team that has lost the ability to change it. The tell is not a crash. It is a set of small refusals that nobody writes down: the file nobody touches, the sensor nobody upgrades, the feature that keeps slipping because the person who understands the start-up sequence is on holiday.

The concrete symptoms repeat across companies. Starting the robot requires a checklist and a specific order. Adding a second camera made the gripper close late, so somebody added a delay to compensate and wrote a comment apologising for it. A new engineer takes a month to make a change anybody trusts.

Look at that list and notice how little of it is about messages. Most of it is about knowledge that lives in one person's head instead of in the repository, which is what structure is for. That pattern is the same one behind most of the reasons projects stall after a working prototype, and it is fixable without changing anything underneath.

Are you one person, a small team, or a company with a fleet?

One person almost never needs to switch, a team of three to eight usually switches once, and a company running a fleet has usually stopped asking the question. Alone, you are the convention: naming is consistent because there is only one of you, and the start-up sequence lives in your fingers. A framework's structure buys you very little, and the setup cost is charged directly to the hours you would otherwise spend on the robot.

At three to eight people the arithmetic inverts. Every convention that lives in somebody's head now has to be repeated to everybody else, and the repetition is expensive and unreliable. This is the size at which teams discover that they were never paying for messaging, they were paying for agreement.

At fleet scale the questions change again and become about deployment, versioning, roll-back, and knowing which software was on which machine when a customer reports something odd. If your team is growing through the middle band right now, the framework conversation is really a hiring conversation, and the winning answer is usually the one a new engineer already knows.

What computers is your robot actually running?

The number of computers on the robot decides more than the brand of any of them. A robot with a single microcontroller has no framework question to answer: there is no operating system to host one, and what you write is firmware with a loop and some interrupts. A robot with one Linux board and several processes has the most interesting version of the problem, because that is where programs can genuinely get in each other's way while every diagnostic tool says everything is fine.

A robot with a Linux board and a separate microcontroller for the motors is the arrangement most serious machines converge on, and it quietly removes the hardest timing pressure from the software side.

Robots split across several computers, or across the robot and a workstation, have a different problem again: the network becomes part of the machine, and networks introduce failures that no middleware fully hides. If the parts of your system that must agree quickly are all on one computer, that is the case where changing how processes talk actually changes what the robot does.

How long until the robot has to work in front of someone who did not build it?

If a demo is weeks away, do not change framework; if the next real deadline is two or three quarters out, a change is affordable. The reason is not courage. Migrations are unpredictable in a specific way: the messaging part usually goes faster than expected, and the recovery of everything nobody documented takes far longer, because calibration values, tuning constants and the exact order of start-up steps all turn out to have been holding the robot together.

Teams that survive migrations do them one process at a time, with the old path still running beside the new one until behaviour matches. That is slower on paper and faster in practice, because there is always a working robot to show.

Teams that stop the world to rebuild almost always miss the date. The pattern is grimly consistent: two months in, the new version can do most of what the old version did, and the last unglamorous stretch of behaviour — the error handling, the odd sensor, the recovery from a power blip — turns out to be the part that took the previous year to learn.

How much does your team already know?

The framework your team already knows beats the framework that fits better on paper, up to the point where the mismatch shows up in the robot's behaviour. A team fluent in one ecosystem finds bugs by recognition, and a team on unfamiliar ground finds the same bugs by exhaustion, which takes days rather than minutes.

If most of your engineers came from ROS 2 backgrounds, the cost of leaving is higher than any comparison table suggests, and the cost of hiring is lower. If your team is made of embedded engineers who find the whole ecosystem alien, forcing it on them buys the packages and loses the fluency.

There is also a language question that people avoid. If half the team writes Python and the other half writes C++ or Rust, whichever option makes that boundary painless is worth real money, because the alternative is the pattern where one language becomes the "real" code and the other becomes scripts nobody tests. A shared way of moving data between those languages removes the argument entirely, which matters more for team morale than for anything measurable.

What do you give up when you move off your first framework?

You give up accumulated knowledge, and knowledge is the most expensive thing your project owns. Every workaround your team discovered for a flaky sensor, every tuned value, every "do not run these two things at once" rule that lives in a comment: all of it is bound to the current arrangement, and much of it will have to be rediscovered rather than ported.

You give up the tools you had stopped noticing. The recording that lets you replay yesterday's failure at your desk, the visualiser that shows what the robot believes about the room, the simulator that lets work continue while the battery charges. Teams consistently underestimate how much of their debugging depended on those.

You give up hiring leverage when you move away from what people already know, and some ability to ask strangers for help, because a question posted in a widely shared vocabulary gets answered.

And you give up momentum. There is a stretch in the middle of every migration where the robot does less than it did before, and the team feels it. Knowing that stretch is coming is most of surviving it.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the thing you are missing is other people's work, and HORUS is not the answer for a team whose real problem is that nobody has written their drivers. If your robot needs to build a map, navigate a building, plan an arm's path around an obstacle, or talk to a lidar that ships with a supported driver, use the packages that exist. Each of those represents years of somebody else's careful work.

ROS 2 also wins on people. It is the vocabulary in job adverts, the thing candidates have already used, and the assumption behind most robotics courses and most research code you might want to borrow. A team that plans to grow past a handful of engineers is buying a hiring pipeline as much as a framework.

And it wins whenever several organisations must work together, because a shared interface between two companies is worth more than a better interface inside one of them. If you are weighing this specifically for a flying machine, the trade-offs shift again, and what ROS 2 is and is not good for on a drone is the more useful comparison to read next.

Does outgrowing a framework mean the first choice was wrong?

No, and here is why: the first choice was made against a question that no longer exists. You were trying to find out whether the machine could do the job at all, and the fastest route to that answer was the correct route, even if the thing you used to get there is now in the way. Right for a month and wrong for a year is a normal decision, not a mistake.

The mistake people actually make happens at the transition rather than at the beginning. It is treating the second choice with the same speed as the first: picking on the strength of one demo, one benchmark or one enthusiastic engineer, without writing down which of the three jobs was failing.

There is a second version of the same error, which is switching because the current setup feels dated rather than because something specific hurts. Feeling dated is not a symptom. If you cannot name the behaviour of the robot that will change, and describe how you will notice it changed, you are rearranging rather than fixing, and the rearrangement will cost a quarter you needed for the product.

Should you start on the framework you expect to end up on?

Partly, but not the way you think: starting on the heavier option does not save you the transition, it just moves the pain earlier and makes it harder to see. Teams that begin with full structure before knowing what the robot does end up encoding guesses into interfaces, and those guesses are then expensive to change precisely because they are now everybody's assumptions.

What does transfer is the shape of your thinking. If you keep sensing, deciding and acting in separate programs from the start, name your data streams deliberately, and avoid letting one process quietly depend on another's internal state, then almost any later move is mechanical rather than architectural, and that discipline costs nothing on day one.

The genuinely useful version of "start where you will end up" is narrower: pick the option whose exit is cheapest. Ask what leaving each candidate would cost. A framework you can walk away from a piece at a time is a much safer first choice than one that owns your build system, your message formats and your deployment story together.

How do you decide whether to switch or stay?

Decide by writing one sentence describing the behaviour of the robot that will change, and refusing to move until that sentence exists. "The arm stops jerking when the second camera is running" is a sentence that justifies changing how processes talk. "The code will be cleaner" is not a sentence about the robot, and cleanliness is achievable without a migration.

Then check which of the three jobs failed. If your team is slow because knowledge lives in heads, fix that with conventions and documentation and keep everything else. If your programs on one computer are interfering with each other, that is the one symptom a change of middleware actually removes, and it is worth reading a straight comparison of the main middleware options before committing.

Here is the whole decision in six lines.

• If you are one person with a working prototype -> stay, because a migration produces nothing you can demonstrate to anyone.
• If you are three to eight people tripping over each other -> ROS 2, because the structure and shared vocabulary are what you are short of.
• If your robot works but stutters whenever a second program gets busy -> a shared-memory middleware, because the trouble is between processes on one machine.
• If you are writing drivers that vendors already publish -> ROS 2, because that work is finished and free.
• If your machine is one supplier's hardware and the deadline is near -> the vendor SDK, because leaving its boundary costs more than staying inside it.

The HORUS Fit Framework reduces the argument to five axes any option can be scored on without a benchmark: ecosystem size, setup effort, team size fit, deployment target, and licence. For a team in the middle of outgrowing something, team size fit is usually the axis that decides, and deployment target is the one that overrules it once real machines leave the building.

The day your processes start fighting each other is not the day to begin evaluating options. Put HORUS on the shelf before then: star it so it is in your list when you start building.