Drake

Modules  
Collision Cliques  
Collision Filter Groups  
Relationship Between Collision Filter Implementations  
In principle, collision cliques and collision filter groups are equivalent implementations of filtering.  
Input File Collision Semantics  
Future Collision Filter Features  
Collision filters are a purely nonphysical concept.
They are about computational efficiency or accommodating models which rely on approximations of physical quantities which might otherwise interfere with a meaningful interpretation of the results of geometric computations.
For example, consider a robot arm. The components of the arm can consist of intricate surfaces. In general, the more complex a surface is, the more complex the algorithms are for evaluating properties of those surfaces. Rather than including the exact surface representation for the links in the robot arm, we replace them with simpler approximations. We may pay a cost with this simplification. The approximations are generally conservative and coarser than the actual robot arm surfaces. With these approximations, it is possible for two links in the arm to report collision even if the actual links wouldn't be in collision at the same configuration. This is particularly likely for links connected by a common joint. In this case, reported collisions would be meaningless and it would be best if we simply filtered them out.
Alternatively, consider using filters as an optimization process. We may only be focused on a single aspect of the robot, e.g., footstep planning. As such, we may decide that the only contacts/collisions that are important are between the feet and the ground. An arm that swings and strikes the torso can safely be ignored. In this case, we would want to filter out all potential collisions except for those between feet and ground.
Drake provides a means for filtering collisions in cases such as these. In fact, Drake uses two different mechanisms to achieve this effect: Collision Cliques and Collision Filter Groups. The two representations are related but complementary.
Before looking at the details of the collision filter mechanisms, there are a few key principles to make note of.
Collision Elements are the basis for performing geometric collision queries. Each body has zero or more collision elements associated with (or fixed to) it. If there is no collision element associated with a body, then that body is effectively invisible with respect to contact. On the other hand, a rigid body can have multiple collision elements – a common solution for representing complex realworld shapes with a union of computationally efficient, simple shapes.
A collision element is comprised of a geometric shape and a transform. The shape can be one of a number of supported primitives (e.g., sphere, box, triangular mesh, etc.).
The collision element's geometric shape is defined with respect to its own local frame E
(e.g., a cylinder could be centered on E
's origin and the axis of the cylinder could be aligned with E
's yaxis). The body to which the collision element belongs has a body frame B
. The collision element has a transform, X_BE
, which positions the E
frame (and, therefore, the geometric shape) with respect to the B
frame.
Although collisions are defined strictly in terms of collision elements, it is often convenient to speak about colliding bodies A
and B
as shorthand for some collision element fixed to A
colliding with some collision element fixed to B
. Similarly, a model is a collection of bodies and we can speak of colliding models M
and N
as shorthand meaning that some body in M
is colliding with some body in N
.
NOTE: collision elements do not necessarily have anything to do with geometry used for other purposes, such as visualization or sensor simulation.
Fundamentally, all collisions consist of pairs of collision elements. Therefore, collision filtering similarly involves pairs of collision elements. It is not meaningful to talk about filtering a single collision element. If the intent is to eliminate that single element from consideration in any collisions, we are implicitly referring to filtering out all pairs of collision elements which include that element. (Alternatively, one could simply omit the collision element in the first place.)
It is worthwhile to think about collision filtering in a graphtheory context. We define a graph G = {V, E}
where:
V = {v₁, v₂, ..., vₙ}
is the set of graph vertices. There is one graph vertex for each collision element in the simulation.E = {e₁, e₂, ..., eₘ}
is the set of graph edges. The edge eᵢⱼ exists if the pair of collision elements (vᵢ, vⱼ) is a filtered pair.This representation is particularly helpful in discussing Collision Cliques and in comparing Collision Cliques with Collision Filter Groups.
Next topic: Collision Cliques