Kann man die Anweisungen eines Roboters ändern, während er sich bewegt?

Ein Roboter sortiert Schaumstoffblöcke, als der rote Behälter voll wird. Der nächste Block ist schon im Greifer. Eine brauchbare Bedienoberfläche sollte es ermöglichen, den nächsten Schritt umzulenken, nach dem Kamerabild zu fragen oder den Lauf zu unterbrechen. Mit Gewicht im Greifer hat jede dieser Aktionen andere Folgen.

Am 5. November veröffentlichte Hugging Face LeRobot 0.7.0, eine neue Version seines quelloffenen Werkzeugkastens zum Aufzeichnen von Roboterdemonstrationen, Trainieren von Steuerungsmodellen und Ausführen auf Hardware. Beim interaktiven Rollout bleiben Roboterverbindung und geladene Policy bereit, während die Bedienperson im Terminal neue Anweisungen gibt. Kompatible Policies oder ein externer Planer können außerdem eine Szene deuten und eine weitere Teilaufgabe wählen. Dieselbe Version überarbeitet das Streaming von Datensätzen, das Training und die entfernte Inferenz. Die interaktive Steuerung verdient besondere Aufmerksamkeit, weil sie während eines Experiments neue Eingriffe ermöglicht. LeRobot-Ankündigung · Veröffentlichung v0.7.0

Die folgenden Beispiele sind Szenarien für einen Versuchsplatz. Sie trennen die Anweisung an das Modell, die tatsächlich gesendete Steuerung und die beobachtbare Folge.

Eine SO-101-Kamerahalterung am Handgelenk, fotografiert von The Robot Studio. Das Bild zeigt eine mögliche Kameraposition an dieser Hardware und stammt aus dem Projekt SO-ARM100 unter Apache 2.0. Telli.sh hat das Bild skaliert und einen Rand ergänzt.

Drei Befehle für drei unterschiedliche Aufgaben

Interaktive Befehle und ihre jeweilige Aufgabe. Eigene Illustration von Telli.sh.

Ein Rollout ist eine laufende Sitzung, in der eine Policy Beobachtungen empfängt und Aktionen erzeugt. Zu den Beobachtungen können Kamerabilder und gemessene Gelenkpositionen gehören. In Version 0.7 hält --interactive=true in einer eingerichteten lerobot-rollout-Sitzung die Roboterverbindung, die Gewichte der Policy und die Prozessoren zwischen Anweisungen geladen. Die Ankündigung zeigt fünf Terminalbefehle. Zwischen /start und /stop stehen drei Möglichkeiten, die laufende Sitzung zu steuern oder abzufragen. LeRobot-Ankündigung · Rollout-Dokumentation v0.7.0

LeRobot nennt FineART-VLA und Wall-OSS-0.5 als Beispiele für Policies, die den Text für Fragen und Ziele erzeugen können. Für eine Aktions-Policy ohne Textausgabe kann ein kompatibles externes Vision-Language-Modell diese Aufgabe übernehmen. Die Version beschreibt dafür eine OpenAI-kompatible API, lokal oder gehostet. Der externe Planer kann Fragen zum Kamerabild beantworten und Anweisungen für die Policy liefern. Die Aktions-Policy übersetzt weiterhin eine Teilaufgabe in Roboterbewegungen. Interaktive Rollouts und externer Planer · Rollout-Dokumentation v0.7.0

Der Unterschied wird auf einem vollen Versuchstisch sichtbar. Sieht die Kamera den Behälterrand nicht, liefert eine flüssige Antwort über den Behälter weiterhin wenig Belege. Wählt der Planer den richtigen blauen Block und der Greifer rutscht ab, war die Sprachauswahl richtig und der physische Versuch erfolglos. Wer Frage, Policy-Aktion und Ergebnis getrennt hält, kann entscheiden, ob Kamera, Anweisung oder Greiftechnik angepasst werden müssen.

Wechseln Sie das Ziel und halten Sie die Aufgabe klein

Nehmen Sie zwei farbige Behälter, drei weiche Blöcke und einen unterstützten Roboterarm. Beginnen Sie mit einer bekannten Aufgabe, etwa einen roten Block aufzunehmen. Wählen Sie ein zweites Ziel, das die Policy unter ähnlichen Bedingungen schon bewältigt hat. Fordern Sie die Änderung beim ersten Lauf vor dem Kontakt an. Sobald der Wechsel erkennbar ist, wiederholen Sie den Versuch aus einer neuen Ausgangsposition und ändern Sie die Anweisung später in der Bewegung. Eine Anweisung während der Fahrt stellt andere Anforderungen als eine nach dem Schließen des Greifers.

Beobachten Sie etwa die erste Bewegung zum neuen Ziel und die Endposition des Blocks. Ein Zeitstempel im Video kann zeigen, wie lange die sichtbare Umleitung gedauert hat. Der Terminalzeitstempel zeigt, wann Sie sie eingegeben haben. Beide zusammen ergeben eine interpretierbare Verzögerung, auch wenn die Software die Eingabe angenommen hat und eine neue Bewegung kaum sichtbar war. Eine vorher festgelegte Stoppbedingung vermeidet, dass die Bedienperson unbegrenzt auf eine womöglich ausbleibende Korrektur wartet.

Ein zweites Beispiel ist das Aufräumen des Arbeitsplatzes nach einem Test. Lassen Sie einen Gegenstand falsch liegen und fragen Sie das System, was noch auf dem Tisch ist. Prüfen Sie eine freie und eine verdeckte Ansicht, bevor Sie den Arbeitsplatz räumen lassen. Ändert sich die Antwort mit dem Kamerawinkel, können Sie die Szene anders aufbauen oder das Ziel enger fassen. Lassen Sie den Roboter immer nur eine vertraute Aktion ausführen, während Sie das Verhalten der Policy kennenlernen.

Geben Sie /autosteer im dritten Versuch ein Ziel wie das Sortieren zweier Schaumstoffblöcke in eine Schale. Schreiben Sie auf, welche Zwischenschritte das System wählt. Es kann einen plausiblen ersten Block auswählen und später Hilfe brauchen, wenn der zweite außer Reichweite liegt. Die Zieldelegation ist besonders aufschlussreich, wenn sich jede Teilaufgabe gegen eine einfache Sollfolge prüfen lässt. Der Ablauf zeigt, ob der Planer den falschen Schritt gewählt oder der Roboter mit einem richtigen Schritt Schwierigkeiten hatte.

Software-Stopp und Stopp an der Maschine brauchen eigene Prüfungen

Eine interaktive Sitzung bringt die Anweisungen näher an die Person, die den Roboter beobachtet. Dabei entsteht eine Lücke, in der die Person die neue Anweisung für wirksam halten kann, obwohl sie noch die vorige Bewegung sieht. Ein Pilot erfasst vier Ereignisse getrennt. Notieren Sie Versandzeitpunkt, eine verfügbare Annahmebestätigung, die erste sichtbare Verhaltensänderung und den Endzustand des Roboters. Gibt es keine Bestätigung, bleibt die Spalte leer. Die anderen drei Angaben sind weiterhin nützlich.

Die versionsgebundene Dokumentation beschreibt für unterstützte Roboter eine softwareseitige Haltefunktion im Korrekturablauf. Sie erneuert das letzte vom Treiber angewandte Positionsziel. Ein belasteter Arm kann sich weiter auf dieses Ziel zubewegen. Das Verhalten des Greifers muss an der Maschine geprüft werden. Die Sprachoberfläche sitzt oberhalb dieser Mechanik. Behalten Sie die physischen Stopp- und Aufsichtsverfahren der Hardware bei und prüfen Sie ihre Wirkung bei freiem Arbeitsplatz, bevor Sie während des Laufs Änderungen einführen. Rollout-Dokumentation v0.7.0

Erfassen Sie den Zeitpunkt der Umleitung, die sichtbare Bewegungsänderung und das Ende des Laufs. Eigene Illustration von Telli.sh.

Damit verändert sich die Bewertung eines scheinbar erfolgreichen Laufs. Ein Block in der richtigen Schale kann zwei fehlerhafte Bewegungen verdecken, die jemand unterbrechen musste. Notieren Sie, wie oft jemand eingreift und ob sich der Lauf aus dem erreichten Zustand wieder aufnehmen lässt. Eine Policy, die einen gewöhnlichen Fehler überwinden kann, verlangt etwas anderes von der Aufsicht als eine, die nach jedem Fehler zurückgesetzt werden muss. Vergleichen Sie passende Versuche mit gleichem Arbeitsplatz und denselben Objekten.

FineART macht Zwischenschritte zu Trainingsdaten

Ein weiterer Grund, die Version zu beachten, liegt in den Demonstrationsdaten. Zeigt eine Aufnahme nur einen sauberen Anfang und einen erfolgreichen Abschluss, bleibt bei einer geänderten Anweisung unklar, welchen Verhaltensschritt die Policy lernen soll. Teilaufgaben geben der Trainingspipeline mehr Informationen zu Übergängen wie dem Greifen, Ablegen und Wechseln zum nächsten Gegenstand.

Hugging Face und Scale AI nennen für FineART mehr als 40.000 beidhändige Episoden, 1.718 Stunden und über 533.000 Teilaufgaben-Annotationen. Laut Veröffentlichung vom 5. November umfasst der Datensatz 1,9 TB im LeRobot-Format. FineART-VLA baut auf π0.5 auf und ergänzt einen Sprachkopf, der eine Teilaufgabe in Worten vorhersagen kann, bevor die Aktionskomponente die Bewegung ausführt. Die Zahlen beschreiben den Datensatz der Autoren, und die Aufteilung beschreibt den Modellaufbau. Ein anders geformter Greifer, eine Kamera mit engem Bildfeld oder Gegenstände, die im Training fehlten, verändern weiterhin die erforderliche Prüfung. Ankündigung und Beschreibung von FineART · Dokumentation zu FineART-VLA

Legen Sie bei einem kleinen Korrekturdatensatz fest, was sich später reproduzieren lassen soll. Erfassen Sie die neue Anweisung, das relevante Kamerabild, den Zustand im Änderungsmoment und das beobachtete Ergebnis. Die Beschreibung „Der rote Behälter ist jetzt voll“ hat eine andere Aufgabe als die Anweisung „Lege den nächsten roten Block in die leere Schale“. Die erste beschreibt den Zustand. Die zweite sagt der Policy, was sie tun soll. Bewahren Sie beides auf, wenn der Versuch beides braucht. Speichern Sie auch Fehlschläge, um eine künftige Policy am ursprünglichen Problem zu prüfen.

Ein erster Pilot passt auf einen Versuchstisch

1. Legen Sie die Version und eine unterstützte Kombination fest. Installieren Sie LeRobot 0.7.0 nach der versionsgebundenen Projektanleitung. Prüfen Sie Roboter, Kameraaufbau und gewählte Policy an einer bekannten Aufgabe. Laut Versionshinweisen vom 5. November verwenden die Standard-PyTorch-Builds für Linux nun CUDA 13 und benötigen dort NVIDIA-Treiber ab 580.65. Für ältere Treiber gibt es die dokumentierte alternative Installation. Behandeln Sie Treiberänderungen und Roboterverhalten als getrennte Experimente. Installationsanleitung · Veröffentlichung v0.7.0

2. Zeichnen Sie vor dem Eingriff einen Referenzlauf auf. Verwenden Sie eine freie Arbeitsfläche, begrenzte Bewegungen und die Aufsichtsvorgaben für den Arm. Speichern Sie Ausgangsposition und Ziel und halten Sie fest, ob die Policy die Aufgabe beendet. Lassen Sie Kameraposition, Beleuchtung und Gegenstände für den Vergleich mit dem gesteuerten Lauf unverändert. Einrichtung des SO-101

3. Ergänzen Sie das interaktive Flag beim bekannten Rollout. Starten Sie im Terminal die Sitzung, geben Sie eine Teilaufgabe vor, ändern Sie sie einmal und beenden Sie den Lauf. Hier stehen die in der Version gezeigten Sitzungsbefehle mit beispielhafter Aufgabenformulierung. Dokumentation interaktiver Sitzungen

   Klartext

   /start
   /subtask move the red block to the tray
   /subtask move the blue block to the tray
   /stop
   

4. Ergänzen Sie visuelle Fragen und ein kleines delegiertes Ziel, sobald der Referenzlauf wiederholbar ist. Wählen Sie eine textgenerierende Policy oder richten Sie den externen Planer nach Anleitung ein. Beginnen Sie mit einer Frage, die sich anhand derselben Kamera beantworten lässt. Testen Sie ein Ziel mit sichtbarem Abschluss und dokumentieren Sie, was passiert, wenn der Planer nicht verfügbar ist oder keine brauchbare Teilaufgabe liefert. Ein externer Endpunkt verändert auch, wo Beobachtungen verarbeitet werden. Das ist wichtig, sobald die Kamera mehr als den Versuchstisch sieht. Dokumentation des externen Planers

5. Vergleichen Sie Wiederaufnahme und Abschluss. Wiederholen Sie einige möglichst gleiche Läufe und bewahren Sie jeden Fehlerfall auf. Notieren Sie, ob die Bedienperson den Ablauf erkennen, passend eingreifen und den Endzustand bestätigen konnte. Wenige Läufe helfen, den Aufbau zu verbessern. Eine Zuverlässigkeitsaussage braucht deutlich mehr Belege unter erwartbaren Bedingungen.

Version 0.7.0 ersetzt außerdem die frühere asynchrone Inferenzschnittstelle durch einen Policy-Server und einen entfernten Rollout-Modus. Wird die Inferenz später auf einen GPU-Server verlegt, wiederholen Sie die Zeit- und Unterbrechungstests über die tatsächliche Verbindung. Der Server kann mehr Rechenleistung liefern. Das Netz fügt zwischen Beobachtung und nächster Aktion eine weitere Abhängigkeit hinzu. Eine langsame oder ausgefallene Verbindung ist ein eigener Testfall. Inkompatible Änderungen in v0.7.0 · Dokumentation zur entfernten Inferenz

Der beste Test beginnt mitten in der Aufgabe

Der entscheidende Moment einer Roboterdemo kommt, wenn ein erwarteter Schritt keinen Sinn mehr ergibt. Der Behälter ist voll, ein Gegenstand verrutscht oder die Bedienperson sieht etwas, das die Kamera verpasst hat. Mit den Terminalbefehlen von LeRobot lässt sich dieser Moment zum Teil des Experiments machen. Entscheidend ist, ob die Aufsicht erkennt, was sich geändert hat, die nächste Aktion umlenken und das Ergebnis selbst überprüfen kann.

Quellen

• Foto der SO-101-Kamerahalterung von The Robot Studio und Lizenz des Repositorys

• Hugging Face, Ankündigung von LeRobot v0.7.0 vom 5. November 2026

• LeRobot v0.7.0 auf GitHub mit Hinweisen zum Upgrade

• LeRobot v0.7.0, Bereitstellung der Policy und interaktive Sitzungen

• SO-101-Dokumentation zu LeRobot v0.7.0

---

Wenn Sie die Entscheidungen und Experimente hinter Ihrer Arbeit durchsuchbar festhalten möchten, erstellen Sie ein Telli.sh-Konto.