SDF geometry enhancements

[osrf-migration]

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

A very common use case of SDF, involves links that have collision and visual elements that use the same geometry properties. Currently this involves duplicated information and manual synchronization. For example:

<link name="ball">
  <collision name="collision">
    <geometry>
      <sphere>
        <radius>1</radius>
      </sphere>
    </geometry>
  </collision>
  <visual name="visual">
    <geometry>
      <sphere>
        <radius>1</radius>
      </sphere>
    </geometry>
    <material>
      <script>Gazebo/Grey</script>
    </material>
  </visual>
</link>

I propose allowing a element as a child of that can be referenced by and elements. The above example could be re-written as:

<link name="ball">
  <geometry name="geom">
    <sphere>
      <radius>1</radius>
    </sphere>
  </geometry>
  <collision name="collision">
    <geometry inherit_from="geom"/>
  </collision>
  <visual name="visual">
    <geometry inherit_from="geom"/>
    <material>
      <script>Gazebo/Grey</script>
    </material>
  </visual>
</link>

I would also propose allowing the tags to accept some geometry elements, which can be used to automatically compute the moment of inertia terms, assuming uniform density. For meshes, it could be based on the bounding box. For example, a ball with inertial parameters could be specified as:

<link name="ball">
  <geometry name="geom">
    <sphere>
      <radius>1</radius>
    </sphere>
  </geometry>
  <inertial>
    <mass>1</mass>
    <geometry inherit_from="geom"/>
  </inertial>
  <collision name="collision">
    <geometry inherit_from="geom"/>
  </collision>
  <visual name="visual">
    <geometry inherit_from="geom"/>
    <material>
      <script>Gazebo/Grey</script>
    </material>
  </visual>
</link>

One could also imagine the utility of allowing elements as children of elements so that a stack of identical boxes could each inherit the same geometric properties.

[osrf-migration]

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

---

Do you think it would be better to allow a visual to inherit the collision shape:

#!xml

<link name="ball">
  <collision name="collision">
    <geometry>...</geometry>
  </collision>
  <visual name="visual">
    <geometry inherit="collision"/>
    <material>...</material>
  </visual>
</link>

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Nate, I think that is simpler syntax for dealing with a single link with one collision and one visual.

What if we want to allow sharing geometry across links? How about a robot with multiple wheels of the same size?

<model name="wheeled_robot">
<link name="chassis">...</link>
<link name="left_wheel>
  <collision name="collision">
    <geometry>...</geometry>
  </collision>
  <visual name="visual">
    <geometry inherit="collision"/>
    <material>...</material>
  </visual>
</link>
<link name="right_wheel>
  <collision name="collision">
    <geometry inherit="left_wheel::collision"/>
  </collision>
  <visual name="visual">
    <geometry inherit="left_wheel::collision"/>
    <material>...</material>
  </visual>
</link>
</model>

The above seems like there's complicated namespace issues.

Here's a different idea:

<model name="wheeled_robot">
<templates>
<geometry name="wheel_geom">...</geometry>
<collision name="wheel_collision">
  <geometry inherit="wheel_shape"/>
  <surface>...</surface>
</collision>
<visual name="wheel_visual">
  <geometry inherit="wheel_shape"/>
  <material>...</material>
</visual>
</templates>
<link name="chassis">...</link>
<link name="left_wheel">
  <pose>...</pose>
  <collision inherit="wheel_collision"/>
  <visual inherit="wheel_visual"/>
</link>
<link name="right_wheel">
  <pose>...</pose>
  <collision inherit="wheel_collision"/>
  <visual inherit="wheel_visual"/>
</link>
</model>

[osrf-migration]

Original comment by Michael Sherman (Bitbucket: sherm1).

---

(Per this morning's discussion.) Another approach to this problem would be to think of geometry as the high level concept, with optional properties: pose/shape/inertial/contact/visual. The list of properties might grow over time -- for example, magnetic, wind resistance, infrared reflectance or whatever.

#!xml

<link name="xxx">
<geometry>
    <pose>...</pose>
    <sphere><radius>1</radius></sphere>   
    <visual> visual properties </visual>
    <collision> contact properties </collision>
    <inertial> <density>1</density> </inertial>
</geometry>
</link>

Even more compact would be to allow sets of properties to be combined into named objects (materials?) that could then be referenced so that geometry would consist of a pose, a shape, and a material.

[osrf-migration]

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

---

• changed state from "new" to "on hold"

Until 2.0

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed state from "on hold" to "open"

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

@jacquelinekay

[osrf-migration]

Original comment by Isaac Saito (Bitbucket: 130s).

---

Now that we have such a useful tool Model Editor, I think this feature makes even more sense than ever.

[osrf-migration]

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

---

• set version to "all"

[osrf-migration]

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

---

• changed state from "open" to "new"

[osrf-migration]

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

---

Similar issue on SDFormat