Best Robotics Tools for People Who Code With AI Assistants

Pick the tools your assistant has read the most of: ROS 2 and Python first, with HORUS or a vendor SDK once the robot moves. An assistant is fluent in whatever appeared often in its training, so a popular stack gets working suggestions and an obscure one gets confident fiction. That flips once your robot has a loop that cannot be late, because architecture decides that, not fluency. The rest of this post is for someone building a real machine with an assistant open in the next window, deciding what to point it at.

The code came out fast and the robot does nothing. No error, no crash, no clue. You ask again and get a different version of the same file, equally confident, with the variable names changed. You paste in the terminal output and the answer is a package you have already installed twice. Somewhere in the last hour the project acquired three ways of doing the same thing and you cannot remember which one is wired to the motors.

Then the parts that do run start behaving oddly. The camera works when you launch the pieces by hand and not when they all start together. Something stops publishing after a few minutes and nothing says why. A tutorial from a forum post gets pasted in wholesale and now half your code follows a convention from an older release, half follows a newer one, and both look identical to you. The uncomfortable part is not that the assistant is wrong. It is that you cannot yet tell when the assistant is wrong, and the robot is the only thing that will tell you, expensively, later.

Which robotics tools should you choose if an assistant writes most of your code?

Choose the stack with the most public code behind it, because an assistant's usefulness tracks how much of a stack has been written down in public, not how good the stack is on its own merits. This is a genuinely different ranking from the one an experienced roboticist would give you, and it is the correct ranking for your situation. Popularity means the suggestions you get are copies of things that worked for somebody, error messages you paste have been discussed before, and the shape of a normal project is something the assistant already knows. Unpopularity means you get code that looks completely reasonable and refers to functions that never existed. The second criterion is that mistakes should be loud. A stack where a wrong guess fails immediately at build time is far kinder to assistant-written code than one where a wrong guess produces a program that runs and quietly does nothing. The third criterion, which only matters once the robot moves, is whether your timing-critical path can sit somewhere small enough for a human to read entirely.

What makes a robotics tool easy for an assistant to work with?

A tool is easy for an assistant when its documentation is public, its version conventions are stable, and its failures are noisy. Public documentation is obvious, and stability is the one people miss: when a library changed its conventions between releases, an assistant blends both eras into a single file that looks plausible and does not build, and you will lose an evening before suspecting that the code came from two different worlds. Noisy failure matters because you are not reviewing the code closely, so you need the machine to review it for you. A typed interface, a compiler, a startup check that refuses to run with a wrong configuration: each of these turns a subtle mistake into a message you can paste back. Text configuration beats a graphical tool for the same reason, since an assistant cannot click a wizard but can write a file. Finally, prefer stacks that print what they are doing, because the questions you will be asking are about what actually happened, not what the code says.

What are the actual options for building a robot this way?

There are about seven realistic starting points, and the honest ranking depends on how much of the robot already exists. ROS 2 with Python nodes is the default recommendation for assistant-heavy work, since it has the largest body of public example code and the assistant's suggestions land closest to correct there. ROS 2 with C++ nodes trades some of that for stricter checking. HORUS is the option for the layer under all of it: open-source real-time middleware where Rust, Python and C++ processes share the same shared-memory ring buffers, so messages are not serialised between programs on one machine, released under Apache-2.0, and worth reaching for once you have a loop that must not be late rather than on day one. Then there is the SDK for a platform you bought, plain Python with no framework at all, firmware on a microcontroller, and a simulator-first setup with no hardware yet. Most projects that get finished use two of these together, and the pairing usually spans a big ecosystem plus one small owned piece. What assistants can and cannot write for robots is the fuller argument.

Which stack should you point your assistant at first?

Point it at the one whose failures you can currently recognise, which for most people means Python on a popular framework. Before reading a row, be honest about one thing: when the robot misbehaves, can you tell the difference between a logic mistake, a configuration mistake and a hardware fault? If not, pick the row where the most other people have been stuck in the same way, because your real bottleneck is diagnosis rather than typing.

The last column is the one to read first. Most bad weeks start with a stack chosen for what it does well rather than for what it does when you are lost. Two rows is the usual honest answer for a robot that gets finished: one row for the outside of the machine, where generated code is welcome and mistakes are cheap, and one row for the small part that moves the motors, where you read every line yourself. Nothing in the table stops you starting on one row and adding the second the week the robot starts stuttering.

What if you are building alone and have never shipped a robot?

Alone and new, take the most popular path even if a forum tells you it is bloated, because your scarcest resource is the ability to tell what went wrong. Every hour you spend on an unusual stack is an hour where nobody has written down the answer to your exact problem and your assistant is guessing from adjacent memories. Popularity buys you three things that matter more than elegance: suggestions that came from working code, error messages that have been discussed publicly, and a normal project shape you can compare yourself against. Set one rule for yourself from the first day. Never let generated code touch the motors until you have read it once, out loud if necessary, asking only what happens when a sensor stops reporting. That single question catches most of the dangerous output, because tutorial code assumes everything works and the assistant learned from tutorials. Keep the motors unpowered for the first run of anything new, and keep a second terminal printing what the robot thinks it sees, so you are never reasoning from the code alone. What quietly breaks when you build a robot this way covers the failure patterns in more detail.

What if your robot is one small board with a camera and two motors?

On a single small board, skip the framework at the start and write one Python program, then add structure only when a real problem forces it. A camera, two motors and a script is a complete robot, and an assistant is at its best in exactly that setting because the whole thing fits in one file it can see at once. The first genuine pressure usually arrives when you want the vision work and the motor work to stop interfering with each other, and the tempting fix is to split them into two programs. That is where the small board starts to matter, because two programs on one computer must hand a camera frame across a boundary, and the naive ways of doing that copy the picture more than once. You will feel that as jerky motion rather than as any number on a screen. Before adding a framework, try the boring fix: shrink the image before it crosses anything, and let the part that must stay on time do less work.

What if you want the robot moving this weekend?

For a weekend, pick the simulator or the single script, and do not install a framework on Saturday morning. A framework's first afternoon is spent on installation, a build, an environment that must be set up in every terminal, and a version pairing between the distribution and your board's operating system. That afternoon is worth paying for a project lasting months, and it is fatal for a project lasting two days, especially since it is the part an assistant helps with least. Installation problems are specific to your machine, produce error text that is nearly the same for a dozen unrelated causes, and get answered with confident advice that reinstalls the wrong thing. So keep the weekend scope brutal. One program, one loop, printed output you can watch, and the motors unpowered until the printed output looks sane. If a simulator is already installed, use that instead of hardware, since a robot that cannot fall off the table lets you fail as often as you like without walking across the room.

What if you can read code but have never written a control loop?

If you can read code, you already have the skill that matters most here, and the missing piece is smaller than it looks: a control loop is a thing that runs on a schedule and must not be late. That is genuinely most of it. The parts newcomers get wrong are not conceptual, they are habits. Do not do slow work inside the loop, so no waiting on a network call, no loading a file, no printing enormous strings every cycle. Decide what happens when the newest sensor reading is old, because it will happen, and the assistant will not add that branch unless you ask. Keep the loop short enough that a human can read the whole thing, since this is the one place where reviewing generated code line by line is non-negotiable. Ask your assistant to write the boring surroundings and write the loop's decisions yourself. If the vocabulary is unfamiliar, what a control loop is and why timing matters is the right primer.

What breaks first in robot code an assistant wrote?

The first thing to break is almost always the handling of missing or late data, because tutorial code assumes the data arrives. Generated code reads the newest camera frame and acts on the newest frame, with no branch for the case where the camera has been silent for a while, so the robot happily drives on a memory of a corridor that is no longer there. Second on the list is startup ordering: everything works when you launch the pieces one at a time in a familiar order, and fails when they all start together, because one program assumed another was already listening. Third is quietly mixed conventions from different library versions, which produces code that builds and behaves subtly differently from what you read. Fourth is queue behaviour that nobody chose deliberately, where messages pile up and the robot acts on a picture of the past. None of these appear in a demonstration. All of them appear the week you leave the robot running, which is why robots behaving differently every run is such a common complaint.

What do you give up by letting an assistant shape your stack?

You give up an accurate mental model of your own robot, and that is the whole cost. Everything else follows from it. When you did not write the code, you do not know which parts are load-bearing, so when something misbehaves your search space is the entire project instead of the two files you had doubts about. You lose the ability to estimate, because a change that sounds small might touch code you have never read. You end up with several styles in one project, since each session starts fresh and the assistant is happy to introduce a new pattern next to an old one. There is also a subtler cost around dependencies: an assistant reaches for whatever library it knows, and you can acquire a stack of packages nobody chose deliberately and nobody is tracking for updates. The countermeasure is not to write everything yourself. It is to keep a small map of the system in your own head, and to insist that anything that moves the robot passes through code you have read.

When is ROS 2 the better choice?

ROS 2 is the better choice for most people doing assistant-heavy robotics work, and it is worth saying that plainly. The assistant has read a great deal of ROS 2, so its suggestions are more often close to correct there than anywhere else, and that alone changes how your week goes. Beyond fluency, the practical cases are the usual ones: you need a driver for a lidar or a depth camera and the vendor ships one for that framework and no other, you need mapping or navigation that took a decade to get right, you want to record a run and watch it back at your desk, you want to see what the robot believed rather than guessing from printed text, or you want to hire someone later who already knows the vocabulary. In all of those cases HORUS is not the answer, because it is a layer underneath rather than a catalogue of robot behaviour, and you would be giving up the exact thing you came for. Start where the help is thickest.

Can an assistant build the whole robot if you keep prompting?

No, and here is why. The assistant cannot see the robot. Everything it knows about your machine arrives as text you chose to paste, so the moment a problem stops producing text it stops being solvable by prompting. A motor that hums instead of turning, a camera mounted a little crooked, a loose connector, a control loop that stutters when a second program gets busy, a wheel that slips on a polished floor: none of these produce an error message, and an assistant asked about them will produce a fluent guess that sends you looking in the wrong place. That is the real ceiling, and it is not about model quality. It is about evidence. The way through is to make the invisible visible: record what the sensors actually reported, print the decisions the robot made and when, and keep a log you can paste. Do that, and the assistant becomes genuinely useful again, because you have converted a physical mystery into text. Robotics rewards the person who can produce evidence.

Do assistants know the newer robotics libraries well enough to help?

Partly, but not the way you think. The gap is not that an assistant knows nothing about a newer library. The gap is that it does not know it is guessing, so you receive confident code with function names that were invented by pattern-matching against similar libraries, and everything reads as though somebody tested it. This is worse than an admission of ignorance, because it costs you an hour before you doubt the premise. The workaround is straightforward and works well: paste the current documentation into the session and tell the assistant to use only what appears there. Assistants are far better at reading than at remembering, and a page of real interface text turns a guessing problem into a comprehension problem. The same trick fixes version drift on well-known frameworks, where the failure mode is code that blends conventions from two releases. Treat recalled API details as a hypothesis and pasted documentation as fact, and newer libraries stop being a special hazard.

How do you decide what to start with today?

Decide with one question about diagnosis and one about the loop. First: when something breaks, will there be a public answer? If yes, take the popular stack even if a stranger on a forum calls it heavy, because your bottleneck is understanding rather than typing. Second: is there any part of this robot where being late causes harm, such as an arm that must stop before it hits the table or a base that must stop before the edge of the dock? If no, stop optimising and go build. If yes, draw a box around that part and make it small enough to read in one sitting, then let generated code live everywhere except inside that box. Those two answers settle almost every stack question people bring to this decision. The rest is preference, and preference is cheap to change later, which is why spending a week comparing frameworks before writing anything is the most common way to end a weekend with no robot.

Take the line that matches you:

• If you are new and alone -> ROS 2 with Python, because the assistant has read the most of it and so has everyone answering your questions.
• If your robot is one board and one script -> no framework yet, because the whole program fits in one place the assistant can see.
• If your parts have not arrived -> a simulator, because failing for free is the fastest way to learn what you do not know.
• If you bought a finished platform -> the vendor's own SDK, because their examples are what the assistant will match against.
• If something must never be late -> a small owned loop under everything else, because generated code belongs outside that box.

The HORUS Fit Framework is the checklist behind those lines, and none of its five axes is a number: ecosystem size, setup effort, team size fit, deployment target, and licence. Score each candidate on all five, and the axis you cannot compromise on decides.

Start where the help is thickest, and add the specialised layer only when the robot asks for it. When the machine reaches the point where sensing and control share one computer and the timing stops forgiving you, HORUS is open source under Apache-2.0, with Rust, Python and C++ reading the same ring buffers instead of serialising to each other. Star it so it is in your list when you start building.