Can ChatGPT Control a Robot? An Honest 2026 Answer

No, ChatGPT cannot control a robot by itself, but a language model above deterministic control code is useful and now ordinary. The model turns a vague sentence into a plan but cannot promise to answer in time, so the stopping code stays underneath it. Underneath means ROS 2 or a leaner middleware such as HORUS, and that only stops mattering if nothing your robot touches can be hurt. The rest of this post is for someone deciding whether to put a language model in a robot at all, and which layer it belongs in.

You saw the video. Somebody says "clean up this table" and an arm picks up cups, and nothing in the demonstration tells you what was actually running. You went looking, and found either a repository naming a model you cannot run or an article that skipped the part you care about. Maybe you already have a robot that works — it drives, or its arm goes where you send it — and you are tired of writing a new script every time you want a slightly different behaviour. Maybe you are the other kind of stuck: you can talk to a model all day and have no idea what to connect it to. Either way the real question is not whether this is possible, because obviously something out there is doing it. The question is what is genuinely inside that loop, how much of it the demonstrator built by hand beforehand, and what happens the first time the model says something confident and wrong while an arm is already moving.

Can I put ChatGPT in charge of my robot?

No, not in charge of the part that moves, though it can be in charge of deciding what the robot should do next. Those are two different jobs, and treating them as one is why the question feels unanswerable. The moving job runs without pause: something checks where the arm is, compares that with where it should be, and corrects, over and over. If that job stops to wait for an answer from a chat service, the arm keeps travelling while the wait happens, and nothing is holding the limit that keeps it off the table. The deciding job is different in kind. Somebody says "tidy the bench", and something has to turn that into an ordered list of things the robot already knows how to do. Language models are unusually good at that conversion, including the awkward parts: working out which object "the blue one" means, or that a drawer opens before anything goes into it. Put a model there, above named skills you wrote and tested, and it earns its place. Put it lower and you have built something that lunges.

What does it mean when people say a language model is driving a robot?

It almost always means one of three arrangements, and the demonstrations that impress you are rarely doing the thing you assume. The first is offline authoring: the model writes code, a person reads it, and the robot runs software reviewed before anything moved. That version is the most common and the least advertised, because it is a programming aid rather than a robot demonstration. The second is runtime selection. The robot has a menu of skills somebody wrote by hand — go to, pick up, open, look for — and the model chooses from the menu and fills in the blanks. The robot is not being controlled by the model there so much as directed by it, and every actual motion comes from code that predates the conversation. The third is genuinely different: a model trained on recordings of robots doing tasks, which outputs motion directly. That third kind is not ChatGPT and does not behave like it, because such a model runs on the machine rather than in a data centre and cannot tell you why it did what it did.

What are my options for connecting a language model to a robot?

Five arrangements cover nearly everything people build, and they differ mostly in where the model sits and what happens when the model is unavailable. A cloud chat model as a planner is the easy start: the robot sends a description of its situation, receives a plan, and runs named skills. A small local model does the same job without the network, in exchange for a weaker planner and a heavier onboard machine. A robot-trained action model replaces some of your skills rather than directing them. Beneath any of those sits the layer that actually moves things, and that is where ROS 2 and its agent bridges compete with leaner middleware — HORUS, for instance, is an open-source Apache-2.0 layer for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so the camera frame a Python agent looked at and the compiled loop acting on it are not serialised between processes on one machine. That layer runs no models; it is the floor, not the brain. The fifth option is no language layer at all, which is right more often than the videos suggest.

How do those arrangements compare?

The right arrangement follows from who will speak to the robot and what happens when the model is wrong, not from which model is currently best. Read the last two columns first and treat the middle one as a warning label. None of these rows are exclusive: most working systems combine a cloud planner for hard requests with a short fixed vocabulary for common ones. Every row also assumes you have skills worth composing, because a language layer arranges capabilities and cannot invent them.

Does this make sense for a hobbyist, a researcher, or a product team?

Yes for hobbyists, yes for researchers, and carefully for product teams, and the difference is who pays when the robot misunderstands. For a hobbyist this is close to free entertainment: the skills are yours, the stakes are a knocked-over cup, and composing behaviours by conversation is more fun than editing a script. For a researcher it is the live question in the field, and the interesting work sits between language and skills rather than in the model. For a product team the calculation changes completely. A machine that accepts free-form instruction from customers inherits a permanent support burden, because somebody will eventually phrase a request in a way the model interprets creatively, and you will be the person explaining that. Product teams that ship this successfully almost always narrow it: a closed set of things the robot will agree to do, with the model interpreting phrasing rather than inventing plans. The demonstration is open-ended. The product is not, and that is not a failure of ambition.

What hardware do I need for this?

Less than you expect if the model runs elsewhere, and considerably more if it runs on the robot. With a cloud model the robot needs a network path, a camera or some other way to describe its surroundings, and a defined behaviour for when the connection disappears mid-plan. The computer on the robot only runs your own code, as it already did. With a local model the picture changes: that machine now runs a model and a control loop at once, and under the pressure it is the loop that suffers, because the loop is the part with a deadline. The common escape is to keep the model on a second computer nearby and let the robot ask it questions, which gives you local privacy without starving the part that must not be late. Microcontroller-class hardware does not participate in this at all. A small board runs firmware, takes commands from a larger computer, and is unaware that a language model exists anywhere in the system.

How long before this actually works?

A convincing demonstration takes a weekend; something you would let a stranger operate takes months, and the gap between them is skills, not models. The weekend version works because you asked in roughly the phrasing you had in mind while writing the skills. The months go on everything after that: writing skills that fail in a defined way instead of an interesting one, deciding what happens when the model names a skill that does not exist, deciding what happens when it names an object that is not in the room, and handling the request that is reasonable and simply not possible with the hardware you own. Connecting a model is an afternoon. Making the robot behave predictably when the model is wrong is the project. For the fastest honest route, spend the first week writing three skills that each end in a known state, and only then hang a model above them.

What do I need to know before trying this?

You need enough Python to write a function, and a clear list of what your robot can already do without help. That is a lower bar than most people assume, because the model does not need you to understand machine learning. What you do need to understand is why the loop underneath cannot wait, which is the single idea separating people who build this safely from people who build something that works in a video. If that idea is fuzzy, the explanation of control loops and their timing is the prerequisite, not the model documentation. The second thing worth knowing is where an interpreted language is fine and where it is not, because your agent layer will be Python and your loop may not be able to be; the honest account of Python in robot control covers that line. Nothing here requires a degree. It requires being precise about what each of your functions promises.

What do I give up by putting a language model in the loop?

You give up repeatability and the ability to explain a run afterwards. The same request, phrased the same way, on the same day, can produce two different plans, and both may be reasonable. Debugging changes character: you are no longer reading a stack trace, you are reading a transcript and guessing at intent. You also take on a dependency that changes underneath you: a hosted model is updated without your involvement, and your robot behaves differently on a day you shipped nothing. Add timing you cannot schedule — an answer arrives when it arrives — and the operational picture is unlike anything in your service backend. None of this argues against doing it. It argues for keeping the model above a layer that behaves the same way every time, so that when the language part surprises you, the physical part still refuses to hit the table. Unpredictability is acceptable exactly where it cannot reach the actuators.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the hard part of your robot is everything except the language layer. If you need a map of a building, a path across it, an arm that plans around obstacles, or drivers for sensors whose vendors only ship ROS 2 support, the ecosystem is the reason to be there and no messaging layer competes with it. If more than one computer is involved, ROS 2 has answers you would otherwise write yourself. In a research group, ROS 2 is how your results get reproduced by somebody else. And if a team already knows the tooling, that knowledge is worth more than any property of a transport. HORUS is not the answer in those cases and does not pretend to be: it hands you no navigation, no mapping and no driver library, it is validated in simulation rather than across a fleet of deployed machines, and replacing a working stack to gain something you cannot yet describe is a good way to lose a quarter.

Will a better model eventually remove the need for control code?

No, and here is why: the control code is not there because the model is insufficiently clever. It is there because something has to be on time, every time, with a bounded worst case, and that requirement does not soften as language models improve. A perfect planner still needs something running continuously that holds the joint limit, notices the person who walked into the workspace between one decision and the next, and brings the machine to a stop when a reading stops arriving. Those are not decisions in the sense a model makes decisions; they are guarantees, which are properties of code you can reason about. The robot must also behave when the model is unreachable. A brilliant driving instructor in the passenger seat does not remove the need for brakes. What better models do change is how much of your skill list you have to write and how forgiving the phrasing can be, which is a real improvement and a different one.

Is this just prompt engineering with extra steps?

Partly, but not the way you think. The prompt matters, and describing the situation clearly is most of the battle. What that leaves out is that the engineering lives in the skill list, not the wording: the vocabulary you hand the model determines what it can ask for, and a well-designed vocabulary makes an ordinary model behave while a careless one defeats an excellent model. A good skill is a verb with stated preconditions and a defined end state, and it refuses rather than improvises when those preconditions do not hold. A "pick up" that returns an error because nothing matching the description is visible is worth more than any amount of prompt tuning. Design that interface as you would design an API for a confident client who is occasionally wrong, because that is exactly what you have. The model then becomes a component you can swap rather than the thing your robot depends on.

What does this look like when it goes wrong?

It looks like the robot doing something confidently wrong while nothing crashes and nothing logs an error. The classic version: the model names an object that is not in the room, the skill takes the closest match, and the arm goes for a stapler because you asked for something blue. Another: the plan is sensible as language and impossible as physics, like putting an item into a drawer that a later step was going to open. The one that catches software engineers hardest is staleness. The model receives a description of the scene, thinks, returns a plan, and by then somebody has moved the cup, so the robot acts correctly on a world that no longer exists. Nothing is broken in that failure; the data was simply older than anyone assumed. This is the same class of problem behind robots that behave differently from run to run, and the defence is the same: skills that re-check what they are about to touch instead of trusting the plan that named it.

How do I decide whether to add a language model at all?

Start by naming who is going to speak to this robot, because that single answer decides most of it. If the answer is "me and two colleagues", you probably want a better command line rather than a model, and you will get there faster. If the answer is "people who will never read a manual", a language layer is worth real effort, because free phrasing is the product feature. Then check whether you have anything for a model to compose: three or more skills that each end in a known state and that you would trust a stranger to trigger. If not, build those first, because a planner cannot arrange capabilities that do not exist and you will misdiagnose missing skills as a bad model. Finally, write down what happens when the model is wrong, slow or unreachable, before you connect anything. If you cannot answer that, keep the model in your editor writing code you review. If the whole field is new to you, the roadmap into robotics from software is a better starting point.

Take the line that matches your situation:

• If you are a hobbyist whose robot already does three things -> a cloud model above your skills, because the composing is the fun part and the stakes are a knocked-over cup.
• If strangers will instruct your machine -> a narrow instruction set with a model interpreting phrasing, because open-ended language is a support burden you carry forever.
• If your drivers and navigation already work on ROS 2 -> stay there and add an agent bridge, because your hard problems are solved already.
• If you are one person with one machine and a loop that must not be late -> keep the model out of that loop, because timing is not a model problem.
• If nobody but you will ever instruct the robot -> no language layer, because a short command list is quicker to use and easier to trust.

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 arrangement on all five, and the axis you cannot compromise on decides it.

Whichever layer you put the model in, something underneath it still has to be on time. When you reach that part, HORUS is open source under Apache-2.0 at github.com/softmata/horus. Star it so it is in your list when you start building.