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:gr10:gr10

Projet Groupe 10

Présentation du projet

  • Quentin Laborde
  • Créneau : PM
  • Clément Sibut
  • Créneau : AM
  • Nom du Projet : Cartographie de l'environnement sonore

Le but de notre application est de créer une cartographie de l'environnement sonore afin de voir quelles sont les zones les plus bruyantes et les plus calmes. Cela permettrait par exemple de voir quels sont les quartiers calmes dans une ville. Nous utiliserons le micro comme capteur qui une fois calibré nous permettra de récupérer le volume sonore. L'heure sera également enregistrée et prise en compte pour pouvoir faire une carte de l'environnement sonore de jour et une autre de nuit.On applique alors un algorithme qui cartographie en fonctions des mesures des utilisateurs et de leur localisation. La localisation est détectée par GPS.

Mise à jour suite à l'évaluation intermédiaire : Nous avons finalement décidé d'utiliser 3 types de “filtre” qui permette à l'utilisateur de sélectionner différents types de map : si les mesures sont prises pendant une période de repos ou d'activité, si elles sont prises a l'extérieur ou à l'intérieur. Ces deux nouveaux filtres sont appliqués pour la création des clusters mais aussi lors de l'enregistrement des amplitudes. Ainsi l'utilisateur doit indiquer avec un paramétrage s'il est à l'extérieur ou à l'intérieur et s'il est dans une période de repos ou en activité (bruyant) afin d'affiner la capture des données. L'utilisateur peut toujours sélectionner le jour de la semaine qu'il veut visualiser lors de la création des clusters mais nous avons choisi d'enlever le filtre jour/nuit (remplacé par le filtre activité/repos car trop imprécis selon notre encadrant).

Scénario

Lorsque Bob installe notre application sur son smartphone et qu'il la lance pour la première fois, un service en arrière-plan est lancé. Ce service va récolter périodiquement la position GPS de Bob et l'amplitude sonore captée par le microphone. Ces données sont envoyées vers un serveur qui traite ces données ainsi que celle d'autres téléphones qui utilisent aussi l'application. Le traitement donne deux informations principales à Bob, une cartographie géographique et temporelle de la pollution sonore ainsi qu'une prévision sur la pollution sonore sur la même zone dans le futur (demain à midi par exemple).

Mise à jour suite à l'évaluation intermédiaire : Ce scénario correspond toujours a notre vision de l'application.

Matériel disponbile

Nous avons deux smartphones avec un OS Android :

* Quentin

  • Samsung Galaxy S6
  • Caractéristiques techniques
    • Capteurs disponibles :
      • Accéléromètre
      • Capteur d'empreintes digitales
      • Capteur Gyro, Capteur Geomagnétique
      • Capteur à effet Hall
      • Capteur HR
      • Capteur de luminosité
      • Capteur de proximité
  • Android 6.0 (utilisation de Android Studio et la SDK Android 6.0 maximum)

* Clément

  • Samsung Galaxy S5 Mini
  • Caractéristiques techniques
    • Capteurs disponibles :
      • Accéléromètre
      • Capteur d'empreintes digitales
      • Capteur Gyro, Capteur Geomagnétique
      • Capteur à effet Hall
      • Capteur HR
      • Capteur de luminosité
      • Capteur de proximité
  • Android 5.1 (utilisation de Android Studio et la SDK Android 5.1 maximum)

Environnement logiciel

Android Studio

Activité reconnue

Notre application reconnaît une activité : le niveau sonore dans une zone géographique avec une dimension temporelle donc avec plusieurs résultats selon l’heure (jour ou nuit) et selon le jour de la semaine.

Mise à jour suite à l'évaluation intermédiaire : Comme précisé plus haut, nous avons enlevé le filtre jour/nuit et nous avons rajouté 2 filtres qui permettent de reconnaitre plus précisément l'activité en incluant un contexte dépendant de l'utilisateur : intérieur/extérieur et repos/activité.

Capteur et données

Dans le projet nous récoltons 3 types de données différents :

  • L'amplitude sonore grâce au microphone du smartphone
  • Les coordonnées GPS avec L'API google
  • L'heure où sont enregistré les données

API

Puisque nos deux téléphones on tous les deux minimums la version 5.1 d'Android, nous allons développer avec la SDK 5.0 afin de toucher un maximum de téléphone sur le marché. Pour les données GPS, nous utiliserons l'API google.

Algorithmes mis en œuvre

Pour traiter les données récoltées par notre application, nous voulons utiliser deux types d’algorithmes. Le clustering (non supervisé) nous permettra de regrouper en clusters chaque échantillon récolté avec son amplitude sonore (en décibel) et sa position GPS. Nous utiliserons plusieurs fois l’algorithme sur les différentes périodes de la semaine pour avoir une dimension temporelle. Pour le deuxième algorithme, nous ne sommes pas encore sûrs que ce sera possible mais nous aimerions utilise un algorithme SVM (supervisé) pour effectuer des prévisions futures sur la pollution sonore (par exemple pour connaître les endroits calmes le samedi)

Mise à jour suite à l'évaluation intermédiaire : Nous avons affiné l'utilisation des clusters en y ajoutant les “filtres” évoqués plus haut. Nous avons renoncé à mettre en place le deuxième algorithme SVM pour plusieurs raisons : manque de temps, utilité restreinte, très compliqué à mettre en place (nous avons de grosses difficultés de compréhension sans parler de l'implémentation).

Faisabilité

Nous avons choisi de développer en natif Android car nous allons utiliser plusieurs fonctionnalités natives et très peu d'affichage qui pourraient être mis en commun sur une application cross-platform comme Xamarin.

De plus, programmer en natif nous donnera accès plus facilement à tous les capteurs. Nous utiliserons le SDK 5.0 pour pouvoir utiliser l’application sur nos deux smartphones et toucher un maximum de smartphone sur le marché. Nous pourrons donc facilement utiliser et avoir accès au GPS, au microphone et à l'heure. Nous pourrons aussi utiliser des services Android (en arrière-plan) pour récolter des données périodiquement pendant toute la journée.

Puisque nous voulons rassembler les données de tous les smartphones qui utilisent notre application pour mettre en commun leurs données, nous allons utiliser un serveur externe et mettre en place une communication par Internet (peut-être avec des services Web)

Mise à jour suite à l'évaluation intermédiaire : Notre application marche bien sur nos deux téléphones. Nous utilisons un serveur Java avec service web rest. Nous utilisons serviceMix pour déployer notre serveur avec pour l'instant une utilisation dans un réseau local uniquement.

Le Rendu (code + doc)

Le code est disponible en intégralité ici : rendu-application-mobile.zip

ou sur github : https://github.com/alchimiste3/Rendu-Application-Mobile.git

cours/plim/projet16_17/gr10/gr10.txt · Dernière modification: 2017/02/19 19:59 par qlaborde