Roboter-Steuerung durch LLMs

Das Thema KI ist aktuell schon auf einem Höhenflug und das scheint sich so schnell nicht zu ändern. Bekannt sind hierbei der Platzhirsch Chat-GPT, auch neuere Namen wie Microsoft Copilot. Was jedoch aktuell noch nicht im Fokus steht, ist die Steuerung von Robotern, welcher Art auch immer, durch eine KI.

Was erwartet den Leser hier:

Eine Bericht der Gedanken und Abläufen der Experimente, die zum Thema der Steuerung eines Dobot Roboters mit Hilfe eines LLMs gefasst und ausprobiert wurden.

Hierbei muss klar sein, dass es nicht nur um eine Befehlsausgabe durch die KI aufgrund der vorhandenen Situation, sondern um eine tatsächliche Eistellung der Endpunkte und Motoren des jeweiligen Roboters durch das Modell geht. Doch was eignet sich hierzu am besten?

Als erster Ansatz wurde hierzu Google Deepmind’s RT2 verwendet. Es handelt sich hierbei um ein spezielles KI Modell zur Steuerung von Robotern.
Die Eingabe ist hierbei eine Kombination aus einem visuellen Input der aktuellen Situation in Kombination mit einer Anweisung in Textform.

Das besondere an RT2 im Vergleich zu RT1 ist neben generellen Performance Verbesserungen die Fähigkeit auch Situationen auswerten zu können, die nicht so in den Trainingsdaten vorkamen[1]. Um das für nicht-Informatiker zu erklären, das gleicht der menschlichen Fähigkeit transformative Situationen zu erkennen aufgrund anderer Erfahrungen, was es für unseren Anwendungszweck perfekt macht.

Versuchsaufbau

Ziel: Ein Dobot Magician soll allein mit Hilfe eines KI Modells aufgrund einer visuellen und sprachlichen Eingabe gesteuert werden.

Was brauchen wir um den KI Roboter zu realisieren?

Zunächst natürlich mal einen Roboter, in unserem Fall zum Start einen “Dobot Magician” – einen Roboter der aus einem Greifarm mit austauschbaren Aufsätzen besteht.
Dann eine Kamera mit möglichst hoher Auflösung und Rauschfreiheit, um die KI nicht unnötig zu Verwirren.
Das KI Modell RT2 und alle zugehörigen Module, welches wir von einem öffentlichen GitHub Repository erhalten.
Und zu Letzt einen leistungsstarken PC, der die Berechnungen durchführen kann.

Alle Tests werden, wenn nicht anders gekennzeichnet, auf folgendem Testsystem durchgeführt:
i7-13700K
NVIDIA RTX 4090 24GB
24GB RAM @ 3600MHz

Hier sollte es nicht zu Leistungseinbußen durch das System kommen, es ist jedoch zu bemerken, dass es bei schwächeren Systemen zu Problemen durch langsamere Antworten durch das LLM kommen kann.

Erster Test

Bei ersten Tests mit dem durch das oben genannte Repository Modell und den zugehörigen Elementen wird direkt eines klar. Das öffentlich verfügbare RT2, welches hier benutzt werden soll ist zwar lauffähig und erreicht auch eine annehmbare Performance (ca. 4 Sekunden für den initial load des Models), jedoch sind die Ausgaben nicht im von Google beschriebenen X,Y,Z Format der Effektoren. Stattdessen gibt das Modell eine Matrix gefüllt mit mehreren tausenden Werten zurück. Das ist leider komplett unbrauchbar.

Es scheint also die Version des RT2, die für die Öffentlichkeit “verfügbar” gemacht wurde, ist nicht fertig implementiert!

Nach Kontaktaufnahme mit dem Inhaber des GitHub Repos bestätigt dieser auch, dass diese Version nicht die Korrekten X,Y,Z Werte ausgibt, es jedoch aber keinen schnellen Fix oder ähnliches gibt, um es funktionsfähig zu machen.

Alternative ChatGPT

Nachdem der vorherige Plan nach einiger Zeit der Arbeit und Fehlversuchen sich nicht als praktikabel erwiesen hat muss ein anderer Plan her. Das Ziel der Steuerung des Roboters allein durch ein LLM besteht immer noch, selbst mit dem neuen Plan.

Am 13.5.2024 hat OpenAI die Version ChatGPT 4-o vorgestellt, die sich optimal für dieses Projekt umfunktionieren lassen sollte. Sie erfüllt dasselbe Kriterium wie RT2, die multi-modalität. Dieses neue Modell ist in der Lage einen visuellen Input mit einer Anfrage per natürlicher Sprache zu kombinieren.

Kurz gesagt, es sieht seine Umwelt und man kann dabei mit ihm reden.

Das ist ähnlich zu dem, was auch RT2 tut, nur dass RT2 nur für Roboter spezialisiert ist. Somit muss also dass allgemeine GPT 4o in ein Modell zur Robotersteuerung umkonfiguriert werden.

Zum Zeitpunkt dieses Berichtes ist die Echtzeit Videoeingabe bereits eindrucksvoll von OpenAI vorgestellt worden, wird jedoch erst in den kommenden Wochen für die Öffentlichkeit verfügbar, also benutzen wir in diesem Experiment eine Reihe an Einzelbildern aus dem Versuchsumfeld als Eingabe

Versuchsaufbau DobotGPT

Für den Versuchsaufbau benötigen wir:

  • Ein Dobot Magician/Magician Lite
  • Eine Oberfläche möglichst mit Markierungen oder anderen Symmetrien
  • Eine Kamera
  • Objekte zur Interaktion
  • Einen angeschlossenen PC zur Steuerung
  • Ein spezialisiertes Modell von GPT – RT GPT 1.0

Durch die Cloud Architektur des ChatGPT Modells wird nahezu keine Rechenpower benötigt und dieses Experiment kann auf jedem handelsüblichen Rechner durchgeführt werden und ist immer gleich performant. Die Performance ist hierbei jedoch von der Auslastung der OpenAI Server abhängig

In diesem Fall wurde die virtuelle Umgebung der Dobot Lab Software benutzt, um eine Laborumgebung zu simulieren

Als Input laufen ein oder mehrere Aufnahmen der Umgebung und eine Aufgabe (QUEST) in den RT GPT, welcher daraufhin eine Reihe an Endeffektor Positionen im Dobot Format ausgibt. Diese Punkte fährt der Dobot dann ab, um im Bestfall die Aufgabe zu erfüllen.

Hierbei eignen sich am besten Bilder aus mehreren Perspektiven und klar erkennbare Objekte. Dies führt auch dazu, dass die Qualität der Ergebnisse außerhalb des Labors stark schwanken kann.

Custom Model – RT GPT

Das im Laufe dieses Projektes erstellte RT GPT ist eine Konfiguration des Standard GPT, die auf die Erkennung von Dobot Situationen und die direkte Berechnung eines Lösungswegs ausgerichtet ist.

Zur Konfiguration des Modells wird der SYSPROMT verwendet, der dem System vor dem ersten Input durch den User bereitgestellt wird. Dieses SYSPROMT kann nicht durch den User überschrieben werden und bestimmt das Verhalten des Modells weitergehend.

Diese Anfangseingabe muss dem Modell alle Parameter seiner Aufgabe übergeben und darf dabei keine möglichen Fälle oder Fragen ungeklärt lassen, um die Wahrscheinlichkeit für Fehler in der Ausgabe zu reduzieren.

Über den Zeitraum des Projektes wurden so immer mehr auftretende Fehler durch Trial and Error ausfindig gemacht und der SYSPROMT konkretisiert, um eine möglichst präzise Ausgabe zu ermöglichen.

Einige Herausforderung waren hierbei:

  • Der Roboter hat Ladung manchmal nicht festgehalten
  • Gelegentlich wurde die Bewegung nach Unten mit Oben vertauscht
  • Die Ausgabe war selten in natürlicher Sprache anstatt dem Ausgabeformat
  • Der Roboter hat gelegentlich Zufällige Startwerte benutzt
  • Bei den Berechnungen wurden teilweise Kollisionen nicht mit einberechnet

Dieses GPT Modell steht über diesen Link öffentlich zur Verfügung

Hier ein kleiner Ausschnitt:

You output not natural language responses but only a list of end effector points to input into the robot to fulfill the quest.

The quests are always formulated from the point of view of the camera.

The robot coordinates are always output from the point of view of the robot

The coordinates X, Y, Z and the opening of the gripper can be output by you.

X, Y and Z describe the range of the arm.

The gripper opening can be 1 or 0 where 1 is grip and 0 is release.

!THE GRIPPER HAS TO STAY 1 TO KEEP HOLDING SO DON’T SWITCH TO 0 UNTIL RELEASE!

Benutzung

Die Benutzung des Modells ist denkbar einfach:

  1. Verschiedene Bilder derselben Szene einfügen (3-5 optimal)
  2. Aufgabe für den Roboter in natürlicher Sprache eingeben
  3. Output folgt!

Format: [X,Y,Z,Ga,Gb]

Dieser Output müsste dann im nächsten Schritt in Dobot Lab eingelesen werden, damit der Roboter die Schritte ausführt.

Bekannte Probleme und Fazit

Die meisten bekannten Fehler sind so weit nicht mehr vorhanden.

Das größte Problem besteht in der perspektivischen Erkennung der Szene durch das Modell. Hin und wieder kommt es vor, dass er aufgrund von falsch erkannten Perspektiven mit etwas kollidiert oder ähnliches.

Dieses Problem sollte aber vermutlich nahezu gelöst sein, sobald die bereits erwähnte Echtzeit Videoeingabe offen verfügbar ist.

Mit diesem Proof of Concept kann man das Projekt trotz anfänglicher Probleme und Umschwung auf halber Strecke durchaus als Erfolg verbuchen und es sollten darauf aufbauend auch zeitnah Weiterentwicklungen möglich sein, sei es in Präzision oder Erweiterung der Funktionalität. Außerdem ist durch diesen Ansatz eine Ausführung der Robotersteuerung unabhängig von guter Hardware und somit theoretisch überall mit einem PC und Internet möglich.

Somit sollte es auch möglich sein, dieses System direkt in Robotern zu integrieren, die einen Chip für einfache Programmierung haben ohne hohe Performance.

Der einzige große Nachteil ist, dass Kosten an OpenAI anfallen für die vollautomatische Nutzung mit der API, da die großen Berechnungen von Ihren Servern durchgeführt werden.

Nächste Schritte

Als nächstes gilt es, weiter zu testen, um weitere potenzielle Fehlerfälle zu erkennen und das Modell weiter zu konkretisieren.

Weiter müssen die Ausgaben zu Testzwecken einem echten Dobot vorgegeben werden, da sich Dinge in echt immer noch anders verhalten als in der Simulation.

Außerdem kann probiert werden, das Modell für andere Roboterarbeiten umzuarbeiten. So könnten beispielsweise humanoide Roboter ein Zielmedium sein.

Man beachte, alle weitergehenden Schritte und deren Ansätze können sich mit der rasanten Entwicklung der KI schlagartig ändern. Dies wird nicht zuletzt durch diesen kompletten Ansatz klar, der durch einen großen Fortschritt überhaupt erst möglich ist.


Teile diese Seite