LinuxFocus Janvier 1999: Un Véhicule Autoguidé basé sur Linux

Vicente Egea, Jorge Garrido, Roberto Guzmán, Ranko Zotovic

Roberto Guzman est spécialiste en Informatique (Système Physique), il a été Professeur et Chercheur dans le domaine de la robotique au Département des Systèmes et Automatismes de l'Université PolyTechnique de Valence, et aussi chercheur dans le Département de Gestion de Production et de Régulation à l'université de Fern-Hagen en Allemagne. En ce moment, il travaille dans le département Recherche et Développement de TMC-Electronics.

Ranko Zotovic est ingénieur dans l'industrie. Il possède plusieurs années d'expérience dans l'implémentation et la conception industrielle de robots, automate de découpe, contrôle qualité, etc.... Il est actuellement professeur de Robotique et CAO/CFAO au Département des Systèmes et Automatismes de l'Université PolyTechnique de Valence.

Jorge Garrido Serrano est spécialiste en Informatique (Système Physique) . Son activité principale a été la conception et le développement de l'architecture logicielle pour le PCBot. Il a remporte le prix Bancaja pour les Partenariats Industriels. En ce moment, il fait partie du projet européen "MobiNet" (Mobile Robotics Technology for Health Care Research) de l'université de Ferm-Hagen (Allemagne).

Vicente Egea Mañas est spécialiste en Informatique (Système Physique). Il a aussi remporte le prix Bancaja pour les Partenariats Industriels pour la conception et l'implémentation de l'architecture 'hardware' du PCBot. Il travaille actuellement au TGI.
Contactez l'Auteur:

Index:
Introduction
Description du Véhicule
Architecture Logicielle
Conclusion

Un Véhicule Autoguidé basé sur Linux

Synthèse: Le champ de la robotique mobile a connu une croissance énorme lors des dernières années. Beaucoup de départements de Robotique, Mecatronic, et d'Intelligence Artificielle ont concentré une partie de leurs recherches à l'étude des véhicules autonomes. Jusqu'à maintenant, les coûts élevés de R&D ont limité leur utilisation dans l'aérospatiale, dans les domaines militaires, et dans les centrales nucléaires. Néanmoins, la proliferation des développements dans ce domaine permet l'introduction de cette technologie dans les domaines commerciaux de l'agriculture, et aussi dans l'industrie, des services, des mines, de la médecine et d'autres encore. C'est un secteur stratégique avec un fort potentiel de croissance.

Introduction

Les véhicules autoguidés commercialisés aujourd'hui, ont un grand nombre de défauts qui limitent leur utilisation au domaine de la recherche. On peut citer notamment des coûts élevés, des architectures "fermées" et propriétaires, un manque de documentation, une difficulté d'ajustement, et ceci tant au niveau matériel qu'au niveau logiciel.

Au Département des Systèmes et de l'Automatisation, nous avons pris la décision de construire un véhicule autoguidé, dans notre laboratoire, ne comportant aucun des inconvénients mentionnés. Nous avons choisi d'utiliser une architecture basée sur une carte PC pour ses avantages énormes : prix, puissance, compatibilité, adaptabilitï¿½ et la disponibilité de matériels et de logiciels. L'utilisation des extensions temps réel de RT-Linux a rendu beaucoup plus facile la réalisation de ce projet.

Véhicule Autoguidé PC BOT 1.0

Description du véhicule

Notre système est un véhicule holonomique avec deux roues tractées et deux roues de support. Sa cinématique est similaire à celle d'une chaise roulante ou d'un tank. Pour contrôler la vitesse en son centre, nous devons contrôler la vitesse des quatre roues à chaque instant.

La conception distingue deux zones séparées : la région basse, où tous les éléments mécaniques et électriques sont situés, et la région supérieure qui est encombrée avec tous les éléments de contrôle et de communication. La région basse est montée sur un morceau d'aluminium. A ce niveau, sont placées les roues, les réducteurs, les moteurs, les encodeurs et les circuits de puissance, l'alimentation et les batteries. Sur la région supérieure est montée la carte PC ainsi que ses cartes de contrôle et le lecteur de disquette.

Vue de Face et de côté du PC BOT 1.0

L'architecture hardware est basée sur une carte de contrôle qui pilote les moteurs via une un circuit de puissance. Le contrôle de l'axe peut être effectuée par la carte de contrôle ou par le PC. Pour ce projet, nous avons conçus à la fois, les cartes et les logiciels.

Architecture Hardware

Les commandes de contrôle du véhicule sont envoyées depuis un ordinateur distant (host). La carte PC embarquée prends alors soin d'envoyer les commandes appropriées aux cartes de contrôle. Cette dernière génère la tension demandé qui sera amplifiée au niveau du circuit de puissance qui alimente les moteurs. Le mouvement de chaque axe est détecté par un capteur de position (encodeur) et est piloté par la carte de contrôle.

Architecture Logicielle

L'implémentation d'un véhicule autoguidé demande, tout d'abord, un bon asservissement qui garantie, à chaque instant, la stabilité de la position. Ensuite, elle réclame aussi une mise à jour périodique des certaines variables d'états, comme par exemple pour déterminer la position du centre du véhicule à chaque instant.

Ces deux exigences, nous obligent à utiliser un système temps réel. Les systèmes d'exploitation temps réel sont ceux dont les performances dépendent non seulement des calculs mais aussi du temps avec lesquels, ils sont obtenus.

Nous avons donc décidé d'implementer l'architecture logicielle de PCBot avec un noyau Linux 2.0.33 et les extensions temps réel (version 0.6).

Les raisons d'utiliser Linux et RT-Linux sont les mêmes raisons qui poussent de nombreuses compagnies d'automatismes à implementer leur logiciel en utilisant ce système d'opération:

Le système d'exploitation utilise les ressources hardware correctement et est très stable.
Le code source est public et par conséquent facile à modifier et à enrichir.
Les coûts de développement sont faibles et même parfois nuls.
Il possède une extension temps réel puissante et gratuite, avec des utilitaires et des services du même niveau que leur homologues commerciaux.
Le support technique, une multitude d'enthousiastes, est excellent.
Il existe un grand nombre de documentations sur la Toile.

Le système d'exploitation temps réel RT-Linux a été développé au département informatique du Minning and Technology Institute de New Mexico par Victor Yodaiken et Michael Barabanov. Le schéma suivant montre une partie de son architecture. Le noyau temps réel tourne au niveau le plus proche du hardware. Un programmateur avec des priorités statiques gère une série de tâches en temps réel avec un accès total au hardware. Linux, lui même est vu par le programmateur comme un tâche temps réel, avec une priorité basse, qui fait qu'il est exécuté si du temps machine est disponible.

Le systï¿½me temps rï¿½el RT-Linux

L'architecture logicielle du PCBot est basé sur le modèle client serveur que chacun connaît. Le serveur tourne sur le robot, traîtant les requêtes qui lui parviennent des clients qui tournent sur les machines distantes. Les échanges entre le client et le serveur sont véhiculé via TCP/IP.

Utiliser TCP/IP pour les échanges rend le robot indépendant du système d'exploitation qui tourne sur la machine distante. Le client relais les commandes saisies par l'utilisateur vers le robot. Il existe trois types de commandes : celles de mouvement, celles pour obtenir l'état du robot et enfin celles qui permettent de changer cet état. Le client vérifie la syntaxe de la commande entrée, construit le message adéquat pour le serveur et lui envoi en utilisant Sockets.

Le serveur attend constamment les connections venant du client. Une fois la connexion établie, le serveur devient l'intermédiaire entre le client et le module temps réel qui fait tourner les tâches de contrôle. Le module temps réel exécute les commandes acceptées par le robot. Il supervise aussi l'intégrité du système grâce à sa tâche périodique de type Watchdog.

Architecture Logicielle

Il existe donc deux parties séparées qui constituent l'architecture logicielle. Une est exécutée sur le système d'exploitation Linux, une autre doit tournée sur un système temps réel (RT-Linux) à cause de ces exigences temporelles. Le serveur tourne sur Linux et est situé sur le PC à l'intérieur du véhicule. Le client, qui est aussi une application sans exigences temporelles, n'a pas besoin d'être sur le PC embarqué.

Le module temps réel est donc une suite de tâche temps réel (commandes de mouvement et tâches de surveillance WatchDog) et de tâche sporadique (pilotage et arrêt).

Un sémaphore binaire protège l'accès au hardware par les tâches temps réel. Nous avons besoins d'un sémaphore pour plusieurs raisons. Tout d'abord, la façon de comuniquer avec la carte de contrôle utilise un registre système si la tâche est interrompu par une autre tâche alors une donnée invalide sera écrite dans le registre. Ensuite, il existe des valeurs de registres qui sont la base de protocoles qui ne doivent pas être interrompus. Enfin, les transferts des actions de contrôle sur chaque axe doit être effectué de la façon la plus simultanée que possible.

Trois piles rt-fifo implï¿½mentent la communication entre les tâches temps réel et le serveur. Le serveur écrit la commande de mouvement, qui provient du client, sur la pile. Le module temps réel se sert des deux autres piles pour passer un accusé de réception au serveur ou pour faire part au client, via le serveur, d'une situation critique.

Une séquence classique se dï¿½roule donc comme celle-ci : l'utilisateur lance un processus client qui agit comme une interface entre le client et le PCBot. Après chaque commande saisie, le client la traite et l'envoie au serveur. Le serveur reçoit le message traité et le retraite avant de l'envoyer au module temps réel via la pile appropriée.

Un processus pilote, attaché à la pile, contrôle la commande et si un mouvement est demandé, lance la tâche temps réel nécessaire et renvoie une confirmation au serveur. La tâche ainsi démarrée va piloter les actions pour actionner les moteurs.

Derrière une commande de mouvement, l'utilisateur peut avoir envoyé une requête d'état ou un changement d'état. Dans ce cas, le même processus pilote réponds à la requête en lisant ou en écrivant vers les variables globales d'état.

Les variables globales sont allouées dans un espace mémoire partagé par tous les modules temps réel et par le processus pilote. Ces variables globales permettent une simple et rapide communication entre ces tâches. Le "WatchDog" les surveille (en plus d'autres tâches) et avertit le serveur des changements dans l'état du véhicule, et aussi des situations anormales.

Architecture Logicielle - Tâches Système.

Conclusion

Un système basé sur les PCs a de nombreux avantages comme les coûts réduits, la mise à jour aisée du hardware et des logiciels, la flexibilité grâce à la quantitï¿½ des logiciels disponibles et enfin la puissance qu'il a à effectuer des opérations. De plus, le hardware ne devient jamais obsolète car il suffit de le remplacer par celui de la génération suivante et on conserve, par ce biais, une compatibilité parfaite avec les logiciels existants.

Choisir Linux et son extension temps réel RT-Linux fut une décision très heureuse. Nous avons utilisé les puissant outils GNU de développement comme wpe (Windows Programing Environment) ou encore le compilateur GNU C sans frais supplémentaires.

Le système Linux n'a pas seulement démontré sa stabilité durant nos expérimentations mais il a aussi montrer qu'il sait gérer de façon très efficace les ressources machines, ce qui nous a permit d'utiliser une simple carte embarquée PC 486 sans jamais être pénalisé au niveau des performances ou du temps de développement (plusieurs utilisateurs en parallèle sur la machine). En fait, notre analyse de la disponibilité du système démontre que même dans le pire des cas, 70% du temps machine était libre.

Les logiciels utilisés durant le projet sont dans le domaine public, donc toutes les sources étaient accessibles durant tout ce temps. Cela nous a permit d'avoir une compréhension détaillée du fonctionnement du coeur du noyau temps réel, nous ouvrant les portes pour ajouter de nouvelles fonctionnalités (utiliser d'autres gestionnaires de temps, développer des pilotes temps réel, etc..) ce qui aurait impossible avec des véhicules commerciaux.

RT-Linux peut être facilement débugguï¿½ en temps réel en utilisant des techniques variés allant de la modification du noyau au stockage et à la visualisation de variables internes en invoquant la routine système printk.

Durant la période de développement, nous avons toujours pu compter sur le soutient inconditionnel des membres de la liste de diffusion à propos de RT-Linux et aussi sur la quantitï¿½ grandissante de documentation accessible.

Références

http://www.rtlinux.org

Autre articles sur RT-Linux dans LinuxFocus:
Linux Temps rï¿½el
Linux Temps rï¿½el II

Original en Espagnol

Traduit en anglais par Miguel Angel Sepulveda

Traduit en franï¿½ais par Laurent Hausermann.