Réalité augmentée au sein de l UM2. Guillaume Gauthier, Abdelssamad Hennani, Ken Izquierdo, Guillaume Mercier, Timotei Soto-Salinas

Transcription

1 Réalité augmentée au sein de l UM2 Guillaume Gauthier, Abdelssamad Hennani, Ken Izquierdo, Guillaume Mercier, Timotei Soto-Salinas 31 mai 2011

2 Table des matières 1 Introduction Présentation de la réalité augmentée Principe Histoire Domaines d application Vocabulaire Recherches Scénarios d utilisations Besoins Matériels Utilité des capteurs Étude de marché technique Plateformes mobiles Étude de marché Comparatif de l étude Choix de la plateforme Le système Android Architecture du système Philosophie Architecture des applications Kit de développement Avantages et inconvénients État de la réalité augmentée sur Android Les applications Librairies ou ressources open source Analyse Implémentation RData ARView et MapView ProviderAdapter et ses sous classes POIProvider et ses sous classes POIView et ses sous classes BD et TablesBDD Graphe, Dijkstra, Node et Edge ArrowOpenGL, ArrowRenderer et ArrowView Positionnement des informations à l écran Données sur l état du téléphone Positionnement des POIs par dessus les images de la caméra Dessin de segments entre deux positions GPS Positionnement des POIs sur la carte Dessin de segments sur la carte Point le plus proche d un bâtiment Acquisition et structuration des données

3 12.1 Acquisition des données Le format des données Mise en place de la base de données Premier chargement Service web Fonctionnement Évolution et réutisabilité Principales technologies utilisées SQLite GPS (Global Positioning System) OpenGL Tests et performances Tests Performances Problèmes rencontrés Problèmes sur les données La Base de données Données des capteurs Problèmes géométriques La programmation sous Android Apprentissage d OpenGL Organisation du groupe L équipe Logiciels utilisés Ressources Conclusion

4 1 Introduction La réalité augmentée est devenue un support aux multiples usages au cours de ces dernières années. Bien que ce concept existe depuis des dizaines d années, son développement a été permis grâce aux avancées technologiques et rendu accessible au grand public avec l évolution des téléphones mobiles. Dans ce rapport, nous exposeront les choix qui s offrent aux développeurs pour la création d application de réalité augmentée sur smartphone puis en justifiant le choix d une plateforme, nous exposeront une analyse du problème et une solution d implémentation d une application de réalité augmentée sur cette plateforme. 3

5 2 Présentation de la réalité augmentée La réalité augmentée désigne les systèmes informatiques qui rendent possible la superposition d un modèle virtuel 3D ou 2D à la perception que nous avons naturellement de la réalité et ceci en temps réel. Elle désigne les différentes méthodes qui permettent d incruster de façon réaliste des objets virtuels dans une séquence d images réelles. La réalité augmentée est une nouvelle technologie qui suscite de plus en plus d intérêts auprès des scientifiques comme du grand public. Sa capacité à enrichir le monde réel par l ajout d entités virtuelles lui offre un grand potentiel et ouvre ainsi les portes à de nouvelles applications. Depuis quelques années, de nombreux systèmes de réalité augmentée ont vu le jour en plaçant le spectateur au centre d une réalité mixte. L apparition des smartphones et de la haute technologie embarquée ont considérablement facilité le déploiement de la réalité augmentée dans notre quotidien. 2.1 Principe La réalité augmentée doit respecter trois règles fondamentales : la combinaison d images réelles et virtuelles. le tout de manière dynamique (en temps réel). le respect de l homogénéité de la perspective (Positionnement à l échelle). 2.2 Histoire Le concept de la réalité augmentée a vu le jour dans les années 60 et a été utilisé dès les années 80, c était alors un outil utilisé par les militaires dans ce qu on appelle les "Head-Up Display" (dispositif de réalité augmentée implémenté sur les casques des pilotes d avions) ou encore dans les tableaux de bord des avions de combat qui affichaient des informations en temps réel posées sur l image du monde réel. Ce concept fut aussi utilisé dans les années 90 dans le domaine médical par les chercheurs Bajura et State qui furent parmi les pionniers de la réalité augmentée. Ils permettaient de pouvoir visualiser directement des données d imagerie à ultrasons sur le corps du patient pour mieux comprendre les pathologies. Les médecins pouvaient superposer les examens tels que les radios ou les scanners avec le patient lui-même. 4

6 La réalité augmentée a vu le jour avec les travaux de Ivan Sutherland qui a réalisé le premier système appelé "réalité augmentée" basé sur un casque suivi par un capteur de mouvement. Avec ce dispositif, l utilisateur pouvait visualiser et naviguer autour d éléments virtuels positionnés dans notre espace réel. Aujourd hui le concept s est assez répandu avec la diffusion d outils tel que ARToolkit qui est un logiciel open source qui a facilité le développement de nouvelles applications de réalité augmentée dans divers langages. 2.3 Domaines d application De nos jours on peut constater que la réalité augmentée est en plein essor, on la retrouve dans plusieurs domaines tel que la publicité (panneau publicitaire par exemple), l industrie automobile où elle est utilisée pour la représentation 3D de prototype de voiture n existant que sur ordinateur. Elle est aussi utilisée dans les domaines du E-commerce où elle aide à la prise de décision dans l acte d achat ou encore dans le domaine de l immobilier, elle permet de visualiser des informations sur un appartement à louer. Elle est aussi utilisée dans des musées, tel que celui des Beau-Arts à Rennes où elle fait office de guide de musée. Ce cadre d utilisation de la réalité augmentée est le but du Projet GAMME. Il s agit d un projet collaboratif financé par l ANR, labellisé par le pôle de compétitivité Images & Réseaux et piloté par OrangeLabs. Les autres partenaires de ce projet sont l INRIA, le CEA leti, MOV EA, P OLY MORP H Software et la ville de Rennes (Musée des Beaux-Arts). On retrouve aussi la réalité augmentée dans le domaine de l environnement et du tourisme afin de permettre aux visiteurs d avoir des informations sur le lieu qu ils visitent. 2.4 Vocabulaire Dans ce rapport, dans l objectif de faciliter nos explications, nous allons utiliser les acronymes suivant : RA : réalité augmentée POI : de l Anglais Point Of Interest, c est un endroit présentant un intérêt et dans un contexte de réalité augmentée ce sont les informations qui sont affichées à l utilisateur 2.5 Recherches Au début de ce TER, nous avons lu quelques articles de recherche sur la réalité augmentée. Cela nous a parmi de comprendre à quel point se domaine était vaste sans pour autant nous fournir de solution pour notre démarche. En effet, les articles que nous avons pu trouver sont trop anciens et ne sont plus en phase avec les technologies actuelles. Cependant, des articles assez récent (années 2000) présente les premiers prototypes de ce concept, à l époque le problème de la géolocalisation précise était le principal frein à la sortie des laboratoires. Reéalitée augmentée - Principes, technologies et applications (2005) Dans cet article, David Roussel et Malik Mallem présentent en profondeur le concept de réalité augmentée sans se quantonner à l augmentation visuelle. [...] la réalité augmentée permet la perception d indices dans l environnement (vue par transparence d un objet modélisé par exemple) que l utilisateur ne pourrait pas percevoir 5

7 avec ses propres sens, d où le terme d augmentation. Cette assistance permet alors à l utilisateur de réaliser des tâches complexes qu il ne pourrait mener à bien autrement. Ils passent également en revue les différents dispositifs d affichage (Notons que l article a été écrit en 2005 et que les smartphones de l époque n étaient pas aussi puissants et complets qu à ce jour). Ils en énumèrent trois types : Headworm : Ce sont des dispositifs de type casque ou lunette portés par l utilisateur. On peut distinguer également ceux qui apportent une vision directe (optical see-throught), dans laquelle l utilisateur perçoit le monde réel à travers un dispositif optique dans lequel sont projetées les images virtuelles destinées à l augmentation ; et ceux qui apportent une vision indirecte (video see-throught), dans laquelle le monde réel est perçu grâce à une ou plusieurs caméras disposées sur le casque ou les lunettes. Handheld : Ce sont des dispositifs portés par l utilisateur de type tablet pc, assistant personnel et également téléphone cellulaire. Projective : Dispositifs qui utilisent des projecteurs destinés à augmenter les objets réels par projection directe d informations supplémentaires sur les objets eux-mêmes. A l époque de la publication de l article, le dispositif Headworm est le plus répandu. De nombreux problèmes existent néanmoins, notamment concernant le champ de vision limité de ce dispositif. Source : http :// An Annotated Situation-Awareness Aid for Augmented Reality de Blaine Bell, To-bias Höllerer et Steven Feiner (2002) Les auteurs de cet article présentent une solution d affichage des informations en réalité augmentée. Ils se basent sur plusieurs recherches déjà effectuées et arrivent à afficher des anotations sur l environnement courant (leur laboratoire). Ils représentent également en trois dimensions la pièce sur un plan affiché en réalité augmentée, ce plan est positionné à l horizontal ainsi quand l utilisateur se penche en avant cela effectue un zoom comme si l utilisateur se penchait sur une maquette. Ils ont utilisé une technique de "head-tracking" pour positionner l utilisateur et son regard dans la pièce. Source : http ://www1.cs.columbia.edu/graphics/publications/uist02.pdf Réalité Augmentée en extérieur : Enjeux et État de l Art (2007) Cet article dresse un large état des travaux menés dans cette discipline, notamment sur les aspects méthodologiques (techniques de localisation, génération de modèles 3D, visualisation et interaction), technologiques (capteurs, dispositifs de visualisation et logiciels) et industriels (projets et travaux). Dans les applications de réalité augmentée, la connaissance de la position et de l orientation du point de vue de la caméra (ou pose de la caméra) est primordiale, car elle permet d assurer la cohérence spatio-temporelle de la scène augmentée. Les techniques proposées en informatiques graphiques nécessitent des adaptations pour prendre en considérations les caractéristiques des terminaux mobiles (capacités limitées de traitement et de stockage). La réalité augmentée en extérieur présente de nombreux enjeux que ce soient sur le plan technologique (capteurs, terminaux mobiles, etc.), méthodologique (techniques de localisation 3D, génération d environnement 3D, visualisation et interaction 3D) ou industriel. La mise en œuvre de tels systèmes nécessite la résolutions des problématiques scientifiques spécifiques à la RA mobile, à savoir la localisation, la visualisation et l interaction 3D. Source : http ://artis.imag.fr/publications/2004/gra04/these.pdf 6

8 3 Scénarios d utilisations Voici quelques scénarios d utilisation permettant d illustrer l utilité d une application de réalité augmentée au sein de l UM2. Journée portes ouvertes Il est acquis que les journées portes ouvertes de la faculté des sciences sont l occasion pour les futurs étudiants de découvrir les nombreuses infrastructures de l université. Souvent, ceux-ci ne trouvent pas ce qu ils cherchent dû au nombre important de bâtiments, ou passent à coté de stands qui auraient pû les intéresser. On pourrait suggérer aux visiteurs de télécharger une application en arrivant sur le campus, celle-ci leur permettrait de se localiser et de se diriger intuitivement vers les différents stands de présentation, lieux-clefs de l Université, et d avoir accès à la liste exhaustive des différents stands disponibles, dans le but de faciliter leurs premiers pas à l UM2. Examen Ce scénario commence lors de la période des examens, période durant laquelle tous les élèves sont extrêmement stressés. Il leur est aussi assez difficile de repérer un bâtiment (Amphithéâtre) dans lequel se déroulera leur examen, s ils ne connaissent pas l amphithéâtre en question, ou qu ils n ont pas l habitude de le fréquenter, il leur est très facile de se tromper. Grâce à une application sur leur smartphone, ils pourraient éviter de perdre du temps en se trompant et pourront ainsi arriver à la bonne salle à l heure et se mettre en condition pour préparer leur examen. Rentrée scolaire Lors de la rentrée scolaire, les nouveaux arrivants au sein de l UM2 ont souvent du mal à s orienter vers un bâtiment ou une salle où ils ont cours, ce qui peut engendrer des retards. Afin d éviter cela, il serait judicieux lors des inscriptions scolaires de proposer aux nouveaux élèves de télécharger une application afin qu ils puissent l utiliser le jour de la rentrée et ainsi se familiariser avec l université et tous ses édifices. Salle de TP Il est très désagréable pour les chargés de TP d avoir des élèves qui viennent perturber leur séance, lorsque ces derniers désirent effectuer des travaux sur machines. Grâce à une application, qui récupèrerai les informations sur la disponibilité des salles de TP, il leur serait possible de voir les salles libres et d éviter de perturber les cours qui ont lieu dans les salles occupées. Événementiel Il arrive très souvent que des événements se passent à la faculté des sciences. Ces événements sont organisés par des étudiants ou par le personnel interne de la faculté (conférence, présentation, séminaire). Il faut donc informer tout le monde du lieu et de la date de cet événement. Actuellement le seul moyen de communication utilisé est le mail, mais il n est pas forcément facile de situer l endroit indiqué dans ce mail. Avec la réalité augmentée, il sera très facile pour les étudiants de prendre connaissance de ces événements et de se diriger vers ceux-ci. 7

9 4 Besoins Matériels Afin de donner l illusion que des objets virtuels appartiennent à la réalité, il est nécessaire de bien les placer, bien les orienter et de respecter des facteurs d échelle par rapport aux objets réellement filmés. Pour cela, il est nécessaire de connaitre la position de la caméra et son champs de vision. Le problème de la localisation de la caméra est donc important. Voici le minimum requis pour faire de la réalité augmentée : un système de repérage géographique une boussole des capteurs d orientations une caméra pour les images de fond 4.1 Utilité des capteurs Il est nécessaire de repérer avec précision, la position de l appareil, car c est sur celle-ci que seront basés les calculs de positionnements (cf rubrique positionnement page 30). Ensuite, il nous faut déterminer quels sont les éléments qui se trouve en face du dispositif. Pour cela il nous faut connaître quel est le champs de vision couvert par le dispositif en fonction des angles d inclinaison de celui-ci. Pour répondre à ces besoins, il existe des outils équipés de tous les capteurs nécessaires, c est le cas de certains smartphones ou tablettes. Pour la géolocalisation c est derniers sont équipés de puces GPS assez sophistiquées qui permettent d obtenir des données de positionnements (longitude, latitude) assez précises. Il sont aussi, pour les plus récents équipés de capteurs magnétiques pour calculer l orientation par rapport au nord du téléphone ce qui nous permet ensuite grâce à quelques traitements de déterminer les éléments qui sont en face de celui-ci. Bien sûr, il nous reste à déterminer l inclinaison du téléphone (pour situer l axe de vue de la camera) pour cela des capteurs tel que l accéléromètre ou le gyroscope font très bien l affaire. Pour résumer, de tels smartphones peuvent être situés dans l espace et nous pouvons également connaître son orientation par rapport au nord et l horizontal. Nous pouvons donc savoir dans quelle direction ils filment et ainsi savoir si un élément situé dans l espace est filmé. 8

10 5 Étude de marché technique Pour faire le choix d une plateforme de développement de façon éclairé, nous avons commencé par identifier les différentes plateformes mobiles existantes actuellement. Nous avons ensuite recherché les informations essentielles concernant le développement sur ces plateformes puis avons étudier leurs parts de marché respectives. 5.1 Plateformes mobiles iphone OS Sources http :// http ://fr.wikipedia.org Depuis la sortie de l iphone 3G, des millions de téléphones ont été vendus de par le monde. Apple s est fait le précurseur de la distribution d applications pour ses téléphones et est un des acteurs majeurs de la banalisation de celles-ci (grâce à l App Store qui a permis de centraliser les centaines de milliers d applications existantes). Cependant, la publication d une application pour iphone est soumise à la validation d Apple ainsi qu à un passage obligé au portefeuille (99 euros/an pour pouvoir publier des applications). Notons également que les fonctionnalités nécessaires pour une application basée sur la réalité augmentée ne sont pas présentes sur tous les modèles d iphone. La boussole a fait son apparition à partir de l iphone 3GS. De fait, une application de réalité augmentée ne pourra être utilisée uniquement par les détenteurs d iphone 3GS et versions supérieurs. Langage et SDK Depuis le 6 Mars 2008 Apple a mis a disposition le SDK permettant de développer des applications pour leurs smartphones. Le langage de programmation utilisé est l Objective-C. L environnement est Xcode. Parc Les appareils en circulation équipés de ce système d exploitation sont tous fabriqués par Apple. Ceux-ci comprennent des smartphones (gamme iphone) ainsi que des tablettes tactiles (gamme ipad) : ipad et ipad2 iphone EDGE/ORIGINAL, ce téléphone ne possède pas la technologie 3G. iphone 3G et iphone 3GS, ils sont tout deux des évolutions de la version précédente, cependant le 3G ne possède pas de boussole contrairement au 3GS. iphone 4, qui est enfin un iphone multitâche et très performant Android Sources http :// http ://fr.wikipedia.org http ://developer.android.com/ Android est un OS libre basé sur Linux, la société américaine du même nom a été rachetée par Google en Ce système s est fait connaître dans le monde des smartphones grâce au HTC Dream fin Ce système dispose d une plateforme d application appelée Android Market qui possède plus de applications faisant concurrence à l App Store d Apple (plateforme d ios). 9

11 Pour pouvoir publier son application sur le l Android Market, il faut simplement payer 25$ lors de l inscription en tant que développeur sur l Android Market. Tous les smartphones sous Android disposent d une puce GPS, d une boussole et d un accéléromètre. Remarque : Android ne fonctionne pas uniquement sur des smartphones. Langage et SDK le développement se fait en Java mais est possible en C/C++. le Kit de développement (Android SDK) est gratuit, multi-plateforme (Windows, Mac, Linux) et fourni également un émulateur. le projet Android nous offre également un Plugin ADT pour Eclipse pour l intégration avec l Android SDK Parc Une grande variété de téléphones est en circulation ainsi que quelques tablettes, conçus par différents constructeurs RIM OS Sources http :// http ://fr.wikipedia.org http :// RIM OS est le système d exploitation développé par la société canadienne Research In Motion (RIM) spécifiquement pour ses terminaux BlackBerry. Il s agit d un système multitâche très implanté aux États-Unis avec une part de marché équivalente à celle d Android et Apple. 11,2 millions de BlackBerry ont été écoulés dans le monde. Langage et SDK Nous avons aujourd hui à disposition, une version bêta de BlackBerry Widget Software Development Kit (SDK) qui est constitué du BlackBerry Widget Packager, d un Emulateur BlackBerry, d exemples et de documentation (l installation d une JDK est requise). Le BlackBerry Widget Packager permet donc de créer des interfaces riches, à base d HTML, CSS et Javascript. Cette boîte à outils permet de développer (en utilisant les technologies standards du Web) des applications de type Widget s exécutant dans le navigateur du BlackBerry. Tout comme Microsoft, Android et Apple, RIM veut attirer les développeurs sur sa plateforme. À notre disposition, deux kits de développement : l un pour l environnement Eclipse et l autre pour Microsoft Visual Studio. Le Kit de développement d Eclipse est baptisé BlackBerry Web Development Plug-in for Eclipse. Il vient de faire son apparition dans la palette des outils de développement pour les BlackBerry. Il permet de débugger et de profiler des pages Web en HTML/CSS/Javascript mais aussi d écrire des applicatifs dans des langages comme, Silverlight, PHP, ASP, Ruby, JSP et Python. On pourra le trouver sur cette page : http ://us.blackberry.com/developers/javaappdev/devtools.jsp Parc Il y a actuellement environ plus de 30 smartphones BlackBerry différents disponibles, ce qui fait tout de même une gamme de téléphones non négligeable sur le marché, cependant ils ne disposent pas tous des capteurs comme la boussole par exemple, ce qui réduit la gamme compatible avec la réalité augmentée. 10

12 5.1.4 OS Symbian Sources http :// http ://fr.wikipedia.org http :// Symbian OS est un système d exploitation pour smartphone et PDA conçu par Symbian ltd. Il est né d un consortium entre les différents constructeurs (initialement Psion, Nokia, Motorola, Ericsson et Matsushita/Panasonic). Le 16 novembre 2006, 100 millions de téléphones mobiles avaient été vendus avec cet OS. Il a été racheté à 100% par Nokia, alors que cette société n en détenait que 48% et que le reste était détenu par Sony Ericsson, Siemens, Samsung et Panasonic. À la suite de ce rachat Nokia a décidé de changer la licence de Symbian OS qui était Open Source depuis le 21 octobre Cette OS est multitâches. Langage et SDK Le langage de programmation de cet OS est le C++. Le SDK, l Application Developpement Toolkit et le Product Developpement Toolkit sont librement téléchargeable après inscription sur le site de la communauté de développeurs Symbian. L environnement de développement est CarbideC++ (basé sur Eclipse) Le kit de développement pour Symbian S60 en est à sa 5ème édition aujourd hui. Parc Dans cet OS se distingue plusieurs versions (voir ci dessus) mais aussi plusieurs séries (aussi appelées User Interface ou UI) afin de s adapter à différents appareils. Ces interfaces évoluant parallèlement à l OS, elles sont déclinées en versions ou éditions que voici : Série 60 ou S60, pour les mobiles destinés au grand public. S80, pour une clientèle plus professionnelle. S90, téléphones dont l interface est développée par Nokia (dotés d un large écran tactile 640x320 pixels). UIQ, avec utilisation d un stylet sur un large écran également. FOMA, interface proposée au Japon par NTT DoCoMo. Cet opérateur peut, grâce à un accord avec Symbian Ltd. disposer du code source de l OS et l implémenter dans ses téléphones avec sa technologie FOMA (3G). Il s agit donc de téléphones qu on ne catégorise dans aucunes des autres séries mais qui se rapprochent le plus de la S60 (pas d écran tactile). Inconvénient : les applications ne sont pas compatibles entre les différentes versions de l OS OS Windows Phone 7 Anciennement Windows Mobile, l OS Windows Phone 7 n est pas encore très répandu sur le marché du smartphone. Windows Mobile est le nom générique donné à différentes versions de Microsoft Windows conçues pour des appareils mobiles tels que les smartphones ou Pocket PC. Ces systèmes d exploitation permettent à des logiciels Microsoft tels que Microsoft Office ou Windows Live Messenger de fonctionner sur un téléphone. Plusieurs marques utilisent l OS Windows Mobile pour leur téléphone. Il y a cependant un problème de compatibilité des téléphones avec cet OS qui est peu être à l origine du manque d expansion que l on peut constater. Les fabricants doivent nécessairement proposer des téléphones avec 5 touches (dédiées à la navigation), un écran capacitif multitouch 4 points de 800x480 pixels, un processeur graphique avec accélération DirectX 9, un récepteur GPS, une boussole numérique, un détecteur de proximité, un appareil photo numérique, un récepteur radio FM et un accéléromètre. 11

13 En outre le téléphone doit posséder au moins 8 Go de mémoire Flash et 256 Mo de RAM. Ce qui en fait des téléphones tout de même assez performants. Mais tout cela réduit les possibilités d importation de cet OS dans des téléphones différents. Langage et SDK Le développement des applications sur l OS Windows Phone 7 se fera à partir de Silverlight pour les applications et XNA pour les jeux (tous deux battis sur le.net Compact Framework). Les principaux outils utilisés pour le développement sont Visual Studio 2010 et Expression Blend 4. Le développement est entièrement gratuit. Le passage obligé pour installer des applications sur son téléphone Windows Phone 7 est Windows Phone Marketplace, pour cela les applications devront être préalablement approuvées par Microsoft. Dernière version : 6.5. Les applications pour Windows Mobile sont réalisées avec Visual Studio et avec un SDK spécifique à la version du téléphone. On peut aussi utiliser WinDev Mobile pour développer des applications pour Windows Mobile (payant). Pour ce qui est des langages de script, une version de Tcl (Tool Command Language, basé sur C, Lisp, Shell et Awk) permet de développer directement des applications fenêtrées sous Windows Mobile. Le développement reste donc essentiellement gratuit. Parc Pour le moment seuls 3 constructeurs proposent des terminaux fonctionnant sous WP7 : LG, deux modèles pour le moment. Samsung, également deux modèles. HTC, avec 7 modèles. Néanmoins d autres fabricants devraient proposer des téléphones compatibles : Sony Ericsson, Dell et Asus Bada Sources wikipedia.org developer.bada.com Bada est un système propriétaire développé par Samsung. Il est utilisé uniquement pour les téléphones Samsung. C est un système basé sur Linux. Langage et SDK Le langage de programmation utilisé est le C++. Un SDK gratuit est à disposition, mais fonctionne sur Windows uniquement. On a également accès à un émulateur pour tester les applications. Ce système supporte le GPS, la boussole et l accéléromètre. Parc Un seul mobile en circulation, le Samsung Wave possédant boussole, GPS et accéléromètre. 12

14 5.1.7 Maemo Sources wikipedia.org wiki.maemo.org Le système est Open source (Nokia) basé sur linux. Langage et SDK Le langage utilisé est le C++ (GTK+/Qt) et il existe un SDK gratuit pour Linux. Ce SDK est virtualisable pour faire du développement sous Mac OS/Windows. Parc Un seul mobile connu en circulation, le Nokia N900 possédant le GPS et l accéléromètre MeeGo Sources wikipedia.org Le système est Open source (Linux Foundation). Langage et SDK Le Langage de programmation est le C++ (GTK+/Qt) et utilise un SDK gratuit pour Linux basé sur Qt Creator Parc Aucun mobile connu en circulation WebOS WebOS est basé sur Linux, il est Open source (en partie propriétaire). Langage et SDK La programmation se fait à base de Javascript. Parc Palm Pre et Palm Pre2 avec le GPS, l accéléromètre mais pas de boussole. Il est difficile de cerner cet OS qui a été racheté plusieurs fois, d où le manque d informations sur celui-ci. 5.2 Étude de marché Pour étudier les parts de marché des smartphones en France, nous nous sommes fiés à l agence comscore qui effectue des sondages auprès des utilisateurs ainsi qu à l agence Bloomberg pour connaître l état des ventes de smartphones sous les différents systèmes. Des statistiques obtenues à partir du nombre de connexions à des sites internet existent, mais celles-ci ne sont pas du tout fiables. Étant donné que pour faire de la réalité augmentée nous avons besoin de téléphones bien 13

15 équipés, nous nous sommes concentrés sur les parts de marché des smartphones. L évolution des parts de marché des différents systèmes en France sur l année 2010 selon com- Score est : On constate principalement la forte augmentation des parts de marché d Android qui sont passées de presque inexistantes à 20% du marché. On constate également de forte baisse pour les plateformes Symbian et celle de Microsoft. RIM a augmenté légèrement et ios stagne. Si on extrapole des tendances, on peut penser que Symbian passera rapidement sous les 20% pour laisser place à Android qui dépassera probablement les parts de marché d ios. La même tendance se constate avec les parts de marché en Europe, toujours selon comscore : 14

16 On comprend mieux ces fortes variations de part de marché quand on regarde le nombre de ventes de smartphones par OS (ici selon Bloomberg) : Symbian reste le système le plus important en Europe mais on constate les mêmes effets de l arrivé d Android sur le marché, bien qu Android n ait pas grignoté autant de part de marché aux autres systèmes qu en France. 5.3 Comparatif de l étude On constate globalement que les téléphones sous Symbian et ios se vendent bien. Cependant, les ventes des téléphones sous Symbian ont baissé fortement ce qui profite à Android. Les ventes de téléphones sous RIM OS demeurent assez faibles, ce qui n augmente pas ses parts de marché, les parts des téléphones sous ios stagnent également. Symbian domine encore le marché en France, cependant leur parc n est pas très équipé en capteurs, pas suffisamment pour être assuré qu une application de réalité augmentée puisse marcher sur de nombreux téléphones. Le parc de smartphones le plus important en France semble être celui des iphones mais quatre versions d iphone existent et seuls les deux derniers modèles sont aptes à supporter de la réalité augmentée (les autres ne possédant pas de boussole), ce qui réduit les utilisateurs potentiels. À l inverse, les smartphones sous Android ont tous l équipement nécessaire, bien que les parts de ce système soient plus faible, les utilisateurs potentiels sont plus nombreux à part de marché égale avec ios. Les smartphones sous RIM OS ne sont également pas tous équipés 15

17 de tout le matériel nécessaire à la réalité augmentée, de plus la plupart de ces mobiles disposent d écran à taille réduite dû à la présence d un clavier physique. Les téléphones sous Windows Phone 7 ont tous l équipement nécessaire mais les parts de marché de ce système sont encore faibles. Les autres systèmes ont un parc insuffisant voir nul. Enfin, si les tendances se maintiennent dans les années (voir les mois) à venir, Android dominera le marché, suivi des smartphones sous ios. Les autres systèmes risquent de voir leurs parts se réduire fortement ou rester faibles. 16

18 6 Choix de la plateforme Le choix de la plateforme à été déterminant pour le succès de notre projet. Ainsi, nous avions établi un certain nombre de critères pour le choix de celle-ci : capteurs du téléphone : les capteurs nécessaires à la réalité augmentée doivent être disponibles dans les téléphones et accessibles via les API de l OS facilité de développement : le langage de programmation, les outils de développement (sur téléphone ou émulateur) doivent être le plus accessible possible coût : l achat de matériel éventuel doit être minimisé débouché pour l application : le nombre d utilisateur potentiel doit être le plus élevé possible Candidats à éliminer Certaines plateformes ont un parc de téléphone n ayant pas les équipements nécessaires ou tout simplement aucun téléphone existant, cela concerne les système Maemo, MeeGo et WebOS. Parc insuffisant RIM OS, qui équipe les BlackBerry, possède un parc assez important de téléphones. Malheureusement, une partie des téléphones ne sont pas équipés des capteurs nécessaires, nous devons donc écarter ce candidat. L OS Symbian est dans le même cas. Windows Phone 7 étant arrivé récemment sur le marché, il n existe que peu de modèle et assez peu en circulation, nous écartons également cette plateforme. De même pour l OS Bada. Un choix stratégique Il nous reste donc deux candidats : Android et ios. On rappelle qu ils sont les deux plus gros sur le marché en France et en Europe, même si ios devance Android, le parc Android s étend de plus en plus et ses parts de marché se sont décuplées lors de ces dernières années au détriment d ios. Concernant les outils de développement pour ios, ceux-ci ne fonctionnent que sous Mac OS contrairement au SDK d Android qui est multi-plateforme. De plus, la publication sur la plateforme d application pour iphone est excessivement coûteuse, beaucoup plus que la plateforme d application d Android. Finalement, tout nous rapproche vers le système Android avec de plus, trois membres sur cinq de notre groupe qui possèdent un smartphone Android. Nous avons donc opté pour cette solution. Le système Android nous donne accès à tous les capteurs du téléphone qui nous sont nécessaires pour faire de la réalité augmentée. Le langage de programmation est le Java, langage que nous connaissons très bien. Nous disposons de tout le matériel nécessaire puisque le kit de développement est multi-plateforme et que nous disposons de quelques téléphones équipés d Android et de nos ordinateurs personnels. Les parts de marché d Android dans le monde de la téléphonie mobile (des smartphones plus précisément) est actuellement plutôt conséquente et tend à devenir la plus importante. 17

19 7 Le système Android Android est un système d exploitation basé sur un noyau Linux actuellement développé par l entreprise Américaine Google. Ce système est open source, sous licence Apache 2. Il est développé en collaboration avec les membres de l OHA (Open Handset Alliance) dont Google est l initiateur ; un consortium de grandes entreprises rassemblant constructeurs de téléphones, opérateurs téléphoniques, fabricants de puces électroniques et d autres. Le but de ce consortium étant d accélérer l innovation dans le monde de la mobilité en développant des standards ouverts tel que le système Android. 7.1 Architecture du système Android inclut un noyaux Linux avec les pilotes nécessaires à l exploitation des ressources matérielles, des librairies, une machine virtuel Java, un framework Java et quelques applications par défaut. Le schéma suivant, tiré de la documentation officielle, représente tous ces éléments. Android fournit aux applications, développées dans le langage Java, une API riche donnant accès au matériel du téléphone, aux paramètres du système et à certaines informations personnelles de l utilisateur (SMS, contacts, etc.). Tout cela est géré par un système de permission qu une application doit avoir pour faire usage d un périphérique ou de données sensibles. Les applications fonctionnent donc dans une machine virtuelle (la Dalvik virtual machine) qui intègre un compilateur JIT (just-in-time) depuis la version 2.2 du système (la version 3.0 est sortie très récemment), permettant la compilation en un code plus rapide à l exécution du byte-code Java d une application, les performances seraient de 4 à 10 fois meilleures (en terme de temps d exécution) sans que nous n ayons trouvé plus de détails. Le développement en C/C++ est aussi possible, bien qu assurer la compatibilité avec un grand nombre de téléphones soit plus compliqué, et que cela perde de l intérêt avec la présence du compilateur JIT. Cela présente néanmoins un grand intérêt pour le portage d application déjà existantes écrites en C/C++. Diverses librairies sont utilisables au travers de l API Java. On notera notamment OpenGL ES qui est une API de rendu graphique 3D pour plateforme mobile, utilisée pour tout le rendu 3D du 18

20 système. Il y a également la possibilité d utiliser SQLite, un moteur de base de données léger. Les applications Java fonctionnent par dessus toutes ces couches en utilisant le framework du système. Application qui peuvent être distribuées via l Android Market, la plateforme gérée par Google. Chaque téléphone Android dispose d une application permettant de parcourir les applications disponibles au téléchargement sur cette plateforme. Android autorise cependant l installation d application provenant d autres sources (téléchargées sur internet, transférés sur la carte mémoire,...). 7.2 Philosophie D abord, Android est un système open source qui a pour vocation d être disponible pour tout constructeur de matériel électronique. Google mise sur ce terrain là pour le développement de son système. L architecture des applications est pensée pour permettre la réutilisation des composants de celle-ci. Une application peut appeler un composant d une autre application pour qu il effectue une tâche spécifique et même récupérer un résultat dans certains cas. Une application peut aussi mettre à disposition des informations (protégées des autres par défaut). Divers moyens permettent aux applications de communiquer entre elles (des IPC puisque les applications fonctionnent dans des processus différents), que ce soit dans un sens ou dans les deux. 7.3 Architecture des applications Une application pour Android est structurée en trois parties. La première est un fichier appelé AndroidM anif est.xml dans lequel on déclare les composants de notre application, les ressources auxquelles on veut accéder (les permissions), la compatibilité avec les téléphones et bien d autres choses. La seconde est l ensemble des ressources de l application, cela comprend les descriptions d interfaces graphiques en XML, les images, des ressources textuelles pour assurer le multilingue et bien d autres. La troisième est le code exécutable de l application, nos classes Java. AndroidManifest.xml et composants d une application Dans ce fichier nous déclarons principalement les composants de notre application, les Activity qui sont les tâches affichées visuellement à l utilisateur (correspondent à une fenêtre dans les librairies graphiques plus conventionnelles), les Service qui sont des tâches de fond (démons) et les ContentP rovider qui permettent la mise à disposition de données de l application aux autres applications (les données d une application n étant pas accessibles aux autres sans cela). Il y a enfin les BrodcastReceiver qui permettent de recevoir des événements (via des Intent), principalement ceux du système comme lorsque le niveau de batterie change ou lorsque que les écouteurs sont connectés bien que cela puisse concerner des événements envoyés par n importe quelle application. Les autres choses importantes sont les permissions qui doivent être déclarées. Pour l utilisation de données sensibles (contacts, données de l agenda,...), pouvant porter atteinte à la vie privée (position GPS,...) ou certaines ressources matérielles (caméra, carte mémoire du téléphone,...), l application doit déclarer dans son manifeste qu elle va accéder à ces ressources. Avant l installation de l application, le système demandera à l utilisateur sa confirmation pour installer l application en lui indiquant les ressources auxquelles accédera l application. Dans le cas où une application utiliserait une ressource qui nécessite une permission dont elle n a pas déclaré l usage dans le manifeste, celle-ci est tout simplement arrêtée par le système (par envoie d une exception qui fait "planter" celle-ci). 19

21 Ressources Les ressources, qui sont identifiées par des entiers dans le code exécutable, sont un point clé pour le support des différents téléphones, ceux-ci ayant des résolutions ou dimensions d écran qui peuvent varier du simple au triple, les ressources doivent être disponibles dans différentes résolutions (pour les images matricielles) pour assurer un meilleur rendu visuel de l application. Il y a également la possibilité de créer des ressources de type image vectorielle. Les téléphones sont catégorisés dans un type de densité d écran (point par pouce) : ldpi (densité faible), mdpi (densité moyenne), hdpi (densité élevé) et xdpi (densité très élevé). Les ressources affectées par cette spécificité matérielle (image matricielle, description d interface dans certains cas) peuvent être placées dans des dossiers prévus à cet effet, le système choisissant le dossier qu il convient au moment de l exécution et en cas d absence d une ressource, il adapte la ressource faite pour la densité par défaut (mdpi) ou la plus proche. Un autre point intéressant sont les ressources de description des interfaces graphiques. Dans une application Android, les interfaces graphiques sont généralement décrites dans des fichiers XML où nous structurons les composants graphiques et où nous les identifions. Ces ressources sont utilisées par les Activity pour construire l interface graphique, les références vers les composants graphiques étant ensuite récupérables grâce aux identifiants de ces derniers. Ces ressources peuvent être placées dans différents dossiers pour être utilisées par certaines résolutions ou dimensions d écrans mais également en fonction de l orientation du téléphone (dont l affichage passe en mode paysage si l écran est placé à l horizontal). L application peut aussi intégrer des ressources textuelles, c est à dire des mots, des phrases qui sont accessibles par le code exécutable. L intérêt de ces ressources est qu elles peuvent être placées dans des dossiers spécifiques qui correspondent chacun à une langue. Ainsi, le système choisira lors de l exécution de l application les ressources qui doivent être utilisées selon la langue choisie par l utilisateur (dans les paramètres du téléphone). Les phrases doivent être traduites dans toutes les langues supportées par l application, bien qu un dossier pour les ressources textuelles soit présent pour les langues non supportées (ressources par défaut). Enfin, nous avons aussi la possibilité d intégrer des données brutes à l application. Nous en avons fait usage pour les données de positionnement en joignant un fichier XML qui est chargé dans une base de données au premier démarrage de l application. Code exécutable Les classes Java de notre application se basent sur des classes de l API pour créer les composants de l application. Nous étendons les classes Activity pour créer une fenêtre par exemple. Toutes les ressources sont accessibles via l API du système, nous pouvons soit laisser le système nous fournir la ressource la mieux adaptée (résolution/densité de l écran) soit choisir celle que nous voulons. 7.4 Kit de développement Le kit de développement d Android est gratuit, multi-plateforme (Linux, Mac OS et Windows) et inclut de nombreux outils. Tout d abord l émulateur qui fait fonctionner le système Android dans un processus sur la machine (appelé "virtual device") sur lequel on peut installer des applications et simuler diverses choses comme des appels, la position GPS, etc. Le kit contient aussi un outil de débogage (ddms) qui permet d interagir avec le téléphone pour voir le log du système (et les affichages des sorties standards des applications en fonctionnement) ainsi que le programme adb (Android Debug Bridge) qui nous permet d accéder à une console sur un téléphone (droits très limités) ou un émulateur et même y installer une application (en ligne de commande depuis un ordinateur). Et bien sûr les programmes nécessaires à la compilation d une application. Google fourni également un plugin pour l IDE Eclipse qui permet une intégration avec tous ces outils et 20

22 une intégration avec l API du système. Le lancement d application en phase de développement est possible sur l émulateur ou un téléphone (ou tout autre appareil) équipé du système sans restriction. 7.5 Avantages et inconvénients L un des inconvénients majeurs de la plateforme Android est sans aucun doute la fragmentation du parc des téléphones équipés de ce système. En effet avec maintenant plusieurs centaines de modèles différents existants, avec des caractéristiques parfois très différentes, il faut faire des efforts pour assurer la compatibilité et la bonne tenue des applications. Ce problème s est accentué avec la sortie de tablettes équipées de ce système (écran dépassant parfois les 10 pouces). Il y a également le problème de la fragmentation des versions du système en circulation qui se comptent au nombre de 7. Cela nécessite dans des cas très spécifiques de créer deux versions de l application bien que le système assure une compatibilité ascendante des applications. L utilisation du langage Java comme langage principal de développement des applications est sans nul doute un avantage pour le développement des applications. Ce langage de haut niveau est très répandu et permet un développement rapide. Avant la version 2.2 du système, cela représentait un inconvénient de devoir utiliser une machine virtuelle pour faire fonctionner les applications plutôt que du code natif (en mobilité il faut économiser les ressources). Mais depuis la version 2.2, avec l utilisation d un compilateur JIT, ce défaut est presque effacé. Avoir un kit de développement multiplateforme est un grand avantage pour ce système, aucun coût supplémentaire (achat de matériel) n est engendré si une équipe de développement passe au développement sur cette plateforme. L ouverture de la plateforme nous permet d utiliser n importe quel téléphone pour essayer notre application en phase de développement. C est sans doute le grand avantage face à son plus grand concurrent, l iphone, pour lequel il faut acheter des ordinateurs Apple pour pouvoir développer des applications. 21

23 8 État de la réalité augmentée sur Android Les applications de réalité augmentée existent depuis quelques années déjà sur Android, certaines étant un portage d application pour iphone. Elles se concentrent principalement sur des informations tel que trouver un restaurant ou des magasins. On trouve peu de librairies ou d applications open source comme base pour faire de la réalité augmentée sur cette plateforme. 8.1 Les applications Les applications disponibles sur l Android Market ne sont pas open source mais peuvent nous inspirer dans le fonctionnement de notre future application. Parmi les applications de réalité augmentée les plus populaires, on peut citer Layar et Wikitude. Ces applications fonctionnent avec un système de calque affichant les informations. Il y a des calques de base et certains peuvent être ajoutés par des utilisateurs. Les données géolocalisées sont affichées sur l horizon, des petites icônes généralement, ce qui nous fait penser que les altitudes ne sont pas prise en compte. Il existe quelques applications (et librairies) basées sur l analyse de l image (filtre numérique), ce sont généralement des applications gadgets qui restent assez gourmandes en ressources pour un usage mobile. Ces applications cherchent un marqueur (généralement un carré noir) dans les images filmées pour y placer un objet en 3 dimensions (généralement). Leur technique n est pas une solution envisageable dans notre cas de figure (on ne va pas poser des étiquettes partout dans l université...). Les applications type Wikitude et Layar sont semblables à ce que nous devions réaliser, bien que prendre en compte l altitude serait plus intéressant en terme de compréhension de ce qui est affiché pour l utilisateur. 8.2 Librairies ou ressources open source Parmi les quelques librairies ou petites applications open source de réalité augmentée, aucune n était vraiment complète et comblait nos besoins. Cependant ce sont des ressources intéressantes sur lesquelles se baser ou sur lesquelles apprendre l utilisation des capteurs, par exemple. ARKit ARKit est une petite librairie de réalité augmentée. Elle pose les bases tel que l exploitation des capteurs du téléphone ou l affichage des images de la caméra. Le positionnement d éléments graphiques est également implémentée. Néanmoins, nous nous sommes aperçu que cela n était pas suffisant. En plus de ne pas effectuer toutes les transformations nécessaires sur les données des capteurs pour assurer un maximum d évolution possible pour l application, cette librairie ne se préoccupait pas de connaître le champ de vision de la caméra. Ce dernier détail à été nécessaire à la réalisation de notre projet comme vous pourrez le constater dans la suite de ce rapport. De plus, l utilisation des capteurs et l affichage des images de la caméra est assez simple. Nous n avons donc pas souhaité utiliser cette ressource telle quelle. Source : https ://github.com/haseman/android-ar-kit/ Magnitude Magnitude est un framework qui se base sur ARKit, ce framework open source ajoute une couche applicative par dessus ARKit. Cela consiste essentiellement en l ajout d éléments d interfaces graphiques, ce qui ne représente pas la partie la plus compliquée de l implémentation d une 22

24 application de réalité augmentée. L utilisation de cette ressource n est donc pas envisagée, nous préférons implémenter une interface graphique mieux adaptée à notre besoin. Source : http ://code.google.com/p/magnitudehq/ 23

25 9 Analyse Ne connaissant pas en détails l API Android, nous avons formulé une première analyse du projet au travers d un diagramme de classe global avec les éléments de l API que nous connaissions. Ce premier diagramme de classes nous a permis de nous répartir le travail, chacun approfondissant sa connaissance de l API dont il avait besoin pour pouvoir compléter le diagramme de classe. Nous avions donc eu assez rapidement le premier diagramme de classe suivant : Notre application sera articulée autour des trois Activity (ou fenêtre) : StartActivity pour la fenêtre de démarrage de l application (accès aux autres fenêtres), ARActivity pour l affichage en réalité augmentée et M apactivity pour la fenêtre affichant la carte de l université. Nous avons également prévu la création de P ref erencesactivity pour la gestion des préférences de l application par l utilisateur. ARActivity contiendra les composants graphiques CameraV iew (fait l affichage des images de la caméra), ARV iew (affiche des points d intérêt à l écran) et ArrowV iew (la flèche d orientation). Nous avons également établi la nécessité de la classe RData qui s occupe de récupérer toutes les informations sur l état du téléphone (position GPS et information sur les autres capteurs nécessaires), nous pourrons sur cette classe n activer que les informations dont nous avons besoin avec un système de drapeaux. Nous implémenterons l interface RDataListener sur les composants qui ont besoin d obtenir les informations des capteurs. Enfin, nous avons convenu de la classe P OIP rovider qui sera la super classe des "sources de points d intérêt". Ces classes nous fourniront les points d intérêts (classe P OI) qui pourront être mis à jour en fonction du temps ou du changement de position GPS du téléphone. À ce stade de l analyse, nous ne savions pas encore exactement où allaient être exploitées les informations provenant de RData, c est pourquoi cette classe n est en relation avec aucune autre sur ce premier diagramme. Ce diagramme a été fortement complété pendant la fin de la période d analyse ainsi qu au tout début du développement, alors que nous découvrions plus en détails l API d Android, la façon dont 24

26 nous allions implémenter les fonctionnalités de l application et que nous créions des petites applications prototypes. Cela s est traduit principalement par l ajout de classe, dû à l implémentation pour la plupart, et par l ajout de méthodes sur les classes de notre première analyse. Cependant, la structure des classes de notre première analyse à été presque respectée. Nous avons donc le diagramme de classes final suivant avec en bleu nos classes et en vert celle de l API Android (cliquez pour télécharger le diagramme en haute résolution ou ouvrez le fichier join à ce rapport) : Les Activity de notre première analyse sont bien toutes là, avec l Activity supplémentaire ChoixP rovideractivity qui nous permet de choisir quelles informations afficher à l écran. Nous retrouvons la classe RData dont nous avons pu établir les liens précis avec les classes de l API et celle de notre application. Les P OIP rovider sont maintenant également utilisés sur la carte où nous avions jugé intéressant d y placer les points d intérêts, les P OIP rovider étant également utilisés dans la classe ARV iew nous avons créé la classe P rovidermanager qui fait la gestion des mises à jour d un P OIP rovider (qui implique une T hread et de nombreux tests). La grande nouveauté par rapport à notre première analyse est l arrivé des DrawableP OI, point d intérêt ayant pour objectif d être dessinés à l écran, permettant des choses plus complexes. Pour cela nous avons créé l interface ARContext sur lequel se dessine un DrawableP OI. Les classes ARV iew et M apv iew implémentent ARContext pour supporter ce type de point d intérêt. Nous avons également dû ajouter une méthode abstraite à la classe P OIP rovider. Les autres nombreuses classes ajoutées sont dues à l implémentation et ont été pour certaines ajoutées en pleine phase de développement. Cela concerne principalement les classes du package ui et ui.runnable, les classes relatives à la base de données ainsi que la hiérarchie des P OIV iew. Notre analyse ne s est pas faite d un seul bloc, nous avons dû prendre connaissance de l API avant d avoir un diagramme de classe plus proche de l implémentation. Néanmoins, nous avions fait une première analyse plutôt solide avec des interfaces et des classes abstraites. Nous n avons donc eu aucune difficulté pour ajouter de nouvelles classes pour les fonctionnalités supplémentaires. 25

27 10 Implémentation 10.1 RData Cette classe est en charge de collecter toutes les informations renvoyées par les capteurs du téléphone, leur utilisation engendrant une augmentation conséquente de la consommation énergétique du téléphone, nous avons pris soins de permettre de n activer que les capteurs nécessaires. Cette classe implémente de nombreuses interfaces de l API Android pour pouvoir recevoir des événements (les informations des capteurs) venant de classes de l API. La classe RData possède une liste de RDataListener qu elle informe lors de nouvelles valeurs pour les capteurs activés. Les données désirées sont activables avec un système de drapeaux combinables avec un ou binaire (opérateur " " en java), ainsi les RDataListener ne seront informés que des données des capteurs activées. Certaines données sont calculées (zangle et zazimuth) à partir des informations des capteurs provenant de l API, il y a donc les dépendances suivantes entre les données et les capteurs qui seront activés : Capteur GPS boussole accéléromètre orientation (du téléphone) position GPS azimut zazimuth orientation zangle De plus, l appel aux méthodes computev erticalangle et computehorizontalangle doit être fait après avoir activé la position GPS (qui doit être acquise) avec en plus l accéléromètre pour la première méthode et la boussole pour la seconde ARView et MapView Ces deux composants graphiques sont similaires, ils fonctionnent presque de la même manière (dans la gestion des P OI et DrawableP OI) et varient principalement dans l implémentation des méthodes de l interface ARContext. Ces deux V iew utilisent la classe RData pour obtenir les informations sur les capteurs du téléphone qui leurs permettent d effectuer le positionnement des P OIV iew et le dessin des DrawableP OI. Ces deux composants héritent de la classe AbsoluteLayout qui est un conteneur graphique dans lequel on peut positionner des V iew à une coordonnée précise en pixel. Ce conteneur est marqué comme "deprecated" dans l API Android, cela car pour le support des différents téléphones cette classe est déconseillée. Nous avons utilisé ce conteneur car c est le meilleur moyen de positionner nos P OIV iew à l écran là où nous avons calculé les coordonnées de la position GPS du POI. Le dessin des DrawableP OI est assurée par l implémentation de ARContext. Pour chaque DrawableP OI qu a fourni le P OIP rovider utilisé, nous faisons appel à sa méthode showon dans la méthode ondraw de ARV iew et MapV iew. Ces deux classes utilisent également une instance de la classe P roviderm anager qui est en charge de maintenir à jour les informations du P OIP rovider que l utilisateur a choisi. Enfin, les classes ARV iew et M apv iew doivent avoir pris connaissance de l Activity dans laquelle elles sont (setp arentactivity) pour pouvoir effectuer la gestion des P OIV iew qui doit être faite dans la thread de l interface graphique via la méthode Activity.runOnU it hread. Nous avons pour cela créé un certain nombre de classes implémentant l interface Runnable tel que V isibilitysetter ou P OIV iewp ositioner ProviderAdapter et ses sous classes Ces classes sont utilisées pour l Activity permettant le choix des informations à afficher, elles héritent de la classe de l API Android BaseAdapter qui est un ListAdapter. Les ListAdapter ont 26

28 pour vocation d être utilisés avec un ListV iew qui est en fait le composant graphique permettant de faire un affichage sous forme de liste de V iew tout en ayant pour objectif de récupérer des données indexées (par l indice dans la liste) en implémentant l interface Adapter (méthodes laissées abstraites) lors de la sélection d un élément de la liste. Nous avons opté pour l utilisation du design pattern State qui nous permet de gérer les états de notre liste de choix en récupérant les P rovideradapter successifs via getn extadapter et getp reviousadapter. Ces deux méthodes sont appelées lors de la sélection d un élément de la liste (c est pourquoi getn extadapter possède un paramètre de type entier, c est l indice sélectionné) ou lors de l appui sur le bouton "back" du téléphone (getp reviousadapter). ChooseP rovideractivity écoute les événements de sélection en implémentant AdapterV iew.onitemclicklistener et fait passer le ListV iew présent dans l interface graphique au nouveau P rovideradapter si le P rovideradapter courant de la liste ne renvoie pas null dans sa méthode getnextadapter. Si cette méthode renvoie null, alors on récupère le P OIP rovider sélectionné via getitem qui a été redéfini dans P rovideradapter (toujours abstraite, type de retour P OIP rovider) et nous mémorisons l instance grâce à l attribut de classe selectedp rovider dans la classe P OIP rovider qui sera accessible ensuite dans toute l application grâce à P OIP rovider.getselectedp rovider (car les fenêtres fonctionnent toutes dans la même machine virtuelle). Ainsi en passant de la carte à la réalité augmentée on conserve la source de données que l utilisateur a sélectionné POIProvider et ses sous classes P OIP rovider est une classe abstraite car nous savions que nous aurions besoin de créer de multiples sources de points d intérêts. Nous y avons mis des méthodes abstraites permettant la mise à jour (update, les traitements long doivent y être implémentés) et assurant le choix du type de mise à jour (constructeur et setters) qui peut être temporel et/ou au changement de position. Les sous classes de P OIP rovider implémentent toutes des traitements spécifiques, certaines s adressent à la base de données pour créer les points d intérêt d autres téléchargent des données provenant de serveur distant. Les points d intérêt sont renvoyés par les méthodes getp OIs et getdrawablep OIs POIView et ses sous classes Les P OIV iew représentent les éléments graphiques qui seront affichés sur les images de fond de la caméra, il en existe de plusieurs types, nous avons les P OIT xtv iew qui représenteront les points d intérêts ne contenant que du texte, nous avons aussi les P OIImgV iew qui représentent les points d intérêt contenant du texte et une image. Afin de décharger la classe ARV iew (ou MapV iew) du choix du type de P OIV iew affichant un POI qu elle désire afficher, une fabrique de P OIV iew a été mise en place, elle est représentée par la classe F abriquep OIV iew, cette dernière grâce a sa méthode static createp oiv iew qui s occupe de renvoyer le bon type de P OIV iew, image ou texte, et permet ainsi une transparence totale. Cette fabrique a un autre avantage qui est l extensibilité, en effet grâce à celle-ci, il serait très facile de créer d autres types de P OIV iews, leurs pouvant être assuré dans la méthode createp oiv iew sans que ARV iew (ou MapV iew) ne s en préoccupe. Remarque : La classe P OIV iew représente la classe de base de tous les types de P OIV iew. Elle a pour reponsabilité d imposer certaines caractéristques ou contraintes d affichage aux differents types de P OIV iew qui étendront cette classe. Pour des raisons d esthétique, dans la classe P OIV Iew la méthode onmeasure de la classe V iew de l API Android a été surchargée de façon a imposer une contrainte sur la taille maximale des P OIV iew. 27

29 10.6 BD et TablesBDD La classe BD n est utilisée qu une fois, lors de la création de la base de données. Elle permet de mettre en place la base de données, c est à dire la création des huit tables. Elle hérite donc de SQLiteOpenHelper, ceci nous permettant de créer les tables lors du premier lancement de la base de données. La classe T ablesbdd fournit toutes les fonctions qui vont interagir avec la base de données. À savoir, une fonction d insertion qui peut effectuer l insertion de tous les types d enregistrement dans la base. Nous avons aussi dans cette classe toutes les fonctions correspondantes aux requêtes qui nous sont utiles tel que la récupération des informations d un bâtiment ou de ses coordonnées, de même pour les salles et les points d intérêts. Le type de retour de ces requêtes que l on récupère avec un Cursor peut aussi bien être une seule instance d un objet qu une liste d objets. Nous avons également choisi de créer une classe pour représenter chaque table de la base de données afin de pouvoir plus facilement exploiter les données de la base en les récupérant dans une instance dont le type correspond à la table associée. Une instance d un bâtiment (classe Batiment) correspondra donc à un enregistrement dans la table Batiment avec les attributs de la classe Batiment correspondant aux colonnes de la table Batiment. Chacune des classes suivantes représentent une table de la base de données : bd.batiment, bd.salle, bd.p oi, bd.p ositionp oi, bd.p ositionsalle et bd.p ositionbatiment Graphe, Dijkstra, Node et Edge La classe Graphe représente le graphe pondéré des divers croisements et chemins que l on a choisit de représenter dans l université, elle utilise donc le design pattern Singleton afin de charger le Graphe qu une fois (une instance). On utilise ici, les classes Node et Edge qui vont représenter respectivement les croisements (sommets) et les chemins (arêtes). Le poids entre deux arêtes est calculé lors de l insertion des arêtes dans le Graphe (distance séparant les deux positions). Cette classe Graphe (à instance unique) est appelée seulement dans la classe Dijkstra qui va déterminer le plus court chemin entre notre position et une destination. Une fonction renvoyant les voisins d un sommet est donc implémentée dans le Graphe. Le remplissage du graphe se fait donc lors de son instanciation unique, à ce moment s effectuent directement les requêtes dans la base de données qui vont déterminer les sommets (Node), les arêtes (Edge) et leur poids dans le graphe. Dans la classe Dijkstra nous avons évidemment la méthode dijkstra qui va renvoyer une liste de prédécesseur permettant de déterminer un plus court chemin d une position vers une autre. Il y a aussi la méthode startp athf inder qui va justement être appelée lorsqu on veut tracer ou retracer (mettre à jour) un chemin. Comme la position courante et la destination ne font pas parti des noeuds du Graphe, la technique d utilisation est de lancer le Dijkstra entre le point le plus près du Graphe et notre position courante, et le point le plus près avec le point de destination également ArrowOpenGL, ArrowRenderer et ArrowView ArrowOpenGL est la classe où se construit la flèche. C est une association de face, chaque face est composée de plusieurs points dans l espace (selon les axes x, y et z). La structure utilisée est un tableau de vertex (point) dans lequel se trouvent tous les points constituant l objet. On détermine aussi la taille de la flèche, en écartant plus ou moins les points selon la taille désirée. ArrowRenderer permet le rendu de la flèche, gérer les mouvements qu elle prendra, et aussi le système de coloration : coloration face par face, couleur unie ou coloration par système de lumière. 28

30 Il y a plusieurs méthodes de coloration, soit on colorise l objet face par face, cela offre la possibilité d avoir plusieurs couleurs pour l objet, soit on colorise tout l objet de la même couleur, l objet sera uni et on distinguera mal la profondeur, soit on colorise grâce à un système de lumière toujours (même couleur), les effets le lumière permettent de distinguer la profondeur, la face la plus proche sera plus éclairée que les faces se trouvant plus en profondeur. Couleur Plusieurs Coloration unie couleurs lumineuse ArrowV iew est la classe permettant l insertion de la flèche dans l interface graphique. Via cette classe on choisira la manière dont la flèche bougera, nous avons choisi de ne suivre que 2 axes pour les mouvements de la flèche vertical et horizontal bien que nous aurions pu aussi avoir un mouvement de balancement (comme un avion qui se balance), selon l axe y. Cela car l utilisation des 2 premiers axes donnait un résultat plus clair pour la compréhension de la direction à suivre. Le choix de la méthode de coloration ce fait également grâce à cette classe. 29

31 11 Positionnement des informations à l écran Pour faire de la réalité augmentée, nous devons positionner les informations géolocalisés en temps réel sur les images de la caméra. Nous avons également décidé de faire des choses un peu plus avancées en calculant les parties visibles de segments entre deux positions GPS, cela pour pouvoir dessiner des figures géométriques géolocalisées Données sur l état du téléphone Le système Android est pensé pour donner accès à nombre de capteurs du téléphone, ainsi il supporte les puces GPS, les boussoles, les gyroscopes, les accéléromètres et bien d autres. Il donne aussi accès à la ou les caméras du téléphone, ainsi que leurs propriétés, notamment les angles de vue de celle-ci à partir de la version 2.2 du système. Certaines informations sur l état du téléphone sont relatives au système de coordonnées du téléphone, ci-contre figure les 3 axes du téléphone qui restent fixe même quand celui-ci est tourné dans un sens ou dans un autre. Notez que l axe dans lequel filme la caméra à l arrière du téléphone est l axe Z. Avec les différents capteurs du téléphone, nous calculons en temps réel un certain nombre d informations sur l état du téléphone. Ainsi, avant d effectuer nos calculs géométriques, nous avons créé un module logiciel offrant les informations suivantes : zazimuth : c est l azimut au nord de l axe où filme la caméra (l axe Z). zangle : c est l angle vertical de l axe où filme le téléphone ( Z). 0 lorsque le téléphone filme en bas et 180 lorsqu il filme en l air. Ces deux informations nous permettent de savoir dans quelle direction filme la caméra. Ce module nous offre aussi les informations suivantes, obtenues depuis l API, certaines étant utilisées pour calculer les précédentes : azimuth : c est l azimut au nord du téléphone (l azimut de l axe Y, autour de Z) orientation : c est l angle de rotation autour de l axe Z du téléphone, plus précisément l angle de Y. 0 lorsque le téléphone est en position normale (écran à la verticale et boutons vers le bas), 90 lorsqu il est couché sur le côté gauche, 270 si couché sur le côté droit et 180 si à l envers (bouton vers le haut). Bien sûr il y a tous les paliers d angles entre 0 et 359. position GPS : la position GPS du téléphone Calcul de zangle Pour le calcul de cet angle, nous utilisons l accéléromètre du téléphone, l API nous fournit l accélération du téléphone sur ses trois axes. L accélération sur Z (l opposé de l accélération sur Z) nous permet de savoir si le téléphone filme vers le haut où vers le bas, plus précisément c est le signe de cette donnée qui est déterminant. Une valeur négative indique que l axe Z est dirigé vers le haut et une valeur positive indique qu il est dirigé vers le bas. Selon la force de l accélération, l axe Z a un angle plus ou moins élevé avec l horizontale. Si l axe Z est à l horizontale l accélération sur cet axe est nulle. On doit donc calculer zangle en fonction de l accélération sur Z. Soit donc l équation : zangle = acc(z) a + b On connaît les trois solutions suivantes (3 directions où filme la caméra) : en haut à la verticale à l horizontale en bas à la verticale { zangle = 180 acc(z) = 1G { zangle = 90 acc(z) = 0G { zangle = 0 acc(z) = 1G 30

32 Avec G la force d attraction terrestre et acc(n) la fonction qui renvoie l accélération sur l axe N. On a donc le système d équations suivant à résoudre : 180 = 1G a + b 90 = 0G a + b 0 = 1G a + b 180 = 1G a + 90 b = 90 1G a = = 1G G b = 90 a = 90 1G On reporte a et b dans notre équation initiale pour trouver notre formule : zangle = (acc(z) 90 1G ) + 90 Calcul de zazimuth Deux données entrent en jeux pour le calcul de de cet angle, tout d abord l azimut. Cet angle est l angle entre la direction vers le nord (le nord magnétique) et l axe Y du téléphone, cela autour de l axe Z. La deuxième donnée est l orientation du téléphone qui correspond à l angle de rotation du téléphone autour de Z par rapport à sa position dite normale (Y, vers le haut). Cette seconde information est nécessaire car l azimut de Z varie quand l orientation du téléphone change. Nous allons procéder de la même manière que pour le calcul de zangle, nous avons donc la formule : zazimuth = azimuth a + orientation b + c On va également utiliser des états connus pour trouver a, b, et c, la première est le cas où le téléphone est en position normale, l azimut de Z est alors égal à l azimut du téléphone (de Y ). Puis on prend le cas où le téléphone est couché sur le côté gauche avec 90 de plus pour zazimuth et enfin le cas où le téléphone est couché sur le côté droit avec 90 de moins pour zazimuth. En se plaçant dans le cas où le téléphone filme au nord, on a donc sur le côté gauche position normale sur le côté droit azimuth = 270 orientation = 270 zazimuth = 0 azimuth = 0 orientation = 0 zazimuth = 0 Ce qui nous donne le système d équations suivant : 0 = 270 a b + c 0 = 0 a + 0 b + c 0 = 90 a + 90 b + c 270 b = 270 a c = 0 90 a = 90 b b = a = a c = 0 azimuth = 90 orientation = 90 zazimuth = 0 a = b = b En choisissant a = 1 on obtient la formule de calcul pour zazimuth suivante : zazimuth = azimuth orientation 11.2 Positionnement des POIs par dessus les images de la caméra Avec ces informations, nous pouvons ensuite positionner une position GPS de façon relative au téléphone. En effet, l API d Android nous donne la possibilité de calculer la distance entre deux position GPS (à vol d oiseaux, sans prendre en compte l altitude), position GPS qui possède une 31

33 latitude, une longitude et une altitude ce qui nous permet de positionner le téléphone et n importe quelle position GPS dans l espace. Pour positionner un POI à l écran, nous utilisons une astuce qui nous évite de faire des calculs dans l espace. Nous avons connaissance des angles de vue de la caméra et pour trouver la position d un POI à l écran il nous suffit de connaître l angle horizontal (autour de Z dans le repère ci-dessous) et vertical (autour de Y dans le repère) entre l axe Z du téléphone et l axe entre la position GPS du téléphone et celle du POI. Ensuite avec une simple proportion avec les angles de vues de la caméra appliquée sur la résolution de l écran du téléphone (également disponible dans l API), nous obtenons les coordonnées sur l écran du POI. Pour trouver l angle horizontal (a H sur la figure ci-contre) d un POI (P sur la figure) nous utilisons le célèbre théorème de Pythagore. Tout d abord nous créons le sommet I formant un triangle rectangle avec la position GPS de P et le téléphone (O, centre du repère) en créant une position GPS avec la latitude de P et la longitude de O. Nous pouvons donc trouver l angle a : a = arcsin(oi/op ) Puis il nous faut trouver l angle b à partir de l angle a, cela se fait par simple soustraction ou addition sur un des angles 0 et 180 selon dans quelle partie du repère se situe P : b = 0 + a si lat(p ) et lon(p ) = 180 a si lat(p ) et lon(p ) = a si lat(p ) et lon(p ) = 0 a si lat(p ) et lon(p ) Avec lat(x) et lon(x) les fonctions qui renvoient la latitude et la longitude de la position GPS X L angle b constitue maintenant l azimut au nord (N) de P par rapport à la position courante, par simple soustraction de l azimut du téléphone nous obtenons a H : a H = b azimuth Pour trouver l angle vertical, nous utilisons toujours le théorème de Pythagore, on procède de manière similaire. On calcule la distance IP en soustrayant l altitude du téléphone (O, centre du repère), qui est dans la position GPS obtenu grâce à l API, avec la distance OI qui est calculée via l API avec les positions O et P (l altitude des positions GPS n influence pas cette valeur) on trouve l angle a : a = arctan(ip/oi) Puis { on calcule l angle b : b = 90 + a si alt(p ) > alt(i) = 90 a si alt(p ) < alt(i) Avec alt(x) la fonction qui renvoie l altitude de la position GPS X. Par soustraction on trouve l angle vertical a V : a V = b zangle L angle a V est dans l intervalle [ 180; 180]. Enfin, avec ces deux angles, nous vérifions que la position GPS ne dépasse pas les angles du champ de vision de la caméra. Si tel est le cas, nous pouvons effectuer nos deux proportions pour calculer la position en pixel sur l écran du téléphone : { x = (ah + (angleh/2)/angleh) H e y = (a V + (anglev/2)/anglev ) L e 32

34 Avec angleh l angle de vision horizontal de la caméra (en degrés), anglev l angle de vision vertical de la caméra (en degrés), H e la hauteur de l écran en pixel et L e la largeur de l écran en pixel Dessin de segments entre deux positions GPS Faire des formes par dessus les images offres de plus grandes possibilités pour la mise en valeur de large zone par exemple. Pour cela, nous avons implémenté le calcul de la partie visible d un segment entre deux positions GPS. Pour bien comprendre, prenons l exemple du dessin des contours d un bâtiment c est à dire sa forme (cubique généralement) en dessinant la surface au sol, les arrêtes de ses murs et les contours de son toit. Quand l utilisateur filme le bâtiment il faut pouvoir connaître quelle partie de chacun de ces segments sont visibles et à quelle position sur l écran les dessiner. Malheureusement, nous ne pouvons pas utiliser la même technique que pour le positionnement des POIs, cela ne fonctionne que si la position GPS est visible. On pourrait penser qu en utilisant cette solution, même si les angles dépassent ceux du champ de vision, on pourrait tout de même tracer un segment de façon correcte, mais il n en est rien! Prenons le cas d une position GPS située au milieu du champ de vision (angle horizontal de 0 ) et d une autre hors du champ de vision avec (angle horizontal de 180 ), la droite passant par ces deux positions étant donc l axe Z du téléphone. En calculant les positions selon la méthode expliquée page 31, nous aurions un point au milieu de l écran et le second hors de l écran avec une position élevée en X (X, position en pixel sur l écran du téléphone), cela tracerait un segment du centre de l écran du téléphone vers le bord droit. Hors, nous devrions ne voir qu un point de la droite, au centre de l écran du téléphone! Définition du problème Ce problème a nécessité un certain temps de réflexion avant que nous ayons trouvé une solution. Cette dernière consiste à se placer dans un espace cartésien en trois dimensions dont le téléphone est le centre. Puis à chercher des intersections entre la droite passant par les deux coordonnées GPS et les quatres plans définis par les angles du champ de vision, intersections qui doivent être dans le champ de vision (sur les bords). Ci-contre une figure représentant le champ de vision du téléphone (le volume entre les surfaces en vert et rose). Les points A et B représentent les deux positions GPS entre lesquelles on veut tracer un segment, les points I 1 et I 2 sont les intersections entre la droite passant par les points A et B et les plans du champ de vision. Coordonnées de A et B 33

35 La première étape consiste à positionner les positions GPS dans notre repère, cela à été réalisé par le passage d un système sphérique à cartésien. En effet, nous avons connaissances de la distance entre le centre du repère (le téléphone) et la position GPS (distance réel par calcul grâce à l API d Android, la différence d altitude et le théorème de Pythagore) et également aux angles horizontaux et verticaux comme expliqué précédemment page 31 ce qui nous permet de calculer les coordonnées sphériques. Prenons P (ρ P ; θ P ; φ P ) une position GPS, ses coordonnées sphériques sont : ρ P = dist(o, P ) θ P = rad(360 a H ) φ P = rad(90 a V ) Avec dist(a, B) la fonction qui renvoie la distance dans l espace entre la position A et la position B (réalisée avec le théorème de Pythagore en suivant le même principe que page 31), rad(q) la fonction qui convertit les degrés Q en radians. On peut maintenant calculer les coordonnées cartésiennes de P : x P = ρ P sin(φ) cos(θ) y P = ρ P sin(φ) sin(θ) z P = ρ P cos(φ) Équation de la droite (AB) Une fois les coordonnées cartésiennes de nos deux positions GPS connues, nous pouvons maintenant calculer l équation de la droite (AB), celle-ci prendra la forme d une équation paramétrique. Soit un point M(x; y; z) sur la droite (AB), alors il existe k tel que : AM = k v avec v vecteur directeur de (AB). Le vecteur v a pour coordonnées : v 1 = x B x A v = v 2 = y B y A Avec A(x A ; y A ; z A ) et B(x B ; y B ; z B ). v 3 = z B z A On obtient ainsi l équation paramétrique de la droite (AB) : x = x A + kv 1 y = x A + kv 1 car M = A + k v x = x A + kv 1 Équation des plans Nous devons maintenant calculer les équations des quatres plans, nous utilisons pour cela un vecteur normal à chacun des plans partant du centre du repère O. Ainsi, un plan Q de vecteur normal n(n 1 ; n 2 ; n 3 ) est l ensemble des points M(x; y; z) tel que OM soit orthogonale au vecteur n. Le produit scalaire de deux vecteurs orthogonaux étant nul on a l équation : n. OM = 0 n 1 x + n 2 y + n 3 z = 0 Donc l équation du plan Q est : n 1 x + n 2 y + n 3 z = 0. Il est relativement facile de trouver les équations des quatre plans définis par le champ de vision. En effet nous pouvons calculer l angle entre ces plans et un des plans formés par les vecteurs X, Y et Z dans le système de coordonnées sphériques grâce aux angles du champ de vision. Nos quatre plans sont orthonormaux au plan ( X; Y ) pour les deux plans définis par l angle de vision vertical et au plan ( X; Z) pour les deux plans définis par l angle de vision horizontal. Par exemple, le plan gauche du champ de vision a pour vecteur normal(coordonnées sphériques) : ρ ng = 1 n G = θ ng = rad(angleh/2) + π/2 avec angleh l angle de vision horizontal de la caméra. φ ng = π/2 34

36 Calcul des intersections Le calcul des intersections entre la droite passant par A et B et un des quatre plans se fait par résolution du système d équations suivant : 0 = n 1 x + n 2 y + n 3 z x = x A + kv 1 avec k pour seul inconnue y = y A + kv 2 z = z A + kv 3 0 = n 1 (x A + kv 1 ) + n 2 (y A + kv 2 ) + n 3 (z A + kv 3 ) 0 = n 1 x A + kn 1 v 1 + n 2 y A + kn 2 v 2 + n 3 z A + kn 3 v 3 kn 1 v 1 + kn 2 v 2 + kn 3 v 3 = n 1 x A + n 2 y A + n 3 z A k(n 1 v 1 + n 2 v 2 + n 3 v 3 ) = n 1 x A + n 2 y A + n 3 z A k = n 1x A +n 2 y A +n 3 z A (n 1 v 1 +n 2 v 2 +n 3 v 3 ) Clairement, ce système d équation admet une solution si (n 1 v 1 + n 2 v 2 + n 3 v 3 ) 0. Si tel est le cas, nous calculons finalement les coordonnées cartésiennes de notre intersection I(x I ; y I ; z I ) grâce à k : I = x I = x A + kv 1 y I = y A + kv 2 z I = z A + kv 3 Coordonnées à l écran du segment visible Nous avons maintenant la possibilité de trouver nos deux intersections. Il faut maintenant détecter quelle coordonnée utiliser entre A, B, I 1 et I 2. En effet, le choix dépend de la visibilité à l écran ou non de A et B mais aussi de si I 1 et I 2 sont vers l avant (visibles donc), c est à dire si x I1 > 0 et x I2 > 0. Il y a trois cas : 1. Les deux positions GPS sont visibles 2. Une seule position GPS est visible 3. Aucune position GPS n est visible Cas 1 : Si les deux positions GPS sont visibles, cela ne pose pas de problème. On réutilise le même principe que dans la page 31, les deux extrémités de notre segment étant les positions à l écran de nos deux positions GPS. Cas 2 : Si nous n avons qu une seule position visible, nous avons très facilement la position de celle-ci à l écran (principe expliqué page 31 encore) et il nous faut trouver l intersection qui est sur le segment [AB] (qui est forcément visible). Une intersection I est sur le segment [AB] s il existe k tel que : 0 <= k <= 1 et AB = k AI 35

37 On calcule k de la manière suivante : k = (x B x A )+(y B y A )+(z B z A ) (x I x A )+(y I y A )+(z I z A ) Cas 3 : Si les deux positions GPS ne sont pas visibles à l écran, il nous faut vérifier que les deux intersections (qui doivent toujours être visibles) sont sur le segment [AB]. De la même manière que pour le cas 2, nous calculons k et si celui-ci est dans l intervalle requis pour les deux intersections, nous utilisons les coordonnées à l écran de ces deux dernières pour tracer notre segment sur l écran du téléphone. Si l une des intersections n est pas sur [AB] alors les segments [AB] ne traverse pas le champ de vision. Avec un algorithme adapté, nous pouvons efficacement trouver la partie visible d un segment entre deux position GPS. Celui-ci consiste à s arrêter dès que nous avons deux coordonnées cartésiennes qui conviennent parmi l ensemble contenant : les deux positions GPS A et B l intersection entre (AB) et le plan supérieur l intersection entre (AB) et le plan inférieur l intersection entre (AB) et le plan gauche l intersection entre (AB) et le plan droit Si nous ne trouvons pas deux coordonnées satisfaisantes dans cet ensemble, alors le segment n est pas visible même partiellement Positionnement des POIs sur la carte 36

38 La carte est en fait une image haute résolution sur laquelle nous connaissons les bornes en terme de latitude et longitude de la zone représentée. Elle est bornée par une latitude maximale et minimale ainsi qu une longitude maximale et minimale, cela nous permet d y positionner n importe quelle information géolocalisée. De plus, seule une partie de la carte peut être visible, celle-ci dépend du niveau de zoom et de la dimension de l écran du téléphone. Ci-contre, en clair la partie visible, en sombre ce qui n est pas visible. Le positionnement sur la carte consiste en l utilisation d un repère cartésien à deux dimensions, celui de l image. les positions GPS sont positionnées par soustraction et avec une proportionnalité sur la zone de la carte visible. Tout d abord nous avons besoin des informations suivantes : lonmin : la longitude minimale de la carte (limite ouest) lonmax : la longitude maximale de la carte (limite est) latmin : la latitude minimale de la carte (limite sud) latmax : la latitude maximale de la carte (limite nord) L : la largeur (en pixel) de la carte (l image) H : la hauteur (en pixel) de la carte (l image) h : la largeur (en pixel) de la zone visible l : la hauteur (en pixel) de la zone visible zoom : le niveau de zoom de la carte entre 1 (zoom maximal) et largeurecran/l ou hauteurecran/h selon le cas (dépend du ratio largeur/hauteur de l écran et de l image) De plus, pour faciliter les calculs, nous calculons les valeurs suivantes : londiff = lonmax lonmin latdiff = latmax latmin Soit la position GPS P, ses coordonnées sur la carte sont : P = { xm = L ((lon(p ) lonmin)/londiff) y M = H (H ((lat(p ) latmin)/latdiff)) Nous devons ensuite calculer la position sur l écran (dans le cas où les coordonnées sur la carte seraient dans la zone visible) en fonction de la partie visible, en passant du système de coordonnée de la carte vers celui de l écran du téléphone. Pour cela, posons les valeurs (connues) suivantes : x V : la position en X sur la carte du bord gauche de la zone visible y V : la position en Y sur la carte du bord gauche de la zone visible Pour trouver les coordonnées sur l écran, nous procédons simplement de la façon suivante : { x = (xm x V ) zoom y = (y M y V ) zoom 11.5 Dessin de segments sur la carte Dessiner des segments sur la carte nous permet de mettre en valeur les même choses qui le sont en réalité augmentée. Le problème est similaire au cas de la réalité augmentée mais est cette fois dans un espace en deux dimensions. Pour dessiner des segments sur la carte, entre deux positions GPS A et B, nous devons suivre l algorithme utilisé pour la réalité augmentée, c est à dire trouver deux coordonnées visibles et sur le segment [AB] parmi : les positions A et B 37

39 l intersection entre (AB) et le bord supérieur de la partie visible de la carte l intersection entre (AB) et le bord inférieur de la partie visible de la carte l intersection entre (AB) et le bord gauche de la partie visible de la carte l intersection entre (AB) et le bord droit de la partie visible de la carte Le repère utilisé étant les positions en pixel sur la carte (l image). On défini le vecteur v : { v1 = x B x A v 2 = y B y A L équation de la droite (AB) avec A(x A ; y A ) et B(x B ; y B ) est l ensemble des points M(x M ; y M ) tel qu il existe k tel que : { xm = x A + kv 1 y M = y A + kv 2 Les équations des bords de la partie visible de la carte étant des simples équations de droite de la forme ax + by + c = 0, par exemple pour le bord supérieur : { x = xv On cherche une solution au système d équation suivant : x = x A + kv 1 y = y A + kv 2 0 = ax + by + c x = x A + kv 1 y = y A + kv 2 0 = a(x A + kv 1 ) + b(y A + kv 2 ) + c ax A + kav 1 + by A + kbv 2 + c = 0 k(av 1 + bv 2 ) = (ax A + by A + c) k = ax A+by A +c av 1 +bv 2 Le système admet une solution si av 1 + bv 2 0 et dans ce cas nous calculons l intersection I comme { xi = x suit : I = A + kv 1 y I = y A + kv 2 Puis, pour accepter l intersection (pour vérifier qu elle est sur [AB]), nous procédons également de la même manière qu en réalité augmentée en vérifiant que le facteur q tel que : AI = q AB Soit dans l intervalle [0; 1] Point le plus proche d un bâtiment Lorsqu un utilisateur veut se diriger vers un lieu de l université, que ce soit un bâtiment ou une salle par exemple, il est logique de lui fournir le point le plus près vers ce lieu, la porte la plus proche d une salle ou le point le plus proche d un bâtiment. Cependant, concernant les bâtiments nous ne connaissons que les positions GPS des quatre coins de ce bâtiment (cas d un bâtiment rectangulaire) et de fait, le point le plus proche d un bâtiment serait un coin même si nous nous trouvons juste à côté du bâtiment, au milieu par exemple. Voici le schéma illustrant le problème : 38

40 Il serait plus convenable de fournir le vrai point le plus près du bâtiment, que ce soit un coin du bâtiment ou sur un mur, comme ci-suit : On cherche donc à trouver le point d un bâtiment le plus proche qu il soit un coin du bâtiment où un point d un des murs de ce bâtiment. Pour cela, il nous faut donc pour chaque mur, calculer le point le plus près. Ensuite, il nous faudra utiliser la position GPS la plus proche de la position courante parmi : les positions des coins du bâtiment les positions les plus proches de chaque mur du bâtiment Pour calculer les coordonnées GPS du point le plus proche d un mur du bâtiment, nous allons utiliser le théorème d Al-Kashi pour tout d abord calculer les angles ACB et ABC de la manière suivante : ACB = arccos( BC2 +AC 2 AB 2 ) et ABC = arccos( BC2 +AB 2 AC 2 ) 2 BC AC 2 BC AB Cela nous permet de savoir si l un des angles ˆB et Ĉ est supérieur ou égal à 90 ce qui implique que le point le plus proche du mur est un coin du bâtiment. Dans ce cas, inutile de calculer la position de ce point. Dans le cas contraire, il nous faut maintenant trouver la distance h qui est la distance entre la position de l utilisateur et le point du mur le plus proche. Pour cela nous allons utiliser les lois de trigonométrie : h = AC sin(ĉ) Maintenant nous devons déterminer le facteur k tel que : P p = C + k CB avec Pp la position du point le plus près Tout d abord, il nous faut utiliser le théorème de Pythagore pour trouver la distance d entre P p et C : d = AC 2 h 2 Ainsi, on calcule très simplement k : k = d BC 39

41 Et finalement on détermine la position GPS de P p : lat(p p ) = lat(c) + (lat(b) lat(c)) lon(p p ) = lon(c) + (lon(b) lon(c)) alt(p p ) = alt(c) + (alt(b) alt(c)) Nous avons donc finalement les coordonnées GPS correspondantes au point le plus près pour un mur (ici le mur BC). 40

42 12 Acquisition et structuration des données Nous avons dû acquérir des données géolocalisées pour la réalisation de notre application. Ces données viennent de plusieurs sources et ont été structurées dans un fichier XML embarqué dans l application, puis sont chargées dans une base de données SQLite au premier lancement de l application pour faciliter leur exploitation dans le code exécutable de l application Acquisition des données Nos données viennent principalement du site Openstreetmap.fr sur lequel nous avons pu télécharger sous la forme d un fichier XML les positions GPS de tous les bâtiments de l université. Pour chaque bâtiment, nous disposions alors d un certain nombre de position GPS nous permettant de situer les contours de celui-ci. Ces données étaient parfois en trop grand nombre, par exemple pour un bâtiment rectangulaire, seule quatre positions GPS suffisent pour connaître ses contours. Nous avons également du concevoir une petite application nous permettant de récupérer quelques positions GPS avec nos téléphones. Cela nous a notamment servi pour positionner quelques points clés de l université et surtout à connaître l altitude des bâtiments (information qui n était pas fournise par OpenStreetMap). Tri des données d Openstreetmap Les données d Openstreetmap ont donc dû être triées car celle-ci contenaient un trop grand nombre de positions GPS pour certains bâtiments en plus d autres données dont nous n avions pas besoin comme les positions GPS des routes qui traversent l université. Nous avons donc utilisé une simple feuille de style XSL pour extraire les données des bâtiments depuis le fichier XML obtenu sur Openstreetmap vers un fichier XML structuré selon nos besoins. Il a donc fallu par la suite trier les coordonnées et éliminer celles qui étaient superflues. Une technique simple pour les bâtiments rectangulaires a été de récupérer le point dont la latitude était la plus faible pour avoir le point le plus bas puis le point dont la longitude était la plus grande correspondant au point le plus à droite, puis la latitude la plus haute pour le plus haut et enfin la longitude la plus faible pour le dernier point le plus à gauche (l ordre des points dans le fichier a son importance pour faciliter le dessin des contours d un bâtiment). Cette manipulation ayant pour effet de bien récupérer les quatre coins du rectangle, pour les bâtiments ayant une forme plus complexe, nous avons dû sélectionner les positions minimales pour la représentation ce ceux-ci en regardant sur Google Map où se situe chaque position de ce bâtiment. Acquisition de donnée Pour les données non disponible, nous avons développé une petite application pour nos téléphones Android nous permettant de mémoriser des positions GPS (altitude inclue) avec un nom dans un fichier XML sur la carte mémoire du téléphone. Nous avons ensuite extrait de ce fichier XML les positions GPS pour les ajouter dans notre fichier XML embarqué dans l application. Les positions manquaient souvant de précision (surtout pour celles dans ou très proche d un bâtiment) et nous avons du faire usage de Google Map pour les vérifier et même parfois les prendre directement. 41

43 12.2 Le format des données Nous aurons donc essentiellement dans notre base de données des positions GPS qui sont définies par : Latitude, correspondant aux parallèles du globe Longitude, correspondant aux méridiens du globe Altitude, correspondant à la hauteur par rapport à un ellipsoïde Pour exploiter ces données dans le code exécutable, nous disposons dans l API Android de la classe Location qui représente une coordonnée GPS. Ces données GPS sont pour certaines accompagnées de données textuelles. Ces données sont tout d abord stockées dans le fichier XML embarqué dans l application ayant cette syntaxe : <way name="batiment 10" height ="5"> <node l a t =" " lon =" " a l t ="104"/> <node l a t =" " lon =" " a l t ="104"/> <node l a t =" " lon =" " a l t ="104"/> <node l a t =" " lon =" " a l t ="104"/> </way> <p o i name=" Poi 7 Amphithéâtre Dumontet " i c o n =" provider_icon_dumontet"> <pos l a t =" " lon =" " a l t ="100.0"/ > </poi> <p l a c e name=" S a l l e TD16.03" > <entry l a t =" " lon =" " a l t ="105.0" /> </place > <pnode id ="far_road " l a t =" " lon =" " a l t ="104"/> <edge id1 ="cross_near_bu " id2 ="far_road "/> Comme nous pouvons le constater ci-dessus, il y a décrit dans ce XML un bâtiment avec ses coordonnées, ainsi qu une salle, suivie d un noeud de chemin (croisement), et d une arête reliant deux noeuds Mise en place de la base de données Afin de pouvoir exploiter toutes ces coordonnées, nous avons ensuite utiliser un SAXParser fourni par l API d Android, afin d analyser le fichier XML embarqué pour inclure toutes ses informations dans la base de données. La base de données n est remplit que si elle est absente (si son fichier est absent), c est le cas lors du premier lancement ou si les données de l application on été effacée. Il nous a fallu représenter huit éléments : Les bâtiments Les salles Les points d intérêts (POI) 42

44 Les positions des bâtiments Les positions des salles Les positions des points d intérêts Les croisements (noeuds) Les chemins (arêtes) Ci-dessous le modèle UML de la base de données : Et le modèle relationnel associé à ce diagramme : Batiment(numero, description, hauteur) Salle(code, #numerobatiment, numerosalle, description) Poi(titre, #numerobatiment, icon) PositionBatiment(#numeroBatiment, latitude, longitude, altitude) PositionSalle(#codeSalle, latitude, longitude, altitude) PositionPoi(#titrePoi, latitude, longitude, altitude) Node(id, latitude, longitude, altitude) Edge(#id1, #id2) Les requêtes Concernant les requêtes pour la table N ode et Edge, celles-ci sont implémentées directement dans l algorithme de remplissage du graphe pondéré (classe Graphe en pattern Singleton) et s exécutent juste avant premier appel de la fonction disjkstra (dans la classe Dijkstra). Ces requêtes sont de la forme : SELECT id1, id2 FROM Edge ; Permet de l i s t e r chaque a r ê t e en renvoyant l id des deux sommets SELECT FROM Node WHERE i d = " un_id_de_sommet " ; S e l e c t i o n n e t o u t e s l e s information concernant un Node Dans le cas des bâtiments, salles, les points d intérêts et leur(s) position(s), nous avons trois types de requête distincts. Ces requêtes sont implémentés dans des fonctions de la classe T ablesbdd, afin qu elle puissent être appelées plus facilement dans différentes classes de l application. 43

45 Elles sont de la forme : SELECT FROM Batiment WHERE numero = " numéro_recherché " ; Permet de f o u r n i r t o u t e s l e s i n f o r m a t i o n s sur un bâtiment SELECT l a t i t u d e, longitude, a l t i t u d e FROM Batiment WHERE numerobatiment = " un_numero_de_batiment " ; S e l e c t i o n n e t o u t e s l e s coordonnées correspondant à un bâtiment Cette base de données est simple tout comme les requêtes, elle est toutefois bien adaptée à notre utilisation et optimisée au sens elle ne ralentit pas l exécution des fonctionnalités l application Premier chargement Nous avons porté une attention toute particulière au chargement du fichier XML dans la base de donnée de façon à ce qu il soit le plus efficace possible. L analyse avec un SAXP arser est assez efficace mais nous avons également du faire la gestion des transactions lors du remplissage de la base de données. En effet, par défaut chaque insertion correspond à une transaction ce qui ralentissait très fortement le chargement car cela provoquait des accès à la mémoire de stockage du téléphone qui est relativement lente. Ainsi, nous lançons le début d une transaction, puis nous remplissons notre base de données et nous terminons la transaction seulement après que toutes les insertions aient été réalisées. 44

46 13 Service web Afin de rendre notre application plus complète, nous avons mis en place un service web nous permettant d y ajouter des point d intérêt. Cela pourrait être des conférences par exemple ou tout autre événement pouvant avoir lieu dans l université. L application télécharge les points d intérêt depuis le service web et les affiche à l utilisateur comme tout autre information, de manière transparente. Ce service web permet l ajout d événement dans les deux langues actuellement supportées par l application via une interface web, le Français et l Anglais. Les points d intérêt peuvent être paramétrés pour n être envoyés en réponse à une demande de l application que sur une période déterminée. Les points d intérêt peuvent être accompagnés d une image pour qu ils soient plus attrayant une fois affichés à l utilisateur, les informations essentielles étant le titre (billingue) et la description (billingue). Le positionnement dans l université se fait aisément à l aide de l API Google Map depuis le navigateur. Il est possible d ajouter et de supprimer à volonté des événements, l application effectuant des mises à jour régulières de ces informations lorsque l utilisation du service web est sélectionné dans le menu des informations à afficher, les modifications apparaîtrons relativement rapidement à un utilisateur Fonctionnement Ce service web est hébergé sur un serveur apache, il est écrit en PHP et utilise un base de données MySQL pour le stockage des informations. L application effectue une requette HTTP pour récupérer les points d intérêt, cette requête est paramétrée par la langue dans laquelle est lancée l application, ce qui permet de renvoyer la traduction qui convient. Le format d échange est le JSON(JavaScript Object Notation) qui est facilement analysé par l application 45