The fleet
Coordination above the controller, with the reason on every assignment
Everything on this page happens at the level of tasks, zones and shared resources. Motion stays with the controllers and fleet managers that own each robot — this layer decides who does what, and records why.
Task allocation
A decision, not a nearest robot
One task, four candidates. Picking the closest idle robot is the obvious rule, and it is wrong in three of these four rows.
| Robot | Reported state | Considered as | Outcome |
|---|---|---|---|
| AMR 07 · vendor B | Idle, 31 m away, battery 18% | Below the reserve for the task and the return to a charger | Skipped — sent to charge instead |
| AMR 03 · vendor A | Idle, 44 m away, battery 82% | Can reach, carry and return with charge to spare | Assigned |
| AMR 11 · vendor A | Carrying, free in about 4 minutes | Possible, but finishes too close to the deadline | Held as fallback |
| Cell 2 transfer arm | Fault reported 2 minutes ago | Unavailable until the fault clears | Excluded |
The allocator weighs every candidate against the same state — position, current task, battery against the reserve the task needs, faults, capability and the resources on its route — and the result is deterministic: the same state and the same plan produce the same assignment. That matters less for elegance than for review, because a decision nobody can reproduce is a decision nobody can check.
It also records the reason. "Assigned: can reach, carry and return with charge to spare" travels onto the task, and "Skipped: below charge reserve" travels onto the robot that did not get it. When a shift lead asks why the far robot went, the answer is next to the task rather than in a log nobody reads.
The line it does not cross
It sends tasks. It never sends motion.
Every robot this software coordinates already has a controller and a safety system validated for the job of moving it safely, and most have a fleet manager as well. The software talks to those, in their own interfaces, at the level they expose for exactly this purpose: a task, a destination, a mission, a zone. It does not generate trajectories, drive actuators, set speeds or touch a safety-rated function, and there is no code path that could.
The vendor system executes the task under its own safety logic and is free to refuse it. A refusal is recorded with the reason the vendor gave and the work goes back to the planner; nothing retries the same command until it is accepted. An emergency stop, a protective stop or an interlock is a fact the planner observes and plans around, never a state it can clear.
That boundary is deliberate and it is not a limitation we intend to remove quietly. Software that commands motion changes what the product is, what it must be validated against and who carries the liability when something moves that should not have. If that ever changes it will be a decision announced on this page rather than a capability that appeared in a release note.
Fleet state
One vocabulary for robots that do not share one
Three vendors report the same idea three ways — a battery as a percentage, a voltage or a time remaining; a fault as a code, a string or a state machine. Each adapter maps its vendor’s reports onto one vocabulary of availability, task, position, battery and fault, and keeps the original report beside the mapped one so a vendor’s own engineer can still read it.
Every reading keeps two timestamps: when it happened on the robot, and when it reached the system. Plans use the first. A robot whose reports have stopped is marked stale after its own heartbeat interval rather than left showing its last good state, because a fleet view that shows a silent robot as idle will eventually assign it work.
Where a vendor only reports status and accepts no tasks, the robot appears in the fleet view and is never offered work. The software is explicit about which robots it can dispatch to and which it can only watch.
Shared resources
A lift belongs to one task at a time
Most multi-robot failures on a real floor are not collisions — the controllers prevent those — but deadlocks: two robots each waiting for something the other holds. A lift, a fire door, a narrow aisle, a charger, a handover station. The planner treats each of these as a resource with a calendar and reserves it explicitly for the task that needs it.
Two tasks holding the same resource over the same interval is refused at planning time, naming both tasks and the resource, rather than discovered when the second robot arrives and waits. Reservations are released when a task completes or is cancelled, and a reservation whose task has gone silent expires rather than holding the resource forever.
Resources crossing vendor boundaries are where this matters most. A lift shared by two vendors’ fleets is invisible to each vendor’s own fleet manager; it is only coordinated if something above both of them owns the reservation.
Replanning
When a robot drops out, the plan changes in the open
Robots fault, run low, get pulled for maintenance and go offline. When one does, the tasks it held are returned to the planner and reallocated under the same rules that allocated them the first time — capability, charge, reservations, deadline — and the reassignment carries its reason like any other.
Replanning is bounded by the plan a person released. Moving a task to another robot inside the released plan is routine and recorded; a change that would move work outside it — a later delivery, a different line, a schedule that breaks a demand limit — is raised to the person who released the plan rather than made silently.
And when the work cannot be done at all, the software says so early. A task that no available robot can complete before its deadline is flagged at the moment that becomes true, not when the deadline passes.
Swarm coordination
Distributed where it helps, auditable everywhere
For large fleets, allocation is distributed: robots or zones bid for work against local state, and conflicts are resolved by explicit rules rather than by whichever message arrived first. Distribution buys speed and resilience — a fleet keeps working when one coordinator is slow — and it is only acceptable here because every outcome is still recorded with the bids and the rule that decided it.
Coordination covers what a swarm actually needs: task allocation, conflict resolution over shared resources, rebalancing when demand moves between zones, and replanning when robots or equipment become unavailable. It does not cover formation, path or motion behaviour, which stay with the vendors’ own systems.
The goal is fleet-level throughput rather than any single robot’s efficiency. A robot that idles for thirty seconds so two others avoid a deadlock is the swarm working correctly, and the record says so.
Simulation
Every new behaviour runs on your layout first
A new allocation rule, a new zone, a changed charging policy or a larger fleet is run in simulation against your own layout, your own resource calendar and a replay of your own recorded demand before it can be released. The output is the thing a person needs to decide: throughput, waiting time, conflicts, charge levels and energy draw, beside the same figures for the plan running today.
Simulation is a gate, not a report. A coordination change that has not been simulated against the layout it will run on cannot be released, and the release records which simulation it was approved against.
Provenance
Every dispatched task traces to a released plan
A task reaches a robot from a released plan or it does not reach one. Each dispatched task carries the plan it came from, the fleet state it was allocated against, the reason it went to this robot, the resources it reserved and the person who released the plan.
A suggestion from a model — a schedule to compare, an anomaly to look at — has nothing computed behind it and cannot become a dispatched task. That is enforced structurally: the allocation path cannot import the model client, and the build fails if it can.
In the console this is a chain you can walk. Click a task on the floor view and you get the robot, the reason, the reservations, the plan, its simulation and the person who released it.
In one place
Everything the coordination layer refuses to do
The stops, collected. A reader evaluating this page is really asking whether they are real, so they are worth listing together.
- Send a trajectory, a speed or any motion command to a robot
- Command, clear or bypass an emergency stop, interlock or safety-rated function
- Retry a task a vendor system refused until it is accepted
- Dispatch a task from a plan nobody released
- Assign work to a robot whose last report is older than its heartbeat
- Assign work to a robot that reported a fault which has not cleared
- Let two tasks hold the same shared resource over the same interval
- Offer work to a robot whose vendor interface only reports status
- Release a coordination change that was not simulated on the layout it will run on
- Move work outside a released plan without raising it to the person who released it
- Let a model’s suggestion become a dispatched task
- Offer a flag that turns any of the above off
Bring the shift where the robots waited
The fastest way to judge a coordination layer is to point it at a shift that went badly — the fleet you run, the layout, and where the work stalled. Send us those and we will show you what it would have done with them.
Get in touch
Talk to the people building it
No chatbot and no ticket queue. Tell us what your floor actually looks like — the robots and who supplies them, the systems they already report to, and what you would like coordinated first — and someone who works on the software will reply.
info@legosphere.com