How we achieved zero-shot sim2real for Asimov

The same locomotion policy in simulation (left) and on the physical Asimov 1 (right), deployed zero-shot with no per-robot tuning.

How long before your new locomotion policy is live on the robot?

We asked researchers this question around the world. The answers vary from "3-5 hours" to "it takes us 2 weeks to adapt a policy for a real life robot".

At Menlo, we spent the last 8 months closing this locomotion sim2real gap on a sophisticated, bipedal form factor, so your policies can work out of simulation, zero-shot. We think we've achieved parity with Unitree locomotion circa early 2025. Still a long way to go, but making fast progress.

In this short post, we highlight what we did to make it work. In short, we think the fix had less to do with nudging models than with making the underlying hardware a lot more deterministic.

Takeaways

Asimov is now zero-shot sim2real on flat terrain walking, generalizing to small terrain variations like slight slopes and grass textures, without additional tuning
This holds across multiple units of the same robot, not just one hand-tuned unit in the lab
Base policies run onboard, on the robot's own motion control board, at 50Hz, controlling 25 motors and sensors with no external compute in the loop
We believe this work, and our learnings, adapt to other open-hardware robots, not just Asimov

Four photo strips of the Asimov humanoid walking: forward, backward, sideways, and rotating in place — Figure 1. Omnidirectional walking on Asimov 1: (a) forward walking, (b) backward walking, (c) sideways walking, (d) yaw rotation.

Grid of joint position versus velocity plots for twelve lower-body joints, comparing simulation trajectories in green with real-robot trajectories in blue — Figure 2. Joint position–velocity trajectories of the 12 lower-body joints under forward and backward velocity commands of magnitude 0.5 m/s, and lateral velocity commands. The real-robot trajectories (blue) closely overlap with the simulation trajectories (green) across the majority of joints, with similar trajectory shapes, ranges, and cyclic patterns. This demonstrates successful sim-to-real transfer, showing that the locomotion policy reproduces the simulated joint-level behavior consistently on the physical robot.

Why zero-shot sim2real matters

Researchers need hardware that moves as fast as their models. Many hardware providers struggle to provide something that validates research right out of the box, without much post-tuning and hardware troubleshooting.

At Menlo, we think that the robot itself should be a single, deterministic hyperparameter in training. We designed Asimov so that developers can safely run policies they have trained zero-shot on our robot.

Diagram of the Asimov locomotion pipeline: motion reference data generation via retargeting, feeding an AMP training pipeline with a discriminator, style and task rewards, and a PPO actor-critic agent in simulation — Figure 3. Asimov comes with a simple adversarial motion training locomotion pipeline and hardware configs.

Improving hardware stability

Hardware degrades, components heat up, fixtures loosen, sensors drift. But overfitting policies on hardware degradation actually trains the model to be overly conservative. We don't think models should compensate that much for what are inherently hardware problems.

The challenge here is to ensure the hardware works at hour 20 exactly the same as in hour 1. Among a myriad of other small and large fixes, we made mechanical design improvements towards a "boring and predictable" real robot.

For example, on the thermal side, the chase for high mechanical determinism needed PREEMPT_RT Linux, but that made our thermals worse, hence the need for a fan. So we added a simple fan to extend component operating ranges. We also fixed CPU-level thermal throttling behavior that was quietly degrading actuator responses over long runs.

Cleaning up robot communications

On-robot communications are noisy, lossy, and latent.

We want more reliable and clean robot data. But we don't want polished and smoothed-over data that obfuscates mechanical properties. So the challenge became: how do we expose real robot signals, without transforming robot data so heavily that it loses raw physics priors?

Asimov uses a CAN bus standardized protocol, an open and widely adopted industry standard. But it's quite messy. So the task for electrical is to make CAN as low latency, deterministic, and high quality as possible. We wanted to present developers raw and accurate visibility into low-level robot states, that they can train great policies from.

The team made several improvements including fixing CAN bus communication issues, corruption issues, and data standardization issues, and speeding up data ingress and egress latencies. For example, this involved moving to full SPI-CAN, due to buggy native CAN on our chosen CPU. This also involved moving to a new SPI-CAN chip (MCP2518FD from the MCP2515), with a large TX and RX buffer, among other fixes.

In addition to reliable communication with the actuators, we also need to accurately model the actuators in simulation. The actuator configurations can be found in our Isaac Lab pull request.

Only domain randomize what's actually random

Once the hardware is stable and the data is clean, we're able to decide what hardware features to model as a hyperparameter for training versus what to leave alone.

Our rule of thumb here is to randomize things that are genuinely uncertain. We found that if we randomized a parameter that isn't actually random on the hardware, the policy starts to hedge against distributions that don't exist. The model should never compensate for bad hardware understanding. Real2sim needs to be stellar.

Concretely, this meant modeling actuators carefully rather than domain randomizing around them. We wrote about this in a previous post. We removed things like integrated velocity, which tend to drift. And we model sensors limited to what is natively perceived.

Training wise, we did a lot of sim2sim across MuJoCo and Isaac Lab. Our researchers prefer mjlab for fast iteration, early-stage methodology validation, parameter tuning, and the wilder policy experiments where iteration speed matters more than fidelity. Isaac Lab is our go-to for later-stage physics learning, especially relying on the Newton physics integration.

Limits

We want to be precise about what we haven't done. We've proven zero-shot transfer on flat ground and mildly uneven terrain, along with recovery from mild disturbances. We have not yet claimed consistency across a large fleet of units or for complicated locomanipulation objectives, which is the next goal. Follow for updates on this soon.

Conclusion

For our pre-order customers and research collaborators who are interested in training locomotion policies for Asimov 1, please use the robot sim models and actuator configurations in our Isaac Lab pull request to get the best sim2real performance.

If you want a modular, developer-friendly humanoid robot, you can get the dev kit here.

If you're working on related problems and would like to collaborate, reach out.