Présentation
En anglaisRÉSUMÉ
Longtemps la face cachée de la robotique, l’intégration logicielle des fonctionnalités du robot devient une problématique centrale pour la future industrie de la robotique de service (médicale, d'assistance, etc.). Celle-ci s'organise autour de l'architecture logicielle de contrôle du robot. L'état des lieux, exposé dans cet article, témoigne d’une grande diversité d’approches pour concevoir et développer de telles architectures. Néanmoins, la tendance actuelle privilégie les approches basées sur les composants logiciels et l'utilisation, pour leur programmation, de middleware dédiés au domaine. L'article présente donc des middleware de référence ou au contraire originaux, compare globalement leurs propriétés et en évoque les limites en présentant les solutions émergentes basées sur la montée en abstraction via l'utilisation de l'ingénierie dirigée par les modèles et des langages dédiés. Cette analyse nous permettra d'identifier les caractéristiques exigées pour amener l’intégration logicielle en robotique à une maturité comparable à celle de l'électronique.
Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.
Lire l’articleABSTRACT
Software integration, which has long been the hidden side of robotics, becomes a central issue to reach industry requirements, notably for service robotics. This software integration is organized around the robot’s software control architecture. The state of the art, exposed in this article, reflects a wide range of approaches in designing and implementing this kind of software architectures. Nevertheless, the current trend favours component-based approaches and robotics dedicated middleware - based implementation. Several middleware are briefly presented, from reference to original ones, and compared according to their properties and technical characteristics. Identified limitations show that some aspects should be dealt with at a higher level of abstraction, as suggested by model driven engineering and dedicated domain specific languages. This short survey will lead to identify mandatory characteristics to reach software integration in robotics as mature as electronics integration.
Auteur(s)
-
Robin PASSAMA : Ingénieur de recherche CNRS - Laboratoire d’informatique, de robotique et de microélectronique de Montpellier (LIRMM)
-
David ANDREU : Maître de conférences - LIRMM, université Montpellier 2
-
Didier CRESTANI : Professeur - LIRMM, université Montpellier 2
-
Karen GODARY-DEJEAN : Maître de conférences - LIRMM, université Montpellier 2
INTRODUCTION
La robotique est par essence multidisciplinaire, traitant dès leur origine des problèmes couplant mécanique, automatique, électronique, informatique, etc. sans omettre ceux relatifs au domaine d’application lui-même. Elle doit ses progrès aux avancées réalisées dans chaque discipline ainsi qu’à leur croisée. Les robots sont des entités technologiques de plus en plus complexes auxquelles sont confiées des missions toujours plus compliquées, relevant d’une multitude de domaines applicatifs. Les spécificités des divers domaines d’application et des grandes catégories de robots (robotique terrestre, sous-marine, aérienne) sont souvent à l’origine de solutions différentes. Certaines applications vont requérir une réactivité importante et des capacités décisionnelles moindres, d’autres auront des besoins de planification importants, etc.
Cette complexité induit de nombreuses exigences, notamment sur l’informatique censée gérer le fonctionnement du robot et supporter ses capacités d’action, d’adaptation, de décision, etc., cette « intelligence » que lui confère son contrôle. C’est donc de l’architecture logicielle de contrôle, c'est-à-dire la manière dont est conçu et développé le logiciel chargé du contrôle du robot, dont nous allons discuter dans cet article.
Ces architectures logicielles se distinguent par le besoin de prendre en compte tout un spectre de fonctions allant de calculs délibératifs, très gourmands en temps et en espace, jusqu’au contrôle en temps réel de dispositifs physiques. Organiser ces « fonctions », les mettre en relation requiert un niveau d'expertise élevé. C'est pourquoi des solutions générales ont initialement été proposées sous la forme de « modèles architecturaux ». Les modèles architecturaux classiquement admis seront présentés, sachant qu’ils sont encore soumis à évolution pour intégrer la variété de schémas relationnels qui donnent une dimension unique à ces architectures. En effet, le robot immergé dans son environnement est aussi sujet à des relations homme-robot (autonomie décisionnelle partagée), robot-robot (flottille) ou encore robot-environnement actif (capteurs de l’habitat et routes intelligentes par exemple) qui, déclinées sur le plan des architectures de contrôle, nécessitent de considérer les relations dynamiques qui peuvent s’instaurer.
Si le modèle architectural guide dans la manière de structurer une architecture, il reste à définir comment la décrire et la mettre en œuvre. Avec la croissance de la complexité des architectures logicielles robotiques et l’explosion de la diversité toujours plus grande des applications et des missions, la conception et le développement d’architectures logicielles performantes et correctes devient un enjeu majeur. Il n’y a à ce jour aucune approche communément admise pour capitaliser et mutualiser les connaissances et les bonnes pratiques et pour réutiliser les briques logicielles développées. L’état des lieux que nous allons dresser témoigne de la diversité des propositions, révélant l’influence des cultures initiales des concepteurs, plus robotique, automatique ou informatique. Dans tous les cas, ces propositions visent, avec plus ou moins de succès, à définir comment décrire et encapsuler les diverses fonctions que le robot doit assurer sous la forme d'un ensemble d'entités logicielles en interaction. Ce faisant, l'objectif est de conférer à la solution des propriétés de modularité, de portabilité, de réutilisabilité, etc.
Décrire l’architecture logicielle n’est pas suffisant car il faut ensuite l'implémenter, la déployer et l’exécuter. Implémenter l’architecture logicielle et la déployer sur une cible d’exécution, tout en maîtrisant les contraintes logiques et temporelles de l’exécution typiques des systèmes réactifs, conduisent à considérer les contraintes provenant de la plate-forme (matérielle, système d'exploitation, langages de programmation) sous-jacente. Construire des architectures pérennes, réutilisables et adaptables pour une grande variété de plates-formes et de composants physiques (capteurs, actionneurs, mais aussi processeurs, réseaux, et autres matériels parfois spécifiques à la robotique) constitue un défi important. Nous évoquerons dès lors, à travers la présentation des approches récentes, les intergiciels (appelés « middleware ») pour les architectures de contrôle robotiques tant leur rôle peut être primordial à ces égards.
KEYWORDS
Robotics | Software architecture | Control | Control architecture | Component | Middleware
DOI (Digital Object Identifier)
Cet article fait partie de l’offre
Robotique
(59 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Présentation
1. Paradigmes de conception des architectures de contrôle
De façon simplifiée, un robot a pour objectif de remplir une mission pouvant être décomposée en une succession de tâches qu'il aura à exécuter au sein d'un environnement connu ou inconnu, statique ou dynamique.
Classiquement, un robot peut être décomposé en trois parties distinctes :
-
d'une part, un ensemble de capteurs extéroceptifs et proprioceptifs lui permettant de recueillir des informations sur son environnement et sur son état estimé, avec dans certains cas des capteurs portés par l’environnement lui-même ;
-
d'autre part, un ensemble d'actionneurs lui permettant d'agir ou d'interagir avec son environnement ;
-
enfin, entre ces deux extrémités de la chaîne de commande, une architecture de contrôle choisissant l'action (comportement) à mettre en œuvre, en fonction de l'objectif de la mission, de l'état courant du robot et de celui de son environnement.
C'est donc au sein de l'architecture de contrôle que sont concentrées les capacités décisionnelles du robot, potentiellement complétées par des interventions de l’opérateur dès lors que l’architecture de contrôle l’admet.
Trois fonctions fondamentales de la robotique peuvent alors être dégagées de ce cadre d'exécution :
-
« planifier » organise dans le temps les tâches que le robot aura à mettre en œuvre pour atteindre l'objectif de sa mission ;
-
« percevoir » traduit la capacité à recueillir le flux sensoriel provenant des capteurs et à en extraire ou à en reconstruire des informations sur l'état du système et de son environnement ;
-
« agir » détermine, à l'aide de lois de commande et autres traitements, les consignes à adresser aux actionneurs pour réaliser la tâche robotique à effectuer puis les applique.
C'est de la présence ou non de ces fonctions et de leur déclinaison au sein des architectures de contrôle, ainsi que de leurs modalités d'interaction dans le temps, que l'on peut dégager trois principaux paradigmes de conception.
1.1 Les architectures délibératives
C'est à la fin des années 1960 que le premier robot mobile réellement doté de capacités décisionnelles, et donc d'une architecture de contrôle, a été développé à l'université...
Cet article fait partie de l’offre
Robotique
(59 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive
Paradigmes de conception des architectures de contrôle
BIBLIOGRAPHIE
-
(1) - NILSON (N.J.) - A mobile automaton : An application of AI techniques - Proceedings of the First International Joint Conference on Artificial Intelligence (Morgan Kaufmann publishers, San Francisco 1969), pp. 509-520 (1969).
-
(2) - ALBUS (J.S.), LUMIA (R.), FIALA (J.), WAVERING (A.) - NASREM : the NASA/NBS standard reference model for telerobot control system architecture - Technical report, Robot Systems Division, National Institute of Standards and Technology (1987).
-
(3) - BROOKS (R.A.) - A robust layered control system for a mobile robot - Robotics and Automation, vol. RA-2, pp. 14-23 (Apr. 1986).
-
(4) - ROSENBLATT (J.K.) - DAMN : a distributed architecture for mobile navigation - Journal of Experimental and Theoretical Artificial Intelligence, 9(2/3), pp. 339-360 (1997).
-
(5) - ARKIN (R.C.), BALCH (T.) - AuRA : principles and practice in review - Journal of Experimental & Theoretical Artificial Intelligence 9 (2-3) : 175-189 (1997).
-
...
YARP :
The ROS Project :
The Orocos Project :
Open RTM-aist :
URBI :
GENOM :
http://homepages.laas.fr/mallet/orocos/genom.pdf
ORCCAD :
http://sed.inrialpes.fr/Orccad/
GenoM3 :
http://www.openrobots.org/wiki/GenoM3
BRICS :
http://www.best-of-robotics.org/
PROTEUS :
Open CCM :
JAUS :
EUROP :
http://www.robotics-platform.eu/
Le Robot Shakey :
https://www.sri.com/hoi/shakey-the-robot/
Vidéo du robot de Shakey :
http://www.sri.com/newsroom/video/shakey-experimentation-robot-learning-and-planning-1969...
Cet article fait partie de l’offre
Robotique
(59 articles en ce moment)
Cette offre vous donne accès à :
Une base complète d’articles
Actualisée et enrichie d’articles validés par nos comités scientifiques
Des services
Un ensemble d'outils exclusifs en complément des ressources
Un Parcours Pratique
Opérationnel et didactique, pour garantir l'acquisition des compétences transverses
Doc & Quiz
Des articles interactifs avec des quiz, pour une lecture constructive