Was ist eine Roboter-Policy? Von der Beobachtung zur Aktion
Eine Roboter-Policy bildet Beobachtung auf Aktion ab. Sehen Sie, wie Ausgaberate, Aktionsformat, Gedächtnis und Determinismus exakt bestimmen, welche Daten Sie erfassen müssen.
Entfernt man das Marketing von einem humanoiden Roboter, bleibt genau in der Mitte ein einziges Objekt übrig: eine Funktion. Sie nimmt das, was der Roboter gerade jetzt wahrnimmt, und gibt zurück, was die Motoren als Nächstes tun sollen. In der Robotik heißt diese Funktion die Policy, und praktisch jede folgenreiche Entscheidung in einem Robot-Learning-Stack ist insgeheim eine Entscheidung über die Form der Policy.
Man kann die Policy ignorieren und trotzdem eine Demo ausliefern. Man kann sie aber nicht ignorieren und zugleich verstehen, warum ein Datensatz eine robuste Fähigkeit trainiert, während ein anderer, größerer und teurerer, eine brüchige hervorbringt. Die Policy ist der Punkt, an dem Daten auf Verhalten treffen, deshalb ist sie der richtige Ausgangspunkt.
Dieser Beitrag definiert die Policy so nüchtern wie möglich und zeigt anschließend, wie ihre Form die Pipeline rückwärts durchwirkt und bestimmt, was Sie erfassen müssen.
Beobachtung hinein, Aktion hinaus
Im Kern ist eine Policy eine Abbildung. Füttert man sie mit einer Beobachtung, also der aktuellen Weltsicht des Roboters, liefert sie eine Aktion zurück, den Befehl, der den Körper bewegt. Lässt man diese Schleife zehn- oder hundertmal pro Sekunde laufen, entsteht Verhalten. Alles andere, das neuronale Netz, das Trainingsziel, der Datensatz, existiert nur, um eine gute Version dieser einen Abbildung zu erzeugen.
Zwei Details machen diese Definition nützlich statt trivial. Erstens ist es eine Entscheidung, was als Beobachtung zählt: Pixel einer einzelnen Kamera, oder Pixel plus Gelenkwinkel plus Kontaktkräfte. Zweitens ist auch das, was als Aktion zählt, eine Entscheidung: eine Ziel-Gelenkposition, eine Änderung der Endeffektor-Pose, oder ein diskreter Token aus einem gelernten Vokabular. Toolkits wie LeRobot machen diese Entscheidungen in ihrem Datenschema explizit, ein gutes Zeichen dafür, dass das Feld sie inzwischen ernst nimmt.
Es hilft auch zu sagen, was eine Policy nicht ist. Sie ist kein im Voraus festgelegter Plan, und sie ist kein starres Skript. Eine gute Policy arbeitet in einer geschlossenen Regelschleife: Sie liest die Welt bei jedem Taktzyklus neu ein und kann auf eine verrutschte Tasse oder einen klemmenden Stift reagieren. Genau diese Reaktionsfähigkeit macht Imitation aus statischem Video so schwer, und sie ist der Grund, warum die Beobachtung, mit der Sie die Policy füttern, schnell genug eintreffen muss, um etwas zu bewirken.
Eine Policy hat eine Form, und die Form hat Konsequenzen
Nicht alle Policies sind gleich gebaut, und die Unterschiede sind nicht kosmetischer Natur. Vier Achsen zählen am meisten.
Ausgaberate
Eine Policy, die mit 10 Hz ausgibt, und eine, die mit 200 Hz ausgibt, sind zwei völlig verschiedene Tiere. Die langsame kann sich auf einen schweren Vision-Backbone stützen und in Ruhe planen. Die schnelle muss leicht genug sein, um einen Regelkreis in einstelligen Millisekunden zu schließen. Kontaktreiche Fähigkeiten brauchen meist die schnelle Schleife, und diese Anforderung wandert bis ganz nach oben zurück, nämlich dazu, wie schnell Sie erfassen müssen.
Aktionsrepräsentation
Absolute Gelenkpositionen, Endeffektor-Deltas und tokenisierte Aktionen implizieren jeweils einen anderen Datensatz und eine andere Generalisierungsgeschichte. Ein Endeffektor-Delta überträgt sich eleganter zwischen verschiedenen Roboterkörpern als ein roher Gelenkbefehl, was in dem Moment wichtig wird, in dem man versucht, Daten über verschiedene Embodiments hinweg zu bündeln, wie Open X-Embodiment herausgefunden hat.
Gedächtnis
Eine Markov-Policy sieht nur das aktuelle Bild. Eine Policy mit Historie kann sich merken, dass sie die Schraube bereits aufgenommen hat und sie nun trägt. Gedächtnis erkauft Ihnen Verhalten über lange Zeithorizonte und kostet Sie saubere, zeitlich kohärente Sequenzen in den Daten statt durchmischter Einzelbilder.
Determinismus
Eine Policy, die auf eine einzige Aktion regressiert, mittelt zwei gleich gute Optionen zu einer schlechten. Eine generative Policy, ein Diffusionsmodell oder ein Token-Sampler, hält die Optionen auseinander. Diese Wahl entscheidet, ob Ihre Daten mehrere gültige Wege enthalten dürfen, dieselbe Aufgabe zu lösen, oder auf einen einzigen heruntergefiltert werden müssen. In der Manipulation zeigt sich das ständig: Es gibt viele gute Arten, einen Becher zu greifen, und eine Policy, die zu einem einzigen gemittelten Griff gezwungen wird, greift oft in die Lücke zwischen zweien von ihnen.
| Designentscheidung | Typische Optionen | Was sie von den Daten verlangt |
|---|---|---|
| Ausgaberate | 10 Hz Planung, 200 Hz Regelung | Erfassung mit mindestens der Regelrate, präzise mit Zeitstempel versehen |
| Aktionsrepräsentation | Gelenkposition, Endeffektor-Delta, Tokens | Konsistente Referenzrahmen und Kalibrierung über jede Demonstration hinweg |
| Beobachtungsmodalitäten | RGB, plus Tiefe, plus Propriozeption und Kraft | Jede Modalität auf eine gemeinsame Uhr synchronisiert |
| Gedächtnis | Markov, oder Historie und Rekurrenz | Ununterbrochene Sequenzen statt durchmischter Einzelbilder |
| Determinismus | Regression, oder generativ | Erlaubnis, mehrere gültige Lösungen pro Aufgabe zu behalten |
Einen realen Stack durch die Policy-Brille lesen
Betrachtet man die aktuellen Systeme auf diese Weise, lassen sie sich leichter vergleichen. NVIDIAs GR00T ist eine Foundation Policy, die für die Anpassung an viele Humanoide gedacht ist, deshalb setzt sie auf endeffektorzentrierte Aktionen und breites Pretraining. Physical Intelligences pi0 und die Large Behavior Models des Toyota Research Institute setzen beide auf Behavior Cloning aus großen, vielfältigen Demonstrationssammlungen. Der gemeinsame Faden ist, dass die zentrale Designentscheidung jedes Projekts, die Form seiner Policy, die Form der Daten diktierte, die es sammeln musste. Ein Großteil der aktuellen Robot-Learning-Arbeiten auf arXiv liest sich wie ein Streit darüber, welche Policy-Form die Kosten der von ihr geforderten Daten am besten zurückzahlt.
Diese Systeme anhand ihrer Benchmark-Werte zu vergleichen, sagt wenig aus, weil sie selten denselben Benchmark auf derselben Hardware ausführen. Sie anhand ihrer Policy-Form zu vergleichen, sagt viel aus: Es sagt voraus, nach welchen Daten jedes von ihnen hungert, und damit, wo jedes beim Skalieren an seine Grenzen stoßen wird.
Eine Policy ist eine Wette darauf, welche Information ausreicht, um die nächste Aktion zu wählen. Der Datensatz ist der Beleg für diese Wette, und kein noch so umfangreiches Training kann einen Beleg hinzufügen, den die Erfassung nie aufgezeichnet hat.
Kleine Definition, große Konsequenzen
Fragt man, was eine Roboter-Policy ist, fällt die ehrliche Antwort klein aus: eine Funktion von Beobachtung zu Aktion. Fragt man, was aus ihrer Form folgt, ist die Antwort fast das gesamte Feld. Ausgaberate, Aktionsrepräsentation, Gedächtnis und Determinismus sind keine Implementierungsdetails. Es sind die Fragen, die, noch vor dem ersten Gradientenschritt, entscheiden, was Ihre Daten enthalten müssen. Klären Sie zuerst die Form der Policy in Ihrem Kopf, und die Datenanforderungen hören auf, ein Rätsel zu sein, und werden zu einer Spezifikation. Das ist der stille Gewinn der Abstraktion: Benennen Sie die Abbildung, legen Sie ihre Form fest, und die Debatte über Daten hört auf, sich im Kreis zu drehen.