MoveIt! defines several type of constraints, which are detailed below. Every type of constraint has a weight parameter, and checking for constraints will return a boolean value indicating whether the constraint is satisfied, and a “distance” (better thought of as cost) from perfect constraint satisfaction. The distance is computed by multiplying the weight parameter with some relevant metric of constraint satisfaction; different constraint types use different metrics.

joint constraints: specify a value and an interval around this value that a joint should be at. A JointConstraint message contains the following:

• joint_name
• position, the joint value to reach
• tolerance_above and tolerance_below
• and the weight parameter.

If joint_name is not a recognized joint name, the constraint evaluates to perfectly satisfied.

position constraints: specify a region that a given link reference point should be at. A PositionConstraint message contains:

• header (whose frame_id specifies the frame name in which the poses for the constraint region shapes are given)
• link_name
• target_offset which is a Vector3 message giving the target point in the link_name frame
• constraint_region, which is a BoundingVolume message containing:
  • primitives
  • primitive_poses
  • meshes
  • mesh_poses, all of which are vectors of messages specifying primitives (BOX, SPHERE, CYLINDER or CONE), meshes, and their poses in the frame given by frame_id from the PositionConstraint header
• and the weight parameter.

The constraint is satisfied if the link reference point is in at least one of the regions specified by constraint_region. The “distance” part of the result is then the weight multiplied by the distance between the link's reference point and the target point in the constraint. If link_name is not recognized or constraint_region is empty, then the constraint is considered perfectly satisfied.

orientation constraints: specify an orientation for a link, with tolerances in the Roll-Pitch-Yaw angles. An OrientationConstraint message contains:

• header (whose frame_id names the frame in which the orientation is given)
• link_name
• orientation
• absolute_{x, y, z}_axis_tolerance give the tolerances for roll, pitch, and yaw respectively
• and the weight parameter.

The constraint is satisfied if the link orientation RPY value doesn't differ from the target one by amounts larger than those given by the tolerances. The “distance” part of the result is then the weight multiplied by the sum of absolute values of the errors in roll, pitch, yaw. If link_name is not recognized, the constraint is considered to be satisfied perfectly.

visibility constraints: test whether the robot can see a specified region. IMPORTANT: only tests whether the robot obstructs its own line of sight, does not take into account world objects or sensor minimum/maximum range. For the latter, use PositionConstraint. A VisibilityConstraint message contains:

• target_radius, the radius of the area to see
• target_pose, pose-stamped of the area center that should be seen, includes orientation
• cone_sides, number of sides to approximate the base of a visibility cone with
• sensor_pose, pose-stamped of the sensor
• max_view_angle, highest tolerated incidence angle of rays from the sensor to the area center
• max_range_angle, highest angular size that the target area is allowed to occupy in the sensor's field of view
• sensor_view_direction, 0 for Z, 2 for X
• and the weight parameter.

The constraint is satisfied if there is no collision between a visibility cone (placed between the sensor and the target) and the robot, AND the incidence angle of the ray to the target area center is below max_view_angle, AND the target area occupies less than max_range_angle from the sensor's field of view, AND the sensor faces toward the target area. If these conditions apply, the constraint is considered perfectly satisfied.

If the angle conditions are met, but there is a collision between the visibility cone and the robot, then the constraint fails, and the “distance” part of the result is the depth of the collision (NOTE: not multiplied by the weight parameter, which may be a MoveIt! bug). If one of the angle conditions fails, then the constraint fails, and the “distance” part of the result is set to 0.

If the target radius is on the order of machine epsilon or smaller, the constraint is considered perfectly satisfied.