Collision checking tests whether a robot in a given configuration hits itself or the world — the fast, constantly-called routine that keeps every motion planner's paths safe, and often its computational bottleneck.
Collision checking asks a simple question over and over: in this pose, does the robot bump into anything — a wall, an object, or itself? Planners call it thousands of times to make sure the path they pick is safe.
🎯 Quick challenge
Why is collision checking often a planner's bottleneck?
Every motion planner shares one unglamorous, essential subroutine, called constantly: does the robot, in this pose, hit anything? That's collision checking, and it quietly determines whether planned paths are safe — and how fast planning runs.
What it does
Collision checking answers a geometric yes/no: given a robot configuration (a set of joint angles or a pose), does the robot's body intersect any obstacle in the world, or itself (self-collision)? Planners also need to check the motion between two configurations — sweeping a short path and verifying nothing is hit along the way.
Is this pose safe?
The checker reports whether a configuration (or a motion between two) is collision-free. Planners keep only the free ones — the basis of safe paths.
Why it's the hidden bottleneck
Sampling planners (RRT, PRM) and optimizers test enormous numbers of configurations and motions — often thousands or millions. Since almost every planning step involves a collision check, the checker's speed dominates total planning time. Making collision checking fast is therefore one of the highest-leverage optimizations in motion planning.
How it's made fast
Simplified geometry. Represent the robot and obstacles with cheap shapes — spheres, capsules, convex hulls, oriented boxes — rather than full detailed meshes. (This is why URDF separates collision geometry from visual geometry.)
Bounding-volume hierarchies. Quick rejection: if two objects' coarse bounding boxes don't overlap, skip the detailed test.
Broad phase + narrow phase. First cheaply rule out most pairs (broad), then precisely test the few that might collide (narrow).
Libraries. FCL and similar do this efficiently and are used across the ecosystem (MoveIt, planners).
Where it lives
It underpins all motion planning — sampling planners check each sampled node and edge; trajectory optimizers turn clearance into a constraint or cost; MoveIt-style manipulation and Nav2-style navigation both rely on it (navigation often via a costmap).
Why it matters
Collision checking is the safety primitive of motion planning — the routine that keeps robots from crashing into the world or themselves. Because planners lean on it so heavily, understanding it (and why simplified geometry matters) is key to both safe and fast robot motion.
