MicroDuck 0.17.2: tiempos UDP y ejes del mando

0.17.2 se publicó el 13 de octubre y era latest en la revisión del día 14. Permite editar ejes del mando. Sin entrada nueva durante 300 ms, detiene la marcha y conserva la sesión; a 1000 ms considera ausente al cliente e intenta sentarse aproximadamente un segundo después.

Pollen Robotics publicó el demonio estable 0.17.2 el 13 de octubre de 2026 a las 09:46 UTC. Lo último de GitHub lo señaló en esta revisión del 14 de octubre. Este sitio leyó el comunicado y corrigió el commit 35b71a2; no instaló una actualización, no condujo un robot ni midió el tiempo de Wi-Fi.

¿Qué cambió después de 0.17.1?

Cambios publicados 0.17.2
Área	Nuevo comportamiento	Límite práctico
Ejes del controlador	Asigne cada comando del joystick a left_x, left_y, right_x, right_y o ninguno; establecer inversión y ganancia. Los límites para caminar, cabeza, cuerpo y rodillos tienen teclas separadas.	Cambia lo que pide la plataforma, no la velocidad física demostrada o la habilidad política. Las anulaciones locales pueden diferir.
Silencio UDP breve	Después de stale_ms sin un marco de pad aceptado, caminar se detiene donde está; el bloqueo del remitente y el estado del botón retenido permanecen.	El stale_ms predeterminado es 300 ms, no una parada de emergencia instantánea del hardware.
Largo silencio UDP	En timeout_ms, el cliente cuenta como desaparecido, se bloquea y se mantiene libre, y luego el robot intenta sentarse si está de pie.	El timeout_ms predeterminado es 1000 ms, luego la solicitud de asiento sigue aproximadamente un segundo después. Una habilidad ocupada puede negarse antes de volver a intentarlo.
Paquetes retrasados	Se descarta un datagrama suficientemente tardío; Mientras llegan los paquetes, los resúmenes de enlaces de netpadd informan percentiles de retraso, caídas tardías y paradas.	Se trata de diagnósticos e implementación ascendente, no de una medición de red realizada por este sitio.

El artículo anterior 0.17.1 registra esa versión, incluido el antiguo tiempo de espera del cliente de 250 ms. No lleve ese número a 0.17.2: la nueva configuración tiene stale_ms = 300 y timeout_ms = 1000. El teclado USB/Bluetooth y el teclado UDP aún comparten el mismo mapa de botones, pero el servicio UDP opcional está dentro del alcance de la sincronización de red de dos etapas. Demonio estable anterior 0.17.1 · 12 de octubre ↗ Demonio estable oficial 0.17.2 · 13 de octubre ↗ Fijado 0.17.2 Diagnóstico de enlace y temporización del pad UDP ↗.

Registre primero la versión instalada y las anulaciones.

Línea base del robot de solo lectura

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

update check daemon verifica la fuente estable sin instalar. Guarde la versión real de la placa, las anulaciones de configuración, los enlaces de botones y la lista de políticas. Un pedido anticipado sin robot no tiene nada que actualizar. El manifiesto de política oficial v8 no ha cambiado desde la revisión del 13 de octubre; la liberación de un demonio no prueba que un robot ejecute esa política. Controlador 0.17.2 fijado y comandos de actualización ↗ Manifiesto oficial del conjunto de políticas v8 sin cambios ↗.

Remapea palos con una edición estrecha y reversible.

En un robot compatible oficial, ejecute sudo robotctl configure y busque pad_axes. El siguiente ejemplo mueve el joystick derecho hacia adelante/atrás, gira con el joystick izquierdo con una ganancia de 0,7 y reduce el rango de comando de avance/atrás solicitado. Es TOML para ingresar en el editor, no un comando de shell:

Ejemplo de anulaciones de configuración, no comandos de terminal

[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

El modo de conducción enviado (pad direccional izquierdo) usa la Y izquierda para avanzar/atrás, la X izquierda para ametrallar y la X derecha para guiñar, con las direcciones de ametrallamiento y guiñada invertidas. La zona muerta predeterminada es 0,1 y cada enlace comienza con una ganancia de 1,0. Los campos faltantes conservan su origen y dirección de envío. gain se aplica antes de sujetar hasta alcanzar la deflexión total; source = "none" desactiva ese comando. Elimine una anulación para devolver ese modo a su valor predeterminado. Los cambios del eje del pad y del límite de conducción llegan a los controladores Bluetooth y UDP en aproximadamente un segundo sin reiniciar los servicios; una edición no válida deja activa la asignación anterior y se registra. Mantenga el robot apoyado y pruebe un eje a la vez, porque un error de señal o modo puede moverlo inesperadamente. Al cambiar netpad.enabled, por el contrario, se cambia qué pad daemon se ejecuta y sigue su procedimiento de aplicación/reinicio por separado. Controlador 0.17.2 fijado y comandos de actualización ↗ Valores predeterminados del eje del pad fijado y validación de anulación ↗ Comportamiento de aplicación de configuración de robotctl fijado ↗.

Comprenda los dos umbrales de pérdida de UDP.

El teclado UDP opcional permanece deshabilitado de forma predeterminada y es solo para una LAN confiable: el puerto 4210 no tiene autenticación ni cifrado. En 0.17.2, stale_ms tiene el valor predeterminado 300 y debe estar por debajo de [safety] deadman_ms (500 predeterminado); timeout_ms por defecto es 1000 y debe ser al menos stale_ms. En el primer umbral, el robot deja de caminar mientras el remitente mantiene su sesión. Si se reanuda una nueva entrada antes del segundo umbral, ese remitente puede continuar; el antiguo estado del stick no se repite. En el segundo umbral, la sesión se libera y la respuesta ordinaria de pad-gone puede solicitar sentarse aproximadamente un segundo después. Ninguna etapa garantiza una parada física inmediata o una sentada exitosa en cada postura. Diagnóstico de enlace y temporización del pad UDP 0.17.2 fijado ↗ Ejemplos de configuración de netpad y controlador fijado ↗ Implementación de datagramas tardíos y obsoletos de UDP fijado ↗.

El receptor también rechaza los datagramas que llegan demasiado tarde en relación con la entrega más rápida de esa transmisión, por lo que presionar un botón en una acumulación de Wi-Fi en cola no debería activarse después del hecho. Mientras siguen llegando datagramas, registra un resumen link: para aproximadamente cada ventana de muestra de diez segundos con retraso adicional de p50/p99/max, caídas tardías y paradas. Una interrupción completa de la entrada no necesita producir un nuevo resumen. Un remitente personalizado que establece su campo de marca de tiempo en cero no obtiene esta verificación de retraso; el duckctl udp-pad oficial utiliza la ruta del cliente publicada. Estas son reglas de software, no una promesa sobre ninguna red inalámbrica. Para inspeccionar un demonio UDP en ejecución en el robot:

Leer diagnóstico de enlace netpadd

journalctl -u netpadd -b

El paquete para computadora portátil duckctl 0.17.2 está publicado para macOS, Linux y Windows. La guía de configuración UDP anterior todavía explica la habilitación de LAN confiable; utilice los tiempos 0.17.2 anteriores después de actualizar. Paquete de computadora portátil duckctl 0.17.2 publicado ↗.

Actualice solo cuando la fuente estable y la placa coincidan.

Apoye al robot, mantenga la energía estable y permita que los servicios del demonio se reinicien. Si el verificador estable ofrece 0.17.2 para la placa declarada, instálelo intencionalmente:

Instalar un demonio estable ofrecido

sudo robotctl update apply daemon

Compare la versión en ejecución, la configuración, los enlaces, la lista de políticas, el estado y el historial de actualizaciones con la línea base guardada. Las anulaciones de joystick configuradas y las ranuras de políticas cargadas manualmente merecen una inspección explícita; Este sitio no tiene ningún resultado de actualización física que sustituya esa verificación.

Verifique el resultado de ejecución

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

Si la actualización falla, inspeccione update show y update log antes de actuar. Una reversión manual del demonio necesita una versión anterior ya instalada en esa placa y no revierte el conjunto de políticas v8 con versión independiente:

Solo si está instalada una versión anterior del demonio

sudo robotctl update rollback daemon
robotctl version
robotctl health

Leer la fuente original ↗

FUENTES Y REVISIÓN

Verificación de fuente: 2026-10-14. El alcance de la verificación se establece en la guía; La revisión de la fuente por sí sola no es una prueba de hardware.