Substitute physics-engine-specific elements with generic ones

[chapulina]

The <physics> element currently supports tags that are physics-engine specific (<ode>, <bullet>, <dart>, <simbody>). These tags apply to Gazebo classic, but they don't necessarily work for other simulators using SDFormat. For that reason, I think we should deprecate these tags and work on a more generic and extensible spec.

It's important we decide this before we add C++ "DOM" classes to access these elements.

Desired behavior

Users can set parameters under the <physics> tag, and each simulator / physics engine supports them as possible. This is similar to how most other tags are handled. For example, the spec has a <restitution_coefficient> that not every engine may support, and that's ok.

Alternatives considered

We could keep adding tags specific to every physics engine to the spec, but that doesn't scale well, and ultimately forces the end user to configure various settings for each engine, sometimes repeating themselves.

Implementation suggestion

Promoting elements to be generic

One quick implementation would be to pull all elements that are currently nested under specific engines one level higher, so they're direct children of <physics>. So for example, instead of:

<physics ...>
  <dart>
    <solver><solver_type>some dart solver</solver_type></solver>
  <dart>
  </bullet>
    <solver><type>some bullet solver</type></solver>
  </bullet>
</physics>

We could have a pattern like this, where each engine picks the first option that works for them:

<physics ...>
    <solver>
      <type>some dart solver</type>
      <type>some bullet solver</type>
    </solver>
</physics>

Accepting arbitrary key / values

Another alternative is to offer an interface that's a bit more open-ended and accepts arbitrary key / value pairs. For example:

<physics ...>
    <param key="solver_type" value="some dart solver">
    <param key="solver_type" value="some bullet solver">
</physics>

From the C++ API, these could be accessible as a map with an std::string as key and a ParamVariant as value:

https://github.com/osrf/sdformat/blob/9c4261badf4fff56fb29da74e0eaa53eaf3cb31e/include/sdf/Param.hh#L244-L254

This option could make the spec more flexible, but it may go against the purpose of having a spec in the first place. If any simulator can accept any parameters they want, we may quickly end up with Simulator A accepting solver_type and Simulator B accepting type, and users needing to set all variations to make their worlds portable.

Custom elements

SDFormat now accepts custom elements, as described on Custom elements and attributes. Each simulator / physics engine could use these to specify tags that are specific to them. For example:

<physics ...>
    <dart::solver>some dart solver</dart::solver>
    <bullet::solver>some bullet solver</bullet::solver>
</physics>

Similar to the key / value approach above, this may offer too much flexibility. Unlike that approach, it may be difficult to come up with a C++ API for them, since custom elements are meant to be ignored by SDFormat.

Conclusion

I believe we may end up with a combination of the options above. I'm leaning towards bumping some of the most common parameters to first-class <physics> elements, and providing a <param> API where engines can put parameters that are very specific to them.

Additional context

This issue is analogous to #31 for friction.

[hyunseok-yang]

@chapulina

So you're planning to change like below, right?

<physics ...>
    <solver>
      <type>some dart solver</type>
      <type>some bullet solver</type>
    </solver>
</physics>

If it so, could you describe more detail examples? especially, the element in joint physics.

[chapulina]

you're planning to change like below,

This is just a proposal, I'm not sure if other people have better ideas. Also, there's no plan to work on this at the moment.

If it so, could you describe more detail examples? especially, the element in joint physics.

I can imagine it would follow the same pattern as the snippets above.