MicroDuck-Fehlersuche: Gamepad, CUDA und ONNX

Wenn das Gamepad eines offiziellen echten MicroDuck nicht reagiert, prüfe laufenden Daemon, Eingabequelle, Verbindung, padd-Zustand und tatsächliche Belegung. Lies Protokolle, bevor du neu koppelst oder Bluetooth-Einstellungen änderst.

Beginnen Sie mit der ersten fehlgeschlagenen Phase.

Verwenden Sie die zu Ihrer Umgebung passende Tabelle. Ein Problem beim Laden des Browsers, eine fehlende Python-Abhängigkeit und eine Nichtübereinstimmung der ONNX-Form treten in verschiedenen Phasen auf. Behalten Sie den ursprünglichen Fehler bei, bevor Sie die Version ändern. Andernfalls verlieren Sie möglicherweise den Hinweis, der die fehlerhafte Ebene identifiziert.

Probleme mit dem Browsersimulator.

Browser-Symptome und die nächste Überprüfung
Symptom	Probieren Sie es aus	Was soll aufgezeichnet werden?
Beim Laden hängengeblieben	Öffnen Sie den Direktsimulator. Probieren Sie die offizielle Boot-Diagnoseansicht ↗ aus. Warten Sie, bis der Asset- oder Policiesschritt abgeschlossen ist.	Browserversion, der letzte Ladeschritt und ein eventueller SYSTEM HALTED-Fehler. Ein vorübergehender Netzwerkausfall ist kein Beweis dafür, dass Ihre GPU nicht trainieren kann.
Der Roboter ignoriert die Pfeile	Betreten Sie die Szene oder setzen Sie sie fort, klicken Sie darauf, um ihr den Fokus zu geben, und halten Sie dann einen Pfeil gedrückt. Probieren Sie die direkte Seite aus, wenn der Wrapper Schlüssel erfasst.	Ob das Willkommens-Overlay geschlossen wurde, ob die Seite gescrollt wurde und ob sich die Geschwindigkeitsanzeige geändert hat.
R sitzt statt zu rollen	Verwenden Sie die aktuelle Tastenbelegung des Browsers. R steuert jetzt Sitzen/Stehen im Fußmodus.	Die Tutorial-URL und die Simulatorrevision. Ersetzen Sie keine Verknüpfungen aus dem lokalen Python-Viewer.
Tritte schlagen nach dem Umschalten des Modus fehl	Kehren Sie zum Fußmodus zurück. Kicks und Groundpick sind reine Beinaktionen; Auch der erste Rollers-Schalter verfügt über eine zusätzliche Belastung.	Ausgewählter Modus und ob das Laden seiner Assets abgeschlossen ist.

Diese Prüfungen kombinieren unsere Desktop-Eingangs-/Geh-/Zurücksetzungsprüfung mit der Simulator-README: Modi, Laden und Steuerelemente ↗ und Browser-Tastatur-Implementierung ↗. Es wird kein Browser-Benchmark oder eine Mobilkompatibilitätsaussage impliziert.

Installations- und CUDA-Probleme.

Abhängigkeits- und GPU-Symptome
Symptom	Nächste Kontrolle
Python-Version abgelehnt	Führen Sie `uv run python --version` in der lokalen Arbeitskopie des Repositorys aus. Diese Revision benötigt Python 3.12. Folgen Sie den Einrichtungsschritten der festen Revision.
GPU ist vorhanden, aber CUDA ist falsch oder GPU-Anzahl ist 0	Führen Sie die Python/CUDA-Probe in derselben Umgebung aus wie das Training. Notieren Sie die Version und den CUDA-Build, das Betriebssystem und die Architektur von PyTorch. Überprüfen Sie unter Linux ARM die ausgewählte Wheel-Quelle des Projekts, bevor Sie den Treiber wechseln.
Zeitüberschreitung beim Herunterladen der ARM-Abhängigkeit	Der offizielle Schnellstart schlägt ein längeres UV-HTTP-Timeout für den ersten großen CUDA-Wheel-Download vor. Probieren Sie die Ein-Befehl-Einstellung unten aus. Es behebt nur Download-Timeouts.
Jetson Thor: fehlende NVPL- oder cuDSS-Bibliothek	Lesen Sie Ausgabe Nr. 38 mit Ihrem genauen JetPack, Treiber und Ihrer Architektur. Es dokumentiert ein Thor-spezifisches Paketproblem; Ein GB10-Paketrezept ist nicht automatisch ein Jetson-Rezept. Der Bericht war zum Zeitpunkt der Prüfung noch offen.
Ein nicht verwandter Zugbefehl wird ausgeführt oder der Zug fehlt	Verwenden Sie `uv run train` im synchronisierten Checkout. Das Projekt ist absichtlich Eigentümer dieses Einstiegspunkts. Seine Abhängigkeitsdatei dokumentiert eine frühere ausführbare Kollision. Synchronisieren Sie die passende Revision erneut, bevor Sie Ihren Systempfad ändern.
CUDA hat keinen Speicher mehr	Notieren Sie den Zuordnungsfehler, den GPU-Speicher und die Umgebungsanzahl. Schließen Sie nur Ihre eigenen ungenutzten GPU-Jobs und wiederholen Sie dann dieselbe Aufgabe mit weniger Umgebungen. Dies ist eine diagnostische Reduzierung und keine garantierte Heilung für jeden Zuordnungsfehler.

Wiederholen Sie einen Abhängigkeits-Download mit Zeitüberschreitung

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

Führen Sie diese einzeilige Zuweisung in einer POSIX-Shell wie bash oder zsh aus. Die zugrunde liegenden Einschränkungen und ausführbaren Kollisionen sind in Python, festgelegte Abhängigkeitsversionen und ARM-Paketquellen ↗ dokumentiert. Die GPU-Erkennung wird durch PyTorch: Überprüfen der CUDA-Verfügbarkeit ↗ beschrieben. Jetson Thor-Bericht Nr. 38 (Community-Bericht, bei Überprüfung geöffnet) ↗ ist ein Benutzerbericht, kein von dieser Site getesteter Fix.

Export- und Wiedergabeprobleme.

Policiessymptome und Übereinstimmungsprüfungen
Symptom	Nächste Kontrolle
ONNX erwartet 61 Eingänge, erhält aber ein älteres Layout	Für den überprüften aktuellen Policenvertrag verwenden Sie `--new-cmd-obs` im lokalen Viewer. Lassen Sie es für ältere 51-Eingabe-Policies weg. Bestätigen Sie die tatsächliche Eingabeform, bevor Sie auswählen.
Eine.pt-Datei wird nicht als ONNX geladen	Nutzen Sie den offiziellen Checkpoint-Exporter. Die Dateitypen dienen unterschiedlichen Zwecken; Durch das Umbenennen eines Prüfpunkts wird dieser nicht konvertiert.
Die Wiedergabe sieht plausibel aus, aber die exportierte Wiedergabe verhält sich schlecht	Überprüfen Sie, ob der offizielle Exporteur die Beobachtungsnormalisierung einbezogen hat. Vergleichen Sie dann Aufgabe, Kontrollpunkt, Robotermodell, Aktionsmaßstab und Befehlslayout. Hierbei handelt es sich um eine Untersuchungsanordnung, nicht um eine Diagnose Ihrer spezifischen Police.
Ein Remote-Job wird nach Strg-C fortgesetzt	Öffnen Sie die URL des gespeicherten Jobs, überprüfen Sie seinen Status und brechen Sie ihn ggf. explizit ab. Durch das Unterbrechen des Protokollstreams wird der Job nicht gestoppt.

Untersuchen Sie Lokale Wiedergabeflags und Tastatursteuerungen ↗ und Offizieller ONNX-Exporter und Beobachtungsnormalisierung ↗ auf das Layout und das Normalisierungsverhalten. Das Verhalten des Cloud-Protokolls ist im MicroDuck Cloud Job Submission Guide ↗ dokumentiert. Die Stornierung wird in Hugging Face: Aufträge verwalten und stornieren ↗ behandelt.

Trennen Sie bei einem offiziellen Roboter ein Problem mit dem Bluetooth-Pad von einer Änderung der Steuerquelle.

Dieser Abschnitt ist ein quellengeprüfter Diagnosepfad für den offiziellen Daemon 0.17.2, veröffentlicht am 13. Oktober; Die Website hat es am 14. Oktober überprüft und weder ein Pad gekoppelt noch einen Roboter bedient. Es beschreibt weder eine Replik noch den Browsersimulator. Die offizielle Bluetooth-Pairing-Seite und das Verlaufsskript existierten bereits vor 0.17.2. Version 0.17.2 ↗ Kopplungs- und Verbindungsanleitung ↗.

Speichern Sie die schreibgeschützte Baseline unten, bevor Sie eine neue Bindung, einen Dienstneustart oder eine Controller-Einstellung versuchen. configure --list listet Überschreibungen auf, daher bedeutet das Fehlen der Zeile netpad.enabled normalerweise den Standardwert false und keine fehlgeschlagene Abfrage. Die beiden Ausgabezeilen von systemctl werden mit padd und dann mit netpadd geordnet. Dies ist eine Überprüfung der Quellenauswahl und kein weiteres UDP-Setup-Tutorial. Der 0.17.2 Release Guide erklärt das neue UDP-Timing. offizielle Befehle ↗ Quellenauswahl ↗.

Schreibgeschützte Pad-Basislinie auf dem Roboter

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

Symptome des offiziellen Roboterpads und die nächsten zu lesenden Beweise
Was Sie sehen	Was es bedeuten kann	Nächster Schritt
`padd` inaktiv; `netpadd` aktiv	UDP ist die ausgewählte Quelle, sodass ein Bluetooth-Pad während dieser Konfiguration nicht fahren kann.	Prüfen Sie die konfigurierte Quellenüberschreibung und die aktuelle Anleitung zum Quellenwechsel. Koppeln Sie ein Bluetooth-Gamepad nicht erneut, um eine absichtlich gewählte UDP-Quelle zu korrigieren.
`padd` aktiv; kein Pad angeschlossen	Der Treiber läuft, aber es gibt keinen aktuellen Bluetooth-Eingang. Ein Pad, das als gekoppelt angezeigt wird, aber NICHT vertrauenswürdig ist, funktioniert möglicherweise jetzt, kann aber nach einem Neustart keine erneute Verbindung herstellen.	Zeichnen Sie die Protokolle `pad status` und `padd` / `bluetooth` auf. Wenn Vertrauen der identifizierte Fehler ist, befolgen Sie die ursprünglichen Controller-spezifischen Kopplungsschritte. Löschen Sie nicht zuerst jede Bindung.
Pad verbunden; `padd` inaktiv	Die Funkverbindung und der Treiber können unabhängig voneinander ausfallen. Ein verbundenes Symbol allein beweist nicht, dass der Roboter die Kontrolle übernimmt.	Vergleichen Sie beide Servicezustände und das Journal `padd`. Wenn keine der Quellen startet, melden Sie den ersten Dienstfehler, bevor Sie die Einstellungen ändern.
Pad angeschlossen und Treiber aktiv; Eine Taste bewirkt nichts	Eine Bindung oder ein Modus kann es erklären. Seit 0.16.2 haben X/Y/LB/RB keine Standardaktion; 0.17.2 kann auch Steuerknüppelachsen, Verstärkungen und Grenzwerte überschreiben.	Lesen Sie `pad bindings`, `configure --list` und den aktuellen Modus. Eine leere Override-Liste druckt nicht alle wirksamen Standardwerte.
Pad angeschlossen und Treiber aktiv; Die Eingabe scheint während der Fahrt einzufrieren	Ein Funkstillstand unterscheidet sich von einer Unterbrechung. `padd` kann den letzten Stick-Wert mit 50 Hz erneut senden, sodass ein neuer Downstream-Intent kein Beweis für neue Pad-Berichte ist.	Überprüfen Sie zuerst das `padd`-Journal. Das offizielle `robotctl monitor` `p`-Panel zeigt rohe Lücken im evdev-Bericht, aber die Interpretation beim Bewegen von Sticks erfordert einen unterstützten, kontrollierten Hardwaretest.

Der ursprüngliche -Pairing-Leitfaden ↗ unterscheidet einen angeschlossenen Controller von einem aktiven Treiber und sein Pro-Controller-Beispiel zeigt, warum manuelles Verbinden vor dem Pairing kein Eingabegerät hinterlassen kann. Ändern Sie BlueZ Privacy nicht durch Vermutungen: Im offiziellen Dokument sind unterschiedliche Fehlergründe aufgeführt, die unterschiedliche Einstellungen erfordern. Sein -Verlaufsskript ↗ liest vorhandene padd- und Kernel-Journaldatensätze ohne Live-Pad; Ein 0x08-Überwachungszeitlimit weist auf Reichweite oder Störung hin, während 0x13/0x16 darauf hinweist, dass das Pad ausgeschaltet wurde. Ein fehlender Verlauf stellt keine verlässliche Verbindung dar, und ein ruhender Block sendet keine Berichte. Rufen Sie einen Live-Stick-Test niemals als schreibgeschützt auf, nur weil der Monitor-Befehl nur Daten liest.

Wenn Sie eine Frage teilen, geben Sie die Daemon-Version, die Quellzustände in der Reihenfolge, die beiden pad status-Zeilen, die tatsächlichen Tastenbelegungen und einen kurzen Protokollauszug mit Zeitstempel an. Entfernen Sie Controller-Adressen, lokale IPs, Seriennummern und Kontodetails. Geben Sie an, ob die Beobachtung von einem offiziellen physischen Roboter stammt. Eine Browsersimulation kann ihre Bluetooth-Funkverbindung nicht testen. Der 0.17.2 UDP stale_ms Stopp und timeout_ms Sitzungsverlust gelten für netpadd, nicht für diese Bluetooth-Pad-Diagnose. UDP-Zustandsmaschine ↗ Stop- und Verlustbehandlung ↗.

Senden Sie einen Bericht, auf den jemand reagieren kann.

Ersetzen Sie die Felder unten durch Ihre Beobachtungen. Fügen Sie einen kurzen, relevanten Fehlerauszug bei; Entfernen Sie Token und persönliche Pfade vor dem Teilen. „Was zuletzt funktioniert hat“ ist oft nützlicher als ein Screenshot der letzten Ausnahme allein.

Fehlerbehebungsberichtsvorlage

Ziel:
Fehlerhafte Stufe (Browser / Einrichtung / CUDA / Training / Export / Wiedergabe):
Seiten-URL oder Repository und vollständiger Commit:
Betriebssystem und Architektur:
Browser-Version ODER Python- / uv- / PyTorch- / CUDA-Versionen:
GPU und Treiber, falls relevant:
Aufgaben-ID / Policy-Quelle / Eingabeform:
Genauer Befehl oder genaue Handlungsfolge:
Erwartetes Verhalten:
Tatsächliches Verhalten:
Erster Fehler (kurzer Auszug ohne Zugangsdaten):
Letzter erfolgreicher Schritt:
Eine getestete Änderung und ihr Ergebnis:

Starten Sie eine entsprechende Diskussion →. Fügen Sie bei einem vermuteten Upstream-Fehler die gleiche minimale Reproduktion über den verfügbaren Supportkanal des Originalprojekts hinzu.

Fahren Sie mit Ihrem Ergebnis fort.

Wiederholen Sie die Umgebungsprüfungen → Überprüfen Sie den Export- und Wiedergabepfad →

Setzen Sie das Gespräch fort

Was möchten Sie als nächstes verstehen?

Halten Sie die Quelle, Ihre Umgebung und Ihre Beobachtungen zusammen.

Starten Sie eine verwandte Diskussion → Lesen Sie verwandte Diskussionen →

Quellen und Prüfdatum

Quellenstand 14. Oktober 2026 · Quelle geprüft