Drake
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:

• a pair of points: the points on each geometry that lies most deeply in the other geometry,
• a vector: the contact normal direction, and
• the penetration depth.

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:

• Universal default values (all objects default to the universal values if none have been explicitly specified).
• Parsing per-collision element material parameters from URDF and SDF files using extended tags (formatted identically for both source files types).
• Runtime query which admits the ability to provide a custom default value.

### Material parameters and evaluating contact

The per-object material parameters consist of:

• Elastic modulus (aka stiffness) (E) with units of pascals,
• dissipation (d) with units of 1/velocity, and
• static and dynamic friction (unitless μ_s and μ_d, respectively).

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:

• sₘ ∈ [0, 1] is the "squish" factor of body M. It represents the amount of total deformation experienced by body M. Consider contact between a steel body and foam ball; the foam ball would experience the entire deformation and the squish factors for the foam ball and steel plate would be 1 and 0, respectively. The squish value is defined as sₘ = kₙ / (kₘ + kₙ), with sₙ = 1 - sₘ.
• E = sₘEₘ = sₙEₙ. The effective Young's modulus of the contact will generally not be the Young's modulus of either constituent material (unless one were infinite). If Eₘ = Eₙ, then E would be Eₘ/2.
• d = sₘdₘ + sₙdₙ. Again, the dissipation of the contact is simply a linear interpolation of the two bodies' dissipation values.
• μ_s (and μ_d) are defined as 2μₘμₙ / (μₘ + μₙ).

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:

...
<collision ...>
<geometry ...>
</geometry>
<drake_compliance>
<youngs_modulus>##</youngs_modulus>
<dissipation>##</dissipation>
<static_friction>##</static_friction>
<dynamic_friction>##</dynamic_friction>
</drake_compliance>
</collision>
...

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:

• If no <drake_compliance> tag is found, the element uses the global default parameters.
• Not all parameters are required; explicitly specified parameters will be applied to the corresponding element and omitted parameters will map to the default values.
• Friction values must be defined as a pair, or not at all. When defined as a pair, the static_friction value must be greater than or equal to the dynamic_friction value. Failure to meet these requirements will cause a runtime exception.