Planen mit manuellen Hilfestellungen

Planen mit manuellen Hilfestellungen

Vorlesung Handlungsplanung

Stefan Edelkamp

1 Uberblick ¨

- Planen durch Dekomposition: Hierarchische Planung

- Planen mit nebenl ¨aufigem Pruning: Lineare Temporale Logik

2 Planen durch Dekomposition

HTN - hierarchical task network - deterministisches und gleichzeitig hierarchisches Planen

Sowohl f ¨ur propositionale als auch f ¨ur metrische und temporale Problemstellungen geeignet.

Wir beschr ¨anken uns im Wesentlichen auf propositionale Fragestellungen und gehen davon aus, das ein Plan eine Folge von Operatoren ist.

Die Planbeschreibung beinhaltet neben Aktionen jedoch nun auch Methoden zur Dekomposition von Aktionen in Teilaufgaben.

Beispielmethode

task: (transport ?p) preconditions:

(at ?p ?x)

(destination ?p ?y) (available-truck ?t) subtasks: (dispatch ?t ?x)

(load ?t ?p)

(move ?t ?x ?y) (return ?t ?x)

Hierbei sind load und move primitive Aufgaben (die Aktionen im Plan), und dispatch bzw. return weitere Methoden.

Rekursive Zerlegung

Planungsbaum: F ¨ur nicht-primitive Aufgaben w ¨ahlt das Planungsverfahren jeweils eine anwendbare Methode

Ist der entstehende Plan nicht durchf ¨uhrbar ⇒ Backtrack-Schritt.

Obwohl der Planungsprozess eigentlich Dom ¨anenunabh ¨angig ist, werden HTN Planer den dom ¨anenabh ¨angigen Planungsverfahren zugerechnet, da die HTN Methoden im Allgemeinen dom ¨anenspezifisch sind.

⇒ Problemwissen in Form von Dekompositionsregeln, die die Performanz der Planenfindung drastisch verbessern.

Eine HTN Dom ¨anenbeschreibung ist an PDDL angelehnt und besteht aus Methoden, Operatoren und Axiomen.

Operatoren

Jeder Operator zeigt auf, wie eine primitive Aufgabe ausgef ¨uhrt werden kann.

Der Kopf head(O) eine Operators O ∈ O sei der Name zusammen mit der ( ¨ublicherweise instantiierten) Parameterliste.

Operatoren k ¨onnen propositionale Vorbedingungs-, Add- und Delete-Listen, aber auch numerische Bedingungen einfordern und Ver ¨anderungen bewirken.

ADL-Konstrukte, wie Quantifikationen sind bei HTN-Planern ¨ublicherweise erlaubt (hier jedoch STRIPS)

Jeder Operator hat desweiteren Anwendungskosten, die, soweit nicht anders festgelegt, bei 1 liegen.

Methoden

Jede Methode zeigt auf, wie eine primitive Aufgabe zerlegt werden kann.

Kopf head(M) einer Mehtode M ∈ M: Name zusammen mit der ( ¨ublicherweise nicht instantiierten) Parameterliste.

Syntax: (:method head(M) p₁t₁p₂t₂ . . .) wobei jedes p_i (mitunter komplexe) Vorbedingung und jedes t_i eine (partiell geordnete) Menge von Teilaufgaben

Bedingungen werden ¨ublicherweise als if-then-else Regeln verstanden.

Hier: Vorbedingung pre(M) und Menge von Teilaufgaben sub(M)

Axiome

Axiome (: head tail) sind generalisierte Horn-Regeln, die sagen, dass der Kopf head immer dann wahr ist, wenn tail gilt.

. . . k ¨onnen benutzt werden, um zu ¨uberpr ¨ufen, ob ein Teilziel erreicht werden kann, z.B.

(:-

; head

(enough-fuel ?plane ?current-position ?destination ?speed)

; tail

(and (distance ?current-position ?destination ?dist) (fuel ?plane ?fuel-level)

(fuel-burn ?speed ?rate)

(eval (>= ?fuel-level (* ?rate ?dist)))))

Optimierungen

Externen Funktionen: z.B. Graphsuchalgorithmen aus einer Bibliothek.

Sortierung von Variablenbindungen: Ist z.B. die Vorbedingung (and (at ?here) (distance ?here ?there ?d)) gegeben dann gibt es m ¨oglicherweise viele Kombinationen von ?here, ?there und ?d, die die Bedingung erf ¨ullen.

Variablenbelegung in absteigender Reihenfolge der Werte in ?d durch:

(:sort-by ?d #> (and (at ?here) (distance ?here ?there ?d)))

Branch ’n Bound: Any-time durch Zeitlimit f ¨ur die Suche angeben, bei der der beste derzeit verf ¨ugbare Plan zur ¨uckgegeben wird.

Planungsalgorithmus

Eingabe: aktueller Zustand S, Aufgabenmenge T (inkl. Vorg ¨angerrelation ≺_p), Aktionsmenge O und Methodenmenge M.

- Menge T wird mit dem Planziel G initialisiert.

- Verfahren w ¨ahlt nichtdeterministisch eine Aufgabe ohne Vorg ¨anger aus.

1. Aufgabe einfach und kann mit nur einer Aktion erreicht werden.

⇒ suche passenden Operator, der die Vorbedingung im aktuellen Zustand S erf ¨ullt.

2. Aufgabe t ein Verbund

⇒ w ¨ahle nichtdeterministisch eine Aufteilung in Teilaufgaben.

Pseudo-Code HTN (SHOP)

Procedure HTN (S, T,O,M)

π ← ∅; T0 ← {t ∈ T | ∀t⁰ ∈ T : t⁰ 6≺_p t}

loop

if (T = ∅) return π select t ∈ T0

if (t is primitive)

A ← {(O, θ) | O ∈ O, θ unifies {head(O), t}, pre(O) ⊆ S}

if (A = ∅) return failure select (O, θ) ∈ A

S ← (S \ del(O)) ∪add(O)); π ← (π, O); T ← T \ t, apply θ T0 ← {t ∈ T | ∀t⁰ ∈ T : t⁰ 6≺_p t}

else

A ← {(M, θ) | M ∈ M, θ m.g.u. {head(M), t}, pre(M) ⊆ S}

if (A = ∅) return failure select (M, θ) ∈ A

T ← (T \ t) ∪sub(M), ∀t⁰ ∈ sub(M), t⁰⁰ ∈ T, t⁰⁰ ≺_d t : t⁰ ≺_d t⁰⁰, apply θ if (sub(M) 6= ∅)

T ← {t ∈ sub(M) | ∀t⁰ ∈ T : t⁰ 6≺ t}

3 Planen mit temporallogischen Kontrollregeln

Temporallogische Kontrollregeln sind sehr kompakte Beschreibungen zum Beschneiden des Suchraumes.

Auch wenn sie genauso effektiv f ¨ur PDDL2.1 Konstrukte angewendet werden k ¨onnen, gehen wir hier von einer pr ¨apositionaler Logik L erster Stufe aus:

- Konstanten wahr (>), falsch (⊥), - Operatoren oder (∨), und (∧), und

- Quantoren (∀, ∃) ¨uber einer Menge von Pr ¨adikaten und Funktionen.

LTL

Lineare temporale Logik (LTL) f ¨ugt zu L die temporalen Modalit ¨aten until (^S), always (), eventually (♦) und next (◦) hinzu.

LTL-Formeln beziehen sich auf Zustandsfolgen.

Dabei meint ◦f, dass Formel f in dem n ¨achsten Zustand gilt, f₁ ^Sf₂, dass f₂ entweder jetzt oder sp ¨ater gilt, davor gilt f₁, ♦^{f, dass f} jetzt oder in Zukunft gilt;

und ^{f, dass f} jetzt und in Zukunft gilt.

Abh ¨angig von der Struktur einer LTL-Formel f propagiert die Prozedur Progress die G ¨ultigkeit von f auf den Nachfolgezustand.

Pseudo-Code: Propagieren von LTL-Formeln

Procedure Progress(f, S) case of

f = φ ∈ L: f⁰ ← (S |= f)

f = f₁ ∧ f₂: f⁰ ← Progress(f₁, S) ∧ Progress(f₂, S) f = f₁ ∨ f₂: f⁰ ← Progress(f₁, S) ∨ Progress(f₂, S) f = ¬f₁: f⁰ ← ¬Progress(f₁, S)

f = ◦f₁: f⁰ ← f₁

f = f₁ ^Sf₂: f⁰ ← Progress(f₂, S) ∨ (Progress(f₁, w) ∧ f) f = ♦^f1: f⁰ ← Progress(f₁, S) ∨ f

f = ^f1: f⁰ ← P rogress(f₁, S) ∧ f

f = ∀[x : ψ(x)]f₁: f⁰ ← ^V_c:S|=ψ(x/c) Progress(f₁(x/c), S) f = ∃[x : ψ(x)]f₁: f⁰ ← ^W_c:S|=ψ(x/c) Progress(f₁(x/c), S)

Beispiel

Nehmen wir an wir wollen ^{(on a b)} in Blocks World in einem Zustand propagieren, in dem (on a b) gilt.

So erhalten wir eine Formel > ∧ ^{(on a b)}, die sich zu wieder zu ^{(on a b)} vereinfacht.

Wenn in dem urspr ¨unglichen Zustand (on a b) nicht gilt, so erhalten wir

⊥ ∧ ^{(on a b), also ⊥.}

Ein weiteres Beispiel ist die Anwendung der Formel

^{((on a b)} ⇒ ◦(clear a)) in einem Zustand, in dem (on a b) gilt

Im Nachfolgerzustand haben wir ^{((on a b) ⇒ ◦(clear a)) ∧ (clear a).}

Planungsverfahren

Eignung: sehr gut f ¨ur einen vorw ¨artssuchenden Planer

Beschreibung des Verfahrens basiert auf nichtdeterministischer Auswahl von Aktionen – Suche ergibt sich aus der systematischen Betrachtung dieser

M ¨oglichkeiten.

Suche (DFS) inkrementell, indem bestehende L ¨osungspfade verl ¨angert werden.

Korrektheit: Beendet der Algorithmus die Suche auf Pfad mit einem Endzustand, dessen Formel falsch ist ⇒ kein Nachfolgerzustand erf ¨ullt die Formel.

Vollst ¨andigkeit: Ist das der Dom ¨anenbeschreibung hinzugef ¨ugte Kontrollwissen korrekt, bleibt durch die Beschneidung die L ¨osbarkeit erhalten.

Pseudo-Code: Planen mit LTL Kontrollregeln

Procedure LTL-Plan(S, f,G,O, π) if S ⊆ G return π

f⁰ ← Progress(f, S) if f⁰ = ⊥ return failure

A ← {O ∈ O : pre(O) ⊆ S} if (A = ∅) return failure

select O ∈ A

S⁰ ← (S⁰ \ del(O)) ∪ add(O)

return LTL-Plan(S⁰, f⁰,G,O,(π, O))

Auswertung

Vollst ¨andigkeit des Planungsverfahrens z.Z. Auswertung S |= φ f ¨ur ein atemporales φ im Algorithmus Progress auch durchzuf ¨uhren

. . . wichtig, da die Formeln f ¨uber Pr ¨adikate und Funktionen definiert sind, die parametrisiert sind.

Atomische Formeln P(t₁ . . . t_n) werden dadurch ausgewertet, dass erst die Terme t₁ . . . t_n ausgewertet werden und dann die entstehende atomische Proposition.

⇒ nehme Menge V von Variablenbindungen an und definiere einen Algorithmus Eval, der testet, ob (S, V ) |= φ gilt.

Auswerten von Formeln

Procedure Eval(f, S, V ) case of

f = P(t₁ . . . t_n):

return EvalAtomic(P(EvalTerm(t₁, S, V ), . . . ,EvalTerm(t_n, S, V ))) f = f₁ ∧ f₂: return Eval(f₁, S, V ) ∧ Eval(f₂, V, S)

f = f₁ ∨ f₂: return Eval(f₁, S, V ) ∨ Eval(f₂, V, S) f = ¬f₁: return ¬Eval(f₁, S, V )

Quantoren

Am schwierigsten gestaltet sich die Behandlung von Quantoren f = ∀[x : ψ(x)]f₁ und f = ∃[x : ψ(x)]f₁.

Hierbei muss:

- die Menge der Variablenbindung successiv f ¨ur jede m ¨ogliche Belegung c der Variablen x erweitert werden (V ∪ {x = c}) und

- die Konjunktion bzw. Disjunktion der Ausdr ¨ucke ausgewertet werden.

Beispiel

Einige typische Kontrollregeln in der Briefcase-Dom ¨ane sind:

• Bewege die Brieftasche nicht vom derzeitigen Ort, wenn es Objekte gibt, die hinein- oder hinausbef ¨ordert m ¨ussen.

• Bewege kein Objekt aus der Brieftasche, wenn es nicht am Zielort ist.

• F ¨uge kein Objekt der Brieftasche hinzu, dass nicht in die Brieftasche bef ¨ordert werden muss.

PDDL-verwandter Notation

(always

(forall (?l) (at briefcase ?l) (forall (?x) (at ?x ?l)

(implies (not (= ?x briefcase)) (and

(implies (goal (at ?x ?l)) ;; 1a

(until (at briefcase ?l) (not (in-briefcase ?x)))) (implies (not (goal (at ?x ?l))) ;; 1b

(until (at briefcase ?l) (in-briefcase ?x)))

(implies (and (in-briefcase ?x) (not (goal (at ?x ?l)))) (next (in-briefcase ?x)))

(implies (and (goal (at ?x ?l)) (not (in-briefcase ?x))) (next (not (in-briefcase ?x)))))))))

Bemerkungen

Der wohl bekanntest HTN-Planer ist das SHOP-System von Nau et al., der auf den internationalen Planungswettbewerben 2000 und 2002 bei den “Hand-Coded”

Planern erfolgreich war.

Temporallogisches Planen wurde von Kabanza und Bacchus eingef ¨uhrt.

In den internationalen Planungs-Wettbewerben 2000 und 2002 wurden die Planer TL-plan (Bacchus et al.) und TAL-Plan (Doherty et al.) beste “Hand-Coded Planer”

ausgezeichnet.

Ublicherweise waren die Kontrollregeln so stark, dass im Planungsprozess keine¨ oder kaum Backtracking-Schritte notwendig waren.