Robot Data Acceptance: Keep Joint Names Beside Values

A robot catalogue can contain a convincing list of joint readings while leaving the receiver unable to tell which reading belongs to which joint. The difficulty is not always a missing unit. It can be a lost relationship between names and parallel values. For a procurement handover, that relationship deserves its own acceptance question. This article considers a fictional data package supplied for a catalogue entry, rather than measurements from an operating robot.

Begin with the record that actually carries the association

Ask the supplier to identify the original record format before reviewing a spreadsheet assembled from it. A screenshot may show names in a convenient order, while a separately exported column follows another order. Neither presentation explains the association unless the transformation between them is documented. Keep the received record and the explanatory table as distinct items in the handover.

The receiver can then ask a concrete question: which rule associates this named joint with this field in this delivered representation? The answer might be an explicit identifier or a documented positional relationship. It should come from the format and the supplier's mapping explanation. Alphabetical sorting by a reviewer is not evidence that independently rearranged columns still correspond.

Read the optional array rule in its stated context

The official Jazzy JointState message definition describes named joints and parallel state arrays. Its fields are optional in the sense explained by the comments: arrays should share their size or be empty. An empty effort array therefore should not automatically be presented as a measured effort of zero. This is a statement about that message format, not a universal rule for every vendor's catalogue.

For the hypothetical package, retain whether a field was absent, empty, or populated. If a downstream table substitutes a display symbol for an empty array, explain the symbol. If a supplier uses another format altogether, request its own specification instead of imposing the ROS message layout on unrelated data. Acceptance begins with the representation that was actually agreed.

Connect the names to the delivered model

The Jazzy robot_state_publisher documentation explains that the publisher receives a URDF kinematic model and uses incoming joint states to update that model. This makes the model reference relevant when a handover claims that named records correspond to a particular robot description. It does not show that a real robot occupied any reported pose.

Ask which delivered model the supplier used when explaining the names. Preserve its reference alongside the association note. A later revision may rename an element or change what an export includes; a familiar product title alone does not resolve that question. Where the relationship remains undocumented, record the ambiguity rather than silently replacing names with the ones a reviewer expects.

The buyer need not start a publisher or move hardware to clarify this documentary relationship. A supplier can first provide the relevant extract and explain its origin. Any operational demonstration should be separately authorized and recorded under its own conditions. The document checklist should not create an implied instruction to connect an unfamiliar robot.

Review a transformed table without inventing missing readings

Suppose the original record has joint names, position entries and no effort entries, while a sales table displays an effort column. The useful follow-up is to ask how that column was produced. It could be a placeholder, a separately sourced specification, or another record entirely. Those possibilities call for different explanations; none can be selected merely because the cells look tidy.

Record the transformation in terms the next receiver can follow: original field, displayed field, association rule and treatment of missing content. Check the explanation against the supplied example. If the example changes, retain the earlier question and identify which replacement resolves it. This keeps an editing decision from becoming an undocumented claim about measured behaviour.

A catalogue editor can also preserve the distinction in a change note. If a column is reordered for presentation, identify the paired names that were reordered with it. If only headings change, describe that narrower edit. This makes the table easier to maintain without requiring a future editor to infer whether a cosmetic change also altered the association represented by the record.

Make the acceptance statement useful to the next reader

A narrow conclusion might state that the delivered names, populated arrays and model reference can be followed through the supplier's explanation. It should also list unresolved associations and distinguish them from measurements that were never supplied. Such a record helps a future reviewer decide what can be imported and what still needs clarification without guessing how blank fields were interpreted.

The two original illustrations explain documentary relationships only; they contain no captured joint values or robot test results. Further reference material is available in the robot data catalogue and the article directory. A readable association is a sound basis for reviewing data delivery, while physical accuracy and operating suitability remain separate matters requiring their own evidence.