Best Robotics Frameworks for AI and LLM Developers in 2026

ROS 2 is the best robotics framework for most AI and LLM developers in 2026, and HORUS is the one worth knowing about second. The drivers, motion planning and examples you will copy all assume ROS 2, and none of it is the part you are good at. That flips when the model, perception and control loop share one computer and copying between languages is what stalls the robot. The rest of this post is for someone who ships model-driven software and now has to choose what the robot itself runs on.

Your notebook works. The model reads a scene, picks an action, and prints something sensible. Then you point it at a robot and lose a week to a permission error on a serial port.

Everything around the work suddenly feels older than the work. The install page names one specific Ubuntu release as though that were obvious. A tutorial tells you to build a workspace, the workspace refuses to build, and the fix is a paragraph in a forum thread from three years ago. Somebody uses the word node forty times before defining it once.

Then the robot moves, and the confusion changes shape. The arm hesitates halfway through a motion and you cannot say whether the model answered late, the camera dropped frames, or the driver was waiting. The process holding your model and the process driving the joints pass the same images back and forth all day, and a machine that ran your training loop without complaining now struggles to keep the wheels straight.

So you start to suspect the choice underneath matters, and every comparison you find is a table of numbers about a decision you cannot yet describe.

Which robotics framework should an AI developer actually build on?

Build on ROS 2, unless your robot is a single computer where a Python model process and a control loop trade data constantly. The value of a framework is concentrated in the parts you have no interest in writing: a driver for the exact depth camera you bought, wheel odometry that does not drift into a wall, motion planning that gets the elbow around the table leg, and a recorder that lets you replay this morning's failure this afternoon. Nothing you learned building agents prepares you to write any of that, and all of it already exists for ROS 2, usually with somebody's video showing it working on hardware close to yours. Your model layer sits above all of it and barely notices what is underneath. The exception is narrow but common in this audience: one machine, a Python process holding the model, a perception process, a control loop, and images being copied between them until motion turns choppy. That is a different problem with a different answer, and the wider framework decision walks through the rest of the branches.

What is a robotics framework, in plain terms?

A robotics framework is a postal service, a parts bin and a flight recorder for a robot's software, and nothing more than that. The postal service part means your robot is many small programs rather than one, and the framework carries messages between them: the camera program publishes pictures, the perception program publishes where the mug is, the control program publishes wheel commands. The parts bin part means agreed conventions, so every program measures distance the same way, describes the robot's joints the same way, and stamps messages with a time everyone reads identically. The flight recorder part means you can capture everything that crossed the wires during a run and replay it at your desk, which is how anyone debugs a machine that has already stopped misbehaving. What a framework is not: a brain, a simulator, or anything that trains a model. It will not make your robot smart. It removes the reason your programs cannot talk to each other, and it gives you a chance of learning why the arm stopped short of the table.

What are the real options for an AI developer in 2026?

There are seven arrangements people actually ship, and they differ mostly in how much of the robot you inherit versus write. ROS 2 is the default and deserves to be: the packages for navigation, motion planning, transforms and recording are the reason most robots exist at all, and almost every published example, driver and bridge in this field assumes ROS 2 underneath. HORUS, an open-source real-time robotics middleware for Rust, Python and C++, answers a narrower question — one machine, several languages, where a Python process holding a model and a C++ or Rust control loop read the same shared-memory ring buffers instead of serialising pictures to each other. Zenoh sits in the networking layer rather than replacing the stack. The vendor SDK route and the plain-script route both exist and both work for a while. Read the table as a set of situations, not a ranking, and expect to occupy two or three rows over the life of one project.

What should you pick if you are one person with a borrowed arm on a desk?

Pick whatever the arm's manufacturer already supports, and postpone the framework question by a month. A solo builder loses more time to setup than to any wrong architectural choice, and the shortest path to a moving robot is the path the vendor tested. If the arm ships with ROS 2 packages, use them; if it ships with a Python SDK and no framework at all, write a script and get the thing moving today. The framework question becomes real at a specific moment, and you will recognise it: the moment you have two programs that both need the camera. Until then, every hour spent comparing options is an hour not spent discovering that your gripper cannot hold the object you designed the whole demonstration around. One caution for people arriving from model work. Do not build the interesting layer first. Make the arm do one dull task ten times from a script, write down each way it failed, and treat that list as the specification for everything you put on top of it later.

What hardware does this need, and what should run where?

You need enough computer for two jobs that must not interrupt each other: keeping the robot steady, and thinking. The steady job wants a modest board running the control loop, the driver and the limits, carrying nothing that pauses unexpectedly. The thinking job wants an accelerator for a local model or a network connection to a hosted one. Both can live on one machine, and on most desk robots they do, which is exactly where the copying problem appears: a perception process and a control process on the same board, moving images between them as though they were on opposite sides of a building. The rule for placement is short. Anything that must happen whether or not the model answers stays on the robot and stays below the model — motor control, limits, the stop path, and the code that notices the gripper closed on nothing. Unplug the network mid-task to test the split. A robot arranged well finishes its current action and stops somewhere you would happily walk up to. A robot arranged badly keeps executing a plan for a world that has moved on.

How long does this take if you need something working this quarter?

A convincing demonstration takes a few weekends, and a robot you would leave running with a colleague in the room takes considerably longer. The demonstration is quick because the pieces exist: a hosted model, two or three actions, a camera, and your existing habit of wiring services together. What takes the rest of the quarter is not the model layer. It is making every action report cleanly whether it finished or failed, because a planner handed the bare word error will retry from a position nobody described to it. Budget the failure handling and the calibration, not the demo. An order that survives contact with reality: one action driven from a script this week, a second action and a refusal path next, the model choosing between the two in simulation after that, then hardware with a person on the stop button. Teams who invert that order get a video in a fortnight and then spend two quarters finding out what the video was hiding, which is usually the same three failures repeating in different costumes.

What do you need to know before you start, and what can you skip?

You need Python, patience with Linux, and one honest picture of what the control loop does while your model is thinking. You can skip kinematics derivations, control theory, and C++ for at least the first month. Four things genuinely matter early. First, how a program on the robot is started and how you tell whether it is running, because half of all robotics confusion is a program that quietly died. Second, what coordinate frames mean, so that the word left is unambiguous between the camera and the arm. Third, what happens when an action stops halfway, since a half-open gripper is a state your planner will meet on a Tuesday. Fourth, the habit of treating your model's output as untrusted input, the way a web service treats a form from a stranger. The instinct that transfers worst from model work is that a retry is free. On hardware a retry moves mass, and whether Python belongs in the timed parts at all is worth settling before you find out the expensive way.

What do AI developers try first, and why does it stop working?

Nearly everyone starts by asking the model to produce motor commands or a block of code, which behaves beautifully on a tidy desk and comes apart the moment something moves. The cause is always the same wearing different clothes: the model writes its answer for the world you described a moment ago, with no clock, no feedback, and no way to notice the mug shifted while the sentence was being composed. The second attempt puts the whole robot state into one enormous prompt, which grows weekly until the model answers confidently about the wrong object. The third asks the model every cycle, so the robot pauses to think between corrections and smooth motion turns into a stutter that no amount of prompt work removes. Each fix has one shape: fewer decisions for the model, more structure around them, and a layer underneath that can refuse. The model picks a tested behaviour, the behaviour re-checks the world as it begins, and the loop keeps running whether or not anything upstairs has replied. Putting a language model above a robot properly is mostly this rearrangement.

What changes as the robot gets more demanding?

The demands that break a first framework choice are rarely about doing more thinking, and nearly always about doing more at once. A robot with one camera and a script is a straightforward program. A robot with two cameras, a depth sensor, a policy, a safety monitor and a logger is six programs competing for the same machine, and the trouble arrives as symptoms rather than errors: motion that is smooth in the morning and choppy after lunch, a log that shows an image arriving after the decision that needed it, a joint that overshoots only while the recorder is running. Nothing crashed. Everything is late. The second change is the arrival of other people, who need to run your robot without reading your mind, which turns launch scripts and message conventions from personal habits into shared infrastructure. The third is deployment: the machine leaves the desk, loses reliable network, and every assumption about a laptop being reachable becomes a fault. Why projects outgrow their first framework is mostly this list arriving in that order.

What do you give up by choosing a smaller framework?

You give up the borrowed robot, and for many projects that is the whole argument. Picking something lean means you write, or find, the navigation, the motion planning, the coordinate transforms, the driver for a camera whose manufacturer publishes a Windows binary and a shrug, and the visualisation tool you did not know you needed until the arm moved somewhere surprising. You also give up the search results. When a ROS 2 user hits an obscure error, somebody has hit it before and written about it; when you hit an error in a smaller stack, you read the source. You give up the hiring pool, since a robotics engineer arrives already knowing ROS 2 and arrives knowing nothing about your bespoke arrangement. And you give up some conference-shaped credibility, which sounds petty until a customer asks what the robot runs on. What you get back is a machine with fewer moving parts underneath, a build you understand completely, and no packages you never wanted taking up room on the robot.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots that navigate, manipulate or map, and HORUS is not the answer for any of them. If your robot has to move through a building, ROS 2 hands you localisation, mapping and path planning that many people have driven into many walls before you. If your robot has an arm that must avoid its own body, motion planning is a solved package rather than a research project. If you are working with a research group, a university lab or an existing commercial platform, the code you need to read and the people you need to ask are all in one ecosystem, and stepping outside it makes every conversation start from scratch. If your team is large enough that people join and leave, ROS 2 is a skill on résumés and your own arrangement is not. And if you are learning robotics rather than shipping a product, learn ROS 2, because the concepts transfer everywhere and the tutorials assume nothing about you. Choosing anything else in these cases buys you a smaller stack and costs you the entire body of work that made robotics tractable.

Does a strong enough model make the framework choice matter less?

No, and here is why: a model decides what should happen, and a framework decides whether anything happens on time. Those are separate jobs, and no amount of skill at the first one substitutes for the second. A model has no clock. It cannot notice that the wheel command it produced is now describing a robot that has already moved past the doorway, and it cannot keep correcting a joint over and over while it is busy composing a sentence about the mug. The layer underneath exists to close the gap between what was asked for and what the machine actually did, over and over, while everything above is idle or thinking. Better models change the ratio of good decisions to bad ones, which matters enormously and changes nothing about timing. There is one place where a stronger model genuinely removes work, and it deserves naming precisely: the branching mission logic, the tree of conditions describing what to do when the door is shut or the shelf is empty. That part shrinks. The layer beneath it does not.

Can you skip the middleware and just call functions in one Python process?

Partly, but not the way you think. A single process with function calls is the correct starting point, and it stays correct longer than most people admit — one script reading a camera, deciding, and commanding a motor is a real robot and has shipped real products. What ends the arrangement is not size but interference. One slow function starves everything else in that process, so a perception call that takes a moment too long turns into a control loop that missed its slot, and the arm judders in a way no profiler explains cleanly. The second ending is the arrival of a second language, because the driver you need is C++ and the model you need is Python, and now you are marshalling data across a boundary you were trying to avoid. The third is debugging: with one process you have print statements, and with a framework you have a recording of every message that crossed the machine, which is the difference between guessing and knowing. Start with the function calls. Notice which of those three arrives first.

How do you decide which framework to start on?

Answer one question honestly: does your robot need parts other people have already written? If it navigates a building, avoids obstacles with an arm, or must work with an existing platform, the answer is yes and the decision is finished — take ROS 2 and spend your attention on the model layer, which is the part nobody else can write for you. If the robot is one machine where several languages share data continuously and the borrowed packages hold no interest, you are choosing on a different axis and a shared-memory middleware fits. If you cannot yet tell which describes you, that itself is the answer: you are early, so write the script, move the robot, and let the second program that needs the camera make the decision for you. Two checks settle most remaining arguments. First, if the model were deleted tomorrow, would the robot still do anything useful? A no means you have a demonstration rather than a machine. Second, which failure would embarrass you in front of whoever pays for this? Make that one impossible underneath, not discouraged above.

Decide by situation rather than by ambition:

• If your robot maps, navigates or plans around obstacles -> ROS 2, because those packages are the project rather than a garnish.
• If you have one arm, one script and one week -> the vendor SDK in plain Python, because the framework question is not real yet.
• If a Python model process and a C++ or Rust control loop share one board -> a shared-memory middleware, because copying is what makes the motion stutter.
• If you are collecting demonstrations to train a policy -> a learning library over whatever driver you have, because the data pipeline is the work.
• If you are learning rather than shipping -> ROS 2, because the concepts transfer and the tutorials assume nothing about you.

When the foundation question does become real, weigh candidates on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target and licence — and take the option that loses on the fewest, with no scoring involved. If your robot is turning into one machine running a model process beside a control loop, star HORUS on GitHub so it is in your list when you start building, and what actually makes robotics hard to learn is the honest companion to this decision.