ROSA (jpl-rosa): A LangChain Agent That Turns ROS1 and ROS2 Queries Into Tool Calls

The gap ROSA fills between ros2 topic list and a question you actually have

ROS tooling is a set of narrow commands. You list topics, you echo one, you check who publishes and who subscribes, and you hold the mental model of the graph in your head while doing it. The README's own first example is the shape of the problem: "Show me a list of topics that have publishers but no subscribers". That is a real diagnostic question with no single CLI verb behind it. You answer it today by running one command, reading the output, running another, and comparing the two by eye. ROSA's pitch is that the agent does the comparison and hands back the answer. The audience is robot developers who already know ROS and want to spend less time on the enumeration steps. It is not aimed at people learning ROS, because the agent's answer is only useful if you can tell whether it is right.

What the ROSA class does with an LLM and a ros_version flag

The mechanism visible in the README is small and specific. You construct a ROSA object with two arguments: a language model you supply yourself, and ros_version set to 1 or 2. The README's example is ROSA(ros_version=1, llm=llm). From there you call agent.invoke() with a natural language string. Everything between those two points is LangChain. The README states ROSA is "Built on the Langchain framework", and the topics list on the repository includes agents, llm and robotics, which matches. The ros_version flag is the interesting design choice: rather than two packages, one class branches on which ROS generation it is talking to, which is why the badge set lists ROS 1 Noetic alongside ROS 2 Humble, Iron and Jazzy. What the README does not show is the tool list. The agent must be calling something to inspect topics, but the names, the return shapes and whether any of them can publish or move a robot are not in the README. That is a gap you have to close in the wiki before you point this at anything that moves.

Installing jpl-rosa and the two lines that get you an agent

The install path is a single pip command: pip3 install jpl-rosa. Requirements are Python 3.9+ and ROS Noetic or higher. The usage block in the README is four lines of Python: import ROSA from rosa, assign a model to llm (the README literally writes get_your_llm_here(), so the model is your problem, not the package's), build the agent with ROSA(ros_version=1, llm=llm), and call agent.invoke() with a query string. For anything beyond that, the README points at the Model Configuration wiki page for LLM setup and the Custom Agents wiki page for inheriting from ROSA, adding tools and customizing prompts. That is the honest boundary of the README: it gives you the constructor and the invoke call, and defers the configuration surface to the wiki. The TurtleSim demo is the one runnable path documented here, and it requires Docker. The README says the demo shows ROSA reasoning about how to draw a five-point star and then executing the commands, but the setup steps live in the TurtleSim Demo Guide, not in the README.

Where an LLM in the command path is the wrong answer

The README lists ROSA's jobs as inspect, diagnose, understand and operate. The first three are read-oriented and low risk. Operate is the one to think about. An agent that turns a sentence into ROS calls is non-deterministic by construction, and the README offers no discussion of confirmation steps, dry runs, or a read-only mode. If your robot is in a lab and you are asking why a topic has gone quiet, a wrong answer costs you a few minutes. If your robot is on a test stand with a spinning actuator, the same wrong answer is a different category of problem. The README also does not state which LLM backends are supported, how large a graph the agent can hold in context, or what happens when a topic name is ambiguous. Those are not reasons to skip the project. They are reasons to treat the operate half of the description as something you validate yourself, and to check the Custom Agents wiki page for whether you can restrict the tool set before you run it anywhere near hardware.

ROSA against writing your own LangChain tools over rclpy

The real alternative is not another agent product. It is the thing ROSA is made of. Because it is a LangChain agent, you could write your own tool wrappers around the ROS client libraries, expose exactly the calls you want, and get a smaller and more predictable surface. The difference in approach is who chooses the tool set. With ROSA you inherit a general-purpose set aimed at inspection and operation across ROS1 and ROS2, and you adapt by subclassing the ROSA class or building a custom instance, which the README points to in the Custom Agents page. With a hand-rolled agent you pick every tool, which means more work but a surface you can reason about line by line. ROSA's advantage is the ROS1 and ROS2 split already being handled behind one constructor argument, plus the demo and the paper behind it. The cost is that you are trusting someone else's tool definitions to be the right ones for your robot. For a research platform you are still exploring, that trade is reasonable. For a fixed production cell, it usually is not.

Release cadence, the tiktoken hotfix and what Apache-2.0 covers

The release history in the supplied material shows v1.0.8 in April 2025, v1.0.9 labelled "Hotfix: Tiktoken Deps" in November 2025, and v1.0.10 in March 2026. The gap between v1.0.8 and v1.0.9 is roughly seven months, and the fact that the intervening release was a dependency hotfix tells you the maintenance pattern is closer to reactive than continuous. Tiktoken is a tokenizer dependency, which usually arrives through the LLM stack rather than through ROS itself, so that hotfix is a reminder that your installed version can break because something upstream changed, not because ROSA changed. Pin your version. On licensing, the repository is Apache-2.0, which permits commercial and closed-source use and includes an explicit patent grant. The README's footer carries a Jet Propulsion Laboratory copyright line. Apache-2.0 is a permissive licence, but it does not settle questions about the model you plug in, the data you send it, or the terms attached to your ROS distribution. Those are separate, and worth a look before deployment rather than after.

Editorial conclusion

Adopt ROSA if you already have a working ROS graph and a model you are willing to point at it, and you want the agent layer rather than another CLI. Do not adopt it if you need deterministic, auditable robot commands, or if you are on a ROS distribution outside the Noetic, Humble, Iron and Jazzy set the README lists. Before wiring it to hardware, verify three things in the wiki: which model backends the Model Configuration page actually covers, what tools the default ROSA instance exposes for your ros_version, and whether the TurtleSim Docker demo reproduces on your machine, since that is the only end-to-end path the README documents.

Official sources

1. License: Apache-2.0
2. nasa-jpl/rosa on GitHub
3. Project website
4. README
5. Releases