The Robot Mesh Is Not the Collision Model: A Simulation Review Note

Reproducible robot simulation depends on keeping three kinds of evidence separate: what a robot looks like, how its links are placed in space, and what a physics engine uses to decide contact. The ROS 2 Jazzy URDF tutorial makes the first split explicit by showing that a link can carry a visual sub-element for appearance and a collision sub-element for contact behavior, both living at the same level under <link> and both able to use a geometry tag with the same format, plus an optional origin tag ros2_documentation Jazzy URDF source. Treating the rendered mesh as the collision model is a common review failure because the two elements are independent declarations even when they happen to share the same shape.

Appearance Is Not Evidence of Contact

A visual block defines what the robot looks like, and in the tutorial example it uses a blue cylinder with a material and color tag. The accompanying collision block in the same base link reuses a cylinder of the same length and radius, but the documentation states that the reason to separate them matters for two cases: quicker processing, since collision detection for two meshes is more computationally complex than for two simple geometries, and safe zones, where a simpler solid such as a cylinder may be used to restrict movement near sensitive equipment ros2_documentation Jazzy URDF source. For reviewers, that means a high-fidelity mesh in the visual tree is not proof that the same mesh is used for contact; the collision geometry may be a box, a cylinder, or a deliberately larger envelope.

Link Transforms Need Their Own Record

Where a link sits relative to another is a separate question from both appearance and collision shape. The origin tag can appear under both visual and collision, and the tutorial notes that many cases want the collision geometry and origin to match the visual ones, while other cases intentionally differ. At the system level, tf2 is the transform library that keeps track of multiple coordinate frames over time and maintains the relationship between frames in a tree structure buffered in time, letting a user transform points or vectors between any two frames at a desired time ros2_documentation Jazzy tf2 source. A simulation review note should therefore log the frame names and the transform source separately from the URDF geometry, because tf2 can operate in a distributed system and can be fed by broadcasters or a central node.

Inertial Data Is a Third Layer

The same tutorial adds that every link being simulated needs an inertial tag, with mass in kilograms and a symmetric 3x3 rotational inertia matrix given by six elements such as ixx, iyy, and izz. It warns that, when using realtime controllers, zero or near-zero inertia elements can cause the robot model to collapse without warning, and that the identity matrix is a particularly bad choice because it is often much too high: the tutorial says it corresponds to a 0.1 m box with a mass of 600 kg. In review terms, this is another independent declaration: a link may look correct, may have a sensible collision shape, and still fail to simulate because its inertial block is missing or implausible. Recommended documentation practice is to record the mass value and the inertia element values next to the link name, rather than assuming the visual dimensions imply them.

Reading Direction and the Transform Tree

tf2 also introduces a subtlety that reviewers often miss: transforms published in the geometry_msgs/msg/Transform message represent the frame formulation, and the values are directly inverse depending on whether data or the frame itself is being traversed. The documentation gives the relation that the data transform is the inverse of the frame transform between the same two frames, and recommends using transform<T>(target_frame, ...) methods so the source frame is read from the datatype and the math is handled internally ros2_documentation Jazzy tf2 source. For a reproducibility checklist, this means noting whether a recorded pose is a lookup result or a broadcast value, and which direction of the tree was used, because the same physical arrangement can be written two ways.

A Hypothetical Review Example

Suppose a team publishes a mobile manipulator URDF in this hypothetical example. The base link has a visual cylinder of 0.6 meters length and 0.2 meters radius with a color, and a collision cylinder of the same dimensions, matching the tutorial's new base link. The inertial block lists a mass of 10 with ixx, iyy, and izz of 1e-3. The arm's end link, however, uses a detailed mesh only in visual, while its collision tag is a larger box to create a safe zone near a camera. If a reviewer copies the visual mesh description into a report and calls it the collision model, the note is wrong. The correct record names the visual geometry type, the collision geometry type, the shared or differing origin, and the inertial values, then links those to the frame names that tf2 would track.

Recommended Reproducibility Checklist

This checklist is a recommended documentation practice, not a claimed requirement of the cited ROS 2 Jazzy sources. Record the URDF file identity and, for each link, whether visual and collision use the same geometry tag format and the same origin or a different one. Note any intentional substitution of a simple geometry for a mesh and the stated reason, either quicker processing or safe zones. Log the inertial mass in kilograms and the six inertia elements, and flag zero, near-zero, or identity-matrix values as items to inspect rather than accept. Separately, keep a frame inventory for tf2: the coordinate frames in the tree, whether transforms are static or time-varying, the broadcast direction, and whether a pose shown in a note came from a listener lookup or a broadcaster message. Finally, store the transform-tree snapshot with a timestamp label, since tf2 buffers frames over time and a pose without its time context is not reproducible.

Keeping those three layers distinct turns a simulation review note from a picture description into testable evidence. For readers tracking tooling changes, see our technical guides and the site's industry updates for related context.