Processing math: 100%
+ - 0:00:00
Notes for current slide
Notes for next slide

Artificial Intelligence

PDDL

1 / 47

Planning

2 / 47

Reminder: The Planning Problem

A planning problem consists of three parts:

  • A definition of the current state of the world

  • A definition of a desired state of the world

  • A definition of the actions the agent can take

All of these definitions are done in "some" formal language.

3 / 47

The Planning Domain Definition Language (PDDL)

  • In The Olden Days every planner used their own input format

  • The formats not only differed in syntax, but also in capabilities

  • In 1998 Drew McDermott and colleagues developed a standardized language for planning problems: PDDL

  • This made comparisons between different planners easier and lead to the creating of the International Planning Competition

4 / 47

PDDL Influences

  • STRIPS, represented operators as preconditions, additions and deletions

  • Other languages, such as ADL, supported a wider variety of formulas as preconditions and effects

  • The idea of actions having "preconditions", that describe when they are applicable, and "effects" that describe what is changed, was common to many of them

  • The "core" of PDDL is therefore the definition of actions

5 / 47

PDDL Layout

  • PDDL separates a planning problem into two files

    • The domain, which defines how the actions operate
    • The problem, which defines the initial state and the goal
  • The idea is that the domain can be reused for many different problems

  • Since historically many planners were written in LISP, PDDL uses the same basic syntax: S-Expressions

6 / 47

S-Expressions

  • Simply put, an S-Expression consists of parenthesized list, where each element can be either a literal string or another S-Expression

  • (Classically S-Expressions are defined as having two elements, which are concatenated with a period ., but this is not commonly explicitly used anymore)

  • For example, these are all valid S-Expression:

()
(and (or (not a) b (and (not x) c d e) e))
(defun fib (n) (if (lt n 2) 1 (+ (fib (- n 1)) (fib (- n 2)))))
7 / 47

S-Expressions and Logic

Logic: liftat(f0)origin(p0,f0)pPs:(served(p)¬boarded(p))pPs:fFs:(when(liftat(f)origin(p,f))boarded(p))

(and (lift-at f0) (origin p0 f0))
(forall (p - Ps) (or (served p) (not (boarded p))))
(forall (p - Ps) (forall (f - Fs)
(when (and
(liftat f)
(origin p f)
)
(boarded p)
)
)
)
8 / 47

S-Expressions

  • Why are S-Expressions useful?

  • They are very simple to parse, and we can use them to represent syntax trees

  • Remember when we discussed how one would implement logic? We can basically take S-Expressions and directly use them with these data structures

9 / 47

Structure of a PDDL Domain File

  • Now we have our PDDL domain file as a parse-tree

  • Let's extract the individual parts

  • For each part we have to do some processing

  • After all processing, we have our domain

10 / 47

Structure of a PDDL Domain File

  • Requirements

  • Types/Objects

  • Predicates

  • Actions

11 / 47

Structure of a PDDL Domain File

  • Requirements

  • Types/Objects

  • Predicates

  • Actions

12 / 47

Structure of a PDDL Domain File

  • Requirements

  • Types/Objects

  • Predicates

  • Actions

13 / 47

Structure of a PDDL Domain File

  • Requirements

  • Types/Objects

  • Predicates

  • Actions

14 / 47

Extensions: "Requirements"

  • PDDL is a standard, but it allows for several extensions

  • In lab 3 you will use

    • :strips
    • :typing
    • :adl, which is an abbreviation for :disjunctive-preconditions, :equality, :existential-preconditions, :universal-preconditions, and :conditional-effects
  • There are many other extensions, related to numbers, temporal planning, probabilistic effects, etc.

15 / 47

Types

  • Objects and variables in PDDL can have types

  • Types form a hierarchy, with a root type containing all objects

  • We need to store these types so we can expand variables in e.g. forall expressions

16 / 47

Types

  • Types are written after objects

  • A type can be applied to multiple objects at the same time

p3 p6 - going_up
p5 p3 p6 p2 p9 p1 - attendant
p7 - never_alone
p2 p7 - conflict_A
p0 p9 p3 p6 p1 p8 p5 p4 - conflict_B
f0 f1 f2 f3 f4 f5 f6 f7 f8 f9
f10 f11 f12 f13 f14 f15 f16 f17 f18 f19 - floor
17 / 47

Type Hierarchy

  • Similar to giving types to objects, types can also be "applied" to other types

  • This is used to create a type hierarchy, by saying "everything that has type X or Y also has type Z" by writing X Y - Z

passenger - object
going_up going_down vip
going_nonstop attendant never_alone
conflict_A conflict_B - passenger
floor - object
18 / 47

Actions

  • "Actions" in PDDL are actually operators

  • That means they contain free variables, or parameters (often with types)

  • Each operator may represent multiple actions

  • Additionally, each operator contains a precondition and an effect

19 / 47

Action Example

(:action up
:parameters (?f1 - floor
?f2 - floor)
:precondition (and (lift-at ?f1)
(above ?f1 ?f2))
:effect (and (lift-at ?f2)
(not (lift-at ?f1)))
)
20 / 47

Structure of a PDDL Problem File

  • The domain defines the available operators of the world

  • The problem defines the initial state and the goal condition

  • Objects may be spread out over both files

21 / 47

Structure of a PDDL Problem File

  • Domain Reference

  • Additional Objects

  • Initial State

  • Goal Condition

22 / 47

Structure of a PDDL Problem File

  • Domain Reference

  • Additional Objects

  • Initial State

  • Goal Condition

23 / 47

Structure of a PDDL Problem File

  • Domain Reference

  • Additional Objects

  • Initial State

  • Goal Condition

24 / 47

Structure of a PDDL Problem File

  • Domain Reference

  • Additional Objects

  • Initial State

  • Goal Condition

25 / 47

PDDL Example: Elevator

26 / 47

Domain: Types and Predicates

(:types
passenger - object
floor - object
)
(:predicates
(origin ?person - passenger ?floor - floor)
(destin ?person - passenger ?floor - floor)
(above ?floor1 - floor ?floor2 - floor)
(boarded ?person - passenger)
(served ?person - passenger)
(lift-at ?floor - floor)
)
27 / 47

Domain: Drive Up and Down

;;drive up
(:action up
:parameters (?f1 - floor ?f2 - floor)
:precondition (and (lift-at ?f1) (above ?f1 ?f2))
:effect (and (lift-at ?f2) (not (lift-at ?f1)))
)
;;drive down
(:action down
:parameters (?f1 - floor ?f2 - floor)
:precondition (and (lift-at ?f1) (above ?f2 ?f1))
:effect (and (lift-at ?f2) (not (lift-at ?f1)))
)
28 / 47

Domain: Stop at Floor

(:action stop
:parameters (?f - floor)
:precondition (lift-at ?f)
:effect (and
(forall (?p - passenger)
(when (and (boarded ?p)
(destin ?p ?f))
(and (not (boarded ?p))
(served ?p))))
(forall (?p - passenger)
(when (and (origin ?p ?f) (not (served ?p)))
(boarded ?p)))
)
)
29 / 47

Problem

(:objects p0 - passenger
f0 f1 - floor)
(:init
(above f0 f1)
(origin p0 f1)
(destin p0 f0)
(lift-at f0)
)
(:goal (forall (?p - passenger) (served ?p)))
30 / 47

Planners

31 / 47

Running a Planner

  • Most planners will provide you with some executable that expects two parameters: a domain file, and a problem file

  • Some will then perform some preprocessing step and translate the problem into some internal representation, and you may have to run a second executable on that

  • Then you wait ...

32 / 47

Running a Planner

  • Most planners will provide you with some executable that expects two parameters: a domain file, and a problem file

  • Some will then perform some preprocessing step and translate the problem into some internal representation, and you may have to run a second executable on that

  • Then you wait ...

  • And wait ...

33 / 47

Running a Planner

  • Most planners will provide you with some executable that expects two parameters: a domain file, and a problem file

  • Some will then perform some preprocessing step and translate the problem into some internal representation, and you may have to run a second executable on that

  • Then you wait ...

  • And wait ...

  • And wait ...

34 / 47

Running a Planner

  • Most planners will provide you with some executable that expects two parameters: a domain file, and a problem file

  • Some will then perform some preprocessing step and translate the problem into some internal representation, and you may have to run a second executable on that

  • Then you wait ...

  • And wait ...

  • And wait ...

  • And then you get a solution (or not)!

35 / 47

Some Planners

36 / 47

Plans

  • So you run a planner and it finishes

  • The output will be a "plan"

  • However, unlike for the input, there is no real standard for the output

  • Some/most planners will print the required actions in a PDDL/LISP-like syntax

37 / 47

planning.domains

  • Since planning is a very active field of research, there are many planning domains out there

  • planning.domains contains a collection of known domains, drawing from planning competitions and other sources

  • All of the files in that repository are PDDL files

  • However, they may require various extensions

38 / 47

Lab 1 and Onward

39 / 47

Lab 1

  • I have graded lab 1

  • Overall, you did really well! Good job!

  • Grades and feedback should be accessible to you on blackboard

  • I want to provide some clarifications

40 / 47

An API

  • If you go into software development, you will often have to implement against specifications

  • Usually, such specifications include (at least) what a function takes as parameters and should return

  • By sticking with this specification, other people can (re-)use your code!

  • For example, if you accept any Node, and return a list of Edge objects, someone can use your algorithms in arbitrary contexts

41 / 47

My tests

  • Several of my tests were based on blocksworld/planning

  • Each node was an arrangement of blocks on the table/gripper

  • Edges represented actions taken by the robot

  • Your pathfinding algorithms searched for solutions, including for the Sussman Anomaly

42 / 47

Path Extraction

  • The returned value (= list of Edge objects) was supposed to be a path

  • This means that an agent should be able to follow Edge after Edge from the returned list

  • As discussed in class, your algorithms need to keep track of how each node was reached, and extract the path from this

  • Let's look at another example

43 / 47

Example

44 / 47

Format

  • One zip file with everything!

  • Report: pdf

  • In your report, make sure to actually answer the questions

  • If you are asked to compare or analyze something, provide data

45 / 47

The Future

  • Thursday, 3/11: Some fun applications of Logic

  • Tuesday, 3/16: Review for the midterm

  • Thursday, 3/18: Midterm

  • Tuesday, 3/23: Lab 3 presentation

46 / 47

Planning

2 / 47
Paused

Help

Keyboard shortcuts

, , Pg Up, k Go to previous slide
, , Pg Dn, Space, j Go to next slide
Home Go to first slide
End Go to last slide
Number + Return Go to specific slide
b / m / f Toggle blackout / mirrored / fullscreen mode
c Clone slideshow
p Toggle presenter mode
t Restart the presentation timer
?, h Toggle this help
Esc Back to slideshow