Humanoid, Android, Cobot: The Words People Mix Up

Humanoid, android and cobot describe three different things: a body shape, a human likeness, and a machine rated to work beside people. Only cobot carries a safety meaning with standards behind it, so mixing the words up costs money rather than pride. That flips if you are buying rather than building, because then the word on the datasheet decides what you are allowed to do. The rest is for someone choosing a machine and a foundation — a vendor kit, ROS 2 or HORUS — before the vocabulary costs them a quarter.

You have read the same three words in one week and they did not agree with each other. A press release calls a wheeled machine with two arms a humanoid. A conference talk calls a face on a stand an android. A factory integrator calls a single arm bolted to a bench a cobot and says it is safe to stand next to, and nobody explains what safe means there.

Then it starts costing you something. You write humanoid in a proposal and a reviewer asks for a safety case you did not know existed. You order a cobot expecting a machine that works alongside a person out of the box, and what arrives is an arm that stops when it touches something. Somebody on the team insists a robot dog counts as a humanoid, somebody else insists it does not, and the argument is really about which software problems the team is signing up for.

Underneath all of it sits a question nobody has answered plainly. Does the word change what you have to build, or is this just marketing dressed as a category?

Do these words change what you actually have to build?

One of the three changes what you build and two of them do not. Cobot is a claim about safety engineering: limited force, limited speed, a defined stopping behaviour, and a machine designed so a person can stand beside it without a fence. That claim comes with standards, with an assessment of your particular application, and with a vendor who has already done a large part of the work and will not let you undo it. It changes your legal position and it changes how much of the control layer you are permitted to touch. Humanoid and android are claims about shape and appearance. They change what your software has to cope with, but nobody certifies them and no rule follows from the label. A humanoid has many joints that must agree about the same instant, which is a real software problem, but the word humanoid did not create that problem — the joints did. So the practical rule is short. If someone says cobot, ask which standard and whose assessment. If someone says humanoid or android, ignore the word and ask how many things move.

What does each of the three words actually mean?

Humanoid means a machine built roughly to the human body plan, android means a humanoid built to look human, and cobot means an arm rated to work beside people without a fence. Humanoid is a bet about buildings. Doors, stairs, handles, shelf heights and hand tools were all designed around one body, so a machine with that body can in principle work in a place nobody modified. Legs are not part of the definition, and several machines sold as humanoids roll on a wheeled base with a torso, head and arms above the wheels. Android narrows humanoid down to appearance: a face that moves, skin, eyes that track you, a voice with the right timing. Most android work is about how people react to a machine, and it appears in research groups, receptions and film work rather than in factories. Cobot is short for collaborative robot, and the collaboration is about sharing space rather than about intelligence. A typical cobot is one arm on a bench doing the same task all day, and the interesting engineering is in how the arm behaves when something unexpected touches it.

What are your actual options for the software on one of these machines?

There are about eight realistic starting points, and which one suits you depends on how many things move rather than on which of the three words appears on the box. You can use the machine vendor's own software development kit, which is the fastest route on a humanoid or a quadruped and the only route on some. You can use a cobot vendor's programming environment, where the arm's controller owns motion and safety and you supply the task. You can adopt ROS 2, the large open ecosystem with drivers, navigation, planning and visualisation already written, where your code becomes one node among many. You can adopt HORUS, an open-source real-time robotics middleware for Rust, Python and C++ under Apache-2.0, where the three languages share the same shared-memory ring buffers so a Python process and a C++ process on one computer exchange messages without serialising them. You can write one program that does everything. You can build the plumbing yourself. Or you can stay in a simulator until hardware exists. Read the table as a set of situations rather than a ranking.

Which option fits a solo developer with a borrowed machine?

Start on the vendor's own software development kit even if you dislike it, because your first job is to find out what the machine actually does. A solo developer with borrowed or shared hardware has one scarce resource, uninterrupted time with the robot, and the worst way to spend it is on a build system. The vendor kit gets a limb moving on the first afternoon and gives you the honest answers no datasheet contains: how the joints report themselves, how long the machine takes to become ready, what happens when you ask for something impossible, and what the emergency stop does to your program while it is running. Write all of that down while you still have access. The graduation point is specific rather than vague. You move off the vendor kit when two things must run at once on different rhythms — a perception loop that thinks for as long as it needs, and a control loop that cannot wait for it. Until that day, extra machinery buys nothing. How to program a humanoid robot covers the first week in more detail.

What changes if your machine is a cobot arm rather than a full humanoid?

Almost everything gets easier, because a cobot vendor has already solved the part that makes humanoids hard. On a collaborative arm, the joint control, the safety monitoring and the stopping behaviour live inside the vendor's controller and are not yours to change. You send goals and read state. That is a far smaller software surface, and it means your project is really about perception, task logic and the gripper rather than about keeping a body upright. The trade is that you cannot reach in. If your idea needs the arm to behave in a way the controller does not offer, the answer is usually no, and no amount of clever code changes it. A humanoid inverts this. You typically get access to much more of the machine and you are responsible for much more of it: dozens of actuators, a balance loop that must never be late, and readings from every limb that have to describe the same instant. Humanoid robots versus robot arms is the fuller comparison, and the short version is that the arm is a project and the humanoid is a programme.

What if you have to show something working in two months?

Pick the option that requires you to learn nothing new, and be honest that you are building a demonstration rather than a product. Two months is not enough time to learn an ecosystem and debug a machine at the same time, so the vendor's kit plus a single program usually wins, even knowing the result will not survive contact with a second developer. Demonstrations are won by machines that do one thing convincingly on a known table under known lighting. What matters is naming the debt while you take it on. Code written this way tends to have perception, motion and the safety checks tangled together, sequenced by luck rather than design, and tuned to one room. That is acceptable for two months and ruinous for two years. Decide in advance which files you intend to throw away, and write those carelessly on purpose. The other trap is the demonstration that looks autonomous because somebody off camera is steering it, which is fine until a stakeholder asks for the same behaviour unattended. What you are actually watching in robot demos is worth reading before you promise a second version.

What if you have never written software that moves a machine?

Borrow or buy something small that moves before you touch a humanoid, because the habits you are missing cannot be read about. Someone arriving from ordinary software has an accurate map of half the system and none of the other half. The missing half is not mathematics. It is the habit of assuming a reading may be absent, the habit of asking what happens when a step takes longer than usual, the discipline of leaving the machine safe when a component stops answering, and the patience to calibrate a sensor again because somebody moved a bracket. Those arrive in weeks of contact with hardware and never arrive from documentation. A humanoid is a poor teacher for this, because it fails in expensive and alarming ways and you rarely get it to yourself for long. A small wheeled machine fails cheaply, on the floor, in front of you, over and over. Beginner robot kits for people who already code covers what to buy for that, and the point is not the kit. The point is owning something you are allowed to break.

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

Nearly everyone starts with one program driving the whole machine through the vendor's kit, and it stops working the day two parts of the robot need different rhythms. The single program is genuinely right at the start. Nothing arrives out of order because nothing runs at the same time, restarting is one command, and you can hold the whole thing in your head. The failure is gradual and specific. Perception takes as long as it takes, and while it is thinking, the code that keeps the body balanced or the path straight is not running. You see that as a machine which behaves well until the interesting thing happens and then lurches at exactly the wrong moment. The obvious fix is to split perception into its own process, which cures the lurch and introduces a new problem, because every camera frame now has to cross between processes. Teams then discover that packing and unpacking images is not free on a machine's own computer, that a queue is filling somewhere, and that the frame being acted on is the oldest one in it. That is when the foundation question stops being theoretical.

What does it look like when the wrong word costs real money?

It looks like a purchase order, a safety review or a hiring round going wrong months after the conversation that caused it. The most common version: a team writes cobot in a specification meaning a machine that works alongside people in general, and receives an arm rated to be touched that does exactly one task in one place. The second version: a team writes humanoid in a proposal, and a reviewer asks for a safety case, a fall analysis and a plan for what the machine does when a leg stops responding, none of which were budgeted. The third is quieter. Somebody watches an android talking fluently on a stage, concludes the hard part of the project is solved, and staffs the team for conversation work when the real difficulty is that the machine cannot reliably pick up a mug. The pattern repeats every time. The word travelled between people who meant different things by it, and nobody stopped to ask what actually moves and who is responsible for stopping it. Why humanoid demonstrations look better than humanoid products is the long form of that gap.

What do you give up by not building on ROS 2?

You give up other people's code, other people's tools and a hiring pool, and those three cost more than newcomers expect. The ecosystem is the product. Drivers exist for hardware you have not bought yet. Navigation and planning represent years of work you cannot reproduce next to your actual project. A visualiser shows what the machine believes about the world, and recording tools let you replay yesterday's bad run at your desk instead of chasing it on a bench with the robot powered up. Choosing a leaner foundation means doing without those or rebuilding them, and rebuilding a visualiser is a quarter nobody planned for. You also give up shared vocabulary, which matters when you hire and when you ask a question in public, because a problem described in common terms gets answered and the same problem described in your own terms does not. Weigh maturity honestly as well. The leaner options above are younger, several are validated in simulation rather than by years of deployed fleets, and a smaller project means fewer people have already met the bug you are about to meet. What software runs inside a humanoid robot shows how much of it is borrowed.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the machine needs software that already exists, and on human-shaped robots that is most of the time. A humanoid that must map a building and walk to a named place is a ROS 2 project, because mapping and navigation are years of work you will not reproduce alongside your real goal. An arm doing collision-aware planning is one for the same reason. If the sensor you bought ships exactly one usable driver and that driver is a ROS 2 package, the decision has been made for you. If the system spans a machine, a workstation and eventually a fleet, ROS 2 was designed for that shape and is well travelled there. If your lab or company already speaks it, that beats any technical argument, because a colleague can help you at four in the afternoon and a mailing list cannot. HORUS is not the answer in those cases, and choosing it there means rebuilding plumbing that already exists in order to lose the packages that were the reason for the project. Do humanoid robots run ROS 2 covers what the vendors actually ship today.

Is an android just a humanoid with a better face?

No, and here is why: the face is a separate engineering project with its own failure modes, and it competes for the same budget. A humanoid's hard problems are mechanical and temporal — many joints, a balance loop that cannot be late, and readings from every limb that must describe the same instant. An android's hard problems are perceptual and social. Skin has to move without looking dead, eyes have to land on a person at the right moment, a voice has to arrive without an awkward pause, and each of those is judged by a human being who will not be able to tell you why the result feels wrong. The two skill sets barely overlap. A team that can make a machine step over a cable is not thereby a team that can make a face believable, and the reverse holds even more strongly. There is also a trap in between. Appearance raises expectations about behaviour, so a machine that looks human is judged far more harshly for a clumsy grasp than the same machine wearing an obvious shell.

Does calling a machine a cobot mean it is safe to stand next to?

Partly, but not the way you think. The rating applies to the arm, and safety applies to the whole application. A collaborative arm is built to limit the force it can apply, to slow down when a person approaches, and to stop when it meets something unexpected, and that is real engineering rather than a marketing word. What it does not do is make your cell safe. Put a blade in the gripper and the force limit stops mattering. Put a heavy payload on the end and the arm's gentleness matters less than what the payload is carrying. Mount the arm so a hand can be trapped between it and a bench and you have built a pinch point that no rating covers. This is why an assessment is done on the application rather than on the machine, and why an integrator will ask what the arm is holding before answering any question about fences. Treat cobot as a statement about what the arm can do to you when it goes wrong, not as permission to skip the assessment.

How do you work out which of these you are actually building?

Count what moves, then ask who is responsible for stopping it, because those two answers decide everything the labels do not. If one thing moves and a vendor controller owns its safety, you are building a cobot application, and your work is perception, task logic and the gripper. If many things move and you own the balance, you are building a humanoid programme, and most of your time will go into keeping readings and commands agreeing about the same instant. If the interesting part is how people react to the machine, you are building an android, and your risks are perceptual rather than temporal. The second question is where your time is currently going. If it goes into borrowed packages and integration, your foundation should be the one with the packages in it. If it goes into moving large data between a Python process and a compiled one on a single computer, your foundation question is about how those processes share memory. Make that call before adopting anything, because a team that adopts a framework to fix an unnamed problem usually finds the problem intact afterwards, wrapped in unfamiliar tooling. Best middleware for humanoid projects narrows it further.

Decide by what moves, not by what it is called:

• If one arm moves and a person works beside it -> a cobot and its vendor environment, because the safety work is done and you cannot redo it cheaply.
• If you need mapping, planning or borrowed drivers -> ROS 2, because that code exists and a quarter of your time will not reproduce it.
• If dozens of joints move and you own the balance -> the machine vendor's kit first, then a message layer once two loops need different rhythms.
• If appearance is the product -> an android project staffed with interaction people rather than a locomotion team.
• If nothing exists yet and hardware is months away -> a simulator, and spend the time on model formats you will keep.

When the foundation question does arrive, weigh it on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. No scores and no league table, just the option that loses on the fewest axes for the machine in front of you. If your project keeps landing on one computer with Python perception, a compiled control loop and a growing suspicion that the boundary between them is where your time disappears, star HORUS on GitHub so it is in your list when you start building.