PDDL (Planning Domain Definition Language)

The domain file is a reusable blueprint that defines the static rules and possible actions for a class of planning problems. It contains:

• Types: A hierarchy of object categories (e.g., robot, location, package).
• Predicates: Boolean functions that describe properties and relationships between objects (e.g., (at ?r - robot ?l - location), (loaded ?r - robot ?p - package)).
• Actions: The operators that can change the state of the world. Each action is defined by its parameters, preconditions (what must be true to execute it), and effects (how it changes the state).

The problem file instantiates a specific planning challenge within a defined domain. It specifies:

• Objects: The concrete instances that exist in this particular scenario (e.g., robot1, locA, locB, package1).
• Initial State: A complete listing of all predicates that are true at the start of the planning episode. All unlisted predicates are assumed false (the closed-world assumption).
• Goal Specification: A (potentially complex) logical expression describing the set of predicates that must be true for the problem to be considered solved (e.g., (and (at package1 locB) (at robot1 locA))).

An action schema is the formal template for an operator within a PDDL domain. It is the core mechanism for state transition. Its structure is:

• Action Name & Parameters: e.g., (drive ?r - robot ?from - location ?to - location).
• Precondition: A logical formula that must hold in the current state for the action to be applicable. For example, (and (at ?r ?from) (connected ?from ?to)).
• Effect: Describes how the action modifies the state, typically using add lists (predicates that become true) and delete lists (predicates that become false), adhering to the STRIPS representation. For example, (and (not (at ?r ?from)) (at ?r ?to)).

In classical PDDL, a state is represented as a complete set of ground (instantiated) logical predicates. The planning algorithm searches through the state space—the set of all possible states reachable by applying sequences of actions. The transition between states is deterministic based on action effects. This discrete, symbolic representation is what allows for logical inference and search, distinguishing it from the continuous representations used in low-level motion planning.

PDDL supports a type system to categorize objects, enabling more concise and error-free modeling. Types can be organized in a hierarchy using inheritance (e.g., (either robot mobile-robot fixed-arm-robot)). Objects are declared in the problem file and must be instantiated from these types. This allows predicates and actions to be parameterized by type, constraining which objects can fill each parameter slot and making the domain definition more reusable and semantically clear.

While classical PDDL focuses on logical predicates, extensions exist for more complex domains:

• PDDL 2.1: Introduces numeric fluents (continuous variables like (battery-level robot1)), allowing actions to increase or decrease these values. It also adds durative actions for temporal planning, with conditions and effects that can hold at the start, end, or over the duration of an action.
• PDDL 3.0: Adds support for expressing preferences and soft constraints on plan quality, as well as state trajectory constraints that must hold over all or some states in the plan execution.

In automated fulfillment centers, PDDL models the complex interplay of resources. A domain defines:

• Objects: Robots, packages, bins, packing stations.
• Predicates: (at ?robot ?location), (in ?package ?bin), (station-free ?station).
• Actions: load, transport, unload. The planner solves for sequences that fulfill multiple orders concurrently, optimizing for makespan or travel distance. This abstracts away the continuous path planning for each Autonomous Mobile Robot (AMR), handled by a lower-layer system.

PDDL is used for automated command sequencing for satellites and rovers. The domain captures strict constraints:

• Resources: Power, data storage, instrument thermal limits.
• Temporal Constraints: Action durations and required time windows for observations.
• Concurrency: Managing parallel instrument activations within power budgets. Planners generate validated command sequences that ensure the spacecraft never violates a safety constraint, a process far more reliable than manual scripting for long-duration, complex missions.

PDDL models assembly lines and job shop scheduling. The domain defines:

• Processes: Machining, painting, assembly.
• Machines with capabilities and maintenance states.
• Parts that flow through the system. Actions represent manufacturing steps with preconditions (e.g., part-is-painted) and effects (e.g., part-is-assembled). The planner finds an order of operations that respects precedence constraints and machine availability, optimizing for throughput. This high-level plan is dispatched to PLCs and robotic workcells.

PDDL can model cyber-attack response for Security Orchestration, Automation, and Response (SOAR) platforms. The domain includes:

• System States: (compromised ?host), (firewall-up), (patch-applied ?software).
• Attacker Actions: exploit-vulnerability, escalate-privileges.
• Defender Actions: isolate-host, deploy-patch, reset-credentials. Given an alert (initial state) and a goal state (e.g., (and (not (compromised any-host)) (evidence-preserved))), the planner generates a validated response playbook, ensuring actions are taken in a logically correct order.

The Stanford Research Institute Problem Solver representation is the direct predecessor to PDDL. It established the fundamental formalism of representing:

• States as sets of logical propositions.
• Actions defined by preconditions (what must be true to execute), add lists (propositions made true), and delete lists (propositions made false). PDDL extends STRIPS with typing, conditional effects, and numeric fluents, but the core state-transition semantics remain identical.

A planning formalism that decomposes high-level tasks using a library of methods, which are recipes for breaking compound tasks into subtasks. Unlike PDDL's state-space search, HTN planning is task-reduction oriented. Key distinctions:

• Primitive Tasks map directly to executable actions (like PDDL actions).
• Compound Tasks are reduced via methods until only primitives remain.
• It inherently encodes domain-specific control knowledge, often making it more efficient for complex, structured domains like manufacturing or logistics.

The algorithmic process of computing a feasible path or trajectory for a robot from a start to a goal configuration while avoiding obstacles and respecting kinematic/dynamic constraints. It operates at a lower level than PDDL task planning.

• Path Planning: Finds a geometric route (e.g., using RRT or A*).
• Trajectory Planning: Adds timing, velocity, and acceleration profiles. Integrated Task and Motion Planning (TAMP) systems use PDDL for high-level logic and motion planners for geometric feasibility, iterating between the two.

A modular, hierarchical control architecture used to structure the decision-making logic of autonomous agents, including robots. Unlike a sequential PDDL plan, a Behavior Tree is a reactive execution model.

• Nodes represent tasks, conditions, or control flow (Sequence, Fallback, Parallel).
• It ticks from the root, traversing the tree based on success/failure of child nodes.
• Provides robust failure handling and dynamic re-planning, often used to execute the sequence of actions generated by a PDDL planner.

An extension of classical planning that explicitly reasons about time. While basic PDDL assumes instantaneous actions, temporal planning (using languages like PDDL2.1) handles:

• Action Durations.
• Concurrent Actions that can overlap in time.
• Hard Deadlines and temporal constraints between events. This is critical for real-world robotics where actions take time and must be synchronized, such as coordinating a robot arm's movement with a conveyor belt.

An advanced online control technique used for low-level robotic actuation. At each control cycle, MPC solves a finite-horizon optimization problem using a dynamic model of the system to determine optimal control inputs. It contrasts with and complements PDDL:

• Timescale: MPC operates at the millisecond level for smooth trajectory tracking; PDDL plans at the second/minute level for task sequences.
• Uncertainty: MPC explicitly handles continuous state uncertainty and disturbances.
• Integration: High-level PDDL plans can set goal states or waypoints for a low-level MPC controller to achieve.