PHASE 2

Après avoir testé une solution industrielle, nous avons démarré la phase deux en faisant quelques tests avec l’Iphone 3G de Apple.

Ce qui ressort sont les points suivants:
- le GPS est tout à fait utilisable, surtout s’il est couplé à la triangulation des antennes de téléphonie. Les parcours enregistrés sont donc très proches de la réalité, mis à par les points de départ qui parfois partent dans les fraises;
- les capacités en terme d’affichage, de mixage et de puissance de calcul sont suffisantes pour nos besoins (en adaptant un peu)
- le gros bémol est au niveau de la disponibilité des fichiers audio, qui prennent bien entre 1 et 2Go de mémoire. Pour la présentation en juin avec les Iphone dédiés au projet, nous allons les configurer par avance, mais pour la suite, le fait de devoir télécharger 2Go de fichiers n’est pas très engageant… Les solutions de streaming existent, mais aucune n’est réellement idéale.
- l’autre point faible est le temps batterie, mais nous avons des solutions de batterie additionnelle.

Prochainement quelques screenshots et images de l’interface et du fonctionnement de l’Iphone du projet.

PHASE 1 (archive)

Pour la fin de la phase 1, nous n’allons pas pouvoir nous fixer sur un choix définitif de module embarqué, pour les raisons suivantes:
- Nous n’avons pas encore pu tester toutes les solutions existant sur le marché actuellement, notamment la toute nouvelle version de l’Iphone (et son SDK) ainsi que les nouveaux processeurs basse consommation (exemple);
- Nous allons tester de manière virtuelle (simulations en software) les solutions d’affichage, de calculs en temps réel (l’analyse), de manière à rester le plus ouvert possible (pouvoir changer de plateforme le plus simplement possible)
- par rapport aux besoins déterminés au départ de la recherche, il y a eu quelques modifications: au niveau puissance graphique, nous avons besoin de pouvoir afficher plusieurs layers et de calculer beaucoup d’informations (donc carte graphique puissante nécessaire); intégration d’une couche interactive pour permettre plus d’interactivité de la part du visiteur (nécessite une bonne réactivité du système dans son ensemble).

Nous visons l’automne 2008 pour arriver au bout de nos tests et de pouvoir choisir une plateforme qui soit la plus adéquate; d’ici là nous allons faire le nécessaire afin de garantir une interopérabilité du code (le portage sur la solution choisie sera vite effectué).

Voici les caractéristiques techniques et une image du module_embarqué que nous avons choisi pour cette première phase:

-> Max Resolution 800 * 480
-> Brightness(cd/m2) 350
-> Contrast Ratio 400:1
-> LCD Color 262K
-> Pixel Pitch (mm) 0.1905(H) x 0.1905(V)
-> Viewing Angle(H-V) 140/110
-> Backlight MTBF 30000
-> CPU AMD Geode™ LX 800 (500MHz)
-> Chipset AMDGeode™ LX 800
-> Touch Screen ResistiveType4-Wire
-> Power Consumption 20W

Le profil idéal du module embarqué (Ultra portable PC / PDA / téléphone / Ipod Touch avec module GPS):

- écran de bonne qualité (VGA idéalement - sinon avec la possibilité de zoomer sur la carte, rapport de contraste adéquat pour une utilisation en plein soleil) – solide – rapide – autonomie minimum 5 heures – portable : petit et léger (devrait se porter en bandouillère) – avec interfaces bluetooth et / ou WIFI – extension carte mémoire souhaitée mais pas indispensable.

- module GPS sensible, rapide et précis (précision à 3 mètres souhaitable) Idéalement, le « lissage » des données venant du GPS est directement fait lors du parcours, selon des paramètres que nous décidons.

- accéléromètre: afin de pouvoir enregistrer des comportements et d’affiner l’analyse du flux GPS. Les premiers tests ont montré la difficulté de dompter les données sortant de ces outils, mais nous comptons tout de même utiliser ce type de données pour l’analyse.

- système d’exploitation permettant la conception d’applications « maison » : base de données audio pilotée par les données issues du GPS (lissés) ; visualisation d’une carte personnalisée avec zones thématiques en superposition
(variantes à tester : possibilité de déterminer le type de narration ; zoomer dans la carte ; voir son trajet inscrit sur la carte en temps réel ; écrire des textes / mots lors de la déambulation ; etc)

- optionnel / à tester : appareil avec capteur photographique, permettant à l’utilisateur de créer des images lors de son parcours. Questions : doit-on restreindre / piloter l’utilisation de cette option (images seulement possible dans un certain endroit ; ou alors après un certain temps d’inactivité ; etc) ?

Les opérations suivantes devraient pouvoir être possibles sur ce module embarqué:

- importer une base de données contenant que des fichiers son venant du serveur (base en PostGresql) - le format des fichiers reste à voir (AAC, AC3, aif etc). Le poids total des fichiers son ne devrait pas excéder 5Go; par contre, on devrait pouvoir synchroniser les deux bases pour tenir à jour le module embarqué (rajouter les derniers sons rajoutés)
- s’il n’y a pas de GPS intégré, lier un gps externe (de type wintec, Navilock, Holux) avec le module embarqué
- pouvoir récupérer le tracé GPS en temps réel, effectuer un “lissage” de ce tracé (afin d’éliminer les points aberrants) et ramener le chemin sur des rails pré-établis, puis l’interpréter (faire une analyse qualitative du parcours afin de déterminer le type de parcours que fait la personne)
- mixer et lire en temps réel entre 2 et 4 pistes son, restituées en fonction de l’emplacement géographique et de l’analyse qualitative du parcours
- afficher la carte du lieu avec les zones thématiques superposées, permettre la fonction zoom afin de changer d’échelle et d’afficher des informations différentes, afficher la position exacte et le parcours
- interagir avec la carte, afficher ou escamoter des layers

Le couplage du module embarqué avec le GPS doit se faire à l’intérieur d’une coque à concevoir spécialement pour ce projet (design d’objet et relation avec la charte graphique du projet): cet objet doit se faire discret, facile à manipuler (on ne peut que faire les opérations utiles dans le cadre du projet) et léger…
Concernant le matériel cartographique, l’idéal serait de reprendre une base existante, d’en garder que l’essentiel (base vectorisée) et de joindre de manière adéquate et fonctionnelle la carte du territoire et la représentation de la base de données (les thèmes).


UPDATE du 29.02.2008

Le SDK de l’Iphone est repoussé, mais des informations on filtré comme quoi il sera très restrictif, et ne sera pas vraiment ouvert à intégrer du hardware extérieur (style notre module GPS); il est donc pour le moment plus d’actualité d’utiliser l’Iphone ou l’Ipod Touch.

UPDATE du 13.02.2008

Documents techniques concernant l’Ipod Touch (avec l’exemple de l’Iphone, mais c’est la même base):

iPhone Human Interface Guidelines

iPod Notes Feature Guide

Web Kit DOM Programming Topics

Safari Web Content Guide for iPhone

———————————————-

Lien internet pour l’utilisation de Linux sur ce genre de machines (pour le moment, l’Ipod Touch n’est pas compatible…)