Outils pour utilisateurs

Outils du site


Panneau latéral

Accueil

Select other language :


Apprentissage

Enseignements

Enseignements Département Informatique SI5 et Master IFI

Enseignements Département Bâtiment Polytech'Nice

Autres Formations française et étrangère

Activités administratives, Ingénierie et Innovation Pédagogiques

Apprentissage Département Informatique SI5/Master 2 ingénierie informatique EUR DS4H


Recherche

Valorisation de la Recherche

Dépôts Logiciels à l’Agence de Protection des Programme (APP)

Valorisation des résultats de recherche et transfert

Diffusion de la Culture scientifique et Technologique

Communications de presse

Séminaire ENSI Tunis

Pédagogie Innovante

Relations industrielles et socio-économique

Organisation de Manifestations

  • Conférence sur les FabLabs, Alexandre Schneider, Professeur Agrégé en Génie Mécanique, Université de Reims Champagne-Ardenne Web
  • Journées UbiMob'14 Site Web

Animation de la Recherche

U-Santé

Privé

Outils

Sources d'Informations

cours:plim:projet16_17:gr11:gr11

É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é 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é

Téléphone compatible avec : 2G 3G Bluetooth WiFi NFC

OS : Android 5.1.1

Environnement logiciel:

Caractéristiques de l'OS : Windows 64bits, Ubuntu 64bits .

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:

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

cours/plim/projet16_17/gr11/gr11.txt · Dernière modification: 2017/02/19 23:32 par blagouge