[Question] Articulation object with mechanical closed loops

[jeferal]

Question

I am working on a robot that I want to model with closed loops mechanisms. I managed to have the USD model working by selecting via isaac-sim's GUI the joints that close the loop to: "Exclude from Articulation". When loading this model using the GUI I can apply a force to a body and I see that the resulting movement in the closed loop mechanism is correct.

I now want to load the USD and create an Articulation object so that I can integrate this model with the RL training. When doing this I define position actuators in the motor with a certain stiffness and damping. And also I define stiffness = 0 in the passive joints. When simulating this, the closed loop mechanism does not move correctly.

Do you have any guidance when dealing with the Articulation object and closed loop mechanisms? Is there any documentation on a robot with closed loops that works using the Articulation from isaac lab?

I use a very similar loop than the one shown here:
#1250

And this is more or less the basic Actuation I have:

ideal_explicit_actuators = {
    "motors": IdealPDActuatorCfg(
        joint_names_expr=[".*_motor"],
        stiffness=80.0,
        damping=2.0,
        armature=0.04,
    ),
    "passive": IdealPDActuatorCfg(
        joint_names_expr=[".*_joint"],
        stiffness=0.0,
        damping=0.0,
        armature=0.0,
     ),
}

The idea with this cfg is to have actuators and passive joints and the resulting behaviour should be according with the closed loop system too.

Thank you very much for your help.

Build Info

Describe the versions that you are currently using:

• Isaac Lab Version: 2.3.1
• Isaac Sim Version: 5.1

[jeferal]

From experimenting, I noticed that the closed loop behaviour is OK when creating the Articulation object, but NOT calling:

robot.write_data_to_sim()

When stepping.

[RandomOakForest]

Thank you for posting this. You have two separate but interacting issues here: (1) how PhysX/Isaac Sim handle closed loops (via “exclude from articulation”), and (2) what Articulation.write_data_to_sim() plus IdealPDActuatorCfg actually change in the simulation.

Here are a few things to consider (summary still under review).

1. Closed loops and “Exclude from Articulation”

Closed-loop chains in Isaac Sim/PhysX are supported by breaking the loop at one joint and marking that joint as “Exclude from Articulation,” so the physical constraint is kept but the articulation tree remains a tree.¹²

When you load the USD in the Isaac Sim GUI and just “apply forces to a body,” you are effectively using the PhysX joint configuration as authored in USD (including which joints are excluded from articulation), and you are not overwriting joint drive parameters from Isaac Lab code. That is why your closed-loop behavior looks correct in that mode.²¹

With Isaac Lab’s Articulation wrapper, as soon as you call write_data_to_sim(), you are pushing Lab’s internal buffers (joint states, drive targets, stiffness/damping, etc.) into the PhysX articulation. That can easily override whatever you set or tested in the GUI and can destabilize or constrain the “excluded” joints differently if your actuator config is not consistent with the USD.³⁴

So the fact that the loop behaves correctly when you do not call robot.write_data_to_sim() is a strong signal that something in the actuator configuration or in the write path is incompatible with the way the closed loop is modeled.

2. IdealPDActuatorCfg vs implicit actuators

The IdealPDActuator configuration is special: in current Isaac Lab it is essentially a thin wrapper that sets stiffness/damping directly into PhysX, and the articulation class does not do its own PD computation.⁵

The documentation notes for the PD actuator (Isaac Lab API) emphasize that for implicit actuators, stiffness and damping are set to the simulation directly; the class itself does not compute torques but keeps approximate torques for logging. This means: ⁵

• If you use IdealPDActuatorCfg as in your example, the “actuation” is really just PhysX joint drives with the given stiffness/damping and targets.
• For joints where you set stiffness = 0, damping = 0, you are effectively disabling any drive; the joint then behaves as a free joint with just the kinematic constraint (and mass/inertia/friction) coming from the USD.⁵

In a closed loop, if the excluded joint or its neighbors rely on a specific drive configuration (e.g., some spring or damping, or specific limits) and you overwrite that to (0, 0) or some default from Lab, the kinematic loop may become either too loose or too stiff and produce non-physical motion.

3. Why behavior changes when calling write_data_to_sim()

Isaac Lab’s Articulation has a clear separation between “set into buffers” and “write to PhysX”:

• robot.set_joint_*_target(...) updates Lab’s internal buffers only.
• robot.write_data_to_sim() pushes all buffered state (root pose, velocities, joint states, actuator parameters/targets) to the simulation.^{4 3}

For closed-loop systems, this implies:

1. When you do not call write_data_to_sim() each step, PhysX uses the joint drive parameters and constraints from the USD file. The articulation wrapper just reads state (robot.update(dt)), so your closed loop uses the same configuration as in the GUI test.
2. When you do call write_data_to_sim(), the articulation wrapper sets whatever is in robot.data plus what is defined by the actuator configs. That can overwrite:
   • joint stiffness/damping (drive gains),
   • drive targets (positions/velocities),
   • possibly some default joint state if you are resetting or writing joint state too often.³⁴

This explains why “closed loop behavior is OK when creating the Articulation object, but NOT calling robot.write_data_to_sim() when stepping”: your actuator config, or the way you use it, is not faithfully reproducing the USD’s joint drive setup for the loop.

4. Concrete guidance for your configuration

Here are specific steps to make your setup more robust:

1. Match USD joint drives for passive joints.
   Instead of forcing passive joints to stiffness=0, damping=0 in the actuator config, consider:
   • Use stiffness=None, damping=None for passive joints in the actuator config so the values from the USD joint prim are preserved.⁵
   • Or, explicitly set the same stiffness/damping as in the working USD (as seen in the GUI joint inspector).
2. Use implicit actuators or direct joint drives for motors.
   For closed-loop structures, it is often safer to:
   • Use an implicit PD actuator (or the default Isaac Lab actuator for that robot) so PhysX handles the PD directly with consistent gains. ⁵
   • Confirm that the actuator type is supported on all motor joints (no NaNs, etc.); see similar notes in related discussions about PD actuators misbehaving when gains are set inconsistently.⁶⁵
3. Ensure the excluded joint is truly “pure constraint”.
   The Isaac Sim closed-loop rigging docs recommend that the joint you exclude from articulation have no limits, no resistance, and no drive (or that you transfer those properties to an adjacent joint before excluding it).¹²
   • Verify in the USD that the excluded joint satisfies this (or adjust accordingly).
   • Then make sure your actuator configuration does not reintroduce stiffness/damping or drive targets on that excluded joint.
4. Write only what you need each step.
   Use the minimal set of write calls:
   • On reset: write_root_pose_to_sim, write_root_velocity_to_sim, write_joint_state_to_sim, then reset(). ³
   • On each step: only set target efforts/positions/velocities and then write_data_to_sim(), but avoid repeatedly overwriting joint states (positions) unless your control scheme requires it. Overwriting joint positions every step in a closed loop can fight the constraint solver.
5. Debug by temporarily removing actuator config.
   A useful sanity check:
   • Instantiate the Articulation but do not attach any actuator config (or use a purely “read-only” usage where you never call write_data_to_sim() except at reset).
   • Confirm that behavior matches the GUI.
   • Then gradually add back actuator configs:
     • First, only for the motor joints with modest stiffness/damping.
     • Keep passive joints using the USD’s own parameters (stiffness/damping = None in config).
       This helps you pinpoint which joint group’s configuration breaks the closed loop.

5. Examples / reference material

• The Isaac Sim docs have a detailed tutorial on rigging closed-loop structures, including which joints to exclude and how to reason about drive placement.²¹
• Isaac Lab’s articulation tutorial shows the correct pattern for resetting and stepping an Articulation with actuators, including when to call write_data_to_sim() and update(dt). ³
• The actuator API docs explain how stiffness/damping are pushed into the physics engine and highlight the difference between implicit actuators and the (more limited) ideal PD actuator wrapper. ⁵

Footnotes

1. https://docs.isaacsim.omniverse.nvidia.com/4.5.0/robot_setup/rig_closed_loop_structures.html ↩ ↩² ↩³ ↩⁴

2. https://docs.isaacsim.omniverse.nvidia.com/6.0.0/robot_setup_tutorials/rig_closed_loop_structures.html ↩ ↩² ↩³ ↩⁴

3. https://isaac-sim.github.io/IsaacLab/main/source/tutorials/01_assets/run_articulation.html ↩ ↩² ↩³ ↩⁴ ↩⁵

4. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.assets.html ↩ ↩² ↩³

5. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.actuators.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

6. https://github.com/isaac-sim/IsaacLab/issues/1568 ↩

[jeferal]

Hi. I really appreciate your detail explanation and references. Thank you very much for your help. I'll carefully try to solve this today and write back again with any other tip I encounter.

[jeferal]

Hi @RandomOakForest, thank you very much again for your guidance. Thanks to it I was able to implement a closed loop model of the robot that seems to behave correctly when using it as an Articulation Asset.

When importing it as an Articulation, I notice different behaviour of the closed loop mechanism when the actuators apply effort when loading the model with different values of solver_position_iteration_count and solver_velocity_iteration_count. For example:

articulation_props=sim_utils.ArticulationRootPropertiesCfg(
            enabled_self_collisions=False,
            solver_position_iteration_count=8,
            solver_velocity_iteration_count=4,
        ),

The behavour of the model seems better when using:

solver_position_iteration_count=64,
solver_velocity_iteration_count=32,

But I don't think it is feasable to train an RL algorithm with many environments in parallel with this higher iteration count. Do you have any guidance on tuning this count and if there is another parameter involved in how accurate or how "stiff" the excluded joint behaves?

[RandomOakForest]

Following up, I'll move this post to our Discussions section. In general, for RL with many parallel envs, you want the minimum settings that keep the mechanism stable and “good enough” instead of “perfect”.

A good workflow:

1. Lower timestep first
   • Reduce global physics timestep (e.g. go from 1/60 to 1/120 or 1/240) while keeping moderate iterations (e.g. 8–16 pos, 2–4 vel).
   • Smaller timesteps reduce constraint error and allow fewer iterations for similar effective stiffness.
2. Moderate iteration counts
   • Start from something like:
     • solver_position_iteration_count ≈ 8–16
     • solver_velocity_iteration_count ≈ 2–4
   • Increase position iterations gradually until the loop stops visibly “breathing” or drifting under load.
   • Only increase velocity iterations if you still see jitter or contact noise.
3. Balance timestep vs iterations for throughput
   • For a fixed target sim Hz (e.g. 60 or 120), benchmark a few combinations like:
     • 1/60 s, 16/4
     • 1/120 s, 8/2
     • 1/240 s, 4/1
   • Choose the one with acceptable stability and highest env-throughput on your GPU.