Beobachtungs- und Aktionsräume: Die stillen Entscheidungen
Der Aktionsraum und der Beobachtungsraum, für die Sie sich entscheiden, bestimmen, was ein Datensatz jemals lehren kann. Ein Leitfaden zu den stillen Entscheidungen, die den Roboter überdauern.
Zwei Labore zeichnen dieselbe Hausarbeit auf: einen Tisch abwischen. Das eine protokolliert die Endeffektor-Pose mit 10 Hz. Das andere protokolliert rohe Gelenkwinkel mit 100 Hz, plus die Kraft am Handgelenk. Gleiche Fertigkeit, gleiche Roboterklasse, und doch kann kaum einer der beiden Datensätze die Policy des jeweils anderen trainieren. Die Lücke liegt nicht in der Aufgabe. Sie liegt in der Wahl von Beobachtungs- und Aktionsraum, an einem Nachmittag getroffen und dann über die gesamte Lebensdauer der Daten bezahlt.
Diese beiden Entscheidungen sind die stillsten in einem Projekt zum robotergestützten Lernen. Niemand schreibt einen Blogbeitrag an dem Tag, an dem er sich für einen Aktionsraum entscheidet. Und doch bestimmt diese Wahl, was sich verallgemeinern lässt, was sich mit anderen Datensätzen zusammenführen lässt und was später verworfen werden muss. Sie verdient weit mehr Sorgfalt, als ihr für gewöhnlich zuteilwird.
Was hier mit „Raum“ gemeint ist
Der Beobachtungsraum ist die Menge all dessen, was eine Policy sehen darf: welche Kameras, in welcher Auflösung, dazu alle propriozeptiven und taktilen Kanäle, die Sie einbeziehen. Der Aktionsraum ist die Menge all dessen, was eine Policy befehligen darf: Gelenkziele, Endeffektor-Bewegungen, Greifersignale und wie jedes davon kodiert wird. Beide sind Designentscheidungen, keine Tatsachen über den Roboter. Derselbe Arm lässt sich durch mindestens drei verschiedene Aktionsräume ansteuern, und jeder erzeugt aus identischer Bewegung einen subtil anderen Datensatz. Ein Protokoll der Gelenkpositionen, ein Protokoll der Endeffektor-Pose und ein tokenisiertes Protokoll desselben Wischvorgangs sind drei verschiedene Datensätze, die ein nachgelagertes Team im Nachhinein nicht mehr frei ineinander überführen kann.
Die Entscheidung für den Aktionsraum
Beginnen wir mit den Aktionen, denn der Aktionsraum ist derjenige, den man am stärksten unterschätzt. Eine Handvoll Optionen dominiert reale Datensätze.
- Gelenkposition. Jedem Gelenk wird ein Zielwinkel befohlen. Präzise, hardwarespezifisch und nahezu unmöglich auf einen Roboter mit anderer Kinematik zu übertragen.
- Gelenkdrehmoment oder -geschwindigkeit. Noch tiefer in der Steuerungsebene, hervorragend geeignet für dynamische und kontaktreiche Bewegungen, und am wenigsten verzeihend bei der sauberen Erfassung.
- Endeffektor-Pose. Es wird befohlen, wo sich die Hand befinden soll, absolut in einem bestimmten Bezugssystem. Besser über verschiedene Körper hinweg übertragbar, auf Kosten dessen, dass die Redundanz des Arms verborgen bleibt.
- Endeffektor-Delta. Bei jedem Schritt wird eine kleine Änderung der Handpose befohlen. Derzeit der Favorit für Cross-Embodiment-Daten, weil ein Delta auf vielen Armen ungefähr dasselbe bedeutet.
- Tokenisierte Aktionen. Jede der obigen Optionen wird in Tokens diskretisiert, die ein sprachmodellartiges Modell ausgeben kann, das ist die Art, wie viele Vision-Language-Action-Modelle die Steuerung an einen Transformer andocken.
Der Grund, warum das so sehr zählt, ist das Pooling. Das Projekt Open X-Embodiment musste Dutzende Datensätze in Einklang bringen, von denen jeder seinen eigenen Aktionsraum gewählt hatte, und ein Großteil der mühsamen Arbeit bestand darin, sie in eine gemeinsame Repräsentation zu übersetzen, ohne die Bedeutung zu verfälschen. DROID setzte bewusst auf ein einheitliches Aktions- und Beobachtungsformat über eine große Teleoperationsflotte hinweg, genau damit sich seine Daten zusammensetzen lassen.
| Aktionsraum | Am besten für | Schwäche | Über Körper hinweg übertragbar? |
|---|---|---|---|
| Gelenkposition | Präzise, wiederholbare Bewegung auf einem Roboter | An die Kinematik dieses Roboters gebunden | Schlecht |
| Gelenkdrehmoment oder -geschwindigkeit | Dynamische, kontaktreiche Steuerung | Schwer sauber zu erfassen und nachzuahmen | Schlecht |
| Endeffektor-Pose | Portable Manipulationsziele | Verbirgt Armredundanz und Eigenkollision | Mittelmäßig |
| Endeffektor-Delta | Pooling von Daten über viele Arme hinweg | Drift akkumuliert ohne gutes Bezugssystem | Gut |
| Tokenisierte Aktionen | Vision-Language-Action-Modelle | Diskretisierungsfehler bei feiner Skalierung | Hängt vom Tokenizer ab |
Die Entscheidung für den Beobachtungsraum
Der Beobachtungsraum birgt dieselbe Art von verborgenem Hebel. Drei Teilentscheidungen richten den größten Schaden an, oder den größten Nutzen.
Welche Modalitäten
RGB allein ist günstig und für grobe Aufgaben oft ausreichend. Fügt man Tiefe hinzu, hilft das der Geometrie. Fügt man Propriozeption und Kraft hinzu, gibt man einer Policy endlich die Information, die ein Mensch beim Einstecken benutzt, ohne darüber nachzudenken. Datensätze wie RH20T wurden gezielt dafür gebaut, Kraft und Multi-View-Vision gemeinsam zu tragen, weil sich ein Wischvorgang oder ein Einstecken aus einem einzelnen RGB-Stream kaum erlernen lässt.
Welches Bezugssystem
Ein Bild einer Handgelenkkamera und ein Bild von einem Stativ lehren unterschiedliche Dinge. Eine im Basis-Bezugssystem des Roboters ausgedrückte Pose und dieselbe Pose in einem Kamera-Bezugssystem sind in den Daten nicht austauschbar. Bezugssysteme zu mischen, ohne die Transformationen zu erfassen, ist eine der häufigsten Arten, wie ein Datensatz still und leise unbrauchbar wird.
Wie viel Historie
Ein einzelnes Bild ist markowsch und lässt sich leicht mischen. Ein kurzes Fenster von Bildern unterstützt Gedächtnis und Geschwindigkeitsschätzung, zwingt aber dazu, Sequenzen intakt zu halten. Im Beobachtungsraum legen Sie sich darauf fest, ob Sie es bemerken oder nicht. Machen Sie das falsch, merken Sie es erst spät, wenn ein Modell, das Geschwindigkeit brauchte, sie aus Bildern, die mit zu großem Abstand protokolliert wurden, nicht mehr rekonstruieren kann.
Sie wählen einen Aktionsraum nicht ein einziges Mal. Sie wählen ihn für jedes Modell, das jemals mit diesen Daten trainiert werden wird, sodass die einzig sichere Regel lautet, die Repräsentation zu wählen, die am wenigsten verwirft.
Warum das Zusammenführen von Datensätzen so schwer ist
All das läuft auf das schwierigste Problem in der Datenversorgung dieses Feldes zusammen: das Pooling. Wenn zwei Datensätze sich bei Aktionsraum, Beobachtungsmodalitäten, Koordinatensystemen oder Steuerrate unterscheiden, ist ihre Zusammenführung keine bloße Dateiformat-Fleißarbeit. Es ist eine semantische Übersetzung, die still und leise verzerren kann, was der Roboter tatsächlich getan hat. Die Kompatibilität eines Policy-Fundaments wie NVIDIAs GR00T mit vielen Roboterkörpern beruht darauf, Repräsentationen zu wählen, die diese Übersetzung überstehen. Wo die Repräsentation verlustbehaftet ist, schleust die Zusammenführung still Rauschen ein, das kein nachgelagerter Trainingslauf mehr entfernen kann.
Deshalb gehört die Steuerrate in dieselbe Diskussion. Ein mit 10 Hz abgetasteter Datensatz und einer mit 100 Hz unterscheiden sich nicht nur in der Größe; der langsamere hat die schnellen Korrekturen verworfen, von denen eine kontaktreiche Fertigkeit lebt. Resampling kann die Zeitstempel angleichen, aber es kann die Bilder nicht erfinden, die nie aufgenommen wurden.
Die Aufgabe ist leicht, der Raum ist für immer
Beobachtungs- und Aktionsraum wirken wie Installationsarbeiten im Hintergrund, und genau deshalb sind sie gefährlich. Sie werden früh gewählt, von wem auch immer der Hardware am nächsten steht, und sie legen fest, was jedes spätere Modell lernen kann. Wählen Sie einen engen Aktionsraum, erhalten Sie einen sauberen Datensatz, der zu einer Sackgasse veraltet. Wählen Sie eine reichhaltige, gut referenzierte, zeitlich ausgerichtete Repräsentation, erhalten Sie Daten, die sich weiter auszahlen, während sich die Policy-Architekturen darüber hinweg verändern. Die Aufgabe ist der leichte Teil. Der Raum, in dem Sie sie aufzeichnen, ist die Entscheidung, die bleibt.