DEV Community: GUMA Robots

Robot Custom Development RFP: 12 Acceptance Tests Before Connecting SDK, ROS 2, AI and Business Systems

GUMA Robots — Fri, 24 Jul 2026 03:53:47 +0000

A robot customization demo can work while the project is still impossible to accept.

An SDK command moves the robot. A ROS 2 topic publishes sensor data. A dashboard changes a task from queued to running. None of those observations establishes that the integrated system can be reproduced, recovered, audited, upgraded or operated safely.

For a buyer, the unit of custom robot development should therefore be a versioned capability with an explicit interface contract, failure behavior, acceptance evidence and support boundary—not a collection of screenshots or a one-time demonstration.

This checklist is for teams commissioning robot software, SDK and ROS 2 integration, perception or AI features, payload control, business-system connectivity, or a representative-site proof of concept.

GUMA product-interface reference. It is not a customer site, live customer data, proof of a completed robot integration or a guaranteed delivery result.

1. Freeze the exact version inventory

Record more than a product-family name. A useful baseline includes:

robot model, hardware edition and installed payloads;
controller, firmware and vendor application versions;
SDK, ROS distribution, middleware and message definitions;
operating system, architecture, GPU or accelerator, drivers and runtime;
adapter, application, model and configuration revisions;
map, calibration, task and business-interface schema versions.

The version inventory must be machine readable and tied to every acceptance run. “Works with this brand” is not a support matrix.

Pass evidence: an immutable bill of materials, compatibility matrix and a command that exports the running versions.

2. Draw the control and responsibility boundary

Name the component that owns each decision:

low-level motion and protective behavior;
navigation and localization;
payload actuation;
mission and task state;
shared-resource coordination;
business authorization;
emergency stop, pause, takeover and controlled resume.

An AI agent, business workflow or fleet platform should not silently inherit motion authority. The contract should identify which commands are advisory, which are executable and which require an approval or vendor controller.

Pass evidence: a responsibility matrix, command path and stop-authority diagram reviewed by the robot vendor, integrator and buyer.

3. Specify every interface as a contract

ROS 2 distinguishes topics for continuous streams, services for short request-response interactions and actions for long-running work with feedback. That distinction is useful only when the project also freezes the concrete contract.

For every interface, record:

name, namespace and version;
message, service or action definition;
units, ranges, enums and coordinate frame;
publisher, subscriber, caller and owner;
update rate, timeout and freshness limit;
authentication and authorization boundary;
error codes, cancellation and retry behavior;
backward-compatibility and deprecation policy.

The same discipline applies to vendor SDK calls, WebSocket events, REST APIs, files and database records.

Pass evidence: a versioned interface catalogue plus contract tests against representative payloads and invalid inputs.

4. Make clocks, units and coordinate frames explicit

Many integration defects are semantic rather than algorithmic. A pose can be numerically valid and still refer to the wrong frame, time or unit.

Define:

clock source and synchronization method;
capture time, command time and arrival time;
maximum age, skew, jitter and drift;
SI or vendor units and conversion ownership;
axis directions, handedness and quaternion order;
map, odometry, base, sensor, tool and business-location frames;
transform validity and behavior when a transform is stale or missing.

Pass evidence: frame tree, clock diagram, conversion tests and a replay in which observations, commands and transforms remain aligned.

5. Test QoS and network behavior, not only a healthy LAN

ROS 2 Quality of Service profiles combine policies such as reliability, durability, history, depth, deadline and lifespan. Incompatible requested and offered profiles can prevent message delivery even though both nodes are running.

The project should define the policy per interface and test:

delayed, duplicated, reordered and dropped messages;
low bandwidth and temporary disconnection;
publisher, subscriber and middleware restart;
stale data after reconnection;
queue growth and resource exhaustion;
replay behavior when recorded QoS differs from the live system.

Pass evidence: agreed QoS profiles, compatibility checks, network-fault results and recorded message-loss or age metrics.

6. Define lifecycle and recovery states

The ROS 2 managed-node design provides explicit states such as unconfigured, inactive, active and finalized, with supervised transitions and error processing. A commercial project may use another mechanism, but it still needs observable states.

For each component, define:

configuration and activation prerequisites;
health and readiness signals;
safe inactive behavior;
shutdown and resource cleanup;
recoverable versus terminal errors;
who may restart or replace the component;
what state must be reconstructed after restart.

Starting a process is not the same as making a capability ready.

Pass evidence: lifecycle state diagram, transition logs, restart tests and proof that unfinished commands do not disappear or execute twice.

7. Make commands idempotent and tasks reconcilable

Networks retry. Clients reconnect. Operators click twice. A safe integration should not create two physical actions merely because the same request was delivered twice.

Use stable command or task identifiers and define:

accepted, rejected, queued, dispatched, running, paused, completed, failed and cancelled states;
duplicate-command behavior;
timeout versus unknown-result handling;
authoritative state after a client, adapter or platform restart;
reconciliation between business state and robot state;
human decision points when automatic recovery is unsafe.

Pass evidence: duplicate and out-of-order request tests, persisted state transitions and a recovery report that explains every final state.

8. Separate protective behavior from functional success

A navigation or manipulation function can meet its nominal task while violating a site rule, payload constraint or human-approval requirement.

The acceptance plan should distinguish:

vendor protective functions and their documented limits;
project-level operational rules;
functional success criteria;
stop and intervention criteria;
prohibited autonomous recovery;
residual risk and operator responsibility.

Do not describe a software integration as certified or safety-rated unless the exact system and claim have current written evidence.

Pass evidence: hazard-informed test cases, stop-state evidence, takeover procedure and a signed list of excluded or unverified conditions.

9. Correlate tasks, robot events and business transactions

Logs stored in separate systems are difficult to use when a task fails. OpenTelemetry context propagation is a useful public reference for correlating traces, metrics and logs across service boundaries.

A robot project can apply the same principle with non-sensitive identifiers:

project and deployment version;
task and command ID;
robot and adapter ID;
map and route revision;
business transaction or work-order reference;
trace and span relationship;
timestamps and result classification.

Never place credentials, personal data or confidential payloads in trace baggage or public logs.

Pass evidence: one representative task reconstructed across the business system, platform, adapter and robot logs without manual timestamp guessing.

10. Prove the build and deployment are reproducible

“The developer can rebuild it” is not delivery evidence.

Require:

source and dependency revisions;
license and redistribution review;
environment or container definition;
build command and artifact checksums;
configuration schema and secret-handling boundary;
model, calibration and map artifact versions;
clean-machine installation;
rollback package and database migration plan.

The buyer should be able to distinguish code, configuration, model weights, customer data and runtime state.

Pass evidence: a clean-environment build and deployment performed from the delivered instructions, followed by checksum verification.

11. Inject failures and replay the result

Acceptance should include failures that match the intended environment:

sensor stream missing or stale;
transform or localization unavailable;
command rejected by the robot;
payload or business API timeout;
network loss during a task;
adapter, application or database restart;
low battery or unavailable resource;
invalid configuration or incompatible version;
operator pause, takeover and abort.

Do not manufacture unsafe physical scenarios. Use simulation, interface stubs, controlled conditions or vendor-approved tests where appropriate.

Pass evidence: fault-injection matrix, expected safe state, retained telemetry, recovery path and replayable result for every test.

12. Deliver an acceptance matrix, rollback and support boundary

The final package should map each promised capability to:

exact supported versions;
buyer inputs and site assumptions;
functional and failure tests;
required evidence;
pass, conditional pass or fail result;
unresolved limitations;
change-control rule;
rollback method;
warranty or support owner and response path.

Price, delivery time and ongoing support should refer to this written scope. Otherwise a quotation can describe one project while the acceptance test measures another.

Pass evidence: signed acceptance matrix, known-issues register, release notes, rollback drill and support handover.

A representative pilot before full rollout

Start with the smallest end-to-end path that can still expose integration risk:

one exact robot and software stack;
one representative task;
one payload or business-system interface;
one controlled network degradation;
one component restart during a task;
one operator takeover and controlled resume;
one full trace, replay and evidence package;
one clean-environment deployment and rollback.

Only expand robots, sites, tasks or autonomy after that loop is accepted.

Turn the checklist into a project brief

The public GitHub form captures the operating scenario, representative task, robot or payload, system interfaces, acceptance priorities, pilot scale and purchasing stage without requesting personal contact information:

Open the structured robot project brief.

Do not place phone numbers, email addresses, exact private site addresses, confidential maps, credentials, customer names or unpublished commercial details in a public issue.

For private interface documents and a written project scope, use the attributed contact route:

Send a private robot custom-development enquiry.

The GUMA custom robot development and systems-integration page describes the service boundary, buyer inputs and evidence expected before quotation.

Primary references

Evidence boundary: this checklist does not claim compatibility with a particular robot, firmware, SDK, ROS distribution, payload, model, site, certification or customer deployment. It does not guarantee safety, performance, price, delivery time or return on investment. Those require exact-version primary evidence, a representative pilot and a written agreement.

15 Acceptance Tests Before Integrating a Multi-Robot Management Platform

GUMA Robots — Thu, 23 Jul 2026 20:38:23 +0000

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:

https://www.lllrobots.com/en/studio.html?utm_source=devto&utm_medium=organic_article&utm_campaign=multi-robot-platform-acceptance-devto-20260724&utm_term=multi-robot-fleet-management

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:

https://www.lllrobots.com/en/contact.html?intent=studio&utm_source=devto&utm_medium=organic_article&utm_campaign=multi-robot-platform-acceptance-devto-20260724&utm_term=robot-platform-poc

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:

https://github.com/zxbteamo-lang/guma-robot-procurement-checklists/issues/new?template=multi-robot-platform-project.yml

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:

https://www.lllrobots.com/en/contact.html?intent=studio&utm_source=devto&utm_medium=organic_article&utm_campaign=multi-robot-platform-acceptance-devto-20260724&utm_term=project-brief-private-documents

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.