NaN Velocity Explosion with ArticulationRootAPI in high-DOF tethered setup

Omniverse Isaac Sim
1

Important: Isaac Sim support

Note: For Isaac Sim support, the community is gradually transitioning from this forum to the Isaac Sim GitHub repository so that questions and issues can be tracked, searched, and resolved more efficiently in one place. Whenever possible, please create a GitHub Discussion or Issue there instead of starting a new forum topic.

Note: For any Isaac Lab topics, please submit your topic to its GitHub repo ( GitHub - isaac-sim/IsaacLab: Unified framework for robot learning built on NVIDIA Isaac Sim · GitHub ) following the instructions provided on Isaac Lab’s Contributing Guidelines ( Contribution Guidelines — Isaac Lab Documentation ).

Please provide all relevant details below before submitting your post. This will help the community provide more accurate and timely assistance. After submitting, you can check the appropriate boxes. Remember, you can always edit your post later to include additional information if needed.

6.0.0
5.1.0
5.0.0
4.5.0
4.2.0
4.1.0
4.0.0
4.5.0
2023.1.1
2023.1.0-hotfix.1
Other (please specify):

Operating System

Ubuntu 24.04
Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):

GPU Information

  • Model:
  • Driver Version:

Topic Description

NaN Velocity Explosion with ArticulationRootAPI in high-DOF tethered setup (4 Drones + Payload)

Detailed Description

I am developing a multi-agent RL environment in Isaac Sim for a cargo stabilization task. The setup consists of 4 multirotor drones carrying a payload via flexible cables. To simulate the cables, I am using chains of rigid bodies (Capsules) connected by D6 joints (24 links per cable). The entire group is wrapped in a single ArticulationRootAPI tree.

When the simulation runs and the drones pull the cables taut, I expect the constraint solver to hold the payload, but Instead, the physics solver suffers a catastrophic numerical explosion. The joint velocities multiply exponentially frame-over-frame until they hit Nan and instantly crash the physics and it allways crashes on the same joint and link which are the first ones connected right to the drone. Interestingly, if I replace the highly flexible 24-link cables with a single rigid bar, the simulation is perfectly stable.

Steps to Reproduce

  1. Spawn 4 multirotor drones and 1 central payload in Isaac Sim.
  2. Connect each drone to the payload using a 24-link chain of rigid capsules connected by D6 joints (to act as a highly flexible tether).
  3. Wrap the entire hierarchy (drones, cables, payload) in a single ArticulationRootAPI
  4. Apply thrust to the drones so they pull away from the payload, causing the cables to go taut.
  5. Monitor the joint velocities in the physics step logs.

Error Messages

No standard crash log, but the step logs show joint velocities exploding to Nan. Here is a capture of the progression across consecutive frames before the physics engine breaks on the first joint[0] connected to the drone:

  • Max Joint Vel: 1413.81

  • Max Joint Vel: 83807.44

  • Max Joint Vel: 371043840.00

  • Max Joint Vel: 969736219426415948603034959872.00

  • Max Joint Vel: NaN

Screenshots or Videos

(If applicable, add screenshots or links to videos that demonstrate the issue)

Additional Information

What I’ve Tried

I have already tried standard rigid-body debugging techniques without success:

  • Mass Ratios: Increased the mass of the individual cable links to ensure the mass ratio between the drones around a exagerated value (1kg).

  • Solver Iterations: Increased the solver velocity and position iteration count on the rigid bodies up to 32 and 64.

  • Linear Elasticity (Shock Absorbers): To prevent infinite constraint impulses when the cable snaps taut, I slightly unlocked the linear limit of the D6 joints and added a spring drive to act as a shock absorber.

Despite these changes, the system still eventually resonates or explodes into Nan values.

Additional Context

I get this warning meaning that the ArticulationRootAPI does not let me have elastic/stretchy cables but i need to be 100% that this is true and that there is no workaround by still having the ArticulationRootAPI → 2026-04-11T20:26:35Z [10,106ms] [Warning] [omni.physx.plugin] Translation DOF is expected to be locked for D6 joint in articulation hierarchy, the resulting joint in articulation will have all translation DOF locked.

3

Hi, The numerical explosion occurs because:

  1. Chain Length: 24 links per cable creates a very stiff system - errors compound exponentially through the chain
  2. Constraint Coupling: With 4 cables (96 total links) in a single articulation tree, the solver must solve a massive coupled system simultaneously
  3. High Forces: When drones pull cables taut, large constraint forces propagate through joints
  4. First Link Failure: The joint connecting to the drone experiences the highest forces and velocities, causing it to fail first when solver precision breaks down.

Here’re some suggestions:

  1. Use PhysX spatial tendons instead of D6 joint chains. Tendons are specifically designed for cable/rope simulation and are much more stable:
# Example tendon setup (pseudo-code)
articulation_root = UsdPhysics.ArticulationRootAPI.Apply(root_prim)
tendon_api = PhysxSchema.PhysxTendonAxisRootAPI.Apply(articulation_root)

# Configure tendon attachment points
# Attach to drone and payload
# Set stiffness and damping properties
  1. If you must use joint chains, considering reducing chain complexity or separating Articulation Trees
    Instead of one massive articulation:
# Create separate artic_ulation for each cable
for cable_idx in range(4):
    cable_root = stage.DefinePrim(f"/World/Cable_{cable_idx}", "Xform")
    UsdPhysics.ArticulationRootAPI.Apply(cable_root)
    # Build this cable's chain under its own root
5

Thank you very much for your help and advice, however, I ran into a major limitation when trying to use Spatial Tendons for my specific setup.

From what I found, Spatial Tendons require all connected bodies to belong to the same articulation tree. To get around this, I actually tried adding a dummy D6 joint to connect the payload and the independent drones into a single tree so the tendons would initialize, but the problem is that this solver constrains the translational degrees of freedom between the links to maintain the articulation structure, and since my drones are independent, free-flying vehicles, placing them in the same articulation tree as the payload effectively restricts their independent 6DOF motion, and as a result, they can no longer move freely as separate flying bodies. So I’m somewhat stuck at the moment, where to use tendons, everything needs to be part of the same articulation tree, but once they are in the same tree, the tendons constrain the translational movement of my drones, which is essential for accurately simulating a system of four drones carrying a payload.

Do you have any advice on how I should proceed with tendons, or do you think they are not a viable option for my system?

6

Hi, it’s a limitation in PhysX, Spatial Tendons require all connected bodies (links) to belong to the same articulation tree. For your tethered drone system, seems using separate articulation trees is a viable solution. Consider reducing link count (24 is very high - try 8-12 links per cable) and using D6 joints with higher stiffness/damping values.

7

Hi, We noticed that this topic hasn’t received any recent responses, so we are closing it for now to help keep the forum organized.

If you’re still experiencing this issue or have additional questions, please feel free to create a new topic with updated details. When doing so, we recommend mentioning or linking to this original topic in your new post—this helps provide context and makes it easier for others to assist you.

Thank you for being part of the NVIDIA Isaac Sim community.

Best regards,
The NVIDIA Isaac Sim Forum Team