Added support for xml file from mujoco

[boshi-an]

Support for mujoco XML

Introduction

In my own project, I wanted to use Pyroki as a retargeter, but it could not read mjcf files.

I tried to use mjcf2urdf, but the result is not satisfactory: MJCF and URDF have several fundamental differences. The most significant one is that MJCF allows joints and links to have different reference frames, while URDF assumes they are identical by nature.

So I implemented a MJCF reader for pyroki, and adjusted a little bit of the forward kinematics of the original Pyroki to support MJCF.

Changes

• Added support for basic XML files
• Support as links
• Support "hinge" and "slide" joints
• Support mimic joints

[boshi-an]

This change has modified the original forward_kinematics() to support situations that joints and links doesn't share the same frame in Mujoco XML. Changes are tested on my own project, more thourough tests should be considered before contributing to the main branch

[chungmin99]

Hi, this is cool / seems useful!

A quick question: is there a reason why you parse the XML file directly (i.e., instead of loading from a MjModel)?

For instance, did you run into problems with such an approach, or is this a stylistic choice? Personally I'd prefer if we load from a model, so that we can follow the same syntax / argument style as Robot.from_urdf(urdf: yourdfpy.URDF).

(Feel free to push back if this doesn't make sense, I'm not as familiar with mujoco ... 🥲)

[boshi-an]

Hi! I think it is very reasonable to use some parser first. But I don’t know anything better than mujoco itself or ETREE. Using a mujoco here seems a bit too big for this usage. If you know some library that loads mjcf and represents it in a more structured way, please comment here so I can integrate it.

Also when I use mjcf, I just load it into mujoco without a third-party library.

Anyway I will consider use the MjModel from mujoco and see if it will simplify the work

[louislelay]

Hello guys, @boshi-an and @chungmin99, has this feature been abandoned? Because I would be interested since my robot has closed-loop :)

[boshi-an]

@louislelay Hi! You may use this branch if you just want to load from xml files, the branch is tested on my own case and should work fine. The mujoco_model based loading is still not developed due to my availability limitations.

[louislelay]

Okay thank you, I'll give it a try !

[chungmin99]

Hi! You may use this branch if you just want to load from xml files, the branch is tested on my own case and should work fine.
Because I would be interested since my robot has closed-loop

Regarding these points: would it be sufficient to implement closed-loop kinematics chains via 1) parsing in the MJCF xml, then 2) enforcing the equality constraints in the optimization problem itself? Or does it need to be more complex e.g., virtually "cutting" the loop at one of the passive (unactuated) joints to break the cycle?

[louislelay]

Hello @chungmin99, for my use case option A is more than enough!

[boshi-an]

@louislelay From my experience, in order to use mujoco models, the best way is by using mjx and jaxls (https://github.com/brentyi/jaxls). Jaxls is the underlying optimizer of pyroki, also from the pyroki's authors. The reason that mjx+jaxls is better in the case of mujoco is that, mjx supports automated differentiation naturally, so that you can use mjx directly as the forward model, and by defining cost functions, jaxls will give you the solution seamlessly. In my own project of a 48-dof complex robot, this solution works very well.

I would also try to incorporate this solution to this pull request, instead of my hand-written forward model.