Tomtom Go : une plate-forme pour l’acquisition sans fil de mesures géoréférencées

1. Introduction

Le Tomtom Go est un récepteur GPS contenant un logiciel propriétaire pour la navigation, exécuté sous GNU/Linux sur un processeur ARM9[1]. Une liaison bluetooth sur le modèle 720 est par ailleurs fournie pour se connecter à des périphériques ne nécessitant qu’un faible débit de communication, tels que les téléphones portables.

Tomtom a documenté les logiciels sous GPL utilisés sur leur récepteur, et fournit une toolchain de crosscompilation. Ceci a permis le projet Opentom, qui démontre la capacité à développer des applications fonctionnelles. Les exemples disponibles1 fournissent les bases de développement utiles pour le reste de cette discussion : une console en mode texte avec un clavier sur l’écran tactile, un enregistreur de traces (pour exploitation sur une application telle qu’Openstreetmaps)2, les scripts nécessaires à ouvrir un terminal sur la liaison bluetooth, ... Ces outils vont nous permettre de nous connecter au Tomtom Go et d’y développer des applications additionnelles. Néanmoins, nous allons ici utiliser le système d’exploitation non pour fournir la capacité à charger dynamiquement un binaire et les bibliothèques associées, mais pour l’interpréteur shell qui est associé à GNU/Linux ainsi que la pile bluetooth du noyau.

Bluetooth est un protocole de communication radiofréquence fonctionnant dans la bande libre (Instrumentation Scientifique et Médicale – ISM) autour de 2,45 GHz. Trop lent pour permettre une communication efficace, trop long à s’associer à ses interlocuteurs pour permettre une gestion efficace de l’énergie, c’est un protocole qui ne doit probablement sa disponibilité dans à peu près tout équipement portable grand public, qu’à la puissance commerciale des grands groupes industriels qui ont dirigé son développement. Nous allons néanmoins essayer de trouver une application qui justifie l’utilisation d’une liaison bas débit sans fil : la mesure de grandeurs scalaires (température) sur un objet en mouvement qui ne permet pas de liaison filaire (ni en alimentation, ni en communication) entre l’ordinateur de traitement et stockage des informations et le capteur.

L’objectif que nous visons est donc le stockage d’informations géoréférencées acquises au moyen d’une liaison sans fil. La justification de la liaison sans fil est de placer le capteur sur un support mobile ou rotatif qui ne permet pas une liaison filaire : une application qui en découle naturellement est la mesure de température du pneu d’un véhicule, avec affichage de l’information en temps réel à l’utilisateur.

On s’intéressera à deux aspects du développement : d’une part, le système de mesure de température qui doit fonctionner sur la batterie (puisque fixé sur la roue) et fournir une autonomie au moins compatible avec un trajet d’une journée, pendant lequel le récepteur GPS Tomtom est alimenté sur batterie de la voiture (on espère donc dépasser l’autonomie du Tomtom sur batterie, qui n’est que de l’ordre de 1,5 à 2 h pour le modèle 720). De façon plus générale, les outils mis en œuvre seront exploitables pour observer une grandeur physique agissant sur la résistance électrique d’un transducteur (applicable à une vaste gamme de mesures, des jauges de contraintes aux capteurs de gaz à oxydes métalliques, en passant par l’intensité lumineuse pour une photorésistance). La communication numérique des informations implique l’utilisation d’un microcontrôleur, ici le MSP430, et la gestion d’énergie associée. D’autre part, la communication des informations par une liaison sans fil et leur restitution à l’utilisateur au travers de l’interface propriétaire mais documentée du Tomtom Go. L’objectif est de conserver la fonctionnalité de guidage, augmentée des informations acquises par le(s) capteur(s), et ce en faisant appel exclusivement par l’utilisation des outils mis à disposition par GNU/Linux au travers du shell bash, sans nécessiter la programmation de nouvelles applications.

2. Le Tomtom : un ordinateur sous GNU/Linux

Nous exploiterons au cours de cette présentation le Tomtom Go 720 : cet ordinateur est équipé d’un processeur ARM9 cadencé à 400 MHz, entouré de 64 MB RAM et 2 GB de stockage non volatil (a priori de la mémoire flash, d’après le nom du device /dev/sdcard monté dans /mnt/sdcard, malgré le symbole de disque dur apparaissant à l’allumage)3. Ces caractéristiques matérielles ne sont importantes que pour obtenir sur le Web les binaires des programmes qui nous manquent, puisque nous allons exploiter au maximum le système d’exploitation préinstallé et ainsi économiser l’effort de programmer des outils déjà accessibles via le shell.

Une distribution dédiée de Linux, avec un noyau modifié, a été mise en place par Tomtom, tandis que les outils accessibles aux utilisateurs sont en grande partie fournis par busybox. Les outils de la bibliothèque de gestion bluetooth bluez [2] sont également disponibles et permettent de rapidement communiquer avec le Tomtom sans recompiler les logiciels embarqués (et donc notamment de développer sur Tomtom sans avoir à en modifier le contenu). Nous allons donc nous familiariser avec l’interaction avec le système installé sur Tomtom afin de déterminer les possibilités et contraintes du système de mesure avec lequel nous voudrons communiquer.

L’accès depuis l’interface graphique (Fig. 1) aux scripts et programmes que nous développerons se fait au travers du répertoire SDKRegistry (attention aux majuscules et minuscules selon que l’on accède au Tomtom par liaison USB de classe mass storage sous MS-Windows ou GNU/Linux). Ce répertoire contient une liste de paramètres de configuration dans un fichier d’extension .cap [3], avec notamment le PATH (AppPath), l’image bitmap de l’icône, le nom de l’application exécutée lorsqu’on appuie sur l’icône (AppName) ... Ainsi, ayant accédé au support de stockage non volatil du Tomtom tel que décrit dans le paragraphe suivant, nous mettrons à jour le répertoire SDKRegistry pour y placer notre application (binaire exécutable ou script shell) qui deviendra accessible depuis l’interface graphique, en prenant soin d’ajouter tous les outils nécessaires au PATH.

3. Les outils pour développer sur Tomtom

Le premier outil qui vient à l’idée pour découvrir les fonctionnalités d’une nouvelle plate-forme est une console : un tel outil est fourni à http://www.opentom.org/TomTom_Console. Un clavier virtuel permet de taper sur l’écran tactile – il est judicieux à cet effet de se munir d’un stylet dédié à cette opération – les commandes classiques fournies par busybox (Fig. 2). Notez néanmoins que la console ne fonctionne qu’avec un firmware suffisamment ancien, puisque les dernières versions du logiciel de navigation reprennent rapidement la main en rafraîchissant l’écran : tous les tests présentés dans ce document ont été effectués sur un Tomtom Go 720 muni de l’application 7.010 (8290/07711), OS version 2618, boot version 5.4062 et GPS version 1.21. Après avoir découvert les fonctionnalités du shell (bash) et les outils mis à disposition par la distribution GNU/Linux embarquée, nous voudrons taper nos commandes via une interface plus efficace que le clavier virtuel.

Le support bluetooth fournit ce qui deviendra notre interface de communication privilégiée : activée à l’origine pour s’interfacer avec un téléphone mobile, nous commencerons par reconfigurer cette interface pour créer un port série virtuel au moyen des scripts mis à disposition4. En lançant la Bluetooth Console, le Tomtom Go crée un serveur de connexion sur un port série virtuel. Du côté du PC, un convertisseur USB-Bluetooth nous fournit une interface sur ce protocole de communication tel que le valide la commande hciconfig. Ayant une interface bluetooth fonctionnelle, l’adresse matérielle (équivalent de l’adresse MAC pour ethernet) MAC_TOMTOM s’obtient par sdptool browse. Finalement, le port série virtuel /dev/rfcomm0 est associé au Tomtom par rfcomm bind 0 MAC_TOMTOM 1. La liaison est réellement mise en place lors de l’exécution d’un client se connectant au terminal série (par exemple minicom) sur /dev/rfcomm0 au débit de 9600 bauds.

À ce point, nous avons pu exploiter la liaison bluetooth pour créer un lien avec une console exécutée sur le Tomtom. Nous avons donc ici une méthode exploitable pour qu’une application de traitement et d’affichage de données reçoive les informations par ce port série virtuel. Cette méthode est d’autant plus attractive qu’elle permet de sérier les problèmes : tester l’application de liaison asynchrone (RS232) sur PC, porter au Tomtom sur la liaison bluetooth, puis ajouter les interfaces avec l’utilisateur. Bien qu’une toolchain5 pour Tomtom soit disponible, nous allons changer notre habitude de développer un programme compilé depuis un langage de haut niveau (C) pour générer une application, mais nous allons exploiter la disponibilité d’un shell et des outils GNU associés pour ne programmer qu’en bash.

4. Électronique de mesure de température et conversion au format numérique

4.1 Mesure de résistance

Le Tomtom va nous servir à enregistrer, localiser et afficher une grandeur mesurée. Nous allons ici développer un aspect original – ou tout au moins inhabituel mais bien documenté [4] : la mesure de température au moyen d’une sonde résistive selon des contraintes compatibles avec une application embarquée faible consommation.

Classiquement, une sonde de température se mesure au moyen d’une source de courant et mesure par amplificateur différentiel de la chute de tension associée à la variation de résistance en fonction de la température, ou par pont de Wheatstone dont un des bras contient la résistance à mesurer [5]. Cependant, ces solutions nécessitent d’une part des amplificateurs opérationnels qui, sauf cas exceptionnel (disponibilité d’un signal de mise hors tension), doivent être continuellement alimentés, et d’autre part la mise en place d’astuces pour fonctionner en alimentation unipolaire (et non alimentation symétrique telle qu’on a l’habitude d’employer sur amplificateur opérationnel).

La mesure de la résistance par circuit RC [4] que nous nous proposons d’exploiter présente l’avantage de ne nécessiter que peu de composants additionnels autour du microcontrôleur en charge de la mesure (un condensateur et une résistance de référence), de ne pas nécessiter de convertisseur analogique-numérique (souvent gourmand en énergie) et d’être désactivé lors de la mise en veille du microcontrôleur.

Néanmoins, certaines précautions doivent être mises en place pour la mesure de résistance sous forme d’une constante de temps. Tout d’abord, la détection précise de seuil (comparateur) et de temps (timer) doivent être disponibles sur le microcontrôleur utilisé. Ces prérequis étant satisfaits par le choix du Texas Instruments MSP430F149 [6] (Code 1 et Fig. 3), il nous faut appréhender la technique de mesure pour en identifier les faiblesses :

- La mesure d’une constante de temps s’obtient dans un premier temps en chargeant un condensateur C pour lui permettre d’atteindre un potentiel connu, puis de le décharger au travers de la résistance R à identifier : ce temps de décharge est associé à la constante de temps τ=RC. Nous identifions ici une première contrainte : le potentiel de charge du condensateur doit toujours être le même, d’où la nécessité d’une régulation de la tension d’alimentation du microcontrôleur.

- Un condensateur est un composant qui évolue considérablement dans le temps (vieillissement) et avec son environnement (température), polluant ainsi la mesure de résistance. Nous ne travaillerons par conséquent jamais sur la valeur absolue de τ, mais sur un rapport de la mesure de la résistance inconnue R à une résistance connue de référence Rref. Ce rapport de temps τ/τref rend la mesure indépendante de C : τ/τref=R/Rref

- Cette mesure se multiplie facilement à un grand nombre de résistances de mesure, pour une unique résistance de référence. En effet, nous utilisons un port numérique d’entrée sortie (General Purpose Input Output, GPIO) comme source de courant lors de la charge du condensateur (potentiel en sortie égal à la tension d’alimentation) ou comme puits de courant lors de la décharge (GPIO en sortie au potentiel de la masse). Les autres broches du port sont pendant la mesure en entrée, c’est-à-dire en haute impédance, ce qui signifie qu’aucun courant ne circule dans ces broches, et par conséquent, n’affectent pas la mesure de constante de temps de charge et de décharge du condensateur.

Dans notre implémentation de cette technique de mesure, nous avons exploité 5 sondes de température Pt1006 et une résistance de référence. La constante de temps a été sélectionnée en choisissant un condensateur qui permette de travailler sur 10 bits d’un compteur compte tenu de la fréquence de l’horloge de référence fournie par un quartz à 4 MHz. Noter qu’un quartz de fréquence élevée consomme plus, mais permet d’obtenir une mesure précise plus rapidement afin de retourner le microcontrôleur en mode veille au plus vite.

Le calcul de la consommation électrique du circuit de mesure s’obtient comme suit :

- Nous savons qu’un condensateur de capacité C chargé à une tension U accumule une énergie E=1/2× C× U2 issue de la pile.

- Le temps caractéristique τ de charge et de décharge d’un condensateur C dans une résistance R est de l’ordre de τ=RC.

- Ce temps est mesuré par un compteur du microcontrôleur de b bits, cadencé par une horloge de fréquence f : τ∼ 2b/f.

- Nous en déduisons une relation entre la valeur du condensateur de charge C, la résistance des sondes de températures imposées par les standards (R∼ 100 Ohm pour une sonde Pt100), la fréquence f du quartz haute-fréquence du MSP430 (nous avons sélectionné f=4 MHz) et b=12 le nombre de bits exploités sur le compteur :

est de l’ordre de 10 µF et l’énergie nécessaire pour charger le condensateur est

soit, pour une tension U=3,3 V, une consommation de 55 µJ par mesure, consommés pendant une durée de τ=RC∼ 1 ms.

Nous pouvons donc nous interroger sur la pertinence d’une mesure de température nécessitant 55 µJ, considérant qu’un périphérique de conversion analogique-numérique consommant 1 mA sous 3,3 V pendant 1 ms ne consomme que 3,3 µJ pour une conversion. La stratégie proposée par la note d’application SLAA129B n’a donc un intérêt que par sa capacité à ne nécessiter aucun composant externe au microcontrôleur pour une mesure de résistance, et en particulier pas d’amplificateur opérationnel généralement associé à une gestion d’énergie complexe (par exemple pour une alimentation bipolaire) et gourmande en énergie. Ainsi, si les composants externes consomment au total 1 mA qui ne peut être désactivé en l’absence de mesure, alors la méthode de SLAA129B devient pertinente pour un rapport cyclique de mesure à veille de l’ordre de 10%. Une application classique consiste en une mesure toutes les quelques secondes, soit un rapport cyclique proche de 0,1%, pour lequel le gain énergétique est significatif par rapport à une mesure de résistance classique (pont de Wheatstone ou source de courant stable).

Code 1 : Programme implémentant en C sur MSP430F149 la stratégie de mesure de résistance par temps de décroissance d’un circuit RC et génération d’une interruption sur comparateur de tension. Notez l’utilisation du Timer B comme sécurité en cas de dysfonctionnement d’une des sondes résistives, qui se traduit par l’absence d’interruption du comparateur analogique.

Classiquement, un microcontrôleur communique avec son environnement par port série asynchrone (RS232). Ici, notre objectif est de placer le capteur sur un objet mobile, donc les liaisons filaires sont proscrites. Par ailleurs, le Tomtom ne possède qu’une interface bluetooth et pas de port asynchrone facilement accessible : nous allons donc exploiter un convertisseur RS232-Bluetooth – Free2Move7, pour communiquer le résultat de mesures au Tomtom Go.

Le dongle Free2Move se configure de diverses façons : soit au moyen d’un logiciel graphique disponible pour MS-Windows uniquement, mais fonctionnel sous GNU/Linux au moyen de wine (Fig. 4), soit en suivant les consignes de configuration fournies dans la notice d’utilisation8 et permettant de reconfigurer le dongle depuis le microcontrôleur à chaque mise sous tension (par exemple pour créer une liaison « sécurisée » avec un unique interlocuteur au lieu d’une configuration acceptant une communication de n’importe quel interlocuteur tel que nous allons le faire ici). Dans tous les cas, nous prendrons soin de configurer le module Free2Move en esclave (Endpoint) et acceptant la connexion de n’importe quel maître, permettant ainsi le debuggage rapide de l’application embarquée soit depuis le Tomtom, soit depuis un PC équipé d’une interface bluetooth. Cette phase de configuration détermine aussi le débit de la liaison asynchrone entre le microcontrôleur et le module Free2Move : nous avons choisi de travailler en 9600 bauds, fréquence accessible depuis le quartz 32 kHz cadençant le MSP430.

4.2 Gestion d’énergie

Deux alimentations sont nécessaires dans le circuit embarqué : l’alimentation du convertisseur RS232-Bluetooth (5 V) et le microcontrôleur (3,3 V). Afin de limiter le nombre et l’encombrement des batteries, nous avons opté pour n’utiliser que deux piles, et élever la tension à 5 V par un convertisseur DC-DC MAX856. Cette stratégie a pour vocation de gérer efficacement l’énergie, et notamment d’illustrer l’économie en désactivant l’alimentation des périphériques inutilisés, puisque la majorité des convertisseurs DC-DC possèdent une broche de désactivation de leur oscillateur interne, et donc de l’alimentation des composants qui y sont connectés. Il est ainsi possible de désactiver certaines portions du circuit inutilisées – ici le dongle Free2Move, seul composant alimenté en 5 V – tout en conservant les fonctionnalités d’acquisition de données ou de contrôle, alimenté directement par les piles.

Cependant, le bluetooth est en ce sens un mauvais exemple car il nécessite près de 10 s pour négocier sa connexion lors de la mise sous tension. Pour l’application qui nous intéresse, il n’est donc pas rentable de couper l’alimentation 3,3-5 V pour économiser l’énergie entre deux communications (une liaison par protocole zigbee, avec son temps de connexion qui se compte en fraction de seconde, est en ce sens plus efficace). Par ailleurs, il est apparu à l’usage qu’alimenter directement le microcontrôleur avec la pile qui est utilisée pour générer le 5 V est source de trop de bruit sur l’alimentation du microcontrôleur pour permettre une mesure exploitable. Nous avons donc élevé la tension des piles (qui doit être au-dessus de 1 V pour que le convertisseur fonctionne) à 5 V, pour en dériver l’alimentation du convertisseur RS232-bluetooth d’une part et, d’autre part, abaisser par régulateur linéaire 5V-3,3V (LE33CZ ou LM1117-3.3) la tension qui alimente le microcontrôleur, garantissant ainsi un potentiel de 3,3 V stable quelle que soit la tension aux bornes des piles. Cette tension d’alimentation stable est requise pour garantir un seuil de charge du circuit RC à un niveau connu lors de la mesure de R.

Par conséquent, nous proposons une gestion efficace de l’énergie avec élévation de la tension de deux piles en série vers 5 V pour en dériver une source stable d’alimentation du microcontrôleur sous 3,3 V, garantissant la stabilité nécessaire à une mesure précise de température (Fig. 5).

4.3 Robustesse aux défaillances mécaniques

L’utilisation intensive des interruptions matérielles permet une gestion efficace de l’énergie, puisque le microcontrôleur passe la majorité de son temps en mode veille (LPM1, Low Power Mode 1). Le danger, cependant, est de ne jamais être réveillé de ce sommeil en cas de dysfonctionnement d’un périphérique. Cette situation est rencontrée lorsqu’une liaison vers une des thermistances est rompue : les charges ne s’accumulent jamais dans le condensateur ou ne peuvent pas s’en évacuer, ce qui implique que l’interruption de passage de seuil de tension n’est jamais activée et le programme bloque pour ne jamais rendre la main au cours d’une mesure.

En effet, le principe de la mesure de résistance est basée sur une mesure de temps de décroissance d’une tension aux bornes d’un condensateur, temps proportionnel à la résistance qui limite le courant de décharge. Cette résistance a pour vocation à être placée au plus près du point de mesure, donc être exposée à un environnement mécanique rude qui peut éventuellement entraîner sa destruction. En l’état, l’ensemble du circuit de mesure est bloqué si une des résistances est détruite, puisque le microcontrôleur passe en mode veille pour attendre le déclenchement d’une interruption de comparaison de tension, interruption qui n’arrive jamais, puisque le condensateur ne peut plus se décharger (ni se charger) au travers de la thermistance détruite. La solution classique du chien de garde (watchdog) est ici implémentée manuellement au moyen d’un second timer, un délai beaucoup plus long que le temps de décroissance de la tension du condensateur : la sortie du mode veille du microcontrôleur s’effectue alors soit lorsque la mesure est correcte, soit lorsque le second timer a atteint sa limite. Dans ce cas, sans réinitialiser le microcontrôleur, nous passons à la mesure de résistance suivante et marquons la mesure comme erronée (le gestionnaire d’interruption étant différent, nous sommes capables de distinguer ces deux cas : code 1).

En conclusion de ce développement électronique, nous obtenons un instrument de mesure de température robuste, de consommation réduite. L’ajout du convertisseur RS232-bluetooth limite à lui seul l’autonomie du circuit puisque

- Le convertisseur DC-DC et le microcontrôleur consomment moins de 1 mA.

- Le régulateur linéaire de tension présente un courant de fuite qui peut être réduit sous le mA dans le cas du LE33CZ (le LM1117-3.3 présente un courant de fuite de près de 10 mA !).

- Le convertisseur RS232-bluetooth consomme moins de 1 mA en l’absence d’activité, pour passer à 7 mA lorsqu’un câble RS232 est branché, mais pas de communication asynchrone, pour grimper à 23 mA lors d’une communication RS232, mais absence d’interlocuteur bluetooth, et finalement atteindre 40 à 60 mA lorsque l’association bluetooth est réalisée.

Le précision de la mesure est établie lors d’un calibrage en enceinte climatique (Fig. 6) : nous constatons qu’une fois stabilisées, les diverses mesures sont obtenues avec un écart type d’environ 0,2°C et une reproductibilité d’une sonde à l’autre du même ordre de grandeur.

5. Affichage et stockage des mesures sur Tomtom

Afin d’acquérir les données émises par le MSP430 sur la liaison bluetooth, nous avons besoin de plusieurs outils, disponibles ou non par défaut au shell du Tomtom Go :

1. configuration de la liaison bluetooth depuis le Tomtom Go vers le convertisseur Free2Move : rfcomm ;

2. lire les informations ligne par ligne depuis le port série virtuel, au moyen de read (au lieu d’attendre une fin de fichier comme le ferait une redirection par > ou | de la sortie du port série vers notre application de traitement et d’affichage) ;

3. fournir les informations à l’utilisateur (afficher un message sur interface graphique) et stocker les informations dans un fichier : le flux de données est divisé en deux au moyen de tee du paquet sh-utils-2.0-1.armv4l.rpm dans les archives de www.netwinder.org9.

Le traitement des informations ligne par ligne est un point important pour rafraîchir régulièrement l’information : l’utilisation en ce sens de la fonction read est illustrée par :

Les informations sont communiquées sur le port série dans la base naturelle d’un système numérique, i.e. en hexadécimal, afin de limiter la charge de calcul sur le système embarqué. Les données à transmettre sont ainsi traitées quartet par quartet, en ajoutant les constantes appropriées pour afficher le code ASCII du caractère correspondant à la valeur transmise (0 à F, soit l’ajout de 0x30 à la valeur transmise si celle-ci est inférieure à 10 et 0x37 sinon, les concepteurs de la norme ASCII ayant eu l’étrange idée de placer des symboles mathématiques et de ponctuation entre les caractères ’9’ et ’A’ pour les raisons décrites dans man ascii).

Cependant, la majorité des utilisateurs de systèmes embarqués ne lisent malheureusement pas l’hexadécimal couramment – a fortiori pour le calcul flottant – et il faut les aider dans l’exploitation des mesures en convertissant les valeurs acquises en informations lisibles par un humain.

Les implications sont, lors du traitement des informations reçues du microcontrôleur :

- lire les données au format hexadécimal – naturel pour un microcontrôleur – sur l’entrée standard ;

- interpréter les informations fournies dans la bonne base et les exporter dans la base préhistorique des humains (base 10) ;

- effectuer le calcul avec une précision compatible avec celle des capteurs, donc calcul flottant (Fig. 10).

L’outil classique bc répond à toutes ces conditions après avoir renseigné la variable de la base des données en entrée correctement. Par défaut, bc prend en entrée des données en décimal et fournit la réponse en base 10, mais ces deux paramètres se modifient en définissant les variables ibase et obabase. Nous ajoutons donc à la liste des outils nécessaires le paquet bc-1.06-12.armv4l.rpm et les dépendances associées, toujours depuis le site www.netwinder.org. Le script script.bc suivant va nous permettre de convertir chaque ligne contenant une séquence de nombres en représentation hexadécimale vers une représentation décimale en virgule flottante, en tenant compte des coefficients de calibrage qui ont été identifiés auparavant (Fig. 6) :

Notez qu’une fois la base d’entrée (ibase) définie à 16, la configuration de la base de sortie (obase) à 10 en décimal s’obtient par A.

Le résultat de tous ces développements est la capacité de mesurer la température sur une roue (Fig. 7), transférer les informations par une liaison sans fil au TomtomGo et les stocker après les avoir datées (Fig. 8)

6. Affichage des résultats dans l’interface graphique du Tomtom Go

Tomtom exploite un mode de communication assez surprenant compte tenu des nombreuses possibilités de communication entre processus fournies par Unix : un fichier dont le nom suit un standard contient la commande à exécuter par le gestionnaire de l’interface graphique. Ce gestionnaire acquitte l’exécution de la commande en effaçant le fichier qui a servi à l’interaction et en fournissant, dans un autre fichier, le résultat de la commande. Bien que ces échanges de fichiers se fassent sur un RAMdisk, l’efficacité de ces transactions est douteuse.

En pratique, un ordre est donné à l’interface Tomtom en écrivant un fichier nommé SDK.TomTomNavigationServer.PID.N.message dans le répertoire /var/run. PID est le numéro du processus qui effectue la requête (obtenu par $$ dans bash) et N est un numéro de requête, que nous maintiendrons toujours à 1. Ce fichier contient la commande à effectuer, telle que décrite plus bas dans le paragraphe suivant. L’ordre est effectivement transmis lorsque /var/run/SDK.TomTomNavigationServer.PID.N.finished contenant le mot finish est écrit. Une fois la commande réalisée, l’interface Tomtom efface ces deux fichiers et crée /var/run/TomTomNavigationServer.SDK*, que nous n’exploiterons pas, mais nous nous contenterons d’effacer à chaque acquittement.

L’ensemble des interactions possibles depuis le shell avec l’interface graphique du Tomtom Go est répertorié à [3]. La partie qui nous concerne est :

- Obtenir la coordonnée géographique au moment de la mesure : une solution est d’interagir avec l’interface Tomtom, au moyen de la commande GetCurrentPositionV01, mais nous avons préféré exploiter la commande whereami fournie par www.opentom.org/Whereami.

- Fournir les informations à l’utilisateur : la commande FlashMessageV01 affiche une fenêtre dans un coin de l’interface graphique (Fig. 9) pendant une durée fournie comme second argument, le premier argument étant le message lui-même. Les arguments sont séparés par des |.

Ainsi, nous proposons dans une boucle infinie

pour continûment afficher les informations acquises sur STDIN et traitées par le script faisant appel à bc pour une mise en forme exploitable (présentée auparavant) à l’utilisateur. Ce script est appelé par

Notez que cette dernière partie est avantageusement précédée de

afin de garantir que le port série virtuel rfcomm2 est libre pour une liaison avec le module Free2Move (conflit possible avec une utilisation antérieure de ces scripts lorsque le Tomtom Go est entré en mode veille et bloque la réinitialisation de la liaison bluetooth à son réveil). La fréquence de rafraîchissement de l’information est déterminée par le microcontrôleur : la fonction read est bloquante et l’information n’est mise à jour que lors de l’envoi d’une trame par le MSP430. Nous sommes cependant limités à un intervalle de temps de l’ordre de 10 s entre deux mesures, à cause de la durée d’obtention de la position par whereami.

7. Exploitation et résultats

Une fois une série de mesures (ici température de jante, Fig. 10) géoréférencées acquise, il nous reste à les exploiter afin d’en tirer un maximum d’informations. La mise en contexte géographique est une étape essentielle : nous utilisons GNU/Octave pour générer un fichier au format KML, permettant d’insérer nos mesures dans Google Earth, qui fournit alors le contexte de mesure sous forme d’un modèle d’élévation sur lequel sont plaquées des photographies aériennes des régions traversées.

Le choix de GNU/Octave pour générer le fichier KML est initialement dicté par la volonté de coder la couleur de l’information de position de la mesure par la température. Il est probable que d’autres outils soient plus appropriés ou plus largement répandus, mais celui-ci répond à nos exigences de souplesse du tracé, au travers de gnuplot et de sauvegarde du code de couleur dans le fichier KML au format hexadécimal (Code 2). GNU/Octave supporte une gestion des chaînes de caractères très proche du C, tout en proposant la souplesse d’un langage scripté dont les performances en termes de vitesse ou d’occupation mémoire n’ont ici aucune importance.

Code 2: Script GNU/Octave pour générer un fichier KML à partir des informations géoréférencées : chaque polygone localisé aux coordonnées de la mesure se voit affecter une couleur issue de la palette jet.

Le résultat de l’exploitation des données est visible à Fig. 11 qui illustre le codage de l’information de température par la couleur, et en Fig. 12 la mise en contexte géographique et topographique avec le modèle de terrain inclus dans Google Earth, qui facilite l’interprétation des données. Nous constatons en effet que tous les points d’échauffement de la jante (en haut à gauche de Fig. 11 et à la longitude 6,01, latitude 47,235) correspondent à des pentes descendantes dans lesquelles nous avons volontairement serré les freins. Au contraire, toute la partie inférieure de la Fig. 11 correspond à une piste cyclable sans relief le long du Doubs. Notez une élévation significative de la température lors des mesures postérieures dans le « carré » à droite de la Fig. 11, par rapport au parcours le long du Doubs : le centre « ville » de Besançon conserve significativement plus de chaleur une fois la nuit tombée (ces parcours ont été effectués entre 20 h et 22 h début septembre).

Conclusion

Nous avons présenté les divers outils pour développer un BAN (Bike Area Network) en vue de la mesure de la température d’un objet mobile et la restitution en temps réel de l’information à un utilisateur. Les informations sont géoréférencées et converties en un format exploitable par un humain qui ne lit pas communément l’hexadécimal au moyen des outils classiquement mis à disposition sur un système Unix.

Afin d’atteindre cet objectif, nous avons exploité le système GNU/Linux installé par défaut sur un assistant de navigation Tomtom Go 720, accessible grâce aux outils mis à disposition par la communauté de opentom.org. Une console nous a permis de nous familiariser avec les outils disponibles, notamment le shell de busybox et les outils de configuration de l’interface bluetooth.

L’ajout de quelques outils dédiés – notamment le calculateur bc – a complété une interface conviviale exploitant le logiciel de navigation propriétaire pour afficher la température de la jante de la roue.

Remerciements

Nous remercions L. Fagot-Revurat (MFPM, Clermont-Ferrand) pour le prêt gracieux du convertisseur Bluetooth-RS232. T. Petazzoni a eu l’excellente initiative de proposer les lightning talks pendant la session « systèmes embarqués » des Rencontres du Logiciel Libre 2009 au cours desquelles le Tomtom Go a été présenté. T. Rétornaz (doctorant à FEMTO-ST, Besançon) a identifié SLAA129B comme méthode de mesure efficace en consommation électrique de la consommation, algorithme mis en œuvre sur MSP430F149 par B. François.

Références

[1] DANIEL (C.) & KLEFFEL (T.), « Hacking into Tomtom Go – Reverse engineering des Embedded-Linux Navigationsystems », 22nd Chaos Communication Congress (2005) [en Allemand]

[2] GARREAU (Xavier), « Bluetooth : développons », GNU/Linux Magazine France, n°80, Février 2006, pages 40-49

[3] TomTom Navigator SDK, TomTom B.V. 2004 et www.opentom.org/FileInterface

[4] QUIRING (K.), Implementing An Ultralow-Power Thermostat With Slope A/D Conversion, MSP430 Application Report SLAA129B, Texas Instruments, Janvier 2006

[5] WILLIAMS (J.), Bridge circuits – marrying gain and balance, Linear Technology, Application Note 43, Juin 1990

[6] FRIEDT (J-M.), MASS (A.), F. BASSIGNOT (F.), « Les microcontrôleurs MSP430 pour les applications faibles consommation – asservissement d’un oscillateur sur le GPS », GNU/Linux Magazine France, n°98, Octobre 2007

Notes de bas de page

¹ http://www.opentom.org

² http://www.opentom.org/TTTracklog

³ http://www.opentom.org/Hardware_Variants

⁴ http://www.opentom.org/BTconsole

⁵ http://www.tomtom.com/page.php?Page=gpl

⁶ Référence 1289666, sonde Pt100 classe A, 5,37 euros/pièce chez Farnell

⁷ http://www.free2move.se et en particulier le F2M01C1, alimenté en 5 V (par exemple depuis USB). Le F2M01SXA est disponible auprès de Lextronic pour 94 euros

⁸ www.free2move.net/uploads/downloads/Wireless_UART_protocol_v3.pdf

⁹ de façon, générale, nous piochons dans les exécutables mis à disposition sur ce site web lorsqu’un programme n’est pas disponible sur le Tomtom, tel que décrit à http://wiki.opentom.org/Talk:TomTom_Console