6.3 Gestion contextuelle de tâches
6.3.1 Mission décrite par un ensemble d'objectifs
Un des points importants dans la navigation autonome est la capacité de l'engin à prendre seul les décisions stratégiques relatives au déroulement de la mission. Nous pou- vons étudier la mission à diérent niveaux de granularité : un niveau très agrégé où l'on va raisonner sur les principales étapes de la mission comme l'inspection d'un pipeline ou la bathymétrie d'une zone, le très bas niveau où on déterminera périodiquement les commandes à appliquer aux actionneurs du véhicule et où on surveillera l'évolution des grandeurs physiques à mesurer, en n un niveau intermédiaire où on décomposera les prin- cipales étapes de la mission en sous étapes élémentaires.
A n de pouvoir appliquer des raisonnements sur ces niveaux, nous leur avons donné existence sous la forme d'un vocabulaire utilisé par le contrôleur et servant aussi d'interface de programmation avec l'utilisateur. Nous avons déjà introduit dans la section précédente l'alphabet et les mots de ce vocabulaire : les objectifs, les sous-objectifs et les modules.
Les objectifs sont manipulés par le superviseur global, les sous-objectifs par le super- viseur local et les modules par le niveau exécutif.
La programmation se fait par la constitution d'une mission. Une mission est une suite d'objectifs à accomplir. Ces objectifs représentent alors les intentions de l'utilisateur.
D'un autre coté la capacité du véhicule est traduite par les modules bas niveau qui ont été construits pour gérer son instrumentation. L'ensemble des modules bas niveau est analogue à un alphabet qui va nous permettre d'écrire des mots : les sous-objectifs. En n, en enchaînant plusieurs sous-objectifs nous obtenons un objectif [39].
Il y a alors deux approches dans l'utilisation du vocabulaire : un approche ascendante qui va consister à construire les lettres et les mots qui vont re éter les capacités du véhicule et une approche descendante qui va consister à se servir de ces mots pour exprimer au système la mission qu'il devra eectuer.
Par exemple si l'on venait à ajouter sur un véhicule sous-marin un sonar à balayage, on construira alors le module bas niveau qui gérera ce capteur. On construit aussi un module qui sauvegarde les données produites par ce module. A partir de ces deux modules nous pouvons dé nir le sous-objectif "relevé topographique", cela signi e que lorsque l'ordonnanceur bas niveau reçoit ce sous-objectif, il va lancer périodiquement le module qui gère le capteur puis le module de sauvegarde.
En combinant ce sous-objectif et un autre sous-objectif qui permet de faire naviguer le véhicule en râteau sur une zone précise, nous pouvons créer l'objectif "bathymétrie".
Nous pouvons utiliser et réutiliser le vocabulaire disponible pour pouvoir construire les missions désirées par l'utilisateur.
Nous allons à travers un exemple mettre en évidence comment l'utilisation de ce vo- cabulaire va donner la possibilité au logiciel de contrôle de faire facilement de la gestion contextuelle de tâche (au sens robotique du terme).
Comme nous l'avons décrit précédemment, une mission est faite d'un ensemble d'objec- tifs que le système robotique doit atteindre. L'exécution de la mission revient à l'exécution de cette séquence logico-temporel d'objectifs.
Exemple de mission : Attente 30s
Chapitre 6 : Construction d'une architecture logicielle
Figure 6.7 Exemple de mission pour un véhicule sous-marin de type AUV Position GPS
Inspection pipeline au point B + Relevé salinité Bathymétrie zone à partir du point C
La description de cette mission par l'utilisateur requiert la construction de cinq objec- tifs à savoir : Navigation, Position GPS, Inspection de pipeline, Relevé salinité, Bathymétrie.
La gure 6.7 représente la mission à accomplir par le véhicule sous-marin. Les objectifs seront alors enchaînés par le superviseur global ( gure 6.8).
Figure 6.8 Objectifs enchaînés par le superviseur global
Les informations concernant la manière dont le superviseur global devra agencer tem- porellement les objectifs pour accomplir la mission sont contenues dans les objectifs eux- mêmes. Ainsi chaque objectif renseigne sur l'événement qui doit l'engager et celui qui doit l'arrêter.
L'exécution d'un objectif peut être déclenchée après un temps xé (potentiellement nul) compté suite à l'occurrence de deux types d'événements :
Evénement traduisant un état particulier du système (exemple : véhicule à l'eau) Fin d'un autre objectif
D'autre part, l'arrêt d'un objectif se fera un temps xé (potentiellement nul) après l'occurrence de :
6.3 Gestion contextuelle de tâches Fin d'un autre objectif
Fin propre
L'entité objectif peut alors être modélisée comme montré à la gure 6.9.
Figure 6.9 Modélisation UML d'un objectif
Lors du déroulement de la mission, le superviseur global trouvera alors dans les ob- jets objectif toutes les informations nécessaires à l'exécution et à l'enchaînement logico- temporelle des objectifs.
L'exemple précédent est un exemple idéal d'exécution de mission. La réalité nous impose d'envisager les cas d'échec d'objectifs durant une mission. Supposons que dans l'exemple précédent, le véhicule perde la trace du pipeline pendant le suivi. Une réaction possible serait de remonter en surface puis d'arrêter la mission en attendant l'intervention humaine ( gure 6.10).
Toutefois, la perte d'un pipeline ne représente pas un danger direct pour un véhicule sous-marin. Elle peut seulement l'empêcher d'atteindre correctement un objectif. De plus ces situations sont assez courantes et prévisibles, dans le sens où l'opérateur peut savoir par exemple que les occultations de pipeline sont fréquentes dans la zone d'opération sans toutefois savoir à quels endroits exactement.
Intuitivement nous savons que l'on peut très bien poursuivre la mission en passant directement au dernier objectif : la bathymétrie (voir gure 6.11). Nous ne pouvons ce- pendant dresser de règles générales dans le cas d'échec d'objectifs qui seraient appliquées par le superviseur global. En eet, l'échec d'un objectif dans certains cas peut invalider le suivant. L'opérateur ayant la capacité de déterminer le sens des objectifs composant la mission est plus à même de proposer une issue pour la mission en cas d'échec d'un objectif.
Chapitre 6 : Construction d'une architecture logicielle
Figure 6.10 Arrêt de la mission suite à l'échec d'un sous-objectif
la mission, la liberté de proposer une mission alternative à exécuter lorsque survient un problème donné.
Dans notre exemple, si en cas d'échec de l'objectif d'inspection de pipeline, nous vou- lons terminer la mission avec l'objectif bathymétrie, nous devrons construire un sixième objectif. Cet objectif sera un objectif bathymétrie, comme le cinquième, mis à part qu'il sera engagé seulement si l'objectif inspection pipeline est entré en échec. Les deux objectifs bathymétrie présents alors dans la mission dièrent par leur condition de lancement.
Nous enrichissons alors le modèle d'un objectif en lui ajoutant un nouveau type de condition de lancement :
Echec d'un autre objectif
et un nouveau type de condition d'arrêt : Echec.
6.3.2 De l'objectif au sous-objectif
Lorsqu'un objectif est sélectionné par le superviseur global pour être exécuté, il est décomposé en une séquence de sous-objectifs. Comme illustré à la gure 6.13(a) l'objectif inspection de pipeline est décomposé en la séquence de sous-objectifs suivante :
plonger, aller à,
rechercher pipeline, suivre pipeline.
Cependant, cette décomposition doit être adaptée au contexte. Dans l'exemple illustré à la gure 6.13(b) le véhicule se trouve déjà en profondeur. Pour accomplir l'objectif inspection de pipeline dans ce cas, la décomposition devient :
aller à,
rechercher pipeline, suivre pipeline.
6.3 Gestion contextuelle de tâches
Figure 6.11 Réaction à l'échec d'un objectif
Le sous-objectif plonger a été retiré. Nous sommes alors amené à rendre la décom- position d'objectif en sous-objectifs contexte-dépendante. Cette fonctionnalité est assurée par le superviseur local.
6.3.3 Les modules bas niveau
Comme nous l'avons expliqué précédemment, le bas niveau de l'architecture (voir gure 6.14) est en charge de la gestion de l'instrumentation de bord. Plus précisément, il doit exécuter les sous-objectifs en envoyant des commandes aux actionneurs et en évaluant l'état du système (acquisitions capteurs notamment).
Pour exécuter un sous-objectif donné, par exemple le sous-objectif plonger, plusieurs modules bas niveau devront être lancés successivement et périodiquement jusqu'à l'exé- cution complète du sous-objectif. Ces modules sont activés par des requêtes envoyées par l'ordonnanceur.
En consultant la base de données des sous-objectifs, l'ordonnanceur connaît, pour un sous-objectif donné l'ensemble des modules à activer, l'ordre d'activation, la durée d'exécution du module ainsi que la période à laquelle il devra répéter cette opération.
Ainsi pour exécuter le sous-objectif plonger, un module capteur gérant un sondeur sera activé pour pouvoir déterminer la distance au fond, un module action implémentant une loi de commande récupère cette valeur pour calculer une valeur de commande pour les actionneurs, en n les modules actionneurs concernés appliquent la commande calculée. Comme plusieurs sous-objectifs peuvent potentiellement être exécutés simultanément, plusieurs capteurs peuvent alors se trouver en fonctionnement en même temps. Cepen- dant certains capteurs (la plupart du temps des capteurs acoustiques adjacents et/ou de fréquence proche ou multiple) ne peuvent eectuer leur mesure en même temps au risque de produire des interférences qui se répercuteront en erreurs de mesures sur les données acquises.
Lorsque des capteurs acoustiques ont des fréquences similaires, ils peuvent engendrer des interférences s'ils sont utilisés simultanément.
Chapitre 6 : Construction d'une architecture logicielle
Figure 6.12 Modélisation UML d'un objectif
Comme le montre la gure 6.15, les trois capteurs acoustiques présents à l'avant du véhicule, ne peuvent fonctionner ensemble car leurs champs d'insoni cation et d'écoute se recouvrent. Dans ce cas si deux sous-objectifs prêts à être exécutés ont besoin de deux capteurs parmi ceux-ci alors ces deux sous-objectifs ne peuvent pas être exécutés simultanément.
Cependant, nous pouvons constater que durant l'exécution d'un sous-objectif, les cap- teurs ne sont pas utilisés continûment mais de façon périodique. Ainsi une façon de per- mettre l'exécution de sous-objectifs requérants des capteurs interférents serait d'activer ces capteurs (donc les modules capteurs bas niveau qui les gèrent) séquentiellement.
On ne peut prévoir à l'avance les ensembles de sous-objectifs qui vont être amenés à être exécutés simultanément durant la mission. Ainsi la prise en compte des contraintes d'interférences capteurs dans l'activation des modules bas niveau sera eectuée en temps réel par l'ordonnanceur.