Planning Scene Monitor¶
The PlanningSceneMonitor is the recommended interface for maintaining an up to date planning scene. The relationship between RobotState, CurrentStateMonitor, PlanningScene, PlanningSceneMonitor, and PlanningSceneInterface can be really confusing at first. This tutorial aims to make clear these key concepts.
The RobotState is a snapshot of a robot. It contains information about the geometry of the robot as well as a set of joint values.
The CurrentStateMonitor can be thought of as a ROS wrapper for the RobotState. It subscribes to a provided topic for JointState messages that provide up to date sensor values for single degree of freedom actuators such as revolute or prismatic joints and updates it’s internal RobotState with those joint values. In addition to the single degree of freedom joints, a robot can have joints with multiple degrees of freedom such as floating and planar joints. To maintain up to date transform information for links and other frames attached with multiple degree of freedom joints, the CSM maintains a TF2 Buffer that uses a TF2 TransformListener to set their transforms in it’s internal data.
The PlanningScene can be seen as a snapshot of the world and that includes both the RobotState and any number of collision objects. The Planning Scene can be used for collision checking as well as getting information about the environment.
The PlanningSceneMonitor wraps a PlanningScene with ROS interfaces for keeping the PlanningScene up to date. To access the PlanningSceneMonitor’s underlying PlanningScene, you can use the provided LockedPlanningSceneRW and LockedPlanningSceneRO classes.
The PlanningSceneMonitor has the following objects which have their own ROS interfaces for keeping sub-components of the planning scene up to date:
- A CurrentStateMonitor for tracking updates to the RobotState via a
tf_buffer_, as well as a planning scene subscriber for listening to planning scene diffs from other publishers.
- An OccupancyMapMonitor for tracking updates an OccupancyMap via ROS topics and services.
The PlanningSceneMonitor has the following subscribers:
collision_object_subscriber_- Listens to a provided topic for CollisionObject messages that might add, remove or modify collision objects in the planning scene and passes them into its monitored planning scene
planning_scene_world_subscriber_- Listens to a provided topic for PlanningSceneWorld messages that may contain collision object information and or octomap information. This is useful for keeping planning scene monitors in sync
attached_collision_object_subscriber_- Listens on a provided topic for AttachedCollisionObject messages that determine the attaching / detaching of objects to links in the robot state.
The PlanningSceneMonitor has the following services:
get_scene_service_- Which is an optional service to get the full planning scene state.
The PlanningSceneMonitor is initialized with:
startSceneMonitor- Which starts the
startWorldGeometryMonitor- Which starts the
planning_scene_world_subscriber_, and the OccupancyMapMonitor.
startStateMonitor- Which starts the CurrentStateMonitor and the
startPublishingPlanningScene- Which starts another thread for publishing the entire planning scene on a provided topic for other PlanningSceneMonitor’s to subscribe to
providePlanningSceneService- Which starts the
Open Source Feedback
See something that needs improvement? Please open a pull request on this GitHub page