RosScope
ROS 2 fleet diagnostics — an oscilloscope for the graph
A Qt6 desktop tool that shows you what a ROS 2 graph is actually doing, instead of making you infer it from scrolling logs.
Problem
When a ROS 2 system misbehaves on a live floor, the available evidence is a scrolling log and a guess. The graph's real state — who is publishing, on what QoS, whether TF is complete, whether a lifecycle node actually came up, whether a node that appears dead is still holding a topic — is all knowable and none of it is visible.
The diagnosis loop was the bottleneck, not the fix.
What I built
A desktop tool that inspects the running graph directly.
- ROS-aware Linux process monitoring mapped to nodes, domains, PIDs, executables and workspaces
- Graph inspection across topics, QoS, TF, Nav2 and lifecycle state
- Zombie-process, conflict and missing-link detection
- Process control, snapshot export and session recording
- SSH-based remote fleet monitoring
- Dual UI — engineer mode for diagnostics, operator mode for the floor
Two audiences, one tool
An engineer debugging a QoS mismatch and an operator checking whether the robot is healthy need completely different surfaces over the same data. Shipping one UI would have meant either burying the diagnostics or exposing an operator to them; the split keeps both usable.
Diagnosing a graph that has gone wrong
The loop RosScope is built to shorten. Every step here is something that was previously inferred from scrolling logs.
Something on the floor stops behaving
Map processes to the ROS graph
Linux processes resolved to nodes, domains, PIDs, executables and workspaces.
Is a node actually alive?
Process gone but topic held — zombie detectedTwo nodes claiming the same name — conflict detectedAlive and singular — inspect the graphInspect topics, QoS, TF, Nav2 and lifecycle state
QoS mismatch — publisher and subscriber never connectMissing TF link — the transform tree is incompleteLifecycle node never activatedGraph healthy — look elsewhereSnapshot or record the session
So the state can be compared later, or sent to someone not standing at the robot.
What it detects
Each of these is knowable from the running graph and invisible in a log stream, which is the whole argument for the tool.
| Class | What it means |
|---|---|
| Zombie process | The process is gone but its topic or service registration is still held |
| Name conflict | Two nodes claiming the same identity in the graph |
| Missing link | A topic with a publisher and no subscriber, or the reverse |
| QoS mismatch | Endpoints that will never connect because their policies are incompatible |
| TF gaps | An incomplete transform tree |
| Lifecycle state | A managed node that never reached active |
Two modes, one tool
| Mode | For | Shows |
|---|---|---|
| Engineer | Debugging | Full graph, QoS, TF, lifecycle, process control, snapshots, SSH fleet monitoring |
| Operator | The floor | A simplified runtime and safety view, with the diagnostics out of the way |
Gallery
Not yet captured
- Engineer mode — graph and process inspection
- Diagnosing a live graph, end to end
Attribution
- Built by me
- RosScope is mine, written while deploying the SMR300 stack.