Menlo Open-Sources Asimov 1 Humanoid Locomotion Policy and RL Code

Most humanoid robot companies treat their locomotion policy — the software that actually makes the thing walk without falling over — as the crown jewel, kept as closed as the hardware around it. Menlo Research took the opposite approach with Asimov 1, its developer-oriented humanoid platform: this week it open-sourced the complete reinforcement-learning training pipeline behind the robot's walking gait, publishing the isaac_asimov repository under a permissive BSD-3-Clause license.

TL;DR

What's actually in the repository

The isaac_asimov repo is a standalone Isaac Lab extension purpose-built for Asimov 1 — not a generic humanoid RL framework retrofitted to one robot. Isaac Lab is NVIDIA's GPU-accelerated robot learning framework, built on Isaac Sim, designed for training policies across thousands of parallel simulated environments simultaneously — the standard approach for making humanoid locomotion training tractable, since a single robot instance walking in real time would take months of wall-clock time to accumulate the experience a policy needs.

The training setup combines two techniques:

• PPO (Proximal Policy Optimization) — the standard baseline reinforcement-learning algorithm for continuous control tasks like locomotion, used here with an asymmetric actor-critic architecture where the critic network sees privileged simulation-only state (exact contact forces, full body velocities) that the actor — the part that actually runs on the real robot — never has access to. That asymmetry is a well-established trick for stabilizing training without requiring the deployed policy to have information it couldn't get from real sensors.
• AMP (Adversarial Motion Priors) — a technique that trains a discriminator network to distinguish "policy-generated motion" from reference motion-capture data, then uses that discriminator's judgment as an additional reward signal. In practice, this is what keeps a PPO-trained gait from looking mechanically stiff or unnatural — pure reward-shaping for "don't fall down and move forward" tends to produce a gait that works but looks nothing like how a human or animal actually walks; AMP nudges the policy toward more natural-looking motion without hand-tuning dozens of reward terms.

Installation targets Ubuntu 22.04+ with an NVIDIA GPU, using uv for environment management, and supports both single- and multi-GPU training with environment counts that scale to available VRAM. Trained policies export to ONNX for deployment — a standard, framework-agnostic model format that keeps the trained policy portable rather than locked to the training stack.

Why this differs from Asimov 1's existing "open" claims

Asimov 1 was already marketed as open hardware — Menlo publishes the mechanical CAD, electrical CAD, MuJoCo simulation model, and full bill of materials, enough for someone to source parts and assemble a unit themselves rather than buy a sealed appliance. What was missing, until this release, was the software layer that actually makes the hardware do anything useful: the trained-from-scratch intelligence for walking.

That distinction matters practically. Open hardware without open control software still leaves you dependent on whatever locomotion policy the vendor ships — you can build the robot, but you can't meaningfully change how it moves without reverse-engineering a closed model. Releasing the training pipeline itself closes that gap: anyone with access to the simulation model can train a new policy from scratch, modify the reward function, swap in different motion-capture reference data for AMP, or fine-tune an existing policy for a different gait style or terrain, without needing anything from Menlo beyond the open repository.

What people are asking

Is this comparable to other open-source robotics releases?

It sits closer to a full research stack than most "open-source robot" announcements, which frequently mean open hardware only, with software staying proprietary. The closer comparisons are projects like Unitree's occasional SDK releases or academic humanoid RL codebases (Berkeley Humanoid, HumanoidBench) — but those are typically research artifacts without a purchasable, developer-shippable physical robot attached the way Asimov 1 is. Pairing a $499-deposit hardware platform with a permissively licensed, production-quality training pipeline is a less common combination.

Do I need to buy the robot to use any of this?

No. The training pipeline runs entirely against Asimov 1's MuJoCo simulation model, so you can train, iterate, and evaluate locomotion policies in simulation with nothing but a capable NVIDIA GPU. A physical unit — or access to one through Menlo's assembly and servicing partners in the US and Singapore — is only necessary for the sim-to-real deployment step, where you'd discover whether a policy trained in simulation actually transfers to the real robot's sensor noise, actuator delays, and unmodeled friction.

What's the practical use case for someone outside robotics research?

If you're building or studying AI agents more broadly, this is a useful, concrete case study in a problem that generalizes past robotics: training a policy in a cheap, fast, parallelizable simulated environment, then bridging the "sim-to-real gap" to deploy it against messier real-world conditions. That same pattern — train in a controllable proxy environment, then validate against reality — shows up anywhere an agent has to act in a physical or otherwise high-stakes environment it can't safely explore through pure trial and error.

How does this compare to other humanoid robot companies' approach?

Figure, Unitree, and Boston Dynamics all keep their locomotion policies closed — proprietary control software is a core competitive moat for those companies, tied tightly to their specific hardware. Menlo's bet with Asimov 1 is different: positioning the robot as an open research and development platform rather than a polished commercial product, betting that community-trained policies and a broad developer ecosystem are more valuable long-term than keeping the walking gait as a trade secret. It's the same open-versus-closed tension that plays out repeatedly across AI more broadly — see explainx.ai's coverage of Figure's Helix humanoid robots for how a closed-stack competitor is positioning the same underlying hardware category.

The robot underneath the policy

The training pipeline is only useful in context of what it's actually controlling. Asimov 1's mechanical design has a few specific choices worth understanding if you're evaluating whether the locomotion approach generalizes to other platforms. It uses canted hips and backward-bending knees — a configuration closer to how many quadrupedal and digitigrade-legged robots are built than the straight-legged, forward-knee layout most consumer-facing humanoids (Figure, Optimus, Unitree's G1) use. Its ankles have deliberately limited range of motion, roughly ±20° of pitch and ±15° of roll, and its toes are passive and spring-loaded — unmotored, unsensored joints that flex mechanically rather than under active control.

Those choices matter for what the RL training code actually has to solve. A passive, unmotored toe means the policy can't rely on toe-off push as an active control input the way a fully actuated foot would allow — the locomotion policy has to produce a stable gait despite that missing degree of freedom, not because of extra actuation. Menlo's own framing for this design philosophy, "locomotion as a data interface problem," points at the same idea from a different angle: what matters most isn't algorithmic sophistication in isolation, but how cleanly the contract between the policy's outputs and the physical system's actual response is defined. A simpler, more constrained mechanical design can make that contract easier to learn well, even if it looks less capable on paper than a robot with more actuated joints.

What this means for builders outside robotics

Even if you never touch a physical robot, the pattern this release documents is worth internalizing for any agentic system that has to act against messy, imperfect real-world feedback rather than a clean simulated one. The asymmetric actor-critic setup — giving the training-time critic privileged information the deployed policy never sees — is a general technique for stabilizing any RL training loop where the deployment environment is noisier or more limited than the training environment. And the sim-to-real gap itself, the reason a policy that works perfectly in MuJoCo might stumble on the physical robot, is a direct analogue to the evaluation-to-production gap that shows up constantly in LLM agent work: an agent that passes every benchmark in a sandboxed eval harness can still behave differently once it's touching real tools, real APIs, and real user input with all their attendant noise and edge cases.

The takeaway

Open hardware has become a reasonably common pitch in humanoid robotics — plenty of platforms publish a bill of materials and call it open source. Open, permissively licensed, production-grade locomotion training code is rarer, because it's the part of the stack most companies treat as their actual product. Whether Asimov 1's approach produces a meaningfully better developer ecosystem than closed competitors remains to be seen, but the release itself is a genuine, checkable data point: anyone can clone the repo, read the reward functions, and judge for themselves rather than taking a vendor's word for how the robot learned to walk.

Related reading

• Figure Helix 02: Collaborative Humanoid Robots That Tidy a Bedroom
• World Humanoid Robot Games: Complete Guide
• Gemini Robotics 2: Whole-Body Intelligence
• UBTECH Humanoid Robot Factory in Liuzhou
• What Is Recursive Self-Improvement (RSI) in AI?

Sources

• isaac_asimov on GitHub (official repository, BSD-3-Clause)
• Menlo Research — Asimov 1 product page
• Menlo Research — "Teaching a humanoid to walk: The RL policy behind Asimov's first steps"
• "Open-sourcing Asimov 1: Locomotion Policy & Training Code" (YouTube announcement)

Details reflect Menlo Research's open-source release as documented in the isaac_asimov repository and Menlo's own posts as of September 25, 2026. Robot specs and licensing terms are Menlo's own published figures — confirm current details on Menlo's official pages before ordering hardware.