No history yet

Contact Analysis

Finding the Touch Points

In robotic assembly, knowing precisely how parts interact is everything. Before a robot can calculate friction, test for stability, or plan its next move, it needs to understand where and how components make contact. This process, called contact analysis, is the foundation for simulating physical interactions.

Our goal is to build a service that takes two geometric parts and returns a 'contact manifold'—a detailed description of the intersection. This includes the area of contact, its location, and the orientation of the surfaces at that point. We'll focus on parts defined by Boundary Representation (B-Rep), a common method for modeling solid objects by their surfaces.

Quickly Ruling Out the Impossible

Checking every face of one part against every face of another is computationally expensive. An assembly might contain thousands of faces. Most parts in an assembly aren't touching, so we need a fast way to eliminate pairs that are too far apart to interact. This is called pre-filtering or broad-phase collision detection.

The standard approach is to use bounding boxes. You wrap each part in a simple, larger shape. If the bounding boxes don't overlap, the parts inside them can't possibly be touching. We can then skip the much more intensive, face-by-face check.

Two common types are:

  • Axis-Aligned Bounding Box (AABB): The simplest box, aligned with the world's X, Y, and Z axes. It's extremely fast to check for overlap—just compare the min/max coordinates on each axis. However, it can be a poor fit for rotated objects, leading to a lot of empty space inside the box.
  • Oriented Bounding Box (OBB): A box that rotates to fit the object as tightly as possible. OBB intersection tests are more complex than AABB tests but provide a much snugger fit. This accuracy means fewer 'false positives,' where boxes overlap but the parts inside do not.

For most applications, a two-step approach works best: use AABBs for a very fast initial culling, then run OBB tests on the pairs that pass. Only when an OBB intersection is confirmed do we proceed to the detailed analysis.

Analyzing the Surfaces

Once we've confirmed that two parts are close enough to potentially touch, we enter the narrow-phase detection. This is where we iterate through the faces of each object's B-Rep model to find the actual points of contact.

A B-Rep model stores a hierarchy of topological data: vertices, edges, and faces. We can use a library like Open CASCADE or nalgebra to traverse this data. The basic algorithm is a nested loop: for each face on Part A, check it for intersection against every face on Part B.

For planar faces, this check involves determining if two polygons in 3D space intersect. For curved (spline-based) surfaces, the math gets significantly more complex, often requiring iterative numerical solvers to find intersection curves.

This face-to-face check identifies different mating conditions:

  • Surface-to-Surface: Two faces overlap, creating a contact area. This is common when a box rests on a table.
  • Edge-to-Surface: The edge of one part touches the face of another. Think of a knife's edge pressing against a cutting board.
  • Point-to-Surface: The vertex of one part touches the face of another, like the tip of a cone resting on a flat plane.

Our primary focus is on surface-to-surface contact, as it's the most informative for stability and friction calculations.

Defining the Contact Manifold

Finding an intersection isn't enough. For a physics engine or a robot's planner to use this information, we need to quantify it. This is the contact manifold, which typically includes the contact area and surface normals.

Calculating the contact area for two intersecting planar polygons is a geometric clipping problem. We can use an algorithm like Sutherland-Hodgman to find the new polygon that represents the overlapping area. The area of this resulting polygon is our contact area.

Equally important are the surface normals. The normal is a vector that points directly away from the surface at a 90-degree angle. When two surfaces touch, their normals at the point of contact are crucial. Ideally, they should point in opposite directions. The alignment of these normals tells us about the quality of the contact. If they are perfectly anti-parallel, the surfaces are flush. If they are at an angle, the contact is at a corner or edge.

The final output of our service will be a list of these contact manifolds, one for each point or area of interaction. Here's how that might look in a Rust struct, representing the data we've gathered.

// Represents a single point of contact within a manifold.
// For a surface-to-surface contact, you'd have a collection of these.
pub struct ContactPoint {
    // Position of the contact point in world space.
    pub point: nalgebra::Point3<f64>,
    // Surface normal of the second body at the contact point.
    pub normal: nalgebra::Unit<nalgebra::Vector3<f64>>,
    // How deep the objects are penetrating each other.
    pub penetration_depth: f64,
}

// A full description of the interaction between two bodies.
pub struct ContactManifold {
    pub body1_id: u32,
    pub body2_id: u32,
    pub contact_points: Vec<ContactPoint>,
    pub contact_area: f64, // Calculated from the intersection polygon.
}

This manifold provides everything a downstream system needs. A physics simulator can use the normals and penetration depth to calculate repulsive forces, while a motion planner can use the contact area and positions to ensure a stable grip.

Quiz Questions 1/6

What is the primary purpose of broad-phase collision detection in robotic assembly simulation?

Quiz Questions 2/6

An automated system needs to check for contact with a long, thin part that is frequently rotated. Which type of bounding box would provide the most efficient pre-filtering by minimizing 'false positives'?