ROS 2 ROS 2 DDS & Kubernetes Fault Diagnosis with Jev
A listener stops receiving messages. Is the cause DDS discovery, QoS, networking or resource pressure? Build a transparent diagnostic comparison without touching a robot.
See the idea in a minute
A listener goes quiet. Clues pile up, plain code sorts the cause, and a person reviews it. Press play or pick a step. Every part of this picture is made up for teaching.
Why did the listener go quiet?
Illustration · syntheticMade up for teaching. No real ROS 2 traffic, no Jev inference, no result and no robot. The study that would measure Jev against a rule baseline is a proposal and has not been run.
Plain-language guide
- QoS (quality of service)
- Settings in ROS 2 that say how a topic delivers messages, such as best-effort or reliable. A subscriber that asks for reliable delivery cannot connect to a best-effort publisher, so it receives nothing.
- DDS discovery
- The way ROS 2 programs find each other over DDS, the messaging layer under ROS 2. If discovery fails, a listener may never learn that a publisher exists.
- Hard gate
- An ordinary code check that must pass first. Here it reads the clues and names the family of problem. Jev cannot override it.
- Jev
- A structured decision model this research proposes to try as an optional adviser. Its answers are advice, never permissions or commands, and a person still reviews the result.
One real research question, not a product claim.
A fictional ROS 2 listener has missed a publisher's messages. The provided record might point to QoS incompatibility, DDS discovery, missing connectivity, or insufficient evidence; the underlying cause is deliberately not assumed.
Research hypothesis
Question: Can a bounded Jev Choice improve held-out synthetic incident classification over a deterministic rule baseline without overconfident diagnoses?
Null hypothesis: Jev offers no meaningful increase in macro-F1 or selective coverage at a fixed error rate compared with a simple offline rule baseline.
Alternative: Jev adds diagnostic information on ambiguous cases while preserving an unknown/review option; this must be measured on held-out data.
Audience & learning targets
ROS 2 students · SREs · teaching assistants · Beginner → MSc · Laptop only for casebook
- Distinguish ROS 2 application nodes from Kubernetes worker nodes.
- Identify reliability and durability QoS mismatches versus DDS discovery gaps.
- Treat ambiguous logs as evidence, not commands; practice abstention.
- Measure a structured classifier against a deterministic baseline.
Follow an illustrative decision trace.
Select a fabricated case and trace where conventional code, an optional Jev judgment, and human review belong. This animation is preauthored educational content: it performs no inference, no API call, and no robot action.
Illustrative stage 1 of 4: Synthetic ROS 2 and pod events
Visual explanation only; Jev probabilities and experimental outcomes are intentionally absent.
Keyboard users: select a case or activate any stage button. The animation can be paused in the header, and system reduced-motion preferences are supported.
Variables, baselines and measurements.
Before anyone reports performance, the task, failure cases, comparison methods and test split must be fixed. Keep negative results and rejected advice visible.
| Research dimension | Proposed measurement contract |
|---|---|
| Dataset | 20–40 starter synthetic incidents across discovery, QoS, network, resource, healthy and unknown; family-grouped held-out test set for later research. |
| Baseline | Rule-based event triage and majority-class/always-unknown controls. Define label criteria before model evaluation. |
| Variables | Event completeness, contradictions, ROS distro wording, log injection, Choice option order and Jev question wording. |
| Failure cases | Stale timestamp, missing QoS metadata, conflicting evidence, API 429/timeout, malicious text inside a simulated log. |
| Primary metrics | Macro-F1, per-class recall and selective risk vs accepted-coverage; measured end-to-end p95 and provider availability later. |
| Reproducibility | Seed, synthetic fixture family, model/request revision, criteria hash, failures, abstentions and exact source commit. |
Suggested experiment procedure
- Author a small licensed synthetic incident corpus with class rationale, ambiguity flags and family IDs.
- Specify the input/output schema and deterministic rules (no provider key required).
- Split by incident family; preserve a held-out test set and preregister evaluation targets.
- Optionally query pinned Jev on sanitized synthetic state with an explicit cost/network budget.
- Report accepted/rejected/unknown outcomes, confidence calibration and runtime/cost evidence from real runs only.
What a contribution should produce
- Synthetic incident casebook + label guidelines
- Versioned schema and offline baseline tests
- Reproducibility manifest and raw predictions (only after actual runs)
- Error analysis and confidence/abstention charts (only from observed data)
Required before publishing a result: independent run ID, method, seed, source/model revisions, environment, raw measurements, executable analysis, errors/limitations and human review.
Current results: not measured.
No verified experiment results yet
No Jev-vs-baseline accuracy, latency, energy, fairness or simulator task-success result is available for this scenario. The website does not fabricate graphs or sample performance numbers. Future evidence must include raw data and replay instructions.
Open results registry ↗Dependencies and research honesty
Follow existing research work #74 and the broader scenario epic #83. The legacy Vagrant/Foxy manifests and current Jazzy image-local test do not establish multi-worker DDS or physical robot integration.
Safety: no actuator commands, unrestricted cluster operations, or vendor data collection from this static demonstration.
Help turn the blueprint into evidence.
Join scenario 01
Contributors can own a small, reviewable task: casebook, synthetic dataset, offline baseline, simulator test, reproducibility review or teaching guide. The issue includes a detailed Claude Code/Codex prompt, acceptance criteria and dependencies.
Contribute on GitHub issue #84 ↗Technical references
Review Jev research umbrella #73, scenario epic #83 and the repository agent instructions. No vendor endorsement or measured success is implied.
Continue exploring
Edge/cloud placement
Which AI workload belongs on a robot, at a nearby edge service, or in Kubernetes? Compare feasibility filters with Jev's structured advice under unreliable networks.
Explore Edge/cloud placement SCENARIO 03Agent skill screening
An LLM proposes a robot skill. Can a structured decision model provide useful extra review without bypassing deterministic permissions and simulator safety checks?
Explore Agent skill screening SCENARIO 04Multi-robot scheduling
Three simulated robots have different capabilities, reservations and energy budgets. Who should get the next task—and how can we measure fairness?
Explore Multi-robot scheduling