A robot finds an aisle blocked just as an urgent pickup comes in. A teammate is waiting for the same station, while another needs to charge. Who should move next?
A fleet manager could decide, robots could work it out through local communication, or the responsibility could be shared. Each approach changes how the team divides work and recovers when communication fails.
The scale of adoption
The International Federation of Robotics reports roughly 5.08 million industrial robots operating worldwide at the end of 2025. Annual installations reached about 603,000 that year. These figures describe industrial manipulators, including factory arms. They provide context for automation adoption, rather than a count of autonomous mobile fleets. IFR industrial robotics data
Figure 1. Worldwide annual industrial robot installations, 2015 to 2025. Values are rounded to thousands in the source. Source: IFR World Robotics 2026 press presentation, slide 9. Industrial robots are a different population from the professional service robots below.
Mobile applications appear more directly in IFR’s professional service robot survey. Its 2025 shipment data put transportation and logistics at about 117,500 robots, or 47 percent of the reported total. That makes material movement a substantial, practical setting for fleet coordination. IFR service robotics release
Figure 2. Professional service robot shipments by application in IFR’s 2025 data. Exact counts are transcribed from slide 29; the press release rounds transportation and logistics to 117,500. The survey covers 238 producers from 1,001 identified manufacturers and is not projected to the whole industry. Its changing sample prevents a simple time series assembled from separate annual reports. Source: IFR World Robotics 2026 press presentation, slides 28 and 29.
Centralized fleets make shared priorities explicit
A centralized fleet manager maintains a shared picture of work and assigns tasks across robots. It might choose which robot retrieves a tote, reserve access to a narrow passage or balance charging against demand. Centralized refers to decision authority. The software can run on local servers, use redundant infrastructure and divide computation across machines.
This approach is useful when robots share constrained resources and the operator needs clear priorities. A scheduler can compare competing jobs using information that no individual robot holds. Central visibility also helps people diagnose delays and connect robot activity to warehouse or production systems.
The tradeoff is the work required to keep that shared picture current and available. Network interruptions can leave the manager with stale state. Planning can become expensive as jobs and constraints accumulate. A system needs explicit behavior for controller failure, loss of contact and recovery. Local navigation and safety functions can remain on each robot even when task allocation is centralized.
Decentralized swarms decide through local interaction
In a decentralized system, robots make decisions from local observations and information exchanged with peers. A robot might announce that it has found work, claim a task or pass along a useful observation. Other robots respond according to shared rules, without asking a single fleet scheduler to approve every choice.
This can suit work spread over an area where connectivity changes and many decisions have local consequences. Keeping communication within a neighborhood can reduce the information each robot must process. Losing one participant need not remove the fleet’s entire decision service.
Local decisions still need coordination rules. Robots can claim the same job, act on old information or disagree after a network split. A disconnected group may continue permitted work, but it cannot safely assume that an unseen robot has released a shared resource. Reconciliation, message expiry and limits on authority are essential parts of the design.
Hybrid systems divide authority by responsibility
A hybrid architecture combines shared oversight with decisions made closer to the work. A site service might set priorities and reserve critical resources, while local groups allocate nearby jobs. Robots retain their own navigation and safety responsibilities. Temporary regional coordinators can collect local summaries without holding every decision permanently.
The difficult part is specifying the boundary. Who may issue a task? How long does that authority last? Which jobs can continue without the site service? What happens when two groups reconnect with conflicting claims? These questions determine whether a hybrid system degrades predictably or simply adds another layer of failure.
| Design choice | Centralized | Decentralized | Hybrid |
|---|---|---|---|
| Task decisions | Shared fleet scheduler | Robots and peer rules | Split by scope and authority |
| Useful context | Site priorities and scarce resources | Local work and changing neighbors | Local reactions with site constraints |
| Main scaling pressure | State freshness and planning load | Peer traffic and agreement | Cross-layer consistency |
| Failure design | Failover and offline permissions | Partition and conflict recovery | Authority expiry and reconciliation |
| Cost and operation | Servers, network and central tooling | Onboard capability and distributed diagnosis | Integration and operation of both layers |
| Security focus | Protect shared authority and credentials | Validate peers and limit their authority | Enforce trust across every boundary |
Figure 3. Where coordination decisions can live. Arrows represent logical information exchange, not a prescribed radio topology. These are simplified architecture patterns, not vendor implementation diagrams. A centralized service can be replicated, and decentralized robots may still depend on shared infrastructure.
Communication load follows the design
Neither centralization nor decentralization determines network load on its own. A robot sending bounded updates to a fleet manager creates a very different workload from streaming raw sensor data. Similarly, a swarm that exchanges information with nearby peers behaves differently from one that forwards every observation throughout the fleet.
All-to-all exchange creates quadratic growth in the number of sender and recipient pairs. That growth is not exponential, and it is not an inherent property of centralized management. A hub with one logical connection per robot grows linearly in connection count. A fixed neighbor limit can also bound each robot’s immediate recipients, although relaying, retries and discovery add traffic.
Connection counts are only a starting point. Message size, update frequency, route length and radio contention determine whether useful information arrives in time. A fleet can have excellent network coverage and still make poor decisions because the information it receives is stale.
That is why we would choose networking around a workload and a site survey. Wi-Fi, private cellular networks and lower-rate radios serve different needs. No radio label guarantees a particular fleet size or end-to-end latency. Measurements must include the application, busy periods, coverage gaps and recovery after failure.
What real systems show
Amazon coordinates across a large operations network
Amazon announced its millionth deployed robot in June 2025, across an operations network spanning more than 300 facilities. It also introduced DeepFleet to improve coordination of robot movement. This is evidence of robotics operating at substantial commercial scale. The million-robot total spans facilities and should not be read as one tightly coupled fleet or one shared wireless network. Amazon Robotics announcement
Brightpick connects robot work to order fulfillment
At Rohlik’s Prague fulfillment center, Brightpick mobile robots retrieve totes and bring them to robotic picking stations. The published case describes Brightpick Intuition orchestrating the fleet and fulfillment process while robots navigate using LiDAR. It illustrates the value of shared orchestration when movement, picking and replenishment depend on each other. Brightpick is the supplier in this example. Rohlik deployment case
Ocado designs the infrastructure around the fleet
Ocado describes hundreds or thousands of bots working together on its fulfillment grids. Its account connects physical bot design with software that continually revises movement plans. The important lesson is the integration of hardware, operating environment and orchestration. Performance on a purpose-built grid does not establish what an unrestricted, mixed fleet can do in an unfamiliar building. Ocado operator account
Harvard demonstrates local coordination in the laboratory
Harvard’s 2014 Kilobot work used 1,024 physical robots to form shapes through local interaction after initialization. Nearby robots communicated using infrared signals. This is a valuable research demonstration of collective behavior at scale. Its controlled task and environment differ substantially from a commercial fleet sharing aisles, chargers and work orders. Harvard SEAS research account
Taken together, these examples support a narrower conclusion than a universal architecture ranking. Large deployments exist, local coordination has physical research evidence, and the operating environment strongly shapes which approach is useful. They do not provide a controlled comparison of cost, reliability or throughput.
Common interfaces still need integration
VDA 5050 defines communication between mobile robots and central master control systems. Version 3.0.0, published in March 2026, extends the interface for robots with greater navigation autonomy. A common interface helps suppliers agree on messages and behavior. Compatibility still requires matching supported capabilities, task meanings and failure handling in an actual installation. VDA 5050 official documentation
Building infrastructure adds another coordination boundary. Changi General Hospital describes work with KONE and partners to let different robots use shared lifts through robotics middleware. It is a concrete reminder that a robot’s useful operating area depends on doors, lifts and other systems beyond its own controller. Hospital integration account
The ECITON Robotics ambition
Our ambition is to enable 1,000 or more coordinated physical robots through integrated hardware, networking and coordination software. This is a long-term goal. It is not an achieved ECITON fleet size, a measured radio capacity or a deployment claim.
ECITON-R is our research and development project toward that goal. We are developing a coordination layer that sits above a robot’s existing navigation, motor control and safety systems. The ECITON-R Node is the working name for the on-robot hardware and runtime. A robot adapter would exchange bounded observations and high-level task intents with that layer.
The proposed coordination design lets agents choose a task preference and decide whether information is worth sending under explicit bandwidth, energy and compute budgets. Options include remaining silent, contacting a neighbor, updating shared state, spreading an observation through gossip or forwarding a regional summary. Temporary regional coordinators would serve for finite terms and remain replaceable. They must not become the only source of truth.
Figure 4. The proposed ECITON integration path. The host retains navigation, motor control and safety authority. The complete integrated path and physical fleet scale remain to be validated. This drawing describes the intended responsibilities, rather than a deployed system.
Deterministic protocol code is intended to own elections, authority expiry, duplicate suppression and conflict handling. Learned policies may later recommend actions, with comparisons against deterministic baselines. The first transport manager is also intended to be deterministic, so the coordination policy and radio-selection experiments can be evaluated separately.
Our current work includes Swarm Lab simulation and deterministic coordination software, alongside Node and gateway development. Simulation lets us inspect communication and behavior under controlled conditions. Physical integration and fleet-scale performance require their own evidence. A smaller sensing and relay demonstration can test part of the path, but it cannot establish the capacity or usefulness of a thousand-robot team.
What we need to prove
A convincing evaluation should start with a defined task and compare architectures under the same workload. Useful measures include completed work, delays at shared resources, delivered information age and recovery after failures. Communication should be measured in transmitted bytes and delivery behavior, alongside compute and energy use where physical measurements are available.
Faults belong in that evaluation. We need to see what happens when a coordinator disappears, messages arrive late or groups reconnect with conflicting state. Security also crosses every layer. Each participant needs bounded authority, and received messages need checks for identity, authorization, freshness and duplicates. Decentralization alone does not contain a compromised robot’s influence.
For ECITON, the next physical proof is a repeatable chain from an observation to a coordination decision, through a real communication path, to a useful response by another participant. We then need to measure how that behavior changes as the workload, population and network conditions change. Hardware, networking and software have to earn the scale claim together.
If you build, research or operate robot fleets, we would like to understand where coordination becomes difficult in your environment. You can explore our Swarm Lab introduction and follow ECITON Robotics as we develop and test this work.
Sources
- World Robotics 2026 press presentation. International Federation of Robotics.
- Global Sales of Professional Service Robots Surge 24 Percent. International Federation of Robotics.
- Amazon deploys its millionth robot and introduces DeepFleet. Amazon.
- One of Europe’s largest online grocers automates order picking in Prague fulfillment center. International Federation of Robotics case study.
- Meet the bots that power Ocado Group’s online grocery fulfilment across the globe. Ocado Group.
- A self organizing thousand robot swarm. Harvard SEAS.
- VDA 5050 official interface documentation. German Association of the Automotive Industry.
- Robot Lift Integration Challenge. Changi General Hospital.