Planification et exécution de plan pour la robotique autonome

Planification et exécution de plan pour la robotique autonome Matthieu Gallien Félix Ingrand LAAS-CNRS 7 avenue du Colonel Roche - 31077 Toulouse Cedex 4 - France {matthieu.gallien, felix.ingrand}@laas.fr Résumé Nous nous intéressons à la planification de missions et à leur exécution à bord de robots mobiles autonomes dans un environnement dynamique et incertain. Dans ce contexte nous avons développé IxTeT, un système capable de produire, exécuter et réparer des plans. Ce système utilise des techniques de planification temporelle et non linéaire. Il manipule des plans flexibles afin de pouvoir les adapter à la réalité de l exécution. Cependant, en cas de problème, IxTeT met en œuvre une stratégie de réparation locale d un plan ou une replanification complète. Nous avons ensuite modifié ce système afin de pouvoir exprimer des contraintes temporelles incertaines. Afin de tirer parti de ces extensions récentes, nous avons décidé de modifier l heuristique de planification. IxTeT a été intégré dans l architecture LAAS et testé sur un robot (ATRV). Nous avons réalisé une étude expérimentale de nos contributions à la fois sur un robot et sur son simulateur afin de pouvoir quantifier les bénéfices éventuels de ce travail. Nous proposerons une solution pour certains problèmes mis à jour lors de nos travaux. 1 Introduction 1.1 Positionnement et état de l art Récemment, plusieurs missions d exploration robotisées ont été envoyées sur la planète Mars. En 1997, le rover" Sojourner, de la NASA, parcourt quelques dizaines de mètres en un peu plus de quatre-vingt jours. En 2003, la mission MER de la NASA comporte deux rovers" qui parcourent près de dix kilomètres au total. Ils sont capables d utiliser une autonomie limitée pour effectuer des navigations basées sur de la stéréo vision. En 2011, les missions ExoMars de l ESA et Mars Science Laboratory de la NASA ont pour ambition de franchir une nouvelle étape de l autonomie avec notamment des navigations au delà de l horizon visuel. Plus tard, lorsque l exploration extraterrestre humaine reprendra, nécessairement, des robots toujours plus nombreux l auront préparée et l accompagneront. Ce travail a été partiellement financé par le FSE (Fond Social Européen). La complexité des systèmes robotiques actuels et futurs crée un besoin pour une autonomie accrue. Elle passe par un accroissement de leurs capacités décisionnelles. Ces robots devront être capables d anticiper leurs actions sur un horizon temporel compatible avec les contraintes liées aux communications avec leurs opérateurs humains. Dans le cas d un robot martien, aux quarante minutes aller-retour d une communication, il faut rajouter des contraintes de visibilité des émetteurs/récepteurs terrestres capables de communiquer avec eux. La planification constitue alors une réponse possible à cette problématique. En 2003, MapGen [1], un système de planification de tâches au sol, a permis d accroître de 25% les retombées scientifiques de la mission MER. Cependant, le mode de fonctionnement de ces "rovers" consiste à exécuter une séquence de commandes envoyées depuis la Terre jusqu à sa fin, ou à la détection d un défaut. Cette absence de raisonnement à bord, ou boucle ouverte, implique des périodes d inactivité et des pertes de données scientifiques lorsque le moindre défaut est détecté. Nous proposons d utiliser la planification de tâches embarquée afin de permettre une commande de systèmes robotiques mobiles autonomes. A cette fin, IxTeT réalise la planification des tâches de la mission, puis exécute son plan en tenant compte des contraintes temporelles. Plusieurs stratégies d adaptation en cas de défauts ont été implémentées. D autres planificateurs comme Europa [2] et CASPER [3] ont été utilisés pour la commande de robots mobiles. Le premier utilise des plans flexibles qui sont ensuite exécutés et adaptés au cours de l exécution sans avoir besoin de replanifier grâce à la flexibilité du plan. Le second propose une approche différente de l exécution en utilisant la réparation de plan de manière continue associée à des plans complètement instanciés. 1.2 Exemple : mission d exploration Nous avons effectué des expérimentations à la fois en simulation mais aussi à bord du robot Dala (Fig.1). Nous prenons pour exemple un domaine appelé "Explorateur", inspiré d une mission d exploration extra planétaire. Cette mission comporte plusieurs demandes de prises de vues à des positions géographiques données, des communications durant des fenêtres de visibilité ainsi que le retour à son

point de départ. Lors de cette mission, il se déplace dans un environnement initialement inconnu. Pour cela, il utilise une navigation visuelle adaptée. Par conséquent, les déplacements sont incertains quant à leur réussite ou leur durée. Les prises de vues scientifiques introduisent également une incertitude quant à la taille mémoire réellement occupée1. Nous présentons l architecture logicielle de contrôle du robot. Puis, nous présentons les caractéristiques du système IxTeT2 utilisé pour la planification et l exécution du plan. Ensuite, nos travaux nous amènent à étendre les capacités de notre système suivant deux axes : la prise en compte explicite des incertitudes (pour l instant restreinte au temps) et une stratégie de planification adaptée aux besoins de l autonomie du robot. Nous concluons avec des résultats d exécution réelles et de simulation. Ces résultats sont importants, ils permettent de voir les limites du système ainsi que ses atouts. 2 2.1 Architecture de contrôle du robot Architecture LAAS le niveau fonctionnel, le niveau contrôle d exécution et le niveau décisionnel. Le niveau fonctionnel est réalisé à l aide de modules générés avec GenoM qui encapsulent les fonctions de perception et d action du robot. Ces modules doivent répondre à des contraintes d exécution en temps réel. On trouve ensuite le contrôleur d exécution appelé R2C [5]. Il compare l état des modules et les requêtes émises par la partie décisionnelle, avec un modèle formel des états autorisés ou interdits pour le robot. Il agit comme un filtre qui empêche alors toute requête conduisant à un état interdit. Finalement, la partie décisionnelle comprend OpenPRS qui est un exécutif procédural et IxTeT. OpenPRS interagit avec l utilisateur ainsi qu avec le planificateur. Celui-ci est chargé de fournir un plan initial suivant un problème posé par l utilisateur. Ensuite, les deux systèmes coopèrent à l exécution du plan. IxTeT contrôle l exécution du plan en démarrant les actions du plan et en les arrêtant, tout en prenant en compte le temps, les ressources et l exécution réelle des actions (échec, dépassement de la durée...). OpenPRS quant à lui affine les actions de haut niveau en requêtes exécutables par le niveau fonctionnel et en surveille le bon déroulement. Il peut également mettre en place des actions de reprise d erreur ou transmettre l erreur au planificateur. 3 3.1 Le système IxTeT Planification IxTeT est un planificateur de tâches dans l espace des plans partiels partiellement instanciés utilisant des liens causaux3 (POCL4 ). Dans le plan partiel, il ajoute de nouveaux opérateurs ainsi que des liens causaux. Ces opérateurs utilisent des variables et des contraintes afin de représenter toutes les instanciations possibles. Le résultat est un plan contenant un ordre partiel sur des opérateurs partiellement instanciés. Le plan produit est également flexible temporellement. Les contraintes sur les variables temporelles et atemporelles sont gérées par deux CSP5 (voir ci-dessous la gestion du plan). F. 1 L architecture LAAS sur Dala, un ATRV irobot. La figure 1 présente l implémentation de l architecture LAAS à bord du robot Dala, utilisé pour nos expérimentations. L architecture LAAS [4] fournit un cadre et des outils pour l intégration d une architecture de contrôle à bord d un robot mobile autonome. Elle est composée de trois niveaux : 1 Les algorithmes de compression utilisés produisent des taux de compression variables. 2 Même si le nom IxTeT est utilisé depuis de nombreuses années, les versions successives de ce système sont assez différentes. La dernière en date inclue un exécutif temporel et un planificateur temporel. Définition 1 (Un plan partiel partiellement instancié) Soit P le plan partiel partiellement instancié, il est défini comme le 4-uplet (A, C, L, F), avec A l ensemble des tâches partiellement instanciées, C l ensemble des contraintes portant sur les variables des actions de A, L l ensemble des liens causaux du plan et F l ensemble des défauts de P. IxTeT représente le monde au moyen de variables d état et de variables de ressources. Il planifie à l aide d opérateurs 3 Un lien causal représente une protection de la valeur de la variable d état durant le lien. 4 POCL : Partial Order Causal Link 5 CSP : "Constraint Satisfaction Problem" ou Problème de Satisfaction de Contraintes [6].

task MOVE(?initL,?endL)(st,et){?initL,?endL in LOCATIONS; event(robot_pos():(?initl,idle_pos),st); hold(robot_pos():idle_pos,(st,et)); event(robot_pos():(idle_pos,?endl),et); event(robot_status():(still,moving),st); hold(robot_status():moving,(st,et)); event(robot_status():(moving,still),et); hold(ptu_pos():forward,(st,et)); variable?di,?du,?dist; variable?duration; distance(?initl,?endl,?di); distance_uncertainty(?du);?dist =?di *?du; speed(?s);?dist =?s *?duration; contingent?duration = et st; }latepreemptive task MOVE_PTU(?initL,?endL)(st,et){ timepoint end_heat;?initl,?endl in PTU_POSITIONS; hold(robot_status():still,(end_heat, st)); event(ptu_status():(cold, HEAT),st); hold(ptu_status():heat,(st,end_heat)); event(ptu_status():(heat,moving),end_heat); hold(ptu_status():moving,(end_heat,et)); event(ptu_status():(moving,cold),et); hold(ptu_init():true,(st,et)); hold(ptu_pos():?initl,(st,end_heat)); event(ptu_pos():(?initl,ptu_pos_idle),end_heat); hold(ptu_pos():ptu_pos_idle,(end_heat,et)); event(ptu_pos():(ptu_pos_idle,?endl),et); (end_heat st) in [10,12]; contingent (et st) in [16,20]; }latepreemptive FIG. 2 Un exemple de tâches de déplacement, et d orientation des caméras extrait du domaine "Explorateur". que nous appellerons tâches (voir Fig.2) qui sont ajoutés autant de fois que nécessaires. Ces opérateurs sont partiellement spécifiés. IxTeT peut insérer dans le plan un opérateur de prise de vue en ne précisant pas quelle caméra sera utilisée à l exécution. La représentation des plans correspond à des chroniques [7]. Plus précisément, IxTeT utilise une logique temporelle réifiée. Deux types de proposition temporelle sont possibles sur les variables d états : event et hold. Un "hold" représente le maintien d une variable d état à une valeur entre deux instants. Un "event" correspond à un changement de valeur instantané d une variable d état à un instant donné. Pour les ressources, trois types de proposition sont possibles : consume, produce et use. Un "consume" correspond à la consommation d une ressource, un "produce" à sa production et un "use" à son emprunt. Gestion du plan. Les plans sont représentés par des variables d états et de ressources qui permettent à tout instant de connaître sans ambiguïté l état du système. Cependant, les tâches étant partiellement spécifiées, IxTeT doit gérer des variables temporelles et atemporelles ainsi que les contraintes sur ces variables. IxTeT utilise deux CSP afin de gérer les variables non complètement instanciées. Le premier est un STN 6, et représente des contraintes entre variables temporelles. Elles sont toutes de la forme : m (t 2 t 1 ) M m, M R, t 1 et t 2 sont des variables temporelles et leurs domaines sont des intervalles [l, u] l, u R. Le planificateur utilise deux types de propagation sur ce réseau. D abord, le réseau minimal 7 est calculé par un algorithme de chemin consistance. Ensuite, le système utilise un algorithme en O(n 2 ) pour l ajout incrémental de contraintes basé sur l algorithme de Mackworth PC-2 [9]. Le second contient des variables dont les domaines sont soient symboliques finis ou à complémentaires finis, soient des domaines numériques réels quelconques. Nous pouvons définir en particulier des contraintes d unification, de somme, etc. Nous pouvons également utiliser des contraintes mixtes entre les deux CSP [10]. Ceci permet notamment de lier les effets d une tâche à sa durée 8. 6 STN : Simple Temporal Network [8]. 7 Toutes les valeurs des domaines des variables et des contraintes ne pouvant pas faire partie d une solution ont été retirées. Dans le cas d un STN, la consistance d arc est complète et la consistance de chemin calcule en plus le réseau minimal. 8 Dans le domaine "Explorateur", une estimation de la distance à parcourir est obtenue à l aide d une distance de Manhatan. Un cal- task INIT()(t_start,t_end){ explained event(robot_status():(moving,still),t_start); explained event(ptu_status():(moving,cold),t_start); explained event(mvt_generation_initialized():(f,t),t_start); contingent event(visibility_window(w1):(in,out),t_start); contingent event(visibility_window(w1):(out,in),t_svisi1); contingent event(visibility_window(w1):(in,out),t_evisi1);... (t_evisi1 t_svisi1) in [30, 31]; (t_svisi1 t_start) in [150, 151];... hold(communication(w1):done,(t_goal3s, t_goal3e)) goal(2, 0); hold(picture(obj1, 0.5, 0 0.5) : DONE, (t_goal5s, t_goal5e)) goal(1,0);... hold(at_robot_x():0.5,(t_goal1,t_end)) goal(3,0); hold(at_robot_y():0 0.5,(t_goal1,t_end)) goal(3,0); (t_end t_goal1) in [2,4];... (t_end t_start) in ]330,500]; }earlypreemptive FIG. 3 Un exemple de plan initial extrait du domaine "Explorateur". Contrôle de la recherche. Deux algorithmes de recherche sont disponibles. Le premier est un A ɛ. Le second effectue une recherche en profondeur d abord. La recherche s effectue sur un plan partiel courant. Elle se prolonge tant que le plan courant contient des défauts et tant qu une solution est possible. Le plan initial (Fig.3) décrit la situation initiale ainsi que les buts de la planification. Celui-ci peut contenir également l évolution connue d attributs contingents tels que des fenêtres de visibilité ou des changements de la capacité d une ressource. IxTeT utilise une hiérarchie d abstraction [11] pour mieux guider la recherche. Cette hiérarchie est dynamique et est adaptée en ligne lors de la planification. IxTeT génère hors ligne, à partir d une description syntaxique des modèles de tâches et de la définition d effets principaux justifiant l insertion d une tâche, un ensemble minimal de contraintes garantissant la propriété de monotonicité ordonnée. Elle contraint l ordre de résolution des défauts dans le plan. Un plan partiel est considéré comme un plan solution lorsqu il ne contient plus de défaut. Dans IxTeT, un défaut peut être soit une proposition temporelle non expliquée par un lien causal, soit un conflit potentiel entre deux propositions temporelles du plan, soit un conflit possible concernant la capacité d une ressource. A chaque étape de la planification, une analyse des défauts contenus dans le plan partiel est effectuée et pour chacun d eux, toutes les résolvantes possibles sont calculées. On cul du temps de parcours est alors effectué à l aide de la contrainte?duration?speed =?distance en ayant pour la variable?speed le domaine convexe des vitesses les plus probables.

choisit ensuite un défaut à l aide d une heuristique (voir ci-dessous), puis sa résolvante. Après son insertion dans le plan partiel, si le plan est toujours consistant, la planification continue. Si le plan est inconsistant, ou qu un défaut ne possède pas de résolvantes, on procède à un retour arrière immédiat. Faisabilité et satisfiabilité. À chaque type de défauts correspond certains types de résolvantes. Pour un sous-but, on peut soit établir un lien causal avec un établisseur interne au plan, soit rajouter une tâche. Pour un conflit potentiel entre deux propositions temporelles sur des variables d états, on peut les séparer temporellement ou unifier leurs valeurs ou séparer au moins un paramètre si la variable d état est paramétrée. Pour un conflit de ressources, il s agit d une surconsommation potentielle sur un intervalle de temps. L ensemble des résolvantes comprend : l ajout d une tâche productrice, la séparation d une proposition paramétrée par rapport à la nature du conflit, la séparation temporelle et une résolvante limitant la quantité consommée par un ensemble de propositions de quantité variable de la forme n i=0 q i qmax. Une recherche heuristique. IxTeT utilise une stratégie opportuniste et de moindre engagement. L idée est de limiter le nombre de retour arrière au cours de la recherche en contraignant le moins le plan, ainsi que la taille de l espace de recherche en limitant le facteur de branchement. Pour cela, on choisit les défauts ayant le moins de résolvantes possibles et parmi celles-ci, la moins contraignante. Planifier avec IxTeT consiste à sur-contraindre le plan en résolvant des défauts, ce qui réduit le nombre de solutions atteignables à partir du plan partiel courant. Ainsi résoudre un défaut entraînera l invalidation de résolvantes possibles sur les autres. On aura alors une réduction du facteur de branchement global. La recherche heuristique est réalisée en calculant un coût d engagement pour chaque résolvante (ou contrainte). Il correspond au pourcentage de solutions atteignables à partir du plan partiel courant, qui vont être retirées par cette résolvante. En réalité, seule une estimation est utilisée. Ensuite, pour chaque défaut φ une opportunité de résolution est calculée à l aide d un facteur K (les détails de ces calculs sont dans [12]). Définition 2 (Coût de l insertion d une résolvante) Soit P un plan partiel quelconque. Soit µ(p) le nombre de plans solutions complètement instanciées atteignables par une recherche utilisant P comme plan initial. Soit r une résolvante du plan partiel P. Soit coût(p, r) le coût de l insertion de r dans P. µ(p r) coût(p, r) = 1 µ(p) En utilisant plusieurs simplifications et hypothèses (voir [12]), le coût d insertion d une résolvante complexe est : n coût(p, r) = (coût(p, r i )) i=0 Définition 3 (Coût d une contrainte de précédence) Soient t 1 et t 2 deux instants du plan. Soit c(t 1, t 2 ) l intervalle de contrainte entre t 1 et t 2. Soit d(c) la durée de la contrainte c. coût(t 1 < t 2 ) = d(c(t 1, t 2 ) ], 0] ) d(c(t 1, t 2 )) Définition 4 (Coût d un lien causal) Un lien causal l = p a i (v 1,..., v n ) a j (w 1,..., w n ) avec a i une proposition temporelle à l instant t i, a j une autre proposition temporelle à l instant t j, correspond à trois contraintes : Une contrainte de précédence entre t i et t j. Une contrainte d unification des variables v 1,..., v n, w 1,..., w n. Une contrainte de durée du lien causal. Soient t début l instant de début du plan et t fin l instant de fin du plan. durée(l) = borneinf(c(t début, t fin )) borneinf(c(t i, t j )) coût(l) = coût(t i < t j ) + coût(v 1 = w 1 ) +... 3.2 Exécution + coût(v n = w n ) + coût(durée(l)) Le système IxTeT comprend depuis [12] un exécutif temporel. Celui-ci démarre, interrompt et reçoit les bilans des tâches. Il est capable de réagir dans des situations imprévues. Il fonctionne selon un cycle perception/réparation/exécution. Le plan résultant de la planification ne contient que des estimations des valeurs incertaines maintenues par les CSP. Par exemple, dans le domaine "Explorateur", la taille mémoire de chaque image ainsi que la durée de chaque déplacement sont partiellement connues. Cycle d exécution. L exécutif temporel exécute le plan initial que lui a produit le planificateur. Pour ce faire, il fonctionne suivant un cycle classique perception/planification/action". La première phase consiste à intégrer les messages en provenance d OpenPRS. Ils sont de trois types : le bilan de l exécution d une tâche, un nouveau but, un changement dans le niveau d une ressource. Le lecteur trouvera dans [12] une présentation de l intégration des messages dans le plan en cours d exécution. La seconde phase effectue si besoin est une réparation du plan. Celle-ci est distribuée sur plusieurs cycles afin de conserver une réactivité aux événements pouvant survenir dans l intervalle de temps nécessaire à la réparation de tous les conflits du plan. La troisième exécute les instants contenus dans le plan. Dans le cas d un instant de début d une action, une commande est émise en direction de l exécutif procédural. Pour la fin d une tâche, si celle-ci est interruptible, un message est également émis. Sinon, IxTeT doit attendre la fin de cette tâche. Si elle dépasse sa durée maximale, le plan est alors partiellement invalidé et nécessite une réparation ou une replanification dans le cas où il n est plus exécutable.

L exécutif s active lorsqu un message a été reçu, lorsqu un instant a besoin d être exécuté ou lorsqu une réparation de plan est en cours. L utilisateur a la possibilité de régler la durée maximale autorisée ts pour un cycle aussi appelée "timestep". 4 Incertitude sur la durée des actions De nombreuses tâches 9 effectuées par un robot mobile en environnement initialement inconnu ou mal connu sont soumises à de fortes incertitudes. Par exemple, lors d un déplacement, le robot ne peut pas décider à priori de l instant de fin. Il doit uniquement observer le fait qu il a atteint son objectif. De même, lors d une communication, c est à dire d une réception d un message provenant d un tiers, le robot ne connaît pas la durée exacte de cette communication. Les modèles de tâches permettent d exprimer cette incertitude sur la durée en la modélisant comme de la flexibilité. Cependant, le formalisme STN suppose que toutes les variables sont contrôlables et recherche une affectation de toutes ces variables à une valeur précise. Dans notre cas, les algorithmes de propagation des contraintes peuvent réduire la durée possible d une action, même si celle-ci n est pas contrôlable. Ceci va conduire à des échecs du plan due à son exécution, sans que l échec d une action ou même qu un dépassement temporel soit en cause. Par exemple si un robot doit enchaîner des tâches contrôlables et des tâches non-contrôlables, les premières doivent voir leur durée réduite afin de préserver les incertitudes sur la durée des autres. Par exemple, un télédéchargement contrôlable sera interrompu au bout de dix secondes si le déplacement non-contrôlable suivant doit commencer au plus tard à cet instant. 4.1 Définition Dans [13], les auteurs introduisent un nouveau formalisme appelé STNU 10. Ce formalisme ajoute la notion de contraintes contingentes ou contrôlables. La notion CSP classique de consistance est remplacée par les notions de contrôlabilité. Trois niveaux principaux sont rappelés dans [14] : faible, forte et dynamique. La contrôlabilité faible garantit que pour chaque instanciation complète de tous les liens contingents, il existe une instanciation possible de chacun des liens contrôlables. La contrôlabilité forte garantit que la même valeur sera choisie pour chacun des liens contrôlables quelque soit la valeur exacte des liens contingents, permettant la génération hors ligne d une politique d exécution. La contrôlabilité dynamique, qui nous semble la plus prometteuse, consiste à ne prendre des décisions sur le STNU qu en fonction des décisions et observations précédentes. Ainsi, elle est très intéressante dans le contexte de l exécution du plan dans un environnement dynamique et incertain, puisqu aucune décision ne nécessite de faire des hy- 9 Dans cette section, les exemples sont tirés du domaine "Explorateur". 10 STNU : Simple Temporal Network with Uncertainties. A 1. Calculer le STN minimal. S il n est pas pseudo-contrôlable retourner faux. 2. Sélectionner chaque triangle tel que AB est contingent et que v (fig. 5) n est pas négatif. Introduire toutes les contraintes requises par le cas "Précédent" et chaque "wait" requis par le cas "Nonordonné". 3. Faire toutes les régressions possibles de "wait", tout en convertissant les "wait" inconditionnel en borne inférieure. Introduire également les bornes inférieures fournies par la réduction généralisée. 4. Si les étapes 2 et 3 n ont pas produit de contraintes supplémentaires retourner vrai, sinon recommencer l étape 1. [p, q] [x, y] C [u, v] FIG. 4 Algorithme 3DC+. B A [p, q] <C, t> [u, v] FIG. 5 Deux exemples de réseaux. Celui de gauche illustre un triangle de contraintes, typiquement parcouru par l algorithme 3DC+, comprenant le lien AB contingent. Celui de droite illustre la propagation ou régression des "wait", au travers d un réseau ayant un lien AB contenant un "wait" causé par un lien contingent AC absent du schéma. pothèses sur l avenir. Elle est également moins restrictive que la contrôlabilité forte. De plus, vérifier qu un STNU est dynamiquement contrôlable en calculant le réseau minimal (i.e. en retirant toutes les valeurs ne pouvant pas être dans une solution), peut s effectuer à l aide de l algorithme 3DC+ en temps polynomial [14]. 4.2 Algorithme 3DC+ Cet algorithme est basé sur des modifications locales de tous les triangles de contraintes en contenant au moins une qui soit contingente et sur la propagation d un nouveau type de contrainte ternaire appelé "Wait". Le réseau minimal est obtenu, sinon l échec est détecté. Nous faisons un bref rappel pour le lecteur. Fig.4 présente l algorithme général. L algorithme effectue plusieurs cycles au cours desquels chaque triangle comportant un lien contingent est examiné. De nouvelles contraintes nécessaires sont ajoutées dans certains triangles. L algorithme s arrête lorsqu aucune nouvelle contrainte n est ajoutée. Un nouveau type de contrainte a été introduit, appelé wait" et noté < d, i >. Il permet à l exécutif d attendre une durée connue d avant de pouvoir exécuter un instant sans risque de réduire la contrainte sur i. Il permet également d exécuter un instant plus tôt si l instant i a été observé. A la fin de chaque cycle, le STNU est complètement propagé comme si c était un STN. A l issu de cette étape, si aucune durée non contrôlable n a été réduite, le STNU est pseudo-contrôlable. Nous avons effectué deux améliorations. La première consiste à maintenir le STNU toujours propagé au lieu de D B

le faire à la fin de chaque cycle. Ceci permet d utiliser l algorithme en O(n 2 ) au lieu de O(n 3 ). Nous avons donc une borne maximale égale à O(n 2 c) avec c le nombre de contraintes non contrôlables. Expérimentalement, la complexité est plutôt de O(n 2 ) pour les propagations. La seconde amélioration a été motivé par le soucis d adapter 3DC+ au STNU dynamique d IxTeT. Avant chaque nouvel ajout de contraintes, tous les waits" sont retirés. Ceci n est pas un problème, car si ils étaient nécessaires, 3DC+ les rajoute qu ils soient présents ou non. Si ils n étaient plus nécessaires, nous diminuons la durée d un cycle de l algorithme. Ce travail mériterait d être complété afin de retirer plus précisément ce qui doit l être. 5 Modification de l heuristique Initialement IxTeT avait été conçu comme un système de planification suivant une stratégie de moindre engagement. Les extensions pour en faire un système de replanification dynamique et de réparation de plan sont plus récentes. Il en va de même pour la prise en compte des incertitudes de durées des tâches. Ces modifications justifient de repenser les heuristiques utilisées par le planificateur. 5.1 Motivation et implémentation Dans le contexte de la robotique d exploration, nous évoluons dans un environnement très incertain. Les tâches peuvent échouer ou leur durée ne pas correspondre aux modèles utilisés en planification. Ceci va nous amener à remettre au moins partiellement en cause le plan initialement produit. De plus notre système est capable de prendre en compte, au cours de l exécution, de nouveaux buts. Pour ces raisons, les plans produits ont une durée maximale supérieure à la durée optimale (théorique) du plan, afin de pouvoir s adapter aux différents événements. Cependant, la stratégie de moindre engagement va placer les actions temporellement flexibles de la manière la moins contrainte du point de vue de l heuristique. Intuitivement, une action sera ordonnée de manière la plus flexible possible par rapport aux événements contingents tels que des fenêtres de visibilité. Ceci va amener le robot à agir peu et à échouer tardivement dans l exécution du plan, ce qui lui laissera peu de temps pour planifier et exécuter un nouveau plan. Au final, des buts atteignables ne l aurons pas été. De plus, si de nouveaux buts sont envoyés à IxTeT, nous souhaitons que le plus grand nombre de ses buts actuels soient déjà satisfaits. Nous avons donc modifié le calcul de l heuristique afin d obtenir des plans plus contraints temporellement. Cependant, nous devons garder à l esprit que les possibilités de réparation d IxTeT dépendent directement de la flexibilité temporelle du plan. Pour cela, les nouveaux calculs doivent prendre en compte les deux objectifs. Pour atteindre nos objectifs, les calculs de l heuristique de moindre engagement liés aux contraintes temporelles ont besoin d être modifiés y compris ceux liés aux liens causaux. Définition 5 (Coût d une contrainte de précédence) Soient t 1 et t 2 deux instants du plan. Soit c(t 1, t 2 ) l intervalle de contrainte entre t 1 et t 2. Soit d(c) la durée de la contrainte c. Soit t début l instant de début du plan et t fin l instant de fin du plan. Soit coût flexible (t 1 < t 2 ) l ancienne mesure du coût. Le coût est calculé en fonction de l effet sur l instant t 1 11. bornesup(c(t début,t 2 )) bornesup(c(t début,t fin si bornesup(c(t )) début, t 1 )) > bornesup(c(t début, t 2 )), coût provisoire (t 1 < t 2 ) = Finalement bornesup(c(t début,t 1 )) bornesup(c(t début,t fin )) coût provisoire (t 1 < t 2 ) coût(t 1 < t 2 ) = coût flexible (t 1 < t 2 ) sinon. si coût flexible (t 1 < t 2 ) < seuil, sinon. Le seuil peut être choisi de manière à privilégier plus ou moins de flexibilité temporelle restante dans le plan solution. Des tests ont été faits et montrent la pertinence de cette approche pour la préservation de réserves de flexibilité. Définition 6 (Coût d un lien causal) Un lien causal l = p a i (v 1,..., v n ) a j (w 1,..., w n ) avec a i une proposition temporelle à l instant t i, a j une autre proposition temporelle à l instant t j correspond à trois contraintes. Une contrainte de précédence entre t i et t j. Une contrainte d unification des variables v 1,..., v n, w 1,..., w n. Une contrainte de durée du lien causal. Soient t début l instant de début du plan et t fin l instant de fin du plan. La fonction de calcul de la durée à été modifiée par rapport à la version précédente. coût(l) = durée(l) = bornesup(c(t début, t fin )) bornesup(c(t i, t j )) coût(v 1 = w 1 ) +... + coût(v n = w n ) + coût(durée(l)) si coût(t i < t j ) coût(t i < t j ) + coût(v 1 = w 1 ) < seuil, +... + coût(v n = w n ) + coût(durée(l)) sinon. 11 Des tests ont également été effectués en prenant en compte la borne au plus tôt de t 2 au lieu de la borne au plus tard de t 1. Ces tests ne montrent pas de différence suivant l une ou l autre des approches. Une explication peut venir du fait que le calcul de l heuristique, prenant en compte le placement dans le temps des actions, reflète dans les deux cas un moindre coût pour un ordonnancement au plus tôt.

6 Résultat en simulation et sur le robot 6.1 Simulation Nous avons utilisé un simulateur [15] capable de reproduire le même fonctionnement de la couche fonctionnelle que si elle était exécutée sur le robot. Grâce à ce simulateur nous sommes capable de tester IxTeT à la fois sur le robot mais aussi de manière intensive en utilisant le simulateur. 6.2 Expérimentation Nous avons choisi d expérimenter 12 uniquement en utilisant le domaine explorateur". Nous avons défini quatre mondes différents comportant aucun, trois, trois autres et six obstacles. Le scénario consiste à effectuer trois prises de vues, deux communications et à revenir au point de départ. Durant la première communication et si elle est réussie, deux nouveau buts sont ajoutés. Nous avons défini plusieurs emplacement des buts de manière aléatoire. Nous utilisons une machine avec un Pentium4 hyperthreadé à 3GHz et 1Go de mémoire vive. 6.3 Résultat Sur la figure 6, le plan a été produit en utilisant un STNU et la nouvelle heuristique. On voit que toutes les tâches ont été placées avant la seconde communication. On voit également que l intervalle pour démarrer une communication est plus court que l intervalle de fin. Ceci est le résultat de 3DC+ qui a protégé la durée non contrôlable de la communication. On peut également remarquer le recouvrement partiel des tâches MOVE" et MOVE_PAN_TILT_UNIT". Par contre, la visualisation de ce plan ne montre pas la contrainte wait" entre ces deux dernières tâches. Durée de la mission Nous avons observé deux phénomènes. En fonction des obstacles, et avec des buts satisfaits égaux, la durée varie de 10% avec un STNU. La nouvelle heuristique produit des plans réellement plus courts, environ 25%. En réalité, certaines combinaisons de buts peuvent la mettre en échec. Cependant, l objectif de minimisation de la durée est atteint. Il pourrait être fait utilisation des travaux [16] cherchant à coupler un second planificateur spécialisé pour gérer certaines parties critiques du plan comme les déplacements. Lors de l exécution, avec un STNU, le gain par rapport à l autre heuristique chute à seulement 10%. Ce phénomène vient des réparations liées aux nouveaux buts ajoutés en cours de mission. En effet, la réparation produit des plans de mauvaises qualité comportant des tâches inutiles et redondantes. Dans nos tests, le robot doit effectuer des aller-retours entre plusieurs points, entraînant un plan beaucoup plus long. 12 Tous les logiciels et autres paramètres utilisés lors de notre travail est disponible sur simple demande aux auteurs, incluant l architecture de contrôle du robot entier et la simulation. Lors de l utilisation de l ancienne heuristique, le planificateur ne peux pas trouver de plan en réparant et replanifie, produisant un plan de meilleure qualité. Ceci augmente la performance du couple STNU/ancienne heuristique. Durée de la planification Il n y a aucune influence sur le temps de planification en utilisant l une ou l autre des deux heuristiques. Il est à noter que les problèmes posés sont toujours facile due aux nécessaires marges sur la durée totale du plan. L influence de 3DC+ est quand à elle significative lors de la planification avec de nombreux buts (> 5 prises de vues et deux communications par exemple). La robustesse Les plans produits avec 3DC+ et quelque soit l heuristique sont statistiquement plus robustes. Cependant, il est à noter que lors de test sur le robot, il est arrivé que la mission soit accomplie de manière correcte avec cette heuristique. Il est à noter également que lors d autres tests sur le robot, l utilisation d un STN soit pénalisante. En effet, lors de certaines missions, le robot est amené à réparer ou replanifier de nombreuses fois. Lors de certaines missions, il est possible que par manque de temps, certains buts doivent être abandonnés au profit de buts plus prioritaires. Nous avons observé que parfois, due aux réductions abusives des durées des tâches, le planificateur conserve un but de faible priorité (prise de vue) en conjonction avec un but plus prioritaire (retour au point de départ). Or ce plan était inexécutable due aux réductions de durée des tâches trop importantes. Finalement, le robot a été incapable de satisfaire le but prioritaire tandis que l autre a été satisfait. Ce problème devient presque impossible avec 3DC+. Temps de calcul L utilisation de 3DC+ rend l exécution de timepoint plus coûteuse dans la mesure ou la propagation est plus coûteuse. En fait, ces différences ne sont pas réellement significative. En effet, avec un STN la durée est d environ 1ms et de 10ms avec un STNU. 7 Conclusion et perspectives En conclusion, nous avons un système capable de produire un plan, de l exécuter et de réagir à différents événements survenus durant l exécution, y compris un échec. De plus, nous avons vu qu il était possible de produire des plans respectant les incertitudes sur les durées des tâches. Nous donnons un exemple sur le domaine "Explorateur". L intégration de ce système sur un robot réel nous a permis de montrer la validité de notre démarche en permettant le contrôle effectif de la mission du robot. Plusieurs systèmes [3, 17] utilisent également la planification de tâches pour commander des "rover". Ces systèmes utilisent différentes approches de la planification de tâches. Le domaine qu ils traitent ne possède pas de problèmes

FIG. 6 Plan initial typique durant nos expérimentations. Ce plan a été généré avec un STNU en utilisant la nouvelle heuristique. types qui seraient connus de la communauté. Il est donc difficile de les comparer, d autant plus que les architectures sont différentes. Nous voudrions étendre la prise en compte explicite des incertitudes à la gestion des ressources. En effet, nous avons là une connaissance incertaine encore inexploitée. Nous voudrions continuer à modifier la planification afin de tenir compte des spécificités de l exécution dans la production des plans. Lors de notre étude sur le simulateur, il a été mis en évidence que la mauvaise qualité de certains plans réparés est préjudiciable à la bonne exécution de la mission entière. Nous pensons qu il est possible d améliorer ce travail en relaxant significativement les tâches dans le plan lors du retrait des liens causaux avant de réparer le plan. Il faudrait alors utiliser des algorithmes de propagation adaptés aux CSP dynamiques tels que ceux présentés dans [18]. Références [1] M. Ai-Chang, J. Bresina, L. Charest, A. Jónsson, J. Hsu, B. Kanefsky, P. Maldague, P. Morris, K. Rajan, and J. Yglesias. Mapgen : Mixed initiative planning and scheduling for the mars 03 mer mission. In Proceedings of isairas, 2003. [2] Ari K. Jonsson, Conor McGann, Liam Pedersen, Michael Iatauro, and Srikanth Rajagopalan. Autonomy Software Architecture for LORAX. In i-sairas-2005, 2005. [3] S. Chien, D. Tran, G. Rabideau, B. Cichy, A. Davies, R. Sherwood, R. Castano, D. Mandl, S. Frye, B. Trout, J. D Agostino, S. Shulman, and D. Boyer. The autonomous sciencecraft on earth observing one. In i-sairas- 2005, 2005. [4] R. Alami, R. Chatila, S. Fleury, M. Ghallab, and F. Ingrand. An architecture for autonomy. IJRR, 1998. [5] F. Py and F. Ingrand. Dependable execution control for autonomous robots. In International Conference on Intelligent Robots and Systems, 2004. [6] A. Mackworth. Consistency in networks of relations. Artificial Intelligence, 8 :99 118, 1977. [7] M. Ghallab, D. Nau, and P. Traverso. Automated Planning : Theory and Practice. Morgan Kaufmann, 2004. [8] R. Dechter, I. Meiri, and J. Pearl. Temporal constraint networks. Artificial Intelligence, 49 :61 95, 1991. [9] A. K. Mackworth and E. C. Freuder. The Complexity of Some Polynomial Newtork Consistency Algorithms for Constraint Satisfaction Problems. Artificial Intelligence, 25(1) :65 74, 1985. [10] R. Trinquart and M. Ghallab. An extended functional representation in temporal planning : towards continuous change. In ECP, 2001. [11] F. Garcia and P. Laborie. Hierarchisation of the seach space in temporal planning. In EWSP-95, pages 235 249, 1995. [12] S. Lemai. IxTeT-eXeC : planification, réparation de plan et contrôle d exécution avec gestion du temps et des ressources. PhD thesis, LAAS-CNRS et Institut National Polytechnique de Toulouse, France, 2004. [13] T. Vidal and H. Fargier. Handling contingency in temporal constraint networks : from consistency to controllabilities. JETAI, 11(1) :23 45, 1999. [14] P. Morris, N. Muscettola, and T. Vidal. Dynamic Control Of Plans With Temporal Uncertainty. In IJCAI, pages 494 502, 2001. [15] Sylvain Joyeux, Alexandre Lampe, Rachid Alami, and Simon Lacroix. Simulation in the LAAS Architecture. In ICRA Workshop on Interoperable and Reusable Systems in Robotics, 2005. [16] B. Lamare. Vers une coopération entre divers systèmes de planification à bord d un robot. PhD thesis, Université Paul Sabatier, 1999. [17] A. Finzi, F. Ingrand, and N. Muscettola. Model-based executive control through reactive planning for autonomous rovers. In IROS 2004 (IEEE/RSJ International Conference on Intelligent Robots and Systems), 2004. [18] P. Surynek and S. Barták. A New Algorithm for Maintaining Arc Consistency After Constraint Retraction. In Principles and Practice of Constraint Programming, 2004.