Microduck 0.17.2 descarta órdenes que llegan tarde por wifi
Microduck 0.17.2 separa una pausa de wifi de una desconexión al conducirlo desde el ordenador. Añade filtros de órdenes tardías y ajustes para los joysticks.

Soltar un joystick deja de ser una orden útil si el robot la recibe después de varias instrucciones antiguas de avance. Pollen Robotics Microduck 0.17.2 filtra mensajes retrasados al conducirlo por la red local y distingue un corte breve de una desconexión completa. Sirve para experimentar con un mando conectado al ordenador, sin que cada bache de wifi obligue a empezar otra sesión.
La versión estable daemon 0.17.2, publicada el 13 de octubre [en], incorpora esos cambios y permite modificar qué hace cada eje del joystick. Es un seguimiento de Microduck 0.16.1 y su reacción al perder el mando, centrado ahora en el envío de órdenes desde otro equipo. La actualización modifica el control; no añade navegación autónoma.
Dos tiempos de espera para conservar la sesión
El cambio de gestión de interrupciones [en] separa dos situaciones. Con los valores predeterminados, 300 milisegundos sin un mensaje aceptado anulan la velocidad de marcha, pero mantienen la posición de cabeza y cuerpo. El cliente conserva el control, las pulsaciones y los botones que estaba manteniendo. Si vuelve antes de agotar el segundo plazo, puede continuar sin reconstruir la sesión.
Tras 1.000 milisegundos de silencio, el cliente se considera desconectado y libera el control. Un segundo después se solicita sentarse si el robot estaba de pie. La maniobra puede rechazarse durante una patada o una transición, por lo que ese plazo no garantiza que termine sentado. Son tiempos del programa, no una distancia física de frenado medida.
Antes, explica el desarrollador, el servicio podía seguir reenviando la última posición del joystick mientras esperaba la desconexión. El nuevo comportamiento deja de alimentar el movimiento con ese estado antiguo. Su descripción declara pruebas de software en macOS y señala que el cambio todavía no se había probado en una placa: la versión publicada no aporta un ensayo físico de frenado en distintos suelos.
Un mensaje reciente puede contener una orden antigua
El filtro de mensajes tardíos [en] aborda otro problema: la wifi puede retener paquetes y soltarlos después, conservando su orden. Comprobar únicamente que el número de secuencia crece no descubre ese retraso.
El receptor utiliza la marca temporal del emisor y compara la entrega con la más rápida observada en ese flujo, sin exigir sincronizar los relojes. En 0.17.2, el límite utiliza stale_ms, los mismos 300 milisegundos predeterminados de la pausa. Si el emisor escribe cero en la marca temporal, esa comprobación no se realiza, según el código de esta versión [en]. Es una condición relevante para quien escriba su propio programa de control.
Las recomendaciones de la IETF para UDP [en] describen la necesidad de gestionar mensajes retrasados, duplicados o desordenados desde la aplicación. Aportan el contexto técnico del filtro, sin certificar su implementación en Microduck. Para observar la conexión, el servicio registra retrasos y paradas por falta de mensajes; esos datos permiten distinguir una pérdida de enlace de un botón que no ha producido la acción esperada.
El mando USB pasa por el ordenador
La guía de control UDP fijada a 0.17.2 [en] describe duckctl udp-pad: lee el primer mando conectado al portátil y envía su estado al robot en la misma red. Con una dirección IP explícita no necesita Bluetooth para localizarlo. Hace falta instalar duckctl en el ordenador y activar el receptor en Microduck; viene desactivado por defecto.
Activarlo sustituye al mando Bluetooth y permanece activo entre reinicios y actualizaciones hasta deshabilitarlo. El receptor UDP no tiene autenticación: cualquier equipo que alcance su puerto en esa red puede intentar conducir o apagar el robot. El fabricante lo limita a una red de confianza y dirige el control desde fuera de ella a su vía WebRTC autenticada y cifrada. Esta opción doméstica no debe interpretarse como acceso remoto preparado para internet.
La configuración de ejes añadida en esta versión [en] permite cambiar el joystick de giro o reducir su sensibilidad sin recompilar. Se aplica tanto a Bluetooth como a UDP. Es útil al preparar un mando propio, pero el autor también documenta validación en el ordenador, sin una prueba con el robot físico.
El manual de actualización [en] permite consultar el canal estable con robotctl update check daemon e instalar lo que ofrezca con sudo robotctl update apply daemon. Conviene comprobar la versión resultante. Una configuración UDP antigua que fije explícitamente timeout_ms = 250 requiere revisión: queda por debajo del nuevo umbral predeterminado de pausa.
Para quien aún no tenga uno de estos bípedos programables, la tienda europea ofrece Microduck Cream por 340 euros, con mando incluido [en]. España figura entre los destinos seleccionables; el total del pedido requiere concretar sus cargos. Sigue en preventa: el aviso principal estima cuatro a seis meses para pedidos nuevos y ya no promete Navidad, aunque la descripción inferior conserva el calendario inicial.
Fuentes
- Pollen Robotics — daemon 0.17.2, versión estable del 13 de octubre [en]
- Pollen Robotics — pausa breve, desconexión, cambios de configuración y alcance de las pruebas [en]
- Pollen Robotics — filtro de mensajes entregados tarde [en]
- Pollen Robotics — receptor fijado a 0.17.2 y comprobación de la marca temporal [en]
- IETF — RFC 8085, fiabilidad y tratamiento de mensajes UDP retrasados [en]
- Pollen Robotics — control desde un portátil, tiempos de espera y límites de confianza [en]
- Pollen Robotics — configuración de ejes y sensibilidad, con pruebas de software [en]
- Pollen Robotics — manual de uso y actualización de 0.17.2 [en]
- Pollen Robotics — oferta europea de Microduck Cream y aviso de preventa [en]
- Imagen: fotografía oficial de Microduck y mandos en una mesa de trabajo, cortesía de Pollen Robotics [en]
Sigue explorando
Robots relacionados
Descubre sus fichas y todo lo que hemos contado sobre ellos.