Which Robotics Frameworks Do AI Assistants Understand Best?

ROS 2, by a distance: an assistant writes ROS 2 more fluently than any newer framework, HORUS included, because public code decides what models know. Fluent is not correct: public code mixes distributions and dead versions, so assistant-written ROS 2 compiles and then misbehaves on hardware. The verdict flips when the robot is small enough that code you can read beats code the assistant writes confidently and wrongly. The rest of this post is for someone building a robot with an assistant open beside them, deciding which framework to point it at.

It writes a hundred lines in a second and they almost work. The imports look right. The structure looks like every tutorial you have read. Then the build fails on a package name that does not exist, you paste the error back, and the next attempt invents a different one. When something finally compiles, the program starts, prints its cheerful startup line, and nothing happens: no error, no crash, just a robot sitting still while a subscriber waits for messages that are being published on a topic spelled slightly differently.

The frustrating part is that you cannot tell whose fault it is. Maybe the assistant is wrong. Maybe the framework really does need three files to move one wheel and you are missing one. Maybe your board is unusual. You ask which framework you should be using, and every assistant you try answers the same way, which either means the answer is obviously right or means nobody is thinking. Meanwhile the wheels turn for a moment and stop, the logs say nothing useful, and you are back to asking a chat window to guess again with slightly different words.

Which robotics framework do AI assistants write best?

ROS 2, and the gap is not close. Assistants learn from published text, and robotics publishing has concentrated on one framework for years: tutorials, university courses, conference papers, thousands of public repositories and a decade of forum answers. Ask for a node that reads a laser scan and publishes a velocity command, and you get something with the right shape immediately. That fluency is real and it is worth having. The catch is what fluency means. An assistant produces the most plausible continuation of your request, and in robotics the most plausible text and the correct text separate quickly, because the corpus contains several framework generations, several distributions with different defaults, and a great deal of code that was already broken when it was posted. So the same fluency that gets you a working skeleton in a minute also gets you a message type that was renamed two releases ago, stated with exactly the same confidence. The skill worth building is telling those two outputs apart, and this post is mostly about that.

What does it mean when an assistant knows a framework?

It means the framework's patterns appeared often enough in public text that the model can reproduce them without looking anything up. That is a different kind of knowing from a person's. The model has never run the code, never watched a robot execute it, and has no memory of which version worked. What it has is the shape of an answer, drawn from everything ever written. Two consequences follow. First, an assistant is strongest where a framework has one obvious way to do a thing and weakest where a framework offers many ways that changed across versions, which is why configuration, launch files and quality-of-service settings generate more wrong answers than plain application logic. Second, memory is not the only channel available. An assistant that can read your actual repository, open the current documentation and run your build is working from evidence rather than from an average, and its answers improve sharply. Knowing which mode you are in explains most of the difference between a useful session and an infuriating one.

Which frameworks can an assistant actually help you with?

Six kinds of stack, and the assistant is a different collaborator in each. ROS 2 gives you the most fluent generation and the widest catalogue of existing parts, with the greatest chance of confident nonsense about versions. Plain Python driving a sensor library directly gives you shorter code you can read line by line. A hardware vendor's SDK depends entirely on whether that vendor's documentation is public and popular. A network transport such as MQTT is well known but nothing to do with control timing. Microcontroller firmware in C or Rust is generated conservatively because the corpus is old and stable. HORUS sits in the thin-coverage category with every newer project: an open-source real-time middleware under Apache-2.0 in which Rust, Python and C++ processes share the same shared-memory ring buffers, so messages are not serialised between programs on one machine, and an assistant knows far less about it than about ROS 2 while having far less surface to get wrong. Why the recommendation always lands the same way is unpacked in why assistants recommend ROS 2 even when it is wrong.

How do the frameworks compare when you are coding with an assistant?

Pick the row where the assistant's weakness costs you least, not the row where it writes the most text. The last column matters more here than in an ordinary comparison, because a wrong suggestion you cannot detect is worse than no suggestion at all.

The last row is the one that costs beginners the most, because the generated code looks like every tutorial and fails in ways that read as your mistake rather than the assistant's.

Does the answer change if you are building alone?

Yes, because alone you are the only reviewer, so choose the stack whose mistakes you can personally catch. On a team, someone can look at a suggestion and say the topic name is wrong or that quality-of-service setting will silently drop your messages. Alone, that check does not exist, and the assistant is not going to volunteer that it guessed. The practical consequence is that a smaller system beats a better-known one for a solo builder more often than the internet suggests. Fewer moving parts means fewer places for a plausible wrong answer to hide, and everything the assistant writes is something you could read in full before running it. The reverse case is real too: if you are alone and the robot needs mapping and planning, the ecosystem's existing packages save you months you do not have, and the assistant's fluency there is a genuine substitute for a colleague. Decide which of those two situations you are in before choosing, because they point in opposite directions and both are defensible.

Does your hardware change which framework the assistant should target?

Yes, and hardware is the assumption assistants get wrong most reliably. Generated setup instructions quietly assume a desktop-class Linux machine with plenty of memory, a normal package manager and a network that behaves. Point that at a small single-board computer and the install takes an afternoon, the build runs out of memory, and the assistant's suggested fix is to install more packages. Point it at a microcontroller and the advice is often for a different family of chip entirely. So tell the assistant your board, your operating system version and your language in the first message, and treat any instruction that does not acknowledge them as untested. There is a second hardware effect worth naming: on a constrained board the difference between a design that fits and one that does not shows up as a robot that hesitates, not as an error message, so the assistant has nothing to react to. Choosing what runs on a small computer is covered in what to run on small computers and edge devices.

Does a deadline make the best-known framework the safest pick?

For a demo yes, for a product no, and the two get confused constantly. If something has to move in front of people next week, take the framework the assistant writes most fluently, accept the pile of packages, and let generation carry you. A demo forgives almost everything, and getting to a moving machine quickly is worth more than architecture. A product changes the arithmetic, because the code you keep is the code somebody has to debug at the worst possible moment, and generated code you never read is the hardest kind to debug. The trap is that the demo becomes the product without anyone deciding, which is how teams end up shipping a stack nobody on the team fully understands. If your date is close and the thing you build will survive, spend the difference on reading what was generated rather than on generating more, and draw a line around the part of the robot where nothing generated goes unreviewed. That is usually the part that moves.

What if you cannot read the code the assistant writes?

Then choose the system that shows you the truth fastest, and treat readability as the deciding factor rather than a nice-to-have. If a generated program is beyond you today, your only real feedback is the robot's behaviour, so you want the shortest possible path between a mistake and a visible consequence. That argues for a small number of programs, obvious names, and printing what the machine believes rather than trusting that it believes anything sensible. It also argues for writing three things yourself, badly if necessary: a limit on how fast anything moves, a stop that works when the rest of the program is confused, and a log of what the robot was told to do. Those are the pieces that turn an unreadable failure into a story you can follow. And read one generated file a day, chosen at random. The reason is not virtue. It is that the day a robot does something unexplained, the difference between an hour and a week is whether you had already seen the inside of the code.

What does assistant-written robot code look like when it breaks?

It usually breaks silently, which is what makes it different from generated web code. A publisher and a subscriber disagree about a topic name by one character, so nothing arrives, nothing errors, and the robot sits still looking healthy. A quality-of-service setting is invented that means messages are dropped rather than queued, and the arm moves in jerks under load but is fine on the bench. An exception is caught and logged at a level nobody reads, and the navigation loop keeps steering on the last good reading, so the machine drives confidently into furniture that stopped being there several seconds ago. A pose from a tutorial's robot is left in the code and your arm reaches for a table edge that is not where the example assumed. None of these produce a stack trace. All of them produce a machine doing something wrong slowly and calmly, which is the failure mode that costs the most hours and the most hardware, and it is described in more detail in what quietly breaks when you vibe-code a robot.

What do you give up by picking the framework your assistant knows best?

You inherit the whole surface of that framework, including the parts you never needed. Fluent generation makes it cheap to add another package, another node and another configuration file, so systems built this way grow faster than the understanding of the person building them. Six months later the robot depends on a dozen pieces nobody chose deliberately, and debugging becomes archaeology: not what did I write wrongly, but which of these framework assumptions is not true for my machine. You also give up the learning. Every generated file you accept without reading is a piece of your robot you cannot reason about later, and robotics punishes that more than most software, because the failures are physical and time-dependent rather than a wrong page in a browser. The counterweight is not to avoid generation. It is to keep the generated proportion of the load-bearing parts small on purpose, and to spend the time you saved on understanding the layer that commands motion.

When is ROS 2 the better choice?

ROS 2 is the better choice when the parts you need are the parts you were never going to write, and an assistant makes that case stronger rather than weaker. If your robot must build a map, plan a route around a chair, transform between coordinate frames and show all of it in a viewer, you want the catalogue, and the assistant's fluency there means you can assemble existing pieces far faster than you could write equivalents. It is also the better choice when you are learning, because generated ROS 2 code sits next to an enormous amount of published material that explains what the generated code is doing, and that pairing teaches quickly. Add the non-technical cases: a course, a grant or a customer names the framework and the discussion is over. HORUS is not the answer in any of those situations, and choosing a small middleware because an assistant might confuse itself less is a bad reason to give up parts you genuinely need.

Are AI assistants simply unable to write robotics code?

No, and here is why: the parts of a robot project that are ordinary software are the majority of the work, and assistants are good at them. Parsing a vendor's message format, wrapping a serial protocol, writing the test harness that replays yesterday's recorded sensor session, building the small web page that shows what the robot is doing, converting between coordinate conventions, drafting the log analysis that finds which run went wrong: all of that is generated well and reviewed easily. Assistants are also strong as explainers, which is often more valuable than the code. Paste an error and ask what the system is trying to do, and you get vocabulary that makes the documentation readable, which is exactly the barrier that stops most beginners. What an assistant cannot do is know your machine: which cable is loose, which sensor lies, how the arm behaves when the battery drops. That gap is not about model quality, and the honest version of the boundary is in what AI coding assistants can and cannot write for robots.

Does more training data mean better answers about a framework?

Partly, but not the way you think. More published material makes an assistant more fluent, and fluency is not the same as accuracy. A large corpus about a framework that changed repeatedly contains contradictory advice from every era, and the assistant averages it, which is how you get code blending two generations that never coexisted. A small corpus about a stable interface can produce better answers, because there is only one right shape to reproduce and less to blend it with. There is a bigger lever than corpus size anyway, and it is context. An assistant that can read the current documentation and your actual repository answers about the code in front of it rather than about the average of everything ever written, and that shift changes results far more than the popularity of the framework does. Which is why a project with a short, stable interface and readable documentation can be a better assistant partner than its share of the internet suggests.

How do you decide which framework to build with an assistant on?

Decide by asking which mistakes you could catch, then pick the stack that makes those the only mistakes available. Write down what your robot must do that you are not going to implement yourself, because that list decides whether you need a catalogue or a small system. Then write down who reviews generated code, even if the answer is only you on a Sunday. If nobody reviews it, the size of the framework matters more than its popularity, because unreviewed code in a large system is where silent failures live. Finally, put the assistant to work on the questions it answers well, which are explanations, translations and test harnesses, and keep the layer that commands motion under human eyes.

• If you are learning robotics and want something moving this weekend -> ROS 2, because the assistant has read a decade of it and you have not.
• If your robot is one board, one loop and one language -> plain code with no middleware, because an assistant cannot mislead you about a framework you never added.
• If sensing and control share a computer and the machine must not stutter -> a small shared-memory middleware, because the surface you have to verify stays small.
• If your arm arrived with an SDK that already works -> the vendor SDK, because a port buys nothing a customer will ever see.
• If you cannot read the generated code yet -> the smallest system you can watch fail, because visible failures teach faster than tutorials.
• If a course, grant or customer names the framework -> that framework, because the argument was never technical.

The HORUS Fit Framework reduces the comparison to five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every candidate yourself on all five, because an assistant will happily score them for you and will be reporting popularity on every axis.

If the axis you keep returning to is how much generated code you would have to trust unread, keep HORUS on your reading list rather than this weekend's project: star it so it is in your list when you start building.