A Geometry Export Is Not a Cell Handover: Keeping Robot Models and Print Parameters Distinct

In automated additive manufacturing cells, the moment a designer exports a shape is often mistaken for the moment a work cell is instructed. That confusion creates gaps in documentation review. A CAD geometry export carries spatial form. A URDF file, used in ROS 2 to describe a visual robot model, is built from link and joint elements that place shapes in a tree with one root link, not from an executable motion plan for a controller (see ROS 2 Jazzy visual-model tutorial). A geometry file alone does not document deposition parameters, because the two artifacts answer different questions: what the part or robot looks like, and how material is laid down layer by layer.

Geometry Export Versus Machine Build Job File

A NIST example explains that additive manufacturing builds a 3D shape from thin layers of metal powder, with each layer melted into place by a laser or similar energy source (see Additive manufacturing | NIST). That example illustrates one powder-based additive process; other additive processes use different materials and mechanisms. A geometry export, by contrast, is a representation of form. When a team hands over a cylinder defined as 0.6 meters long with a 0.2 meter radius in a URDF geometry block, the file states size and visual placement. It does not state laser power, scan spacing, layer thickness, or powder feed behavior. Those belong to a process record or a machine build job file that may contain parameters.

The technical reference section covers handover methods, while the industry updates index provides a separate starting point for following equipment announcements. For a handover review, the practical distinction is simple. A geometry export is a spatial artifact. A build job file is a process artifact. Reviewers should never assume that because a mesh or URDF passed a visual check, the deposition recipe is documented. NIST also notes that comprehensive measurements and standards will be critical as the field matures, which supports keeping observable records separate from geometry files rather than merging them silently (see Additive manufacturing | NIST).

What a URDF Actually Describes

The ROS 2 Jazzy URDF tutorial shows a minimal model named myfirst with one link whose visual component is a cylinder 0.6 meters long and 0.2 meters in radius (see ROS 2 Jazzy visual-model tutorial). Later examples add a right_leg box and a fixed joint named base_to_right_leg with a parent base_link and a child right_leg. The documentation states clearly that URDF is ultimately a tree structure with one root link, and that a leg's position depends on the base link's position through the joint origin, defined in the parent's reference frame.

That structure is a kinematic description of links and joints. It is not an executable robot trajectory. The tutorial's goal is to build a visual model that can be viewed in RViz, and the launch file loads the model as a parameter for the robot_state_publisher node and starts RViz with a configuration file. Reviewers should read a URDF as a statement of shape, hierarchy, material color tags such as a blue material with rgba values, and transforms. They should not read it as proof that a controller moved, deposited material, or executed a path. A trajectory or executed motion record needs its own identifier and review history.

Unit Mismatch at Document-Review Time

A recurring qualitative problem in handover review is unit mismatch. In the URDF examples, lengths are given in meters: 0.6 meters for a cylinder length, 0.1 meters for a box dimension, and origin offsets such as -0.22 meters in the y direction and 0.25 meters in the z direction (see ROS 2 Jazzy visual-model tutorial). If a CAD system exports in millimeters while a robot model consumes meters, the numbers describe different physical sizes even though the digits look similar.

At document-review time, the recommended documentation practice is to record the unit convention next to the geometry export and next to any linked process record. A reviewer can note, for example, that a visual geometry block uses meters while a separate deposition sheet uses millimeters, and flag the mismatch before any build is discussed. This is a paper-level check on documents. It does not assert that a controller actually moved, or that a mismatch would cause a specific physical event. The safe editorial position is that the reviewer observes the units in the artifacts and records the discrepancy in a handover log.

Another review point is the visual origin. In the origins example, the leg's visual origin has an xyz offset of 0 0 -0.3 and an rpy rotation of 0 1.57075 0 so the long part of the leg aligns with the z axis (see ROS 2 Jazzy visual-model tutorial). A geometry export may therefore encode placement that a downstream reader mistakes for a machine coordinate. The record should say the file encodes visual placement in a parent frame, not a commanded cell pose.

A Handover Record With Separate Owners

Below is a hypothetical checklist for a geometry handover record. It is not a required standard from NIST or ROS; it is a recommended documentation practice for an additive manufacturing handover.

• Artifact name: e.g. 05-visual.urdf style model name from the tutorial family.
• Artifact type: CAD geometry export or URDF visual robot model, not a build job file.
• Declared units: meters in the URDF geometry blocks, recorded explicitly.
• Structure summary: root link base_link, child links such as right_leg, and fixed joints with parent and child.
• Parameter status: deposition parameters are NOT in this file; they live in a separate process record.
• Review note: unit mismatch observed between geometry meters and process sheet millimeters, logged for follow-up.
• Motion statement: no controller motion is assumed from this file; only visual or kinematic description is documented.

This handover record is unique because it separates the spatial artifact from the process artifact and records unit conventions at review time. It uses the URDF structure shown in the ROS 2 Jazzy source: one root link, joints defined by parent and child, and visual geometry with origins (see ROS 2 Jazzy visual-model tutorial).