IFT 702 – Planification en intelligence artificielle Planification par recherche heuristique dans un espace d’états Froduald Kabanza Département d’informatique.

Présentation au sujet: "IFT 702 – Planification en intelligence artificielle Planification par recherche heuristique dans un espace d’états Froduald Kabanza Département d’informatique."— Transcription de la présentation:

1 IFT 702 – Planification en intelligence artificielle Planification par recherche heuristique dans un espace d’états Froduald Kabanza Département d’informatique Université de Sherbrooke planiart.usherbrooke.ca/kabanza/cours/ift702

2 vendredi 31 mars 2017 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

3 Rappel – un planificateur est un solveur de modèle
observations buts observations buts action Planificateur Plan Le comportement du robot résulte de l’ Il est autonome en ce sens qu’il peut ajuster son mécanisme de choix d’actions à des situations non progrannées explicitement en générant un nouveau plan– toute fois, cela est limité par son modèle. Modèle d’actions, capteurs et buts Exécution de l’action World

4 Rappel – Hypothèses sur le domaine
vendredi 31 mars 2017 Rappel – Hypothèses sur le domaine Les 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

5 vendredi 31 mars 2017vendredi 31 mars 2017
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. L’agent est le seul acteur du changement. Pour les mêmes raison, le plan est une séquence d’actions. 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.

6 Exemple 1: Monde des blocs
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. On dit au robot quoi faire (le but) Exemple: Livrer des colis Le comportement pour accomplir le but n’est pas codé d’avance Le robot utilise un planificateur pour déterminer le comportement C’est quoi un comportement au juste? Une séquence d’actions Que veulent dire les hypothèses détermiste et complétement observable ici?

7 Exemple 2: Livraison de colis
vendredi 31 mars 2017 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 1 Colis 2 d11 d12 d23 d24 Que veulent dire les hypothèses détermiste et complétement observable ici?

8 Exemple 1 : Empiler des blocs
vendredi 31 mars 2017vendredi 31 mars 2017 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é.

9 Exemple 2 : Livrer des colis
vendredi 31 mars 2017vendredi 31 mars 2017 Exemple 2 : Livrer des colis État initial But r1 r2 r3 r4 r1 r2 r3 r4 r5 r6 r5 r6 robot É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é.

10 Goto(r5,r1) Goto(r5,r2) … Take(…) … … … … Goto(…) … … …

11 Rappel - Comment trouver un chemin dans un graphe?
vendredi 31 mars 2017vendredi 31 mars 2017 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)) α = 0: algorithme glouton (greedy) β = 0: uniform-cost α = β: A* Défi: trouver une fonction heuristique h(x) In AI, heuristics are criteria, methods or principles for deciding which among several alternative courses of action promises to be the most effective in order to achieve some Son but (Pearl, 1983, p. 3). In general, a heuristic is a function that computes an estimate from the current state to an optimal Son but state. This way, it provides the search process used by a planner with a sense of direction with actions resulting in states that are closer to the Son but being preferred. In a recent book chapter, Geffner provides the following parallel between heuristics and similar functions in human cognition (Geffner, Heuristics book chapter): Heuristic evaluation functions are also used in other settings such as Chess playing programs (Pearl, 1983) and reinforcement learning (Sutton & Barto, 1998). The difference between evaluation functions in Chess, reinforcement learning and domain-independent planning mimic actually quite closely the relation among the three approaches to action selection mentioned in the introduction: programming-based, learning-based and model-based. Indeed, the evaluation functions are programmed by hand in Chess, are learned by trial-and-error in reinforcement learning, and are derived from a (relaxed) model in domain-independent planning. He relates to heuristics to ‘feelings’, ‘emotions’ or ‘appraisals’ in high-level human problem solving: It is now widely accepted in cognitive science that emotions play a key role in action decision, yet not consciously. Analogously, heuristics are most of the time ‘opaque’ to the search process of a planning algorithm and yet provide key guidance for the search to converge rapidly to a Son but solution. Heuristics provide a sense of direction or ‘gut feeling’ to the agent. Similarly, emotions have been shown to provide the appraisals that are necessary for navigating in a complex world.

12 Rappel - Algorithme A* (IFT 615)
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. Les heuristiques sont fondamentales en IA. Dans la planification, les enjeux sont notamment au niveau de: Extraire automatiquement des heuristiques à partir du modèle Apprendre des heuristiques automatiquement (non couvert dans ce cours) IFT615 Froduald Kabanza

13 Rappel - Algorithme A* (IFT 615)
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. IFT615 Froduald Kabanza

14 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. © Froduald Kabanza IFT702

15 Langage STRIPS Transformation du modèle pour avoir une fonction de transition

16 Exemple STRIPS pour le monde des blocks
a b (: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)) Pour l’instant, nous ne traitons pas l’évitement de collision avec les obstacles. Nous supposons que cela est fait au niveau des actions primitives. (:action putdown :parameters (?x – block) :precondition (holding ?x) :effects (and (not (holding ?x)) (ontable ?x) (clear ?x) (handempty))

17 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 b4 b3 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)))

18 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 :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)))) Ici non plus, nous ne traitons pas l’évitement de collision avec les obstacles. Nous supposons que cela est fait au niveau des actions primitives.

19 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 b4 b3 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))

20 Exemple PDDL pour la livraison de colis, suite
(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 :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))))

21 Une autre version PDDL pour la livraison de colis
r1 (room) r2 (room) c1 (corridor) r4 (room) r3 (room) c2 (corridor) d11 d12 d23 d24 b1 b2 b4 b3 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)))

22 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 :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)))))

23 Autres exemples Voir International Planning Competition
© Froduald Kabanza IFT702

24 vendredi 31 mars 2017 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.

25 vendredi 31 mars 2017 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.