Live Robot Operations
Dagmont Command
Dagmont Command is the operational control layer for supervising live robots, missions, commands, alerts, and failures.
What Dagmont Command is
Dagmont Command is a supervisory operations platform for physical robots. It connects operators to robot fleets through site gateways and Robot Agents. Operators register robots, organize fleets and sites, issue supported commands, and keep the execution record.
Supervise live robots and robotic machines from one operational control layer. Monitor state, run missions, issue supported commands, record operational issues, and escalate deployment failures with the full operational context attached.
The operating path is operator intent, then command, then gateway, then robot acknowledgement, then execution, then physical evidence, then result, then the audit trail. Fleet software runs robot motion and dispatch. Dagmont Command supervises operations, issues authorized high-level commands, records what happened, and escalates failures into Deployment Intelligence.
- Robot registration
- Fleet organization
- Site management
- Command execution
- Robot capabilities
- Mission supervision
- Telemetry
- Execution state
- Failures and alerts
- Audit history
- Gateway health
- Robot Agent health
- Operator permissions
Command lifecycle
Every command follows the same states. A later state is not inferred from an earlier acknowledgement. HTTP success from the gateway is transport acceptance, not physical completion.
- Requested
- Queued
- Dispatched
- Gateway acknowledged
- Robot acknowledged
- Executing
- Completed
- Failed
Completed and failed are decided from robot-reported state and physical execution evidence. If a move was commanded and the evidence does not show movement, the result is failed. A command can also be rejected, cancelled, expired, or marked dispatch uncertain when the outcome cannot be confirmed. See robot command software for how operators read that sequence.
Physical robot architecture
Commands travel outward through the site:
Dagmont Command → Site Gateway → Robot Agent or adapter → robot controller → physical robot.
Telemetry and execution results travel back:
Robot → Robot Agent → Site Gateway → Dagmont Command.
Gateway health and Robot Agent health are separate. A gateway can be online while the agent on the robot computer is not. Whether a specific robot completes a command on the floor still depends on that robot’s enrolled integration and the evidence it reports.
Multi-vendor architecture
Dagmont sits above different robot manufacturers through adapters. The production control path is HTTP/JSON from the Site Gateway to the Robot Agent. The same contract is what vendor Python integrations use. Serial and controller drivers run on the robot computer when that integration is enrolled. Simulated robots stay labeled simulated. CleanBot is a simulator.
- HTTP/JSON between the Site Gateway and the Robot Agent
- Vendor Python integrations on that same HTTP contract
- Serial and controller integrations on the robot computer
- A simulator for fleets that are not physical robots
- VDA 5050 3.0.0 message translation
VDA 5050 3.0.0 translation maps messages into the supervisory model. Production control does not use VDA 5050 MQTT. An additional manufacturer is connected when its adapter is implemented and the robot is enrolled, including AMRs, AGVs, and humanoid robots.
Operational commands
Where the robot integration supports them, authorized operators issue high-level operational commands. These are supervisory commands. They are not safety commands, physical emergency stops, or millisecond safety loops.
- Pause
- Resume
- Cancel
- Controlled stop
- Return to charge
- Return to base
- Mode changes
- Mission dispatch
Safety boundary
Dagmont Command issues supervisory commands. The robot and the site keep the protective systems that must act locally:
- Physical emergency stops
- Safety PLCs
- Collision avoidance
- Real-time motor control
- Braking systems
- Robot-local safety controls
A controlled stop in Command asks the integration to stop work. It does not replace the physical emergency stop on the robot.
Permissions and audit history
Viewers observe robots, telemetry, and history. They cannot send commands. Operators send permitted commands when command execution is enabled. Admins configure sites, gateways, robots, adapters, and command access.
The audit trail records who issued a command, gateway acknowledgement, robot acknowledgement, execution state, completion or failure, and the operational issues around that window. That is the record telemetry and physical robot monitoring make visible during the shift.
Failure escalation
When a live failure needs structured investigation, Command creates a Deployment Intelligence case with the operational snapshot and related command history. The escalation path:
- Live failure
- Operational issue
- Evidence and context snapshot
- Deployment Intelligence case
- Investigation
- Corrective action
- Retest
- Acceptance
Alert detail
Record alert type, time, acknowledgement, operator action, and escalation status so night-shift events remain inspectable the next morning.
Command and mission history
Keep commands issued, mission events, acknowledgements, and operator actions on one timeline for the incident window.
Escalation into Dagmont Deployment Intelligence
When a live failure needs structured investigation, Command creates a Deployment Intelligence case with the operational snapshot and related command history.
Frequently asked questions
What is robot fleet management?
Robot fleet management is the work of organizing many physical robots by site and fleet, then supervising health, connectivity, capabilities, commands, telemetry, and execution history. Dagmont Command is that supervisory layer. It does not replace the motion software that drives each robot.
What is a robot command platform?
A robot command platform records operator intent and carries it to a robot as a high-level command, then keeps the result. In Dagmont Command the path is operator, command, site gateway, robot acknowledgement, execution, physical evidence, result, and audit trail.
Can Dagmont send commands to physical robots?
Yes. When command execution is enabled, an authorized operator can send a supported command to an enrolled physical robot. The site gateway delivers it to the Robot Agent or adapter. Completion is recorded only when the robot reports the result and the execution evidence supports it. A specific robot still depends on its enrolled integration.
How does Dagmont connect to robots?
Dagmont Command connects through a Site Gateway at the operating site. The gateway talks HTTP/JSON to a Robot Agent or adapter beside the robot. The agent talks to the robot controller. Telemetry and execution results return on the same path in reverse.
What is a Robot Agent?
The Robot Agent is the software that sits with the robot, accepts supervisory commands from the Site Gateway, and reports telemetry and execution state back. It is the adapter boundary between Dagmont and the robot controller. It is not the robot’s motor controller.
What is a Site Gateway?
A Site Gateway is the on-site connection between Dagmont Command and the robots at that site. It receives dispatched commands, acknowledges them, and forwards them to the Robot Agent. Gateway health is separate from robot health: a gateway can be online while a robot or its agent is not.
Does Dagmont replace the robot controller?
No. The robot controller keeps real-time motion, local safety, and vendor-specific control. Dagmont Command supervises the operational layer above that controller: registration, commands, telemetry, execution state, and history.
Does Dagmont provide emergency-stop functionality?
No. Dagmont Command can issue a supervisory stop where the integration supports it. Physical emergency stops, safety PLCs, collision avoidance, braking, and other robot-local safety controls stay on the robot and the site. A Command stop is not a safety-rated emergency stop.
Can Dagmont work with different robot manufacturers?
Yes. Dagmont is designed to sit above different manufacturers through adapters. Available paths include HTTP/JSON, vendor Python integrations, serial or controller integrations, a simulator, and VDA 5050 message translation. Production control uses the HTTP/JSON gateway and Robot Agent path. VDA 5050 MQTT is not the production control path.
Does Dagmont support AMRs?
Dagmont Command supervises autonomous mobile robot operations: sites, fleets, missions, commands, telemetry, and failures. Onboard navigation, SLAM, and local obstacle avoidance remain on the AMR. Dagmont does not provide those robot-local functions.
Does Dagmont support AGVs?
Dagmont Command supervises AGV fleets the same way: site context, commands, telemetry, execution state, and incidents. Path guidance, motion control, and vehicle safety systems remain on the AGV and the site.
How does Dagmont verify command execution?
A command moves through requested, queued, dispatched, gateway acknowledged, robot acknowledged, and executing. Completed or failed is decided from robot-reported state and physical execution evidence. A network acknowledgement is not treated as physical completion. If motion was commanded and the evidence does not show movement, the result is a failure.
What happens when a robot disconnects?
If the robot heartbeat stops, Command records the Robot Agent as disconnected and opens an operational issue. If the heartbeat is fresh but the robot reports itself offline, Command records the robot as offline. A gateway can stay online in either case. Commands that cannot be confirmed end as failed or dispatch uncertain rather than completed.
How does Dagmont handle stale telemetry?
Command stores telemetry snapshots separately from the robot heartbeat. If the heartbeat is fresh but no telemetry snapshot has arrived within five minutes, Command opens a stale-telemetry issue. Operators should not treat the last snapshot as the current physical state.
What roles can send commands?
Viewers can observe robots, telemetry, and history. They cannot send commands. Operators can send permitted commands when command execution is enabled for the organization. Admins configure sites, gateways, robots, adapters, and command access.
Can Dagmont distinguish simulated and physical robots?
Yes. Simulated organizations and robots are labeled simulated, including the CleanBot simulator. Physical robots use an enrolled gateway and Robot Agent. A simulated robot is not presented as a physical one.
How are failures recorded?
Failures are command results and operational issues with a time, a robot, and a reason. Command keeps the state transitions, operator identity, gateway and robot acknowledgements, and the failure reason on the audit trail. When a failure needs investigation, Command can open a Deployment Intelligence case with that operational context.
Can Dagmont integrate through HTTP or Python?
Yes. The production path between the Site Gateway and the Robot Agent is HTTP/JSON. Vendor integrations can use that same HTTP contract from Python or another runtime. The vendor must report completion explicitly; a transport response alone does not complete the command.
What is the relationship between Command and Deployment Intelligence?
Dagmont has two products. Command supervises live robots and records commands, telemetry, and failures. Deployment Intelligence owns investigation, corrective action, retesting, and acceptance. When a live failure needs that investigation, Command creates a Deployment Intelligence case with the operational snapshot and command history.
Robot operations topics
- Robot fleet management
- Robot operations platform
- Robot command software
- Physical robot monitoring
- AMR fleet management
- AGV fleet management
- Robot telemetry
- Robot command center
- Humanoid robot operations
- Deployment Intelligence
Open Command · View Dagmont Deployment Intelligence · All products · Use cases · Request a Deployment Review