Robot fleet management

Robot fleet management software

Organize multiple robots by site and fleet, then supervise health, connectivity, capabilities, commands, telemetry, and execution history.

How to manage a fleet of robots

Managing a fleet means knowing which robots exist, where they work, what they can do, and what they are doing now. Dagmont Command is the supervisory operations layer for that work. Operators register robots, place them in sites and fleets, and supervise commands and results without taking over the controller that moves each machine.

A fleet is not one vendor’s dashboard. Warehouses, plants, and campuses often run several machine types at once. Command keeps those robots in one operational record: identity, site, connectivity, capabilities, and the history of what was asked of them.

Sites, fleets, and robot registration

A site is the place where robots operate and where a Site Gateway is enrolled. A fleet is the group of robots an operator supervises together. Registration gives each robot a name, a site, a fleet, and an adapter so commands have a destination and telemetry has a source.

That organization is what makes multi-robot fleet management inspectable. An operator can see which robots belong to a dock, a cleaning route, or a production cell, and which gateway connects that site to Command.

  • Robot registration and identity
  • Site assignment and Site Gateway enrollment
  • Fleet grouping for operators
  • Adapter and capability record
  • Simulated robots labeled separately from physical robots

Health, connectivity, and capabilities

Fleet software is only useful if it shows whether a robot can accept work. Command separates gateway online status, Robot Agent heartbeat, and robot-reported status. A site can have a live gateway while one robot’s agent is disconnected.

Capabilities describe the supervisory actions that robot’s integration actually supports, such as mission dispatch, pause, resume, or return to charge. Operators issue those actions from the robot command center. Unsupported actions are not invented for a machine that has not reported them.

Commands, telemetry, and execution history

Each command is an operator intent with a lifecycle: requested, queued, dispatched, acknowledged by the gateway, acknowledged by the robot, executing, then completed or failed. Robot command software keeps that sequence so a network acknowledgement is not mistaken for physical completion.

Telemetry returns on the path from the robot through the Robot Agent and Site Gateway. Robot telemetry shows freshness, battery, faults, and the active command. Execution history remains available after the shift so a later reviewer can see who commanded what and how it ended.

Incidents and warehouse robot operations

When a robot goes offline, telemetry goes stale, or a command fails, Command records an operational issue instead of leaving the event in a chat log. Those issues are the start of incident management. If the failure needs investigation, corrective action, and retesting, Command escalates into Deployment Intelligence with the operational snapshot attached.

Warehouse robot operations are a common fleet pattern: several mobile robots, one or more sites, and a mix of transport and service machines. Command supervises that pattern for AMRs and AGVs. It does not replace warehouse execution software that plans picks, nor the navigation stack on each vehicle.

Related