[Question] A compute torque function is different between a isaaclab and a legged_gym

[CAI23sbP]

I'm curious about the compute_torque implementation in IsaacLab.

In legged_gym, torque computation is typically based only on position error (i.e., proportional control).
But in IsaacLab, the torque computation includes both a feed-forward term (from the policy) and a velocity error term (i.e., damping).

Why are these additional terms included in IsaacLab’s implementation?
Is it due to differences in simulation fidelity, control architecture, or reinforcement learning stability?

---

In IsaacLab

        self.computed_effort = self.stiffness * error_pos + self.damping * error_vel + control_action.joint_efforts

In legged_gym

         torques = self.p_gains*(actions_scaled + self.default_dof_pos - self.dof_pos) - self.d_gains*self.dof_vel

[RandomOakForest]

Thank you for posting this. I'll move this post to our Discussions. The differences you’ve observed between IsaacLab’s and legged_gym’s torque computation stem mainly from IsaacLab’s emphasis on physical realism, versatility of control strategies, and sim-to-real transfer. Here’s a detailed breakdown:

1. Explicit Actuator Models and Physical Realism

IsaacLab provides two main actuator paradigms: implicit (where the simulator’s internal PD controller is used) and explicit (where torque is computed by user-provided models). In the explicit case—such as in actuator_pd.py—the control law is:

$$\text{computed\_effort} = \text{stiffness} \times \text{error}_{pos} + \text{damping} \times \text{error}_{vel} + \text{control\_action.joint\_efforts}$$

This formula includes both a feed-forward (policy-provided torque) and a velocity error (damping) term¹².

Why Add Feed-forward and Damping?

• Feed-forward Term (control_action.joint_efforts):
  • Lets the RL agent (or MPC, or other higher-level controller) provide torques directly. This is crucial for more expressive policies, improved tracking of non-trivial reference trajectories, and more accurate simulation of real actuator dynamics—where you often combine low-level stabilization with higher-level learned or computed torques.
  • Especially important in sim-to-real transfer, as real robots frequently use a combination of model-based control (feed-forward) and feedback laws, not just pure PD¹.
• Velocity Error (Damping):
  • Adds essential damping for stability, mimicking real actuator effects and compensating for unmodeled friction or actuator lag. It helps stabilize control even when the policy’s torque output is noisy or when trajectory following needs energy dissipation on sudden changes¹.

2. Control Architecture and RL Stability

• The inclusion of both terms enables separation of responsibilities between policy (feed-forward, task-specific control) and the low-level joint stabilization (stiffness and damping), resulting in improved RL training stability and more realistic simulation of robot control stacks. This is especially important because direct torque outputs from learned policies can be unstable in high-frequency physics simulation unless stabilized by auxiliary feedback¹.
• This mirrors standard practice in robotics, where you would combine a feed-forward control term (such as gravity or model compensation) with a stabilizing PD (or even full PID) loop¹³.

3. Simulation Fidelity and Sim-to-Real Transfer

• The main reason for this richer control law is to close the “sim-to-real” gap. If simulation acts more like hardware, with both feedback and policy-generated torques, then trained policies are far more likely to work on a real robot out-of-the-box¹⁴.

4. Comparison with legged_gym

legged_gym typically assumes a much simpler mapping from policy actions to desired joint positions and applies only proportional and derivative (PD) terms, without a feed-forward torque. This is often sufficient for simulation benchmarking and development, but it lacks the direct expressiveness and fidelity needed for real hardware deployment or highly dynamic tasks that benefit from explicit torque control.

In summary:
IsaacLab’s actuator implementation is designed for realistic sim-to-real deployment, robustness, and flexibility. The additional feed-forward and damping terms make control architectures more expressive, facilitate stable RL training, allow compatibility with real robot control schemes, and help bridge simulation with physical hardware by accurately mimicking the blend of feedback and model-based control used in real robots¹².

Footnotes

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

2. https://isaac-sim.github.io/IsaacLab/main/source/overview/core-concepts/actuators.html ↩ ↩²

3. https://www.instructables.com/PID-Feedforward-for-Precise-Trajectory-Following/ ↩

4. https://developer.nvidia.com/blog/closing-the-sim-to-real-gap-training-spot-quadruped-locomotion-with-nvidia-isaac-lab/ ↩

[CAI23sbP]

@RandomOakForest Thank you for your response — it was very helpful in understanding the differences.

I have a follow-up question that's closely related to the original topic.

In unitree.py, the "UNITREE_GO2_CFG" defines a single effort_limit value, whereas in the official references, effort_limit is defined per joint with varying values.

You mentioned that IsaacLab is designed for realistic sim-to-real deployment, robustness, and flexibility. Given that, I'm wondering why the effort_limit values in IsaacLab don’t seem to closely match the more detailed reference specifications.

[RandomOakForest]

I've placed your question in our Discussions for follow up. See #3056. Thank you for your interest in Isaac Lab.