Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cours:plim:projet16_17:gr11:gr11 [2016/10/19 14:42] – blagouge
+++ cours:plim:projet16_17:gr11:gr11 [2017/02/19 22:32] (Version actuelle) – blagouge
@@ Ligne 1: / Ligne 1: @@
-**Activité à reconnaître:** Étude du taux d’utilisation du téléphone
+====== Étude du taux d’utilisation du téléphone ======
 **Équipe :**
 __Nom 1 :__ Théo Donzelle
 Créneau (AM ou PM) : PM
 __Nom 2 :__ Bénédicte Lagouge
 Créneau (AM ou PM) : PM
 **Un scénario d'illustration du Projet**
-Utilisation du capteur de proximité pour savoir combien de temps notre téléphone passe dans notre poche. Récupération du temps passé au téléphone par l’utilisateur. Puis clusterisation des utilisateurs en fonction de ces deux temps. L’utilisateur peut donc savoir de quel type d’utilisateur il fait partie .
+Utilisation du capteur de proximité et de la détection de mise en veille de l'écran pour savoir combien de temps notre téléphone passe dans notre poche et récupération du temps passé au téléphone par l’utilisateur. Puis clusterisation des utilisateurs en fonction de ces deux temps. L’utilisateur peut donc savoir de quel type d’utilisateur il fait partie .
+**Critères de clusterisation**
+Nos hypothèses sont les suivantes :
+- si le téléphone est en veille et le capteur de proximité "proche",le téléphone est dans une poche
+- si le téléphone est en veille et le capteur de proximité "loin", le téléphone est posé quelque part
+- si le téléphone n'est pas en veille et le capteur de proximité "proche", l'utilisateur est en appel
+- si le téléphone n'est pas en veille et le capteur de proximité "loin", l'utilisateur utilise son téléphone sans téléphoner.
+Nous recoupons les informations "en veille", "pas en veille", "proche", "pas proche" pour définir les clusters suivants :
+- caller : l'utilisateur passe en majorité son temps d'utilisation à téléphoner
+- player : l'utilisateur utilise son téléphone souvent
+- pocket user : l'utilisateur a souvent son téléphone dans sa poche
+- idle user : l'utilisateur n'utilise pas bien souvent son téléphone
+- equilibrated user : l'utilisateur a une utilisation équilibrée
+**L'architecture et les rôles des différentes parties**
+L'utilisateur a à sa disposition une application Android enreigstrant les données nécessaires dans une base de données SqLite . Cette base de données contient basiquement tous les enregistrements de temps passé dans tel critère, avec une date de commencement.Elle stocke les données enregistrées par l'application jusqu'à ce que l'application envoie les données au serveur.
+Lorsque l'utilisateur envoie les données au serveur via l'application, il envoie également son identifiant de téléphone de façon à ce que le serveur sache quel utilisateur lui envoie quelles informations (le serveur peut en effet stocker et traiter les informations de plusieurs utilisateurs).
+Le serveur va alors stocker les nouvelles données de cet utilisateur.
+Chaque jour à minuit ,le serveur va utiliser un algorithme de Random Forest qu'il a à sa disposition et façon à déterminer le profil (cluster) le plus vraisemblable pour chaque utilisateur. Il stocke ce résutats dans un fichier propre à l'utilisateur.
+L'utilisateur peut alors demander le profil le plus vraisemblable qu'il peut avoir pour un jour futur.
+En résumé ....
+__Rôle de l'application Android :__
+- Sauvegarder les changements d’états du capteur de proximité et du fait que l’écran du téléphone soit allumé ou non en BDD locale
+- Envoyer les données sauvegardées au serveur en appuyant sur le bouton “Send Datas”
+- Demander au serveur quel type d’utilisateur on sera pour un jour futur en sélectionnant une date future sur le calendrier
+__Rôle du serveur :__
+- Recevoir et stocker les données de chaque utilisateur en quatre catégories : “in_use” (c’est-à-dire que le téléphone est allumé mais que le capteur de proximité ne détecte rien), “not_in_use” (le téléphone est allumé et le capteur de proximité ne détecte rien), “pocket” (le téléphone est éteint et le capteur de proximité détecte quelque chose) ou “call” (le téléphone est allumé et le capteur de proximité détecte quelque chose)
+- En fin de journée, passer les données de chaque utilisateur par l’algorithme de Random Forest pour leur associer un type d’utilisateur et stocker cet historique
+- Prévoir pour un jour donné dans quel type chaque utilisateur sera classé
 **Cible mobile utilisée : Samsung S3 Mini **
 __Programmation :__ Android
 __Caractéristiques techniques__
 Fiche technique : http://www.samsung.com/fr/consumer/mobile-devices/smartphones/galaxy-s/GT-I8190MBAXEF
 __Capteurs disponible:__
  - accéléromètre
  - capteur géomagnétique
  - gyroscope
  - capteur de proximité
@@ Ligne 28: / Ligne 81: @@
 **Environnement logiciel:**
 __Caractéristiques de l'OS :__ Windows 64bits, Ubuntu 64bits .
-__IDE utilisable :__ Android Studio, IntelliJ IDEA, Eclipse.
+__IDE utilisés :__ Android Studio pour la partie application, IntelliJ IDEA pour la partie serveur
+__SDK Android conseillé:__ Android SDK 5.1
+__JDK utilisé : __ 1.8
+**Activité reconnue :** Étude du taux d’utilisation du téléphone
 **Capteurs utilisés et données collectées:**
-__Capteur utilisé :__ capteur de proximité
-__Données collectées par le téléphone :__ temps passé au téléphone
-__SDK :__ Android SDK
-__API utilisée :__ Google Analytics pour connaître le temps passé au téléphone
+__Informations du téléphone étudiées :__ capteur de proximité, mise en veille ou non du téléphone
+__Données collectées par le téléphone :__ temps passé par le téléphone selon les 4 critères "en veille", "pas en veille", "proche", "pas proche"
+** API et librairies:**
+__Pour l'algorithme de Random Forest : __ Quickml, qui nous a permis d'intégrer Random Forest dans notre code Java ; la page principale se situe ici http://quickml.org/
+__Pour utiliser des objets JSON (transmission d'infos application <-> serveur) : __ la librairie org.json : https://mvnrepository.com/artifact/org.json/json
+__Pour "tester":__ Google Analytics pour avoir des informations supplémentaires sur les utilisateurs utilisant leur téléphone (cette api a été introduite dans notre projet par pure curiosité de notre part mais n'est absolument pas le centre du projet)
 Lien vers la documentation de cette API : https://developers.google.com/analytics/
 **Faisabilité du projet : **
-Pour conclure le projet est totalement faisable, nous pouvons par le biais de Google Analytics récupérer le temps passé par l’utilisateur au téléphone. Et Android offre la possibilité d’avoir accès aux différents capteurs du téléphone donc le capteur de proximité. Nous pourrons donc aussi connaître le temps que le téléphone passe dans la poche de l’utilisateur.
+Pour conclure le projet est totalement faisable.Android offre la possibilité d’avoir accès aux différents capteurs du téléphone donc le capteur de proximité. Nous pourrons donc aussi connaître le temps que le téléphone passe dans la poche de l’utilisateur.
 **Algorithme à mettre en oeuvre :**
 Nous allons récupérer des temps d’utilisations et voulons les clusteriser afin de classifier les différents utilisateurs.
-Reconnaissance d’activité non-supervisée avec la minute en métrique.
+Nous avons utilisé Random Forest en mode supervisé avec le temps en métrique.
+**Exécutables, Git, How-to...**
+__Voici l'APK Android : __ https://github.com/Sualty/ProjetELIM/blob/master/app-debug.apk
+__Voici l'exécutable Java du serveur : __ https://github.com/Sualty/ProjetELIM/blob/master/elim-1.0-SNAPSHOT-jar-with-dependencies.jar
+__Voici le lien du git :__ https://github.com/Sualty/ProjetELIM.git
+__Comment utiliser notre projet?__
+L'application Android peut se lancer en utilisant l'APK : en transférant le fichier .apk vers le téléphone, en "cliquant" dessus, et en disant qu'on veut l'installer, ça l'installe. (il faut indiquer qu'on accepte les .apk de sources externes dans l'onglet "Sécurité" des paramètres.
+Le serveur peut se lancer en utilisant dans un terminal la commande
+    java -jar elim-1.0-SNAPSHOT-jar-with-dependencies.jar
+Il faut noter que pour envoyer/recevoir des données de l'application ver le serveur ,il faut avoir le serveur lancé puis (re)lancer l'application.