Edge-Based QoS-Aware Adaptive Task Placement: A Closed-Loop Control in Multi-Robot Systems

This paper presents a QoS-aware Adaptive Task Placement (ATP) controller for multi-robot systems that dynamically optimizes task placement between local execution and edge offloading based on real-time latency and resource metrics, demonstrating through a closed-loop testbed that this approach significantly reduces deadline violations and tail latency compared to static orchestration under stress and network fault scenarios.

The Gist

Imagine a team of robots working on a factory floor. They need to do two things at the same time: look at what's happening (using cameras) and act on it (moving their arms).

Doing both of these jobs requires a lot of brainpower. If the robot tries to do everything itself, its "brain" (the processor) might get too hot and slow down. If it tries to send the "looking" job to a super-computer nearby (the "Edge"), it has to wait for the message to travel back and forth, which can cause delays.

This paper builds a small test lab to figure out the best way to handle this tug-of-war. Here is the breakdown of their experiment and what they found, using simple analogies.

The Setup: The Robot Team

The researchers built a mini-system with three main characters:

1. Robot 1 (The "Light" Camera): A small, simple robot with a camera. It takes pictures.
2. Robot 2 (The "Heavy" Arm): A slightly more powerful robot with a mechanical arm. It moves based on instructions.
3. The Edge Node (The "Smart Assistant"): A powerful computer sitting nearby on the same Wi-Fi network. It can do heavy math if asked.

They connected these three with a Wi-Fi network and created a loop: The camera sees something $\rightarrow$ figures out what it is $\rightarrow$ tells the arm where to move $\rightarrow$ the arm moves.

The Three Strategies

The researchers tested three different ways to manage the work:

1. The "Do It All Yourself" Strategy (Local)

• How it works: Robot 1 takes the picture and figures out what it sees all by itself. It never asks for help.
• The Analogy: It's like a chef trying to chop vegetables, cook the soup, and wash the dishes all at once in a tiny kitchen.
• The Result: It's very fast because there's no waiting for messages. But, the chef gets exhausted (the CPU hits 85% usage) and starts dropping plates if too many things happen at once.

2. The "Always Ask for Help" Strategy (Static Offloading)

• How it works: Robot 1 takes the picture and immediately sends it to the Smart Assistant to figure out what it is. The Assistant sends the answer back.
• The Analogy: The chef sends the vegetables to a sous-chef in another room to chop them.
• The Result: The main chef stays fresh (CPU usage drops to 15%). However, if the hallway (the network) gets crowded or the door jams (network lag), the vegetables sit there too long. The soup burns because the chef is waiting too long for the chopped veggies.

3. The "Smart Manager" Strategy (Adaptive Task Placement - ATP)

• How it works: This is the new invention. A smart controller watches the situation.
  • If the main chef is sweating and tired, it sends the work to the assistant.
  • If the hallway is jammed or the assistant is slow, it brings the work back to the main chef.
• The Analogy: A traffic cop who directs cars. If the main road is clear, cars stay local. If the main road is clogged, they take the highway. If the highway has an accident, they go back to the local road.
• The Result: It gets the best of both worlds. It keeps the chef from getting too tired, but it never lets the soup burn because it switches strategies instantly when things go wrong.

The Experiments: Stressing the System

The researchers put this system under pressure in two ways:

1. CPU Stress: They made Robot 1 do extra, fake work to see if it would crash.
2. Network Stress: They made the Wi-Fi slow and unreliable (like a bad connection in a busy factory).

What They Found

• The "Do It All" robot failed miserably when it got busy. It missed its deadlines (dropped the plates) because its brain was too full.
• The "Always Ask" robot failed miserably when the network was bad. The delays caused it to miss deadlines too.
• The "Smart Manager" (ATP) was the hero.
  • When the robot got tired, it offloaded work to the edge.
  • When the network got bad, it immediately switched back to doing the work locally.
  • The Outcome: It kept the deadline violations (missing the target time) below 5% in every scenario. It maintained a healthy balance, keeping the robot's brain at a comfortable 55% usage instead of 85% or 15%.

The Big Takeaway

The paper proves that you shouldn't just pick one way to run robots (either always local or always cloud). Instead, you need a dynamic switch that watches the robot's health and the network's health in real-time.

By using this "Smart Manager," robots can stay fast and safe even when the factory is chaotic, the Wi-Fi is spotty, or the robot is overworked. It turns a fragile system into a resilient one.

Technical Summary

Technical Summary: Edge-Based QoS-Aware Adaptive Task Placement in Multi-Robot Systems

Problem Statement
Multi-robot systems (MRS) increasingly rely on offloading compute-intensive perception tasks to edge nodes to meet strict Quality-of-Service (QoS) constraints. However, static task orchestration on shared edge nodes often degrades QoS due to network latency, jitter, and resource contention. While existing literature explores offloading and edge-accelerated robotics, there is a lack of empirical evidence from real-world testbeds that simultaneously instruments one-way control-loop latency, injects realistic network impairments, and evaluates QoS-aware adaptive policies under varying conditions. Specifically, static offloading can reduce on-board CPU load but often amplifies tail latency and deadline misses when network conditions fluctuate.

Methodology
The authors present a pilot edge-centric MRS testbed utilizing Raspberry Pi nodes to evaluate a camera-to-manipulator visual servoing pipeline. The system architecture consists of:

• Robot 1 (R1): A "light" node (Raspberry Pi 3B) responsible for image acquisition (Sensing, T1).
• Robot 2 (R2): A "heavy" node (Raspberry Pi 5) driving a robotic arm, executing motion control (Planning/Decision T3, Control/Actuation T4).
• Edge Node (E): An Ubuntu-based server (Raspberry Pi 5) running offloaded perception tasks (Perception, T2).

The study compares three execution modes for the perception task (T2):

1. Local (LOC): All tasks execute on the robots; the edge collects telemetry only.
2. Static Offload (SO): Perception (T2) is permanently offloaded to the edge.
3. QoS-Aware Adaptive Task Placement (ATP): A lightweight controller dynamically switches T2 between local (R1) and edge (E) execution based on measured metrics.

The ATP Controller
The ATP controller operates as a closed-loop agent using a hysteresis mechanism to prevent oscillation. It evaluates metrics over a two-second observation window (comprising $W$ control cycles):

• Metrics: End-to-End (E2E) latency ($\hat{L}$), Robot CPU utilization ($\hat{U}_r$), and Edge CPU utilization.
• Decision Logic:
  • Offload to Edge: Triggered if $\hat{L} \geq L_{th}$ (latency threshold) or $\hat{U}_r \geq U^H_r$ (high CPU threshold).
  • Onload to Robot: Triggered if $\hat{L} \geq L_{th}$ (indicating network degradation) or $\hat{U}_r \leq U^L_r$ (low CPU threshold, indicating sufficient local headroom).
• Stability: A minimum dwell time ($N_{min}$) is enforced before allowing a state switch.

Experimental Setup
Experiments were conducted under three scenarios:

1. Baseline: Low network constraints and default CPU loads.
2. Robot CPU Stress: Synthetic load injected on R1 to simulate competing processes.
3. Network Impairment: Gaussian delay ($\mu=25$ms, $\sigma=5$ms) and 2% packet loss injected via tc netem.

Performance was evaluated using E2E latency distributions (specifically the 95th percentile, $L_{95}$), deadline violation rates ($V_D$), and CPU utilization.

Key Results

• Latency and Tail Behavior: The Static Offload (SO) mode exhibited significant "long tail" latency and higher overall delays due to network round-trip times. The Local (LOC) mode provided the most consistent latency but at the cost of high CPU usage. The ATP mode closely mirrored the low-latency profile of LOC while avoiding the tail latency spikes of SO.
• Deadline Compliance:
  • Under CPU Stress, LOC failed catastrophically, with deadline violations spiking to nearly 40%. SO and ATP remained stable.
  • Under Network Faults, SO failed with violation rates exceeding 40% due to transmission delays. LOC remained stable.
  • ATP was the only mode to maintain deadline violation rates below the 5% threshold across all scenarios, effectively acting as a safety fallback by switching to local execution when network conditions degraded.
• Resource Utilization: ATP achieved an optimal balance, reducing R1 CPU load by approximately 35% compared to LOC (averaging 55% utilization vs. 85%) while avoiding the latency penalties of static offloading.

Significance and Claims
The paper positions the QoS-aware ATP controller as a practical edge-side control primitive for Multi-Robot Systems. The authors claim that:

1. Adaptability is Critical: Static offloading is fragile under variable network conditions, whereas adaptive placement provides resilience against both local resource contention and network impairments.
2. Practical Implementation: The study provides concrete design guidelines for Cloud-Edge-Robotics (CER) deployments, demonstrating that a simple, measurement-driven controller with hysteresis can effectively manage the trade-off between local compute headroom and network latency.
3. Empirical Validation: The work bridges a gap in the literature by providing empirical evidence from a real hardware testbed that instruments realistic jitter and control-loop behavior, rather than relying solely on simulation or average latency metrics.

The authors conclude that ATP serves as a foundational architectural reference for next-generation CER and motivates further research into QoS-aware multi-objective workload orchestration for industrial cyber-physical systems. Future work is proposed to extend this logic to richer task graphs, multi-robot fleets, and more complex optimization frameworks.