Rapport projet UniceBot

UNIVERSITE NICE SOPHIA-ANTIPOLIS
04/06/2012

MASTER PROJET D’ANNEE : DEVELOPPEMENT POUR LE
1 MIAGE ROBOT ASPIRATEUR ROOMBA « TURTLEBOT »

Rapport | Antoine Boulinguez, Régis Canioncq, Shyn-Yuan Cheng,
Sébastien 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.

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

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 Fig. 1 Le robot aspirateur Roomba
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.


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).

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 .

Fig. 4 Vue d'ensemble du Turtlebot


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.

Fig. 6 Réseau du Turtlebot

Ordinateur maître utilisé Internet
pour piloter le robot à
distance

Transmission des
commandes VPN

Ordinateur esclave
embarqué pour
piloter le robot

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).


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.

ROS OpenCV GTK+
Emission données Conversion Affichage
Fig. 8 Pipeline de rendu du flux Kinect

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

Fig. 9 Rendu du flux kinect
Fig. 10 Hierarchie des widget GTK+ implémentés


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

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.
Fig. 11 Interface du Turtlebot en mouvement avec flux couleur

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


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

Fig. 13 interface avec flux monochrome

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

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.

Fig. 15. Interface texte de configuration ROS


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 Réalisée
exploitation de ces informations
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 Le domaine abordé (la robotique) et les technologies utilisées dans ce
dans la réalisation 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


Rapport projet UniceBot

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Rapport projet UniceBot

Similar a Rapport projet UniceBot (20)

Rapport projet UniceBot