Club robotique de Sophia-Antipolis

Accueil > Projets et études > Etudes techniques > ROS > Le pourquoi du comment

Le pourquoi du comment

jeudi 13 novembre 2014, par Eric P.

 Introduction

ROS est bien connu dans le monde de la recherche en robotique et est largement utilisé pour contrôler des robots extrêmement sophistiqués. Son point de départ se situe au milieu des années 2000, dans les travaux de l’équipe robotique de Stanford University.

Un de ses atouts est d’offrir une souplesse maximale nécessaire dans le cadre d’activités de recherche, grâce à son architecture à base de composants fortement découplés, s’appuyant sur sur un mécanisme de communication inter-process multi modal :

  • synchrone : remote procedure call (RPC)
  • asynchrone : bus de message avec publication/souscription

Ces mécanismes de communication permettent de construire une application par assemblage de composants écrits dans des langages différents, et en totale transparence. A ce jour plusieurs bindings existent, C/C++ et Python étant supportés officiellement par les mainteneurs de ROS, Java, Lisp et d’autres s’y ajoutant grâce aux contributions d’une communauté très active.

Ce point n’est pas le seul atout de ROS, et le mieux pour en avoir une vue plus détaillée est de visiter le site officiel d’une part, et également le Wiki qui en constitue la documentation vivante.

 Nono 2.0

Un des multiples projets du club est de redonner une deuxième vie à un robot jouet Emiglio [1], sous la forme d’un interlocuteur interactif destiné à animer notre stand lors des diverses manifestations publiques auxquelles nous participons. Pour l’occasion, nous l’avions re-baptisé Nono.

JPEG - 37.2 ko
Emiglio/Nono

Outre cette ambition, nous souhaitons pouvoir mener ce projet sous forme de sous-projets pouvant avancer de manière individuelle, au gré de l’inspiration (et surtout des disponibilités) des membres impliqués. De plus, n’étant jamais à cours d’imagination, la solution technique résultante doit présenter une structure à géométrie variable, assemblée à partir des constituants disponibles à la manière de briques de LEGO, en fonction de l’objectif visé, des modules disponibles, des évolutions, des idées nouvelles,... Bref, ça doit être un projet vivant et évolutif.

Dans de telles conditions, il est clair qu’une application unique ne fait pas l’affaire, quelle que soit l’infrastructure technique utilisée. Certes on aurait pu arriver à un résultat fonctionnel similaire à grand renfort d’Arduino ou de scripts Python sur Raspberry, PCDuino et consorts, mais en perdant toute facilité d’évolution et souplesse d’expérimentation. Etant donné qu’un des souhaits est de pouvoir reconfigurer le bidule en fonction des animations auxquelles il est censé participer, ce type d’approche classiquement monolythique n’est pas appropriée.

Ne connaissant ROS que par la littérature, ça nous a semblé de plus une bonne idée de s’y former par la pratique avec un vrai cas d’étude. Il n’est pas certain que ROS soit la meilleure solution pour ce projet, et il est probablement overkill. Mais peu importe, encore une fois le projet n’est qu’un prétexte pour découvrir quelque chose de nouveau. Et c’est ce parcours de découverte et d’apprentissage qui nous motive avant tout, plus que le résultat final.

Ce sera d’ailleurs le contexte idéal pour expérimenter d’autres approches d’implémentation du même type d’architecture, par exemple sur un modèle plus léger basé sur D-Bus [2] et d’en comparer à l’issue de cela les avantages et inconvénients respectifs.

La transformation d’Emiglio en Nono a donné lieu à quelques modifications :

  • des tas de LEDs clignotantes, pour animer son sourire, ses yeux, ses plaques lumineuses,
  • un télémètre infra-rouge pour détecter qu’un visiteur est là,
  • une motorisation de la tête, équipée de capteurs de proximité pour pouvoir suivre les mouvements de la personne,
  • une sonorisation,
  • un petit écran LCD,
  • des boutons sur ses mains pour dialoguer par le toucher,
  • une RaspberryPi pour gérer tout cela.

L’architecture matérielle initiale comporte également une Arduino reliée par liaison série avec la RaspberryPi, et chargée de gérer l’interface avec le hardware. A ce jour Nono est déjà capable de quelques mouvements et animations, mais bien du chemin reste à faire.

Dans un souci de simplification, il a été décidé de la remplacer par des cartes d’interface issues de l’offre de AB Electronics, et déjà bien connues de certains d’entre nous et de reprendre l’architecture logicielle qui anime notre ami cybernétique.

Tout cela nous amènera à : Nono 2.0 :-))

 La suite ?

Cette rubrique regroupe une série d’articles écrits au fur et à mesure des travaux. Ce sont aussi bien des blogs retraçant un cheminement spécifique, des articles détaillant un élément particulier, une étude technique plus poussée,...

Comme le projet, il s’agit d’un contenu vivant et évolutif. Alors revenez faire un tour de temps en temps, car il y a des chances que des nouvelles lectures soient apparues depuis votre dernière visite.


[1récupéré je ne sais plus où

[2oui, je sais, je suis un peu monomaniaque dans mon genre

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document