Feature: merge a fixed joint's child link to the parent

[scpeters]

Desired behavior

By default, parser_urdf.cc currently merges links connected by fixed joints, lumping the inertia together and moving collisions, visuals, and sensors from parent to child and updating poses (also referred to as fixed-joint reduction). During this process, the original child link frame location is lost; though it would be possible to add a //frame to memorialize it.

This is a useful feature, so I would propose adding it to the SDFormat specification. This would also greatly simplify the code in parser_urdf.cc that currently implements this functionality.

Alternatives considered

• Status quo: keep it only as a feature of the URDF parser.

Implementation suggestion

Add data to a //joint/fixed tag to enable and configure this behavior:

• //joint/fixed/merge_child_to_parent/@enabled: boolean
• //joint/fixed/merge_child_to_parent/@discard_child_inertia: boolean

Additional context

[scpeters]

though it would be possible to add a //frame to memorialize it.

I have a prototype for adding these //frame tags in branch scpeters/debug_urdf_frame_13

[azeey]

I have a fundamental question about joint reduction. As far as I know, it was added as an optimization for physics engines that use maximal coordinates. As such, shouldn't the feature be an implementation detail in the physics engine? Why should SDFormat be involved in any of it?

[scpeters]

though it would be possible to add a //frame to memorialize it.

I have a prototype for adding these //frame tags in branch scpeters/debug_urdf_frame_13

//frame tags are now added to memorialize each link and joint that are lost when reducing fixed joints (#1148, #1182)

[scpeters]

I have a fundamental question about joint reduction. As far as I know, it was added as an optimization for physics engines that use maximal coordinates. As such, shouldn't the feature be an implementation detail in the physics engine? Why should SDFormat be involved in any of it?

The best argument I can make is to improve consistency between how SDFormat and URDF files are parsed since this feature only applies to URDF files and can be confusing to users. Outside of historical reasons and consistency, I don't have a principled argument for why this should be part of libsdformat and not a physics engine detail

[azeey]

I would argue that the change should be made in our URDF parser to make it more consistent with SDFormat. From my experience, joint reduction causes confusion, especially for new users, and it's currently done in a way that doesn't hide this optimization/implementation detail from the users (eg. Gazebo UI will not show the original joint and lumped links, saved models will have lost the original content, etc.).