A multi-robot platform can look convincing long before it is ready to operate a real fleet.
The demo usually works: robots appear on a map, battery percentages update, and a task button changes a card from “queued” to “running.” The production risk lives underneath that interface:
- Which component owns motion and safety decisions?
- What does each adapter guarantee about timestamps, units, coordinate frames, retries and duplicate commands?
- Can the platform reconstruct a task after a robot, adapter, database or network restart?
- Does a “supported robot” mean an exact tested version, or only a product-family name?
This is the implementation-oriented checklist I would put into a request for proposal and a representative-site proof of concept.
GUMA product presentation asset; not a customer site, live customer data or proof of completed integration.
Start with three explicit control layers
Keep these responsibilities separate in the architecture diagram and in the acceptance test:
- Robot and vendor fleet layer — low-level motion, navigation, protective behavior, device health and vendor constraints.
- Fleet orchestration layer — task allocation, shared-resource coordination, cross-fleet policy and operational state.
- Business operations layer — orders, work tickets, inspection plans, permissions, evidence, reporting and enterprise integration.
Open-RMF is a useful public engineering reference for multi-fleet integration, task dispatch and shared infrastructure. Its official demos include multiple fleets, doors, lifts and task bidding. The MassRobotics AMR Interoperability Standard is another useful reference for sharing basic capabilities and operational state across vendors.
Neither reference proves that a specific robot, firmware, adapter, site or commercial platform is compatible. Compatibility is a versioned test result, not a logo on a slide.
1. Exact version identity
Record the robot model, hardware edition, controller, firmware, navigation stack, vendor fleet software, SDK, adapter revision and platform release.
Pass evidence: a machine-readable inventory and a supported-version matrix.
2. Capability contract
For each robot type, list what the orchestration layer can observe and request. Separate status reading, task requests, remote assistance and direct control. Mark functions as supported, unsupported, simulated or site-restricted.
Pass evidence: a capability matrix tied to exact versions.
3. Adapter semantics
Document timestamps, clock source, units, coordinate frames, update rates, rate limits, timeout rules, idempotency and error mapping. A field named pose is not a contract if two vendors interpret its frame or freshness differently.
Pass evidence: schemas, fixtures, error examples and duplicate-request tests.
4. Map ownership and versioning
Define who owns floors, zones, waypoints, chargers, doors, lifts and restricted areas. Record transforms between vendor maps and the orchestration site model.
Pass evidence: a versioned site model, approval flow and rollback test.
5. Task lifecycle
Test more than queued, running and completed. Include accepted, assigned, paused, blocked, failed, cancelled, expired, resumed and manually completed.
ROS 2 managed-node lifecycle design is a useful reminder: known states and supervised transitions make recovery testable. An application task needs its own explicit state machine as well.
Pass evidence: normal and abnormal transition logs with reasons.
6. Allocation decisions
Verify why a robot receives a task. Capability, location, battery reserve, payload, site access, maintenance state and service priority may all matter.
Pass evidence: repeatable allocation cases with every decision input recorded.
7. Shared resources
Test corridors, intersections, doors, lifts, workcells, chargers and human-operated zones. A moving icon is not evidence that physical resources are coordinated.
Pass evidence: contention, waiting, timeout and recovery cases.
8. Battery and charging
Confirm reserve thresholds, charger compatibility, queueing, interrupted-task policy and charger-failure behavior.
Pass evidence: one complete low-battery run through recovery.
9. Network degradation
Inject latency, packet loss, disconnection and reconnects. Define what remains local on the robot and what may be replayed after communication returns.
Pass evidence: a safe robot state, bounded retries, no duplicate execution and a reconstructed timeline.
10. Service restart and reconciliation
Restart the adapter, task service, message broker, database and dashboard separately. The system must not lose task ownership or silently create a second execution.
Pass evidence: persisted state, reconciliation decision and operator alert for every restart case.
11. Manual takeover
Define who may pause, drive, release, resume or cancel. Manual action must not destroy the evidence needed to understand the incident.
Pass evidence: role checks, command audit and hand-back rules.
12. Permissions and audit
Separate operators, engineers, administrators, service partners and auditors. Map publication, remote motion, software rollout, data export and security changes need explicit authority.
Pass evidence: a role matrix plus immutable audit events for high-risk actions.
13. End-to-end observability
Use one trace identifier across the business request, task service, adapter and robot event stream where the interfaces allow it. OpenTelemetry's official tracing model is useful here: context propagation links spans across distributed services.
Robot telemetry alone is not enough. Store the robot, map, task, adapter, platform and business-system versions with state changes, errors and manual interventions.
Pass evidence: replay one failed task without relying on the operator's memory.
14. Enterprise integration
Test WMS, MES, EAM, ticketing, inspection and identity interfaces with duplicates, delayed acknowledgements and unavailable downstream systems.
Pass evidence: API contracts, retry policy, dead-letter handling and reconciliation.
15. Upgrade and rollback
Canary one adapter or robot group before the entire fleet. Block incompatible versions and prove rollback without corrupting maps or tasks.
Pass evidence: canary, compatibility gate and verified rollback.
A safer pilot sequence
- One robot, one representative site and one complete task.
- Failure injection: network loss, blocked route, localization loss, low battery, service restart and manual takeover.
- A second robot type or vendor to test whether the adapter model holds without hiding differences.
- Shared resources and business integration only after the earlier gates pass.
Scaling should be the consequence of evidence, not the purpose of the first demonstration.
What the handover should contain
- supported robot and version matrix;
- architecture and responsibility boundaries;
- adapter and business API contracts;
- versioned maps and task assets;
- role and permission matrix;
- deployment, upgrade and rollback procedures;
- acceptance scripts and failure cases;
- logs, replay instructions and known limitations;
- training and operational recovery guide.
GUMA Robot Studio publicly organizes robots, maps, points, tasks, roles, logs and deployment options around this operational layer. Its public simulation is isolated from real customer robots and customer data. That simulation is useful for reviewing workflows, but it is not proof that a specific robot version or site is already integrated.
Platform overview:
To scope a representative-site PoC, provide the exact robot models and versions, site, network and data boundaries, representative task, business systems, timeline and acceptance priorities:
Turn the checklist into a reviewable project brief
Before asking a platform vendor or integrator to quote, write down one representative task and the exact system boundary. A useful brief should name the robot and software versions, site resources, map and task lifecycle, business-system interfaces, failure tests, pilot scale, decision window and purchasing stage.
The reusable public form below collects those inputs without asking for personal contact details:
Do not place phone numbers, email addresses, exact private site addresses, confidential maps, credentials, customer names or unpublished commercial information in a public GitHub issue. Use the private project contact route for those materials:
Primary references
- Open-RMF root repository: https://github.com/open-rmf/rmf
- Open-RMF demonstrations: https://github.com/open-rmf/rmf_demos
- ROS 2 managed-node lifecycle design: https://design.ros2.org/articles/node_lifecycle.html
- OpenTelemetry traces and context propagation: https://opentelemetry.io/docs/concepts/signals/traces/
- MassRobotics AMR Interoperability Standard overview: https://www.massrobotics.org/what-is-the-massrobotics-amr-interoperability-standard/
Evidence boundary: this checklist does not claim compatibility with a particular robot, customer deployment, certified safety, guaranteed performance, price, delivery date or return on investment. Those require exact-version interface evidence, a representative-site test and a written project scope.
Image disclosure: the cover is a GUMA product presentation asset showing a management-interface concept. It is not a customer site, live customer data or proof of completed integration.
Top comments (0)