IFT 702 – Planification en intelligence artificielle

Planification par recherche heuristique dans un espace d’états

Froduald KabanzaDépartement d’informatique

Université de Sherbrookeplaniart.usherbrooke.ca/kabanza/cours/ift702

Contenu• Rappels

• Architecture d’un planificateur utilisant comme solveur une recherche dans un espace d’états

• Langage de modélisation STRIPS et transformation correspondante pour un solveur par recherche dans un espace d’états

• Langage de modélisation PDDL transformation correspondante pour un solveur par recherche dans un espace d’états

Rappel – un planificateur est un solveur de modèle

observations buts

action

WorldExécution de l’action

PlanPlanificateur

Modèle d’actions, capteurs et buts

observations buts

Rappel – Hypothèses sur le domaineLes hypothèses du domaine à considérer sont:

– Un seul agent vs plusieurs agents– Déterministe vs stochastique– Complétement observable vs partiellement observable

Nous supposons dans un premier un temps que l’environnement est déterministe, complètement observable, avec un seul agent pour qui on planifie.

Un algorithme défini avec ces hypothèse peut néanmoins être appliqué dans un environnement ne satisfaisant pas les deux premières:

– L’incertitude est géré par l’architecture décisionnelle en re-planifiant– Un planificateur déterministe centralisé peut planifier pour plusieurs agents

Architecture générale d’un planificateur opérant par recherche dans un espace d’états

Modèle (actions, buts)

Fonction de transition

Recherche heuristique dans

un graphe d’états

Plan (Séquence d’actions)

ButÉtat initial

• Le modèle ne décrit pas les capteurs puisque l’environnement est déterministe.

• Le modèle est transformé en fonction de transition pour un graphe d’états.

Un robot doit empiler des blocs dans une configuration indiquée. C’est une version simplifiée d’un robot de manipulation de conteneurs dans un port.

Exemple 1: Monde des blocs

Exemple 2: Livraison de colis

Un robot doit recevoir des commandes de livraisons de colis et les exécuter.

r1 (chambre) r2 (chambre)

c1 (corridor)

r4 (cuisine)r3 (s. bain)

c2 (corridor)

Colis 1Colis 2

d11 d12 d23 d24

Exemple 1 : Empiler des blocs

• Étant donné un modèle d’actions primitives (prendre un block, relâcher un bloc, etc.), trouver un plan pour attendre le but.

• Le problème est transformé en un problème de trouver un chemin dans un graphe dirigé.

Exemple 2 : Livrer des colis

• Étant donné un modèle d’actions primitives (prendre un colis, relâcher un bloc, se déplacer d’une pièce à l’autre), trouver un plan pour attendre le but.

• Le problème est transformé en un problème de trouver un chemin dans un graphe dirigé.

r1 r2 r3 r4

r5 r6

r1 r2 r3 r4

r5 r6

État initial But

robot

Goto(r5,r1)

Goto(r5,r2

)

…

Take

(…)

Goto(…)…

… … … …

… …

Rappel - Comment trouver un chemin dans un graphe?

• Non informé: Largeur, profondeur, iterative deepening, Dijkstra, etc.

• Ces algorithmes ne sont pas efficaces pour des problèmes qui nous intéressent. Ils n’ont aucun sens de direction.

• Le sens de direction est donné par une fonction heuristique.

• Recherche heuristique dans un graphe– Best-first: (f(x) = α*g(x) + β*h(x))

oα = 0: algorithme glouton (greedy)oβ = 0: uniform-costoα = β: A*

• Défi: trouver une fonction heuristique h(x)

Froduald Kabanza 12IFT615

• A* est une extension de l’algorithme de Dijkstra – Utilisé pour trouver un chemin optimal dans un graphe via l’ajout d’une

heuristique

• Une heuristique h(n) est une fonction d’estimation du coût entre un nœud n d’un graphe et le but (le nœud à atteindre)

• L’heuristique donne un sens de direction à l’exploration de l’espace d’états.

• Le temps de calcul de A* et la qualité de la solution (proximité à la solution optimale) dépendent beaucoup de la qualité de l’heuristique.

Rappel - Algorithme A* (IFT 615)

Froduald Kabanza 13IFT615

• Entrée de A*– État initial (l’état courant)– État final (le but)– Fonction de transition : successeur(état, action)– Fonction de cout : cout(état,successeur)– Fonction heuristique: h(état)

• Sortie: chemin entre l’état initial et l’état final. Le chemin est optimal si l’heuristique est admissible.

• Les fonctions sont définies une seule fois pour un domaine. Elles définissent le domaine. L’état initial et le but spécifie un problème dans le domaine.

Rappel - Algorithme A* (IFT 615)

© Froduald Kabanza 14IFT702

Langages de modélisation

• STRIPS est un langage très simple, classique:– Pas moyen de spécifier des contraintes sur la durée des actions– Pas moyen de spécifier des effets conditionnels– Pas moyen de spécifier des contraintes numériques

• PDDL (Planning Domain Definition Language) :– Une extension de STRIPS levant les restrictions précédentes– Un “standard” pour les compétitions sur des algorithmes de

planification (conférence ICAPS)– La BNF de PDDL 3.

Transformation du modèle pour avoir une fonction de transition

Langage STRIPS

(:action unstack :parameters (?x – block ?y - block) :precondition (and (on ?x ?y) (clear ?x) (handempty) :effects (and (not (on ?x ?y)) (not (clear ?x)) (not (handempty)) (holding ?x) (clear ?y))

(:action stack :parameters (?x – block ?y - block)

:precondition (and (holding ?x) (clear ?y)):effects (and (not (holding ?x)) (not (clear ?y))

(on ?x ?y) (clear ?x) (handempty))

(:action pickup :parameters (?x – block) :precondition (and (ontable ?x) (clear ?x) (handempty) :effects (and (not (ontable ?x)) (not (clear ?x)) (not (handempty)) (holding ?x))

(:action putdown:parameters (?x – block) :precondition (holding ?x) :effects (and (not (holding ?x)) (ontable ?x) (clear ?x) (handempty))

Exemple STRIPS pour le monde des blocksc

a b

ca b

c

a b

c

ab

c

a b

Exemple STRIPS pour la livraison de colis

r1 (room) r2 (room)

c1 (corridor)

r4 (room)r3 (room)

c2 (corridor)

d11 d12 d23 d24

b1 b2

b3

b4

b5

(:objects b1 b2 b3 b4 b5 - ball left right – gripper r1 r2 r3 r4 – room c1 c2 - corridor)(:init (atRobot c2) (free left) (free right) (at b1 r2) (at b2 r2) (at b3 r2) (at b4 r3) (at b5 r3))(:goal (at b1 r4) (at b2 r4) (at b3 r4) (at b4 r4) (at b5 r4))(:goal (forall (?x - ball)(at ?x r4)))

Exemple STRIPS pour la livraison de colis, suite(define (domain robotWorld1) (:types gripper ball room corridor door) (:predicates atRobot at free holding connects) (:action pick :parameters (?b – ball ?g – gripper ?r – room) :precondition (and (at ?b ?r) (atRobot ?r) (free ?g)) :effect (and (holding ?g ?b) (not (at ?b ?r)) (not (free ?g))))

(:action release :parameters (?b – ball ?g – gripper ?r – room) :precondition (and (holding ?g ?b) (atRobot ?r)) :effect (and (at ?b ?r) (not (holding ?g ?b)) (free ?g)))

(:action move :parameters (?rf ?rt – room ?d - door) :precondition (atRobot ?rf) (connects ?d ?rf ?rt) :effect (and (atRobot ?rt) (not (atRobot ?rf))))

Exemple PDDL pour la livraison de colis

r1 (room) r2 (room)

c1 (corridor)

r4 (room)r3 (room)

c2 (corridor)

d11 d12 d23 d24

b1 b2

b3

b4

b5

(:objects r1 r2 r3 r4 – room c1 c2 - corridor)

(:init (atRobot r2) (= (free) 2) (= (holding) 0) (= (atBalls r3) 2)(= (atBalls r2) 3)

(:goal (= (atBalls r4) 5))

(define (domain robotWorld2) (:types ball room corridor) (:predicates at atRobot)

(:action pickup :parameters (?r – room) :precondition (and (> (atBalls ?r) 0) (atRobot ?r) (> (free) 0)) :effect (and (increase (holding) 1) (decrease (atBalls ?r) 1)

(decrease (free) 1))) (:action release :parameters (?r – room) :precondition (and (> (holding) 0) (atRobot ?r)) :effect (and (increase (atBalls ?r) 1) (decrease (holding) 1) (increase (free) 1))) (:action move :parameters (?rf ?rt – room ?d - door) :precondition (and (atRobot ?rf)(connects ?d ?rf ?rt))) :effect (and (atRobot ?rt) (not (atRobot ?rf))))

Exemple PDDL pour la livraison de colis, suite

r1 (room) r2 (room)

c1 (corridor)

r4 (room)r3 (room)

c2 (corridor)

d11 d12 d23 d24

b1 b2

b3

b4

b5

(:objects b1 b2 b3 b4 b5 - ball left right – gripper r1 r2 r3 r4 – room c1 c2 - corridor)(:init (atRobot c2) (free left) (free right) (at b1 r2) (at b2 r2) (at b3 r2) (at b4 r3) (at b5 r3))(:goal (at b1 r4) (at b2 r4) (at b3 r4) (at b4 r4) (at b5 r4))(:goal (forall (?x - ball)(at ?x r4)))

Une autre version PDDL pour la livraison de colis

Une autre version PDDL pour la livraison de colis(define (domain robotWorld3) (:types gripper ball room corridor door) (:predicates atRobot at free holding connects) (:action pick :parameters (?b – ball ?g – gripper ?r – room) :precondition (and (at ?b ?r) (atRobot ?r) (free ?g)) :effect (and (holding ?g ?b)(not (free ?g))))

(:action release :parameters (?b – ball ?g – gripper ?r – room) :precondition (and (holding ?g ?b) (atRobot ?r)) :effect (and(not (holding ?g ?b)) (free ?g)))

(:action move :parameters (?rf ?rt – room ?d - door) :precondition (atRobot ?rf) (connects ?d ?rf ?rt) :effect (and (atRobot ?rt) (not (atRobot ?rf))) (forall (?b – ball ?g - gripper) (when (holding ?b ?g) (and (not (at ?b ?rf)) (at ?b ?rt)))))

© Froduald Kabanza 23IFT702

Autres exemples

• Voir International Planning Competition–http://ipc.icaps-conference.org/

Ce qu’il faut retenir

• Nous venons de voir le langage de modélisation PDDL et son cas simple (STRIPS)

• Nous avons vu une transformation assez simple d’un modèle PDDL en une fonction de transition pour un graphe d’états.

• Cela nous a permis d’utiliser une recherche dans un graphe comme solveur, particulièrement A*.

• Pour l’instant, le seul avantage perceptible d’avoir un modèle PDDL (au lieu d’une fonction de transition normale) est de représenter la fonction de transition de façon compacte.

• Un autre avantage que nous voyons dans la leçon suivante est l’extraction d’heuristiques.

Prochaine leçon

• Nous verrons l’extraction d’heuristiques à partir d’un modèle.

• Devoir permettant de se familiariser avec PDDL et un planificateur basé sur PDDL et la recherche heuristique dans un espace d’états.

• Voir le plan de cours pour plus de détails.