Middlewares robotiques

Les Middlewares permettent de simplifier le développement d’applications logicielles en créant une couche d’abstraction entre le système d’exploitation et les applications. Dans le do- maine robotique, les Middlewares fournissent des services permettant de simplifier la concep- tion d’architectures logicielles. En effet, l’abstraction réalisée offre de nombreux avantages dans le développement d’architectures de contrôle ([PACGD14]) :

– portabilité/homogénéité : en travaillant à un niveau d’abstraction plus élevé, ils four- nissent un modèle de programmation indépendant des spécificités du système d’exploi- tation utilisé. Les aspects conceptuels et les mécanismes à disposition du développeur sont donc identiques pour tous les systèmes supportés par le Middleware.

– efficacité : les services offerts par le Middleware prennent en charge de nombreux aspects bas-niveau qui sont dès lors transparents pour les utilisateurs qui ne sont généralement

pas familiers avec les aspects système, notamment temps-réel. Bénéficiant qui plus est de l’homogénéité précédemment évoquée, le développement d’applications, leur évolution ou leur portage sur une autre cible technologique s’en trouvent simplifiés et leur temps de développement réduit.

– fiabilité : les Middlewares (temps-réel) sont développés et testés par des spécialistes de la programmation système, temps-réel ou encore de la gestion des réseaux. Le bon fonctionnement est donc assuré pour les utilisateurs non-spécialistes. En outre, pour les Middlewares les plus communément utilisés, une communauté importante assure généralement leur maintenance sur le long terme et une détection rapide de tout problème pouvant apparaître.

Dans nos travaux, nous utiliserons le Middleware temps-réel ContrACT développé au LIRMM. Les grands principes de son fonctionnement seront présentés au chapitre 7.

Parmi les Middlewares robotiques les plus utilisés, nous pouvons citer ROS [QGC+_09].

Développé initialement par la société Willow Garage, il est structuré autour de l’exécution de processus fonctionnant de manière indépendante, potentiellement sur des hôtes différents (au sens de nœuds différents d’un réseau), et communiquant ensemble via une topologie peer-to- peer. Chaque processus calculatoire est appelé un node. Ceux-ci communiquent entre eux en échangeant des messages. Ces derniers sont constitués de structures aggrégant des types de données "primitifs" offerts par ROS. Il est également possible d’échanger des tableaux de don- nées mais aussi de définir un message comme un tableau de messages ou encore en composant plusieurs types de messages offrant ainsi un cadre très souple pour définir les données échan- gées. La communication en elle-même est réalisée suivant un mécanisme publish/subscribe et organisée autour du concept de topics. Il s’agit d’un "bus" identifié de manière unique chargé de réceptionner les messages des nodes qui publient sur ce topic et de transmettre les infor- mations à ceux qui y ont souscrit. Les messages échangés sur un topic donné doivent avoir une structure clairement établie lors de sa définition. Si ce mécanisme permet une grande souplesse et un découplage entre publication et souscription, il n’est pas adapté aux communi- cations synchrones où un accusé de réception est nécessaire. Ce type d’échange est également implémentable sous ROS en utilisant les services qui sont définis par trois informations, un identifiant unique, le type de message utilisé pour la requête et le type de message utilisé pour y répondre.

2.4. Conception modulaire de logiciel de contrôle en robotique

La structure d’un logiciel conçu avec ROS peut être représentée comme un graphe dont les nœuds sont les nodes et les arcs représentent les liaisons effectuées entre eux via les topics et services. Un tel graphe est, par exemple, représenté Figure 2.14. Celui-ci est affiché à l’aide de l’utilitaire rxgraph qui permet de le visualiser et d’afficher toutes les informations relatives aux connexions possibles avec un node donné.

Figure 2.14 – Un graphe représentant la structure d’un logiciel de contrôle basé sur ROS (figure tirée de [MF13, page 98])

ROS intègre également une problématique importante, la gestion des repères dans lesquels sont représentées les différentes données. En effet, toute information qui a pour grandeur une position, une distance ou une grandeur dérivée (vitesse, accélération) est fondamentalement exprimée par rapport à un repère précis (le repère monde, le repère spécifique à un robot ou encore le repère spécifique à un actionneur). Pour résoudre ce problème, ROS propose la librai- rie tf [Foo13] chargée d’assurer le suivi des différents repères définis dans l’application et des relations de transformation (potentiellement dynamiques) entre eux. S’inspirant du principe des graphes de scène utilisés dans la visualisation 3D, elle représente les différents repères sous la forme d’un arbre (préféré à un graphe pour des raisons d’efficacité dans son parcours) dont chaque nœud correspond à un repère et les arcs représentent les transformations à effectuer pour passer de l’un à l’autre. En outre, afin de gérer les problématiques inhérentes aux archi- tectures distribuées (délais, perte d’information), l’évolution des différentes transformations est historisée et associée à une date de validité. Ainsi quand une donnée est soumise pour un changement de repère, celle-ci est datée afin de permettre de déterminer la transforma- tion adéquate à appliquer. Implémentée dans des nodes de ROS, cette librairie est facilement

associable au reste de l’architecture.

La décomposition du logiciel de contrôle en différents nodes permet une conception modu- laire et une grande évolutivité. En effet, il est possible de voir les nodes comme des "modules" encapsulant un code interne et communiquant vers d’autres "modules" via une interface qui est représentée ici par les messages et les topics. La structure du système de fichiers de ROS permet également de facilement échanger des solutions logicielles entre utilisateurs. Malgré tout, même s’il facilite l’intégration de contributions diverses, l’une des principales limitations de ROS est son absence de gestion des aspects temps-réel qui sont délégués au développeur dans la conception du code interne à chaque node. De fait, tous les aspects temporels liés à l’implémentation d’une loi de commande sont laissés à la responsabilité du concepteur.

Un autre Middleware ayant connu un large succès dans la communauté robotique est Orocos (Open Robot Control Software). Il s’agit d’un Middleware temps-réel visant à favoriser le découplage entre les différents composants logiciels du système afin de favoriser la modularité et la réutilisabilité [BSK03]. Orocos est organisé autour de trois éléments :

– RealTime Toolkit (RTT) : un ensemble de librairies fournissant une abstraction du sys- tème d’exploitation permettant d’implémenter les différents composants du Middleware. Elle sert ainsi à compiler et exécuter l’application conçue par l’utilisateur comme montré Figure 2.15.

– Orocos Component Library (OCL) : Un ensemble de composants d’infrastructure basés sur RTT et nécessaires pour faire fonctionner l’application. Elle contient ainsi les com- posants permettant de paramétrer et debugger l’application, de logger les données ou encore d’assurer le bon fonctionnement des connexions entre composants.

– Une Toolchain permettant aux utilisateurs de développer leurs propres composants en utilisant RTT et ayant notamment la capacité de générer des squelettes de code à com- pléter par le code spécifique à l’utilisateur.

Un composant Orocos est appelé un TaskContext du nom de la classe définissant la struc- ture de base commune à tous les composants. L’utilisateur va pouvoir définir ses propres composants en héritant de la classe TaskContext. Celle-ci est présentée Figure 2.16.

Le comportement interne d’un TaskContext est régi par une machine à états dont les transitions d’états correspondent aux fonctions qui seront exécutées. Durant la création du composant, celui-ci se trouve dans l’état Init. L’utilisateur peut alors choisir soit de mettre un module en état PreOperational rendant obligatoire sa configuration (fonction configure()) ou alors de démarrer directement le module dans l’état Stopped qui signifie que le module est prêt à être démarré. Dans le second cas, la configuration est optionnelle mais reste toujours

2.4. Conception modulaire de logiciel de contrôle en robotique

Figure 2.15 – La suite d’outils mis en œuvre dans le Middleware Orocos (figure tirée de [Soe12, Figure 1.1])

possible dès lors que le module est arrêté. Enfin, lorsque le module est démarré (via la fonction start()) il se retrouve dans l’état Running qui permet d’appeler de manière périodique ou évènementielle (suivant la configuration du module) la fonction update(). Enfin, il est possible de stopper l’exécution d’un module (fonction stop()) voire d’annuler sa configuration (fonction cleanup()). Chacune de ces fonctions fournit un point d’interface aux utilisateurs afin qu’ils puissent implémenter le code spécifique à chaque composant. Les TaskContexts sont connectés ensemble via leurs ports d’entrée/sortie. Les échanges sont réalisés suivant un flux de données. Il est à noter qu’Orocos permet l’échange d’objets et que l’exécution d’un module (appel à la fonction update()) peut être déclenchée sur réception d’une donnée d’un port.

Un ensemble de propriétés permet également de configurer le composant. Enfin, chaque composant peut fournir un ensemble de services appelés Operations qui peuvent être appelées soit par l’opérateur soit par un autre TaskContext. Cet appel se fait via des objets spéciaux, les OperationCallers. Ces Operations peuvent être soit des actions associées à des méthodes appartenant au composant (pour contrôler son exécution ou obtenir/modifier la valeur d’un paramètre) soit des appels à des fonctions externes.

La structuration en composants proposée par Orocos permet donc une grande modularité dans l’application tout en assurant un support de l’exécution temps-réel. De plus, Orocos n’est pas rattaché à une structuration architecturale particulière et l’échange d’objets laisse aux utilisateurs une grande liberté dans la spécification de l’interface entre composants. Cela nécessite néanmoins de mettre en place une couche d’abstraction supplémentaire qui aurait pour rôle de définir la structure de l’application et la spécification des interfaces entre Task- Contexts afin d’assurer la cohérence de l’application.

Figure2.16 – Structure d’un composant Orocos

Enfin, nous pouvons également citer le Middleware MOOS-IvP [BSNL13]. Cette approche vise principalement à faciliter le développement d’architectures de contrôle pour les véhicules sous-marins dans le contexte d’une architecture calculatoire distribuée. L’élément central de l’approche MOOS est une base de données, la MOOSDB, qui permet aux différents processus formant une "communauté" MOOS de communiquer ensemble. Une telle "communauté" est illustrée Figure 2.17.

Les différentes applications MOOS communiquent avec la base de données via un mé- canisme de publication/souscription. Ainsi, l’interface d’une application est définie comme l’ensemble des messages publiés et l’ensemble des messages auxquels l’application souscrit. Cette approche permet une grande modularité dans la conception et une grande évolutivité puisque chaque application peut être modifiée sans affecter le reste du logiciel de contrôle tant qu’elle conserve la même interface. Grâce à la base de données qui assure un découplage entre les différentes applications, celles-ci peuvent s’exécuter indépendamment et, par exemple, n’ont pas à fonctionner à la même période (l’accès partagé à la base de données partagée restant un point critique comme dans tout approche basée sur un tableau noir).

Une application MOOS notable est le système de prise de décision IvP Helm. En fonc- tion des informations fournies par la base de données MOOS (par exemple des informations

2.4. Conception modulaire de logiciel de contrôle en robotique

Figure 2.17 – Une "communauté" MOOS organisée autour d’une base de données (figure tirée de [BSNL13, Figure 2.3])

venant des capteurs ou de l’exécution d’autres applications), celle-ci va arbitrer les calculs effectués par un certain nombre de comportements (suivre un ensemble de points de passage, éviter des collisions) et transmettre différentes consignes que devront appliquer les autres ap- plications (par exemple cap ou vitesse d’avance désirés) [BSNL13]. La Figure 2.18 illustre le fonctionnement d’IvP.

Figure 2.18 – Le fonctionnement du système décisionnel IvP (figure tirée de [BSNL13, Fi- gure 2.7])

En fonction des objectifs de mission, les comportements adéquats sont choisis puis leurs sorties sont arbitrées en utilisant les principes de la programmation par intervalles afin de déterminer les consignes à appliquer [Ben04].

Ainsi, le Middleware MOOS-IvP permet une grande souplesse dans la conception du logiciel de contrôle d’un robot sous-marin. La décomposition en applications indépendantes permet une grande modularité à la fois dans la définition des différentes applications et au sein même

des applications comme l’a illustré l’exemple de l’application IvP. Néanmoins, cela impose de définir une couche d’abstraction supplémentaire permettant de déterminer la structure de chaque application MOOS et la manière dont celles-ci interagissent ensemble.