Le modèle de domaine RobotML : méta-modèle

L’objectif principal de notre DSML consiste à permettre aux roboticiens de ma-nipuler les concepts dont ils ont l’habitude d’utiliser pour la définition de leurs applications. Nous avons distingué trois parties dans notre modèle de domaine : la partie architecture, la partie communication et la partie contrôle. Cette distinction découle des principales parties à définir pour une application de robotique.

La figure IV.18 montre une vue globale des principaux packages du modèle du do-maine RobotML :

Figure IV.18 – RobotML Domain Model

– Le package RoboticArchitecture regroupe les concepts architecturaux et structurels qui définissent une application de robotique. Ce package représente la partie Architecture.

– Le package RoboticBehavior permet de définir le comportement d’un com-posant d’une application de robotique à travers une machine à états finis ou des algorithmes. Ce package représente la partie Control.

– Le package RoboticCommunications définit la communication entre les com-posants à travers des ports et des connecteurs. Ce package représente la partie Communication.

– Le package Deployment permet de spécifier les propriétés relatives au déploie-ment des composants en représentant les plateformes cibles (middleware ou

simultaurs) vers lesquelles le code des composants sera généré.

4.1.1.1 La partie Architecture Cette partie représente les concepts qui per-mettent de définir l’architecture d’un scénario de robotique sous forme d’un mo-dèle à base de composants ayant des propriétés, des ports et des types. La partie Architecture comporte six packages comme le montre la figure IV.19 : le package RoboticSystem, le package SystemEnvironment, le package DataType, le package Ro-boticMission, le package Platform et le package Deployment que nous détaillerons dans ce qui suit.

Figure IV.19 – RoboticArchitecture Package

1. Le package Robotic System (voir Figure IV.21). La méta-classe System représente un composant ayant une activité (attribut activity) et qui peut être local ou non (attribut native). Cet attribut permet d’indiquer si un composant qui satisfait le même rôle existe déjà localement sur la machine. Les attributs

libraryPath et LibraryComponentName sont respectivement le chemin et le

nom de ce composant existant qu’on peut associer au composant représenté. Un System a une ou plusieurs propriétés (Property), un ou plusieurs ports (Port) et des connecteurs (Connector) qui permettent de relier les ports entre eux. La méta-classe Property est soit une propriété d’un système dans le sens attribut (méta-classe BasicProperty de la figure IV.20) soit une partie d’un système (méta-classe Part de la figure IV.20).

IV.4 Conception de RobotML

Figure IV.20 – La méta-classe Property

La méta-classe Port sera développée dans la partie Communication. Un System a un comportement exprimé à travers la méta-classe Evolution Model que nous détaillerons dans la partie Control. Un RoboticSystem est un System permettant de représenter un composant concret, il a une position et une orientation. La méta-classe SensorSystem représente les capteurs, l’attribut frequencyest la fréquence de chargement des données des capteurs. La méta-classe ActuatorSystem représente les effecteurs. Ces deux méta-méta-classes sont spécialisées dans d’autres types de capteurs et d’effecteurs spécifiques que nous ne présenterons pas car nous nous intéressons uniquement aux concepts du DSML et non aux détails spécifiques des capteurs et des effecteurs.

2. Le package SystemEnvironment. Ce package définit les concepts de l’en-vironnement où le robot évolue. Cette représentation permet de définir les environnements de simulation par exemple.

3. Le package DataType. Ce package permet de spécifier les types de données qui vont être utilisés par les ports, les propriétés, etc. (voir figureIV.22).

Figure IV.22 – RobotML Data Types Un data type peut être :

– une donnée physique Physical Data : Ce type représente une unité mathé-matique associée à un objet physique. Cet object mathémathé-matique peut être considéré comme une abstraction d’une donnée physique. On trouve par exemple les types Distance, Angle, Acceleration comme le montre la figure IV.23. La sémantique exacte de ces types est gérée ensuite par l’uti-lisateur. En effet, au niveau du DSML, ces types n’ont pas de sémantique opérationnelle. Par exemple, le type distance peut désigner une distance par rapport à un obstacle ou une distance de sécurité, etc.

IV.4 Conception de RobotML

– un type composé ComposedData. C’est un type qui représente des données communes à des objets du domaine de la robotique. Comme par exemple GPS, Image, etc. (voir figureIV.24).

Figure IV.24 – Types composés de RobotML

– un type primitif PrimitiveData comme par exemple le type bool, int, char, etc. (voir figure IV.25).

– une collection c.-à-d. listes, tables de hashage, séquences, etc.

– un timestamped data qui associe un horodateur à une donnée pour connaître son évolution au fil du de l’exécution (si elle reste valide, etc.).

Figure IV.25 – Types primitifs de RobotML

Étant donné que le middleware ROS a été intégré à la plupart des plateformes cibles de RobotML (OROCOS, RT-Maps, etc.), nous avons également défini une librairie basée sur les types ROS afin de faciliter leur utilisation par les

uti-lisateurs de RobotML. Ces types sont représentés comme des DataType comme le montre la figureIV.26 où les geometry_msgs de ROS sont représentés.

Figure IV.26 – Intégration des geometry_msgs de ROS à RobotML

4. Le package Robotic Mission. Ce package décrit les concepts qui sont re-quis pour la définition d’une mission opérationnelle et qui sont utilisés par les composants de l’architecture qui réalisent cette mission. Ce package est typiquement utilisé pour la représentation des scénarios.

5. Le package Platform (voir figure IV.27). Il définit les plateformes qui re-présentent l’environnement d’exécution. La méta-classe Platform peut être un

middleware (méta-classe RoboticMiddleware) ou un simulateur (RoboticSimulator). L’attribut RoboticMiddlewareKind est typpé par une énumération où les noms

des middleware pris en charge par le DSML sont spécifiés. Aucune propriété des middleware n’est représentée. Le choix d’un middleware servira unique-ment au déploieunique-ment. De même pour la méta-classe RoboticSimulator qui est spécialisée en trois méta-classes où il y a seulement besoin de spécifier la configuration souhaitée de l’exécution (temps-réel ou non, valeur de la gravité, etc.) selon le simulateur choisi.

6. Le package Deployment permet l’allocation d’un composant (méta-classe