# Robot software integration requirements

**Version 0.1 — 14 November 2026**
Published by Embodied Software Labs (Synthari AI LLC).
Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Use it, change it,
publish your filled-in copy. No attribution is required in the filled-in document itself.

---

## What this is

A questionnaire you fill in **before** asking anyone to scope, estimate or quote a robot
software integration. It collects the facts that every integrator ends up asking for
anyway, in one pass, in writing.

## What this is not

This is **a proposal**, not an industry standard. No standards body publishes it and
nobody has adopted it. Filling it in certifies nothing and commits nobody.

It is **not a safety assessment** and not a risk assessment. Nothing in it determines
whether an installation is safe. That is decided by a competent assessor for your
specific application, and that assessment governs regardless of anything written here.

Embodied Software Labs has released no robotics software and does not currently perform
integrations. This document is a reference, not an offer.

## How to fill it in

Answer what you know. Write `UNKNOWN` where you do not know, and `N/A` where the
question genuinely does not apply — those are different answers and both are useful.

**A blank field is information.** Every `UNKNOWN` is a question somebody will have to
answer later, and the cost of answering it goes up the further into a project it is
discovered. An integrator who receives a form with nine `UNKNOWN`s has a more accurate
picture of the work than one who receives a form with nine guesses.

Do not attach source code, credentials, API keys, proprietary datasets, trained model
weights, workplace video containing identifiable people, or anything under embargo. None
of it is needed to scope an integration, and sending it before an agreement exists
creates a problem for both parties.

---

## 0. About the request

| Field | Answer |
| --- | --- |
| 0.1 Organisation | |
| 0.2 Contact name and role | |
| 0.3 What you want to be able to do (one sentence) | |
| 0.4 Why now — what triggered this | |
| 0.5 Is this a feasibility question, a scoping exercise, or a funded project? | |
| 0.6 Decision date, if there is one | |
| 0.7 Is any of the below confidential? (if yes, stop and agree terms first) | |

**0.8 — What already exists.** Tick what is already true today:

- [ ] The robot is purchased and on site
- [ ] The robot is on order
- [ ] The robot is still being chosen
- [ ] The cell, fixturing and guarding exist
- [ ] A previous integration attempt exists (describe it in 0.9)
- [ ] Nothing physical exists yet

**0.9 — What has been tried already, and what happened.**

> Free text. Previous attempts are the single most useful paragraph in this document.
> An integration that failed for a known reason is worth more than a clean sheet.

---

## 1. The robot and end effector

The purpose of this section is to establish what physically exists and what it can
physically do, before anybody discusses software.

| Field | Answer |
| --- | --- |
| 1.1 Robot manufacturer | |
| 1.2 Robot model, exact | |
| 1.3 Serial number or fleet identifier, if several | |
| 1.4 How many robots, and are they identical? | |
| 1.5 Controller model and firmware version | |
| 1.6 Teach pendant / HMI software version | |
| 1.7 Rated payload from the datasheet | |
| 1.8 **Usable payload at full extension, with the end effector fitted** | |
| 1.9 Reach, and the reach actually available inside the cell | |
| 1.10 Mounting — floor, ceiling, wall, rail, mobile base | |
| 1.11 Is the robot fixed, or on a mobile base or linear axis? | |

**1.12 — The end effector.**

| Field | Answer |
| --- | --- |
| Manufacturer and model | |
| Type — two-finger, vacuum, magnetic, tool changer, custom | |
| Mass, including adapter plate and cabling | |
| Actuation — pneumatic, electric, hydraulic | |
| How it is commanded today | |
| Does it report state back? What state? | |
| Tool centre point — defined, and by whom? | |
| Tool changer present? If so, how many tools, and is change automatic? | |

**1.13 — The objects being handled.** One row per object class.

| Object | Mass range | Dimensions | Surface / material | Rigid or deformable? | Presentation |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

> *Presentation* means how the object arrives: in a fixture, loose on a surface,
> randomly in a bin, on a moving conveyor. This single column changes the difficulty of a
> task by an order of magnitude and is routinely omitted.

**1.14 — The environment.**

| Field | Answer |
| --- | --- |
| Indoor / outdoor | |
| Temperature range the equipment sees | |
| Lighting — fixed artificial, mixed, daylight ingress? | |
| Dust, moisture, washdown, required IP rating | |
| Vibration sources nearby | |
| Floor flatness, if a mobile base is involved | |

**1.15 — Who is nearby while it runs.**

- [ ] Nobody — the cell is empty and interlocked
- [ ] Trained operators only
- [ ] Untrained personnel may be present
- [ ] Members of the public may be present

> This answer changes the entire engineering picture and belongs at the top rather than
> in a safety annex. It is not itself a safety assessment — see 6.7.

---

## 2. Controllers and interfaces

This is the section that decides whether an integration is a configuration exercise or a
research project.

| Field | Answer |
| --- | --- |
| 2.1 Is there a documented external control interface? | |
| 2.2 Interface type — fieldbus, Ethernet, vendor SDK, ROS driver, OPC UA, digital I/O | |
| 2.3 Vendor documentation URL and the version of the document | |
| 2.4 Is the interface licensed, optional, or an extra-cost module? | |
| 2.5 Is a vendor-supplied program or app required on the controller? | |
| 2.6 Does enabling external control void, limit or alter any warranty or support? | |
| 2.7 Maximum external command rate the controller accepts | |
| 2.8 Is real-time control available, or only goal-level commands? | |
| 2.9 What does the controller do when the external connection drops? | |

**2.10 — If ROS 2 is in scope.**

| Field | Answer |
| --- | --- |
| Distribution — exact, e.g. Jazzy Jalisco | |
| Is there a vendor or community driver? Which repository, which tag? | |
| Is `ros2_control` used? Which controllers? | |
| Hardware component type — `system`, `actuator`, `sensor` | |
| Which command interfaces are exposed — position, velocity, effort? | |
| Which state interfaces are published? | |
| RMW implementation and DDS vendor | |
| Is a `FollowJointTrajectory` action server available? | |

> The last row matters more than it looks. MoveIt acts only as a client of that action —
> the robot side must provide the server. If no server exists, somebody has to write one,
> and that is work nobody has costed. See the references.

**2.11 — Existing software the integration has to live with.**

| System | Vendor / version | What it owns | How it would be reached |
| --- | --- | --- | --- |
| PLC | | | |
| SCADA / HMI | | | |
| WMS / MES / ERP | | | |
| Fleet or traffic manager | | | |
| Safety controller | | | |
| Vision system | | | |

**2.12 — Who owns each interface.** Copy the ownership matrix in the appendix and fill
in a row per interface. An interface with no named owner is the commonest cause of a
stalled integration.

---

## 3. Model files and usage rights

Simulation, planning and collision checking all depend on files somebody has to supply,
and on permission somebody has to grant.

| Field | Answer |
| --- | --- |
| 3.1 Is a URDF or equivalent kinematic model available? From whom? | |
| 3.2 Is an SRDF (or equivalent semantic description) available? | |
| 3.3 Are collision meshes available, or only visual meshes? | |
| 3.4 Are CAD models of the cell, fixtures and guarding available? | |
| 3.5 Format and units of each file | |
| 3.6 Are the models known to match the installed hardware, or nominal? | |
| 3.7 Who last verified that, and when? | |
| 3.8 Are object models (CAD, meshes, point clouds) available? | |

**3.9 — Rights.** For each file set above, state the answer explicitly. "Probably fine"
is not an answer; this is the section that stops a project three weeks in.

| File set | Owner | May it be used in simulation? | May it be modified? | May it leave your network? | May it be published? | Expiry or conditions |
| --- | --- | --- | --- | --- | --- | --- |
| Robot model | | | | | | |
| Cell / fixture CAD | | | | | | |
| Object models | | | | | | |
| Recorded data | | | | | | |

**3.10 — Data produced during the work.** Who owns logs, recordings, trajectories and
any dataset generated while developing or operating the capability? State it now.

---

## 4. Sensors, frames and timing

| Field | Answer |
| --- | --- |
| 4.1 Sensors already installed — make, model, firmware | |
| 4.2 Mounting — on the tool, on the robot, fixed in the cell | |
| 4.3 Resolution, frame rate, field of view, working distance | |
| 4.4 Interface — GigE, USB3, Ethernet, driver and version | |
| 4.5 Is a working driver known to exist for your software stack? | |
| 4.6 Lighting — controlled, ambient, or both? Does it change through the day? | |
| 4.7 Is there a safety-rated sensing system? Who owns it? | |

**4.8 — Frames and calibration.** Name the transform tree as it exists today.

| Field | Answer |
| --- | --- |
| Named frames in use | |
| Who publishes each transform | |
| Is the tree a single chain with one parent per frame? | |
| Hand-eye calibration — done, by whom, when, with what residual? | |
| Tool centre point — measured or nominal? | |
| How is drift detected, and by whom? | |
| What happens when a calibration is wrong — is it noticed, or silent? | |

> [REP 105](https://reps.openrobotics.org/rep-0105/) names `earth`, `map`, `odom` and
> `base_link`, and requires a single chain in that order — each frame has exactly one
> parent. A tree with two parents on one frame is a defect, not a configuration choice.

**4.9 — Timing.**

| Field | Answer |
| --- | --- |
| Cycle time target | |
| Is the target an average or a worst case? | |
| Longest acceptable single-operation time | |
| Is the robot paced by anything external — a conveyor, an upstream cell, a person? | |
| Time synchronisation — NTP, PTP, none? | |
| Acceptable latency between sensing and action | |

---

## 5. Software, compute and network dependencies

| Field | Answer |
| --- | --- |
| 5.1 Operating system and version on the control PC | |
| 5.2 Is a real-time kernel required or available? | |
| 5.3 CPU, RAM, GPU — the actual installed hardware, not the plan | |
| 5.4 **Sustained** compute available, measured in the real enclosure | |
| 5.5 Enclosure ventilation — is thermal throttling possible? | |
| 5.6 Storage available, and retention policy for logs | |
| 5.7 Who administers this machine? | |

> 5.4 and 5.5 are a pair. Peak performance on a bench in an air-conditioned room is not
> the number to size against. Thermal throttling is a common sizing error and it appears
> in service, in summer, months after acceptance.

**5.8 — Network.**

| Field | Answer |
| --- | --- |
| Is the robot network isolated from the business network? | |
| Who controls the firewall, and what is the change process? | |
| Is outbound internet access available from the control PC? | |
| Is remote access possible? Through what, and who approves it? | |
| Is a VPN or jump host required? | |
| Expected bandwidth for sensor data | |
| Wireless involved? Band, coverage, and who owns it? |  |

**5.9 — Dependencies and change control.**

| Field | Answer |
| --- | --- |
| Can packages be installed from public registries, or is a mirror required? | |
| Is there an approved-software list? | |
| Who approves a dependency version change? | |
| Is there a container runtime available? | |
| How is software deployed to the machine today? | |
| Is there a rollback path, and has it ever been used? | |

**5.10 — Security and access.**

| Field | Answer |
| --- | --- |
| Who may log into the control PC? | |
| Is there an existing security review process for new software? | |
| Are there audit or logging obligations? | |
| Are there regulatory constraints on where data may be stored? | |

---

## 6. Deliverables and acceptance evidence

The purpose of this section is to make "done" a thing both parties can check rather than
argue about.

| Field | Answer |
| --- | --- |
| 6.1 What has to exist at the end — software, documentation, training, source? | |
| 6.2 Is source code a deliverable? Under what licence? | |
| 6.3 Who may maintain it afterwards? | |
| 6.4 Is a capability specification a deliverable? *(see the related template)* | |
| 6.5 Who signs off, and against what? | |

**6.6 — Acceptance criteria.** One row per criterion. A criterion without a measurement
method is a preference.

| Criterion | Target | How it is measured | Who measures it | Over how many trials | Pass / fail boundary |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

> State the **definition used** for every metric. "95% success rate" means nothing until
> somebody writes down what counted as a success, who decided, over how many attempts, on
> how many physical robots, and what a human was doing during each one.

**6.7 — Safety and compliance ownership.** Fill this in even though this document does
not assess safety.

| Field | Answer |
| --- | --- |
| Who is responsible for the risk assessment for this application? | |
| Has one been done? When, and by whom? | |
| Who owns the safety-rated equipment and its validation? | |
| Which standards or regulations has your organisation decided apply? | |
| Who signs the final safety acceptance? | |

> **This questionnaire is not a risk assessment.** Section 1.15 and this section collect
> facts an assessor will need; they do not substitute for the assessment, and nothing
> recorded here transfers responsibility for it.

**6.8 — What happens after acceptance.**

| Field | Answer |
| --- | --- |
| Who answers the phone when it misbehaves? | |
| What is actually committed — best effort, a response target, or a contract? | |
| Who watches for upstream changes — firmware, OS, dependency, site layout? | |
| What re-validates the system after one of those changes? | |
| Is there a defined end of support? | |

---

## Appendix A — Interface ownership matrix

One row per interface. The three columns that matter are the last three: a named person,
a documented change process, and what happens when the interface changes without notice.

| Interface | What crosses it | Direction | Protocol / transport | Documented? | Owner (named) | Change process | On unannounced change |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Robot external control | | | | | | | |
| End effector command | | | | | | | |
| Camera / sensor stream | | | | | | | |
| PLC ↔ control PC | | | | | | | |
| WMS / MES task source | | | | | | | |
| Safety controller signals | | | | | | | |
| Operator HMI | | | | | | | |
| Logging / telemetry out | | | | | | | |

**Ownership levels, so the column means the same thing to everyone:**

| Level | Meaning |
| --- | --- |
| **Owned** | A named person is accountable, the interface is documented, and changes go through a process. |
| **Operated** | Somebody runs it day to day but cannot change or specify it. |
| **Vendor-controlled** | A supplier defines it; you consume it and find out about changes when they happen. |
| **Orphaned** | It exists, something depends on it, and nobody is accountable for it. |

> *Orphaned* is a real and common answer. Writing it down is the point.

---

## Appendix B — Example 1: an incomplete request (HYPOTHETICAL)

**This example is fictional.** It is not a real enquiry from a real organisation. It is
included to show what an unanswerable request looks like, because most first contacts
look like this and that is not a criticism of the people sending them.

> *"We have a UR robot in our packing area and we want it to pick items out of totes and
> put them on the line. We've got a camera already. Can you give us a rough number and a
> timeline? Ideally live by Q2."*

Nothing is wrong with this message. It just cannot be answered. Here is what it leaves
open, by section:

| Section | What is missing | Why it changes the answer |
| --- | --- | --- |
| 1.2 | "A UR robot" — which model? | Payload and reach differ by a factor of three across the range. |
| 1.8 | Usable payload with the tool fitted | A 1.4 kg tool removes 1.4 kg of capacity before anything is picked. |
| 1.13 | What the items are | "Items" covers rigid cartons and deformable polybags. These are different projects. |
| 1.13 | Presentation | "Out of totes" could be a fixture or random bin picking. Order-of-magnitude difference. |
| 1.15 | Who is nearby | Determines the entire safety and cell design picture. |
| 2.1 | Which external control interface | Decides whether this is configuration or driver development. |
| 2.10 | Whether a trajectory action server exists | If not, somebody writes one. Uncosted. |
| 3.1 | Model files and rights | Decides whether simulation is possible at all. |
| 4.1 | "A camera" — which one | Decides whether a working driver exists. |
| 4.8 | Hand-eye calibration | Decides whether the camera can be used for picking at all. |
| 4.9 | Cycle time | Decides the compute and the approach. |
| 5.4 | Sustained compute | Decides whether a perception model fits. |
| 6.6 | What "working" means | Without this there is no acceptance, only opinion. |

**The honest reply to this message is a link to this questionnaire**, not an estimate.
Any number given against the message above is invented, and both parties will later
behave as though it was not.

---

## Appendix C — Example 2: a completed brief (HYPOTHETICAL)

**This example is entirely fictional.** The organisation does not exist, the deployment
does not exist, no robot has run this task, and every value below was invented to show
what a filled-in form looks like at the right level of detail. **None of it should be
cited, quoted or used as a benchmark.**

### 0. About the request

| Field | Answer |
| --- | --- |
| 0.1 Organisation | *(fictional)* Northfield Packing Co. |
| 0.3 What you want to be able to do | Move single totes from a staging bench onto a powered conveyor, under operator supervision. |
| 0.4 Why now | The bench-to-conveyor step is manual and is the slowest step on the line. |
| 0.5 Feasibility, scoping or funded? | Scoping. Capital not yet approved. |
| 0.6 Decision date | End of Q2, indicative. |
| 0.7 Confidential? | No. Everything below is non-confidential. |
| 0.8 What exists | Robot purchased and on site; cell and guarding exist; no previous attempt. |

### 1. Robot and end effector

| Field | Answer |
| --- | --- |
| 1.1–1.2 | Universal Robots UR10e |
| 1.4 | One robot. |
| 1.5 | PolyScope 5.x — exact version `UNKNOWN`, to be read off the pendant. |
| 1.7 | 12.5 kg rated. |
| 1.8 | **9.9 kg usable** at full extension with the 1.4 kg tool fitted. |
| 1.10 | Floor mounted, fixed. |
| 1.12 | Two-finger electric gripper, 1.4 kg with adapter; commanded over the tool I/O; reports open/closed and grip detect; TCP measured by the installer on 2 October, not re-verified since. |

**1.13 Objects**

| Object | Mass | Dimensions | Surface | Rigid? | Presentation |
| --- | --- | --- | --- | --- | --- |
| Tote, loaded | 3.2–6.0 kg | 600 × 400 × 220 mm | Textured HDPE | Rigid, lid not fitted | Single tote, on a bench, within ±30 mm of a marked position |

**1.14 Environment** — indoor, 12–28 °C, fixed overhead LED lighting with daylight
ingress from a roof light on the east side in the morning, light dust, no washdown.

**1.15 Who is nearby** — trained operators only. The cell is not interlocked against
entry; an operator stands at the bench.

> Note how 1.15 and 1.14 together already constrain the design: a person is present, and
> the lighting is not constant. Both are findings, not problems with the form.

### 2. Controllers and interfaces

| Field | Answer |
| --- | --- |
| 2.1 | Yes — documented external control interface. |
| 2.3 | Universal Robots ROS 2 driver documentation, `rolling` docs read 14 November 2026. |
| 2.5 | Yes — a vendor-supplied program must run on the controller. Not yet installed. |
| 2.6 | `UNKNOWN` — to be confirmed with the supplier before anything is enabled. |
| 2.9 | `UNKNOWN` — must be tested, not assumed. |
| 2.10 | ROS 2 Jazzy intended. `ur_robot_driver` via `ros2_control`. Hardware component type `system`. Position command interface. `FollowJointTrajectory` server provided by the vendor driver. RMW: default, not yet chosen deliberately. |
| 2.11 | A PLC owns the conveyor. No WMS integration in scope. Separate safety controller, owned by the original cell installer. |

**2.12 Ownership**

| Interface | Owner | Change process | On unannounced change |
| --- | --- | --- | --- |
| Robot external control | Vendor-controlled | Firmware updates applied by supplier on service visits | Not detected today — this is a gap |
| End effector command | Owned — maintenance lead | Internal change request | Detected on next cycle |
| Camera stream | Orphaned | None | Not detected |
| PLC ↔ control PC | Operated — line engineering runs it, supplier specifies it | Supplier change note | Line stops |
| Safety controller | Vendor-controlled — original installer | Formal, requires re-validation | Line stops |

> Two `Orphaned` and `Not detected` entries in a five-row matrix is a useful result. It
> says where the first week of work goes.

### 3. Model files and rights

| Field | Answer |
| --- | --- |
| 3.1–3.2 | Vendor URDF and SRDF available from the public driver repository. |
| 3.3 | Collision meshes present, simplified. |
| 3.4 | Cell CAD exists at the installer. Not yet requested. |
| 3.6–3.7 | Nominal. Not verified against the installed cell. |
| 3.9 Rights | Robot model: vendor, open licence, may be used and modified. Cell CAD: installer owns it; permission to use in simulation `UNKNOWN`. Recorded data: Northfield owns it; may not leave the site network without written approval. |
| 3.10 | Logs and recordings owned by Northfield. Any improvements to the capability itself: `UNKNOWN` — to be agreed, not assumed. |

### 4. Sensors, frames and timing

| Field | Answer |
| --- | --- |
| 4.1 | One fixed RGB-D camera above the bench. Make and model on the asset tag; `UNKNOWN` pending a site visit. |
| 4.5 | `UNKNOWN` until the model is confirmed. |
| 4.6 | Overhead LED, constant; plus morning daylight on the east side. **Not controlled.** |
| 4.8 | No hand-eye calibration has ever been performed. No documented frame tree. Drift would not currently be detected. |
| 4.9 | Target 20 s per tote, stated as an **average**; worst acceptable single transfer 35 s. Robot is paced by the conveyor. No time synchronisation configured. |

### 5. Software, compute and network

| Field | Answer |
| --- | --- |
| 5.1–5.3 | Ubuntu 24.04 on a small-form-factor PC; 8-core CPU, 32 GB RAM, no discrete GPU. |
| 5.4–5.5 | Sustained figure `UNKNOWN`. PC sits in a closed cabinet with no active ventilation — **throttling is plausible and untested.** |
| 5.7 | Administered by line engineering. |
| 5.8 | Robot network is isolated. No outbound internet from the control PC. Remote access would need a jump host that does not exist yet. |
| 5.9 | No public registry access — a local mirror would be required. Dependency changes need line engineering approval. No container runtime today. No rollback path has ever been exercised. |

### 6. Deliverables and acceptance

| Field | Answer |
| --- | --- |
| 6.1 | Working capability, operator documentation, a capability specification, and a handover session. |
| 6.2 | Source code delivered; licence `UNKNOWN`, to be agreed. |
| 6.4 | Yes — a completed capability specification is a deliverable. |

**6.6 Acceptance criteria**

| Criterion | Target | How measured | Who measures | Trials | Pass / fail |
| --- | --- | --- | --- | --- | --- |
| Transfer completed | 95% | Tote ends fully on the conveyor, within the marked zone, lid undisturbed | Line engineering, observed | 200 consecutive, across 3 shifts | ≥ 190 |
| Operator interventions | ≤ 10 per 100 attempts | Any time a person touches the robot, the tote or the controls | Line engineering, logged | Same 200 | ≤ 20 total |
| Worst single transfer | ≤ 35 s | Timestamped from command accepted to result published | Automatic | Same 200 | No attempt over 35 s |
| Clean refusal | 100% | When the tote is outside the envelope, the robot refuses before moving | Deliberate out-of-range trials | 30 | 30 of 30 |

> **These two rows are not contradictory:** 95% completion alongside 10 interventions per
> 100 attempts. Some interventions rescued an attempt that then completed, and some
> failures required no intervention because the robot refused before moving. That is why
> each metric carries its own definition.
>
> And no threshold here is universally acceptable. Whether 95% is good depends entirely
> on what a failure costs at this site — which is a judgement for whoever operates it.

**6.7 Safety** — risk assessment not yet performed. Northfield's engineering manager owns
it. The original cell installer owns the safety-rated equipment and its validation.
Standards applicable are to be determined by the assessor, not by this document.

**6.8 After acceptance** — maintenance ownership `UNKNOWN`. No commitment agreed. Nobody
currently watches for vendor firmware changes. There is no re-validation trigger. These
four `UNKNOWN`s are the most important ones in the document.

---

## Change log

| Version | Date | Change |
| --- | --- | --- |
| 0.1 | 14 November 2026 | First publication. |

## Corrections

This document has **not been reviewed by a qualified robotics professional**.
Corrections and disagreements are welcome at `support@embodiedsoftwarelabs.com`.

## References

- ROS 2 `ros2_control` hardware interface types, Jazzy documentation —
  <https://control.ros.org/jazzy/doc/ros2_control/hardware_interface/doc/hardware_interface_types_userdoc.html>
- MoveIt 2 `move_group` concepts —
  <https://moveit.picknik.ai/main/doc/concepts/move_group.html>
- REP 105, coordinate frames for mobile platforms —
  <https://reps.openrobotics.org/rep-0105/>
- Universal Robots ROS 2 driver documentation —
  <https://docs.universal-robots.com/Universal_Robots_ROS_Documentation/index.html>