⚡ electrical engineering

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

Dieses Paper präsentiert eine QoS-bewusste adaptive Task-Placement-Steuerung (ATP) für Multi-Roboter-Systeme, die die Aufgabenplatzierung zwischen lokaler Ausführung und Edge-Offloading basierend auf Echtzeit-Latenz- und Ressourcenmetriken dynamisch optimiert, wobei durch ein Closed-Loop-Testbed nachgewiesen wird, dass dieser Ansatz im Vergleich zu statischer Orchestrierung unter Stress- und Netzwerkausfallszenarien die Deadline-Verletzungen und die Tail-Latenz signifikant reduziert.

Ursprüngliche Autoren: Thien Tran, Jonathan Kua, Thuong Hoang, Minh Tran, Honghao Lyu, Jiong Jin

Veröffentlicht 2026-06-02

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Thien Tran, Jonathan Kua, Thuong Hoang, Minh Tran, Honghao Lyu, Jiong Jin

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich ein Team von Robotern vor, die auf einem Fabrikboden arbeiten. Sie müssen zwei Dinge gleichzeitig tun: sehen, was passiert (mit Kameras), und handeln (ihre Arme bewegen).

Diese beiden Aufgaben zu bewältigen, erfordert viel Gehirnschmalz. Wenn der Roboter versucht, alles selbst zu erledigen, wird sein „Gehirn“ (der Prozessor) zu heiß werden und langsamer werden. Wenn er versucht, den „Sehen“-Job an einen Supercomputer in der Nähe (den „Edge“) zu senden, muss er auf die Nachricht warten, die hin- und herreist, was zu Verzögerungen führen kann.

Diese Arbeit baut ein kleines Testlabor auf, um herauszufinden, wie man diesen Tauziehen-Kampf am besten bewältigt. Hier ist die Aufschlüsselung ihres Experiments und das, was sie herausgefunden haben, unter Verwendung einfacher Analogien.

Der Aufbau: Das Roboter-Team

Die Forscher bauten ein Mini-System mit drei Hauptcharakteren:

Roboter 1 (Die „leichte“ Kamera): Ein kleiner, einfacher Roboter mit einer Kamera. Er macht Fotos.
Roboter 2 (Der „schwere“ Arm): Ein etwas leistungsfähigerer Roboter mit einem mechanischen Arm. Er bewegt sich basierend auf Anweisungen.
Der Edge Node (Der „schlaue Assistentin“): Ein leistungsstarker Computer, der sich in derselben Nähe über dasselbe WLAN befindet. Er kann schwere Berechnungen durchführen, wenn man ihn darum bittet.

Sie verbanden diese drei über ein WLAN-Netzwerk und erzeugten eine Schleife: Die Kamera sieht etwas $\rightarrow$ findet heraus, was es ist $\rightarrow$ sagt dem Arm, wohin er sich bewegen soll $\rightarrow$ der Arm bewegt sich.

Die drei Strategien

Die Forscher testeten drei verschiedene Wege, um die Arbeit zu verwalten:

1. Die „Mach alles selbst“-Strategie (Lokal)

Wie es funktioniert: Roboter 1 macht das Foto und findet ganz allein heraus, was er sieht. Er bittet nie um Hilfe.
Die Analogie: Es ist wie ein Koch, der gleichzeitig versucht, Gemüse zu schneiden, die Suppe zu kochen und das Geschirr zu spülen, und das in einer winzigen Küche.
Das Ergebnis: Es ist sehr schnell, weil man nicht auf Nachrichten warten muss. Aber der Koch erschöpft sich (die CPU erreicht 85 % Auslastung) und fängt an, Teller fallen zu lassen, wenn zu viele Dinge gleichzeitig passieren.

2. Die „Frag immer nach Hilfe“-Strategie (Statisches Offloading)

Wie es funktioniert: Roboter 1 macht das Foto und sendet es sofort an die schlaue Assistentin, um herauszufinden, was es ist. Die Assistentin sendet die Antwort zurück.
Die Analogie: Der Koch schickt das Gemüse an einen Sous-Chef in einen anderen Raum, damit dieser es schneidet.
Das Ergebnis: Der Hauptkoch bleibt frisch (CPU-Auslastung sinkt auf 15 %). Aber wenn der Flur (das Netzwerk) überfüllt ist oder die Tür klemmt (Netzwerk-Lag), liegen die Gemüse zu lange herum. Die Suppe verbrennt, weil der Koch zu lange auf das geschnittene Gemüse wartet.

3. Die „Schlaue Manager“-Strategie (Adaptive Task Placement – ATP)

Wie es funktioniert: Dies ist die neue Erfindung. Ein smarter Controller beobachtet die Situation.
- Wenn der Hauptkoch schwitzt und müde ist, schickt er die Arbeit an die Assistentin.
- Wenn der Flur verstopft oder die Assistentin langsam ist, holt er die Arbeit wieder zum Hauptkoch zurück.
Die Analogie: Ein Verkehrspolizist, der Autos leitet. Wenn die Hauptstraße frei ist, bleiben die Autos lokal. Wenn die Hauptstraße verstopft ist, nehmen sie die Autobahn. Wenn es auf der Autobahn einen Unfall gibt, kehren sie auf die lokale Straße zurück.
Das Ergebnis: Es bietet das Beste aus beiden Welten. Es verhindert, dass der Koch zu müde wird, aber es lässt die Suppe nie verbrennen, weil es die Strategie sofort wechselt, wenn etwas schiefgeht.

Die Experimente: Das System unter Druck setzen

Die Forscher setzten dieses System auf zwei Arten unter Druck:

CPU-Stress: Sie ließen Roboter 1 zusätzliche, vorgetäuschte Arbeit verrichten, um zu sehen, ob er abstürzt.
Netzwerk-Stress: Sie machten das WLAN langsam und unzuverlässig (wie eine schlechte Verbindung in einer belebten Fabrik).

Was sie fanden

Der „Alles selbst machen“-Roboter versagte kläglich, als er beschäftigt war. Er verpasste seine Fristen (ließ die Teller fallen), weil sein Gehirn zu voll war.
Der „Immer fragen“-Roboter versagte kläglich, wenn das Netzwerk schlecht war. Die Verzögerungen führten dazu, dass er Fristen versäumte.
Der „Schlaue Manager“ (ATP) war der Held.
- Als der Roboter müde wurde, verlagerte er die Arbeit auf den Edge.
- Als das Netzwerk schlecht wurde, wechselte er sofort zurück zur lokalen Ausführung der Arbeit.
- Das Ergebnis: Er hielt die Fristverletzungen (das Verpassen der Zielzeit) in jedem Szenario unter 5 %. Er hielt ein gesundes Gleichgewicht und hielt die CPU-Auslastung des Roboters bei komfortablen 55 % statt bei 85 % oder 15 %.

Das Wichtigste in Kürze

Die Arbeit beweist, dass man sich nicht nur für einen Weg entscheiden sollte, wie man Roboter betreibt (entweder immer lokal oder immer Cloud). Stattdessen benötigt man einen dynamischen Wechsel, der die Gesundheit des Roboters und die Gesundheit des Netzwerks in Echtzeit überwacht.

Durch die Verwendung dieses „Schlauen Managers“ können Roboter schnell und sicher bleiben, selbst wenn die Fabrik chaotisch, das WLAN instabil oder der Roboter überarbeitet ist. Es verwandelt ein fragiles System in ein belastbares.

Technisches Resümee: Edge-basierte QoS-bewusste adaptive Aufgabenplatzierung in Multi-Roboter-Systemen

Problemstellung
Multi-Roboter-Systeme (MRS) verlassen sich zunehmend auf das Offloading rechenintensiver Wahrnehmungsaufgaben an Edge-Knoten, um strikte Quality-of-Service-Anforderungen (QoS) zu erfüllen. Eine statische Aufgabenorchestrierung auf gemeinsam genutzten Edge-Knoten führt jedoch häufig zu einer Verschlechterung der QoS aufgrund von Netzwerklatenz, Jitter und Ressourcenkonflikten. Während die bestehende Literatur Offloading und Edge-beschleunigte Robotik untersucht, mangelt es an empirischen Belegen aus realen Testbeds, die gleichzeitig die einseitige Regelkreis-Latenz instrumentieren, realistische Netzwerkschäden injizieren und QoS-bewusste adaptive Strategien unter variierenden Bedingungen evaluieren. Insbesondere kann statisches Offloading zwar die lokale CPU-Last reduzieren, aber oft die Tail-Latenz und das Verpassen von Deadlines verstärken, wenn sich die Netzwerkbedingungen ändern.

Methodik
Die Autoren präsentieren ein Pilotprojekt für ein Edge-zentriertes MRS-Testbed unter Verwendung von Raspberry Pi-Knoten, um eine Kamera-zu-Manipulator-Visual-Servoing-Pipeline zu evaluieren. Die Systemarchitektur besteht aus:

Roboter 1 (R1): Ein „leichter“ Knoten (Raspberry Pi 3B), der für die Bildaufnahme verantwortlich ist (Sensorik, T1).
Roboter 2 (R2): Ein „schwerer“ Knoten (Raspberry Pi 5), der einen Roboterarm steuert und die Bewegungssteuerung ausführt (Planung/Entscheidung T3, Steuerung/Aktorik T4).
Edge-Knoten (E): Ein Ubuntu-basierter Server (Raspberry Pi 5), auf dem die ausgelagerten Wahrnehmungsaufgaben laufen (Wahrnehmung, T2).

Die Studie vergleicht drei Ausführungsmodi für die Wahrnehmungsaufgabe (T2):

Lokal (LOC): Alle Aufgaben werden auf den Robotern ausgeführt; der Edge-Knoten sammelt lediglich Telemetrie.
Statisches Offload (SO): Die Wahrnehmung (T2) wird dauerhaft an den Edge-Knoten ausgelagert.
QoS-bewusste adaptive Aufgabenplatzierung (ATP): Ein leichtgewichtiger Controller schaltet T2 dynamisch zwischen lokaler Ausführung (R1) und Edge-Ausführung (E) um, basierend auf gemessenen Metriken.

Der ATP-Controller
Der ATP-Controller arbeitet als Closed-Loop-Agent unter Verwendung eines Hysteresemechanismus, um Oszillationen zu verhindern. Er evaluiert Metriken über ein Beobachtungsfenster von zwei Sekunden (bestehend aus $W$ Regelzyklen):

Metriken: End-to-End (E2E) Latenz ( $\hat{L}$ ), Roboter-CPU-Auslastung ( $\hat{U}_r$ ) und Edge-CPU-Auslastung.
Entscheidungslogik:
- Offload zum Edge: Wird ausgelöst, wenn $\hat{L} \geq L_{th}$ (Latenzschwellenwert) oder $\hat{U}_r \geq U^H_r$ (hoher CPU-Schwellenwert) gilt.
- Onload zum Roboter: Wird ausgelöst, wenn $\hat{L} \geq L_{th}$ (weist auf Netzwerkdegradation hin) oder $\hat{U}_r \leq U^L_r$ (niedriger CPU-Schwellenwert, deutet auf ausreichenden lokalen Spielraum hin) gilt.
Stabilität: Eine Mindestverweilzeit ( $N_{min}$ ) wird erzwungen, bevor ein Zustandswechsel zulässig ist.

Experimenteller Aufbau
Die Experimente wurden unter drei Szenarien durchgeführt:

Baseline: Geringe Netzbeschränkungen und Standard-CPU-Lasten.
Roboter-CPU-Stress: Synthetische Last wurde auf R1 injiziert, um konkurrierende Prozesse zu simulieren.
Netzwerkstörungen: Gaußsche Verzögerung ( $\mu=25$ ms, $\sigma=5$ ms) und 2 % Paketverlust wurden via tc netem injiziert.

Die Leistung wurde mittels E2E-Latenzverteilungen (insbesondere dem 95. Perzentil, $L_{95}$ ), Deadline-Verletzungsraten ( $V_D$ ) und CPU-Auslastung bewertet.

Kernergebnisse

Latenz und Tail-Verhalten: Der Modus Statisches Offload (SO) zeigte signifikante „Long-Tail“-Latenzen und höhere Gesamtezeiten aufgrund der Netzwerk-Round-Trip-Zeiten. Der lokale Modus (LOC) lieferte die konsistenteste Latenz, jedoch auf Kosten einer hohen CPU-Auslastung. Der ATP-Modus spiegelte das latenzarme Profil von LOC wider und vermied gleichzeitig die Tail-Latenz-Spitzen von SO.
Deadline-Konformität:
- Unter CPU-Stress versagte LOC katastrophal, wobei die Deadline-Verletzungen auf fast 40 % anstiegen. SO und ATP blieben stabil.
- Unter Netzwerkfehlern scheiterte SO mit Verletzungsraten von über 40 % aufgrund von Übertragungsverzögerungen. LOC blieb stabil.
- ATP war der einzige Modus, der die Deadline-Verletzungsrate über alle Szenarien hinweg unter der 5 %-Schwelle hielt, indem es effektiv als Sicherheitsfallback fungierte und bei Verschlechterung der Netzwerkbedingungen zur lokalen Ausführung wechselte.
Ressourcenauslastung: ATP erreichte ein optimales Gleichgewicht, indem es die R1-CPU-Last im Vergleich zu LOC um etwa 35 % reduzierte (durchschnittlich 55 % Auslastung gegenüber 85 %), während es gleichzeitig die Latenzstrafen des statischen Offloadings vermied.

Bedeutung und Ansprüche
Das Paper positioniert den QoS-bewussten ATP-Controller als praktitives Edge-seitiges Steuerungselement für Multi-Roboter-Systeme. Die Autoren behaupten:

Adaptivität ist entscheidend: Statisches Offloading ist unter variablen Netzwerkbedingungen fragil, während adaptive Platzierung Resilienz gegenüber sowohl lokalen Ressourcenkonflikten als auch Netzwerkstörungen bietet.
Praktische Implementierung: Die Studie liefert konkrete Designrichtlinien für Cloud-Edge-Robotics (CER)-Einsätze und zeigt, dass ein einfacher, messungsgesteuerter Controller mit Hysterese effektiv den Trade-off zwischen lokaler Rechenkapazität und Netzwerklatenz verwalten kann.
Empirische Validierung: Die Arbeit schließt eine Lücke in der Literatur, indem sie empirische Belege aus einem echten Hardware-Testbed liefert, das realistische Jitter- und Regelkreisverhalten instrumentiert, statt sich nur auf Simulationen oder durchschnittliche Latenzmetriken zu verlassen.

Die Autoren kommen zu dem Schluss, dass ATP als grundlegendes architektonisches Referenzmodell für das nächste Generation CER dient und die Forschung zu QoS-bewusster, multikriterieller Arbeitslast-Orchestrierung für industrielle Cyber-Physische Systeme motiviert. Zukünftige Arbeiten schlagen vor, diese Logik auf reichhaltigere Task-Graphen, Multi-Roboter-Flotten und komplexere Optimierungsframeworks auszuweiten.