VDA 5050 Multi-Robot Fleet Management

Overview

• When and what — April to June 2026, Industrial Mobile Robotics Lab at KIT’s Institute for Material Handling and Logistics (IFL): individual tasks in simulation first, then team work on real robots
• My role — all individual tasks (10 fleet-management tasks, 3 motion-control tasks); in the team I owned the fleet-management core and took part in real-robot integration and the final on-site demonstration
• Problem — make two real mobile robots of different vehicle types carry out transport tasks in parallel and in a given order: dispatching orders, keeping state in sync, and avoiding path conflicts and deadlocks
• Outcome — moved from simulation onto real industrial mobile robots (GEBHARDT) and verified stable operation in the live final assessment

What I did

• VDA 5050 orders and state — built standard-compliant orders with multiple nodes and edges through pick, process and drop stations and published them over MQTT; parsed the robots’ state messages and marked a vehicle idle only once all remaining nodes and edges were cleared and every action reported FINISHED
• Layout graph and A* planning — parsed the LIF layout into a graph of nodes and edges; implemented A* with a heapq priority queue and a Euclidean heuristic, which searches towards the goal instead of expanding blindly like Dijkstra
• Multi-stop order pipeline — split “current position → pick → process → drop → dwelling node” into A* segments, joined them without duplicate nodes, and injected the init_fine_positioning action on the node before each station
• Background dispatching — a daemon thread keeps assigning tasks to the nearest idle vehicle without blocking the simulation UI or MQTT traffic; adding a vehicle takes one entry in the initialisation file
• Motion control — extracted the released nodes of an order as waypoints, tracked them with a proportional controller and reported lastNodeId on arrival to unlock the next part of the order; handled execution noise and acceleration limits with moving-average and low-pass pose filtering and velocity ramps
• Fleet management for two real robots (team) — coordinated cat001 (longitudinal conveyor) and mouse001 (lateral conveyor); A* filters approach edges by vehicle type so each robot docks at a station with the right orientation; station locking allows only one vehicle per station at a time to avoid collisions and deadlocks
• Real-robot integration and final demo (team) — switched to real-robot mode on the lab MQTT broker and tuned speed, loading and fine-positioning times to the observed robot behaviour; in the final event, tasks were handed out on the day and the robots could start anywhere on the test area

Technical details

Layout and vehicle constraints

• Fixed test-area layout: 16 nodes, 23 edges, 6 stations (3 transfer, 3 process) and 2 charging dwelling nodes
• Two vehicle types: cat001 is a longitudinal conveyor, mouse001 a lateral conveyor. For each transfer station there is exactly one valid approach edge per vehicle type; the edge enforces a tangential heading, so the robot arrives already facing the right way and may not rotate at the station
• Fine-positioning parameters (init_fine_pos_*, fine_pos_control_*) are read from the layout file and forwarded unchanged; the vehicle handles the last few centimetres of docking

System layers

Limitations and lessons

• Greedy dispatching — tasks go to the nearest idle vehicle in the given order; there is no global optimisation of the assignment
• Simulation versus reality — the gap is uncertainty: real robots get blocked for a moment, and their speeds and handling times differ from the simulator, so the fleet manager has to absorb delays without crashing, colliding or deadlocking