[Question] ImplicitActuators not recommended but used extensively in examples

[Nate711]

The docs say not to use ImplicitActuators directly https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.actuators.html#implicit-actuator but many of the example robots use them anyways https://github.com/isaac-sim/IsaacLab/blob/main/source/isaaclab_assets/isaaclab_assets/robots/unitree.py because, as I've verified myself, damping values over 0.5 with typical timesteps of 0.004s cause huge instabilities.

I think the docs or code should be updated since it's impractical to use basically any of the derived explicit actuator classes like DelayedPDActuator since they are unstable for larger motors which require higher damping coefficients.

[RandomOakForest]

Thank you for posting this. The team will review. I'll tag this as an improvement proposal.

[georgwi]

I had a similar issue when switching from the implicit model to the explicit one for a damping value of 5.0 and armature of 0.0. The simulation became unstable for damping gains over 0.5 just as @Nate711 described.

However, I found that a small armature value helps stabilizing the simulation when using explicit actuators. I was able to keep my original damping value of 5.0 with an armature of 0.01. Looking at the documentation for armature it mentions something along those lines as well.

[YuHoChau]

I had a similar issue when switching from the implicit model to the explicit one for a damping value of 5.0 and armature of 0.0. The simulation became unstable for damping gains over 0.5 just as @Nate711 described.

However, I found that a small armature value helps stabilizing the simulation when using explicit actuators. I was able to keep my original damping value of 5.0 with an armature of 0.01. Looking at the documentation for armature it mentions something along those lines as well.

I encountered a similar issue. For example, when I tried to test the IK controller
with a different robot, the implicit model worked very well, but switching to the DC configuration caused significant shaking. Why does the official demo still use the implicit motor configuration, and how can this issue be resolved?

[T-K-233]

The docs say not to use ImplicitActuators directly

Are you referring to this line in the doc:

I think this line is only suggesting that the class attributes like effort_limit, velocity_limit etc are not effective in this class, and is only kept for consistency with the explicit models. The PD computation logic is handled in the physics simulator, hence "does not implement any functionality" in this Python class.

I don't think this notice is telling us to not use this actuator config. In fact, I find this implicit actuator behaves much better and more stable than the explicit ones. I suspect this is also the reason why so many provided examples are using this config.

[AntoineRichard]

@Nate711 thanks for pushing on this — the docstring really did tell people not to use a class we use everywhere.

That wording is gone. ImplicitActuator's docstring was rewritten in #6839 (merged) and now explains that the backend solver applies the joint drive while the class computes approximate effort telemetry, so its use in the example robots is intended. For the explicit-actuator instability at high damping, adding a small armature (as @georgwi suggested) is the recommended fix. If that still bites you on Newton, please open a focused issue.

---

🤖 This issue was reviewed as part of an AI-assisted triage of the Isaac Lab backlog, with automated verification against the current codebase. If we got this wrong, please reopen — we'd rather hear about it!