Architectures spécifiques

• Development of an Underwater Robot, ODIN-III
  [Choi et al. 2003] : ODIN03
  Cet article présente l'URV (underwater robotic vehicle) ODIN-III. La partie logicielle de l'URV s'exécute sous le COTS Windows2000 avec RTX, et utilise le système de DLL pour implanter et tester plus facilement différents types d'algorithmes. L'URV est connecté à une station au sol, qui peut le commander directement ou simplement servir de station d'observation. L'architecture du système est composée de cinq niveaux (mais on peut considérer que les deux premiers font partie du même niveau fonctionnel, ce qui porterait le nombre a quatre) : un niveau matériel et un niveau de périphériques, un niveau exécutif, un niveau décisionnel, et un niveau de supervision qui contrôle la sûreté de fonctionnement du système d'après un certain nombre de règles et de feedback. Pour le moment le niveau décisionnel et le niveau de supervision ne sont pas très développés. L'article présente ensuite quelques résultats expérimentaux vis-à-vis du planificateur de trajectoire.

• Design of a Prototype Miniature Autonomous Underwater Vehicle
  [Gadre et al. 2003] : MOD003
  Cet article présente un prototype d'AUV (Autonomous Underwater Vehicle) appelé MOD0, dont les objectifs sont : un faible coût de production et une petite taille, la maximisation de la portée et de la robustesse, de permettre une modularité, d'atteindre une profondeur de 200m, et de réaliser en équipe des tâches d'observation. Le prototype réalisé a une longueur de l'ordre de 80cm pour un coût de moins de 3000$, et doit régulièrement remonter à la surface pour déterminer sa localisation. L'article décrit en détail la structure matérielle du prototype (système de propulsion, composants électroniques, capteurs) avant de décrire les modifications apportées au prototype suivant.

• Remote Operation with Supervised Autonomy (ROSA)
  [Gillett et al. 2001] : ROSA01
  Cet article présente l'architecture ROSA qui propose un système dont l'autonomie est variable, pour ravitailler des satellites. Le niveau fonctionnel de cette architecture est composée d'une partie commande et d'une partie capteur ; le niveau exécutif met en place une hiérarchie de ``comportements'' réactifs : des fonctionalités nominales du système. Le niveau décisionel contient trois éléments : un moteur d'inférence qui traduit un script d'ordres de l'opérateur en succession de comportements à exécuter par le niveau exécutif, un superviseur de mission intelligent qui planifie les actions du système en fonction des missions fixées par l'opérateur, et un multiplexeur de commande, qui permet à l'opérateur de définir le mécanisme décisionnel à utiliser et de transmettre des scripts d'ordre ou de nouvelles taches à celui-ci. L'article présente ensuite l'environnement du projet ROSA : la capture puis libération d'un satellite pour son ravitaillement.

• Risks evaluation and Failures Diagnosis for Autonomous tasks execution in Space
  [Finzi et al. 2001] : SITCALC01
  Cet article présente un système de comande basé sur le Situation Calculus, permettant d'évaluer la probabilité de succés des actions du système, et de diagnostiquer leur défaillance. Le système est composé de trois niveaux : un superviseur qui choisit un des objectifs du système et le décompose en plusieurs tâches, un planificateur qui décompose la tâche choisie en une séquence d'action basique et les fait exécuter, et un module de vision qui met à jour la base de données du système et la carte locale. Le fonctionnement du système est de : (1) choisir un objectif puis une tâche à exécuter, (2) vérifier son exécutabilité, déterminer les probabilités de succés et l'exécuter, (3) observer l'état de l'environnement résultant de cette exécution, le diagnostiquer et replanifier la tâche au besoin. L'étape (2) est réalisée en construisant l'arbre de toutes les actions possibles en considérant leurs défaillances, évaluer la probabilité de chacun des résultats à partir de probabilité définies à l'avance pour chaque action, et de choisir celle remplissant l'objectif avec la plus grande chance de succés. L'étape (3) est un diagnostique par comparaison entre les observations réalisées et chaque résultat possible de l'arbre de la tâche pour déterminer la succession d'exécution la plus probable qui a menée à la situation observée. L'article décrit ensuite en détail le langage utilisé par le système pour évaluer le succés d'une tâche et diagnostiquer une défaillance. Il présente enfin l'implémentation du module de vision, et le langage utilisé par le superviseur.

• A New Breed of Explorer : Development of a Network of Mobile Robots for Space Exploration
  [Barfoot et al. 2001] : RISE01
  Cet article présente le mini-rover autonome RISE, conçu selon une architecture subsumptive dans un cadre multi-agent pour l'exploration spatiale. Il décrit les différentes caractéristiques du robot, en commençant par ses capacités sensorielles : des capteurs infra-rouge et d'autres haptiques de type moustache). La navigation est mise en place en étudiant la position de trois repères, naturels ou artificiels, et par odométrie entre chacun de ces repérages. Les robots communiquent entre eux par fréquence radio pour connaitre la position de chacun. L'architecture logicielle est de type subsumptive : 14 comportements ordonnés par priorité. L'article présente quelques résultats, en simulation et en opération, et une discussion sur les avantages et défauts de ces robots.

• Onboard Autonomy on the Three Corner Sat Mission
  [Chien et al. 2001] : 3CS01
  Cet article présente les composants relatifs à l'autonomie de la mission Three Corner Sat, prévue pour lancer trois satellites fin 2002, mais qui semble avoir été abandonnée. Trois composants sont particulièrement étudiés : SCL (Spacecraft Command Language), un exécuteur de script COTS, CASPER, un planificateur également utilisé dans l'architecture CLARAty, et SELMON, un système de contrôle et de détection des défaillances. SCL met en oeuvre le niveau exécutif de cette architecture, générant des tâches et réagissant à des événements à travers des scripts de règles et de fonctions, et maintient une base de données sur l'état du système. CASPER est un logiciel de planification continue, qui à chaque appel modifie le plan précédent et l'étend jusqu'à un nouvel horizon, afin de minimiser le temps pris pour chaque planification. Un cylce de planification se déroule comme suit : modification des objectifs et de l'état courant du plan, propagation de ces modifications dans le plan, appel d'algorithmes de réparation pour résoudre les conflits et satisfaire les nouveaux objectifs. SELMON est supposé s'exécuter en complément de SCL pour enregistrer des informations sur l'état du système et détecter des anomalies à travers différentes techniques : chien de garde, comparaison entre les valeurs des capteurs et un modèle du système...