Skip to main content
Version: 8

Planning Scene & Collision Checker

In MoveIt Pro, the planning scene is the source of truth for the environment in which your robotic agents do motion planning. The planning scene contains all the information used to represent the robot and its physical environment, for use with collision checking. Overall, it includes a representation of the robot's state, the physical environment around the robot, and sensor data that can modify the planning scene, such as point clouds or occupancy maps. It can be modified using Behaviors (e.g. the AddVirtualObjectToPlanningScene behavior) in MoveIt Pro, or directly in C++ (e.g. applyPlanningScene), or via ROS2 service calls. The planning scene monitor is a wrapper over the planning scene itself that allows for thread-safe concurrent modification of the planning scene.

See the Doxygen page to read more about the planning scene and planning scene monitor.

The Allowed Collision Matrix (ACM)​

Typically we want our motion planners and controllers to check for and avoid collisions. However, there are some exceptions where we will want to skip collision checking:

  1. Disable collision checking between adjacent links in a robot whose meshes slightly overlap
  2. Disable collision checking between links in a robot model that cannot physically collide (to increase collision checking speed)
  3. Disable collision checking between objects we expect to collide (such as a gripper link and an object we are grabbing)

Your SRDF sets the default entries for the ACM that cover cases 1 and 2 via <disable_collisions> elements. You can see examples of these "Adjacent" and "Never" cases in the lab_sim srdf.

Behavior such as SetupMTCIgnoreCollisionsBetweenObjects allow you to further modify the ACM to support case 3.

Joint Groups​

Joint groups are simply a set of joints described in your SRDF. There are several ways to describe them you can learn about in the SRDF spec. Joint groups are used in several ways in MoveIt Pro and ros2_control:

  • Telling a motion planner which joints it is allowed to manipulate in the planning request.
  • Telling an IK solver which joints it is allowed to manipulate.
  • Telling our waypoint manager API which joint values should be saved for the waypoint (so your mobile base does not move when you just want to move the arm to a waypoint). For example, the lab_sim waypoint yaml file saves the desired joint_group_names.
  • Configuring certain ros2_control controllers that take in a joint group instead of a list of joints, which it uses to know which joints it should attempt to claim before executing a trajectory. For example, the velocity_force_controller has a planning_group_name parameter as seen in the lab_sim controllers configuration.

When the joint group is used in the context of motion planning, we also call it a "planning group".