ROBOT à base d'Android - Rapport PFE

SIGNATURES

Signature Encadreur
ESPRITEC

Signature
Département de
langue

Robot à base d’Android

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
i
Dédicaces


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.

ii
Remerciements


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.

iii
Résumé


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

iv
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

v
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

vi
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

vii
Table des matières


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

viii
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

ix
Liste des figures


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

x
Liste tableaux


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, Figure 1 - Android@Home
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.

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

2
Introduction 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

3
Présentation générale


- 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 Figure 3 - Différents environnement du projet
transféré d’un environnement à un autre plusieurs fois avant qu’il soit finalisé.

1
http://www.espritmobile.com/

4


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.

5


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 Figure 4 - ADK de Google
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.

6
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 Bluetooth Shield NATIVE (V.3)
Shield 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
Figure 5 - Arduino Mega2560
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.

7
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

8
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
Figure 7 - IOIO – Distributeur Sparkfun
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...

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

Figure 9 - Carte IOIO
Figure 8 - Montage de la carte IOIO

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/

10
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

11
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>

12
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

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

Figure 11 - Montage de l'exemple Démo

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.
13
Etat de l’art


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.

14
Spécifications et analyse des besoins


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 Itératif et incrémental.
rétroaction possible, phases
séquentielles.
Planification Prédictive, caractérisée par des Adaptative avec plusieurs niveaux de
plans plus ou moins détaillés sur planification avec ajustements si
la base d’un périmètre et nécessaires au fil de l’eau en fonction
d’exigences définies au début du des changements survenus.
projet.
Documentation Produite en quantité importante Réduite au strict nécessaire au profit
comme support de d’incréments fonctionnels
communication, de validation et opérationnels pour obtenir le feedback
de contractualisation. du client.
Équipe Une équipe avec des ressources Une équipe responsabilisée où
spécialisées, dirigées par un chef l’initiative et la communication sont
de projet. privilégiées, soutenue par le chef de
projet.
Qualité Contrôle qualité à la fin du cycle Un contrôle qualité précoce et
de développement. Le client permanent, au niveau du produit et du
découvre le produit fini. processus. Le client visualise les
résultats tôt et fréquemment.
Changement Résistance voire opposition au Accueil favorable au changement
changement. inéluctable, intégré dans le processus.
Processus lourds de gestion des
changements acceptés.
Suivi de Mesure de la conformité aux Un seul indicateur d’avancement : le
l’avancement plans initiaux. nombre de fonctionnalités
implémentées et le travail restant
Analyse des écarts. affaire.
Gestion des risques Processus distinct, rigoureux, de Gestion des risques intégrée dans le
gestion des risques. 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 Satisfaction client par la livraison de
en termes de coûts, de budget et valeur ajoutée.
de niveau de qualité.
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é

15


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

16


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

17


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 Rational Logiciel Mobile
Mobile-D
Changement élevée En raison du changement élevé des Incertitude élevée, environnement
d’environnement exigences, on a besoin de dynamique: Centaines de nouveau de
l’approche de développement téléphones portables sont fabriqués
incrémental et itératif chaque année
Petite équipe de Les petites équipes peuvent réagir Majorité de logiciel mobile sont
développement plus rapidement, partager développés par micro (<10) ou
l’information, peu de moyennes (<250) entreprises, La taille
documentation est nécessaire de l’équipe est souvent inférieure à 20
personnes
Client identifiable Pour éviter le malentendu Nombre potentiellement illimité
d’affaires d’utilisateur. Client d’affaires plus facile
à identifier, par exemple distributeur
Environnement de Flexible, extensive, etc… Utilise souvent Java et C++
développement
d’objet orienté
Non sécurité Les échecs ne causent pas la perte Majorités de logiciel mobile existant
critique des vies sont pour le but de divertissement. Les
équipement mobiles sont non fiables
Logiciel de niveau Les grands systèmes embarqués Tandis que les systèmes mobiles sont
d’application exigent la communication étendue complexes et fortement dépendants, les
et mécanismes de vérification. applications mobiles peuvent être
applications autonomes
Petit système Moins de conception d’Up front La taille des applications mobiles varie,
requise mais généralement elles sont moins que
10.000 lignes de code
Cycle de Pour les buts de la rétroaction Les cycles de développement varient. En
développement rapide général, les applications mobiles
court peuvent être développés de 1 à 6 mois
Tableau 3 - Caractéristiques du Mobile-D

18


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 une manipulation plus raffiné des fonctionnalités à assurer
permettrait 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

19


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.

20


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

21


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.

22


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

23


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

24


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

25


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

26


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

27


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.

28


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.

29


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

30

ROBOT à base d'Android - Rapport PFE

ROBOT à base d'Android - Rapport PFE

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a ROBOT à base d'Android - Rapport PFE

Similar a ROBOT à base d'Android - Rapport PFE (20)

ROBOT à base d'Android - Rapport PFE