ROBOT à base d'Android - Rapport PFE

SIGNATURES

Signature Encadreur ESPRITEC

Signature Département de langue

Robot à base d’Android

i

Dédicaces

DEDICACES

Je dédie ce travail en témoignage de mon profond respect, mon grand amour et toute ma

gratitude à :

Mes chers parents,

Tous les membres de ma famille,

Et tous mes amis.

Houssem Eddine LASSOUED


ii

Remerciements

REMERCIEMENTS

C’est avec un grand plaisir que je tiens tout d’abord à exprimer toute ma

reconnaissance à mon cher encadrant à ESPRIT : Mr Imed AMRI, pour l'attention

qu'il a apportée à mon projet tout au long de ses divers stades allant de l’idée à la

réalisation et pour ces précieux conseils.

Je veux aussi, adresser mes remerciements à tous les membres de l’équipe ‘’ESPRIT

MOBILE‘’ Sana, Salma, Wael, Hamza et Karray pour leurs soutien, appui et

encouragement.

Je suis redevable à tous mes enseignants d’ESPRIT pour leurs efforts qui ont guidé

mes pas tout au long de mes études universitaires.

Que tous ceux qui m'ont soutenu de près ou de loin, trouvent dans ce travail

l’expression de ma reconnaissance infinie.

Je tiens enfin, à exprimer l'honneur que me font les membres du jury pour avoir

accepté de me prêter leur attention et évaluer mon travail.


iii

Résumé

RESUM

Le travail présenté dans ce rapport, qui a été effectué au sein d’ESPRITEC, entre dans le

cadre du projet de fin d’études pour l’obtention du diplôme national d’ingénieur en

télécommunication. Il concerne la conception et la réalisation d’un ROBOT à base d’Android.

Ce ROBOT assure un ensemble de fonctionnalités tels que l’exploration des milieux

quotidiens, dangereux et inaccessibles, il assure la sécurité dans les milieux industriels, par la

détection d’obstacles, détection de fuite de gaz, envoi d’alerte, par plusieurs moyens.

Mots-clés: Android, Robot, Embarqué, IOIO, capteurs

ABSTRACT

The work presented in this report, which was performed within ESPRITEC, is part of the

graduation project for the National Diploma in telecom engineering, it concern the design

and implementation of an Android Based ROBOT.

This ROBOT ensures a variety of features such as the exploration of daily zones, dangerous

and inaccessible; it provides security in industrial sectors, obstacle detection, detection of

gas leakage, sending alarm by several methods

Keywords: Android, Robot, Embedded, IOIO, sensors.


iv

Table des matières

TABLE DES MATIERES

SIGNATURES .................................................................................................... i

DEDICACES ...................................................................................................... i

REMERCIEMENTS ........................................................................................... ii

RESUM ........................................................................................................ iii

TABLE DES MATIERES .................................................................................... iv

LISTE DES FIGURES ....................................................................................... viii

LISTE DES TABLEAUX ...................................................................................... x

INTRODUCTION GENERALE ............................................................................ 1

1. PRESENTATION GENERALE ......................................................................... 3

Introduction ............................................................................................................................ 3

I. Contexte du projet .......................................................................................................... 3

II. Présentation de l’Organisme d’Accueil ........................................................................... 3

III. Problématique du projet ............................................................................................. 4

IV. Solution proposée........................................................................................................ 5

Conclusion .............................................................................................................................. 5

2. ETAT DE L’ART ............................................................................................ 6

Introduction ............................................................................................................................ 6

I. Présentation des Solutions Existantes ............................................................................ 6

Choix de la solution ............................................................................................................. 7

Avantages de la carte IOIO .................................................................................................. 8

II. La Carte IOIO ................................................................................................................... 9

1. Présentation ................................................................................................................ 9

2. Caractéristiques Techniques et capacités ................................................................. 10

3. Plateforme de développement ................................................................................. 11


v

Table des matières

Conclusion ............................................................................................................................ 13

3. SPECIFICATIONS ET ANALYSE DES BESOINS .............................................. 14

Introduction .......................................................................................................................... 14

I. Gestion du projet ........................................................................................................ 14

1. Approche Agile vs. Séquentielle ............................................................................ 15

2. Choix de méthodologie .......................................................................................... 16

1. Adaptative Software Development (ASD) ............................................................ 16

2. Dynamic Software Development Method (DSDM) ............................................. 16

3. eXtreme Programming (XP) ................................................................................... 16

4. Rapid Application Development (RAD) ................................................................ 17

5. Scrum ........................................................................................................................ 17

3. Choix de la méthodologie : Mobile D .................................................................. 17

II. Identification des acteurs .............................................................................................. 19

III. Spécification fonctionnelle ........................................................................................ 19

1. Vision du produit ....................................................................................................... 19

2. Besoin fonctionnels ................................................................................................. 20

3. Besoin non fonctionnels ......................................................................................... 20

4. Cas d’utilisation généraux ......................................................................................... 21

IV. Cas d’utilisations Détaillés ...................................................................................... 23

1. Le 1er Cas- Explorer un lieu .................................................................................... 23

2. Le 2ème Cas- Récupérer le Streaming Vidéo ........................................................ 24

3. Le 3ème Cas- Détecter un obstacle ........................................................................ 25

4. Le 4ème Cas- Détecter une fuite de gaz ................................................................ 26

5. Le 5ème Cas- Récupérer l’état du ROBOT .............................................................. 27

V. Diagramme de séquence système ............................................................................ 28

VI. Diagrammes de Séquence détaillés ...................................................................... 29

1. Diagramme de séquence 1– Déplacer le ROBOT ............................................... 29

2. Diagramme de séquence 2– Surveiller un lieu .................................................... 30

3. Diagramme de séquence 3– Détecter un Obstacle ............................................ 31

4. Diag.de séquence 4 – Détecter une fuite de Gaz .............................................. 32


vi

Table des matières

VII. Maquettes ................................................................................................................. 33

Conclusion ............................................................................................................................ 35

4. CONCEPTION ............................................................................................ 36

Introduction ........................................................................................................................ 36

I. Diagramme de séquence objets ............................................................................... 36

II. Diagramme d’activités ................................................................................................... 37

III. Diagramme de Classe ................................................................................................ 38

Conclusion ........................................................................................................................... 39

5. REALISATION ............................................................................................ 40

Introduction .......................................................................................................................... 40

I. Réalisation Logicielle .................................................................................................. 40

1. Environnement de travail .......................................................................................... 40

II. Réalisation Matérielle ................................................................................................... 48

1. Environnement de travail ....................................................................................... 48

3. Construction matérielle .......................................................................................... 53

4. Estimation du coût .................................................................................................. 55

5. Produit final .............................................................................................................. 56

a. Montage électronique Fritzing .................................................................................. 56

b. Album Photos ............................................................................................................ 57

III. Défis relevés............................................................................................................... 58

IV. Perspective & Evolution ............................................................................................ 58

V. Chronogramme ............................................................................................................. 59

CONCLUSION GENERALE .............................................................................. 60

BIBLIOGRAPHIE ............................................................................................ 61

ANNEXE ........................................................................................................ 62

OpenAccessory et ADK ...................................................................................................... 62

OpenAccessory .................................................................................................................. 62

ADK .................................................................................................................................... 62

Spécification Huawei Gaga U8180 ................................................................................... 63

Capteur Ultrason – Dossier Technique ............................................................................ 64


vii

Table des matières

Motor Driver TB6612FNG .................................................................................................. 68

Capteur de Gaz (MQ5) ....................................................................................................... 72

1er Article sur Tunandroid.com ........................................................................................ 73

Participation à TUNIROBOTS2012 et premier prix ........................................................ 75

Participation à ComNet’2012 Supcom à Hammmet .................................................... 77

Participation à Droidcon Tunis 2012 (cité des sciences) ............................................... 78


viii

Liste des figures

LISTE DES FIGURES

Figure 1 - Android@Home ......................................................................................................... 1

Figure 2 - Logo ESPRIT Mobile .................................................................................................... 3

Figure 3 - Différents environnement du projet ......................................................................... 4

Figure 4 - ADK de Google............................................................................................................ 6

Figure 5 - Arduino Mega2560 ..................................................................................................... 7

Figure 6 - IOIO – Logo officiel ..................................................................................................... 9

Figure 7 - IOIO – Distributeur Sparkfun ...................................................................................... 9

Figure 8 - Montage de la carte IOIO ......................................................................................... 10

Figure 9 - Carte IOIO ................................................................................................................. 10

Figure 10 - Classification des Pins ............................................................................................ 11

Figure 11 - Montage de l'exemple Démo ................................................................................. 13

Figure 12 - Interface de l'application Démo ............................................................................. 13

Figure 14 - Cas d’utilisation généraux du projet ..................................................................... 21

Figure 15 – Cas d’utilisation - Explorer un lieu ......................................................................... 23

Figure 16 - cas d'utilisation - Récupérer le Streaming Vidéo ................................................... 24

Figure 17 - Cas d'utilisation – Détecter un obstacle ................................................................ 25

Figure 18 - Cas d'utilisation - Détecter une fuite de gaz .......................................................... 26

Figure 19 - Cas d'utilisation - Récupérer l’état du ROBOT ....................................................... 27

Figure 20 - Diagramme de séquence système ......................................................................... 28

Figure 21 - Diagramme de séquence – Déplacer le ROBOT ..................................................... 29

Figure 22 - Diagramme de séquence – Surveiller un lieu ........................................................ 30

Figure 23 - Diagramme de séquence – Détecter un Obstacle ................................................. 31

Figure 24 - Diagramme de séquence – Détecter une fuite de Gaz ......................................... 32

Figure 25 - Maquette du ROBOT .............................................................................................. 33

Figure 26 - Maquette de l’interface principale de l’application de commande ..................... 34

Figure 27 - Diagramme de séquence objets............................................................................. 36

Figure 28 - Diagramme d'activités ............................................................................................ 37

Figure 29 - Diagramme de Classe ............................................................................................. 38

Figure 30 - Logo Eclipse ............................................................................................................ 40

Figure 31 - Logo Fritzing ........................................................................................................... 41

Figure 32 - Logo Photoshop...................................................................................................... 41

Figure 33 - Logo GIT .................................................................................................................. 41

Figure 34 - Dropbox logo .......................................................................................................... 41


ix

Liste des figures

Figure 35 - Interface de connexion .......................................................................................... 42

Figure 36 - Joystick de déplacement ........................................................................................ 42

Figure 37 - Zone d'affichage du streaming ............................................................................... 42

Figure 38 - SeekBars ................................................................................................................. 43

Figure 39 - Interface de détection de Gaz ................................................................................ 43

Figure 40 - Interface de détection de distance ........................................................................ 43

Figure 41 - Interface d'affichage d'état de Batterie ................................................................. 43

Figure 42 - Notification de connexion ...................................................................................... 44

Figure 43 - Tab d'orientation .................................................................................................... 44

Figure 44 - écran 1 - Interface de connexion ........................................................................... 44

Figure 45 - écran 2 - Interface de commande .......................................................................... 45

Figure 46 - Interface de l'application Daemon ......................................................................... 48

Figure 47 - Huawei Gaga .......................................................................................................... 49

Figure 48 - Carte IOIO ............................................................................................................... 50

Figure 49 - Plateforme de déplacement .................................................................................. 50

Figure 50 - Motor Driver ........................................................................................................... 50

Figure 51 - Détecteur Ultrason ................................................................................................. 51

Figure 52 - Capteur de gaz........................................................................................................ 51

Figure 53 - Servo Moteur ......................................................................................................... 52

Figure 54 - Brackets .................................................................................................................. 52

Figure 55 - Montage du bras de la caméra .............................................................................. 52

Figure 56 - Batterie ................................................................................................................... 52

Figure 57 – Montage Carte IOIO - Smartphone ....................................................................... 53

Figure 58 – Montage électronique de la plateforme de déplacement .................................... 53

Figure 59 – Montage Carte IOIO et capteur de gaz ................................................................. 54

Figure 60 – Montage Carte IOIO et capteur ultrason .............................................................. 54

Figure 61 – Montage de la carte IOIO avec les servos moteurs .............................................. 55

Figure 62 - Estimation du coût du ROBOT ................................................................................ 55

Figure 63 - Schéma électronique global ................................................................................... 56

Figure 64 - Le Robot dans sa première phase .......................................................................... 57

Figure 65 - Le Robot dans la phase intermédiaire ................................................................... 57

Figure 66 - Le Robot en phase finale ........................................................................................ 58

Figure 67 - Chronogramme général ......................................................................................... 59

Figure 68 - USB Host and Accessory Modes ............................................................................. 62


x

Liste tableaux

LISTE DES TABLEAUX

Tableau 1 Comparaison entre les différentes solutions ........................................................... 7

Tableau 2 - Comparatif entre approche agile et approche classique ..................................... 15

Tableau 3 - Caractéristiques du Mobile-D ................................................................................ 18

Tableau 4 - Définition du problème ......................................................................................... 19

Tableau 5 - Position du produit ................................................................................................ 19

Tableau 6 - Description du cas d'utilisation Explorer un lieu ................................................... 23

Tableau 7 - Description du cas d'utilisation Récupérer le streaming vidéo ............................. 24

Tableau 8 - Description du cas d'utilisation Récupérer la distance ......................................... 25

Tableau 9 - Description du cas d'utilisation récupérer le niveau de gaz ................................. 26

Tableau 10 - Description du cas d'utilisation récupérer l'état du ROBOT ............................... 27

Tableau 11 – Commande des Moteurs .................................................................................... 46


1

Introduction Générale

INTRODUCTION

GENERALE

Android est devenu de plus en plus intéressant pour le développement de matériel.

Maintenant, on devrait bientôt pouvoir brancher des manettes de jeu, un matériel

personnalisé, des capteurs et autres dispositifs et de faire une plate-forme Android-

Anywhere.

Les nouvelles API1 de gestion de matériel permettront à tout le monde de développer des

accessoires matériels pour Android, à partir d’amateurs individuels vers les grandes marques

mondiales. On n’a pas à signer un NDA2, et vous n’avez pas besoin d’une licence de matériel

spéciale, les aspects qui concernent la politique d’Apple n’existeront pas chez Android.

On a toujours été en mesure de connecter un appareil Android à un ordinateur, mais jusqu'à

quelques mois avant, il n'y avait aucun moyen pour les applications Android d’interagir avec

un autre matériel via le port USB. Dans ce contexte, nous explorons un nouvel appui pour les

périphériques d'entrée USB, ainsi que de nouvelles possibilités pour les applications de

communiquer avec des périphériques via le port USB ou même la connectivité Bluetooth.

L’une des annonces (1) les plus importantes du Google IO 20113, est l’arrivée du géant

d’internet dans les systèmes domotiques et électroniques pour maison, office, industrie

etc... Google devrait proposer un écosystème composé de plusieurs éléments Software et

Hardware tournant autour d’Android, le tout disponible en open source.

Pour satisfaire ce nouveau besoin, plusieurs sociétés ont commencé déjà des mois avant

l’annonce de Google, à proposer différentes solutions, parmi

lesquelles nous trouvons La carte IOIO, la solution de Ytai BEN TSVI

(2), un jeune ingénieur développeur et amateur d’électronique, qui a

conçu cette carte dans son passe-temps sans savoir au préalable

que son produit serait exploitable mondialement et adopté

officiellement par Google (3).

C’est dans ce cadre que notre projet s’inscrit : il s’agit de Concevoir,

construire, développer un système embarqué intelligent basé sur

1 Application Programming Interface

2 Non-Disclosure Agreement

3 Google I/O est une conférence annuelle de deux jours, organisée par Google au Moscone Center de San

Francisco, en Californie.

Figure 1 - Android@Home


2

Introduction Générale

Android, soit un Robot à base d’Android.

Tout au long de ce rapport, nous exposerons les différentes étapes de réalisation de notre

projet, en commençant par une présentation des notions fondamentales relatives à la

compréhension de notre sujet, ensuite nous présenterons les différentes solutions

existantes et finalement dans la dernière partie, on donnera une description détaillée de la

solution formulée.


3

Présentation générale

1. PRESENTATION

GENERALE

Introduction Nous présentons dans ce chapitre une étude préliminaire du projet. Dans un premier temps,

nous présentons l’environnement du stage. Par la suite, nous décrivons la problématique,

ainsi que les principaux objectifs du projet.

I. Contexte du projet Dans le cadre de la formation d’ingénieurs Télécommunications à l’École Supérieure Privée

d’ingénierie et de Technologies (ESPRIT), nous avons eu l’occasion d’effectuer notre projet

de fin d’études pour l’obtention du diplôme d’ingénieur national en Télécommunications au

sein du Laboratoire de Recherche et Développement EPRITEC attaché à ESPRIT précisément

avec l’équipe ESPRIT Mobile, généralement ce projet vise à compléter notre formation

universitaire acquise, durant trois ans, au sein de cet établissement, et de nous introduire

dans la vie professionnelle grâce à une mise en pratique de nos connaissances, à l’utilisation

des compétences acquises et à mettre en épreuve notre esprit d’ingénieur. Le projet

consiste à concevoir et réaliser un ROBOT à base du système Android dans le but d’initier et

d’améliorer la recherche dans le domaine Mobile/Embarqué à ESPRIT.

II. Présentation de l’Organisme d’Accueil Le projet a été réalisé au sein d’ESPRITEC, l’unité de Recherche-Développement-Innovation

(RDI) de l’Ecole Supérieure Privé d’Ingénierie et de Technologies (ESPRIT) situé au pôle

technologique El Ghazela. Cette unité s’oriente vers la «Recherche appliquée » et privilégie

deux axes :

– L’axe «Technologique» : pour la maitrise des technologies avancées. Elle nécessite la mise

en place d’une plate-forme pour le développement des services et l’expérimentation des

nouvelles applications et des nouvelles technologies.

– L’axe «Application et service» : pour développer des prototypes, des nouveaux services et

applications avancées pouvant avoir des retombées

industrielles et/ou socio-économique.

ESPRITEC partage ses activités entre plusieurs équipes :

Figure 2 - Logo ESPRIT Mobile


4


- L’équipe ESPRIT Mobile1 réalise des Projets sur les différentes plateformes et systèmes

mobile, comme Android, BlackBerry, iOS, WP7, et aussi sur la SMART TV, l’AR-Drone, ADK,

Panda Board etc…

– L’équipe M2M (Machine to Machine) spécialisé dans la technologie ambiante et le

traitement d’image.

– L’équipe Cloud travaille sur la mise en place des systèmes de Cloud Computing.

– L’équipe E-GOV réalise des projets d’intégration et d’urbanisation des systèmes

d’informations.

Les projets entrepris mobilisent des équipes composées de plusieurs chercheurs,

enseignants-chercheurs, ingénieurs et étudiants en projet de fin d’études (PFE) et projet de

fin de l’année (PFA) sous la conduite d’un chef de projet. Des étudiants en PFE, Mastères ou

Doctorats d’autres institutions sont aussi intégrés dans les équipes de projets dans le cadre

de conventions de partenariat avec les laboratoires et unités de recherche des

établissements publics.

Notre projet, réalisé au sein de l’équipe ESPRIT Mobile entre également dans le cadre d’un

grand projet pédagogique innovant à ESPRIT, vise à intégrer les toutes nouvelles tendances

technologiques dans l’environnement pédagogique à travers des Workshops orientés, des

Travaux Pratiques dirigés, et même des Produits finis à réalisés.

III. Problématique du projet Pour aboutir à un système embarqué intelligent basé sur Android et qui répond aux besoins

demandés par ESPRITEC et par des

différents clients potentiels

(entreprises, personnes), il est

important de se focaliser en premier

lieu sur les problématiques du projet

pour pouvoir s'organiser.

De la sorte, on va déterminer le

périmètre d'action et de faisabilité de

ce projet. Comme il est illustré à la

figure 3, le projet passe par plusieurs

environnements, cela commence sur la

machine du développeur, en passant

par une phase de réalisation matérielle,

vers l’environnement de test réel pour

arriver finalement à l’environnent de

production. De plus, le projet peut être

transféré d’un environnement à un autre plusieurs fois avant qu’il soit finalisé.

1 http://www.espritmobile.com/

Figure 3 - Différents environnement du projet


5


La migration et le déploiement du projet d’un environnement vers un autre ne se fait pas de

la même façon et ne présente pas les mêmes degrés de complexité, puisque sur

l’environnement de développement, une simple compilation suffira, mais le déploiement de

la solution sur les autres environnements surtout la réalisation matérielle présente plusieurs

contraintes et difficultés de plus si nous voulons transférer seulement un composant ou une

fonctionnalité bien spécifique, sans toucher aux autres composants ce qui rend cette

manipulation délicate et pénible d’où le besoin de concevoir une approche qui permet de

réaliser cette tâche.

Il y a aussi d’autres scénarios possible du système qui nous obligent de concevoir une

solution polyvalente tel que :

Système qui répond à des besoins spécifiques en termes de fonctionnalités. Système qui possède une marge d’évolutivité assez grande. Prouver la possibilité de fusionner l’intelligence d’Android avec le milieu quotidien

IV. Solution proposée La solution proposée comme système embarqué intelligent basée sur le OS Android, sera un

ROBOT à base d’Android, équipé avec deux applications, la première aura comme rôle

d’assurer le fonctionnement interne du Robot et l’interaction avec le milieu extérieur, la

deuxième permet à l’utilisateur de commander et interagir avec le ROBOT en offrant une

interface graphique dotée de plusieurs fonctionnalités avancées, et une interface de

connexion sans fil.

Conclusion Ce chapitre nous a servi à mettre notre projet dans son cadre. En effet, notre projet de fin

d’études est réalisé à ESPRITEC, et qui consiste à créer un robot intelligent basée sur

Android, dans le but de suivre et accroître l’innovation technologique dans ce domaine et

initier tout un nouvel horizon dans la création et l’exploitation des systèmes embarqués

intelligents.

Dans le chapitre suivant, nous introduirons les concepts nécessaires à la compréhension de

ce projet à savoir : une présentation de la solution choisie comme concept et comme

plateforme de développement logicielle et matérielle et les autres solutions existantes ainsi

qu’une comparaison entre ces derniers pour mettre l’accent sur leurs points forts et faibles.


6

Etat de l’art

2. ETAT DE L’ART

Introduction Dans ce chapitre nous allons présenter quelques notions et technologies qui vont servir à

mieux comprendre notre sujet, ce chapitre sera composé de cinq parties qui seront réparties

comme suit.

La première partie sera consacrer à la présentation du principe et concept des solutions

existantes et leurs nouveaux enjeux avec une étude comparative entre les produits similaires

du marché, la seconde partie présente la carte IOIO, son architecture physique et logique

ainsi toutes ces composantes pour finir avec une brève présentation de sa plateforme de

développement.

I. Présentation des Solutions Existantes Les systèmes embarqués ne sont pas particulièrement nouveaux, les premiers systèmes

sont apparus au début des années 60. La première génération de ces systèmes a été

construite sur des solutions lourdes et complexes à déployer en se basant essentiellement à

la programmation bas-niveau et les résultats obtenus n’ont pas toujours été à la hauteur des

espérances des utilisateurs. Il faut également ajouter que les systèmes embarqués classiques

n’étaient pas suffisamment matures pour tenir véritablement les promesses de l’unification

des interfaces de communications vis-à-vis l’utilisateur.

Fort heureusement la situation a beaucoup changé ces derniers temps

grâce à l’apparition du système mobile Open Source Android: de

nouvelles plates-formes techniques embarquées plus simples et plus

complètes telles que la carte IOIO, la carte Arduino (4), l’ADK de Google

(5), la PANDA BOARD et la Beagle BOARD sont apparues et le niveau de

maturité des systèmes embarqués à base d’Android s’est

considérablement accru. Il en résulte le début d’un grand retour des

projets embarqués conçues à base d’ANDROID.

Vu la présence de quelques produits exploitables sur le marché, le choix

d’une solution pour la création du ROBOT, se base sur plusieurs critères tel que le prix et les

fonctionnalités offertes, la compatibilité avec les autres acteurs environnementaux tel que

les composants électroniques, et surtout la réponse aux besoins demandés.

Figure 4 - ADK de Google


7

Etat de l’art

Le tableau ci-dessous présente une étude comparative entre les principales solutions sur le

marché.

Critères de comparaison Carte Arduino Carte Google ADK Carte IOIO Développement JAVA, C++ Sketch JAVA, C++ Sketch JAVA (+IOIO Lib) Compatibilité Versions Android V1.5 with ADB V3.1 Or V2.3.4 V1.5 and UP Dimensions 68 - 53mm 86 - 53mm 70 - 30mm Compatibilité Bluetooth Bluetooth

Shield Bluetooth Shield NATIVE (V.3)

Plug & Play Compatibilité OpenAccessory Non Oui Oui (V.3) Connectivité USB Hôte Oui Oui Oui Prix 75$ 80$ - 400$ 50$

Tableau 1 Comparaison entre les différentes solutions

D’après le comparatif ci-dessus nous constatons que la carte IOIO est la carte la plus adaptée à la création de ce système intelligent.

Choix de la solution :

Les deux différences les plus significatives entre les 3 solutions sont les suivantes:

ADK et ses clones ne fonctionnent que sur des appareils Android très spécifiques, tandis que

la carte IOIO pourrait fonctionner sur presque n'importe quel appareil Android depuis

Android 1.5.

Avec ADK ou l’Arduino vous devriez écrire à la fois le côté Android (Java) et de côté carte (C++) du logiciel (Sketch (6)) et d'établir un protocole de communication (7) entre eux. Vous auriez à connaître les deux langages et deux IDE1 différents et, même si vous faites quelque chose de très trivial, il faudra une importante durée de temps pour obtenir quelque chose qui fonctionne de manière fiable. Avec IOIO, vous écrivez simplement le côté d'Android. Il suffit d’inclure une bibliothèque appelée IOIOLib dans l’application, ce qui fournit une API qui vous permet de contrôler les broches de la carte IOIO et ses fonctions comme s'ils étaient physiquement connectés à votre Android. Vous n'avez pas besoin de se soucier du fait qu'il y a un processeur distinct, des protocoles de communication, etc…

Si vous vous en tenez un Dongle Bluetooth dans IOIO au lieu d'un câble USB à l'Android, il communiquera sans fil avec l’appareil. La bonne chose est que votre application n'a pas besoin de s'en soucier, et vous pourrez même revenir en arrière lorsque votre application est en cours d'exécution.

IOIO Supporte officiellement le protocole OpenAcessory (ADK)2 de Google. Cette nouvelle fonctionnalité est actuellement réalisée en mode bêta. Les Informations techniques disponibles sur le wiki

1 Integrated Development Environment

2 Le terme "ADK" Accessory Development Kit : est souvent utilisé comme synonyme de "OpenAccessory",

lorsqu’on dit que cette carte supporte ADK ça veut dire qu'elle supporte le protocole OpenAccessory.

Figure 5 - Arduino Mega2560


8

Etat de l’art

IOIO. La façon dont cela fonctionne est que la carte IOIO sera capable de communiquer avec le périphérique Android via le protocole OpenAccessory. Lorsque ce n'est pas supporté, il sera parfaitement switcher à ADB1. Cela vous permet de connecter la même carte IOIO aux deux types de dispositifs, les nouveaux et les anciens. L’application peut très facilement être portée sur le nouveau mode, cela ne nécessite que quelques non-intrusive modifications aux métadonnées de l’application.

Avantages de la carte IOIO

La carte IOIO Supporte toutes les versions Android - puisque elle fonctionne aussi bien avec OpenAccessory et l’ADB elle peut communiquer avec une très grande variété de dispositifs Android existants, en s'appuyant sur OpenAccessory quand elle existe et en tirant parti des fonctionnalités supplémentaires de l’ADB. D'autres cartes, qui ne prennent pas en charge de l’ADB, sont limitées à tous, sauf aux derniers appareils Android sur le marché.

Fonctionnalité - IOIO est presque identique à Arduino Mega (figure 5) en termes de nombre de broches (pins) et de fonctions. La seule différence est le nombre de canaux PWM (IOIO-9, Mega-16) et les canaux de TWI (IOIO-3, Mega-1).

Coût - à 50 $, IOIO semble actuellement être la carte la moins chère commercialisée et disponible sur le marché. Une alternative à proximité est une version DIY, ce qui coûte 55 $ et nécessite une certaine amélioration de plus.

Développement de haut niveau - les autres cartes nécessite à la fois une application Android et un code intégré en C pour la carte, la conception de votre propre protocole de communication. IOIO fait tout cela automatiquement, il ne reste qu’écrire le code Android de l’application, En utilisant une API Java de haut niveau pour contrôler les fonctions de la carte.

Support Forum et Wiki - IOIO a un groupe de discussion active et une extensive documentation wiki, qui continue de croître rapidement. Le projet IOIO est engagé aussi bien dans la communauté amateur que dans la communauté professionnelle

Dimensions - IOIO est probablement la plus petite carte, presque aussi petit qu’on pourrait obtenir avec 48 broches E/S, des broches d'alimentation et d'un connecteur USB. Il est beaucoup plus petit que la carte ADK.

Bootloader - firmware - IOIO comprend un chargeur de démarrage sécurisé, qui permet les mises à niveau à effectuer à travers un appareil Android.

Alimentation - IOIO possède un commutateur-mode à 5V capable de délivrer jusqu'à 1,5 A. Cela permet de charger simultanément un appareil Android et alimenter deux servos moteurs standard sans problème. Quelques autres cartes nécessitent une alimentation de 5V externe pour soutenir ce cas d'utilisation. En outre, IOIO a un limiteur intégré qui permet de limiter le courant de charge d'Android. Ceci est très utile pour les configurations fonctionnant sur batterie, lorsque vous ne voulez pas l'appareil Android à vider votre

1 Android Debug Bridge


9

Etat de l’art

batterie.

Open-Source - Contrairement à certaines des autres solutions, le matériel de l'IOIO, le Firmware et le logiciel(les APIs) sont totalement open-source avec une licence FreeBSD (très permissive). Cette approche a été choisie parce que selon l’inventeur c'est ce qui marche le mieux pour la communauté des amateurs, et permet aux gens de personnaliser le produit pour leurs besoins, contribuer au projet, le comprendre mieux et concurrencer sur son prix.

En conclusion, la carte IOIO est très compétitive avec les autres plates-formes compatibles OpenAccessory, d’où le choix d’utiliser cette carte lors de ce projet.

Figure 6 - IOIO – Logo officiel

II. La Carte IOIO

1. Présentation IOIO (prononcez: yo-yo) est un produit qui vous permet de connecter des circuits

électroniques à un appareil Android et de les contrôler à partir d'une application

Android.

Il est composé d'une petite carte PCB (2.7x1.2

"= 7x3cm) spécialement conçu pour être piloté

via un dispositif Android (avec version d'OS 1.5

et sup.) par le biais de son port USB Ce pilotage

s'effectuera via des API JAVA™ simples et

intuitives que vous utilisez dans votre

application Android qui gère toutes les

communications avec la carte sans avoir

recours à une programmation embarquée bas

niveau, ni au moindre programmateur externe).

Aucune modification de l'appareil Android est nécessaire - vous éviter la complication de

la modification et l'annulation de la garantie.

Dès lors le module IOIO permettra à votre système Android d'interagir avec le monde

extérieur en lui permettant de disposer de ports d'entrée/sorties tout ou rien, de sortie

PWM, d'entrée analogiques, de liaison SPI™, I2C™, UART...

Figure 7 - IOIO – Distributeur Sparkfun


10

Etat de l’art

IOIO est disponible pour achat en ligne à partir du site officiel de SparkFun Electronics1.

La totalité du logiciel et du matériel sont à 100% open-source sous une licence

permissive.

2. Caractéristiques Techniques et capacités La carte électronique est construite autour d’un microcontrôleur PIC série 24F, qui dispose

d’une connexion USB hôte. Il suffit donc de la relier à l’aide d’un câble USB à un périphérique

Android (OS v1.5 minimum) pour que la carte IOIO interprète des commandes reçues par

une application.

Pour mieux comprendre c’est quoi la carte IOIO et comment utiliser au mieux ses

caractéristiques, cette section prend une brève tournée à travers ce produit et fournit des

introductions aux quelques-unes de ses caractéristiques et ses capacités.

Pour les spécifications techniques, la carte IOIO se compose de :

1. Connecteur USB (type A) connecteur femelle: Permet de connecter l'appareil Android.

2. GND pins (9 pins): prise de terre.

3. VIN pins (3 pins): Utilisé pour l'alimentation à la carte. Tension entre 5V-15V doit être fournie.

4. 5V pins (3 pins): Normalement, utilisée comme sortie 5V lorsque la carte est alimentée à

partir de VIN. Peut être utilisé comme entrée 5V en cas VIN n'est pas connecté.

5. 3.3V pins (3 pins): 3,3 V en sortie.

6. I/O pins (48 pins, numérotées 1-48): Des broches E/S. Certains ont des fonctions spéciales,

voir ci-dessous:

48 pins d’entrées/sorties (peuvent fonctionner comme des entrées et sorties

numériques.)

1 http://www.sparkfun.com/

Figure 8 - Montage de la carte IOIO

Figure 9 - Carte IOIO


11

Etat de l’art

16 entrées analogiques (10-bits)

Jusqu’à 9 sorties PWM

Jusqu’à 4 liaisons séries UART

Jusqu'à 3 canaux SPI.

Jusqu’à 3 liaisons TWI (I2C-compatible)

7. LED d'alimentation: S'allume lorsque la carte IOIO est sous tension.

8. Stat LED: S'allume brièvement lors de la mise sous tension, puis devient sous le contrôle des

applications.

9. MCLR pin: Non normalement utilisé. Son but est de programmer le Firmware nouveau

Bootloader sur la carte IOIO.

10. Charge Current Trimmer (CHG): Permet de régler la quantité de courant de charge fourni

sur la ligne VBUS de l'USB à l'appareil Android. Tourner dans le sens (+) augmente de

courant de charge.

11. Régulateur de tension 5v - 1,5 A : Peut charger l'appareil Android ainsi que la puissance

d'un couple de petits moteurs.

12. Bootloader : intégré sur la carte, permettant la mise à niveau du Firmware en direct à

partir d’une application sur l’appareil Android.

Figure 10 - Classification des Pins

3. Plateforme de développement Dans cette section, nous allons jeter un œil à l'architecture de la carte IOIO du point de

vue d'un développeur.

La carte IOIO offre un ensemble de logiciels et Firmware disponible en téléchargement via la

page Github 1officielle du Développeur (8).

1 GitHub est un service web d'hébergement et de gestion de développement de logiciels, utilisant le

programme Git


12

Etat de l’art

Le pack se compose de :

IOIOLib (V3.23) : API JAVA officielle pour le développement sous Android

Image IOIO Bootloader (v3.23) : pour mettre à jour le Bootloader de la carte

Firmware Image (v2) : pour mettre à jour le Firmware de la carte IOIO

L’application IOIO Manager (9) : elle permet de gérer les images des applications ainsi

que les images de Bootloader

IOIOLib – Principe de développement :

IOIOLib est une bibliothèque Android, qui permet à votre application Android de contrôler la

carte IOIO. Elle expose un ensemble d'interfaces Java, couvrant les différentes fonctions de

la carte électronique. Lorsque vous générez votre application, IOIOLib se fait emballé dans

votre fichier Apk, afin que votre application soit autonome et ne nécessite aucune

installation supplémentaire sur l'appareil Android qui l'exécute. L'ensemble du code est pur

Java, dépendant uniquement de la norme Android 1.5 (ou version ultérieure).

IOIOLib est tout documenté au format Javadoc standard, et cette documentation est

destinée à être complète et être utilisée comme référence pendant le codage. Dans ce qui

suit, nous essayons de couvrir une utilisation de la bibliothèque à partir d'une approche

commune de cas d'utilisation plutôt que d'être 100% formelle.

La bibliothèque est organisée en plusieurs packages Java. Le package ioio.api contient toutes

les APIs publiques pour contrôler la IOIO. Ceci est le package de notre application qui sera

utilisé. Dedans, le paquet ioio.api.exception contient certaines exceptions levées par l'API

IOIO. Le paquet ioio.impl contient la mise en œuvre de ces interfaces et n'est pas destinée à

être utilisée directement. Le paquet ioio.util contient des utilitaires utiles qui peuvent vous

rendre la vie un peu plus facile lors de l'écriture des applications ioio, mais ne fournissent

pas les fonctionnalités de base. Ce paquet contient une classe, qui sert de classe de base

pour notre application basée sur IOIO, qui gère automatiquement la bonne connexion /

déconnexion à la carte IOIO en réponse à des événements d'application.

IOIOLib – Utilisation : (sous Eclipse)

La dernière version de IOIOLib peut être téléchargée depuis la page Téléchargements (10).

Extraire IOIOLib à un endroit où vous voulez normalement garder vos projets

Android.

L'importer dans Eclipse en utilisant Fichier> Importer ... > Général> Projets existants

dans Workspace ..., puis choisissez le répertoire IOIOLib vous venez de créer et

cliquez sur Terminer.

Il référence de votre projet d'application, conformément à ces instructions

Assurez-vous que votre application déclare android.permission.INTERNET. Cela

peut se fait en ouvrant le fichier AndroidManifest.xml qui se trouve à la racine de

votre projet, allez à l'onglet Permissions> Ajouter ... > Permissions Utilisateur>


13

Etat de l’art

Sélectionnez android.permission.INTERNET sous "Nom".

Assurez-vous que vous avez activé le débogage USB sur votre appareil Android, en

allant dans Paramètres> Applications> Développement> Activer le débogage USB.

Voici à quoi ressemble un exemple de HelloIOIO

public class MainActivity extends IOIOActivity {

...

class Looper extends BaseIOIOLooper {

private DigitalOutput led_;

@Override

protected void setup() throws ConnectionLostException {

led_ = ioio_.openDigitalOutput(0, true);

}

public void loop() throws ConnectionLostException {

led_.write(!button_.isChecked());

try {

Thread.sleep(100);

} catch (InterruptedException e) {

}

}

}

@Override

protected IOIOLooper createIOIOLooper() {

return new Looper();

}

}

Cette Application permettra d’allumer la LED numéro 0 de la carte IOIO via un Bouton

Conclusion Dans ce chapitre, nous avons passé en revue les différentes notions nécessaires à la

compréhension de notre sujet et nous avons mené une étude comparative entre les

différentes approches et solutions disponibles pour réaliser un système embarqué basé sur

Android.

Puisque ce projet est notre premier contact avec le milieu Android embarqué, il nécessite

beaucoup de recherche et dès le début nous savions que selon nos découvertes nous serons

amenés à changer les spécifications, avec ces contraintes.

Figure 11 - Montage de l'exemple Démo

Figure 13 Figure 12 - Interface de l'application Démo


14

Spécifications et analyse des besoins

3. SPECIFICATIONS

ET ANALYSE DES

BESOINS

Introduction Après avoir présenté le cadre général de notre projet, nous allons, dans ce chapitre, entamer

la phase de spécification et d’analyse des besoins. En effet, tout au long de ce chapitre, nous

allons identifier et préciser les besoins à satisfaire. Ces besoins représentent aussi les

fonctionnalités à réaliser dans notre application, ce chapitre sera présenté sous forme de

« User cases » et « Sequence Diagrams »- scénarios. Nous commençons ce chapitre avec une

description de la gestion de notre projet

Le choix d’une méthode agile est évident et après une comparaison entre les principales

méthodes agiles, nous allons choisir la méthodologie la plus adéquate pour réaliser ce

projet.

I. Gestion du projet Trop souvent, de bonnes idées de projet n’aboutissent pas, du fait d’une mauvaise

organisation. Pour améliorer nos chances de réussite, nous devons choisir une méthode de

développement de logiciels pour notre application.

La discipline de gestion des projets comporte deux grandes branches de méthodologie, les

méthodes classiques (ou Séquentielle) et les méthodes agiles.

Nous allons dans cette partie présenter ces deux approches, faire une brève description des

différentes méthodologies, et présenter la méthodologie que nous allons l’adaptée en

spécifiant les avantages et la compatibilité avec notre cas de figure.


15


1. Approche Agile vs. Séquentielle Pour bien choisir notre type de méthodologie de travaille nous avons dressé le tableau 2-6

qui présente une comparaison entre les deux approches par thème. (11)

Thème Approche Séquentielle Approche agile

Cycle de vie En cascade ou en V, sans rétroaction possible, phases séquentielles.

Itératif et incrémental.

Planification Prédictive, caractérisée par des plans plus ou moins détaillés sur la base d’un périmètre et d’exigences définies au début du projet.

Adaptative avec plusieurs niveaux de planification avec ajustements si nécessaires au fil de l’eau en fonction des changements survenus.

Documentation Produite en quantité importante comme support de communication, de validation et de contractualisation.

Réduite au strict nécessaire au profit d’incréments fonctionnels opérationnels pour obtenir le feedback du client.

Équipe Une équipe avec des ressources spécialisées, dirigées par un chef de projet.

Une équipe responsabilisée où l’initiative et la communication sont privilégiées, soutenue par le chef de projet.

Qualité Contrôle qualité à la fin du cycle de développement. Le client découvre le produit fini.

Un contrôle qualité précoce et permanent, au niveau du produit et du processus. Le client visualise les résultats tôt et fréquemment.

Changement Résistance voire opposition au changement. Processus lourds de gestion des changements acceptés.

Accueil favorable au changement inéluctable, intégré dans le processus.

Suivi de l’avancement

Mesure de la conformité aux plans initiaux.

Analyse des écarts.

Un seul indicateur d’avancement : le nombre de fonctionnalités implémentées et le travail restant affaire.

Gestion des risques

Processus distinct, rigoureux, de gestion des risques.

Gestion des risques intégrée dans le processus global, avec responsabilisation de chacun dans l’identification et la résolution des risques. Pilotage par les risques.

Mesureur succès Respect des engagements initiaux en termes de coûts, de budget et de niveau de qualité.

Satisfaction client par la livraison de valeur ajoutée.

Tableau 2 - Comparatif entre approche agile et approche classique pour la gestion de projet

Maintenant que nous connaissons mieux les différences majeures entre approches traditionnelles et approches agiles à travers la comparaison faite ci-dessus nous avons opté


16


pour une approche agile pour gérer notre projet.

2. Choix de méthodologie Puisque nous avons choisie d’adopter une approche agile pour gérer notre projet nous allons

maintenant choisir quelle méthode agile à suivre tout au long de la réalisation de notre

Projet.

Pour choisir une méthode nous citons, tout d’abord, quelque unes parmi les principales

méthodes agiles, par ordre alphabétique, avec leurs caractéristiques principales.

1. Adaptative Software Development (ASD)

Ses caractéristiques principales sont :

Focaliser sur l’objectif. Se baser sur des composants. Itérer. Découper le temps et fixer des deadlines (timeboxing). Piloter le projet par les risques. Accepter le changement.

2. Dynamic Software Development Method (DSDM) DSDM se base sur neuf principes :

Implication active des utilisateurs. Autonomie et pouvoir de décision des équipes. Livraisons fréquentes. Adéquation aux besoins des clients comme seul critère d’acceptation du produit. Développement itératif et incrémental. Modifications réversibles. Définition globale macroscopique des besoins. Intégration des tests dans tout le cycle de vie. Collaboration et coopération entre toutes les parties prenantes.

3. eXtreme Programming (XP)

XP repose sur quatre valeurs :

Communication : l’effort de communication entre les différents intervenants est indispensable pour atteindre l’objectif commun. Nous devons privilégie la communication directe, dans le recueil et la clarification des besoins, dans la planification des itérations, dans la répartition et l’exécution des travaux.

Simplicité : la solution la plus simple est la meilleure pour atteindre les objectifs ; grâce à cette simplicité, l’application pourra évoluer facilement, si nécessaire. La simplicité est applicable au client dans la définition de ces besoins, dans le choix des outils et du processus.

Feedback : le retour d’information est essentiel pour valider le fait que le projet est sur la bonne voie : tests unitaires pour valider le fonctionnement du code, intégration continue


17


pour détecter des anomalies, tests fonctionnels pour valider la conformité aux besoins, livraisons fréquentes…, autant de pratiques qui rendent plus aisées les adaptations éventuelles, sans attendre le terme du projet.

Courage : le courage est nécessaire aussi bien chez le client que chez les développeurs. Pour mener à bien un projet XP, le client doit avoir le courage de donner un ordre de priorité à ses exigences, de reconnaitre que certains de ses besoins ne sont pas toujours très claires. Le développeur doit aussi avoir le courage de modifier l’architecture même si le développent est déjà bien avancée, de jeter du code existant et d’accepter qu’il est parois plus rapide et efficace de réécrire une portion de code à zéro plutôt que de bricoler du code existant.

4. Rapid Application Development (RAD) RAD n’est pas à proprement parler une méthode agile, mais c’est une approche (semi)itérative incrémentale préconisant un usage intensif des techniques de communication facilitée.

5. Scrum

Les valeurs mises en avant par Scrum sont les suivantes :

Transparence : La transparence garantit que tous les indicateurs relatifs à l’état du développement sont visibles par tous ceux qui sont intéressés par le résultat du produit. Non seulement la transparence pousse à la visibilité mais ce qui est rendu visible doit être bien compris ; cela signifie que ce qui est vu est bien le reflet de la réalité. Par exemple, si un indicateur annonce que le produit est fini (ou une partie seulement du produit), cela doit être strictement équivalent à la signification de fini définie par l’équipe.

Inspection : Les différentes facettes du développement doivent être inspectées suffisamment souvent pour que des variations excessives dans les indicateurs puissent être détectées à temps.

Adaptation : Si l’inspection met en évidence que certains indicateurs sont en dehors des limites acceptables, il est probable que le produit résultant sera également inacceptable si on ne réagit pas ; le processus doit donc être ajusté rapidement pour minimiser les futures déviations.

Une étude de ces différentes méthodologies révèle qu’elles ont un tronc commun, mais elles

se différencient par leur degré de formalisme, les revues, le rythme du projet, le nombre et

la longueur des itérations et à la taille de projets.

Après cette étude comparative notre choix s’est focaliser sur deux méthode Scrum et XP,

mais nous avons choisi XP puisque la qualité principale de cette dernière est la simplicité de

plus cette méthode privilégie une équipe autonome, malgré que nous n’avons pas respecté

une caractéristique fondamentale de XP qui est le travail en binôme, ce qui n’est le cas avec

notre projet, puisqu’il est réalisé par un seul développeur.

3. Choix de la méthodologie : Mobile D

Tandis que beaucoup de méthodes agiles ont été présentées, aucune d’elles n’est


18


spécifiquement visée pour le développement mobile et surtout pour notre cas.

Mobile-D est une approche agile pour l’équipement mobile qui est basé sur XP (eXtrême

Programing), la méthodologie Crystal (Scalability) et Rational Unified Proces (Assurance de

cycle de vie). Elle est conçue pour rencontrer les caractéristiques spécifiques de

développement de l’application mobile et le standard de qualité de l’industrie.

Le travail de développement est divisé en différentes phases qui sont l’exploration,

initialisation, production, stabilisation, et test et correction du système.

Il se dégage de ce qui précède que nous allons suivre la méthodologie XP (eXtreme

Programing) qui est un processus de développement logiciel agile.

XP propose un cycle de développement itératif incrémental, qui fusionne les trois phases de

conception, de réalisation et de test pour chaque itération du logiciel à réaliser.

En faisant la combinaison des avantages des trois méthodes, Mobile-D satisfait les

caractéristiques du développement requis, Cela est représenté dans le tableau 3 suivant :

Caractéristiques de Mobile-D

Rational Logiciel Mobile

Changement élevée d’environnement

En raison du changement élevé des exigences, on a besoin de l’approche de développement incrémental et itératif

Incertitude élevée, environnement dynamique: Centaines de nouveau de téléphones portables sont fabriqués chaque année

Petite équipe de développement

Les petites équipes peuvent réagir plus rapidement, partager l’information, peu de documentation est nécessaire

Majorité de logiciel mobile sont développés par micro (<10) ou moyennes (<250) entreprises, La taille de l’équipe est souvent inférieure à 20 personnes

Client identifiable Pour éviter le malentendu d’affaires

Nombre potentiellement illimité d’utilisateur. Client d’affaires plus facile à identifier, par exemple distributeur

Environnement de développement d’objet orienté

Flexible, extensive, etc… Utilise souvent Java et C++

Non sécurité critique

Les échecs ne causent pas la perte des vies

Majorités de logiciel mobile existant sont pour le but de divertissement. Les équipement mobiles sont non fiables

Logiciel de niveau d’application

Les grands systèmes embarqués exigent la communication étendue et mécanismes de vérification.

Tandis que les systèmes mobiles sont complexes et fortement dépendants, les applications mobiles peuvent être applications autonomes

Petit système Moins de conception d’Up front requise

La taille des applications mobiles varie, mais généralement elles sont moins que 10.000 lignes de code

Cycle de développement court

Pour les buts de la rétroaction rapide

Les cycles de développement varient. En général, les applications mobiles peuvent être développés de 1 à 6 mois

Tableau 3 - Caractéristiques du Mobile-D


19


II. Identification des acteurs L’acteur de notre Système Intelligent (Robot) s’intercale entre 3 types d’utilisateurs

selon l’environnement d’exploitation, soit les entreprises (principalement

industrielles) ou les personnes physiques pour des besoins personnelles, ou les

établissements de Recherche (Universités, Laboratoires,…).

Ces utilisateurs jouent presque le même rôle ce qui nous permet de dire que notre application n’a qu’un seul acteur qu’on l’appelle dorénavant UTILISATEUR.

III. Spécification fonctionnelle Nous commençons par présenter la vision et le use case général de notre projet puis nous découpons le projet sous forme de scénarios.

1. Vision du produit Pendant les premières réunions avec le responsable à ESPRITEC (Equipe ESPRIT Mobile) nous

avons discuté les différents côtés de notre projet ce qui nous a permis de définir l’énoncé du

problème, l’impact de la problématique, ce que permet le produit, et la position du produit à

réaliser dans son environnement et par rapport à l’existant, comme montré dans les deux

tableaux suivants:

Le problème d’intégration de solutions intelligentes dans le monde réel en utilisant l’intelligence logicielle disponible(Android).

Affecte les milieux domotiques, industriels, …

L’impact du problème est manipulation délicate et trop de temps perdu pour interagir avec le milieu quotidien d’une façon automatisée

Une solution réussite permettrait

une manipulation plus raffiné des fonctionnalités à assurer par le système intelligent, une interaction efficace avec le monde extérieur

Tableau 4 - Définition du problème

Pour ESPRITEC

Type de produit ROBOT(Hardware) + 2 applications mobiles.

Qui permet d’assurer différentes types de fonctionnalités comme l’exploration, la sécurité, la surveillance, la réaction intelligente.

A la différence de les systèmes embarqués existants, Limité en fonctionnalités, Programmables généralement en langage bas niveau, et ne communique pas avec les moyens disponibles pour tout le monde (Smartphone, Tablet, Navigateur Web).

Tableau 5 - Position du produit


20


2. Besoin fonctionnels

a. Explorer un lieu

Le ROBOT doit être explorateur, il doit être doté de capacités de déplacement, dans les

différentes directions y inclut les rotations à gauche et à droite, l’utilisateur doit être capable

de le faire déplacer à volonté et à distance.

b. Récupérer le Streaming Vidéo

L’application de commande doit récupérer le streaming vidéo à partir de la caméra du

ROBOT, pour permettre à l’utilisateur de le visualiser directement.

c. Détecter un obstacle

Le ROBOT doit être capable de détecter un obstacle à une portée définie, et de l’éviter, en

donnant en temps réel des indications sur la distance qui le sépare de cet obstacle.

d. Détecter une fuite de gaz

Le ROBOT doit être capable de détecter le niveau de gaz (type à définir après) dans l’air, et

de lancer une alarme lorsqu’il détecte une fuite et un niveau élevé.

e. Lancer une Alerte en cas d’urgence

Le ROBOT doit être capable d’activer une alerte et d’envoyer des notifications par les

moyens disponibles (Email/SMS) en cas d’urgence.

f. Avoir l’état du Robot

L’utilisateur sera capable de récupérer un ensemble d’information concernant l’état actuel

du ROBOT, soit le niveau du signal wifi, le niveau de batterie, les 3 axes du ROBOT dans

l’espace pour détecter les inclinaisons, la géolocalisation etc...

3. Besoin non fonctionnels

a. Ergonomie L’application de commande doit respecter les standards de l’interfaçage Homme-Machine, en offrant à l’utilisateur une interface ergonomique et une bonne expérience d’utilisation. L’apparence de cette interface est principalement caractérisée par des composants, des formes, des couleurs et la disposition des éléments.

b. Contraintes techniques et matérielles La partie technique et matérielle du ROBOT doit être adaptée aux besoins du projet et doit être totalement contrôlable et gérable via la partie logicielle et d’une façon transparente à l’utilisateur.


21


c. Contraintes d’utilisation L’interface utilisateur doit être simple et facile à comprendre pour que l’utilisateur puisse bénéficier des fonctionnalités du système.

d. Contraintes de performance Le temps de réponse de tout le système doit être acceptable pour une utilisation en temps réel. Le système doit être stable et sûr.

e. Automatisation partielle Le système doit être d’une façon partielle automatisé, dans la communication ROBOT-Utilisateur et inversement, et dans les différentes parties de détection.

f. Maintenabilité

Les différents modules développés du système doivent être faciles à maintenir. Pour cela, le code doit être lisible et bien structuré. Nous devons respecter les standards de codage concernant par exemple les noms des attributs et des variables, les noms des méthodes ainsi que la disposition des commentaires.

4. Cas d’utilisation généraux Pour avoir une vue globale sur les grandes lignes de notre système, les spécifications

générales sont synthétisées sous la forme du diagramme UML des cas d’utilisation de la

figure 3-17 : ce schéma résume les actions que peut effectuer l’utilisateur du projet.

Figure 14 - Cas d’utilisation généraux du projet


22


Cas d’utilisation 1: Explorer un lieu

L’utilisateur sera capable de déplacer le ROBOT à distance, directement à travers une

interface dédiée équipée avec les composants nécessaires, une certaine communication

avec le ROBOT sera établie au préalable, puis les commandes de déplacements seront

envoyés instantanément au ROBOT, qui se charge de la réception des commandes, du

traitement, et de l’exécution des ordres.

La possibilité d’orienter la caméra du ROBOT pour visionner une certaine zone précise aussi

entre dans cette idée d’explorer des lieux.

Cas d’utilisation 2 : Récupérer le Streaming Vidéo

Le ROBOT se charge d’enregistrer en temps réel une partie du flux vidéo depuis la caméra,

l’envoyé à l’application de commande, et ainsi de suite.

Cas d’utilisation 3 : Récupérer la distance à un obstacle

L’utilisateur doit avoir la possibilité de récupérer à tout moment la distance à l’obstacle le

plus proche directement sur l’interface de commande.

Le ROBOT se charge d’activer, stabiliser le capteur et d’exécuter à tout moment cette

fonctionnalité, une possibilité de prendre une décision si la distance calculée est moins d’une

certaine valeur.

Cas d’utilisation 4 : Afficher le niveau de gaz

L’utilisateur doit avoir la possibilité de récupérer à tout moment le niveau de gaz

directement sur l’interface de commande.

Le ROBOT se charge d’activer, stabiliser le capteur et d’exécuter à tout moment cette

fonctionnalité, et d’être en mode écoute s’il y aura un changement dans le niveau de gaz.

Cas d’utilisation 5 : Activer une Alerte Email/SMS

En cas d’urgence le ROBOT peut envoyer des alertes SMS/Email à un correspondant et lancer

une alerte sonore

Cas d’utilisation 6 : Récupérer l’état du ROBOT

L’utilisateur peut recevoir un ensemble d’information depuis le ROBOT :

Afficher l’orientation du ROBOT : cette information est obtenu directement depuis

l’accéléromètre intégré dans le Smartphone du ROBOT, cette information nous donne une

indication sur l’inclinaison du ROBOT, l’activation de la géolocalisation sera aussi disponible

en OUTDOOR.

Afficher l’état du signal WIFI : cette information est primordiale pour l’utilisateur pour garder

la connectivité au ROBOT, une fois le signal est faible, une alerte sera affichée à l’écran

directement et avant la coupure de connexion.


23


Afficher l’état de la batterie : elle permet à l’utilisateur de connaitre le pourcentage de

batterie du ROBOT et de savoir une approximation du temps restant avant l’alimenter.

IV. Cas d’utilisations Détaillés Cette section sera consacrée à la présentation des cas d’utilisations principales.

1. Le 1er

Cas- Explorer un lieu

Figure 15 – Cas d’utilisation - Explorer un lieu

Ce diagramme représente les différents aspects de ce que nous appelons exploration des

lieux, que nous présentons dans ce tableau :

Cas d’utilisation n° 001

Nom Explorer un lieu

Acteur Utilisateur

Description Permettre de déplacer librement le Robot et explorer un lieu bien déterminé.

Pré-Conditions ROBOT alimenté et activé,

connexion avec la partie commande établie

Post-Conditions N/A

Scénario nominal 1. Commander le ROBOT à distance pour le faire déplacer en avant/arrière, le faire tourner à gauche/droite

Scénario Alternatif N/A

Exception Erreur de connexion :

Le système s’arrête Tableau 6 - Description du cas d'utilisation Explorer un lieu


24


2. Le 2ème

Cas- Récupérer le Streaming Vidéo

Figure 16 - cas d'utilisation - Récupérer le Streaming Vidéo

Ce diagramme représente la fonctionnalité responsable de la récupération du streaming

vidéo, le ROBOT sera équipé d’une caméra pour l’enregistrement vidéo, l’utilisateur doit

avoir la possibilité de récupérer le streaming directement sur l’interface de commande et

savoir exactement ce que le ROBOT filme en temps réel, ci-dessous la description :


Nom Récupérer le streaming vidéo

Acteur Utilisateur

Description Permettre de recevoir le streaming vidéo en temps réel depuis le ROBOT.


connexion avec la partie commande établie

Post-Conditions N/A

Scénario nominal 1. Activer la caméra du ROBOT, et l’envoi du streaming

2. Activer la réception du streaming directement sur l’application de commande



Le système s’arrête

Faible bande passante :

Temps de latence plus grand Tableau 7 - Description du cas d'utilisation Récupérer le streaming vidéo


25


3. Le 3ème

Cas- Détecter un obstacle

Figure 17 - Cas d'utilisation – Détecter un obstacle

Ce diagramme représente la fonctionnalité de détecter un obstacle à proximité et calculer la

distance qui le sépare au ROBOT, on trouve une description de ce cas ci-dessous :


Nom Récupérer la distance

Acteur Utilisateur

Description Permettre à l’utilisateur d’afficher la distance qui sépare le robot à un obstacle.


Capteur bien fonctionnel

Post-Conditions N/A

Scénario nominal 1. Détecter l’obstacle

2. Mesurer la distance

3. Eviter l’obstacle à une distance déterminée



Pas de récupération de valeur Tableau 8 - Description du cas d'utilisation Récupérer la distance


26


4. Le 4ème

Cas- Détecter une fuite de gaz

Figure 18 - Cas d'utilisation - Détecter une fuite de gaz

Ce diagramme représente la fonctionnalité de calculer le niveau de Gaz dans l’air autours du

ROBOT et détecter s’il y a une fuite ou non, ci-dessous une description détaillée :


Nom Récupérer le niveau de gaz

Acteur Utilisateur

Description Permettre à l’utilisateur d’afficher le niveau de gaz autour détecté par le ROBOT.


Capteur bien fonctionnel

Post-Conditions N/A

Scénario nominal 1. Détecter le niveau de Gaz

2. Envoyer le niveau de gaz à l’application de commande

3. Lancer une Alerte en cas d’urgence



Pas de récupération de valeur Tableau 9 - Description du cas d'utilisation récupérer le niveau de gaz


27


5. Le 5ème

Cas- Récupérer l’état du ROBOT

Figure 19 - Cas d'utilisation - Récupérer l’état du ROBOT

Ce diagramme présente la fonctionnalité de récupérer un ensemble d’informations et

d’indicateurs qui nous donne plus de détail sur l’état du ROBOT lorsqu’il est actif, ci-dessous

une description détaillé de ce cas:


Nom Récupérer l’état du ROBOT

Acteur Utilisateur

Description Récupérer un ensemble d’information qui représente les caractéristiques actuelles du ROBOT comme le niveau du signal, le niveau de batterie etc.


Détection de gaz activée

Post-Conditions N/A

Scénario nominal 1. Récupérer automatiquement toutes les informations sur l’interface utilisateur.


Exception Pas de service GPS/internet disponible:

Pas d’envoi d’information Tableau 10 - Description du cas d'utilisation récupérer l'état du ROBOT


28


V. Diagramme de séquence système Pour avoir une vue séquentielle globale sur les principales fonctionnalités de notre système, on présente de diagramme de séquence système dans la figure 15 :

Figure 20 - Diagramme de séquence système

Ce diagramme montre l’interaction de façon séquentielle entre l’acteur et le système.

Une première connexion doit être établie, une fois la connexion est effectuée, l’utilisateur

peut sélectionner une action à faire, lorsqu’il aura l’interface principale.

La fonctionnalité explorer un lieu consiste à faire déplacer le ROBOT dans les directions

voulues librement que ce soit en avant, arrière ou en tournant à gauche et droite, les

commandes seront envoyées à l’objet Daemon qui va exécuter ces taches directement sur le

ROBOT.

La fonctionnalité de surveiller une zone se base essentiellement sur le fait que l’utilisateur

peut recevoir le streaming vidéo directement sur l’application de commande.

Récupérer la distance à l’obstacle et le niveau de Gaz constituent aussi des fonctionnalités

prêtes à utilisés via des interfaces utilisateurs ou celui-ci peut recevoir la distance au

obstacle ainsi que le niveau de gaz en air, une action sera effectuée si le niveau de gaz ou la

distance atteint un niveau prédéfini.


29


VI. Diagrammes de Séquence détaillés Dans cette partie nous présentons une étude dynamique du projet en se basant sur les

diagrammes de séquence détaillés

1. Diagramme de séquence 1– Déplacer le ROBOT

Figure 21 - Diagramme de séquence – Déplacer le ROBOT

Ce diagramme de séquence représente les différentes étapes établies afin de mettre le

ROBOT en mouvement, le système sera divisé en modules actives comme suit :

Application 1 : elle représente l’application de commande qui représente l’interface

utilisateur d’une part et le lien sans fil avec le ROBOT d’autre part.

Application 2 : elle représente l’application résidente qui contrôlera le ROBOT

réellement elle fait le lien entre l’application de commande et la carte IOIO

Carte IOIO : elle représente l’interface entre l’application Android 2 et tous les

composants électroniques, dans ce cas les moteurs DC et les circuits associés qui

seront détaillés dans le chapitre réalisation

Moteurs DC : représentent les composants électroniques qui seront

activés/désactivés via la carte IOIO

L’utilisateur doit entrer l’adresse IP du ROBOT pour pouvoir se connecter, l’application 1

tente d’établir la connexion avec l’application 2, une fois la connexion est établie, il y aura

l’activation de la carte IOIO, et l’interface de commande principale sera affichée à

l’utilisateur.


30


L’utilisateur sera capable de commander le ROBOT à l’aide d’un Joystick, le faite de bouger le

Joystick va générer un ensemble de commandes suivant le sens, qui seront envoyées à

l’application 2 qui reçoit ces commandes, les traites, puis les transformer en commandes

compréhensibles par la Carte IOIO, une fois les données sont envoyés à cette carte, elle se

charge de générer des signaux de commandes vers les différents moteurs.

Lorsque l’utilisateur relâche le Joystick, l’application 1 envoi une commande spéciale d’arrêt

à l’application 2 qui envoi de même une commande à la carte IOIO pour arrêter

immédiatement les moteurs.

2. Diagramme de séquence 2– Surveiller un lieu

Figure 22 - Diagramme de séquence – Surveiller un lieu

Ce diagramme de séquence représente les différentes étapes et possibilités pour assurer la

fonctionnalité de surveiller un lieu, le système sera divisé en modules actives de la même

façon comme dans le diagramme précédent.

La partie connexion est nécessaire pour pouvoir établir la suite des actions.

L’utilisateur sera capable d’activer la caméra du Smartphone situé dans le ROBOT, suite à

cette action l’application 2 se charge de lancer la caméra et d’envoyé le streaming en retour


31


à l’application 1 dans laquelle l’utilisateur peut visualiser ce flux directement dans l’interface

de commande.

L’utilisateur peut aussi orienter la caméra suivant deux axes, Pan(gauche/droite) et

Tilt(haut/bas), ces deux fonctions seront bien accessible à tout moment via l’interface de

commande à l’aide de deux composants sous forme de ‘SeekBar’ qui seront détaillés dans le

chapitre réalisation, la manipulation de ses deux composants génèrent des commandes qui

seront envoyés à l’application 2 qui à son tour traite ces commandes et l’état actuel de la

caméra et décide ou non et avec quel angle de changer l’orientation de la caméra.

Le changement de l’orientation de la caméra peut s’effectué aussi bien dans le cas où le

ROBOT est en arrêt que lorsqu’il est en mouvement.

Comme option l’utilisateur peut prendre des snapshots directement via la caméra du

ROBOT, et ces photos seront sauvegardées dans un emplacement spécifique dans le

Smartphone 2.

3. Diagramme de séquence 3– Détecter un Obstacle

Figure 23 - Diagramme de séquence – Détecter un Obstacle

Ce diagramme de séquence montre le déroulement de la détection d’obstacle assurée par le

ROBOT, le système sera divisé en modules actives de la même façon comme dans le

diagramme précédent.


32



L’utilisateur aura la possibilité d’afficher la distance qui sépare le ROBOT au premier obstacle

sur son chemin, une commande sera envoyé à l’application 2 qui se chargera d’activer le

capteur de proximité utilisé via la carte IOIO, le capteur donc va être en fonction il va

envoyer les informations sur la distance calculée à la carte IOIO qui va à son tour traiter et

envoyer ces informations à l’application 2.

Au niveau de l’application 2, elle va envoyer ces informations à l’application 1 qui va

visualiser des valeurs compréhensibles pour l’utilisateur, selon les valeurs reçues par

l’application 2 un certain traitement va s’effectuer pour décider si elle va réagir ou non, dans

le cas où ces valeurs sont dans une certaine portée qui sera détaillée dans le chapitre

réalisation, elle va ordonner à la carte IOIO pour exécuter une ou un ensemble d’action pour

éviter un choc avec l’obstacle, les moteurs vont changer la direction vers la droite ou gauche.

Le type de capteur de proximité et son fonctionnement vont être détaillés dans le chapitre

réalisation.

4. Diag.de séquence 4 – Détecter une fuite de Gaz

Figure 24 - Diagramme de séquence – Détecter une fuite de Gaz

Ce diagramme de séquence montre le déroulement de la détection d’une fuite de gaz

assurée par le ROBOT, le système sera divisé en modules actives de la même façon comme

dans le diagramme précédent.


33



L’utilisateur aura la possibilité d’afficher le niveau de gaz dans l’air dans la pièce où se situe

le ROBOT, une commande sera envoyé à l’application 2 qui se chargera d’activer le détecteur

de gaz via la carte IOIO, le détecteur donc va être en fonction il va envoyer les informations

sur la concentration du gaz calculée dans l’air à la carte IOIO qui va à son tour traiter et

envoyer ces informations à l’application 2.

Au niveau de l’application 2, elle va envoyer ces informations à l’application 1 qui va

visualiser des valeurs compréhensibles pour l’utilisateur, selon les valeurs reçues par

l’application 2 un certain traitement va s’effectuer pour décider si elle va réagir ou non, dans

le cas où ces valeurs sont au-delà de la valeur normale et présentent un danger, elle va

ordonner à la carte IOIO pour exécuter une Alerte qui sera envoyé directement à

l’utilisateur. Le type de gaz et le fonctionnement du détecteur vont être détaillés dans le

chapitre réalisation.

VII. Maquettes

1. Maquette du ROBOT

Figure 25 - Maquette du ROBOT

Suivant notre besoin essentiel et notre vision sur le produit à réaliser, nous dessinons

grossièrement une maquette du futur ROBOT. Pour ce faire nous modélisons deux vues pour

aboutir à la figure 16.

Ces deux vues présentent la squelette générale du ROBOT, composée d’une tête qui va


34


contenir essentiellement un Smartphone Android équipé d’une caméra, une connectivité

Wifi, un accéléromètre, un dispositif GPS, et qui constitue le cerveau du ROBOT et la partie

intelligente contenant la deuxième application qui assure la réception des commandes

issues de l’application de commande, et assure aussi l’interfaçage avec tous ce qui est

électronique pour exécuter ces commandes convenablement, l’application est responsable

de la capture vidéo à partir de la caméra, la capture des différentes signaux à partir des

différents composants du ROBOT, le traitement de ces informations et l’exécution des

actions appropriés.

La tête du ROBOT est liée au corps via un mécanisme mobile qui permettra un certain degré

de rotation et d’inclinaison qu’on détaillera dans le chapitre Réalisation.

Le corps du ROBOT est composé d’une plateforme de déplacement composée essentiellement de 4 roues avec deux chaines, une partie électronique qui va contenir la carte IOIO, les capteurs, l’alimentation et les autres circuits nécessaires.

2. Maquette de l’application de commande

Figure 26 - Maquette de l’interface principale de l’application de commande

L’application de commande se présente sous la forme d’une interface principale, avec des widgets, boutons et autres contrôles découpée en cinq zones organisées comme suit : En haut un menu qui contient 4 Tabs représentants un Tab pour le niveau de batterie, un

Tab pour la distance au premier obstacle, un Tab qui affiche le niveau de gaz et un autre

Tab pour afficher les coordonnées d’orientation du ROBOT dans l’espace.


35


À gauche deux bulles qui permettent à l’utilisateur de savoir le niveau du signal et le

niveau de la luminosité si elle est disponible, un Pad/Joystick principal de commande qui

va permettre de déplacer le ROBOT.

Au milieu une grande interface qui représente un afficheur du streaming Vidéo reçu à

partir du ROBOT.

À droite, deux éléments qui affichent les alertes qui correspondent à la faiblesse du

signal Wifi ou à une erreur de connexion avec le ROBOT, un Widget qui donne une

indication sur la vitesse du ROBOT.

En bas, un ensemble de commande pour activer/désactiver le Streaming vidéo, le

déplacement de la caméra, le flux audio

Pour donner un aspect familier à notre application de commande nous avons choisi

d’adopter le « look and fée» d’une sorte d’interface de jeu ou d’un tableau de bord ou

panneau de commande unique qui va contenir la quasi-totalité des fonctionnalités.

Conclusion La spécification des besoins nous a permis d’avoir une vision plus claire du sujet et une

compréhension plus profonde des tâches à réaliser. Elle mène également à prévoir les

problèmes à rencontrer et chercher les solutions permettant de les contourner.

Nous avons essayé tout au long de ce chapitre de bien présenter les besoins fonctionnels et

non fonctionnels du sujet et les différents scenarios d’utilisation de l’application. Ces

scenarios vont être la base sur laquelle nous allons concevoir et réaliser notre projet, ces

deux phases seront détaillées dans les deux chapitres qui suivent.


36

Conception

4. CONCEPTION

Introduction

Nous consacrons ce chapitre à la présentation de l’architecture et de la conception de notre

projet. Nous commençons par décrire l’architecture de notre application principale à travers

les différentes vues dynamiques à travers le diagramme de séquence objets, ainsi qu’un

diagramme d’activités global et un diagramme de de classe qui va jeter un coup d’œil sur les

différentes entités du projet. Ensuite, nous décrivons la conception de la structure technique

du ROBOT, par plusieurs schémas explicatifs, représentant les différents composants

matériels qui seront choisis et bien détaillés dans le chapitre suivant.

I. Diagramme de séquence objets Pour avoir une vue séquentielle globale sur les principales fonctionnalités de notre système, on présente de diagramme de séquence système dans la figure 27 :

Figure 27 - Diagramme de séquence objets


37

Conception

Ce diagramme montre l’interaction de façon séquentielle entre les 6 Objets principaux du

scénario et l’acteur, ces objets représentent les classes principales de l’application de

commande et les classes principales de l’application Daemon coté ROBOT.

Une première connexion doit être établie entre les deux applications, pour que l’utilisateur

puisse sélectionner une action à faire via l’interface qui sera affichée.

II. Diagramme d’activités Dans cette partie nous présentons le diagramme d’activité lié à tout le système

Figure 28 - Diagramme d'activités

Selon ce diagramme on remarque que notre système est multitâche, il offre un ensemble de

possibilités qui sont tous accessible via une seule interface principale de commande, qui est

le moyen de communication entre l’utilisateur et le ROBOT.

L’interface de commande est toujours en action que ce soit lors de réception des données

ou lors d’envoi des commandes ou même lorsque elle est en écoute car à tout moment elle

assure la connectivité au ROBOT et reste prête à n’importe quel action ou notification

L’utilisateur sera capable de commander le ROBOT à l’aide d’un Joystick, le faite de bouger le

Joystick va générer un ensemble de commandes suivant le sens, qui seront envoyées à

l’application 2.


38

Conception

III. Diagramme de Classe On présente ici le diagramme de classe du système développé :

Figure 29 - Diagramme de Classe

Le diagramme de classes est un schéma statique. Il représente le point de vue statique d'une

application, il est non seulement utilisée pour visualiser, décrire et documenter les différents

aspects d'un système, mais aussi pour la construction de code exécutable de l'application

logicielle. Il décrit les attributs et les opérations d'une classe et aussi les contraintes

imposées au système.

Le diagramme de classe de notre projet montre deux grandes parties qui représentent

chacune une application séparée.

La première application nommée application de commande est celle qui va être disponible

pour l’utilisateur pour commander et gérer le ROBOT, une de ses classes importantes est la

classe Client_Thread qui va se charger d’établir et de maintenir la connectivité avec sa

correspondante dans la deuxième application Server_Thread.

La deuxième application nommée Application Daemon pour dire qu’elle est résidente dans

le ROBOT et elle fonctionne sans intervention humaine directe, elle fonctionne en


39

Conception

permanence dès que le ROBOT est mis sous tension. Elle se compose d’un nombre plus

grand de classes parmi lesquelles on cite la classe IOIO_Thread_Connection qui se charge de

la communication avec la carte IOIO en utilisant la bibliothèque IOIO Lib.

Conclusion La conception détaillée nous a permis d’avoir une vision plus précise sur le sujet et une

compréhension plus profonde des tâches à réaliser. Elle mène également à prévoir les

besoins matérielles et logicielles nécessaires pour atteindre l’objectif.

Nous avons essayé tout au long de ce chapitre de bien présenter les différents diagrammes

conceptuels du projet. Ces diagrammes vont être la base sur laquelle nous allons réaliser

notre projet, cette phase sera détaillée dans le chapitre suivant.


40

Réalisation

5. REALISATION

Introduction Ce chapitre constitue le dernier volet du rapport de notre projet de fin d'études. Il a pour

objectif d'exposer le travail achevé. Pour ce faire, nous avons divisons la réalisation en deux

grandes parties, la réalisation logicielle qui va contenir tous le travail effectué au niveau de

développement des deux applications, la deuxième partie est la réalisation matérielle qui va

décrire les différentes phases de construction du ROBOT. Enfin, nous clôturons ce chapitre

par la présentation du chronogramme des taches réalisées et des défis relevés.

I. Réalisation Logicielle Dans cette partie nous allons présenter l’environnement du travail, les différentes phases de

développement des applications, et le résultat obtenu.

1. Environnement de travail Chaque développeur doit choisir un environnement de développement constitué

généralement par un IDE, et quelques autres outils et logicielles.

1. Eclipse

Eclipse est un environnement multi-langage de développement comprenant un

environnement de développement intégré (IDE) et un plug-in extensible système. Il est écrit

principalement en Java et peut être utilisé pour développer des applications en Java et, par

le biais de divers plug-ins, autres langages de programmation, y compris Ada, C, C + +,

COBOL, Perl, PHP, Python, Ruby.

2. SDK Android

Android SDK est indispensable pour développer sous

Android, c’est un kit de développement crée pour être

intégré dans un IDE, il offre un ensemble d’outils nécessaire

pour le développement et le test comme le ADT, le

compilateur, l’émulateur, le DDSM …

1. IOIO Lib

IOIO Lib est une bibliothèque Android spéciale crée par le constructeur de la carte IOIO, qui

permet à l’application Android de contrôler la carte IOIO. Elle expose un ensemble

d'interfaces Java, couvrant les différentes fonctions de la carte. Elle offre un ensemble de

Figure 30 - Logo Eclipse


41

Réalisation

classes et méthodes qui servent à communiquer avec les différents pins de la carte, d’autres

méthodes servent à changer la fréquence ou la pulsation d’un tel pin. Lorsqu’on génère

l’application, IOIOLib s’intègre dans la cible .apk, afin que l’application soit autonome et ne

nécessite aucune installation supplémentaire sur le Smartphone Android qui l'exécute.

2. Fritzing1

Fritzing est un logiciel libre d'édition de circuit électronique ou circuit

imprimé. Il est possible de compléter sa bibliothèque de composants.

Chaque composant est défini à l'aide de 3 éléments : l'image du composant,

qui peut être réalisée à partir d'une image, le symbole du composant et la

représentation du composant sur le circuit imprimé (nombre et position

des pistes).

Tout en étant un logiciel d'apparence simpliste, il possède malgré tous des fonctions

d'exportation vers Eagle et Gerber, ainsi que les typon au format PDF et SVG. On va l’utiliser

pour schématiser les différents montages du projet, ainsi que le montage complet de tout le

ROBOT.

3. Photoshop CS5

Photoshop est un logiciel de retouche, de traitement et de dessin assisté par

ordinateur édité par Adobe. Il est principalement utilisé pour le traitement

de photographies numériques, mais sert également à la création d’images et

de design. On l’utilise énormément dans notre application de

commande, pour créer presque tous les éléments graphiques allant du

Joystick, les Tab personnalisés, les éléments flottant jusqu’au design général de l’interface et

des bordures ainsi les autres besoins comme le SplashScreen et l’icône.

4. EGit (plugin) 2

Git est un logiciel de gestion de versions décentralisé. C'est un logiciel libre créé par Linus Torvalds, et distribué selon les termes de la licence publique générale GNU version 2. EGit est une interface écrite en Java, puis une extension git pour Eclipse, elle permet toutes les opérations de SVN.

5. Dropbox 3

Dropbox est un service, sécurisé, de stockage et de partage

de fichiers dans le Cloud.

2. Développement

On va diviser cette section en deux parties chacune corresponde à une application, on va

1 http://fritzing.org/

2 http://www.eclipse.org/egit/

3 http://www.dropbox.com/

Figure 34 - Dropbox logo

Figure 31 - Logo Fritzing

Figure 32 - Logo Photoshop

Figure 33 - Logo GIT

http://fr.wikipedia.org/wiki/Eagle_(logiciel)

http://fr.wikipedia.org/wiki/Gerber_(format_de_fichier)

http://fr.wikipedia.org/wiki/Typon

http://fr.wikipedia.org/wiki/Portable_Document_Format

http://fr.wikipedia.org/wiki/SVG


42

Réalisation

détailler les phases de développement de chacune élément par élément étape par étape.

1. Application de commande

Cette Application représente l’interface de commande principale pour l’utilisateur, à travers

elle il peut contrôler et gérer le ROBOT.

Phase 1 – Interface de connexion

Cette interface représente le moyen avec lequel

l’utilisateur peut insérer l’IP du ROBOT ainsi qu’un mot de

passe en cas ou le ROBOT est sécurisé, une fois les

paramètres sont insérer un clic sur le bouton OK va créer

une socket réseaux de type TCP qui va tenter de trouver

cette IP, une fois l’IP est trouvée et les trames sont

envoyées l’autre application va traiter le mot de passe s’il

est validé elle va ouvrir un canal de communication sur le

port 81, et elle va répondre par un message de confirmation, ce message va permettre

d’afficher l’interface de commande à l’utilisateur et le laisser contrôler le ROBOT. Dans

l’autre cas la fenêtre de connexion s’affiche une autre fois pour signaler que les paramètres

sont incorrects.

Phase 2 – Système de déplacement

Cette fonctionnalité de base est assurée à l’aide d’un Joystick

conçu spécialement pour cette tâche, il est composé d’un élément

mobile qui sera sensible à la touche, cet élément peut varié dans

un rayon limité par rapport au centre fixe, le centre de cet

élément est repéré par un point, chaque point est caractérisé par

un x et un y, ils représentent deux coordonnées par rapport au

centre, selon leurs valeurs, une variable qui s’appelle commande

initialisé à STOP va contenir une certaine chaine de caractères de

cette liste : NORD, NORD-EST, EST, SUD-EST, SUD, SUD-OUEST, OUEST, NORD-OUEST et

STOP.

Une fois la variable change de valeur elle sera immédiatement envoyée via un canal UDP à

l’application au côté ROBOT.

Phase 3 – Streaming de la caméra

Dans l’interface principale au milieu on trouve une

grande zone dédiée pour l’affichage du flux vidéo issu

de la caméra du ROBOT, le principe est plutôt

compliqué, l’application situé au niveau du ROBOT

lance la caméra en mode visualisation et pas

enregistrement, une fois la caméra est en fonction,

l’application fais une capture successive d’images et

Figure 35 - Interface de connexion

Figure 36 - Joystick de déplacement

Figure 37 - Zone d'affichage du streaming


43

Réalisation

enregistre cet ensemble d’images dans un "buffer" comme le cas d’une vidéo classique, pour

envoyer tous ces images d’une manière fluide et pour ne pas encombré le canal déjà établie

entre les deux partie, on a trouvé une solution qui se résume dans la création d’un petit

serveur Web au niveau de l’application Daemon, ce serveur va fonctionner sur le port 80

pour ne pas augmenter le débit sur l’autre port déjà ouvert, il assure la disponibilité d’une

page contenant une image pris chaque 0.2 sec à partir du buffer, et de l’autre part

l’application de commande va récupérer cette image du serveur et rafraichir la zone

d’affichage avec une fréquence supérieure à la fréquence d’envoi, avec cette méthode en

gagne en bande passante , aussi on gagne au niveau de la rapidité d’exécution des

commandes sans avoir penser à la taille du flux reçu.

Phase 4 – Mécanisme d’orientation de la caméra

Cette fonctionnalité permet de tourner la caméra (Smartphone)

à gauche ou à droite, l’incliner en haut ou en bas, l’application

de commande comporte 2 SeekBars, une horizontale située en

bas de la zone de streaming, et une verticale située à droite de

la même zone, elles sont directement opérationnelles par

l’utilisateur qui peut déplacer sont doit directement pour

tourner la caméra dans la direction voulue, une fois la valeur de

l’un des SeekBars change, une commande sera directement envoyée au ROBOT en indiquant

la valeur de changement selon cette valeur le résultat sera un mouvement angulaire de la

caméra.

Phase 5 – Niveau de Gaz

Pour avoir le niveau de gaz actuel, nous avons développé cette

interface qui reçoit d’une façon continue les valeurs depuis le

capteur de gaz situé dans le ROBOT et à travers l’application

Daemon et la carte IOIO, les valeurs sont comprises entre 0 et 700

ppi, un indicateur du niveau dangereux indique si la valeur actuelle

est acceptable ou non.

Phase 6 – Distance à l’obstacle

Pour avoir la distance qui sépare le ROBOT au premier obstacle,

nous avons développé cette interface qui reçoit d’une façon

continue les valeurs depuis le détecteur de proximité situé dans

le ROBOT et à travers l’application Daemon et la carte IOIO, la

distance est affichée en centimètre.

Phase 7 – Pourcentage de la batterie

Cette fonctionnalité est réalisée à travers un circuit qui va

calculer le pourcentage de la batterie restant ainsi que la valeur

de la batterie du Smartphone situé dans le ROBOT, et ces valeurs

sont reçues et affichées dans l’application de commande, on

trouve aussi une estimation sur la durée restante.

Figure 39 - Interface de détection de Gaz

Figure 40 - Interface de détection de distance

Figure 41 - Interface d'affichage d'état de Batterie

Figure 38 - SeekBars


44

Réalisation

Phase 8 – Notifications de connexion

Une fois on récupère l’état du signal wifi du ROBOT, on peut juger est ce

que ce signal est bien acceptable pour maintenir la connexion ou non, dans

le cas où ce signal devient faible une notification d’alerte s’affiche en

indiquant un Warning, dans le cas où l’application détecte que la connexion

wifi avec le ROBOT est coupée, une nouvelle alerte s’affiche indiquant une

erreur, ces fonctions sont réalisées à travers des Thread qui tourne en

Background d’une façon continue.

Phase 9 – Orientation

L’orientation du ROBOT est effectuée en recevant les 3 indicateurs de

l’accéléromètre du Smartphone du ROBOT, un certain calcul se fait et on aura

exactement ces valeurs, on peut juger sur la stabilité du ROBOT, ou

l’inclinaison du terrain à travers ces indicateurs.

Phase 10 – Caméra Move / ROBOT Speak

Caméra Move est une fonctionnalité optionnelle qui permet une deuxième méthode pour

orienter la caméra du ROBOT directement à travers les indicateurs accéléromètre du

Smartphone de commande, elle est encore en phase bêta mais elle peut servir pour les tests.

ROBOT Speak est une fonctionnalité optionnelle, elle est une sorte de Talkie-Walkie entre le

Smartphone de l’utilisateur et le ROBOT, une fois activée l’utilisateur peut parler

directement au Smartphone, ce dernier à l’aide du microphone va récupérer la parole et

l’application va envoyer ce flux audio vers l’autre application, un Haut-parleur au niveau du

ROBOT servira pour diffuser le son.

Phase finale – Application Complète

Ci-dessous les interfaces finales de l’application de commande :

Figure 42 - Notification de connexion

Figure 43 - Tab d'orientation

Figure 44 - écran 1 - Interface de connexion


45

Réalisation

Figure 45 - écran 2 - Interface de commande

2. Application Daemon (démon)

Cette Application représente la partie intelligente du ROBOT, elle offre tout un système

autonome de contrôle, basée généralement sur des activités héritées de Thread, et d’autres

hérités de Runnable, ce qui l’application prête à n’importe que action que ce soit provenant

de la partie commande via des trame TCP ou UDP ou de la part des composants

électroniques via la carte IOIO, nous détaillons ci-dessous les différentes phases de

réalisation de cette application.

Phase 1 –connexion

C’est la deuxième partie de la même fonctionnalité de l’application 1, dès la mise sous

tension du ROBOT l’application affiche son adresse IP, et ouvre un canal réseau d’écoute

pour attendre l’autre application. Une fois la requête de demande de connexion arrive,

l’application vérifie le mot de passe, et répond par une requête de confirmation, et ouvre un

nouveau canal de communication dédié à la réception des commandes sur le Port spécifique

81, toutes les commandes reçues sont envoyées à une unité qui valide, traite et achemine

les actions.

Phase 2 – Streaming vidéo

Nous avons déjà expliqué cette partie dans la première application, il reste à indiquer que

cette application détecte les qualités disponible des images prises par la caméra, et affecte

une qualité minimale mais pas inférieur à 320x480, pour que le traitement et le transfert

sera un peu rapide et on aura un minimum de temps de latence sans avoir une différence

niveau qualité d’affichage.

Pour le serveur Web attribué dans l’application, il ouvre un canal de communication

accessible depuis n’importe quel adresse du réseau, donc si on possède l’adresse IP du

ROBOT, on peut suivre le streaming tout comme la personne qui commande le ROBOT.


46

Réalisation

Les images successives sauvegardées dans un Buffer auront une taille maximale de 1024 Ko

soit à peu près 10 images compressées de type JPEG, une fois le Buffer est plein il y aura

automatiquement un écrasement de l’image la plus ancienne et ainsi de suite.

Phase 3 – Déplacement du ROBOT

Une fois l’utilisateur déplace le joystick dans une direction, l’application daemon reçoit une

commande spécifique, cette commande est traitée pour distinguer est ce que il s’agit d’un

mouvement vers l’avant (NORD) ou vers la droite (EST) ou autre … une fois la commande est

identifiée, une suite d’action seront attribuées à chacun des 4 moteurs, suivant ce tableau :

Moteur 1 (avant -droit)

Moteur 2 (avant -gauche)

Moteur 3 (arrière -droit)

Moteur 4 (arrière - gauche)

NORD Sens direct Sens direct Sens direct Sens direct

NORD-EST STOP Sens direct STOP Sens direct

EST Sens Inverse Sens direct Sens Inverse Sens direct

SUD-EST STOP Sens Inverse STOP Sens Inverse

SUD Sens Inverse Sens Inverse Sens Inverse Sens Inverse

SUD-OUEST Sens Inverse STOP Sens Inverse STOP

OUEST Sens Inverse Sens direct Sens Inverse Sens direct

NORD-OUEST Sens direct STOP Sens direct STOP Tableau 11 – Commande des Moteurs

Pour ce faire l’application passe ces nouvelles commandes à une unité qui va les transformer

en des ordres compréhensibles par la carte IOIO, du genre : activer tel Pin avec tel courant

etc...

RQ : suivant le tableau résultant et suivant des tests effectués, on peut utiliser juste deux

moteurs pour déplacer le ROBOT, le M1 et le M2, on aura le même résultat mais une petite

baisse de vitesse, par contre on gagne dans la consommation d’énergie, ça reste un choix

pour le client final d’utiliser tant de moteurs qu’il en a besoin.

Phase 4 –Orientation de la caméra

Ce mécanisme est assuré par deux Servos Moteurs avec un bras constitué de deux ‘Braquets’

(supports métalliques), un pour assurer le PAN (panorama) et l’autre le TILT(inclinaison), une

fois que l’application reçoit la commande elle traite la valeur, et la change en fréquence

qu’elle l’envoi à la carte IOIO pour pouvoir commander le Servo Moteur voulu avec la valeur

adéquate.

Le premier Servo Moteur possède un angle d’action égale à 200° ce qui nous permet

d’effectué une orientation de gauche à droite facilement, même on peut tourner avec un

angle de 20° vers l’arrière.

Le 2ème Servo Moteur possède un angle d’action plus limité de 120°, vu qu’il y aura des

contraintes mécaniques dans son mouvement, il nous permet de s’orienter vers le Haut, vers

l’avant (position par défaut) et une petite inclinaison vers le bas de 20°.

Phase 5 – Détection de gaz

La détection du Gaz s’effectue à l’aide d’un module qu’on a développé spécialement pour ça,

il s’occupe de l’écoute active du Pin de la carte IOIO attaché au détecteur de Gaz, aussi il se


47

Réalisation

charge de gérer la stabilité du capteur lors du démarrage, une fois le capteur détecte un

niveau de gaz supérieur à la normale, il génère un signal électrique analogique, qu’il se passe

par la carte IOIO, et selon sa puissance l’application traite cette information et donne

directement les bonnes valeurs à la partie d’envoi qui se charge d’envoyer ces valeurs à

l’application de commande où il seront directement visible dans la zone dédiée pour ça.

Phase 6 – Détection d’obstacles

La détection d’un obstacle s’effectue aussi à l’aide d’un module développé spécialement

pour ça, il fait de l’écoute active du Pin de la carte IOIO attaché au capteur de proximité, le

capteur choisit est un capteur Ultra-son il envoi et reçoit un signal ultrasonique chaque

période (de l’ordre de 20 ms), selon la rapidité de la réception il estime avec une précision

de 1 cm la distance qu’il le sépare à l’obstacle, il génère un signal électrique analogique, qu’il

l’envoi à la carte IOIO, l’application traite cette information et donne directement des

valeurs compréhensibles à la partie d’envoi qui se charge d’envoyer ces valeurs à

l’application de commande où il seront directement visible dans la zone dédiée pour ça.

Une fois la distance détectée est inférieure à une valeur prédéfinie (10 cm), le ROBOT

s’arrête et change de direction vers la droite/gauche, ce mécanisme intelligent permet

d’éviter les obstacles proches. On peut bien entendu exécuter n’importe quel action de type

lancer une alarme ou suivre un certain trajet etc…

Phase 7 – Récupération d’état de Batterie

Pour récupérer l’état de la batterie du ROBOT, on a recourt à un circuit spécial qui détecte le

pourcentage restant vis-à-vis la capacité totale, cette valeur est envoyé à la carte IOIO est

sera lu à partir de l’application Daemon chaque intervalle de temps (5 min) on ajoute à cette

valeur la valeur de la batterie du Smartphone, puis on envoie les deux à l’application de

commande qui se charge de les afficher et d’estimer la durée restante.

Phase 8 – Orientation du ROBOT

On récupère les valeurs données par l’accéléromètre et la boussole (si elle est disponible)

puis l’application traite ces informations avant de les envoyées à l’application de commande

Phase 9 – Envoi d’alertes

Dans le cas où on détecte un niveau de gaz élevé, l’application se charge de lancer une

nouveau module, ce dernier il effectue une procédure pour lancer une alerte, il envoie un

SMS spécial/Mail qui contient un message prédéfini alertant l’utilisateur qu’il y a une fuite

de gaz, et il le propose d’appeler l’un des numéros d’urgence, une alerte SONORE sera aussi

déclenchée.

Phase finale – Application Complète

Après assemblage de tous ces fonctions nous aurons une application complète prête à

opérer, cette application ne nécessite pas une interface conviviale avec des beau design vu

qu’elle interagit avec un ROBOT est une autre application à distance, mais au minimum elle

doit être compréhensible.


48

Réalisation

Figure 46 - Interface de l'application Daemon

II. Réalisation Matérielle La réalisation matérielle du ROBOT comporte plusieurs phases, on va commencer par

présenter un peu l’environnement, le matériel requis et les outils utilisés, puis on détaille

tous les phases de construction jusqu’au aboutir à un résultat final.

1. Environnement de travail Pour construire un ROBOT on doit avoir un ensemble d’outils et on aura besoin d’un endroit

adéquat pour le faire, pour ce faire on liste ci-dessous ces différents nécessités.

Atelier : nous avons utilisé pendant les premières phases le laboratoire

d’électromécanique d’ESPRIT, où on a trouvé les équipements et les outils pour

pouvoir commencer nos tests, après on a décidé de changer la stratégie et d’avoir

nos propres outils et équipements et migrer vers le Labo ESPRIT-Mobile.

Outils & équipements : puisque notre ROBOT se compose d’une partie électronique

donc on aura besoin des outils de base pour l’assemblage, soudure, la connexion

filaire, les différentes tests électriques, voici une liste complète : Fer à souder,

multimètre, Transformateur de courant, un cutter, des piles, des connecteurs (pin

strip), des fils conducteurs, maquette de test, des diodes de test, des résistances,

toile isolante, …

2. Composants matériels Notre ROBOT a besoin d’un ensemble de composants pour pouvoir voir le jour, on liste ici

tous les composants principaux pour construire le ROBOT, leurs spécification technique:


49

Réalisation

Un Smartphone Android (Huawei GAGA)

La première chose indispensable à avoir pour construire ce ROBOT, est un Smartphone,

sur lequel il y aura l’OS Android qui sera notre milieu d’exploitation et de développement

de l’application qui va gérer tout le ROBOT, aussi on va exploiter tous les autres

composants du Smartphone comme suit :

o La carte WIFI jouera le rôle de connectivité sans fil du ROBOT

o La connectique Bluetooth, sera un autre moyen exploitable pour se connecter

au ROBOT

o La carte d’acquisition GSM + puce : nous les exploitant en envoyant les SMS

d’alerte à n’importe que numéro, on peut aussi avoir la possibilité d’appeler

ou d’envoyer des commandes SMS pour commander le ROBOT

o La carte 3G : on peut connecter le ROBOT à Internet directement, on doit ainsi

penser au temps de latence, et la bande passante

o L’écran : il servira d’interface pour afficher des notifications visuelles, ou autre

informations

o Microphone : Le ROBOT sera capable d’écouter son entourage, enregistrer est

diffuser, on peut avoir un ROBOT détecteur de son, ou même un ROBOT qui

réagit à des commandes vocales.

o Haut-parleur : il servira comme une sortie sonore du ROBOT, un tas de

possibilités existe

o L’accéléromètre : nous l’utilisant dans la récupération de l’orientation du

ROBOT dans l’espace

o La Boussole : servira à indiquer l’orientation selon le Nord du ROBOT

o GPS : est nécessaire pour avoir la localisation de notre ROBOT

o La carte SD/le stockage interne : servira énormément pour la sauvegarde des

données volumineuses comme les photos, vidéos, son et toute autre

information générée ou traitée par le ROBOT

Nous avons choisi d’utiliser le Huawei GAGA, il tourne sous Android 2.2, il comporte

toutes les spécifications requises pour le projet ainsi qu’il possède deux avantages

majeures, le poids et les dimensions sont les plus faibles, aussi le prix il est le moins cher

du marché (environ 199 DT soit 130 $) – [voir annexe pour les spécifications techniques

complètes]

Figure 47 - Huawei Gaga


50

Réalisation

Une carte IOIO

La carte IOIO est notre grand secret, elle est la relation entre l’OS Android (SOFT) et

l’électronique (HARD) (voir Chapitre 2.II)

Figure 48 - Carte IOIO

Moteurs + Roues (ROVER5)

Pour pouvoir se déplacer le ROBOT a besoin de 4 Moteurs + 4 Roues, après une recherche

dans les constructeurs robotique nous avons trouvé ce modèle qui s’appelle ROVER5 c’est

un châssis équipé de 4 moteur DC avec deux chaines en plastiques qui couvre les 4 bases

de Roues, il servira comme base du ROBOT

CARACTÉRISTIQUES

Tension nominale moteur: 7,2 V

Blocage du moteur actuel: 2.5A

Couple de sortie d'axe: 10Kg/cm

Rapport Boîte de vitesse: 86.8:1

Type de codeur: Quadrature

Résolution du codeur: 1000 changements d'état par 3 tours de roue

Vitesse: 1Km/h

Motor Driver (TB6612FNG)

C’est un petit circuit imprimé qui est nécessaire pour pouvoir commander les 4 Moteurs

DC simultanément et via la même source d’alimentation

Figure 49 - Plateforme de déplacement

Figure 50 - Motor Driver


51

Réalisation

CARACTERISTIQUES

Tension d'alimentation: VM = 15V max, VCC = 2.7-5.5V

Courant de sortie: Iout = 1,2 (en moyenne) / 3.2A (crête)

Le contrôle Standby pour économiser l'énergie

CW / CCW / court freinage / arrêt /modes de commande de moteur

Built-in circuit de coupure thermique et le circuit de détection de basse tension

Toutes les broches de la TB6612FNG espacées de 0,1 "

Condensateurs de filtrage sur les lignes d'approvisionnement

Capteur Ultrason(SEN10737P)

Comme capteur de proximité on a choisi d’utiliser le capteur ultrason SEN10737P, Ce

capteur Grove-ultrasons est un module sans contact de mesure de distance qui est

compatible avec le système Grove. Il est conçu pour une utilisation facile dans les projets

modulaire avec la performance industrielle.

CARACTERISTIQUES

Plage de détection: 3cm-4m, meilleur résultat en angle de 30 degrés.

Interface Grove

Précision : ~ 1 cm

Alimentation 5V DC

Capteur de Gaz(SEN90512P)

Le capteur de gaz choisi est le SEN90512P c’est un capteur de gaz (MQ2) ce module est

utile pour détecter les fuites de gaz (dans la maison et de l'industrie). Il peut détecter GPL,

l'i-butane, le méthane, l'alcool, l'hydrogène, la fumée et ainsi de suite. S'appuyant sur son

temps de réponse rapide. Les mesures peuvent être prises dès que possible. Également la

sensibilité peut être ajustée par le potentiomètre.

CARACTÉRISTIQUES

Haute sensibilité au GPL, le gaz naturel, gaz de ville

Faible sensibilité à l'alcool, la fumée.

Réponse rapide

Stable et durable

Circuit de pilotage simple

MQ-5: gaz de ville, l'hydrogène, 100 ppm à 3,000 ppm

Figure 51 - Détecteur Ultrason

Figure 52 - Capteur de gaz


52

Réalisation

Servos Moteur + accessoires

Pour pouvoir orienter la caméra et la faire tourner à gauche/droite et en haut/bas, nous

avons choisi d’utiliser un mécanisme qui se compose de deux Servos Moteurs et les

accessoires en relations comme les ‘Brackets’.

Un montage est requis pour avoir le résultat ci-dessous :

CARACTERISTIQUES

Nom de marque: EMax

Item: ES08A

Tension de fonctionnement: 4.2-6V

Vitesse de fonctionnement: 0.10sec/60degree (4.8v)

Couple de blocage: 1.8kg/cm

Plage de température: -55 ℃ 0 ℃

Dimension: 32 (notamment l'oreille cas servo)

x11.5x24mm

Poids: 9g

Kit comprend: Servos Horns x3 & Vis x3

Liste des éléments du Paquet 9g Servo Bracket:

Support x2

Yoke x1

Rivet plastique (3X5.5) x4

Rivet plastique (2X5.6) x8

Rondelle plastique x2

Visses x8

Batterie

Pour assurer une alimentation à tous les

composants du ROBOT, nous avons choisi

d’utiliser une alimentation centralisée par le biais

d’une seule batterie 12 V, 2.2 AH /20HR, avec un

prix de 27 $.

Figure 53 - Servo Moteur Figure 54 - Brackets

Figure 55 - Montage du bras de la caméra

Figure 56 - Batterie


53

Réalisation

3. Construction matérielle Dans cette partie nous allons présenter tous les schémas et montages électroniques

effectués afin d’avoir une vue détaillée et profonde sur chaque élément construit.

1. Smartphone et carte IOIO

Le Smartphone doit être connecté à la carte IOIO via le port USB comme le montre la figure

ci-dessus, l’alimentation de la carte IOIO est séparée donc on doit connecter les pins Vin et

GND à +VCC et GND de la batterie. Une fois connectée et alimentée la carte IOIO peut

communique avec le Smartphone à travers notre application. Le mode débogage doit être

activé dans le Smartphone.

2. Plateforme de déplacement

Figure 58 – Montage électronique de la plateforme de déplacement

Figure 57 – Montage Carte IOIO - Smartphone


54

Réalisation

La figure montre le montage de deux Moteurs DC avec le Motor Driver cité avant, le Motor

Driver doit être connecté à la carte IOIO du côté montré dans le schéma, les Pins attribués

doivent être les mêmes utilisés dans l’application. Chaque Motor Driver peut faire

fonctionner deux moteurs, donc on aura besoin de refaire ce montage en changeant bien

évidement les pins de 4-11, le Motor Driver est alimenté avec 3.3 V via la carte IOIO, et il

alimente les moteurs par 9v via la batterie.

Chaque Moteur possède deux pins pour le commander, faire circuler le courant dans un sens

ou un dans l’autre sens permet d’inverser le sens de rotation du Moteur.

3. Capteur de gaz

Figure 59 – Montage Carte IOIO et capteur de gaz

Le capteur de gaz comporte 3 pins, on connecte le pin Signal à la carte IOIO (fil bleu), par une

entrée analogique, par exemple le PIN 34, ce même nombre va être utilisé dans l’application

pour faire l’écoute du signal analogique généré lorsque il y aura une fuite de gaz. Les deux

autres fils sont pour l’alimentation et la masse, ce capteur ne nécessite pas plus de 5 V donc

on peut l’alimenter directement par le PIN 5v de la carte IOIO.

4. Capteur Ultrason

Figure 60 – Montage Carte IOIO et capteur ultrason

Le capteur Ultrasonique se connecte à la carte IOIO via une sortie analogique connecté ici au

PIN 6(fil jaune) jouant le rôle du SIGNAL, elle génère un signal analogique au fur et à mesure

qu’il détecte un obstacle, la deuxième sortie (fil orange) sert comme stabilisateur du


55

Réalisation

capteur, elle est toujours à 1, les deux autres fils sont pour l’alimentation el la masse, le

capteur ultrason a besoin de moins de 5 v donc il peut prendre sa tension de la carte IOIO.

5. Servos Moteurs

Figure 61 – Montage de la carte IOIO avec les servos moteurs

Le mécanisme d’orientation de la caméra nécessite deux servos moteurs, ils sont branchés

comme suit, la sortie en jaune représente le SIGNAL analogique (PWM) d’entrée qui va

commander le servos moteur pour le faire tourner d’un tel angle. Ils sont liés ici aux pins 3 et

6, les autres sorties sont pour l’alimentation (5v) et la masse.

4. Estimation du coût On présente ici une estimation du coût du ROBOT :

Produit Prix Smartphone Huawei Gaga 130 $ Carte IOIO 50 $ Rover5 55 $ Motor Driver 8.95 $ x 2 Capteur Ultrason 15 $ Capteur de Gaz 6.90 $ Servos Moteurs 9.90 $ x 2 Brackets 9.90 $ x2 Batterie 27 $ Autres 40 $ TOTAL 381 $

Figure 62 - Estimation du coût du ROBOT


56

Réalisation

5. Produit final On présente ici le produit final réalisé, pendant la partie de mettre tous les composants

ensemble nous avons la possibilité de changer quelques PINS suivant les contraintes

techniques rencontrés.

a. Montage électronique Fritzing

Figure 63 - Schéma électronique global

Ce montage Global montre presque tous les composants électroniques du ROBOT, on aura

toujours la possibilité d’ajouter d’autres composants et d’avoir de nouvelles fonctionnalités

tant qu’il reste des PINS vides dans la carte IOIO, nous parleront des nouvelles possibilités

dans la section perspectives.


57

Réalisation

b. Album Photos

On présente ici un ensemble de photos du ROBOT depuis les premières phases jusqu’à la

phase finale.

Ces Photos sont prises dans des dates différentes, elles montrent l’évolution du Robot

pendant les 2 premiers mois, où le grand travail été sur le développement des applications

et comment gérer la connectivité entre eux.

Figure 64 - Le Robot dans sa première phase

Figure 65 - Le Robot dans la phase intermédiaire


58

Réalisation

Ces Photos présente un produit final et bien fonctionnel, avec lequel nous avons participé à

plusieurs évènements (voir annexes)

III. Défis relevés Après avoir achevé ce projet, nous pouvons citer les différents problèmes rencontrés que

nous avons pu résoudre tout au long de son réalisation :

Problème de consommation en énergie, et l’effet auto-drain rencontré avec le Motor Driver.

Le temps énorme que nous avons pris pour nous documenter sur la carte IOIO et l’utilisation de matériel.

Le Problème du temps de latence du ROBOT. Le problème de synchronisation entre deux applications Android distantes. Le problème de la bande passante limité. Les blocages techniques lors du montage de quelques circuits électroniques. Le problème du non disponibilité de la quasi-totalité des composants électroniques

en Tunisie.

IV. Perspective & Evolution D’après les paragraphes qui précèdent nous pouvons dire qu’il reste des points à optimiser

dans notre projet tel que l’optimisation de la réception du streaming vidéo, la gestion des

cas d’urgence lors des incidents, l’amélioration de la partie traitement d’information, ce

manque est dû à des contraintes techniques puisque ce projet est notre première

Figure 66 - Le Robot en phase finale


59

Réalisation

expérience avec le Matériel géré par Android.

Comme perspective, nous pouvons rendre notre projet plus polyvalent en ajoutons des

capteurs de température, d’humidité, de magnitude, de couleurs, de courant, de force, de

pression, infrarouges, téléphonique, "de chocs", d’autres types de gaz, d'inclinaison, de

niveau, Humidistances, Transducteurs à ultrasons etc…

Ces composants nous ouvrent l’esprit à d’autres idées réalisables à travers un système

embarqué basé sur Android, nous citant ci-dessous quelques idées de projets:

Robot suiveur de ligne

Robot détecteur de mines (métaux)

Robot autonome de surveillance

Robot spécialisé dans la détection des différents types de gaz (milieux industriels,

plateformes pétrolières)

Robot explorateur de zones inaccessibles pour humains (catastrophes naturelles)

Système d’éclairage basé sur Android

Système d’alarme basé sur Android

Appareil de détection de niveau d’alcohol (Breath Analyser)

Système de notification pour boite aux lettres

Système de verrouillage intelligent

Système d’aide à la décision pour voiture

Système intégré pour réfrigérateur basé sur Android

Quadricoptère volante basée sur Android

V. Chronogramme

On remarque que la réalisation de ce projet été bien distribué au niveau de plusieurs

environnements en parallèle et sur une période de 6 mois.

Figure 67 - Chronogramme général


60

Conclusion

CONCLUSION

GENERALE

Ce projet de fin d’études, qui s’est déroulé à ESPRITEC, avait pour but la conception et la

réalisation d’un ROBOT intelligent à Base du système Android pour des buts divers comme la

sécurité, la surveillance, l’exploration etc...

« Android Based ROBOT » offre une multitude de fonctionnalités dont, les essentielles sont :

Visualisation du Streaming Vidéo directement sur le Smartphone de l’utilisateur.

Déplacement avancé et exploration d’endroits inaccessibles.

Détection d’obstacles et réaction automatisée.

Détection de fuite de Gaz,...

La gestion des Alertes suite à des évènements précises.

Notre projet a couvert au bout du compte la majeure partie des fonctionnalités qui nous ont

été demandées au début, mais opportunités d’améliorations de ce projet sont multiples.

D’une part, nous pourrons améliorer l’application pour rendre l’interactivité plus souple et

complète avec l’utilisateur, aussi on peut évoluer même le ROBOT en lui intégrants de

multiples nouveaux capteurs et détecteurs, et circuits diverses pour le rendre encore plus

complet et automatisée.

D’autre part, nous pourrons penser à lui ajouter des modules pour qu’il puisse gérer non

seulement les situations déjà programmées mais aussi de nouvelles situations où il peut

apprendre tout seul à l’aide d’algorithmes d’apprentissage et d’intelligence artificielle, qu’on

peut modéliser facilement au niveau de l’application Android.

D'un point de vue personnel, tout au long de ce projet, nous avons eu l’occasion de mettre

en pratique nos connaissances acquises au sein de l’école ESPRIT, aussi bien en

programmation et développement qu’en électronique, embarquées et en matières Télécom

et nous avons également eu l’opportunité de travailler avec de nouveaux outils, matériels, et

méthodologies.

Cette expérience a été très enrichissante et importante car elle a marqué la fin de ce cycle

d’ingénieur et nous a permis d’être confrontés aux responsabilités qui sont celles d’un

ingénieur : faire face aux délais, au stress et aux contraintes du travail dans un milieu de

recherche et d’innovation.


61

Bibliographie

BIBLIOGRAPHIE

1. Mike Lockwood, Erik Gilling, Jeff Brown. Google I/O 2011: Android Open Accessory API

and Development Kit (ADK). Youtube.com. [Online] 05 11, 2011. [Cited: 01 01, 2012.]

http://www.youtube.com/watch?v=s7szcpXf2rE.

2. TSVI, Ytai Ben. Profil Google+. Plus.Google.com. [En ligne] [Citation : 15 04 2012.]

https://plus.google.com/113760481226159480550/about.

3. FELLER, SAM. An Interview with Ytai Ben-Tsvi, Inventor of the IOIO. Engineer Blogs.

[Online] 03 21, 2012. [Cited: 03 24, 2012.] http://engineerblogs.org/2012/03/an-interview-

with-ytai-ben-tsvi-inventor-of-the-ioio/.

4. Site officiel ARDUINO. Arduino.cc. [En ligne] [Citation : 03 01 2012.] http://arduino.cc/.

5. Google. Android Open Accessory Development Kit. Developer.android.com. [En ligne]

[Citation : 01 04 2012.]

http://developer.android.com/guide/topics/connectivity/usb/adk.html.

6. First Sketch. Arduino.cc. [En ligne] [Citation : 15 02 2012.]

http://arduino.cc/en/Tutorial/Sketch.

7. Two steps communication protocol. arduino.cc. [En ligne] [Citation : 19 02 2012.]

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1292733514.

8. Tsvi, Ytai Ben. Github ytai / ioio. Github.com. [En ligne] https://github.com/ytai/ioio.

9. —. The IOIO Manager ApplicationNew Page Edit Page Page History. Github.com. [En ligne]

https://github.com/ytai/ioio/wiki/The-IOIO-Manager-Application.

10. Android Software and IOIO Application Firmware Images. github.com. [En ligne]

https://github.com/ytai/ioio/wiki/Downloads.

11. Rota, Véronique Messager. Gestion de projet agile avec Scrum, Lean, eXtreme

Programming... 3e édition. s.l. : Eyrolles.


62

Annexe

ANNEXE

OpenAccessory et ADK

OpenAccessory

OpenAccessory est une nouvelle fonctionnalité pour Android, qui permet de connecter des

périphériques externes à un appareil Android via une connexion USB. Cette fonctionnalité

expose une interface standardisée sur le bus USB, ainsi que d'une API Java permettant une

application Android à communiquer avec l'accessoire sur l'autre extrémité. Cette

fonctionnalité est supportée sur Android 2.3.4 et supérieur. Le protocole OpenAccessory

permet à l'appareil Android à agir comme un hôte ou d'un périphérique sur le bus USB (le

mode hôte est pris en charge uniquement sur Android 3.x et supérieur, et seulement sur

certains appareils).

OpenAccessory est un protocole de bas niveau: il dispose d'un seul canal de communication

full-duplex entre l'appareil Android et l'accessoire, sur laquelle des octets arbitraires peuvent

être envoyés dans les deux sens - un peu comme une connexion UART. Il laisse au

concepteur d'accessoires pour concevoir le protocole de niveau supérieur, c'est à dire quels

sont les messages à envoyer et à ce que leur sens est de l'application Android et de

l'accessoire.

ADK

Le kit de développement de l'accessoire (ADK) est

une implémentation de référence des cartes

OpenAccessory enabled, développé par Google et

a annoncé conjointement avec OpenAccessory.

Cette carte est essentiellement un Arduino Mega

avec un Shield à bord d'hôte USB. Il est livré avec

une bibliothèque C ++ de côté Arduino qui

implémente le protocole. Suite à Google,

plusieurs constructeurs ont publiés des cartes

compatibles.

Figure 68 USB Host and Accessory Modes


63

Annexe

Spécification Huawei Gaga U8180

General Information

Brand Huawei

Model Gaga U8180

Weight 100 G

Form Factor Touch Bar

Dimensions 104x56x13 MM

Operating Freq GSM 850 / 900 / 1800 / 1900 / UMTS

900 / 2100 MHz

Touch Screen Yes, Capacitive Touch Screen

Display Color 2.8 inches QVGA, TFT Capacitive

Touchscreen, 262K Colors

Display Size Huawei Gaga U8180 has a display size

of 240 x 30 px

Sensors G-sensor for Auto-Rotate UI

Camera Yes, 3.2 Mega Pixels Camera with Focus

Camera Res. 2048 x 1536 Pixels

Zoom Yes, Digital Zoom

Video Yes, QVGA (240x320 Pixels) at 24fps

Video Player Yes, Video Formats : MP4, H.263, H.264,

15fps VGA / 30fps WQVGA

Software

Games Yes

Browser Yes, WAP 2.0/HTML

Operating System Android OS, v2.2 (Froyo)

Call Records

Phone Book Practically Unlimited

Received Calls Practically unlimited

Dialed Calls Practically unlimited

Battery

Stand-By Time N/A

Talk Time N/A

Li-ion 1200 mAH

Memory

Internal

Memory

Yes, Internal Memory : 256MB RAM +

512MB Flash

External

Memory

Yes, Up to 16GB

Memory Slot Yes, Micro SD Card

Message

SMS Yes

MMS Yes

Email Yes

Social

Networking

Services

Google Maps, Google Search, Gmail

Music

Ring Tone Vibration, Polyphonic, MP3

FM N/A

Music Yes, Music Formats : MP3, AAC+, eAAC

with 3.5mm Audio Jack

Speaker Yes

Headset Yes

Data

GPRS Yes

Bluetooth Yes, v2.1 with A2DP

Wirless

Protocol

Yes, Wi-Fi 802.11 b/g/n

Port Yes, Micro USB (High Speed USB)

Edge N/A

Infra Red No

3G Yes

GPS Yes, with A-GPS support

CPU Yes, Qualcomm MSM7225 528MHz

Processor

Salespack Handset, Battery, Charger, Earphone,

USB Cable, User Manual, Warranty Card


64

Annexe

Capteur Ultrason – Dossier Technique Spécification

Supply voltage 5V

Global Current Consumption 15 mA

Ultrasonic Frequency 40k Hz

Maximal Range 400 cm

Minimal Range 3 cm

Resolution 1 cm

Trigger Pulse Width 10 μs

Outline Dimension 43x20x15 mm

Dimensions Mécaniques

M

http://www.seeedstudio.com/wiki/File:Ultra-Sonic-dimen.JPG

http://www.seeedstudio.com/wiki/File:Ultra-Sonic-Example.jpg

http://www.seeedstudio.com/wiki/File:Ultra-Sonic-dimen.JPG

http://www.seeedstudio.com/wiki/File:Ultra-Sonic-Example.jpg


65

Annexe

Utilisation

Installation Matérielle

Une brève impulsion ultrasonique est transmise à l'instant 0, réfléchie par un objet. Le seigneur reçoit ce signal

et le convertit en un signal électrique. L'impulsion suivante peut être transmis lors de l'écho est disparu. Cette

période est appelée période de cycle. La durée du cycle recommandent devrait pas être inférieur à 50ms. Si

une impulsion largeur 10μs de déclenchement est envoyé à la broche de signal, le module à ultrasons se

produire huit signal de 40 kHz à ultrasons et à détecter l'écho de retour. La distance mesurée est

proportionnelle à la largeur d'impulsion d'écho et peut être calculée par la formule ci-dessus. Si aucun obstacle

n'est détecté, la broche de sortie donne un signal de niveau haut 38ms.

Programmation

/* Ping))) Sensor

This sketch reads a PING))) ultrasonic rangefinder and returns the

distance to the closest object in range. To do this, it sends a pulse

to the sensor to initiate a reading, then listens for a pulse

to return. The length of the returning pulse is proportional to

the distance of the object from the sensor.

The circuit:

* +V connection of the PING))) attached to +5V

* GND connection of the PING))) attached to ground

* SIG connection of the PING))) attached to digital pin 7

created 3 Nov 2011

by David A. Mellis

modified 30 Jan 2012

by Tom Igoe

This example code is in the public domain.

*/

http://www.seeedstudio.com/wiki/File:Ultra-Sonic-seq.JPG


66

Annexe

// this constant won't change. It's the pin number

// of the sensor's output:

const int pingPin = 7;

void setup() {

// initialize serial communication:

Serial.begin(9600);

}

void loop()

{

// establish variables for duration of the ping,

// and the distance result in inches and centimeters:

long duration, inches, cm;

// The PING))) is triggered by a HIGH pulse of 2 or more microseconds.

// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:

pinMode(pingPin, OUTPUT);

digitalWrite(pingPin, LOW);

delayMicroseconds(2);

digitalWrite(pingPin, HIGH);

delayMicroseconds(5);

digitalWrite(pingPin, LOW);

// The same pin is used to read the signal from the PING))): a HIGH

// pulse whose duration is the time (in microseconds) from the sending

// of the ping to the reception of its echo off of an object.

pinMode(pingPin, INPUT);

duration = pulseIn(pingPin, HIGH);

// convert the time into a distance

inches = microsecondsToInches(duration);

cm = microsecondsToCentimeters(duration);

Serial.print(inches);

Serial.print("in, ");

Serial.print(cm);

Serial.print("cm");

Serial.println();

delay(100);

}

long microsecondsToInches(long microseconds)

{

// According to Parallax's datasheet for the PING))), there are

// 73.746 microseconds per inch (i.e. sound travels at 1130 feet per

// second). This gives the distance travelled by the ping, outbound


67

Annexe

// and return, so we divide by 2 to get the distance of the obstacle.

// See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf

return microseconds / 74 / 2;

}

long microsecondsToCentimeters(long microseconds)

{

// The speed of sound is 340 m/s or 29 microseconds per centimeter.

// The ping travels out and back, so to find the distance of the

// object we take half of the distance travelled.

return microseconds / 29 / 2;

}


68

Annexe

Motor Driver TB6612FNG

Block Diagram

Fonctions des PINS


69

Annexe

Operation Range

Fonction H-SW de contrôle

Description Opérationnelle H-SW


70

Annexe

Caractéristiques visées

Caractéristiques électriques


71

Annexe

Diagramme d’application Typique


72

Annexe

Capteur de Gaz (MQ5)

Caractéristiques électroniques

Items Parameter

name Min Type Max Unit

System Characteristics

VCC Working Voltage 4.9 5 5.1 V

PH Heating

consumption 0.5 - 800 mW

RL Load resistance can adjust

RH Heater resistance - 33 - Ω

Rs Sensing

Resistance 3 - 30 kΩ

Installation Matérielle

Connectez ce module à la broche analogique de Grove. Vous pouvez

gagner la tension présente à travers la broche SIG. Plus la

concentration du gaz, plus la tension de sortie de la broche SIG. La

sensibilité peut être réglée en tournant le potentiomètre. S'il vous plaît

noter le meilleur temps de préchauffage de la sonde est d'environ 24

heures.

Programmation

Connectez le module avec l'aide Grove Bouclier A0 comme sur la

photo ci-dessus. Utilisez le programme ci-dessous pour obtenir la tension. Vous pouvez voir la tension

ira plus élevé si la concentration des incréments de gaz.

void setup() {

Serial.begin(9600);

}

void loop() {

float vol;

int sensorValue = analogRead(A0);

vol=(float)sensorValue/1024*5.0;

Serial.println(vol,1);

}


73

Annexe

1er Article sur Tunandroid.com

TUNANDROID.COM

La Communauté Android en Tunisie

« Android Based ROBOT » – Un Robot Tunisien avec un cerveau Android1

PAR HOUSSEM EDDINE LASSOUED, LE 6 FÉVRIER 2012

Avec ses premiers pas, le Robot à bien pris une

forme et peut être déclaré comme une Version

Alpha du projet de Réalisation d’un ROBOT Basée

sur le OS Mobile ANDROID, dans le cadre d’un

Projet de fin d’études à ESPRIT (Ecole Supérieure

Privée d’Ingénierie et de Technologie) en TUNISIE.

L’idée de base de ce projet été comment

Transformer un smartphone Android en un Robot!

Connecter le monde Android(Soft) au monde

électronique(Hard) est bien évidement possible

maintenant, quelques solutions de faire

communiquer ces deux mondes existent, citant la

carte IOIO(utilisé dans ce Robot),la carte Arduino,

la Google ADK Board,… un choix est possible selon

les besoins du projet et les caractéristiques de

chaque plateforme, je vous propose quelques

comparaisons entre ces solutions:

Google ADK vs Arduino ADK vs Sparkfun IOIO

vs ADK Shield

IOIO over OpenAccessory (ADK)

The IOIO and Android Based Hardware

The Buzz at the Google I/O 2011

Android est devenu de plus en plus intéressant

pour le développement de matériel. Maintenant,

vous devriez bientôt pouvoir brancher manettes de

jeu, matériel personnalisé, des capteurs et autres dispositifs et de faire une plate-forme

Android-Anywhere.

Les nouvelles API de gestion de matériel permettra à tout le monde de développer des

accessoires matériels pour Android, à partir d’amateur individuels vers les grandes

marques mondiales. Vous n’avez pas à signer un NDA, et vous n’avez pas besoin d’une

licence de matériel spécial, les aspects qui concerne la politique d’Apple n’existera pas

chez Android. N’importe qui peut le faire.

Revenant à ce Robot, comme c’est une première expérience à ESPRIT, il sera destiné

pour le Test, la sécurité et la recherche dans le domaine Android Embarqué, la domotique

avec Android, la notion de Maison Intelligente etc…

1 Lien : http://www.tunandroid.com/content/2012/02/06/android-based-robot-un-robot-tunisien-avec-un-

cerveau-android/

http://www.tunandroid.com/content/

http://forum.xda-developers.com/showthread.php?t=1371750

http://forum.xda-developers.com/showthread.php?t=1371750

http://ytai-mer.blogspot.com/2011/06/ioio-over-openaccessory-adk-available.html

http://www.sparkfun.com/news/643

http://www.funnyrobotics.com/2011/05/android-catapults-arduino-into-cloud.html

http://www.tunandroid.com/content/wp-content/uploads/2012/02/Flyer1-Robot_update2.png


74

Annexe

Il sera doté d’un ensemble de capacités et il assurera pas mal de fonctionnalités, je vous

liste ici quelques-unes:

-Déplacement dans les 4 directions (inclut les rotations) avec 2 niveaux de vitesses.

-Commandé à distance via un Smartphone Android(wifi)/ via un Navigateur Web

-Capture vidéo et envoi du Streaming en direct vers l’application de commande

-Un système de détection d’obstacles/de distances

-Un module de géolocalisation GPS (OUTDOOR)

-Détection de mouvement (motion Detection)/d’obscurité

-Détection de fuite de Gaz/Mesure de Température

-Fonctionnalité d’Alarme en cas d’urgence

-Notification Automatique par SMS / E-mail

-Signalisation en cas de problèmes (Alimentation faible, déséquilibre, wifi hors portée)

-Récupération des mesures sur l’alimentation du Robot et la qualité de signal

-Module de Commandes Vocales

-… (de nouvelles idées tous les jours)

Le projet est encore dans sa première phase, en attendant l’avancement au fur et à

mesure, nos encouragement pour toute l’équipe qui travaille dessus, on espère qu’on voit

d’autres projets innovants en Tunisie, il faut juste avoir confiance en soi.

“Trust yourself. You know more than you think you do.”

Quelques Photos:

FÉVRIER 6TH, 2012 | TAGS :ANDROID, ANDROID BASED ROBOT, DOMOTIQUE, ESPRIT, ESPRIT

MOBILE, IOIO, IOIO ANDROID, MOBILE PHONE, ROBOT, ROBOT

ANDROID, ROBOTIQUE, TUNISIA,TUNISIE | CATÉGORIE

: DÉVELOPPEMENT, NOUVEAUTÉS, SMARTPHONES

http://www.tunandroid.com/content/tag/android/

http://www.tunandroid.com/content/tag/android-based-robot/

http://www.tunandroid.com/content/tag/domotique/

http://www.tunandroid.com/content/tag/esprit/

http://www.tunandroid.com/content/tag/esprit-mobile/

http://www.tunandroid.com/content/tag/esprit-mobile/

http://www.tunandroid.com/content/tag/ioio/

http://www.tunandroid.com/content/tag/ioio-android/

http://www.tunandroid.com/content/tag/mobile-phone/

http://www.tunandroid.com/content/tag/robot/

http://www.tunandroid.com/content/tag/robot-android/

http://www.tunandroid.com/content/tag/robot-android/

http://www.tunandroid.com/content/tag/robotique/

http://www.tunandroid.com/content/tag/tunisia/

http://www.tunandroid.com/content/tag/tunisie/

http://www.tunandroid.com/content/category/developpemnt/

http://www.tunandroid.com/content/category/nouveautes/

http://www.tunandroid.com/content/category/androids/smartphones/


75

Annexe

Participation à TUNIROBOTS2012 et premier prix

TUNANDROID.COM

La Communauté Android en Tunisie

Un ROBOT Android élu comme Meilleur Exposition à TUNIROBOTS-20121

PAR HOUSSEM EDDINE LASSOUED, LE 22 AVRIL 2012

L’Institut National des Sciences Appliquées et de la Technologie (INSAT) a organisé le dimanche

22 avril 2012 à partir de 9 h la journée nationale de la robotique, baptisée Tunirobots’12.

Une action menée en grande partie par les étudiants bénévoles de l’institut qui ont composés des

équipes bien organisées afin d’assurer la réussite de cette journée.

Les expositions des différents robots construits par les étudiants leur a permis de démontrer

encore une fois l’ingéniosité des jeunes tunisiens en matière de robotique et de technologie, et

seront le trait d’union entre eux et les différentes entreprises qui assisteront à cet évènement qui

promet de belles réalisations.

Android été bien évidement présent lors de cette journée, et oui... nos jeunes tunisiens ont bien

pensé cette année d’entrer à Tunirobots avec des robots plus intelligents et moins classique, des

robots avec un cerveau ANDROID !

C’est à ce propos que nous parlons de la participation d’un jeune élève ingénieur de l’école

ESPRIT, Mr. Houssem Eddine Lassoued qui a participé avec son Projet de fin d’étude en cours de

réalisation, un Robot à base d’Android, nous avons bel et bien

parlé de ce projet avant, ici.

Pour résumer la journée, « l’Android Based Robot » a eu

beaucoup de succès auprès de l’audience présente tout au

long de la journée, des étudiants de différentes institutions

des amateurs, des professionnels, et des médias ont profité

de l’occasion pour faire quelques interviews avec l’exposant

du Robot, il y avait aussi un nombre de jurys

indépendants appartenant à des différentes universités et

« labos », leurs rôle était de visiter chaque exposant et juger

son Robot sur différentes critères, dont les plus importantes

sont l’originalité, les fonctionnalités, la réalisation et les

perspectives du projet qui doivent être bien expliquées par

l’exposant.

1 Lien :

http://www.tunandroid.com/content/

http://www.tunandroid.com/content/2012/02/06/android-based-robot-un-robot-tunisien-avec-un-cerveau-android/

http://www.tunandroid.com/content/wp-content/uploads/2012/04/IMG_20120421_222536.jpg

http://www.tunandroid.com/content/wp-content/uploads/2012/04/BN7169robo300.jpg


76

Annexe

Le résultat est annoncé vers la fin de la journée, et une victoire pour le Robot à Base Android qui

a remporté le prix de la meilleure exposition ) un grand Bravo pour Houssem Eddine,

Félicitation pour toute l’équipe Mobile d’ESPRIT, et c’est une victoire aussi pour la Communauté

Tunandroid;)

le prix attribué au vainqueur est une Tablette ARCHOS 70 IT, une certification de participation,

et une jolie médaille pour garder le souvenir.

AVRIL 22ND, 2012 | TAGS :12, ANDROID, ESPRIT, EXPOSANT, HOUSSEM EDINE LASSOUED, INSAT,IOIO

ANDROID, MOBILE, PRIX, ROBOT, TUNIROBOTS, TUNISIE | CATÉGORIE

: ARCHOS, EMBARQUÉ,EVENTS, NATIONAL, NOUVEAUTÉS

http://www.tunandroid.com/content/tag/12/

http://www.tunandroid.com/content/tag/android/

http://www.tunandroid.com/content/tag/esprit/

http://www.tunandroid.com/content/tag/exposant/

http://www.tunandroid.com/content/tag/houssem-edine-lassoued/

http://www.tunandroid.com/content/tag/insat/



http://www.tunandroid.com/content/tag/mobile/

http://www.tunandroid.com/content/tag/prix/

http://www.tunandroid.com/content/tag/robot/

http://www.tunandroid.com/content/tag/tunirobots/

http://www.tunandroid.com/content/tag/tunisie/

http://www.tunandroid.com/content/category/androids/tablettes/archos-tablettes/

http://www.tunandroid.com/content/category/androids/embarque/

http://www.tunandroid.com/content/category/events/

http://www.tunandroid.com/content/category/nouveautes/national/

http://www.tunandroid.com/content/category/nouveautes/








77

Annexe

Article Tekiano.com 1:

Un peu plus loin, nous retrouvons cette fois le stand du Club Esprit.

Houssem Eddine Lassoued, étudiant en 5ème année télécommunication

nous présente un robot commandé à base du système d'exploitation

Google Android. «Ce robot est constitué de quatre moteurs, d'une carte

électronique IOIO, d'une webcam, d'un capteur à ultra-son et d'un

détecteur de gaz. Il est capable s'introduire dans divers endroits restreints

et effectuer des tâches variées comme la surveillance d'un domicile, ou

d'un entrepôt » Souligne le concepteur qui au passage, précise que

l'avantage de ce système embarqué est le fait de pouvoir contrôler ce

robot directement depuis son Smartphone, grâce à une application qui

renseignera l'utilisateur sur les distances d'un tel

objet ou obstacle ou encore du taux de gaz présent

dans une pièce...

Participation à ComNet’2012 Supcom à Hammmet 2

On a participé avec le robot à la la troisième Conférence Internationale sur les

Communications et Réseaux (ComNet'2012), qui se tiendra le 1er avril 2012, à

Hammamet.

Cette conférence internationale réunit des chercheurs des TIC des pays du

Nord et du Sud dans le but de se rencontrer, d'échanger leurs idées et leur

expertise, d'initier et de renforcer leur coopération sur des sujets liés aux

communications réseaux. Il se positionne comme une plate-forme pour les

chercheurs et les praticiens à la fois du milieu universitaire et de l'industrie

pour se rencontrer et partager la recherche de pointe et le développement

dans ces domaines.

ComNet'2012 fournira une excellente tribune internationale pour le partage

des connaissances et des résultats de recherche dans les théories, les

méthodologies et les applications dans différents sujets liés à la communication

et au réseau (filaires et sans fil).

1 http://www.tekiano.com/tek/science/5177-tunirobots-2012-bataille-de-robots-et-premiere-fusee-tunisienne-

.html 2 http://www.supcom.mincom.tn/ComNet2012/


78

Annexe

Participation à Droidcon Tunis 2012 (cité des sciences)1

La Cité des sciences de Tunis a accueilli pour la

première fois en Tunisie, le 12 et 13 Mai 2012, «le

Droidcon Tunis 2012 », un événement majeur

tournant autour du système d’exploitation mobile

Android. Ces deux jours sont constitués de

conférences, de débats, d’ateliers d’initiation, d’un

espace d’expositions gratuit, de démonstrations, d’un Barcamp et même d’un Hackathon,

sorte de marathon pour développeurs. .

Durant deux jours de Droidcon Tunis, plus de 350 participants ont pris part à une

aventure à la fois originale et exceptionnellement enrichissante.

Durant le premier jour, un barcamp a été organisé en parallèle à une succession de

formations d’initiations donné par les membres de Tunandroid et une conférence donné

par Tunisiana.

Dans le grand auditorium, un challenge d’application a eu lieu, ou chaque participant, qui

souhaite participer au challenge, a 3 minutes pour présenter son application. Le gagnant

par vote à main levée, a eu un smartphone Alcatel One Touch.

Parmi la participation d’ESPRIT, été notre projet le Robot à Base d’Android

1 droidcon.tn

http://droidcon.tn/

http://droidcon.tn/


79

Annexe


80

Annexe


81

Annexe


82

Annexe


83

Annexe


84

Annexe

NOTES

ROBOT à base d'Android - Rapport PFE

Technology

Transcript of ROBOT à base d'Android - Rapport PFE