sdformat
sdformat copied to clipboard
gazebosim
Use common friction parameters across physics engines
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.
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).
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Starting work in branch issue_31 with 117b0dc95476baa99951861462f2e38a3e8adaac
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.
Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).
Related issue, support material database in sdformat or gazebo?
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Also make sure to give bullet its own friction parameters (see BulletSurfaceParams.cc:48)
Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).
Waiting on gazebo pull request for surface parameters
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
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:
-
It might be confusing to define one parameter outside of the
friction_modelelement 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. -
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.
- 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::Surfaceclass various member functions likeconst Coulomb* Surface::GetCoulomb() constandconst Pyramid* Surface::GetPyramid() const, etc, where everything returns a nullptr except the friction model that was requested by the user.
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
The DART implementation on Ignition Physics has been using the <ode> tag until this issue is resolved.
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
