ROS 2 Fair Multi-Robot Task Assignment with Jev Advisory Ranking
Three simulated robots have different capabilities, reservations and energy budgets. Who should get the next task—and how can we measure fairness?
See the idea in a minute
Three simulated robots can each do a different job, and a dispatcher picks who gets the next task. Compare two ways of choosing, one step at a time. The tasks are made up and no result has been measured.
Who gets the next task?
Illustration · syntheticSimulation with synthetic tasks. The bars have no unit and are not data. A real study would compute fairness in code from a seeded simulator run. No measured result exists.
Plain-language guide
- Dispatcher: the scheduler code that picks which waiting task goes to which robot.
- Eligible robot: a robot that has the needed capability, is not reserved elsewhere and has enough energy. The scheduler removes all others first.
- Fairness: whether every robot and task type gets served, instead of one waiting far longer than the rest. The plan is to compute Jain's fairness index in code.
- Jev ranking: optional qualitative advice that ranks only eligible robots. The deterministic scheduler keeps the final say.
One real research question, not a product claim.
In a fictional lab, a scout robot can inspect markers, a carrier delivers mock parcels and an arm manipulates objects in simulation. A scheduler must first remove unavailable or incapable robots before asking which candidate best fits.
Research hypothesis
Question: Does Jev's qualitative ranking among eligible simulated robots improve task fit and completion compared with constrained round-robin or cost-aware deterministic schedulers?
Null hypothesis: Jev's rank offers no reproducible improvement after controlling for task feasibility, arrival order, reservations and resource overhead.
Alternative: Jev helps choose semantic fit in ambiguous cases while a deterministic scheduler alone enforces feasibility, fairness and capacity.
Audience & learning targets
Multi-agent systems · OR · robotics researchers · MSc → PhD · CPU-only fixtures first
- Model robotic capabilities and authorization as hard constraints.
- Compare round-robin, greedy and cost-aware scheduling baselines.
- Use seeded task arrivals and congestion to measure fairness.
- Record invalid suggestions and no-eligible-robot outcomes.
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 fleet + incoming task
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 |
|---|---|
| Fleet | Fictional scout (camera), arm (grasp) and carrier (parcel) with fixed capability and reserve states. |
| Baseline | Constrained round-robin, greedy shortest estimated task time, capacity/fairness heuristic. |
| Variables | Task arrival mix, reservations, simulated low battery, robot outage, queue size and uncertain task semantics. |
| Failure cases | Ineligible capability, insufficient reserve, conflicting exclusive tasks, spoofed state, no available robot. |
| Primary metrics | Simulator task completion, queue wait, invalid suggestion rate, utilization, Jain's fairness index computed in code. |
| Reproducibility | Seeded workload generator, queue and capability matrices, fixed schedule budget, full task-allocation trace. |
Suggested experiment procedure
- Define a tiny synthetic, licensed fleet/task schema with hard capabilities and budget constraints.
- Implement deterministic eligible-set filtering plus a no-JeV allocation baseline.
- Prepare fixed task-arrival seeds, failure injection and fair-scheduling comparison definitions.
- Optionally use Jev Choice only among eligible robot IDs and record advice vs actual assignment.
- Execute a verified simulator study before reporting completion or fairness results; preserve negative runs.
What a contribution should produce
- Synthetic robot capability and task-arrival fixture definitions
- Constraint-aware baseline scheduler tests
- Simulator trace/run manifest with seeds (later)
- Plots of fairness, waiting time and task success after verified runs
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 #69 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 04
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 #87 ↗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 02Edge/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