MicroDuck 0.18.1: Boot Recovery, OS Updates & Settings

What 0.18.1 changes at startup

Pollen Robotics published 0.18.0 on October 29 at 12:57:56 UTC and 0.18.1 at 16:49:37 UTC. The latter is a stable release pinned to 7d866d0f. Our October 30 review date is separate from those publication times; the 0.17.9 article remains a historical reference.

Instead of waiting 180 seconds to begin judging, the boot timer starts after one second. The checker watches updaterd, robotd, configd and btd: failure or at least three restarts triggers a handover to robot-rescue; all loaded members active continuously for ten seconds ends the check successfully. The deadline defaults to 60 seconds and is clamped to 20–300. A stopped or still-unsettled unit without failure evidence is left alone; unloaded units are skipped. Handover still depends on rescue’s own eligibility checks; active hardware-waiting daemons do not prove motion readiness.

• Stable 0.18.1 release
• Pinned boot-check implementation

Identify the update layer before changing anything

A daemon update and an OS update are different operations. The new os interface requires microduck_yocto’s A/B layout and installed OS-update script; an unsupported board returns NOT_SUPPORTED/15. os status reports slots, progress and last_result; os check asks the channel. apply and switch mutate state and reboot, refuse motion or an active remote session, and share a lock with daemon updates. An accepted apply is the start of work; read last_result after reboot to learn the outcome.

The provisioned base remains /etc/robot/robotd.toml; owner overrides in /var/lib/robot/robotd.toml win per key. The editor writes the owner layer, while old recognized non-template edits are adopted. Unknown keys are retained and named, not silently removed. The migration cannot distinguish a deliberate choice equal to a shipped default. Hugging Face sign-in moves to persistent storage with a compatibility link; do not paste or publish the token. None of this establishes A/B support for a personal Armbian replica.

• Official OS command reference
• Layered configuration implementation

Community policies still need a separate decision

0.18.0 makes non-official policy fetching opt-in through policy.allow_community. A published model, permission to fetch it and a compatible model loaded for motion remain separate conditions. The official policy set is still v8 at the reviewed manifest; upgrading the daemon does not turn a community model into an official policy.

0.18.0 also includes camera, weak-link video and fall-predictor changes listed in the release. We reviewed public releases, manifests and fixed implementation, without installing a daemon, switching OS slots or testing a robot. Start with a record of the running build, current update layer and existing logs.

1. Record the exact daemon build and whether the image actually has A/B slots.
2. Compare effective owner settings and save existing update/boot logs before troubleshooting.
3. After an update performed by the owner, read the result rather than inferring success from a disconnected page.

• 0.18.0 release and merged changes
• Community-fetch permission in source