htn planning · 2013. 4. 15. · htn planning radek ma r k cvut fel, k13133 16. dubna 2013 radek ma...

HTN Planning

Radek Mǎŕık

CVUT FEL, K13133

16. dubna 2013

Radek Mǎŕık ([email protected]) HTN Planning 16. dubna 2013 1 / 67

Obsah

1 Classical PlanningDefinitionProstor plánůPlánovaćı grafyPř́ıklady

2 HTN PlanningDefinitionSTNHTNSHOP, SHOP2HTN Example: API testing


Classical Planning Definition

Planning and Scheduling [Nau09]

Scheduling . . . assigns in time resources to separate processes,

Planning . . . considers possible interaction among components ofplan.

Planning

Given: the initial state, goal state, operators.

Find a sequence of operators that will reach the goal state from theinitial state

Select appropriate actions, arrange the actions and consider thecausalities

Scheduling

Given: resources, actions and constraints.

Form an appropriate schedule that meets the constraints

Arrange the actions, assign resources and satisfy the constrains.



Conceptual Model of Planning I [Nau09]

Environment

State transition system

Σ = (S,A,E, γ)

S = {states}A = {actions}E = {exogenous events}γ ={state-transition function}



Planning Task [Nau09]

Planning problem

System description Σ

Initial state or set ofstates

Initial state = s0

Objective

Goal state,set of goal states,set of tasks,“trajectory” of states,objective functionGoal state = s5



Plan [Nau09]

Classical plan

a sequence of actions

< take,move1, load,move2 >

Policy:

partial function from S into A

{(s0, take), (s1,move1),(s3, load), (s4,move2)}



Classical Planning [Nau09]

Requires all 8 restrictive assumptions

Offline generation of action sequences for a deterministic, static, finitesystem, with complete knowledge, attainment goals, and implicit time.

Reduces to the following problem:

Given (Σ, s0, Sg)Find a sequence of actions π =< a0, a1, . . . , an >, that produces asequence of state transitions < s0, s1, . . . , sn > such that sn ∈ Sg.

This is just path-searching in a graph

Nodes = statesEdges = actions

Is this trivial?



Classical Representatons [Wic11]

Planning as Theorem Provingworld state is a set of propositionsactions contains applicability conditions as a set of formulas and effectsin a form of formulas added or removed if a given action is applied,

STRIPS representationsimilar to the propositional representationliterals of the first order are used instead of propositions

a representation using state variablesstate is k-tuple of state variables {x1, . . . , xk}action is a partial function over states



Factored State Representation

World State Representation

atomic . . . state is a single indivisible entity

factored . . . state is a collection of variables



Overview of PDDL [Wic11]

Planning Domain Definition Language (PDDL)

http://cs-www.cs.yale.edu/homes/dvm/

language features (verze 1.x):

basic STRIPS-style actionsvarious extensions as explicit requirements

used to define:planning domains:

requirements,types,predicates,possible actions.

planning problems:

objects,rigid and fluent relations,initial situation,goal description.

the current version is 3.xRadek Mǎŕık ([email protected]) HTN Planning 16. dubna 2013 11 / 67

Classical Planning Prostor plánů

Prohledáváńı prostoru stav̊u vs. plánů [Wic11]

prohledáváńı stavového prostoru

prohledáváńı grafu, jehož uzly reprezentuj́ı stavy světa

prohledáváńı prostoru plánů

prohledáváńı grafu, jehož uzly reprezentuj́ı částečné plány

uzly: částečně určené plány

hrany: operace zjemněńı plánů

řešeńı: částečně uspǒrádané plány

částečný plán:

podmožina akćıpodmnožina organizačńı struktury

časové uspǒrádáńı akćızdůvodněńı: co akce znamená pro plán

podmnožina vazeb proměnných



Plánováńı v prostoru plánů - omezuj́ıćı podḿınky [Nau09]

podḿınka p̌redcházeńı

a muśı p̌redcházet b

vazebńı podḿınka

podḿınky nerovnosti, nap̌r. v1 6= v2 nebo v1 6= cpodḿınky rovnosti a substituce, nap̌r. v1 = v2 nebo v1 = c

kauzálńı vazby

použij akci a k vytvǒreńı podḿınky p poťrebné pro akci b



Řešeńı nedostatk̊u - hrozby kauzálńıch vazeb [Nau09]

Kauzálńı vazba:

vzhledem k vlastnosti relace uspǒrádáńı∀α1, α2 ∈ π : ∃x : x ∈ pre(α2) ∧ x ∈ eff(α1)⇔ α1 ≺ α2vlož́ıme kauzálńı vazbu jako relaćı splnitelnosti mezi operátoryα1

x→ α2, kde x ∈ eff(α1) ∧ x ∈ pre(α2) ∧ α1 ≺ α2čteme: α1 poskytuje x pro α2

hrozba kauzálńı vazby

negativńı hrozba kauzálńı vazby: α1q→ α3 je kauzálńı vazba v plánu

a α1 ≺ α2, α2 ≺ α3, jsou konzistentńı s plánema existuje efect p ∈ eff(α2) takový, že může smazat qpositivńı hrozba kauzálńı vazby: . . . podobně p̌ridáńı q

řešeńı hrozby

degradace (angl. demotion) α2 ≺ α1povýšeńı (angl. promotion) α3 ≺ α2omezeńım vazby proměnných



TOPLAN [Pec10]

angl. Total Order Planning

1 inicializace: Π← {{sgoal}},S← {sgoal}

toplan(s0,Π,S)

1 jestliže ∃sn ∈ S, πn ∈ Π : sgoal == sn, pak return(πn)2 jestliže S = ∅

pak return(failure)jinak

1 remove si from S a remove πi from Π2 A← {α|eff(α) ∈ si}3 S ← {s|∀α ∈ A : successor(α, s) = si}4 Ω← {π|∀α ∈ A : π = α ∪ πi}5 return(toplan(s0, append(Π,Ω), append(S, S)))



POPLAN [Pec10]

angl. Partial Order Planning (simplified)

1 inicializace: Π← {actions, {s0 ≺ sgoal}, {}, {pre(sgoal)}}2 akce α, β

poplan(Π)

1 if complete(Π) then return(Π)2 if ∃p ∈ eff(β) ∧ β ∈ openGoals(Π) a ∃α, že p ∈ eff(α)

then append(Π, {{α p→ β}, {α ≺ β}}) a remove(p, β, openGoals(Π))else return(fail)

3 if existuje kauzálńı vazba α1x→ α2 ohrožená akćı α3

then udělej jeden z následuj́ıćıch krok̊u

Promotion: return(poplan(Π⊎{α3 ≺ α1}))

Demotion: return(poplan(Π⊎{α2 ≺ α3}))

else return(poplan(Π))



TWEAK, PWEAK plánovače

1987

plánovač s částečným uspǒrádáńım:

Plány jsou reprezentovány jako částečné uspǒrádané sekvence.Závislosti mezi akcemi se zaznamenávaj́ı explicitně.Konečný plán se źıská linearizaćı částečného plánu.

Jestliže dojde k selháńı podćıle, prohledávaj́ı se pouze hraničńıpodḿınky.

Je rychlý.

sekvence s 20 metodami v několika sekundách,Bohužel, existuj́ı situace, kdy se plánovač chyt́ı do nekonečné smyčky:

smyčky p̌ri vytvá̌reńı a rušeńı objekt̊u.


Classical Planning Plánovaćı grafy

GRAPHPLAN plánovač

1997plány jsou reprezentovány pomoćı plánovaćıho grafu,

myšlenka je velmi podobná dynamickému programováńı či řešeńı tokusit́ı,

Všechny plány jsou konstruovány souběžně.rozšǐrováńı grafu (dop̌redný běh)vyhledáńı plánu (zpětný běh)

Plánovač udržuje relaci binárńı vzájemné výlučnosti (mutex) mezi uzlyrepresentuj́ıćı aplikované akce a výroky popisuj́ıćı stav.

Problém s cykleńım odstraněn.Nelze použ́ıvat parametrizované akčńı schémata (instance).

Vytvá̌ŕı obrovský prostor výrok̊u.

Existuje řada podpůrných strategíı, které podstatně urychluj́ıplánovańı.

Implementace jsou schopny zvládnout plány s 50-100 voláńımi metoddo minut.



GraphPlan - plánovaćı graf

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��



Plánovaćı grafy [Nau09]

Plánovaćı graf

Sťŕıdáńı dvou úrovńı

Si obsahuje všechny literály, které bý mohly platit v čase i

Ai obsahuje všechny akce, které mohou ḿıt splněny p̌redpoklady včase i

Mutex

mezi dvěma akcemi

nekonzistentńı efekty . . . jedna akce neguje efekt druhé akce,interference . . . efekt jedné akce je negaćı podḿınky druhé akcekonkurečńı poťreby . . . podḿınka jedné akce je neslučitelná spodḿınkou druhé akce

mezi dvěma literály

nekonzistentńı podpora . . . dva literály jsou vzájemně svou negaćınebo každý pár akćı produkućı tyto dva literály je vzájemněneslučitelný.


Classical Planning Př́ıklady

Př́ıklad - Specifikace API

pweakDefine(action(saTag::loadTags),

domain(saTag),

comment(’\%(TagsId)s are loaded from the stream

\%(StreamId)s into \%(TagGroupId)s’),

body(

parameters::(ComId #com; StreamId #stream;

TagGroupId #tagGroup; TagsId # tags;

CounterId #counter),

constraints::[],

precondition::[

(object(com, open, ComId), assumed),

(object(stream, filled, StreamId, tags, CounterId),

validated),

(stream(StreamId, start), validated),

(object(tagGroup, open, TagGroupId), assumed),

(object(tags, tagDeclaration, TagsId), assumed),

(size(tags, TagsId, CounterId), assumed)],

positive_effect::[

operation(loadTags),

object(tags, open, TagsId),

activeFlags(tags, TagsId, satActiveNone),

related(tags, TagsId, tagGroup, TagGroupId)],

negative_effect::[

object(tags, tagDeclaration, TagsId)])).



Př́ıklad - abstraktńı testovaćı skript

TESTCASEMARK

TESTCASE: [86, simpleMethodUsage]

Tested: [step(loadTags(comA, streamA, tagGroupB, tagsA, counterA),

%(TagsId)s are loaded from the stream %(StreamId)s into %(TagGroupI

begin(start)

step(declare(counter, counterA), An object must be declared)

step(declare(server, serverA), An object must be declared)

step(initilizeCom(comA), COM environment is initialized)

step(declare(tagGroup, tagGroupA), An object must be declared)

step(declareTagNames(tagNamesA, counterA), TagNames must be declare

step(createServer(comA, serverA), SATag %(ServerId)s is created)

step(createTagNames(tagNamesA), Names reference %(TagNamesId)s is e

step(declareTags(tagsA, counterA), An object must be declared)

step(createTagGroup(comA, tagGroupA, serverA), SATag %(TagGroupId)s

step(declare(stream, streamA), An object must be declared)

step(releaseServer(comA, serverA), SATag %(ServerId)s is released)

step(addTags(comA, tagGroupA, tagNamesA, tagsA, counterA), Tags %(T

step(setActivationFlags(tagGroupA, satActiveBound, tagsA), Activati

step(createStream(streamA), A stream %(StreamId)s in memory is crea

step(declare(tagGroup, tagGroupB), An object must be declared)

step(createServer(comA, serverA), SATag %(ServerId)s is created)

step(saveStream(streamA, tagGroupA, tagsA, counterA, satActiveBound

step(rewindStream(streamA), %(StreamId)s is rewinded to its begin)

step(createTagGroup(comA, tagGroupB, serverA), SATag %(TagGroupId)s

step(releaseTags(comA, tagsA, counterA), Tags %(TagsId)s are releas

step(loadTags(comA, streamA, tagGroupB, tagsA, counterA), %(TagsId)

aTEST(loadTags(comA, streamA, tagGroupB, tagsA, counterA), %(TagsId

step(releaseTagNames(tagNamesA), Reference %(TagNamesId)s is releas

step(releaseFilledStream(streamA, start, counterA), %(StreamId)s is

.....

step(uninitilizeCom(comA), COM environment is closed)

endRadek Mǎŕık ([email protected]) HTN Planning 16. dubna 2013 25 / 67


Př́ıklad - výsledný C++ kód

// ===============================================

// Test case: 441

// Created: Wed Nov 15 21:19:35 2000

// Author: Generated by TCG written by Radek Marik,

// Description:

// TagsId are loaded from the stream StreamId into TagGroupId.

void Test_441_0()

HRESULT hr = S_OK;

ISATagServer *serverA;

ISATagGroup *tagGroupA;

// SATag ’serverA’ is created.

hr = CoCreateInstance(CLSID_SATagServer, NULL, CLSCTX_ALL,

IID_ISATagServer, reinterpret_cast(&serverA));

TG_CheckHResult(hr, NULL, __uuidof(0), __LINE__ - TestRefStart_441,

ISATagRef * tagsA[counterA];

........

// ’tagsA’ are loaded from the stream ’streamA’ into ’tagGroupA’.

hr = tagGroupA->Load(streamA, counterA, tagsA);

TG_CheckHResult(hr, tagGroupA, __uuidof(tagGroupA),__LINE__ - TestR

_T("tagGroupA->Load"));

// TEST: ’tagsA’ are loaded from the stream ’streamA’ into ’tagGrou

TG_PrintResult(_T("’tagsA’ are loaded from the stream ’streamA’ int

streamA->Release();

// Release tags tagsA

for( long i = 0; i < counterA; i++) tagsA[i]->Release();

tagGroupA->Release();

// SATag ’serverA’ is released.

serverA->Release();



Implementations of planners

Initial attempts

STRIPS [1971] . . . , the first planner, regressive planning throughaction preconditions

State/Plan space

WARPLAN [1973] . . . a linear planner, Sussman anomaly solved usingaction shifting

PWEAK, TWEAK [1987], UCPOP [1992] . . . a partial order planner

Planning graphs

GRAPHPLAN[1997] . . . a breakthrough graphplan planner

Blackbox [1998] . . . combines GRAPHPLAN and SATPLAN

FF [2000] . . . a planning graph heuristics with a very fast forward andlocal search


HTN Planning Definition

Hierarchical Planning [SV10]

Hierarchical Task Net (HTN) Planning

Basic Ideas

Complex plans often have identifiable structure,

That structure can often be captured in the form of hierarchies ofabstract subplans.

Subplans are often (nearly) independent of one another.

Example

”To get to conference in ?x, get to the airport, take a plane to ?x,then get to the conference hotel”

”To get to the airport, either drive or take a cab”

”If you have enough money for the fare: To take a cab to ?y, eithercall ahead, or flag a cab down, then enter the cab, say “I want to goto ?y”, wait until at ?y, pay the fare, then exit the cab.”



HTN vs Classical Planning I [Hoa07]

Like classical planning

Each state of the world is represented by a set of atoms

Each action corresponds to a deterministic state transition

Situation calculus

(block b1) (block b2) (block b3) (block b4)

(on-table b1) (on-table b3)

(clear b2) (clear b4) (on b2 b1) (on b4 b3)



HTN vs Classical Planning Differences [Hoa07]

Classical Planning

1 Objective: to perform a set of goals

2 Terms, literals, operators, actions, plans

HTN planning

1 Objective: to perform a set of tasks

2 Terms, literals, operators, actions, planshave same meaning as classical planning

3 Added tasks, methods, task networks4 Tasks decompose into subtasks

ConstraintsBacktrack if necessary



HTN Plans: Example



HTN Planning [Hoa07]

Domain consists ofmethods and operations (SHOP-axioms)

Problem consists ofdomain,initial state,initial task network(tasks to accomplish, with some ordering of the tasks defined)

Solution - a plantotally ordered collection of primitive tasks (SHOP),partially ordered collection of primitive tasks (General HTN planner)



HTN Task [Hoa07]

Task: an expression of the form t(u1, . . . , un)t is a task symbol andeach ui is a term(variable, constant, function expression (f t1 t2 t3))

Example

(move-block ?nomove)

(move-block (list ?x . ?nomove))

Two types of tasks1 Non-primitive (compound) - decomposed into subtasks2 Primitive

cannot be decomposed,know how to perform directly,task name is the operator name

Example

(!drive-truck ?truck ?loc-from ?loc-to)



Methods and Operators (SHOP) [Hoa07]

Method:

(:method h [n1] C1 T1 [n2] C2 T2 . . . [nk] Ck Tk)

h method head - task atom with no call termsn1 OPTIONAL name for succeeding C1 T1 pairC1 conjuct - preconditionT1 task list

Operator:

(:operator h P D A)

h head - primitive task atom with no call termsP precondition list (logical atoms)D delete list (logical atoms)A add list (logical atoms)



Methods and Operators Examples (SHOP) [Hoa07]

Method: decomposes into subtasks

( : method ( d r i v e−t r u c k ? t r u c k ? l o c−from ? l o c−to )( ( same ? l o c−from ? l o c−to ) )( ( ! do−n o t h i n g ) )( )( ( ! d r i v e−t r u c k ? t r u c k ? l o c−from ? l o c−to ) ) )

Operator: achieves PRIMITIVE TASKS

( : o p e r a t o r ( ! d r i v e−t r u c k ? t r u c k ? l o c f r o m ? l o c t o )( )( ( t r u c k−at ? t r u c k ? l o c f r o m ) )( ( t r u c k−at ? t r u c k ? l o c t o ) ) )



HTN Plans [SV10]

Plan = (Tasks, Constraints)

Tasks

Primitive

Standard STRIPS-style operators“Executable”

Compound

Preconditions and EffectsMethods for decomposing operator into more detailed subplans

Details internal structure,Parameterized,Similar to macros or subroutines.


HTN Planning STN

STN and HTN [Hoa07]

STN: Simple Task Network (simplified version of HTN

1 TFD - Total-order Forward Decomposition (SHOP [NCLMA99])1 Input: tasks are totally ordered.2 Output: totally ordered plan

2 PFD - Partial-order Forward Decomposition (SHOP2)1 Input: tasks are partially ordered.2 Output: totally ordered plan

HTN: generalization of STN (NONLIN, O-PLAN, SIPE-2, UMCP)

1 More freedom about how to construct the task networks

2 Can use other decomposition procedures than just forwarddecomposition

3 Like Partial-order planning combined with STN1 Input: partial-order tasks2 Output: the resulting plan is partially ordered


HTN Planning STN

Task Network [Hoa07]

STN:

w = (U,E) . . . an acyclic graph

U . . . set of task nodes

E . . . set of edges

HTN:

w = (U,C)

U . . . set of task nodes

C . . . set of constraints (allow for generic tasks networks)

Different planning procedures


HTN Planning STN

Search Space [SV10]

Problem Reduction Search

Goal state is an abstract task to be achieved

not state of the world

Search space operators

Decompose task into subtask(s)

Parameterize task

Solve for conflicts.


HTN Planning STN

Pseudo-code for TFD [Hoa07]

TFD(s, 〈t1, . . . , tk〉, O,M)if k = 0 then return 〈〉 (i.e. the empty plan)if t1 is primitive then

active ← {(a, σ)|a is a ground instance of an operator in O,σ is a substitution such that a is relevant for σ(t1),and a is applicable to s}if active = ∅ then return failurenondeterministically choose any (a, σ) ∈ activeπ ← TFD(γ(s, a), σ(〈t2, . . . , tk〉), O,M)if π = failure then return failureelse return a.π

else if t1 is nonprimitive thenactive ← {(m,σ)|m is a ground instance of a method in M ,σ is a substitution such that m is relevant for σ(t1),and m is applicable to s}if active = ∅ then return failurenondeterministically choose any (m,σ) ∈ activew ← subtasks(m).σ(〈t2, . . . , tk〉)return TFD(s, w,O,M)


HTN Planning HTN

HTN Constraints and Plans [SV10]

Constraints

Precedence (before, after, between)

Metric temporal

Resource

Constraints at one level apply to all pairs of tasks at lower level

U = {u1, u2}; V = {v1, v2}U < V ⇒ u1 < v1;u2 < v1;u1 < v2;u2 < v2

Plans

An Abstract Plan contains compound operators

An Instantiated Plan has only primitive operators

A Fully Instantiated Plan is a totally-ordered instantiated plan withall variables bound.


HTN Planning HTN

Abstract HTN Algorithm [SV10]

HTN-plan(tasks, constraints,methods)

1 If (tasks, constraints) has no solution, return({})2 If (tasks, constraints) is an instantiated plan

Select a fully instantiated planIf such a plan exists, return it; otherwise return({})

3 Select an abstract task t ∈ tasks4 Choose an applicable m ∈ methods

where u is the task-list of m and c are the constrains mtasks = (tasks− {t}) ∪ uconstraints = constraints ∪ c

5 (tasks, constraints) = applyCritics(tasks, constraints)

6 return(HTN-plan(tasks, constraints,methods)


HTN Planning HTN

Where is the Power? [SV10]

Specification

Methods encode domain knowledge.

Methods encode problem solving knowledge

“how” rather than “what”

Abstractions encapsulate patterns of interaction

+ May be easier to specify domain

− Have to specify all possible goals (and how to achieve them)

Caveats

HTN planning, in worst case, is still NP-complete

May not terminate (recursive method expansions – may be hard todetect infinite loops)

May have to completely expand before finding plan is illegal.


HTN Planning HTN

Simple HTN Planning Extensions [SV10]

1 Threat detection

Deal with interacting goals,Find ways of reusing operators

2 Methods can include preconditions and effects

Find threats earlier in the planning process

3 Methods can indicate resource usage

Do some types of scheduling

4 Operators/Methods can include open conditions (”externalpreconditions”)

Need to use action-based (refinement) planningEnables planner to find ”novel”solutions


HTN Planning SHOP, SHOP2

Simple Hierarchical Order Planner (SHOP) [SV10]

SHOP Algorithm

Forward search, linear planner

Plans in same order as executionEssentially depth-first search

Primitive operators have no preconditions

No concurrent actions

Highly expressive operator representation (numeric calculations)

Efficient (but rather inflexible) planning algorithm



SHOP Domain Example [SV10]



SHOP, SHOP2 Applications [NAI+05]

Projects in government laboratoriesEvacuation planning,Evaluating terrorist threats,Fighting forest fires,

Industry projectsControlling multiple UAVs,Evaluating of enemy threats,Location-based services,Material selection for manufacturing

University projectsAutomated composition of Web services,Project planning,Statistical goal recognition in agent systems,Distributed planning.



Example: house building (O-Plan) [SV10]


HTN Planning HTN Example: API testing

HTN Example: OO test design1. UML model



HTN Example: OO test design2. Datapool with generated instances



HTN Example: OO test design3. Metascripts



HTN Example: OO test design4. Generated test scripts



HTN Example: OO test design5. Test set



HTN Example: OO test design6. Test records



HTN Example: OO test design7. Testing life-cycle statistics


Př́ıloha

3 Př́ılohaJSHOP2


Př́ıloha JSHOP2

JSHOP2 [Ilg06]

Atomic task

([: immediate] s t1 t2 . . . tn)

Task list

([: unordered] [tasklist1 tasklist2 . . . tasklistn])


Př́ıloha JSHOP2

JSHOP2 [Ilg06]

Operators

(: operator h P D A [c])

(: protection a)

Methods

(: method h [name1] L1 T1 [name2] L2 T2 . . . [namen] Ln Tn)


Př́ıloha JSHOP2

JSHOP2 [Ilg06]

Planning domain

(defdomain domain-name(d1 d2 . . . dn))

Planning task

(defproblem problem-name domain-name([a1,1 a1,2 . . . a1,n]) T1 . . . ([am,1 am,2 . . . am,n]) Tm)


Př́ıloha JSHOP2

References I

Hai Hoang.

Hierarchical task network (HTN) planning, lecture notes.http://www.cse.lehigh.edu/ munoz/AIPlanning/classes/HTNApril 2007.

Okhtay Ilghami.

Documentation for jshop2.Technical Report CS-TR-4694, University of Maryland, Department of Computer Science, University of Maryland,College Park, MD 20742, USA, May 2006.

D. Nau, T.-C. Au, O. Ilghami, U. Kuter, D. Wu, F. Yaman, H. Munoz-Avila, and J.W. Murdock.

Applications of shop and shop2.Intelligent Systems, IEEE, 20(2):34–41, 2005.

Dana Nau.

CMSC 722, ai planning (fall 2009), lecture notes.http://www.cs.umd.edu/class/fall2009/cmsc722/, 2009.

Dana Nau, Yue Cao, Amnon Lotem, and Hector Munoz-Avila.

Shop: simple hierarchical ordered planner.In Proceedings of the 16th international joint conference on Artificial intelligence - Volume 2, IJCAI’99, pages 968–973,San Francisco, CA, USA, 1999. Morgan Kaufmann Publishers Inc.

Michal Pechoucek.

A4m33pah, lecture notes.http://cw.felk.cvut.cz/doku.php/courses/a4m33pah/prednasky, February 2010.


Př́ıloha JSHOP2

References II

Reid Simmons and Manuela Veloso.

Planning, execution, and learning, lecture notes.http://www.cs.cmu.edu/ mmv/planning/, September 2010.

Gerhard Wickler.

A4m33pah, lecture notes.http://cw.felk.cvut.cz/doku.php/courses/a4m33pah/prednasky, February 2011.


Classical PlanningDefinitionProstor plánuPlánovací grafyPríklady

HTN PlanningDefinitionSTNHTNSHOP, SHOP2HTN Example: API testing

PrílohaPrílohaJSHOP2

htn planning · 2013. 4. 15. · htn planning radek ma r k cvut fel, k13133 16. dubna 2013 radek ma...

Documents