What "Autonomy" Actually Means in AI Robotics Marketing

In robotics marketing, autonomy usually means the robot finished a rehearsed task without a hand on it during the clip, not that the robot decided anything. The word stretches from staying upright to choosing what is worth doing, and companies quote the easiest rung while showing footage that implies the hardest. That changes when a vendor states what actually runs on board, which is also where the stack underneath, whether ROS 2, a vendor kit or HORUS, starts to matter. The rest of this post is for someone reading launch videos and datasheets who wants to know what was actually claimed.

The video says fully autonomous. The robot crosses the room, pulls a jumper out of a basket, and folds it, and there is no cable and nobody in the frame. In the comments somebody says there is an operator in a headset next door. Somebody else says that is nonsense. Neither offers a way to check.

Then you read the product page. The machine operates autonomously in unstructured environments and learns new tasks. You cannot tell whether learns means it learns in your building, or whether a team spends a month teaching it in theirs. You cannot tell whether unstructured means a real warehouse, or a warehouse where somebody placed the pallets carefully that morning.

The stakes are not academic. Somebody is deciding whether to buy one, take a job at the company, or build software on the platform. All three turn on the same question, which is what the machine does when nobody is watching, and every source available is written by a party with something to sell.

What does the word autonomy actually claim in a robotics launch video?

It claims that during the clip, nobody was touching the robot. That is the whole of the claim, and it is far smaller than the statement most viewers hear.

Four qualifiers are silently attached to it. This take, which may be one success out of many attempts, none of which are shown. This room, which was tidied, lit and arranged by people who knew what the robot needed. This task, which somebody spent weeks teaching the machine and which is the only thing it can do in that space. And this duration, which is as long as the clip and no longer, because the interesting question is what the tenth hour looks like, not the first minute.

None of that makes the footage dishonest. The motion happened. What misleads is narration describing a capability while the picture shows a rehearsal.

The honest way to read any such clip is as an upper bound. This is the best this machine has ever done, in the best conditions anyone could arrange for it. Teleoperation versus autonomy in demonstrations goes through the tells in more detail.

What are the levels of robot autonomy in plain terms?

There are five rungs, and one word is being used for all of them, which is exactly why the arguments never resolve.

The first rung is keeping itself intact: staying upright, not driving off a step, stopping when something enters its path. Solved, on board, and nobody films it any more.

The second is repeating a taught motion in a place that has not changed. Pick from here, place there. Reliable, boring, and the backbone of most machines actually earning money.

The third is completing a task despite variation. The box is at a different angle, the light is different, somebody left a cup on the shelf. This is where modern learned policies live, and where the ground starts moving under everybody's claims.

The fourth is noticing failure and recovering without a person. The jumper slipped, so try a different grip. Rare, and the honest edge of the field.

The fifth is deciding what is worth doing at all. Nobody has this. A robot that notices the room is untidy and starts on it does not exist outside narration.

What are your actual options if you want a robot to run unattended?

There are seven, and most deployments quietly combine two or three. You can keep a trained operator driving, which works today and costs a salary per machine. You can change the world instead of the robot, fixturing the environment so the hard variation never appears. You can build a classical stack that maps, plans and executes, which is what most mobile robots in real buildings run. You can train a learned policy from demonstrations, which handles contact and mess better and explains itself worse. You can buy a vendor's closed autonomy package and accept its edges. You can run supervised autonomy, where the machine works alone until it gets confused and asks a remote person. Or you can stay in simulation while the hardware market settles.

Underneath all of those sits plumbing, and that is where a middleware choice lives. Most teams use ROS 2, which brings drivers, coordinate frames, navigation and a large community. Some use a manufacturer's kit. A narrower option is HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between programs on one machine are not serialised. Apache-2.0, validated in simulation, and not an autonomy product.

How do the options compare side by side?

Read the last column first. Most projects are eliminated into an approach rather than persuaded into one, and the quickest route is noticing which rows your building and budget already rule out.

What should you take from an autonomy claim if you are buying rather than building?

Take the claim as a description of a best day and price the bad days yourself. A buyer is not purchasing the capability in the video; a buyer is purchasing whatever fraction of that capability survives a site nobody prepared, staff who did not build it, and a Tuesday when something is out of place.

Three questions cut through most of it. How many of these machines does one person supervise, and what does that person do all day? What happens when the robot gets confused, and how long does the site wait? And who is on site when something goes wrong at night?

The answers tell you which rung you are actually buying. A vendor who says one supervisor per fleet, with escalations arriving as a queue, is describing supervised autonomy honestly and is probably worth talking to. A vendor who cannot answer at all is selling you the video.

The other tell is a pilot's shape. A pilot in your building, with your mess, is a real offer. A pilot in a demonstration space is a longer video.

What hardware does a company imply when it calls a robot fully autonomous?

It implies a machine that carries its own computer, its own sensing, and enough power to do both for a working day. Those three are more constraining than they sound, and where a lot of quiet compromises live.

Onboard computation means an accelerator that draws real power and produces real heat, which is why the interesting spec on a mobile robot is not the processor but the battery and the cooling. Onboard sensing means cameras and often a lidar, mounted where they see the task rather than where they look good, which is a tension every industrial design meeting loses.

Then there is the part that never appears in marketing: a physical stop that cuts power without asking software, and enough mechanical margin that a mistake bends nothing. A machine designed to be autonomous is designed to fail safely, and you can tell how seriously a company takes unattended operation by whether the safety hardware looks bolted on for the photograph.

If a claim of autonomy comes with a tether or a laptop on a trolley, you are looking at a prototype.

How long does it take to turn a demonstrated task into unattended operation?

Far longer than the demonstration took, and the gap is where most robotics timelines die. Getting a robot to do a task once, in a prepared space, with the team watching, takes a competent group weeks. Getting the same task to run all day, with nobody watching, is a matter of seasons.

The reason is that unattended operation is not a harder version of the demonstration. It is a different problem, made almost entirely of things that were never in the demonstration. What happens when the object is not where it should be, when a person walks through, when the machine drops something and the floor has an obstacle nobody modelled, when the network is down and the part of the system that lives elsewhere stops answering.

Teams discover this in a predictable order: the task works, then the task works most days, then the exceptions eat the whole schedule. Anybody quoting you a timeline that does not have a long, vague stretch labelled hardening has not done this before.

What if you have no robotics background and only the marketing to go on?

You can still read these claims well, because the useful questions are not technical. You are not judging an algorithm; you are judging whether a company describes its own limits without being cornered into it.

Start with the language. Specific claims are a good sign: this machine moves totes between these two conveyors, at this site, with one supervisor for this many units. Broad claims are a warning: operates autonomously in unstructured environments, learns new tasks, understands your workflow. The second set is not false, it is unfalsifiable, which is the point of writing it that way.

Then look for figures about people rather than about the robot. Staff per machine, escalations per shift, time to recover from a stoppage. Deployed companies know these and will say them, because they are what their customers already argue about.

And watch what the video does not show: the walk to the workstation, the reset between attempts, the moment something goes wrong. Absence is information. Whether home humanoids are really autonomous applies the same reading to consumer machines.

What does it look like when an autonomy claim breaks on a real site?

It rarely looks like a dramatic failure. It looks like a machine standing still in an aisle while somebody goes to find the tablet.

The common shape is this. The robot works for the first week because everybody is careful around it and the site is unusually tidy. Then normal operations resume: a pallet half in the lane, a door propped open that the map says is shut, a shift that starts before the lights do. The robot handles most of it and stops for the rest, and each stop takes a person a few minutes plus the walk.

Those minutes are the whole economics. The machine that pays for itself and the machine that gets switched off differ mainly in how often somebody has to go and rescue it, and no demonstration measures this.

The second shape is quieter. Somebody notices the robot hesitates before the same corner every time. Often nothing about the autonomy changed, and something in the software underneath started arriving late. That failure gets blamed on the model and usually is not the model's fault.

What do you give up by taking an autonomy claim at face value?

You give up the ability to plan, which is worse than it sounds. A team that believes the machine is autonomous staffs for a machine that is autonomous, and then spends two quarters explaining why an operator, a supervisor and a maintenance slot appeared in a budget that had none.

You also give up leverage. Autonomy claims are easiest to interrogate before a contract, when the vendor wants the deal. Afterwards, the same questions become support tickets, and the answers get slower and more careful.

And you give up learning what is actually hard. Believing the demonstration means believing the difficult part is over, so teams invest in the wrong things: more machines rather than better exception handling, a bigger model rather than a site the existing model can cope with.

The alternative is not cynicism. It is asking what rung a claim sits on, and planning for that rung. Machines at rungs two and three are useful and worth buying. They are just not the machine in the narration, and the difference is a staffing plan.

When is ROS 2 the better choice?

Almost always, for anything that has to move around a real building. If a robot needs to navigate, if it carries a lidar, if it needs coordinate frames between a base and an arm and a camera, if you want visualisation and logging you did not write, ROS 2 is the right foundation and the argument is not close. The navigation stack alone represents work no small team should attempt from scratch.

ROS 2 is also correct when you will hire, when the project must outlive whoever started it, and when being able to use a driver somebody else wrote is worth more than owning every detail of how messages move.

HORUS is not the answer to any of that. There are no drivers, no navigation, no planners and no ecosystem of that size behind it, and it makes nothing autonomous. It is worth a look only in the narrow case where you already have a working behaviour, everything runs on one machine, and your own programs are getting in each other's way. If that is not your problem, ROS 2 is where to spend your attention.

Is every autonomy claim just marketing?

No, and here is why. A great deal of genuine autonomy already ships, and dismissing all of it is as inaccurate as believing the launch videos.

Warehouse robots move goods across large sites all day with nobody driving them. Vacuums map homes and cover them without instruction. Agricultural machines follow rows and adjust to terrain. Inspection drones fly routes and come back. None of those are marketing; they are rung two and rung three working properly, at scale, unglamorously, and they earn money.

What is marketing is the implication that these successes generalise. A machine that navigates a warehouse flawlessly is not close to tidying a kitchen, because the warehouse was designed around the robot and the kitchen was not. The gap is not effort or time; it is a different problem.

So the accurate posture is neither trust nor cynicism. It is asking which rung a specific claim occupies, in a specific place, for a specific task. Claims at rung two are usually true. Claims at rung five are always narration.

Does adding a language model make a robot autonomous?

Partly, but not the way you think. A language model genuinely adds something that was missing: the ability to take an instruction in ordinary words and break it into steps the rest of the system can act on. Before that, changing what a robot did meant changing code.

What a language model does not touch is the half that actually fails. Knowing that tidying means putting the mug in the sink is easy. Getting fingers around a wet handle at an angle that does not spill it, and noticing when it slips, is the hard part, and fluency contributes nothing to it.

The models that moved this field are trained on motion rather than text, taking images and an instruction and producing joint commands directly, with language as a component rather than the trick. That distinction is worked through in whether these models replace classic robot software.

So treat conversational ability as a better interface, which it is, and not as evidence of competence. A robot that discusses your kitchen well handles it no better.

How should you decide whether an autonomy claim matters to you?

Decide by naming the rung you need, then asking whether anything on sale reaches it without a person attached. If nothing does, you are not buying a product, you are joining a project, which is fine to choose deliberately and miserable to discover later.

• If you want a chore done at home -> wait, because no machine on sale removes a chore without somebody nearby.
• If you move goods on a site you control -> a classical navigation stack, because routes repeat and the building can be adapted.
• If you need the work done this quarter -> supervised autonomy, because a person per fleet is a cost you can actually plan.
• If you are writing software for somebody else's platform -> ROS 2, because the drivers, frames and community already exist.
• If the behaviour is fine and the machine still stutters -> look at how your programs pass data, because that fault sits below the autonomy.

The HORUS Fit Framework reduces that last decision to five things you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. For anything shipping to a customer, deployment target and licence usually decide it, because somebody will eventually ask what you are allowed to sell.

The week your demonstration works and the real machine hesitates is a bad week to start reading about the layer underneath. Put HORUS on the shelf before then: star it so it is in your list when you start building.