Really impressive work! I love that you can set this up without touching any existing robot code—just start rosbridge and the MCP server, and the LLM can both control and observe the ROS system. It’s like having a conversational ros2cli. The KUKA arm demo is particularly striking—the LLM can call gripper services in real time, all from natural language. One thing I’m curious about—could this setup handle coordinating multiple robots simultaneously, or is it still limited to a single robot per session?”
The underlying stack definitely can connect to multiple robots simultaneously. Our current implementation is sequential, where the language model can connect from one robot to the next (and then back).
But it is definitely possible for us to write it to be simultaneous as well.
Really cool, the multi-robot angle got me thinking. For simultaneous setups, would that mean spinning separate MCP clients (one per robot), or could a single client handle multiple connections in parallel, almost like an operator shell aware of multiple robot contexts?
On the flip side, how would you handle conflicting commands from multiple clients? Is it last-writer-wins, or do you envision some arbitration layer? It feels like orchestration + conflict resolution will be key if MCP is to scale beyond single-robot demos into fleet-level use.
Conflicting commands from multiple clients is one of the open questions at the moment.
We're also building out a technical steering committee to help guide our direction on topics like this. Safety is a big category where having direction from across the community will be important.
It should be possible to do it from one client. The MCP server would handle the parallel connections.
We're using websockets as the interface between the server and the robot itself, which to the best of my exploration does have the ability for simultaneous connections.
