allow multiple <inertial> blocks in a single Link element

[scpeters-test]

Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

This will make modeling slightly easier for end users. Currently, if a rigid body is composed of multiple simple geometries, user has to either:

1. compute combined inertia by hand, or
2. attach multiple links together with fixed joints

Allowing multiple <inertial> blocks in a single link will leverage gazebo::Inertia class to compute combined inertia.

[scpeters-test]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

tagging @scpeters, @nkoenig and @rosebudflyaway

[scpeters-test]

Original comment by Steve Peters (Bitbucket: Steven Peters).

---

An alternative that just occurred to me is to use the URDF fixed-joint reduction in SDF as well.

[scpeters-test]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Fixed joint reduction comes with naming problems. We might also end up creating a real fixed joint in Gazebo.

I would be in favor of adding <density> or <mass> to <collision> elements. We could then compute the intertial properties. With the following behavior:

1. If a link has an <inertial> tag, then use only that. Also use the default inertia if no <inertial> and no <denisity/mass> tags are present.
2. Otherwise compute inertia from collision shapes that have a density/mass info.

[scpeters-test]

Original comment by Steve Peters (Bitbucket: Steven Peters).

---

@nkoenig another issue related to our sdf 1.6 discussion today, but I'm not sure this would require a version bump

[scpeters-test]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

I like <density> and <mass> as well, but I am concerned about tying inertia information to collisions. What about <inertia> blocks using <density> <mass> and <geometry>?

[scpeters-test]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

It shouldn't require a version bump.

@hsu, what is your concern about tying inertia to collisions?

[scpeters-test]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Inertia and collision are two separate components that do not necessarily couple (e.g. by the same logic, we could also use visual geometries to define inertia). The only information that collision gives us in addition to density is the shape of the object. Adding geometry block and density to define inertia in a inertia block seems less hackish than hijacking collision block...

<inertia>
  <density>1</density>
  <geometry>
    <sphere>
      <radius>0.1</radius>
    </sphere>
  </geometry>
</inertia>

If we are just adding <density> and <geometry>, this should not require a version bump either?

Another benefit of keeping inertia in inertia block that I can think of off the top of my head is this use case: Suppose a robot arm is mostly carbon fiber structure with a powerful and heavy motor mounted somewhere in the arm. We can approximate the mass of the arm by a steel cylinder approximately the shape of the motor and located near the motor mount point (the arm's collision shape is not necessarily the best description of the inertia of the link here).

Down the road, we can get fancy, and compute MOI of an object based on trimesh defined shapes (assuming water tight meshes), this could introduce the ability to define shell-like MOI for a given density and shape.

John

[scpeters-test]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

+1 for multiple inertias within a link but not necessarily tied to a collision.

You might want to have multiple inertias to simplify calculation by hand but still a single collision to reduce contact computation. Take a long rod with an uneven weight distribution for example, you might want to add a mass point at each end but still only use a single collision shape.

Another concern I would have with tying inertia to collisions is changing the semantic meaning of a "collision". Right now I understand it purely as something related to contacts, but I might be mistaken.

[scpeters-test]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

One more thing, if we add shape description (geometry) for inertia, then one can choose to specify either mass or density, but not both.

[scpeters-test]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

@hsu and I sent messages at the same time, I like his arm with heavy motor example better than my rod :)

[scpeters-test]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Sounds good. I like the inside the . This also dovetails with the notion of inheriting/copying geometry from a collision. For example,

<geometry name="col_shape">
  <sphere><radius>1.0</radius></sphere>
</geometry>

<inertia>
  <density>1</density>
  <geometry inherit='col_shape'/>
</inertia>

<collision name="collision">
  <geometry inherit="col_shape"/>
</collision>

<visual name="visual">
  <geometry inherit="col_shape"/>
</visual>

[scpeters-test]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

The inherit tag is nice to prevent copy-n-paste, but I feel doing so kind of drives sdf towards scripting territory. This feels like something that could be done in erb or xacro. Supporting something like this could also make the parser much[slightly] more complex, harder to maintain.

[scpeters-test]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

The inherit concepts also encodes information about relationships between geometries, visuals, collisions, and inertias. In the above example, a program would know that the geometry affects all three.

Moving toward a scripting territory it not necessarily bad. I could argue that since everyone needs/uses xacro, then parts of xacro should be incorporated into the standard.

[scpeters-test]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Agreed, something similar but not exactly the same was done for <material>, see urdf. I am OK with or without it.

In case you are thinking about implementing basic scripting features directly into sdf, my vote is for math expressions and shared variable properties. I find myself wanting these features in several use cases where xacro is not available.

[scpeters-test]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

Sounds good.

I'm not planning on implementing basic scripting features directly in sdf. I'm waiting on ruby support in OSX to re-submit a previous pull request that would give us a full scripting language inside libsdformat (note that this is different from the SDF specification).

[scpeters-test]

Original comment by Steve Peters (Bitbucket: Steven Peters).

---

@hsu I'd prefer to just use a real scripting language like ruby or python with templates since it is such a slippery slope. Once you have simple arithmetic (+-*/), then you want trig functions, and it's a slippery slope from there. I think it's better just to use a real scripting language.