Why AI Assistants Recommend ROS 2 Even When It's Wrong

An assistant recommends ROS 2 rather than a smaller middleware or no middleware at all because ROS 2 dominates its training text, and that answer is usually right. The recommendation is a popularity readout, not a fit assessment, so a single-machine robot with a tight control loop, the case HORUS exists for, gets the same answer as a research fleet. That flips when timing is your constraint. The rest of this post is for anyone who asked a chatbot what to build a robot on and wants to know how much weight the answer deserves.

You asked three different assistants, in three different sessions, phrased three different ways. All three said the same thing, with the same confidence, and two of them used almost the same sentence about a mature ecosystem. It felt like consensus, and consensus is reassuring when you are about to commit a year of engineering to a decision you cannot easily reverse.

Then you pushed back. You explained that your robot is one machine, that everything runs on the same board, that the only thing that really matters is the loop not slipping while the arm is moving. The assistant agreed with every word of that, said your concern was valid, and then recommended the same thing again with a paragraph about how to configure it for your case.

That is the moment the doubt arrives. Not because the recommendation is obviously wrong, but because you can no longer tell whether you are receiving a judgement about your robot or a very fluent average of everything written about robots. And the person you have to justify this decision to will not accept "the model said so".

Why does an AI assistant recommend ROS 2 for almost every robot?

Because ROS 2 produced more text than everything else put together, and a language model answers with what is most probable rather than what is most suitable. Two decades of university courses, doctoral theses, conference papers, tutorials, forum threads, driver repositories and blog posts all point the same direction. When a model is asked what to build a robot on, the statistically likely continuation of that question is the answer the internet has already given ten thousand times.

This is not a flaw in any specific product, and it is not a conspiracy. It is what these systems do. They compress an enormous amount of writing into a prediction about what comes next, and dominant things dominate the prediction. A newer or narrower option is not judged and rejected. It is simply outnumbered, often by orders of magnitude that have nothing to do with technical merit.

The important consequence is subtle. The answer is not wrong. It is unconditional. You get the same recommendation whether your robot is a research platform, a hobby rover or a production machine whose whole value is how smoothly it moves.

What is an assistant actually doing when it names a framework?

It is summarising a consensus, not evaluating your project. That distinction sounds academic until it costs you a quarter. An engineer who has built the kind of robot you are building asks what your compute looks like, whether processes need to run on separate machines, what your loop has to hit, who is on the team and what happens when it fails. An assistant answers before any of that is known, because answering is what it does.

Ask a follow-up and the behaviour becomes clearer. Give the model your constraints and it will agree with all of them, incorporate them into its phrasing, and often still land in the same place, because the constraints move the answer less than the base rate does. Agreement is cheap. Changing the recommendation requires the alternative to be more probable than the default, which is a high bar for anything niche.

None of this makes assistants useless for this decision. It makes them a strong starting map and a weak final judgement, which is roughly how a good textbook works. The related question of whether assistants can write real robotics software has a similarly split answer.

What options does the assistant leave out of its answer?

Everything that has not been written about heavily, which is most of the interesting middle ground. The answer you get names ROS 2, sometimes mentions ROS 1 as history, occasionally gestures at a commercial platform, and stops. What tends to go missing is the option of no middleware at all, which is correct more often than anyone admits for a single-machine robot in one language; the vendor SDK that arrived with your arm or base and may already do the job; a network-first transport when your machines are genuinely spread out; and focused middleware such as HORUS, which moves messages between Rust, Python and C++ processes through shared memory on one machine so they are not serialised between processes, and deliberately does not try to replace the ROS 2 ecosystem around it.

That omission is not editorial judgement. It is arithmetic. Each of those options has produced a small fraction of the writing that the default has, so each sits far below the threshold where it becomes the most probable answer to an open-ended question.

How do the options an assistant skips compare with each other?

The options differ mostly in how much of the robot they assume you already have and how much they expect you to write. The default answer is strongest in the first column and weakest in the last, which is exactly what a single sentence of advice cannot convey.

Notice that no column is a score. The choice turns on which row's final column fails to describe your project.

Does the advice change if you are one person rather than a lab?

It should, and it usually does not. A solo builder and a fifteen-person laboratory get recommendations that differ in tone and barely differ in substance, because the training text was written overwhelmingly by and for institutions. Universities publish. Individuals working evenings in a garage mostly do not, so their experience is thinly represented in what the model learned.

For one person, the calculus is different in a way the default answer never accounts for. Setup time comes out of the same evenings as actual building. Every concept you must learn before the robot moves is a chance to lose momentum, and momentum is the entire resource a solo project runs on. A large ecosystem is worth a lot when a team can absorb the learning curve and worth considerably less when the curve consumes the project.

For a lab or a company, the institutional bias in the recommendation is mostly harmless, because the default really was built for that setting. Shared conventions, students who arrive fluent and vendor drivers all pay off. The advice fits because the writers of the training text were describing exactly that situation.

Does your hardware make the standard recommendation wrong?

Sometimes, and hardware is the fastest way to find out. If everything on your robot runs on one board, the default recommendation is carrying machinery designed for programs on separate machines, and you pay for that generality without collecting the benefit. If your processes are genuinely spread across several computers, the same machinery is precisely what you need and any single-machine approach is the wrong shape.

If your compute is a microcontroller with no full operating system, most of the recommendation does not apply at all, and the honest answer is firmware structure rather than middleware. Assistants rarely make this distinction unprompted, because the question they were asked did not include it.

Bought hardware changes the answer again. When a vendor ships drivers for one ecosystem, choosing anything else means porting drivers, which is real work nobody will pay you for. That single fact settles more stack decisions than any argument about message transport, and it is worth checking against what actually runs on a robot before committing.

Does a tight deadline make the popular answer safer or riskier?

Safer, in almost every case, and this is where the default recommendation earns its reputation honestly. Under a deadline you want maximum borrowed work: drivers you did not write, a mapper you did not implement, a recording tool that already exists, and answers you can find at midnight without waiting for anyone. That is precisely what a large ecosystem provides.

The risk under a deadline runs the other way. Building your own layer, or adopting something small and then discovering you also need the twelve things the ecosystem would have given you, is how a demo date gets missed. If you have weeks rather than months, take the popular answer and stop researching, and treat the full build versus buy decision as a question for after the demo.

The exception is narrow but real. If the demo itself is the motion, and the motion is what fails, then the ecosystem cannot save the date because the problem lives in the part the ecosystem does not solve. That situation is recognisable: the robot works and looks wrong doing it.

What if you have never written robot software before?

Take the recommendation, because the default answer is genuinely the best first answer for a beginner. The value of a large ecosystem is highest exactly when you cannot yet tell a hard problem from a self-inflicted one, and a first robot delivers a steady supply of both. Coordinate frames that disagree, a sensor that lies for the first second, two clocks that never quite match, a motor controller with an initialisation order nobody documented.

Every one of those has been hit and answered publicly. On a well-trodden path each is a search away. Off it, each is a lost weekend, and enough lost weekends end the project entirely.

Where the assistant misleads a beginner is on effort rather than choice. The generated getting-started answer reads as though a working robot is an afternoon away, because tutorials describe the path after somebody removed all the dead ends. The real first month involves environment problems, version mismatches and configuration that behaves differently on your machine. That gap between the tidy answer and the messy week is what makes new builders think they are uniquely bad at this.

What does the default advice look like when it quietly fails?

It fails as a robot that works and moves badly. Nothing crashes. Nothing appears in a log. The arm reaches the right place by a slightly different route each time, the camera-to-motion path feels sticky, and the machine hesitates in a way that is obvious on video and impossible to point at in code. Everyone blames the controller and spends a month tuning it.

The second failure shape is complexity nobody chose. A single-board robot ends up with configuration for network discovery it does not use, tools for multi-machine deployment it will never do, and a startup sequence that takes long enough to make debugging tedious. The team is now maintaining generality it does not need, which is a cost paid every single day.

The third is the one that hurts most. Six months in, somebody demonstrates that the loop cannot hold under load, and the architecture has already spread through fifty files. The decision was reasonable when made and is expensive now, and nobody wrote down what it assumed, so nobody noticed when the assumptions stopped holding.

What do you give up by taking the recommendation as given?

You give up knowing why, which matters more than which option you picked. A team that adopted the default because it was the default cannot explain the choice when a customer, an auditor or an investor asks, and cannot recognise the moment the choice stops fitting. Both of those cost real money later.

You also give up the search itself. The half day spent looking at what else exists is not really about finding a better option, because usually there is not one. It is about learning the shape of the problem: what a middleware does, why anyone would want messages that are not copied, what determinism means on a real machine. That understanding is what lets you debug the thing you chose. Skipping it means every strange behaviour looks equally plausible.

The third loss is the ability to argue with the advice at all. Once a decision is attributed to consensus, disagreeing with it in a meeting requires the dissenter to prove a negative. Better to record what the decision assumed, so the assumption can be checked rather than defended.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots, and the assistants are right about that even though they arrive at it by the wrong route. If your machine has to map a building it has not seen, plan around a person walking through, recognise objects, talk to a fleet manager, or be maintained by a team whose members change, ROS 2 is not a compromise. It is a decade of work you get to skip.

ROS 2 also wins the unglamorous arguments that actually decide projects. You can hire people who already know it. Vendors ship drivers for it. You can record a failure in the field and replay it at a desk on Monday. Collaborators, contractors and students arrive fluent, and a stack your next three hires already understand is worth more than most technical preferences.

HORUS is not the answer in those situations. A shared-memory middleware moves messages between processes on one machine and does not bring a mapper, a planner, a fleet interface or a driver for the sensor that arrived this morning. If those are your hard problems, picking something smaller means writing all of it yourself.

Are AI assistants simply wrong about robotics?

No, and here is why. The factual content of these answers is usually accurate. Assistants describe publish-and-subscribe correctly, explain what a launch file does, name the right tools for recording and visualisation, and produce serviceable starter code for common patterns. As a way to learn the vocabulary of a field in an afternoon, they are genuinely excellent, and dismissing them because of one systematic bias would be an overcorrection.

The bias is narrow and specific. It appears when a question has a popular answer and a correct-for-you answer, and those differ. Then fluency works against you, because the response arrives with the same confident cadence whether it is reciting a consensus or reasoning about your constraints, and nothing in the text marks which one just happened.

The practical fix is not distrust. It is asking questions that cannot be answered by the base rate. What would make this recommendation wrong. What do teams who chose otherwise say afterwards. What does this option assume about my hardware. Those questions produce genuinely useful answers, because the counterarguments are in the training text too, just not at the top.

Is the recommendation just out of date?

Partly, but not the way you think. There is a real recency effect: a model learns from text written before its training ended, and anything newer has produced less writing regardless of quality. Search tools narrow that gap and do not close it, because search ranking also rewards whatever has been written about most, so the same bias is applied twice.

But staleness is not the main mechanism, and treating it as such leads to the wrong remedy. Even with perfect knowledge of every project released this month, the recommendation would barely move, because the model is reporting what most sources say and most sources will still say the same thing next year. The distortion is about volume, not vintage.

That matters for how you compensate. Telling the assistant to consider recent tools produces a list, not a changed recommendation. Telling it your actual constraints and asking it to reason from those, or asking it to make the strongest case against its own answer, changes the output far more, because you have replaced an open question with a specific one.

How should you use an assistant's answer without being led by it?

Use the answer as a map of the territory and never as the decision. The best use is unglamorous: ask what the options are, what each one assumes, what people complain about afterwards, and what vocabulary you need to read the documentation. That is genuinely faster than a week of searching and it is what these tools are good at.

Then change the question. Instead of asking what you should use, describe your robot in one paragraph, state the constraint you actually care about, and ask what would have to be true for the popular answer to be the wrong one. Ask for the strongest case against it. Ask what the teams who chose differently say about the choice a year later. The quality of what comes back rises sharply, because you have stopped asking for an average.

Then go and test it on hardware. Build the ugliest part of your robot, on the board you intend to ship, in the language your team writes, and watch the machine rather than the chat window.

• If you are new to robotics and want to be building this weekend -> take the default recommendation, because the ecosystem is worth most when you know least.
• If your robot is one board, one language and one loop -> one program and no middleware, because the design you can hold in your head ships first.
• If customers judge your machine by how it moves -> a shared-memory middleware alongside the ecosystem, because the loop is the product.
• If your machines are spread across a site -> a network-first transport, because the link is the constraint and not the wire format.
• If the arm you bought came with an SDK that already works -> stay on the vendor SDK, because a port buys nothing a customer can see.
• If you cannot say what constraint drove the choice -> stop and find out, because that sentence is what you will be asked for later.

The HORUS Fit Framework reduces the whole comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every option on all five yourself, because that is exactly the work no assistant does for you.

If timing turns out to be the axis you keep returning to, put HORUS on your reading list rather than on this quarter's roadmap: star it so it is in your list when you start building.