Robot Simulation Deliverables: URDF, Collision Models, Limits, and Hardware Gaps

A robot that looks perfect in a viewer can still be unusable for planning. The mesh loads, the arm moves, and nothing warns you that the collision geometry is a hollow shell, that the inertia values are placeholders, or that the joint limits belong to a different revision of the machine. Simulation deliverables are a procurement item, not a free extra, and they are worth the same scrutiny you give the hardware. This article is about how to read a simulation package for what it can actually answer, and how to decide what still has to be confirmed on real hardware.

Separate Visual, Kinematic, Collision, and Dynamic Models

A simulation package is several models wearing one file name, and each answers a different question. Treating the mesh file as the whole package is the first mistake.

The visual model is what you see in a viewer. The kinematic model defines the links, the joints, and how they connect, which is what lets a planner compute where the tool will be. The collision model is the geometry the physics engine uses to detect contact; it is often a simplified shape that does not match the visual mesh. The dynamic model carries mass, center of mass, and inertia, plus the actuation assumptions the controller uses.

These are not interchangeable. A good visual model tells you nothing about whether the tool will hit the fixture. A conservative collision box can flag paths that the real tool could clear, while omitted or undersized geometry can hide collisions that would occur on the machine. In the URDF format that ROS-based toolchains use, these live in separate elements: the visual element feeds the display, the collision element feeds the physics engine, and the inertial element carries mass, center of mass, and the inertia matrix. A package can be complete in one and empty in another. Check each model against the question you need it to answer, and do not let a polished visual model stand in for a collision or dynamic model.

Check Frames, Joints, and Limits

The kinematic model is only useful if its frames and limits match the machine you are actually buying.

Frames define where each link's coordinate system sits, and the joint definitions describe how one link moves relative to the next. If a frame is offset, or a joint axis is defined in the wrong direction, the planner will compute a pose that the real robot cannot reach. The zero position matters too: the model's joint zero has to correspond to the machine's actual zero, or every computed pose is shifted.

Limits are where model and hardware most often diverge. The joint range, the velocity limits, and any soft limits in the model have to correspond to the physical unit and its firmware revision. A model built for an earlier revision may carry limits the current machine no longer has, or miss limits that were added. Universal Robots provides model-description resources through its official ROS 2 repository, while ROS-Industrial also maintains description packages. Use the files for the exact robot model and controller generation you intend to buy, and verify the configuration and joint limits against the delivered hardware. Where the model and the machine disagree, the machine wins, and the model is an open item to correct.

Inspect Collision Geometry

The collision model decides what the planner thinks can hit what, so its scope is a safety and feasibility question, not a cosmetic one.

A collision model that covers only the arm links but not the tool, the cables, or the fixtures will let the planner route a path that collides in reality. The reverse is also a problem: an overly conservative collision model that wraps a tool in a large box will make feasible paths look impossible, and you will pay for that in cycle time or in a redesign. The right scope is the geometry that can actually collide, modeled closely enough to be useful and simply enough to compute.

Look at what the package includes. Does it model the end effector and its cabling? Does it include the fixtures and the machine frame, or only the robot? Are the collision meshes simplified versions of the visual meshes, and if so, by how much? For a tool with a complex shape, a simplified collision mesh can hide a real interference. Ask the supplier which geometry the collision model covers and which it deliberately omits, and treat the omissions as items to verify on site.

Review Inertia and Actuation Assumptions

Dynamic values are the part of a simulation package most likely to be missing or assumed, and they are the part that most affects whether a simulation predicts real behavior.

Inertia, mass, and center of mass determine how the robot responds to acceleration, so a dynamic simulation is only as good as these numbers. The problem is that manufacturers often do not publish a complete set. Some robot-description packages provide geometry without a fully documented, experimentally identified set of mass, inertia, and friction parameters. The buyer should therefore distinguish values measured on hardware from values calculated from CAD or assumed in a model. That is the practical reality: for some machines, the dynamic values in a package are estimates, and the source of each value matters.

Ask where each inertia value came from: measured, computed from a detailed CAD model, or assumed. Where a value is assumed, the simulation's prediction of torque, settling, or dynamic behavior carries that assumption forward. Do not invent inertia or friction numbers to fill a gap. Instead, state which tasks the model is valid for and which it is not. A model with assumed dynamics may be fine for reach and collision planning and unreliable for predicting cycle time or motor load. Model-predicted actuator loads and settling behavior should be treated cautiously when friction, inertia, or controller assumptions have not been validated on the intended hardware. Mark the dynamic values as verified or assumed, and let that mark travel with the model.

Compare Simulation with Safe Hardware Tests

A simulation that passes is not a factory acceptance test, and treating it as one is how surprises reach the floor.

The gap between simulation and hardware comes from several sources at once: the fidelity of the geometry, the accuracy of the dynamic values, the model of the controller, and the behavior of the real world that the model simplifies. Geometric mismatches between the model and the real cell change the clearances a planner predicts. Record those differences and check the required poses against the delivered hardware. None of that is a reason to skip simulation; it is a reason to know what simulation can and cannot certify.

Use simulation for what it is good at: reach checks, collision screening, cycle-time estimates, and path planning. Then confirm the critical poses and tasks on real hardware, at reduced speed and with safety limits in place. Pick representative poses, not the easy ones, and observe where the real robot differs from the model. Record the differences. A pose that the model says is reachable but the machine cannot reach, or a path the model clears but the machine grazes, is exactly the kind of finding that belongs on the floor rather than in the proposal. Do not let a clean simulation run stand in for a hardware test, and do not let a hardware test on one pose stand in for the poses the cycle actually uses.

If the buyer is still deciding how the paths will be created, the drag teaching versus offline programming comparison addresses that upstream choice; the model-deliverables review here starts after the toolchain is chosen.

Specify the Model Delivery Record

The deliverable is not a folder of files; it is a documented package with a version, a scope, and an owner.

Ask for a delivery record that states the model version and the hardware revision it corresponds to, the format and the toolchain it was built for, and the licence under which it may be used. List which models are included: visual, kinematic, collision, and dynamic, with the source of the dynamic values. State the known limitations, including any geometry the collision model omits and any dynamic value that is assumed rather than measured.

Include at least one reproducible example: a scene, a set of poses, or a script that a third party can load and run to confirm the package behaves as documented. Assign responsibility for updates. When the machine's firmware or hardware revision changes, who updates the model, and how is the new version delivered? A model without an update path goes stale the first time the machine changes. This record is what turns a simulation package from a courtesy into a procurement item you can hold a supplier to.

The separate robot configuration management guide addresses the broader firmware, map and parameter change-control process.

Know what the simulation can actually prove before you buy the robot. Send the model revision, proposed URDF or CAD inventory, omitted collision geometry, and two or three poses that must be checked on the real machine. Through documentation and compliance support, AIsirRobot can help compare the manufacturer's existing files with your requested deliverables and identify the missing version, inertia, or validation records for supplier clarification.