Geometry Queries and Roles

Geometry roles help define how a real-world object is modeled in Drake.

We model the physical presence of real-world objects with geometric representations. For a single object, we can assign many different properties to the corresponding geometry depending on how the geometry is used (or what aspect of the real-world object it represents). There are many operations that can be applied to geometric representations. Each operation may only depend on some of the possible properties. Furthermore, it may be advantageous to represent a single real-world object with different geometries for different operations.

An example

A physical robot arm (such as the KUKA Iiwa) has a great deal of detail: flanges, vents, bolts, inset holes, stylistic creases, shiny paint, dull paint, lettering, etc. Furthermore, the materials the arm is made of have meaningful properties (e.g., Young's modulus, Poisson ratio, etc.) All of these taken together are part of the physical whole.

The physical arm is partially represented in Drake with geometric approximations and a set of properties which map the physical detail to the Drake's underlying mathematical models (other aspects of the arm, e.g., mass properties, are associated with the arm components as "bodies"). There are many things we may want to use this geometric representation of the arm for:

These are all meaningful operations on the virtual arm, but each operation requires a subset of the objects' properties. For example, the Young's modulus of the arm's end effector is not relevant to the external display of the state of the arm.

Beyond the relevancy of a property for any given operation, two different operations may be best served by having different geometric representations of the same physical object. For example, in modeling a bowling ball, the finger holes may not be necessary for determining contact forces and by simply representing the ball as a sphere the operation becomes much more efficient. On the other hand, a perception system for a robot that is attempting to pick up the ball and place fingers in the holes, would require a representation with the actual holes.

Geometry roles and geometry operations

Geometry roles are the Drake mechanism that allows us to represent a single real-world object with different geometries best suited to the type of operation. (Rather than a single, monolithic representation which may be ill-suited for all operations.)

Drake partitions its geometry operations into classes (in the non-C++ sense of the word) and defines a unique role for each class of operations.

Role assignment is achieved by assigning a set of role-related properties to a geometry. The properties can either be assigned to the GeometryInstance prior to registration, or after registration via the registered geometry's identifier (see SceneGraph::AssignRole()). The set can be empty. Each role has a specific property set associated with it:

Even for a single role, different consumers of a geometry may use different properties. For example, a contact model is a likely consumer of geometries with the proximity role. However, how contact is implemented may vary from model to model. Those implementations can require model-specific parameters. The ProximityProperties need to include properties compatible with all the consumers active in the system.

In such a case, each consumer should document the properties it requires and how they are organized (see GeometryProperties). The properties can be segregated by collecting their model-specific parameters into a named property group as specified by each consumer.

To make a geometry universally compatible with anything in Drake, it would provide properties for all known consumers of geometry properties (e.g., contact models, visualizers, etc.) In practice, it is sufficient to satisfy those consumers used in a particular system.

Finally, a geometry is not limited to having a single role. A geometry must always have at least one role to have any impact. But it can have multiple roles.

Generally, any code that is dependent on geometry roles, should document the type of role that it depends on, and the properties (if any) associated with that role that it requires/prefers.

Next topic: Proximity Queries