Robot fleet management software is the layer that turns a group of individual robots into a working system. One autonomous mobile robot can follow a map and carry a tote. Twenty of them, sharing aisles with forklifts and people, need something above them that decides which robot takes which job, keeps them from blocking each other at a junction, sends them to charge at the right moment, and tells a supervisor when one is stuck. That something is robot fleet management.
The category matters more every year. The International Federation of Robotics (IFR) counted almost 200,000 professional service robots sold in 2024, and more than half of them, 102,900 units, were built for transport and logistics. Most of those machines move goods inside warehouses and factories, and every site that runs more than a handful of them has to answer the same question: who coordinates the fleet?
This guide explains what robot fleet management software does, the standards that let robots from different makers share one site, how the architecture fits together with a warehouse management system, what to measure, how to size a fleet, what it costs and how to choose a platform. It is written for operations leaders, engineers and IT teams planning a first multi-robot deployment, or untangling one that grew by accident.
It sits alongside our coverage of the wider robot software stack, including NVIDIA Isaac ROS 5.0 and browser-based robotics simulation testing. Figures come from the named public sources listed at the end. Where a number is a planning assumption rather than a published figure, the text says so.
Table of contents
- What Is Robot Fleet Management Software?
- Core Functions of Robot Fleet Management Software
- Three Kinds of Robot Fleet Management Platform
- Robot Fleet Management Interoperability Standards
- Robot Fleet Management Architecture
- Integrating Robot Fleet Management With WMS, MES and ERP
- Robot Fleet Management Platforms to Know in 2026
- Safety and Compliance for Robot Fleet Management
- Robot Fleet Management KPIs That Matter
- Sizing a Fleet: A Worked Robot Fleet Management Example
- What Robot Fleet Management Software Costs
- How to Choose Robot Fleet Management Software
- A Robot Fleet Management Implementation Roadmap
- Common Robot Fleet Management Mistakes
- The Future of Robot Fleet Management
- Robot Fleet Management FAQs
- References and Further Reading
What Is Robot Fleet Management Software?
Robot fleet management software is a central application that assigns work to a group of robots, coordinates how they move through shared space, manages their energy, and reports on their health and performance. The rest of this section unpacks that definition and explains why demand is rising.
A working definition from the VDA 5050 standard
The German VDA 5050 specification, the most widely cited interface standard in this field, lists the minimum functions of a fleet control system. They are: assigning orders to robots, calculating routes, detecting and resolving deadlocks, managing energy, controlling traffic, handling temporary changes such as closed areas or lower speed limits, communicating with doors, gates and lifts, and detecting communication errors. That list is a good practical definition of robot fleet management, and a useful checklist when you compare products.
Robot fleet management versus onboard autonomy
A modern autonomous mobile robot (AMR) already localises itself, plans a local path and avoids obstacles using lidar, cameras and computer vision. None of that is fleet management. Onboard autonomy answers the question “how do I get from A to B without hitting anything?” Robot fleet management answers a different one: “which robot should go from A to B, when, by which corridor, and what happens to the three robots already queued at B?” The two layers talk constantly, but they are separate products, often from separate vendors.
Where robot fleet management is used
Warehouses and distribution centres are the largest users, followed by factories moving parts to production lines. Hospitals run fleets of delivery robots for linen, meals and medicines, which is where the open-source Open-RMF project began. Cleaning robots in airports and shopping centres, inspection robots on energy sites and security robots on large campuses all need fleet software too. The priorities differ: a cleaning fleet cares about coverage and schedules, while a warehouse fleet cares about throughput per hour.
Why demand for robot fleet management is growing
The growth shows in the IFR’s figures. Sales of transport and logistics robots rose 14% in 2024, and robot-as-a-service (RaaS) contracts in that segment grew 42%. On the industrial side, the IFR’s World Robotics 2026 report, released on 24 September 2026, puts the global operating stock of industrial robots at a record 5 million units. More robots per site means more coordination per robot, which is exactly the problem robot fleet management software exists to solve.
Transport and logistics robots outsold every other professional service category in 2024 by more than two to one.
Core Functions of Robot Fleet Management Software
Every serious robot fleet management platform covers the same seven jobs. Vendors differ in how well they do each one, and in which ones they quietly leave to you or your integrator.
Task allocation and dispatch
Work arrives from a warehouse management system (WMS), a manufacturing execution system (MES), a button on a workstation, a timetable or an operator’s tablet. The fleet manager turns each request into a mission and picks the robot best placed to do it, based on location, battery level, payload type and current workload. Better systems chain tasks so a robot that has just dropped a load picks up the next job nearby, and reassign a mission automatically when a robot faults halfway through it.
Traffic management and deadlock resolution
Once several robots share a floor, they meet at junctions, in narrow aisles and at lift doors. Robot fleet management software reserves space ahead of each robot, enforces one-way routes and waiting positions, and spots deadlocks, where two robots each wait for the other to move, before they freeze a whole zone. For line-guided robots the fleet server usually plans the whole route. For freely navigating robots it sets the rules and lets the robot plan within them.
Charging and energy management
Robots that run out of charge in an aisle become obstacles. Fleet software decides when each robot charges, which charger it uses and how charging fits around peak demand. Many systems use opportunity charging, topping robots up during short idle gaps rather than taking them out of service for long cycles. VDA 5050 notes that charging orders can interrupt transport orders, which is a policy decision you should make deliberately, not leave to a default.
Maps, zones and site configuration
The site map is shared infrastructure. Robot fleet management software stores map versions, pushes them to robots and defines zones: speed limits near pedestrian crossings, no-go areas during maintenance, one-way aisles and loading bays. VDA 5050 version 3.0 adds standard actions to download, enable and delete maps on a robot, so map changes can be controlled centrally rather than robot by robot.
Monitoring, alerts and remote assistance
A live view of every robot, its mission, its battery and its errors is the part of robot fleet management that supervisors use every hour. VDA 5050 3.0 defines four error levels. A WARNING, such as a dirty lidar scanner, needs no immediate action. An URGENT issue, such as low battery, needs attention but the robot can continue. A CRITICAL issue, such as trying to pick up a load that is not there, stops the robot but it can take new orders. A FATAL issue, such as lost localisation, needs a person.
Software updates and configuration control
Robots, like laptops, need updates, and a fleet of 40 cannot be updated one at a time by hand. Good fleet software stages updates to part of the fleet, pins versions per robot type, and rolls back when something goes wrong. The same discipline applies to configuration: who changed a speed zone, when, and why. Our device management work follows the same principles for other connected equipment.
Analytics and reporting
Finally, robot fleet management software records what happened: missions completed, time spent waiting, errors by location, charge cycles and interventions. The best platforms export raw events so you can analyse them in your own tools rather than only in the vendor’s dashboard.
| Function | What it decides | Question to ask a vendor |
|---|---|---|
| Task allocation | Which robot does which job, in what order | Are missions reassigned automatically when a robot faults? |
| Traffic management | Right of way at junctions, aisles and lifts | How are deadlocks detected and cleared without a person? |
| Energy management | When and where each robot charges | Can charge thresholds change by shift or time of day? |
| Maps and zones | Speed limits, no-go areas, one-way routes | Can a zone change go live without stopping the fleet? |
| Monitoring | Status, errors and who is alerted | Which alerts reach a phone, and who acknowledges them? |
| Updates | Software and configuration versions | Can updates be staged to part of the fleet and rolled back? |
| Analytics | Throughput, utilisation and interventions | Can raw event data be exported to our own tools? |
Three Kinds of Robot Fleet Management Platform
Products sold as robot fleet management fall into three broad groups. Knowing which group a product belongs to saves a lot of confused demos.
Vendor fleet managers
Almost every AMR maker ships its own fleet manager, tuned for its own robots. These are usually the most capable option for a single brand, because the vendor controls both ends of the conversation. The catch is lock-in. As the IFR’s explainer on VDA 5050 puts it, AGVs have typically worked only with their manufacturer’s own fleet software, which creates complex commissioning, trouble when robots of different brands need to cross paths or share a lift, and lost floor space when each brand needs separate routes.
Multi-vendor orchestration layers
Orchestration layers sit above the robots and command several brands through one system. Some talk to each vendor’s fleet manager; others command robots directly through a standard interface such as VDA 5050. They are the answer when a site mixes, say, pallet movers from one maker with tote robots from another, and both need to use the same aisles, doors and lifts.
Observability and RobOps platforms
A third group focuses less on real-time traffic control and more on seeing and operating fleets at scale: telemetry, remote assistance, incident history, data pipelines and analytics across sites and robot types. Cloud platforms such as Formant and InOrbit sit here. They suit robot makers who need to support deployed fleets, and operators running many sites who need one view of robot fleet management performance across all of them.
Which kind of robot fleet management you actually need
A single-brand site with one use case rarely needs more than the vendor’s own manager. Two or more brands sharing space need an orchestration layer or a common interface. Many sites, or a business that builds robots, benefit from an observability platform on top. Many real deployments combine two of the three, and that is fine as long as the boundaries of each are clear.
| Type | Real-time traffic control | Mixed brands | Best fit |
|---|---|---|---|
| Vendor fleet manager | Yes, for its own robots | Rarely | One brand, one main process |
| Multi-vendor orchestrator | Yes, across brands | Yes, via adapters or VDA 5050 | Mixed fleets sharing space |
| Observability platform | Usually not | Yes | Many sites, robot makers, remote support |
Robot Fleet Management Interoperability Standards
Standards are what make multi-vendor robot fleet management practical. Three matter most today, and they solve different parts of the problem.
VDA 5050: the common language for AGVs and AMRs
VDA 5050 is an open interface between mobile robots and a central fleet control, developed jointly by the German Association of the Automotive Industry (VDA) and the VDMA Materials Handling and Intralogistics Association. Messages travel over MQTT in JSON format, with MQTT 3.1.1 as the minimum version. Most topics use MQTT quality-of-service level 0 to keep traffic light, while the connection topic uses level 1. The specification is published openly on GitHub under the MIT licence.
Version 2.0 appeared in November 2021 and version 2.1 in August 2024. Version 3.0 was published on GitHub in March 2026 and announced by the VDA on 20 April 2026, after a public consultation that ran until early February 2026 under the technical supervision of the Institute of Materials Handling and Logistics at the Karlsruhe Institute of Technology.
What changed for robot fleet management in VDA 5050 3.0
Earlier versions suited line-guided vehicles that follow routes set by the fleet server. Version 3.0 adds support for freely navigating robots. A zone concept lets the fleet control define restricted areas, one-way routes and areas where a robot needs explicit permission to enter. Robots then plan their own routes between waypoints and share those planned paths back to the fleet control, which can still manage traffic. The update also adds URGENT and CRITICAL error levels, error messages in local languages, and a standard power-saving mode. Predefined trajectories and corridors remain for simpler vehicles.
| VDA 5050 3.0 topic | Published by | Used for | Status |
|---|---|---|---|
| order | Fleet control | Sending orders to a robot | Mandatory |
| instantActions | Fleet control | Actions to run immediately | Mandatory |
| state | Robot | Reporting the robot’s state | Mandatory |
| connection | Broker or robot | Flagging a lost connection | Mandatory |
| factsheet | Robot | Robot parameters for set-up | Mandatory |
| visualization | Robot | High-frequency position and planned path | Optional |
| zoneSet | Fleet control | Transferring zone sets to a robot | Optional |
| responses | Fleet control | Answering requests from a robot | Optional |
Open-RMF: open-source coordination across fleets and buildings
Open-RMF describes itself as a free, open-source, modular system that enables sharing and interoperability between multiple fleets of robots and physical infrastructure such as doors, lifts and building management systems. It was originally developed for healthcare, is built on ROS 2 and is licensed under Apache 2.0. Since 2024 it has been managed by the Open Source Robotics Alliance, and its main repository currently supports the ROS 2 Humble, Jazzy, Kilted and Rolling distributions.
Open-RMF connects to each robot fleet through a fleet adapter. With Full Control, the adapter can send explicit paths and replace them at any time. With Traffic Light control, the adapter can only pause and resume robots that otherwise move by themselves. Simplified EasyFullControl and EasyTrafficLight interfaces reduce the integration work. For robot fleet management in hospitals, offices and airports, where robots must share lifts and doors with the public, this building-level coordination is the main attraction.
The MassRobotics AMR Interoperability Standard
The MassRobotics standard, released as version 1.0 in May 2021, takes a lighter approach. Rather than commanding robots, it lets robots of different types share information about their location, speed, direction, health, tasking and availability, so they can coexist on the same floor. It is defined as a JSON schema, and the reference sender and receiver on GitHub exchange messages over WebSockets. It suits sites where each vendor keeps its own fleet manager but everyone needs to know where everyone else is.
How the three standards fit into robot fleet management
The standards are complementary rather than rivals. VDA 5050 is a command interface between a fleet control and each robot. Open-RMF coordinates several fleets and the building around them. MassRobotics shares status so separate fleets can coexist. A realistic mixed site might use VDA 5050 to command new robots, an Open-RMF-style layer for lifts and doors, and status sharing for older robots that support neither.
| Standard | What it standardises | Transport | Latest release | Licence |
|---|---|---|---|---|
| VDA 5050 | Orders, actions and state between fleet control and robot | MQTT with JSON | 3.0.0, March 2026 | MIT |
| Open-RMF | Multi-fleet traffic, tasks, doors and lifts | ROS 2 | Tracks current ROS 2 releases | Apache 2.0 |
| MassRobotics | Status sharing for coexistence | JSON over WebSockets | 1.0, May 2021 | Published schema |
Robot Fleet Management Architecture
A working robot fleet management system has five layers. Each can fail on its own, so it helps to know where the boundaries are.
Robots and onboard autonomy
At the bottom are the robots, each running its own navigation, safety systems and sensors. The robot is responsible for not hitting anything. Fleet software never replaces the robot’s safety-rated obstacle detection, and a design that assumes otherwise is a design to reject.
The message layer
Robots and fleet server exchange messages constantly. VDA 5050 standardises this on MQTT, a lightweight publish-and-subscribe protocol, through a broker that every robot connects to. The specification expects that communication to be secured, typically with TLS, and includes a standard action for pushing new certificates to a robot. Treat the broker as critical infrastructure, with monitoring, redundancy and access control of its own.
The fleet server: on site, at the edge or in the cloud
Traffic control needs low, predictable latency and must keep working if the internet connection drops, so in most warehouses the robot fleet management server runs on site or on an edge server. Cloud services are better suited to analytics, fleet-wide dashboards, remote support and long-term storage. A sound design keeps robots moving safely during a cloud outage and syncs the history later.
Building systems: doors, lifts and PLCs
Robots need to open fast doors, call lifts and hand over loads to conveyors. Fleet software talks to these through programmable logic controllers (PLCs) or building systems. OTTO Fleet Manager, for example, communicates with existing PLCs using OPC UA, and Open-RMF includes adapters for doors and lifts. Budget time for this work: it is often slower than integrating the robots themselves.
Simulation and digital twins
Many robot fleet management platforms let you model a site before any robot arrives: routes, traffic, charger positions and fleet size. Simulation catches bottlenecks that are expensive to discover on a live floor. It is also the safest place to test map changes and software updates later on, which is why simulation tools increasingly sit alongside the fleet manager rather than only in the engineering lab.
Integrating Robot Fleet Management With WMS, MES and ERP
Robots create value only when they are connected to the systems that know what needs moving. Most robot fleet management projects that disappoint do so at this boundary, not in the robots.
Decide who owns each task
The WMS or MES knows what needs to move and when. The fleet manager knows how to move it. Keep that split clean. Business systems should create missions such as “move pallet X from dock 4 to aisle 12”, and the fleet software should choose the robot, route and timing. A WMS that tries to micro-manage individual robots duplicates logic and breaks every time the fleet changes.
Use events, not polling
Good integrations exchange events: mission created, accepted, load collected, delivered, failed. MiR describes a REST API for integrating its fleet software with ERP, WMS and MES platforms, and OTTO describes open APIs for the same purpose. Whatever the interface, make each message idempotent, so a retried request cannot create a duplicate mission.
Plan for exceptions first
The happy path is easy. The work is in exceptions: a blocked destination, a load that is not where the WMS says it is, a robot that faults while carrying goods, a mission cancelled halfway. Write down how each exception is detected, which system owns the fix, and what the operator sees. This is where custom software development often earns its keep, because no two sites handle exceptions the same way.
Common integration failures
Three problems recur. Location names differ between the WMS and the robot map, so missions fail on lookup. Clocks drift between systems, so event timelines make no sense during an incident. And nobody owns the integration after go-live, so small changes in the WMS silently break robot fleet management workflows months later.
Robot Fleet Management Platforms to Know in 2026
The market changes quickly, so treat this as a map of the landscape rather than a ranking. Every capability below comes from the vendor’s own published material.
Single-vendor robot fleet managers
MiR Fleet, from Mobile Industrial Robots, gives web-based central control of up to 100 MiR robots and offers a REST API for ERP, WMS and MES integration. OTTO Fleet Manager handles fleets from one robot to 100, supports opportunity charging, and, through VDA 5050 compliance, lets OTTO robots take orders from third-party controllers. Locus Robotics says its LocusONE platform supports a thousand or more robots in sites as large as one million square feet, coordinating several robot form factors as one fleet. Boston Dynamics’ Orbit manages fleets of Spot inspection robots, with dashboards across sites and integration with maintenance and warehouse systems.
Multi-vendor robot fleet management platforms
SYNAOS offers vendor-independent fleet control based on VDA 5050 and reports more than 40 mobile robot partners, more than 50 live installations and a multi-brand VDA 5050 fleet of more than 130 robots. Meili Robots positions Meili FMS as a universal fleet manager compatible with ROS 1, ROS 2 and VDA 5050, with traffic control at intersections. Integrators also build multi-fleet systems on Open-RMF, trading licence fees for engineering effort.
Observability, cleaning and inspection platforms
Formant and InOrbit focus on operating and analysing fleets across robot types and sites. In commercial cleaning and retail, Brain Corp builds its BrainOS autonomy platform into robots from OEM partners and reports more than 50,000 robots deployed and more than 25 million hours of real-world operation. These platforms rarely replace a warehouse traffic controller, but they are often the tool a support team opens first.
Optimisation engines
Some organisations build their own robot fleet management logic and buy only the hard mathematics. NVIDIA cuOpt is an open-source, Apache 2.0 licensed, GPU-accelerated solver for linear programming, mixed-integer programming and vehicle routing problems. Its documentation includes a worked example of pickup-and-delivery routing with time windows for a fleet of AMRs on a factory floor. For developers, it pairs naturally with edge hardware such as the Jetson Orin Nano 2 on the robot side.
Lessons from products that disappeared
Two recent exits are worth remembering. Zebra Technologies bought Fetch Robotics in 2021, decided in December 2025 to exit its robotics automation business, and sold the Fetch unit to Skild AI in April 2026. Amazon Web Services discontinued its RoboMaker robotics service on 10 September 2025 and pointed customers to AWS Batch. If your robot fleet management depends on a single product, your contract should cover data export, source escrow or transition support, and your integration should use standard interfaces wherever possible.
| Platform | Type | Documented capability |
|---|---|---|
| MiR Fleet | Vendor manager | Up to 100 MiR robots, REST API for ERP, WMS and MES |
| OTTO Fleet Manager | Vendor manager | 1 to 100 robots, OPC UA to PLCs, VDA 5050 compliant robots |
| LocusONE | Vendor platform | 1,000+ robots, sites up to one million square feet |
| Boston Dynamics Orbit | Vendor platform | Spot fleets, multi-site dashboards, maintenance system links |
| SYNAOS | Multi-vendor | VDA 5050 fleet control, 40+ robot partners |
| Meili FMS | Multi-vendor | ROS 1, ROS 2 and VDA 5050 compatible |
| Open-RMF | Open source | Multi-fleet traffic, doors and lifts, Apache 2.0 |
| NVIDIA cuOpt | Optimisation engine | GPU routing and scheduling solver, Apache 2.0 |
Safety and Compliance for Robot Fleet Management
Fleet software does not make a robot safe, but it changes how robots behave on site, so it sits inside the safety case. Four frameworks matter most for UK and European sites.
ISO 3691-4:2023 for driverless industrial trucks
ISO 3691-4:2023 sets safety requirements and verification for driverless industrial trucks and their systems, a category that covers automated guided vehicles and AMRs. It addresses the vehicle, its control system and the wider system around it, including operating zones where people and robots meet. It also sets out shared responsibilities between the robot manufacturer, the integrator and the site operator, so ask each supplier which edition they design to and how the site risk assessment is split between you.
ANSI/A3 R15.08 for industrial mobile robots
In North America, the ANSI/A3 R15.08 series covers industrial mobile robots. Part 1 sets requirements for the robots themselves. Part 2, released in October 2023, is written for system integrators and covers risk assessment for a deployment, including collections of robots operating together as an industrial mobile robot fleet. A planned Part 3 will address users. Even outside the US, Part 2 is a useful checklist for robot fleet management design reviews.
The EU Machinery Regulation and the UK position
The EU Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and replaces the Machinery Directive 2006/42/EC. According to the European Commission, it adds provisions for machinery with AI-powered safety functions and for the cyber-safety of software and safety control systems. In Great Britain, machinery is still placed on the market under the Supply of Machinery (Safety) Regulations 2008, and employers must meet the Provision and Use of Work Equipment Regulations 1998, known as PUWER. HSE’s workplace transport guidance also applies wherever robots share routes with people and vehicles.
Cybersecurity for robot fleets
A robot fleet is an operational technology network that moves heavy objects near people. Segment it from office IT, secure the MQTT broker, rotate certificates, and control remote access tightly. The ISA/IEC 62443 series and the NCSC’s operational technology guidance are the natural references. Our IT security team treats robot networks the same way as any other industrial control system, including basic cybersecurity hygiene such as patching and access reviews.
| Framework | Scope | Main audience |
|---|---|---|
| ISO 3691-4:2023 | Driverless industrial trucks and their systems | Robot makers and integrators |
| ANSI/A3 R15.08-2 | Mobile robot systems, applications and fleets | System integrators |
| EU 2023/1230 | Machinery placed on the EU market from 20 January 2027 | Manufacturers and importers |
| PUWER 1998 | Safe use of work equipment in Great Britain | Employers and site operators |
| ISA/IEC 62443 | Security of industrial automation and control systems | Operators, integrators and suppliers |
Robot Fleet Management KPIs That Matter
What you measure shapes how the fleet is run. These five KPIs cover most of what an operations team needs from robot fleet management reporting.
Fleet utilisation
Utilisation is the share of available time robots spend on productive missions. Very low utilisation means you bought too many robots or the process does not feed them. Very high utilisation, above about 85%, sounds good but leaves no headroom for peaks, faults or charging, and queues start to grow quickly.
Missions per hour and cycle time
Missions per hour is the output the business cares about. Break the average cycle time into travel, load handling and waiting. Waiting time is the part robot fleet management software controls most directly, through better task allocation and traffic management, so it is the number to watch after every change.
Interventions per 1,000 missions
Count every time a person has to help a robot: freeing it, moving a blocking object, re-localising it. Normalise per 1,000 missions so the figure stays comparable as volume grows. A rising intervention rate is often the first sign of a map drifting out of date or a layout change nobody told the fleet about.
Availability, MTBF and MTTR
Availability is the share of scheduled time a robot is able to work. Mean time between failures (MTBF) and mean time to repair (MTTR) explain why availability moves. Track them by robot type and by location, since a single troublesome doorway can dominate a site’s figures.
Battery health and charging
Track charge cycles, time spent charging and battery capacity over time. Batteries fade, and a fleet sized on new-battery run times will quietly come up short a couple of years later. Good robot fleet management reporting shows this trend before it shows up as missed orders.
| KPI | How to calculate it | Warning sign |
|---|---|---|
| Utilisation | Mission time divided by available time | Above 85% at peak, or below 40% all day |
| Cycle time | Travel plus handling plus waiting, per mission | Waiting share rising week on week |
| Intervention rate | Human interventions per 1,000 missions | Clusters at one location or shift |
| Availability | Time able to work divided by scheduled time | One robot type lagging the rest |
| Charging share | Time charging divided by scheduled time | Creeping up as batteries age |
Sizing a Fleet: A Worked Robot Fleet Management Example
How many robots does a site need? The answer depends on the process, but the arithmetic is simple enough to do on one page. The inputs below are planning assumptions for illustration, not figures from any vendor.
The inputs
Assume a warehouse needs 240 transport missions an hour at peak. Each mission takes an average of 3.0 minutes of travel, 1.0 minute of load handling and 0.5 minutes of waiting at junctions and stations, a cycle time of 4.5 minutes. After charging, each robot is available 85% of the time. To keep headroom for peaks and faults, the plan caps utilisation at 80%.
The arithmetic
One robot completes 60 ÷ 4.5 = 13.3 missions an hour if it never stops. Multiply by 85% availability and the 80% utilisation cap (0.85 × 0.80 = 0.68) and each robot can be planned for 9.1 missions an hour. The site therefore needs 240 ÷ 9.07 = 26.5, rounded up to 27 robots, plus one spare for maintenance: 28 in total.
What better robot fleet management is worth
Cycle time drives fleet size, and waiting time is the part of the cycle that fleet software controls most directly. Every extra half-minute of average cycle time costs about three robots at this volume.
Amazon says its DeepFleet foundation model improves the travel time of its robot fleet by 10%. Apply that to the 3.0 minutes of travel here and the cycle falls to 4.2 minutes. The same 240 missions then need 25 robots instead of 27 (240 ÷ (60 ÷ 4.2 × 0.68) = 24.7, rounded up). Cutting waiting from 0.5 to 0.2 minutes has the same effect. Either way, two robots saved is a figure to set against the price of better robot fleet management software.
What Robot Fleet Management Software Costs
Published price lists are rare in this market, so budgets usually start from quotes. It still helps to understand the pricing models and where the hidden costs sit.
Robot fleet management pricing models
Vendor fleet managers are often bundled with the robots, sometimes with a per-robot annual software fee. Multi-vendor platforms usually charge a subscription per robot per month, or a site licence. Robot-as-a-service contracts fold robots, software and support into one monthly fee, a model the IFR says is growing quickly. Open-source software such as Open-RMF has no licence fee, but it needs engineering time to integrate, operate and support.
The costs outside the licence
The licence is rarely the largest line. Budget for a site survey, Wi-Fi improvements, server or edge hardware, WMS and PLC integration, door and lift interfaces, training, support and change requests over the life of the system. Wireless coverage alone can stall a project: robots that lose connection in a cold store or behind racking stop being part of robot fleet management at all.
An illustrative three-year budget
The comparison below uses planning assumptions for a 20-robot site, not vendor prices: a subscription of £120 per robot per month; a perpetual licence of £45,000 with 20% annual support; integration at a £650 day rate, taking 25 days for a commercial product and 90 days for a self-integrated open-source build, which also needs 2 support days a month.
| Model (20 robots, 3 years) | Software | Integration and support | Total |
|---|---|---|---|
| Per-robot subscription | 20 × £120 × 36 = £86,400 | 25 days × £650 = £16,250 | £102,650 |
| Perpetual site licence | £45,000 + 3 × £9,000 = £72,000 | 25 days × £650 = £16,250 | £88,250 |
| Open-source, self-integrated | £0 | (90 + 72) days × £650 = £105,300 | £105,300 |
On these assumptions the three options land within about £17,000 of each other over three years, so the licence model matters less than the integration and support effort behind it.
How to Choose Robot Fleet Management Software
Choosing well comes down to a few disciplines applied in the right order.
Start from the process, not the robot
Map the material flows first: what moves, from where to where, how often, at what peak, and what happens when it goes wrong. Then choose robots that suit those flows, and robot fleet management software that can coordinate them. Buying robots first and discovering the orchestration problem later is the most expensive order to do things in.
Insist on open interfaces
Ask every vendor which standards they support today, not on a roadmap: VDA 5050 version and topics, Open-RMF adapters, REST or event APIs for business systems, OPC UA for PLCs. Ask for the API documentation before signing. Open interfaces are what let robot fleet management outlive any single robot model.
Prove it in simulation, then in a pilot
Ask the vendor to simulate your layout and peak volumes, then run a pilot with a small fleet on a real route. Measure cycle time, interventions and availability against the plan. A vendor confident in its robot fleet management software will welcome this; one that resists it is telling you something.
Contract for the exit as well as the launch
Agree who owns operational data, how it can be exported, what happens if the product is discontinued, and what support looks like after year one. The Fetch and RoboMaker examples show why this is not a theoretical worry.
| Area | What good looks like | Red flag |
|---|---|---|
| Interoperability | Named VDA 5050 version, documented APIs | “Open” with no public specification |
| Scale | Reference sites at your fleet size or larger | Only demos with a handful of robots |
| Resilience | Robots stay safe and useful if the cloud link drops | Traffic control only in the cloud |
| Data | Raw events exportable, you own them | Dashboard-only access |
| Security | TLS, certificate rotation, role-based access | Shared logins, open ports |
| Exit | Data export and transition support in contract | No answer on discontinuation |
A Robot Fleet Management Implementation Roadmap
Most successful rollouts follow the same five phases, whatever the robots.
Phase 1: map the flows and the site
Survey routes, doors, lifts, floors, gradients and wireless coverage. Collect volumes by hour for a typical day and a peak day. Agree the KPIs that will define success.
Phase 2: simulate and design
Model the layout, fleet size and charger positions. Design the integration with the WMS or MES, including every exception path. Decide which system owns each decision.
Phase 3: pilot a small fleet
Run a few robots on one real route. Tune zones, speeds and task rules. Train operators and supervisors, and test the alerting chain at night, not just during the day shift.
Phase 4: integrate and scale
Connect business systems fully, add robots in steps, and watch cycle time and interventions after each step. Scaling robot fleet management too fast hides the cause of any drop in performance.
Phase 5: tune and extend
Review KPIs monthly. Adjust task rules, charging thresholds and zones as the business changes. Add new robot types through standard interfaces rather than new silos, and feed the event data into your data analytics platform alongside the rest of the operation.
Common Robot Fleet Management Mistakes
The same errors appear again and again. Each is cheap to avoid and expensive to fix.
Buying robots before choosing the orchestrator
A second robot brand arrives for a new use case, and suddenly two fleets share aisles with no common control. Decide early how multi-vendor robot fleet management will work, even if the first phase uses one brand.
Treating wireless as someone else’s problem
Robots depend on the network more than laptops do, and they move through racking, cold stores and dock doors. Survey coverage along every route and plan roaming, not just signal strength.
Forgetting people and manual trucks
Robots share space with people, forklifts and pallet trucks that no fleet software controls. Design zones, crossings and signage for the mixed reality, and involve the people who work on the floor.
No change control for maps and software
An untracked map edit or an unplanned update can stop a fleet. Treat maps, zones and robot software as configuration under change control, tested in simulation first where possible.
Measuring robots instead of flow
A fleet can report high utilisation while orders still leave late. Measure the business outcome, orders or parts delivered on time, alongside the robot fleet management statistics.
The Future of Robot Fleet Management
Three trends are reshaping the field.
Foundation models for fleet coordination
In July 2025 Amazon announced that it had deployed its one millionth robot across more than 300 facilities, and introduced DeepFleet, a generative AI foundation model that coordinates robot movement across its fulfilment network. A research paper published in August 2025 describes DeepFleet as a suite of four model architectures trained on movement data from hundreds of thousands of robots, including one that combines temporal attention with graph neural networks. Few operators have Amazon’s data, but the direction is clear: robot fleet management is becoming a learning problem, not just a rules problem.
Freely navigating robots and shared paths
VDA 5050 3.0 formalises a shift already visible on warehouse floors. Rather than dictating every route, fleet control sets zones and rules, robots plan their own paths, and the two share plans so traffic can still be managed. Expect vendors to compete on how well their robot fleet management handles these negotiated routes.
Mixed fleets with humanoids and mobile manipulators
Mobile manipulators and humanoid robots are moving from demos towards pilots, as our coverage of humanoid robot control in narrow gaps shows. ANSI/A3 R15.08-2 already distinguishes robot platforms, robots with attachments and robots with manipulators. Robot fleet management will need to schedule work for machines that can pick, place and open doors, not just carry loads, and to coordinate them with the IoT solutions already running on site.
Robot Fleet Management FAQs
What is robot fleet management software?
It is software that assigns work to a group of robots, controls their traffic, manages charging, and monitors their health and performance from one place. It sits above each robot’s own navigation and safety systems.
Do I need fleet software for two or three robots?
Usually the vendor’s built-in fleet manager is enough for a small single-brand fleet. Dedicated robot fleet management becomes important once robots share busy space, come from more than one maker, or need integration with a WMS or MES.
Can one system manage robots from different manufacturers?
Yes, through multi-vendor orchestration platforms, Open-RMF, or a common interface such as VDA 5050. Check exactly which robot models and which VDA 5050 version each vendor supports before committing.
Is VDA 5050 only for the automotive industry?
No. It was developed by the German automotive and materials handling associations, but it is an open interface used by robot makers and fleet software vendors across intralogistics, and version 3.0 explicitly targets mobile robots of all kinds.
Should robot fleet management run in the cloud or on site?
Real-time traffic control usually runs on site or at the edge, so robots keep working if the internet link fails. The cloud suits analytics, multi-site dashboards and remote support.
How much does robot fleet management software cost?
It depends on the pricing model, fleet size and integration effort. In our illustrative 20-robot example, three-year totals ranged from £88,250 to £105,300, with integration and support making up a large share. Always build the budget from real quotes.
References and Further Reading
VDA 5050 specification on GitHub
VDA: Version 3.0 of VDA 5050 released
Open-RMF fleet adapter integration guide
MassRobotics AMR Interoperability Standard
IFR World Robotics 2025: Service Robots
Amazon: one millionth robot and DeepFleet
DeepFleet: Multi-Agent Foundation Models for Mobile Robots
AGV Network: What is ISO 3691-4 for AGV?
The Robot Report: ANSI/A3 R15.08-2 released
European Commission: Machinery Regulation
Supply of Machinery (Safety) Regulations 2008
ISA/IEC 62443 series of standards
