Download pdf - Rapport projet UniceBot

UNIVERSITE NICE SOPHIA-ANTIPOLIS

04/06/2012

Rapport | Antoine Boulinguez, Régis Canioncq, Shyn-Yuan Cheng, Sébastien Lagneau

MASTER

1 MIAGE

PROJET D’ANNEE : DEVELOPPEMENT POUR LE

ROBOT ASPIRATEUR ROOMBA « TURTLEBOT »

2 DEVELOPPEMENT POUR LE ROBOT ASPIRATEUR ROOMBA « TURTLEBOT » M1 MIAGE – BOULINGUEZ, CANIONCQ, CHENG, LAGNEAU

Résumé

Ce rapport présente le projet d’année de quatre étudiants en MIAGE (Méthodes Informatiques

Appliquées à la Gestion des Entreprises) à Nice, dans le cadre de leur second semestre de Master 1 :

Antoine BOULINGUEZ, Régis CANIONCQ, Shyn-Yuan CHENG et Sébastien LAGNEAU.

Le présent document est la synthèse technique et méthodologie du projet d’année d’Antoine

Boulinguez, Régis Canioncq, Shyn-Yuan Cheng et Sébastien Lagneau, dans le cadre du Master 1

MIAGE - Université de Nice Sophia Antipolis, année 2011/2012.

Ce projet informatique a été l’occasion d’aborder un domaine faisant la jonction entre l’informatique

et l’électronique : la robotique. C’est dans ce domaine que nous avons notemment été amené à

développer une application permettant le pilotage à distance d’un robot.

Le robot en question se nomme Turtlebot et est composé d’un robot-aspirateur (iRobot Roomba) et

d’un dispositif de capture audio et vidéo (Microsoft Kinect). Les possibilités qu’offrent les deux

appareils composant le sujet du présent projet d’année sont multiples et les technologies logicielles

et matérielles permettant de travailler avec sont difficiles à maitriser. Les buts du projet sont donc de

maitriser aussi bien l’aspect matériel que l’aspect logiciel pour proposer une application permettant

de manipuler le robot à distance.

La particularité de ce projet est d’avoir lieu à Sophia Antipolis, dans les locaux du laboratoire I3S,

sous la direction de M. Andrew COMPORT et de M. Gilles MENEZ, le Turtlebot ne pouvant pas quitter

ce laboratoire.


Table des matières

1 Introduction ..................................................................................................................................... 4

2 L’environnement de travail : Le Pôle SIS (Signal, Images et Systèmes) .......................................... 5

3 Descriptifs des éléments techniques ............................................................................................... 6

3.1 IRobot et Roomba ................................................................................................................... 6

3.2 Kinect ....................................................................................................................................... 7

3.3 Configuration « Turtlebot » du Roomba ................................................................................. 8

3.4 Robot Operating System (ROS) ............................................................................................... 9

4 Élaboration du cahier des charges ................................................................................................ 10

4.1 Télésurveillance et téléopération du robot ........................................................................... 11

5 Calendrier prévisionnel ................................................................................................................. 12

6 Travail réalisé ................................................................................................................................. 14

6.1 Approche du projet ............................................................................................................... 14

6.2 Choix technologiques ............................................................................................................ 15

6.2.1 Choix du framework de développement ....................................................................... 15

6.2.2 Choix du langage principal de développement ............................................................. 17

6.3 Installation et configuration du Turtlebot ............................................................................. 18

6.3.1 Installation et configuration matérielle ......................................................................... 18

6.3.2 Installation et configuration logicielle ........................................................................... 18

6.4 Apprentissage de l’API et Développement............................................................................ 22

6.4.1 Les différentes bibliothèques utilisées .......................................................................... 22

6.4.2 L’implémentation .......................................................................................................... 23

6.5 Tests et optimisation ............................................................................................................. 24

6.6 Réalisation des objectifs ........................................................................................................ 25

6.6.1 Illustration des résultats ................................................................................................ 25

6.6.2 Fonctionnalités réalisées ............................................................................................... 27

7 Calendrier effectif .......................................................................................................................... 28

7.1 Cause des retards .................................................................................................................. 30

7.2 Problèmes rencontrés ........................................................................................................... 31

8 Conclusion ..................................................................................................................................... 32

9 Table des illustrations .................................................................................................................... 33

10 Annexes ..................................................................................................................................... 34


1 Introduction

La robotique est l'ensemble des techniques permettant la conception, la réalisation de machines

automatiques ou de robots. Il s’agit pour le robot d’effectuer des tâches prédéterminées par

l’homme, de manière autonome, une fois les directives connues (lave-linge, lave- vaisselle, robot-

aspirateur, etc.).

Les avancées dans ce domaine ont permis d’assister à la création de robots pouvant imiter la marche

humaine, pouvant guider les hommes pour diverses informations (robots-hôtesses ou instituteurs),

ou encore pouvant servir d’animal de compagnie.

L’acquisition d’images et de séquences d’images remonte à des décennies, voire des siècles. Les

technologies permettant ces acquisitions ont changé, évolué au fil du temps, ayant pour

conséquence d’améliorer la qualité des images saisies.

Jusqu’à il y a quelques années, la question de l’interprétation des images saisies trouvait des

réponses encore très floues. Il s’agissait, soit d’images saisies par un dispositif A et traitées plus tard

par un dispositif B (sous l’assistance de l’homme), soit traitées par l’homme lui-même. Mais n’était

pas encore étudiée la possibilité d’analyser les images, ou séquences d’images saisies par un

dispositif, indépendamment de l’homme.

Le fait de pouvoir saisir des images ou séquences d’images, et ensuite de pouvoir les analyser pour

pouvoir en tirer des informations pouvant revêtir un intérêt certain ou prendre des décisions, est une

des définitions possibles de la vision.

On peut noter, dans de nombreux cas de figure, qu’il n’est pas impossible d’établir un lien entre la

robotique et la vision (notamment dans le cas de robots pouvant imiter la marche humaine, de telle

sorte qu’ils puissent percevoir d’éventuels obstacles et agir en conséquence). La vision pouvant être

une aide précieuse pour certains types de robots, étudier la possibilité de lier robotique et vision

peut constituer une avancée technologique intéressante.

Pour notre projet, il s’agit de permettre à un robot aspirateur (Roomba) de voir ce qui l’entoure grâce

à un dispositif de capture vidéo comme le Kinect.


2 L’environnement de travail : Le Pôle SIS (Signal, Images et

Systèmes)

Notre projet prenait place à Sophia Antipolis, au sein du laboratoire de recherche I3S, (laboratoire

d’Informatique, Signaux et Systèmes de Sophia-Antipolis). Ce laboratoire est organise en quatre

pôles :

- COMRED : COMmunications, Réseaux systèmes Embarqués et Distribués ;

- GLC : Génie du Logiciel et de la Connaissance ;

- MDSC : Modèles Discrets pour les Systèmes Complexes ;

- SIS : Signal, Images, Systèmes.

Notre projet concerne le dernier pôle, dont le domaine de connaissances s’étend sur trois axes : les

signaux, l’imagerie et les systèmes. C’est sur le troisième axe qui nous intéresse sur ce projet, celui-ci

se penchant sur trois types d’activités :

- Condor – Drones ;

- SIM : System Identification and Modelling (Identification de systems et conception) ;

- ANM : Autonomous Navigation and Mapping (Navigation Autonome et Cartographie).

Notre projet porte sur la troisième activité, celle-ci ayant pour contributeurs, par ordre

alphabétique :

- M. COMPORT Andrew ;

- M. MENEZ Gilles ;

- M. THIERRY Eric ;

- Mme TORRES DOLORES RENDAS Maria João.

Les maitres d’ouvrage, ceux qui encadrent notre projet sont les deux premiers cités : M. COMPORT et

M. MENEZ.


3 Descriptifs des éléments techniques

3.1 IRobot et Roomba

Roomba est une gamme de robots aspirateurs automatiques et autonomes commercialisée depuis 2002 par la société iRobot. Cette société technologique américaine, fondée en 1990, est spécialisée dans la conception et la vente de robots ménagers mais aussi militaires. À ce jour, plus de 5 millions Roomba ont été vendus et de plusieurs déclinaisons et versions du Roomba ont été développées. Le Roomba est alimenté par une batterie rechargeable. Il peut être fourni avec une station d'accueil à laquelle il est capable de revenir pour se recharger à la fin de son cycle de nettoyage.

Depuis 2005, la société iRobot a choisi d’intégrer une interface physique et logicielle à leurs Roomba

pour que chacun puisse développer ses propres projets autour de la technologie iRobot. Cette

interface nommée iRobot Roomba Serial Command Interface (ou Roomba SCI), est un protocole

permettant aux développeurs de piloter le robot via son port série.

SCI inclut des commandes capables de contrôler toutes les capacités motrices et comportementales

du robot (moteurs, aspirations, haut parleurs, LED, etc.), mais aussi de capturer les données

collectées par les capteurs positionnés sur le robot. Grâce à SCI, les utilisateurs peuvent donc ajouter

des fonctionnalités au comportement de base du Roomba mais aussi créer de toute nouvelles

applications pour le robot.

Un site internet recense diverses applications utilisant le robot Roomba pour d’autres usages que le

nettoyage : http://hackingroomba.com/. On y retrouve par exemple des applications utilisant

Roomba comme un instrument de musique.

Fig. 1 Le robot aspirateur Roomba


3.2 Kinect

Le dispositif de capture d’images surmontant le Turtlebot est à la base un accessoire de jeux vidéo :

le Kinect, développé par Microsoft. À l’origine connu sous le nom de « Project Natal », cet accessoire

permet à la base aux possesseurs d’une console Microsoft Xbox360 d’interagir avec leur console, via

la voix (micro) ou via divers mouvements (caméras de détection de profondeur, infrarouge et

couleur).

Fig. 2 La camera Microsoft Kinect

Un pilote open-source du dispositif Kinect a vu le jour en 2010, malgré l’avertissement de Microsoft,

qui ne tolérait pas la moindre modification de son produit commercialisé avec des techniques

empêchant la rétro-ingénierie. Ce pilote a ensuite été porté sur ROS (Robot Operating System), ce

qui permet aux robots pouvant être pilotés avec (dont le Turtlebot) de pouvoir bénéficier de la

vision.

Fig. 3 Pattern du laser infrarouge Kinect


3.3 Configuration « Turtlebot » du Roomba

Afin d’augmenter encore les capacités sensitives du Roomba, il est possible de construire une version

améliorée communément appelée Turtlebot. Cette dénomination décrit la combinaison d’un

Roomba avec un périphérique Microsoft Kinect. C’est un Roomba dans sa configuration Turtlebot

que nous utiliserons pour le projet.

Le Turtlebot est conçu par Willow Garage, un laboratoire de recherche en robotique, qui aura

développé entre autres ROS (Robot Operating System) et OpenCV (bibliothèque graphique

initialement développée par Intel) qui sont deux applications open source, et qui aura également

conçu des robots comme PR2 (robot doté de deux bras) ou Texai (destiné à la visio-conférence).

Fig. 4 Vue d'ensemble du Turtlebot

A iRobot Roomba 521. B Périphérique de capture vidéo 3D Microsoft Kinect. C Ordinateur embarqué dédié au contrôle du robot. D Structure du Turtlebot.

Batterie dédiée à l’alimentation de la Kinect. Carte adaptateur Port Série/USB .


3.4 Robot Operating System (ROS)

Le principe de fonctionnement de ROS est le suivant : chaque programme ROS est appelé node et

peut communiquer avec d’autres nodes en s’inscrivant à ce que l’on appelle des topics et en

échangeant des données à travers ce topic. Il est possible avec ROS, de savoir quels nodes

communiquent entre eux au travers de quels topics en utilisant un outil intégré dans le framework :

le rxgraph. En voici un exemple ci-dessous :

Fig. 5 Graphe des noeuds ROS

Les ellipses représentent des nodes et les flèches, des topics. Dans cet exemple, nous pouvons

notamment remarquer que le nœud teleop_turtle communique avec le nœud turtlesim au travers du

topic turtle1/command_velocity, le premier node permet de piloter un Turtlebot et le second est un

utilitaire permettant de faire une simulation de pilotage d’un Turtlebot. On peut donc logiquement

déduire de ce graphe que le premier node envoie des données au second au travers du topic précité.

Le développement d’applications et la téléopération du robot se fait au travers de deux versions du

framework ROS :

- Une version « netbook » à installer sur l’ordinateur embarqué, et qui permet de téléopérer le

robot ;

Une version « workstation » à installer sur d’autres ordinateurs, pour y développer des applications à

tester sur le robot.

Pour développer sous ROS, il est nécessaire d’utiliser un terminal pour y lancer ROS et ainsi utiliser

les commandes terminal de ce framework (par exemple roscreate-pkg [package_name] [depend1]

[depend2] [depend3] pour créer un package ROS avec ses éventuelles dépendances). Il est ensuite

possible de développer sous un IDE (comme Eclipse ou Code Blocks), pour faciliter l’écriture du code,

mais il faudra ensuite compiler « à la main » (c’est-à-dire, via le terminal, avec la commande

rosmake) pour pouvoir créer les exécutables du ou des programmes que l’on développe.

Il est ensuite possible, à partir des ordinateurs de développement, de tester les applications

développées pour Turtlebot : ces ordinateurs sont connectés sur un réseau ad hoc, le même que

l’ordinateur embarqué sur le robot, et communiquent avec ce dernier pour qu’il puisse téléopérer le

robot.


4 Élaboration du cahier des charges

De par sa nature singulière, à mi-chemin entre l’électronique et l’informatique et notre manque

d’expérience dans ce domaine, il a été difficile de déterminer des objectifs fonctionnels initiaux pour

le projet. Le matériel support qui nous a été confié était inconnu, notamment pour les usages qui

pouvaient rentrer dans le cadre de notre projet. De plus, il fallait également découvrir et prendre en

main la plus part des outils et des technologies utiles au développement d’applications exploitant les

capacités motrices et sensorielles du robot.

De plus, nous nous sommes rendu compte que l’éventail des possibilités offertes par le matériel était

très large. Beaucoup d’applications pouvaient être implémentées pour le Turtlebot, et il nous était

difficile de déterminer les objectifs que l’on pouvait fixer et l’application finale que l’on voulait

obtenir, car beaucoup d’applications étaient intéressantes à implémenter, le choix a donc été

difficile.

La première étape dans la réalisation du cahier des charges a été de découvrir et de prendre en main

le robot. L’objectif premier à donc été d’être capable de connaitre le potentiel du matériel afin

d’élaborer des objectifs pour le CdC.

La seconde étape était de se familiariser avec les outils de développement, qui nous permettaient

d’utiliser le potentiel du matériel et de déterminer la faisabilité des objectifs fixés en premier lieu.

Nous avons identifié plusieurs fonctions à implémenter dans la réalisation de notre projet, des

fonctions principales et des fonctions complémentaires.

Pour ce qui est des fonctions principales :

- Mise en tension et hors tension du robot à distance ;

- Pilotage du robot à distance ;

- Affichages des images acquises et exploitation de celles-ci.

Pour ce qui est des fonctions complémentaires :

- Navigation autonome du robot ;

- Retour à un point de départ sur ordre de l’utilisateur.


4.1 Télésurveillance et téléopération du robot

L’objectif principal défini par le cahier des charges est la capacité pour un utilisateur de piloter le

robot à distance tout en observant ce que le robot voit grâce à la caméra 3D Kinect.

Les trois fonctions de service principales pour cet objectif étaient les suivantes :

- F1 : Pilotage du robot à distance (téléopération)

- F2 : Affichages des informations capturées par le Kinect et exploitation de ces informations

- F3 : Mise en marche/arrêt du robot à distance

Le diagramme ci-dessous décrit l’environnement global permettant la mise en œuvre des

fonctionnalités citées.

Dans sa configuration Turtlebot, le Roomba est commandé par un ordinateur esclave embarqué sur

sa structure. Ce dernier reçoit les ordres de commande depuis un ordinateur maître distant. Tous

deux sont connectés à internet par Wifi et sont reliés ensemble via un réseau privé virtuel (VPN).

Fig. 6 Réseau du Turtlebot

VPN

Ordinateur maître utilisé

pour piloter le robot à

distance

Ordinateur esclave

embarqué pour

piloter le robot

Internet

Transmission des

commandes


5 Calendrier prévisionnel

Afin de planifier au mieux la réalisation du projet, nous avons décidé d’un découpage du travail en

« work packages » comme suit :

WP1 Recherche et développements - conduit par Régis

- T1.1 Prise en main du robot, installation des environnements de développement

- T1.2 Prise en main et étude du framework ROS

- T1.3 Prise en main et étude du Kinect

- T1.4 Mise en projection des connaissances et des capacités acquises afin d’identifier les

développements futurs.

WP2 Conception et implémentation des applications identifiées - conduit par Shyn

Pour chaque application

- T2.1 Analyse et conception du système

- T2.2 Implémentation

- T2.3 Tests (tests "unitaires" et sur simulateur)

WP3 Mise en production et tests - conduit par Sébastien

- T3.1 Élaboration des scénarios de test grandeur nature (en fonction des cas d’utilisation,

avec critères de réussite)

- T3.2 Mise en production des applications sur le robot

- T3.3 Gestion des tests grandeur nature des applications

- T3.4 Rédaction de rapport d'exécution des tests (cas d’utilisation, description de

l’environnement lors des problèmes, comment reproduire le problème, diagnostique

envisagé, etc.).

WP4 Gestion de projet et livrables - conduit par Antoine

- T4.1 Gestion de l’équipe et suivi de projet

- T4.2 Rédaction des documents techniques

- T4.3 Rédaction des documents liés à la gestion de projet

- T4.4 Mise à jours des outils utilisés pour la gestion de projet (google project, agenda, etc.)


Le calendrier prévisionnel est le suivant :

Fig. 7 Planning prévisionnel


6 Travail réalisé

6.1 Approche du projet

Ce projet se démarque par le fait qu’il ne s’agit pas d’un projet purement informatique. Il s’agissait

également d’un projet électronique et robotique, puisque le sujet de notre projet est un robot

aspirateur surmonté d’un dispositif de vision. Ce projet était également une sorte de « sujet libre »

dans le sens où aucune application précise ne nous était demandée au départ. C’était donc à nous

d’imaginer et d’implémenter les fonctionnalités qu’on allait donner au Turtlebot au travers de notre

application, tout en utilisant au mieux les capacités du Turtlebot dans son ensemble (Roomba, Kinect

et les possibles interactions entre eux).

Ce projet touchait donc à plusieurs secteurs, et les manières d’exploiter le sujet de notre projet

étaient très nombreuses, ce qui rendait notre projet particulièrement singulier.

Il aura donc fallu dans un premier temps apprivoiser le Turtlebot, faire des tests, puis essayer de le

piloter par ordinateur. Il s’agissait là de faire l’état des lieux des capacités et des fonctionnalités

natives du Roomba afin d’être capable d’identifier les développements possibles.

Dans un second temps, il fallait se familiariser avec les frameworks qui permettaient de développer

des applications sur le Turtlebot. On en a identifié deux : PyRoomba, et ROS, qui nous était indiqué

au départ. Comme notre choix pour ce projet s’est porté sur le second, il nous aura fallu apprendre à

maitriser l’environnement qu’il offre (ce choix avait néanmoins ses contraintes, comme le fait qu’il

nous était imposé de travailler sous Linux, ou encore le fait qu’il faille choisir le langage C++, qui bien

qu’il ne nous était pas imposé, était recommandé pour pouvoir mieux traiter les flux de données

qu’envoie le Kinect).

Enfin, il aura fallu imaginer, puis implémenter une application pour le Turtlebot. Cette application

consiste dans un premier temps à proposer une interface de commande complète pour piloter à

distance ce robot avec la possibilité d’enregistrer la séquence d’images captée par le Kinect. Dans un

second temps, des pistes ont été explorées pour exploiter les séquences d’images enregistrées (par

exemple, la génération d’un itinéraire, puis reproduction de celui-ci grâce à la vision).


6.2 Choix technologiques

6.2.1 Choix du framework de développement

Afin de faciliter le développement et de nous extraire du protocole série bas niveau, nous avons

identifié deux « frameworks » encapsulant l’interface SCI nous permettant d’interagir avec le robot :

PyRoomba et Robot Operating System (ROS).

PyRoomba :

PyRoomba est un ensemble de modules Python développés spécialement pour contrôler les Roomba

d’iRobot. Ces modules pythons sont capables d’exploiter toutes les fonctionnalités motrices et

sensitives du robot.

ROS :

ROS quant à lui est un Framework plus global se comportant comme un système d’exploitation, il

s’agit en fait d’un système d’exploitation distribué sur plusieurs machines. Il se charge de

l’abstraction du matériel physique et fournit un ensemble d’outils et de bibliothèques utiles au

développement d’applications robotiques. ROS est compatible avec un grand nombre de robots est

notamment avec le Roomba et sa configuration Turtlebot. ROS est la plateforme officiellement

« fournie » avec un Turtlebot. La majorité des bibliothèques sont développées en Python ou en C++.

Visual studio - .net :

Il s’agit du bien célèbre framework de développement de Microsoft ainsi que son IDE. Depuis Mars

2012 la bibliothèque kinect officielle sous .net est disponible aux développeurs.

Il aura donc fallu donc faire un choix en ce qui concerne le framework de développement. Notre

choix s’est porté sur ROS, car celui-ci est complet, même s’il est contraignant à utiliser. ROS n’est

disponible en version stable que sur Ubuntu et ses distributions « sœurs » (nous avons choisi

Xubuntu, pour sa légèreté et sa simplicité d’utilisation).


Afin de pouvoir décider quel environnement adopter, nous avons établis des critères ainsi et avons

évalués chacun des framework. Il en résulte la matrice suivante :

Matrice des critères de prise de décision du framework

PyRoomba ROS Visual studio

Système Installation / configuration + + + - - - + + Compatibilité des drivers - + + Support réseau + + + + - Puissance de traitement + + + + + - - « Embarcabilité » + + + + + - - - Gestion de plusieurs robots - + + - - Programmation Diversité des langages de programmation - + + + + API existante Kinect - - - + + + + + API existante roomba + + + + + - - - Tutoriels et exemples - + + Complexité + - - - + + Support au développement - - - + + + + Evolutivité Possibilité d’évolution et potentiel - + + + + Effet d’expérience, notoriété en robotique - - + + + - Développements spécifiques au Turtlebot - + + + - Compatible avec l’environnement de l’équipe (OS, drivers, langage)

+ + + - - -

Evaluation (somme des + et des -) -11 29 -2

C’est donc ROS qui a été choisi pour le développement de notre application.


6.2.2 Choix du langage principal de développement

ROS ne nous impose pas un langage de développement en particulier (il est possible de coder en

python, en C++ et en Java, grâce à un portage expérimental), cependant, comme nous utilisons

également un dispositif d’acquisition d’images, le Kinect, la meilleure option était le langage C++,

pour optimiser le traitement des flux de données envoyés par celle-ci (le C++ étant un langage très

puissant, une évolution du langage C rétro compatible avec celui-ci, mais aussi difficile à maitriser à

cause de sa permissivité, notamment au niveau de la gestion mémoire).

Nous utilisons également des scripts en BASH (Bourne Again SHell) pour configurer les ordinateurs de

développement et de pilotage du robot.

La matrice qui nous a permis de décider quel langage de programmation nous allions utiliser est la

suivante :

Python C/C++ Java

Complexité + + - - + + + Puissance de traitement + + + + - Richesse de l’API + + + + - Support de l’API - + + - Exemples, tutoriels - + - Configuration / compilation + - - - Expérience + + - - -

Résultat 4 7 -6

C’est donc le C/C++ qui a été choisi pour développer notre application.


6.3 Installation et configuration du Turtlebot

6.3.1 Installation et configuration matérielle

Comme vu précédemment, le Turtlebot est un assemblage de:

- Un dispositif de vision Microsoft Kinect ;

- Un robot aspirateur Roomba ;

- Une plaque électronique de connexion au Roomba qui fournit une interface USB ;

- Un ensemble d’armatures tubulaires et de plateaux supportant le Kinect et l’ordinateur.

Il peut être commandé chez Willow Garage, une entreprise américaine qui développe du matériel et

des logiciels open sources pour la robotique. Il est livré en pièces détachées et doit être assemblé à la

réception. Au démarrage du projet, l’I3S nous a fourni un robot déjà monté et théoriquement prêt à

être interfacé avec un ordinateur.

Il nous a cependant été nécessaire d’apporter, avec l’aide de l’équipe I3S une modification : l’ajout

d’une batterie 12v pour permettre une alimentation autonome du Kinect, qui était trop gourmand

pour se satisfaire de la batterie d’origine du Turtlebot.

Le Turtlebot s’interface à un ordinateur via deux interfaces fournies :

- Un port USB relié au Kinect (camera) ;

- Un port USB relié au Roomba (base aspirateur motrice).

Nous aborderons la découverte de certains problèmes matériels qui a eu lieu pendant la

configuration logicielle comme décrit ci-après.

6.3.2 Installation et configuration logicielle

Le choix de la plateforme de développement ayant été fait, une première étape indispensable était

l’installation et configuration des systèmes d’exploitation supportés par ROS.

6.3.2.1 Installation du système d’exploitation et de ROS

Le système pour lequel les binaires ROS ont été précompilés est Linux Ubuntu (et ses déclinaisons

Kubuntu et Xubuntu).

Nous disposions de deux laptops fournis par l’I3S sous Ubuntu ainsi que de nos laptops personnels

fonctionnant sous Windows. Afin de pouvoir travailler efficacement en dehors des locaux de l’I3S,

nous avons donc entrepris, sur nos ordinateurs personnels, l’installation d’Ubuntu via une machine

virtuelle (Virtual Box).


Malheureusement il s’est avéré impossible de faire fonctionner le Kinect dans un système virtualisé,

son driver « open ni » ne le supportant pas.

C’est donc en dual-boot que nous avons dû installer Ubuntu sur nos PC personnels.

6.3.2.2 Communication USB avec le Turtlebot

Nous avons dû également faire face à un problème important : malgré le suivi à la lettre des

instructions d’installations de ROS pour Turtlebot, il nous a été impossible pendant une longue

période de faire fonctionner l’interface USB relié au Roomba du Turtlebot dont la vocation est la

commande de ses roues et moteurs.

Dans un premier temps, après un examen matériel attentif, nous avons découvert un défaut de

soudure de ce port (spécifique type DIN/PS2 modifié). Nous avons donc refait la soudure.

Malgré ce défaut écarté, nous échouions toujours dans l’établissement d’une connexion avec les

fonctions motrices du Turtlebot. Nous avons alors examiné d’autres moyens de communications

pouvant confirmer le bon état du port en excluant un éventuel problème d’installation/configuration

de ROS.

L’utilisation du terminal putty a pu nous montrer que le port répondait positivement à

l’établissement d’une connexion. Puis c’est en python avec Pyroomba (alternative à ROS) que nous

avons finalement réussi à affirmer que le port fonctionnait bien. Nous avons, à cette occasion, étudié

les commandes motrices au niveau le plus bas, celui de la transmission d’octets en USB.

Alors que nous allions renoncer à l’utilisation de ROS, système pourtant officiellement préconisé par

l’assembleur du Turtlebot. Nous avons pu, par expérimentation et analyse du driver de ROS (écrit en

python) déterminer que c’est celui-ci qui était à l’origine du problème.

La solution était donc de modifier ce driver pour brider la connexion à 19200 bauds au lieu de 57600

bauds, vitesse normalement supportée par le Turtlebot. La connexion à 19200 bauds fonctionne

donc bien sous ROS avec le Turtlebot, sans entrainer de désagréments particuliers.

Il peut paraitre étonnant que le système ROS préconisé par l’assembleur du Turtlebot ne marche pas

sans modification. Notre hypothèse est celle-ci : il existe différentes déclinaisons du Turtlebot, le

modèle de Roomba embarqué peut différer en fonction de sa date d’achat, voir même du pays

d’achat (en effet notre version a été achetée chez un assembleur européen et non pas chez

l’assembleur officiel US Willow Garage).


6.3.2.3 Configuration réseau

Une fois résolus les problèmes de communication USB avec le Turtlebot, un autre point délicat était

la configuration réseau des ordinateurs.

Basiquement le Turtlebot sous ROS requiert les ordinateurs suivants pour fonctionner :

- Un NETBOOK embarqué, disposant d’une autonomie suffisante et d’un poids et

encombrement réduits. Cet ordinateur embarqué a pour rôle la capture et la retransmissions

des images du Kinect et des instructions motrices du Roomba ;

- Un ordinateur dénommé « workstation », distant du Turtlebot et ne nécessitant pas d’être

mobile ou autonome. Son rôle est de télécommander le Turtlebot et effectuer un éventuel

traitement des données reçues ;

- Les deux machines tournant sous linux (Ubuntu) et exécutant le système ROS se doivent

d’être en réseau.

Etant donné l’encombrement important des machines fournies par l’I3S (trop lourdes et trop grosses

ou batterie HS) le choix a été fait d’utiliser un netbook appartenant à un des membres de notre

équipe projet pour l’embarquer sur le Turtlebot. On notera cependant la fourniture par l’I3S d’un

MacBook Air qui aurait pu convenir si l’installation de ROS (à compiler soit même sur mac) était

facilement réalisable dans le temps imparti (car expérimentale).

Malgré la présence de nombreux réseaux dans les locaux de l’I3S, il s’est avéré difficile de les

exploiter. Le tableau ci-dessous résume les difficultés rencontrées.

Réseau Exploitabilité Raison

Wifi Eduroam Aucune Déconnexions intempestives

Wifi Unice-hot spot Aucune Ports bloqués

Wifi I3S Partielle VPN obligatoire Difficulté d’obtention des identifiants Débit irrégulier

Filaire I3S Aucune Blocage des adresses mac non référencées

Dans un premier temps, nous avons donc optés pour l’établissement d’un réseau ad-hoc entre la

machine embarquée « Turtlebot » et la machine distante « workstation ». L’établissement d’un tel

réseau dépend fortement des systèmes d’exploitation utilisés et il n’était pas rare de devoir passer

plus d’une heure pour y parvenir. Cela ne fut pas sans conséquences sur notre productivité.

Nous avons donc finalement pu nous procurer un routeur wifi indépendant afin de réaliser une

connexion réseau fiable et enfin pouvoir expérimenter nos développements logiciels.


6.3.2.4 Scripts de configuration

Une fois les communications USB et réseau établies, une question clé fut la configuration des

variables d’environnement ROS (différentes sur chacune des machines en fonction de la

configuration réseau) ainsi que l’exécution dans un ordre précis et avec un timing efficace de tous les

processus (dénommés « nodes » dans ROS) nécessaires au bon fonctionnement des équipements.

Ces configurations et exécutions étant assez longues et rébarbatives, nous avons créés des scripts

shell linux (bash) automatisant ces tâches. Ces scripts sont garnis d’une interface utilisateur (en mode

texte) facilitant grandement leur utilisation. Il est à noter qu’ils incorporent le patch du driver ROS

ainsi que la résolution de nombreux problèmes rencontrés durant ce projet et non documentés par

le fabriquant. Leur mise au point a été continue durant toute la durée du projet.

Ils garantissent une bonne initialisation des machines embarquée et distante permettant ainsi de se

concentrer sur les problèmes de développement d’application.


6.4 Apprentissage de l’API et Développement

6.4.1 Les différentes bibliothèques utilisées

Pour la capture des images du Kinect ainsi que la commande des déplacements du Roomba, ROS

fournit les drivers nécessaires, transmet les données capturées par le Kinect à notre programme et

achemine nos commandes de déplacement vers le Roomba.

Pour le calcul (gestion des différents encodages) et l’affichage image par image de la vidéo en temps

réel capturée par le Kinect et transmis par ROS, nous utilisons la bibliothèque graphique OpenCV.

Spécialisée dans la lecture, l’écriture et le traitement d’images et de vidéos, cette bibliothèque ne

propose cependant pas la possibilité de faire une « belle » interface graphique complète avec

notamment une barre d’outils et un menu.

C’est pourquoi, il nous fallait une autre API pour créer une fenêtre avancée dans laquelle envelopper

la vidéo du Kinect traitée par OpenCV. Nous avions donc eu le choix entre deux API : Qt ou GTK+.

Nous avons donc testé les deux API au travers de deux programmes qui affichaient la vidéo du

Kinect. Il se trouvait alors que GTK+ était le plus simple à utiliser. En effet, le nombre de lignes était

beaucoup plus conséquent pour faire la même chose dans Qt. C’est donc GTK+ que nous avons choisi

pour l’affichage de la fenêtre de notre application.

Enfin, il nous fallait faire parler le robot au travers des haut-parleurs de l’ordinateur embarqué.

L’utilisateur devait pouvoir écrire un message depuis le workstation, choisir un son à jouer, et le

robot se chargeait de le dire ou de le jouer. Pour cela, nous avons décidé de faire un nœud ROS

différent de notre programme (ou nœud) principal, utilisant le stack ROS audio_common. Ce stack

propose plusieurs packages pour la gestion de la capture et de la sortie audio. Audio_play est le

nœud qui souscrit au topic « robotsound », il est lancé sur l’ordinateur embarqué par le Turtlebot.

Tandis que notre nœud « Unicebot_Talker » publie les messages contenant les données des sons à

jouer dans ce topic. Cette publication s’effectue lorsque l’utilisateur choisit un son à jouer ou écrit

une phrase à faire dire à notre robot. Notons que l’interface pour l’écriture des phrases et le choix

des sons prédéfinis est différente de celle de notre nœud principal (sous GTK). En effet, cette

interface est le terminal de Linux.


6.4.2 L’implémentation

Dans GTK+, tout élément affiché à l’écran est widget. En effet, une fenêtre (GtkWindow), un

conteneur (GtkHBox, GtkVBox, GtkLayout etc.), une barre d’outils (GtkToobar), etc. sont des

widgets. Ainsi, ce sont tous des objets GtkWidget par relation d’héritage.

La gestion de l’affichage est gérée par GTK+ dans une boucle indépendante dédiée. Dans notre cas

cette gestion s’effectue sur un unique thread différent de celui qui gère les traitements de notre

programme. En effet, la fonction GtK_Main() permet de lancer cette boucle et donc l’affichage de la

fenêtre. De plus, cette boucle émet et reçoit des « signaux » (évènements) par rapport à nos widgets

(click de souris, appuie sur un bouton, la fenêtre perd le focus, la fenêtre se ferme etc.). Le

traitement de ces signaux s’effectue dans des callbacks et ce n’est qu’après l’exécution de ces

callback que le contenu des widgets GTK+ est rafraîchi.

Ceci a été une source de difficultés car nous devions modifier le contenu des widgets dans la callback

d’un évènement ROS (émis pour chaque image que le Kinect génère). En effet, il a fallu trouver un

moyen de forcer le rafraîchissement de l’affichage des widgets que nous modifions. Ce moyen est de

forcer l’itération de la boucle principale de GTK+.

Concernant l’affichage en temps réel des images émises par le Kinect, nous nous abonnons

initialement à un topic ROS « /camera/rgb/image_color » permettant ainsi de recevoir les données

du Kinect. Ainsi pour chaque image reçue, une callback est appelée. Dans cette callback, les données

sont initialement traitées avec OpenCV, en faisant conversions nécessaires selon l’encodage de

l’image (Bayer, Flotant etc.). Ainsi nous obtenons une IplImage (objet OpenCV) dont nous devons

convertir en GtkImage pour l’afficher.

Voici la hiérarchie des widgets GTK+ de notre application :

Fig. 10 Hierarchie des widget GTK+ implémentés

ROS OpenCV GTK+

Emission données Conversion Affichage

Fig. 8 Pipeline de rendu du flux Kinect

Fig. 9 Rendu du flux kinect


L’enregistrement des images du Kinect est géré avec openCV, notamment grâce à la fonction

cvSaveImage. Cet enregistrement est déclenché au clic sur un des boutons de la barre d’outils. Un

GtKFileChooser permet de choisir le chemin d’enregistrement.

Pour le contrôle du Roomba à la souris, nous utilisons les évènements GTK+ « motion-notify-event »,

« button-press-event » et « button-release-event» qui sont émis par la fenêtre. Ainsi dans le callback,

selon la position de la souris dans la fenêtre, nous publions un message sur le topic ROS

« turtle1/command_velocity » avec les informations d’angle et de vitesse de déplacement. Ceci

permet ainsi de commander le déplacement du robot. De même, nous capturons les évènements

claviers de la fenêtre GTK+ pour gérer les commandes claviers de déplacement du robot.

Enfin, la flèche indiquant la direction en cours du Roomba est dessinée grâce à OpenCV.

6.5 Tests et optimisation

Au fur et à mesure de notre avancée dans le développement, nous avons effectué divers tests afin de

s’assurer du bon fonctionnement de notre programme.

Notre protocole de test est le suivant : Tout d’abord, nous testons en local (seulement la machine

Turtlebot), puis nous testons avec la machine Workstation connectée en VPN à la machine Turtlebot

et enfin, si tout se passe bien, nous embarquons le PC Turtlebot et faisons sortir le robot de la salle

de travail pour effectuer une plus grande distance.

Le premier bug pour lequel nous avions eu des problèmes était une fuite mémoire lors l’affichage des

images du Kinect sous GTK+. Il a fallu comprendre la gestion mémoire d’OpenCV (cvRelease après un

cvCreate) pour résoudre ce problème.

Les autres problèmes majeurs étaient le manque de réactivité du contrôle des déplacements du

robot, ainsi que le nombre d’image par seconde reçus du Kinect à distance très faible. Cela induit une

impossibilité de contrôle à distance le robot. Pour régler le problème de contrôle des déplacements,

nous avons rajouté un timer ROS permettant de republier l’état en cours (angle et vitesse de

déplacement) toutes les dixièmes de secondes.

Concernant le problème de fluidité de la vidéo du Kinect lorsque l’on est en réseau VPN, nous avons

découvert que le package ROS « image_transport » possédait un plugin

« compressed_image_transport » qui pouvait intercepter les images brutes du Kinect depuis un

topic ROS, les compresser au format jpeg et ensuite les republier dans le même topic ROS. Pour

l’utiliser, il y avait deux choses à faire. D’une part, sur le Turtlebot, demander à ROS de compresser

les images reçues et de les republier, grâce à la commande : « rosrun image_transport republish

compressed in:=/camera/rgb/image_color _image_transport:=compressed raw

out:=/camera/rgb/image_color ». D’autre part, sur le workstation, il fallait indiquer dans les

paramètres d’appel de la fonction subscribe que nous recevons des images compressées.


6.6 Réalisation des objectifs

6.6.1 Illustration des résultats

Fig. 11 Interface du Turtlebot en mouvement avec flux couleur

Ci-contre l’interface principale du logiciel réalisé et exécuté sur une machine distante (non embarquée) pour le téléguidage du Turtlebot. Un des flux d’images transmis par le Kinect est affiché en temps réel, après conversion, sur l’interface GTK. Ici c’est le flux couleur qui est récupéré. C’est grâce à la souris ou au clavier, on peut diriger le Turtlebot via l’interface et ainsi lui faire explorer son espace de navigation.

La flèche verte au centre (ci-dessus) est l’illustration du vecteur de déplacement du Turtlebot. Sa taille est fonction de la vitesse et son orientation correspond à celle du Turtlebot. En cas d’arrêt c’est un cercle rouge qui est affiché (ci-contre).

Fig. 12 Interface du Turtlebot à l'arret


Fig. 13 interface avec flux monochrome

Il est également possible de récupérer le flux monochrome du Kinect ainsi que le flux illustrant les données de profondeur.

L’enregistrement des flux transmis est possible, soit en mode image par image comme le montre le dossier représenté ci-contre, soit en mode vidéo. Ces flux peuvent ainsi être stockés pour une utilisation ultérieure ; éventuellement par les algorithmes de reconstitution 3D ou de guidage autonome développés par l’équipe I3S.

Fig. 14 Flux sauvegardé image par image

Fig. 15. Interface texte de configuration ROS

Parmis les développements réalisés, c’est le menu de configuration et demarrage du Turtlebot, développé en script shell linux (bash) qui est représenté ici.


6.6.2 Fonctionnalités réalisées

Par rapport au cahier des charges original, le tableau ci-dessous montre quelles ont été les

fonctionnalités réalisées par rapport aux fonctionnalités initialement prévues. Toutes les fonctions de

service principales ont été développées. On note une évolution du cahier des charges en ce qui

concerne les fonctionnalités complémentaires qui n’ont pas été réalisées mais remplacées par de

nouvelles, après réexamen de la faisabilité technique et temporelle de celles-ci.

Fonction Etat

F1 Pilotage du robot à distance (télé-opération) Réalisée

F2 Affichages des informations capturées par le Kinect et exploitation de ces informations

Réalisée

F3 Mise en marche/arrêt du robot à distance Réalisée (dépendante de l’environnement réseau)

C1 Navigation autonome du robot Non réalisée

C2 Retour à un point de départ sur ordre de l’utilisateur Non réalisée

C3 Enregistrement des flux vidéo pour traitement postérieur Réalisée

C4 Faire parler le Turtlebot Réalisée


7 Calendrier effectif

Le calendrier de réalisation effectif est différent du calendrier prévisionnel. Du retard a été pris et a

empêché la réalisation complète du work package WP3.

WP1 Recherche et développements - conduit par Régis

- T1.1 Prise en main du robot, installation des environnements de développement

- T1.2 Prise en main et étude du framework ROS

- T1.3 Prise en main et étude du Kinect

- T1.4 Mise en projection des connaissances et des capacités acquises afin d’identifier les

développements futurs.

- T1.5 Implémentation et mise à jour de scripts de configuration de l’environnement

WP2 Conception et implémentation des applications identifiées - conduit par Shyn et Sébastien

- T2.1 Analyse et conception de l’application de téléopération

- T2.2 Implémentation de l’application de téléopération

- T2.3 Analyse et conception de l’application de communication

- T2.4 Implémentation de l’application de téléopération

- T2.5 Mise en production et tests

WP3 Mise en production et tests - conduit par Sébastien

- T3.1 Élaboration des scénarios de test grandeur nature (en fonction des cas d’utilisation,

avec critères de réussite)

- T3.2 Mise en production des applications sur le robot

- T3.3 Gestion des tests grandeur nature des applications

- T3.4 Rédaction de rapport d'exécution des tests (cas d’utilisation, description de

l’environnement lors des problèmes, comment reproduire le problème, diagnostique

envisagé, etc.).

WP4 Gestion de projet et livrables - conduit par Antoine

- T4.1 Gestion de l’équipe et suivi de projet

- T4.2 Rédaction des documents techniques

- T4.3 Rédaction des documents liés à la gestion de projet

- T4.4 Mise à jours des outils utilisés pour la gestion de projet (google project, agenda, etc.)


-

Janvier Février Mars Avril Mai S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 WP1 - Recherche et développement T1.1 T1.2 T1.3 T1.4 T1.5 WP2 - Conception et implémentation des applications identifiées T2.1 T2.2 T2.3 T2.4 WP3 – Mise en production et tests T3.1 T3.2 T3.3 T3.4 WP4 - Gestion de projet et livrables T4.1 T4.2 T4.3 1 T4.4 Fig. 16 Planning effectif

1 - Rendu du cahier des charges


7.1 Cause des retards

Les retards constatés par rapport au calendrier initial et les différences dans le déroulement du

projet sont principalement dus à trois facteurs :

La nature du projet La nature du projet proche de la recherche a conduit à un fort investissement de temps dans le domaine de la recherche et du développement. N’ayant conduit dans notre cursus que des projets dont nous maîtrisions le domaine et les technologies, nous avons sous-estimé le temps nécessaire à la prise en main globale du projet. De ce fait on observe un écart dans la répartition du temps entre le planning initial et le planning final.

Les difficultés rencontrées dans la réalisation

Le domaine abordé (la robotique) et les technologies utilisées dans ce projet nous ont parfois posé des difficultés techniques annexes à l’analyse et au développement, entrainant ainsi des retards dans certaines tâches.

Le contexte du projet La localisation du projet à Sophia-Antipolis a été incontestablement une difficulté supplémentaire dans l’organisation du travail et l’avancement du projet.


7.2 Problèmes rencontrés

Nous avons rencontré plusieurs problèmes lors du déroulement du projet :

- Le sujet de notre projet, le Turtlebot, ne pouvant quitter l’institut de l’I3S, il nous aura fallu nous

déplacer à Sophia pour pouvoir tester le robot et travailler dessus. Nous avions décidé que nous

irions essentiellement sur place en étant au moins deux, mais à cause de nos emplois du temps

respectifs plutôt chargés et qui ne correspondaient pas beaucoup, il nous était difficile de

pouvoir travailler fréquemment sur le projet durant les premières semaines ;

- Lors de nos premiers essais avec le robot, il nous était impossible de le faire fonctionner avec

ROS, à cause d’un problème de branchements. Il aura été finalement possible de faire

fonctionner le Turtlebot avec ROS en s’assurant qu’il était connecté dans un type précis de

branchements (ttyUSB0) ;

- Le framework ROS était s’est parfois avéré difficile à installer et à utiliser suivant les configuration

matérelle et logicielle des machines et ce, malgré la présence de tutoriels en anglais sur le site

officiel de ROS. Nous avons dû essayer plusieurs fois de l’installer sur nos ordinateurs respectifs

(problèmes de paquets, d’ordre d’installation) pour pouvoir mettre en place notre

environnement de développement et ainsi, commencer à implémenter notre application ;

- Le Turtlebot était difficile à manier au départ, car plusieurs programmes sur nos ordinateurs

empêchaient aux services que proposaient ROS de se lancer correctement, et donc de

fonctionner. Il aura fallu élaborer un script de démarrage de la téléopération du robot, en

arrêtant tout ce qui empêchait les programmes présents sur ROS de fonctionner au préalable,

puis en lançant les services que l’on voulait utiliser pour la téléopération du robot (exemples :

image de profondeur, image RGB, dashboard de contrôle du robot et pilotage du robot grâce aux

touches du clavier d’un ordinateur distant) ;

- Étant donné que le Turtlebot est constitué d’un robot aspirateur Roomba et d’une Kinect, la

batterie du Turtlebot devait être capable d’alimenter les deux appareils. Or, la Kinect est très

énergivore, et ses besoins dépassent de très loin les capacités de la batterie du robot.

Cependant, il était tout de même possible d’alimenter la Kinect avec, mais les performances de

celle-ci était bien moindres, et l’autonomie du Turtlebot diminuait considérablement également.

Il aura fallu ajouter une seconde batterie pour la Kinect, et réarranger les branchements pour

rendre le tout autonome, ce qui aura impliqué une manipulation du matériel à laquelle on n’est

pas habitués ;

- Le langage de programmation utilisé pour ce projet, le C++, est un langage très puissant, mais

aussi très permissif sur l’aspect de la gestion de la mémoire, ce qui fait que le moindre problème

dans l’application peut entrainer une surcharge de la mémoire vive, ce qui peut être dangereux.

De plus, sont utilisées conjointement dans notre projet deux bibliothèques, Gtk et OpenCV, et le

manque de documentation pour celles-ci nous a fait perdre un temps précieux dans

l’implémentation de notre application.


8 Conclusion

Nous avons étés très enthousiasmés par ce projet de robotique qui nous a permis de lier

informatique et monde réel. Ce fut l’occasion de se confronter à l’écart important qu’il peut y avoir

entre théorie logicielle et réalité physique.

Notre ambition, après avoir « essuyé les plâtres » du Turtlebot, est que notre application constitue

une base saine sur ce matériel, pour le support des applicatifs de plus haut niveau du pôle SIS de

l’I3S, tels que la cartographie 3D de l’intérieur de bâtiments et la navigation autonome. On pourrait

également envisager une utilisation plus ludique avec plusieurs Turtlebots qui interagirait entre eux

sous forme de jeu.

Enfin malgré les nombreuses difficultés rencontrées, nous avons acquis des notions pour le

développement d’applications de robotique grâce à ROS et dans le domaine du traitement de

signaux visuels.

Nous espérons avoir à nouveau l’opportunité de mettre ces connaissances en pratique dans le

domaine de la robotique.


9 Table des illustrations

Fig. 1 Le robot aspirateur Roomba .......................................................................................................... 6

Fig. 2 La camera Microsoft Kinect ........................................................................................................... 7

Fig. 3 Pattern du laser infrarouge Kinect ................................................................................................. 7

Fig. 4 Vue d'ensemble du Turtlebot ........................................................................................................ 8

Fig. 5 Graphe des noeuds ROS................................................................................................................. 9

Fig. 6 Réseau du Turtlebot ..................................................................................................................... 11

Fig. 7 Planning prévisionnel ................................................................................................................... 13

Fig. 8 Pipeline de rendu du flux Kinect .................................................................................................. 23

Fig. 9 Rendu du flux kinect .................................................................................................................... 23

Fig. 10 Hierarchie des widget GTK+ implémentés ................................................................................. 23

Fig. 11 Interface du Turtlebot en mouvement avec flux couleur .......................................................... 25

Fig. 12 Interface du Turtlebot à l'arret .................................................................................................. 25

Fig. 13 interface avec flux monochrome ............................................................................................... 26

Fig. 14 Flux sauvegardé image par image.............................................................................................. 26

Fig. 15. Interface texte de configuration ROS ....................................................................................... 26

Fig. 16 Planning effectif ......................................................................................................................... 29


10 Annexes

Cahier des charges

Cookbook pour le développement