Diagnóstico MicroDuck: mando, CUDA, carga y ONNX

Si el mando de un MicroDuck físico oficial no responde, comprueba el daemon activo, la fuente de entrada, la conexión, el estado de padd y las asignaciones reales. Lee los registros antes de volver a emparejar o editar Bluetooth.

Comience en la primera etapa fallida.

Utilice la mesa que coincida con su entorno. Un problema de carga del navegador, una falta de dependencia de Python y una discrepancia en la forma de ONNX ocurren en diferentes etapas. Mantenga el error original antes de cambiar de versión; de lo contrario, puede perder la pista que identifica la capa que falla.

Problemas con el simulador de navegador.

Síntomas del navegador y próxima comprobación.
Síntoma	Prueba esto	que grabar
Atascado en la carga	Abra el simulador directo. Pruebe la vista de diagnóstico de arranque oficial ↗. Espere a que finalice el paso de su activo o política.	Versión del navegador, último paso de carga y cualquier error de SISTEMA DETENIDO. Una falla transitoria de la red no es evidencia de que su GPU no pueda entrenarse.
El robot ignora las flechas.	Ingrese o reanude la escena, haga clic en ella para enfocarla y luego mantenga presionada una flecha. Pruebe la página directa si el contenedor está capturando claves.	Si la superposición de bienvenida se cerró, si la página se desplazó y si la lectura de velocidad cambió.
R se sienta en lugar de rodar	Utilice el mapa de claves del navegador actual. R ahora controla sentarse/pararse en el modo de pies.	La URL del tutorial y la revisión del simulador. No sustituya atajos del visor local de Python.
Las patadas fallan después de cambiar de modo	Regrese al modo Pies. Las patadas y los ataques al suelo son acciones que se realizan únicamente con las piernas; el primer interruptor de rodillos también tiene carga adicional.	Modo seleccionado y si sus activos terminaron de cargarse.

Estas comprobaciones combinan nuestra comprobación de entrada/caminar/reinicio del escritorio con el Simulador README: modos, carga y controles ↗ y Implementación del teclado del navegador ↗. No se implica ninguna evaluación comparativa del navegador ni afirmación de compatibilidad móvil.

Problemas de instalación y CUDA.

Síntomas de dependencia y GPU
Síntoma	Próximo cheque
Versión de Python rechazada	Ejecuta `uv run python --version` desde la copia local del repositorio. Esta revisión requiere Python 3.12; sigue los pasos de configuración de la revisión fijada.
La GPU existe, pero CUDA es falsa o el recuento de GPU es 0	Ejecute la sonda Python/CUDA desde el mismo entorno que el entrenamiento. Registre la versión de PyTorch y la compilación, el sistema operativo y la arquitectura de CUDA. En Linux ARM, inspeccione la fuente de rueda seleccionada del proyecto antes de cambiar los controladores.
Se agota el tiempo de descarga de la dependencia ARM	El inicio rápido oficial sugiere un tiempo de espera HTTP uv más largo para la primera descarga grande de CUDA-wheel. Pruebe la configuración de un solo comando a continuación. Solo aborda los tiempos de espera de descarga.
Jetson Thor: falta la biblioteca NVPL o cuDSS	Lea el número 38 con su JetPack, controlador y arquitectura exactos. Documenta un problema de paquete específico de Thor; una receta de paquete GB10 no es automáticamente una receta Jetson. El informe todavía estaba abierto a revisión.
Se ejecuta un comando de tren no relacionado o falta el tren	Utilice `uv run train` dentro dla copia local del repositorio sincronizado. El proyecto posee intencionalmente este punto de entrada; su archivo de dependencia documenta una colisión ejecutable anterior. Vuelva a sincronizar la revisión correspondiente antes de modificar la RUTA de su sistema.
CUDA sin memoria	Registre el error de asignación, la memoria de la GPU y el recuento del entorno. Cierre solo sus propios trabajos de GPU no utilizados y luego vuelva a intentar la misma tarea con menos entornos. Se trata de una reducción del diagnóstico, no de una cura garantizada para cada error de asignación.

Reintentar una descarga de dependencia agotada

UV_HTTP_TIMEOUT=600 uv sync --locked --python 3.12

Ejecute esa asignación de una línea en un shell POSIX como bash o zsh. Las restricciones subyacentes y la colisión ejecutable están documentadas en Python, versiones fijadas de dependencias y fuentes de paquetes ARM ↗; El descubrimiento de GPU se describe en PyTorch: comprobar la disponibilidad de CUDA ↗. Informe #38 de Jetson Thor (informe de la comunidad, abierto en revisión) ↗ es un informe de usuario, no una solución probada por este sitio.

Problemas de exportación y reproducción.

Síntomas de política y controles coincidentes
Síntoma	Próximo cheque
ONNX espera 61 entradas pero recibe un diseño más antiguo	Para el contrato de póliza actual revisado, utilice `--new-cmd-obs` en el visor local. Déjelo desactivado para políticas heredadas de 51 entradas. Confirme la forma de entrada real antes de elegir.
Un archivo.pt no se cargará como ONNX	Utilice el exportador de puntos de control oficial. Los tipos de archivos tienen diferentes propósitos; cambiar el nombre de un punto de control no lo convierte.
La reproducción parece plausible, pero la repetición exportada se comporta mal.	Verificar que el exportador oficial haya incluido la normalización de observaciones. Luego compare la tarea, el punto de control, el modelo de robot, la escala de acción y el diseño del comando. Esta es una orden de investigación, no un diagnóstico de su póliza específica.
Un trabajo remoto continúa después de Ctrl-C	Abra la URL del trabajo guardado, inspeccione su estado y cancele explícitamente si corresponde. La interrupción del flujo de registro no detiene el trabajo.

Inspeccione indicadores de reproducción locales y controles de teclado ↗ y Exportador oficial de ONNX y normalización de observación ↗ para conocer el diseño y el comportamiento de normalización. El comportamiento del registro de la nube está documentado en Guía de envío de trabajos en la nube de MicroDuck ↗; la cancelación está cubierta en Hugging Face: gestión y cancelación de trabajos ↗.

En un robot oficial, separe un problema de teclado Bluetooth de un cambio de fuente de control.

Esta sección es una ruta de diagnóstico revisada en el código fuente para el demonio oficial 0.17.2, lanzado el 13 de octubre; el sitio lo revisó el 14 de octubre y no emparejó una plataforma ni operó un robot. No describe una réplica ni el simulador de navegador. La página oficial de emparejamiento de Bluetooth y el script del historial ya existían antes de la versión 0.17.2. versión 0.17.2 ↗ guía de emparejamiento y enlace ↗.

Guarde la línea base de solo lectura a continuación antes de intentar un nuevo enlace, un reinicio del servicio o una configuración del controlador. configure --list enumera anulaciones, por lo que ninguna línea netpad.enabled generalmente significa el valor predeterminado false, no una consulta fallida. Las dos líneas de salida de systemctl se ordenan padd, luego netpadd. Esta es una verificación de selección de fuente, no otro tutorial de configuración de UDP; la guía de lanzamiento de 0.17.2 explica la nueva sincronización de UDP. comandos oficiales ↗ selección de fuente ↗.

Línea base del pad de solo lectura en el robot

robotctl version
robotctl configure --list
systemctl is-active padd netpadd
robotctl pad status
robotctl pad bindings
robotctl logs padd -n 100
robotctl logs bluetooth -n 100

Síntomas oficiales de la plataforma robótica y la siguiente evidencia para leer
lo que ves	lo que puede significar	Siguiente paso
`padd` inactivo; `netpadd` activo	UDP es la fuente seleccionada, por lo que un pad Bluetooth no puede funcionar durante esa configuración.	Comprueba la configuración que fuerza la fuente de entrada y consulta la guía actual para cambiar de fuente; no vuelvas a emparejar un mando Bluetooth para corregir una selección deliberada de UDP.
`padd` activo; no hay almohadilla conectada	El controlador se está ejecutando, pero no hay ninguna entrada Bluetooth actual. Un pad que se muestra como emparejado pero NO confiable puede funcionar ahora pero no puede volver a conectarse después de reiniciar.	Registre los registros `pad status` y `padd` / `bluetooth`. Si la falla identificada es la confianza, siga los pasos de emparejamiento específicos del controlador original; No borres todos los vínculos primero.
Almohadilla conectada; `padd` inactivo	El enlace de radio y el conductor pueden fallar por separado. Un icono conectado por sí solo no prueba que el robot reciba el control.	Compare ambos estados de servicio y el diario `padd`. Si ninguna fuente se inicia, informe su primer error de servicio antes de cambiar la configuración.
Pad conectado y controlador activo; un botón no hace nada	Un enlace o modo puede explicarlo. Desde 0.16.2, X/Y/LB/RB no tienen acción predeterminada; 0.17.2 también puede anular los ejes, las ganancias y los límites del stick.	Lea `pad bindings`, `configure --list` y el modo actual. Una lista de anulación vacía no imprime todos los valores predeterminados efectivos.
Pad conectado y controlador activo; la entrada parece congelarse mientras se conduce	Una parada de radio es diferente a una desconexión. `padd` puede reenviar el último valor del stick a 50 Hz, por lo que una nueva intención descendente no es prueba de informes nuevos del pad.	Primero verifique el diario `padd`. El panel oficial `robotctl monitor` `p` muestra lagunas en el informe evdev sin procesar, pero interpretarlo mientras se mueven los dispositivos requiere una prueba de hardware controlada y compatible.

La guía de emparejamiento ↗ original distingue un controlador conectado de un controlador activo, y su ejemplo de Pro Controller muestra por qué la conexión manual antes del emparejamiento no puede dejar ningún dispositivo de entrada. No cambie BlueZ Privacy por conjeturas: el documento oficial registra diferentes motivos de falla que requieren diferentes configuraciones. Su script de historial ↗ lee registros de diario del kernel y padd existentes sin un panel activo; un tiempo de espera de supervisión 0x08 indica alcance o interferencia, mientras que 0x13/0x16 indica que el pad estaba apagado. La falta de un historial no prueba un vínculo confiable y una plataforma de descanso no envía informes. Nunca llame a una prueba de dispositivo en vivo como de solo lectura simplemente porque el comando del monitor solo lee datos.

Cuando comparta una pregunta, incluya la versión del demonio, los estados fuente en orden, las dos líneas pad status, las combinaciones de botones reales y un breve extracto del registro con marca de tiempo. Elimine las direcciones del controlador, las IP locales, los números de serie y los detalles de la cuenta. Indique si la observación provino de un robot físico oficial; una simulación de navegador no puede probar su radio Bluetooth. La parada stale_ms UDP 0.17.2 y la pérdida de sesión timeout_ms se aplican a netpadd, no a este diagnóstico de teclado Bluetooth. Máquina de estado UDP ↗ Manejo de paradas y pérdidas ↗.

Envíe un informe sobre el cual alguien pueda actuar.

Reemplace los campos a continuación con lo que observó. Incluya un extracto de error breve y relevante; elimine tokens y rutas personales antes de compartir. “Lo último que funcionó” suele ser más útil que una captura de pantalla de la excepción final únicamente.

Plantilla de informe de resolución de problemas

Objetivo:
Etapa del fallo (navegador / instalación / CUDA / entrenamiento / exportación / reproducción):
URL de página o repositorio y commit completo:
Sistema operativo y arquitectura:
Versiones de navegador O Python / uv / PyTorch / CUDA:
GPU y controlador, si corresponde:
ID de tarea / fuente de la política / dimensiones de entrada:
Comando o secuencia de acciones exactos:
Comportamiento esperado:
Comportamiento real:
Primer error (extracto breve sin secretos):
Último paso satisfactorio:
Un cambio probado y su resultado:

Iniciar una discusión relacionada →. Para un posible error ascendente, incluya la misma reproducción mínima en el canal de soporte disponible del proyecto original.

Continúe con su resultado.

Repita las comprobaciones del entorno → Verifique la ruta de exportación y reproducción →

CONTINUAR LA CONVERSACIÓN

¿Qué te gustaría entender a continuación?

Mantenga juntos la fuente, su entorno y sus observaciones.

Iniciar una discusión relacionada → Leer discusiones relacionadas →

Fuentes y fecha de revisión

Fuentes comprobadas el 14 de octubre de 2026 · Fuente revisada