Le présent article présente Microsoft Robotics Developer Studio, l’environnement de développement dédié à la robotique créé par Microsoft. L’objectif de cet article est de positionner Microsoft Robotics Developer Studio dans l’écosystème du développement de programmes dédiés à la robotique.

Un peu d’histoire

En juin 2006, lors de la RoboBusiness Conference and Exposition 2006, Microsoft annonce la disponibilité de Microsoft Robotics Studio  (MSRS), une plate-forme de développement standardisée pour la Robotique. Cette annonce représente la concrétisation d’un nouvel effort de Microsoft, initié par Bill Gates lui-même, dans un article du magazine Scientific American de Décembre 2006, intitulé « A Robot in Every Home[1] ». Dans cet article, Bill Gates remarque que l’industrie de la robotique se trouve dans l’exacte situation de l’industrie du PC il y a 30 ans de cela, à savoir un manque de standardisation au niveau OS, hardware ou langage de programmation. Les sociétés impliquées dans la robotique sont demandeuses de l’équivalent d’un système d’exploitation permettant de faire tourner un même code sur plusieurs plateformes matérielles différentes. En effet, chaque vendeur de robots programmable propose son propre environnement de programmation et son propre langage.

En terme stratégique, Bill Gates estime que la robotique constitue un champ privilégié de l’évolution des technologies et que chaque foyer interagira avec des éléments robotiques au quotidien. « Je pense que des technologies telles que le calcul distribué, la reconnaissance vocale et visuelle ou la connexion sans fil à haut débit ouvrent la porte à une nouvelle génération de périphériques autonomes qui permettront aux ordinateurs de réaliser des tâches dans le monde physique pour notre compte. Nous sommes à l’aube d’une nouvelle ère où le PC s’éloignera du bureau pour nous permettre de voir, toucher, entendre et manipuler des objets dans des endroits où ne sommes pas physiquement présents ».

Bill Gates étaye sa réflexion en précisant que le coût du hardware diminue et permet de penser que la robotique ne peut que démocratiser. Ce constat étant fait, un groupe de travail est constitué en 2004, dirigé par Tandy Trower (photo), architecte en chef du groupe Microsoft Robotics.  Le résultat de cet effort est la mise à disposition de Microsoft Robotics Studio  fin 2006. Cet outil vise une population assez large depuis les industriels, en passant par les chercheurs et enseignants et enfin les passionnés, ceux que Microsoft nomme les hobbyists.

Qu’est ce que Microsoft Robotics Studio ?

Les principes qui ont mené l’architecture proposée

Une plate-forme unique et standardisée

L’idée principale est de proposer un environnement de programmation intégré qui permette de développer, tester, débugger des applications robotiques, sans avoir à faire d’hypothèse sur le hardware sous-jacent. La portabilité du code est l’un des objectifs majeurs.

Microsoft choisit de s’appuyer sur le framework .NET véritable pierre angulaire de la programmation chez Microsoft.

Une gestion simple des problématiques spécifiques à la robotique

L’un des principaux problèmes auxquels ont à faire face les développeurs d’application robotiques est la complexité des applications en raison de la nature fortement parallèle d’un développement en robotique. Qu’est ce qu’un robot ? Pour simplifier, un robot est composé de 3 parties :

• Une série de capteurs permettant au robot de percevoir son environnement
• Un centre de calcul (un processeur)
• Des « effecteurs» (généralement des moteurs) permettant au robot d’agir sur l’environnement selon les ordres donnés par le centre de calcul.

Le problème est que les capteurs fournissent des informations au centre de calcul en continu et en parallèle, le centre de calcul devant les intégrer en temps réel et demander aux actuateurs d’agir. Il n’est en effet pas possible de stopper le fonctionnement du robot le temps que tous les capteurs fournissent des informations. De même, que se passe-t-il si l’un des capteurs met du temps à réagir ?

La réponse est connue depuis longtemps par les roboticiens. Les développements sont massivement parallèles, impliquant donc une gestion fine du multithreading. Cette gestion peut rapidement devenir difficile voire consommer la plus grande partie du temps de développement, au détriment du programme spécifique du robot.

Microsoft a choisi d’abstraire toute cette partie en proposant un modèle intégré de gestion du multithreading. L’une des briques de Microsoft Robotics Studio  (voir plus loin), est le CCR (Concurrency and coordination runtime). Il s’agit d’une librairie de code C# .Net 2.0, développé par George Chrysanthakopoulos dans le cadre d’un groupe chez Microsoft nommé Advanced Strategies. CCR n’avait donc rien à voir au départ avec Microsoft Robotics Studio  mais a été intégré au SDK car répondant parfaitement aux besoins du développement robotique. Cette librairie permet en effet, comme son nom l’indique, de coordonner et s’assurer la gestion de la concurrence (le multithreading) de services, de manière simple et sûre.

Les briques technologiques

Microsoft Robotics Studio  est un Software Development Kit (SDK) qui consiste en trois briques technologiques essentielles :

1. Un runtime permettant de faire tourner les programmes .NET réalisés pour n’importe quel type de robots. C’est le CCR et le DSS.
2. Un ensemble d’outils de développements et de debbuging. Il est possible d’utiliser soit Visual Studio pour le développement basé sur .NET, soit un nouvel outil de développement visuel nommé Visual Programming Language.
3. Un outil de simulation, permettant de tester les programmes réalisés dans un environnement virtuel tridimensionnel simulant les conditions physiques (gravité, frictions, forces,…).

Microsoft fournit un large ensemble de tutoriels et exemples de codes afin de permettre à tout un chacun de s’approprier l’outil.

Nous allons développer dans la suite de ce document chacun des outils proposés dans ce SDK. Faisons tout d’abord un point sur les différentes versions de Microsoft Robotics Studio  proposé par Microsoft.

Les pré-requis

Microsoft Robotics Studio  étant un SDK, il nécessite un ensemble d’outils pour fonctionner. Heureusement, certains de ces outils existent en version gratuite :

• NET Framework 2.0
• Visual 2008 (la version Express de cet outil est gratuite).

Microsoft Robotics Studio  est compatible 64 bits.

Le mode de licencing

Depuis la version Microsoft Robotics Studio 2008 R3, MSRS est gratuit (rendez-vous sur http://www.microsoft.com/robotics

Les différentes releases

La version active fin 2008 de Microsoft Robotics Studio  est la troisière version, renommée Microsoft Robotics Developer Studio 2008. Deux versions précédentes ont été livrées avant.

Tableau 1: Historique des versions de MSRS

La version 1.5 apporte également (sous la forme d’un téléchargement séparé), un ensemble supplémentaire de tutoriaux et codes nommé « Introductory Courseware for Microsoft Robotics Studio (1.5) » qui restent utiles dans la version 2008.

CCR

Description

Le CCR (concurrency and coordination runtime), est une library managée (.DLL) accessible depuis n’importe quel langage .NET qui permet d’abstraire les difficultés inhérentes à la programmation multithread en robotique.

Le CCR est une librairie qui permet de répondre aux besoins suivants :

• Asynchronisme : le fait que différentes parties du programme puissent fonctionner indépendamment et en parallèle, sans que l’une des partie puisse bloquer l’ensemble en cas de problème

• Concurrence : si le programme est organisé en plusieurs sous parties indépendantes, il faut gérer le fait que plusieurs parties souhaitent accéder à une même ressource en même temps.

• Coordination et gestion des erreurs : coordonner les différentes parties du programme entre elles et gérer les éventuelles erreurs qui peuvent survenir.

En fournissant des méthodes de haut niveau, la complexité de développement est très fortement réduite et l’application est rendue plus robuste.

Modèle de programmation

Les principaux concepts de programmation du CCR sont définit par certains objets clés que nous allons présenter ici.

Les ports

Les ports sont des listes FIFO (First In First Out) qui peuvent contenir n’importe quel objet .Net. Comme nous le verrons plus tard, les Ports du CCR sont utilisés par DSS pour faire communiquer les services entre eux. Le CCR définit également des ensembles de Port que l’on nomme PortSets.

Les arbiters

Ce sont les classes dans lequel vont s’exécuter le code utilisateur.

Les tasks

Les tasks sont les objets générés lorsque des messages arrivent sur un port.

Les dispatchers et les dispatchersQueues

Ces objets permettent de gérer la planification et le loadbalancing des tâches.

Le DSS décrit dans le paragraphe suivant s’appuie sur le CRR.

DSS

Un modèle à base de services

DSS est un environnement d'exécution (un runtime) qui s'appuie sur le CCR et qui permet d'exécuter les services que l'on a réalisé à l'aide de Microsoft Robotics Studio. DSS expose de manière standardisée des services qui peuvent être utilisés (on dit consommés) par un autre programme, un autre service ou une interface utilisateur. Dans le cadre de ce modèle, un service peut représenter :

• un composant matériel (hardware) comme un capteur ou un actuateur.
• un composant logiciel de l'interface utilisateur (comme une fenêtre de commande), un répertoire, un élément de stockage...
• une agrégation d'éléments précédents.

L'intérêt de représenter les différentes parties d'un robot sous forme de service est multiple :

• ROBUSTESSE : chaque service s'exécute indépendamment, ce qui permet de proposer une architecture faiblement couplée. Ainsi, si le service gérant le bras d'un robot tombe en panne le reste du robot peut continuer à fonctionner. Les services sont isolés du point de vue de l'exécution mais également du point de vue des données.

• COMPOSABILITE : les services sont standardisés, ce qui fait que leur utilisation, la manière de dialoguer avec eux ou de requêter leur état sont standardisés. Cela simplifie grandement le développement du code car le développeur n'a pas à réinventer la roue sur ces différentes opérations. Par ailleurs, les services ainsi réalisés sont portables d'un nœud DSS à un autre.

• OBSERVABILITÉ : DSS permet d'observer l'état des services permettant ainsi de déterminer l'état du système dans son ensemble. On parle d'observabilité. Pour cela, DSS attribut une URI à chaque service et expose l'état de ces services. Par ailleurs, chaque service est accessible via un navigateur augmentant ainsi la capacité de monitoring du système.

Les services sont exécutés dans le contexte d'un nœud DSS qui se comporte comme l'environnement de support des services. Les services peuvent dialoguer entre eux d'une manière standardisée, qu'ils s'exécutent au sein du même nœud DSS ou bien qu'ils soient distants et utilisent le réseau pour dialoguer. Deux protocoles permettent d'accéder aux services. Il s'agit d'une part de HTTP (il est possible de visualiser l'état d'un service dans un navigateur) et également DSSP (Decentralized Software Services Protocol), un protocole proche de SOAP, le protocole utilisé pour interagir avec les web services.

Qu’est ce qu’un service ?

- DSS permet de gérer toutes les parties d'un robot et des logiciels liés à celui-ci sous forme de services. DSS s'appuie sur le CCR pour la gestion du parallélisme.

Un service est un modèle de programmation faisant intervenir les éléments suivants :

• Un contrat
• Un identifiant
• Un état
• Des ports pour la communication
• Des services handlers pour gérer les messages entrant et sortant
• Des notifications
• Des services partenaires

La figure suivante représente un service de manière schématique :

Pour créer un service, il suffit de créer un projet avec Visual Studio et le compiler ou bien de créer un projet à l’aide de Visual Programming Language ou bien encore d’utiliser l’utilitaire de commande DSS New Service Generation Tool (DSSNewService.exe).

Le contrat

Chaque service expose un contrat qui décrit son comportement. C’est en quelque sorte sa carte d’identité et son manuel d’utilisation. Le contrat permet ainsi à d’autres servies d’établir de manière automatique une relation avec le service. Le contrat d’un service peut être inspecté à l’aide de l’outil DDS Contrat Information Tool (DssInfo.exe). Le contrat est accessible via une URI nommée contract identifier. Cet identifiant est automatiquement créé lors de la création du service.

L’identifiant de service

Lorsqu’un service démarre sur un nœud, il lui est dynamiquement attribué un identificateur. Cet identificateur est une URI et permet d’identifier de manière sûre une instance d’un service (et non pas le service), sachant que plusieurs instances d’un même service peuvent être démarrées.

L’identificateur est utilisé par les autres services ou programmes (tel un navigateur web) pour identifier le service. Il ne fournit aucune information sur l’état du service, son objectif ou sa manière de fonctionner (c’est le rôle du contrat). Ce n’est donc pas une bonne pratique de se baser sur l’identificateur pour deviner ce qu’est le service.

L’état du service

C’est une notion très importante. L’état est une représentation du service à un instant t. Une manière de se le représenter est d’imaginer un document représentant le contenu du service à un moment donné. La notion d’observabilité décrite plus haut se base largement sur l’état des services.

Toute information sur un service qui peut être obtenue, modifiée ou monitorée doit être décrite comme faisant partie de l’état du service.

Par exemple, pour un service représentant un moteur, l’état peut contenir :

• Le nombre de tours par minutes
• La pression hydraulique
• La température
• La résistance
• …

Les services partenaires

Etant donné que les services doivent collaborer ensembles pour réaliser l’objectif de l’application globale et que lorsqu’un service démarre, il ne sait pas a priori où se trouvent les services avec lesquels il doit interagir et s’ils sont démarrés.

Pour répondre à ce problème, DSS introduit la notion de services partenaires. Les services partenaires sont la liste des services avec lequel le service courant dépend ou interagit.

Plusieurs types de partenariat sont disponibles :

-Le service peut déclarer qu’un service partenaire est obligatoire (dans ce cas, si le partenaire n’est pas trouvé, le service courant ne démarre pas)

-Le service peut déclarer un service partenaire comme optionnel. Dans ce cas, si le partenaire n’est pas trouvé ou ne démarre pas, le service principal peut tout de même continuer sa création.

Le port principal

Le port principal (ou port opération) est un port CCR où les messages s’échangent avec les autres services. En effet, les services ne dialoguent pas directement, ils ne le font que par l’intermédiaire de messages qu’ils s’échangent au travers de leur port principal.

Le port principal est un attribut privé de la classe du service et il est identifié par l’attribut ServicePort comme le montre l’exemple ci-dessous.

[ServicePort("/monExemple")]

private MesOperationExemples _mainPort = new MesOperationExemples();

Les messages acceptés sur le port principal sont définis par le type de port (ici la classe MesOperationsExemples). La liste des opérations possibles sur un port est déclarée dans le constructeur du port. Il s’agit d’opérations DSSP (Decentralized Software Service Protocol) ou bien d’opérations HTTP. Un exemple de constructeur de port est présenté ci-dessous :

public class MesOperationExemples : PortSet<DsspDefaultLookup, DsspDefaultDrop,
 Get,Replace, HttpGet, HttpPost>{}

Le port créé à l’aide du constructeur ci-dessus définit 6 opérations possibles. Les messages arrivant sur le port doivent donc déclencher l’une de ces 6 méthodes.

Les services handlers

Pour chacune des méthodes acceptées sur le port principal, un service handler (un gestionnaire littéralement) doit être défini (sauf pour les deux opérations que sont DsspDefaultLookup et DsspDefaultDrop pour lesquels DSS définit des handlers par défaut). Il s’agit d’une méthode qui indique ce qui doit être fait lorsqu’un message reçu sur le port principal déclenche la méthode DSSP.

Le service handler peut réaliser tout type d’opération propre à changer l’état du service par exemple. Il peut également envoyer un message à un autre service. Il utilise pour cela un service forwarder qui est un port CCR local qui représente en fait le port principal du service auquel le service handler souhaite envoyer un message. Nous voyons ici que le service handler ne s’adresse pas directement au port distant mais à un port local qui lui communique avec le port distant. Cela rappelle fortement le fonctionnement des systèmes de messages asynchrones comme MSMQ ou MQSeries pour ceux qui connaissent.

La notification d’événement

Un service peut également être alerté si l’état d’un autre service est modifié. N appelle cela la notification d’événement. Lorsque le service A a souscrit à la notification d’événement du service B, le service B génère et envoi un message sur le port principal du service A.

Visual programming language

Le Visual Programming Language (VPL) est une autre brique livrée avec Microsoft Robotics Studio. Il s’agit d’un environnement de programmation visuel générant le code .Net. Visual Programming Language s’appuie donc sur DSS et le CCR. Le code .Net généré peut être ouvert et modifié avec Visual Studio (l’environnement de développement professionnel de Microsoft), de même un programme réalisé par code à l’aide de Visual Studio est chargeable dans VPL.

La figure suivante présente une capture d’écran de cet outil.

Dans cet outil, les éléments visuels déplacés par glisser/déposer sont des services. Le panneau de gauche liste les services présents sur la machine. VPL est livré avec un grand nombre de service directement intégrables.

Cet environnement est facile d’utilisation et permet en quelques minutes de bâtir un programme pour son robot.

L’intérêt de cet environnement par rapport à NXT-G, l’environnement de développement fourni avec Lego Mindstorms NXT (qui est lui aussi graphique et fonctionne de la même manière par glisser/déposer), c’est que le VPL fonctionne avec virtuellement toute plate-forme robotique et non pas seulement avec Lego Mindstorms NXT. D’ailleurs des services spécifiques pour Lego Mindstorms NXT sont fournis avec le VPL.

Le VPL permet de faire tourner le code généré mais également de le debugger. Le VPL permet de transférer un code vers le robot mais également de visualiser le fonctionnement de ce code sur un robot virtuel évoluant dans l’environnement de simulation visuel comme nous allons le voir dans la rubrique suivante.

Visual Simulation Environment

La dernière brique livrée avec Microsoft Robotics Studio  est le Visual Simulation Environment (VSE) qui permet de tester les codes que vous avez développés dans un environnement virtuel en 3 dimensions. L’intérêt d’un tel outil est évident lorsque vous pensez qu’un mauvais programme peut endommager un robot ou son environnement.

Le moteur de rendu de l’environnement est basé sur Microsoft XNA Framework qui est le framework de Microsoft pour développer des jeux pour les consoles de Jeux Xbox. Afin que la simulation soit réaliste et apporte ainsi une valeur ajoutée, VSE intègre la technologie AGEIA^TM PhysX^TM qui est un moteur de rendu physique. Un tel moteur ajoute les lois physique de notre monde dans le monde virtuel (le fait que le haut et le bas aient des significations, le choc, la gravitation, les frictions…).

Les captures d’écran ci-dessous présentent des simulations réalisées à l’aide de Visual Simulation Environment :

Pour tester un code réalisé à l’aide de VPL sur robot dans VSE, il suffit d’utiliser des manifests (les manifests sont des fichiers XML de paramétrage) permettant de spécifier que l’on souhaite utiliser VSE. De tels manifests sont fournis en standard dans VPL pour certains robots comme Lego Mindstorms NXT.

Comment utiliser Microsoft Robotics Studio avec un robot personnel ?

Nous verrons ici un exemple simple permettant de simuler le pilotage d’un robot Lego Mindstorms dans l’environnement Visual Simulation Environment. Le code sera généré à partir de Visual Programming Language.

Création du diagramme VPL

Generic Differential Drive

Démarrez l’outil Visual Programming Language depuis le menu démarrer de votre PC. Dans l’onglet service à gauche, sélectionnez le service Generic Differential Drive et glisser le sur le diagramme de travail (il s’agit de la partie centrale de l’écran VPL). Lorsque la boite correspondant au Generic Differential Drive est sélectionnée, dans la colonne des propriétés, à droite, il existe une liste déroulante nommée Configuration. Sélectionnez « Use a manifest ». Ceci indique que pour ce service Generic Differential Drive, dont l’objectif est de piloter un robot ayant deux moteurs et deux roues (un sur chaque roue), nous allons utiliser un fichier XML de paramétrage (un manifest) existant.

Cliquez sur le bouton Import qui est apparu. La fenêtre suivante est lancée :

Cette fenêtre liste tous les manifests trouvés sur votre PC. Il s’agit de fichier XML que vous avez réalisé ou bien installé avec MSRS. Le manifest indique la liste des services qui devront être démarrés.

Choisissez LEGO.NXT.Tribot.Simulation.Manifest.xml. Ce manifest indique à MSRS que le robot qui sera lancé sera le tribot de Lego et que celui-ci sera lancé dans l’environnement de simulation. Notez que si nous avions choisi LEGO.NXT.Tribot.xml, cela aurait indiqué que le robot est un robot réel. Comme vous le voyez, passer de l’environnement de simulation à l’environnement réel est aussi simple que cela, il suffit de changer de manifest !

Simple Dashboard

Dans la liste des services, dans le menu de gauche, trouvez le service Simple Dashboard et glissez-le sur le diagramme.

Génération du projet

Sauvegardez votre travail et cliquez ensuite sur le bouton Start en forme de flèche verte. Cela lance tout d’abord la fenêtre RUN qui vous montre les étapes techniques de votre programme.

Ensuite, deux fenêtres sont lancées :

• Microsoft Visual Simulation Environment (puisque spécifié dans le manifest)
• Le dashboard.

Afin de piloter le robot Tribot à l’aide du Dashboard, il faut indiquer au Dashboard où trouver le robot. Pour cela, dans la champ Machine, saisissez l’adresse IP locale de votre machine (127.0.0.1) puis cliquez le bouton Connect. Vous devez voir le Dashboard tel que présenté dans la figure suivante :

Dans la zone de texte au milieu à droite, le DashBoard a découvert le Tribot. Double-cliquez dessus, puis cliquez sur le bouton Drive qui se trouve à gauche.

Vous y voila, à l’aide de la boule de direction en haut à gauche, pilotez le Tribot dans l’environnement de simulation. Constatez le respect des règles physique dans l’environnement de simulation en fonçant sur le plot par exemple.

Par cet exemple simple, nous avons illustré le fait que créer un programme robotique est rapide et simple à l’aide de VPL et nous avons illustré également la capacité de MSRS à créer des programmes pour différentes plateformes hardware.

Conclusion

En guise de conclusion, il vous est conseillé de pratiquer MSRS au travers des nombreux tutoriels inclus dans l’aide de MSRS mais également à l’aide des Webcast (vidéos en ligne) proposées par Microsoft.

Nous sommes convaincus que si Microsoft poursuit son effort, la communauté des développeurs robotiques disposera d’un environnement générique professionnel propre à assurer l’évolution durable de la robotique personnelle.

Génération Robots (http://www.generationrobots.com)

–

Tout usage et reproduction soumis à autorisation explicite préalable.