ROSA : un agent LangChain posé au-dessus de vos topics ROS
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.
En bref
- De quoi s’agit-il ?
- ROSA (nasa-jpl/rosa) transforme une requête en langage naturel en appels d'outils sur un graphe ROS1 ou ROS2. Le paquet s'installe avec pip3 install jpl-rosa, mais tout ce qui compte se joue dans la configuration du LLM et dans les outils que vous ajoutez vous-même.
- À qui s’adresse-t-il ?
- ROSA convient aux équipes qui connaissent déjà leur graphe ROS et veulent une couche de requêtage en langage naturel sans écrire d'outils à partir de zéro. Il ne convient pas à qui cherche un système déterministe ou certifié pour des commandes d'actionneurs.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- L’activité ralentit. Les derniers commits datent d’il y a 6 mois.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un graphe ROS se lit mal à la main
Un système ROS en fonctionnement expose des dizaines de topics, de services et de nœuds, et la seule façon de savoir ce qui publie sans abonné consiste à croiser ros2 topic list avec ros2 topic info sur chaque entrée. Le README de ROSA donne justement cet exemple comme première démonstration : agent.invoke("Show me a list of topics that have publishers but no subscribers"). C'est un cas d'usage étroit mais révélateur. ROSA ne remplace pas les outils en ligne de commande, il les enveloppe dans un agent capable d'enchaîner plusieurs appels pour répondre à une question formulée en prose.
Le public visé est précis. Le README parle de développeurs roboticiens qui doivent inspecter, diagnostiquer, comprendre et opérer un robot. Autrement dit, des gens qui savent déjà ce qu'est un topic et qui perdent du temps en commandes répétitives, pas des débutants qui découvriraient ROS par ce biais. La page d'accueil du projet renvoie d'ailleurs vers un wiki séparé pour la documentation, les guides et la FAQ, ce qui suggère que le README n'est qu'une porte d'entrée.
Sous le capot : LangChain, des outils, et un LLM que vous fournissez
Le README est explicite sur un point : ROSA est construit sur le framework LangChain. L'agent reçoit une requête en langage naturel, le LLM choisit parmi un ensemble d'outils, et ces outils sont ce qui touche réellement au graphe ROS. Le nom de classe est ROSA, l'import se fait par from rosa import ROSA, et l'instanciation prend au minimum ros_version et llm : ROSA(ros_version=1, llm=llm).
Ce qui n'apparaît pas dans le README, c'est la liste des outils embarqués. Le matériel fourni ne permet pas de l'affirmer, et c'est une lacune documentaire réelle : avant de faire confiance à l'agent, il faut aller lire le code ou le wiki. Le paramètre ros_version mérite aussi qu'on s'y arrête. Il est passé à la construction de l'agent, pas déduit de l'environnement. Une valeur erronée ne produira pas forcément une erreur claire, mais orientera l'agent vers la mauvaise famille de commandes. Les badges du dépôt couvrent ROS 1 Noetic et ROS 2 Humble, Iron et Jazzy, ce qui donne la matrice de compatibilité annoncée.
La séparation est saine : ROSA ne réimplémente pas une couche de communication ROS, il s'appuie sur ce qui est déjà installé et se contente d'orchestrer. Le revers est que la qualité de la réponse dépend entièrement du modèle choisi, question traitée dans une page du wiki que le README ne fait que citer.
Installation : trois lignes, puis tout le reste
L'installation tient en une commande, pip3 install jpl-rosa. Le paquet PyPI s'appelle jpl-rosa, la licence Apache-2.0, et le badge PyPI du README confirme ce nom. Les prérequis annoncés sont Python 3.9 ou supérieur et ROS Noetic ou plus récent.
Une fois installé, le squelette d'utilisation est celui-ci : llm = get_your_llm_here(), puis agent = ROSA(ros_version=1, llm=llm), puis agent.invoke avec la question en clair. La fonction get_your_llm_here() est un espace réservé dans le README, pas une API du projet. Toute la configuration du modèle se trouve sur la page Model Configuration du wiki, et c'est là qu'il faut aller avant d'écrire la moindre ligne. Le choix du modèle n'est pas un détail d'implémentation : il détermine si l'agent sait enchaîner deux appels d'outils ou s'il s'arrête au premier.
Pour essayer sans robot, le dépôt fournit une démo TurtleSim qui nécessite Docker. Le README renvoie vers un guide dédié dans le wiki plutôt que de détailler la procédure, et la vidéo associée montre l'agent raisonner sur la manière de tracer une étoile à cinq branches avant d'exécuter les commandes. C'est le chemin le plus court pour voir le comportement de l'agent sans risquer quoi que ce soit sur un vrai système.
Personnaliser : hériter de ROSA plutôt que tout réécrire
Le README décrit deux voies pour adapter l'agent à un robot donné. La première consiste à hériter de la classe ROSA, la seconde à créer une nouvelle instance avec des paramètres personnalisés. Les deux sont renvoyées à la page Custom Agents du wiki pour le détail, ce qui laisse le README volontairement muet sur la signature exacte des méthodes à surcharger.
Cette conception a une conséquence pratique : ROSA n'essaie pas de couvrir tous les robots. Il fournit un socle et attend que vous ajoutiez les outils propres à votre plateforme, ainsi que vos invites. C'est un choix défendable pour un projet qui vise des environnements aussi différents qu'un TurtleSim simulé et un robot quadrupède évoluant dans un terrain d'essai. C'est aussi ce qui rend le projet difficile à évaluer sans lire le wiki : la valeur réelle dépend de ce que vous ajoutez, pas de ce qui est livré.
Le dépôt mentionne par ailleurs une extension IsaacSim en préparation, avec une intégration directe permettant de piloter le simulateur lui-même et pas seulement les robots qui y tournent. Le README précise toutefois qu'on peut déjà utiliser ROSA avec IsaacSim via le pont ROS/ROS2. À traiter comme une annonce, pas comme une fonctionnalité disponible.
Ce que ROSA ne fera pas pour vous
La limite la plus nette tient au mode de fonctionnement lui-même. Un agent qui traduit une phrase en appels d'outils n'est pas déterministe. La même requête peut produire une séquence d'appels différente d'une exécution à l'autre, selon le modèle et l'état du graphe. Pour de l'inspection et du diagnostic, c'est acceptable. Pour une commande d'actionneur ou une séquence de mouvement, cela impose une couche de validation qui n'est pas décrite dans le README.
Deuxième limite, la documentation. Le README renvoie au wiki pour presque tout : configuration du modèle, agents personnalisés, démo TurtleSim, FAQ, feuille de route. Qui veut juger le projet sur pièces doit sortir du dépôt principal. Le README ne documente ni les outils par défaut, ni les invites système, ni la gestion des erreurs quand un service ROS ne répond pas.
Troisième point, la maintenance. L'historique des versions montre un rythme irrégulier. La v1.0.8 date d'avril 2025, la v1.0.9 de novembre 2025 et porte le libellé Hotfix: Tiktoken Deps, la v1.0.10 de mars 2026. Une correction de dépendances liée à tiktoken entre deux versions espacées de sept mois indique que la chaîne LangChain sous-jacente bouge et que le projet doit suivre. C'est un coût récurrent pour l'utilisateur, pas un coût ponctuel.
Face à quoi : l'alternative des scripts et des services ROS
L'alternative la plus directe n'est pas un autre agent, c'est ce que les équipes font déjà : des scripts Python qui utilisent rclpy ou rospy directement, ou des nœuds de service dédiés. Un script qui liste les topics sans abonné fait une vingtaine de lignes, s'exécute de façon identique à chaque fois, et ne dépend d'aucun modèle de langage. La différence d'approche est nette. Le script encode une intention précise et ne sait faire que cela. ROSA accepte une intention formulée librement et la traduit en une séquence d'appels qu'il choisit lui-même.
Le compromis se lit en termes de couverture contre prévisibilité. Un ensemble de scripts couvre exactement les cas que vous avez anticipés, mais il faut en écrire un nouveau dès qu'une question change de forme. ROSA couvre des questions non anticipées, au prix d'un résultat variable et d'une dépendance à un modèle externe. Pour un diagnostic ponctuel sur un système en fonctionnement, l'échange est favorable. Pour une procédure répétée quotidiennement sur une flotte, un script reste plus simple à auditer.
Il existe aussi une troisième voie, plus proche de ROSA : brancher un LLM sur les outils ROS sans passer par LangChain. Cela réduit les dépendances mais suppose de réécrire l'orchestration, la gestion des invites et le formatage des outils. ROSA existe précisément parce que ce travail est répétitif.
Licence et coût de mise à jour
Le projet est publié sous Apache-2.0, licence permissive qui autorise l'usage commercial, la modification et la redistribution, avec obligation de conserver les mentions de copyright et les brevets concédés. Le README précise que le copyright est détenu par le Jet Propulsion Laboratory. Pour un usage interne en entreprise, cela ne pose pas de difficulté particulière. Pour une redistribution d'un produit dérivé, il faut conserver le fichier LICENSE et signaler les modifications. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique.
Le coût de maintenance réel se situe ailleurs. ROSA dépend de LangChain, dont les interfaces ont beaucoup évolué, et l'historique des versions montre qu'un correctif de dépendances a été nécessaire en v1.0.9 autour de tiktoken. Une équipe qui épingle une version et ne la met jamais à jour prend un risque de rupture au moment où elle devra le faire. Une équipe qui suit les versions doit prévoir de retester ses agents personnalisés à chaque montée, puisque ce sont les invites et les outils qu'elle a ajoutés qui sont les plus exposés aux changements d'API.
Le point de contact indiqué dans le README est un mainteneur unique, ce qui est cohérent avec un projet de laboratoire mais doit entrer dans l'évaluation : la réactivité dépend d'une personne, pas d'une équipe large. Le dépôt n'est pas archivé et la dernière publication est récente, ce qui indique une maintenance active au moment de la rédaction.
Conclusion éditoriale
ROSA convient aux équipes qui connaissent déjà leur graphe ROS et veulent une couche de requêtage en langage naturel sans écrire d'outils à partir de zéro. Il ne convient pas à qui cherche un système déterministe ou certifié pour des commandes d'actionneurs. Avant d'adopter, vérifiez deux choses concrètes : le contenu de la page Model Configuration du wiki, puisque le README ne dit rien du LLM au-delà de get_your_llm_here(), et la liste exacte des outils exposés par défaut dans votre version, car c'est elle qui détermine ce que l'agent peut réellement faire sur votre robot.
Notes de la communauté