Using Lula with a Closed-Loop Robot (Kawasaki BX200X) — Incorrect End-Effector Position in Lula Test Widget

Important: Isaac Sim support

Note: For Isaac Sim support, the community is gradually transitioning from this forum to the Isaac Sim GitHub repository so that questions and issues can be tracked, searched, and resolved more efficiently in one place. Whenever possible, please create a GitHub Discussion or Issue there instead of starting a new forum topic.

Note: For any Isaac Lab topics, please submit your topic to its GitHub repo ( GitHub - isaac-sim/IsaacLab: Unified framework for robot learning built on NVIDIA Isaac Sim · GitHub ) following the instructions provided on Isaac Lab’s Contributing Guidelines ( Contribution Guidelines — Isaac Lab Documentation ).

Please provide all relevant details below before submitting your post. This will help the community provide more accurate and timely assistance. After submitting, you can check the appropriate boxes. Remember, you can always edit your post later to include additional information if needed.

6.0.0
5.1.0
5.0.0
4.5.0
4.2.0
4.1.0
4.0.0
4.5.0
2023.1.1
2023.1.0-hotfix.1
Other (please specify):

Operating System

Ubuntu 24.04
Ubuntu 22.04
Ubuntu 20.04
Windows 11
Windows 10
Other (please specify):

GPU Information

  • Model: RTX A4000
  • Driver Version: 573.06

Topic Description

Using Lula with a Closed-Loop Robot (Kawasaki BX200X) — Incorrect End-Effector Position in Lula Test Widget

Detailed Description

I am trying to use Lula to control a Kawasaki BX200X robot (6-DOF: J1–J6) so that the end-effector follows a target pose.

The BX200X has a closed-loop (parallel linkage) mechanism between J2 and J3, as illustrated in the figure below. This 4-bar closed-loop linkage is mechanically coupled.

To handle this closed-loop structure within Lula’s framework, I have adopted the following approach:

  • One joint in the 4-bar closed-loop is omitted entirely from the kinematic chain (treated as a passive/fixed link).

  • Two joints are defined as mimic joints to replicate the mechanical coupling.

  • In the Lula Robot Description Editor, the mimic joints are set to fixed.

  • In the URDF, those same joints are defined using the <mimic> tag.

However, when I run the Lula Test Widget after this configuration, the end-effector coordinate is displayed at an incorrect/unexpected location.

Steps to Reproduce

    1. Prepare the URDF for the Kawasaki BX200X, modeling the closed-loop linkage between J2 and J3 as follows:
      • Omit one passive joint from the 4-bar linkage.

      • Define two joints as mimic joints using the <mimic> tag in URDF.

    2. Import the URDF into Isaac Sim.
    3. Open the Lula Robot Description Editor.
    4. Set the mimic joints to fixed in the Lula Robot Description Editor.
    5. Save the Lula robot description file (YAML/XRDF).
    6. Open the Lula Test Widget and load the robot.
    7. Observe the end-effector position — it appears at an incorrect location in the scene.

Error Messages

  1. What is the recommended workflow in Isaac Sim / Lula for robots with closed-loop (parallel linkage) kinematics?

  2. Should the mimic joints be handled differently in the Lula Robot Description Editor (e.g., not set to fixed, but handled via the URDF <mimic> tag only)?

  3. Is there a known limitation in Lula regarding closed-loop kinematic chains, and if so, what is the recommended workaround?

  4. Are there any reference examples or documentation for configuring parallel linkage robots (similar to 4-bar mechanisms) with Lula?

Any guidance or example configurations would be greatly appreciated. Thank you!

Screenshots or Videos

(If applicable, add screenshots or links to videos that demonstrate the issue)

Additional Information

What I’ve Tried

(Describe any troubleshooting steps you’ve already taken)

Related Issues

(If you’re aware of any related issues or forum posts, please link them here)

Additional Context

(Add any other context about the problem here)

Hi @deokrak1004,

This is a known limitation of Lula — it only supports open-chain (serial/tree) kinematics. It does not interpret URDF joint tags, and the cspace_to_urdf_rules fixed rule locks a joint to a constant value rather than dynamically coupling it to another joint.

When you set the mimic joints to fixed in the Lula Robot Description Editor, Lula computes FK using those constant values regardless of where J2 actually is — which is why the end-effector shows up at the wrong location.

This was confirmed by an NVIDIA engineer in a similar thread: Inverse Kinematics Problem of Parallel Mechanisms (Inverse Kinematics Problem of Parallel Mechanisms)

Workarounds:

  1. Use PhysX articulation directly for FK/IK — PhysX handles mimic joints at the simulation level. If your goal is end-effector tracking and control (rather than Lula-based motion planning), you can query the articulation’s FK directly via ArticulationKinematicsSolver.
  2. Write a custom IK wrapper — Compute the mimic joint values yourself (q_mimic = multiplier × q_parent + offset), inject them into the full joint state, and feed that to Lula. This won’t fix Lula’s internal IK, but it would correct the FK display.
  3. Build a custom IK solver — You can implement your own and either extend the KinematicsSolver interface or use it directly to set joint position targets on the articulation.

Native support for mimic joints / closed-loop kinematics in Lula would be a feature request — I’d encourage filing one on the Isaac Sim GitHub (Sign in to GitHub · GitHub) so it can be tracked.

Hi @deokrak1004,

Closing this out since we haven’t heard back. To recap: Lula only supports open-chain (serial/tree) kinematics and does not dynamically couple mic joints — it locks them to constant values via
cspace_to_urdf_rules. The workarounds are to use PhysX articulation directly for FK/IK, write a custom wrapper that injects computed mimic joint values, or build a custom IK solver.

If you’d like any follow-up discussion, please file a discussion or issue on the Isaac Sim GitHub repository. Going forward, that’s
also the best place to open new questions or issues — the community is transitioning from this forum to GitHub so everything can be tracked and searched in one place.