Presentation is loading. Please wait.

Presentation is loading. Please wait.

State Transition Systems  linear planning  bounded model checking  conditional planning  model checking  state transition description languages: oPDDL.

Similar presentations


Presentation on theme: "State Transition Systems  linear planning  bounded model checking  conditional planning  model checking  state transition description languages: oPDDL."— Presentation transcript:

1 State Transition Systems  linear planning  bounded model checking  conditional planning  model checking  state transition description languages: oPDDL – named transitions, automatic creation of frame axioms, [arithmetic] ox,x’ notation- unnamed transitions, requires explicit frame axioms oSMV – unnamed transitions (by non-deterministic assignment operator), automatic creation of frame axioms, arithmetic

2 Computational Considerations  Features of a problem that influence the choice of algorithm: oSize of state space oNumber of transitions to a relevant state (possibly  ) oType of result required:  Can a state be reached where some property holds?  Will states where some property holds be reached infinitely often?  What is a sequence of transition labels to reach such a state? (sequential plan)  Does some property hold in every reachable state?  What is a control function (mapping from states to transition labels) that guarantees that some property holds in every reachable state? (conditional plan; policy)

3 Towers of Hanoi  For towers of Hanoi, the length of the solution is about the same as the number of states o2 n -1 steps and 3 n states oEach state can be reached in many ways.  It can be solved by explicitly computing the entire set of states, and using some caching scheme so states are only recorded once. oE.g.: (non-symbolic) model checking; state-space linear planner with caching oThis could work up to about 12 disks (3 12  500,000)  Graphplan / SATPLAN / bounded model checking are not well suited to towers of Hanoi, because they do not use caching.

4 Towers of Hanoi: Domain (define (domain hanoi) (:predicates (on ?disk1 ?disk2) (smaller ?disk1 ?disk2) (clear ?disk)) (:action MOVE :parameters(?disk ?source ?dest) :precondition (and (clear ?disk) (on ?disk ?source) (clear ?dest) (smaller ?disk ?dest)) :effect (and (on ?disk ?dest) (not (on ?disk ?source)) (not (clear ?dest)) (clear ?source))))

5 Problem Instance: 4 Disks (define (problem hanoi4) (:domain hanoi) (:length (:parallel 15)) (:objects D1 D2 D3 D4 P1 P2 P3) (:init (on D1 D2) (on D2 D3) (on D3 D4) (on D4 P1) (clear D1) (clear P2) (clear P3) (smaller D1 D2) (smaller D1 D3) (smaller D1 D4) (smaller D1 P1) etc. (:goal (and (on D1 D2) (on D2 D3) (on D3 D4) (on D4 P3))))

6 Solution Time  SAT Solver: Chaff  Solution length given as input DisksSolVarsClausesTime 4151,84733, sec 5316,174183,3431 min 14 sec 66318,528807,178timeout

7 Blocks World  Standard benchmark domain for search algorithms  Robot arm(s) can pick up blocks and stack them on other blocks  Straight stack constraint: at most one block can be on a block; any number can be on the table  Multiple arms operate synchronously in parallel

8 Complexity  Large state space: #blocks !  Plan existence is trivial  NP-complete to find a solution of minimum length oSingle-arm: number of actions oMultiple-arm: number of parallel steps (makespan)

9 State of the Art  Optimal planning: opre-1996: Prodigy, UCPOP, TWEAK: 5 blocks o1996: Graphplan, Satplan: 11 blocks  Blocks world has not been included in the ICAPS planning competition to date o“It is a toy problem, BW does not have the complexity of real world planning.” o“It is too hard, real world problems do not have such complex interactions between goals.”

10 Blocks World in PDDL (:predicates (on ?x ?y) (on-table ?x) (clear ?x) (arm-empty ?a) (holding ?a ?x)) (:action pick-up :parameters (?a ?obj) :precondition (and (clear ?obj) (on-table ?obj) (arm-empty ?a)) :effect (and (not (on-table ?obj)) (not (clear ?obj)) (not (arm-empty ?a)) (holding ?a ?obj)))

11 Blocks World in PDDL (:action put-down :parameters (?a ?obj) :precondition (holding ?a ?obj) :effect (and (not (holding ?a ?obj) (clear ?ob) (arm-empty ?a) (on-table ?obj)))

12 Blocks World in PDDL (:action stack :parameters (?a ?obj ?underobj) :precondition (and (holding ?a ?obj) (clear ?underobj)) :effect (and (not (holding ?a ?obj)) (not (clear ?underobj)) (clear ?obj) (arm-empty ?a) (on ?obj ?underobj)))

13 Blocks World in PDDL (:action unstack :parameters (?a ?sob ?underobj) :precondition (and (on ?obj ?underobj) (clear ?obj) (arm-empty ?a)) :effect (and (holding ?a ?obj) (clear ?underobj) (not (clear ?obj)) (not (arm-empty ?a)) (not (on ?obj ?underobj)))))

14 Problems in PDDL ;;; bw-large-a ;;; ;;; Initial: 3/2/1 5/4 9/8/7/6 ;;; Goal: 1/5 8/9/4 2/3/7/6 (define (problem bw-large-a) (:domain prodigy-bw) (:objects a1 a2) (:init (arm-empty a1) (arm-empty a2) (on 3 2) (on 2 1) etc

15 Results probblocksarmsmax var max clause sol length time a acts 0.5s b112 3,992102, acts 16s c153 13,884472, acts 1m 12s

16 Results  Solver was not given optimal time length  Results include time to create & search all shorter plans, thus proving solution is optimal oProblem A was solved by graph search alone, thus no SAT encoding created  Planner: blackbox version 4.1 oSolver: graphplan for 20 sec, then chaff oHardware: 1.6 GHz Pentium laptop


Download ppt "State Transition Systems  linear planning  bounded model checking  conditional planning  model checking  state transition description languages: oPDDL."

Similar presentations


Ads by Google