Fleet architecture and task allocation

1. Engineering problem

A fleet needs someone to decide which robot does which task, where robots may go, and what to do when a robot fails. Where those decisions live determines how the fleet behaves when the network or the server fails.

2. When is this needed?

• Moving from one robot to several.
• Choosing between a vendor fleet manager and your own.
• Designing for network loss.

3. Selection and design decisions

Open-RMF (README read 2026-11-06) is an open-source platform for multi-fleet robot management, packaged for ROS 2 Humble, Jazzy, Kilted and Rolling. Generic architecture options: centralised (a server plans for all robots: global optimum, single point of failure), decentralised (robots negotiate: resilient, harder to guarantee), hybrid (a server assigns tasks and reserves traffic; the robot executes and keeps local safety). Task allocation with costs (distance, battery, capability) is an assignment problem: a global solution (for example the Hungarian algorithm) can beat greedy dispatch.

4. Advantages and disadvantages

• Centralised optimises and has one point of failure; decentralised survives failures and is less predictable.
• Vendor-neutral platforms reduce lock-in and need integration effort.
• More server logic means more load on the network.

5. Requirements and constraints

• Robots operate safely without the server for a defined time.
• Assignment considers all robots and tasks (global), with capability and battery constraints.
• Every robot has a unique identity and namespace.

6. Architecture

operators/WMS ─▶ fleet server (tasks, traffic, monitoring) ─network─▶ robots (navigation, safety, local autonomy)

7. Implementation

1. Decide what must work without the server and keep it on the robot.
2. Define tasks, capabilities and costs.
3. Implement global assignment (below) or use a fleet platform.
4. Define behaviour on loss of the server.
5. Test with the network cut.

import itertools
robots = {"R1": (0, 0), "R2": (4, 0)}
tasks = {"T1": (3, 0), "T2": (8, 0)}
def cost(r, t):
    (x1, y1), (x2, y2) = robots[r], tasks[t]
    return abs(x1 - x2) + abs(y1 - y2)
def greedy():
    free, out, total = set(robots), [], 0
    for t in ("T1", "T2"):                                  # tasks arrive in this order and are given to the nearest free robot
        r = min(free, key=lambda r: cost(r, t)); free.remove(r); out.append((t, r)); total += cost(r, t)
    return out, total
def optimal():
    best = min(itertools.permutations(robots), key=lambda p: sum(cost(r, t) for r, t in zip(p, tasks)))
    return list(zip(tasks, best)), sum(cost(r, t) for r, t in zip(best, tasks))
g, gt = greedy(); o, ot = optimal()
print("greedy assignment:", g, "total travel", gt)
print("optimal assignment:", o, "total travel", ot)
print("a global assignment (for example the Hungarian algorithm) removes the order dependence of greedy dispatch")

Printed (checked by the site’s tests):

greedy assignment: [('T1', 'R2'), ('T2', 'R1')] total travel 9
optimal assignment: [('T1', 'R1'), ('T2', 'R2')] total travel 7
a global assignment (for example the Hungarian algorithm) removes the order dependence of greedy dispatch

Reading it: with two robots at positions 0 and 4 and tasks at 3 and 8 arriving in that order, greedy dispatch gives the first task to the nearer robot at 4 and the second to the robot at 0, total travel 9; the optimal assignment costs 7. The example is one-dimensional and illustrative.

8. Real examples

• Warehouse: the server assigns pick tasks globally; each robot plans its own path and stops itself.

9. Failure scenarios

• A fleet that stops when the server restarts.
• First-come-first-served assignment that sends a far robot to a near task.
• Robots sharing a namespace.

10. Troubleshooting

1. Cut the network and watch what each robot does.
2. Compare assignment cost against the optimum.
3. Check identities and namespaces.

11. Validation

• The comparison prints the lines shown (executed by the site tests).
• The fleet continues safely for the defined time with the server down.

12. Engineering checklist

• Safety local
• Global assignment
• Server-loss behaviour
• Unique identities
• Network-cut test

13. Further references

• Open-RMF README: open-rmf/rmf, read 2026-11-06 (“the Open-RMF platform for multi-fleet robot management”; supported for the ROS 2 distributions Humble, Jazzy, Kilted and Rolling).

Related on FixTheRobot