If you wanted to build a humanoid robot from scratch in 2026, the strangest thing about the project is how little of it would be invention. The actuators are catalog items. The simulation environments are open source. The base policies are downloadable. The vision-language-action models are checkpoints on Hugging Face. What is left is the integration, which is the part nobody wants to write a paper about, and which is the part most homebrewed humanoids actually die of. This is a tour of what is on the shelf, what the three stacks look like in mid-2026, and the one decision that should be made before any of them are wired up.
The threshold was crossed sometime between the release of Google's RT-2 in mid-2023 and Physical Intelligence's π0 in late 2024: vision-language-action (VLA) models that take camera images and a language instruction and output joint trajectories, trained on internet-scale vision-language data plus tens of thousands of hours of robot trajectories, started generalising to objects they had never seen. π0 could fold laundry it had never met. Its successor π0.5 extended the trick to whole rooms: feed it a video of a tidy kitchen, and a mobile manipulator running the policy can put a stranger's kitchen into that same tidy state. Figure's Helix is the same shape of object on a different body — a VLA sitting on top of a fixed stereo pair, controlling a 28-DoF upper body for household manipulation. The locomotion world caught up separately, and through different mechanisms, but on a similar schedule: by 2025 the MuJoCo Playground library from Google DeepMind was shipping bipedal locomotion environments out of the box (the G1JoystickFlatTerrain task ships with the package, tuned for the Unitree G1), and NVIDIA Isaac Lab had become the default GPU-accelerated simulator for teams that needed photorealism plus rigid-body contact. A single researcher with a workstation can now train a walking policy overnight that, five years ago, would have been a multi-year lab project.
That is the part of the story worth holding onto. The hardware exists; the software exists; the open weights exist. So when I look at a serious solo build today, I do not start with a question about which policy to train. I start with three questions about which stack to bolt together.
The locomotion stack. This is the solved-shaped part of the problem, in the narrow sense that the rough shape of a working pipeline is now standard. Train in simulation, with domain randomisation over friction, mass, motor latency, and payload. Use a teacher-student distillation: a privileged policy gets ground-truth state (full pose, contact forces, velocities) in sim, and a student policy learns to imitate it from only what the robot can actually sense (joint angles, IMU, base linear velocity from a Kalman filter over leg odometry). Deploy the student. Then fine-tune on hardware with PPO or SAC on the real robot for a few hours to close the sim-to-real gap. The key insight, repeated in every postmortem of a working build I have read this year, is that you do not train from scratch. You take a base policy from NVIDIA's Project GR00T, or from one of the open Berkeley Humanoid checkpoints, or from a community-trained MuJoCo Playground model, and you adapt it to your specific body. Your body is the unknown. Your control law is well-known.
The perception stack. This is where the field split cleanly in 2024-2025, and the split is worth understanding because it dictates the hardware bill. Locomotion has mostly stayed proprioceptive — joints, IMU, leg odometry — because the thing the policy needs to know, "am I about to fall over," is not really a vision question. Manipulation, on the other hand, went the other way: the policies that fold laundry or clean kitchens are doing it through stereo or RGB-D cameras and a transformer that consumes both image tokens and proprioceptive tokens, trained jointly on the internet and on robot data. So the modern build separates these. The locomotion policy runs at 200 Hz on the joint controller, reading proprioception and outputting joint targets, and does not look at the cameras at all. The manipulation policy runs at 5-10 Hz, on a separate GPU box (an Orin or a small discrete board), reading the wrist cameras and a third-person RGB-D, and outputs end-effector targets that a low-level controller interpolates toward. The two policies share a body but do not share a brain. Trying to fuse them into one network is an active research question, and the working answer in 2026 is: don't.
The body. Actuator choice defines everything downstream. Quasi-direct-drive units — low-ratio planetary gearboxes driven by a high-torque BLDC motor, the architecture used in Agility's Digit, Unitree's H1, and the Booster T1 — give you backdrivability and clean force control: you can push the robot's leg and the motor pushes back proportionally, which is what makes compliant contact survivable. The cost is torque density: at equal mass, a quasi-direct-drive joint delivers less peak torque than a high-ratio harmonic-drive joint. Series-elastic actuators (a spring in series between motor and output) give you even better compliance and better force fidelity for force-sensitive tasks, at the cost of bandwidth — you cannot command a position faster than the spring's resonant frequency allows. The decision rule, simplified: if you want robustness to falls, unstructured environments, and contact with humans, quasi-direct-drive. If you want high-precision assembly at a bench, series-elastic or even rigid. The Unitree H1 weighs 47 kg, runs about 180 cm tall, and runs off an 864 Wh battery; the actuator cost dominates the BOM but the form factor and the open SDK dominate the integration effort. You are picking how much pain you want to feel later.
Here is the part of the brief I want to argue with. The morning pass seeded the contrarian claim that the humanoid form factor is probably wrong for home use, and a wheeled mobile manipulator (a Mobile Aloha, a TidyBot, or the equivalent) covers 80% of useful household tasks with 20% of the complexity. I think that claim is right and that it is being under-weighted. A humanoid can climb stairs; a wheeled manipulator can not, and that is the entire counterargument. But most homes have one stair. Most factories have none. The wheeled platform wins on payload, battery life, simplicity of perception (the base never falls over, so the locomotion policy is trivial), and dollar-per-task — and it loses only on a small class of human-built environments. So the honest framing for a 2026 build is not "humanoid or not." It is "which parts of the human environment do you actually need, and is the 28-DoF cost of legs worth paying for those parts?"
A decision tree, then, in compressed form:
- Kitchen helper / household pick-and-place on one floor. Wheeled mobile manipulator. Unitree's wheeled base plus a 7-DoF arm with a parallel-jaw gripper, running π0.5 fine-tuned on a few hours of your own kitchen data. BOM under $20K, software stack mature, deployable in three months. Skip the humanoid entirely.
- Factory pick-and-place / bin-to-bin transfer. A fixed-arm Franka Panda or a UR5e on a rail, no mobile base needed; vision-language-action for novel SKU handling, but the locomotion stack is the empty stack. BOM under $30K, deployable in two months.
- Stair-climbing explorer / outdoor unstructured terrain. Humanoid, quasi-direct-drive actuators, full simulation training pipeline. Unitree H1 or Booster T1 as the base, custom torso and arms if you can afford the integration time. BOM $50-90K, six months minimum, and you will be debugging the legs for at least half of it.
That third option is where the research lives, and it is also where most solo builders should expect to lose the most time. The body integration — getting actuators, motor controllers, a real-time bus, a battery management system, and a safety-rated stop circuit to all agree with each other — is the part that does not appear in any paper, because nobody writes papers about the part that has already been solved fifteen times by other people on different hardware. You will write that paper yourself, by doing it, badly, the first three times. That is the cost of admission to the field in 2026, and it is a real cost — but it is, finally, a cost that a single person with a workstation and a credit card can pay.
The remaining question is whether the field wants to be the kind of place where a single person can pay that cost. The release of open base policies, open simulation environments, and openly-documented actuators is the reason this is even a thinkable project now, and it is also the reason it is worth being suspicious of any humanoid roadmap that requires a $100K subscription to a proprietary model API. The integration work is the price. The lock-in is optional. Choose accordingly.
Sources:
- Physical Intelligence, π0 and π0.5 — generalist robot policies.
- Kevin Zakka et al., MuJoCo Playground: An open-source framework for GPU-accelerated robot learning and sim-to-real transfer, Google DeepMind, 2025.
- Anthony Zhang et al., Mobile ALOHA — Learning Bimanual Mobile Manipulation with Low-Cost Whole-Body Teleoperation, Stanford.
- Jimmy Wu et al., TidyBot — Personalized Robot Assistance with Large Language Models, MIT CSAIL.
- Unitree H1 / H1-2 — Universal humanoid robot specifications.
- Berkeley Humanoid — open-source humanoid robot project.
- NVIDIA, Isaac Lab — GPU-accelerated robot learning.
- NVIDIA Project GR00T — foundation models for humanoid robots.
- Figure AI, Figure 03 and Helix — AI for general-purpose humanoids.
- Anthony Brohan et al., RT-2 — Vision-Language-Action Models, Google DeepMind, 2023.