ROS 2 Edge vs Cloud AI Inference Placement for ROS 2
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.
See the idea in a minute
A robot has a sensor and a model to run. The model could run on a nearby edge box or in a faraway cloud. Press play or pick a step to see how a time budget decides. The picture is a sketch, and no timing has been measured.
Where should the model run?
Illustration · syntheticIllustrative only. Bar lengths are invented and carry no units. No latency has been measured, and no real robot, camera, model or network is involved. The edge/cloud study is a proposal.
Plain-language guide
- Edge and cloud
- The edge box is a computer close to the robot. The cloud is a faraway service, here a Kubernetes cluster or a hosted model service, reached over a network that can slow down or drop.
- Latency budget
- The longest time a result may take to come back and still be useful. A placement that goes past the budget is over budget.
- Hard gate
- An ordinary code check that removes placements that cannot work, such as ones that are unreachable, too slow or not allowed, before any ranking happens.
- Jev
- A structured decision model this research proposes to try as an optional adviser. It would only rank placements that already pass the gate. Its answers are advice, not commands.
One real research question, not a product claim.
A fictional camera-equipped robot needs to run a task-compatible perception policy. Local CPU and remote hosted inference have different cost and network risks. A deterministic gate removes impossible or stale placements before any model comparison.
Research hypothesis
Question: Does Jev's preference among already eligible placements improve simulated task outcomes over deterministic heuristics once action freshness and network overhead are measured?
Null hypothesis: Under the same hard constraints and fixed workload, Jev advisory selection yields no net outcome gain after hosted latency, outage and cost.
Alternative: A bounded soft preference helps choose among equally eligible locations in a reproducible simulation; no hard real-time claim.
Audience & learning targets
Edge AI · systems researchers · Kubernetes · MSc → PhD · Start with synthetic inputs
- Separate compute placement policy from hard real-time robot control.
- Apply numeric deadlines, data residency and memory bounds in code.
- Design repeatable RTT, jitter, loss, disconnect and recovery profiles.
- Collect action age, availability and cost without invented benchmarks.
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 observation + resource profile
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 |
|---|---|
| Placements | Local process, same-LAN remote policy, and Kubernetes remote policy after verified DDS/network prerequisites. |
| Baseline | Deterministic hard constraints and latency/cost-aware heuristic; explicitly define an oracle for retrospective regret. |
| Variables | RTT, jitter, packet loss, disconnection duration, model service queue and approved data locality. |
| Failure cases | Lossy link, stale action chunk, provider timeout, remote policy unavailable, infeasible accelerator memory. |
| Primary metrics | p50/p95/p99 sensor-to-valid-action age, missed deadlines, reject counts, availability and eligible-placement regret. |
| Reproducibility | Source SHA, simulator/model version, hardware/clock, network profile seed, placement eligibility snapshot and failures. |
Suggested experiment procedure
- Describe a specific compatible simulator, model and task; otherwise remain on synthetic decision examples.
- Implement deterministic eligibility and establish a no-JeV local baseline with unit tests.
- Validate network fault injection and timestamp assumptions before collecting measurements.
- Compare placement advisories under matched workloads and fixed budgets, including outages.
- Publish raw timing/event records and explain what cannot be generalized to physical robotics.
What a contribution should produce
- Synthetic placement matrices with eligible/ineligible candidates
- Latency/network impairment run protocol
- Immutable inference request and eligibility logs
- p95/action-age/failure plots with raw runs (future)
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 #62 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 02
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 #85 ↗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
Fault triage
A listener stops receiving messages. Is the cause DDS discovery, QoS, networking or resource pressure? Build a transparent diagnostic comparison without touching a robot.
Explore Fault triage 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