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

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:

1. one exact robot and software stack;
2. one representative task;
3. one payload or business-system interface;
4. one controlled network degradation;
5. one component restart during a task;
6. one operator takeover and controlled resume;
7. one full trace, replay and evidence package;
8. 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

• ROS 2 managed-node lifecycle design
• ROS 2 interfaces: topics, services and actions
• ROS 2 Quality of Service settings
• rosbag2 QoS overrides for recording and playback
• OpenTelemetry context propagation

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.