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.
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
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
PDDL separates a planning problem into two files
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
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)))))
Logic: liftat(f0)∧origin(p0,f0)∀p∈Ps:(served(p)∨¬boarded(p))∀p∈Ps:∀f∈Fs:(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) ) ))
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
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
Requirements
Types/Objects
Predicates
Actions
Requirements
Types/Objects
Predicates
Actions
Requirements
Types/Objects
Predicates
Actions
Requirements
Types/Objects
Predicates
Actions
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.
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
Types are written after objects
A type can be applied to multiple objects at the same time
p3 p6 - going_upp5 p3 p6 p2 p9 p1 - attendantp7 - never_alonep2 p7 - conflict_Ap0 p9 p3 p6 p1 p8 p5 p4 - conflict_Bf0 f1 f2 f3 f4 f5 f6 f7 f8 f9f10 f11 f12 f13 f14 f15 f16 f17 f18 f19 - floor
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 - objectgoing_up going_down vipgoing_nonstop attendant never_aloneconflict_A conflict_B - passengerfloor - object
"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
(:action up :parameters (?f1 - floor ?f2 - floor) :precondition (and (lift-at ?f1) (above ?f1 ?f2)) :effect (and (lift-at ?f2) (not (lift-at ?f1))))
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
Domain Reference
Additional Objects
Initial State
Goal Condition
Domain Reference
Additional Objects
Initial State
Goal Condition
Domain Reference
Additional Objects
Initial State
Goal Condition
Domain Reference
Additional Objects
Initial State
Goal Condition
(: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))
;;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))))
(: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))) ))
(: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)))
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 ...
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 ...
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 ...
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)!
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
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
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
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
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
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
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
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
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 |