We’re training two policies for Asimov 1 in simulation (mjlab, using the MJCF from asimov-1/sim-model): a get-up policy that brings the robot back to the standing pose used by the stock locomotion policy, and a safe-fall policy that reduces impact on the head, torso and knees when a fall can’t be avoided. Both work well in sim. Before moving to hardware and publishing, we have a few questions we couldn’t answer from the docs or repos, or where two sources disagree. Short answers are fine.
Running on the robot
Fall fault. The docs say a detected fall (projected gravity z above about −0.5) puts the robot into DAMP and latches a fault that only a firmware restart clears. Is there a mode or setting that lets a custom controller keep commanding the joints during and after a fall?
Custom policy on the CM5. What’s the intended way to run our own ONNX policy onboard (runtime/version, how observations and actions are passed, how to switch between the stock locomotion policy and ours)?
Commands from DAMP. Can TrajectoryRequest commands be accepted in DAMP? The API overview mentions direct joint control from DAMP, but the Robot Control page says commands are dropped in that state.
Actuators
Torque limit enforced by firmware: rated (e.g. knee 25 Nm), peak (75 Nm), or the 45 Nm in isaac_asimov? How long can peak torque be held?
Velocity limit (e.g. hip roll 3.98 rad/s): motor no-load speed (torque → 0) or a firmware speed cap?
Back-driving above the velocity limit: in falls, impacts push joints past the limit for tens of ms (≈1.2× with our policy, ≈2.5× in a passive fall). Safe for the actuators/drivers? Any over-speed or over-voltage fault?
Armature: the docs/MJCF give 0.095625 for hip pitch; isaac_asimov and the mjlab draft use 0.0698. Which values should we use?
Ankle motors A/B (peak 145.4 / 57.6 Nm, rated 40 / 17 Nm): per-motor or joint-space figures? Is A = pitch and B = roll? Do ankle trajectory commands use motor angles or joint angles?
Robot model
Joint ranges: the mechanical table shows hip pitch −2.09…1.00 and elbow 0…2.44 rad, but sim-model PR #25 changed them to ±1.57 and 0…2.09 “to match the hardware”. Which is current?
Ankle range (pitch ±0.35, roll ±0.1 rad): mechanical stops or a safety setting?
Mass: docs ≈35 kg vs 32.2 kg in the MJCF. What’s missing (battery, cabling?) and where is it mounted?
Joint zeros: which joint angles does the calibration home pose correspond to?
Publishing
License of sim-model/: GPL-2.0 or CERN-OHL-S-2.0? We plan to release our policies under Apache-2.0 and include your model as a git submodule, not a copy.
We saw the get-up work in isaac_asimov PR #7. Would you be interested in comparing results, or in having our policies contributed upstream?
Ariel and I have typed down the answers below for all the questions!
For the first version we release this would not be possible to override the safety alerts but we are actively working on supporting this as well so that developers are able to modify these parts! If you want to sort of bypass these
The only way to run a custom policy would be through the sdk but that means initially you wouldn’t be able to directly deploy custom policies through the firmware directly onto the CM5 and only deploy custom policies through SDK using trajectory mode! However, we are also actively working on ensuring users can directly deploy policies using our firmware onto the CM5 directly!!
Nope TrajectoryRequest commands aren’t accepted while the robot is in DAMP. The Robot Control page is correct, and we will update the API overview page! So you need to send STAND first for the robot to accept TrajectoryRequest commands!
We set the simulation effort limit and firmware torque limit to approximately 120% of the motor’s rated torque for safety considerations. We have not stress-tested each motor to determine its thermal limits, but motor thermal protection has rarely been triggered during our normal operation.
The velocity limit in our table is the motor’s datasheet peak output speed, and the same value is configured as the joint velocity limit in firmware. In simulation, we treat this as the approximate no-load speed in our linear torque–speed model, with available driving torque decreasing to zero at that speed.
We do not implement joint-velocity clipping in the robot firmware. The motor drivers have built-in overvoltage protection, and once it’s triggered, the error will show up in our firmware.
Please use the values on isaac_asimov, asimov_1.py. The MJCF was the previous estimation which we corrected later on after talking to the motor manufacturers. When you launch the training the actuator cfg files will overwrite the MJCF values also.
The docs listed per-motor configurations (there’s gonna be update to that table since we’ve defined new values for safety) . The ankle uses a parallel mechanism, motors A and B work together to produce both ankle pitch and ankle roll, so A does not independently correspond to pitch, nor B to roll. Our policy is trained using ankle pitch and roll joints in simulation, and the deployment controller converts between joint space and motor space.
The sim-model is the latest one, we will also update the docs soon.
Pitch maximum is 0.35 already roll maximum is also 0.35 but it’s clipped to 0.1 as a safety setting in the firmware. Once we roll out how to configure safety settings etc as mentioned in some of the questions above you would be able to edit them!
Fasteners throughout the body add up to around 2-3 kgs! We will be updating the URDF soon with the exact mass updates to the linkages based on how many fasteners we used for each part but it shouldn’t make a big difference right now to locomotion training and deployment!
We will be adding the exact calibration procedure to the manual shortly once you calibrate according to the guide the robot will calibrate and the zero pos would be the URDF zero position!
We’re confirming the intended license for the MJCF, URDF and meshes internally and will add an explicit statement to sim-model/ (and the README) so it’s unambiguous. We’ll follow up once that’s in place, including how it applies to your plan to release your policies under Apache-2.0 with the model included as a git submodule.
Yes you can create PRs in that repo and we can also help you verify your policies on our robots!
Thanks a lot, Ishneet and Ariel, this is really helpful. We’ve updated our setup accordingly (isaac_asimov armature, sim-model joint ranges, training at rated torque, since the firmware limit is ~120% of it). We’d also love to take you up on verifying the policies on your robots once the fall handling allows it.
Two quick follow-ups:
Telemetry rate in trajectory mode. Since custom policies run off-board through the SDK for now: at what rate can an off-board controller read joint states and IMU data in trajectory mode? The docs mention telemetry at ~10 Hz, and our policies run at 50 Hz on 50 Hz observations.
Your first answer seems to be cut off at “If you want to sort of bypass these”. Could you share the rest? We’re interested in any way to test get-up while the safety alerts can’t be overridden yet.
Thanks again for the detailed answers. We applied them (isaac_asimov armature, sim-model ranges, torque at rated, ~2-3 kg extra mass in the randomization) and retrained both policies, now also on uneven ground (2-5 cm bumps).
Simulation results, 2048 episodes per test:
Get-up: 99.8% success, median 1.7 s to stand
Safe-fall: 94.7% lower peak impact on head/torso/pelvis/knees than a passive fall
Get-up after safe-fall: 99.7%
Cross-check in plain CPU MuJoCo: 100% get-up, 92.3% impact reduction
Policies, specs and a standalone MuJoCo runner (numpy + mujoco + onnxruntime, runs on your asimov_1.xml):
We also opened a small docs PR linking them, in case you’d like to list community policies:
One new question, about back-driving. Our motor model can’t drive a joint past its velocity limit, but impacts still push joints over it: up to about 1.5-1.6x the limit, for about 75 ms at most (p95). A passive fall reaches about 3x. You mentioned the drivers’ over-voltage protection raises a firmware error. Do you know roughly how much overspeed, or for how long, would trip it?
The two questions from my last post are still open: the joint/IMU rate available in SDK trajectory mode, and the end of the sentence starting “If you want to sort of bypass these”.
Whenever the firmware lets custom control continue through a fall, we’d be glad to take you up on testing these on a robot.