RALF. Dossier de Post-Evaluation

Code projet : 31 Ecole Centrale de Lille - Activité-Projet RALF Dossier de Post-Evaluation Equipe élèves : - Florence Bohnes - Alexandre Chakroun - Stéphane Coulon - Maxence Dallongeville - Vladimir Dombrovski - Guillaume JEAG -Ahmed Trabelsi Directeur scientifique : Thomas Bourdeaud huy Pilote : Amandine Leriche Date :04 /04 /14

«L'équipe atteste que ce travail est original et indique en bas de page chaque source utilisée» Signatures des membres de l équipe projet :

version : 02/04/2014 DEFINITION DE PROJET CODE PROJET : 31 VERSION N 2 DATE : 02/04/14 SUJET : Titre : RALF Objectif : Créer une plateforme multimédia interactive communiquant avec des téléphones mobiles et l utilisateur. Ce robot pourra se connecter à Internet afin d y récolter des informations, puis de les transmettre intelligemment à l utilisateur. Il pourra de plus être capable de divertir l utilisateur. Origine de l idée : Directeur Scientifique (M. Bourdeaud huy) Disciplines concernées : Mécanique, Automatique, Informatique Embarquée, GE ACTEURS : Equipe élèves : NOM Prénom (groupe) - encadrer le nom du correspondant - Florence BOHNES (F11) -Ahmed TRABELSI (G21) - Guillaume JAEG (G11) -Alexandre CHAKROUN (H12) -Stéphane COULON (G11) -Vladimir DOMBROVSKI (E21) - ( ) Projet en 3 ou 4 semestres. Equipe enseignants : - Directeur Scientifique : M. Bourdeaud huy - Conseiller Scientifique (facultatif) : - Consultant : Philippe Quaegebeur domaine : Mécanique - Consultant : Alexandre Kruzewski domaine : Automatique - Consultant : Fabien Verbrugghes domaine : Electronique - Consultant : Samir El Khattabi domaine : Informatique Partenaires extérieurs : Pas de Partenaire extérieur. Partenariat avec l électif Intelligence Ambiante. Financement : acquis négociation en cours non acquis EVALUATION DES RISQUES SECURITE : 1 2 3 EVALUATION DES DEPENSES ( ) : 400 SIGNATURES : Elèves : Directeur Scientifique : En toute circonstance, je m'engage à veiller à ma sécurité et à celle de mes camarades Sauf convention avec une entreprise, EC Lille est seule propriétaire des résultats du projet PARTIE RESERVEE AU DEPARTEMENT INGENIERIE : Fiche examinée le : / / Commentaires Pilote désigné : DECISION : Projet accepté Projet intéressant mais faisabilité à prouver (nouvelle version de la fiche) d ici le Projet refusé en l état, Nouvelle proposition à faire pour le Ecole Centrale de Lille p. 1/1 Département Ingénierie

Table des matières Introduction 9 1 Organisation et technique dans le projet 10 1.1Mise en place du projet 10 1.1.1 Naissance du projet...................................... 10 1.1.2 Définition et organisation du projet.............................. 10 1.1.2.1 Définition du projet.................................. 10 1.1.2.2 Organisation du projet................................. 11 1.2Partie Mécanique 12 1.2.1 Planification........................................... 12 1.2.2 Recherche de solutions techniques............................... 13 1.2.2.1 Fabrication du corps.................................. 13 1.2.2.2 Mouvement des bras.................................. 14 1.2.2.3 Mouvement de la tête................................. 14 1.2.2.4 Agencement des composants à l intérieur du robot................. 15 1.2.3 Conception sous CATIA.................................... 15 1.2.3.1 Modélisation des composants............................. 15 1.2.3.2 Organisation interne du robot............................. 15 1.2.3.3 Réalisation de la coque du robot........................... 16 1.2.4 Commande des composants de la coque du robot...................... 17 1.2.5 Fabrication à l atelier mécanique............................... 18 1.2.6 Intégration des composants électroniques........................... 19 1.3Partie Automatique 20 1.3.1 Introduction........................................... 20 1.3.2 Précision............................................. 20 1.3.3 Présentation du problème................................... 20 1.3.4 Cahier des charges....................................... 20 1.3.5 Présentation du problème................................... 20 1.3.6 Modélisation du moteur.................................... 21 1.3.7 Caractérisation du moteur................................... 21 1.3.8 Modélisation et simulation sous MatLab........................... 23 1.3.9 Conclusion........................................... 27 1.4Pôle Electronique 28 1.4.1 Introduction........................................... 28 1.4.2 Démarche............................................ 28 1.4.3 Problématiques......................................... 28 1.4.4 Entrée audio.......................................... 29 1.4.5 Sortie audio........................................... 32 1.4.6 Signalisation lumineuse.................................... 33 1.4.7 Bouton............................................. 34 1.4.8 Pont H.............................................. 34 1.4.9 Shield.............................................. 36 1.5Pôle Informatique 37 1.5.1 Introduction........................................... 37 1.5.2 Le système embarqué...................................... 38 1.5.2.1 Considérations sur le choix du Raspberry Pi et de ArchLinux........... 38 1.5.2.2 Gestion des processus et fonctionnement général.................. 39 Page 4/173 Partie 0

1.5.3 Paquets et fonctions système................................. 41 1.5.3.1 Installation des paquets et des dépendances..................... 41 1.5.3.2 Mise en place de la connexion Wifi.......................... 42 1.5.4 Conception des fondements du système............................ 46 1.5.4.1 L organisation du système de base.......................... 46 1.5.4.2 Le multiplexeur..................................... 46 1.5.4.3 Les sockets partie client............................... 48 1.5.4.4 Le contrôleur...................................... 49 1.5.5 Les programmes de traitement de données.......................... 53 1.5.5.1 La reconnaissance vocale............................... 53 1.5.5.2 Le contrôle du bouton................................. 54 1.5.5.3 La reconnaissance d images.............................. 54 1.5.5.4 Le programme de contrôle des moteurs........................ 57 1.5.5.5 Contrôle des LED................................... 60 1.5.5.6 La synthèse vocale................................... 62 1.5.6 Les applications......................................... 64 1.5.6.1 Le streaming de musique............................... 64 1.5.6.2 L application météo.................................. 64 1.5.6.3 La lecture des emails.................................. 66 1.5.6.4 Les perspectives de développement.......................... 69 1.5.7 Conclusion........................................... 70 1.6Tests du robot assemblé 71 2 Gestion de projet 72 2.1Introduction 72 2.2Budget 72 2.2.1 Premières estimations..................................... 72 2.2.2 Solution finale.......................................... 73 2.2.3 Charges non financières.................................... 73 2.3Valorisation 74 2.3.1 Valorisation sur internet.................................... 74 2.3.1.1 CentraleWiki...................................... 74 2.3.1.2 Le site internet du projet............................... 74 2.3.1.3 La diffusion du site internet.............................. 77 2.3.2 Valorisation sur d autres supports............................... 78 2.3.2.1 Le poster........................................ 78 2.3.2.2 L article de presse................................... 78 2.3.2.3 La plaquette...................................... 78 2.3.2.4 Les tutoriels....................................... 79 2.3.2.5 Le QRCode....................................... 79 2.4Partenaires 80 2.4.1 Campagne de recherche de partenaire :............................ 80 2.4.2 Relation avec le CITC :.................................... 80 2.4.3 Conclusion :........................................... 80 2.5Documentation 81 2.5.1 Dossiers produits........................................ 81 2.5.2 Les comptes rendus....................................... 81 2.5.3 Le site web externe....................................... 81 2.5.4 Dropbox............................................. 81 Page 5/173 Partie 0

2.6Animation 82 2.7Communication interne 84 2.7.1 Première étape de la communication : le googlegroup.................... 84 2.7.2 Le miniblog........................................... 84 2.8Planification 85 2.8.1 Outils mis en place...................................... 85 2.8.2 Recherche d outils plus avancée................................ 85 2.8.2.1 DESCRIPTION DE PROJECT OR RIA :...................... 86 2.8.2.2 SES FONCTIONNALITES :............................. 86 3 La suite... 86 3.1Futur du projet 86 3.1.1 Utilisation à l école....................................... 86 3.1.2 Partage avec la communauté Open Source.......................... 87 3.2Futur du projet 88 3.2.1 Utilisation à l école....................................... 88 3.2.2 Partage avec la communauté Open Source.......................... 88 3.3Industrialisation du projet Android 89 Conclusion 93 Annexes 94 Résumé 173 Page 6/173 Partie 0

Table des figures 1 Robot en 3D.......................................... 10 2 Tableau partie mécanique................................... 12 3 Organisation du pôle mécanique............................... 13 4 Imprimante 3D......................................... 13 5 Imprimante 3D......................................... 14 6 HarmonicDrive......................................... 15 7 Intérieur de RALF....................................... 16 8 Intérieur de RALF....................................... 16 9 Vue extérieure de RALF.................................... 17 10 Les bras du robot........................................ 17 11 La fabrication.......................................... 18 12 RALF vers la fin du projet.................................. 19 13 RALF vers la fin du projet.................................. 19 14 Modélisation du système.................................... 20 15.................................................. 21 16.................................................. 21 17.................................................. 21 18 Circuit pour déterminer Ra.................................. 22 19 Evolution de la tension..................................... 22 20 Vue globale du robot...................................... 23 21 Modélisation de la caméra et du traitement d image.................... 24 22 Présentation de l entrée.................................... 24 23.................................................. 24 24.................................................. 24 25 Asservissement avec un correcteur PI............................. 25 26.................................................. 25 27 Schéma avec saturation.................................... 25 28 Réponse indicielle........................................ 25 29 Schéma du système complet.................................. 26 30 Système asservi complet.................................... 26 31 Réponse à une rampe..................................... 27 32 Réponse à une sinusoïde.................................... 27 33 Micro avec connexion usb................................... 29 34 Carte son usb.......................................... 29 35 Schéma du montage du micro................................. 30 36 Montage du micro sur la table à trous............................ 31 37 Carte micro (face 1)...................................... 32 38 Carte micro (face 2)...................................... 32 39 Carte amplificateur audio................................... 33 40 Carte Led............................................ 34 41 Carte bouton.......................................... 34 42 Carte pont H.......................................... 35 43 Carte Shield (face 1)...................................... 36 44 Carte Shield (face 2)...................................... 36 45 Schéma de fonctionnement................................... 40 46 Schéma de fonctionnement................................... 47 47 Caméra relié au Raspberry Pi................................. 54 48 Page du projet sur Centrale Wiki............................... 74 49 Site internet ralf.ec-lille.fr................................... 75 50 Exemple d article du site.................................... 76 51 Exemple d article du site.................................... 76 52 Activité du site en temps réel................................. 77 53 Activité du site sur une plus longue durée.......................... 77 Page 7/173 Partie 0

54 QR Code............................................ 79 55 Code latex............................................ 81 56 Compte rendu d une séance de QHP............................. 83 57 Gantt pôle mécanique au S7.................................. 85 58 Planification pour la fin de l année.............................. 85 59.................................................. 89 60 Première méthode....................................... 90 61 Deuxième méthode....................................... 91 62 Etude sur le long terme.................................... 91 63 Tableau récapitulatif...................................... 92 Page 8/173 Partie 0

Introduction Le projet G1-G2 de l Ecole Centrale de Lille permet à des groupes d étudiants de se souder autour d un travail commun et de s organiser afin de minimiser le temps perdu. En outre, la multiplicité des domaines techniques d un même projet permet aux élèves ingénieurs d établir des liens concrets entre les différentes matières qui sont enseignées à l Ecole et de les approfondir afin de pouvoir les utiliser au sein du projet. S inscrivant dans cette formation, le projet RALF a pour but de concevoir un robot dont le design rappelle le logo Android qui pourra interagir facilement avec l utilisateur, lui fournira diverses informations se trouvant sur internet ou sur son téléphone et accessoirement le divertira. Ce robot serait donc un intermédiaire, voire un filtre programmable entre le flux d information se trouvant sur internet et l utilisateur qui pourra recevoir les informations essentielles grâce au robot. Nous allons dans ce dossier expliquer le travail accompli pendant les deux années du projet, et montrer les aboutissements de ce travail, avec bien entendu les difficultés et les obstacles que nous avons surmontés, et les différents succès qui ont récompensé notre acharnement. Bien entendu, comme le projet ne s arrête pas lors de la soutenance, nous aborderons aussi la possibilité d industrialisation de notre robot ainsi que le transfert de compétence, qui consiste à aider les futurs projets en leur donnant des tutoriels ou des ressources que nous avons durement acquis lors de notre projet. Enfin, pour mesurer l impact qu a eu le projet sur chacun des membres, nous inclurons dans ce dossier de Post-Evaluation des retours d expériences à la fois collectif, pour montrer comment l ensemble du groupe a vécu le projet et l apport que celui-ci a eu pour tous les membres. Mais aussi un retour d expérience individuel, qui permettra à chacun des membres de s exprimer sur ce que le projet leur a appris sur eux-mêmes, notamment sur leurs personnalités et comment s améliorer lors qu un travail en équipe. Page 9/173 Partie 0

Première partie Organisation et technique dans le projet 1.1 Mise en place du projet Cette partie résume la formation ainsi que l organisation qui a été amenée à être faite. De plus amples détails peuvent être trouvés dans nos anciens dossiers, notamment dans le rapport d avancement S6. 1.1.1 Naissance du projet Ce projet a été lancé dans la bourse aux projets par M. Thomas Bourdeaud huy. Son idée de base a été de concevoir un robot intelligent et interactif avec l être humain. Le but original était donc de créer le robot social idéal, compagnon parfait des amateurs de nouvelles technologies. Le groupe projet surnomme affectueusement le robot RALF. Il s agit de son surnom mais cela correspond aussi au nom du projet : Robot Android Ludique et Fonctionnel. 1.1.2 Définition et organisation du projet 1.1.2.1 Définition du projet Les fonctionnalités voulues pour RALF ont beaucoup évolué au fil du projet. Il pouvait s agir de contraintes techniques ou bien temporelles (devant les échéances certaines fonctionnalités jugées inutiles ont été abandonnées). Voici l idée de départ autour ce ce projet : Figure 1: Robot en 3D Page 10/173 Partie 1

Fonctionnalité Lire les sms et les mails à voix haute Flux RSS (météo, infos... ) Commande à distance par la voix Vidéo conférence avec suivi de mouvement Autonomie par rapport au réseau Reconnaissance de puces NFC Caméra de «surveillance» avec voyant de sécurité Vidéo conférence 3D et jeux 3D Enregistrement de mémos Connexion à une télé Projection Affichage laser de l heure Lumière et mouvement lors d une action Servir de télécommande Ecouter de la musique Composant ou contrainte Haut-parleur Synthèse vocale Connexion à internet Connexion au téléphone Connexion internet Synthèse vocale Micro Reconnaissance vocale Caméra Rotation de la tête Serveur local Antenne NFC LEDS Caméra Caméra 3D Micro Reconnaissance vocale Port HDMI Vidéo-projecteur Projecteur laser LED Mouvement des bras Bouton Connexion au téléphone Connexion à internet Haut-parleur Il s agit là de la liste non-exhaustive des fonctions que le robot devait être capable de réaliser pour correspondre à l idée initiale, de notre point de vue. Le robot, à la fin de ce projet, est équipé de leds, d un micro, d une caméra, d un haut parleur, ainsi que de bras et d une tête motorisée. Il comporte donc les composants principaux qui pourraient permettre une continuation du projet au niveau logiciel presque infinie. L ouverture du projet à la communauté est d ailleurs quelque chose qui nous tient à coeur depuis le début. 1.1.2.2 Organisation du projet Une des particularités de notre projet est son caractère complet. On trouve en effet de quoi faire dans plusieurs domaines si on veut le mener à bien. C est pourquoi il a été décidé de séparer l équipe en 4 pôles : Pôle Mécanique Pôle Automatique (composé de membres du pôle mécanique) Pôle Electronique Pôle Informatique Page 11/173 Partie 1

1.2 Partie Mécanique Après avoir pris possession du projet et décidé des fonctionnalités que notre robot aurait, nous avons pu commencer les parties techniques à proprement parlé. Nous fabriquons un robot social, et avons décidé qu il devrait bouger la tête et les bras. Nous avons donc rapidement formé un pôle mécanique, qui allait s occuper jusqu à la fin du projet de la conception physique du robot. Il était dès le début destiné à travailler en étroite collaboration avec les autres pôles, car l intégration des composants ou encore des mouvements est une phase complexe et importante qui lie des domaines très différents. C est pourquoi 3 membres du groupe projet ont intégré le pôle mécanique : Florence, Guillaume et Stéphane. Au début, les solutions techniques ont été abordées et réfléchies à trois. Lorsque cette partie théorique fut finie, le pôle s est divisé le travail : Florence s est consacrée à la modélisation du robot sous CATIA, pendant que Stéphane et Guillaume ont changé temporairement de pôle pour faire l automatique. Le pôle se retrouvait tout de même pour toutes les décisions importantes lors de réunions régulières. Lorsque la fabrication commença, Guillaume laissa Stéphane finir la partie automatique pour aider Florence au labo mécanique. Ici se trouvent les étapes de la partie mécanique, les détails techniques sont présentés dans les annexes. Il faut préciser que la conception du robot sous CATIA est la partie la plus importante en terme de temps, car elle représente une petite centaine d heures de travail. La fabrication en représente une trentaine. 1.2.1 Planification Nous avons tout d abord réfléchi à toutes les étapes que nécessite la construction d un robot. Nous avons rassemblé toutes ces étapes par lots, puis fait un GANTT avec ces différents lots. Figure 2: Tableau partie mécanique Page 12/173 Partie 1

Figure 3: Organisation du pôle mécanique Aujourd hui, nous nous rendons compte que cette planification était très optimiste. Nous avons rapidement pris du retard sur ce planning et avons revu les délais prévus pour chaque lot. Nous avons donc refait plusieurs plannings au fur et à mesure de l avancement du projet (voir partie Gestion de projet : Planification). 1.2.2 Recherche de solutions techniques Avant de se lancer dans la conception en tant que telle, une longue phase de recherche de solutions a été nécessaire. Nous n avions que le budget attribué par l Ecole, nous ne pouvions donc pas nous permettre de commencer à fabriquer quelque chose dont nous n étions pas sûrs à 100% de la réussite. Nous avions une idée de la taille approximative du robot, et avons donc commencé à étudier les différents aspects techniques, d un point de vue mécanique, de notre prototype. 1.2.2.1 Fabrication du corps Nous avons la chance d être dans une Ecole équipée avec les dernières technologies dans le domaine du prototypage rapide. Nous pensions donc imprimer entièrement le robot grâce à l une des imprimantes 3D présentes dans le laboratoire de prototypage rapide de l école. Cela aurait été nettement plus rapide au niveau de la conception et de l assemblage du robot. Figure 4: Imprimante 3D Mais cela nous aurait aussi coûté extrêmement cher (coût estimé : 600 euros). Or nous n avions que 300 euros en tout pour notre robot. C est pourquoi après discussion avec le groupe, nous avons décidé d imprimer que certaines pièces à l imprimante 3D. Il s agit de pièces dont la forme n est pas trouvable facilement dans le commerce : les bras. Le reste du robot a été fabriqué avec des pièces de format standard, usinées par nos soins. Il nous a fallu attendre que les composants électroniques soient dimensionnés pour commencer à chercher quelles pièces commander exactement. Page 13/173 Partie 1

1.2.2.2 Mouvement des bras Pour la motorisation des bras comme pour la plupart des questions de mécanique, nous nous sommes adressés à Philippe Quaegebeur pour nous conseiller. Nous avons fait quelques réunions avec lui lors desquelles les idées fusaient allègrement, puis étaient étudiées au cas par cas pour aboutir à un choix. C est comme cela que nous avons décidé que nous utiliserions un seul moteur pour les deux bras, et des engrenages en plastique organisés comme ci-dessous (pour les détails de la recherche de solution, voir annexe Solution bras) : Figure 5: Imprimante 3D 1.2.2.3 Mouvement de la tête La principale difficulté de la motorisation de la tête est due au fait que le mouvement doit être précis. Nous voulons qu un utilisateur puisse être suivi par la caméra lorsqu il bouge dans la pièce. Cela nécessite de la précision dans le mouvement et dans la réponse du moteur (Voir partie Automatique). Nous avons donc dû nous tourner vers des engrenages et couronnes à module plutôt petits (0,8) pour augmenter la précision du mouvement. Ces engrenages coûtent plus chers que des engrenages de module 1, plus courant. Nous avons donc dans un deuxième temps cherché du côté de solutions extravagante pour baisser le prix, comme un HarmonicDrive. Un Harmonic Drive est un système de réduction à engrenage très particulier. Il est composé de deux engrenages l un dans l autre, un à denture extérieure et l autre à denture intérieure. Ce premier a deux dents en moins par rapport au second et est déformable. Au milieu de ces deux engrenages se trouve un moyeu elliptique, qui en tournant va déformer l engrenage à dents extérieures en tournant. Cela permet un jeu nul et donc une précison extrèmement élevée. Voir : http ://www.harmonicdrive.de/french/funktionsprinzip/funktionsprinzip-film.html Page 14/173 Partie 1

Figure 6: HarmonicDrive Mais la recherche s est révélée infructueuse pour la baisse du prix. Nous avons donc utilisé des engrenages de module 0,8. Pour plus de détails sur la recherche de solution pour la tête : voir l annexe Solution Tête. 1.2.2.4 Agencement des composants à l intérieur du robot Pour lui permettre d avoir toutes les fonctionnalités que nous avons prévues, le robot va contenir un certain nombre de composants. Ceux-ci vont devoir s agencer les uns avec les autres dans un espace très restreint qu est l intérieur du corps du robot. Nous avons donc dû penser très tôt à comment fixer les composants entres eux, de manière à ce qu ils ne bougent pas lorsque le robot est en fonction, mais que nous puissions les atteindre une fois le robot ouvert pour pouvoir les régler à tout moment. Très vite, l idée que l on pourrait appeler du «bocal à cornichon» a émergée. Le principe est d avoir un axe central solidaire d une plaque, et les composants seraient tous fixés autours de cet axe et sur cette plaque. Ceux-ci pourront être soulevés par le haut de l axe, comme dans un bocal à cornichon, et nous pourrons ainsi accéder aux composants. 1.2.3 Conception sous CATIA Pour voir une idée précise de ce qui doit être usiné, conçu, assemblé, l étape indispensable de toute conception mécanique est sa modélisation sous un logiciel de Conception Assistée par Ordinateur (CAO). Celui que nous apprenons à prendre en main à l école est CATIA, logiciel de CAO de Dassault Industry. La modélisation du robot est essentielle pour pouvoir déterminer l agencement des composants entre eux, et donc déterminer la taille du robot, mais aussi avoir des plans précis des différentes pièces à fabriquer à l atelier. Cette modélisation s organise en plusieurs étapes : 1.2.3.1 Modélisation des composants Il faut commencer par modéliser sous CATIA tous les composants que le robot va contenir. La précision, à ce stade, n est pas indispensable : le but est d avoir un encombrement maximal pour chacune des pièces qui composent RALF pour ne pas se retrouver coincé le jour de l assemblage. 1.2.3.2 Organisation interne du robot Il faut ensuite créer un assemblage, qui va réunir tous les composants, en différents sous-ensembles, permettant d agencer les composants les uns par rapport aux autres. C est à ce moment-là que l on peut connaître les dimensions minimales du robot et de peut-être se rendre compte qu une solution technique choisie est en fait impossible à cause de la place disponible. C est également à ce stade que l on se rend compte de la complexité de la robotique. De nombreux problèmes qui étaient jusqu à présent passés inaperçus se présentent à nous au fur et à mesure de l assemblage, et nous devons les résoudre pour pouvoir avancer. Page 15/173 Partie 1

Figure 7: Intérieur de RALF Figure 8: Intérieur de RALF 1.2.3.3 Réalisation de la coque du robot Maintenant que nous connaissons la taille du robot et que nous avons une idée précise de ce à quoi il va ressembler, les choses sont beaucoup plus claires et nous pouvons réfléchir de manière précise aux pièces qui vont composer la coque du robot. En effet, étant donné que nous avons décidé de réaliser cette coque nous même et non à l imprimante 3D, nous devons être sûrs de ce que nous fabriquons. Nous n avons qu un budget très restreint, et nous ne pouvons nous permettre de commander plusieurs fois certaines pièces. Page 16/173 Partie 1

Figure 9: Vue extérieure de RALF Comme cela a déjà été évoqué plus haut, les bras du robot ont été imprimés à l imprimante 3D. Il a donc fallu les concevoir sous CATIA de manière précise. Nous pouvions les créer de A à Z, nous en avons donc profité pour les faire de la forme exacte qui nous arrangeait. Figure 10: Les bras du robot Pour la conception des bras, voir Annexe Tutoriel de la conception des bras de RALF. 1.2.4 Commande des composants de la coque du robot Après avoir modélisé le robot sous CATIA, nous avons pu commencer à chercher quels composants de base utiliser pour fabriquer la coque du robot. Les recherches se sont faites sur internet, et ont mené à la commande de pièces chez 4 fournisseurs. La plus grande partie du budget est partie dans les engrenages, et particulièrement la couronne de la tête car il s agit d une pièce de qualité pour que le mouvement soit contrôlé au mieux. La gestion et les procédures concernant les commandes sont évoquées dans la partie concernant le budget. Page 17/173 Partie 1

1.2.5 Fabrication à l atelier mécanique Nous arrivons à la phase la plus délicate de la partie mécanique. Les pièces designées sous CATIA vont être fabriquées grâce aux composants commandés. En cas d erreur de fabrication ou d incompatibilité non prévue par la modélisation, les pièces doivent être réfléchies à nouveau et refaites avec de nouveaux composants, ce qui peut coûter très cher. Toute la précision du travail effectué auparavant va être testée lors de cette phase. C est également à ce stade que l on découvre une nouvelle série de problèmes auxquels nous n avions pas pensé précédemment. Il s agit souvent d étapes de fabrication qui semblent faciles à première vue, mais qui vont en fait s avérer faire appel à toute l imagination des professeurs de mécanique pour que l opération puisse être effectuée. La raison est principalement que le laboratoire de mécanique n est pas fait pour travailler avec du plastique mais de l acier. Figure 11: La fabrication Pour plus de détails concernant la fabrication (ordre, problèmes rencontrés, etc) voir l annexe Fabrication. Page 18/173 Partie 1

DPE 1.2.6 Intégration des composants électroniques Une fois la coque du robot fabriquée, il nous a fallu intégrer les composants électroniques à l intérieur du robot. Nous les avons fixés à l axe central grâce aux trous prévus à cet effet. Le robot était ainsi prêt à être testé. Figure 12: RALF vers la fin du projet Figure 13: RALF vers la fin du projet Page 19/173 Partie 1

1.3 Partie Automatique 1.3.1 Introduction Dans le cadre de notre projet Android, nous avons été confrontés à l asservissement d un moteur dont nous n avions pas les caractéristiques. Nous allons montrer dans ce document comment nous avons réussi à établir les constantes principales du moteur, puis la mise en place du modèle de notre asservissement, enfin la modélisation de celui-ci sous MatLab. 1.3.2 Précision Cette partie a été volontairement vulgarisée, en effet nous avons supprimé une partie des explications pour arriver directement au résultat afin de ne pas alourdir le texte et le rendre le plus accessible possible. Vous pouvez trouver en annexe cette partie non vulgarisée si vous souhaitez connaitre l ensemble du raisonnement et des calculs. 1.3.3 Présentation du problème Notre robot Android doit pouvoir suivre l utilisateur avec sa tête, cela signifie une reconnaissance de l utilisateur grâce à la caméra. De plus, le moteur chargé de faire tourner la tête sera asservi, afin que le centre de la tête soit orienté vers l utilisateur et que celui-ci ne sorte pas du champ de vision du robot. Par souci budgétaire, ce moteur a été récupéré d un autre système, mais semble pouvoir convenir à notre problème 1.3.4 Cahier des charges Tout d abord il s agit de poser le problème. C est pourquoi nous aborderons dans un premier temps le cahier des charges qui nous étaient imposées. La consigne sera échantillonnée de manière non négligeable, avec un retard conséquent (300ms a priori) Le moteur est alimenté sous +/-5V Adapter le moteur au système Avoir une précision de 10 Avoir un temps de réponse de 2 secondes 1.3.5 Présentation du problème Voici de manière simpliste le système et une brève explication : Figure 14: Modélisation du système La caméra nous fournit l information sur la position de l utilisateur, celle-ci est transmise au microprocesseur (un RaspBerryPi) qui analyse cette information et envoie une consigne au moteur par le biais d un pont H (qui permet de contrôler le sens de rotation du moteur). La vitesse du moteur est recueillie par un capteur optique grâce à deux roues codeuses, cette information est envoyée au RaspBerryPi qui l analyse. Page 20/173 Partie 1

Maintenant que nous avons brièvement présenté notre objectif, nous allons rentrer plus dans les détails et expliquer notre démarche de manière didactique, afin qu une personne voulant asservir un moteur aux caractéristiques inconnues puisse le faire en se basant sur notre expérience. 1.3.6 Modélisation du moteur Dans un premier temps, il convient de modéliser le moteur. Figure 15: Voici le schéma électrique équivalent classique d un moteur à courant continu. En utilisant les deux types d équation classique pour modéliser un moteur on obtient : Figure 16: Nous obtenons ainsi la vitesse de rotation du moteur en fonction de l entrée (U a (p)) et du couple résistant généré par la charge(c r (p)). Maintenant que le moteur est modélisé grâce à l équation précédente, cela va nous permettre de déterminer les caractéristiques de notre moteur. 1.3.7 Caractérisation du moteur Afin de connaitre parfaitement le fonctionnement du moteur, il nous faut déterminer les différentes inconnues de l équation : R a, L a, J eq,k Détermination de la constante électromagnétique k Pour déterminer cette grandeur, on se place en régime permanent et on fait fonctionner le moteur sans charge mécanique. Ainsi C r (p)=0 et p=0 Donc il nous reste uniquement : Figure 17: Ainsi, il est aisé de connaitre k, il suffit d alimenter le moteur sous 5 volts, sans charge mécanique et en régime permanent et de relever la vitesse de rotation du moteur, ce qu on a fait grâce à un tachymètre. Page 21/173 Partie 1

Nous obtenons pour une tension d alimentation de 5 volts une vitesse de rotation de 1489 tr/min, soit 248 rad/s. On trouve ainsi k = 0.032 V.s /rad Détermination de R a On veut désormais connaitre la résistance interne du moteur. Pour cela, on va alimenter le moteur et bloquer la rotation du moteur et placer en série du moteur une résistance R2, on obtient ainsi grâce à l équation k (t)=e m que la force contre-électromotrice est nulle. Il suffit donc juste d utiliser un ohmmètre pour déterminer R a. On obtient ainsi R a = 22Ω. Détermination de L a Une fois R a déterminé, nous pouvons mesurer l inductance du moteur. Pour cela, on branche en série avec le générateur et le moteur une résistance R 1 de 67Ω. Nous avons donc le circuit suivant : Figure 18: Circuit pour déterminer Ra On va mesurer à l aide d un oscilloscope la tension aux bornes de la résistance R 1. On obtient ce genre de courbe lorsque l on allume le générateur, avec τ = R a /L a : Figure 19: Evolution de la tension Il s agit donc d évaluer sur l oscilloscope au bout de combien de temps on atteint la valeur finale de la tension, pour récupérer le temps de montée 3 de la tension aux bornes de la résistance et ainsi obtenir τ etl a. En faisant la moyenne de plusieurs mesures on obtient : L a = 19mH Page 22/173 Partie 1

Détermination de J eq Nous allons maintenant chercher le moment d inertie de l ensemble d éléments qui forme la tête, je vais par la suite me référer à l image ci-dessous pour expliquer les approximations que nous allons effectuer Figure 20: Vue globale du robot Comme vous pouvez le constater, de nombreux élément logent dans la tête. Il est donc délicat de calculer de manière exacte le moment d inertie équivalent de l ensemble de la tête, nous avons donc dû procéder par approximation. Nous avons effectué des approximations (expliquées dans la partie annexe) afin d évaluer le moment d inertie de chaque pièce de la tête, pour ensuite les sommer. On obtient au final J eq = 2.74Ö10 4 kg.m 2 1.3.8 Modélisation et simulation sous MatLab MatLab est un logiciel permettant de voir la réponse de systèmes complexes selon l entrée que l on choisit. Ici nous regardons le déplacement de la tête suite à celui de l utilisateur Tout d abord voici la modélisation de la caméra et du traitement d image sous MatLab : Nous avons donc deux entrées : la position angulaire de l utilisateur et la position angulaire de la tête, on effectue la différence entre ces deux positions pour l angle que la tête doit faire pour pouvoir fixer l utilisateur. Dès lors il faut prendre de compte deux phénomènes que nous avons modélisé avec les deux blocs «Zero-Order Hold» et «Delay». Le premier bloc permet d échantillonner le résultat, comme il le sera dans notre système réel, et le deuxième rajoute un délai. L échantillonnage du signal et le délai sont générés à cause du temps de calcul nécessaire à l analyse de la vidéo. Nous allons décomposer l asservissement du système en deux parties : une partie discrète et une partie continue. La partie discrète fournira une consigne de vitesse à partir des informations délivrées Page 23/173 Partie 1

Figure 21: Modélisation de la caméra et du traitement d image Figure 22: Présentation de l entrée par la caméra, et la partie continue consiste en un simple asservissement de vitesse du moteur pour suivre cette consigne. Nous ne tiendrons pas compte dans cette étude du couple résistant. Partie continue Pour mémoire, voici la fonction de transfert du moteur : Figure 23: On constate que le terme d ordre 2 est négligeable devant les autres, pour ce calcul on considèrera donc le moteur comme un système du premier ordre, de fonction de transfert : Figure 24: Page 24/173 Partie 1

On remarque que la constante de temps est trop élevée par rapport au temps de réponse désiré. Nous allons donc asservir le système à l aide d un correcteur PI pour le rendre plus rapide tout en assurant sa précision. Figure 25: Asservissement avec un correcteur PI On aimerait que le comportement du système asservi soit dix fois plus rapide. Pour cela, on va placer pour ce système d ordre 2 un pôle double égal au pôle du système simple multiplié par 10. On obtient : Figure 26: Ce modèle n est pas suffisamment représentatif. En effet, la tension d alimentation du moteur est limitée par la tension d alimentation du robot (5V). Il est donc impossible de commander le moteur au-delà de +/-5V. Le système devient : Et voici la réponse indicielle : Figure 27: Schéma avec saturation Figure 28: Réponse indicielle Le système est plus lent que prévu, mais ne pourra en aucun cas aller plus rapidement. La vitesse du moteur est limitée, et l accélération ne peut dépasser la valeur qu elle a en boucle ouverte. Page 25/173 Partie 1

Partie discrète Le système complet peut maintenant être modélisé ainsi : Figure 29: Schéma du système complet Pour permettre de donner des résultats satisfaisants, nous allons implanter l équivalent discret d un correcteur PD en sortie De plus, pour éviter les problèmes de saturation liés à l asservissement de vitesse, nous allons limiter la commande à 90 pour cent de la vitesse maximale atteignable par le moteur (saturation logicielle) Voici donc le système asservi complet : Figure 30: Système asservi complet Page 26/173 Partie 1

Nous avons testé ce modèle dans deux cas, voici les courbes que l on obtient Figure 31: Réponse à une rampe Figure 32: Réponse à une sinusoïde En Jaune, la position de l utilisateur, en violet, la position de la tête du robot, et en bleu l information délivrée par la caméra. On remarque que le système suit la position de l utilisateur, tout en conservant le retard causé par le traitement de l image. Dans le cas de la consigne en rampe, on pourrait «rattraper» ce retard en ajoutant une composante intégrale, mais cette dernière ne fait qu ajouter des écarts avec la consigne en rampe. De plus, comme le système est facilement sujet à des saturations, rajouter une composante intégrale pourrait le rendre instable. 1.3.9 Conclusion Après avoir déterminer les caractéristiques du moteur, nous avons abouti à un asservissement correct, répondant au cahier des charges et permettant la mobilité de la tête de notre robot. La seule chose qu il nous reste à faire est de faire des tests sur le modèle réal afin de vérifier si la théorie et les approximations sont vérifiés, mais pour cela il nous faut le robot complètement monté. Page 27/173 Partie 1

1.4 Pôle Electronique 1.4.1 Introduction La partie électronique était au début gérée par tout le groupe projet. Mais vu la quantité de travail qui devait être allouée a cette partie, il était plus approprié de la confier à une seule personne. Je m en suis donc chargé (Ahmed). 1.4.2 Démarche La première étape dans cette partie était d identifier les composants ou les fonctionnalités nécessitant la fabrication d une carte électronique bien déterminée. Nous avons ainsi examiné toutes les fonctionnalités du robot une par une pour identifier les ressources matérielles nécessaires. L identification de chaque fonctionnalité a été suivie d une revue de toutes les solutions déjà existantes ou dans le cas contraire techniquement réalisables, c est-à-dire des solutions qui ont été commercialisées et que nous pouvons intégrer directement dans le robot ou des solutions techniques que nous pouvons développer nous même et que nous avons la possibilité de réaliser sous les contraintes du matériel disponible à l école centrale. 1.4.3 Problématiques Emission sonore : Parmi les fonctionnalités du robot, la communication auditive avec l utilisateur est une des plus importantes puisque elle constitue le moyen prépondérant de la signalisation d état et de la communication d information du robot à l utilisateur. En rajoutant à ceci la possibilité de lecture de musique, il devient indispensable de doter notre robot d une sortie audio d assez bonne qualité capable de pourvoir convenablement à ces deux fonctionnalités. Il se trouve malheureusement que la sortie audio propre du Rasberry pi est de mauvaise qualité. Enregistrement sonore : le robot RALF est essentiellement commandé par les paroles de l utilisateur. Il devient donc nécessaire de l équiper d une entrée audio apte à enregistrer un son qui soit facilement reconnaissable par le logiciel de reconnaissance de voix utilisé par le pôle informatique (en l occurrence le service Google de reconnaissance de parole). Signalisation lumineuse : Afin de rendre le robot plus interactif, nous avons pensé à rajouter des signalisations lumineuses qui pourront indiquer l état actuel du robot (écoute, connexion à internet,... ) ou servir à faire simplement une animation lumineuse. Nous avons jugé ainsi intéressant d utiliser les yeux du robot comme sources lumineuses assurant cette fonctionnalité. Bouton d interaction : A fin d assurer des fonctionnalités comme la mise en tension/hors tension ou activer la commande vocale, on a pensé à rajouter un bouton qui pourra assurer cette fonction. Commander un moteur : Afin de réaliser la fonctionnalité de suivi de personne lors de la conférence vidéo, la tête sera montée sur un moteur qui va lui permettre de tourner et suivre la direction de la personne qui parle. Nous avons donc besoin de commander le moteur et de l asservir pour suivre au mieux la personne. Page 28/173 Partie 1

1.4.4 Entrée audio 1ere solution : Nous pourrons utiliser un micro avec une entrée USB parmi ceux commercialisés sur le marché. Pour cela il faudrait envisager de vérifier la compatibilité avec le système d exploitation utilisé sur le Rasberry PI, éventuellement installer les drivers nécessaires. On pourra ainsi enlever le plastique et n utiliser que le micro et le circuit qui vient avec. Figure 33: Micro avec connexion usb 2eme solution : Utiliser un composant électret (une sorte de condensateur avec membrane mouvante qui délivre un signal électrique de tension proportionnel à l amplitude de l onde sonore). Le signal étant très faible, il va falloir penser à l amplifier avec des étages de pré-amplification. Finalement, pour récupérer le signal sur le rasberry Pi, il faut convertir le signal analogique en un signal numérique pour pouvoir le récupérer sur les entrées GPIO du rasberry Pi et implanter un pilote qui pourrait assurer la compréhension du signal récupéré et le convertir en un fichier audio. On pourrait utiliser pour ceci un convertisseur analogique numérique. Il faudrait faire attention aux taux d échantillonnages du convertisseur pour qu il ne soit pas plus rapide que celle des entrées GPIO du rasberry Pi. Il faudrait aussi penser au nombre de ports GPIO à utiliser, ce qui va fixer la résolution du signal numérique récupéré, c est-à-dire que plus on utilisera de ports GPIO plus on aura de résolution sur les niveaux de tension récupérés (Pour 4 ports on pourrait récupérer un signal sur 2 4 = 32 niveaux de signal (bit)). On pourrait faire passer un échantillonnage sur 2 cycles ce qui donnerait un signal numérisé sur 64 bits. Mais cela risquerait de compliquer énormément à la fois le coté logiciel et matériel). 3eme solution : Utiliser la même technique d entrée que celle de la deuxième solution, c est-à-dire un micro électret mais équiper le système d une carte son USB qui permettrait de récupérer directement le signal analogique et effectuer tout le traitement nécessaire pour produire directement un fichier son exploitable par le système d exploitation du rasberry Pi. La carte son serait également exploitable en sortie puisqu on a déjà mentionné la médiocrité de la sortie principale du raspberry pi. Figure 34: Carte son usb Page 29/173 Partie 1

Pour des raisons de simplicité, de coût, et parce que cette solution est profitable à l entrée comme à la sortie audio, nous avons opté pour la troisième proposition. Pour concrétiser cette solution, on a commencé par modéliser un circuit assez simple capable d exploiter le composant électret. Le circuit est sur la figure à côté. En effet le composant électret contient un condensateur sensible à une onde sonore ainsi qu un transistor qui amplifie le signal récupéré aux bornes du condensateur qui est très faible. Il a donc fallu polariser le transistor et l alimenter, ce qui a été assuré sur ce schéma par la résistance de 4k et la tension de +V dont la valeur est entre 2V et 10V. Figure 35: Schéma du montage du micro Page 30/173 Partie 1

Pour ne récupérer que la composante ondulatoire qui contient le signal proportionnel à l onde sonore, on a placé un condensateur à la sortie du micro pour effectuer un filtrage haute fréquence qui éliminera la composante continue du signal. Le choix de la valeur de la capacité était très important puisqu il a fallu faire attention lors du filtrage à garder les fréquences présentes dans le spectre du son perceptible par l homme. Ici, en l occurrence, on a effectué un filtre passe haut avec une constante de temps égale à R1 C1 = 10.34 10 3 s donc avec une fréquence de coupure légèrement inférieure à 100Hz : la plus basse fréquence perceptible par l homme. Malheureusement, nous n avons pas pu récupérer un signal lisible sur la sortie de ce montage, nous avons plutôt eu un signal très faible qui n était même pas visible sur l écran de l oscilloscope. Pour corriger ce défaut nous avons rajouté un étage d amplification très commun pour les entrés audio et qu on appelle conventionnellement étage de pré-amplification. Pour faire cela, on a tout simplement utilisé un AO (amplificateur opérationnel) en montage amplificateur, qu on a testé sur une plaque à trous au début pour vérifier son fonctionnement normal et le bon choix des valeurs des résistances et des capacités utilisées, à la fois pour le filtrage et pour l amplification. Figure 36: Montage du micro sur la table à trous Le schéma exact est fourni en document annexe et explique bien le circuit électronique utilisé. Pour bien tester le fonctionnement du circuit, nous avons récupéré la sortie telle qu elle est sur un pc. On a utilisé un potentiomètre pour le réglage de la valeur de l amplification. En effet, on voulait une amplification qui soit assez forte pour que le signal puisse être utilisable sans dépasser pour autant l alimentation de l amplificateur et donc éviter les problèmes liés à la saturation tel que la déformation du signal. Nous avons également essayé plusieurs valeurs de capacités pour le filtrage. On a noté que pour certaines valeurs, certains sons, plus précisément les graves, disparaissaient. En effet, les fréquences de coupures des filtres passe haut dans ces cas étaient très élevés, ce qui a conduit à la disparition des sons graves. Ainsi après plusieurs essais nous avons entamé la construction d une carte électronique qui allait assurer la fonction d acquisition de son. Page 31/173 Partie 1

Figure 37: Carte micro (face 1) Figure 38: Carte micro (face 2) 1.4.5 Sortie audio Avant de commencer à trouver les solutions technologiques pour la sortie audio, il a fallu tout d abord déterminer la puissance sonore (qui se quantifie en décibels) nécessaire à notre robot pour communiquer selon l entourage (le niveau sonore dans lequel il se trouve) et la distance par rapport à l utilisateur. Ainsi nous avons mené une étude, dont vous trouverez les résultats en annexe, qui nous a aidé à déterminer les caractéristiques nécessaires du haut parleur à utiliser, ceci en choisissant des hypothèses de distance limite et un niveau de bruit ambiant maximal autour du robot. Référence : http ://www.antibruit.org/echelle.htm Pour être plus concret, il nous a fallu un haut parleur qui peut délivrer une puissance sonore de 65dB pour un bureau, ce qui serait normalement l environnement quotidien du robot. La deuxième caractéristique à déterminer pour choisir un haut parleur, autre que la puissance, est la gamme de fréquence à balayer. En effet, le haut parleur se comporte comme un filtre pour les ondes sonores et ne produit qu une gamme de fréquences bien définie. Conventionnellement, il existe 3 types de hauts parleurs. Le premier est conçu pour produire les sons graves donc de basses fréquences(en général entre 30Hz et 3kHz). Le deuxième est conçu pour produire des ondes de moyennes fréquences(en général entre 400Hz et 15kHz) et le dernier est conçu pour des ondes de hautes fréquences (pouvant atteindre les 20kHz). Dans notre cas le deuxième nous convenait parfaitement puisqu il couvre la plage de fréquence de la parole de l humain qui nous intéresse, surtout que nous comptons faire de la vidéo conférence avec le robot et de le faire parler pour un retour d état ou d information. Page 32/173 Partie 1

Finalement, il a fallu faire attention à la puissance consommée par le haut parleur. En effet, les hauts parleurs consomment généralement énormément d énergie, ce qui nous a amené à prévoir l alimentation nécessaire pour celui-ci. Idéalement, il faudrait que le haut parleur ne dépasse pas les 2.5W de puissance délivrée par un port USB qu on pourrait utiliser pour alimenter le HP. En listant les différentes possibilités des hauts parleurs disponibles sur le marché (liste en documents annexe), et en se basant sur les caractéristiques techniques déjà étudiées, nous avons choisi le HP. Comme le haut parleur consomme nominalement 1W et au maximum 2W alors que la puissance délivrée par les sorties audio d une carte son ne dépasse généralement pas les 0.5W, même moins, il a été nécessaire d amplifier la puissance à la sortie de la carte son pour qu elle soit exploitable au niveau du haut parleur. Pour réaliser cette fonction d amplification, il a fallu explorer les différents types d amplification de puissance. En effet il existe plusieurs manières d amplifier un signal en puissance qui sont regroupées par les électriciens en différentes classes. Les plus connues sont les classes A, B et AB qui sont des amplificateurs linéaires pour lesquels le signal de sortie est en général parfaitement proportionnel à celui de l entrée, et l amplificateur de classe D qui a le comportement d un ondulateur. La classe A est la plus fiable en termes de reproduction du signal mais a le défaut d avoir un rendement en énergie très bas. En effet, on ne récupère à la sortie au maximal que le quart de la puissance apportée par l alimentation extérieure. Donc, nominalement, pour alimenter notre haut parleur de 1W, on aurait besoin de 4W au niveau de l alimentation. Nous n avons ainsi pas pu exploiter l alimentation des ports USB qui ne délivre que 2.5 W. Les classes B et AB présentent des défauts de fiabilité au niveau du signal de sortie car elles n exploitent pas tout le signal d entrée (Par exemple pour la classe B, on n amplifie que la moitié du signal) Elles présentent néanmoins un rendement plus confortable de 4/5. L amplificateur de classe D a l avantage d avoir des rendements assez élevés qui peuventt atteindre 95%, ce qui a motivé notre choix par la suite étant donné que ceci nous permettait d économiser la puissance pour l utiliser également dans les différentes cartes présentes sur le robot. Ainsi nous avons commandé un amplificateur de classe D en CMS. Comme il n était pas possible d essayer ce composant sur une plaque à trous puisqu il était de très petite taille, il a fallu construire directement la carte pour le porter. Vous trouverez en pièce jointe le circuit électronique associé à ce composant. Figure 39: Carte amplificateur audio 1.4.6 Signalisation lumineuse Comme il a été précédemment mentionné dans la problématique, le robot devrait pouvoir communiquer une partie de ses états avec des signalisations lumineuses. Ainsi pour assurer cette fonction, tout en restant esthétique, nous avons pensé à placer les sources lumineuses au niveau des yeux. Nous avons opté pour 3 couleurs qui nous ont semblé suffisantes et convenables. L étape suivante était de créer une carte pour porter les 6 LEDs : 3 pour chaque oeil. Pour commander les LEDs, nous avons utilisé les sorties GPIO du rasberry Pi. La question à se poser en premier était si l on pouvait alimenter les LEDs directement avec le courant délivré par les Page 33/173 Partie 1

ports GPIO, et si dans ce cas nous ne serions pas en train de surexploiter le raspberry pi (en prenant une valeur moyenne de 20mA pour chaque LED on aurait en total 6*20 = 120 ma si on allumait les 6 LEDs ensembles). Donc, pour éviter d exposer le rasberry pi à ce courant, nous avons fait un étage d amplification et nous avons utilisé l alimentation qui nous provenait d un port USB du HUB pour commander les LEDs. Ensuite, nous avons procédé à la construction de la carte qui contient toutes les LEDs ainsi que les étages d amplification associés que vous pouvez trouver en annexe. Figure 40: Carte Led Il a fallu respecter la distance entre les deux yeux du robot lors de la construction de la carte. C est pour cette raison qu on a l impression à première vue que la carte n est pas optimisée en surface. 1.4.7 Bouton Nous avons aussi essayé d équiper le robot d un bouton qui viendrait se fixer au milieu de la tête et qui servirait pour déclencher ou arrêter certaines commandes du robot. Le bouton est un simple interrupteur qui commande un port GPIO configuré en mode entrée. La carte est en fichier annexe. Figure 41: Carte bouton 1.4.8 Pont H Pour asservir le moteur de la tête en vitesse, nous avons eu besoin de faire varier la commande en tension entre ses bornes. La tension devait éventuellement être inversible entre ses bornes pour pouvoir le commander dans les deux sens. C est-à-dire il a fallu pouvoir appliquer une tension positive aux bornes du moteur pour qu il puisse tourner dans le sens horaire par exemple et une tension négative pour qu il puisse tourner dans le sens antihoraire. La variation de la tension aux bornes du moteur peut être réalisée à travers un hacheur tout simple. Ce montage fonctionne comme un interrupteur commandé par le rasberry Pi qui va laisser passer ou Page 34/173 Partie 1

bloquer le courant. Ce fonctionnement est réalisé en cycle et en fonction de la variation du rapport entre le temps pendant lequel on sollicite le hacheur et la période d un cycle, et pourrait donc nous donner des niveaux de tension différentes aux bornes du moteur. Pour réaliser la fonction d inversion de tension, nous avons utilisé un pont H qui n est autre que l association de 4 hacheurs qui vont être commandés par paire et, selon qu on commande une paire de hacheurs où l autre, nous aurons aux bornes du moteur une tension positive ou négative. Le moteur devrait être aussi inversible en courant car, lors de la fermeture de tous les interrupteurs, la bobine du moteur va générer une force électromotrice de contre réaction avec un courant opposé à celui qui la parcourait initialement. Pour évacuer cette intensité il a donc fallu penser à placer des diodes de roues libres. Cet artifice nous a permis de ne pas détruire à la fois le moteur et les hacheurs. Pour observer le schéma mis en place pour réaliser cette fonction, veuillez regarder les fichiers annexes. Figure 42: Carte pont H Page 35/173 Partie 1

1.4.9 Shield Afin de relier toutes les cartes au Raspberry Pi, nous pouvons soit souder directement tous les composants sur les broches de ce dernier, soit utiliser des connecteurs qui sont faits pour le Raspberry ou fabriquer un shield qui se superposera sur la carte Raspberry et se connectera à ses roches. Nous avons alors choisi cette dernière solution qui nous a permis de ramener l alimentation du HUB USB sur le shield afin de centraliser toutes les connections et essayer éventuellement de stabiliser l alimentation pour toutes les autres cartes. La carte associée est dans les fichiers annexes. Figure 43: Carte Shield (face 1) Figure 44: Carte Shield (face 2) Page 36/173 Partie 1

1.5 Pôle Informatique 1.5.1 Introduction La partie informatique constitue l une des grandes parties du projet RALF. Elle concerne le développement logiciel du robot et permet de faire fonctionner les différents appareils embarqués sur le dispositif de façon intelligente. Nous allons expliquer la théorie, le fonctionnement, et la mise en œuvre des différents éléments qui ont permis de rendre le robot fonctionnel. Notre démarche commencera par des considérations générales, elle sera suivie par des problématiques bas-niveau, pour aboutir progressivement au développement d applications de haut-niveau. Nous avons fait l effort expliquer au mieux notre travail dans ce rapport. Cependant, même si la majorité des éléments restent compréhensibles par un lecteur moyen, certains points nécessitent tout de même des connaissances de base en algorithmique et en systèmes basés Linux. Nous invitons donc les lecteurs souhaitant étudier en profondeur notre système à se renseigner sur ces notions avant de commencer. Page 37/173 Partie 1

1.5.2 Le système embarqué Dans cette première partie, nous allons introduire des notions de base sur notre robot. Nous allons également justifier nos choix en matière de système d exploitation et de microordinateur. Enfin nous allons présenter le fonctionnement général du robot. 1.5.2.1 Considérations sur le choix du Raspberry Pi et de ArchLinux Tout ce qui peut être réalisé en termes de fonctionnalités est lié entièrement au matériel utilisé. Cela constitue donc l une des considérations principales pour le projet RALF. Le monde d aujourd hui offre en effet un vaste choix de composants et de matériel pouvant traiter les données et contrôler une machine. Nous avons donc été amenés à décider avant tout de l environnement dans lequel allait tourner notre système. Le choix du Raspberry Pi : Le Raspberry Pi est apparu sur le marché peu après le début du projet. C est un micro-ordinateur avec une architecture ARM qui peut abriter un système d exploitation. Il est aussi équipé pour un branchement USB, un branchement de caméra vidéo, ainsi que des ports GPIO pour contrôler des circuits électroniques. Notre choix a donc très vite été dirigé par des qualités exceptionnelles du Raspberry : Le micro-ordinateur peut faire tourner un OS sans pertes de fonctionnalités par rapport à un ordinateur classique. Cela évite notamment une grande partie de considérations bas-niveau et permet d accéder à des fonctionnalités intéressantes et technologiquement évoluées. Le prix du Raspberry, qui se situe autour de 35-40 euros se trouve être très avantageux par rapports à d autres appareils, comme l Arduino, qui nécessite plus d investissement. L idée derrière ce concept est bien sûr de rendre le projet accessible à tous. Il est donc possible pour un utilisateur de s inspirer de notre projet pour faire un dispositif ayant des fonctionnalités différentes. Les branchements : parmi les fonctionnalités attendues de notre projet, nous avons relevé une grande multitude de branchements différents avec d autres appareils. En effet, certains d entre eux comme les diodes ou les moteurs doivent absolument être controlés par de simples circuits, alors que d autres, comme le wifi ou le son nécessitent un branchement par USB. Encore une fois, nous avions également besoin d une caméra pour notre projet. Le Raspberry fournit toutes ces branchements et répond donc parfaitement aux critères. Tous ces critères justifient donc le choix du Raspberry pour notre projet. Il reste cependant à considérer le choix du système d exploitation utilisé. Le choix de Arch Linux : Une fois en possession du micro-ordinateur, nous avons été confrontés à un choix difficile. Le choix d une base Linux était plutôt évident, car c est l un des seuls systèmes d exploitations accessibles et aboutis capables de fonctionner en ARM. Cependant, Linux offre un choix non négligeable de distributions, chacune ayant ses propres caractéristiques et particularités. Le critère principal était donc la consommation de ressources. En effet, la différence entre un système embarqué comme le Rasperry Pi et un système fixe est la différence de performances. Il est impossible d embarquer une puissance de calcul aussi grande dans un appareil de la taille du Raspberry. Nous étions obligés de compenser le manque de puissance par la légèreté du système d exploitation. Celui-ci devait contenir les fonctions de base seulement, tout paquet non nécessaire devait donc être Page 38/173 Partie 1

enlevé. En termes d OS, nous avons comparé les différentes possibilités. Voici les 3 solutions retenues : Raspbian : l OS recommandé par la fondation Raspberry Pi, fourni avec des programmes avancés, ainsi qu une interface graphique. Arch Linux ARM : Distribution ArchLinux portée sur le Raspberry, l installation des paquets est effectuée manuellement avec le gestionnaire de paquet. Contient de base un système complet mais avec un minimum de paquets installés pour lancer le Raspberry, gérer la connectivité, et gérer les processus. LFS (Linux From Scratch) : Projet permettant de créer sa propre distribution Linux en compilant l intégralité du système soi-même à partir des sources. Il permet notamment de créer des distributions personnalisées extrêmement légères et est donc bien adapté aux systèmes embarqués. Nous avons commencés par effectuer nos premiers tests sur Raspbian. Cette distribution fonctionne très bien mais elle possède un peu trop de programmes de base et ceux-ci consomment des ressources inutilement. De plus, cette distribution (comme Debian) a tendance a avoir des paquets assez vieux dans ses dépôts, ce qui oblige a compiler certains paquets lorsque l on a besoin de la dernière version. Ensuite, nos encadrants nous ont recommandé d explorer la piste de LFS afin de pouvoir créer un système minimal et afin de pouvoir bien contrôler les aspects bas niveau et les entrées / sorties du système. Ce processus s est cependant révélé assez fastidieux puisqu il fallait effectuer une compilation croisée de l intégralité des paquets. Or, n ayant pas beaucoup d expérience dans ce domaine, il nous était difficile de trouver d où venaient les nombreuses erreurs que nous obtenions et parfois nous avions du mal à trouver quel composant du système il nous manquait pour faire fonctionner une application. Finalement, comme nous n avions, de toute manière, pas besoin d aborder des considérations d aussi bas niveau, nous sommes parti sur une base Archlinux. Celle-ci nous permet d avoir une base stable, plutôt minimaliste, pratique à utiliser, et dotée d un gestionnaire de paquets permettant d installer facilement des versions récentes des paquets qui nous intéressaient. 1.5.2.2 Gestion des processus et fonctionnement général Le langage utilisé pour la programmation du robot est le Python, version 2.7. Lorsque le robot fonctionne, différents processus sont lancés en parallèle sur le système pour effectuer des tâches concrètes. Nous avons subdivisé ces processus en 2 catégories : Les processus de détection d évènements Les processus d actions La première catégorie prend en compte tous les programmes qui vont tourner en permanence sur le robot. Ceux-ci incluent la reconnaissance vocale, la caméra, et d autres tâches qui sont en charge de gérer la communication interprocessus. La seconde catégorie comprend tous les processus à durée limitée, qui ont pour but de traiter une tâche donnée une fois lancés, puis de se terminer. Ceux-ci incluent notamment la synthèse vocale, les programmes pour les scénarios (comme la météo, les mails etc..). La quantité de processus qui peuvent être lancés en même temps sur le Raspberry Pi étant limitée, nous ne lançons que 4 programmes en même temps : le contrôleur, le multiplexeur, la reconnaissance vocale et la reconnaissance vidéo. Cependant, d autres processus sont lancés au même moment sur le Raspberry Pi. Ce sont des processus système, comme le daemon DHCP, les processus de l OS, le daemon Wifi, le serveur de configuration et autres. Ces services étant nécessaires au fonctionnement du système, il faut les prendre en Page 39/173 Partie 1

compte dans l utilisation des ressources. Le principe de fonctionnement au niveau logiciel est décrit dans ce dia- Fonctionnement général gramme : Figure 45: Schéma de fonctionnement Le multiplexeur et le contrôleur constituent la partie centrale du robot. Ils permettent de rediriger les paquets des entrées vers les sorties, en lançant des instances différentes pour chaque tâche. Côté multiplexeur, une série de liaisons socket dédiées permet aux clients attachés aux services de détection, comme la reconnaissance vocale, de se connecter au serveur. Le contrôleur se connecte également à celui-ci qui l identifie comme étant le contrôleur. Ainsi, tous les paquets sont redirigés vers celui-ci après la connexion. Côté contrôleur, une détection de la tâche à effectuer est faite, afin de déterminer le programme à démarrer. Nous utilisons un dictionnaire prédéfini, ce qui permet de traiter du texte provenant de la reconnaissance vocale, ou bien des ordres précis envoyés par d autres programmes. Ensuite, la fonction correspondante est appelée, souvent celle-ci est suivie par le lancement du processus de synthèse vocale, qui permet de diffuser le résultat de la requête à l utilisateur. En conclusion, l architecture logicielle utilisée sur le RALF permet d implémenter facilement d autres tâches et de connecter rapidement d autres appareils et programmes à celui-ci. Page 40/173 Partie 1

1.5.3 Paquets et fonctions système 1.5.3.1 Installation des paquets et des dépendances Cette partie sera consacrée à l installation des differents paquets utilisés par le système, afin de pouvoir executer les tâches demandées. En effet, le choix du système d exploitation effectué auparavant ne permet pas de démarrer avec tous les prérequis, il faudra donc les installer manuellement. Nous allons décrire dans cette partie, les principaux paquets à installer afin de faire fonctionner le robot. Cette liste va être complétée au fur et à mesure de l implémentation des différents modules. Il est également possible d installer des outils de travail permettant de programmer directement sur le Raspberry Pi. Nous conseillons donc fortement de tout faire en utilisant la connexion ssh, donc de programmer et de tester les programmes sur le Raspberry directement. Il faut cependant faire attention à sauvegarder souvent les programmes sur un autre support, en les télechargeant par exemple. Une fois le système d exploitation ArchLinux installé, celui-ci démarre avec quelques services par défaut. Tout d abord, le daemon DHCP est déjà installé, ce qui permet au Raspberry de se connecter à un réseau via un câble Ethernet. Le système comporte également un serveur ssh (Secure Shell), ce qui permet à l utilisateur de s y connecter. Pour se connecter en SSH au Raspberry, il faut d abord trouver son adresse IP. Pour cela, il est possible de scanner le réseau en utilisant nmap (sous Linux). Cependant, lorsque le dispositif est branché à un routeur domestique, son adresse IP est assez simple à détérminer. Il suffit en effet de regarder la page de configuration du routeur dans le navigateur, ou encore de trouver l adresse en effectuant des ping sur le subnet 192.168.1.* Une fois l adresse détérminée, il est possible de s y connecter en utilisant un client SSH comme Putty, MobaXTerm ou XShell sous Windows, ou en tapant la commande ssh [adresse du Raspberry] dans la console sous MacOS ou Linux. Cependant, comme nous l avons précisé dans l introduction, nous ne pouvons pas fournir un tutoriel complet sur l utilisation de Linux. Nous allons donc nous contenter de donner des paquets nécessaires à installer. Voici la liste de ces paquets : Python 2. 7 : Interpréteur python, utilisé pour faire marcher tous les scripts python utilisés Wpa_supplicant : programme de connexion à un réseau wifi, utilisé dans la seconde partie de ce chapitre Alsa : gestionnaire audio utilisé pour la synthèse vocale notamment Pip easy_install pour python 2.7 : un port de pip sur ArchLinux permettant de faciliter l installation des librairies Python base-devel : Outils de base nécessaires pour compiler du code, utilisées pour les scripts de la caméra notamment. Il est également nécessaire d effectuer les branchements de la caméra et de la carte wifi, puis de faire un update/upgrade du système complet en utilisant la commande : pacman Syu. Cela permet de télecharger les pilotes de la caméra Raspberry Pi notamment, ce qui est une étape nécessaire pour la suite. Les programmes installés précédemment constitueront la base de notre système. Nous allons cependant y apporter des modifications en cours de route, car celles-ci concernent principalement les paquets python et non des paquets système. Dans la seconde partie, nous verrons un point essentiel au fonctionnement du robot, qui permet de Page 41/173 Partie 1

simplifier grandement la procédure de connexion : l installation du Wifi. 1.5.3.2 Mise en place de la connexion Wifi La connexion Internet est un aspect important du robot. Le fonctionnement entier de l appareil dépend de sa possibilité à accéder à Internet. Cependant, le robot reste un objet mobile, même s il est destiné à rester dans un habitat ou un lieu de travail. Dans cette partie, nous avons donc essayé de mettre en place un protocole permettant d effectuer une connexion par Wifi à un réseau connu automatiquement lors du démarrage du robot. (c est à dire la mise sous tension). Cette implémentation a été effectuée manuellement, en utilisant le strict minimum au niveau des gestionnaires. Cette approche permet alors de personnaliser la connexion, ou encore d ajouter simplement un gestionnaire permettant d automatiser plus encore la procédure. L approche globale de la connectivité : Même si notre approche n a pas abouti à l automatisation totale de la procédure de connexion, nous avons tout de même réussi à faire connecter le robot au démarrage à un point d accès Wifi connu et préconfiguré. Nous aimerions cependant expliquer la problématique derrière cette implémentation, ainsi que de faire part des différentes idées pour améliorer celle-ci. Voici tout d abord la procédure générale à suivre pour se connecter au Wifi : Le Raspberry Pi démarre, initialisant les différents pilotes nécessaires au fonctionnement du système. Parmi ces derniers, le pilote de la carte Wifi USB se voit lancé. A cet instant, l utilisateur n a pas encore la possibilité d utiliser ce système. Cependant, comme nous le verrons plus en détail, il lui est possible de programmer à l avance des tâches à executer au démarrage (on boot). Nous allons donc lui demander de scanner les réseaux Wifi disponibles à l aide de la carte Wifi. Une fois identifiés, ces réseaux auront des noms associés à eux : on les appelle les ESSID. (Extended Service Set IDentification). La terminologie est ici intéressante, car cette appellation fait entendre qu on se connecte à un AP (Access Point, ou encore Point d Accès). C est ce que l on retrouve dans la plupart des cas dans le cadre d un réseau domestique (un routeur ou un modem ADSL possèdent cette sorte de fonctionnalité). L étape précedente est importante, car nous allons utiliser cet ESSID, afin de faire connecter le robot au point d accès correspondant. Le problème d implémentation se trouve en effet à ce niveau là. En effet, le réseau de l utilisateur est protégé, et le robot ne possède pas les informations de connexion qui lui permetteraient de se connecter. Ainsi, celui-ci doit être configuré par l utilisateur préalablement. Il existe une multitude de façons de procéder. Voici une liste non exhaustive des solutions pouvant être mises en place : L utilisateur connecte le robot par un câble, ce qui permet au robot de se connecter sans pour autant devoir s identifier. Cette solution a le défaut de nécessiter une intervention physique de l utilisateur au coeur du robot, afin de brancher le câble. Le risque est bien évidemment un manque de confort et de practicité, ainsi qu un danger d endommager le robot lors de la manipulation. L utilisateur peut également utiliser d autres technologies pour configurer le robot : un badge NFC configuré avec une application sur un téléphone, ou encore une application utilisant le bluetooth seraient des solutions viables pour permettre ce déploiement. Enfin, l utilisateur pourrait utiliser la carte SD portable qui s insère dans le robot ou encore une clé USB, ainsi qu une application sur ordinateur pour configurer les différentes options, puis insérer la carte ou la clé USB dans celui-ci, démarrant ainsi une mise à jour qui configu- Page 42/173 Partie 1

rerait le Wifi. Comme nous pouvons le voir, les solutions sont nombreuses, cependant aucune ne semble être la solution parfaite qui conviendrait à tout utilisateur du robot. C est pourquoi, la mise en oeuvre de ces solutions ne sera pas détaillée dans cet article. La dernière étape dans l établissement d une connexion est le lancement d un daemon DHCP. Le robot, une fois connecté, peut en effet communiquer avec le routeur, cependant, il ne possède toujours pas d adresse IP, qui lui permetterait de transmettre des paquets à l extérieur. Le travail du DHCP consiste alors à demander une adresse au point d accès pour le robot ; une fois cette adresse récupérée, il est possible pour l appareil de communiquer avec Internet. Nous avons vu une approche théorique dans l établissement d une connexion Wifi, nous allors désormais nous intéresser au développement de notre solution. La conception de la solution : Pour commencer, je tiens à rappeler que notre robot fonctionne sous ArchLinux. La solution présentée ici est cependant transposable à d autres systèmes, elle nécessite tout de même un minimum de connaissances en matière de systèmes d exploitation Linux. Afin de déployer notre solution, nous aurons besoin de plusieurs paquets : wpa_supplicant, utilitaire de connexion à un réseau Wifi permettant d écrire manuellement la configuration de chaque réseau. Il est également possible de préciser certaines options au lancement du programme, comme par exemple le pilote à utiliser. dhcpcd, un daemon DHCP standard qui vient avec l installation d ArchLinux. Nous avons également eu recours à systemd, un daemon système qui permet de gérer les ressources et les différents processus qui tournent sur le système. Le daemon est disponible désormais par défaut dans pratiquement toutes les distributions Linux, il permet notamment de créer des services qui s éxecutent au démarrage selon certaines règles. Enfin, nous avons utilisé un script shell très simple pour lancer la série de processus. Pour cet exemple, nous allons faire deux implémentations différentes : l une se déroulera dans le cadre d un réseau domestique, utilisant un accès par WPA. L autre sera plutôt axée sur l implémentation dans un réseau d entreprise, lors d un accès WPA en utilisant le protocole EAP pour s identifier. Nous allons commencer par configurer la connexion en utilisant le protocole EAP. Pour cela il faut tout d abord créer un fichier de configuration dans le dossier /etc/wpa_supplicant. Nous allons l appeler "entreprise.conf". Voici le code à insérer dans ce fichier : network={ s s i d="nom_reseau" scan_ssid=1 key_mgmt=wpa EAP eap=peap i d e n t i t y=" I d e n t i f i a n t " password="mot de passe " phase1=" p e a p l a b e l=0" phase2=" auth=mschapv2" } Page 43/173 Partie 1

Il est évidemment nécessaire de remplacer le SSID du réseau, l identifiant et le mot de passe. L étape suivante est d utiliser la configuration nouvellement créée afin de la lancer dans un script. Nous allons donc créer un script en bash qui permettera de lancer les services nécessaires, et de se connecter au réseau. Voici le contenu de ce script (appelé entreprise.sh). #! / bin / bash wpa\ _supplicant B i wlan0 c / e t c /wpa\ _supplicant / e n t r e p r i s e. conf D wext dhcpcd wlan0 i f c o n f i g wlan0 grep " i n e t " mail s "RPI IP Address " mail@test. f r Dans ce script, nous demandons tout d abord à wpa_supplicant de se lancer en arrière plan avec l intérface réseau wlan0 et utilisant la configuration du fichier entreprise.conf, et en forçant le pilote à être wext. Ensuite, nous executons le daemon DHCP en précisant l interface réseau, dans notre cas wlan0. Enfin nous demandons d envoyer un mail à l utilisateur (l adresse est à remplacer), pour lui donner l adresse IP du robot, au cas où il voudrait s y connecter ou le configurer. La dernière étape est de configurer le gestionnaire de services (systemd) pour executer notre service. Nous allons donc créer un fichier dans le répertoire /etc/systemd/system qui s appelle wifientreprise.service. Dans ce fichier, nous écrirons les lignes suivantes : [ Unit ] D e s c r i p t i o n=i n i t i a l i s a t i o n du w i f i u t i l i s a n t EAP [ S e r v i c e ] ExecStart =[chemin v e r s e n t r e p r i s e. sh ] / e n t r e p r i s e. sh Type=f o r k i n g [ I n s t a l l ] WantedBy=multi user. t a r g e t Dans ce code, nous précisons le chemin d execution du service, ainsi que le type de service. Les services executés au demarrage sont par défaut fermés lorsque leur execution est terminée. Cependant, notre objectif est de laisser tourner le service afin de garder la connexion ouverte, c est pourquoi nous utilisons l option "forking". Cela va permettre au script de se lancer en tant que processus maître. Il suffit alors d activer le service précedent avec la commande suivante : s y s t e m c t l enable w i f i e n t r e p r i s e Le service se lancera donc au prochain démarrage. Nous allons donc maintenant répeter la configuration précedente pour l authentification en WPA Personnel. Voici le fichier de configuration wpa_supplicant (appelé maison.conf) : network={ s s i d="nom_reseau" scan_ssid=1 psk=" mot de passe reseau " } Page 44/173 Partie 1

Voici le script associé (appelé maison.sh) : #! / bin / bash wpa\ _supplicant B i wlan0 c / e t c /wpa\ _supplicant / maison. conf D wext dhcpcd wlan0 i f c o n f i g wlan0 grep " i n e t " mail s "RPI IP Address " mail@test. f r Et enfin, voici le service associé (appelé wifi-maison.service) : [ Unit ] D e s c r i p t i o n=i n i t i a l i s a t i o n du Wifi a l a maison [ S e r v i c e ] ExecStart=/root / w i f i maison. sh Type=f o r k i n g [ I n s t a l l ] WantedBy=multi user. t a r g e t En somme, la connexion Wifi nécessite beaucoup d efforts, mais est néanmoins très flexible et peut être facilement automatisée. Il est possible notamment d altérer ces configurations à l aide d unj programme qui se connecte par bluetooth au téléphone par exemple. Un tel scénario a été envisagé, mais n a pas pu être réalisé dans le cadre de ce projet. Page 45/173 Partie 1

1.5.4 Conception des fondements du système 1.5.4.1 L organisation du système de base Nous allons expliquer l organisation du système à partir du diagramme ci-dessous : Chaque bulle représente ici un processus séparé, sauf pour l entrée son, qui est combinée avec le traitement au sein d un même processus. En effet, un des avantages fournis par l utilisation d un système d exploitation est la parallélisassions des tâches. Le gestionnaire des tâches de ArchLinux, appelé systemd permet de gérer les différents services qui fonctionnent à un moment donné. Il est également possible de mettre fin à ces derniers à tout moment. La parallélisation quant à elle permet à plusieurs processus d accéder et d utiliser les ressources du système en même temps, ce qui se traduit à haut niveau par l exécution simultanée des tâches. Par exemple, RALF a la capacité de parler en même temps qu il enregistre l utilisateur et fait clignoter ses yeux. Notre but est donc de concevoir une série de programmes, qui seront exécutés de plusieurs façons, afin de rester à la fois vigilant au regard des entrées (ou inputs) de l utilisateur, et aussi de traiter les demandes de celui-ci et de lui envoyer des réponses en conséquence. Cela implique obligatoirement l exécution séparée de plusieurs processus. C est pourquoi nous avons choisi de mettre chaque fonction dans un programme différent, et de lancer ces programmes au démarrage pour ceux qui fonctionnent de manière permanente, ou bien d appeler les programmes qui vont effectuer une tâche, puis se fermer. L ensemble est donc un ensemble de scripts programmés en Python, dont certains seulement vont être exécutés, et qui permetteront de lancer les autres programmes pour effectuer des actions particulières. C est en effet au contrôleur de traiter les entrées qu il reçoit, de reconnaître des tâches à lancer, puis enfin d exécuter les fonctions correspondantes. En somme, cette organisation nous permet d ajouter facilement des fonctionnalités au robot. Lorsque la fonction concerne une détection, celle-ci sera liée au centre de communication, c est-à-dire le multiplexeur, qui sera traité dans une partie séparée. Au contraire, si la fonction en particulier concerne une action, celle-ci sera paramétrée dans le contrôleur, pour être exécutée lors d un événement spécifique. De même, les programmes externes peuvent être liés facilement au reste du système via le multiplexeur, et il est même possible de lier le robot à des processus lancés sur d autres machines du réseau. Nous avons abordé l organisation basique des programmes dans le système. Les parties qui suivent dans ce chapitre auront pour but d éclaircir le fonctionnement de chacune de ces entités. 1.5.4.2 Le multiplexeur Le multiplexeur est une partie fondamentale au niveau software. Les processus qui sont lancés sur le Raspberry Pi doivent pouvoir interagir entre eux. C est pourquoi une communication intelligente est nécessaire : c est le rôle du multiplexeur. Comme on le voit sur le schéma de fonctionnement géneral, le multiplexeur se trouve au centre du montage. Choix du procédé de communication La communication inter-process peut être gérée de plusieurs façons : on peut utiliser principalement les pipes, les websockets, les sockets Unix ou les sockets TCP. Nous avons fait le choix d utiliser des TCP pour plusieurs raisons : Python inclut des librairies permettant la gestion avancée de sockets TCP : socket et asyncore Dans cette optique de développement, il sera facile de connecter une machine externe au robot via le multiplexeur, et de la faire communiquer. Page 46/173 Partie 1

Figure 46: Schéma de fonctionnement Implémentation Nous avons utilisé une approche asynchrone pour le multiplexeur. Le programme est organisé en plusieurs parties : Un thread principal, qui permet d accepter et de gérer les nouvelles connexions Des threads secondaires, qui sont créés dès qu un processus se connecte au multiplexeur. Ce découpage permet de gérer plusieurs processus simultanément. En utilisant les librairies asynchore et socket de Python, il est possible d implémenter rapidement le multiplexeur : import asyncore import s o c k e t c l i e n t s = {} r e c e i v e r=none currentaddress=none c l a s s MainServerSocket ( asyncore. d i s p a t c h e r ) : def init ( s e l f, port ) : asyncore. d i s p a t c h e r. init ( s e l f ) s e l f. create_socket ( s o c k e t.af_inet, s o c k e t.sock_stream) s e l f. s e t s o c k o p t ( s o c k e t.sol_socket, s o c k e t.so_reuseaddr, 1) s e l f. bind ( (, port ) ) s e l f. l i s t e n ( 5 ) def handle_accept ( s e l f ) : g l o b a l currentaddress newsocket, address = s e l f. accept ( ) currentaddress=address c l i e n t s [ address ] = newsocket p r i n t " Connected from ", address SecondaryServerSocket ( newsocket ) La première étape est la création du thread principal. Celui-ci est initialisé au lancement du programme. Lorsqu un programme se connecte, il accepte la connexion, en créant ainsi un socket TCP, et l ajoute à la liste des clients. Il lance ensuite le thread secondaire pour gérer la connexion avec le programme. Page 47/173 Partie 1

c l a s s SecondaryServerSocket ( asyncore. d i s p a t c h e r ) : def handle_read ( s e l f ) : g l o b a l r e c e i v e r receiveddata = s e l f. recv (8192) i f receiveddata : i f r e c e i v e r==none : i f receiveddata==" c o n t r o l e u r " : r e c e i v e r=c l i e n t s [ currentaddress ] r e c e i v e r. send ( " c o n t r o l e u r _ i d e n t i f i e " ) i f r e c e i v e r!=none and receiveddata : r e c e i v e r. send ( receiveddata+ \n ) e l s e : s e l f. c l o s e ( ) def handle_close ( s e l f ) : p r i n t " Disconnected from ", s e l f. getpeername ( ) one = s e l f. getpeername ( ) d e l c l i e n t s [ one ] La deuxième étape est le lancement du thread secondaire, en charge de communiquer avec le programme. Celui-ci est en charge de recevoir des données. Il a pour fonction également d identifier le contrôleur, auquel il va envoyer tous les paquets reçus. Lorsque ce dernier est identifié, son adresse est retenue et est utilisée par les autres threads pour renvoyer les paquets, grâce à l utilisation de la variable globale "receiver". Enfin, une fois les deux classes définies, il suffit de lancer le serveur : MainServerSocket (21567) asyncore. loop ( ) 1.5.4.3 Les sockets partie client La partie qui suit est consacrée à l implémentation des sockets TCP dans la partie client. Cela permet aux différents processus en marche de communiquer avec le multiplexeur et de transmettre des données à celui-ci, comme la parole ou une commande par exemple. On s intéresse ici à l implémentation des sockets au niveau des autres processus. Le code sera donc inclus dans l ensemble des programmes qui doivent être connectés au multiplexeur. from s o c k e t import HOST = 1 2 7. 0. 0. 1 PORT = 21567 ADDR=(HOST,PORT) tcpclisock = s o c k e t (AF_INET, SOCK_STREAM) tcpclisock. connect (ADDR) Cette première partie permet d initialiser la librairie python, puis de se connecter au serveur défini précédemment. tcpclisock. send ( message ) Afin d envoyer une information au serveur, il suffit d exécuter la commande send. tcpclisock. c l o s e ( ) Page 48/173 Partie 1

Afin, pour fermer le socket, il suffit d utiliser close. Pour recevoir des données, on crée une fonction receive, que l on définit par : def recv ( ) : while True : data= tcpclisock. recv (BUFSIZE) # I n s e r e r i c i l a commande a e x e c u t e r l o r s q u e l e s donnees sont recues Thread ( t a r g e t=recv ). s t a r t ( ) On lance ensuite la fonction recv dans un thread séparé. Pour cela on utilise la librairie threading importée en début de programme : from threading import Thread Il convient également de mettre BUFSIZE (taille du buffer) dans une variable séparée, puis de la modifier en fonction de la quantité de données reçue. BUFSIZE = 1024 En implémentant ces différentes fonctions dans les clients il nous a été possible de faire communiquer les processus entre eux. Cette implémentation joue donc un rôle de médiateur entre les différents programmes de notre robot. La partie suivante sera consacrée à l implémentation du programme qui reçoit et traite les différentes données, c est le rôle du contrôleur. 1.5.4.4 Le contrôleur Le robot doit être en mesure réagir aux diverses entrées qui lui sont proposées. C est l application contrôleur qui permet de réaliser cela. Son rôle consiste globalement à analyser les commandes sous forme brute provenant des différents périphériques d entrée, notamment du texte envoyé par le programme de reconnaissance vocale, et d exécuter la fonction correspondante. Cette dernière consiste globalement en l exécution d une application. Le principe : L utilisateur donne tout d abord une commande au robot, il faut bien sûr que la plupart des formulations d une même commande puissent être comprises par le robot. Cette dernière condition s applique surtout pour la voix, qui nécessite une analyse supplémentaire de la part du contrôleur. Compte tenu de l organisation de notre système, le multiplexeur redirige toutes les données vers le contrôleur. L analyse de la commande décrite précédemment s applique par conséquent à toutes les commandes quelque soit leur source. Une fois l analyse terminée, le programme repère la fonction correspondante aux mots clés qui lui sont donnés, et exécute cette dernière fonction en lançant un nouveau processus. Il est également possible de personnaliser entièrement le résultat d une commande. Nous pouvons donc imaginer un système permettant d éteindre le robot par exemple. Lorsque la fonction est lancée, le controleur continue d écouter en attente d une nouvelle commande à analyser. Ainsi, dans la mesure où le programme est entièrement maître des tâches lancées par le système, l appelation de contrôleur est bien justifiée. Page 49/173 Partie 1

Le fonctionnement : Pour ce programme, nous avons choisi une implémentation sous la forme d un objet. Cela permet de définir plus facilement un dictionnaire de mots clés, ainsi que de pouvoir encapsuler de façon plus judicieuse les méthodes (ou fonctions) qui utilisent celui-ci. Il faut tout d abord charger toutes les bibliothèques de mots nécessaires au contrôleur pour que le contrôleur effectue les analyses du texte qu il reçoit. c l a s s i n i t c : def init ( s e l f ) : s e l f. dic_action = {} s e l f. dic_objet = {} a c t i o n = [ " pren ", " captur " ] f o r i in a c t i o n : s e l f. dic_action [ i ] = take a c t i o n = [ " ouvr ", " ouve ", " v o i r ", " c o n s u l t ", " donn " ] f o r i in a c t i o n : s e l f. dic_action [ i ] = open a c t i o n = [ " d i s ", " d i r e ", " p a r l e " ] f o r i in a c t i o n : s e l f. dic_action [ i ] = say o b j e t = [ " photo ", " image " ] f o r i in o b j e t : s e l f. dic_objet [ i ] = p i c t u r e o b j e t = [ " video ", " f i l m " ] f o r i in o b j e t : s e l f. dic_objet [ i ] = video o b j e t = [ " mail ", " email ", " messa " ] f o r i in o b j e t : s e l f. dic_objet [ i ] = mail o b j e t = [ " meteo ", " temp ", " s o l e i l ", " p l u i e ", " pleu " ] f o r i in o b j e t : s e l f. dic_objet [ i ] = weather En créant une instance du controleur, on initialise les dictionnaires de mots pour que l application ait une rapidité optimale (le temps d accès à un dictionnaire est sensiblement moins élevé que pour une liste, surtout si les bibliothèques s épaississent). Chaque mot du dictionnaire est associé à une clé qui correspond à la moitié du nom de la fonction qui sera lancée par le controleur. Nous avons évité le problème de conjugaison ou de formulation des commandes en créant un dictionnaire composé des racines des mots, qui se retrouvent quelque soit la formulation de la phrase par l utilisateur. La classe comprend aussi toutes les fonctions qui vont être amenées à être exécutées par l application contrôleur proprement dite. Chaque fonction se présente sous un nom particulier. Par exemple : open_video, open_mail, take_video... Ce nom correspond aux mots clés qui sont identifiés dans la fonction d analyse du controleur. Page 50/173 Partie 1

Pour analyser et lancer les programmes, deux méthodes ont été créées : def commande( s e l f ) : t e x t e = " " do = s e l f. a n a l y s e ( s e l f. input, s e l f. dic_action ) what = s e l f. a n a l y s e ( s e l f. input, s e l f. dic_objet ) i f do!= False and what!= False : t e x t e = " s e l f. f o n c t i o n s. " + do + "_" + what + " ( ) " exec ( t e x t e ) e l s e : s e l f. f o n c t i o n s. f o n c t i o n _ e r r e u r ( ) La fonction commande récupère les résultats de la fonction analyse (qui renvoit la clé correspondant au mot clé identifié dans la phrase) et exécute la fonction correspondante. def a n a l y s e ( s e l f, phrase, dico ) : " " " Traitement d une phrase a p a r t i r des d i c t i o n n a i r e s de mots c r e e s " " " mots = phrase. s p l i t ( ) act = " " f o r mot in mots : i f l e n ( mot ) < 4 : i f mot in dico : act = dico [ mot ] break e l s e : f o r i in range ( 4, l e n (mot) +1) : c l e = mot [ : i ] i f c l e in dico : act = dico [ c l e ] break i f act!= " " : break i f act!= " " : r eturn act e l s e : r eturn False La fonction analyse commence par découper le texte reçu en une liste de mots et les compare un par un aux mots contenus dans le dictionnaire mis en argument. Page 51/173 Partie 1

Il suffit alors de créer un objet qui contient l ensemble des actions possibles, ainsi que leur résolution, c est-à-dire l application à lancer. c l a s s f o n c t i o n s c : def open_video ( s e l f ) : p r i n t ( " Jouvre une photo " ) def open_picture ( s e l f ) : p r i n t ( " Jouvre une photo " ) def open_mail ( s e l f ) : mail ( ). l i s M a i l ( ) def open_weather ( s e l f ) : p r i n t ( meteo ( " l i l l e " ). annonce ( ) ) def take_video ( s e l f ) : p r i n t ( " Je prends une video " ) def take_picture ( s e l f ) : p r i n t ( " Je prends une photo " ) Les fonctions lancées dans le code précédent sont ici fournies à titre d exemple. Elles sont en effet remplacées par l exécution de l application, une fois cette dernière implémentée. L exécution de l application en Python a la syntaxe suivante : subprocess. Popen ( " python2 [ chemin du f i c h i e r ] " + t e x t + " ", s h e l l=true ) Elle utilise la librairie python subprocess, qui permet de lancer des processus fils depuis un programme python. Le paramètre «text» permet de passer un argument lors de l exécution du dit programme, mais il n est pas obligatoire. Enfin, la dernière partie consiste à lancer le contrôleur en lui-même : from cont2 import c o n t r o l e u r from i n i t c import i n i t c from f o n c t i o n s c import f o n c t i o n s c i n i t c o n t r o l e u r = i n i t c ( ) f o n c t i o n s c = f o n c t i o n s c ( ) cont = c o n t r o l e u r ( i n i t c o n t r o l e u r. dic_action, i n i t c o n t r o l e u r. dic_objet, f o n c t i o n s c ) Le contrôleur est cependant un client du multiplexeur. Il ne faut par conséquent pas oublier d intégrer la boucle suivante dans la fonction «receive» de la partie socket (celle-ci sera expliquée ultérieurement) : while True : data= tcpclisock. recv (BUFSIZE) cont. input=data cont. commande ( ) Nous avons vu dans cette partie l implémentation de l une des instances principales du système. Il se trouve que le paramétrage du contrôleur n est pas une tâche facile, mais doit tout de même être effectuée proprement afin que l ensemble fonctionne correctement. Cette partie se trouve être le dernier fondement qu il faut implémenter. Nous avons par la suite cherché à concevoir les différents processus qui permettent d interagir avec les différents périphériques d entrée/sortie. Page 52/173 Partie 1

1.5.5 Les programmes de traitement de données 1.5.5.1 La reconnaissance vocale La reconnaissance vocale a pour but de capturer la voix de l utilisateur, et de l analyser afin d en déduire un ordre ou une fonction à exécuter. Dans notre projet, il existe d autres périphériques de capture comme le bouton ou la caméra par exemple. Cependant, le procédé audio reste le moyen de communication principal avec l utilisateur. Nous avons par conséquent travaillé à le rendre aussi fonctionnel et fiable que possible, c est ce qui a influencé nos choix de développement pour cette partie. Le programme de reconnaissance vocale utilise la fonctionnalité fournie par Google : Google Speech. C est une fonctionnalité peu connue par l utilisateur de Google, cependant la plupart des applications smartphone Android utilisent cette fonctionnalité. Le choix d externaliser le serveur de reconnaissance vocale (ou plutôt celui de traduction), relève du fait que le Raspberry Pi n a pas la puissance nécessaire pour faire fonctionner ce serveur et obtenir des délais satisfaisants. Parlons maintenant de l implémentation de ce module en Python. La première librairie utilisée est PyAudio, qui peut être facilement installée depuis les Repos ArchLinux en recherchant python2-pyaudio. Si toutefois le paquet n est pas disponible, il est également possible de cloner depuis le Git officiel. La seconde librairie, moins connue, s appelle pygsr. Elle permet d utiliser les fonctionnalités de pyaudio afin de récupérer le fichier audio, puis de l envoyer à Google Speech et de récupérer le texte correspondant en utilisant une autre librairie, pysox. pacman S sox En utilisant ces deux librairies, la reconnaissance vocale se limite en quelques lignes : from pygsr import Pygsr speech = Pygsr ( ) speech. record ( 5 ) phrase, complete_response = speech. speech_to_text ( fr_fr ) # pour l a t r a d u c t i o n en f r a n c a i s La variable "phrase" récupérée contient le texte reconnu. En utilisant les sockets, on envoie ensuite cette phrase au multiplexeur puis au contrôleur. L implémentation de ces derniers a été vue dans le chapitre précédent. La partie suivante traite de l implémentation du bouton poussoir, un autre périphérique d entrée du robot. Page 53/173 Partie 1

1.5.5.2 Le contrôle du bouton L implémentation du bouton permet d envoyer des signaux très simples au système. Elle peut être configurée pour envoyer des fonctions élémentaires. Nous avons décidé d implémenter la fonctionnalité correspondante, cependant nous n avons pas d application pratique ou d utilisation de celui-ci pour une fonction. Ce sera donc à l utilisateur de configurer l utilisation du bouton poussoir selon ses besoins. import RPi. GPIO a s GPIO GPIO. setmode (GPIO.BCM) import time c l a s s bouton : def init ( s e l f, e n t r e ) : s e l f. e n t r e = e n t r e p r i n t ( port n + s t r ( e n t r e ) + mis sur l e bouton ) s e l f. sortie_gpio = e n t r e GPIO. setup ( s e l f. sortie_gpio, GPIO. IN ) #methode qui r e t i r e l e t a t du bouton def get_state ( s e l f ) : r eturn GPIO. input ( s e l f. e n t r e ) #methode b o u c l e qui v e r i f i e l e t a t chaque 100ms def boucle ( s e l f ) : while ( 1 ) : s e l f. s t a t e=s e l f. get_state ( ) time. s l e e p ( 0. 1 ) L objet bouton utilise ici la librairie GPIO fournie par défaut avec certaines installations. Il est possible, le cas échéant, de rechercher le paquet correspondant, disponible sur les dépôts ArchLinux : pacman Ss gpio Nous allons désormais nous attacher à un autre moyen de capturer des informations : la reconnaissance d images. 1.5.5.3 La reconnaissance d images Le but de cette partie est de reconnaître le visage de l utilisateur et de le suivre en utilisant les moteurs de la tête du robot. Pour cela, nous disposons d un Raspberry Pi, avec le module caméra CSI ainsi que d un système de moteurs pour diriger la tête sur laquelle est fixée la caméra. Cette caméra a l avantage d avoir des caractéristiques intéressantes (5MP, vidéo en 1080p/30fps) mais surtout de peu utiliser le CPU par rapport aux webcams USB classiques. Elle a par contre pour inconvénient de ne pas être connectée en USB et n est donc pas contrôlable aussi facilement que les autres caméras USB. Figure 47: Caméra relié au Raspberry Pi Page 54/173 Partie 1

Nous allons principalement nous intéresser dans cette partie à l utilisation de la caméra pour faire de la vision par ordinateur. Pour cela, nous allons utiliser la bibliothèque OpenCV (http ://opencv.org/) qui est capable d effectuer de la reconnaissance de visage depuis la version 2.4, et le framework python SimpleCV pour contrôler tout ça en python. On notera cependant que ces bibliothèques ne permettent pas à d exploiter la partie GPU assez puissante du Raspberry Pi et l on risque donc d être limité par les performances très moyennes de son CPU. On commence donc par installer OpenCV. Dans notre cas, nous avons été en mesure d utiliser les dépôts d Archlinux ARM, afin d installer directement la version 2.4. Le problème suivant est de transmettre les images de la caméra du Raspberry Pi au programme de traitement OpenCV. En effet, cette caméra n étant pas une caméra USB, OpenCV ne peut pas récupérer les images avec ses fonctions natives. Plusieurs solutions semblent avoir été trouvées sur le net : Pierre Raufast propose une solution en modifiant le code source des programmes gérant la caméra du RPi (après l avoir testée, cette solution nous semble assez difficile à mettre en place comparée aux 2 autres) Miguel Araujo utilise le projet Userspace Video4Linux qui inclus depuis juillet 2013 un driver pour la caméra CSI Tony DiCola utilise le module picamera comme interface entre la carte et OpenCV Pour la suite, nous avons travaillé avec la troisième solution, car c est celle qui nous a posé le moins de problèmes à implémenter en pratique. On commence par initialiser la caméra à l aide du module Picamera, on attend une seconde le temps qu elle s initialise correctement, et l on règle ses paramètres de capture. On choisit ici une résolution très faible (240x180) afin d avoir par la suite un traitement d image assez rapide. with picamera. PiCamera ( ) a s camera : time. s l e e p ( 1 ) camera. r e s o l u t i o n = (240, 180) camera. r o t a t i o n= 180 On utilise ensuite la fonction capture_continuous dans une boucle pour capturer les images successives. On choisit d utiliser le mode vidéo pour prendre les photos afin d avoir une prise de vue rapide. f o r foo in camera. capture_continuous ( stream, jpeg, True ) : Ensuite, les images successives sont stockées dans un stream. On les récupère puis on les convertit afin qu elles soient utilisables par OpenCV, puis on les convertit en niveaux de gris afin d avoir un traitement d image plus efficace. Page 55/173 Partie 1

data = np. f r o m s t r i n g ( stream. g e t v a l u e ( ), dtype=np. uint8 ) mg = cv2. imdecode ( data, 1) img = img [ : : 1 ] # conversion RGB > BGR gray = cv2. cvtcolor ( img, cv2.color_bgr2gray) gray = cv2. e q u a l i z e H i s t ( gray ) On peut ensuite effectuer la détection de visage sur l image obtenue. Nous n allons pas cependant décrire en détail les algorithmes existants car ceux-ci sont assez difficiles à appréhender. L idée générale est que ceux-ci utilisent des classificateurs pour caractériser les zones de l image. Ils commencent par utiliser des classificateurs faibles permettant d éliminer très rapidement les parties de l image qui ne nous intéressent pas, puis ils utilisent une série de classificateurs "en cascade" et de plus en plus forts afin d affiner la sélection. En pratique, la librairie OpenCV nous simplifie bien le travail. On commence par sélectionner et par charger une série de classificateurs entraînés à reconnaître ce qui nous intéresse (ici les visages de face). Pour cela, on peut soit utiliser ceux qui sont fournis directement par OpenCV (comme je l ai fait) ou créer les nôtres à partir une phase d entraînement (pouvant être assez laborieuses selon le type de classificateur utilisé) cascade_fn=" / usr / share / opencv / haarcascades / h a a r c a s c a d e _ f r o n t a l f a c e _ a l t. xml " cascade = cv2. C a s c a d e C l a s s i f i e r ( cascade_fn ) Dans notre cas, nous pouvons utiliser les classificateurs utilisant des caractéristiques de Haar et ceux utilisant les "Local Binary Patterns". Les premiers sont réputés pour être plus précis que les seconds mais ils sont également plus lents et moins adaptés aux systèmes embarqués car ils utilisent des calculs sur des flottants. Nous avons effectué des tests pour comparer les deux. Les classificateurs LBP sont effectivement beaucoup plus rapides que les autres mais ils ne détectaient que trop peu de visages en pratique. Nous avons donc choisi d utiliser les classificateurs Haar. Pour effectuer la détection en pratique dans OpenCV, on utilise la fonction detectmultiscale en lui précisant des paramètres permettant de trouver un bon compromis précision/temps de calcul. r e c t s = cascade. d e t e c t M u l t i S c a l e ( img, s c a l e F a c t o r =1.3, minneighbors =4, minsize =(40, 40), f l a g s = cv.cv_haar_scale_image) Celle-ci renvoie un tableau comportant les coordonnées et les dimensions des différents visages détectés. Dans notre cas, nous allons nous intéresser principalement à l abscisse des visages détectés afin de pouvoir centrer l image dessus. Nous avons donc vu dans cette partie comment récupérer l image depuis la caméra du Raspberry Pi et comment effectuer le traitement avec OpenCV. Il nous restera par la suite à transmettre cette information à un asservissement du moteur afin de centrer l image sur les visages détectés. Le programme associé fera l objet de la partie suivante. Page 56/173 Partie 1

1.5.5.4 Le programme de contrôle des moteurs Le programme de contrôle des moteurs permet d envoyer des données à la carte électronique qui effectue la commande de ceux-ci. Nous décrivons ici le contrôle logiciel des moteurs. Nous commençons par initialiser les librairies nécessaires, puis nous nous intéressons au sens de rotation tout d abord. Celui-ci est en effet lié au port GPIO sur lequel on envoie le signal. Nous avons également prévu ici une commande d arrêt, permettant de stopper l envoi du signal. import RPi. GPIO a s GPIO GPIO. setmode (GPIO.BCM) import time c l a s s sens : #i n i t i a l i s a t i o n du sens en a s s o c i a n t une S o r t i e GPIO a un sens donne def init ( s e l f, sens, s o r t i e ) : s e l f. sens = sens p r i n t ( port n + s t r ( s o r t i e ) + mis sur l e sens + sens ) s e l f. sortie_gpio = s o r t i e GPIO. setup ( s e l f. sortie_gpio, GPIO.OUT) GPIO. output ( s e l f. sortie_gpio, False ) #methode d a c t i v a t i o n du port pour l a mise en r o t a t i o n def set_on ( s e l f ) : GPIO. output ( s e l f. sortie_gpio, True ) #methode d a r r e t du moteur def s e t _ o f f ( s e l f ) : GPIO. output ( s e l f. sortie_gpio, False ) #methode qui permet un hachage pour c o n t r o l e r l a l i m e n t a t i o n vue par l e moteur def hachage ( s e l f, freq, alpha, nb ) : f o r i in range ( 1, nb ) : s e l f. set_on ( ) time. s l e e p ( alpha / f r e q ) s e l f. s e t _ o f f ( ) time. s l e e p ((1 alpha ) / f r e q ) Page 57/173 Partie 1

Nous avons conçu par la suite l objet qui permet de gérer la rotation du moteur. Cet objet utilise l objet vu précédemment pour configurer le sens de la rotation. c l a s s moteur : #i n i a l i s a t i o n des deux sens de r o t a t i o n du moteur def init ( s e l f ) : s e l f. sens_avant=sens ( avant,27) s e l f. s e n s _ a r r i e r e=sens ( a r r i e r e,17) #methode qui permet l a marche avant du moteur avec hachage def marche_avant ( s e l f, freq, alpha, nb ) : s e l f. s e n s _ a r r i e r e. s e t _ o f f ( ) s e l f. sens_avant. hachage ( freq, alpha, nb ) #methode qui permet l a marche a r r i e r e du moteur def marche_arriere ( s e l f, freq, alpha, nb ) : s e l f. sens_avant. s e t _ o f f ( ) s e l f. s e n s _ a r r i e r e. hachage ( freq, alpha, nb ) #methode qui permet l a marche a r r i e r e du moteur def stop ( s e l f ) : s e l f. sens_avant. s e t _ o f f ( ) s e l f. s e n s _ a r r i e r e. s e t _ o f f ( ) Pour exécuter le programme, il suffit de créer une instance de l objet. Il est possible alors de faire tourner le moteur avec des paramètres (fréquence, alpha dont dépend la vitesse, nb le nombre de fois à répéter le hachage). moteur = moteur ( ) GPIO. cleanup ( ) Cette API permet en somme de configurer les ports GPIO associés à la commande du moteur de la tête à travers le pont H. Elle permettra de définir le sens de rotation et permettra un hachage qui contrôle le niveau de tension mis aux bornes du moteur, et effectue donc la commande de celui-ci. Nous avons désormais effectué la commande du moteur de la tête. La commande des bras quant à elle est effectuée par un servomoteur. L utilisation de ce composant simplifie le contrôle au niveau logiciel. Nous pouvons facilement contrôler celui-ci à l aide du port PWM du Raspberry Pi. Le contrôle consiste en une série d impulsions dont la fréquence détermine la vitesse du moteur. Nous avons également accès au pourcentage d angle, qui détermine la position de consigne du moteur, sachant que celui-ci ne peut tourner que d un angle de 120. Enfin, nous pouvons asservir cette position à tout moment en changeant la valeur de la consigne à l aide de la fonction ChangeDutyCycle. Cela permet de définir facilement des séquences de mouvement des bras. Page 58/173 Partie 1

import RPi. GPIO a s GPIO GPIO. setmode (GPIO.BCM) import time c l a s s servo_moteur : def init ( s e l f, s o r t i e ) : s e l f. s o r t i e = s o r t i e p r i n t ( port n + s t r ( s o r t i e ) + mis sur l e servo moteur ) GPIO. setup ( s e l f. sortie_gpio, GPIO.OUT) s e l f. commande = GPIO.PWM( s e l f. s o r t i e, 5 0 ) def f r e q u e n c e ( s e l f, nouvelle_frequence ) s e l f. commande. ChangeFrequency ( nouvelle_frequence ) def angle ( s e l f, pourcentage_angle ) s e l f. commande. s t a r t ( pourcentage_angle ) def a s s e r v i s s e m e n t ( s e l f, nouveau_pourcentage ) s e l f. commande. ChangeDutyCycle ( nouveau_pourcentage ) def stop ( s e l f ) s e l f. commande. stop ( ) Cet objet nous permet donc de contrôler les bras du robot. L utilisation de ces fonctions dépend toutefois du scénario d utilisation. Par exemple, nous pouvons lancer un mouvement de bras selon une séquence précise ou encore utiliser la position des moteurs pour faire des signes ou de varier en fonction d un autre paramètre. Nous allons désormais voir le dernier programme utilisant les ports GPIO : le contrôle des LED. Page 59/173 Partie 1

1.5.5.5 Contrôle des LED C est un ensemble de classes qui va contrôler la carte des LED pour commander leurs états : allumé où éteint. La première étape est de lier les différentes LED aux bons ports GPIO. Nous utilisons donc la librairie GPIO afin de régler les ports à utiliser en mode OUTPUT (sortie émetteur). Il nous faut également apprendre au programme à allumer, éteindre et faire clignoter les diodes. Nous avons donc intégré des fonctions pour traiter ces opérations. Enfin, la carte des LED nous permet de contrôler la luminosité de chacune des diodes. Il nous suffit donc de créer une fonction qui gère le hachage de la tension, et donc la luminosité. Le code est fourni ci-après : import RPi. GPIO a s GPIO GPIO. setmode (GPIO.BCM) import time c l a s s l e d : #i n i t i a l i s a t i o n de l o b j e t LED avec l a c o u l e u r e t l e port GPIO avec l e q u e l on va commander l a LED def init ( s e l f, couleur, s o r t i e ) : s e l f. c o u l e u r = c o u l e u r p r i n t ( port n + s t r ( s o r t i e ) + mis sur l a s o r t i e + c o u l e u r ) s e l f. sortie_gpio = s o r t i e GPIO. setup ( s e l f. sortie_gpio, GPIO.OUT) GPIO. output ( s e l f. sortie_gpio, False ) def set_on ( s e l f ) : GPIO. output ( s e l f. sortie_gpio, True ) def s e t _ o f f ( s e l f ) : GPIO. output ( s e l f. sortie_gpio, False ) #methode qui f a i t c l i g n o t e r une LED avec une p e r i o d e d une seconde def c l i g n o t e ( s e l f, nb ) : f o r i in range ( 1, nb ) : s e l f. set_on ( ) time. s l e e p ( 1 ) s e l f. s e t _ o f f ( ) time. s l e e p ( 1 ) #methode qui f a i t un hachage sur l a l i m e n t a t i o n de l a LED pour c o n t r o l e r sa l u m i n o s i t e def hachage ( s e l f, freq, alpha, nb ) : f o r i in range ( 1, nb ) : s e l f. set_on ( ) time. s l e e p ( alpha / f r e q ) s e l f. s e t _ o f f ( ) time. s l e e p ((1 alpha ) / f r e q ) #methode qui f a i t allumer l a l e d progressivement def degrade ( s e l f, temp, freq, etape ) : f o r i in range ( 1, etape ) : s e l f. hachage ( freq, i / etape, i n t ( temp f r e q / etape ) ) Page 60/173 Partie 1

La deuxième partie du problème est d utiliser les fonctions définies précédemment, afin d automatiser le contrôle des LED et de permettre d écrire facilement une séquence lumineuse. Le code est le suivant : c l a s s l e d _ c o n t r o l : def init ( s e l f ) : s e l f. bleu=l e d ( bleu,18) s e l f. rouge=l e d ( rouge,17) s e l f. jaune=l e d ( jaune, 7 ) def verifformat ( s e l f, combi ) : i f ( combi. l s t r i p ( rbj0123456789,. )== ) : r eturn 1 e l s e : p r i n t ( e r r e u r dans l e format ) r eturn 0 def combinaison ( s e l f, combi ) : i f s e l f. verifformat ( combi ) : l i s t=combi. s p l i t (, ) f o r i in l i s t : i f b in i : p r i n t ( a f f i c h e bleu ) s e l f. bleu. set_on ( ) i f r in i : p r i n t ( a f f i c h e rouge ) s e l f. rouge. set_on ( ) i f j in i : p r i n t ( a f f i c h e jaune ) s e l f. jaune. set_on ( ) s=i. l s t r i p ( r b j ) p r i n t ( a t t e n t e pendant +s+ seconde ) s f=f l o a t ( s ) time. s l e e p ( s f ) s e l f. bleu. s e t _ o f f ( ) s e l f. rouge. s e t _ o f f ( ) s e l f. jaune. s e t _ o f f ( ) GPIO. cleanup ( ) Afin d illustrer le fonctionnement du script, nous avons pris l exemple suivant : On souhaite effectuer la séquence suivante : les LEDs rouge, bleu et jaune pour 2 secondes, puis les LEDs rouge et belu pendant une seconde, puis la LED rouge pour 2 secondes, puis enfin la LED jaune pour 0.3 seconde La commande sera donc : l e d. combinaison ( rbj2, rb1, r2, j 0. 3 ) En résumé, l implémentation de cette API permet d intégrer facilement des signaux lumineux dans les différentes applications et rajoute un niveau de fonctionnalité au robot. Nous allons pour finir ce chapitre voir la mise en place de la synthèse vocale, qui reste le moyen de communication principal du robot. Page 61/173 Partie 1

1.5.5.6 La synthèse vocale La synthèse vocale consiste en la conversion d un texte donné issu d une source particulière (lecture d un mail ou d un article) et un fichier audio diffusé dans le haut parleur. C est l outil principal dans la réponse (output) fournie à l utilisateur. Pour la synthèse vocale, nous utilisons le service de Google Translate, Google TTS (Text to Speech). C est un service gratuit, fourni par Google, qui peut être utilisé par des programmes. Fonctionnement : #! / usr / bin / python import u r l l i b 2, pycurl, os, sys, subprocess, time, u r l l i b proxy_url = http : / / proxy. ec l i l l e. f r :3128 proxy_support = u r l l i b 2. ProxyHandler ({ http : proxy_url }) opener = u r l l i b 2. build_opener ( proxy_support ) u r l l i b 2. i n s t a l l _ o p e n e r ( opener ) i f l e n ( sys. argv ) < 2 : p r i n t ( " P r e c i s e z une a c t i o n en parametre " ) sys. e x i t ( 1 ) t e x t = sys. argv [ 1 ] def downloadfile ( url, filename ) : fp = open ( filename, "wb" ) c u r l = pycurl. Curl ( ) c u r l. s e t o p t ( pycurl.proxy, " http : / / proxy. ec l i l l e. f r " ) c u r l. s e t o p t ( pycurl.proxyport, 3 1 2 8 ) c u r l. s e t o p t ( pycurl.url, u r l ) c u r l. s e t o p t ( pycurl.writedata, fp ) c u r l. perform ( ) c u r l. c l o s e ( ) fp. c l o s e ( ) def getgooglespeechurl ( phrase ) : googletranslateurl = http : / / t r a n s l a t e. google. com/ t r a n s l a t e _ t t s? t l=f r& parameters = { q : phrase } data = u r l l i b. urlencode ( parameters ) googletranslateurl = "%s%s " % ( googletranslateurl, data ) return googletranslateurl def speakspeechfromtext ( phrase ) : googlespeechurl = getgooglespeechurl ( p h r a s e ) downloadfile ( googlespeechurl, " t t s. mp3" ) time. s l e e p ( 0. 1 ) p. terminate ( ) speakspeechfromtext ( t e x t ) La synthèse est effectuée en 3 parties : L envoi du texte à Google TTS. La récupération du lien et le téléchargement du fichier associé. La lecture du fichier audio téléchargé. Page 62/173 Partie 1

Les deux premières parties sont gérées par CURL et Urllib, deux librairies inclues dans Python par défaut. La dernière partie est gérée par mplayer, un lecteur audio disponible sur les Repos linux. L avantage de mplayer est que celui-ci est configurable ; l utilisateur peut par conséquent choisir la vitesse, le pitch et d autres fonctions de lecture. pacman S mplayer Pour lancer la synthèse vocale, nous avons utilisé un paquet Linux appelé nohup, qui permet de lancer un processus en arrière plan. Le paquet est disponible dans les dépôts ArchLinux et est accessible avec la commande suivante qui permet de l installer sur le système : pacman S nohup Page 63/173 Partie 1

1.5.6 Les applications Nous avons désormais programmé l ensemble des fonctions nécessaires au fonctionnement du robot. Dans cette dernière partie nous avons détaillé quelques applications basiques permettant de donner de l intelligence au robot. Leur intégration ayant été détaillée auparavant, nous nous contenterons ici de présenter les solutions trouvées pour traiter certains scénarios. Nous laissons donc au lecteur le choix de leur intégration. 1.5.6.1 Le streaming de musique Le but de cette partie est de jouer de la musique avec le Raspberry Pi en la contrôlant depuis un smartphone (connecté sur le même réseau wifi), la musique pouvant être situé sur le smartphone, sur le Raspberry Pi ou sur un serveur DLNA connecté au même réseau local. L idée est de faire fonctionner le Raspberry Pi en client UPnP afin qu il puisse être contrôlé pour lire de la musique présente sur un serveur UPnP. Pour cela, on installe le programme GMediaRenderer, dans sa version améliorée par Henner Zeller. Sous Archlinux, ce programme est disponible dans l AUR, ce qui facilite la compilation. On peut ensuite le lancer avec la commande systemctl. Ensuite, on configure Alsa afin d avoir une sortie son fonctionnant correctement. Il faut tout d abord charger le module snd_bcm2835. modprobe snd_bcm2835 Pour le charger automatiquement au boot, on crée un fichier /etc/modules-load.d/snd_bcm2835.conf contenant : snd_bcm2835 Puis on utilise des utilitaires disponibles dans le paquet alsa-utils. On utilise "alsamixer" pour régler le son et sélectionner la carte son, on sauvegarde avec "alsactl save" et on peut ensuite tester si ça marche avec "aplay /usr/share/sounds/alsa/front_right.wav". De l autre côté, sur le smartphone Android, on installe l application BubbleUPNP. Si le smartphone est connecté sur le même réseau local, il devrait détecter le Raspberry Pi dans Devices/Renderer et on peut ensuite jouer de la musique dessus. Ensuite, on peut installer un serveur DLNA pour pouvoir distribuer de la musique depuis le Raspberry Pi. Pour cela, on peut par exemple installer le paquet minidlna, et le configurer en éditant le fichier /etc/minidlna.conf pour choisir les dossiers à scanner. 1.5.6.2 L application météo Cette application permet au robot de donner la météo sur demande. L application météo récupère différentes informations sur internet et les renvoie sous forme d un texte. On peut lancer cette application de deux façons différentes : meteo ( ). annonce ( ) Page 64/173 Partie 1

Avec une string vide, l application récupère les coordonnées GPS de l ordinateur sur internet pour renvoyer la météo. meteo ( P a r i s ). annonce ( ) Il est aussi possible de récupérer a météo d une ville en particulier, ici pour Paris par exemple. Deux sites internet sont utilisés par l application : openweathermap.org et telize.com. Le premier permet de récupérer la météo d un endroit donné (au format JSON), soit en entrant le nom de la ville dans l url, soit en entrant des coordonnées GPS (longitude et latitude). Le second renvoit un objet json contenant des coordonnées GPS déterminées grâce à l IP de l ordinateur. On utilise donc les classes python urllib2 et JSON, pour récupérer les objets JSON et les parser : def getwithcity ( s e l f, j o u r ) : i f j o u r == 0 : u r l = http : / / api. openweathermap. org / data /2.5/ weather?q= u r l += s e l f. v i l l e u r l += &u n i t s=metric parsed_json = s e l f. recupjson ( u r l ) On définit l url à partir de laquelle récupérer l objet json. def recupjson ( s e l f, u r l ) : try : page_json = u r l l i b 2. urlopen ( u r l ) j s o n _ s t r i n g = page_json. read ( ) parsed_json = j s o n. l o a d s ( j s o n _ s t r i n g ) page_json. c l o s e ( ) r eturn parsed_json except : p r i n t ( Je n \ a r r i v e pas a r e c u p e r e r l e s donnees ) sys. e x i t ( 2 ) La fonction recupjson récupère et parse l objet en format Json. L application météo doit retourner au final une string qui pourra être utilisée par l API de synthèse vocale pour que le robot puisse énoncer la météo. Page 65/173 Partie 1

La fonction annonce() appelle donc getmeteo() qui appelle les différentes fonctions permettant d aller chercher les informations nécessaires et utilise ces informations pour renvoyer la string finale. def annonce ( s e l f ) : phrase = f o r i in range ( 0, 3 ) : s e l f. getmeteo ( i ) i f i ==0: i f s e l f. temps!= : phrase += s e l f. l ist_day [ i ] +, phrase += s e l f. dico_today [ s e l f. temps ] phrase +=, et l a temperature e s t comprise e n t r e phrase += s t r ( s e l f. temp_min) phrase += et phrase += s t r ( s e l f. temp_max) phrase += degre C e l s i u s. e l s e : i f s e l f. temps!= : phrase += s e l f. l ist_day [ i ] +, phrase += s e l f. d i c o _ f o r e c a s t [ s e l f. temps ] phrase +=, et l a temperature s e r a comprise e n t r e phrase += s t r ( s e l f. temp_min) phrase += et phrase += s t r ( s e l f. temp_max) phrase += degre C e l s i u s. p r i n t ( phrase ) def getmeteo ( s e l f, j o u r ) : s e l f. temps = s e l f. temp_min = s e l f. temp_max = i f s e l f. v i l l e!= : s e l f. getwithcity ( j o u r ) e l s e : s e l f. getwithcoord ( j o u r ) La fonction annonce() reçoit des données en anglais, elle utilise donc des dictionnaires afin d effectuer une traduction des termes anglais récupérés dans les JSON. Le texte renvoyé par la fonction est donc directement transmis au programme de synthèse vocale, et l application est exécutée par le contrôleur. 1.5.6.3 La lecture des emails Cet article décrit comment la récupération des mails s effectue. Nous avons choisi d utiliser IMAP pour récupérer les mails. Au niveau de python, la classe Imaplib nous permet d identifier les mails présents dans la boite de réception suivant plusieurs critères (tous, non lus, dans un dossier particulier...) et de les récupérer. D autres fonctions sont nécessaires à la récupération des informations d un mail (destinataire, émetteur, sujet, texte). Le mail récupéré par défaut est de premier abord illisible et une fonction permet donc de récupérer les informations qui ont un intérêt pour nous. Page 66/173 Partie 1

La fonction parse permet de réaliser cela : def parse ( content ) : msgobj = Parser ( ). p a r s e s t r ( content ) i f msgobj [ Subject ] i s not None : decodefrag = decode_header ( msgobj [ Subject ] subj_fragments = [ ] f o r s, enc in decodefrag : i f enc : s = unicode ( s, enc ). encode ( u t f 8, r e p l a c e ) subj_fragments. append ( s ) s u b j e c t =. j o i n ( subj_fragments ) e l s e : s u b j e c t = None attachments = [ ] body = None html = None f o r part in msgobj. walk ( ) : i f part. get_content_type ( ) == " t e x t / p l a i n " : i f body i s None : body = " " body += unicode ( part. get_payload ( decode=true ), part. get_content_charset ( ), r e p l a c e ). encode ( u t f 8, r e p l a c e ) e l i f part. get_content_type ( ) == " t e x t /html " : i f html i s None : html = " " html += unicode ( part. get_payload ( decode=true ), part. get_content_charset ( ), r e p l a c e ). encode ( u t f 8, r e p l a c e ) return { s u b j e c t : subject, body : body, html : html, from : parseaddr ( msgobj. get ( From ) ) [ 1 ], to : parseaddr ( msgobj. get ( To ) ) [ 1 ] } Cette fonction extrait les informations intéressantes du mail. Pour cela, elle analyse les différents mots-clés dans le mail, afin d extraire les différentes données relatives au sujet, à l émetteur, au message et au destinataire. On peut maintenant s intéresser à la façon de récupérer les mails. Page 67/173 Partie 1

C est la fonction lismail() qui s en occupe (ici les identifiants d accès au compte et le nom du serveur sont mis directement dans le code) : def l i s M a i l ( ) : obj = imaplib. IMAP4_SSL( imap. gmail. com, 993 ) #I c i pour gmail obj. l o g i n ( i d e n t i f i a n t, mdp ) obj. s e l e c t ( ) r e s u l t, data = obj. uid ( search, None, " Unseen " ) nonlus = data [ 0 ]. s p l i t ( ) nb = l e n ( nonlus ) i f nb == 0 : r eturn " Votre b o i t e mail e s t vide " e l s e : reponse = reponse += Vous avez reponse += s t r ( nb ) i f nb > 1 : reponse += nouveaux messages e l s e : reponse += nouveau message f o r uid in nonlus : r e s u l t, data = obj. uid ( f e t c h, uid, (RFC822) ) raw_email = data [ 0 ] [ 1 ] s u j e t = parse ( raw_email ) [ s u b j e c t ]. decode ( utf 8 ) d e s t i n a t a i r e = parse ( raw_email ) [ to ] d e s t i n a t e u r = parse ( raw_email ) [ from ] content = parse ( raw_email ) [ body ]. decode ( utf 8 ) reponse += \nmessage envoye par reponse += d e s t i n a t e u r reponse += \n reponse += s u j e t reponse += \n reponse += content r eturn ( reponse ) Cette fonction s identifie tout d abord sur le serveur Gmail à l aide de l identifiant et du mot de passe fournis, et effectue une demande pour les emails non lus. Elle crée ensuite un texte de réponse dans lequel sont inclus les informations données par l analyseur. La réponse contient donc la phrase à lire par le programme de synthèse vocale. Encore une fois, l objet retourné par la fonction lismail() doit être une string qui pourra être lue par l API de synthèse vocale du robot. On peut remarquer une chose intéressante et sur laquelle nous avons quelque peu buté, les mails sont ici traités par leur uid (qui est unique pour un mail donné) alors que certaines documentations que l on peut trouver sur internet vont proposer une solution où les mails sont traités par leur identifiant imap. Or n importe quelle opération sur les mails (suppression, copie,...) va effectuer un décalage au niveau des identifiants imap. Ainsi, les mails ouverts par l application ne seront dans la plupart des cas pas les bons avec cette technique. Page 68/173 Partie 1

1.5.6.4 Les perspectives de développement Nous avons lors de ce projet réussi à mettre en place des applications basiques, qui permettent de donner un certain degré d intelligence et d interaction à notre robot. Cependant, afin d aboutir à une véritable utilisation du robot, il faut intégrer d autres applications dans le système. En effet, nos choix de développement permettent de développer facilement une application en Python répondant à un besoin spécifique. Son intégration est également facilitée par une bonne gestion des ressources et des processus, ainsi que par des moyens de communication simples à implémenter. Nous pouvons ainsi définir des axes de développement du produit qui permettront de le rendre plus intelligent et fonctionnel. Ces axes se divisent principalement en deux pôles. Le premier pôle concerne l optimisation des applications existantes. Le travail à effectuer consisterait en effet à ajouter des nouvelles fonctionnalités aux applications déjà existantes. Un bon exemple serait de donner la possibilité de répondre aux messages lus par l application mail. Il est également possible d augmenter la réactivité du robot en ajoutant des mots clés supplémentaires qui correspondraient à l exécution de l une de ces applications. De cette façon, il sera plus simple à l utilisateur d exprimer son besoin au robot. Le second pôle concernerait l ajout d applications supplémentaires. Celles-ci doivent bien évidemment répondre à un besoin de l utilisateur, et donc doivent s inscrire obligatoirement dans un scénario particulier. La pertinence des scénarios relève des tendances actuelles, comme le besoin de communiquer via des réseaux sociaux, ou encore de pouvoir se divertir grâce à des jeux casuels ou encore des médias. Il faut cependant tenir compte de la disponibilité des outils permettant de réaliser la fonctionnalité voulue. En effet, le développement de certaines applications pourrait rendre le dispositif coûteux pour l utilisateur (pour la diffusion d une musique par exemple), ou encore de nuire à la stabilité du robot par l utilisation de ressources trop élevées entre autres. Ces facteurs seront par conséquent décisifs dans le choix des applications futures et du développement du robot. Ainsi, le développement des fonctionnalités du produit permettra dans notre cas de créer des scénarios d utilisation, afin d aboutir à une communauté d utilisateurs et de développeurs qui guideront l évolution de la plateforme créée lors de ce projet. Page 69/173 Partie 1

1.5.7 Conclusion Nous avons réussi dans cette partie à créer un robot intelligent, fonctionnel et entièrement personnalisable. Notre façon de procéder a fait intervenir des choix importants au point de vue physique et logiciel. La démarche employée a touché à tous les niveaux de programmation et à de multiples domaines de l informatique : le réseau, le développement d applications haut-niveau en Python, l administration des systèmes, la gestion des ressources, la gestion et la commande de périphériques, la communication entre processus. En partant d une multitude de périphériques matériels, nous avons su gérer la conception d un système depuis les premières considérations en termes de choix et d architecture, jusqu au développement d applications de haut niveau qui utilisent les différentes ressources pour créer une véritable intelligence dans le robot. Nous avons également réussi à garder à l esprit le développement futur et l avenir du robot, en créant un système personnalisable qui peut être facilement amélioré et enrichi par de nouvelles applications. Notre prototype constitue alors une plateforme qui permettra non seulement d ajouter des fonctionnalités au robot, mais aussi de fonder une communauté qui, nous l espérons, fera de RALF un appareil à la hauteur des dispositifs intelligents actuels. Page 70/173 Partie 1

1.6 Tests du robot assemblé Page 71/173 Partie 1

Deuxième partie Gestion de projet 2.1 Introduction Le bon fonctionnement d un projet passe essentiellement par une bonne maitrise des outils de gestion de projet. Il faut que chaque tâche qui n est pas purement technique soit attribuée à quelqu un, sous peine de voir cette tâche oubliée. Nous nous sommes donc répartis des rôles dès la moitié la première année. Répartition : Florence : Gestion de la planification (chef de projet) Vladimir : Animateur (dont la gestion du QHP) Maxence : Trésorier Ahmed : Recherche et relation avec le partenaire Stéphane : Communication interne (compte-rendu par exemple) Guillaume : Valorisation Alexandre : Documentation (Mise en page des rapports par exemple) Chacun a donc eu un rôle précis à jouer pour que le projet puisse avancer à un rythme soutenu. Dans cette partie, nous allons parler de certains des outils mis en place par les membres du groupe concernant leur rôle de gestion de projet, ainsi que du budget. 2.2 Budget 2.2.1 Premières estimations Au début du projet, pendant la phase d étude de faisabilité, nous avions effectué une première estimation du budget nécessaire pour réaliser à bien le projet. A partir des premières solutions techniques, nous étions arrivé à une estimation de 310 euros pour les composants et de 200 euros pour la partie mécanique en utilisant des techniques d impression 3D. Composants Raspberry Pi LED NFC Caméra HP Carte Wifi Alimentation Microphone Hub Bluetooth Câbles et petits composants Cout composants 35 euros max 20 euros environ 100 euros max 30 euros environ 20 euros max 15 euros 20-30 euros environ 15 euros environ 15 euros environ 15 euros environ 25 euros Ces estimations étaient plutôt correctes en ce qui concerne les composants et la partie électronique, mais la partie mécanique avait clairement été sous-évaluée. Lorsque nous avons ensuite disposé de Page 72/173 Partie 2

données plus précises, nous avons pu estimer que réaliser cette partie avec une imprimante 3D nous coûterait environ 600 euros. 2.2.2 Solution finale Or, comme par la suite, nous n avons finalement pas trouvé de partenaire financier pour notre projet, nous avons dû trouver de nouvelles solutions afin de rester dans l enveloppe des 300 euros alloués par l école pour le projet. Ainsi, certains composants ont été abandonnés tandis que d autres ont pu nous être prêtés par l intermédiaire de M. Bourdeaud huy, et la partie mécanique a dû revoir entièrement sa solution technique. Finalement, les commandes effectuées sont les suivantes : N Description Fournisseur Prix TTC N Description Fournisseur Prix TTC 1 Electronique Farnell 14,79 2 Electronique Farnell 10,43 3 Engrenages Engrenages HPC 51,36 4 Roues dentées Conrad 14,38 5 Demi-Sphere Abaqueplast 35,75 6 Bras Labo Méca 68,17 7 Tube PVC Labo Méca 4 8 Axe et fixation Labo Méca 4 9 Poster COREP 36 total 238,88 2.2.3 Charges non financières Pour le budget, il est également assez important de suivre les charges non financières, afin de vérifier que l on n a pas dépassé les limites qui nous étaient données et car celles-ci correspondent à des charges assez importantes. A ce niveau, je vous invite à vous référer au détail du budget présenté en annexe, nous avons utilisé : 75h enseignants (soit un équivalent de 4125 ) sur les 94h qui nous sont mises à disposition 20h d utilisation de machines de l école (CAO, machines conventionnelles) 100 de prêt de matériel Nous avons ainsi pu réaliser à bien le projet du point de vue du budget, malgré les problèmes que nous avons pu rencontrer. Page 73/173 Partie 2

2.3 Valorisation Nous allons dans cette partie aborder la valorisation effectuée concernant le projet RALF, qui permet au projet d être connu par une communauté qui ne se limite pas à l Ecole Centrale de Lille mais cette valorisation permet aussi de promouvoir la formation centralienne et plus précisément le projet G1-G2. 2.3.1 Valorisation sur internet 2.3.1.1 CentraleWiki Avoir une page sur le site CentraleWiki est primordiale pour un projet comme le nôtre, en effet c est une opportunité unique pour faire connaitre notre projet à l ensemble des centraliens. Notre projet étant OpenSource (c est-à-dire n importe qui peut récupérer l ensemble des données de notre projet afin de se l approprier et de l améliorer), la page de CentraleWiki présentant notre projet est un moyen de valoriser et de capitaliser l expérience que nous avons eu. Car un si un futur projet similaire au notre voit le jour, il pourra se servir de l ensemble des connaissances que nous avons acquis lors de ces deux années et aura de très solides bases pour commencer ce nouveau projet. Voici le début de notre page sur CentraleWIki. Figure 48: Page du projet sur Centrale Wiki 2.3.1.2 Le site internet du projet Si le site CentraleWiki est un bon vecteur de valorisation, il faut toutefois noter qu il n est accessible qu aux centraliens, aux encadrant de l Ecole Centrale de Lille et aux anciens élèves. En effet, pour pouvoir avoir accès aux données du CentraleWiki il faut préalablement se connecter à CentraleWIki et ceci n est possible que pour les personnes citées précédemment. Or nous souhaitions que toutes personnes intéressées par le projet puissent avoir accès à nos données, c est pourquoi nous avons créé un site internet permettant un partage plus complet de nos savoirs. Page 74/173 Partie 2

Ainsi, le site http ://ralf.ec-lille.fr a vu le jour. Nous avons souhaité montrer particulièrement l avance progressive du projet, et pour cela nous avons choisi une mise en page du site spéciale. Notre site est donc composé de deux pages principales, qui récapitulent le but du projet et présentent l équipe, puis nous avons divisé le site en sous parties représentant chacun des pôles de notre projet (Informatique, électrique, mécanique, automatique). Dans ces sous-parties, nous publions un article à chaque succès ou difficultés rencontrés, ce qui en fait un site dynamique et vivant. Nous allons maintenant vous monter comment le site se présente. Voici la première page du site : Figure 49: Site internet ralf.ec-lille.fr Page 75/173 Partie 2

Voici deux exemples d article publié sur notre site : Figure 50: Exemple d article du site Figure 51: Exemple d article du site Comme vous pouvez le constater, nous expliquons sur notre site l ensemble des informations nécessaires pour qu une tierce personne puisse continuer, améliorer notre projet ou simplement utiliser une partie des connaissances que nous avons acquises. Il est nécessaire de mesurer l affluence d un tel site, afin de savoir si le site intéresse et rempli son rôle de vecteur de transmission. Ainsi, nous avons installés Google Analytic sur notre site qui permet de connaitre la localisation, le nombre de visite, le nombre de visiteur unique, le temps de consultation Page 76/173 Partie 2

du site et bien d autres données utiles. Voici l interface qui nous donne l activité sur le site en temps réel, avec le nombre de pages visitées durant la dernière demi-heure. Figure 52: Activité du site en temps réel Nous pouvons aussi déterminer le nombre de visite pour une durée plus grande, ici du 26 Mars au 30 Mars. Figure 53: Activité du site sur une plus longue durée Nous allons analyser ces données : durant ces quatre jours 91 personnes se sont connectées sur notre site et ont vu 607 pages de notre site. En moyenne ils sont restés une minute 24 secondes sur notre site. Il faut ajouter que ce site est parfaitement adapté aux téléphones portables, permettant de consulter les nouvelles avancées du projet sans être sur son ordinateur. 2.3.1.3 La diffusion du site internet Bien entendu, de tels résultats ne s obtiennent pas uniquement en créant un site internet, nous l avons aussi diffusé à travers un grand nombre de forum et à travers Facebook. En effet, nous avons posté sur un grand nombre de forum un article présentant notre projet et donnant le lien de notre site internet. Nous n avons évidemment pas choisi ces forums par hasard, et nous avons ciblé des forums traitant d Android qui est le thème de notre projet, de RaspberryPi, qui notre microprocesseur ou alors de robotique en général. Vous trouverez en annexe l article type que nous avons publié sur les forums, sachant que nous l avons adapté en fonction du forum et des règles de celui-ci. Voici un petit échantillon des forums sur lesquels nous avons publié un article : 1. OpenClassrooms 2. Robot-Maker Page 77/173 Partie 2

3. Korben Notre but était bien évidemment d informer un maximum de personne de l existence du projet, mais nous voulions informer en priorité des personnes susceptibles de nous aider, c est pourquoi nous avons choisi des forums spécialisés dans un des domaines que nous abordons dans le projet. 2.3.2 Valorisation sur d autres supports Nous allons maintenant aborder les vecteurs de valorisation que nous avons utilisés sur d autres supports qu internet. 2.3.2.1 Le poster Tout groupe projet doit réaliser un poster présentant son projet, cela permet d attirer l oeil d un passant sur notre projet. Sachant cela, nous avons créé notre poster de façon à ce qu il attire l oeil sur les fonctionnalités du robot et son but : l intégration dans un espace intelligent avec lequel il communique grâce au Wifi. Nous avons donc placé sur l affiche le robot au centre, dans une maison équipée d appareils avec lesquels le robot est susceptible de communiquer pour montrer de manière frappante l intérêt d un tel robot et que celui-ci a bien sa place au coeur d un foyer standard. Outre le poster en lui-même, il est important de considérer où il sera affiché. En effet, pour la plupart des groupes projet, les posters sont affichés de manière très éphémère avant les soutenances. Ce ne sera pas le cas du notre, en effet, nous avons obtenu des membres organisant le forum étudiantsentreprises de l Ecole Centrale de Lille que ce poster fasse partie de la dizaine de posters affichée durant l évènement de l année prochaine. Cet affichage se fera à côté des différents bars qui permettent aux représentants des entreprises de se désaltérer. Il n était pas possible les années précédentes, et donc aura lieu après la fin du projet, permettant au projet de perdurer. Mais cet affichage n a pas lieu uniquement pour la valorisation du projet, en affichant notre poster, nous montrons aux entreprises que les étudiants de l Ecole sont capable de mener à bien un projet complexe utilisant des technologies récentes, et que l Ecole encourage le travail en groupe et forme des ingénieurs capable de mener à bien des travaux de longue durée. Ce poster servira donc à valoriser de manière efficace le projet en attirant l oeil du passant sur les points forts de notre projet, mais aussi montrera aux représentants d entreprises l efficacité de la formation centralienne. 2.3.2.2 L article de presse Afin d informer un plus grand nombre de personne, il est nécessaire de publier dans la presse un ou plusieurs articles parlant des ambitions du groupe projet. C est pourquoi nous avons contacté la revue de «L ingénieur» qui a répondu favorablement à notre demande de publication d un article. Après avoir retravaillé plusieurs fois cet article, il sera publié pour le numéro de Juin, donc encore une fois après la soutenance finale du projet, mais cela n a aucun effet sur la valorisation du projet, et cet article précise que le projet est OpenSource. Un personne lisant l article peut tout à fait vouloir nous contacter pour connaitre l aboutissement du projet et l améliorer. En outre, nous avons aussi contacté «La Voix du Nord» et le «Monde» pour publier un article dans ces deux journaux, toutefois nous avons eu moins de succès car pour les deux journaux il nous fallait un livrable concret avant de publier un article, ce que n avions pas jusqu à récemment. 2.3.2.3 La plaquette Afin de démarcher des partenaires, nous avons utilisé un autre vecteur de communication : la plaquette. Nous avons en effet crée une plaquette que vous pouvez trouver dans les annexes, dans le but de donner une brève explication sur le but du projet. Celle-ci comportait donc un visuel approximatif du livrable final tel que nous l imaginions, mais aussi une liste des composants que nous comptions intégrer au robot et l adresse mail du groupe projet afin de pouvoir nous poser des questions. Page 78/173 Partie 2

Cette plaquette fut extrêmement efficace, c est grâce à elle que nous avons trouvé notre premier partenaire et une aide matérielle non négligeable (Don de deux robots par une entreprise afin de nous aider dans notre démarche et nos recherches. 2.3.2.4 Les tutoriels Toujours dans le but d aider les futurs groupes projets et de leur éviter des obstacles que nous avons rencontrés, ou alors pour faciliter la reprise du projet par une tierce personne, nous avons établi deux tutoriels, un pour la partie mécanique qui explique comment précisément comment modéliser les bras en 3D avec CATIA, et permet d apprendre comment prendre en main ce logiciel très complet de modélisation 3D. Le deuxième tutoriel quant à lui concerne la partie automatique, avec l explication de la démarche à suivre pour modéliser et asservir un moteur sous MATLAB. Là encore, ce tutoriel est crée dans le but d aider les futurs centraliens ou de faciliter la reprise et l optimisation du projet. Ce tutoriel (que vous pouvez retrouver dans les annexes) a été diffusé sur internet à travers notre site internet mais aussi sur le site où les centraliens postent les différents cours et annales qui leur sont fournis. Ainsi, ces tutoriels sont à la portée de tous et nous espérons qu ils s avèreront utiles. 2.3.2.5 Le QRCode Afin de permettre le lien entre les supports papiers et notre site internet, nous avons généré un QR Code. Ce code est un outil permettant à un utilisateur de téléphone portable possédant l application adaptée d ouvrir directement notre site internet sur son téléphone portable. Ce QR code étant présent sur notre poster et sur l article qui sera publié, une personne souhaitant connaitre plus en détail notre projet peut simplement ouvrir notre site internet sur son portable en passant son téléphone devant l affiche ou l article. Ce code est donc un lien certain entre les différents supports papier de valorisation et notre site internet. Voici le QRCode en question : Figure 54: QR Code Page 79/173 Partie 2

2.4 Partenaires Dès le début du projet, nous nous sommes mis à la recherche d un partenaire dans le but de financer les dépenses du projet qui pourraient déborder par rapport à la somme subventionnée par l Ecole. En effet, les premières estimations des dépenses dépassaient la somme de 300 euros et un partenaire semblait nécessaire. 2.4.1 Campagne de recherche de partenaire : Nous avons développé une stratégie pour trouver un partenaire. Nous avons dans un premier lieu listé toutes les entreprises de robotique et d automatique qui sont les plus succeptibles d adopter notre projet (le robot RALF), nous avons ensuite essayé de les contacter par mail. Suite à ceci nous avons eu quelques réponses d Aldeberan (entreprise qui a fait le Karotz) et Phoceis. Aucune de ces 2 pistes n a pu aboutir, à cause des règles de conformités internes pour Aldeberan qui refuse tout projet externe. Du côté de Phoceis, la relation bien que semblant prometteuse au début a été interrompu suite à leur déménagement et nous n avons plus pu avoir de contacts avec eux depuis, bien que nous ayons tenté de nombreuses fois de les appeler, contacter par mails, et même nous rendre sur place. Suite à ceci, et sur les conseils de notre directeur scientifique, nous avons contacté CITC (spécialiste des technologies de communication sans contact). Le CITC est en train de développer un projet qui s intitule la maison intelligente. Ce projet est en effet une maison qui est dotée de plusieurs sortes de capteurs et d actionneurs qui pourront commander par exemple l ouverture des portes, les fenêtres, ou l allumage des lumières. Nous nous sommes rapprochés du CITC pour intégrer notre robot qui s inscrit bien dans le thème de la maison intelligente comme une interface de communication avec l utilisateur. En effet, notre robot RALF qui est conçu pour comprendre des commandes vocales et les interpréter sera un intermédiaire très intéressant puisque la maison sera commandée directement par les ordres prononcés par une personne. De plus, comme nous avions envisagé d intégrer des lecteurs RFID au robot et que le CITC est un expert de cette technologie, nous avons trouvé très intéressant le fait de nouer un partenariat avec eux ce qui nous donnerait finalement un support de valorisation de notre projet (la maison intelligente) et une aide technique. 2.4.2 Relation avec le CITC : Suite à plusieurs échanges avec notre correspondant au CITC, nous lui avons fait savoir nos intentions de faire un partenariat avec eux. Lors d une réunion, nous avons mis au clair toutes les obligations de chaque parti du contrat selon les exigences de l Ecole Centrale de Lille, à savoir les obligations de présentation de livrables, les subventions de l école et les obligations financières du partenaire. Le CITC a refusé ce partenariat pour des causes financières en nous expliquant clairement leur souhait de faire ce partenariat en n offrant que la maison intelligente comme support d essai et de test et aucun budget ne peut être prévu pour ce projet. Sur ce, notre relation a été rompu puisque sans l apport financier nécessaire, le partenariat semble défavorable pour le projet dans la mesure où nous devions orienter tout notre travail sur l adaptation du robot pour communiquer avec la maison intelligente, ce qui n a pas été prévu dès le début. 2.4.3 Conclusion : Nous sommes maintenant à la fin du projet et nous avons pu nous passer d aides financières autres que celle de l Ecole Centrale. Nous pensons faire un partenariat avec l électif d intelligence ambiante qui pourra transmettre le projet à d autres groupes projet pour l améliorer dans les années futures. Page 80/173 Partie 2

2.5 Documentation Pour assurer la documentation du projet et s assurer qu elle soit de qualité, nous avons été amené à utiliser plusieurs outils. 2.5.1 Dossiers produits Tout au long du projet, la documentation destinée à Centrale ou aux éventuels partenaires a été produite en utilisant un format unique et professionnel mis en place avec latex. Cela nous a permis d avoir une unité dans nos dossiers tout en réduisant le temps passé à mise en forme finale des dossiers. En effet, à la fin du projet, les membres du projet était formés aux bases de latex et pouvait produire directement leur partie chacun de leur côté dans ce langage. Figure 55: Code latex 2.5.2 Les comptes rendus Chaque réunion pendant le projet a fait l objet d un compte rendu. Cela a l avantage de permettre à tous les membres de retrouver les informations importantes relatives au projet lorsqu ils en ont besoin. 2.5.3 Le site web externe Le site internet du projet regroupe toute la documentation disponible autour du projet. Il sert aux membres du projet autant qu il peut servir à des personnes extérieures à celui ci. 2.5.4 Dropbox Le groupe projet a utilié une dropbox tout au long du projet pour partager de façon efficace et rapide les documents importants du projet. Page 81/173 Partie 2

2.6 Animation Le rôle d animateur dans un groupe projet peut prendre différentes facettes. L animateur est non seulement celui qui coordonne et anime les réunions au sein de l équipe, c est aussi la personne qui veille à la cohésion du groupe. En cas de conflit ou de désaccord, son rôle consiste à faire office de médiateur entre les parties. Il est toutefois difficile de coordonner une équipe de plusieurs membres. Le format de réunions classique n est pas toujours adapté à l avancement du projet, et la cohésion de l équipe se trouve souvent fracturée par la répartition du travail et les spécialités de chacun. C est pourquoi l animateur se réserve le droit de changer le format des réunions de l équipe projet, et d imposer un axe de discussion qui lui semble judicieux et efficace. Dans notre groupe projet, le bilan sur la première année a fait apparaître un défaut majeur : la combinaison du phénomène de division par pôles de travail a provoqué une séparation entre les sous-groupes, ainsi qu une certaine opacité par rapport à ce qui se passait dans chacun des pôles. En conséquence, lors des réunions générales de l équipe projet, chaque groupe se retrouvait à débattre sur sa partie, pendant que les autres membres se sentaient perdus, faute de pouvoir suivre régulièrement l avancement du pôle en question. L une des conséquences directes est que les réunions étaient devenues inefficaces à cause de 2 facteurs principaux. Tout d abord, le manque d informations sur les autres groupes constituait un obstacle à la compréhension et la planification des différentes tâches. Ensuite, le temps passé à expliquer l avancement et les objectifs a mené à des réunions trop longues, lors desquelles il était difficile de suivre et de rester concentré. L autre conséquence est l impossibilité de voir le projet dans sa globalité. Aucun des membres n étant capable de résumer la partie des autres groupes, les réunions avec le DS ou le pilote s étaient transformées en des entretiens individuels plus qu en retour collectif, n impliquant ainsi aucune participation de la part des autres membres. Ayant constaté et analysé la cause du problème, Vladimir, l animateur du groupe a décidé de mettre en place une solution innovante à ce problème. Cette solution, que nous avons appelé ultérieurement «QHP» ou «Quart d Heure Projet» était devenue une solution alternative aux réunions classique du groupe projet. Le QHP a pris la forme d une réunion hebdomadaire de 15 minutes, lors de laquelle chacun des membres devait présenter très rapidement son avancement sur la semaine, et rappeler ses objectifs pour la semaine prochaine. Chaque semaine, ces objectifs étaient repris par l animateur, et le membre concerné devait confirmer que l objectif planifié a bien été atteint, ou dans le cas échéant devait donner la cause du problème qui a entravé sa progression. Le résultat de la réunion était résumé dans un tableau consultable par l ensemble du groupe : Page 82/173 Partie 2

Figure 56: Compte rendu d une séance de QHP Le compte rendu des QHP était mis sur la Dropbox, afin que chacun puisse être en mesure de consulter ses objectifs et son avancement. Les conséquences de ce nouveau format étaient devenues très rapidement visibles : Chacun des membres était mieux informé du travail des autres Les informations importantes étaient diffusées, et les sujets étaient discutés rapidement pendant les QHP, rendant les autres réunions pratiquement inutiles Le gain de temps était devenu de 1 à 2 heures par mois environ Le format des réunions incitait les membres à fournir un travail plus régulier et les motivait à parler de leurs succès et de partager leur progression En somme, cette innovation a eu un impact très positif sur le groupe, et a permis de résoudre les différents problèmes responsables de l inefficacité au sein de l équipe. Cette expérience en gestion de projet a donc non seulement simplifié la tâche de l animateur, mais a aussi constitué un bon exemple à rajouter au bagage d expérience de chacun des membres du groupe projet RALF. Page 83/173 Partie 2

2.7 Communication interne 2.7.1 Première étape de la communication : le googlegroup Pour faciliter la communication au sein du projet et permettre un travail en équipe efficace, nous avons du mettre en place plusieurs outils. Tout d abord, le googlegroup pjandroid@googlegroups.com contenant tous les membres de l équipe projet permettait de faciliter cette communication, en nous permettant de partager les informations facilement au sein du groupe. De plus, elle permettait à nos encadrants, consultants ou partenaires de contacter l ensemble du groupe tout aussi facilement. Pour ces deux raisons, ce googlegroup a été une avancée importante pour la cohésion du projet. 2.7.2 Le miniblog Pour des raisons pratiques, le googlegroup ne contenait que les élèves membres de l activité projet, pour éviter que les consultants et encadrants ne voient leurs boîtes mail inondées de mails ne les concernant pas. Cependant, cela avait aussi des inconvénients, car les encadrants et les consultants n étaient pas informés automatiquement de ce qu il se passait. Nous avons donc mis en place un petit blog (www.ralf.ec-lille.fr/shaarli) que nous mettions à jour au fur et à mesure des avancées du projet. Ainsi, une fois le lien communiqué, il permettait à tous d évaluer rapidement les dernières avancées du projet. Page 84/173 Partie 2

2.8 Planification Une bonne planification est indispensable pour un projet qui progresse régulièrement. Si l on ne sait pas où l on va, on ne peut pas travailler efficacement, et cela peut mener à de grosses charges de travail sur une très courte période, ce qui aurait pu être évité. Malheureusement, planifier n est pas une tâche simple. A notre niveau de connaissance nous ne savons souvent pas combien de temps une tâche va nous prendre. Nous tentons donc de planifier ce que nous devons faire sur quelques semaines, le plus souvent sans succès. Nous sommes ainsi condamner à refaire des plannings de manière régulière pour pouvoir se tenir à jour dans la planification prévue. 2.8.1 Outils mis en place Chaque pôle ayant des tâches que les autres ne comprennent pas forcément à effectuer, ce sont les chefs de pôles (Vladimir pour l informatique, Guillaume pour l auto-méca et Ahmed pour l électronique) qui ont planifié le travail de leur petite «équipe» au fur et à mesure de l avancement du projet. La chef de projet (Florence) leur demandait régulièrement de lui transmettre le nouveau planning et leur demandait à intervalle régulier où ils en étaient par rapport à la planification transmise. Cela lui a permis de garder un regard vigilant par rapport aux deadlines, et une vision globale du projet. Figure 57: Gantt pôle mécanique au S7 Quant à la planification de tout ce qui n était pas technique, c est la chef de projet qui s en ait chargé grâce à sa connaissance de l avancée globale du projet. Elle a ainsi produit des GANTT pour cadrer le travail de l ensemble de l équipe, comme celui ci-dessous pour la fin de projet. Figure 58: Planification pour la fin de l année 2.8.2 Recherche d outils plus avancée La tâche de la chef de projet était ainsi plutôt répétitive, dans le sens où elle devait souvent regarder les plannings puis envoyer des mails de rappel aux membres de l équipe. Florence a donc essayé de trouver un outil interactif qui enverrait automatiquement des mails aux personnes concernées de l équipe projet et les informerait de là où ils sont censés être dans le planning. Elle a ainsi trouvé un logiciel nommé Project or Ria, qui réunit tous les outils dont elle avait besoin. Page 85/173 Partie 2

2.8.2.1 DESCRIPTION DE PROJECT OR RIA : Project Or RIA est un logiciel de gestion de projets. Open Source. Son nom signifie Project Organizer Rich Internet Application. Son utilisation est encore peu répandue mais la contribution d une communauté croissante lui a permis d atteindre un niveau de maturité et de fiabilité suffisant pour pouvoir être déployé en mode opérationnel. 2.8.2.2 SES FONCTIONNALITES : Définition des projets et sous-projets : description et liens hiérarchiques entre projets Gestion de documents : définition des documents, lien avec les versions et fichiers correspondants Gestion des tickets : demandes, anomalies (bug tracking),... Gestion des activités : phases, tâches, assignation des ressources... Gestion des jalons : dates clés, livrables,... Planning : planification des activités, pilotée par la charge et présentée sous forme de Diagramme de Gantt Gestion des réunions : suivi des réunions Définition des paramètres environnementaux : clients, contacts, projets, utilisateurs, équipes, ressources, affectations Gestion des habilitations et restrictions d accès Envoi de mails automatiques lors des changements d états Définition d indicateurs et envoi automatique de rappels et d alertes Attachement de pièces jointes sur chaque élément Ajout de notes sur chaque élément Historique des mises à jour de chaque élément Mais malheureusement, le logiciel installé et paramétré, il était impossible d envoyer des mails automatiquement. Le logiciel essayait bien de les envoyer, mais il y avait un échec d envoi à chaque essai. L idée a donc été abandonnée lorsqu en février de 2ème année le problème n était toujours pas résolu. Troisième partie La suite... 3.1 Futur du projet L Activité Projet ne consiste pas simplement en la réalisation d un livrable, il est également important qu il se traduise par quelque chose de concret qui va pouvoir être utilisé après la fin du projet. En ce sens, nous allons voir dans cette partie l avenir que pourra avoir notre projet, et comment notre travail pourra être réutilisé par la suite. 3.1.1 Utilisation à l école Tout d abord, notre livrable final est le robot RALF, et celui-ci va être remis à M. Bourdeaud huy, pour qu il puisse l utiliser dans le cadre de son électif Intelligence Ambiante. Dans le cadre de notre projet, nous nous sommes principalement concentrés sur la réalisation d une base fonctionnelle, et nous avons mis en place les fonctionnalités importantes ainsi que celles qui nous paraissaient délicates à implémenter (contrôle vocal, détection de visage,... ). D autres, comme par exemple, la communication en Bluetooth avec un smartphone, ont été laissées de côté et il reste encore de nombreuses fonctions qu il est possible d implémenter à notre robot. De plus, nous avons également laissé la possibilité d ajouter facilement de nouvelles fonctionnalités au niveau de notre code. Notre projet devrait donc pouvoir être utilisé dans le cadre d un mini-projet à l école sans avoir à modifier tout ce que nous avons fait. Il pourrait permettre à des élèves de se faire Page 86/173 Partie 3

la main sur un objet communiquant entièrement modifiable et d apprendre à manipuler un système Linux avec des contraintes de systèmes embarqués. On pourrait également imaginer l utilisation de notre robot comme base d un projet G1-G2 qui consisterait en l ajout de nouvelles fonctionnalités innovantes et nécessitant davantage de travail. Dans ce cas, le groupe projet aurait l avantage de pouvoir commencer à travailler directement sur les implémentations pratiques après s être approprié notre base. 3.1.2 Partage avec la communauté Open Source L autre aspect important de notre projet est son ouverture à la communauté Open Source. Nous avons en effet essayé d adapter notre projet au maximum pour que celui-ci puisse bénéficier et être utilisable par cette communauté. Nous avons donc consacré une partie de notre temps à suivre les tendances actuelle et à analyser les réalisations existantes dont on pourrait s inspirer ou qui pourraient être améliorées. Nous avons ainsi choisi d utiliser un Raspberry Pi, car ses caractéristiques nous convenaient, mais également parce qu il est très utilisé par la communauté Open Source en ce moment. Nous avons ainsi pu nous appuyer sur de nombreux articles existants sur des blogs ou des forums pour nous donner des pistes à explorer pour implémenter nos fonctions. En retour, nous avons mis en ligne un site web (http ://ralf.ec-lille.fr) avec des explications permettant de pouvoir refaire intégralement notre robot. En pratique, nous ne nous attendons pas à ce que quelqu un refasse exactement notre robot mais plutôt qu il puisse reprendre certains éléments pour réaliser un autre projet plus ou moins similaire au nôtre. Ainsi, après la fin du projet, la partie physique du projet pourra être réutilisée par des élèves de l école pour réaliser des projets leur permettant d apprendre à travailler sur ce type d objets. D un autre côté, la partie logicielle pourra permettre d aider d autres projets à mettre en place des fonctions similaires grâce à la documentation présente sur notre site. Page 87/173 Partie 3

3.2 Futur du projet L Activité Projet ne consiste pas simplement en la réalisation d un livrable, il est également important qu il se traduise par quelque chose de concret qui va pouvoir être utilisé après la fin du projet. En ce sens, nous allons voir dans cette partie l avenir que pourra avoir notre projet, et comment notre travail pourra être réutilisé par la suite. 3.2.1 Utilisation à l école Tout d abord, notre livrable final est le robot RALF, et celui-ci va être remis à M. Bourdeaud huy, pour qu il puisse l utiliser dans le cadre de son électif Intelligence Ambiante. Dans le cadre de notre projet, nous nous sommes principalement concentrés sur la réalisation d une base fonctionnelle, et nous avons mis en place les fonctionnalités importantes ainsi que celles qui nous paraissaient délicates à implémenter (contrôle vocal, détection de visage,... ). D autres, comme par exemple, la communication en Bluetooth avec un smartphone, ont été laissées de côté et il reste encore de nombreuses fonctions qu il est possible d implémenter à notre robot. De plus, nous avons également laissé la possibilité d ajouter facilement de nouvelles fonctionnalités au niveau de notre code. Notre projet devrait donc pouvoir être utilisé dans le cadre d un mini-projet à l école sans avoir à modifier tout ce que nous avons fait. Il pourrait permettre à des élèves de se faire la main sur un objet communiquant entièrement modifiable et d apprendre à manipuler un système Linux avec des contraintes de systèmes embarqués. On pourrait également imaginer l utilisation de notre robot comme base d un projet G1-G2 qui consisterait en l ajout de nouvelles fonctionnalités innovantes et nécessitant davantage de travail. Dans ce cas, le groupe projet aurait l avantage de pouvoir commencer à travailler directement sur les implémentations pratiques après s être approprié notre base. 3.2.2 Partage avec la communauté Open Source L autre aspect important de notre projet est son ouverture à la communauté Open Source. Nous avons en effet essayé d adapter notre projet au maximum pour que celui-ci puisse bénéficier et être utilisable par cette communauté. Nous avons donc consacré une partie de notre temps à suivre les tendances actuelle et à analyser les réalisations existantes dont on pourrait s inspirer ou qui pourraient être améliorées. Nous avons ainsi choisi d utiliser un Raspberry Pi, car ses caractéristiques nous convenaient, mais également parce qu il est très utilisé par la communauté Open Source en ce moment. Nous avons ainsi pu nous appuyer sur de nombreux articles existants sur des blogs ou des forums pour nous donner des pistes à explorer pour implémenter nos fonctions. En retour, nous avons mis en ligne un site web (http ://ralf.ec-lille.fr) avec des explications permettant de pouvoir refaire intégralement notre robot. En pratique, nous ne nous attendons pas à ce que quelqu un refasse exactement notre robot mais plutôt qu il puisse reprendre certains éléments pour réaliser un autre projet plus ou moins similaire au nôtre. Ainsi, après la fin du projet, la partie physique du projet pourra être réutilisée par des élèves de l école pour réaliser des projets leur permettant d apprendre à travailler sur ce type d objets. D un autre côté, la partie logicielle pourra permettre d aider d autres projets à mettre en place des fonctions similaires grâce à la documentation présente sur notre site. Page 88/173 Partie 3

3.3 Industrialisation du projet Android Ici nous allons envisager l industrialisation de notre robot Android, c est-à-dire le processus de fabrication de produits manufacturés avec des techniques permettant une forte productivité du travail. Nous pouvons très aisément constater que notre projet est parfaitement adapté à l industrialisation, car celui-ci projet comporte 3 grands pôles qui s inscrivent dans cette démarche d industrialisation. Tout d abord le pôle informatique a créé l ensemble des programmes nécessaires au bon fonctionnement du robot, or ces programmes ne sont pas créé pour un robot unique, ils peuvent être installés sur une multitude de robot. La seule difficulté de l industrialisation concernant la partie informatique est donc l implémentation du code, ce qui est une difficulté minime. Et si on veut améliorer le temps de calcul du robot et donc le temps de réaction, une étude peut être menée antérieurement afin d optimiser le code des différents programme mais concernant la production de plusieurs robot, un seul et unique programme est nécessaire pour l ensemble des robots. Ensuite, concernant le pôle électrique, les plans des différentes cartes nécessaires pour l alimentation des composants du robot sont déjà effectués, il ne reste plus qu à les produire à grande échelle, ce qui n est pas une difficulté majeure car nous n utilisons aucun composant onéreux ou nécessitant des précautions particulières pour les monter. Enfin, le pôle mécanique a méticuleusement noté l ensemble des difficultés qui sont apparues lors du montage du robot, avec les solutions que nous avons trouvé. Nous connaissons donc la totalité du processus de fabrication de notre robot, avec une modélisation précise sous CATIA qui assure l accessibilité de l ensemble des dimensions de nos composants et la position de ceux-ci. Il est donc aisé de reproduire ce qui nous a été très délicat à faire dans un premier temps, car en théorie plus aucun imprévu n apparaitra durant la fabrication et le montage. Figure 59: Maintenant il ne faut pas oublier que le robot que nous avons créé au cours de ces deux années de projet est un prototype, et que faute de moyen illimité et de temps nous avons dû faire des choix concernant les fonctionnalités et les processus de fabrication de notre robot. Dès lors, envisager l industrialisation du robot permet aussi d envisager des processus de fabrication plus onéreux mais plus rapides, ainsi que de donner plus de fonctionnalité au robot afin qu il soit plus attractif. Par exemple, il faut mentionner qu initialement nous souhaitions que la coque de notre robot soit Page 89/173 Partie 3

totalement créée grâce à la technologie d impression 3D. Or cette méthode était trop couteuse pour notre budget, mais beaucoup plus adapté à l industrialisation que la création de chaque partie du robot avec des processus de fabrication totalement différent. En effet, l impression 3D nécessite uniquement d avoir accès à une imprimante 3D, ensuite elle nécessite uniquement la résine et le plastique nécessaire à effectuer l impression, l ensemble de la modélisation nécessaire pour faire l impression 3D étant déjà réalisée par notre groupe projet. Alors que la fabrication des pièces de manière individuelle comme nous l avons effectué nécessite un plus grand nombre de machine, une planification plus importante et surtout il est extrêmement plus difficile de produire des robots similaires avec l incertitude qui existe dans la fabrication des pièces de manière individuelle. Comparaison des deux méthodes Nous allons effectuer maintenant une étude concernant l industrialisation et la rentabilité de l impression 3D. Celle-ci comportera bien entendu des approximations mais nous certifions que celles-ci sont justifiées et documentées. Nous envisagerons les deux modes de fabrication pour la carcasse du robot, avec pour mode de travail le travail en «Trois Huit». Dans un premier temps, calculons la rentabilité de chaque méthode pour une production d un robot par heure. Sachant que nous avons fabriqué les bras par impression 3D en 10 heures, nous estimons la création de l ensemble de la carcasse par impression 3D à 35 heures. La première estimation importance est d établir le prix, que nous fixons à 170 euros. L ensemble des autres estimations sont présentes dans les tableaux suivants, qui présentent le raisonnement pour déterminer au bout de combien de jours la production d un robot par heure devient rentable. Il ne faut pas omettre que nous ne prenons pas en compte les dépenses liées à la commercialisation et donc au marketing du robot, mais ces dépenses sont les mêmes pour les deux types de fabrication, nous ne les aborderons donc pas. Figure 60: Première méthode Page 90/173 Partie 3

Figure 61: Deuxième méthode On constate donc que la première méthode est plus rentable sur le court terme, avec une durée de rentabilité plus courte. Figure 62: Etude sur le long terme Ici nous pouvons voir ce qui se passe si l on continue ces modes de fabrication plus longtemps. On constate que la fabrication avec l impression 3D devient plus rentable que l autre méthode au bout de 216 jours. Il convient toutefois de modérer ce résultat, car l impression 3D reste une technologie récente et donc relativement incertaine et sujette à des améliorations, notamment quant à la qualité de la surface produite par impression 3D et la durée nécessaire pour imprimer. De plus, nous avons comparé uniquement deux types d industrialisation, mais si la production du robot était totalement automatisée comme dans les grandes usines, la fabrication avec l imprimante 3D ne serait plus rentable à cause du temps de production du robot beaucoup trop grand par rapport aux autres manipulations. Dans ce cas il faudrait bien entendu revoir toute la méthode et le processus de fabrication de notre robot et trouver un autre moyen de créer les bras de notre robot. C est pourquoi deux solutions sont possibles : soit créer notre robot entièrement à l impression 3D, mais ce type d industrialisation nécessite d attendre que cette technologie se développe davantage afin de réduire le temps de production des imprimantes 3D. Ou alors revoir entièrement le processus de fabrication de notre robot, car si nous avons tout fait pour permettre la reproductibilité de notre robot, utiliser une imprimante 3D pour faire uniquement les bras est extrêmement peu adapté à l industrialisation et la diversité des machines-outils que nous avons utilisé nuit aussi à la rentabilité de l industrialisation. En conclusion, il est nécessaire de faire des études quant à l évolution future des imprimantes 3D et sur la création d un nouveau mode opératoire pour la création du robot dans une usine totalement automatisée. Page 91/173 Partie 3

Figure 63: Tableau récapitulatif Dès lors, l industrialisation de notre robot est totalement possible, et le fait que notre projet soit OpenSource permet à n importe quelle personne qui le souhaite de lancer l industrialisation de notre robot, ce qui sera un merveilleux aboutissement pour notre projet, et concrétiserait deux années d effort. Page 92/173 Partie 3

Conclusion Le projet Android fut un projet très complexe d un point de vue technique et donc un défi de taille pour les 7 étudiants que nous sommes. En effet, quatre domaines techniques étaient concernés, et demandaient des compétences poussées. Nous avons réussi à relever le challenge dans le sens où dans chaque domaine un travail considérable a été réalisé et a abouti un procédé qui fonctionne. Mais la partie la plus complexe est l assemblage de toutes ces parties pour former un seul et même robot, et c est là que nous avons eu en fin de compte le moins de temps. Le résultat final est satisfaisant, mais aurait bien sûr pu être encore mieux si nous avions eu par exemple les 2 semaines de vacances de Pâques comme cela se faisait chaque année jusqu à présent. Mais cette expérience a été très enrichissante pour nous tous d un point de vue technique comme d un point de vue personnel (voir retours individuels et collectifs). Cela n a pas été facile tous les jours mais le travail accompli est considérable, et le projet G1-G2 est sûrement l expérience centralienne la plus instructive tout en étant la plus difficile de notre scolarité. Page 93/173 Partie 4

Annexes Table des matières 1 Retours Individuels 3 1.1 Florence Bohnes........................................ 3 1.2 Alexandre Chakroun...................................... 3 1.3 Stéphane Coulon........................................ 4 1.4 Maxence Dallongeville..................................... 4 1.5 Vladimir Dombrovski...................................... 5 1.6 Guillaume Jaeg......................................... 5 1.7 Ahmed Trabelsi......................................... 6 2 Retour collectif 7 3 Annexe : Fabrication 8 3.1 22/01/14 : 1ère séance au laboratoire de mécanique avec Philippe Quaegebeur...... 8 3.2 Modélisation de la solution trouvées sous CATIA...................... 9 3.3 29/01/14 : 2ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 9 3.4 10/02/14 : 3ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 10 3.5 Modélisation de la solution trouvées sous CATIA...................... 11 3.6 17/02/14 : 4ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 12 3.7 11/03/14 : 5ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 12 3.8 19/03/14 : 6ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 13 3.9 Modélisation de la solution trouvées sous CATIA...................... 13 3.10 26/03/14 : 7ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 13 3.11 27/03/14 : 8ème séance au laboratoire de mécanique avec Philippe Quaegebeur..... 14 4 Annexe : Recherche de solution pour la motorisation des bras 15 4.1 Recherche de solutions (Florence et Stéphane)........................ 15 4.2 Solutions adoptées (Guillaume, Florence et Stéphane)................... 15 4.2.1 Transmission de mouvement :............................. 15 4.2.2 Mise en place du bras :................................ 15 4.3 Calculs des engrenages (Florence)............................... 15 5 Solutions pour la motorisation de la tête 17 5.1 Recherche de solutions..................................... 17 5.2 Calculs sur les engrenages :.................................. 17 5.3 Réunions avec les consultants................................. 17 5.4 Solutions adoptées....................................... 18 6 Annexe : Tutoriel pour modéliser les bras de RALF sous CATIA 19 6.1 Création de la partie allongée du bras............................ 19 6.2 Création de la rondelle qui relie le bras au corps...................... 22 6.3 Volume............................................. 24 6.4 Creux pour centrer l engrenage................................ 24 7 PLANS 25 8 Annexe pôle électronique 31 8.1 Utilisation d Altium...................................... 31 8.2 Carte micro........................................... 31 8.3 Etude sur la puissance sonore nécessaire........................... 32 8.4 Carte amplificateur audio................................... 33 8.5 Carte LED........................................... 34 8.6 Carte Bouton......................................... 35 Page 1 Annexes

8.7 La carte pont H moteur.................................... 35 8.8 Carte Shield........................................... 36 Annexe pôle automatique 37 Articles 51 Budget 52 Plaquette 58 Bons de commande 59 Etude de multidimensionnalité 62 Page 2 Annexes

1 Retours Individuels 1.1 Florence Bohnes Le projet G1-G2 a été une expérience très enrichissante sur de nombreux plans. Tout d abord par rapport au travail en équipe, ce qui était une nouveauté pour moi. Fraichement sortie de prépa où le travail individuel est de rigueur, organiser une équipe et travailler ensemble sur un sujet était un grand changement. Malgré les difficultés survenues au long des deux années qu a duré ce projet, nous avons toujours réussi à rebondir et à continuer ce projet ambitieux coûte que coûte. La gestion du groupe, qui est en fin de compte le cœur du management d équipe, est extrêmement complexe. Il faut arriver à s adapter à chaque personnalité pour arriver à faire avancer le projet au mieux, en fonction des attentes divergentes de chacun. Ensuite, la semi absence d encadrement a été une des facettes du projet les plus formatrices de mon point de vue. Nous avons été lancés quasiment seuls sur un projet de plusieurs mois, alors que nous n avions même pas fait de projet de quelques heures auparavant. Nous avons du faire preuve d autonomie du début à la fin, et prendre de nombreuses décisions sans aide extérieure, sur des points qui pouvaient changer tout notre projet. Cela nous a ainsi beaucoup appris sur la confiance en soi et en ses décisions. Bien sûr, nous avons pris certaines fois de mauvaises décisions et avons été contraints de revenir sur nos pas, d apprendre de nos erreurs et de recommencer en sachant mieux ce que nous faisions. Cela nous a appris sur comment réagir aux problèmes en temps réel, comment s adapter. Personnellement, je me suis sentie perdue à plus d une reprise durant ces 2 années, et cela a été dur de repartir ensuite, de trouver une solution aux problèmes auxquels j étais confronté. Par rapport à la gestion de projet, nous avons des cours, des TD, qui nous apprennent les outils de base, mais ils n arrivent pas toujours au bon moment par rapport à notre avancée. Ils ne pourraient d ailleurs pas arriver au bon moment pour tous les projets. Par rapport à la technique, les consultants peuvent nous aider, mais ce sont avant tout des professeurs qui ont des obligations extérieures au projet et ne peuvent pas nous tenir par la main du début à la fin. Ainsi le projet G1-G2 a été certaines fois frustrant, perturbant, décourageant ou rageant, mais dans la globalité ce fut une expérience unique que peu d écoles proposent à leurs étudiants et incroyablement enrichissante aussi bien d un point de vue technique que personnel. D ailleurs aujourd hui déjà, c est un atout remarquable pour trouver des anecdotes par rapport à notre expérience «professionnelle» lors d un entretien. 1.2 Alexandre Chakroun Le projet G1-G2 a pour moi été une expérience très enrichissante. Il m a permis de développer mes compétences tant au niveau technique qu en gestion de projet. Nous ne sommes bien sûr pas des spécialistes de toutes les techniques de gestion de projet que nous avons pu voir mais savoir qu elles existent et en connaître les bases constitue déjà un avantage pour le futur, selon moi. Du point de vue technique, j ai eu l occasion de me former à un nouveau langage qu est le python, ainsi qu à des techniques de programmation plus généralement qui seront adaptables dans toutes les situations plus tard. Ce projet m a montré de plus les problèmes qui peuvent se présenter lorsque l on travaille en équipe, et j ai pu découvrir quelques solutions qui pourront, je pense, m être bien utiles dans des situations de ma future vie professionnelle. Les soucis de cohésion et donc d efficacité de l équipe sont en effet apparus comme primordiaux pour l avancement du projet, et les solutions que nous avons mises en place comme les QHP ont prouvés leur efficacité. Si j avais à émettre un regret, ce serait probablement le fait que nous n avons pas pu aller assez loin dans le projet pour voir RALF se comporter comme nous l avions imaginé au tout début. Un peu plus de temps nous aurait permis d avancer plus les fonctions très haut niveau du robot, ce qui est en somme le plus remarquable quand on découvre un projet terminé. Comme vous pouvez le remarquer j ai choisi d axer ce retour d expérience sur l avenir car c est pour moi l objectif principal qui ressort après deux ans de participation à l activité projet. Page 3 Annexes

1.3 Stéphane Coulon Alors que la fin de l activité projet se rapproche de plus en plus, il convient de se poser la question suivante : qu ai-je tiré de cette expérience? Comment a-t-elle été vécue? Il est bien sûr un peu tôt pour répondre de façon complète à cette question, dans la mesure où le projet n est pas encore complètement terminé, et que je manque de recul sur le projet. Cependant, il est déjà possible d apporter quelques éléments de réponse. D abord, l élément qui est pour moi le plus important de l activité projet : le travail en équipe. Même si les APP du début d année donnaient un aperçu de ce qu était le travail dans une équipe de 6 à 7 membres ; mener un projet si long avec une équipe fait apparaître de nouvelles problématiques. Maintenir la cohésion et l efficacité du groupe durant une période prolongée n est pas facile. D ailleurs, durant la première année, le groupe était presque scindé en deux. Pour des raisons techniques, comme les compétences requises par le projet étaient séparées en plusieurs parties distinctes, nous avons travaillé séparément. Ceci a fini par peu à peu séparer le projet en deux groupes qui étaient presque distincts, la partie mécanique/automatique d une part et la partie informatique/électronique d autre part. La fin de la première année a été difficile, les mauvais résultats obtenus lors de la soutenance ont été durs à encaisser, mais cela nous a permis de prendre conscience de l état déplorable du projet à cette date. C est ainsi que nous avons commencé la deuxième année gonflés à bloc après les vacances, déterminés à rattraper la situation et à nouveau soudés. Un autre aspect important de l activité projet est la gestion de projet. en effet, les différents amphis et TDs ont rythmé la première année, mais étaient un peu frustrants ; j ai eu parfois l impression d avoir passé plus de temps à travailler sur ces TDs que sur le projet en lui-même. Rétrospectivement, beaucoup des notions évoquées en Gestion de Projet nous ont été très utiles, et sans cela nous n aurions pas eu les outils nécessaires à la bonne conduite du projet. Etude des risques, valorisation, planification, budget... tout ceci sera utile en milieu professionnel. Pour conclure, je dirais que le projet a connu pour moi des hauts et des bas, des moments de fierté et de motivation, ou au contraire des moments de stress ou de démoralisation. Personnellement, j en aurai tiré une bonne expérience du travail en équipe, une occasion de mettre en pratique des notions de gestion de projet, ainsi qu un moyen de mettre en relation les cours reçus à Centrale avec des problèmes concrets 1.4 Maxence Dallongeville L Activité Projet représente pour moi une opportunité pour l élève-ingénieur de mettre en relation plusieurs domaines : une partie technique, une partie rédaction de rapports ainsi qu une partie gestion de projet. Elle nous permet ainsi d aborder ces différentes composantes du métier d ingénieur dans le cadre d un projet de taille relativement importante par rapport aux projets scolaires que nous avions pu mener jusque-là, et ce, en essayant de n en négliger aucune car elles sont toutes importantes pour la bonne réussite du projet. Ainsi, celui-ci m a permis d apprendre à effectuer un travail à mi-chemin entre les exercices plutôt théoriques et assez encadrés qui nous pouvons effectuer en cours, et le travail très orienté technique et pratique que j ai pu effectuer dans mes projets personnels. J ai par exemple pu apprendre à documenter le travail au fur et à mesure que je l effectuais afin de garder une trace et de pouvoir expliquer facilement par la suite le travail effectué plusieurs mois auparavant. J ai pu aussi découvrir les difficultés que l on peut avoir pour s organiser en groupe et pour répartir les tâches en fonction des compétences des différents membres de l équipe et afin de pouvoir les effectuer en parallèle. Idéalement, il faudrait pouvoir délimiter précisément qui est responsable de l exécution de quelle tâche et à quel moment afin d éviter les ambiguïtés potentielles sur le travail à réaliser. Il peut par exemple être difficile de savoir s il vaut mieux déléguer une tâche, et il vaut donc mieux essayer, dans la mesure du possible de mettre ça au clair à l avance. En pratique, cette délimitation n est souvent pas réalisable en un temps acceptable. En effet, j ai également appris à quel point il pouvait être délicat d estimer à l avance le temps que prendra une tâche pour être réalisée. Il est en effet nécessaire de respecter un minimum le planning en surveillant le chemin critique afin de ne pas pénaliser les autres pôles en aval qui peuvent avoir besoin de notre travail. Mais les contraintes extérieures, les problèmes inopportuns, notre manque d expérience en gestion de projet et le nombre d heures de disponibilité de chacun variant en fonction Page 4 Annexes

des semaines font que la plupart des estimations que nous avons pu effectuer se sont finalement révélées assez éloignées de la réalité. Le travail en groupe a également tendance à diminuer significativement l efficacité du travail réalisé. La séparation du travail en différents pôles de compétences spécialisés implique en effet de devoir organiser le travail mais également de devoir transmettre au fur et à mesure les informations dont les autres membres peuvent avoir besoin sans les surcharger de données inutiles. Je regrette toutefois que nous n ayons pu avancer davantage sur la partie pratique du projet. La plupart des groupes projet semblent avoir eu ce problème. Je n ai pas l impression que cela vienne d une sous-estimation par les différents groupes du temps disponible, ni d un problème d organisation de ces groupes. Je pense plutôt que cela pourrait venir de l organisation générale de l activité projet : les jalons successifs permettent de donner une bonne idée du travail à effectuer au fur et à mesure mais au final, ils sont inadaptés pour la plupart des groupes projet. En effet, les différents projets ont généralement tendance à ne pas aborder les mêmes points au même moment, en fonction de leur domaine, de leur envergure, ou par exemple de leur état d avancement dans la recherche de partenaire. Les différentes équipes peuvent ainsi avoir tendance à passer du temps pour effectuer ce travail alors qu elles ne sont pas au moment le plus propice pour le faire. Finalement, l activité projet est une expérience plutôt enrichissante pour l élève-ingénieur centralien car elle lui permet de mettre en œuvre ses différentes compétences généralistes de manière transverse, et constitue ainsi une première avancée permettant d approcher le fonctionnement de l entreprise. 1.5 Vladimir Dombrovski Le projet G1-G2 reste à mes yeux avant tout une expérience professionnelle. En effet, au moment où le projet sera terminé, chacun des membres en tirera sa propre expérience. Une expérience enrichissante certes, mais surtout une expérience réelle, composée de moments forts comme de moments difficiles. Une expérience à laquelle j ai eu la chance de participer, et lors de laquelle j ai pu montrer mes talents tout comme j ai pu commettre des erreurs. Travailler dans le projet RALF, c était aussi et surtout travailler avec des personnes, qui ne partagent pas mes avis ni mes passions. Des personnes que j ai du apprendre à connaître, à apprécier et parfois à supporter. C est en me plaçant au sein du groupe que j ai eu l occasion de trouver mon rôle dans l équipe. Un rôle que je serai en mesure d assurer plus tard dans le monde du travail, en utilisant le vécu acquis lors de ce projet. Le projet est aussi pour moi un moyen de montrer mes compétences en tant que futur ingénieur cadre, de relever des défis dans la réalisation d un projet long et complexe, et de se faire une idée très précise du déroulement d un projet. Car outre les compétences techniques apprises tout au long des deux ans, j ai également appris à organiser un groupe, et m organiser moi. Le projet m a donné des outils et des clés pour mener à bien un projet, et je reste persuadé que ces clés me serviront plus tard pour m ouvrir des portes dans le monde professionnel. Un monde professionnel que j ai également pu découvrir à travers ce projet. Un monde composé d entreprises pouvant devenir d éventuels partenaires ou des clients. Un monde composé de flux, d activités, d innovations. Un monde dans lequel il est possible de se donner les moyens de réussir et de réaliser ses rêves. Un monde, où la négociation et la coopération jouent des rôles prédominants. Tant d enjeux sur lesquels le projet m a fait ouvrir les yeux. Des enjeux que je garderai à l esprit en entrant sur le marché du travail dans pas longtemps. En somme, le projet reste pour moi une expérience hors pair, caractérisée par sa multidimensionnalité qu il n est possible de saisir qu en devenant un véritable acteur et en jouant son rôle au sein du groupe tout au long des deux années. 1.6 Guillaume Jaeg A mes yeux, le projet G1-G2 est à la fois l aboutissement et la quintessence de la formation centralienne. En effet, notre projet à la particularité de mettre en application les divers domaines de l ingénierie, qui sont l informatique, l électronique, l automatique et l informatique. Certes nous n étions pas tous investis et versés dans l ensemble ces domaines durant le projet, du fait de notre décision à séparer le projet en différents pôles travaillant de concert, toutefois nous avons tout mis en œuvre afin de Page 5 Annexes

rapprocher ces pôles et d informer l ensemble des membres des avancées de chaque pôle. Ceci explique pourquoi j ai parlé d aboutissement de la formation centralienne, nous avons dans ce projet mis en application une grande partie de nos enseignements, et malgré plusieurs échecs, nous avons dépassé nos acquis pour apprendre par nous-même et élargir les vastes connaissances que l Ecole nous a offertes. Je vais mentionner maintenant le travail en équipe, en effet le projet m a appris à effectuer un travail sur moi-même afin d éviter de frustrer une personne ou d en gêner une autre, quitte à accepter une charge de travail plus importante ou d omettre une partie de la vérité lors de la rédaction d un compte rendu. Ainsi, l apport principal du projet reste pour moi un enseignement sur soi-même et sur la prise en compte de la personnalité des autres membres, ce qui change radicalement de l enseignement des Classes Préparatoires aux Grandes Ecoles, qui m a appris à tirer le meilleur de moi-même en ignorant les réactions des autres. Le projet est donc un excellent moyen de se sociabiliser et d apprendre à interagir avec d autres personnes dans des moments d urgence et des situations critiques, à faire des concessions afin que tous les partis soient satisfaits de l accord. Pour résumer, le projet est un excellent outil pour étudier sa personnalité et trouver ses défauts pour pouvoir les amoindrir et travailler en groupe efficacement. En outre, les deadlines imposées par les nécessités du projet ont poussé mon sens de l organisation à l extrême, car ayant des responsabilités que je ne peux pas ignorer dans la vie associative centralienne, j ai dû organiser chaque minute de mes semaines lors des périodes de crise afin de pouvoir satisfaire toutes mes obligations. Ces moments où l organisation a été maximisée m a appris mes limites en termes d endurance et de responsabilité que je peux supporter. Cet enseignement que j ai acquis malgré moi me servira certainement dans le futur, pour ne pas accepter trop de responsabilité et ne pas crouler sous le poids d un excès de devoir et d obligation. Ainsi, ce projet m a surtout permis de découvrir de nouvelles limites, différentes de celle que j ai dû surmonter en Classes Préparatoires aux Grandes Ecoles. Ces nouvelles limites sont beaucoup plus susceptibles d intervenir dans le monde de l entreprise et auraient pu me causer un préjudice si le projet ne me les avait pas montrés de manière si évidente. 1.7 Ahmed Trabelsi Le projet G1-G2 a été pour moi une expérience assez marquante tant sur le côté pédagogique que sur le côté professionnel. J ai pu toucher plusieurs domaines techniques comme l informatique où l électronique. J ai même approfondi plusieurs notions et appris de nouveaux outils de travails essentiels au travail d ingénieurs. L aspect très pratique du projet, dans la mesure où on ne s arrête pas l étude technique de la solution mais qu on la réalise nous-même, m a permis de réaliser l écart entre le côté théorique et le côté pratique des sciences de l ingénieur. J ai aussi pu apprendre d avantage sur le fonctionnement d un projet en groupe, l organisation et la coordination au sein de l équipe. Ceci à travers des outils de gestion de projet qui nous était présenté tout au long de la formation. A part le côté technique, cette expérience m a permis de comprendre les habitudes avec lesquelles il fallait aborder un consultant ou une personne extérieure au projet qui n est pas forcément intéressé par le projet où n a tout simplement pas le temps pour nous aider. En effet, j ai appris à être concis et structurer mes questions pour bien faciliter la tâche au consultant pour qu il m aide à la fois convenablement et à cœur ouvert. D une façon plus générale, même si au début je me sentais assez contraint par le travail en groupe parce que tout d abord je n avais pas l habitude de travailler ainsi, j ai pu au fur et à mesure comprendre à la fois l utilité et l efficacité de ce que ça pourrait apporter. En effet, j ai mis du temps à bien m organiser et coordonner mes efforts avec le reste du groupe à fin de ne pas gêner l avancement des autres membres ou me gêner moi par l avancement des autres. Page 6 Annexes

2 Retour collectif Nous sommes tous d accord pour dire que le projet est une expérience qui nous servira énormément lorsque nous rentrerons dans la vie professionnelle car il nous apprend énormément dans tous les domaines qui touchent l ingénieur : la technique, mais aussi la gestion de projet, la rédaction de rapport et le travail en groupe. Tout d abord d un point de vue scientifique, le projet a permis à chacun d entre nous de développer un domaine qui l intéresse, et d aboutir à quelque chose qui fonctionne. Les domaines qui touchaient notre projet étaient nombreux, c est pourquoi chacun a du approfondir de manière intense le domaine qu il étudiait. Cela a été une difficulté car la quantité de travail a été énorme en technique, mais nous ne pouvions pas négliger les autres paramètres du projet. Cela a également posé des problèmes en 1ère année car l équipe a été scindée en deux groupes. Nous avons dû réagir vite et ainsi nous avons créé le Quart d Heure du Peuple (QHP). Cette décision a rendue notre année de G2 beaucoup plus efficace. Ensuite, le projet nous a appris comment travailler en groupe. Cela a été totalement nouveau pour nous tous, venant de classes préparatoires. L accord entre les membres du groupe n a pas toujours été évident, mais nous avons toujours su régler nos différents et laissé passer le projet avant nos personnes afin de garder une cohésion. Prendre sur nous et accepter des tâches obligatoires à contre cœur sont des situations qui nous sont arrivées, mais nous nous sommes soutenu pour surmonter ces difficultés. Enfin, la gestion de projet est une clé que nous avons découverte pour la réussite de projets ambitieux comme le nôtre. Malheureusement, les TD et amphis sont souvent arrivés au mauvais moment, ce qui a pu perturber la bonne avancée du projet à cause des livrables de gestion de projet qui prennent beaucoup de temps à rédiger. La répartition des tâches é aussi été difficiles au début, mais quand nous avons appris à nous connaître un peu mieux, tout s est arrangé. Finalement, ce qui a globalement frustré tous les membres du groupe projet est le fait de n avoir pas pu exploiter plus en profondeur le potentiel du robot construit. Le temps en fin d année a manqué, et nous aurions rendu un travail bien meilleur si nous avions eu les vacances d avril car nous n aurions pas eu les partiels et dossiers d électif en parallèle. Après la fin du projet, nous pourrons prendre du recul, et peut-être que bien d autres réflexion nous viendront quant à ce que le projet aura été ou pas été, mais pour l instant voici c est ce qui sort de nos analyses juste quelques semaines avant la soutenance finale. Page 7 Annexes

3 Annexe : Fabrication Après avoir passé plus d un an à chercher les solutions optimales pour construire notre robot, nous avons enfin pu commencer, en janvier 2014, la fabrication du prototype. Ce document sert à retracer les différentes étapes que nous avons suivies, les difficultés rencontrées et les solutions trouvées. 3.1 22/01/14 : 1ère séance au laboratoire de mécanique avec Philippe Quaegebeur Lors de cette séance, nous avons usiné plusieurs pièces avec l aide de Philippe Quaegebeur et de certains de ses collègues du labo méca : Couper le tuyau qui sert de corps au robot de la bonne taille (tuyau vendu par le labo de l Ecole). Usiner une plaque de plastique plane de forme ronde pour le bas du robot. Nous avons également abordé une solution technique concernant le centrage de la tête par rapport au corps. Solutions évoquées : Coller un tube de plastique creux femelle au centre haut de la tête et coller un tube de plastique mâle sur l axe central pour pouvoir emboiter les 2 permettre le centrage. Coller un tube de plastique mâle sur l axe central et fixer une plaque percée au centre au plus bas dans la tête pour permettre le centrage. Solution retenue La 2ème solution a été retenue, en soulignant le fait qu avec la présence des éléments dans la tête comme la caméra, il faudrait faire une forme de plaque particulière. C est la solution la plus sûre pour un centrage parfait à cause de la distance entre l élément centreur et le corps. Page 8 Annexes

3.2 Modélisation de la solution trouvées sous CATIA Suite à la recherche de solution, la plaquette a été modélisée sous le logiciel de CAO CATIA : 3.3 29/01/14 : 2ème séance au laboratoire de mécanique avec Philippe Quaegebeur Nous avons continué l usinage lors de cette séance : Couper des cylindres de diamètre petit afin d en faire les pieds du robot. Coller la plaque du bas du robot et les pieds du robot pour en faire un ensemble solidaire. Percer le corps afin d y faire les trous pour le micro, les câbles d alimentation et le haut parleur. Page 9 Annexes

3.4 10/02/14 : 3ème séance au laboratoire de mécanique avec Philippe Quaegebeur Lors de cette séance nous avons rencontré des problèmes techniques par rapport au mouvement des bras. En effet, ayant reçu les engrenages qui serviront pour faire bouger ceux-ci, nous avons enfin pu parler en ayant le matériel que nous allions utiliser sous les yeux et certaines contraintes se sont présentées à nous. Tout d abord, comment fixer l engrenage à l arbre du moteur? Problème : Le moteur a un arbre très court, et le bout de l arbre doit être équipé d un petit embout de plastique parmi ceux fournis. Nous disposons d une croix, d un rond, d un rail. Solution retenue : La 2ème solution a bien entendu été retenue. Pour centrer l engrenage avec précision, nous allons devoir usiner une petite pièce bi-diamètre qui se glisse d un côté dans l engrenage et de l autre dans l embout. Cette solution engendre un décalage de l engrenage par rapport à la plaque : il sera sur-élevé. Il faut donc trouver comment sur-élever le reste des engrenages. Pour cela nous allons tout simplement utiliser le fait que certains de nos engrenages sont doubles. Il reste un seul engrenage qui serait au niveau de la plaque. Nous utiliserons donc une sorte de coussinet pour le remonter à la hauteur des autres. Aucune autre solution n a été abordée car ces solutions très simples seront amplement suffisantes. Page 10 Annexes

3.5 Modélisation de la solution trouvées sous CATIA Page 11 Annexes

3.6 17/02/14 : 4ème séance au laboratoire de mécanique avec Philippe Quaegebeur Nous avons pu lors de cette séance : Couper à la bonne taille la plaque utilisée pour les engrenages des bras. La trouer de manière à pouvoir y encastrer et visser le moteur et placer les engrenages. Nous avons également reçu les bras du robot, qui ont été confectionnés à l imprimante 3D. Nous les avons poli et avons collé les engrenages qu il faut à l emplacement prévu à cet effet. 3.7 11/03/14 : 5ème séance au laboratoire de mécanique avec Philippe Quaegebeur Nous avons lors de cette séance : Réalisé l axe bi-diamètre qui servira à fixer l engrenage sur le moteur des bras Réalisé un coussinet en acier qui ré haussera le deuxième engrenage de 10 dents pour les bras (solutions trouvés en séance 3) Fixé les engrenages, les bras et le moteur sur la plaque prévue à cette effet Page 12 Annexes

3.8 19/03/14 : 6ème séance au laboratoire de mécanique avec Philippe Quaegebeur Nous avons rencontré durant cette séance plusieurs problèmes concernant le centrage de la tête. Nous avons donc réfléchi à une solution technique pour centrer de manière précise l axe qui dépassera dans la tête. Nous sommes arrivés à la conclusion que la seule solution possible est d ajouter une plaque à la limite haute du corps qui servirait dans un premier temps à fixer le moteur et dans un 2ème temps à centrer l axe central. De plus nous avons usinés quatre plaques de plastique rondes pour : Le bas du «bocal à cornichon» Le centrage de l axe dans la tête (voir séance 1) Le mouvement de la tête Le centrage de la tête dans le corps 3.9 Modélisation de la solution trouvées sous CATIA 3.10 26/03/14 : 7ème séance au laboratoire de mécanique avec Philippe Quaegebeur Fait lors de la séance : Trous pour les yeux Trous pour la bouche Trous dans la plaque de centrage corps pour pouvoir fixer le moteur et faire passer l axe. Page 13 Annexes

DPE 3.11 27/03/14 : 8ème séance au laboratoire de mécanique avec Philippe Quaegebeur Fait lors de la séance : Usinage de la pièce en plastique pour permettre à l engrenage de se fixer à l arbre du moteur Usinage de l axe central du robot Trou pour la couronne Trou pour l axe dans le bas de la plaque du «bocal à cornichon» Réalisation de trous dans la plaque de centrage corps pour que les fils puissent passer Découpage de la forme non usuelle dans la plaque de centrage de l axe dans la tête Nous avons rencontré quelques difficultés lors du perçage de la plaque pour la couronne. En effet, les machine n étant pas faite pour usiner le plaque, la plaque avait une élasticité top grande et s est mise à vibrer violemment jusqu à se détacher des mandrins et voler à travers la machine. Nous avons ainsi fendu la pièce de plastique et avons dû recommencer. Toutes les pièces étant usinée, il ne nous restait plus qu à les assembler et peindre le robot en vert. Page 14 Annexes

4 Annexe : Recherche de solution pour la motorisation des bras 4.1 Recherche de solutions (Florence et Stéphane) Réunion avec Philippe Quaegebeur le 20/09/13 Deux solutions sont sélectionnées pour la transmission de mouvement parmi toutes celles discutées avec le consultant : 1ère solution : Utiliser un système d engrenages pour réduire la vitesse d un moteur unique et transmettre le mouvement aux deux bras. 2ème solution : Utiliser un système de ficelles (pantin) pour transmettre le mouvement aux deux bras, après avoir réduit la vitesse d un moteur unique grâce à un réduction mécanique. Deux solutions sont sélectionnées pour la mise en place des bras de manière physique parmi toutes celles discutées avec le consultant : 1ère solution : Bras détachables du système de motorisation avec un clip. On enlèverait donc les bras du corps avant d enlever tout le centre avec le principe du bocal à cornichons. 2ème solution : Bras solidaires du système de motorisation et comportant à leur extrémité un engrenage ancré. Le système de motorisation des bras serait donc retiré par le haut du corps du robot grâce à une fente, et indépendant des autres composants internes. 4.2 Solutions adoptées (Guillaume, Florence et Stéphane) Suite à des discussions au sein du pôle, nous avons de décidé de retenir les solutions suivantes : 4.2.1 Transmission de mouvement : 1ère solution : Utiliser un système d engrenages pour réduire la vitesse d un moteur unique et transmettre le mouvement aux deux bras. Raison : Il existe des engrenages peu chers et en plastique dans le commerce, et les calculs pour trouver ceux qui conviennent sont plutôt faciles, contrairement à l achat d un réducteur. De plus il y a le risque que les ficelles cassent ou se détendent. 4.2.2 Mise en place du bras : 2ème solution : Bras solidaires du système de motorisation et comportant à leur extrémité un engrenage ancré. Le système de motorisation des bras serait donc retiré par le haut du corps du robot grâce à une fente, et indépendant des autres composants internes. Raison : Faire un clip est complexe en soi, et surtout cela manquerait de rigidité. Le risque de casser le bras lorsqu on l enlève est élevé, alors que les inconvénients du système choisi sont moindre (esthétique surtout). 4.3 Calculs des engrenages (Florence) Nous voulons que le bras fasse environs un tiers de tours en une seconde, soit : Vbras=0.333 tr/s Le servomoteur que nous allons utiliser a une vitesse de : Vmoteur= 0.126 s/(60 degrès) =1.32 tr/s Il nous faut donc un rapport de transmission de : Page 15 Annexes

Or la formule est la suivante : Conclusion : Il n y a pas besoin d une vis sans fin, deux roues dentées de 10 et 40 dents suffisent pour chaque bras. Il existe des assortiments de roues dentées en plastique peu chères, parmi lesquels nous pouvons sûrement trouver ce qu il nous faut. Si l on utilise des roues dentées de module 1, les roues de 40 dents auront un diamètre de 42mm et les roues de 10 dents un diamètre de 12mm. Notre robot ayant un diamètre de 150mm, voici une solution possible : Page 16 Annexes

5 Solutions pour la motorisation de la tête 5.1 Recherche de solutions Réunion interne du pôle : Il faut qu il y ait une réduction de la vitesse du moteur. De plus il faut qu il y ait une plaque sur le bas de la tête pour pouvoir poser et fixer les composants comme la caméra. De plus il faut que la tête soir fixée sur le bas du corps. Problème : comment allier tous ces points? Après un brainstorming actif, nous avons déduit que la tête serait reliée au reste du robot grâce à un emmanchement (liaison cylindre-cylindre) au centre. Pour permettre la présence de cette tige et de la réduction, nous ne pouvons mettre de plaque sur toute la surface basse. Nous mettrions donc une plaque percée au milieu. Plusieurs solutions ont été trouvées par le groupe projet pour la réduction : Couronne + engrenage : mettre une couronne sur l intérieur de la plaque du bas de la tête et un engrenage sur le moteur. Engrenage + engrenage : mettre un engrenage sur la tige centrale et un engrenage sur le moteur. Pour décider de quelle solution est la meilleure, nous allons voir M. Quaegebeur. 5.2 Calculs sur les engrenages : Nous voulons que la tête fasse environs un tour en 3 secondes, soit : Vbras=20 tr/min Le moteur que nous allons utiliser a une vitesse de : Vmoteur= 1000 tr/min Il nous faut donc un rapport de transmission de Or la formule est la suivante : Conclusion : C est très important. 5.3 Réunions avec les consultants Réunion avec Philippe Quaegebeur le 25/10/13 Tout d abord, la réduction que nous voulons est énorme. Il faut donc en priorité essayer de ralentir directement la vitesse de rotation du moteur, soit en changeant de moteur, soit en l alimentant avec une tension inférieur. Problèmes potentiels : est-ce que cela va poser des problèmes pour l asservissement (vitesse réduite = précision réduite)? Est-ce que le couple serait alors suffisant? Sinon, entre la couronne et les engrenages, il conseille plutôt la couronne car elle permet une réduction plus importante. Il propose également plusieurs autres solutions : Train épicycloïdal Harmonic Drive Page 17 Annexes

Mais ce sont des solutions plutôt couteuses. Cela nécessiterait des recherches approfondies pour trouver du matériel dans des prix abordables pour nous. Pour le capteur de rotation il conseille de prendre celui d une vieille souris d ordinateur. Consultation d Alexandre Kruszewski le 15/11/13 Après des calculs de vitesse minimum du moteur, et confirmation par consultation d Alexandre Kruszewski, nous concluons que le moteur peut beaucoup diminuer de vitesse. Nous décidons donc de chercher comment réduire le plus la vitesse pour des prix raisonnables. 5.4 Solutions adoptées La solution de la couronne semble la meilleure d un de vue montage et réduction. Le choix de couronnes sur internet est assez limité. Nous nous décidons donc pour une couronne de la marque HPC, fournisseur de l école. Nous pouvons avoir une couronne à 60 dents, de module 0.8, pour 35 euros. Page 18 Annexes

6 Annexe : Tutoriel pour modéliser les bras de RALF sous CATIA Nous avons eu la chance de pouvoir imprimer les bras de notre robot grâce à une imprimante 3D. Nous avons donc du modéliser ces bras sous un logiciel de Conception Assistées pas Ordinateur CATIA. Voici les étapes grâce auxquelles quelqu un pourrait refaire ces bras. Grâce à l électif CAO Avancée j ai appris à utiliser le surfacique et le volumique. J ai donc pu former des surfaces complexes afin de les transformer en volumes. Tout d abord il faut aller dans le menu et choisir l environnement «Generative Shape Design». Dans le set géométrique, nous allons créer puis assembler les surfaces qui nous serviront à créer le volume désiré. 6.1 Création de la partie allongée du bras 1. Créer d un cylindre de 20mm de rayon. 2. Créer 2 points qui seront le centre des bouts arrondis. Page 19 Annexes

3. Autours du premier point, créer une sphère de même rayon que le cylindre : 20mm. 4. Créer un plan passant par ce même point 5. Grâce à l outil découpage, couper le cylindre à la hauteur du plan. Page 20 Annexes

6. Grâce à l outil découpage, couper la sphère à la hauteur du plan. 7. Faire de même avec le deuxième point. 8. Utiliser l outil Assembler pour ne former qu une seule pièce avec le cylindre et les 2 sphères ainsi découpée. Page 21 Annexes

Le bras est maintenant formé. 6.2 Création de la rondelle qui relie le bras au corps 1. Esquisser un cercle Page 22 Annexes

2. Extruder ce cercle des 2 côtés 3. Créer 2 nouveaux repères à égale distance du centre dans la direction Y. Tracer une droite dans chacun des plans et extruder la droite. Cela forme des plans parallèles. 4. Grâce aux outils découpage et assemblage, former la rondelle. Page 23 Annexes

6.3 Volume Créer une surface épaisse. Importer ce volume dans le corps principal. 6.4 Creux pour centrer l engrenage Afin que l engrenage que l on veut coller sur le bras soit centrer, nous allons faire un creux dans le bras directement. Nous nous servons de l outil habituel pour faire les creux : Poche. Le bras de RALF est terminé. Il s agit là du bras droit. Pour le bras gauche, il suffit de faire la poche de l autre côté de la rondelle. Page 24 Annexes

7 PLANS Page 25 Annexes

Page 26 Annexes

Page 27 Annexes

Page 28 Annexes

Page 29 Annexes

Page 30 Annexes

8 Annexe pôle électronique 8.1 Utilisation d Altium Altium est un logiciel de CAO d électronique très puissant qui permet à la fois de créer les schémas électroniques, des circuits et de générer les schémas des circuits imprimés. Altium fonctionne avec des bibliothèques qui contiennent à la fois des empreintes schématiques, des composants et les empreintes des composants sur les circuits imprimés. Il faut d abord faire le schéma électronique de la carte puis Altium le transforme automatiquement en circuit imprimé en affichant les composants et les interconnections qu il faut faire. Ensuite, il faut faire un travail de routage qui consiste à construire les interconnections entre les composants. Altium propose un service qui fait le routage automatiquement, mais n est en général pas très optimisé car il construit une seule interconnexion à la fois, alors que l utilisateur a une vision globale des interconnections à faire. Tout l art de construire les circuits imprimés est le choix de la disposition des composants sur la carte avant le routage. En effet, cette étape peut faire de l étape de routage, une étape facile ou difficile. Les règles à adopter lors de cette phase est de rapprocher les composants qui ont des interconnections et mettre le composant qui a le plus d interconnections au milieu de la carte. Altium gère la fabrication des cartes multicouches. Dans un souci d optimisation nous allons essayer de construire des cartes simples couches, et le cas échéant en doubles couches. Un des atouts d Altium est la facilité à modéliser des composants non présents dans les bibliothèques. En effet en ayant les dimensions mécaniques, il est possible de modéliser le composant en 3D sur Altium et d observer la carte finale en 3D. Toutes les cartes réalisées dans ce projet ont été faites sur Altium. 8.2 Carte micro La carte micro a été conçue comme expliqué dans la partie électronique avec un micro électret d entrée de gamme qui a coûté au projet 1 euro, ce qui est un grand avantage. Sur le schéma nous pouvons observer le micro, à gauche, avec un premier étage de polarisation et de filtration réalisé par la résistance R2 et le condensateur C1. Nous avons ensuite un étage d amplification réalisé avec un composant actif à savoir l amplificateur opérationnel MCP601. Le choix de ce composant a été principalement conditionné par sa tension d alimentation. En effet, le MCP601 doit être alimenté à ses bornes par 5-6V en VCC et 0V disponible par notre hub USB ce qui va nous éviter d apporter une nouvelle source d alimentation. L AO est branché en montage dérivateur inverseur à cause du condensateur C1 mis en amont de la broche négative inverseuse. Il va par ailleurs fonctionner en régime idéal puisque nous avons mis une boucle entre la broche de sortie et la broche d entrée inverseuse. Les deux résistances R3 et R4 permettront de centrer le signal à la moitié de la tension d alimentation de l AO puisqu elles réalisent un pont diviseur de tension de coefficient 1/2 que l on branche sur la broche non inverseuse de l AO. Cet artifice nous permettra de fixer la référence du signal de sortie à Vcc/2 ce qui nous permettra d éviter les problèmes de saturation de l AO. En appliquant la relation de Millman à la patte 2 de l amplificateur nous obtenons la relation suivante entre la tension obtenue directement aux bornes du micro et la tension calculée à la sortie de l amplificateur : Page 31 Annexes

V S = R 1 C 1 dv micro dt + V CC 2 Le condensateur C4 a pour rôle d éliminer la composante continue Vcc/2 à la sortie de l AO pour ne récupérer que la partie alternative. C est un filtre passe haut. A l issue de ce circuit, on ne récupère que le signal oscillant, généré par le micro, amplifié et déphasé de 2π puisqu on effectue deux filtrations de 1er ordre avec des fréquences assez éloignées de la fréquence de coupure. Le déphasage n est pas un problème puisque toutes les fréquences subissent le même déphasage ce qui ne va pas déformer le signal initial. Pour finir, les capacités C3 et C2 sont là pour stabiliser l alimentation. Ainsi après tous les essais décrits dans la partie DPE, nous avons modélisé la carte sur le logiciel Altium pour pouvoir l imprimer mécaniquement. Faute d avoir l empreinte exacte du micro sur Altium, nous avons remplacé le micro par une résistance sur le schéma et sur le fichier PCB. La sortie micro sera ensuite reliée à l alimentation par des connecteurs molex qui assureront la rigidité mécanique des connections. Elle sera aussi relié à la carte son USB à travers un fil avec un connecteur molex d un côté et un fil jack de l autre. Nous avons appris après la construction de la carte que généralement les cartes son apportent l alimentation nécessaire directement par le fil jack et nous aurions pu éventuellement alimenter la carte micro ainsi. Comme on peut observer sur la figure 3, le 1 correspond à la masse, le 3 correspond au signal et le 2 correspond au Vcc. Pour les fils jack n ayant que 2 contacts, l alimentation est apportée sur la même broche que le signal. C est un facteur à prendre éventuellement en compte. 8.3 Etude sur la puissance sonore nécessaire Afin d étudier la puissance nécessaire qui doit être délivrée par les haut-parleurs, il faut connaitre le niveau de bruit ambiant autours du robot. En effet pour que les ondes sonores délivrées par les haut-parleurs soient audibles, il faut qu elles aient une puissance plus forte que le bruit sonore présent dans l environnement du robot. L onde sonore est générée par la vibration de l air donc une différence de pression. Ainsi pour la quantifier, on utilise le Pascal. Pour faciliter le calcul, on utilise une autre échelle qui présente le gain par rapport au son audible le plus faible en pression. Cette unité s exprime en db (décibel). En se référant au site suivant : http ://www.antibruit.org/echelle.htm, nous avons pu connaitre approximativement le niveau sonore ambiant dans un bureau qui sera quotidiennement l environnement du robot RALF. La figure 4 donne 40db pour un bureau. Nous allons donc avoir besoin d un son avec une puissance sonore de 50 db. Le deuxième critère à prendre en compte est la diminution du niveau de puissance sonore lorsque l onde parcours un certaine distance. La figure 5 donne une échelle du rapport de gain d une même onde calculée entre deux points distants. Page 32 Annexes

Donc en prenant comme hypothèse une distance maximale de 5m entre le robot et l utilisateur, nous allons avoir besoin de rajouter 15db de gain pour que le signal délivré par le robot ait une puissance de 50db lorsqu il atteint l utilisateur. Finalement, nous aurons besoin d un hautparleur qui délivre minimalement, 65db. 8.4 Carte amplificateur audio Pour construire notre circuit amplificateur audio en amont du haut-parleur, nous nous sommes basés sur un amplificateur de classe D. Le composant utilisé est un composant CMS fabriqué par Texas Instrument référencé tpa2000d1(figure 6) En explorant la datasheet de ce composant et l exemple fourni par la maison de fabrication nous avons pu faire un schéma minimal qui va pouvoir être exploité pour ce composant(figure 7) Nous allons maintenant expliquer la fonction de la majorité des composants présents sur le schéma. Les deux condensateurs C1 etc2 permettent un filtrage passe-haut qui va assurer uniquement l amplification de la composante alternatif du signal venant de la carte son. La résistance de R4 et le condensateur C5 permettent la configuration de l oscillateur interne de l amplificateur en les connectant sur les broches ROSC et COSC. La fréquence de cet oscillateur va déterminer la fréquence de hachage de l amplificateur. La datasheet donne une fréquence égale à 6.6/(R1*C1) qui doit être comprise, pour le bon fonctionnement de l amplificateur, entre 200MHz et 300MHz. Ici en l occurrence, nous avons une fréquence de 250MHz avec R1=120k et C5=220pF. L amplificateur audio a quatre niveaux d amplification qui sont réglables par les entrées Gain 1 et Gain 0 en les connectant à travers une résistance pour 1 ou à la masse pour 0. Dans notre cas nous Page 33 Annexes

avons mis les deux entrées sur 1 pour obtenir le gain le plus élevé. Les résistances R2 et R5 vont assurer cette fonction. La broche SHDN active l amplificateur si elle est alimentée. Elle est faite pour ajouter une fonction muette si l on souhaite. En l occurrence, on l a mise en permanence sous tension en l alimentant à travers la résistance R1. Les condensateurs C11 et C10 permettent un filtrage basse fréquence qui va éliminer la composante qui se rajoute après le hachage. Sans faire d essais nous avons procédé à la fabrication de la carte amplification son avec le schéma de la figure 8. La soudure de circuit a été faite au four car tous les composants sont des composants CMS. 8.5 Carte LED Pour construire la carte LED nous avons eu recours à des transistors MOSFET qui vont nous permettre de constituer l étage d amplification de puissance. En effet, les transistors fonctionneront comme des relais qui vont être commandés par le biais du Raspberry Pi pour alimenter les LEDs à travers l alimentation du HUB USB. Le circuit est shématisé sur la figure suivante. Nous pouvons observer que les deux yeux contiennent 3 LEDs commandées par paires à travers le même transistor. Nous avons choisi de mettre des résistances en amont de chaque LEDs pour s assurer de l équilibrage des intensités traversants chacune des leds. En effet, en mettant une résistance pour chaque paire de LED, nous ne sommes pas sûrs d avoir des intensités quasi égales parcourant les leds. Les résistances R7, R8 et R9 assurent que les grilles des transistors sont bien reliées à la masse lorsque les transistors ne sont pas commandés. Les transistors utilisés sont des transistors CMS référencés IRLM2402. La datasheet nous donne pour une tension, entre la grille et la source, de 3.3V qui est celle délivrée par le Raspberry Pi, un canal Drain Source qui peut laisser passer 8A et nous obtenons une tension de 1V entre le Drain et la Source. Donc nous n avons pas de limitation au niveau de l intensité qui traverse les LEDs. Pour s assurer d avoir une intensité aux alentours de 10mA parcourant les LEDs, nous avons pris des résistances de 150Ω. Nous avons par ailleurs deux connecteurs molex. L un qui va apporter l alimentation et l autre qui va ramener la commande à partir du rasberry Pi. Le figure 10 illustre le schéma du circuit imprimé : Page 34 Annexes

8.6 Carte Bouton La carte bouton est une carte très simple qui va contenir un petit bouton poussoir. Celui-ci se comportera comme un interrupteur en étant un circuit fermé si on appuie dessus et vice versa. Le bouton va tout simplement être relié à un port GPIO programmé en entrée et une alimentation à travers une résistance comme schématisé sur la figure 11. Comme on n avait pas l empreinte du bouton poussoir sur Altium, il a fallu construire nous-même l empreinte schématique et celle sur le circuit imprimé qui sont shématisés sur les figures 12 et13. Finalement nous avons pu construire le modèle qui sera imprimé sur la carte (Figure 14). 8.7 La carte pont H moteur Comme expliqué dans la partie DPE, il nous faut un pont H avec des diodes de roues libres. Ce pont sera réalisé à travers 4 transistors MOFSET (bipolaires) comme sur le schéma suivant. Page 35 Annexes

Le schéma du circuit imprimé est représenté sur la figure 16 : 8.8 Carte Shield La carte shield contiendra la connexion à l alimentation ainsi que toutes les autres cartes. Elle contiendra aussi une capacité pour stabiliser l alimentation. Le dimensionnement de cette capacité doit être fait en connaissant les variations possibles du courant et l impédance de notre circuit. La capacité se branchera en parallèle avec l alimentation et donnera un filtra passe bas qui coupera toutes les fréquences au-dessus de la fréquence de coupure 1/(2πZC), Z étant l impédance du système. Comme on ne connait pas la valeur de l impédance ainsi que la fréquence de bruitage du courant, nous allons mettre une capacité de 100 nf qui pour une impédance d entrée du circuit égale à 10k Ω donnera une fréquence de coupure aux alentours de 10Hz. Donc toutes les variations de courant plus grandes que 10Hz seront éliminées. Ci-dessus le schéma électronique de la carte ainsi que le circuit imprimé. Page 36 Annexes

Annexe Automatique Introduction : Dans le cadre de notre projet Android, nous avons été confrontés à l asservissement d un moteur dont nous n avions pas les caractéristiques. Nous allons montrer dans ce document comment nous avons réussi à établir les constantes principales du moteur, puis la mise en place du modèle de notre asservissement, enfin la modélisation de celui-ci sous MatLab. Présentation du problème Notre robot Android doit pouvoir suivre l utilisateur avec sa tête, cela signifie une reconnaissance de l utilisateur grâce à la caméra. De plus, le moteur chargé de faire tourner la tête sera asservi, afin que le centre de la tête soit orienté vers l utilisateur et que celui-ci ne sorte pasdu champ de vision du robot. Par souci budgétaire, ce moteur a été récupéré d un autre système, mais semble pouvoir convenir à notre problème. Cahier des charges : Tout d abord il s agit de poser le problème. C est pourquoi nous aborderons dans un premier temps le cahier des charges qui nous étaient imposées. La consigne sera échantillonnée de manière non négligeable, avec un retard conséquent (entre 200 et 500ms a priori) Le moteur est alimenté sous +/-5V Adapter le moteur au système Avoir une précision de 10 Avoir un temps de réponse de 2 seconde Présentation du système : Voici de manière simpliste le système et une brève explication : 1

La caméra nous fournit l information sur la position de l utilisateur, celle-ci est transmise au microprocesseur (un RaspBerryPi) qui analyse cette information et l envoie au moteur par le biais d un pont H (qui permet de contrôler le sens de rotation du moteur). La vitesse du moteur est recueillie par un capteur optique grâce à deux roues codeuses, cette information est envoyée au RaspBerryPi qui l analyse. Maintenant que nous avons brièvement présenté notre objectif, nous allons rentrer plus dans les détails et expliquer notre démarche de manière didactique, afin qu une personne voulant asservir un moteur aux caractéristiques inconnues puisse le faire en se basant sur notre expérience. Modélisation du moteur : Dans un premier temps, il convient de modéliser le moteur. Schéma d un moteur à courant continu Voici le schéma électrique équivalent classique d un moteur à courant continu. Nous disposons de deux types d équation pour modéliser ce moteur : L équation électrique (Loi des mailles) : 3 ( ) ( ) ( ) ( ) L équation mécanique (Principe Fondamental de la Dynamique) : ( ) ( ) ( ) Les équations électromécaniques : 5 ( ) ( ) ( ) 2

Ces équations sont classiques, je ne vais donc pas les démontrer dans ce document. On utilise alors la transformation de Laplace, ce qui nous donne : 6 ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) Dès lors, on peut obtenir la fonction transfert du système : 7 ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )( ( ) ( )) ( ) ( ) ( ) Nous obtenons ainsi la vitesse de rotation du moteur en fonction de l entrée ( ( )) et du couple résistant généré par la charge ( ( )). Maintenant que le moteur est modélisé grâce à l équation précédente, cela va nous permettre de déterminer les caractéristiques de notre moteur. 3

Caractérisation du moteur Afin de connaitre parfaitement le fonctionnement du moteur, il nous faut déterminer les différentes inconnues de l équation : Détermination de Pour déterminer cette grandeur, on se place en régime permanent et on fait fonctionner le moteur sans charge mécanique. Ainsi ( ) et Donc il nous reste uniquement : ( ) ( ) ( ) ( ) ( ) Ainsi, il est aisé de connaitre k, il suffit d alimenter le moteur sous 5 volts, sans charge mécanique et en régime permanent et de relever la vitesse de rotation du moteur, ce qu on a fait grâce à un tachymètre. Nous obtenons pour une tension d alimentation de 5 volts une vitesse de rotation de 1489 tr/min, soit 248 rad/s. On trouve ainsi k = 0.032 V.s /rad ( ) ( ) Détermination de On veut désormais connaitre la résistance interne du moteur. Pour cela, on va alimenter le moteur et bloquer la rotation du moteur et placer en série du moteur une résistance R 2, on obtient ainsi grâce à l équation k ( ) que la force contre-électromotrice est nulle. Ainsi si on réutilise l équation : ( ) ( ) ( ) ( ) On élimine e m (t) car celle-ci est nulle dans cette manipulation : ( ) ( ) ( ) De plus, comme on se place en régime permanant avec pour tension d entrée U= 5V, il n y a pas de variation d intensité : D où 4 ( ) =0 ( ) ( )

Il suffit dont juste d utiliser un ohmmètre pour déterminer. On obtient ainsi. Détermination de Une fois déterminé, nous pouvons mesurer l inductance du moteur. Pour cela, on branche en série avec le générateur et le moteur une résistance R 1 de 67 Ω. Nous avons donc le circuit suivant : 13 On va mesurer à l aide d un oscilloscope la tension aux bornes de la résistance R 1. On obtient ce genre de courbe lorsque l on allume le générateur, avec : Il s agit donc d évaluer sur l oscilloscope au bout de combien de temps on atteint la valeur finale de la tension, pour récupérer le temps de montée 3 de la tension aux bornes de la résistance et ainsi obtenir et. 5

Les mesures du temps de montée donnent les résultats suivants : Mesure n Temps de montée (µs) 1 232 2 400 3 420 4 350 5 300 6 410 7 320 On constate qu il y a une grande différence dans nos mesures du fait de la mauvaise qualité des générateurs à alimentation stabilisée, qui nous fournissaient un signal d entrée peu stable et donc nos mesures sont peu fiables, d où le grand nombre de mesure que l on a effectué. En moyenne cela donne : 347 µs C est-à-dire τ = 115 µs Et comme on obtient : = 19mH 6

Détermination de Nous allons maintenant chercher le moment d inertie de l ensemble d éléments qui forme la tête, je vais par la suite me référer à l image ci-dessous pour expliquer les approximations que nous allons effectuer Couronne Comme vous pouvez le constater, de nombreux élément logent dans la tête. Il est donc délicat de calculer de manière exacte le moment d inertie équivalent de l ensemble de la tête, nous avons donc dû procéder par approximation. Ainsi, voici les approximations que nous avons faites, sachant que nous avons préféré surestimer : Nous allons considérer que : La demi-sphère creuse à un rayon de 152mm, une épaisseur de 2mm et une masse de 108 g La plaque ici en vert est un disque de rayon 60 mm et d épaisseur 3mm en PVC 7

La plaque inférieure est anneau de 152 mm de diamètre extérieur et 68mm de diamètre interne, avec une épaisseur de 3mm en PVC La couronne est un anneau de 68mm de diamètre extérieur et 47 mm de diamètre interne, avec une masse de 30g Nous allons négliger l influence du microphone et des LED dans ce calcul de Nous avons donc : ( ) L apparition du est due au rapport de réduction crée par l engrenage. Nous allons utiliser la formule : Cela donne kg.m² ( ) = 2.89 ( ) kg.m² On obtient au final 2.74 8

Modélisation et simulation sous MatLab (simulink) Après avoir obtenu l ensemble des caractéristiques le système modélisé sous MatLab : Tout d abord voici la modélisation de la caméra et du traitement d image sous MatLab: Nous avons donc deux entrées : la position angulaire de l utilisateur et la position angulaire de la tête, on effectue la différence entre ces deux positions pour l angle que la tête doit faire pour pouvoir fixer l utilisateur. Dès lors il faut prendre de compte deux phénomènes que nous avons modélisé avec les deux blocs «Zero-Order Hold» et «Delay». Le premier bloc permet d échantillonner le résultat, comme il le sera dans notre système réel, et le deuxième rajoute un délai. L échantillonnage du signal et le délai sont générés à cause du temps de calcul nécessaire à l analyse de la vidéo. Nous obtenons donc en sortie de l analyse et du traitement de la vidéo ce signal : 9

En effet, nous avons considéré que l utilisateur se déplaçait à vitesse constante dans une seule direction, nous pouvons donc approximer l entrée comme étant une rampe. Nous pouvons voir le type de signal biaisé que le moteur va recevoir, car en retard et échantillonné. Nous allons décomposer l asservissement du système en deux parties : une partie discrète et une partie continue. La partie discrète fournira une consigne de vitesse à partir des informations délivrées par la caméra, et la partie continue consiste en un simple asservissement de vitesse du moteur pour suivre cette consigne. Nous ne tiendrons pas compte dans cette étude du couple résistant. Partie continue : Pour mémoire, voici la fonction de transfert du moteur : ( ) ( ) On constate que le terme d ordre 2 est négligeable devant les autres, pour ce calcul on considèrera donc le moteur comme un système du premier ordre, de fonction de transfert : ( ) ( ) On remarque que la constante de temps est trop élevée par rapport au temps de réponse désiré. Nous allons donc asservir le système à l aide d un correcteur PI pour le rendre plus rapide tout en assurant sa précision. ( ) ( ) ( ) ( ) ( ) ( ) 10

On aimerait que le comportement du système asservi soit dix fois plus rapide. Pour cela, on va placer pour ce système d ordre 2 un pôle double égal au pôle du système simple multiplié par 10. On obtient : Ce modèle n est pas suffisamment représentatif. En effet, la tension d alimentation du moteur est limitée par la tension d alimentation du robot (5V). Il est donc impossible de commander le moteur au-delà de +/-5V. Le système devient : Et voici la réponse indicielle : Le système est plus lent que prévu, mais ne pourra en aucun cas aller plus rapidement. La vitesse du moteur est limitée, et l accélération ne peut dépasser la valeur qu elle a en boucle ouverte. 11

Partie discrète : Le système complet peut maintenant être modélisé ainsi : Pour permettre de donner des résultats satisfaisants, nous allons implanter l équivalent discret d un correcteur PD en sortie. Une correction PD est en effet nécessaire, car l information nous arrive avec un retard non négligeable ; pour commander efficacement le système, il est nécessaire d anticiper son évolution à l aide d une composante dérivée (il s agit en réalité seulement d une dérivée à gauche). De plus, pour éviter les problèmes de saturation liés à l asservissement de vitesse, nous allons limiter la commande à 90% de la vitesse maximale atteignable par le moteur (saturation logicielle). Ceci nous empêche cependant d utiliser un correcteur intégral, puisque les phénomènes de saturations risqueraient de rendre l intégrale instable. Voici donc le système asservi complet : 12

Nous allons tester ce modèle dans deux cas : L utilisateur tourne autour du robot avec une vitesse angulaire constante (ici 0.5 rad/s) L utilisateur fait des allers retours devant le robot =>modélisés par une sinusoïde d amplitude 0.5 rad et de période 2s Nous avons déterminé de manière empirique les paramètres du correcteur PD discret : ( ) Voici les résultats : 13

En Jaune, la position de l utilisateur, en violet, la position de la tête du robot, et en bleu l information délivrée par la caméra. On remarque que le système suit la position de l utilisateur, tout en conservant le retard causé par le traitement de l image. Dans le cas de la consigne en rampe, on pourrait «rattraper» ce retard en ajoutant une composante intégrale, mais cette dernière ne fait qu ajouter des écarts avec la consigne en rampe. De plus, comme le système est facilement sujet à des saturations, rajouter une composante intégrale pourrait le rendre instable. 14

Articles Article de presse Bonjour, Nous sommes une équipe de sept élèves-ingénieurs de l Ecole Centrale de Lille et nous souhaitons construire un robot dont le design rappelle le logo Android. Celui-ci pourra interagir avec son utilisateur, fournira diverses informations se trouvant sur internet ou sur son téléphone (par exemple les mails, les SMS, la météo), suivra l utilisateur de la tête afin de permettre de prendre une vidéo toujours centrée sur l utilisateur et l identifiera grâce une reconnaissance faciale. Notre robot sera surtout, et avant tout, un objet divertissant qui s intègrera aussi bien dans une maison que dans un environnement intelligent. En effet, il sera amené à agir et, sous les ordres de son propriétaire, à effectuer des actions telles qu allumer la lumière ou ouvrir les volets. La partie logicielle que nous installons utilise des technologies de communication modernes (Bluetooth, Wifi) avec des composants tout aussi récents (RaspberryPi) lui permettant d être fonctionnel, pratique, et innovant. De plus, notre projet a pour particularité d être totalement ouvert aux suggestions externes, cela se traduit par l étude des commentaires et des remarques que nous recevons sur notre site ou notre adresse mail afin d optimiser le fonctionnement de notre robot. En effet notre projet est en OpenSource et toutes les informations concernant les difficultés rencontrées ainsi que nos solutions techniques se trouvent sur notre site internet, tant pour la partie informatique que pour la partie mécanique. Nous comptons donc sur vos avis et vos commentaires afin de nous aider à la réalisation de notre projet. Plus d infos : http ://ralf.ec-lille.fr/ pjandroid@googlegroup.com Article pour les forum Bonjour, Avec la multiplication des appareils audiovisuels et high-tech dans nos foyers, nous devons gérer un flux d information de plus en plus complexe. Voulant proposer une solution à ce problème, nous souhaitons construire un robot qui pourra interagir facilement avec son utilisateur, lui fournira diverses informations se trouvant sur internet ou sur son téléphone (par exemple les mails, les SMS, la météo). En effet, nous sommes une équipe de sept élèves-ingénieurs et menons le projet «Robot Android» qui a pour but de concevoir un robot d environ 20 centimètres de haut dont le design rappelle le logo Android. Ce sera donc un intermédiaire, un filtre programmable entre le flux d informations se trouvant sur internet et l utilisateur qui pourra recevoir les informations qui lui sont nécessaires au moment propice grâce à ce robot. Ce projet exige de vastes savoirs et compétences, bien sûr en informatique pour gérer les connections aux différents réseaux, mais aussi en mécanique et automatique car le robot sera apte à bouger la tête afin de suivre l utilisateur du regard pour pouvoir le filmer dans ses déplacements. Pour cela, nous utilisons une reconnaissance faciale grâce à notre microprocesseur (un RaspberryPi). Celui-ci est codé en python et contrôle deux moteurs permettant la rotation de la tête et celle des bras de notre Page 51 Annexes

robot que nous avons asservi en position. Notre robot sera surtout, et avant tout, un objet divertissant qui s intègrera aussi bien dans une maison que dans un environnement intelligent. En effet, il sera amené à agir et, sous les ordres de son propriétaire, à effectuer des actions telles qu allumer la lumière ou ouvrir les volets. La partie logicielle que nous installons utilise des technologies de communication modernes (Bluetooth, Wifi) qui lui permettent d être intelligent et fonctionnel, notamment grâce à la reconnaissance vocale. Ce robot sera donc un partenaire intelligent avec lequel on peut communiquer naturellement et obtenir des réponses concrètes. Notre projet a pour particularité d être totalement ouvert aux suggestions externes, cela se traduit par l étude des commentaires et des remarques que nous recevons sur notre site ou notre adresse mail afin d optimiser le fonctionnement de notre robot. En effet notre projet est en OpenSource et toutes les informations concernant les difficultés rencontrées ainsi que nos solutions techniques se trouvent sur notre site internet, tant pour la partie informatique que pour la partie mécanique. Cela permet à notre projet d être compréhensible par tous, reproductible et personnalisable par l utilisateur averti. Plus d infos : http ://ralf.ec-lille.fr/ pjandroid@googlegroup.com Page 52 Annexes

BUDGET PROJET RALF Charges Budget n 2 Réalisation au 01/04/2014 Ecart R/B Produits Budget n Réalisation au Nbre heures /Heure Total Nbre heures /Heure Total en Charges non financières Produits non financiers Total Frais de personnel 5280 3740-0,29166667 Total Ressources en personnel 5280 3740 DS 34 55 1870 15 55 825 Pilote 20 55 1100 13 55 715 Total Consultants 42 55 2310 40 55 2200 Ingénieurs 55 0 0 55 0 Techniciens 35 0 0 35 0 Total Amortissement machines 1050 210-0,8 Total machines 1050 210 CAO 25 30 750 7 30 210 FAO 5 60 300 0 60 0 Machine conventionnelle 5 40 200 0 40 0 Machine à CN 70 0 0 70 0 Mise à disposition de matériels 80 75-0,0625 Total mise à disposition 80 75 Partenaire non lié à EC 50 0 Laboratoire lié à EC ou EC 30 75 TOTAL charges non financières 6410 4025-0,37207488 TOTAL produits non financiers 6410 4025 Dépenses Recettes ( = dépenses, sortie de trésorerie) ( = recettes, entrée de trésorerie) Total Achats 225 202,88-0,09831111 Ecole Centrale 300 100% 300 100% Matériel 225 202,88 Partenaire 0% 0% Sous traitance 0 Anvar 0% 0% CETEC 0% 0% Total Frais de mission 50 36-0,28 Déplacements 0 Total Autres subventions 0 0% 0 0% Communications 50 36 Sub 1 Papèteries 0 Sub 2 Sub 3 TOTAL dépenses 275 238,88-0,13134545 TOTAL recettes 300 100% 300 100% Frais de gestion EC (10%) 0 0 TOTAL CHARGES 6685 4263,88-0,36217203 TOTAL PRODUITS 6710 4325 03/04/2014

Journal des frais de personnel (en heures) DS Pilote Consultants Ingénieurs Techniciens T. Noms Bourdheaud' huy A. Leriche A. Kruszewski F. Verbrugghes P. Quaegebeur L. Cayron S. El- Khattabi Tous Tous Dates 27/09/2012 1 09/10/2012 0,25 18/10/2012 1 21/11/2012 1 1 01/12/2012 1 1 20/12/2012 0,5 04/01/2013 0,25 28/02/2013 1 05/03/2013 0,5 18/03/2013 1 02/04/2013 1 1 07/05/2013 2 07/05/2013 0,5 13/05/2013 2 22/05/2013 1,5 31/05/2013 2 2 03/06/2013 4 4 05/06/2013 1 07/06/2013 1 11/06/2013 1 20/09/2013 2 01/10/2013 1 11/10/2013 1 10/09/2013 0,25 02/10/2013 0,5 07/10/2013 0,25 17/10/2013 0,25 23/10/2013 0,25 21/10/2013 0,25 05/10/2013 0,25 25/10/2013 1 15/11/2013 0,5 16/01/2014 1 22/01/2014 2 29/01/2014 2 10/02/2014 3 12/02/2014 0.5 17/02/2014 2 05/03/2014 2 2 03/04/2014 2 11/03/2014 2 19/03/2014 3 26/03/2014 2 27/03/2014 4,5 01/04/2014 0,5 TOTAL 15 13 5 4,5 26 1 3,5 0 0 03/04/2014

Journal des mises à disposition de matériel Amortissement matériel EC Valorisation des prêts Valorisation des dons (en heures) (en ) (en ) Dates Description matériel CAO FAO M. conventionnelle M. à CN Lié à EC Hors EC Lié à EC Hors EC 22/05/2013 Catia 2 10/06/2013 Catia 5 04/03/2014 Prêt matériel 75 TOTAL 7 0 0 0 75 0 0 0 03/04/2014

Journal des achats Dates Fournisseurs Descriptions Matériels TTC en Sous-traitance TTC en 25/10/2013 Farnell Commande électronique 1 14,79 ~12/01/2014 Engrenages HPC Engrenages 51,36 ~12/01/2014 Conrad Roues dentées 14,38 ~12/01/2014 Abaqueplast Demi-sphère 35,75 ~12/01/2014 Labo méca Bras 68,17 ~12/01/2014 Labo méca Tube PVC 4 ~12/01/2014 Labo méca Axe et fixation 4 ~12/01/2014 Farnell Commande électronique 2 10,43 Total 202,88 0 03/04/2014

Journal des frais de mission Dates Fournisseurs Descriptions Déplacements Communication Papèterie TTC en TTC en TTC en Prévision COREP Poster 36 Total 0 36 0 03/04/2014

ANDROID SOCIAL ROBOT Notre idée Notre projet porte le nom «Android Social Robot» [ASR]. Il s agit d une plateforme autonome et interactive, qui reprend le design du célèbre personnage éponyme. Notre engagement Nous sommes 7 étudiants de l Ecole Centrale de Lille. Notre projet rentre dans le cadre d un apprentissage du type «Learning by Doing» (Apprendre en faisant). Nous y consacrerons plus de 200 heures de travail sur une période de 18 mois. Au cours de cette période, notre équipe devra travailler sur un projet réel, se rapprochant d un homologue dans le monde de l entreprise. Celui-ci nous permettra de développer nos capacités de travail en groupe, de gestion et d expertise technique. Un robot multifonctionnel L ASR sera doté d outils lui permettant de récolter des informations sur son environnement : un microphone et une caméra pouvant tourner avec la tête, ainsi que d un lecteur RFID et d une carte Bluetooth. D autre part il pourra se connecter à Internet de façon autonome par WiFi, afin d y récuperer des informations et de les transmettre à l utilisateur par SMS, par des gestes, ou encore de façon vocale, grâce à un Haut-Parleur intégré. Nous contacter N hésitez pas à nous écrire à l adresse suivante: pjandroid@googlegroups.com Un robot familial Le robot pourrait servir de plateforme de jeux, ou de station de musique. Il sera d une utilité incontournable à toute la famille, permettant la communication entre la maison et l extérieur. Il simplifiera la vie de son maître, s assurant que celui-ci reste informé de tout à tout moment. Muni de son blouson, ce robot sera un parfait majordome, et fera le bonheur de toute la famille. Groupe Projet Android

EC LILLE Cité Scientifique (face métro 4 cantons) B.P. 48 59651 VILLENEUVE D'ASCQ Cedex Téléphone (standard) : 03-20-33-53-53 Code APE : 8542Z N de SIRET : 19590349700012 Imputation lolf : Axe et Code : Service : Demandeur : Si dépense sur convention, son intitulé (ou numéro): Groupe projet RALF Thomas Bourdeaud'huy COMMANDE N Fournisseur CONRAD 59260 10 rue Paul Langevin ZI du Hellu 59260 LEZENNES Madame, Monsieur, Nous vous prions de bien vouloir livrer le matériel ci-dessous : QUANTITE DESIGNATION DU MATERIEL 1 Jeu de roues dentées 10/20/30 module 1 237663-62 1 Jeu de roues dentées double module 1 237655-62 PRIX UNITAIRE 6,99 7,39 DECOMPTE 6,99 7,39 Le chef de service ou de laboratoire, Thomas Bourdeaud'huy l'ordonnateur Total H.T. Remise % Villeneuve d'ascq, le Total H.T. T.V.A. 19,60% TOTAL T.T.C. EUROS - 14,38 Attention : - Tout bon de commande ne comportant pas la signature de l'ordonnateur ou de son représentant dûment habilité est nul et non avenu. - Toute facture ne comportant pas la référence au bon de commande sera rejetée. - La facture, datée, doit être adressée en un exemplaire au Service financier de l'ecole Centrale de Lille, dont l'adresse figure en haut de page. - Les travaux doivent être facturés en mentionnant le coût horaire de main d'œuvre et le détail des prix des fournitures. Sauf dérogation expressément exprimée dans le corps du bon de commande, les stipulations des conditions générales d'achat de l'ecole Centrale de Lille sont applicables à toutes les commandes passées par l'ecole. Ces stipulations prévalent sur les conditions générales de vente des fournisseurs. Les conditions générales d'achat de l'ecole Centrale de Lille sont disponibles à l'adresse suivante : www.ec-lille.fr.

EC LILLE Cité Scientifique (face métro 4 cantons) B.P. 48 59651 VILLENEUVE D'ASCQ Cedex Téléphone (standard) : 03-20-33-53-53 Code APE : 8542Z N de SIRET : 19590349700012 COMMANDE N Fournisseur ENGRENAGES HPC SARL CP 69570 58 chemin de la bruyère 69570 DARDILLY Imputation lolf : Axe et Code : Service : Demandeur : Si dépense sur convention, son intitulé (ou numéro): Groupe projet RALF Thomas Bourdeaud'huy Tel : 04 37 496 496 Madame, Monsieur, Nous vous prions de bien vouloir livrer le matériel ci-dessous : QUANTITE DESIGNATION DU MATERIEL 1 Engrenage droit 10 dents, module 0,8 ZG0.8-10 1 Engrenage interne 60 dents, module 0,8 ZIN0.8-60 PRIX UNITAIRE 8,55 34,39 DECOMPTE 8,55 34,39 Le chef de service ou de laboratoire, Thomas Bourdeaud'huy l'ordonnateur Total H.T. 42,94 Remise % Villeneuve d'ascq, le Total H.T. T.V.A. 19,60% TOTAL T.T.C. EUROS 42,94 8,42 51,36 Attention : - Tout bon de commande ne comportant pas la signature de l'ordonnateur ou de son représentant dûment habilité est nul et non avenu. - Toute facture ne comportant pas la référence au bon de commande sera rejetée. - La facture, datée, doit être adressée en un exemplaire au Service financier de l'ecole Centrale de Lille, dont l'adresse figure en haut de page. - Les travaux doivent être facturés en mentionnant le coût horaire de main d'œuvre et le détail des prix des fournitures. Sauf dérogation expressément exprimée dans le corps du bon de commande, les stipulations des conditions générales d'achat de l'ecole Centrale de Lille sont applicables à toutes les commandes passées par l'ecole. Ces stipulations prévalent sur les conditions générales de vente des fournisseurs. Les conditions générales d'achat de l'ecole Centrale de Lille sont disponibles à l'adresse suivante : www.ec-lille.fr.

EC LILLE Cité Scientifique (face métro 4 cantons) B.P. 48 59651 VILLENEUVE D'ASCQ Cedex Téléphone (standard) : 03-20-33-53-53 Code APE : 8542Z N de SIRET : 19590349700012 Imputation lolf : Axe et Code : Service : Demandeur : Si dépense sur convention, son intitulé (ou numéro): Groupe projet RALF Thomas Bourdeaud'huy COMMANDE N Fournisseur ABAQUEPLAST 41 Avenue Gaston Monmousseau 93245 STAINS Cedex Tel : 01 48 26 32 80 Madame, Monsieur, Nous vous prions de bien vouloir livrer le matériel ci-dessous : QUANTITE DESIGNATION DU MATERIEL 1 Demi-sphere-PMMA-Choc-Incolore-Transparent- Brillant-152,4 PRIX UNITAIRE 35,75 DECOMPTE 35,75 Le chef de service ou de laboratoire, Thomas Bourdeaud'huy l'ordonnateur Total H.T. 29,89 Remise % Villeneuve d'ascq, le Total H.T. T.V.A. 19,60% TOTAL T.T.C. EUROS 29,89 5,86 35,75 Attention : - Tout bon de commande ne comportant pas la signature de l'ordonnateur ou de son représentant dûment habilité est nul et non avenu. - Toute facture ne comportant pas la référence au bon de commande sera rejetée. - La facture, datée, doit être adressée en un exemplaire au Service financier de l'ecole Centrale de Lille, dont l'adresse figure en haut de page. - Les travaux doivent être facturés en mentionnant le coût horaire de main d'œuvre et le détail des prix des fournitures. Sauf dérogation expressément exprimée dans le corps du bon de commande, les stipulations des conditions générales d'achat de l'ecole Centrale de Lille sont applicables à toutes les commandes passées par l'ecole. Ces stipulations prévalent sur les conditions générales de vente des fournisseurs. Les conditions générales d'achat de l'ecole Centrale de Lille sont disponibles à l'adresse suivante : www.ec-lille.fr.

Projet Android Etude de multidimensionnalité G2 R.A.L.F. Robot Android Ludique et Fonctionnel Directeur Scientifique : Thomas Bourdeaud huy Pilote : Amandine Leriche Le Groupe Projet : Florence Bohnes Alexandre Chakroun Stéphane Coulon Maxence Dallongeville Vladimir Dombrovski Guillaume Jaeg Ahmed Trabelsi

Etude de multidimensionnalité G2 Table des matières Introduction 3 1 Les dimensions 4 1.1La gestion du budget 4 1.1.1 Un budget incertain...................................... 4 1.1.2 La gestion du budget au quotidien.............................. 4 1.2La gestion des motivations au sein de l équipe projet 5 1.2.1 L importance de la motivation pour un projet........................ 5 1.2.2 Les sources de la motivation.................................. 5 1.2.3 La gestion de la motivation au sein de notre équipe..................... 5 1.2.4 Conclusion........................................... 6 1.3Gestion du stress au sein de l équipe projet 7 1.3.1 Les origines du stress...................................... 7 1.3.1.1 Des deadlines précises................................. 7 1.3.1.2 Un budget serré.................................... 7 1.3.1.3 Des livraisons non fiables............................... 8 1.3.2 La gestion du stress...................................... 8 1.3.2.1 Des deadlines adaptées................................. 8 1.3.2.2 Un partenariat inattendu............................... 8 1.3.2.3 Des délais anticipés.................................. 9 1.3.3 Conclusion........................................... 9 1.4Communication au sein de l équipe 10 1.4.1 Début du projet........................................ 10 1.4.2 Les premiers problèmes.................................... 10 1.4.3 Le début de la G2....................................... 10 1.4.4 La fin du projet......................................... 10 1.5Gestion des connaissances 11 1.5.1 La place des connaissances dans le projet.......................... 11 1.5.1.1 Répartition selon les membres............................. 11 1.5.1.2 Nécessité pour le projet................................ 11 1.5.2 L acquisition des connaissances................................ 11 1.5.2.1 Centrale Lille...................................... 11 1.5.2.2 Autres sources..................................... 11 1.6Gestion des personnalités 12 1.6.1 Exemples de difficultés rencontrées et solutions trouvées................. 12 1.6.1.1 Plusieurs meneurs................................... 12 1.6.1.2 Valorisation du travail des plus discrets....................... 12 1.6.2 Comment anticiper ces problèmes............................... 12 1.7Partenaires 14 1.7.1 Campagne de recherche de partenaire :............................ 14 1.7.2 Relation avec le CITC :.................................... 14 1.7.3 Conclusion :........................................... 14 2 Interactions entre les dimensions 15 Page 1/17 Partie 0

Etude de multidimensionnalité G2 2.1Diagramme 15 2.1.1 Explication du diagramme................................... 15 2.2Limites d un graphe comme celui-ci 16 Conclusion 17 Page 2/17 Partie 0

Etude de multidimensionnalité G2 Introduction Durant les deux années passées sur notre projet Android, nous avons vécu de nombreux succès mais aussi des déboires passagers dépendant d interactions «complexes» entre différents aspects plus ou moins bien maîtrisés. Nous avons donc analyser dans cette étude de multidimensionnalité comment nous avons surmonté les nombreux obstacles qui nous sont apparus dans le projet, et ce que l on en a appris, car ces chacun de ces échecs fut un apprentissage dans notre formation d ingénieur. Après concertation, nous avons donc défini sept dimensions primordiales : La gestion du budget La motivation La gestion du stress La communication interne La gestion des connaissances Les différentes personnalités La recherche de partenaires Page 3/17 Partie 0

Etude de multidimensionnalité G2 Première partie Les dimensions 1.1 La gestion du budget 1.1.1 Un budget incertain Etablir un budget solide est un élément très important pour le projet puisqu il permet de prévoir ce qu il est possible de faire en comparant les charges et les ressources du projet. Notre projet a eu la particularité d avoir un budget qui est longtemps resté incertain car nous ne savions pas si nous allions avoir un partenaire financier extérieur ou non. Au début du projet, comme nous avions alors des pistes prometteuses de partenaires, nous avons basé nos premières estimations de coût sur l hypothèse d un partenariat qui nous apporterait des ressources de l ordre de quelques centaines d euros. Nous avons ensuite construit nos solutions techniques autour de cette hypothèse, car même si nous n avions pas de partenaire prêt à nous aider financièrement, des pistes restaient exploitables. De ce fait, nous ne pouvions pas commander rapidement les composants, car nous ne savions pas si nous allions avoir le budget pour, et nous avons donc dû réaliser les premiers tests de faisabilité sur des composants possédés par les membres du groupe projet, et non pas par le projet en propre. Ce n est ensuite qu arrivé à la deuxième année que nous nous sommes rendus compte que nous n aurions très probablement pas de partenaire extérieur et nous avons donc dû revoir certaines de nos solutions techniques afin de réduire les coûts de fabrication du prototype. Nous avons par exemple prévu de construire la coque autour d un tube PVC existant plutôt que de la créer à l imprimante 3D, et nous avons retiré certaines fonctionnalités secondaires au robot (comme la NFC). Nous avons également pu compter sur le soutien de M. Bourdeaud huy qui nous a prêté quelques composants pour compléter ce qui nous manquait et nous avons ainsi pu disposer des pièces nécessaires à notre robot pour un budget d environ 210 euros, inférieur aux 300 euros alloués par l école. 1.1.2 La gestion du budget au quotidien En pratique, suivre le budget au quotidien est nécessaire afin d avoir une idée des coûts internes et externes du projet, et afin de vérifier que l on ne dépasse pas les limites qui nous sont imposées. Tout d abord, il convient de suivre les commandes effectuées pour commander les différents composants, surtout quand le budget est très limité comme le nôtre. A ce niveau, l école impose un circuit de commande pour acheter des composants : il faut d abord établir un bon de commande, le faire signer par le DS et le transmettre ensuite à l école pour que la commande puisse être effectuée. Ce système permet à l école de bien suivre les dépenses effectuées dans le cadre du projet mais nous impose des limites. Nous ne pouvons effectuer les commandes que dans une liste de fournisseurs acceptant les bons de commandes de l école et les délais de traitement sont augmentés de par l ajout d intermédiaires, ce qui a pu entraîner des problèmes de disponibilité de pièces chez le fournisseur. Ensuite, il est également important de suivre correctement les heures consultants car les frais de personnel correspondent aux charges les plus importantes du projet (même s il s agit de charges internes) et il faut vérifier que l on ne dépasse pas les 94h mises à disposition par l école. Au début, seul le trésorier les gérait en demandant aux différentes personnes quels consultants ils sont allés voir et quand. Cette solution s est toutefois rapidement révélée inefficace et sujette à des oublis potentiels. En effet, les pôles étant assez séparés, le trésorier n était pas forcément au courant de tout et il n était pas pratique de toujours passer par lui pour les noter. Nous sommes donc passé ensuite à un système de Google doc qui permet à chacun de noter les heures utilisées et de voir où on en est actuellement dans l utilisation de ces heures. Ainsi, malgré les difficultés initiales, nous avons pu construire réaliser le projet avec un budget qui tient la route. Page 4/17 Partie 1

Etude de multidimensionnalité G2 1.2 La gestion des motivations au sein de l équipe projet 1.2.1 L importance de la motivation pour un projet La motivation est un facteur clé dans un projet, elle influe sur la réussite du projet aussi bien en termes de temps que de qualité. Un manque de motivation se manifeste généralement par un projet qui n avance pas à un moment donné, ou encore un projet bâclé. Notre projet met en commun 7 personnes de personnalité, d origine, et d occupations différentes. Nous avons tous une approche différente quant au travail, et nous avons des cadences de travail différentes. C est pourquoi la motivation constitue un facteur clé de la réussite du projet. Elle permet notamment de constituer une cohésion entre les membres, et d inciter tous les individus à consacrer une partie de leurs efforts et de leur temps au projet plutôt qu à une autre activité. Comme précisé précédemment, tous les individus étant différents, il est souvent difficile pour eux de voir les conséquences de leurs actions à long terme. Car généralement, nous avons tendance à n envisager les problèmes qu à court terme, et nous nous mobilisons pour faire face à ceux-ci avant de contribuer à un travail qui ne paye de plus tard. La motivation consiste notamment à s approprier le projet dans son ensemble, et d avoir en tête l objectif final à tout moment. De plus, l objectif d un groupe projet motivé est non pas d éviter l échec du projet, mais au contraire de favoriser un bon résultat. En effet, nous avons choisi un projet qui nous tient à cœur, nous avons tous envie que celui-ci soit bien réalisé. La motivation permet aux personnes du groupe de ne plus penser en termes de résultat à la soutenance finale, mais en termes d une création à laquelle ils ont contribué. 1.2.2 Les sources de la motivation La motivation peut être considérée comme une ressource dans une équipe projet. Elle peut être produite par des moments positifs, par des résultats concluants ou tout simplement par l avancement du projet. Cependant, l environnement extérieur au projet tend à dissiper cette motivation. Nous nous retrouvons portés par d autres idées, et nos moments difficiles nous enlèvent l envie de contribuer en général. Il est souvent nécessaire de créer artificiellement de la motivation ou encore de la transmettre à d autres personnes du projet. Mais même notre motivation propre a des sources différentes. Chacun des membres a son propre objectif, et travaille pour une cause différente. Certains ne travaillent que pour le résultat à la soutenance, c est donc leur note finale, qui détermine leur passage à l année supérieure qui leur donne de la motivation. D autres cherchent à accomplir le projet afin d acquérir des connaissances qui leur serviront dans leur travail plus tard, des capacités qui seront requises par les entreprises. Ces personnes ont une envie d apprendre sur un cas réel qui est le projet. D autres encore s attachent au projet à tel point, que leur seul désir est de mener le projet à son apogée. Souvent ils ont envie de valoriser ce dernier, de le commercialiser ou même de créer une startup avec leur invention. Il est clair que les niveaux présentés précédemment sont fondamentalement différents, telle est également la motivation de ces différents membres. Malheureusement le cas idéal de fanatisme et d obsession n est pratiquement jamais atteint, il convient ainsi d exploiter au mieux la motivation existante et de résister aux différentes contraintes qui nous enlèvent celle-ci. C est tout le rôle de la gestion de la motivation. 1.2.3 La gestion de la motivation au sein de notre équipe Il est clair que les niveaux présentés précédemment sont fondamentalement différents, telle est également la motivation de ces différents membres. Malheureusement le cas idéal de fanatisme et d ob- Page 5/17 Partie 1

Etude de multidimensionnalité G2 session n est pratiquement jamais atteint, il convient ainsi d exploiter au mieux la motivation existante et de résister aux différentes contraintes qui nous enlèvent celle-ci. C est tout le rôle de la gestion de la motivation. La deuxième clé pour garder un groupe motivé est la reconnaissance du travail accompli. Celle-ci consiste à prendre connaissance du travail effectué par les autres, de les conseiller et de les féliciter. Cela permet à chacun de se sentir utile au projet à tout moment et l incite à donner le meilleur de soi pour les tâches à venir. Il nous arrive souvent de partager nos créations ou de faire des démonstrations pour les autres membres sur le travail accompli. Cette tâche se voit être d autant plus importante vu que notre groupe travaille par pôles, et que les autres n ont pas toujours la chance d être au courant de tous les avancements. Le troisième point essentiel est la gestion des conflits. Celle-ci est en lien direct avec la motivation des membres. Un conflit peut non seulement faire perdre la motivation à un membre, il ralentit et touche l ensemble du groupe projet. C est pourquoi nous essayons de régler nos différents lors des mini-réunions hebdomadaires portant le nom de «QHP» (Quart d Heure Projet). Ces réunions, décrites dans d autres parties ont plusieurs objectifs, et notamment celui de garder un œil sur l ensemble du groupe afin de repérer tout problème qui pourrait ralentir ou mettre en danger le projet. Enfin, le dernier point est la relance et l entraide. Nous essayons en effet de mettre en place des deadlines pour tous les objectifs à accomplir, afin que chacun puisse s organiser et ne se retrouve pas pris au dépourvu par une tâche urgente à faire. Nos objectifs nous sont également donnés par des comptes rendus des réunions, et résultent d une division du travail en accord avec chacun des membres. Nous faisons également appel à l entraide, qui consiste à aider, voir reprendre la responsabilité d un autre membre pour le décharger. Dans un groupe, il arrive parfois que l un des membres se retrouve trop encombré, du fait d une tâche se retrouvant être beaucoup plus coûteuse en temps et en ressources par exemple. Ainsi, plutôt que de harceler le responsable, en le forçant à atteindre des objectifs impossibles, nous essayons de consacrer du temps à aider la personne en question. Ce procédé requiert toutefois une bonne connaissance du contexte de l objectif, c est pourquoi l entraide est souvent faite intra-pôle. De plus, le fait de se faire aider, ou encore de travailler en équipe fournit de la motivation à l équipe et constitue donc une pratique positive pour le groupe projet. 1.2.4 Conclusion Il est évident que la motivation est un point essentiel à la réussite d un projet. C est également un point délicat, qui consomme des ressources et nécessite une certaine organisation. Aussi, la mise en place des différentes pratiques contribue à l expérience acquise par les membres et permettra de gérer plus efficacement des projets à l avenir. Elle prend donc effectivement place dans la multidimensionnalité de notre projet. Page 6/17 Partie 1

Etude de multidimensionnalité G2 1.3 Gestion du stress au sein de l équipe projet Nous allons ici aborder le stress, c est-à-dire pourquoi celui-ci apparait, et comment est-il géré par l équipe projet. 1.3.1 Les origines du stress Malgré le fait que le projet Android ne nécessite pas de manipulations ou de montages utilisant des outils à risque (chalumeaux, matériaux toxiques... ) le stress fait quand même partie intégrante au projet et de plusieurs manières différentes. 1.3.1.1 Des deadlines précises Afin de réaliser notre projet dans le temps, nous avons établi des deadlines et des étapes dans notre cheminement et ce pour chaque pôle de notre projet (mécanique, automatique, informatique, électrique). Toutefois, de ces quatre pôles, trois nécessitent la présence ou l aide d un enseignant afin de pouvoir avancer à un rythme acceptable. En effet, le pôle électrique doit constamment faire vérifier son travail par un enseignant spécialisé dans le domaine, car aucune erreur n est tolérée dans son travail, le moindre faux contact se révélant catastrophique pour le fonctionnement et la durabilité de notre robot. De plus, chaque montage du pôle électrique dépend du précédent, dès lors il ne peut pas passer au travail d après sans valider le schéma antérieur, et dois donc attendre la disponibilité de son consultant pour pouvoir avancer. Nous retrouvons le même schéma pour le pôle automatique, en effet, ce pôle a besoin d un logiciel (MatLab) afin de concevoir et d établir des modèles avant de passer à la pratique. Or ce logiciel est extrêmement couteux et accessible uniquement dans des salles de l Ecole dont l accès doit être autorisé par un professeur. Ainsi pour pouvoir travailler correctement, le pôle automatique doit chercher un enseignant capable de lui donner l accès à la salle, et cette recherche peut faire perdre un temps très précieux et donc engendrer des retards dans les livrables. Enfin, pour créer la coque et assembler les différents composants permettant la mobilité du robot (engrenages, moteurs, système de support) le pôle mécanique doit avoir accès au laboratoire de mécanique de l Ecole afin de profiter d un environnement idéal et adapté à leur besoin. Toutefois, il est obligatoire de se faire accompagner d un enseignant si l on cherche à effectuer le moindre travail avec un outil du laboratoire de mécanique de l Ecole. Ainsi durant la moitié des créneaux consacrés au projet, aucun enseignant n est disponible pour encadrer le pôle mécanique, qui se voit contraint à faire de la théorie et ne peut pas avancer de manière concrète. L avancée de la majeure partie de notre groupe projet Android est donc liée à la disponibilité des enseignants, qui est variable et extrêmement peu prévisible, ce qui cause de nombreux problèmes concernant les objectifs fixés et est donc une grande source de stress, car il est quasiment impossible de quantifier à l avance la progression d un pôle durant un créneau projet. 1.3.1.2 Un budget serré Contrairement à la majorité des projets centraliens, notre projet Android n a actuellement pas de partenaire. En effet, nous avions démarché plusieurs entreprises, et deux d entres elles se sont révélées intéressées. Toutefois, la première entreprise est devenue injoignable après avoir participé à notre première soutenance et nous avoir promis une aide financière durant tout le premier semestre. La deuxième quant à elle nous demandait de lui livrer le robot après notre projet mais sans aucune contrepartie financière de sa part, elle se proposait uniquement de nous fournir des conseils ou de nous prêter du matériel, mais on ne pouvait pas utiliser celui-ci pour construire notre robot. Ne voyant pas Page 7/17 Partie 1

Etude de multidimensionnalité G2 en quoi ce type de partenariat nous était profitable, nous avons décidé de ne pas aller plus loin dans le partenariat avec cette entreprise. Finalement, nous disposons que de 300 euros pour réaliser notre projet. Selon une estimation très précise que nous avons effectué, cela semble suffisant mais il faut faire extrêmement attention à nos achats et l utilisation de nos composants. En effet, nous n avons pas les moyens de racheter un composant, il ne faut donc pas faire de manipulation hasardeuse qui pourrait résulter par l usure voire la casse d un composant de notre robot, ce qui bien entendu est une source importante de stress. 1.3.1.3 Des livraisons non fiables Pour nous procurer les parties de notre robot, nous les commandons via les services de l Ecole, ce qui nécessite beaucoup de formalités administratives et limite notre nombre de fournisseur. Toutefois, la fiabilité de ces livraisons n est pas optimale, en effet, dans le cadre de notre projet, le pôle mécanique a commandé par le service de l Ecole un grand nombre d engrenages, tous indispensables pour assurer la mobilité de notre robot. Trois causes de stress sont alors apparues : Nos dossiers ont été oublié et donc envoyé en retard Nous n avions aucune certitude à propos des délais de livraisons Une partie des pièces n a pas été livrée ou de mauvais composants ont été livrés. Ces deux problèmes majeurs causent toujours l incertitude devant la faisabilité du projet, car une des pièces que nous avions commandé est maintenant non disponible, le fournisseur n ayant plus de stock. Or cette pièces est cruciale pour la rotation de la tête de notre robot, qui est une des fonctionnalités principale. De plus, cette pièce coute extrêmement chère et nous ne pouvons pas nous permettre d en acheter chez un autre fournisseur. 1.3.2 La gestion du stress Afin de gérer le stress, il est nécessaire de contrôler, de diminuer les sources de celui-ci. 1.3.2.1 Des deadlines adaptées Après avoir expérimenté et prit conscience que la présence des consultants est essentielle pour le bon déroulement de notre projet, l ensemble des pôles a donc planifié avec l ensemble des consultants leur disponibilité, afin de pouvoir travailler le projet en dehors des créneaux si besoin et de savoir précisément quand il est possible d avancer de manière concrète le projet. Malgré cette planification, une partie des créneaux projets restent sans enseignants disponibles. Dès lors, les membres du pôle concerné se consacrent soit à la théorie soit à la gestion de projet. Cette planification permet de diminuer le temps perdu à chercher un enseignant disponible et donc s avère efficace. Toutefois des imprévus persistent et certains enseignants ne peuvent pas être disponibles malgré la planification, c est pourquoi lorsque nous établissons des deadlines nous nous accordons un créneau projet de plus afin de palier à cette éventualité. 1.3.2.2 Un partenariat inattendu Notre directeur scientifique, monsieur Bourdeaud huy nous a récemment proposé de nous fournir du matériel pour notre robot si nous lui en faisions la demande. Il nous a ainsi proposé un partenariat avec l électif «Intelligence Ambiante» qui nous serait profitable car allégerait grandement le stress occasionné par notre budget très limité. En contrepartie, nous devrons lui fournir tous les documents relatifs à notre robot et le robot lui-même. Ce partenariat n est pas encore définitif mais semble prometteur car nous assurerait d avoir suffisamment de fond si un problème apparait avec une partie de notre matériel. Page 8/17 Partie 1

Etude de multidimensionnalité G2 1.3.2.3 Des délais anticipés Concernant les problèmes liés aux livraisons, nous avons effectués notre demande de commande suffisamment en avance pour limiter l impact du double retard sur notre travail et sur nos deadline. Toutefois, nous n avions pas anticipé que durant le temps qui a été mis à faire la commande, une des pièces ne serait plus dans le stock et donc indisponible. Nous sommes toujours dans l attente de cette pièce et nous ne savons pas quand cette pièce indispensable nous parviendra. 1.3.3 Conclusion Le stress est donc omniprésent dans ce projet, et nous avons fait de notre mieux pour le réduire voir l éliminer afin qu il ne soit pas un obstacle à la réalisation de notre projet. En effet, la majeure partie des causes de stress a été contrôlé ou le stress lui-même a été pris en compte dans notre travail, ce qui permet de progresser en sachant à quel moment le stress va intervenir. Toutefois, la seule cause de stress restante est une cause primordiale, et nous essayons actuellement de déterminer comment nous pourrions la contourner. Page 9/17 Partie 1

Etude de multidimensionnalité G2 1.4 Communication au sein de l équipe Savoir gérer les différentes personnalités des membres du groupe n est pas suffisant pour garantir l efficacité du travail en équipe. Il est également essentiel que la communication entre les membres de l équipe soit efficace afin d éviter les pertes de temps. En effet, si la répartition des tâches à effectuer entre les différents membres du groupe n a pas été un problème ; il est évident que chacune de ces tâches dépendra, à un moment ou à un autre, du travail effectué par un autre membre du groupe. 1.4.1 Début du projet Les premières mesures pour faciliter la communication au sein de l équipe ont été prises dans les premières semaines de l activité projet : la création d un googlegroup pour faciliter l envoi de mails communs à toute l équipe et la mise en place du dossier DropBox pour partager les fichiers utiles (qui sera développée plus tard lorsque nous parlerons de gestion des connaissances). 1.4.2 Les premiers problèmes Malgré ces mesures, il est très vite apparu une véritable séparation entre les différents pôles du projet : chacun n avait qu une vague idée de l avancement des autres, et en plus ne comprenait rien à ce qu ils faisaient. Cela a causé de nombreux malentendus, engendré des retards conséquents, et nuisait à la cohésion du groupe. Nous avons commencé à prendre conscience du phénomène au moment de remplir la matrice PME : les membres du groupe étaient incapables d évaluer le travail de ceux qui travaillaient dans un pôle différent. Le temps que nous réalisions pleinement le problème et son origine, la G1 était presque terminée, nous avions pris un retard conséquent sur le planning, et on aurait presque pu croire que le groupe était scindé en trois groupes distincts : le pôle mécanique, le pôle informatique et le pôle électronique (le travail du pôle automatique n avait pas réellement commencé). 1.4.3 Le début de la G2 Une fois passées les vacances d été, chacun a pu prendre du recul sur l activité et le groupe projet, ce qui a permis d identifier de nombreux problèmes, dont celui qui nous occupe ici. C est à la rentrée que Vladimir, notre animateur en réunion, a proposé sa solution au problème : Le QHP. Le QHP, pour Quart d Heure Projet, consiste en une courte réunion informelle hebdomadaire à la cafétéria durant laquelle chaque membre du groupe présente aux autres le travail accompli depuis le QHP précédent, ainsi que ce qu il prévoit de faire avant le suivant. L effet a été très rapide : au bout de quelques semaines seulement, le groupe avait retrouvé une certaine cohésion, et même si chacun ne comprenait pas totalement le travail des autres, on avait tout de même une idée assez précise de l avancée du projet dans les différents pôles. 1.4.4 La fin du projet Grâce au QHP, la phase finale du projet va pouvoir commencer en évitant beaucoup de problèmes. La phase finale est en effet un moment critique pour le projet : c est le moment où les différents pôles finissent leur travail et où le groupe entier procède à «l assemblage» des différents travaux effectués pour aboutir au projet fini. Si nous avions continué à travailler de la même façon qu en G1, l échec était assuré ; tandis qu actuellement, la communication étant pleinement rétablie au sein du groupe, les interdépendances entre les différents pôles sont clairement identifiées et l assemblage pourra s effectuer sans heurt. Page 10/17 Partie 1

Etude de multidimensionnalité G2 1.5 Gestion des connaissances 1.5.1 La place des connaissances dans le projet 1.5.1.1 Répartition selon les membres Notre projet présente une particularité, c est que plusieurs domaines sont impliqués dans sa réalisation. On pourrait presque le diviser en 3 projets, correspondant aux différents pôles actuels du projet (informatique, mécanique/automatique et électronique). Ainsi, il n est pas possible que chaque membre du projet est accès, ou en tout cas comprenne, tous les aspects du projet. Chacun a donc sa place dans le projet et possède les connaissances qui correspondent à la partie qui lui est attribué. 1.5.1.2 Nécessité pour le projet Etant donné que toutes les connaissances ne pouvaient être gérées par un unique individu, il fallait bien sûr mettre en place des outils afin de savoir qui connait quoi et que l accès à ces connaissances soit permis pour les autres. Ainsi, nous faisons hebdomadairement des réunions (QHP : Quart d Heure du Peuple) pendant lesquelles chacun expose ses avancées de la semaine et ce qui est prévu pour la semaine suivante. De plus, notre dropbox, notre site de communication interne et notre site de communication externe regroupent toutes la documentation nécessaires pour pouvoir comprendre tel ou tel aspect du projet. 1.5.2 L acquisition des connaissances 1.5.2.1 Centrale Lille Centrale propose toutes sortes de cours ou électifs qui peuvent permettre de réaliser certaines parties du projet. On peut penser notamment aux cours et électifs de conception sur CATIA ou encore ceux d automatique. 1.5.2.2 Autres sources Bien sûr certaines parties du projet ont nécessité de se renseigner par nous même. On peut penser notamment à la programmation en python. Page 11/17 Partie 1

Etude de multidimensionnalité G2 1.6 Gestion des personnalités L un des buts premiers de l activité projet de l Ecole Centrale de Lille est d apprendre à travailler en équipe. C est un acquis indispensable pour un futur ingénieur, qui sera sans aucun doute confronté au travail en groupe dans sa vie professionnelle. Mais cela n en fait pas la partie la plus simple de l activité projet, loin de là. Travailler ensemble, au sein d un groupe de 7 élèves par exemple, comme nous l avons fait durant 2 ans, est un défi de tous les instants. Car une équipe de 7 individus signifie 7 personnalités différentes, 7 manières de communiquer différentes, 7 manières de travailler différentes. Le tout est d apprendre à les gérer au fil du temps et d essayer d en tirer le meilleur pour que le projet avance au mieux. 1.6.1 Exemples de difficultés rencontrées et solutions trouvées 1.6.1.1 Plusieurs meneurs Certains ont plutôt une âme de meneurs, voulant prendre des décisions, prenant les devants, et d autres sont plutôt des suiveurs, qui ne vont pas forcément prendre d initiatives mais qui donnent leur avis quand on leur demande. Nous avons découvert assez vite qu au moins deux personnes de notre groupe étaient du type "meneur". Nous avons cru pendant un moment que cela serait problématique, car cela pouvait créer des tensions au sein du groupe. Mais au fil du temps, cela s est révélé être un moteur à l avancée du projet, car nous avons développé notre communication, et avons défini clairement des rôles importants pour chacune de ces personnes. Nous avons ainsi lutté contre la frustration de ceux qui veulent être au centre de l action, en leur attribuant des responsabilités importantes et de la marge de manœuvre, et nous avons permis à ceux qui ne sont pas à l aise avec la prise de décisions d être encadrés pour pouvoir mieux s épanouir. 1.6.1.2 Valorisation du travail des plus discrets Une autre difficulté que nous avons rencontré a été le manque de mise en avant de certaines personnes de notre groupe, qui a mené nos encadrants à penser qu il s agissait d un manque de travail. En effet, un membre de notre équipe est plutôt discret. Il parle rarement en réunion à part lorsqu on lui demande explicitement et a quelques difficultés à exprimer certaines idées en français car il est d origine étrangère. Cela lui a malheureusement joué des tours car nos encadrants croyait, et ceci encore récemment, qu il s agissait de manque de motivation et de travail, alors que ce n était pas le cas. De plus, lors du remplissage de la matrice PME, c est également cet élève qui aurait dû avoir la moins bonne note, sans que nous ne comprenions pourquoi. C est pour cela que nous avons refusé de rendre la matrice. Arriver à mettre en avant le travail régulier de quelqu un qui reste en retrait lors des réunions n est pas évident, et il nous a fallu le faute encore et encore à chaque rencontre avec des encadrants. 1.6.2 Comment anticiper ces problèmes La clé de réussite de l activité projet est d arriver à utiliser les différentes manières de travailler de chacun au profit du projet, et de ne pas demander à tous le même genre de tâche. Comme nous l avons vu en accompagnement grâce à l établissement de nos profils MBTI, certaines personnes travaillent mieux dans l urgence et d autres préfèrent planifier clairement ce qu ils ont à faire à l avance. Certains préfèrent travailler sur des sujets techniques purs, en utilisant des procédés déjà existants, et d autres aiment innover, brainstormer sur des sujets nouveaux. Certains travaillent efficacement mais n arrivent pas à se vendre, et ne sont pas à l aise pour les présentations orales. C est de ce genre de différences qu il faut se servir au quotidien dans le projet, pour que chacun soit à l aise dans ce qu il fait, et qu il utilise ses capacités au maximum. Si l on arrive à utiliser les profils de chacun pour servir le projet, c est un bénéfice énorme à la fois pour l avancée du projet et pour ses membres, qui seront à l aise dans leur travail. Mais il ne faut pas oublier que nous sommes également ici pour apprendre et pour developer nos capacités. Il ne faudrait pas se cantonner à nos acquis et toujours essayer de se dépasser et de se surprendre sur des tâches qui semblent de base ne pas nous correspondre. La grande difficulté est Page 12/17 Partie 1

Etude de multidimensionnalité G2 donc d arriver à utiliser les profils et personnalités différentes qui composent un groupe projet pour faire avancer la problématique au mieux tout en laissant une possibilité d évolution à chacun s il veut progresser sur telle ou telle tâche. Page 13/17 Partie 1

Etude de multidimensionnalité G2 1.7 Partenaires Dès le début du projet, nous nous sommes mis à la recherche d un partenaire dans le but de financer les dépenses du projet qui pourraient déborder par rapport à la somme subventionnée par l Ecole. En effet, les premières estimations des dépenses dépassaient la somme de 300 euros et un partenaire semblait nécessaire. 1.7.1 Campagne de recherche de partenaire : Nous avons développé une stratégie pour trouver un partenaire. Nous avons dans un premier lieu listé toutes les entreprises de robotique et d automatique qui sont les plus succeptibles d adopter notre projet (le robot RALF), nous avons ensuite essayé de les contacter par mail. Suite à ceci nous avons eu quelques réponses d Aldeberan (entreprise qui a fait le Karotz) et Phoceis. Aucune de ces 2 pistes n a pu aboutir, à cause des règles de conformités internes pour Aldeberan qui refuse tout projet externe. Du côté de Phoceis, la relation bien que semblant prometteuse au début a été interrompu suite à leur déménagement et nous n avons plus pu avoir de contacts avec eux depuis, bien que nous ayons tenté de nombreuses fois de les appeler, contacter par mails, et même nous rendre sur place. Suite à ceci, et sur les conseils de notre directeur scientifique, nous avons contacté CITC (spécialiste des technologies de communication sans contact). Le CITC est en train de développer un projet qui s intitule la maison intelligente. Ce projet est en effet une maison qui est dotée de plusieurs sortes de capteurs et d actionneurs qui pourront commander par exemple l ouverture des portes, les fenêtres, ou l allumage des lumières. Nous nous sommes rapprochés du CITC pour intégrer notre robot qui s inscrit bien dans le thème de la maison intelligente comme une interface de communication avec l utilisateur. En effet, notre robot RALF qui est conçu pour comprendre des commandes vocales et les interpréter sera un intermédiaire très intéressant puisque la maison sera commandée directement par les ordres prononcés par une personne. De plus, comme nous avions envisagé d intégrer des lecteurs RFID au robot et que le CITC est un expert de cette technologie, nous avons trouvé très intéressant le fait de nouer un partenariat avec eux ce qui nous donnerait finalement un support de valorisation de notre projet (la maison intelligente) et une aide technique. 1.7.2 Relation avec le CITC : Suite à plusieurs échanges avec notre correspondant au CITC, nous lui avons fait savoir nos intentions de faire un partenariat avec eux. Lors d une réunion, nous avons mis au clair toutes les obligations de chaque parti du contrat selon les exigences de l Ecole Centrale de Lille, à savoir les obligations de présentation de livrables, les subventions de l école et les obligations financières du partenaire. Le CITC a refusé ce partenariat pour des causes financières en nous expliquant clairement leur souhait de faire ce partenariat en n offrant que la maison intelligente comme support d essai et de test et aucun budget ne peut être prévu pour ce projet. Sur ce, notre relation a été rompu puisque sans l apport financier nécessaire, le partenariat semble défavorable pour le projet dans la mesure où nous devions orienter tout notre travail sur l adaptation du robot pour communiquer avec la maison intelligente, ce qui n a pas été prévu dès le début. 1.7.3 Conclusion : Nous sommes maintenant à la fin du projet et nous avons pu nous passer d aides financières autres que celle de l Ecole Centrale. Nous pensons faire un partenariat avec l électif d intelligence ambiante qui pourra transmettre le projet à d autres groupes projet pour l améliorer dans les années futures. Page 14/17 Partie 1

Etude de multidimensionnalité G2 Deuxième partie Interactions entre les dimensions Toutes les dimensions évoquées dans ce dossier ne sont pas indépendantes. Nous avons pu le constater dans un premier temps car dans la partie concernant une dimension donnée, d autres dimensions sont très souvent citées. Elles peuvent avoir un impact négatif ou positif, constant ou changeant au fur et à mesure du temps, unilatéral ou l une sur l autre. 2.1 Diagramme Le diagramme ci-dessous traduit une grande partie de ces interactions. Figure 1: Interactions 2.1.1 Explication du diagramme On peut distinguer des flèches de différentes couleurs sur le diagramme ci-dessus. Les flèches vertes traduisent un impact globalement positif, les flèches rouges un impact globalement négatif, et les flèches oranges une interaction plus complexe, qui a fluctuée au cours du temps dans notre projet. Toutes les flèches oranges pointent vers la motivation car la motivation est un facteur qui peut varier vite et de manière extrême. La relation avec le partenaire, par exemple, a eu au fil du temps une bonne ou une mauvaise influence sur notre motivation. En effet, nous avons trouvé à 2 reprises des partenaires, qui sont même venus à nos soutenances, mais à chaque le partenariat s est conclut sur un échec. Les échecs ont été un coup dur sur le moral de l équipe, mais lors des périodes où nous pensions avoir trouvé un partenaire, le moral était au plus haut. De même la gestion du budget peut avoir un impact positif ou négatif sur la motivation, et ceci est directement lié à la recherche de partenaire car le budget dépend du partenaire. D autre part, beaucoup de facteurs influent sur le stress de manière négative, mais en contrepartie le stress est bon pour la motivation. Page 15/17 Partie 2

Etude de multidimensionnalité G2 La gestion des connaissances peut être motivante, car l on voit que l on avance et même si l on a fait face à un échec au niveau technique, ce qui pourrait nous laisser croire que nous avons fourni du travail pour «rien», le fait de retracer ce que nous avons fait nous permet de nous valoriser le travail effectué même sans résultats. Mais lorsque la documentation prend plus de temps que la partie pratique, c est un frein à l avancement du projet, ce qui a tendance à baisser notre motivation. 2.2 Limites d un graphe comme celui-ci Sur le graphe réalisé, la gestion des personnalités différentes n est reliée que par des flèches rouges, ce qui peut laisser penser que c est uniquement un frein au projet. Mais dans la partie consacrée à cette dimension, nous avons vu que c est également un atout par la diversité de manière de travailler. Ceci est difficilement réinscriptible dans un diagramme tel que celui là. Page 16/17 Partie 2

Etude de multidimensionnalité G2 Conclusion Même si le projet touche à beaucoup d aspects techniques, au final c est avant tout une aventure humaine, qui nous a permis de découvrir la réalité du travail en équipe. Bien sûr, le groupe a connu des hauts et des bas, des moments de joie comme de doute, mais chaque membre en sortira grandi. Chacun de nous avait déjà du, individuellement, faire face à des fluctuations de motivation, des moments de stress, mais le projet nous a appris à gérer ces phénomènes chez nos coéquipiers. De plus, nous avons également du nous adapter à un budget plus serré que prévu, faire face à des soucis de communication ou découvrir la dure réalité des relations avec un partenaire/client. C est ainsi qu au final, les aspects non techniques évoqués dans cette étude auront été au moins aussi déterminants que les aspects techniques dans le déroulement du projet, et également très formateurs pour notre future vie professionnelle. Page 17/17 Partie 4

Résumé Ce dossier représente le bilan du projet Android mené à bien entre octobre 2012 et Avril 2014. Le groupe projet Android a procédé à la conception et au montage d un robot à l aspect android qui a pour but de communiquer avec son entourage, qu il s agisse d autres objets communicant ou bien de personnes. Vous pouvez lui demander oralement certaines choses, comme par exemple lire les mails, donner la météo... Ses bras et sa tête sont par ailleurs équipés de moteurs pour lui donner un aspect ludique et permettre la mise en place de certaines fonctions plus utiles comme le suivi du visage lors d une visio-conférence. Il s agit d un projet ouvert à tout ceux qui voudrait le reproduire ou réutiliser certaines de ses fonctions. Vous pouvez donc accéder à toutes les sources, qu il s agisse du code ou bien de fichiers de logiciels spécifiques comme CATIA sur le site ralf.ec-lille.fr. Ce dossier aborde tout d abord les aspects techniques du projet qui se décline en quatre pôles : Mécanique, Automatique, Électronique et Informatique. Il présente ensuite la gestion du projet, en introduisant comment le groupe a pu s organiser pendant ces deux années et comment il a su se mettre en valeur dans les communautés de programmeurs. Il évoque finalement les perspectives pour le futur du projet. Page 173/173 Partie 4