Modeling gearbox backlash / mechanical joint play in IssacSim — Best practice?

[robopara]

We're developing a small biped robot using CubeMars AK-series geared actuators
(~10:1 reduction) and are trying to model realistic mechanical play in the
joints for Sim-to-Real RL training. We're interested in two related but
distinct sources of play:

1. Internal gearbox backlash (clearance between meshing gear teeth)
2. Play at a rigid mechanical coupling (e.g. a bolted/splined output shaft-to-
   horn connection with a small amount of slop) — in our own hardware testing,
   this turned out to be the dominant source, larger than the gearbox backlash
   itself

Both show up as the same kind of behavior: a small dead-zone where the driven
side can move slightly without the output side responding.

We found an older unanswered forum thread on the same topic (Simulating joint
/ servo backlash,
2024) and wanted to ask again with more specifics here, since this seems like
a common need for anyone working with geared actuators or bolted/keyed
mechanical joints in general.

We went through the available joint APIs and couldn't find a play / dead-zone
parameter anywhere:

• None of PxFixedJoint / PxSphericalJoint / PxRevoluteJoint /
  PxPrismaticJoint / PxDistanceJoint / PxD6Joint expose anything like it
• PxGearJoint / PxRackAndPinionJoint (the gear-mesh-specific joints) don't
  have one either
• PxArticulationJointReducedCoordinate (used by Isaac Lab's Articulation-
  based robots) doesn't have one either — checked the full member list (limit
  params, drive params, armature, friction coefficient, etc.)

Since PhysX/USD Physics joints always connect exactly two rigid bodies (or a
body and world), our current plan is to add an explicit, near-massless
intermediate link between the driven (actuated) joint and a limited, undriven
"play" joint, to represent this as a small extra DOF — regardless of whether
the play originates in the gearbox or in a mechanical coupling further down
the chain.

Questions:

1. Is there an official/recommended way to represent this kind of joint play
   (gearbox backlash or mechanical coupling slop) in Isaac Sim / PhysX that
   we're missing?
2. Is the "intermediate link + limited passive joint" approach the intended
   workaround, or is there a known issue with it (e.g. solver stability with a
   very low-mass link)?
3. Is native support for this on any roadmap?

Environment: Isaac Sim 5.1.0, Ubuntu 24.04, RTX 5080

Happy to share more details about our setup if useful. Thanks in advance!

[PeterL-NV]

You're correct that PhysX joints don't currently expose a native backlash or dead-zone parameter.

Your approach of using an intermediate near-massless link with a limited passive joint is a physically reasonable workaround for modeling this type of mechanical play. Here are some key considerations:

1. Stability Tips:

• Keep the intermediate link mass very low (e.g., 0.001 kg) but not zero
• Use appropriate solver iteration counts for stability
• Consider adding a small amount of joint damping to prevent oscillations
• Set the joint limits carefully to represent your measured backlash range

2. Implementation Structure:
   Parent Body → Driven Joint (actuated) → Intermediate Link → Play Joint (limited, passive) → Output Body

3. Joint Configuration:

• The play joint should have tight limits (e.g., ±0.5° to ±2° for typical gearbox backlash)
• Add light spring/damper properties to simulate the "clunk" behavior when transitioning through the dead zone
• The driven joint carries your main actuator control

Notes:

• Very low-mass links can sometimes cause solver instability at high simulation speeds - monitor for jittering
• The approach adds computational overhead (extra bodies/constraints)

Native backlash support would be a valuable feature request for the PhysX team, we will discussion this with them to see if this can be natively supported.

[robopara]

Thank you for the detailed breakdown — this confirms our own investigation (we checked all joint types and PxArticulationJointReducedCoordinate's full API surface and found no native backlash/dead-zone parameter).

One follow-up question: you noted that very low-mass intermediate links can cause solver instability at high simulation speeds. Given that risk, is there a way to model backlash/mechanical play without adding an extra rigid body/DOF to the articulation?

Specifically, backlash is fundamentally a hysteresis (history-dependent) nonlinearity — the output "sticks" for a fixed play range whenever the input reverses direction, rather than tracking the input 1:1. We already use Isaac Lab's NoiseModelWithAdditiveBiasCfg elsewhere in our pipeline, and a slowly-varying additive bias could crudely approximate the steady-state positional offset that play introduces in a given direction of motion — so it may offer some partial robustness benefit. But it can't reproduce the direction-reversal "stick" itself, since it has no memory of motion direction or how much of the play range has been taken up.

We're considering instead implementing backlash as a stateful transform applied to the command signal or the reported joint position/velocity (similar in spirit to how we already use a custom DelayedPDActuatorCfg for actuator delay), rather than as an added physical constraint.

Is there a recommended pattern in Isaac Lab/PhysX for this kind of stateful, non-physical (command/observation-level) nonlinearity — e.g. via a custom Actuator class, or a custom NoiseModel with internal state — or would that fall outside what either framework is designed to support?

[PeterL-NV]

You're absolutely right that backlash is fundamentally a history-dependent nonlinearity, and modeling it at the command/observation level is a much more practical approach than adding extra bodies for many use cases.
Isaac Lab's actuator framework is specifically designed for this type of stateful, command-level transformation.
The DelayedPDActuatorCfg you mentioned is a good reference - you'd follow a similar pattern.

1. Custom Actuator Approach:

• Extend ActuatorBase or one of the existing actuator models (e.g., ImplicitActuator, DCMotor)

• Maintain internal state to track:

  • Last command direction
  • Current position within the backlash range
  • Whether the backlash has been "taken up" in the current direction

• Apply the hysteresis logic in the compute() method before passing commands to the simulation

2. Key Implementation Details:class BacklashActuator(ActuatorBase):

    def __init__(self, cfg, ...):
        super().__init__(cfg, ...)
        # State tracking
        self._last_direction = torch.zeros(...)
        self._backlash_offset = torch.zeros(...)
        self._backlash_range = cfg.backlash_range  # e.g., ±0.02 rad

    def compute(self, control_action, joint_pos, joint_vel, ...):
        # Detect direction reversals
        direction = torch.sign(control_action - joint_pos)
        direction_changed = (direction != self._last_direction)

        # Apply hysteresis: when direction reverses, command "sticks"
        # until the play range is taken up
        effective_command = control_action.clone()
        effective_command[direction_changed] -= (
            self._backlash_offset[direction_changed]
        )

        # Update state
        self._last_direction = direction

        # Pass to underlying actuator model
        return super().compute(effective_command, joint_pos, joint_vel, ...)

3. Alternative: Observation-Level Transformation

• For observation-side modeling, you could create a custom ObservationNoise class that applies backlash-like transformations to reported joint positions
• This is simpler but less physically accurate since it doesn't affect the actual control loop

from omni.isaac.lab.utils.noise import NoiseCfg, NoiseModel

class BacklashNoiseCfg(NoiseCfg):
    """Backlash as observation noise."""
    class_type: type = BacklashNoiseModel
    backlash_range: float = 0.02

class BacklashNoiseModel(NoiseModel):
    """History-dependent position offset in observations."""
    
    # Similar state tracking as actuator version
    # Applied to joint_pos observations