search

RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.35k stars 1.27k forks source link

Parsing the SDFormat inertia auto=true attribute #21101

Open jwnimmer-tri opened 8 months ago

jwnimmer-tri commented 8 months ago

Is your feature request related to a problem? Please describe.

There are situations like https://github.com/RobotLocomotion/drake/issues/20730 where users run an asset conversion tool to produce an SDFormat file. The tool emits redundant information (scaled geometry scale + density-based inertia). Later if the user decides the geometry scale is wrong, they might adjust that piece but forget to adjust the inertia.

Or even without such a conversion tool in play, it's onerous to have to type in the inertia just to get up and running with something sensible. We have fix_inertia that can help automate the process, but it still means dealing with manual file reprocessing and remembering to re-run the fixer any time you change the geometry.

Describe the solution you'd like

Implement the standardized attribute <inertial auto="true"> so that inertia will be automatically calculated, instead of making the user type in numbers that they might have trouble describing correctly.

Describe alternatives you've considered

Tell users to write MJCF files instead of SDFormat files. MJCF has better defaults, so the user doesn't need to opt-in to the auto=true logic.

Additional context

There is a whole discussion about mesh calculation methods in the SDFormat specification. Someone should study it more carefully, but at first glance my reaction is that we should just use the same logic we already have for fix_inertia and direct-*.obj parsing.

Once we have this feature ready, we should probably upgrade mesh_to_model to use it. That way, it will be much safer for users to hand-edit the file afterwards.

jwnimmer-tri commented 8 months ago

Possibly we would want to help finish out the https://github.com/gazebosim/sdformat/issues/1482 enhancement, too. It is probably an important usability win.

In the meantime, probably mesh_to_model can work around it by converting the user-provided mass into volume-influenced density, and only put the density in the file. That's still redundant in a sense, but the specific redundancy feels to me somewhat less dangerous than the status quo. If they see a density of 1e-9 they will hopefully quickly correlate that with why their mug is flying around like a grain of sand.