Learning paths and use cases
Explore a practical curriculum and research questions using the lab's verified components and historical artifacts; proposed future features remain clearly marked as future work.
For students and educators
Design an undergraduate or graduate exercise around the differences between ROS application nodes and Kubernetes worker nodes. Students can read and diagram a three-VM kubeadm cluster, identify historical networking dependencies and inspect stress workloads without booting Vagrant.
Trace the topology
Find the Vagrantfile and map the three virtual machines, IPs, CPU and memory allocations.
Inspect the ROS containers
Compare the modern Jazzy Dockerfile and verified image-local test with legacy Foxy files.
Understand metrics
Open historical Prometheus data in Jupyter and describe dataset provenance without calling it a live benchmark.
Learning outcomes: explain containers versus pods versus ROS nodes; identify middleware discovery risks; distinguish configuration evidence from observed runtime behavior; and document a reproducible observation.
For researchers and PhD students
Use the repository to form hypotheses about cross-node DDS behavior, recovery and scaling, rather than assuming results. Begin by establishing a modern validated reference environment before collecting any new benchmark.
| Research question | Proposed measurement | Current state |
|---|---|---|
| DDS discovery across workers | Discovery time and message receipt on separate Kubernetes nodes | Open test task, #14 |
| Multicast vs explicit discovery | Repeatable setup, connectivity trace and failure matrix by CNI/RMW | Networking research task, #15 |
| Recovery after pod termination | Time until verified message delivery resumes; recorded restart strategy | Proposed controlled experiment, #18 |
| Autoscaling under load | Raw CPU, memory and message metrics across controlled repeats | Historic stress examples; modern benchmark planned, #18 |
For any experiment, version the environment, record raw measurements, attach commands, identify failed repetitions, and publish plots with methods and limitations. Never turn a static manifest into a performance claim.
For ROS developers and platform engineers
Inspect provisioning scripts, historical access assumptions and image CI. Choose bounded tasks that can be reviewed and tested independently of physical robotics equipment.
- Containers: build and smoke-test the Jazzy image on amd64.
- Networking: design an explicit DDS discovery test matrix with reproducible pod placement.
- Security: audit old cluster-admin and permissive filesystem assumptions before reuse.
- Observability: separate historical dashboard configuration from actual present-day runtime tests.
- Developer experience: help implement a smaller kind/k3d entry point under issue #16.
Explore the interactive robotics scenario lab
Students can follow four published research blueprints: ROS 2 DDS/QoS fault diagnosis, edge-versus-cloud inference placement, agent-skill screening in simulation, and fair multi-robot task allocation. Each contains a preauthored, animated synthetic trace, falsifiable hypothesis, baseline comparison, proposed metrics and a contributor issue.
The experiment registry deliberately reports no verified results until raw, reproducible evidence has been reviewed. None of these pages claim that Jev runtime integration, a modern ROS 2 cross-worker DDS setup or physical robotics tasks work today.
Cloud-edge AI and agentic robotics research (proposals)
Possible follow-on topics include LLM-assisted ROS workflow planning, semantic model execution near robot sensors, Hugging Face model packaging for CPU/GPU edge nodes, AI-assisted anomaly analysis, safe cloud-to-edge scheduling, and traceable evaluation harnesses. These are idea-stage directions, not implemented integrations in this repository.
Propose an experiment
Use a public feature request to state the scientific question, dataset or simulated task, target ROS and Kubernetes versions, measurable success criteria, failure modes, resource budget and responsible-use concerns. A one-off idea without an implementation or test plan should not be advertised as delivered.