PHASE 2

En cours d’élaboration. Dernière mise à jour le 25.01.2009

Après avoir testé une solution industrielle (voir archive phase 1 ci dessous), 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 et d’arrivée qui parfois partent dans les fraises (le moteur d’analyse devra les “shooter” pour éviter les erreurs de montage). Pour garantir les meilleurs résultats, il faut éviter de faire des parcours par temps trés nuageux ou brumeux – on améliore également la précision si l’on “chauffe” le GPS via google map (on est tout de suite bon après dans l’interface du projet);
- sur la question du débit DATA: Orange semble moins bon que Swisscom (400kbit en moyenne pour Orange via le 3G alors que Swisscom permet presque 1000kbit dans les mêmes conditions);
- les capacités en terme d’affichage, de mixage et de puissance de calcul ne permettent pas d’effectuer tous les calculs en direct sur l’Iphone, donc il s’agit de décentraliser un maximum sur un serveur centralisé. L’Iphone ne ferait donc qu’envoyer le flux GPS et recevoir en retour un flux data qui permettrait d’afficher la présentation du processus en cours ainsi que de permettre l’écoute du flux audio;
- il serait donc possible de mettre à disposition une application à télécharger sur n’importe quel Iphone 3G – cette application ne ferait que gérer les flux entre l’appareil et le serveur et serait donc légère et pas trop gourmande;
- reste la question de la customisation des appareils prêtés au public: il fait verrouiller la possibilité de sortir de l’interface du projet (le bouton Home inopérant);
- l’autre point faible est le temps batterie, mais nous avons des solutions de batterie additionnelle.

 L’interface et utilisation de l’Iphone durant le parcours: quelques réflexions et pistes de travail.

Comme décrit ci dessus, l’Iphone est au minimum l’interface qui permet d’enregistrer le tracé (via GPS) et d’écouter le film en train d’être marché (via un mixage audio en temps réel). A priori, nous n’aurions pas besoin de plus pour permettre la réalisation du projet, à savoir le montage d’un film à partir d’un parcours.

L’utilisation d’une interface pour la navigation ainsi que pour la visualisation du processus en cours n’est pas strictement nécessaire pour le projet et ne devrait pas déconcentrer le visiteur de la relation particulière qu’il tisse avec le contexte urbain à travers notre dispositif. En effet, le but sous jacent du dispositif global est de permettre une confrontation / immersion dans la réalité connue en permettant un filtrage et une réduction des multiples strates du réel pour pouvoir déclencher la construction mentale d’un “film” imaginaire…
Le parcours effectué dans le but de construire un film, en étant accompagné par le flux sonore du film en train d’être marché devrait déjà permettre une stimulation de l’imagination du visiteur, en lui faisant sentir que son parcours va faire sens et que les fragments sonores qu’il entend sont une dimension condensée de ce qu’il a sous les yeux.

Néanmoins, nous pensons qu’il est souhaitable et intéressant d’essayer d’offrir la visualisation du processus en cours, à savoir l’écriture d’une histoire (dans le sens non narratif) qui contient passé, présent et futur (des potentialités) basée sur le parcours en cours. Vu que le visiteur effectue un montage d’un film sans en voir les images, on imagine que s’il voit une représentation artificielle du processus en cours, cela pourrait lui permettre (en plus des enjeux décrits ci dessus) les choses suivantes:
- voir qu’il écrit une trace (parcours et médias choisis) – contrairement au cerveau humain où la mémoire est “évasive”, il a accès à la “mémoire” de son parcours via l’interface de l’Iphone;
- pouvoir représenter le moment présent dans un flux qui est composé d’un passé et d’un futur – un peu comme si le piéton avait accès à un rétroviseur qui lui permet d’avoir dans un seul champ de vision le chemin effectué (le passé) et le moment présent dont l’horizon constitue le futur;
- il voit l’effet de son parcours en temps réel: il déclenche un processus fait de choix (passé et présent) et de potentialités (le futur). Plus il marche vite, plus les médias représentés sont petits, plus il ralentit, plus les médias augmentent de taille; il a ainsi une représentation graphique de l’incidence de son rythme sur le choix des médias;
- il peut essayer de cueillir le prochain média de manière plus consciente (selon la présentation du futur), mais sachant qu’au final c’est son parcours (ses pieds) qui fait les choix, la réussite de cibler des médias bien précis est de l’ordre d’une performance…
- permettre un rapport ludique au processus en cours: le fait de devoir marcher son film devrait stimuler l’imaginaire mais aussi l’intellect – les représentations spatiaux-temporelles de la dimension artificielle du processus en cours sont pas éloignées des mondes artificiels existants dans certains jeux (citer quelques exemples – je suis pas spécialiste dans la matière, mais des comparaisons ont déjà été faites par certains colaborateurs);
- la visualisation du processus et plus importante que la représentation cartographique du parcours: nous souhaitons nous concentrer sur la présentation du processus, qui est en même temps hautement artificiel comme étant organique (faisant partie d’un ensemble d’interactions partant des pieds du visiteur et passant par un serveur qui calcule un montage à partir de chiffres envoyés par un téléphone). La question de savoir “où je suis dans le territoire réel” est moins importante que de savoir “dans quelle dynamique je me trouve dans la création de mon film”.

En somme, toutes ces pistes là fonctionnent seulement si elles ne sont pas illustratives d’une réalité visible et appréhendable, mais suggestives d’un ensemble de réalités parallèles qui sont l’addition du parcours réel, du placement d’une couche média sur le territoire ainsi que l’enclenchement d’un processus de filtrage et de montage de médias via des métadonnées…

Ceci étant posé, afin de pousser ces hypothèses sur le terrain et de les éprouver, il s’agit maintenant de trouver des traductions graphiques dynamiques (c’est important que la présentation soit aussi fluide qu’une marche urbaine peut l’être). Vincent Jacquier et Dimitri Delcourt vont travailler d’ici fin février sur quelques pistes développées ensemble – plus de précisions concrètes donc fin février…

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…)