SmartCampus/FicheSuivi

De fablab
Aller à : navigation, rechercher

Introduction

Présentation du sujet et objectifs

L'objectif de ce projet de spécialité "SmartCampus" est d'implémenter de nouvelles fonctionnalités au projet original de SmartCampus, consultable via le lien suivant : http://air.imag.fr/index.php/SmartCampus2014. Pour rappeler brièvement de quoi il s'agit, ce projet s'articule autour de l'interaction des étudiants avec leur campus. Plus précisément, il s'agit d'offrir aux étudiants une base de données conséquente et dynamique - ainsi que de quoi y accéder intuitivement - pour qu'ils puissent bénéficier de diverses informations (telles que le temps d'attente à un restaurant universitaire) en temps réel.

Le produit soumis par l'équipe précédente est une implémentation de ce modèle sur une maquette représentant le campus ainsi que sur une interface web utilisant une carte interactive. Notre objectif principal est donc de réutiliser toutes les informations déjà collectées afin de fournir une interface en temps réel sur smartphones et tablettes utilisant le principe de la réalité augmentée.

Equipe en charge du projet

L'équipe chargée de la réalisation de ce projet est composée par les membres suivants :

  • Thomas BERTAULD
  • Cédric BIANCHERI
  • Michael LAFRASSE
  • Arthur SONG

Elle sera encadrée par messieurs Vivien QUEMA et Didier DONSEZ.

Vous pouvez nous contacter en utilisant l'adresse mail suivante : smartcampus.ensimag@gmail.com

Cahier des charges

Notre projet s'articule autour de deux axes majeurs :

  • La mise en place d'une application Android de réalité augmentée.
  • L'implémentation d'un plug-in pour le projet collaboratif OpenHAB (Mise à jour : En fait, il s'agit plutôt d'intégrer des flux vidéo à notre application, la création d'un module dédié sur OpenHab étant un moyen particulier d'atteindre cet objectif).

Nous détaillons dans les sections suivantes les différentes attentes attenantes à ces deux objectifs.

Application Android de réalité augmentée

Objectif

Le but de l'application à réaliser est de permettre à tout étudiant du campus disposant d'un smartphone de pouvoir, à l'aide de ce smartphone (ou tablette), accéder à toutes les informations utiles liées à son environnement via la réalité augmentée. En d'autres termes, on doit pouvoir, en utilisant la caméra du téléphone, cibler un bâtiment voisin et obtenir les informations liées audit bâtiment (pour peu que le bâtiment en question ait des informations à partager). Par exemple, on pourra cibler l'un des restaurants universitaires du campus et afficher en temps réel le temps d'attente moyen ou encore les menus du jour.

Contraintes

Avant de commencer la réalisation de notre application, nous avons beaucoup discuté avec notre encadrant afin de cerner les contraintes auxquelles nous devrons faire face. Finalement, la seule réelle contrainte qui s'impose à nous est que nous devons reprendre un projet existant et utiliser le plus possible les produits déjà fournis par la précédente équipe. En particulier, nous devons réutiliser au maximum la base de données déjà mise en place, ce qui impose évidemment d'en comprendre la structure et de la prendre en main.

Nous listons ci-dessous la liste des contraintes matérielles et logicielles qui découlent en partie du constat précédent :

  • L'application doit tourner sur des smartphones et des tablettes.
  • Elle ne doit donc pas être gourmande en mémoire.
  • Elle doit nécessiter le moins de calcul possible pour l'utilisateur.
  • Elle ne doit pas être dépendante d'un modèle particulier (tout smartphone devrait pouvoir utiliser l'application à 100%).
  • Elle utilisera les technologies de géolocalisation présentes sur ce type d'appareils : GPS, magnétomètre...
  • Elle gérera correctement la caméra et ses mouvements.
  • En complément des données collectées par l'appareil, on utilisera de la reconnaissance d'images (archivées dans une base d'images sur une plate-forme cloud).
  • La base de données utilisée par l'application doit pouvoir combiner des données "brutes", présentes en permanence, ainsi que des données fournies "à la volée" via le crowd sourcing.
  • Les accès aux données doivent être transparents pour l'utilisateur.
  • L'interface utilisateur doit respecter plusieurs critères.
  • Elle doit être la plus intuitive possible pour permettre à chaque utilisateur d'exploiter les fonctionnalités essentielles de l'application.
  • Par ailleurs, elle devra fournir une interface de debug qui pourra, par exemple, être utile à un utilisateur souhaitant modifier les sources du projet.
  • La base de données fournie devra être complétée avec différents flux : twitter, facebook, instagram...
  • En plus de l'interface "classique" de réalité augmentée, notre application devra proposer une interface présentant une carte du campus et permettant de sélectionner "à la main" les infrastructures dont on souhaite récupérer les informations.

L'intégration d'un module openHAB

Objectifs

OpenHAB est un projet collaboratif qui a pour but de fournir une interface web permettant, à tout un chacun, de contrôler différents appareils de domotique afin de créer un habitat intelligent. Pour plus d'informations, on pourra visiter le site officiel d'OpenHAB : http://www.openhab.org/.

L'architecture d'OpenHAB est basée sur le modèle OSGi. Ainsi, elle est schématiquement composée d'un "noyau dur" correspondant au système principal et de "bundles" qui gravitent autour de ce système en lui proposant différents services (à travers des interfaces appelées "contrats") qu'il peut utiliser à loisir. L'ensemble communique via un bus d'évènements.

Ainsi, notre objectif est de créer un nouveau "bundle" capable de contrôler, via l'interface d'OpenHAB, une caméra IP. Notre implémentation se basera dans un premier temps sur une caméra DLink. En particulier, on devra être capables d'intégrer les flux live des caméras vidéos dans les interfaces OpenHAB et dans l’interface SmartCampus. En effet, ces caméras viendront compléter la maquette précédemment créée pour améliorer la démonstration du projet.

Mise à jour : Après revu des demandes du client, nous nous sommes finalement aperçus que la création d'un bundle OpenHAB n'est qu'un moyen de parvenir à intégrer des flux vidéo à notre application. Nous donnons tout de même le cahier des charges associés à la réalisation du module OpenHAB.

Contraintes

Comme nous l'avons expliqué précédemment, openHAB est un projet OpenSource collaboratif et dont la communauté est très active. Ainsi, la contrainte principale de cet incrément est de s'intégrer à cette communauté et de respecter toutes les contraintes d'architecture et de conception imposées par l'architecture globale du système (basée sur le modèle OSGi) et les exigences de ses concepteurs (respect de la licence EPL, coding style etc...). Il faut donc bien comprendre le fonctionnement du projet et le prendre en main pour pouvoir y contribuer correctement. La liste ci-dessous représente l'ensemble des contraintes relevées jusqu'à présent :

  • Contraintes de fonctionnalités :
  • Le module doit permettre la reconnaissance automatique de toutes les caméras IP présentent sur le réseau (via UPnP).
  • Le module doit pouvoir contrôler à distance des caméras IP.
  • En particulier, on doit pouvoir les allumer, les éteindre et récupérer le flux vidéo "à la volée".
  • Si l'orientation des caméras est contrôlable de manière mécanique (i.e les caméras possèdent un moteur), on devra pouvoir choisir leur orientation via ce module.
  • Comme tous les modules OpenHAB, il doit être très facile d'utilisation et ne pas nécessiter de paramétrages à outrance.
  • Contraintes d'architecture et d'implémentation :
  • On devra se conformer à la licence EPL (Eclipse Public License).
  • Le module devra se fondre dans l'architecture d'OpenHAB.
  • En particulier, il devra être conforme aux attentes de la spécification OSGi, c'est-à-dire qu'il sera vu comme un "bundle" au sens OSGi.

Organisation

Pour ce projet, nous travaillons avec une approche de type agile : nous définissons une liste de tâches à effectuer et nous assignons à chacune d'entre elles une priorité. Nous parlons de type agile car, au gré de nos entretiens avec notre encadrant, de nouvelles tâches apparaissent et nous sommes amenés à revoir nos priorités (voir nos objectifs). Nous avons cependant distingué deux listes de tâches distinctes : la première concernant l'application android de réalité augmentée et la seconde l'intégration du module OpenHAB de gestion de la caméra ip.

Mise à jour : Comme nous l'avons déjà précisé, l'intégration d'un module de contrôle des caméras IP à OpenHAB n'est qu'un moyen d'intégrer des flux vidéos à notre application. Cependant, la réalisation d'un bundle pour cette interface peut bel et bien se faire de façon tout à fait indépendante de l'application dans un premier temps. C'est d'ailleurs la tactique que nous avons adopté en premier lieu.

En ce qui concerne les méthodes de communication, nous faisons chaque jours au minimum trois petites réunions de mise au point et nous rencontrons notre encadrant de façon régulière afin qu'il puisse nous aider à nous concentrer sur les parties critiques du projet. Nous sommes également en relation avec de nombreuses personnes dont les connaissances nous sont précieuses pour avancer plus sereinement.

Journal de bord

Du 26/05/2014 au 28/05/2014

Les premiers jours du projet ont été consacrés à la prise en main dudit projet. Il s'agissait essentiellement d'évaluer le travail demandé, de prendre en main les réalisations de l'équipe précédente et de lever le voile sur de nombreuses zones d'ombres. En effet, si l'objectif du projet est très clair, les moyens à employer pour le mettre en œuvre l'étaient beaucoup moins.

Pour commencer, nous avons commencé à nous documenter sur OpenHAB et ses principaux objectifs. Par ailleurs, nous avons pu discuter avec deux étudiants actuellement en stage au labo, et avec lesquels nous avons pu apprendre de nombreuses choses concernant OpenHAB ainsi que le protocole MQTT.

Par ailleurs, afin de commencer l'application android, il a été nécessaire de mettre en place un premier cahier des charges (qui sera mis à jour au fur et à mesure de l'évolution du projet) et de définir les technologies à employer. Ce point a été très important car très problématique. En effet, nous avons dû nous atteler à la compréhension du code précédemment fourni pour voir ce qui aurait pu nous resservir. Il est ressorti de notre première analyse que nous ne connaissions aucun des langages ou technologies employés. Nous nous sommes donc naturellement documenté sur ces technologies et notamment sur le protocole MQTT, l'architecture REST, le Node.js, le javascript et le python. Nous ne savions pas, à ce moment, ce que nous devions réutiliser. Finalement, nous avons opté pour le développement d'une application android "native", donc écrite en java (voir la partie conception).

Du 29/05/2014 au 01/06/2014

Durant ce week-end prolongé, nous avons donc commencé à expérimenter la programmation sur android. Il s'agissait dans un premier temps d'installer correctement le SDK puis de rechercher les moyens d'accéder aux différents capteurs de l'appareil, le but final de l'application étant d'offrir une vue en réalité augmentée. Ainsi, il a été nécessaire de se familiariser avec la gestion des éléments suivants :

  • La caméra.
  • Le GPS.
  • Le magnétomètre.
  • L'accéléromètre.

Les premières mesures récupérées à l'aide de ces capteurs nous ont permis de constater leur faible précision et donc la nécessité de moduler les données obtenues.

Par ailleurs, des recherches ont été effectuées sur les manipulations possibles sur la caméra DLink DCS 5222-L (modèle de référence). Nous avons ainsi pu tester l'envoie de différentes requêtes sur la caméra via un navigateur internet.

Le 02/06/2014

Nous avons mis en commun nos avancées du week-end et nous avons notamment pu comparer l'efficacité de nos différentes applications utilisant la caméra. Nous avons ensuite continué à chercher à améliorer notre gestion des capteurs du téléphone. Parallèlement, nous avons réfléchi à la façon dont nous allions stocker les différents points d'intérêts à afficher sur l'interface.

De plus, nous avons commencé à nous pencher sur le développement d'un second module, utilisant l'API Google Maps afin de pouvoir afficher les mêmes types de données que sur notre application de réalité augmentée mais sur une carte "classique".

Enfin, afin de mieux comprendre le fonctionnement concret d'OpenHAB, nous nous sommes documentés sur la spécification OSGi et sur les moyens de l'utiliser. Nous avons également posé quelques questions aux principaux contributeurs du projet, sans grand succès.

Le 03/06/2014

Une première version de l'application utilisant d'une façon plus poussée les capteurs était disponible. Celle-ci consistait en un repérage de la BU à l'aide de ses coordonnées GPS et de l'angle de vue de la caméra. Seules des informations de debug étaient affichées à l'écran. Un gros travail a d'ailleurs été effectué afin de trouver les paramètres optimaux pour la gestion de l'angle de vue de la caméra. En effet, tous les téléphones ne disposent pas du même angle de vue et il a donc été nécessaire de trouver un compromis. Afin de rendre cette application intéressante et la plus fiable possible, nous avons regardé plus en profondeur les propriétés du GPS ainsi que différents algorithmes permettant de calculer l'orientation du téléphone par rapport au Nord ou encore l'angle compris entre le Nord et deux coordonnées GPS.

Les points affichés (ici, la BU) sont stockés par l'application sous la forme de POI (Point Of Interest) actuellement codés en dur. L'obtention de ces points par un serveur via une base de données fera l'objet des futures expérimentations.

Par ailleurs, des tests ont été faits pour intégrer des infobulles à notre application.

Le 04/06/2014

L'objectif principal de la journée était de rendre l'application plus "user-friendly". Nous voulions en particulier rendre notre système d'info-bulles complètement fonctionnel. En effet au début de la journée, celles-ci restaient fixes sur l'écran et n'était pas reliées à un POI particulier. Nous avons donc passé une bonne partie de la journée à lier les infos-bulles aux dits POI afin qu'elles n'apparaissent à l'écran que si les infrastructures cibles sont dans le champ de vision de la caméra.

De plus, nous avons réalisé l'intégration du second module de visualisation par carte au module de réalité augmentée. Il est désormais possible de passer d'une interface à l'autre en utilisant un menu contextuel.

Parallèlement à cela, nous avons reconstruit une partie du code afin de mieux gérer des ensembles de POI pour pouvoir plus facilement les modifier (en ajouter, en supprimer etc...). En particulier, l'intérêt principal était de rendre beaucoup plus aisée l'intégration de la future base de données à notre application : il suffira qu'un serveur se connecte à celle-ci pour nous renvoyer l'ensemble des POI nécessaires.

Le 05/06/2014

La réalisation de la partie serveur de notre application se faisant de plus en plus urgente, une partie de l'équipe a commencé à s'y dédier. L'enjeu de ce serveur est qu'il doit effectuer le plus de calculs possibles afin de délester au maximum le téléphone ou la tablette client. Nous avons donc regardé du côté des APIs java permettant d'implémenter un serveur utilisant l'architecture REST. Les échanges entre le client et le serveur se feront par le protocole HTTP et l'utilisation de l'architecture REST semble toute indiquée.

Pendant ce temps, une autre partie de l'équipe s'est consacrée à l'amélioration de la géolocalisation ainsi qu'au placement des infobulles. L'affichage est désormais moins sensible aux variations des capteurs et les infobulles semblent être correctement ancrées à leurs POI. Cependant, d'autres problèmes se sont posés tels que la superposition de certains info-bulles dont les POI sont trop rapprochés. Il faudra donc consacrer une partie de notre temps à la gestion de différentes "couches" d'infobulles.

Enfin, une première application java a été créée, permettant des contrôles basiques sur la caméra DLink DCS-5222L. Grâce à cette application, il est possible d'orienter la caméra comme on le souhaite, de configurer certains capteurs et d'accéder à toutes les données de configurations de la caméra (en mode root).

Le 06/06/2014

Nous avons entamé de manière concrète la réalisation de la partie serveur : nous utiliserons une application web java tournant sur un serveur Apache tomcat. Cette application doit permettre d'accéder à n'importe quelle donnée de la base par le biais de simples requêtes HTTP (architecture REST). On a donc une batterie de classes java dédiées à interagir avec la base de données et une servlet traitant les requêtes HTTP. Cette servlet se charge de renvoyer les données demandées sous forme de JSON.

Par ailleurs, nous avons testé notre application sur tablette et il semble qu'il ne soit pas possible (pour le moment) de gérer correctement la rotation de l'appareil (contrairement à ce que l'on est capables de faire avec les smartphones). De plus, même si nous avons commencé à gérer la rotation des infobulles en fonction de l'inclinaison de l'appareil, seule la partie "graphique" de l'application tourne. En d'autres termes, même si les infobulles semblent graphiquement bien répondre à l'inclinaison de l'appareil, les surfaces cliquables sous-jacentes ne pivotent pas, ce qui créé des incohérences dans l'application.

Du 07/06/2014 au 09/06/2014

Durant ce week-end prolongé, nous avons principalement travaillé à l'amélioration du code produit (rédaction de javadoc manquante, amélioration de performances...). Par ailleurs, nous avons apporté quelques modifications à l'interface graphique afin de la rendre plus agréable. En particulier, nous avons implémenté une méthode permettant aux différentes infobulles de ne pas se chevaucher lorsqu'elles désignent deux endroits distincts mais géographiquement proches.

Nous avons également géré l'affichage des informations liées à une infobulle lors d'un clique (on ouvre alors une nouvelle page contenant lesdites informations).

En parallèle, nous avons continué notre travail documentaire sur la spécification OSGi : après avoir lu de nombreux tutoriels, nous avons commencé à implémenter de petits programmes pour nous entraîner.

Enfin, nous avons continué l'implémentation de la partie serveur de notre application et notamment la gestion des accès à la base de données et du JSON.

Le 10/06/2014

En premier lieu, nous avons effectué une refonte du serveur : ré-agencement du code en packages cohérents, amélioration de la stabilité et du contrôle et implémentation des dernières fonctionnalités manquantes.

Par ailleurs, les rotations ont été améliorées, elles sont désormais plus fluides et plus "réalistes" mais le problème de la surface cliquable (voir note du 06/06/2014) persiste. De plus, nous nous sommes aperçus que la rotation graphique des boutons ne fonctionne pas sur les versions d'android antérieures à la 4.3 du à l'absence de la méthode "setClipBound()".

Enfin, nous avons implémenté la partie client (donc sur smartphone) dédiée à la communication avec le serveur nouvellement créé. Conformément à l'architecture REST, le client se contente d'envoyer des requêtes HTTP GET contenant les paramètres désignant les informations à récupérer, puis le serveur traite la requête et renvoie (sous forme de JSON) les informations demandées.

Le 11/06/2014

Nous avons continué à améliorer le code de diverses façons. Nous avons également commencé à compléter l'API du serveur en ajoutant des méthodes permettant de poster des données dans la base de données. Par ailleurs, nous nous sommes intéressés à la gestion de différentes couleurs pour les infobulles en fonction du type de l'objet visé. Par exemple, les écoles apparaissent en rouge, les bars apparaissent en jaune etc...

De plus, après un point avec notre encadrant, il nous est apparu que la réalisation du module de contrôle d'une caméra via OpenHAB pouvait être mise de côté dans le sens où son but (outre le fait de contribuer à une communauté open source) était essentiellement de contrôler un flux vidéo via notre application. De toute façon, nous n'aurions pas eu le temps de mener à terme cette partie du projet car nous nous sommes heurtés à énormément de difficultés lors de nos différents essais d'intégration.

Le 12/06/2014

Lors de cette journée, nous avons continué notre amélioration de l'IHM en gérant plus finement le positionnement des infobulles ainsi qu'en implémentant un filtrage dynamique des objets à afficher. Par dynamique, on entend que l'on récupère uniquement les types que nous renvoi la BD. Rien n'est donc codé "en dur".

Par ailleurs, nous avons amélioré la stabilité du serveur et commencé un script d'initialisation de la base de données basé sur celui produit par l'équipe précédente, mais fonctionnant grâce à notre API.

Le 13/06/2014

Cette journée était un peu particulière car nous avons effectué une "pré-soutenance" avec notre encadrant, qui ne pourra pas être présent le jour de la soutenance finale.

Du 14/06/2014 au 15/06/2014

En vu de la soutenance du 17 juin, nous avons commencé à sérieusement améliorer la lisibilité de notre code en ajoutant les commentaires manquants, en en refactorant certaines parties... Nous avons également produit un ensemble de documentations sous forme de "README" permettant d'expliquer comment lancer et utiliser notre application.

Par ailleurs, nous avons pu testé l'intégration de flux vidéo à notre interface de manière basique (via une simple URL). En effet, nous avons dû abandonner la création du module OpenHAB par manque de temps, car nous avons eu fort à faire sur la partie application Android. En particulier, le responsable de la partie OpenHAB s'est occupé de la partie serveur de l'application.

Le 16/06/2014

Nous avons participé aux démonstrations Persyval à la MJK. Cela a été l'occasion de montrer notre application à un grand nombre de personnes et de récupérer leurs remarques et leurs avis. Globalement, le public semblait conquis par notre application. Ce fut une expérience très enrichissante et valorisante.

Problèmes rencontrés

Lors de la réalisation de notre projet, nous nous sommes heurtés à de nombreux problèmes dont voici une liste (non-exhaustive) :

  • Reprendre un code existant : il est souvent difficile de se plonger dans un code que l'on a pas écrit soit-même, et encore plus quand certaines parties manquent de documentations. Finalement, nous n'avons pas réutilisé une grande partie du code légué par l'équipe précédente, nous n'avons conservé que leur base de données et la partie de leur serveur servant à l'initialiser.
  • Certaines limitations liées au développement Android comme l'impossibilité de gérer correctement et uniformément (i.e sur toutes les versions), la rotation des infobulles.
  • L'intégration d'une multitude de technologies en un temps limité : nous avons pris en main de nouvelles technologies que nous ne maîtrisions pas, telles que le javaScript, le JSON, le noSQL etc... Et, même si prises séparément, elles ne représentent pas des obstacles insurmontables, il est parfois difficile de toutes les manier correctement et de manière harmonieuse.
  • Certains facteurs externes : en particulier le temps de réponse sur les forums dédiés à OpenHAB qui pouvait aller jusqu'à quelques jours. Compte-tenu de la courte durée du projet, de tels délais pouvaient vite devenir handicapant.
  • La difficulté à prioriser les tâches. On retiendra particulièrement notre mauvaise gestion du module OpenHAB : nous pensions, à l'origine, que cela devait faire l'objet d'un livrable à part entière alors qu'il ne s'agissait que d'un moyen d'intégrer plus proprement des flux vidéos à notre application. Finalement, nous n'avons pas eu le temps de finir ce module car nous avons dû revoir nos priorités à l'approche du rendu pour fournir l'application la plus robuste et performante possible.

Choix de conception

Nous présentons ci-dessous différents choix liés à notre conception ainsi qu'une brève vision du fonctionnement de notre application.

Technologies utilisées

Nous utilisons actuellement les technologies suivantes :

  • Android : pour le développement de notre application.
  • Java : pour le développement sur Android.
  • JavaScript : utilisé par l'API du serveur pour lancer certaines requêtes.
  • Node.Js : pour charger la BD sur le serveur.
  • JSON : pour formater l'ensemble de nos données.
  • L'architecture REST : pour structurer les échanges entre le client (l'application) et le serveur.
  • Apache tomcat : pour la réalisation concrète du serveur (en JAVA également).
  • mongoDB : qui est notre base de données noSQL.

Technologies envisagées mais abandonnées

Les technologies suivantes ont été étudiées mais n'ont finalement pas été utilisées :

  • PhoneGap : cette alternative à une application JAVA native semblait parfaite mais ne permettait pas une assez bonne gestion de la caméra et des capteurs du téléphone.
  • L'architecture OSGi : qui est utilisée par OpenHAB. Nous nous sommes beaucoup documenté sur cette technologie et avons effectué quelques tests. Cet apprentissage n'aura de toute façon pas été vain.
  • OpenHAB : à cause des trop nombreuses difficultés que nous avons expérimentés durant notre projet, nous avons été contraints de nous rabattre vers une gestion plus "classique" des flux vidéos de caméras IP.

Diagrammes de conception

Voici les principaux diagrammes de conception liés à notre application :

Fonctionnement principal de l'application

L’application Android fonctionne de manière assez simple. Dans un premier temps, elle commence par relever votre position GPS. Ensuite, elle interroge la base de données (via notre serveur), afin de récupérer l'ensemble des POI (Points Of Interest) se trouvant à proximité, à la suite de quoi des traitements de données sont effectués afin de placer convenablement les infobulles par rapport aux coordonnées de ces POI et de leur distance par rapport à l'utilisateur.

L'ensemble des échanges de données suit une architecture de type REST. En particulier, l'ensemble des informations est contenu dans les requêtes échangées. Par ailleurs, nous avons essayé de minimiser le nombre de calculs effectués du côté client en maximisant la prise en charge de ces calculs par le serveur.

En plus du GPS, nous utilisons le magnétomètre et l'accéléromètre de l'appareil afin de calculer les angles des prises de vues notamment et de fournir l'interface la plus précise possible en positionnant au mieux les infobulles.

Réalisations

Voici ci-dessous des screenshots de différentes versions de notre application.

Version debug

Version beta

Evolutions possibles

Comme nous l'avons déjà évoqué, les possibilités de cette application sont quasi-infinies. Nous avons notamment pu le constater lors de notre présentation à Persyval, lorsque chaque personne testant l'application lui imaginait déjà une nouvelle fonctionnalité. Nous donnons donc une liste infime de fonctionnalités pouvant être ajoutées dans le futur.

  • L'intégration des réseaux sociaux.
  • Commenter certains POI.
  • Gérer un système d'utilisateurs.
  • Ajouter des points par le biais de l'application.
  • Gérer la caméra frontale.
  • Mémoriser le chemin effectué par l'utilisateur.
  • Gérer les métriques.
  • Proposer un système de guidage.
  • Choisir la distance maximale des points à afficher.

...

Communication autour du projet

Flyer

Vidéo

La vidéo de présentation de notre application est disponible à l'adresse suivante : https://www.youtube.com/watch?v=dsqibd7xYqM&feature=youtu.be