Microduck ships a prebuilt Pi image with the default password printed in the README

The image comes with a hostname and a password in print

The released image is not a base system with a guide attached. It already contains Raspberry Pi OS Lite 64-bit, a hostname of microduck, a default user called user, a deployment directory at ~/microduck, a Python virtual environment at ~/microduck/.venv, the walking model at ~/microduck/src/agents/walk.onnx, and a headless gamepad service that can start the model from a controller after boot. The login it expects is the one the page spells out twice, a username of user and a password of password, entered over SSH at microduck.local, and the page does tell you to run the password change command immediately afterwards. The exposure is worth naming plainly: a device on a wireless network with a predictable hostname, a predictable account and a published password, which is why the change-password step is written as a recommendation rather than a step in the sequence.

The bill of materials explains price variation and then prints no prices

The parts list opens by saying prices vary with region, purchasing channel and quantity, and that they are for estimation only. The table that follows has four columns, category, item, quantity and note, and no price column at all, so the caveat governs a number the page never states. The contents are still specific enough to plan a build. A Raspberry Pi Zero 2 W runs the control program, the Bluetooth gamepad, the wireless and SSH. A ROBOTIS OpenRB-150 board connects over USB and talks to the XL330 servo bus, with the code looking first for a serial device path matching the OpenRB name. Fourteen XL330-M288-T servos, a finished 6V rechargeable pack rather than a homemade two-cell build, a power switch, a 16GB or larger card, one BNO080, BNO085 or BNO086 IMU module, a set of printed parts, self-tapping screws in two sizes and the three-pin servo cables. The battery note is the one to act on: confirm it can deliver enough instantaneous current.

Fourteen IDs, one chain per limb, and an optional mouth

The servo ID table is the part of the build you cannot improvise, and it has to be set with Dynamixel Wizard before you flash the image or run anything. The right leg takes 1 through 5 as ankle, knee, hip pitch, hip roll and hip yaw. The left leg takes 6 through 10 in the same order, ankle, knee, hip pitch, hip roll, hip yaw. The head and neck take four more: head pitch at 11, neck pitch at 12, head yaw at 13 and head roll at 14. A fifteenth ID is reserved for a mouth servo, which you may fit but which the current walking policy does not use. The bus diagram then shows the physical order, and it differs from the numeric one: the right leg chain runs 5 to 1, the left runs 10 to 6, and the head and neck chain runs 12, 11, 13, 14. The page is explicit that the physical order is yours to choose for wiring convenience and only the IDs are fixed.

The serial port search has a primary path and four fallbacks

How the control program finds the servo board is described in one sentence with a specific list. Normally it selects the OpenRB-150 USB serial port automatically, and if nothing is found it falls back, in order, to /dev/ttyACM0, /dev/serial0, /dev/ttyAMA0 and /dev/ttyS0. The first of those is the usual name a USB CDC device takes, and the rest are the platform serial names a Pi may expose, so the chain is a genuine best-effort rather than a single assumption. The IMU side has the same shape. The BNO08x module sits on I2C, with the supply pin going to 3.3V according to the module marking, ground to ground, SDA to GPIO2 and SCL to GPIO3. Software defaults to I2C bus 1 and searches the common BNO08x addresses, and the mounting orientation is set by one configuration value which the page says is already matched to the walking model.

The verification step compares against a hash the page does not print

The image section starts by advising you to check the download before writing it, with a one-line checksum command. The instruction is that the result should match the SHA256 given on the release page or above. Neither appears in the visible document: there is no digest printed next to the image link, and the text only points forward and back to a value it does not contain. So the check as written cannot be completed from this page alone, and you have to find the digest on the release page before you can use it for anything. The flashing instructions that follow are careful in a way that suggests the author knows what goes wrong here. The graphical route is Raspberry Pi Imager in seven steps, including declining the offer to apply OS customisation, and the command line route is two commands, one to list block devices and one to decompress and write with a progress indicator and a flush. The warning attached to it is blunt: substitute the real device node and do not write to your system disk.

Two ways to put the robot on Wi-Fi, and only one needs a keyboard

Wireless setup is offered as two routes because the robot may be assembled or not. The first is to write the card on a computer, where Ubuntu mounts two partitions after flashing, a boot partition you can edit and a system root you generally leave alone, and the file to edit is a netplan-style network configuration. Three placeholders have to be replaced: a two-letter country code, the network name and the password, and more than one network can be listed. The second route needs a mini HDMI display and a USB keyboard, with an OTG adapter on the Zero, because the image is the Lite system with no desktop and you land at a terminal login after the first boot expands the partition, which takes one to three minutes. From there it is a scan, a connect, and two connection edits, one disabling power save and one enabling autoconnect. Both routes then end the same way, with a ping to the hostname and a check that autoconnect is set.

The training half is a separate directory that exports one file

The repository is two projects and the page is honest about which half it covers. The first directory holds the deployment code that runs on the Pi Zero 2 W: it reads the IMU, reads gamepad or keyboard input, drives the Dynamixel servos and loads the ONNX walking policy. The second holds a reinforcement learning training environment built on MuJoCo and MjLab, whose job is to train that policy and export it as walk.onnx. Everything after that is the first half, and it is presented in a useful order: put the robot on a stable surface or hold it, change into the deployment directory, and start the control program with the source directory on the Python path:

cd ~/microduck
PYTHONPATH=src .venv/bin/python src/main.py

On startup the program turns servo torque on, returns smoothly to a neutral pose, starts reading input and loads the policy. A short key table follows, with one key to toggle walking, arrows to drive and turn, one to zero the speed, one to show the IMU readout and one to quit.

Editorial conclusion

This tutorial fits someone who has decided to build this particular robot and wants the tedious parts, servo IDs, wiring order, the flash steps and the first run, written down rather than guessed. It is a poor fit as a general RL robotics starting point, because the training environment is a separate directory producing a single ONNX file and the page is about assembly and first boot, and a poor fit for anyone uncomfortable with a prebuilt image that logs you in as a known user with a known password. Before flashing, read the servos section, set the IDs and the Dynamixel parameters first, and change the password on the robot the moment it is on the network.

Frequently asked questions

Official sources

1. AI-FanGe/Microduck-build-tutorial on GitHub
2. Issues
3. License: MIT
4. README
5. Releases