Disclosure: I help run MicroDuck Robot Community, an independent, unofficial community site. It is not affiliated with Pollen Robotics or Hugging Face. Everything below comes from the replica author's public release notes as summarized on our page; we did not download or flash the large image ourselves.
On October 23, 2026 (Beijing time), the author of a community MicroDuck replica published image 20261023 for the Feetech HD1910 / Radxa Zero 3W build. It is explicitly marked as a prerelease. That makes it a good example for a habit worth building whenever a hobby-robot image drops: separate "what changed" from "what has actually been verified on hardware".
Here is the checklist I now use.
1. Confirm the image is for your hardware route
This image targets the HD1910 / Radxa Zero 3W replica route. It is not an image for an official XL330 robot or for Open Duck Mini. If your build is different, stop here.
2. Verify the file before you write it to a card
The compressed file is microduck-replica-20261023.img.xz (712,183,896 bytes). Download the checksum companion from the same release and check it in the same directory.
macOS / Linux:
shasum -a 256 -c microduck-replica-20261023.img.xz.sha256
Windows PowerShell (compare the output with the published SHA-256):
Get-FileHash -Algorithm SHA256 .\microduck-replica-20261023.img.xz
3. Read which components actually changed
A new image number does not mean everything inside it is new. In this release, the Studio/build source and helper (0.7.0) changed, but the custom runtime stays at the previous fork revision with the same runtime hash as the earlier 21b image. Its Armbian 26.2.1 / Debian 13 base and the official 0.15.1 base runtime are also separate from the current official daemon 0.17.8. In short, a new Studio image is not a new robot daemon.
4. Keep a working card and your calibration backup
The author's offline acceptance record covers packaging, software tests and filesystem inspection. A fresh-card standing and walking run, plus real camera and ToF checks, had not been completed for this exact image. So keep the card that already works, and keep your calibration backup.
5. Treat "service online" as different from "sensor working"
The new Studio adds camera and ToF pages and seven device indicators (battery, servos, IMU, camera, ToF, gamepad, board). Those are diagnostic states, not seven passed hardware tests. The image still defaults to a camera test picture, so a running media service does not prove a real camera feed.
6. Use the supported flows, not manual shortcuts
- IMU direction: there is a new "Recalibrate direction" flow that needs Studio and helper 0.7.0 together. Start with the body supported and torque off, and don't replace it with a manual mode edit. If it's interrupted, resolve it through the recovery entry.
- Models: training and export still happen on your computer. Import a package with the model and its matching manifests, not a bare ONNX file. "Installed", "selected" and "currently executing" are three different states.
-
SSH: it's optional. Register your own public key (the
.publine, never a private key). There's no usable default remote SSH password, and the hotspot password is not an SSH password.
7. Record what you skipped
The checklist now lets you skip steps. A skipped step is not a validated step. For example, skipping IMU orientation just uses a default mounting assumption. Write down exactly what you skipped so a later failure report makes sense.
8. If something fails, report precisely and privately
Note the exact image, the Studio and runtime versions, the checklist stage, and a redacted error. Export diagnostics privately rather than posting a full bundle in public.
The full, regularly updated notes (including first-boot hotspot steps, the bus-IMU bench record and earlier image history) are on our unofficial community page: MicroDuck replica build notes.
