Projet Icare

Précédent : Logiciels Remonter : Projet ICARE, Instrumentation, Commande et Suivant : Actions industrielles

Résultats nouveaux

Stabilisation de robots mobiles par retour d'état instationnaire

Participants : Claude Samson , Pascal Morin , Dimitris Tsakiris , Patrick Rives , Jean-Jacques Borrelly , Konstantinos Kapellos

Stabilisation de systèmes chaînés

Mots-clés : système chaîné, commande instationnaire, système homogène, retour d'état continu

Résumé : De nombreux systèmes mécaniques nonholonômes sont localement modélisables par des équations canoniques ayant la forme dite chaînée. C'est le cas de véhicules de type unicycle, de véhicules de type voiture, ou encore de trains de remorques à attaches «non déportées». Il est de ce fait devenu usuel d'aborder le problème de la commande de robots mobiles à roues, dont celui réputé difficile de stabilisation d'une posture désirée, via l'étude de la commande des systèmes chaînés. Nous avons cette année poursuivi nos travaux sur le sujet en montrant que tout retour d'état linéaire qui stabilise asymptotiquement l'origine d'un intégrateur linéaire d'ordre induit un retour d'état instationnaire continu simple qui stabilise exponentiellement l'origine d'un système chaîné non-linéaire d'ordre à deux entrées. Pour cela, nous avons adapté un de nos résultats antérieurs [6] en nous inspirant d'une méthode développée dans [MM97] qui permet de transformer des retours d'état stabilisant différentiables conduisant à une convergence polynomiale lente en des retours d'état continus homogènes assurant une convergence exponentielle.

L'essence du résultat, décrit plus en détails dans [15], est le suivant.
Soient :

un ensemble de paramètres positifs , ( $i=2, \ldots ,n$ ), tel que le polynôme $P(s)=s^{n-1}+a_ns^{n-2}+ \ldots +a_js^{j-2}+ \ldots + a_2$ est stable au sens du critère de Routh-Hurwitz (i.e. a toutes ses racines dans le demi-plan complexe gauche).
le système chaîné à deux entrées :

$\begin{displaymath}\begin{array}{lll}\dot{x}_1 & = & u_1 \\ \dot{x}_2 & = & u... ...ot{x}_{n-1} & = & u_1 x_n \\ \dot{x}_n & = & u_2 \\ \end{array}\end{displaymath}$
l'opérateur de dilatation :

$\begin{displaymath}\delta (\lambda, x_1, x_2, \ldots , x_n)=(\lambda^{r_1}x_1, \ldots ,\lambda^{r_n}x_n)\end{displaymath}$

avec et ( $q\gt$ ) pour $i=2,\ldots ,n$ .
une fonction réelle positive et propre $\rho(x_2,\ldots ,x_n)$ , homogène de degré un par rapport à l'opérateur de dilatation $\delta (\lambda, x_1, x_2, \ldots , x_n)$ . Par exemple :

$\begin{displaymath}\rho(x_2,\ldots ,x_n)=(\sum_{i=2}^{i=n}\vert x_i\vert^{\frac{p}{r_i}})^{\frac{1}{p}}~~~~~p\gt.\end{displaymath}$

Alors il existe $q_0\gt$ tel que $q \geq q_0$ entraîne que le retour d'état instationnaire :

$\begin{displaymath}\begin{array}{lll}u_1(x,t) & = & -k_1 x_1 + \rho(x_2,\ldot... ...i sign(u_1)^{n+1-i}x_i/\rho(x_2,\ldots ,x_n)^{n+1-i}\end{array}\end{displaymath}$

stabilise asymptotiquement et globalement l'origine du système chaîné. De plus les solutions du système commandé convergent exponentiellement vers zéro du fait que ce système est homogène de degré zéro par rapport à l'opérateur de dilatation $\delta (\lambda, x_1, x_2, \ldots , x_n)$ .

Stabilisation d'un bras mobile par commande instationnaire référencée vision

Mots-clés : bras mobile, commande référencée vision, retour d'état instationnaire

Résumé : Le projet utilise un bras mobile, constitué d'un véhicule de type unicycle sur lequel est monté un bras manipulateur, à des fins de validation de concepts nouveaux, d'intégration de l'ensemble des composantes (matérielles, logicielles, algorithmiques) intervenant dans la chaîne de commande des systèmes robotisés, et d'expérimentation. Afin d'étudier les aspects de commande référencée capteurs, ce dispositif est actuellement complété par une ceinture de capteurs à ultrasons et par une caméra montée à l'extrémité du bras manipulateur. Le problème que nous avons tenté de résoudre est celui de l'adaptation des lois de commande instationnaires, telles que celles présentées ci-dessus, au cas d'un bras mobile utilisant une information visuelle pour se localiser et se positionner dans son environnement. Il s'inscrit dans la problématique plus générale de la commande des systèmes hybrides holonômes/nonholonômes. Il s'agit, à notre connaissance, de la première tentative de commande instationnaire référencée capteurs.

Le principe de la commande référencée capteurs repose sur la détermination adéquate et la régulation à zéro d'une fonction de tâche vectorielle dont les composantes sont mesurables par le biais de capteurs d'environnement (embarqués ou non sur le robot). Cette fonction doit, à l'instar du vecteur de configuration du robot (dont la mesure n'est pas toujours directement accessible) caractériser de façon unique la configuration du système robotique par rapport à son environnement (ses composantes, en nombre égal à celles de ,constituent en quelque sorte un second système de coordonnées généralisées). La régulation à zéro de cette fonction traduit la tâche que l'on désire faire réaliser au robot.

L'expérience que nous avons mise en place consiste à observer, par le biais de la caméra montée à l'extrémité du bras mobile, une cible géométrique (matérialisée en l'occurrence par trois montants parallèles dont les intersections avec un plan orthogonal coincident avec les sommets d'un triangle isocèle), et à stabiliser le bras mobile face à cette cible. Lorsque la cible est déplacée, le bras mobile doit être capable de se repositionner automatiquement et de se stabiliser à nouveau face à la cible. Pendant le déplacement du bras mobile, il importe aussi de toujours maintenir la cible dans le champ de la caméra de sorte que l'information de localisation ne soit jamais perdue. Cette expérience peut donc aussi être interprétée comme une expérience de suivi de cible.

Dans le cas présent, le bras manipulateur est configuré comme une tourelle possédant un degré de liberté en rotation de sorte que la caméra puisse pointer dans une direction quelconque du plan, quelque soit l'orientation de la base mobile. Ultérieurement, l'ensemble des degrés de liberté du bras manipulateur sera utilisé pour étudier les aspects de redondance mécanique. Le deux autres degrés de liberté du système sont ceux propres à la base mobile. Le vecteur de configuration de l'ensemble (base mobile+bras) est quant à lui constitué du vecteur tridimensionnel de coordonnées de position et orientation de la base mobile dans le plan, exprimées dans un repère cartésien fixe lié à la cible, et de la variable articulaire du bras. Le repère cartésien est choisi de sorte que corresponde à la situation désirée pour la base mobile. La différence, égale à un, entre le nombre de degrés de liberté et le nombre de variables de configuration correspond au degré de nonholonomie du bras mobile. La fonction de tâche que nous avons considérée est ,où est une variable mesurée dans l'image qui caractérise le défaut de pointage de la caméra vers la cible.

Une difficulté importante, mise en évidence par cette expérience, provient du fait que l'état de la base mobile, que les études de commande par retour d'état instationnaire ont jusqu'à présent supposé mesurable, n'est en réalité observable que par le biais de l'information contenue dans l'image de la cible. On sait d'autre part que la «reconstruction» de cet état à partir de mesures issues de capteurs d'environnement est généralement entachée d'imprécision et d'erreurs. Cet aspect du problème est d'ailleurs une des motivations majeures des études de robustesse réalisées dans le cadre de la commande des bras manipulateurs holonômes. L'expérience pose donc de façon concrète deux questions sur lesquelles nous avons commencé à travailler : i) comment adapter les lois de commande par retour d'état instationnaire au cadre de la commande référencée capteurs, dans le cas de systèmes nonholonômes, et ii) est-il possible de robustifier ces lois de commandes vis-à-vis d'erreur de modélisation, celles provenant de l'utilisation de capteurs d'environnement en particulier? Cette seconde question introduit par ailleurs une question encore plus fondamentale pour l'Automatique, à savoir le sens qu'il est possible de donner au concept de stabilisation des systèmes non-linéaires.

Le travail de cette année a essentiellement porté sur la première question. Dans [22,23], deux méthodes de commande instationnaire référencée capteurs sont décrites, avec les premiers résultats expérimentaux que nous avons obtenus. Bien qu'encourageants, ces résultats illustrent aussi clairement les limitations et le défaut de robustesse des lois de commande jusqu'ici proposées. De nouvelles études sont de ce fait prévues pour essayer de remédier à ces limitations.

Perception et autonomie

Participants : Patrick Rives , Jean-Jacques Borrelly , David Djian , Laurence Pelletier , Jose-Luis Carrilho-Sequeira

Planification de tâches référencées capteurs et navigation sûre

Mots-clés : planification de chemins, carte de visibilité, actions référencées capteurs, réactivité

Résumé : L'objectif que nous poursuivons est de fournir à l'utilisateur une méthodologie et un ensemble d'outils lui permettant de spécifier, analyser et implémenter une application robotique en enchaînant des tâches élémentaires référencées capteurs. Cette approche nécessite, d'une part, de définir des actions élémentaires référencées capteurs permettant de contrôler l'interaction entre le robot et son environnement local, et, d'autre part, de manipuler ces actions élémentaires au niveau de la planification afin de produire une séquence d'actions permettant de réaliser la tâche robotique.

L'utilisation de modèles de torseur d'interaction [3], issus de recherches antérieures, permet de spécifier des tâches locales sous formes de contraintes géométriques entre les capteurs et des éléments de l'environnement, et également de dériver des schémas de commande possèdant de bonnes propriétés de robustesse. Grâce à ce formalisme, nous avons établi un catalogue d'actions élémentaires canoniques référencées capteurs (suivi de surface, positionnement vis à vis de cibles...) pouvant être instanciées pour différents types de capteur (vision, ultrason...) et différents types de primitives géométriques de l'environnement. Cette année, le travail a porté sur la manipulation de ces actions au niveau de la planification.

Ce travail a été initialisé dans le cadre de l'action de développement PRAXITELE, avec comme problématique, la conduite automatique d'un véhicule dans un environnement de type «parking». Nous supposons, dans un premier temps, que cet environnement est structuré, statique et connu. Les méthodes développées seront applicables à tout environnement répondant à ces critères, notamment les environnements d'intérieur. Notre approche est basée sur le partitionnement de la carte de l'environnement en lieux caractérisés par le type d'action élémentaire que l'on peut y réaliser. Une action élémentaire étant définie par un couple constitué d'une primitive géométrique locale de l'environnement et d'un capteur, le calcul des cartes de visibilité des primitives présentes dans l'environnement est indispensable au calcul du partitionnement. Il est apparu, après discussion avec les spécialistes de géométrie algorithmique du projet PRISME, que très peu de résultats existaient et étaient exploitables concernant le calcul de cartes de visibilité telles que nous les définissons : domaine de l'espace duquel on peut voir totalement ou partiellement une primitive géométrique. Nous avons donc entrepris l'extension du calcul de la carte de visibilité des sommets d'un polygone (cas où il existe un algorithme de calcul par balayage efficace) au calcul de la carte de visibilité des arêtes. La conjecture que nous essayons de démontrer est la suivante :

Il existe un ensemble $I =\{S_0 \ldots S_m\}$ de points de l'arête, avec $m \leq \frac{n.(n-1)}{2}$ où est le nombre de sommets contenu dans le demi plan extérieur à l'arête, tel que l'union des cartes de visibilité des points de est la carte de visibilité de l'arête.
Ces points appartiennent à l'intersection de l'arête avec l'ensemble des droites passant par au moins deux éléments de l'ensemble constitué par les sommets et les deux extrémités de l'arête.

Dans des environnements contenant des obstacles de grande taille vis-à-vis de la longueur des arêtes, le nombre est très inférieur à $\frac{n.(n-1)}{2}$ . Une preuve mathématique de cette conjecture est en cours de démonstration ainsi qu'une implémentation d'un algorithme de calcul de la carte de visibilité en s'appuyant sur la bibliothèque de calcul géométrique LEDA.

Une fois que le partitionnement de l'espace en régions de visibilité étiquetées par l'ensemble des actions élémentaires référencées capteurs admissibles sera réalisé, le problème de la planification de chemin pourra être posé en terme d'optimisation d'un critère de parcours de graphe.

Perception pour l'exploration et la localisation d'un robot mobile

Mots-clés : recalage, odométrie, ultrasons, fusion, filtrage

Résumé : Dans de nombreuses applications de robotique mobile, il est important de pouvoir localiser le robot vis-à-vis de son environnement. Cette localisation peut être réalisée en intégrant les données odométriques. Le résultat est cependant peu fiable du fait des glissements des roues et des défauts géométriques du robot. Il est donc utile de compenser cette dérive de localisation odométrique en se recalant vis à vis de l'environnement à l'aide de mesures extéroceptives. Dans le cas de scènes d'intérieur relativement structurées, les proximètres à ultrasons permettent, pour un faible coût, d'obtenir des mesures de distances pouvant être utilisées pour la localisation. En contrepartie, ces mesures sont souvent de mauvaise qualité et contiennent de nombreux artéfacts qui doivent être filtrés. De plus, le modèle géométrique de l'environnement est souvent mal connu. Nous étudions dans cet axe de recherche des techniques permettant à la fois la localisation et la construction incrémentale d'une carte de l'environnement

Les résultats obtenus cette année portent sur deux aspects. Tout d'abord, la robustification des mesures fournies par les capteurs ultrasons. D'un point de vue purement géométrique, un capteur ultrason (US) est un télémètre fournissant la plus courte distance à un obstacle situé dans son champ de vision. Cet obstacle se comporte en général comme un miroir compte tenu des longueurs d'onde utilisées. Nous avons utilisé cette propriété pour constituer à partir de deux capteurs US élémentaires fonctionnant l'un en émission/réception et l'autre uniquement en réception, un système télémétrique basé sur la triangulation fournissant en sortie à la fois la distance et l'orientation d'une cible supposée localement planaire. La possibilité d'inverser le rôle des capteurs renforce la fiabilité de la mesure en introduisant de la redondance. Cette technique a été validée en simulation et sur données réelles. Les précisions obtenues sont de l'ordre du centimètre dans une gamme de 0.5 à 1.5m et du degré pour une inclinaison d'une cible plane dans une gamme de +/-30 degrés.

Le deuxième aspect ayant donné lieu à des résultats concerne la définition d'un algorithme de fusion entre données odométriques et données US dans un but de localisation. Cet algorithme met en oeuvre un filtre de Kalman étendu utilisant les données odométriques dans l'équation d'évolution et de prédiction de l'état $(x(k), y(k), \theta(k))$ du robot et les mesures fournies par le capteur US dans l'équation d'observation. Un second filtre, permet de mettre à jour, après chaque localisation, une représentation incrémentale de la scène définie dans le repère initial de référence. Un test sur la matrice de covariance des données reconstruites permet à l'instant de n'utiliser dans le processus de localisation que les données suffisamment sûres.

Afin de valider cet algorithmique, un simulateur complet a été écrit en MATLAB, l'implémentation sur le robot expérimental du projet est prévu courant 1998.

Stratégie de vision active pour la reconnaissance

Mots-clés : vision active, réseaux Bayésiens, apprentissage, reconnaissance de forme

Résumé : Dans le contexte de la navigation d'un robot mobile, il est souvent utile de pouvoir identifier des éléments caractéristiques de l'environnement, soit pour les utiliser à des fins de localisation, soit pour s'asservir dessus au moyen de boucles de commande référencée capteurs. Cela est particulièrement vrai lorsque la navigation s'appuie sur une modélisation topologique de l'environnement. Dans ce cas, le système de perception doit être capable de reconnaître des points de passage (par exemple, une porte) qui jalonnent le trajet menant d'un lieu à un autre. Un travail de thèse, en collaboration avec le Groupe de Robotique de l'université d'Oxford a permis de poser les bases d'une stratégie de vision active pour l'apprentissage et la reconnaissance d'objets.

L'originalité de l'approche est de prendre explicitement en compte la notion d'utilité d'une action de perception et celà, directement au niveau du modèle de la scène. La stratégie de perception peut alors s'exprimer de la façon suivante : sachant la connaissance à l'instant sur l'état de l'environnement, quelle est l'action la plus utile pour renforcer cette connaissance à l'instant . La volonté a été de rendre cette approche la plus générale possible : i) indépendante des capteurs physiques en utilisant le formalisme des capteurs logiques, ii) utilisant une représentation générique et puissante des connaissances à base de probabilités conditionnelles, iii) utilisant pour la manipulation de ces connaissances des réseaux Bayésiens pouvant être générés automatiquement à partir de vues réelles des objets (figure .a) par une méthode d'apprentissage supervisé. La figure .b montre les graphes associés aux jonctions et relations entre jonctions des objets simples composant une chaise, pour les vues c01, c04, c05 et c08.

$\begin{figure} \begin{tabular} {ll} \includegraphics[width=6cm]{app_c0_jct.eps} ... ...rentissage.& b) Graphes générés par l'apprentissage.\\ \end{tabular}\end{figure}$

Les résultats obtenus ont permis de construire et de reconnaître des modèles génériques d'objets tels que des portes ou des chaises. Bien sûr, un long chemin reste à parcourir pour traiter des environnements plus complexes. Ce travail a cependant permis de dégager une nouvelle façon de poser le problème de l'analyse de scène dans un cadre de perception active. Il a aussi défini les bases des études futures sur le sujet.

Programmation de systèmes robotiques

Participants : Soraya Arias , Ève Coste-Manière , Konstantinos Kapellos , Daniel Simon , Nicolas Turro

Développements du système ORCCAD

Mots-clés : architecture de contrôle/commande, temps réel, programmation, vérification, simulation

Résumé : L'année a été essentiellement consacrée au développement d'un prototype intégrant les concepts et idées précédemment étudiés. Ce travail de développement logiciel a été mené en étroite collaboration avec le projet BIP et le SERVICE ROBOTIQUE de l'U.R. Rhône-Alpes [10]. Le logiciel est en cours de validation au travers d'expérimentations utilisant notre robot mobile Anis [22] ainsi que d'une mise à disposition et de tests sur une plate forme de manipulation sous-marine au laboratoire de robotique de l'IFREMER [21,14] [SKE97].

Le dévelopement d'ORCCAD s'est poursuivi au travers du dévelopement d'outils logiciels et d'expérimentations menées en interne et en collaboration avec l'IFREMER.

ORCCAD est un ensemble de concepts et d'outils destinés à concevoir, vérifier, simuler et exécuter des applications robotiques variées. Le logiciel comprend les outils suivants (figure ) :

Figure: Outils ORCCAD

$\begin{figure}\centerline{\includegraphics[width=8cm]{toolbox.eps}}\end{figure}$

Le Noyau est une librairie de classes C++ implémentant la hiérarchie de classes proposée dans le modèle de la structure ORCCAD. Les principales classes sont donc les modules, les TâCHES-ROBOT (TR) et les PROCéDURES-ROBOT (PR).
L'Interface graphique, développée sous ILOGVIEWS, permet de créer des instances de la hiérarchie d'ORCCAD. Elle permet de créer des objets de complexité croissante, des modules de base jusqu'à des applications complètes. Les modules de vérification et de génération de code peuvent être activés au travers de cette interface. Cette interface permet en particulier d'instancier et de paramétrer complètement une TâCHE-ROBOT sous forme de modules communiquants (figure ).
Le module de Vérification, utilisant FC2TOOLS et AUTOGRAPH, permet de vérifier les propriétés logiques du contrôleur après composition des actions élémentaires. Certaines propriétés génériques (vivacité, sûreté et absence de conflits pour accéder à une ressource physique) sont automatiquement vérifiées. Une interface graphique particulière permet à l'utilisateur d'accéder aux vues externes de TâCHES-ROBOT et PROCéDURES-ROBOT composant l'application et de créer les critères abstraits permettant la vérification d'une propriété spécifique en cliquant simplement sur les noms de signaux (figure ).
Le module de Simulation permet de simuler le système robot+contrôleur à l'aide de SIMPARC. L'utilisation d'un modèle du système d'exploitation temps-réel permet de simuler une structure de code identique à celle effectivement générée pour la cible réelle.
Le module d'Exécution génère le code exécutable sur l'architecture cible. Les cibles logicielles actuelles sont VXWORKS et SOLARIS utilisant les «threads» POSIX. La version actuelle ne génère automatiquement que du code mono-cadence et monoprocesseur.

Figure: Interface de programmation d'une TâCHE-ROBOT

$\begin{figure}\centerline{\includegraphics[width=8cm]{scheme.eps}}\end{figure}$

Figure: Interface de vérification

$\begin{figure}\centerline{\includegraphics[width=8cm]{verif.eps}}\end{figure}$

Ces différents modules sont en cours d'intégration. Une première version du système, simple mais diffusable, est accessible par http://www.inrialpes.fr/iramr/pub/Orccad/ Jusqu'à présent, dans la plupart des applications réalisées le code de contrôle rassemblant le comportement logique des TâCHES-ROBOT et PROCéDURES-ROBOT est compilé en un seul automate global, permettant en particulier d'effectuer des vérifications formelles du comportement global au niveau le plus haut i.e. celui de la mission. Cependant, cet automate peut atteindre des tailles importantes (plusieurs centaines d'états et plusieurs milliers de transitions), ce qui pose des problèmes pratiques de vérification même si ceux-ci peuvent être partiellement résolus en utilisant des représentations sous forme de diagrammes de décision binaires (BDD). De plus, dans de nombreuses applications embarquées, le logiciel est réparti sur plusieurs noeuds de calcul : dans ce cas, si le contrôleur est situé sur l'un des noeuds de l'architecture matérielle, une rupture de communication entre ce noeud et les autres laisserait les sous-systèmes distants totalement hors de contrôle. Répartir le code de contrôle sur les différents noeuds permet de maintenir la taille des automates dans des tailles raisonnables et d'améliorer les capacités de survie des sous-systèmes en leur conférant une autonomie minimale.

Une technique de répartition du code de contrôle a été testée sur le système de manipulation sous-marine de l'IFREMER [14]. Elle consiste à spécifier et compiler séparément les contrôleurs correspondant aux différents noeuds et les faire communiquer de façon asynchrone. Les canaux de communication entre les contrôleurs sont automatiquement générés en suivant des directives de compilation. Cette solution simple se paye par la perte de la possibilité de vérification formelle globale de la mission : la simulation complète du contrôleur permet alors de valider le schéma d'exécution et en particulier de valider les transitions entre actions élémentaires ([SKE97]).

L'analyse du comportement temporel du réseau de tâches temps-réel communiquantes composant les TRs, modélisées par des réseaux de Pétri temporisés ([SCF97]) est poursuivie : en particulier l'utilisation de l'algèbre (max,+) permet d'affiner l'analyse en modélisant la préemption introduite par l'utilisation d'un ordonnanceur à priorités [BGS97]. Ceci est l'objet d'une collaboration avec F. Baccelli (projet MISTRAL) et B. Gaujal (projet SLOOP). L' optimisation de la répartition du code de calcul en respectant des contraintes de sûreté de fonctionnement est caractéristique du logiciel temps-réel embarqué : ce thème de recherche est l'objet d'une proposition d'action incitative associant les projets BIP, ICARE et SOSSO.

Programmation de missions

Mots-clés : architecture de contrôle, contrôle/commande, système embarqué, programmation orientée domaine, vérification formelle, environnement de programmation, temps réel

Résumé : La programmation de missions touche au niveau d'abstraction où l'utilisateur du système robotique manipule des entités de natures différentes pour spécifier les objectifs de diverses missions (programmation orientée domaine applicatif). Elle implique de définir, d'une part, les entités manipulées (lois de commande, algorithmes de vision, de génération de trajectoires...), et d'autre part, la sémantique et la syntaxe des primitives de manipulation de ces entités (définition d'un langage).

Les entités manipulées

Pour élargir le champ des applications potentielles de notre approche, il est nécessaire de formaliser des entités que la notion de TâCHE-ROBOT ne recouvre pas : algorithmes de planification de trajectoires, de traitement d'images...

La formalisation nécessaire à la manipulation d'algorithmes de vision pour le système de vision ARGES est étudiée en collaboration avec le projet ROBOTVIS. Les premiers résultats de cette étude dépassent la simple utilisation des modules de vision dans des applications robotiques [11]. Ils montrent la nécessité de concevoir de façon globale la programmation des applications de vision, chose que notre approche permet de faire. Actuellement, l'objectif est de proposer des concepts équivalents à ceux de la TâCHE-ROBOT, en prenant en compte la spécificité du domaine applicatif de la vision (cf figure ).

Cette étude a également permis d'adapter le code temps-réel généré par ORCCAD sous SOLARIS en respectant la norme POSIX. Cette tentative de standardisation a été validée expérimentalement sur le même système expérimental. Les résultats obtenus constituent un premier pas vers la portabilité sur différents systèmes supportant le temps réel. Ils ont depuis été intégrés dans le système ORCCAD et utilisés pour programmer une application de vision.

Figure: Spécification d'un module de lissage d'image avec ORCCAD

$\begin{figure}\centerline{\includegraphics[width=8cm,height=6cm]{lissage.ps}}\end{figure}$

Langage de programmation de mission

Initialement, ESTEREL avait été pressenti comme pouvant servir de langage de programmation de missions. Malgré les avantages maintenant reconnus de l'approche synchrone (cadre formel de manipulation de la réactivité et preuves associées), l'utilisation d'ESTEREL et des outils de vérification associés n'est pas toujours bien adaptée du fait de la complexité introduite par le caractère généraliste du langage et d'une insuffisance à représenter les actions asynchrones propres au contexte qui nous intéresse.

Il nous est apparu souhaitable de fournir à l'utilisateur un langage «plus naturel» (de type «scénario», ou «domain specific» dans la terminologie anglo-saxone), moins généraliste qu'ESTEREL, mais conservant toutefois les avantages de l'approche synchrone. On propose ainsi un ensemble d'opérateurs permettant de manipuler les vues abstraites des actions élémentaires identifiées et pouvant être traduits dans un cadre formel tel qu'ESTEREL.

L'outil logiciel CENTAUR, développé dans le projet CROAP, nous a permis d'implémenter un prototype évolutif de langage de programmation de missions, baptisé MAESTRO [2].

La sémantique opérationnelle est obtenue par traduction dans un langage cible (ici le langage synchrone ESTEREL). La traduction a plusieurs avantages. D'une part, elle rend la spécification indépendante du modèle formel choisi comme cible de traduction (on pourrait envisager dans le futur une traduction selon le formalisme TIMED-ARGOS comme proposé à Grenoble dans le projet BIP) tout en masquant certaines subtilités de programmation. D'autre part, elle effectue de façon automatique et transparente des vérifications préliminaires sur la cohérence de la spécification (e.g. portées des actions manipulées).

Un prototype de MAESTRO est déjà disponible (Figure ). Il possède un ensemble d'opérateurs permettant d'exprimer le séquencement, le parallélisme, et l'itération d'actions (SEQ, PAR, LOOP, UNTIL, PROCéDURE,...). Les actions qu'il manipule sont paramétrables. La traduction en langage cible ESTEREL des opérateurs, des PROCéDURES-ROBOT, et des TâCHES-ROBOT est réalisée de manière automatique lorsque la cohérence de la spécification a été validée. Certaines propriétés logiques sont garanties par construction (vérification par méthodes comportementales). La vérification des propriétés opérationnelles correspondant à la réalisation de l'objectif final de l'application n'est, par contre, pas garantie a priori. Cependant, la forme compacte de spécifications proposée contraint l'utilisateur final à rester proche des objectifs de l'application.

Figure: L'environnement MAESTRO de spécification de missions robotiques. Dans cet exemple de programmation de mission robotique sous marine, la spécification de 30 lignes en MAESTRO conduit à 900 lignes d'ESTEREL et à un automate fini de 88 états

$\begin{figure}\centerline{\includegraphics[width=15cm]{maestro.ps}}\end{figure}$

La vérification formelle des programmes obtenus est pour l'instant effectuée de façon classique sur les automates produits par compilation du code ESTEREL généré (cf figure ). Nous étudions aussi la possibilité d'effectuer des diagnostics, c'est-à-dire d'interpréter les résultats de la vérification formelle afin d'éclairer l'utilisateur sur les modifications à apporter au programme source MAESTRO.

Plusieurs expérimentations de programmation de missions ont été menées, ou sont en cours de réalisation, afin de tester et valider le prototype de MAESTRO. Elles portent sur le véhicule sous-marin VORTEX de l'IFREMER [RCMe97,CMHe97], sur la coordination de deux bras mobiles du Robotics Lab de l'université de Stanford, et sur le système de vision ARGéS (dans le cadre d'une collaboration avec Th. Vieville du projet ROBOTVIS). Cette dernière expérimentation a permis de valider l'ensemble des opérateurs du langage. Les premiers résultats tendent à montrer que MAESTRO peut être utilisé pour divers systèmes, même au delà du cadre d'application initialement imaginé pour son développement. Des expérimentations futures sont prévues pour compléter ces résultats.

Moyens expérimentaux

Participants : Jean-Jacques Borrelly , Patrick Itey

Laboratoire de robotique

Le laboratoire de robotique met à disposition des utilisateurs du projet ICARE trois plateformes expérimentales. Chacune de ces plateformes (éventuellement multiprocesseurs) fonctionne sous un système opératoire temps-réel (VxWorks). Tous les noyaux temps-réel correspondants possèdent l'option multiprocesseurs (VxMP) et l'option d'analyse temps-réel (windView). Ces plateformes sont interconnectées entre elles et reliées au réseau général par ETHERNET.

Plateforme mobile avec système de perception
Cette plateforme est constituée d'une base mobile et d'un bras manipulateur à six degrés de liberté embarqué. Elle est également équipée d'une ceinture de huit capteurs ultrasonores et d'une caméra située sur l'organe terminal du bras.
L'ensemble a subi une remise à niveau portant sur les points suivants :
- les ensembles moto-réducteur de la base ont été modifiés de manière à augmenter notablement (facteur 12) les couples moteur disponibles,
- le train avant a été modifié de manière à obtenir un meilleur roulement et surtout afin de limiter les perturbations liées au retournement des roues folles,
- la commande de bas niveau (régulateurs PID) a été homogénéisée (bras et base identiques) en utilisant systématiquement les interfaces TIP-102,
- les drivers du bras, de la base et des capteurs ultrasonores ont été réécrits de manière à accepter des appels multiprocesseurs grâce à un mécanisme de type RPC.
Système de vision
Le système de vision est constitué d'une carte de traitement bas niveau (gestion de fenêtres, convolutions, extraction de points d'intérêt...), d'une carte de traitement intermédiaire basée sur quatre modules DPS96002 (détermination des paramètres caractéristiques des motifs recherchés par fenêtre) et d'une carte processeur d'usage général pour la gestion de l'ensemble et les traitements haut niveau.

Ces deux ensembles ont été utilisés conjointement dans une application d'asservissement visuel.

Outils de simulation

Le simulateur SIMPARC permet de simuler aussi bien l'évolution dynamique du système (robot manipulateur ou mobile) que l'architecture de contrôle, y compris en prenant en compte des notions de temps de calcul ou d'interruption. Les principaux éléments pris en compte par SIMPARC sont :

la description de l'architecture système sous forme de composants interconnectés grâce à un interface graphique,
la description du modèle dynamique du système commande sous forme d'équations différentielles ordinaires,
les éléments de base d'un OS temps-réel (multitâche, files de messages, sémaphores) en version mono ou multiprocesseurs,
des composants de type capteur géométrique (image, ultrasons),
la description de l'environnement sous formes de segments/facettes.

Le noyau de SIMPARC a été réécrit de manière à faciliter le portage sur différentes architectures. Actuellement SIMPARC fonctionne sur SUN (sunOS5), DEC ALPHA (osf1) et PC (linux).
La couche «run time» propre à ORCCAD a été écrite en utilisant les possibilités de SIMPARCOS. Ceci a permis de réaliser des simulations d'une application d'asservissement visuel spécifiée sous ORCCAD, bien que la génération du code ne soit pas totalement automatisée.

Précédent : Logiciels Remonter : Projet ICARE, Instrumentation, Commande et Suivant : Actions industrielles