Choosing robot configuration parameters for Isaac Lab

[mobinajamali]

I have a custom robot URDF that I converted to USD and imported into Isaac Lab to train a policy for a specific task. One thing I’m unsure about is how to choose good configuration values for parameters such as action scale, effort limits, and velocity limits.
At the moment, I obtain these values through manual iteration and experimentation until the robot behaves reasonably and training becomes stable. I’d like to find a more principled or systematic way to determine these values.
Is there a recommended approach for selecting or deriving them? How do others typically handle this when working with custom robots in Isaac Lab?

[RandomOakForest]

Thank you for posting this. You can make this much more systematic by tying effort/velocity limits to your robot’s specs and then choosing action scales so that a normalized $[-1,1]$ action corresponds to “reasonable” fractions of those limits, with a simple test‑and‑tune loop.

Ground truth from the robot / USD

1. Start from physical specs, not RL:
   • Use joint torque/force limits from datasheets or controller config where possible; for revolute joints these are in Nm, for prismatic in N, and velocities in rad/s or m/s.¹
   • In Isaac Lab, if you leave effort_limit / velocity_limit as None in your actuator cfg, they inherit the USD joint values, which should match your URDF.²
2. Pick what the simulator enforces:
   • effort_limit_sim and velocity_limit_sim are the limits enforced by the physics solver; if left None, they are taken from the USD joint prims.²
   • For implicit actuators (the default Isaac Lab “PD‑style” motors), you typically set both limits to your desired physical caps, and the solver uses them as inequality constraints.³²
   • For explicit actuators (DC‑motor models), the actuator itself clips, so *_sim is often set very high to avoid double clipping.²

This gives you a consistent baseline: physical joint limits in USD → inherited by Isaac Lab → optional overrides via *_sim when you want to be stricter or looser.

Choosing velocity and effort limits

Once you have nominal “datasheet” numbers, treat them as an upper bound and shrink to what’s needed for the task and stable sim.

1. Start conservative relative to hardware:
   • For pure policy training, use something like 50–80% of physical max torque/velocity as effort_limit_sim / velocity_limit_sim to reduce extreme accelerations and contacts.
   • The velocity limit is the max the joint can reach given enough torque; if the torque is too low it will saturate earlier, so tune them together.²
2. Use joint‑level tests without RL:
   • Follow the Isaac Sim joint tuning procedure: set drives, apply step targets, and verify that the joint max velocity is within tolerance; if it overshoots, lower stiffness or torque limit.⁴⁵
   • Check that at maximum load your robot can still reach critical motions (e.g., swing a leg, lift an object), otherwise increase limits slightly.
3. Watch for pathological behavior:
   • If you see joints blasting through joint limits, flying apart, or very jerky motion, first reduce effort_limit_sim, then possibly velocity_limit_sim.⁶⁵
   • If motion is sluggish and the policy can’t accomplish even simple reaching, scale them up.

Rule of thumb: pick the smallest torque/velocity limits that still make the nominal task “comfortably doable” in a simple scripted controller.

Action scale selection

After limits are set, choose action scales so that $[-1,1]$ actions map to meaningful fractions of those limits, not directly to hardware extremes.

1. Define control mode per joint group:
   • Position control: policy outputs joint position deltas or absolute targets.
   • Velocity control: outputs desired joint velocity.
   • Effort control: outputs normalized torque/force.
2. Map normalized actions to physical ranges:
   • Effort mode: torque_cmd = action * alpha * effort_limit_sim, where alpha is something like 0.3–0.7 initially.
   • Velocity mode: vel_cmd = action * beta * velocity_limit_sim, with beta often 0.3–0.5 for locomotion/arms.
   • Position delta mode: q_delta = action * q_delta_max, where q_delta_max is a fraction (e.g., 5–10 degrees) of your joint range per control step.
3. Tune with a simple scripted policy:
   • Before RL, drive joints using sinusoidal or hand‑crafted actions at $|a| = 1$ and visually check: is motion too violent or too small?
   • The oft‑seen pattern is: start with alpha, beta around 0.3; if the robot barely moves, increase; if it flails or saturates contacts, decrease.

Conceptually: $[-1,1]$ should correspond to “full aggressive motion I’m willing to let the policy attempt,” not “maximum hardware rating.”

How people typically handle this in Isaac Lab

From practice in Isaac Lab and earlier Isaac Gym pipelines:

• They rely on URDF/robot specs for base limits, then override a bit for the task.
• They choose normalized actions and decouple policy scale (action scale) from physics limits:
  • Physics limits (*_sim) keep the simulation realistic and safe.³²
  • Action scales are picked for learning convenience and are usually < 1.0 of those limits.
• They do quick pre‑training checks:
  • Use tools like the Isaac Sim joint‑tuning workflow to calibrate drive gains and verify that the velocity limits and max forces behave as expected.⁵⁴
  • Then they run short RL experiments and monitor: percentage of time at action saturation, joint effort saturation, and instability; if saturation is frequent, they shrink the action scale; if the robot underperforms even with near‑saturated actions, they increase limits.

A concrete pattern for a custom manipulator would be:

• Import URDF → USD with proper torque and velocity limits.
• Set effort_limit_sim = 0.7 × datasheet torque, velocity_limit_sim = 0.7 × datasheet velocity.
• For velocity control, use action_scale = 0.4 * velocity_limit_sim; for effort control joints, action_scale = 0.3 * effort_limit_sim.
• Run a quick “follow a moving target” scripted task to verify smooth motion, then start RL and adjust these three global multipliers if learning is unstable or too slow.

Footnotes

1. https://github.com/isaac-sim/IsaacLab/issues/1636 ↩

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

3. https://arxiv.org/html/2511.04831v1 ↩ ↩²

4. https://docs.isaacsim.omniverse.nvidia.com/4.5.0/robot_setup/joint_tuning.html ↩ ↩²

5. https://docs.isaacsim.omniverse.nvidia.com/6.0.0/robot_setup_tutorials/joint_tuning.html ↩ ↩² ↩³

6. https://forums.developer.nvidia.com/t/simulation-disrespecting-joint-limits/284781 ↩