Robot Foundation Model Companies Worth Watching in 2026

Watch the companies publishing downloadable weights — Physical Intelligence, Nvidia and Google DeepMind — rather than the ones with the most convincing videos. A company you can download from changes what you build this month; one you can only watch changes nothing until hardware ships. That flips if your platform vendor supplies the policy, leaving ROS 2 or HORUS beneath as your only real choice. The rest of this post is for someone tracking this field who has to turn a list of company names into a decision about what to build.

You have watched the videos. A humanoid folds a shirt, sorts a bin, hands somebody a cup, and the caption says the robot was told to do it in plain English. Something real is happening and you would like to be near it.

Then you try to work out what any of it means for you. One company has published weights and a paper. Another has raised an enormous round and shows a new video every few weeks with no way to reproduce anything. A third sells a robot you could buy, running a policy you cannot inspect. A fourth was quietly absorbed into a larger company and its model went with it. The lists you find rank them by valuation, which tells you who investors believe and nothing about whether you can build on any of it.

Meanwhile the practical questions pile up. If you downloaded a policy tomorrow, would it work with your arm, your gripper, your camera on a different mount? What has to exist underneath before a downloaded policy is allowed near a motor? And which of these names will still exist when your product ships?

Which robot foundation model companies are worth watching in 2026?

Watch by what a company releases, not by what a company demonstrates. Three groups are worth your attention, and they are worth it for different reasons. The first is the labs that publish weights and training code for general manipulation policies — Physical Intelligence and Nvidia are the clearest examples, with Google DeepMind releasing selectively and running a trusted-tester programme around the rest. These change your options immediately, because a published checkpoint is something you can fine-tune on your own demonstrations. The second group builds humanoids and keeps the model private: Figure, 1X, Tesla, Agility, Skild. Watch these for where the field is heading and for hardware you might eventually buy, but do not plan a quarter around anything they show. The third group is the platform vendors whose robots you can actually purchase, Unitree being the obvious one, where the interesting question is what the SDK exposes rather than what the model can do. Verify all of this before betting on it — this field reorganises itself faster than any published list survives.

What is a robot foundation model, in plain terms?

A robot foundation model is a single trained model that takes camera images and an instruction and produces robot motion, across many tasks rather than one. That last clause is the entire claim. Older robot learning produced one policy per task: a model that could stack blocks knew nothing about wiping a table. A foundation model is trained on recorded behaviour from many robots doing many things, in the hope that a new task described in words lands close enough to something in that experience to work without fresh training. The comparison with language models is fair in structure and misleading in supply. Text is abundant and free on the internet; robot demonstrations exist only because somebody moved a real arm and recorded it. That is why the interesting differences between these companies are usually about data collection — teleoperation fleets, wearable capture rigs, simulation at scale — rather than architecture. A fuller explanation of the term is worth reading before comparing any two companies on capability.

What are your real options if you want to build on any of this?

You have eight options, and most working projects combine three or four rather than choosing one. ROS 2 is the foundation for nearly everything below the model: drivers, transforms, motion planning, navigation and the recording tools that let you explain a failure after it happened, all with an ecosystem where somebody has already met your error. HORUS, an open-source real-time robotics middleware for Rust, Python and C++, addresses a narrower situation — one machine where a Python process holding a policy and a C++ or Rust control loop share the same shared-memory ring buffers rather than copying pictures between processes. Above that sit your choices about the model itself: a published checkpoint you fine-tune, a hosted model from a large provider, a vendor's own stack on a robot you bought, or your own demonstrations through a learning library. A simulator and a set of hand-written skills round out what real projects contain. Read the table as situations rather than as a ranking.

Which companies matter if you are one developer without a robot?

Only the ones that publish something you can run today, which narrows the list considerably. Without hardware, a private model is entertainment: you cannot fine-tune it, cannot measure it, and cannot tell from a video whether the robot was teleoperated, scripted, or autonomous with fifty takes on the cutting-room floor. What you can do is download a published policy, load a released robot model into a simulator, and watch the policy attempt a task you invent. That single exercise teaches more than a month of announcements, because you discover immediately how narrow the behaviour is and how much depends on the camera being where the training data expects. The second useful move is to follow the data side rather than the model side, since the bottleneck in this field is demonstrations and the companies solving collection are the ones whose results will keep improving. If you want hardware eventually, the platforms that are actually open to developers is a more useful list than any ranking by funding.

What hardware do you need to run anything these companies release?

You need a machine with an accelerator for the policy and a separate, uninterrupted path for the control loop. Published policies vary enormously in appetite: some compact ones will run on a well-specified robot computer with an accelerator attached, and the largest will not fit on anything you would bolt to a robot. Fine-tuning is a different machine again, and belongs on a desktop or a rented box rather than on the robot. The part people underestimate is not the model hardware but the reservation: whatever runs the joints must keep its rhythm while the policy is thinking, which means the control loop needs a core nothing else is allowed to disturb and code that does not pause at unpredictable moments. On a single-board robot, this is where the copying problem shows up, with a policy process and a control process on one machine passing images back and forth as though they were on separate computers. Test the arrangement by unplugging the network mid-task and watching what the robot does next.

How long before any of this is usable in something you ship?

Fine-tuning a published policy for one narrow task on your own hardware is a matter of weeks; a product whose behaviour comes from a general model is not close. The weeks-scale version is real and worth doing: pick one task, collect demonstrations on the exact arm and gripper you will ship, fine-tune, and you will have something that works in your workspace and nowhere else. That is a useful capability and a fair way to learn what the technology does. The product version is further away because the failures that matter are not the ones a model fixes. A customer cares that the robot never crushes the thing it is holding, always stops when someone walks in, and does the same thing on Friday as it did on Monday. Those properties come from the layer underneath, and no announcement changes them. Plan on a general policy handling the variable middle of a task while hand-written code owns the beginning, the end and every refusal.

What do you need to understand to follow this field usefully?

You need to know what the training data contained, because that single fact predicts more than any other detail about a released model. Four habits separate useful watching from consuming marketing. First, ask what robot the demonstrations came from, since a policy trained on one arm with parallel jaws has learned that arm's reach and that gripper's shape. Second, ask whether the video shows one take or a representative one, because these are enormously different claims and the caption rarely distinguishes them. Third, ask whether a person was in the loop, since teleoperation and autonomy look identical from outside. Fourth, ask what the robot does when the model is wrong, which is the question that separates a demonstration from a machine. None of this requires understanding the architecture, and understanding the architecture will not substitute for it. Why data rather than model design is the bottleneck is the single most clarifying thing to read in this area.

What does a foundation-model robot look like when it goes wrong?

It looks confident and slightly wrong, which is far harder to handle than an obvious failure. The arm reaches for the mug, closes a fraction early, and carries a closed gripper to the destination as though it were holding something. Nothing errored. The policy produced a plausible motion for a world in which the grasp succeeded, and no part of the model is responsible for checking whether the world agreed. A second signature is drift with conditions: the robot works in morning light and gets clumsy in the afternoon, because the training data came from one room with one set of lamps. A third is task boundaries — the policy performs the middle of a task well and has no clear idea when to stop, so it keeps wiping a table that is already clean. Every one of these needs the same answer, and it is not a better model. It is a skill layer that checks the result, a force limit that notices an empty grasp, and something that ends the task on a condition rather than on a feeling.

What do teams try first with a released policy, and why does it stop working?

Almost everyone downloads a policy, points it at their own arm, and expects the video. What arrives instead is motion that looks approximately right and succeeds occasionally, which is more discouraging than outright failure because it suggests the fix is small. It usually is not. The camera sits somewhere the training data never saw, the gripper is a different width, the table is a different height, and the policy is quietly extrapolating in all three at once. The second attempt collects a handful of demonstrations and fine-tunes, which helps enough to be encouraging and not enough to ship, because a handful of demonstrations covers the successful path and none of the recoveries. The third attempt collects demonstrations that include failures and recoveries, which is when results start to hold. The pattern is consistent across teams: the work is in the data, on your hardware, including the parts where things go wrong. Budget for collection sessions, not for training runs.

What do you give up by betting on one company's model?

You give up control over the thing your product's behaviour depends on. A private hosted model can change under you: the new version is better on average and different in the specific case your customer relies on, and you will find out from a support ticket. Terms change, pricing changes, access tiers change, and a company that pivots takes its model with it. A downloaded checkpoint avoids most of that and costs you the improvements, since you are frozen at whatever you fine-tuned unless you repeat the work. Betting on a vendor's whole stack goes further: the model, the hardware and the interface arrive together, and the exit from any one of them is an exit from all three. There is also a subtler cost. Building above someone else's policy means your team learns to prompt and fine-tune rather than to characterise and constrain, and the second skill is what makes a robot shippable. Keep the layer beneath the model yours regardless of which model you choose.

When is ROS 2 the better choice?

ROS 2 is the better choice for most robots being built right now, and HORUS is not the answer for any of them. If the robot navigates a building, ROS 2 hands you localisation, mapping and planning that many people have already driven into many walls on your behalf. If the arm must avoid its own body, motion planning is a package rather than a research problem. If you intend to use a published policy at all, the surrounding tooling — drivers for common arms, the recording formats the datasets use, the visualisation everyone else is looking at — assumes ROS 2, and stepping outside it means porting before you can start. If your team will grow, ROS 2 is a skill people arrive with. And if you are learning rather than shipping, ROS 2 is where the tutorials, the questions and the answers are. Choosing something leaner buys you a smaller machine and costs you the accumulated work that makes any of this approachable.

Will one of these companies eventually make the rest of the stack unnecessary?

No, and here is why: a model decides what should happen, and the stack decides whether anything happens on time and stops when it must. Those are different jobs, and being excellent at the first has never produced the second. A model has no clock. A model cannot notice that the command it produced now describes a robot that has already moved past the doorway, and cannot keep correcting a joint while composing its next decision. It cannot be the thing that refuses itself, because a component cannot be its own safety case, and the certification conversation for anything sold to a customer requires code somebody can read and reason about. Better models change the ratio of good decisions to bad ones, which matters enormously and changes nothing about timing or refusal. There is one place where progress genuinely removes work, and it deserves naming precisely: the branching task logic, the tree of conditions describing what to do when the shelf is empty or the door is shut. That part shrinks. The layer beneath does not.

Do the demo videos tell you what these robots can actually do?

Partly, but not the way you think. The videos are usually real in the narrow sense that the robot did the thing on camera, and misleading in every sense that matters to you. What the caption rarely states is how many attempts preceded the one you are watching, whether a person was steering any part of it, how much of the scene was arranged, and whether the same robot repeats the task in a room it has not seen. A demonstration answers can this happen. A product needs does this happen every time, and the gap between those two questions is where most of this industry currently lives. Watch for specific tells: an unedited take with a visible clock, a task performed in an obviously unstaged environment, a robot handed an object it was not expecting. When a company publishes weights, you can answer these questions yourself, which is the real argument for watching the labs that publish. What you are actually watching in robot demos is a useful habit to build before the next video.

How do you decide who to watch and what to build on?

Separate the two questions completely, because they have different answers and merging them is what wastes quarters. Who to watch is settled by release policy: follow the labs that publish weights closely, follow the humanoid companies loosely for direction and hardware, and follow your own platform vendor carefully because that vendor's decisions become your constraints. What to build on is settled by your robot, not by the field. If your machine navigates or manipulates, the foundation is ROS 2 and the model sits above it. If your machine is one board where a policy process and a control loop trade images continuously, you are choosing a shared-memory middleware for a reason that has nothing to do with any company on your watch list. Two checks resolve most arguments. If every model in this field vanished tomorrow, would your robot still do something a customer would pay for? And when the model is wrong — not if — what stops the arm? Answer those before you pick anybody's favourite.

Decide by situation rather than by enthusiasm:

• If you have no robot yet -> a simulator and a published policy, because that costs nothing and teaches you how narrow these models are.
• If you own an arm and one repeatable task -> fine-tune a published checkpoint on your own demonstrations, because generality is not your problem.
• If you bought a humanoid platform -> the vendor's stack for now, because the alternative is porting before you have learned anything.
• If your robot navigates or manipulates -> ROS 2 underneath whatever model you choose, because those packages are the project.
• If a policy process and a control loop share one board -> a shared-memory middleware, because copying is what makes the motion stutter.

When the foundation question becomes real, weigh candidates on the five axes of the HORUS Fit Framework — ecosystem size, setup effort, team size fit, deployment target and licence — and take the option that loses on the fewest, with no scoring involved. If your robot is becoming one machine running a policy beside a control loop, star HORUS on GitHub so it is in your list when you start building, and the open-source projects that sit under all of this is the companion to this list.