Walking the edit

INTRODUCTION:

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

Une vision de la carte avec nuage vert ainsi que trajet et position actuelle

DÉVELOPPEMENTS EN COURS:

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

Quelques pistes de fonctionnalités, de présentation et de règles de jeu:

- Opération de START / STOP (comme une caméra) pour définir le point de départ, le point d’arrivée (et donc la durée).
- Max de durée définie par film: 3o minutes.
- Il peut y avoir plusieurs films en fonction du start / stop…

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…

Une simulation de l’interface du module embarqué:

Stade actuel:

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