Thirteen task families target one 800 g robot
Microduck RL trains policies for an approximately 800 g, 25 cm biped, then exports them to ONNX for the separate Microduck runtime. The README lists 13 task families covering walking, fall recovery, standing up, sitting, ground touches, ball kicks, a forward roll, and several roller-skating moves. That makes the repository useful as a concrete sim-to-real case study. It is a poor shortcut for another robot because the joint layout, models, observations, and deployment contract all belong to Microduck.
The shared policy interface is the interesting engineering choice. Every task keeps a 61-dimensional actor observation, including 48 proprioceptive values plus command slots for motion, head pose, and body pose. Tasks that do not need a slot fill it with zero rather than changing the shape. The physical runtime can therefore switch among walking, recovery, and trick policies without renegotiating inputs. An inference script rehearses that handoff in CPU MuJoCo before an ONNX file reaches the robot.
Actuator detail addresses a 14-servo sim-to-real gap
The environments model all 14 servo joints with BAM's M6 actuator behavior rather than an ideal position controller. Battery voltage, voltage sag, command delay, back EMF, and friction can vary between environments. Backlash variants add 2 degrees of total gear play through passive hinges, while encoder observations read the output side of that play. These details are tied to the Dynamixel XL330 hardware and explain why the repository is more useful to a Microduck owner than a generic PPO example.
Robot models are split by contact needs. The walking XML strips some trunk and head contacts, while recovery and trick tasks use an all-collisions model that can lie on the floor. Roller tasks get another model with passive wheels. The exporter embeds the observation normalizer in the ONNX graph. The README warns against hand-converting a checkpoint because the runtime would then feed unnormalized observations to the policy.
What happened when we ran it
Our sandbox cloned commit d424a0c and installed 161 packages in 150 seconds. The environment consumed 7,952 MB on disk, far more than the 28.8 MB checkout. Building succeeded in 4 seconds. The repository contained 222 files and about 23,125 lines of source, with a tests directory but no Dockerfile and no CI workflow file. Pip-audit reported 4 known vulnerabilities in the installed environment.
The test command exited with code 1 after 27 seconds. Pytest recorded 5 passed tests, 1 skip, and 16 collection or setup errors out of 21. The repeated error said FrictionDRBamActuatorCfg.__init__() received an unexpected vin_drop_gain_range keyword. It appeared while collecting configuration tests for walking, rollers, slopes, spinning, stand-up, and other tasks. The log shows an interface mismatch at setup time; it does not establish which package or code change introduced it.
Those 16 errors matter because most tests never reached their assertions. The README describes CPU-only checks for configuration invariants, joint-index mappings, reward signs, and NaN guards, but our run could confirm only the 5 tests that passed. There is no basis here for judging training speed or policy quality. We did not run a CUDA training job, download a W&B checkpoint, export ONNX, or command a physical Microduck.
Local training needs CUDA, while hosted training needs accounts
The documented local route requires Python 3.12, uv, and a CUDA GPU because training uses MuJoCo Warp. The quick command suggests 4,096 environments. The README gives a training-time estimate, but our sandbox did not measure it, so it is project guidance rather than a result from this review. ARM users on DGX Spark, GB10, or Jetson are warned that the first dependency sync may pull about 2 GB of CUDA wheels and exceed uv's default 30-second network timeout.
Hugging Face Jobs is the official escape hatch for a machine without a suitable GPU. That path requires an HF token, a namespace with billing, and private repositories for uploaded source and checkpoints. W&B login is optional for submitted jobs, yet the main playback and export examples expect a W&B run path. The submitter uploads tracked and uncommitted files in a tarball, so inspect that payload before sending a working tree to a hosted account.
Asset licensing and absent weights narrow the audience
The repository code uses Apache-2.0, but the README assigns the 3D model files a CC BY-SA-NC license. A company planning a commercial robot product should separate code rights from model rights before reuse. The project does not present itself as a policy download catalog. Open issue 6, created on August 28, asks whether walking weights are available for simulation, while the documented workflow starts from training or an existing W&B run.
GitHub showed 678 stars, 8 combined issues and pull requests, and a last push on August 30, 2026. Several open pull requests were updated on August 29 and 30, including work on AMD GPU support and task fixes, so current activity is visible even though the latest-release endpoint returned no published release. That is the profile of young, active research code. The failed setup phase and absent CI workflow still make commit pinning and a local compatibility test mandatory before spending GPU money.
Microduck owners get the clearest payoff
A Microduck team gets task definitions, robot models, actuator behavior, policy export, hosted-job plumbing, and a CPU rehearsal script in one 23,125-line workspace. Reproducing those pieces independently would be tedious, and the project documents contracts such as passive-joint naming and baked-in observation normalization. The value drops sharply outside that hardware because each choice becomes an assumption to remove.
Our 7,952 MB environment and 16 setup errors make this a deliberate adoption, not a casual example install. Fix the pinned dependency path, rerun all 21 collected tests, and rehearse each exported policy in CPU MuJoCo before connecting the 14-servo robot. Researchers on other platforms will spend their time better in mjlab or Isaac Lab, where Microduck's observation and model decisions are not the starting point.