Wir haben einen Unitree G1-Humanoid (29 angetriebene Gelenke, positionsgesteuert) darauf trainiert, zu laufen, indem wir einen Referenz-Bewegungsclip in MuJoCo nachahmten, und haben die Referenz anschließend reduziert, um zu sehen, wie wenig tatsächlich ausreicht.
Die Minimalversion lief am schnellsten. Das Reduzieren des Referenzsignals erreichte nicht nur die Basislinie des vollständigen Clips – es übertraf diese um fast das Doppelte. Die Einschränkung war kein Korsett mehr.
Dieser Beitrag berichtet über die Ablation, erklärt, warum weniger Referenzframes einen schnelleren Gang erzeugen, und weist auf die Fehlermodi hin, die die Minimalversion noch aufweist (als Vorbote der Geschichte zum Reward-Hacking).
Imitationslernen im DeepMimic-Stil ist das Arbeitspferd der modernen humanoiden Fortbewegung. Aktuelle Veröffentlichungen (PHC, HOVER, OmniH2O) drängen immer wieder in eine Richtung: mehr Mocap-Daten. 100.000 bis 25 Millionen Referenzframes sind mittlerweile Standard für eine hochpräzise humanoide Steuerung.
Wir haben die umgekehrte Frage gestellt. Mit wie wenig kommt man durch und kann dennoch einen brauchbaren zweibeinigen Gang erzeugen?
Das ist nicht nur eine akademische Frage. Der Einsatz von Humanoiden in der Praxis wird durch die Verfügbarkeit von Motion-Capture-Daten eingeschränkt. Die Aufzeichnung einer hochwertigen Motion-Capture-Session ist langsam, teuer und auf Studio-Umgebungen beschränkt. Wenn zwei statische Posen für das grundlegendste Laufverhalten ausreichen, hat dies weitreichende Auswirkungen: Jedes System, das zwei Posen aus einem Foto, einem Videobild oder einer Abbildung in einem Lehrbuch extrahieren kann, verfügt über genügend Informationen, um eine Laufstrategie für einen Humanoiden zu entwickeln.
Das ist ein völlig anderer Ausgangspunkt als der, von dem die Branche derzeit ausgeht.
Roboter. Unitree G1, 29 angetriebene Gelenke. Der G1 wird auf Aktuator-Ebene positionsgesteuert: Jedes Gelenk verfügt über einen integrierten PD-Regelkreis (kp = 500) und akzeptiert Zielwinkel, keine Drehmomente. Das haben wir zu Beginn des Projekts auf die harte Tour gelernt – die Anwendung unseres eigenen externen PD-Reglers zusätzlich zum integrierten entspricht mathematisch einem viel steiferen System mit falscher Dynamik, und der Roboter fällt nach etwa 50 Schritten um. Wenn der integrierte PD-Regler beachtet wird, bleibt derselbe Regelcode stabil.
Simulator. MuJoCo mit 50 Hz Steuerung / 500 Hz Physik unter Verwendung des offiziellen Menagerie G1-Modells.
Algorithmus. PPO aus Stable-Baselines3, 256×256 MLP-Policy. 16 parallele Umgebungen. Jede Ablationsvariante wurde für ~10–20 Millionen PPO-Schritte trainiert, was ~90–180 Minuten auf einer einzelnen 4-GB-Laptop-GPU entspricht. Kein Training auf mehreren Knoten, kein übermäßiger Rechenaufwand.
Belohnung. Standard-DeepMimic-Kernel – 0,65 für die Positionsverfolgung, 0,15 für die Geschwindigkeitsverfolgung, 0,10 für die Wurzeltenden, 0,10 für die Wurzelhöhe – plus eine Aufgabenbelohnung (Lebensbonus + Vorwärtsgeschwindigkeit). Die Zusammensetzung ist bewusst einfach gehalten. Der Sinn des Experiments besteht darin, die in den Pose-Tracking-Term eingespeisten Referenzdaten zu variieren, nicht die Form der Belohnung.
Referenzdaten. Unitrees vorab retargeteter LAFAN1 Bewegungsclip walk3_subject1. Wir segmentieren automatisch einen einzelnen Zyklus des geradlinigen Gehens (~50 Frames pro Zyklus bei 50 Hz), drehen ihn um die Y-Achse, sodass die Anfangsausrichtung +x ist, und verwenden ihn als kanonische Referenz.
Drei Varianten der Referenzdichte:
| Variante | Was wir in den Pose-Tracking-Term einspeisen |
|---|---|
| Vollständige Referenz | Der gesamte 50-Frame-Zyklus, phasensynchronisiert mit der Simulationsuhr. |
| 10 Keyframes | 10 gleichmäßig verteilte Posen aus dem Zyklus, linear auf 50 Hz hochinterpoliert, bevor die Policy sie sieht. |
| 2 Posen | Nur Mitte des Stand- und Schwungphasen (extrahiert durch Argmax/Argmin der Hüftneigung), auf 50 Hz interpoliert. |
Anti-Cheat. Zwei Abbruchbedingungen schützen vor pathologischen Policies, die die Belohnungsstruktur aufdecken: Eine Beckenhöhe unter 0,3 m beendet die Episode (kein Gehen auf den Knien), und ein großer Positionsverfolgungsfehler beendet die Episode (kein Mikro-Shuffle, der die Referenz ignoriert). Ohne diese Schutzmechanismen führte jedes von uns getestete Belohnungssignal zu einem dieser beiden Fehlermodi – eine Geschichte, die wir in einem späteren Beitrag zum Thema Belohnungs-Hacking ausführlich erzählen werden.
Drei Basislinien im direkten Vergleich: reines RL (keine Nachahmung), vollständige Nachahmung (50 Frames) und eine Variante mit abklingender Nachahmung, bei der die Belohnung für die Nachahmung im Laufe des Trainings ausläuft:
Reines RL lernt innerhalb weniger Minuten eine Mikroschritt-Mischung und verbessert sich danach nicht mehr weiter. Die Mimic-Strategien entdecken echtes Gehen. Der Sinn der Gegenüberstellung besteht darin, zu zeigen, dass das Referenzsignal echte Arbeit leistet – es ist nicht nur ein Regularisator.
Unten sehen Sie jede der drei Varianten der Referenzdichte auf dem G1, aufgezeichnet nach dem Training auf 1000-Schritt-Überleben. Beobachten Sie, was sich ändert – und was nicht.
Vollständige Referenz (50 Frames). 0,69 m/s, 13,87 m. Dies ist die Goldstandard-Policy nach der VecNormalize-Korrektur (wir haben sie in unseren Archiven als v12_gold gekennzeichnet; die Geschichte des Fehlers, der sie verdeckte, ist ein eigener Beitrag auf Reproduzierbarkeit).
10 Keyframes. 0,46 m/s, 9,31 m. Gleiche Pipeline, 80 % weniger Referenzdaten:
Nur 2 Posen. 1,22 m/s, 24,58 m. Die Minimalversion. Nur Mittelstellung und Schwungmittelstellung, interpoliert auf 50 Hz:
Alle drei Strategien wurden über fünf deterministische Episoden mit demselben Startwert und derselben clip_obs-Konfiguration evaluiert, um die Zahlen vergleichbar zu machen.
Eine Anmerkung vor den Ergebnissen, da es irreführend wäre, sie zu überspringen.
Die positionsgesteuerten Aktuatoren des G1 sind nicht nur ein Kalibrierungsdetail – sie sind eine tragende Annahme, die alles zunichte machte, was wir in den ersten zwei Wochen versucht haben. PyBullet-Beispiele und die meisten RL-Humanoid-Tutorials gehen von einer Drehmomentsteuerung aus: Deine Aktion ist ein 29-dimensionaler Drehmomentvektor, der Simulator integriert ihn, du liest den nächsten Zustand aus. Der G1 in MuJoCo Menagerie verwendet Positionsaktuatoren mit integrierten PD-Reglern auf Gelenkebene. Deine Aktion ist ein Zielwinkel, kein Drehmoment, und der interne PD-Regler des Simulators übernimmt die eigentliche Integration.
Wenn man dies ignoriert – was wir wiederholt getan haben – und den eigenen PD-Regler darüberlegt, entspricht das System einem mit einer viel höheren effektiven Steifigkeit, als man selbst oder der Simulator erwartet. Episoden, die in den ersten 50 Schritten stabil erscheinen, brechen danach katastrophal zusammen, und keine noch so intensive Anpassung der Belohnung kann das beheben, da die zugrunde liegende Dynamik falsch ist.
Der Tagebucheintrag an dem Tag, an dem wir das herausfanden, bestand aus einer einzigen Zeile:
PD darüberlegen → Roboter fällt nach ~50 Schritten. Dies entspricht mathematisch einem viel steiferen System mit falscher Dynamik.
Sobald wir den Aktuatortyp berücksichtigten, blieb derselbe Policy-Code über Episoden von 1000 Schritten stabil. Die folgenden Mocap-Ablationsergebnisse gehen davon aus, dass diese Korrektur vorgenommen wurde. Wenn Ihre humanoide Policy ohne ersichtlichen Grund bei Schritt 50 zusammenbricht, überprüfen Sie den Aktuatortyp, bevor Sie die Belohnungsfunktion ändern.
Das wichtigste Ergebnis – 2 Posen schlagen 50 Frames – klingt wie ein Paradoxon. Das ist es nicht. Hier ist, was tatsächlich passiert.
Der DeepMimic-Posenverfolgungsterm erfüllt zwei Aufgaben gleichzeitig:
Wenn wir von 50 Frames auf 2 Posen reduzieren, geht Aufgabe (2) vollständig verloren. Der Pose-Tracking-Term belohnt die Policy zwar weiterhin dafür, nahe an einer der beiden Posen zu sein, aber er zwingt die Trajektorie nicht mehr, zwischen diesen beiden zu liegen. Die Policy kann frei jede Amplitude wählen, die die Endpunkte interpoliert, und PPO – mit einer Geschwindigkeitsbelohnung im Aufgabentermin – wählt die Trajektorie, die die Vorwärtsgeschwindigkeit maximiert.
Mit anderen Worten: Das Referenzsignal in der Minimalvariante erfüllt eine Aufgabe, nicht zwei, und die Geschwindigkeitsbelohnung übernimmt die zweite. Die Policy läuft letztendlich zwischen zwei festen Posen hin und her, anstatt eine sorgfältige Phasentrajektorie nachzuverfolgen.
Ein Zitat aus dem Projektjournal, das dies verdeutlicht:
Die zeitliche Reihenfolge der Referenz kodiert die Richtung. Statische Posen sind richtungsunabhängig. Die Zwei-Posen-Variante funktioniert, weil die Geschwindigkeitsbelohnung ebenfalls die Richtung kodiert – ohne sie würden dieselben beiden Posen ebenso leicht zu rückwärtsgerichtetem Gehen führen.
Wir haben dies direkt bestätigt. In einem separaten Experiment (v14) wurde ein einzelnes, von Hand kodiertes Posenpaar aus Winters Lehrbuch zur Ganganalyse verwendet – keine Motion-Capture, kein Video, lediglich Hüft- und Kniewinkel, die einem statischen Diagramm entnommen wurden – und dieselbe Pipeline ohne Geschwindigkeitsbelohnungs-Bias durchlaufen. Der Roboter ging 1000 Schritte lang mit einer Geschwindigkeit von -0,18 m/s rückwärts, vollkommen stabil. Zwei Posen ohne zeitliche Reihenfolge sind richtungsunabhängig; die Strategie wählt eine beliebige Richtung. Wir behandeln dies ausführlich im Beitrag zum Belohnungs-Hacking – behalten Sie vorerst einfach im Hinterkopf, dass das 2-Posen-Ergebnis hier die vollständige DeepMimic-Reihenfolge (Mitte der Standphase → Mitte der Schwungphase) verwendet, was die Vorwärtsbewegung erzeugt.
Diese Zerlegung – Richtung vs. Amplitude – erklärt die Beschleunigung. Die vollständige Referenz erzwingt eine bestimmte Schwungamplitude der Hüfte und eine bestimmte Form der Kniebeugung. Diese Einschränkungen summieren sich. Sie binden die Strategie an „das Aussehen des Gehens im LAFAN1-Datensatz“. Wenn wir sie weglassen, findet die Strategie eine schnellere Lösung: längere Schritte, weniger Wackeln des Oberkörpers, aggressiverer Hüftantrieb zwischen den beiden Endpunkten.
Es gibt noch einen weniger offensichtlichen Mechanismus: die Erkundung durch PPO. Der Pose-Tracking-Term der Vollreferenz weist einen steilen Gradienten auf – kleine Abweichungen vom Zielwert pro Frame führen zu starken Belohnungsabfällen. Dieser Gradient ist zu Beginn des Trainings hilfreich (er gibt der Policy ein starkes Signal „Was ist als Nächstes zu tun?“ von einem zufällig initialisierten Netzwerk), wirkt sich aber im späteren Verlauf des Trainings nachteilig aus, da er die Policy davon abhält, Trajektorien zu erkunden, die von der Referenz abweichen. Die 2-Posen-Variante weist eine viel flachere Pose-Tracking-Landschaft auf: Solange die Policy in der Nähe der beiden Endpunkte verläuft, ist die Belohnung in etwa gleich. Diese Flachheit lädt zur Erkundung der Trajektorie zwischen den Posen ein, und die Geschwindigkeitsbelohnung sorgt für einen starken Gradienten in Richtung „schneller werden“. PPO optimiert letztendlich in erster Linie die Geschwindigkeit, wobei das Pose-Tracking als weiche Richtungsbeschränkung fungiert.
Dies lässt sich direkt aus den Aktionsstatistiken ablesen. Die Vollreferenz-Strategie nutzt ~30 % ihres Hüftneigungs-Aktuatorbereichs über einen Gangzyklus; die 2-Posen-Strategie nutzt ~67 %. Dasselbe gilt für die Kniebeugung. Die Minimalreferenz-Strategie ist durchweg aggressiver – das Referenzsignal zieht sie nicht bei jedem Zeitschritt zurück in eine bestimmte Pose.
Die 2-Posen-Strategie ist schneller, aber sie ist nicht in jeder Hinsicht strikt besser.
Stil. Der 2-Posen-Gang wirkt angespannt. Die Arme schwingen kaum. Der Oberkörper bleibt bemerkenswert starr. Die Vollreferenz-Strategie sieht dem natürlichen menschlichen Gehen ähnlicher, auch wenn sie langsamer ist. Wenn Sie einen Roboter für Videodemonstrationen oder die Mensch-Roboter-Interaktion trainieren, ist die Vollreferenz nach wie vor das richtige Werkzeug.
Varianz. Über fünf Evaluierungsdurchläufe mit demselben Startwert hinweg zeigt die 2-Posen-Strategie eine höhere Varianz bei Geschwindigkeit und Bewegungsbahnform auf Episodenebene als die 10-Keyframe- oder Vollreferenz-Strategien. Sie funktioniert, ist aber „sprunghafter“ – kleine Störungen bringen sie in weniger stabile Zustände.
Seitliche Abweichung. Die Minimalvariante beendet jede 1000-Schritt-Episode 4,56 m von der Geraden entfernt (gegenüber 2,44 m bei der Vollreferenz). Die Minimalreferenz schränkt die seitliche Fußplatzierung nicht gut ein; die Geschwindigkeitsbelohnung allein fixiert die Trajektorie nicht in 2D.
Risiko bei der Übertragung von der Simulation in die Realität. Alle diese Experimente wurden in MuJoCo durchgeführt. Eine schnellere, weniger eingeschränkte Strategie lässt sich möglicherweise schlechter auf Hardware übertragen, da sie stärker auf simulationsspezifische Ausnutzung der Dynamik angewiesen ist. Wir haben dies nicht getestet, und es ist die offene Frage, die uns am meisten interessiert. Die Vollreferenz-Strategie enthält mehr „Weisheit“, die aus menschlichen Bewegungen stammt; die 2-Posen-Strategie ist eher „entdeckt“ – und entdeckte Strategien neigen dazu, den Simulator zu überanpassen.
Robustheit beim Zurücksetzen. Jede Strategie in der Ablation wurde aus einer einzigen nominalen Standpose zurückgesetzt. Wir haben nicht gemessen, wie jede einzelne mit Startzuständen außerhalb der Verteilung umgeht (z. B. Fall aus 30 cm Höhe, Start mit einem Fuß über dem Boden, Stoß mitten im Schritt). Unsere Intuition: Die Full-Reference-Strategie ist robuster, da der Referenzclip implizit einen „guten Zustand“ definiert, auf den die Strategie zu konvergieren lernt; die 2-Posen-Strategie ist anfälliger, da dieser Anker viel schwächer ist. Wir kommen in dem Beitrag LLM-Reward-Iteration darauf zurück – Robustheit erweist sich als ein Problem der Zustandsraumabdeckung, nicht als ein Problem der Belohnungsgestaltung, und Referenzdaten sind eine kostengünstige Möglichkeit, die Abdeckung zu erweitern.
Der Ansatz mit hohem Datenaufkommen beim Imitationslernen für Humanoide ist gut etabliert. PHC (NVIDIA, 2023) trainiert auf dem gesamten AMASS-Datensatz – Millionen von Frames, die Tausende von Bewegungen umfassen. HOVER und OmniH2O gehen noch einen Schritt weiter und entwickeln universelle Humanoid-Steuerungen auf der Grundlage von über 25 Millionen Frames. Die Prämisse lautet, dass die Morphologie von Humanoiden zu hochdimensional und zu instabil ist, um mit spärlicher Überwachung gelernt zu werden; nur ein dichtes, bewegungsreiches Referenzsignal kann Strategien hervorbringen, die verallgemeinerbar sind und natürlich wirken.
Diese Prämisse trifft auf die allgemeine Steuerung zu. Wenn man eine einzige Strategie will, die gehen, laufen, tanzen, sich von einem Stoß erholen und nach einem Sturz wieder aufstehen kann, braucht man tatsächlich viele Daten.
Unser Experiment bewegt sich in einem anderen Bereich. Wir fragen, was die minimal erforderliche Referenz für eine spezifische Fertigkeit (Gehen) auf einer spezifischen Morphologie (G1) ist. Das Ergebnis mit zwei Posen widerspricht PHC nicht; es ergänzt es, indem es zeigt, wie gering der Aufwand ist. Ein Allzweck-Controller benötigt plausibel immer noch 25 Millionen Frames. Eine Strategie, die nur das Gehen umfasst, benötigt plausibel zwei Posen plus eine Geschwindigkeitsbelohnung.
Die interessante Frage ist, was dazwischen liegt. Wie viele Fähigkeiten lassen sich in eine einzige humanoide Policy trainieren, beispielsweise mit einem sorgfältig ausgewählten Posenpaar pro Fähigkeit – Gehen, Drehen, Aufstehen – und einer globalen Geschwindigkeits-/Orientierungsbelohnung? Dieses Experiment haben wir noch nicht durchgeführt. Das hier vorgestellte 2-Posen-Ergebnis legt nahe, dass es sich lohnt, es durchzuführen.
Wenn Sie an humanoider Fortbewegung mittels Imitationslernen arbeiten, ist das Budget für Motion-Capture viel geringer, als in der Literatur angenommen wird:
Die tiefere Aussage ist methodischer Natur. Damit ein Roboter überhaupt laufen kann, muss das Referenzsignal in erster Linie die Symmetrie zwischen links und rechts aufheben. Alles darüber hinaus ist Stil, nicht Substanz. Die Geschwindigkeitsbelohnung – die im Grunde kostenlos ist, man erhält sie vom Simulator ohne jegliche Motion-Capture – erledigt den Rest.
Wenn Sie nach 25 Millionen Referenzframes greifen, bevor Sie 2 Posen ausprobiert haben, beginnen Sie Ihre Suche am falschen Ende der Datenachse.
Ein paar Dinge, die wir nicht getestet haben, die wir aber gerne sehen würden:
Alles in diesem Beitrag ist anhand der archivierten Checkpoints reproduzierbar. Das Eval-Skript ist src/humanoid_sim/scripts/full_analysis.py; übergeben Sie ihm ein Modell-.zip und die dazugehörige VecNormalize-Datei (warum dieses Paar zusammenbleiben muss, erklären wir im Beitrag zur Reproduzierbarkeit), und Sie erhalten die Metriken, aus denen die obigen Balkendiagramme stammen.
Die in diesem Beitrag angezeigten Zahlen stammen wörtlich aus:
archives/v12_gold/metrics.json — vollständige Referenz, 0,693 m/s, 13,87 marchives/v9d_keyframes/metrics.json — 10 Keyframes, 0,464 m/s, 9,31 marchives/v9e_posepair/metrics.json — 2 Posen, 1,222 m/s, 24,58 mIn der Tabelle erfolgt keine Rundung über zwei Dezimalstellen hinaus; im Text wird die in der Veröffentlichung übliche Konvention der Angabe von zwei signifikanten Stellen verwendet (0,69, 0,46, 1,22).
Zwei Folgebeiträge dieser Reihe gehen auf die naheliegenden nächsten Fragen ein.
Sobald man das Referenzsignal entfernt, findet die Strategie kreative Wege zum „Gehen“, die kein Gehen sind – auf den Knien kriechen, rückwärts schlurfen, einbeiniges Hüpfen, getarnt als zweibeinige Bewegung. Fünf Wege, wie ein Humanoid beim Gehen schummelt ist die Taxonomie.
Und bevor diese Ergebnisse überhaupt vertrauenswürdig waren, mussten wir einen subtilen Reproduzierbarkeitsfehler beheben, der eine funktionierende Strategie zwei Wochen lang verdeckt hatte. Die VecNormalize-Falle ist der diagnostische Beitrag – eine empfehlenswerte Lektüre, wenn Sie PPO auf Humanoiden ausführen und Ihren Trainingsmetriken vertrauen.