Speech & NLP

Knowledge Representation & Problem Solving

with

Planning Domain Definition Language (PDDL)

Vladimir Kulyukin Department of Computer Science

Utah State University

Outline

Review of Basic FOPC Concepts

PDDL Background

PDDL Problem Specification

STRIPS Semantics of PDDL Actions

Sussman Anomaly

Solving Sussman Anomaly with PDDL & BLACKBOX

Review of Basic Concepts of FOPC

● Knowledge formalization begins with a conceptualization

of the world

● Conceptualization, generally speaking, analyzes the

world in terms of objects and relations

● Functions are also relations

● Objects can be concrete (book, pen, block) or abstract

(number 2, honesty, love)

● Objects can be primitive (number 2) or abstract

(algebraic expression)

Review: Objects & Relations

● It is impossible for any conceptualization to include all objects

in the world

● Conceptualizations reside inside observers (human or

mechanical) and include only those objects that present some

interest to the observers

● Beekeepers conceptualize the world in terms bees, swarms,

beehives, honey extractors, bee disease treatments, etc.; number

theorists conceptualize the world in terms of numbers, sets,

properties of numbers, etc.

● The set of objects covered by a conceptualization is called the

universe of discourse

Review: Objects & Relations

● Once a conceptualization has objects, the observer

must establish relations among those objects

● There are two types of relations most conceptualizations

contain: functions and relations

● A set of functions in the conceptualization is called

functional basis

● A set of relations in the conceptualization is called

relational basis

Review: Functional & Relational Bases

● Conceptualizations, although they are written down,

consists of the objects and relations the observer

actually sees in the world

● The same world may have multiple conceptualizations

(e.g., blocks world can be conceptualized in terms of line

segments, curves, and their relations)

● Different conceptualizations allow/inhibit certain kinds

of knowledge (light as a wave vs. light as a particle;

geocentric vs. heliocentric universe)

Review: Conceptualizations & Observers

● A, B, C, D, E are object constants and, therefore,

terms

● Hat is a function constant

● Hat(C) is a term (functional expression)

● Hat(Hat(C)) is a term (functional expression)

● Hat(x) is a term (functional expression)

● Hat(Hat(x)) is a term (functional expression)

Review: FOPC Terms

● In FOPC, facts are stated in sentences

(aka well-formed formulas or wffs)

● Three types of sentences:

– Atomic sentences (aka atoms)

– Logical sentences

– Quantified sentences

Review: FOPC Well-Formed Formulas

PDDL Problem Specification

Background

PDDL is a standard knowledge representation (KR)

language for classical planning problems

PDDL has been the de-facto standard for several

International Planning Competitions (IPCs)

PDDL is closely related to other KR formalisms such

as ADL (Action Description Language) and APPL

(Abstract Plan Preparation Language) and MA-PDDL

(Multi Agent PDDL)

PDDL Components

Objects – actual objects in a specific domain

Predicates – statements about objects that are

true or false

Initial State – initial state of the world in a specific

domain

Goal State – final state of the world that must be

reached from the initial state

Actions (aka Operators) – specific actions used to

change states of the world

PDDL Problem Specification

Knowledge engineers must do two things to do

problem solving describe in PDDL: 1) describe a

domain and 2) describe a problem

The description of the domain is placed into a

domain file

The description of the problem is placed into

a problem file

Domain Definition

(define (domain <DOMAIN NAME>)

<REQUIREMENT>*

<PREDICATE>*

<ACTION>*

)

<REQUIREMENT>* is a statement that specifies requirements

(e.g., :typing or :equal)

<PREDICATE>* is a sequence of predication specifications

<ACTION>* is a sequence of action specifications

Problem Definition

(define (problem <PROBLEM NAME>)

<DOMAIN NAME>

<OBJECT STATEMENT>

<INITIAL STATE DESCRIPTION>

<GOAL DESCRIPTION>

)

<DOMAIN NAME> is a statement that references the domain in which the

problem must be solved

<OBJECT STATEMENT> is a sequence of object constants

<INITIAL STATE DESCRIPTION> is a sequence of predicates that describe the

initial state of the world

<GOAL DESCRIPTION> is a sequence of predicates that describe the goal state

of the world

STRIPS Semantics of PDDL Actions

STRIPS (Stanford Research Institute Planning System) is an

AI Planner developed by Richard Fikes and Nils Nilson in

1971

A STRIPS operator has preconditions (a set of predicates

that must be true in the current state of the world for the

operator to be considered application) and postconditions

(a set of predicates that will be true in the state of the

world that results from the operator’s application)

A PDDL action also has preconditions and postconditions

called effects

STRIPS Semantics of PDDL Actions

(:action <ACTION_NAME>

:parameters (?x1 ?x2 …. ?xn)

:precondition (<PREDICATE STATEMENT>*)

:effect (<PREDICATE STATEMENT>*)

)

SYMBOLIC VARIABLES

THAT BIND TO OBJECT

CONSTANTS

PREDICATE STATEMENTS THAT

MUST BE TRUE IN THE CURRENT

STATE OF THE WORLD FOR THE

ACTION <ACTION_NAME> TO

EXECUTE

PREDICATE STATEMENTS THAT WILL BE

TRUE IN THE WORLD AFTER THE ACTION

IS EXECUTED

Sussman Anomaly

Sussman Anomaly: Definition

Initial state:

(ON B T)

(ON A T)

(ON C A)

Goal State:

(ON A B)

(ON B C)

(ON C T)

The Sussman Anomaly is an AI planning problem described the MIT computer scientist Gerald

Sussman. Suppose our universe of discourse (domain) has the following object constants: A, B,

C, and T (this is the table). Suppose the robot must find a plan (sequence of actions) to

transform the initial state of the world (on the left) into the goal state (on the right) by moving

one block at a time.

PLAN

Sussman Anomaly: Definition

Initial state:

(ON B T)

(ON A T)

(ON C A)

Intermediate State:

(ON A B)

(ON B T)

(ON C T)

Suppose the robot starts working on the sub-goal (ON A B). The robot can put C

on T and then put A on B. Thus, (ON A B) is achieved. But now to achieve the

sub-goal (ON B C), the robot must un-achieve (ON A B), because B is not clear

and cannot be moved on top of C.

PUT C ON T; PUT A ON B

What Sussman Anomaly Demonstrates

The Sussman Anomaly demonstrates that sequential

achievement of goals is not always straightforward

because the achievement of one goal may clobber

a previously achieved different goal.

Solving Sussman Anomaly

with

BLACKBOX

Problem Statement

Let us solve the Sussman Anomaly with BLACKBOX, an AI

planner developed by Henry Kautz & Bart Selman

BLACKBOX can be downloaded from here

To solve a problem in BLACKBOX we must create two files:

the domain file and the problem specification file

The domain file specifies object constants, predicates,

and actions

The problem file specifies a problem we want BLACKBOX

to solve by finding a plan (i.e., a sequence of actions)

Sussman Anomaly Domain w/o Types

(define (domain sussman-anomaly)

(:requirements :strips :equality)

(:predicates (block ?x) (on ?x ?y) (clear ?x) (table ?x))

(:action MOVE_01

:parameters (?b1 ?b2 ?t)

:precondition (and (block ?b1) (block ?b2) (table ?t) (clear ?b1)

(on ?b1 ?b2) (on ?b2 ?t))

:effect (and (not (on ?b1 ?b2)) (on ?b1 ?t) (clear ?b2)))

(:action MOVE_02

:parameters (?b1 ?t ?b2)

:precondition (and (block ?b1) (block ?b2) (table ?t) (clear ?b1) (clear ?b2)

(on ?b1 ?t) (on ?b2 ?t))

:effect (and (on ?b1 ?b2) (not (on ?b1 ?t)) (not (clear ?b2))))

(:action MOVE_03

:parameters (?b1 ?t ?b2 ?b3)

:precondition (and (block ?b1) (block ?b2) (block ?b3) (table ?t)

(clear ?b1) (clear ?b2) (on ?b1 ?t) (on ?b2 ?b3)

(on ?b3 ?t))

:effect (and (not (on ?b1 ?t)) (on ?b1 ?b2) (not (clear ?b2))))

)

source code is in sa_domain.pddl

Sussman Anomaly Domain: MOVE_01

(:action MOVE_01

:parameters (?b1 ?b2 ?t)

:precondition (and (block ?b1) (block ?b2)

(table ?t) (clear ?b1)

(on ?b1 ?b2) (on ?b2 ?t))

:effect (and (not (on ?b1 ?b2)) (on ?b1 ?t) (clear ?b2)))

;;; ?b1 is a block;

;;; ?b2 is a block

;;; ?t is a table

;;; ?b1 is clear

;;; ?b1 is on ?b2

;;; ?b2 is on ?t

;;; ?b1 is not on ?b2

;;; ?b1 is on ?t

;;; ?b2 is clear

precondition

effect

Sussman Anomaly Domain: MOVE_02

(:action MOVE_02

:parameters (?b1 ?t ?b2)

:precondition (and (block ?b1) (block ?b2) (table ?t)

(clear ?b1) (clear ?b2) (on ?b1 ?t) (on ?b2 ?t))

:effect (and (on ?b1 ?b2) (not (on ?b1 ?t)) (not (clear ?b2))))

;;; ?b1 is a block;

;;; ?b2 is a block

;;; ?t is a table

;;; ?b1 is clear

;;; ?b2 is clear

;;; ?b1 is on ?t

;;; ?b2 is on ?t

;;; ?b1 is on ?b2

;;; ?b1 is not on ?t

;;; ?b2 is not clear

precondition

effect

Sussman Anomaly Domain: MOVE_03

(:action MOVE_03

:parameters (?b1 ?t ?b2 ?b3)

:precondition (and (block ?b1) (block ?b2) (block ?b3) (table ?t)

(clear ?b1) (clear ?b2) (on ?b1 ?t) (on ?b2 ?b3)

(on ?b3 ?t))

:effect (and (not (on ?b1 ?t)) (on ?b1 ?b2) (not (clear ?b2))))

;;; ?b1 is a block

;;; ?b2 is a block

;;; ?b3 is a block

;;; ?t is a table

;;; ?b1 is clear

;;; ?b2 is clear

;;; ?b1 is on ?t

;;; ?b2 is on ?t

;;; ?b2 is on ?b3

;;; ?b3 is on ?t

;;; ?b1 is not on ?t

;;; ?b1 is on ?b2

;;; ?b2 is not clear

precondition

effect

Sussman Anomaly Problem

(define (problem sa-problem)

(:domain sussman-anomaly)

(:objects A B C T)

(:init

(block A) (block B) (block C) (table T)

(on B T)

(on A T)

(on C A)

(clear B)

(clear C))

(:goal (and (on A B) (on B C))))

source code is in sa_problem.pddl

OBJECT

CONSTANTS

INITIAL STATE

OF THE

WORLD

GOAL STATE

OF THE

WORLD

BLACKBOX Planning System Output

vladimir@VladimirT3500:~/programming/planning$ ./blackbox -o

Examples/SussmanAnomaly/sa_domain.pddl -f Examples/SussmanAnomaly/sa_problem.pddl -g

Examples/SussmanAnomaly/sa_problem_plan.txt

blackbox version 43

----------------------------------------------------

Begin plan

1 (move-01 c a t)

2 (move-02 b t c)

3 (move-03 a t b c)

End plan

----------------------------------------------------

The above output is from BLACKBOX 4.3 on Ubuntu 12.04 LTS

-o specifies the domain file

-f specifies the problem file

-g specifies the file where the plan is saved

If –g is omitted, the plan (if one is found) is output in the terminal

Sussman Anomaly Domain with Types

(define (domain sussman-anomaly-typed)

(:requirements :strips :typing)

(:types BLOCK TABLE)

(:predicates (on ?x - BLOCK ?y - (either BLOCK TABLE)) (clear ?x - BLOCK))

(:action MOVE_01

:parameters (?b1 - BLOCK ?b2 - BLOCK ?t - TABLE)

:precondition (and (clear ?b1) (on ?b1 ?b2) (on ?b2 ?t))

:effect (and (not (on ?b1 ?b2)) (on ?b1 ?t) (clear ?b2)))

(:action MOVE_02

:parameters (?b1 - BLOCK ?t - TABLE ?b2 - BLOCK)

:precondition (and (clear ?b1) (clear ?b2) (on ?b1 ?t) (on ?b2 ?t))

:effect (and (on ?b1 ?b2) (not (on ?b1 ?t)) (not (clear ?b2))))

(:action MOVE_03

:parameters (?b1 - BLOCK ?t - TABLE ?b2 - BLOCK ?b3 - BLOCK)

:precondition (and (clear ?b1) (clear ?b2) (on ?b1 ?t) (on ?b2 ?b3) (on ?b3 ?t))

:effect (and (not (on ?b1 ?t)) (on ?b1 ?b2) (not (clear ?b2))))

)

source code is in sa_domain_typed.pddl

Sussman Anomaly Problems with Types

(define (problem sussman-problem-typed)

(:domain sussman-anomaly-typed)

(:objects

A - BLOCK

B - BLOCK

C - BLOCK

T - TABLE)

(:init

(on B T)

(on A T)

(on C A)

(clear B)

(clear C))

(:goal (and (on A B) (on B C))))

source code is in sa_problem_typed.pddl

BLACKBOX Planning System Output

vladimir@VladimirT3500:~/programming/planning$ ./blackbox -o

Examples/SussmanAnomaly/sa_domain_typed.pddl -f

Examples/SussmanAnomaly/sa_problem_typed.pddl -g

Examples/SussmanAnomaly/sa_problem_typed_plan.txt

blackbox version 43

----------------------------------------------------

Begin plan

1 (move-01 c a t)

2 (move-02 b t c)

3 (move-03 a t b c)

End plan

----------------------------------------------------

The output of BLACKBOX 4.3 on Ubuntu 12.04 LTS

References & Reading Suggestions

Ch 02, M. Genesereth & N. Nilsson. Logical Foundations

of AI, Morgan Kaufmann

Fikes, R., and Nilsson, N., "STRIPS: A New Approach to

the Application of Theorem Proving to Problem Solving,"

Artificial Intelligence, 2(3/4):189-208, 1971.