VDA-5050-Flottenmanagement für mehrere Roboter

Überblick

Zeitraum und Rahmen — April bis Juni 2026, Industrial Mobile Robotics Lab am Institut für Fördertechnik und Logistiksysteme (IFL) des KIT: zuerst Einzelaufgaben in der Simulation, danach Teamarbeit mit realen Robotern
Meine Rolle — alle Einzelaufgaben (10 Aufgaben zum Flottenmanagement, 3 zur Bewegungsregelung); im Team verantwortlich für den Kern des Flottenmanagements, beteiligt an der Integration auf den realen Robotern und an der abschließenden Vorführung vor Ort
Aufgabe — zwei reale mobile Roboter unterschiedlicher Fahrzeugtypen führen Transportaufträge parallel und in vorgegebener Reihenfolge aus: Aufträge verteilen, Zustände synchron halten, Wegkonflikte und Verklemmungen vermeiden
Ergebnis — von der Simulation auf reale industrielle mobile Roboter (GEBHARDT) übertragen und in der abschließenden Vorführung stabil betrieben

Meine Beiträge

VDA-5050-Aufträge und -Zustände — standardkonforme Aufträge mit mehreren Knoten und Kanten über Hol-, Bearbeitungs- und Abgabestationen erzeugt und per MQTT versendet; Zustandsnachrichten der Roboter ausgewertet und ein Fahrzeug erst dann als frei markiert, wenn alle verbleibenden Knoten und Kanten abgearbeitet und alle Aktionen FINISHED waren
Layoutgraph und A*-Planung — das LIF-Layout in einen Graphen aus Knoten und Kanten überführt; A* mit heapq-Prioritätswarteschlange und euklidischer Heuristik umgesetzt, das zielgerichtet sucht, statt wie Dijkstra blind zu expandieren
Mehrstufige Auftragskette — „aktuelle Position → Holen → Bearbeiten → Abgeben → Warteplatz” in A*-Abschnitte zerlegt, ohne doppelte Knoten zusammengefügt und die Aktion init_fine_positioning am Knoten vor jeder Station eingefügt
Auftragsvergabe im Hintergrund — ein Daemon-Thread weist Aufträge laufend dem nächstgelegenen freien Fahrzeug zu, ohne Simulationsoberfläche oder MQTT-Verkehr zu blockieren; ein weiteres Fahrzeug braucht nur einen Eintrag in der Initialisierungsdatei
Bewegungsregelung — die freigegebenen Knoten eines Auftrags als Wegpunkte extrahiert, mit einem P-Regler abgefahren und bei Ankunft lastNodeId gemeldet, um den nächsten Auftragsteil freizuschalten; Ausführungsrauschen und Beschleunigungsgrenzen mit gleitendem Mittelwert und Tiefpassfilter der Pose sowie Geschwindigkeitsrampen behandelt
Flottenmanagement für zwei reale Roboter (Team) — cat001 (Längsförderer) und mouse001 (Querförderer) koordiniert; A* filtert die Anfahrkanten nach Fahrzeugtyp, sodass jeder Roboter mit der richtigen Ausrichtung an der Station andockt; Stationssperren lassen je Station nur ein Fahrzeug zu und vermeiden Kollisionen und Verklemmungen
Integration auf realen Robotern und Abschlussvorführung (Team) — in den Realbetrieb am MQTT-Broker des Labors umgeschaltet und Geschwindigkeit sowie Lade- und Feinpositionierzeiten an das beobachtete Verhalten angepasst; in der Abschlussvorführung wurden die Aufträge erst am Tag vergeben, und die Roboter konnten an beliebiger Stelle der Testfläche starten

Technische Details

Layout und Fahrzeugtypen

Festes Layout der Testfläche: 16 Knoten, 23 Kanten, 6 Stationen (3 Übergabe-, 3 Bearbeitungsstationen) und 2 Ladeplätze
Zwei Fahrzeugtypen: cat001 ist ein Längsförderer, mouse001 ein Querförderer. Für jede Übergabestation gibt es je Fahrzeugtyp genau eine gültige Anfahrkante mit tangentialer Ausrichtung; der Roboter kommt bereits richtig ausgerichtet an und darf an der Station nicht drehen
Feinpositionierparameter (init_fine_pos_*, fine_pos_control_*) werden aus der Layoutdatei gelesen und unverändert weitergegeben; die letzten Zentimeter beim Andocken übernimmt das Fahrzeug

Systemebenen

Ebene	Inhalt
Protokoll	VDA-5050-Auftrags- und Zustandsnachrichten, JSON-Schema-Validierung, MQTT Publish und Subscribe
Auftragsvergabe	Auftragsverwaltung, Zuweisung an das nächste freie Fahrzeug, digitaler Zwilling des Fahrzeugzustands
Planung	Einlesen des LIF-Graphen, fahrzeugtypabhängige A*-Planung, Zusammenfügen der Abschnitte, Einfügen von Aktionen
Regelung	Wegpunktverfolgung, Zustandsmeldung, Filterung und Geschwindigkeitsrampen
Verifikation	pytest-Tests je Entwicklungsaufgabe; grafische Simulation; reale Roboter im Labor

Grenzen und Lehren

Gierige Auftragsvergabe — Aufträge gehen in vorgegebener Reihenfolge an das nächste freie Fahrzeug; eine global optimale Zuweisung gibt es nicht
Simulation und Realität — der Unterschied liegt in der Unsicherheit: Reale Roboter werden kurz blockiert, Geschwindigkeiten und Handhabungszeiten weichen von der Simulation ab. Das Flottenmanagement muss Verzögerungen auffangen, ohne abzustürzen, zu kollidieren oder sich zu verklemmen