Embodied AI vs Embedded AI: Two Words, Two Fields

Embedded AI is about making a model fit on small hardware; embodied AI is about making a model act safely through a body. They share a robot but fail differently: one by not fitting, the other by acting on a world that has already moved. Only a machine too slow to damage anything escapes the second problem, or the need for something like ROS 2 or HORUS underneath. The rest of this post is for people who build models and are now deciding what to run underneath one that moves something physical.

Your model works. It works on the recorded clips, it works when you hold the object up to the camera, and it worked well enough in the demo that somebody asked whether it could run on the machine itself.

So you put it on the machine. The board is not your workstation. The model loads, the fan spins up, the case gets warm, and the answers start arriving late — not wrong, late. You quantise, you trim, you swap the backbone, and you get it back under control, and you assume the hard part is behind you.

Then you connect it to something that moves. Nothing throws an exception. The camera stops sending frames and your loop cheerfully reuses the last picture it saw. The gripper reports closed while holding nothing at all. The arm reaches for a cup that moved while the model was thinking, and no part of your stack treats any of this as an error, because there is no error to catch.

Then somebody asks what happens if a hand enters the workspace mid-reach, and you discover that you have a plan to write an answer rather than an answer.

Should you care which of the two labels describes your project?

Yes, because the two labels point at different halves of your calendar, and mistaking one for the other means you budget for the wrong work. An embedded problem is a fitting problem: the model is too large, too slow on this chip, or too hungry for the battery, and every fix is a fix to the model — quantise, prune, distil, pick a smaller backbone, push a layer onto the accelerator. An embodied problem is a structure problem: the model is fine and the machine still behaves badly, because the software around the model has no way to keep time, no way to notice stale data, and no way to stop. Teams that call an embodied problem an embedded one spend a quarter shrinking a model that was never the obstacle, then find the arm still lurches. Teams that call an embedded problem an embodied one build careful software around a model that will never load on the board. The cheapest thing you can do this week is decide which sentence describes your machine, because the two roads barely touch after the first fork.

What does embedded AI actually mean?

Embedded AI means running a model on the hardware inside the product rather than sending data somewhere else to be answered. The defining constraint is the device: a fixed amount of memory, a chip chosen for cost and power rather than for matrix multiplication, a network you cannot count on, and a thermal budget that a plastic case decides for you. Everything interesting about the field follows from that. You care about the size of the weights, the format they are stored in, whether the accelerator on the board supports the operations your architecture uses, and what happens to the answer rate once the case has been shut for an hour. The application need not move at all. A doorbell that recognises a face, a water meter that reads itself and a hearing aid that separates voices are all embedded AI, and none has a body in any useful sense. Success is a model that fits, answers quickly enough for the job, and keeps doing so when the device is warm. Nothing on that list involves motion, consequence, or timing between separate programs.

What does embodied AI actually mean?

Embodied AI means a model whose output becomes motion, in a world that carries on moving while the model is deciding. The defining constraint is not the chip but the consequence: an action changes the physical world, the change cannot be undone by calling the function again, and the scene the model looked at is already out of date by the time a motor responds to it. Sensing is continuous rather than a question and an answer. Failures are quiet, which is the part that catches people out — a frozen camera looks exactly like a still room, and a missing reading looks like nothing at all. A model can be sized perfectly for the board and still produce a machine that lurches, grabs where a cup used to be, or keeps pressing after contact. Success here is not a model that fits but a machine that behaves the same when nobody is standing next to it. That is a software structure question, and most model teams have never had to answer one. Embodied AI and robotics are not the same word twice, and the difference shows up in who you hire.

What are your actual options for running a model on a machine that moves?

You have eight realistic options, and they differ mostly in how many separate programs the machine runs and how much of it somebody else wrote. You can keep everything in one Python program on one board, which is where nearly every first attempt lands. You can buy a vendor robot and drive it through its own interface. You can leave the model on a workstation and send goals to the machine over a network. You can go the other way and put a small model on a microcontroller with no operating system underneath it. You can buy a finished platform and live inside the behaviour it exposes, or stay in simulation. Or you can accept that the machine is several programs that must agree on what is true right now, which is where middleware arrives: ROS 2 carries the largest body of existing robotics code anywhere, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ in which the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised. Neither of them runs your model. Read the table as descriptions of teams rather than a ranking.

What should you pick if you come from machine learning rather than robotics?

Buy a machine you did not build, drive it from the model you already have, and add structure only when the machine forces you to. Somebody arriving from model work brings one real advantage and one predictable trap. The advantage is genuine: data collection, evaluation and knowing when a result is fooling you are exactly the habits a robot will demand. The trap is assuming that everything below the model is plumbing. It is not plumbing, it is most of the calendar, and it is staffed differently. The specific shape of the failure is that the machine works while you are watching it, because you restart the script, you re-seat the cable, you nudge the object into frame and rerun. What you have not built is a machine that behaves the same when the room is empty. So keep your model work exactly as loose as it is today and be deliberate about one boundary only: the line between the program that decides and the program that moves. Get that line right early and you can swap models a hundred times without touching the machine underneath.

What hardware turns an embedded AI problem into an embodied one?

Anything that can move under its own power turns an embedded problem into an embodied one, no matter how small the device is. A camera bolted to a wall is embedded work forever. Put that same camera on a pan-tilt head and you now have a thing that can point at the wrong place, overshoot, and hunt back and forth around a target, and none of that is fixed by a better model. Weight and reach set the stakes. A desktop arm that cannot lift a full mug forgives months of bad software; a mobile base heavy enough to bruise a shin does not. Then there is the computer itself, and here the two fields collide directly: a model wants an accelerator and long uninterrupted runs, while a control loop wants to be left alone on a steady beat. Both on one small board is normal, and it is exactly where projects discover that thinking and moving are competing for the same machine. The tell is a robot that glides smoothly until the model is asked a question, then hesitates mid-reach. Small boards make the collision sharper.

What can you finish in a quarter, and what needs a year?

A quarter is enough to make a model drive a machine while somebody watches; a year is what it takes for the same machine to run unattended. Those are two different products and confusing them wrecks more schedules than any technical choice. The quarter version is worth doing: a vendor arm or a small base with a supported interface, one program that reads a camera and sends commands, a physical stop within reach of whoever is standing there, and a demonstration that mostly works with a person ready to intervene. The year version is where the quiet parts live — what happens when a sensor stops reporting, what happens when the machine is started cold by somebody who was not there when it was built, what happens on the two hundredth cycle rather than the fourth. If your deadline is a demonstration, spend week one getting hardware you can physically hold and week two making the machine move with no model involved at all. Choosing a framework in week one and learning its build system in week two is how demonstrations arrive having never picked anything up.

What if you have never written code that talks to a motor?

Write one small loop that runs on a rhythm before your model needs one, because the idea takes an afternoon to learn and discovering it the hard way takes months. A control loop reads where things are, works out the difference from where they should be, sends a correction, waits, and repeats on a beat. The loop must hold that beat while the rest of the machine is busy, so it cannot wait on a file being written or a model finishing a thought. The pattern that works is a division of labour: the model publishes a goal now and then, and a loop underneath drives smoothly towards whatever the most recent goal happens to be. A machine built that way moves like a machine. A machine whose motors receive commands only when inference happens to finish moves like something being dragged. The second thing worth learning early is that data can be stale rather than absent, so every reading needs a timestamp and every consumer needs an opinion about how old is too old. The timing side of a control loop repays reading before you need it.

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

Almost everyone starts with one program that reads the camera, runs the model and commands the motors in a single sequence, and it stops working as soon as any of those three takes a variable amount of time. The single loop is the right first move: easy to write, easy to debug, and it proves the pieces talk to each other. It breaks in a predictable order. First the motion gets uneven, because the loop now runs at whatever speed the slowest step allows. Then somebody adds a second camera and the arm slows down for reasons that have nothing to do with the arm. Then a driver blocks for a moment and the whole machine holds its breath. The instinct at that point is threads, which solve the rhythm and create a new problem: everything shares one crash and one memory space, so a driver that dies takes the safety logic with it. The next step is separate programs, at which point you need them to share data without copying large frames back and forth, and that is the moment middleware stops being an abstract idea.

What do you give up when you build for a body instead of a board?

You give up the right to judge your system by how good the model is. That is a larger loss than it sounds, because model quality is measurable, improvable and satisfying, while the things that decide whether a robot works are none of those. You give up speed of iteration: a change that took a minute on recorded data now takes a walk to the bench, a power cycle and a reset of the scene. You give up clean failure: instead of a stack trace you get somebody saying it looked strange, and you get to work out whether that was the model, a dropped frame, a warm motor or the light through the window at four o'clock. You give up single-process simplicity, because the fix for uneven motion is more programs, not fewer. And you take on a duty that has no equivalent in model work: the machine has to be safe while it is wrong, for the entire long period during which it is frequently wrong. Nothing about a better checkpoint discharges that duty, and no evaluation score tells you whether you have met it.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever most of the robot's value is code that somebody else has already written. If the machine has to build a map, localise in it and drive to a goal, ROS 2 hands you that on day one and reimplementing it is a project rather than a task. The same goes for arm planning with collision checking, for a fleet talking to a control room, for cameras and lidars whose only maintained driver is a ROS package, and for anything a customer will audit against what the industry already does. ROS 2 is also the better choice for hiring: the pool of people who can walk in and be useful is far larger, and the tutorials, courses and forum answers already exist for the problem you are about to have. HORUS is not the answer in any of those cases, and pretending otherwise would cost you months. Choose ROS 2 when the ecosystem is the reason you are there, when several computers must agree over a network, or when you simply need to be conventional. Those are good reasons, not compromises.

Is embodied AI just embedded AI with wheels attached?

No, and here is why: the constraint that defines each field is different, so the two disciplines optimise for opposite things. Embedded work pushes toward doing less on the device — smaller weights, fewer operations, longer gaps between answers, everything shaved down until it fits inside a power budget. Embodied work pushes toward being answerable to the present moment, which usually means doing more on the device rather than less, because anything you send away comes back describing a world that has moved. An embedded engineer who succeeds ships a device that answers within budget while warm. An embodied engineer who succeeds ships a machine that stops when a person walks in, notices when a sensor goes quiet, and behaves the same on the thousandth cycle as the first. Put wheels under a well-built embedded product and you do not get a robot; you get a well-built embedded product that now has a way to hurt somebody. The skills overlap in exactly one place, which is that both live on hardware you cannot upgrade after shipping. Everything else diverges.

Will a bigger model fix an embodied system that keeps failing?

Partly, but not the way you think. Bigger models genuinely remove work, and they remove a specific kind: the hand-written behaviour in the middle of the stack. Perception pipelines that took a team a year now fall out of a checkpoint, and task sequencing that filled a state machine collapses into a policy. That trend will continue. What does not shrink is everything beneath the decision. A larger model does not read an encoder, does not decide what happens when frames stop arriving, does not hold a rhythm while it is thinking, and does not stop an arm when the cell door opens. If anything, a stronger model raises the demands on that layer, because a machine trusted to act on its own gets sent places a supervised machine never went, and the cost of a missed reading rises accordingly. There is a trap in the other direction too: teams reach for a bigger model when the fault was a stale frame or a loop starved of processor time, and no checkpoint fixes a timestamp nobody checked. Rule out the plumbing before you retrain.

How do you tell which of the two problems you actually have?

Replace the model with a fixed, hard-coded answer, run the machine anyway, and watch what still goes wrong. The test takes an afternoon and settles arguments that otherwise run a quarter. Command the arm to a stored pose on a loop, or drive the base along a fixed path, with no inference in the picture. If the motion is uneven, if the machine keeps going after a sensor dies, if starting the system in a different order changes the behaviour, or if there is no clean way to stop it, then your problems are structural and a better model will not touch a single one of them. Now the opposite test: run the model on a saved clip on the target board, case closed and machine warm, and see whether the answers still arrive in time. If they do not, the problem is embedded and the fix is in the model. Most real robots hand you both lists. The useful part is knowing which one you are working from this week, because the two ask for different people and different definitions of done.

Decide by the situation you are actually in:

• If the model will not load on the board you have chosen -> an embedded problem, because shrinking and quantising is the whole job and no middleware helps.
• If the model is fine and the machine still lurches -> an embodied problem, because the fix is structure rather than weights.
• If the robot must map a building, navigate it, or use drivers you did not write -> ROS 2, because the ecosystem is the reason to be there.
• If Python inference and a compiled control loop must share camera frames on one board -> a shared-memory middleware, because copying those frames between processes is the thing you are trying to stop.
• If the machine is slow, supervised and unable to damage anything -> one program, because structure you do not need is still structure you maintain.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Five honest questions about your situation rather than about the software, with no scores attached — take the option that loses on the fewest. If your project keeps landing on one machine with a model in Python and a control loop that must not wait for it, star HORUS on GitHub so it is in your list when you start building.