ROSA: ein LangChain-Agent, der ROS-Topics per natürlicher Sprache abfragt
ROSA 🤖 is an AI Agent designed to interact with ROS1- and ROS2-based robotics systems using natural language queries. ROSA helps robot developers inspect, diagnose, understand, and operate robots.
Auf einen Blick
- Was ist das?
- Das JPL-Projekt ROSA verbindet ein LLM über das LangChain-Framework mit ROS1 und ROS2. Der Agent richtet sich an Robotikentwickler, die Diagnoseabfragen stellen wollen, ohne für jede Frage ein eigenes Skript zu schreiben. Die Dokumentation liegt überwiegend im Wiki, nicht im Repository.
- Für wen ist es gedacht?
- ROSA passt zu Entwicklern, die ROS1 Noetic oder ROS2 in den Varianten Humble, Iron oder Jazzy betreiben, Python 3.9 oder neuer einsetzen und ihr eigenes Modell über den llm-Parameter anbinden können. Wer keine belastbare Modellkonfiguration hat oder dessen Roboter ausschließlich über proprietäre Schnittstellen erreichbar ist, sollte zuerst die Wiki-Seite zur Modellkonfiguration lesen und erst danach entscheiden.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Die Aktivität lässt nach. Die letzten Commits kamen vor 6 Monaten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welche Frage ROSA beantwortet, die ros2 topic list offen lässt
Die Standardwerkzeuge von ROS sind präzise, aber sie beantworten nur die Frage, die man ihnen stellt. Wer wissen will, welche Topics publiziert werden, ohne dass jemand zuhört, muss mehrere Befehle kombinieren und deren Ausgabe selbst gegeneinander halten. ROSA setzt genau dort an. Das README nennt als Beispiel den Aufruf agent.invoke("Show me a list of topics that have publishers but no subscribers"). Das ist keine Suche in einer Dokumentation, sondern eine Abfrage gegen den laufenden Graphen.
Die Zielgruppe sind laut Beschreibung Robotikentwickler, die ihre Systeme inspizieren, diagnostizieren, verstehen und bedienen wollen. Der Nutzen liegt weniger im Ersetzen von Kommandozeilenwerkzeugen als im Formulieren von Fragen, für die man sonst ad hoc ein Skript schreiben würde. Ein Team, das bereits ein sauberes Monitoring über ROS-eigene Mittel betreibt, gewinnt hier wenig. Interessant wird es in der Fehlersuche, wenn die Frage erst im Moment des Problems entsteht.
LangChain als Trägerschicht, ROSA als Roboterschicht
ROSA ist laut README auf dem LangChain-Framework aufgebaut. Das ist die entscheidende Architekturentscheidung, weil sie die Zuständigkeiten trennt: LangChain liefert die Anbindung an das Sprachmodell, ROSA liefert die Werkzeuge, mit denen dieses Modell auf den ROS-Graphen zugreift. Der Konstruktor macht das explizit. In ROSA(ros_version=1, llm=llm) wird die ROS-Version als Zahl übergeben und das Modell als fertiges Objekt.
Bemerkenswert ist, dass das Repository kein Modell mitbringt. Im Beispiel steht get_your_llm_here(), ein Platzhalter, den der Leser selbst füllen muss. Die Dokumentation verweist dafür auf eine eigene Wiki-Seite zur Modellkonfiguration. Wer hier eine out-of-the-box lauffähige Integration erwartet, wird enttäuscht. Das ist eine bewusste Arbeitsteilung, denn sie erlaubt den Betrieb mit lokalen oder gehosteten Modellen, verlagert aber auch die gesamte Verantwortung für Kosten, Latenz und Zuverlässigkeit des Modells auf den Anwender.
Der Datenfluss ist damit gerichtet: Eine natürlichsprachliche Anfrage geht an das Modell, das Modell wählt Werkzeuge aus, diese Werkzeuge sprechen mit dem ROS-Graphen, und das Ergebnis fließt als Text zurück. Die Qualität der Antwort hängt also an zwei Stellen, an der Werkzeugauswahl durch das Modell und an der Genauigkeit der Werkzeuge selbst.
Installation in einer Zeile, Anpassung über Vererbung
Die Installation ist knapp gehalten. Das README nennt pip3 install jpl-rosa als einzigen Schritt. Vorausgesetzt werden Python 3.9 oder neuer und ROS Noetic oder höher. Die Badges im Kopf der Datei grenzen das genauer ein: ROS 1 wird über Noetic abgedeckt, ROS 2 über Humble, Iron und Jazzy. Wer eine ältere ROS-2-Distribution fährt, findet in dieser Aufzählung keine Bestätigung.
Für die Anpassung an einen konkreten Roboter nennt das README zwei Wege: eine Unterklasse der Klasse ROSA bilden oder eine neue Instanz mit eigenen Parametern erzeugen. Details dazu, etwa wie Werkzeuge hinzugefügt oder Prompts verändert werden, stehen nicht im Repository, sondern auf der Wiki-Seite zu Custom Agents. Das ist ein wiederkehrendes Muster in diesem Projekt: Der Code ist installierbar, das Wissen liegt daneben.
Für einen ersten Eindruck gibt es einen TurtleSim-Demo, der laut README Docker voraussetzt und in einem separaten Wiki-Guide beschrieben wird. Wer das Projekt evaluieren will, ohne einen echten Roboter anzufassen, ist damit gut bedient. Wer es in eine bestehende ROS-Umgebung integrieren will, muss den Weg über die Wiki-Seiten nehmen.
Die Grenze zwischen Abfrage und Eingriff
Die Projektbeschreibung nennt vier Tätigkeiten: inspizieren, diagnostizieren, verstehen und bedienen. Die ersten drei sind lesend, die vierte nicht. Genau hier liegt das Risiko, das die Materialien offenlassen. Ein Agent, der Werkzeuge auswählt und ausführt, kann bei einem Modell mit unzuverlässiger Werkzeugauswahl auch dann etwas auslösen, wenn der Nutzer nur eine Frage gestellt hat.
Das README adressiert diese Frage nicht. Es gibt keinen Hinweis auf eine Bestätigungsstufe, auf einen Dry-Run-Modus oder auf eine Einschränkung der verfügbaren Werkzeuge in der Standardkonfiguration. Wer ROSA auf einem realen System mit Aktuatoren betreibt, sollte deshalb davon ausgehen, dass der Schutz vor unbeabsichtigten Aktionen selbst zu bauen ist, und zwar über die Anpassungsschicht, die das Projekt anbietet.
Ein zweiter Punkt betrifft die Modellabhängigkeit. Da das Modell vom Anwender gestellt wird, ist die Fehlerrate der Werkzeugauswahl keine Eigenschaft von ROSA, sondern eine Eigenschaft der Kombination aus Modell, Prompt und Werkzeugmenge. Zwei Teams mit identischer ROSA-Version können sehr unterschiedliche Ergebnisse sehen. Das macht Erfahrungsberichte Dritter schwer übertragbar.
Wann ein klassisches Skript die bessere Wahl bleibt
Der naheliegende Vergleich ist ein kurzes Python-Skript mit rclpy oder rospy, das genau die eine Abfrage ausführt, die man braucht. Der Unterschied liegt nicht in der Fähigkeit, sondern im Pfad: Das Skript kennt seine Abfrage zur Entwicklungszeit, ROSA bestimmt sie zur Laufzeit. Für eine feste, wiederkehrende Prüfung in einer CI-Pipeline ist das Skript überlegen, weil es deterministisch ist, keine Modellkosten verursacht und dessen Ausgabe sich direkt parsen lässt.
ROSA gewinnt dort, wo die Frage vorher nicht feststeht. Das Beispiel aus dem README, Topics mit Publishern ohne Subscriber, ist eine solche explorative Abfrage. Man könnte sie in ein Skript gießen, aber dann müsste man vorher wissen, dass man sie stellen will.
Ein zweiter Unterschied betrifft die Umgebung. Ein Skript läuft ohne Netzwerkzugriff, wenn das Modell lokal betrieben wird. Wird ein gehostetes Modell verwendet, verlassen die Abfragetexte und die zurückgegebenen Topic-Namen die eigene Infrastruktur. Für Laborumgebungen ist das selten ein Thema, für Anlagen mit Zugangsbeschränkungen schon.
Pflegeaufwand und die Herkunft der Abhängigkeiten
Die Release-Historie zeigt ein unregelmäßiges Muster. Auf v1.0.8 vom 21. April 2025 folgte v1.0.9 am 29. November 2025, ausdrücklich als Hotfix für Tiktoken-Abhängigkeiten gekennzeichnet, und v1.0.10 am 17. März 2026. Zwischen den Versionen liegen Monate, und mindestens eine davon war eine Korrektur an einer Abhängigkeit, nicht am eigenen Code.
Das ist für die Planung relevant. Ein Projekt, das auf einem schnelllebigen Framework wie LangChain aufsetzt, erbt dessen Änderungstempo. Der Tiktoken-Hotfix deutet darauf hin, wie solche Brüche aussehen können: nicht im ROSA-Code, sondern in der Kette darunter. Wer ROSA in eine langlebige Umgebung einbaut, sollte die Abhängigkeiten pinnen und nicht blind aktualisieren.
Lizenzseitig steht das Projekt unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Änderungen kenntlich gemacht und Lizenzhinweise beibehalten werden. Das Repository verlinkt zusätzlich CONTRIBUTING.md, CODE_OF_CONDUCT.md und GOVERNANCE.md, was auf eine strukturierte Betreuung hindeutet. Eine rechtliche Bewertung des eigenen Einsatzes ersetzt das nicht.
Ein Vorbehalt zur Dokumentationslage: Das README verweist für fast alle Details auf das Wiki und auf ein Paper unter arXiv 2410.06472. Wer nur das Repository liest, bekommt Installationsbefehl und Konstruktor, aber keine vollständige Beschreibung der mitgelieferten Werkzeuge. Das ist vor einer Adoption die erste Lücke, die man schließen sollte.
Redaktionelles Fazit
ROSA passt zu Entwicklern, die ROS1 Noetic oder ROS2 in den Varianten Humble, Iron oder Jazzy betreiben, Python 3.9 oder neuer einsetzen und ihr eigenes Modell über den llm-Parameter anbinden können. Wer keine belastbare Modellkonfiguration hat oder dessen Roboter ausschließlich über proprietäre Schnittstellen erreichbar ist, sollte zuerst die Wiki-Seite zur Modellkonfiguration lesen und erst danach entscheiden. Vor dem ersten produktiven Einsatz ist zu prüfen, welche Tools die gewählte ROSA-Version mitbringt und ob diese auf den eigenen Namensraum passen.
Community-Notizen