Section 6.3: Contact, friction, and why contact-rich sim is hard

"Contact does not arrive smoothly. It arrives as an interruption, and the simulator must decide what the world looks like on the other side of it."

A Frustrated Collision Solver

Your grasp policy reports 95 percent success in simulation, ships to the real Franka, and the mug slips through its fingers on the first try: the gap is almost never the controller and almost always a single line in the MuJoCo contact log you never read. The vocabulary that exposes it, signed separation (the gap between two surfaces, positive when apart, zero at touch, and negative when interpenetrating), the coefficient of restitution, the Coulomb friction cone, and the stick/slide active set, is what this section builds. We define each on the simplest possible system, a point mass hitting a floor, then connect it to the case that actually breaks policies: a Franka Panda hand closing on a mug, where 20 fingertip contacts must each resolve as stick or slide every 2 ms.

The practical question is the one every sim-to-real failure eventually forces: when an IsaacGym policy reports 95 percent grasp success but the real Franka drops the object, was the grasp real or did the policy exploit a 20 mm contact shell? Answering that requires reading penetration depth and stick/slide mode out of the contact solver, not just the reward curve.

Theory

Contact is fundamentally different from the rest of dynamics. Between contacts, a robot's equations of motion are smooth ordinary differential equations: forces are continuous, accelerations are continuous, and standard integrators work well. The moment two bodies touch, a constraint force appears instantaneously. Velocities can jump discontinuously: a bouncing ball reverses its normal velocity in zero time. An infinitesimal change in configuration can flip the set of active constraints. Better hardware or a smaller timestep will not cure this. It is a structural property of rigid-body mechanics. At every step, the simulator must choose which contacts are active and whether each one is sticking or sliding, a choice called the active set, meaning the specific subset of contacts currently exerting force and the stick-or-slide mode assigned to each. That combinatorial decision changes the equations the integrator solves. A five-fingered hand grasping a mug can have 20 simultaneous contact points. Each can independently stick or slide, giving \(2^{20}\) (over one million) possible active sets to evaluate every millisecond. The scale grows fast. A locomotion policy trained on a flat floor with two foot contacts converges in roughly 5,000 rollouts. The same policy trained on terrain with 20 simultaneous contact points can require over 500,000 rollouts to reach the same reward, because each new contact mode is effectively a new problem the policy has never seen. This is the combinatorial explosion of contact modes, and it is the root reason contact-rich simulation is hard.

A policy trained where contact is wrong does not learn to grasp objects; it learns to exploit the simulator's tolerance for overlap. The friction-cone diagram below makes both halves of this concrete: on the left, a single contact's impulse either lands inside the Coulomb cone (stick) or on its boundary (slide); on the right, N such independent stick-or-slide choices multiply into the \(2^N\) mode combinations the solver must sort through every timestep.

The practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

Worked Example: Impulse-Based Contact With Restitution and a Friction Cone

Hard contact is hard because it is a constrained, set-valued problem. An impulse-based resolution sidesteps stiff penalty forces by directly computing the impulse \(J = (J_n, J_t)\) that corrects the relative velocity at the contact point in a single step. Two physical laws bound that impulse:

• Normal restitution. The coefficient of restitution \(e \in [0,1]\) reverses the post-impact normal velocity by its own factor: \(v_n^{+} = -e\, v_n^{-}\). With \(e=1\) the bounce is perfectly elastic; with \(e=0\) the contact is fully plastic. Why it matters: a robot foot or fingertip is neither perfectly elastic nor perfectly plastic. The wrong \(e\) in simulation produces a post-impact velocity that does not match hardware. A locomotion policy tuned on \(e=0.8\) rubber pads will then stumble on a real floor with \(e=0.3\) foam. How it works: during collision, bodies deform elastically, store energy, then rebound. The value \(e\) is the ratio of rebound speed to approach speed. It captures how much stored elastic energy the material returns versus dissipates as heat and plastic deformation.
• Coulomb friction cone. The tangential impulse is limited by \(\lVert J_t \rVert \le \mu J_n\). Inside the cone the contact sticks (relative tangential velocity is driven to zero); on the cone boundary it slides and friction opposes the slip direction.

The example resolves a point mass striking the ground at an angle. It computes the normal impulse from restitution, then clamps the sticking tangential impulse to the friction cone, which is exactly the projection a contact solver performs at every active contact.

import numpy as np

def resolve_contact(v_in, m, normal, e, mu):
    """Impulse-based resolution of a point mass hitting a surface.
    v_in   : incoming velocity (2D)
    normal : unit surface normal pointing away from the surface
    e      : coefficient of restitution in [0,1]
    mu     : Coulomb friction coefficient
    Returns post-impact velocity and the applied impulse."""
    n = normal / np.linalg.norm(normal)
    t = np.array([-n[1], n[0]])            # tangent direction

    vn = v_in @ n                          # normal component (negative if approaching)
    vt = v_in @ t                          # tangential component

    if vn >= 0:                            # separating, no contact impulse
        return v_in, np.zeros(2)

    # Normal impulse enforces v_n^+ = -e * v_n^-.
    Jn = -(1 + e) * vn * m                 # >= 0

    # Sticking tangential impulse would cancel all tangential velocity.
    Jt_stick = -vt * m
    Jt_max   = mu * Jn                     # friction-cone limit
    if abs(Jt_stick) <= Jt_max:
        Jt = Jt_stick                      # inside cone: stick
        mode = "stick"
    else:
        Jt = -np.sign(vt) * Jt_max         # on cone: slide, oppose slip
        mode = "slide"

    J = Jn * n + Jt * t
    v_out = v_in + J / m
    return v_out, J, mode

m = 0.5
v_in = np.array([3.0, -2.0])               # moving right and down
normal = np.array([0.0, 1.0])              # floor normal points up

for e, mu in [(0.0, 2.0), (0.8, 0.5), (0.8, 0.05)]:
    v_out, J, mode = resolve_contact(v_in, m, normal, e, mu)
    vn_out = v_out @ normal
    print(f"e={e} mu={mu:<4} -> v_out={np.round(v_out,3)} "
          f"vn_out={vn_out:+.3f} mode={mode}")

The output shows the three regimes a contact-rich simulator must get right: with \(e=0\) the normal velocity is killed and high friction makes the contact stick; with \(e=0.8\) the mass bounces, \(v_n^{+}=0.8\,|v_n^{-}|\); and with low \(\mu\) the tangential impulse saturates on the cone and the mass slides instead of sticking. The set-valued switch between stick and slide is precisely the active-set decision that makes contact-rich simulation non-smooth and timestep sensitive.

Practical Recipe

The friction-cone projection above is what one solver step does in principle; turning that principle into a contact model you can trust on real hardware means fixing the concrete timestep, solver, and logging choices that govern whether the projection ever runs on sane inputs.

1. Set the MuJoCo timestep to 2 ms for manipulation (Franka Panda fingertip contacts) and 4 ms for locomotion (Unitree H1 foot strikes); coarser steps cause tunneling (a body moving fast enough within one timestep to pass entirely through a thin surface without the solver ever detecting contact) at fingertip scale, finer steps waste compute without improving contact fidelity.
2. Run a free-motion energy check before adding contact: integrate a Franka arm at zero torque for 5 s and confirm that kinetic energy drifts less than 0.1 % per second; a larger drift means inertia parameters in the URDF are inconsistent.
3. Add a single flat-ground contact and verify that penetration depth stays below 0.1 mm at steady state; if depth grows monotonically, tighten solref from the MuJoCo default "0.02 1" to "0.005 1".
4. Test grasp stability with the Franka hand by logging the stick/slide mode at each finger pad contact across a 500 ms hold; if mode switches exceed 5 per second without a change in applied torque, the contact is chattering and solimp needs adjustment.
5. Before scaling to Isaac Lab for parallel rollouts, reproduce the same grasp in a single-environment MuJoCo run and confirm that success rate, mean penetration, and energy error match to within 5 %; GPU-parallelism does not fix a broken contact model.

Production Pattern

Contact, friction, and why contact-rich sim is hard sits inside the Part II robotics contract: geometry defines where things are, kinematics defines what motion is possible, dynamics defines what motion costs, control defines how errors are corrected, and sensing defines what the agent can know on time.

Inspect contact as a numerical model with solver settings, not as a perfect physical event. Contact then serves practitioners, builders, and researchers at once: the idea has an intuitive role, a formal interface, a runnable check, and a reproducible failure mode.

Contact is hard because the model changes structure the instant two bodies touch. Free motion gives way to a constraint force, penetration must stay small, and tangential slip may switch between sticking and sliding. The solver has to satisfy all three at once, in one step.

Use this recipe when turning Contact, friction, and why contact-rich sim is hard into code, a simulator experiment, or a robot diagnostic. The point is not to use every library. The point is to keep the hand-built baseline and the maintained-tool path comparable.

1. Specify mass, inertia, actuator limits, contact model, timestep, and solver tolerance before running a rollout.
2. Run one free-motion test and one contact test with logged energy, constraint violation, and penetration depth.
3. Compare the hand calculation with MuJoCo, Drake, Pinocchio, or MJX on the same model and timestep.
4. Store solver settings, random seed, initial state, trajectory, and failure labels in one artifact.
5. Scale to Isaac Lab or GPU-parallel simulation only after a small model passes deterministic checks.

Distrust smooth simulation until the section-specific physical assumption has been stress-tested: timestep, contact stiffness, damping, friction, actuation, and energy behavior should each have a small diagnostic.