From URDF to SimReady: What a Robotiq Gripper Taught Us About Simulation Assets

For industrial robotics teams, simulation is useful only when the important parts of the simulated system behave enough like the real system to support better engineering decisions. A robot arm that looks right but reaches to the wrong pose is an obvious problem. A gripper that looks right but responds differently during contact can be harder to notice, and in manipulation work it may matter even more.

At Southwest Research Institute, we have been developing and evaluating Physical AI approaches for high-mix manipulation. The broader effort combines teach-through-demonstration with simulation, with the goal of supplementing demonstrations through reinforcement learning. Our lab setup includes Universal Robots UR5e arms and Robotiq 2F-85 grippers. The full workcell matters, but the gripper became the clearest example of a practical problem many robotics teams are beginning to face: the asset that is available is rarely the same thing as the asset that is ready for production-oriented simulation.

Isaac Sim representation of the lab system

Photograph of the lab setup

The first problem: available assets are not automatically usable assets

A common starting point in a simulation project is to use the assets that are already available in the simulator or in the ROS ecosystem. That was our starting point as well. Isaac Sim includes Robotiq gripper assets, and there are public Robotiq-related resources in the ROS and ROS 2 ecosystem. Those resources are valuable, but in our testing they did not immediately give us the behavior we needed.

The issues were not cosmetic. We encountered practical asset-structure and behavior problems, including difficulty restructuring an articulation root, gripper assets that were not instanceable, and contact behavior that failed when a mimic joint encountered an object asymmetrically at one finger pad. Each of those issues matters in a production-oriented simulation workflow.

For readers who do not spend their day in USD internals, an “instanceable” asset is one that can be referenced and reused cleanly rather than copied and manually modified each time. That matters when a simulated workcell becomes more complex or when the same asset must appear in many scenes. A “mimic joint” is a joint whose motion follows another joint. For a mechanically coupled gripper, mimic behavior can be the right abstraction because the physical hardware is not simply two independent fingers driven by unrelated commands.

That distinction is central to the Robotiq 2F-85.

Why the Robotiq 2F-85 is a useful test case

The Robotiq 2F-85 is a parallel gripper, but its mechanism is not as simple as two independent pads moving toward each other. It includes closed-loop mechanical behavior, which creates challenges for simulation asset authoring. The practical modeling decision becomes: should the gripper be represented with one driven joint and mimic behavior, or should both sides be driven independently?

A single driven joint with mimic behavior is attractive because it better reflects how the gripper is normally commanded. Driving both sides independently can make an asset move in simulation, but it introduces extra controller and joint-state complexity and moves the simulation farther away from the real gripper abstraction. We evaluated that path by importing a URDF into USD and adding drives to both sides. For our purposes, that direction created more complexity than value, and it likely would still have required mimic behavior to represent the coupled mechanism faithfully.

NVIDIA’s Isaac Sim documentation includes a tutorial on rigging closed-loop structures using a Robotiq 2F-85 gripper, and that tutorial points to a workflow that starts from a CAD/Onshape representation and then adds the physics, joint, and drive configuration needed to make the asset functional in Isaac Sim. That detail is important: import is only the beginning. A realistic gripper asset still needs careful authoring and validation.

What we tried from the ROS ecosystem

After our initial asset testing, we reviewed several public resources related to Robotiq grippers, including the older ROS-Industrial Robotiq repository, PickNik’s ros2_robotiq_gripper, and UW-Lab resources and assets. It’s worth noting that Robotiq does not currently provide first-party assets for its grippers; all of the resources we tested are community-maintained.

The best-performing candidate in our lab testing was the UW-Lab calibrated USD asset for the Robotiq 2F-85. That asset appears to follow the same general pattern as the Isaac Sim closed-loop structure workflow, with additional modifications. Out of the box, it behaved better than the other candidates we tested. Even though it uses mimic behavior, it did not break when an object contacted one finger before the other, and we did not observe the unexpected mesh behavior we saw elsewhere when larger forces were applied.

Simulated Robotiq 2F-85 mounted on the UR arm

That made the UW-Lab asset a much better starting point. It did not make the problem disappear.

The remaining fidelity gap

The physical Robotiq 2F-85 still exhibited behavior that the simulation did not capture. In the real gripper, when an object is grasped near the base-side region of the finger pads, the pads can angle inward slightly. When the object is grasped farther out on the pads, the pads remain parallel.

In our simulation, that behavior was not represented. The simulated kinematics and physics did not capture the same pad motion we observed on the physical gripper.

Physical Robotiq 2F-85 on the lab robot

That may sound like a small difference. In manipulation, small differences at the contact interface can become large differences in outcome. A grasping policy trained or validated in simulation is sensitive to contact geometry, friction, compliance, joint coupling, and failure modes. A gripper asset that works for visualization may still be insufficient for reinforcement learning, synthetic data generation, or pre-deployment validation.

The broader lesson: conversion is not fidelity

ROS users tend to start with URDF, and for good reason. URDF is familiar, widely supported, and often the most available robot description format for ROS-based systems. SDF is also common in simulation workflows. USD and OpenUSD offer a powerful scene representation for modern simulation and digital-twin workflows. But moving from URDF or SDF to USD does not automatically create the physical and behavioral information needed for high-fidelity simulation.

A converter can translate what is present. It cannot reliably invent what is missing.

That is where the SimReady idea is useful. NVIDIA describes SimReady as more than placing simulation data into a USD file. The goal is to represent simulation-ready content through named, typed, validated properties that tools can interpret, validate, and use. In NVIDIA’s broader description, SimReady assets include physics properties, semantic labels, material attributes, and, where needed, behavioral or articulation data.

For robotics teams, that framing exposes the real gap. A useful production asset is not merely a mesh. It is not merely a URDF. It is not merely a USD file. It is a validated representation of geometry, kinematics, dynamics, contacts, materials, semantics, and control-relevant behavior at the level required by the task.

Practical takeaways for robotics teams

First, validate assets against the behavior that matters for the application. Loading the asset, moving the joints, and rendering the workcell are necessary checks, but they are not enough. For manipulation, validation should include contact cases, asymmetric grasps, edge grasps, expected failure modes, verification of the mesh geometries, and comparisons against the physical hardware.

Second, choose the simulated command abstraction deliberately. For a mechanically coupled gripper, independent finger drives may be convenient during asset authoring, but they may also create a mismatch with the real system. If the physical gripper is commanded as a coupled mechanism, the simulation should preserve that abstraction unless there is a clear reason to do otherwise.

Third, track asset provenance and simulator version. Isaac Sim documentation, import workflows, asset structure, and tuning parameters can vary between versions. A gripper that behaves acceptably in one workflow may require different configuration in another. Asset source, simulator version, import method, and post-import modifications should be captured as part of the engineering record.

Fourth, treat conversion as the start of an asset-authoring workflow rather than the end. URDF-to-USD or SDF-to-USD conversion is valuable, but high-fidelity simulation still requires authoring, tuning, and validation. The missing information often lives with the equipment manufacturer or must be measured experimentally.

Finally, involve equipment manufacturers where possible. Manufacturers are often best positioned to provide richer kinematic, dynamic, material, and behavioral information about their products. The robotics community would benefit from a more standard way to move that information from manufacturer data into ROS-compatible descriptions, USD-based simulation assets, and validation tests.

Toward a better ROS-to-SimReady workflow

The Robotiq 2F-85 experience points to a larger opportunity for the ROS-Industrial, open-source robotics, simulation, AI, and equipment-manufacturer communities. We need workflows that preserve what ROS users already rely on while adding the physical and behavioral fidelity required by modern high-fidelity simulation.

A practical workflow could look something like this:

• Manufacturers provide CAD, URDF or SDF descriptions, kinematic details, material properties, actuator behavior, and validation data;

• ROS and open-source tools support accessible robot descriptions and integration;

• USD-based simulation workflows support composition, reuse, and high-quality scene representation; and

• SimReady-style validation defines whether an asset is ready for the intended class of simulation tasks.

The important point is that “simulation ready” should become an engineering claim that can be tested, not a label applied because an asset loads in a simulator.

There are signs this is starting to happen. When we contacted Robotiq prior to publication, they indicated that “an official C++ SDK, ROS 2 driver, URDF and updated Isaac Sim assets are in active development.”

Conclusion

Our experience with the Robotiq 2F-85 was a reminder that the hard part of simulation is not always the robot arm, the environment, or the renderer. Sometimes the hard part is the contact behavior of a gripper pad at the exact point where the simulated world meets the physical one.

URDF, SDF, USD, and SimReady all have roles to play, but no single file format solves the fidelity problem by itself. For production robotics, a simulation asset earns trust only when it reproduces the behaviors that affect the task. The closer the ROS, simulation, AI, and equipment communities can align around that standard, the less time teams will spend rebuilding the same assets and the more confidence they can place in simulation before deploying to real hardware.