[Question] DifferentialIKController cannot reach the goal for the Booster T1 robot.

[InnaSviri]

Question

I am working on generating a synthetic dataset to control the T1 booster's hands. I would like to use GPU-oriented IK to integrate this data generation with RL training in joint space. For these purposes, I’m trying to use DifferentialIKController.

Similarly to DifferentialInverseKinematicsAction, I obtain the desired joints from ik_controller.compute at the simulation frequency and set the command to ik_controller at the policy frequency. I have sampled the end-effector gains, interpolating between the start and end points within the following ranges:
"x_start": (0.3, 0.35),
"y_start": (-0.3, 0.1),
"z_start": (-0.1, 0.1),
"roll_start": (0., 0.),
"pitch_start": (0., 0.),
"yaw_start": (0., 0.),
"x_end": (0.3, 0.35),
"y_end": (-0.3, 0.1),
"z_end": (-0.1, 0.1),
"roll_end": (0., 0.),
"pitch_end": (0., 0.),
"yaw_end": (0., 0.),

However, the decisions obtained from the ik_controller output are unreliable (see video). The pinocchio IK handles this ranges well.

The situation is slightly better with more limited sampling ranges, but it is still not good enough for training a policy on it (video).
"x_start": (0.2, 0.25),
"y_start": (-0.3, -0.1),
"z_start": (-0.1, 0.1),
"roll_start": (0., 0.),
"pitch_start": (0., 0.),
"yaw_start": (0., 0.),
"x_end": (0.2, 0.25),
"y_end": (-0.3, -0.1),
"z_end": (-0.1, 0.1),
"roll_end": (0., 0.),
"pitch_end": (0., 0.),
"yaw_end": (0., 0.),

Could someone give me an idea of how to solve this problem?

Thank you in advance!

Build Info

Describe the versions that you are currently using:

Isaac Lab Version: v2.2.1
Isaac Sim Version: 4.5

[RandomOakForest]

Thank you for posting this. Would it be possible for you to upgrade to Isaac Sim 5.1 and Isaac Lab v2.3.2?

[InnaSviri]

Thank you for your response! I have upgraded to Isaac Sim 5.1 and Isaac Lab v2.3.2, but the issue still persists - video

Perhaps you could suggest another way to generate a synthetic dataset for controlling the T1 booster's hands during joint space training?

[RandomOakForest]

Thank you for following up and upgrading your toolset. The behavior you’re seeing is almost always caused by a mismatch between how DifferentialIKController is configured/used and how you’re generating the task‑space commands and Jacobians, not by the workspace ranges themselves.¹²³

Below are the concrete things I would check and adjust. I'll move this post to our Discussions section for follow-up.

1. Command type and relative mode

DifferentialIKController can interpret the command either as an absolute pose or as a delta pose, and that must match how you build your trajectory.²¹

• If command_type="pose" and use_relative_mode=False, then:
  • command[..., :3] (if you use position‑only) should be the absolute desired EE position in the same frame as ee_pos passed into compute.
  • In that case, you should not be interpolating in “delta space” and feeding deltas; you should interpolate absolute poses and pass them directly.
• If command_type="pose_rel" and/or use_relative_mode=True, then:
  • The command must be a delta pose: $\Delta x, \Delta y, \Delta z$ (and rotation delta) over a controller time step.³
  • These deltas should scale with the controller timestep (e.g., per‑step increment of your Cartesian trajectory), not the full start→end displacement.

If you are:

• computing a full start→end displacement and directly giving it as the command every step, or
• providing absolute positions but configuring the controller for relative mode,

you will see exactly the kind of overshoot, oscillation or inconsistent solutions that make the output unusable for RL.

Actionable check

• Print/inspect:
  • diff_ik_cfg.command_type
  • diff_ik_cfg.use_relative_mode
• Make them consistent with how you build command:
  • For trajectory in absolute Cartesian: command_type="pose", use_relative_mode=False, command = x_interp(t) (no deltas).
  • For per‑step deltas: command_type="pose_rel", use_relative_mode=True, command = x_interp(t+dt) - x_interp(t).

2. Jacobian and frame consistency

DifferentialIKController assumes that:

• ee_pos and ee_quat are the current EE pose in some task frame (often world or base).¹
• jacobian is the geometric Jacobian mapping joint velocities to spatial twist in the same frame and convention as the pose.
• The order of the joints in jacobian[..., :, :] matches joint_pos exactly.

If any of these are off, the solver can behave badly even though Pinocchio IK works (Pinocchio may use a different reference frame and its own Jacobian building).

Key pitfalls to check:

• Are you using the EE Jacobian in the same frame as the pose you pass into compute (e.g., world frame vs base frame)?
• Does your Jacobian order match the joint DOF order used in the articulation?
• Are you accidentally passing a body Jacobian that’s not aligned with the same origin/orientation as ee_pos / ee_quat?

Minimal sanity test

At a fixed configuration:

1. Set command equal to the current pose (absolute mode) or zero delta (relative mode).
2. Run compute for several steps while holding the command constant.
3. The joint targets should converge to a fixed configuration with almost no drift.
   • If they drift or vibrate, you likely have a frame or scaling mismatch.

3. IK method and parameters (damping, gains)

DifferentialIKController supports several Jacobian inversion methods and parameters that affect stability and workspace behavior.⁴⁵³¹

• For manipulators working over a wide workspace, I strongly recommend:
  • ik_method="dls" with a moderate lambda_val (e.g. 1e-2 to 5e-2).
• If you use "pinv" or "svd" without damping, you can see wild swings near singularities or ill‑conditioned regions.
• There is also a scaling factor on the joint updates (k_val for some methods) which effectively acts like a Cartesian proportional gain; too large and you get overshoot/excitation.

Actionable configuration

For example:

from isaaclab.controllers import DifferentialIKController, DifferentialIKControllerCfg

diff_ik_cfg = DifferentialIKControllerCfg(
    command_type="pose",           # or "pose_rel"
    use_relative_mode=False,       # match how you form commands
    ik_method="dls",
    ik_params={"lambda_val": 0.02} # try 0.01–0.05
)
diff_ik = DifferentialIKController(
    cfg=diff_ik_cfg,
    num_envs=num_envs,
    device=sim.device
)

If you already use "dls", try increasing lambda_val and slightly reducing the magnitude of your per‑step delta pose.

4. Multi‑rate control: sim vs policy frequency

You mentioned:

compute at simulation frequency and set the command at policy frequency.

DifferentialIKController is a differential method; it expects that the relationship between command increments and integration steps is consistent.⁵³

Common failure mode:

• You compute joint targets each sim step assuming a small $\Delta x$, but only update the high‑level command at a slower policy frequency while using large deltas that effectively span multiple sim steps.

Best practice:

• Let the IK controller run at the same frequency as the pose trajectory.
• If policy runs at a lower rate, do one of:
  • Make the policy output a desired pose (absolute), and have a local interpolator (in task space) generate the per‑step command at the sim frequency before passing to DifferentialIKController.
  • Or, if output is a delta, ensure it is normalized per sim step (divide by number of sim steps per policy step) so that each sim step only sees a fraction of the movement.

Also confirm that you’re not repeatedly applying the same large delta at each sim step between policy updates.

5. Workspace and joint limits vs Pinocchio IK

Pinocchio IK (or PinkIKController) usually does:

• optimization with joint limit and sometimes posture regularization explicitly considered.⁵¹

DifferentialIKController by default:

• integrates joint updates without explicit optimization, relying on damping and possibly clipping to joint limits.

If your T1 booster hand is near joint limits or singular postures in the sampled regions:

• Pinocchio can “bend around” those constraints.
• Differential IK can hit limits, saturate, and produce poor trajectories.

Mitigations:

• Ensure joint limit clipping is enabled in your higher‑level control (clip joint_pos_target before sending).
• Slightly shrink the task‑space ranges away from singular zones or extreme extension.
• Increase damping (lambda_val) and potentially reduce per‑step Cartesian velocity.

6. Quick diagnostic experiment

To isolate the issue away from sampling ranges:

1. Pick a single start pose that Pinocchio IK can reach comfortably.
2. Use DifferentialIKController in absolute pose mode:
   • Command a static target pose in the center of your “good” workspace (e.g., x=0.22, y=−0.2, z=0.0).
3. Observe:
   • If it converges smoothly and holds position, your config is basically correct.
   • If it oscillates or fails, focus on:
     • Jacobian frame/order
     • ik_method="dls" and lambda_val
     • command_type / use_relative_mode consistency.

If this static test works but the interpolated trajectory fails, then the bug is almost certainly in:

• how you build the start/end interpolation vs. relative/absolute interpretation,
• or how you distribute trajectory updates across sim vs policy frequencies.

Footnotes

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

2. https://isaac-sim.github.io/IsaacLab/main/source/tutorials/05_controllers/run_diff_ik.html ↩ ↩²

3. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.controllers.html ↩ ↩² ↩³ ↩⁴

4. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.controllers.html#isaaclab.controllers.DifferentialIKControllerCfg ↩

5. https://arxiv.org/html/2511.04831v1 ↩ ↩² ↩³