When a robot breaks in the field, we often end up SSH-ing and checking “what is actually running” with the ROS CLI. It works, but it does not scale.
We are building ros2_medkit, an open-source layer that exposes a running ROS 2 system via a diagnostics-oriented REST API.
The idea
ros2_medkit translates ROS concepts (nodes, topics, services, actions, params) into a stable entity tree: Area / Component / Function / App.
This shape is inspired by SOVD (Service-Oriented Vehicle Diagnostics), an ISO automotive standard. We borrow the model and API style and adapt it to ROS 2 so it is easy to integrate, and stays compatible with other SOVD servers.
What works today
ROS 2 Gateway (REST over the ROS graph)
- Runtime discovery of nodes and topics
- Areas derived mostly from namespaces
- REST endpoints to read topics, publish topics, call services/actions, and read/set params
Fault Manager
- Central fault aggregation node
- Report, query, and clear faults
- Faults aggregated by
fault_code
Repos
- Core: GitHub - selfpatch/ros2_medkit: Modern, SOVD-compatible diagnostics for ROS 2 robots (runtime discovery, introspection, remote troubleshooting).
- Demos: GitHub - selfpatch/selfpatch_demos: Demo projects showcasing ros2_medkit integration with real ROS 2 systems
- Web UI prototype: GitHub - selfpatch/sovd_web_ui: Simple SOVD Web UI
Demo videos
- https://drive.google.com/file/d/13vWAMr0HlAm4Clx0JcuGgPqeInwTQtgV/view?usp=sharing
- https://drive.google.com/file/d/1R758nsaRPV4LBv6yNAZzQU5pG6Gbx8My/view?usp=sharing
About “selfpatch”
If you are wondering what the selfpatch GitHub org is: it is just a code space where we keep building blocks towards a future self-healing workflow for robots.
Let me know what you think.
