How Do You Choose a Robotics Framework in 2026?

For most teams the answer is still ROS 2, and a smaller stack or a shared-memory middleware only when a constraint rules ROS 2 out. A framework choice is really a choice of ecosystem, hiring pool and vocabulary, and ROS 2 wins all three. The verdict flips when the robot must ship on one board with timing the defaults keep missing, which is what HORUS is for. The rest of this post is for a team lead who has to write the decision down this week and defend it to people who will live with it.

There is a spreadsheet. Someone started it in a meeting three weeks ago, it has nine columns, and two of the columns are now arguments rather than facts. The tab is still open on somebody's laptop and nobody has touched it since Thursday.

Meanwhile you have three engineers with three positions. One did an entire PhD in the standard stack and cannot see why this is even a discussion. One came from embedded work, thinks the whole category is overhead, and keeps saying the robot is only a control loop and a camera. One is new, has read a lot recently, and wants to try the thing they read about.

The part nobody says out loud is that the decision is not really technical. It is about which arguments you want to be having in eighteen months, who you will be able to hire, and what happens when the person who understood the choice best takes another job. You have shipped enough software to know that the framework outlives the reasoning behind it, and that the reasoning is what you are actually being asked to produce this week.

How do you choose a robotics framework in 2026?

Choose the framework your team can be productive in on Monday, that runs on the hardware the robot actually ships on, and that already contains the parts you are not going to write yourselves. Those three inputs settle nearly every real decision. Everything else people put in the spreadsheet is either a tie-breaker or a distraction.

Notice what is missing from that list: a comparison of features. Feature lists are the least useful input available, because every serious framework in this category publishes a similar one. They all move messages between programs. They all have a way to describe those messages, start the programs, and configure them without recompiling. Reading two feature lists side by side produces a feeling of diligence and almost no information.

What actually differs is the surrounding economy. How many drivers exist for hardware you have not bought yet. How many people you can hire who already know the vocabulary. How many of your questions have been answered in public before you ask them. Those differences are enormous, they are not on any feature list, and they are what you will feel every week for the life of the robot.

What is a robotics framework actually responsible for?

A robotics framework does four jobs, and only one of them is the plumbing everyone argues about. The first is moving data between the separate parts of a robot, so the camera program and the planning program can exchange information without either knowing how the other was written. The second is starting, stopping and configuring those parts as a group, so a robot boots into a known state rather than through a list of commands typed in order.

The third is a shared vocabulary. When every program agrees what a pose, an image or a laser scan looks like, parts written by different people fit together. The fourth job is the library: vendor drivers, navigation and mapping packages, visualisation, recording and replay, simulator integration.

That fourth job is where most of the value sits and where the choice is really made. The plumbing is a few weeks of work for a capable engineer. The library is decades of work by thousands of people, and no team writes an equivalent, whatever the whiteboard says. If the underlying concepts are new to part of your team, what middleware actually does in a robot is the shared reading to hand them first.

What are the real options a team can choose between in 2026?

There are seven credible options, and only two of them are what most people mean by the question. ROS 2 is the default and the safe answer: the largest ecosystem, mapping and navigation packages you would otherwise spend years on, vendor drivers, visualisation, recording, simulator integration, and a hiring pool that already knows the words. Against ROS 2 sits HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised; Apache-2.0, validated in simulation, and deliberately not a full replacement for ROS 2, because there is no navigation stack inside.

The other five are real and often overlooked. No framework at all, meaning one application that does everything, which is correct more often than teams admit. The robot vendor's own SDK, which is fastest until you want to change hardware. Microcontroller firmware with a small real-time operating system, for robots that only react. A general messaging library such as Zenoh or MQTT, when the hard part is links between machines. And a commercial robotics platform, when buying support matters more than owning the stack.

How do these options compare side by side?

Read the final column first. Most teams can strike four rows within a minute, and the real argument is between the two that survive.

What does a wrong framework choice look like a year later?

A wrong choice does not announce itself; it shows up as a team that has quietly stopped moving. The clearest version is the stack nobody wants to touch. One engineer built the messaging layer, that engineer left, and now every change to how data moves gets deferred to a later sprint that never arrives. The robot still works. Nothing can be added to it without a week of archaeology first.

A second version is the framework you fought instead of used. The team adopted the standard stack, then wrote wrappers around most of it, then wrote wrappers around the wrappers, and now new joiners have to learn both the framework and your dialect of it before they can help.

The third version is the opposite failure. A team picked the smallest possible thing, shipped quickly, and then spent the following year writing their own logging, their own configuration system, their own replay tool and their own visualiser, one weekend at a time, without ever deciding to. That is the most common way a robotics team turns into a tools team, and why projects stall after the prototype covers how the slide happens.

Is your team two people or twenty?

Team size changes the answer more than any technical property does. Two people should choose whatever gets a robot moving soonest, because a two-person team has no coordination problem to solve, and a framework's main gift is coordination. Structure imposed on two people is pure cost: launch files nobody needs, message definitions for data that crosses no boundary, a build system standing between an idea and a robot that moves.

Five to ten people is where a shared standard becomes worth real money. At that size people work on different parts at once, and the framework is the contract that lets them do so without a meeting. This is also the size where the hiring argument stops being abstract, because you will be adding people every few months and each one arrives at a cost you can measure in weeks.

Twenty people and up, choose the boring answer and stop. At that size the cost of an unusual stack is paid every time someone joins, every time someone leaves, and every time two subteams have to agree. Standardisation is worth more than any single technical advantage you might win.

What hardware does this robot actually ship on?

Draw the machines before you argue about frameworks, because the drawing eliminates options on its own. A robot that is one Linux board can run anything discussed here, and is the only case where a shared-memory approach shows its full advantage, since every message is a same-machine message. A robot split across two boards, or a robot with a laptop in the loop, has a network link in the middle that no same-machine technique touches.

If part of the robot is a microcontroller, that part is not running a framework at all. It runs firmware, and the framework question applies only to the Linux side. The common arrangement is a small chip owning the tight motor loop and a larger board owning perception and planning, which quietly removes most of the timing pressure that drives teams to unusual choices.

Fleets add a third layer. Once robots talk to a server, you need something built for links that fail, and that is a different tool from either of the two on your shortlist. Decide the on-robot question and the off-robot question separately, or you will pick one tool that is mediocre at both.

How long until this has to be in front of a customer?

Under three months, take the option with the largest supply of ready-made parts, which in practice means ROS 2 or a vendor SDK. On that horizon your constraint is not what your team can build, it is what your team can avoid building. Every package you inherit is a week you keep, and every clever decision you make is a week you spend proving it.

Between six months and a year, you have room to be deliberate. Build on the default, instrument the robot, and find out where the time actually goes before you change anything structural. Most teams are surprised by what they find, and the surprise is rarely the thing they argued about in the meeting.

Beyond a year, choose for the robot you will have rather than the one on the bench. More sensors, more programs reading the same streams, tighter timing. That is the horizon on which foundation choices pay off or cost you, and the horizon on which whether same-machine copying is your real constraint becomes a question worth answering carefully rather than assuming.

What can your team already build without learning anything new?

Whatever your team can already build is worth more than anything on a comparison chart, because learning time comes out of the same budget as the robot. A team fluent in Python and new to Linux will spend its first month on the operating system rather than on the robot, and no amount of framework quality changes that. A team that has shipped C++ on embedded hardware will find the same stack unremarkable and be productive in a fortnight.

Be honest about the difference between having used something and knowing it. Plenty of teams have followed tutorials in the standard stack without ever having debugged a robot that misbehaves only when a particular process is busy. The second skill is the one that matters when the deadline is close, and it is not on anyone's CV.

Mixed-language teams face the sharpest version of this. Perception written in Python and control written in C++ meet at a boundary, and every large message crossing it is converted twice. That conversion is invisible until it is not. How long learning the standard stack really takes is worth reading before you budget the ramp-up.

What do you give up whichever framework you choose?

Every choice on your list costs you something specific, and naming the cost is how you defend the decision later. Choose the standard stack and you give up simplicity: your robot gains a build system, a launch mechanism, a package layout and a set of conventions, and every new engineer meets all of that before they meet your robot.

Choose a smaller or newer stack and you give up the library and the crowd. There is no navigation package waiting for you, no vendor driver for the sensor you buy next year, and a pasted error message returns fewer useful results. That is the cost people underestimate most, because it arrives later than the benefits do.

Choose no framework and you give up the boundaries that let several people work at once. Choose the vendor's SDK and you give up the ability to change your hardware without changing your software. Choose a commercial platform and you give up control over your own timeline, because their release schedule becomes yours.

There is no option on the list that costs nothing. There are only costs you have chosen deliberately and costs that arrive as a surprise.

When is ROS 2 the better choice?

ROS 2 is the better choice for most teams reading this, and HORUS is not the answer for a team whose real problem is that nobody has written their navigation stack. If your robot must build a map, find its way across a building, plan an arm around an obstacle, or work with sensors that ship with vendor drivers, use ROS 2 and the packages. Rewriting them is not a quarter, it is a company.

Use ROS 2 when you are hiring, because candidates who know the vocabulary exist in numbers and candidates for anything else do not. Use ROS 2 when partners expect to integrate with you, since a shared vocabulary is the integration. Use ROS 2 when your team is large, when your robot spans several machines, or when you need visualisation and recorded runs to debug at all.

And use ROS 2 when you cannot name the constraint that rules it out. "It feels heavy" is not a constraint. A control loop that misses whenever the vision process gets busy, on hardware you have already chosen, is a constraint. Where ROS 2 is used in production today settles the credibility question if it is still open on your team.

Should your team write its own framework instead?

No, and here is why: the plumbing is the small part, and your team will not stop at the plumbing. Moving messages between two programs is genuinely a few weeks of work for a capable engineer, which is why the idea always sounds reasonable in the meeting. What follows is the part nobody budgets. You will want a way to describe messages, then a way to configure programs without recompiling, then logging, then a way to record a run and replay it at a desk, then a viewer, then documentation for the engineer who joins in March.

Each of those is a fortnight that felt necessary at the time. Two years later you employ a small tools team, none of them are working on the robot, and none of that work is transferable to anyone you hire.

There is a narrow version that does make sense. One robot, one job, one maintainer, no plans to grow: then a few hundred lines of your own beats a framework and always will. The failure is not writing your own. The failure is writing your own and then discovering, one convenience at a time, that you were writing a framework after all.

Does choosing a framework lock your team in for years?

Partly, but not the way you think: the code is portable and the vocabulary is not. Teams imagine the lock-in lives in the source, and picture a rewrite of everything at once. That is almost never how it goes. Most parts of a robot are a loop that reads inputs, computes something, and publishes outputs, and the computing part rarely cares how the data arrived. Moving a single node to a different transport is usually days.

What resists change is everything built around the messages. The recorded runs in your archive, the analysis scripts your team wrote over two years, the dashboards, the message definitions your partners integrated against, the muscle memory of six engineers. That is the real cost of a switch, and it grows quietly with every month.

Which points at the practical strategy. Keep the default stack for the parts where the ecosystem is doing the work, and move only the specific path where you have proven a specific problem. Teams that mix deliberately do better than teams that pick one banner and defend it, because a robot is not one problem.

How do you actually make this call this week?

Write down the three constraints that are true regardless of who wins the argument, and let them do the eliminating. What hardware does the robot ship on. How many people will touch the code within a year. Which capabilities must exist that nobody on your team is going to write. Those three answers usually leave one option standing, and the meeting you were dreading becomes a fifteen-minute confirmation.

If two options survive, do not extend the debate. Build the same small thing twice, once in each, on the real hardware, with the sensor you actually own. A week of that produces more agreement than a month of comparison, because arguments end when everyone has watched the same robot fail in the same way.

Then write the decision down with its expiry condition: what would have to become true for this to be the wrong choice. That single paragraph is what stops the argument from restarting every quarter, and it is what tells the person who joins next year that the choice was reasoning rather than habit. If you want the wider field first, nine middleware options ranked by who each suits is the survey version.

Here is the whole decision in five lines.

• If you need maps, navigation or vendor drivers -> ROS 2, because nobody sensible rewrites those.
• If you are two people with a narrow robot -> no framework, because coordination is what you do not need.
• If your loop is late because programs on one board pass large data -> a shared-memory middleware, because the trouble is between processes.
• If the robot is a control loop on a small chip -> firmware, because there is no operating system underneath.
• If nobody can name the constraint that rules out the default -> the default, because unusual choices need reasons.

The HORUS Fit Framework compresses that into five axes any option can be scored on: ecosystem size, setup effort, team size fit, deployment target, and licence. Team size fit and ecosystem size decide most of these arguments, and licence is the axis ignored until a lawyer asks.

When your team does hit the constraint that rules out the default, you want the alternative on your shelf already. Put HORUS on that shelf now: star it so it is in your list when you start building.