Robot software integration requirements checklist

Published 14 November 2026 · questionnaire version 0.1 · published and edited by Randy Levine for Synthari AI LLC. This page has not been reviewed by a qualified robotics professional. Corrections and disagreements are welcome at support@embodiedsoftwarelabs.com.

Why a form beats a kickoff call

The same facts get asked for on every integration. They get asked across six emails and two calls, answered by whoever happens to be on the thread, and then re-asked three weeks later by somebody new. Half the answers turn out to be assumptions, and the assumptions are discovered in the order that is most expensive.

A questionnaire is just those questions, written down once, in an order, with the uncomfortable ones included rather than left for later. It is not bureaucracy — it is a way of finding out early which parts of the job nobody has thought about yet.

Which is the point worth making before any of the sections: an unanswered field is a result, not a failure. A form returned with nine fields marked unknown gives a more accurate picture of the work than one returned with nine guesses. The template asks you to distinguish unknown from not applicable, because those are different answers and both are useful.

One thing the form deliberately does not ask for: source code, credentials, API keys, proprietary datasets, model weights, or workplace video of identifiable people. None of it is needed to scope an integration, and sending it before an agreement exists creates a problem for both sides. There is no upload on this page and there is not going to be one until there is a process behind it worth trusting.

1. Describe the robot and end effector

This section establishes what physically exists before anybody discusses software, and three of its fields do most of the work.

The exact model, not the brand. Payload and reach vary by a factor of three across a single manufacturer's range. "A UR robot" and "a UR10e" are different amounts of information.

Usable payload, not rated payload. State it at full extension with the end effector fitted. A 1.4 kg tool removes 1.4 kg of capacity before anything is picked up, and the datasheet number is measured without it.

How the object is presented. This is the field that most often decides the difficulty of a task, and it is the one most often left out. "Out of a tote" can mean a single item in a fixture or an unsorted pile in a bin. Those are not variations of one project; they are two different projects, and the gap between them is the gap between configuration and research.

The section also asks, near the top, who is expected to be nearby while it runs — nobody, trained operators, untrained personnel, or the public. That single answer changes the whole engineering picture, and it belongs at the front rather than in a safety annex at the back. Collecting it is not the same as assessing it; see section 6.

2. Inventory controllers and interfaces

This is the section that decides whether an integration is a configuration exercise or a development project, and the difference is usually invisible from the outside.

The first question is whether a documented external control interface exists at all, and the follow-ups are the ones that get skipped: is it an extra-cost module, does a vendor-supplied program have to run on the controller, does enabling it affect warranty or support, what command rate does the controller actually accept, and what the controller does when the external connection drops. That last one is nearly always assumed and nearly never tested.

If ROS 2 is in scope, the form asks for the distribution by name, the driver repository and tag, and — where ros2_control is used — the hardware component type and which command and state interfaces are exposed. The ros2_control documentation describes hardware components as system, actuator or sensor, with command interfaces setting goal values and state interfaces reporting current condition. Those are the words a driver's own documentation will use, so they are the words the form uses.

One row in that table is worth more than it looks: whether a FollowJointTrajectory action server exists. MoveIt's move_group node uses that action interface and acts only as a client — the robot side has to provide the server. If no server exists, somebody is writing one, and in most first estimates nobody has costed that.

The section finishes with the systems the integration has to live alongside: the PLC, the safety controller, the vision system, anything that schedules work. Each of those is an interface, and each needs an owner.

3. Provide model files and usage rights

Simulation, motion planning and collision checking all depend on files somebody has to supply and permission somebody has to grant, and the permission half is what stalls projects.

The files: a kinematic model, a semantic description, collision meshes as well as visual ones, cell and fixture CAD, and models of the objects being handled. For each, two questions that are usually skipped — is this known to match the installed hardware, or is it nominal? and who last checked, and when? A nominal cell model is still useful; a nominal cell model believed to be accurate is a trap.

Then rights, as an explicit table rather than an assumption. For each file set: who owns it, may it be used in simulation, may it be modified, may it leave your network, may it be published, and does any of that expire. The cell CAD usually belongs to the installer rather than the operator, and nobody discovers this until the week it is needed.

The last row is the one worth settling before anything starts: who owns the data produced during the work — the logs, the recordings, the trajectories, and anything learned from them.

4. Declare sensors, frames and timing

Sensors are the easy part of this section: make, model, firmware, mounting, resolution, interface, and whether a working driver is known to exist for your stack. The question underneath them is lighting, and whether it is controlled or merely present.

Frames are where the section earns its place. The form asks you to name the transform tree as it exists today, say who publishes each transform, and confirm that it is a single chain with one parent per frame. REP 105 names earth, map, odom and base_link and requires exactly that ordering, because each frame can have only one parent. A tree with two parents on one frame is a defect rather than a configuration choice, and it is worth knowing about on day one.

Calibration gets its own block, because it is a dependency that is not a component. Hand-eye calibration, tool centre point, who owns them, when they were last verified, how drift is detected — and the uncomfortable one, what happens when a calibration is wrong: is it noticed, or is it silent?

Timing closes the section with a distinction that changes designs: is the cycle-time target an average or a worst case? The average is what the robot does. The worst case is what everything around it has to tolerate.

5. List software, compute and network dependencies

Two fields in this section are a pair and belong together: sustained compute, measured in the real enclosure, and whether that enclosure has any ventilation. Peak throughput on a bench in an air-conditioned room is not the number to size a perception model against. Thermal throttling is one of the commonest sizing errors in robotics, and it shows up in service, in summer, long after acceptance.

Network comes next, and it is usually more restrictive than anyone assumed. Is the robot network isolated? Who controls the firewall? Is there outbound internet from the control PC — and if not, can packages be installed at all, or is a local mirror required? Is remote access possible, through what, and who approves it? A plan that assumes a package manager can reach the internet is a plan that stops on the first day on site.

Then change control, which is the part that outlives the project: who approves a dependency version change, how software is deployed to the machine today, whether a rollback path exists — and whether it has ever actually been used. An untested rollback is a hope.

6. Define deliverables and acceptance evidence

The job of this section is to make done something both parties can check rather than argue about.

Deliverables first: what has to exist at the end, whether source code is one of them and under what licence, who may maintain it afterwards, and who signs off against what.

Then acceptance criteria, one row each, with a column that is usually missing: how it is measured, and by whom. A criterion without a measurement method is a preference. "95% success rate" means nothing until somebody has written 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.

Safety and compliance ownership is collected here even though this document assesses nothing: who is responsible for the risk assessment, whether one has been done, who owns the safety-rated equipment and its validation, and who signs the final acceptance. These are facts about your organisation, not conclusions about your installation.

The section ends after acceptance, with four questions that are the most common source of trouble a year later: who answers the phone, what is actually committed, who watches for upstream firmware and dependency changes, and what re-validates the system when one of them happens. Best effort, a response target and a contracted commitment are three different answers, and no commitment is a legitimate one that prevents a bad assumption.

Who owns which interface

Every integration has a handful of interfaces, and the one that causes trouble is always the one nobody is accountable for. The questionnaire carries this matrix as an appendix; it is reproduced here because the four ownership levels are the useful part and they only work if everyone reads them the same way.

Orphaned is a real and common answer, and writing it down is the whole point of the exercise. A matrix that comes back with two orphaned rows has told you where the first week of work goes, which is more than most kickoff calls achieve.

The two examples, and what they are not

The questionnaire ships with two worked examples. Both are entirely fictional. The organisation does not exist, the deployment does not exist, no robot has run the task, and every value was invented to show what a filled-in field looks like at the right level of detail. None of it should be cited or used as a benchmark.

The first is an incomplete request — a short, polite, completely ordinary first email that cannot be answered. It is followed by a table of the thirteen fields it leaves open and what each one changes. The point is not that the sender did anything wrong. Most first contacts look like this. The point is that the honest reply is a link to the questionnaire rather than an estimate, because any number given against that email is invented, and both parties will later behave as though it was not.

The second is a completed brief, filled in to a realistic standard — which means it still contains a dozen fields marked unknown. That is deliberate. A completed form is not a form with no gaps; it is a form where the gaps are visible and labelled. In the example, four of them sit in the final section, about who maintains the system afterwards, and those are the most important unknowns in the document.

The example also carries one pair of numbers worth looking at: 95% task completion alongside 10 operator interventions per 100 attempts. Those look contradictory and are not. Some interventions rescued an attempt that then completed, and some failures needed no intervention at all because the robot refused before moving. Seeing that in a filled-in document is what makes the "definition used" column obvious.

References

The interface vocabulary in the questionnaire follows ROS 2 conventions. These are the documents it follows, with the version read and what was actually checked:

• ros2_control — hardware interface types
  Jazzy documentation, checked 14 November 2026. Confirms the three hardware component types — system, actuator and sensor — and that joints carry command interfaces to set goal values and state interfaces to read current state. Section 2.10 of the questionnaire uses these terms.
• MoveIt 2 — the move_group node
  Main-branch documentation, checked 14 November 2026. Confirms that move_group reads the URDF from the robot_description parameter and the SRDF from robot_description_semantic, listens on /joint_states and to TF, and uses the FollowJointTrajectory action as a client only — the robot must supply the action server. That is the basis for the claim in section 2.
• REP 105 — coordinate frames for mobile platforms
  Checked 14 November 2026. Names earth, map, odom and base_link, and states that map is the parent of odom and odom the parent of base_link, because each frame can have only one parent. Section 4 asks you to confirm your tree against this.
• Universal Robots — ROS 2 driver documentation
  Checked 14 November 2026, as a vendor example rather than an endorsement. The driver's hardware interface marks robot_ip, reverse_port, script_sender_port, script_filename and the input and output recipe filenames as required parameters — which is exactly the kind of mandatory network and controller configuration section 2 exists to surface before anyone quotes a timeline.
• CC BY 4.0
  The licence this questionnaire is published under.