Drake MJCF Parser Features: Ignore Inertias from Meshfiles flag and Equality Constraints

[jeh15]

I am currently porting Agility Robotics Digit over to Drake for multibody simulation. Agility provides a MJCF description of Digit and currently Drake's MJCF parser is missing a few flags to move forward with the MJCF approach to port Digit into Drake.

There are three issues I am currently running into that make the MJCF parsing approach infeasible:

1. inertiafromgeom='false' is currently unsupported which causes a failure to parse assets intended for visual use only.
2. Digit contains closed kinematic chains and currently equality constraints are unsupported (relevant existing issue/feature request: https://github.com/RobotLocomotion/drake/issues/18803)
3. Mujoco and Drake result in different poses of the same MJCF.

If possible I would like to see support for the following:

1. I would like to see support for the inertiafromgeom flag to be able to parse visual only mesh files.
2. Being able to describe closed kinematic chains from within a descriptor format (MJCF, SDF, URDF) would be an immensely helpful convenience.
3. Currently, Drake seems to be parsing the MJCF differently than Mujoco and results in an unexpected pose of Digit.

Current Alternate Solution: To get around issues 1 and 3, I rewrote the MJCF to a URDF. My plan to get around issue 2 is to programmatically add SAP constraints.

Additional Context: I am unsure as to why the pose is getting messed up. I tried stripping away as many unsupported tags as possible to try to see if maybe one of them was causing an unexpected error but that does not seem to be the case. Attached are two pictures comparing the same MJCF xml (only containing collision geometries) being parsed by Mujoco and Drake.

Additionally, I am unable to share these assets publicly, but @EricCousineau-TRI has access to the private repository containing these assets.

[jwnimmer-tri]

BTW One debugging tip for the mis-postured robot might be to view the plant.GetTopologyGraphvizString() to check for any topology mistakes. More likely the problem is with some transforms' frames or the default positions, but ruling out bad topology would be a good start.

[rpoyner-tri]

FWIW, support for closed chains is discussed in issue #18803. I will add MJCF to the list.

[yu-fz]

One other thing is that the Agility mjcf model file for digit uses the default mujoco euler sequence (intrinsic xyz) for specifying frame rotations- in mujoco docs you can find that The “rpy” convention used in URDF corresponds to the default “xyz” in MJCF. However, I think that SDF/URDF actually uses extrinsic xyz rotations by default. I ran into this problem when I ported the digit mjcf model into an SDF model for drake a while ago, but iirc it didn't look that messed up.

[RussTedrake]

It's possible that #20414 will help. I've not yet investigated the kinematic constraints nor the euler rotation order.

[jeh15]

Using the nightly build (0.0.20231027) it still produces the model as posted above. I'll have some time this weekend to verify that rotation order is indeed the issue.

[jeh15]

I have only tried it on the left leg, but converting to an extrinsic rotation order produces the expected orientation. Thank you @yu-fz! I would have never caught this.

[RussTedrake]

Thanks for reporting this. I agree with @yu-fz. I believe the mujoco XML documentation is wrong here. cc @joemasterjohn , @yuvaltassa.

https://mujoco.readthedocs.io/en/latest/XMLreference.html#compiler

eulerseq: string, “xyz” This attribute specifies the sequence of Euler rotations for all euler attributes of elements that have spatial frames, as explained in Frame orientations. This must be a string with exactly 3 characters from the set {‘x’, ‘y’, ‘z’, ‘X’, ‘Y’, ‘Z’}. The character at position n determines the axis around which the n-th rotation is performed. Lower case denotes axes that rotate with the frame, while upper case denotes axes that remain fixed in the parent frame. The “rpy” convention used in URDF corresponds to the default “xyz” in MJCF.

But the rpy convention used in URDF corresponds to extrinsic x-y-z or "XYZ" in mujoco, not "xyz". I'll PR the fix to the Drake parser.

[yuvaltassa]

Thanks (again 🙂) for picking up on this!

Now fixed