Dépannage MicroDuck : manette, CUDA et ONNX

Si la manette d’un MicroDuck physique officiel paraît inactive, vérifiez daemon actif, source d’entrée, connexion, état de padd et affectations réelles. Lisez les journaux avant de refaire l’appairage ou de modifier Bluetooth.

Commencez par la première étape défaillante.

Utilisez le tableau correspondant à votre environnement. Un problème de chargement du navigateur, une dépendance Python manquante et une incompatibilité de forme ONNX se produisent à différentes étapes. Conservez l'erreur d'origine avant de changer de version ; sinon, vous risquez de perdre l'indice qui identifie la couche défaillante.

Problèmes de simulateur de navigateur.

Symptômes du navigateur et prochaine vérification
Symptôme	Essayez ceci	Quoi enregistrer
Coincé lors du chargement	Ouvrez le simulateur direct. Essayez la vue officielle du diagnostic de démarrage ↗. Attendez que son actif ou son étape politique soit terminé.	Version du navigateur, dernière étape de chargement et toute erreur SYSTEM HALTED. Une panne réseau passagère ne prouve pas que votre GPU ne peut pas s'entraîner.
Le robot ignore les flèches	Entrez ou reprenez la scène, cliquez dessus pour lui donner le focus, puis maintenez une flèche enfoncée. Essayez la page directe si le wrapper capture les clés.	Si la superposition de bienvenue s'est fermée, si la page a défilé et si la vitesse de lecture a changé.
R s'assoit au lieu de rouler	Utilisez la carte des touches du navigateur actuelle. R contrôle désormais la position assise/debout en mode pieds.	L'URL du didacticiel et la révision du simulateur. Ne remplacez pas les raccourcis du visualiseur Python local.
Les coups de pied échouent après avoir changé de mode	Revenir au mode Pieds. Les coups de pied et le choix au sol sont des actions utilisant uniquement les jambes ; le premier commutateur Rollers a également une charge supplémentaire.	Mode sélectionné et si ses actifs ont fini de se charger.

Ces vérifications combinent notre vérification d'entrée/marche/réinitialisation du bureau avec le Simulateur README : modes, chargement et contrôles ↗ et Implémentation du clavier du navigateur ↗. Aucune référence de navigateur ou réclamation de compatibilité mobile n’est implicite.

Problèmes d'installation et de CUDA.

Symptômes de dépendance et de GPU
Symptôme	Vérification suivante
Version Python rejetée	Exécutez `uv run python --version` depuis la copie locale du dépôt. Cette révision exige Python 3.12 ; suivez les étapes de configuration de la révision fixée.
Le GPU existe, mais CUDA est False ou le nombre de GPU est 0	Exécutez la sonde Python/CUDA à partir du même environnement que l’entraînement. Enregistrez la version de PyTorch et la version CUDA, le système d'exploitation et l'architecture. Sous Linux ARM, inspectez la source de roue sélectionnée pour le projet avant de changer de pilote.
Le téléchargement des dépendances ARM expire	Le démarrage rapide officiel suggère un délai d'attente HTTP UV plus long pour le premier gros téléchargement de la roue CUDA. Essayez le paramètre à une commande ci-dessous. Il ne traite que les délais d'attente de téléchargement.
Jetson Thor : bibliothèque NVPL ou cuDSS manquante	Lisez le numéro 38 avec votre JetPack, votre pilote et votre architecture exacts. Il documente un problème de package spécifique à Thor ; une recette de package GB10 n'est pas automatiquement une recette Jetson. Le rapport était encore ouvert au moment de son examen.
Une commande de train sans rapport fonctionne ou le train est manquant	Utilisez `uv run train` dans la copie locale du dépôt synchronisée. Le projet possède intentionnellement ce point d'entrée ; son fichier de dépendances documente une précédente collision d'exécutable. Resynchronisez la révision correspondante avant de modifier le PATH de votre système.
CUDA manque de mémoire	Enregistrez l'erreur d'allocation, la mémoire GPU et le nombre d'environnements. Fermez uniquement vos propres tâches GPU inutilisées, puis réessayez la même tâche avec moins d'environnements. Il s’agit d’une réduction diagnostique et non d’une guérison garantie pour chaque échec d’allocation.

Réessayez un téléchargement de dépendance expiré

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

Exécutez cette affectation sur une ligne dans un shell POSIX tel que bash ou zsh. Les contraintes sous-jacentes et les collisions exécutables sont documentées dans Python, les versions figées des dépendances et les sources du package ARM ↗ ; La découverte de GPU est décrite par PyTorch : vérification de la disponibilité de CUDA ↗. Rapport Jetson Thor n°38 (rapport communautaire, ouvert à la révision) ↗ est un rapport d'utilisateur, pas un correctif testé par ce site.

Problèmes d'exportation et de relecture.

Symptômes de stratégie et vérifications de correspondance
Symptôme	Vérification suivante
ONNX attend 61 entrées mais reçoit une disposition plus ancienne	Pour le contrat de police actuel révisé, utilisez `--new-cmd-obs` dans le visualiseur local. Laissez-le désactivé pour les anciennes politiques à 51 entrées. Confirmez la forme d'entrée réelle avant de choisir.
Un fichier.pt ne se chargera pas en tant qu'ONNX	Utilisez l'exportateur de point de contrôle officiel. Les types de fichiers répondent à des objectifs différents ; renommer un point de contrôle ne le convertit pas.
la lecture semble plausible, mais la relecture exportée se comporte mal	Vérifiez que l'exportateur officiel a inclus la normalisation des observations. Comparez ensuite la tâche, le point de contrôle, le modèle de robot, l'échelle d'action et la disposition des commandes. Il s’agit d’une ordonnance d’enquête et non d’un diagnostic de votre politique spécifique.
Un travail à distance continue après Ctrl-C	Ouvrez l'URL de la tâche enregistrée, inspectez son statut et annulez explicitement le cas échéant. L'interruption du flux de journaux n'arrête pas le travail.

Inspectez Indicateurs de lecture locale et commandes du clavier ↗ et Exportateur officiel ONNX et normalisation des observations ↗ pour le comportement de mise en page et de normalisation. Le comportement du journal cloud est documenté dans Guide de soumission des tâches cloud MicroDuck ↗ ; l'annulation est couverte dans Hugging Face : gestion et annulation des tâches ↗.

Sur un robot officiel, séparez un problème de pad Bluetooth d'un changement de source de contrôle.

Cette section est un chemin de diagnostic révisé par les sources pour le démon officiel 0.17.2, publié le 13 octobre ; le site l'a examiné le 14 octobre et n'a pas couplé de pad ni fait fonctionner de robot. Il ne décrit ni une réplique ni le simulateur de navigateur. La page officielle de couplage Bluetooth et le script d'historique existaient déjà avant la 0.17.2. Version 0.17.2 ↗ Guide d'appairage et de liaison ↗.

Enregistrez la ligne de base en lecture seule ci-dessous avant de tenter une nouvelle liaison, un redémarrage de service ou un paramètre de contrôleur. configure --list répertorie les remplacements, donc aucune ligne netpad.enabled signifie généralement la valeur par défaut false, pas une requête ayant échoué. Les deux lignes de sortie de systemctl sont ordonnées padd, puis netpadd. Il s'agit d'une vérification de sélection de source, pas d'un autre didacticiel de configuration UDP ; le guide de version 0.17.2 explique le nouveau timing UDP. commandes officielles ↗ sélection de source ↗.

Ligne de base du pad en lecture seule sur le 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

Symptômes du tampon de robot officiel et prochaines preuves à lire
Ce que tu vois	Ce que cela peut signifier	Étape suivante
`padd` inactif ; `netpadd` actif	UDP est la source sélectionnée, donc un pad Bluetooth ne peut pas piloter pendant cette configuration.	Vérifiez la configuration qui impose la source d’entrée et consultez le guide actuel de changement de source ; ne réappairez pas une manette Bluetooth pour corriger un choix volontaire d’UDP.
`padd` actif ; aucun pad connecté	Le pilote est en cours d'exécution, mais il n'y a aucune entrée Bluetooth actuelle. Un pad affiché comme couplé mais NON fiable peut fonctionner maintenant mais ne parvient pas à se reconnecter après un redémarrage.	Enregistrez les journaux `pad status` et `padd` / `bluetooth`. Si la confiance est le défaut identifié, suivez les étapes d'appariement spécifiques au contrôleur d'origine ; n’effacez pas d’abord tous les liens.
Pad connecté ; `padd` inactif	La liaison radio et le pilote peuvent échouer séparément. Une icône connectée ne prouve pas à elle seule que le robot en reçoit le contrôle.	Comparez les deux états de service et le journal `padd`. Si aucune des deux sources ne démarre, signalez sa première erreur de service avant de modifier les paramètres.
Pad connecté et pilote actif ; un bouton ne fait rien	Une liaison ou un mode peut l'expliquer. Depuis la version 0.16.2, X/Y/LB/RB n'ont plus d'action par défaut ; 0.17.2 peut également remplacer les axes, les gains et les limites du stick.	Lisez `pad bindings`, `configure --list` et le mode actuel. Une liste de remplacement vide n'imprime pas toutes les valeurs par défaut effectives.
Pad connecté et pilote actif ; l'entrée semble se figer pendant la conduite	Un décrochage radio est différent d’une déconnexion. `padd` peut renvoyer la dernière valeur du stick à 50 Hz, donc une nouvelle intention en aval n'est pas une preuve de nouveaux rapports de pad.	Vérifiez d'abord le journal `padd`. Le panneau officiel `robotctl monitor` `p` montre des lacunes brutes dans le rapport evdev, mais son interprétation lors du déplacement des bâtons nécessite un test matériel pris en charge et contrôlé.

Le guide d'appairage original ↗ distingue un contrôleur connecté d'un pilote actif, et son exemple de contrôleur Pro montre pourquoi la connexion manuelle avant l'appairage ne peut laisser aucun périphérique d'entrée. Ne modifiez pas BlueZ Privacy par conjecture : le document officiel enregistre différentes raisons de panne nécessitant des réglages différents. Son script d'historique ↗ lit les enregistrements padd existants et le journal du noyau sans live pad ; un délai d'attente de supervision 0x08 indique une portée ou une interférence, tandis que 0x13/0x16 indique que le pad a été éteint. L’historique manquant ne prouve pas un lien fiable et une plate-forme de repos n’envoie aucun rapport. N'appelez jamais un test Live Stick en lecture seule simplement parce que la commande Monitor ne lit que les données.

Lorsque vous partagez une question, incluez la version du démon, les états sources dans l'ordre, les deux lignes pad status, les liaisons de boutons réelles et un court extrait de journal horodaté. Supprimez les adresses du contrôleur, les adresses IP locales, les numéros de série et les détails du compte. Indiquez si l'observation provient d'un robot physique officiel ; une simulation de navigateur ne peut pas tester sa radio Bluetooth. L'arrêt 0.17.2 UDP stale_ms et la perte de session timeout_ms s'appliquent à netpadd, pas à ce diagnostic de pad Bluetooth. Machine à états UDP ↗ Gestion des arrêts et des pertes ↗.

Envoyez un rapport sur lequel quelqu'un peut agir.

Remplacez les champs ci-dessous par ce que vous avez observé. Incluez un court extrait d’erreur pertinent ; supprimez les jetons et les chemins personnels avant de partager. « Ce qui a fonctionné en dernier » est souvent plus utile qu'une capture d'écran de la seule exception finale.

Modèle de rapport de dépannage

Objectif :
Étape en échec (navigateur / installation / CUDA / entraînement / export / exécution) :
URL de la page ou dépôt et commit complet :
Système et architecture :
Versions du navigateur OU de Python / uv / PyTorch / CUDA :
GPU et pilote, si pertinent :
Identifiant de tâche / source de la politique / dimensions d’entrée :
Commande ou séquence d’actions exacte :
Comportement attendu :
Comportement réel :
Première erreur (court extrait sans secrets) :
Dernière étape réussie :
Une modification essayée et son résultat :

Démarrer une discussion connexe →. Pour un bug suspecté en amont, incluez la même reproduction minimale sur le canal de support disponible du projet d’origine.

Continuez avec votre résultat.

Répétez les vérifications de l'environnement → Vérifiez le chemin d'exportation et de relecture →

CONTINUER LA CONVERSATION

Qu’aimeriez-vous comprendre ensuite ?

Gardez la source, votre environnement et vos observations ensemble.

Démarrer une discussion connexe → Lire les discussions connexes →

Sources et date de vérification

Sources vérifiées le 14 octobre 2026 · Source examinée