What Is Physical AI? A 2026 Explainer

Physical AI is industry's name for machines that sense, decide and move in the real world, and it describes a stack rather than an algorithm. The parts are ordinary — a model, a machine, and middleware such as ROS 2 or HORUS carrying readings and commands — so the label tells you nothing about what to build. The word matters when a vendor attaches it to a product you must buy whole. This post is for someone who trains models and now has to make a real machine act on them without a detour through vocabulary.

Every keynote this year is about physical AI. A chip launch says the next decade belongs to it. A funding announcement uses the phrase four times without ever saying what the software does. Your manager forwards the video and asks whether the team should be doing this, and you cannot answer, because you cannot tell whether physical AI is a research direction, a product category, or a way of saying robots to an audience that finds robots boring.

Underneath the vocabulary sits something more practical. You have a model that behaves. Someone bolts a camera to a frame with two motors, and the machine moves in a way that makes the room go quiet. There is a pause before the gripper closes. There is a lurch whenever the camera code is busy. The same script gives a different result on the second run and nobody can say which part changed.

So you are trying to answer two questions at once. Whether the word means anything. And whether you are about to spend a quarter rediscovering something the robotics people already have a name for.

Does calling your project physical AI change what you should build?

No, the phrase changes who is listening rather than what you build. Physical AI is a positioning term: it groups the model, the machine, the chip and the simulator into one story that can be sold, funded or put on a stage. Underneath the story, the engineering decisions are the ones robotics teams have been making for decades. Something reads a sensor. Something decides. Something drives a motor. Something has to carry readings and commands between those parts while the decision still applies. Where the phrase does change something is procurement. When a vendor says physical AI, they often mean one bundled stack — their chip, their simulator, their runtime, their tools — and adopting the word can quietly mean adopting the bundle, including the parts you would rather swap out in a year. Treat the term as a question rather than an answer. Ask which layer the person using it actually sells, and one sentence will usually teach you more than the whole talk did.

What is physical AI in plain terms?

Physical AI means a model whose output moves something, and that single change carries most of the difficulty with it. A classifier that answers late gives the same answer slightly later, and nobody is harmed. A policy that answers late gives a correction aimed at where the arm used to be, and the arm has moved on. Lateness here is not a milder form of correctness; it is a different answer. Two other things change at the same time. The input never stops arriving: a camera produces frames whether or not anything is ready to read them, and nothing waits for your process the way a test set waits. And mistakes leave marks, because a misclassified image is a row in a table while a misjudged grasp is a cup on the floor and possibly a bent finger, which changes how freely you are willing to experiment. Taken together, physical AI is less about larger models than about a system that keeps its promises on a rhythm. For the vocabulary itself, the difference between embodied AI and physical AI covers who uses which word and why.

What are your actual options for putting a model on a machine?

There are about seven realistic options, and most teams pass through two or three of them in order. You can write one Python program that reads the sensor, runs the model and commands the motors, which is where nearly everyone starts. You can lean on the robot vendor's own kit, usually the fastest route on a complete arm or mobile base. You can adopt ROS 2, the large open ecosystem where drivers, mapping, navigation and visualisation already exist and your model 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 holding the model and a C++ process driving the motors exchange messages on one computer without serialising them between processes. You can keep the model on a workstation and talk to the robot over the network. Or you can build the plumbing yourself. Read the table as a description of situations rather than a ranking.

Which option fits someone who trains models but has never shipped hardware?

Start with one Python program and the vendor's kit, because your first job is finding out which problems you actually have. An engineer arriving from modelling work has an accurate map of one half of the system and almost none of the other, and the fastest way to draw the missing half is to make a real machine move badly and watch how it fails. That takes days rather than months, and it turns a vague worry into a list of named problems. What you should not do is adopt a large framework in week one because it looks like what professionals use. You will spend a fortnight on workspaces and build tooling, learn nothing about your robot, and conclude that robotics is mostly paperwork. The moment to graduate is specific: it arrives when one program can no longer hold both jobs, because the model wants to think for as long as it needs while the motors want an answer on a fixed rhythm. That is the day a middleware earns its keep, and it is worth recognising the day when it comes rather than a quarter later.

What should you run on the small computer that rides on the robot?

Keep every process on that one computer and stop copying large data between them, because copying is what a small board can least afford. A robot computer usually holds several jobs at once: pulling frames off a camera, running the model, keeping a control loop on its rhythm, and writing logs. When those jobs live in separate processes and every frame is packed up, sent and unpacked again, the board spends a large share of its attention moving bytes that never left the machine. That work is invisible in your code and extremely visible in the motion. The symptoms are ordinary. The arm hesitates when you raise the camera resolution. The fan runs constantly. Adding one more sensor makes an unrelated part of the system worse for no reason anyone can explain. This is the exact problem shared memory addresses, by letting one process write into a buffer that another process reads directly. If the board on your robot is the constraint, the software options for small computers and edge devices works through the choice in more detail.

What if you have one quarter to show a machine doing something?

Pick whatever requires you to learn nothing new, and be honest that you are building a demo rather than a product. A quarter is not enough time to learn an ecosystem and debug a machine at once, so the vendor's kit plus a single Python program is usually right, even knowing it will not survive contact with the second robot. Demos are won by machines that do one thing convincingly, not by well-organised machines that do nothing yet. What matters is being clear about the debt you are taking on. A demo built this way tends to have the model, the hardware calls and the safety checks tangled in one file, sequenced by luck rather than design, and it will work on one table under one set of lights. That is fine for a quarter and ruinous for a year. Decide now which parts you intend to throw away, write those parts carelessly on purpose, and keep the boundary between the model and the machine clean enough that you can replace everything on the machine side later without touching the model.

What if nobody on the team has written a control loop?

Assume the hard part will not be the model, and plan the team around that assumption. A group of strong modelling engineers with no robot experience reliably underestimates the same four things: how much time drivers and calibration eat, how differently a machine behaves on a cold morning, how much of the code is deciding what to do when a reading is missing, and how long it takes to reproduce a failure that happened once. None of that is intellectually hard. All of it is slow, and none of it appears in the paper you are implementing. Two moves help more than any framework choice. First, give one person ownership of the machine itself — wiring, mounting, power — because a team where nobody owns the hardware loses days to problems that were never software. Second, learn what a loop that runs on a rhythm is before arguing about which language it should be in, since the shared vocabulary shortens every later conversation. What a control loop is and why its timing matters is the shortest useful version of that.

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

Almost every team starts with one Python process doing everything, and it stops working the day two parts of the robot need different rhythms. The single-process design is genuinely correct at the start: easy to reason about, easy to restart, and nothing can arrive out of order because nothing runs at the same time. The failure is gradual and specific. The model takes as long as it takes, and while the model is thinking, the code that keeps the wheels straight is not running. You see that as a machine which behaves nicely until the interesting thing happens and then lurches at exactly the wrong moment. The usual next move is to split the model into its own process, which cures the lurching and introduces a new problem, because now every camera frame has to get from one process to the other. Teams then discover that packing and unpacking images is not free, that a queue somewhere is filling up, and that the oldest frame in that queue is the one being acted on. That is the point where the middleware question stops being theoretical.

What does it look like when the model is right and the machine is still wrong?

It looks like a machine making sensible decisions at the wrong moments, which is far harder to diagnose than a machine making bad decisions. The tell is that your logs look fine. The chosen action suits the scene the model was given, the scene was real, and the gripper still closed on air. What happened is that the frame was already stale when the model saw it, or the command landed after the moment it suited. A second signature is inconsistency: the same task succeeds and fails on alternating attempts with nothing changed, because the ordering of events differs slightly each run. A third is that adding a harmless-looking log line changes the behaviour, which should always alarm you, because it means correctness depends on how long things take. None of these are model problems, and no amount of retraining touches them. Teams lose months here by tuning weights against a plumbing fault, which is why it is worth learning the signature once and recognising it immediately the next time a machine hesitates.

What do you give up by choosing a smaller foundation?

You give up other people's code, other people's tools and the hiring pool, and those three things are worth more than newcomers expect. The ecosystem is the product: drivers for hardware you have not bought yet, mapping and navigation representing years of work, a visualiser that shows what the robot believes about the world, and recording tools that let you replay a bad run at your desk instead of chasing it around a table. 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 hiring and when asking a question in public, because a problem described in common terms gets answered while the same problem described in your own terms does not. Weigh maturity honestly too: the leaner options above are younger, several are validated in simulation rather than by a decade of deployed fleets, and a smaller project means fewer people have already hit the bug you are about to hit.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the robot needs software that already exists, which is more often than people arriving from modelling work expect. A machine that must map a building and drive to a goal is a ROS 2 project, because navigation and mapping stacks represent work you cannot reproduce alongside your actual research. An arm doing collision-aware planning is one for the same reason. If the sensor you bought ships one usable driver and that driver is a ROS 2 package, the decision has already been made for you. If the system spans a robot, a workstation and eventually a fleet of machines in a building, ROS 2 was designed for that shape and is well travelled there. And if you work somewhere everyone already speaks it, the shared vocabulary beats any technical argument, because your colleagues can actually help you. HORUS is not the answer in those situations, and choosing it there means rebuilding plumbing that already exists in order to lose the packages that were the point of the project.

Is physical AI just robotics with a new label?

Partly, but not the way you think. The mechanics are old: sensors, loops, actuators, and the discipline of deciding what to do when a reading does not arrive. Robotics has done all of that for decades and the physical AI branding does not change any of it. What genuinely shifted is where the decision comes from. Classical robot software was written as rules a person could read: if the reading exceeds this, stop; if the goal is there, plan a path to it. A learned policy is a large opaque function that answers in roughly the same time every time, and cannot be inspected line by line when it makes a strange choice. That changes testing more than it changes plumbing. You cannot prove correctness by reading the code, so you lean on the behaviour around the model instead — the checks that catch an implausible command, the safe stop when a reading is missing, the recorded run you can replay. The old skills still apply. The new part is that the interesting component is no longer readable.

Will a large foundation model remove the need for middleware?

No, and here is why: a model decides what to do, and something else still has to make the decision arrive in time. A larger and more capable model does not read the camera, does not drive the motor, and does not notice when a sensor stops answering. Those jobs belong to the software around it, and they do not shrink as the model grows — if anything, a heavier model makes the timing question sharper, because the surrounding system has less room to be careless while the model thinks. There is a second reason. A model that answers in roughly the same time every time is a gift to a robot, but only if the answer can travel from wherever the model runs to wherever the motors are without being copied and repacked at every step. That path is the middleware's job, whether it comes from ROS 2, from a leaner foundation, or from code your team writes and then maintains forever. Why a capable language model still cannot pick up a cup works through the same gap from the model's side.

How do you tell which problem you actually have?

Log what the machine decided alongside when it acted, and read the two columns together, because that one comparison separates almost every category of failure. If the decisions are sensible and the actions land after the moment they suited, you have a delivery problem, and retraining will not help. If the decisions themselves are wrong for the scene, you have a model problem and the plumbing is fine. If decisions and timing both look reasonable and the machine still misbehaves, look at what your code does when a reading is absent, because that path is the least tested part of most robots. And if the answer changes run to run, the ordering of events is not under your control, which is a scheduling question rather than either of the others. Do this before choosing a foundation rather than after. A team that adopts a large framework to cure a problem they never identified usually finds the problem still there afterwards, now wrapped in tooling nobody on the team knows how to debug.

Decide by situation rather than by vocabulary:

• If you are putting a policy on hardware for the first time -> one Python program plus the vendor's kit, because you need to find out what actually breaks.
• If the robot must map a building or plan around obstacles -> ROS 2, because that code exists and you will not reproduce it.
• If your model is Python and your control loop is compiled, both on one computer -> a shared-memory middleware, because copying frames between them is where your time goes.
• If the model is too large for the robot's computer -> a policy server, plus a local behaviour that keeps the machine safe when the link stalls.
• If a demo must exist next month -> the shortest path you already know, and write the throwaway parts as throwaway on purpose.

When the foundation question arrives, weigh it on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target and licence. No scores, 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 a Python model and a compiled control loop, star HORUS on GitHub so it is in your list when you start building.