PlanSys2 ROS2 Planning System

The Planner module is responsible for generating plans by invoking a PDDL solver. By default, it uses the popf binary. The module works by calling the solver binary and parsing its output.

The core component is the plansys2::PlannerNode class. While it inherits from rclcpp_lifecycle::LifecycleNode, its functionality is currently implemented in the active phase.

The Problem Expert module is responsible for maintaining the PDDL problem's instances, predicates, and goals. It acts as a dynamic and volatile repository of the current problem state.

Key components include:

• plansys2::ProblemExpertNode: A rclcpp_lifecycle::LifecycleNode that provides the ROS2 interface. Currently, its functionality is available in the active phase.
• plansys2::ProblemExpert: The core logic class that maintains the problem instance; it is independent of ROS2.
• plansys2::ProblemExpertClient: A client class designed to hide the complexity of ROS2 services and messages. It implements the plansys2::ProblemExpertInterface, making its API similar to the core ProblemExpert class.

To ensure consistency, the Problem Expert instantiates a plansys2::DomainExpertClient and verifies every update query against the domain to check for validity.

Instead of polling the Problem Expert for changes, you can subscribe to the /problem_expert/update_notify topic. The module publishes a std_msgs::msg::Empty message to this topic whenever any update occurs in the Problem. This allows other modules and applications to react immediately to state changes.

# Example of monitoring updates via CLI
ros2 topic echo /problem_expert/update_notify

A PDDL problem file defines the specific instance for a domain. It requires:

• Domain Reference: The name of the domain being used.
• Objects: A list of all specific entities (e.g., robots, rooms, zones) available in the problem, often categorized by their types.
• Initial State (:init): A list of predicates and facts that are true at the start of the plan (e.g., connectivity between locations, robot positions, battery status).
• Goal (:goal): A logical expression defining the state that must be achieved to complete the plan.

( define ( problem problem_1 )
( :domain plansys2 )
( :objects
	leia - robot
	room_1 room_2 - room
  corridor_1 - corridor
  zone_1_1 zone_1_2 zone_recharge - zone 
)
( :init
	( connected room_1 corridor_1 )
    ...
  ( battery_low leia )
  ( robot_at leia zone_1_1 )
)
( :goal
	( and
		( robot_at leia zone_1_2 )
	)
)
)

The Executor module manages the lifecycle of plan execution. It requests a plan from the Planner and executes it by calling action nodes in the client application.

Key responsibilities include:

• Requirement Checking: For every action, it verifies preconditions (At Start, At End, and Over all for durative actions). If requirements are not met, plan execution is cancelled.
• Effect Application: It applies the effects of completed actions.
• State Synchronization: It requests updates to the Problem Expert after actions are processed.

The execution flow involves the ExecutorNode requesting the domain and problem, obtaining a plan from the Planner, and then creating a plansys2::ActionExecutor for each individual action in that plan.

The Domain Expert module is responsible for maintaining the PDDL (Planning Domain Definition Language) domain. It consists of two main parts:

1. plansys2::DomainExpertNode: A rclcpp_lifecycle::LifecycleNode that acts as the ROS2 interface. During its configuration phase, it reads a model_file parameter, which specifies the path to the .pddl file used to define the model.
2. plansys2::DomainExpert: The core logic class that maintains the domain. This class is independent of ROS2.

While the Domain Expert is active, its internal state does not change; instead, users interact with it via ROS2 services to query information about the domain.

The primary entry point for plan execution is the plansys2::ExecutorNode class (implemented in executor_node.cpp).

Plan execution is handled via the ROS2 action /execute_plan using the plansys2_msgs::action::ExecutePlan action type. Note that the goal must already be present in the Domain Expert before requesting plan execution.

When executing a plan, the ExecutorNode creates a plansys2::ActionExecutor for each action. This object manages the lifetime of a single action and invokes the client application's implementation using the plansys2_msgs::action::ExecuteAction ROS2 action.

// The main class for plan execution
plansys2::ExecutorNode

Plansys2 is a modular planning and execution framework composed of four primary modules. To build or extend the system, you must understand the responsibilities of each:

• Domain Expert Module: Manages the domain knowledge, including actions, predicates, and functions.
• Problem Expert Module: Manages the problem instance, including objects, initial state, and goal state.
• Planner: Responsible for generating a plan based on the domain and problem provided.
• Executor: Responsible for executing the generated plan and managing the execution lifecycle.