Robot fleet management

Why one robot and fifty robots are different problems

A single robot doing a task is an engineering problem. Fifty robots sharing a building is an operations problem, and most of its difficulties do not exist at all in the single-robot case. Teams that solve the first and assume the second follows generally discover otherwise during the first busy shift.

Traffic

The problem that appears immediately and scales worst.

• Routing has to account for other robots, not just obstacles — and the other robots are also routing around you, which makes the environment reactive rather than static.
• Congestion emerges without anyone designing it. Aisles that work for three robots gridlock at eight, and the threshold is sharp rather than gradual.
• Deadlock is the characteristic failure: two machines each waiting for the other to move. Avoiding it requires either a central authority over space or a protocol with a guaranteed resolution, and ad-hoc politeness rules produce deadlock under load.
• Priority. When two robots want the same corridor, something must decide, and the decision has throughput consequences.
• Mixed traffic. People, forklifts and manual carts do not follow the protocol. A fleet that assumes all traffic is cooperative is not deployable in a real building.

Task allocation

Deciding which robot does which job, continuously, given position, battery, capability and current load. This is a live optimisation problem with real consequences for throughput.

The critical issue in practice is not the algorithm — it is making sure only one system is doing it. If a warehouse execution system and a robot fleet manager both believe they are allocating work, you have two planners with partial information competing for the same resources. The symptom is throughput well below the sum of the parts, and the cause is an unresolved ownership question rather than a bug.

Charging and availability

Charging is not a detail; at scale it is a scheduling constraint that shapes the whole operation. Robots must be pulled from service before they are empty, chargers are a contended resource, and charging during peak demand costs throughput while charging too conservatively costs utilisation.

Availability is the figure that actually matters, and it is worse than uptime suggests, because recovery time after a stoppage usually exceeds the stoppage itself. A machine that faults for thirty seconds and needs ten minutes of human attention was unavailable for ten and a half.

Versioning and rollout

This is where fleet management stops resembling web operations, and the differences are the important part.

• Know exactly what is running where. Software version, configuration, calibration state and model version, per machine. Without this, a fleet-wide problem cannot be correlated to a change.
• Stage rollouts. One machine, then a few, then the fleet — with a measured gate between stages, not a schedule.
• Rollback must be immediate and tested. A regression on a machine that moves is not the same as one on a server, and an untested rollback path is not a rollback path.
• Refuse unsafe updates. A machine must be able to decline an update that would put it outside a validated configuration. This makes version identity a safety-relevant property.
• Behaviour changes with the model. Updating a learned policy changes what the machine does, which can invalidate the assumptions a risk assessment was built on. A software deployment is a change to the installation, not just to the software.

Observability

When a task fails in a building with fifty robots, the question is which machine, doing what, under what conditions, and whether it is one machine or a pattern. Answering that requires instrumentation designed in from the start.

• Per-machine state, task history and intervention events.
• Enough sensor context to reconstruct what the robot perceived and decided, not merely what it did.
• Exception categories consistent across the fleet, so the same failure counts the same way everywhere.
• A single operational view, because three dashboards each showing their own layer as healthy is how interaction failures stay invisible.
• Correlation between software versions and failure rates, which is only possible if the first point in the previous section is solved.

Where the boundaries cause trouble

• Fleet manager and execution system both allocating work.
• Fleet manager and robot vendor software disagreeing about who owns routing.
• Mixed-vendor fleets, where two fleet managers each control part of the building and neither can see the other's robots. This is the hardest version and it is increasingly common.
• Safety and fleet logic. Fleet-level coordination is not a safety function and must not be relied on as one. Each machine's own safety systems remain authoritative.

Scaling, and the thresholds nobody warns you about

Fleet problems do not grow smoothly. They appear at thresholds, and the thresholds arrive sooner than expected.

• Two robots introduces traffic, and with it the first deadlock.
• Around five makes task allocation matter, because the obvious assignment stops being the good one.
• Around ten makes congestion emerge in aisles that worked fine, typically non-linearly.
• Around twenty makes charging a scheduling constraint rather than a background activity.
• Beyond that, observability becomes the limiting factor: there are now more machines than a person can hold in their head, and anything not instrumented is invisible.

The practical consequence is that a pilot with two robots validates the capability and almost nothing about the operation. If the intention is a fleet, the questions in the next section need answering at purchase, not after the second phase — because retrofitting version management and observability onto a running fleet is considerably harder than specifying them at the start.

Questions worth asking a fleet vendor

• How is deadlock prevented, and what happens when it occurs anyway?
• What happens at twice the robot density you have tested?
• Who allocates tasks, and how does that interact with our existing system?
• Can we see what version every machine is running, right now?
• What does a staged rollout look like, and how is rollback tested?
• How do you handle a mixed fleet with another vendor's robots in the same space?
• What is recorded when a task fails, and for how long is it kept?

Mixed fleets, the hardest version

Most published fleet management assumes one vendor's robots. Real buildings accumulate equipment from several, bought at different times for different tasks, and the result is two or more fleet managers each controlling part of the floor with no visibility of the other's machines.

The consequences are predictable and severe. Neither system can route around robots it cannot see. Deadlock resolution protocols do not interoperate, so two machines from different vendors in the same aisle have no agreed way to yield. Task allocation cannot balance across the whole fleet. And when throughput drops, no single system has the data to explain why.

Interoperability standards for this exist and adoption is partial, which means the practical answers today are organisational rather than technical: segregate vendors by physical zone so they never contend for the same space, or accept one vendor as the traffic authority and require the others to subordinate to it. Both are compromises. Anyone planning a multi-vendor fleet should treat this as a procurement question asked before purchase, not an integration problem discovered afterwards.

What a fleet actually needs from a capability layer

For software that runs on the robots rather than over them, being a good fleet citizen is a short list and a strict one:

• Interruptible tasks. A capability that cannot be paused, pre-empted or cancelled mid-execution cannot be scheduled by anything.
• Honest state. Reporting what it is doing, how far through it is, and whether it is stuck — promptly, not on completion.
• Consistent exception categories, so the same failure counts the same way across every machine.
• Bounded resource use. Predictable compute, memory and network, because a capability that occasionally saturates the link degrades the whole fleet.
• Version identity. Reporting exactly what is running, so fleet-wide correlation is possible at all.

Staging a change across a fleet one robot at a time: the deployment and rollback checklist.