Drake
Drake Contact Implementation
Collaboration diagram for Drake Contact Implementation:

Drake's compliant point contact model is a coarse approximation of the previous discussion.

This section outlines the simplifications. With time, the contact model will grow more and offer more sophisticated and accurate models.

Collision Detection and Characterization

When the collision geometry of two bodies penetrate, the penetration is characterized by:

The volume and domain of the penetration is conspicuously absent. As such, it is impossible for a contact model to calculate a contact force based on the specific details of that unreported volume.

Future versions of Drake will support additional characterizations of geometry penetration in support of volume-based contact force calculation.

Contact Force Computation

Given the characterization of penetration outlined above (i.e., a single point), a full implementation of the contact normal force would be impossible. Instead, Drake employs a corruption of the Hertz model. The best analogy would be to think of the contact as between a vertical cylinder and a plane: fₙ = 2⋅E⋅R⋅x. In other words, it assumes that the contact area is independent of the depth and that pressure is proportional to the penetration depth. The radius R is a tunable "global" parameter of the CompliantContactModel. (See Working with Contacts in Drake on how to work with this property.)

Based on this Hertzian value, the full Hunt-Crossley normal force is computed as defined above. Furthermore, the tangential component of the contact force is also computed as outlined above.

Per-object Contact Material

Drake supports defining compliant contact materials on a per-collision geometry basis. It has several mechanisms in place to facilitate working with per-collision object contact materials:

Material parameters and evaluating contact

The per-object material parameters consist of:

The parameters outlined in The Details of Computing Contact Forces are derived from the material values for the two colliding bodies. Consider two colliding bodies M and N. The contact values E, d, μ_s, and μ_d used to compute the contact force are defined in the following way:

Finally, the contact point is also defined with respect to the "squish" factors. For penetrating bodies M and N, there is a point on the surface of M that most deeply penetrates into N (and vice versa). We will call those points Mc and Nc, respectively. The contact point, is C = Mc * sₙ + Nc * sₘ. We draw particular attention to the fact that the point on M's surface is weighted by N's squish factor and vice versa. That is because, if body M experiences all of the deformation, it will be deformed all the way to the point of deepest penetration in M, which was the definition of Nc.

Contact material default values

Every collision element has a compliant material. If the values of that material have not been explicitly set (i.e., via calls to the API or specified in a URDF/SDF file), the the value is configured to use a "default" value. What the actual default value is depends on how the material property is accessed (see the documentation for CompliantMaterial for further elaboration).

Consider a box used as collision geometry with all of its compliant material parameters set to default. Consider querying for the box's dissipation. The value returned could be different values based on invocation:

  1. Querying directly (e.g., box.compliant_material().dissipation()) will return the hard-coded, Drake-wide default value.
  2. Alternatively, when the CompliantContactModel used by a RigidBodyPlant evaluates it, the default value will be the CompliantContactModel's default material dissipation value. Which may be different from the hard-coded globals or from any other instance of CompliantContactModel.
  3. Alternatively, user-code could provide a preferred default which will be returned iff the property is default configured (e.g., box.compliant_material().dissipation(0.125))

The point that needs to be emphasized is that configuring a material property to be default is not a one-time operation. It defines a relationship that can be determined at evaluation time.

A word of warning

It might be tempting to write code akin to this pseudo-code:

CompliantMaterial mat;
RigidBodyPlant plant;
mat.set_dissipation(0.1);
plant.set_default_contact_material(mat);
ParseUrdf(plant, "my_robot.urdf");
mat.set_(5e6);
mat.set_dissipation(0.2);
plant.set_default_contact_material(mat);
ParseUrdf(plant, "other_robot.urdf");

At first glance, one might be inclined to believe that the any collision elements without specified contact materials in the file my_robot.urdf would have dissipation value of 0.1, whereas those in the file other_robot.urdf would have dissipation of 0.2. This is not the case. The collision elements of both robots are configured to use the default value. And they will report a dissipation of 5e6 if the plant evaluates it, or some other value in other contexts.

Specifying contact parameter values in URDF/SDF.

We are exploiting the fact that URDF and SDF are XML files and choose to naively extend the specification to include a custom tag. Although there are numerous differences between the two formats, there is fortunate similarity in declaring collision geometries. For simplicity's sake, we expect identically formatted contact material format in both formats that look something like this:

1 ...
2 <collision ...>
3  <geometry ...>
4  </geometry>
5 
6  <drake_compliance>
7  <youngs_modulus>##</youngs_modulus>
8  <dissipation>##</dissipation>
9  <static_friction>##</static_friction>
10  <dynamic_friction>##</dynamic_friction>
11  </drake_compliance>
12 
13 </collision>
14 ...

Differences between URDF and SDF are dismissed with ellipses. What is significant is that the <drake_compliance> tag should be introduced as a child of the <collision> tag (common to both formats) and should be formatted as shown.

The following rules are applied for parsing: