Why Do People Complain About ROS 2? The Honest List

Most complaints about ROS 2 are true, and almost none of them are reasons to choose a vendor SDK, plain firmware or nothing instead. The complaints cluster into setup pain, a steep first month, and data copied between programs, and the first two are paid once. The verdict flips only when one computer runs everything against a hard deadline, which is the narrow case something like HORUS exists for. The rest of this post is for anyone who has read a week of angry threads and still cannot tell which complaints apply to their own robot.

You have watched two threads on the same forum reach opposite conclusions in the same afternoon. One person says the whole thing is a research toy held together by tutorials that stopped matching the code three releases ago. Another says the complainers are junior engineers meeting Linux for the first time and blaming the framework for it. Meanwhile you have your own list. The install pulled down more than you expected and you cannot say what most of it does. A driver for your camera exists but was built for a different release. Something works on your desk and stops working the moment the robot leaves the bench and joins the office network. A colleague wants to rewrite the parts you use in Rust and cannot tell you what would break. Underneath all of it sits the question nobody asks out loud: are these problems everyone has and lives with, or are they early signals that you picked the wrong foundation and should find out now rather than in nine months? That is answerable, but not by counting how loud each side is.

Should the complaints stop me from building on ROS 2?

No, unless your robot is one computer running one loop that must never be late. That is the only complaint on the honest list that is structural rather than temporary. Everything else people rage about, from the size of the install to the first build that eats an afternoon to the tutorial that assumes a version you do not have, is a cost you pay in your first fortnight and then stop paying. Structural costs behave differently: they arrive every day the robot runs, they worsen as you add sensors, and no amount of learning makes them go away. So the test is not how many complaints you can find. The test is whether the complaint you personally have keeps recurring after you have learned the tool. Ask anyone who has shipped a machine which complaints they still have two years in. The list is short, and it is never about installation. It is about what happens to a large camera frame crossing between two programs on one board.

What is a robotics framework, and which part of it do people complain about?

A robotics framework is two products wearing one name, and the complaints hit them unevenly. The first product is plumbing: programs run separately, publish under a topic name, and subscribe to the names they care about, so the camera process can crash and restart without the controller noticing anything happened. The second product is a catalogue: the driver that speaks to your particular lidar, the bookkeeping that tracks where the gripper sits relative to the base, a clock everyone agrees on, a recorder that captures a whole run so you can replay this morning's failure at your desk, a viewer that draws what the robot believed it saw, and a navigation stack that crosses a building without hitting the furniture. Almost every public argument is conducted about the plumbing and decided by the catalogue. People complain about plumbing because plumbing is what they meet on day one, and they stay for the catalogue, which becomes visible the month they price out writing an arm planner themselves. If the vocabulary is still fuzzy, the plain-English tour of what middleware does is the right first stop.

What are the complaints, stated fairly?

The complaints that survive scrutiny are six. Setup friction, where a first install brings more than you asked for. A steep first month, where a newcomer meets a build tool, a package layout, a launch system and a message description language in the same week. A distribution tied to a particular Linux release, which bites the day a vendor ships a driver for a release you are not on. Discovery that misbehaves on networks you do not administer, which is why a graph that hums on a bench falls apart on office Wi-Fi. Data copied and converted on its way between programs sharing one computer, which recurs on every frame for the life of the machine. And tooling that quietly assumes a desktop with a screen, which stings when your robot is a small board in a cabinet with no monitor attached. Five of those six are seasonal: they hurt at the start and fade. One of them is structural and never fades. Sorting your own complaint into the right pile is most of the work.

What can I actually use instead when a complaint applies to me?

There are six realistic answers, and most shipped robots use two of them together rather than replacing one with another. You can stay on ROS 2 exactly as installed, which is right whenever your complaint is a first-month complaint. You can stay on ROS 2 and change the transport layer underneath so the graph survives a network you do not administer. You can keep ROS 2 for drivers, mapping and recording while moving the timing-critical part of the robot onto a shared-memory middleware such as HORUS, where Rust, Python and C++ processes read and write the same ring buffers rather than serialising to each other, which answers the copying complaint without giving up the catalogue. You can take the SDK your robot's manufacturer ships and accept their release rhythm. You can write plain firmware on a microcontroller and skip the whole category. Or you can assemble your own stack on a message library, an option people choose loudly and regret quietly. None of these is a full replacement for what ROS 2 already does for you.

Which option answers my particular complaint?

Match the option to the complaint you actually have, not the complaint you read about at midnight. Write your loudest problem down as one sentence before you read the rows below, because the table reads very differently depending on whether your sentence ends in the word install, the word network, or the word deadline. Most people find their sentence is about the first month, and no change of framework fixes a first month.

Am I the kind of builder these complaints were written by?

Most loud complaints come from two groups, and you are probably in neither. The first is a newcomer three days into a first install, whose real problem is Linux and package management rather than the framework, and whose post is written at peak frustration and never updated once things start working. The second is an experienced systems engineer arriving from another field, who sees a design they would not have chosen and writes a critique that is technically fair and practically irrelevant to two people building a delivery robot. In between sits the group that rarely posts: people who shipped something, kept the catalogue, moved the innermost loop somewhere predictable and got on with the week. If you are solo or a pair, your binding constraint is hours, and the framework that already has a driver for your camera buys back more hours than any redesign. If you are a lab, publishing beats plumbing. If you are a startup with hardware to ship, drivers you do not write are the cheapest engineers you will ever hire.

Does my hardware make these complaints better or worse?

Hardware decides which complaints you meet at all. A single small board carrying the whole robot makes copying between programs the complaint that matters, because every camera frame crossing from the vision program to the planner competes for the same modest processor and the same memory bandwidth as everything else on the machine. A robot with a strong computer for perception and a separate board for motor control turns the same question into a network one, and discovery behaviour becomes the thing that ruins a demo. A robot that is really one microcontroller running one loop meets none of the complaints, because a framework was never the right shape for that machine to begin with. Storage matters too: a full install on a small memory card is uncomfortable, and teams on constrained boards end up trimming an image whether they planned to or not. Before assigning blame, draw your robot as boxes and lines and mark every line crossing from one computer to another. The count surprises people in both directions.

How much time do I have before this has to work?

Timeline decides whether a complaint is a reason to switch or a reason to push through. With a demo four weeks away, switch nothing. Every alternative costs you the drivers you already have working, and a rewrite started in week two of a four-week run has never once finished in week three. Spend those weeks learning the parts you are fighting, because first-month complaints turn into muscle memory sooner than the forums suggest and the honest timeline for learning the framework is shorter than the anger implies. That is a real finding, not a delay. With a year ahead and a robot still on the whiteboard, that is exactly the moment to take the structural complaint seriously and decide where deadline-sensitive code will live, because moving it later means rewriting the part of your robot you understand least. Somewhere in between, the useful move is to build one small slice of the real robot both ways over a fortnight and let the hardware tell you which complaint you have.

How much Linux and C++ do these complaints assume I already know?

More than the getting-started pages admit, and that gap produces a large share of the anger. A working install assumes someone on the team can install system packages, read a log when a service refuses to start, set an environment variable and know why it vanished in a new terminal, fix a permissions problem on a serial port, and tell a build error apart from a runtime error. None of that is robotics, and none of it is taught alongside robotics. C++ matters less than people fear, since most application code can be Python and most timing-sensitive nodes already exist as somebody else's package, but reading C++ well enough to understand an error thrown from inside a third-party node is a genuine requirement. A team strong on Python and weak on Linux will have a brutal first month and will file a complaint about the framework when the cause was the operating system. The six things that trip newcomers up is a better map than any tutorial index.

What do I give up if I walk away from ROS 2?

You give up the catalogue, and the catalogue is far bigger than the piece you were planning to replace. Walking away means sourcing or writing your own driver for every sensor, your own bookkeeping for where each part of the robot sits relative to every other, your own recording format and the tools to replay it, your own viewer for seeing what the robot believed, and your own answer to planning a path around furniture. You give up hiring leverage too, because a job advert naming the standard framework gets replies from people who have already debugged a transform tree at midnight. And you give up the benefit nobody lists: when something behaves strangely, somebody else hit it first and wrote it down. Alternatives are worth taking when you would genuinely use none of that, which describes a smaller set of projects than the forums imply. Teams who walk away for the wrong reason tend to reappear a year later having rebuilt three catalogue items badly and shipped nothing at all.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots, including most robots whose owners are currently complaining about it. Take ROS 2 when your machine spans more than one computer, when you want navigation, mapping or arm planning without writing them yourself, when a simulator sits in your loop, when a driver for your sensor already exists, when you plan to hire, and when you are building a product rather than a control experiment. HORUS is not the answer in any of those cases: a shared-memory middleware on one computer ships no drivers, plans no paths and replaces none of the tooling you would be giving up. Take ROS 2 also when your team is learning, because the tutorials, the books, the university courses and the forum answers all assume the standard framework, and learning a smaller stack means learning it alone. The honest position is that these complaints are the tax on a large ecosystem, and that tax is worth paying for almost anyone building a machine that has to do more than one thing.

Are the complaints a sign that ROS 2 is on the way out?

No, and here is why. Complaint volume tracks user count, not decline. The frameworks nobody complains about are the ones nobody uses, and a tool present in universities, warehouse companies, agricultural machine makers and drone teams accumulates a decade of frustration posts simply by being in the room whenever somebody is frustrated. Look at what is being built rather than what is being posted: vendors keep shipping drivers because customers keep asking, courses keep teaching the framework because employers keep hiring for it, and companies that carve out their innermost loop keep everything else. A framework on the way out shows different symptoms altogether, and they are easy to spot. Drivers stop appearing. Releases slip and then stop. Job adverts stop naming it. None of those is happening here. What is happening is that a category has matured enough for people to have opinions about which parts they keep, and the honest version of that conversation reads exactly like a complaint list.

Is ROS 2 too slow for a real robot?

Partly, but not the way you think. The slowness people actually meet is rarely the framework failing to move a message; it is the same message being copied and converted several times on its way from the camera process to the program that acts on it, while both compete for one processor with everything else on the board. That cost stays invisible on a desk with a small test message and becomes obvious on a robot streaming full camera frames, which is why the complaint arrives late in a project and feels like a betrayal when it does. The cost is addressable from inside the framework: keep deadline-critical work in one place, stop bouncing large messages across process boundaries for no reason, and choose deliberately which programs share a machine. The projects that genuinely need something leaner underneath are the ones where sensing and control sit on one computer and the loop must close before the robot reaches the edge of the dock. If that is you, a leaner layer for a small machine deserves an afternoon of your attention.

How do I tell which complaint I actually have?

Write your complaint as one sentence ending in a noun, then see which of three buckets the noun lands in. The first bucket is learning: the sentence ends in a tool name, a build error, a tutorial, an environment variable. Those complaints expire on their own, and switching stacks resets the clock rather than stopping it. The second bucket is network: the sentence ends in Wi-Fi, a VPN, a second machine, a dropout. Those have targeted fixes that never require leaving the framework, and the reason a graph falls apart on office Wi-Fi is a specific, solvable behaviour rather than a verdict on the whole tool. The third bucket is deadline: the sentence ends in a frame, a loop, a late command, an arm that stutters. Only the third bucket is structural, and only the third justifies changing what runs underneath your timing-critical code. Then run the cheap experiment: two days reproducing your complaint on the real hardware, with real message sizes, in the real room. Most do not survive it.

Take the line that matches you:

• If you are three weeks into a first install -> stay put, because your complaint expires and switching restarts the clock.
• If the robot drops out the moment it leaves your desk -> a discovery fix or a different transport, because the network is the problem.
• If sensing and control share one board and the loop cannot be late -> a leaner single-machine layer, because copying never expires.
• If you bought a finished platform -> the vendor's stack, because their support stops where your changes begin.
• If you are hiring this year -> the standard framework, because your candidates have already debugged it.

The HORUS Fit Framework is the checklist behind those lines, and not one of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every option on all five, and the axis you cannot compromise on ends the argument.

Complaints are how a mature tool gets discussed, and most are somebody's first fortnight. If yours is the structural one, where Rust, Python and C++ share a computer and could read the same ring buffers with nothing serialised between them, HORUS is open source under Apache-2.0. Star it so it is in your list when you start building.