Installing the Rust packages doesn't provision a robot
Microduck's Rust dependency step succeeded in 23 seconds in our sandbox, then compilation stopped at a missing GStreamer library. That gap fits the project: this repository operates a particular robot, with camera services and board configuration alongside the movement code. Treat it as a robot software stack you're prepared to maintain. The first decision is whether you want to operate that hardware or work on a learning algorithm.
The README describes a small biped whose control daemon sends neural-policy outputs to its servos. Other daemons handle configuration, Bluetooth and camera streaming. Training lives in the separate microduck_rl repository, which exports ONNX policies for this runtime. That split is useful. You can study or change how an existing policy reaches the motors without adopting the policy-training workflow, and researchers can follow the training project without provisioning a physical duck.
What happened when we ran it
Our run installed commit d7560ef in 23 seconds, adding 547 packages. The build failed with exit code 101 after 114 seconds, and the test command failed with the same exit code after 59 seconds. The October 16, 2026 run used image lab-rust:1, an unprivileged container with 3 CPUs, 12 GB of RAM and no secrets. These are host-side results, without evidence of the runtime controlling a robot.
Both failing log tails identify the same native dependency: gstreamer-sys could not find GStreamer through pkg-config. The build request required GStreamer 1.22 or newer, and gstreamer-1.0.pc was unavailable in its search path. The log also says PKG_CONFIG_PATH was unset. That does not prove that setting the variable alone would solve it, since the required library and metadata file must actually exist. The test failure supplies no assertion results.
The checkout contained 449 files, roughly 157,746 source lines and 9.1 MB of files. Our scan recorded 10 CI workflow files. Those figures describe a substantial workspace with upstream automation, while our failed commands establish a narrower fact: the fresh lab image lacked a native prerequisite needed by the selected compilation path. We cannot turn that result into a judgment about walking stability, camera latency or successful rollback on hardware.
Linux needs C libraries that the contributor guide names
The contributor guide explicitly lists Linux packages including libudev-dev and GStreamer development packages. It explains that the media pipeline compiles differently on Linux and macOS. The top-level README links to this guide, so the dependency is documented beyond the landing page. Our container failure is a reason to read that platform section before starting, rather than evidence that the maintainers omitted the requirement everywhere.
The 547-package Rust installation therefore covered only part of setup. Board work adds an aarch64 Linux target, service configuration and policy assets. The development-board guide requires network details and SSH key access because provisioning reconnects after a reboot. It also distinguishes development signing keys from customer trust settings. I would keep the host's native packages and the board's provisioning procedure as separate records, since success at either step leaves the other unproven.
Signed updates and health checks are part of the runtime
Release daemon-v0.17.4 includes signed artifacts and a manifest, matching the documented update design. updaterd installs releases and can roll back when the robot comes up unhealthy. Configuration has its own daemon, separate from motor control, so troubleshooting access doesn't have to depend on the control process being healthy. These are practical choices for a machine whose software can fail while you're away from its keyboard.
The 114-second build failure prevented us from evaluating those mechanisms. Signed updates and rollback are documented capabilities here, without an endorsement from fault injection in our lab. Developer-board provisioning also intentionally changes which signing keys are trusted. Follow that route only for the matching board setup, and retain the documented recovery access. The distinction matters when moving beyond experiments to a robot whose installed software you expect to recover predictably.
MuJoCo runs the daemons without reproducing the board
The simulation guide describes real daemons communicating with a MuJoCo body through a simulated hardware connection. It gives contributors a way to investigate control and API behavior without a duck on the desk. That's a better match for software exploration than buying hardware before you've worked out which process or policy you want to change. Training new policies still belongs in the sibling learning repository.
Our 59-second test failure leaves that simulation route unverified too. The contributor guide warns that host checks do not validate Linux-specific NetworkManager and BlueZ paths. A current open pull request 417 also describes a held body pose interfering with sitting, even though the command reports acceptance. Its proposed fix is still open. If your application treats accepted commands as completed movement, this report gives you a concrete reason to reconsider that assumption.
October releases address real board behavior
GitHub recorded an October 16, 2026 push, 9,487 stars and 42 open issues and PRs. Release daemon-v0.17.4 shipped on October 15 with a beta-board serial identity fix. Nearby activity includes a merged release preparation and open proposals around controller behavior and mapping. The maintenance evidence is specific to operating robots, rather than just a star count. An open proposal remains a proposal until it lands.
For a build-it-yourself biped project with mechanical resources, compare Open Duck Mini. For policy training, start with Microduck RL and its simulation-to-ONNX workflow. Choose this runtime when you need Microduck's device services and update machinery enough to own the native Linux prerequisites. Before putting a modified release on a robot, get past the GStreamer blocker and check the exact behavior you changed on the intended target.