MicroDuck 0.17.2: UDP Stop Timing and Custom Pad Axes

What changed after 0.17.1?

The earlier 0.17.1 article records that release, including its old 250 ms client timeout. Do not carry that number into 0.17.2: the new configuration has stale_ms = 300 and timeout_ms = 1000. The USB/Bluetooth pad and UDP pad still share the same button map, but the optional UDP service is the scope of the two-stage network timing. Previous stable daemon 0.17.1 · October 12 ↗ Official stable daemon 0.17.2 · October 13 ↗ Pinned 0.17.2 UDP pad timing and link diagnostics ↗.

Record the installed version and overrides first.

robotctl version
robotctl update status
robotctl update check daemon
robotctl configure --list
robotctl pad bindings
robotctl policy list
robotctl health

update check daemon checks the stable source without installing. Save the actual board version, configuration overrides, button bindings and policy list. A preorder with no robot has nothing to update. The official v8 policy manifest is unchanged from the October 13 review; a daemon release does not prove that a robot runs that policy. Pinned 0.17.2 controller and update commands ↗ Unchanged official v8 policy-set manifest ↗.

Remap sticks with a narrow, reversible edit.

On an official compatible robot, run sudo robotctl configure and search for pad_axes. The example below puts forward/back on the right stick, turns with the left stick at 0.7 gain, and narrows the requested forward/back command range. It is TOML to enter in the editor, not a shell command:

[pad_axes.drive.vx]
source = "right_y"

[pad_axes.drive.vyaw]
source = "left_x"
gain = 0.7

[pad_drive]
vx_min = -0.2
vx_max = 0.3

The shipped drive mode (D-pad left) uses left Y for forward/back, left X for strafe and right X for yaw, with the strafe and yaw directions inverted. The default deadzone is 0.1 and each binding starts at gain 1.0. Missing fields retain their shipped source and direction. gain applies before clamping to full deflection; source = "none" disables that command. Remove an override to return that mode to its default. The pad-axis and drive-limit changes reach both Bluetooth and UDP controllers within about one second without restarting services; an invalid edit leaves the previous mapping active and is logged. Keep the robot supported and test one axis at a time, because a sign or mode mistake can move it unexpectedly. Changing netpad.enabled, by contrast, changes which pad daemon runs and follows its separate apply/restart procedure. Pinned 0.17.2 controller and update commands ↗ Pinned pad-axis defaults and override validation ↗ Pinned robotctl configure apply behavior ↗.

Understand the two UDP loss thresholds.

The optional UDP pad remains disabled by default and is for a trusted LAN only: port 4210 has no authentication or encryption. In 0.17.2, stale_ms defaults to 300 and must be below [safety] deadman_ms (default 500); timeout_ms defaults to 1000 and must be at least stale_ms. At the first threshold the robot stops walking while the sender keeps its session. If fresh input resumes before the second threshold, that sender can continue; the old stick state is not replayed. At the second threshold, the session is released and the ordinary pad-gone response can request a sit about a second later. Neither stage guarantees an immediate physical stop or a successful sit in every posture. Pinned 0.17.2 UDP pad timing and link diagnostics ↗ Pinned controller and netpad configuration examples ↗ Pinned UDP stale and late-datagram implementation ↗.

The receiver also rejects datagrams that arrive too late relative to that stream’s fastest delivery, so button presses in a queued Wi-Fi backlog should not fire after the fact. While datagrams keep arriving, it logs a link: summary for roughly each ten-second sample window with p50/p99/max added delay, late drops and stalls. A complete input outage need not produce a new summary. A custom sender that sets its timestamp field to zero does not get this lateness check; the official duckctl udp-pad uses the published client path. These are software rules, not a promise about any wireless network. To inspect a running UDP daemon on the robot:

journalctl -u netpadd -b

The duckctl 0.17.2 laptop package is published for macOS, Linux and Windows. The previous UDP setup guide still explains trusted-LAN enablement; use the 0.17.2 timings above after upgrading. Published duckctl 0.17.2 laptop package ↗.

Upgrade only when the stable source and board match.

Support the robot, keep power stable and allow the daemon services to restart. If the stable checker offers 0.17.2 for the declared board, install intentionally:

sudo robotctl update apply daemon

Compare the running version, configuration, bindings, policy list, health and update history with the saved baseline. Configured joystick overrides and manually loaded policy slots deserve explicit inspection; this site has no physical upgrade result to substitute for that check.

robotctl version
robotctl configure --list
robotctl pad bindings
robotctl policy list
robotctl health
robotctl update log
robotctl update show

If the update fails, inspect update show and update log before acting. A manual daemon rollback needs a previous release already installed on that board, and it does not roll back the independently versioned v8 policy set:

sudo robotctl update rollback daemon
robotctl version
robotctl health

Where to go next.