Drake: Compute UnitInertia from Volume and Surface meshes

[SeanCurtis-TRI]

Given the ubiquitous assumption of uniform density, there is no reason we shouldn't be able to compute the unit inertia for an arbitrary volume mesh and use that in dynamics.

[SeanCurtis-TRI]

cc @amcastro-tri

[jwnimmer-tri]

It would be neat to have this algorithm in master! For now, I use meshlab to compute the inertia matrix and then drake/manipulation/util/meshlab_to_sdf.py to convert it to *.sdf's XML format and commit the *.sdf file. Evicting meshlab from the picture would make it even smoother. I don't even need the runtime to do it automatically for me, I just need an obj,mass -> inertia subroutine.

[SeanCurtis-TRI]

Well, we're a ways a way from obj -> volume mesh. We're currently not doing tetrahedralizations on arbitrary meshes -- that'll be a step in the future to directly enable "soft" meshes (a currently unscheduled step). But, by providing the functionality now, it'll slot in nicely then.

[SeanCurtis-TRI]

Although, I strongly suspect unit inertia from surface mesh should be immediately doable as well...I'll confer with @mitiguy and correspondingly update the issue if it checks out.

[SeanCurtis-TRI]

Yep; we're good. We should be able to produce the SpatialInertias for arbitrary meshes.

Reference for the implementer:

http://docsdrive.com/pdfs/sciencepublications/jmssp/2005/8-11.pdf

[sherm1]

That reference looks good for a tet mesh. You mentioned doing this for surface meshes also?

[SeanCurtis-TRI]

You use it for the surface mesh in the same way you can compute the volume of surface mesh: divergence theorem.

1. Pick reference point (origin, average vertex, whatever).
2. Compute the signed volume, centroid, and inertia tensor for every tet (some will be negative some positive) formed by a surface triangle and the reference point.
3. Combine all of the tets' quantities appropriately (noting that some will add to and some will remove from).

Done

[SeanCurtis-TRI]

Essentially, the same way you create the inertia tensor for a thin spherical shell -- the tensor of the large volume minus the tensor of the small volume.

[sherm1]

FYI regarding the tet inertia reference above: there are two sign conventions for products of inertia (the off-diagonals). Check with @mitiguy to make sure to use the Drake sign convention.

Follow up on "products of inertia" from @sherm1.
There are various sign conventions, name conventions, and symbol conventions for products of inertia which can be easily compared for considering a single particle of mass m in "quadrant I".

The convention used by Drake (and many other multibody packages):
calls "_product of inertia_" Ixy = -m * x *y.

The convention in a paper referenced earlier (equation 3b):
http://docsdrive.com/pdfs/sciencepublications/jmssp/2005/8-11.pdf
calls "_product of inertia_" b = m * x y
It then uses -b in the inertia tensor in equation (2).
(Note: There seems to be a typo in equation 3b, using xz instead of x*y).

The convention used in Mirtich's paper in
https://www.geometrictools.com/Documentation/PolyhedralMassProperties.pdf
calls "_product of inertia_" Ixy = m * x *y.
It then uses -Ixy in the inertia tensor (matrix) in equation (3).

The convention used in Eberly's paper in
https://www.geometrictools.com/Documentation/PolyhedralMassProperties.pdf
avoids the term "product of inertia" altogether.

[amcastro-tri]

I computed this in the past from the (water tight) surface of the volume. In that case you use Gauss's theorem to replace volume integrals for surface integrals.

[amcastro-tri]

This document has all you need: https://www.geometrictools.com/Documentation/PolyhedralMassProperties.pdf

[sherm1]

@jwnimmer-tri can you say more about the workflow you have in mind? It's easy for me to see how we could add another calculator to Drake's UnitInertia class. But I'm not seeing yet how that works in an sdf-oriented workflow. For example, here is Gazebo's recommended workflow: http://gazebosim.org/tutorials?tut=inertia&cat=build_robot

[jwnimmer-tri]

@sherm1 that was exactly the tutorial we've been using, just semi-automated using https://github.com/RobotLocomotion/drake/blob/master/manipulation/util/meshlab_to_sdf.py. My goal would be to update + rename that tool so that given an *.obj file from an artist (+ the --mass_kg command line argument), it creates the rough draft *.sdf exactly like that tool does now, but without the user needing to deal with meshlab.

I would then verify the file is valid, and commit it to git for code review, merge, etc. as usual. It would _not_ be computing new inertias on the fly during sdf loading, for example. I just want a subroutine to remove the meshlab step from this program.

[sherm1]

@jwnimmer-tri thanks, got it. In that case I would propose we add this as a static method of the SpatialInertia class, similar to what we already have in the UnitInertia class:

So something like

static SpatialInertia<T> SpatialInertia::UniformDensitySolidFromSurfaceMesh(
    const std::filesystem::path& mesh_file_name, const T& mass);

[jwnimmer-tri]

I'm not sure SpatialInertia, a fundamental value-type abstraction, is where I want my file opening and obj parsing to occur. Seems like a layering violation.

[sherm1]

I think it depends whether you see this as primarily

• a mass properties operation (like we have for cubes, cylinders, etc.), or
• a operation on meshes.

I don't see a layering issue or a logical issue as to why a SpatialInertia class wouldn't be a good place to calculate spatial inertias. Maybe as an optimization we would only want to open the mesh file and process it once? In that case we could provide an opportunistic geometry API that makes mass properties available from SceneGraph after it has processed the mesh. Even so I think SpatialInertia should be able to perform this computation, perhaps with a note saying that SceneGraph users can get it cheaper.

[jwnimmer-tri]

I would buy this API for sure:

static SpatialInertia<T> SpatialInertia::UniformDensitySolidFromSurfaceMesh(
    const drake::SurfaceMesh& mesh, const T& mass);

But why should every single class in Drake that uses surface mesh data have APIs to read it from a file? We should have an API to read from a file (possibly from many different formats!) into a value type, and an API to turn that value (+ mass) into an inertia. Coupling the error-handling required for file parsing and reporting errors back to the user really pollutes the nice SpatialInertia data type.

[sherm1]

Oh, yes that is much better. I like it.

[DamrongGuoy]

I added label component: geometry general. Please feel free to change it. I'm not sure whether it's component: geometry proximity or component: multibody plant too?