A Reproducible Record Workflow for Robot Model Data Entries

On a robot model data site, the difference between a useful catalogue entry and an ambiguous one is rarely the number of fields it holds. The difference is whether another engineer can repeat the same recording process and reach the same description. This article sets out a practical operating method for building a step-by-step record for a robot model entry, using inputs, observations, exceptions and an owner. The method applies to entries such as those found under articulated robot structures at /type/14.html, SCARA configurations at /type/25.html and Cartesian gantry layouts at /type/17.html, where mechanical classification alone does not capture how the record was made.

Why a Reproducible Record Matters for Robot Model Data

The International Federation of Robotics defines an industrial robot as an automatically controlled, reprogrammable multipurpose manipulator programmable in three or more axes, either fixed in place or on a mobile platform for industrial automation applications, following ISO 8373:2021. That definition gives a boundary for what counts as an industrial robot, and the mechanical structures listed alongside it help sort entries into Cartesian, SCARA, articulated, parallel, cylindrical and polar families. A data record, however, must show more than the family. It must show how the payload, axis count, controller interface and safety description were obtained, so a reviewer can audit the entry. Without a reproducible method, two editors can read the same datasheet and produce conflicting values because one counted a tool flange interface as an axis and the other did not.

Inputs: What the Recorder Starts With

The first step is to list inputs before any value is written. Inputs are the documents, interface files and physical observations used to build the entry. Typical inputs include the manufacturer manual, the controller configuration export, the teach-pendant screen showing axis parameters, and the safety document for the installed cell. The recorder writes the input name, version or date, and where it came from. When the robot is one of the collaborative types described by the International Federation of Robotics, the input set should also include the standard followed, such as ISO 10218-1, or a note that a different national or in-house standard was used. Inputs are not conclusions; they are the raw material. The record separates them from observations so a later user can see which claims rest on the manual and which rest on a measured trial.

Observations: Recording What Was Measured

After inputs are logged, the recorder performs a fixed sequence of checks and writes each observation with its condition. For a payload field, the observation is not simply the number printed on the nameplate. The recorder notes the arm pose, the centre-of-gravity offset used, the tool mass included or excluded, and the repeatability trial count if one was run. For an I/O terminal count, the observation distinguishes physical terminals on the controller from logical channels mapped in software. Each observation line uses the same template: item, method, value, unit and context. If entry belongs to the articulated family linked at /type/14.html, the observation might record joint rotation limits per axis and tool-centre-point speed as two different measurements rather than one blended figure. Consistency in the template is what makes the record repeatable.

Exceptions: Where the Source Is Incomplete

An exception occurs when an input does not support a clean observation. The manual may give a payload at a centre of gravity that the actual cell never uses, or the controller export may omit the sixth axis because it is reserved for an external rail. Rather than guessing, the recorder marks the field as an exception with the reason and the unresolved question. Exceptions are a first-class part of the record, not a failure. The Data Catalog Vocabulary published by the W3C, DCAT Version 3, describes how datasets and data services can carry metadata for interoperability and discovery; in the same spirit, a robot data record should carry its own metadata about gaps so a downstream catalogue does not treat an incomplete field as a confirmed one. The exception note names the missing evidence and, if possible, the input that would resolve it.

Owner and Sign-Off for Each Entry

Every record ends with an owner. The owner is the person or role responsible for the entry at the time of writing, together with the date and the version of the workflow used. This does not mean the owner invented the values; it means the owner attests that the inputs were listed, the observations followed the template, and the exceptions were recorded rather than hidden. For a site that holds many model entries, the owner field turns the database from a passive list into a maintained asset. When a later editor updates the SCARA entry linked at /type/25.html after a firmware change, the new owner supersedes the previous one and the date makes the sequence visible. Ownership also helps when a user questions a value: there is a named point of contact for that specific record rather than an anonymous page.

Applying the Method Across Robot Type Records

The workflow is the same whether the record covers a gantry layout at /type/17.html or a delta-style parallel arm. Start with inputs from the manual and controller, move to observations using a fixed template, flag exceptions where evidence is missing, and assign an owner. The mechanical classification from the IFR structure list tells you which family the robot belongs to, but the step-by-step record tells you how trustworthy the entry is. Over time the site accumulates entries that can be compared because each one states what was read, what was measured, what was uncertain and who stands behind it. That is the practical value of a reproducible operating method: it makes robot model data records auditable rather than merely descriptive.