Use common friction parameters across physics engines

[osrf-migration]

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

---

Currently each physics engine has its own friction parameters. We should make some common parameters that each can use.

[osrf-migration]

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

---

We should also make sure that these friction parameters are defined in both physics.sdf (default values) and surface.sdf (per-collision values).

[osrf-migration]

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

---

Starting work in branch issue_31 with 117b0dc

[osrf-migration]

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

---

• set version to "1.5"

[osrf-migration]

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

---

Existing format:

<link>
  <collision>
    <surface>
      <friction>
        <ode>
          <mu>1.0</mu>
          <mu2>1.0</mu2>
        </ode>
      </friction>
    </surface>
  </collision>
</link>

Proposed:

<link>
  <collision>
    <surface>
      <friction>

        <!-- real world physical properties -->
        <static_friction>1.0</static_friction>
        <dynamic_friction>1.0</dynamic_friction>  <!-- do we need this now? only simbody uses it. -->
        <viscous_friction>0.0</viscous_friction> <!-- do we need this now? only simbody uses it. -->

        <!-- physics engine specific parameters -->
        <ode>
          <!-- ratios below are applied to static/dynamic friction coefficient of this collision body -->
          <mu_ratio>1.0</mu_ratio>
          <mu2_ratio>1.0</mu2_ratio>
        </ode>
        <simbody>
          <!-- alternatively, put dynamic and viscous friction params in physics specific block -->
          <dynamic_friction>1.0</dynamic_friction>
          <viscous_friction>0.0</viscous_friction>
        </simbody>

      </friction>
    </surface>
  </collision>
</link>

Reference simbody implementation of static / dynamic / viscous friction.

[osrf-migration]

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

---

Related issue, support material database in sdformat or gazebo?

[osrf-migration]

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

---

Also make sure to give bullet its own friction parameters (see BulletSurfaceParams.cc:48)

[osrf-migration]

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

---

Waiting on gazebo pull request for surface parameters

[osrf-migration]

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

---

I was just talking about friction parameters today with @azeey and we talked about the following:

In the interests of simplicity for model creators who don't know what friction model they want to use, it's nice to have a single parameter to correspond roughly to a Coulumb friction coefficient. This is shown in the snippet below as <mu>.

You can also define named <friction_model> blocks with additional parameters, such as mu2 for the pyramid model or dynamic_friction and viscous_friction for the Stribeck model, but each friction model should strive to use the <mu> parameter and define specifically what it means in that model.

<link>
  <collision>
    <surface>
      <friction>
        <mu>1.0</mu>

        <friction_model name="pyramid">
          <!-- use generic mu for mu1 -->
          <mu2>1.0</mu2>
          <slip1>0.0</slip1>
          <slip2>0.0</sliip2>
          <fdir1 frame="">1 0 0</fdir1>
        </friction_model>

        <friction_model name="cone">
          <!-- use generic mu for friction coefficient -->
          <cone_parameter1/>
        </friction_model>

        <friction_model name="stribeck">
          <!-- use generic mu for static friction coefficient -->
          <dynamic_friction>1.0</dynamic_friction>
          <viscous_friction>0.0</viscous_friction>
          <simbody>
            <!-- can put physics-engine specific parameters inside a friction_model -->
          </simbody>
        </friction_model>

        <ode>
          <!-- or you can put physics-engine specific parameters directly under friction -->
        </ode>

      </friction>
    </surface>
  </collision>
</link>

cc @mxgrey

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

I definitely like this concept. There are just a few thoughts that jump out at me:

1. It might be confusing to define one parameter outside of the friction_model element while all the rest are defined inside of one. I understand the motivation and I'm not opposed to doing it, but I wanted to voice that concern.

2. Are these friction models additive, or could they conflict with each other? I assume the user must choose only one. In that case, it might make more sense to do something like

<link>
  <collision>
    <surface>
      <friction type="[coulomb|pyramid|cone|stribeck]">
        <mu>1.0</mu>

        <!-- If and only if type is pyramid
        <mu2>1.0</mu2>
        <slip1>0.0</slip1>
        <slip2>0.0</sliip2>
        <fdir1 frame="">1 0 0</fdir1>
         -->

         <!-- If and only if type is cone
         <cone_parameter>1.0</cone_parameter>
         -->

        <!-- If and only if type is stribeck
        <dynamic_friction>1.0</dynamic_friction>
        <viscous_friction>0.0</viscous_friction>
        -->

        <simbody>
          <!-- can put physics-engine specific parameters inside a friction_model -->
        </simbody>

        <ode>
          <!-- or you can put physics-engine specific parameters directly under friction -->
        </ode>

      </friction>
    </surface>
  </collision>
</link>

The type attribute would default to coulomb when the type isn't specified.

3. Whether or not we go with the suggestion I make in (2), the sdformat API might have some difficulty with converting the polymorphism into concrete data types. I suppose one option might be to give the sdf::Surface class various member functions like const Coulomb* Surface::GetCoulomb() const and const Pyramid* Surface::GetPyramid() const, etc, where everything returns a nullptr except the friction model that was requested by the user.

[osrf-migration]

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

---

more references:

• OpenCOLLADA physics extension: https://www.khronos.org/collada/wiki/Physics_material_OpenCOLLADA_extension

• Drake stribeck friction model: https://drake.mit.edu/doxygen_cxx/group__stribeck__approximation.html

[chapulina]

The DART implementation on Ignition Physics has been using the <ode> tag until this issue is resolved.

[scpeters]

the MuJoCo file format has a very flexible way to express friction coefficients; we could consider copying their parameterization:

• https://mujoco.readthedocs.io/en/latest/computation.html#contact