04) Préparation de la première application autonome.

Autonome implique plusieurs contraintes par rapport à la solution élémentaire qui se résume à approvisionner une carte Arduino NANO ou UNO et un module GPS. C’est l’ordinateur qui fournit le clavier et l’écran de visualisation. Pour envisager un petit appareil portatif, il faut ajouter un dispositif de visualisation, un « clavier » pour dialoguer dans des menus et une source d’énergie :

Experience_19_Noyau : Le programme noyau.

À ce stade rien ne nous interdit d’envisager plusieurs variantes qui ne diffères les unes des autres que par le type d’afficheur utilisé, présence ou non d’un codeur incrémental rotatif, utilisation d’un clavier à deux ou cinq touches etc. Il est évident que si on choisit un afficheur graphique les possibilités seront plus importantes que se limiter à un LCD avec deux lignes de texte. Toutes ces applications auront un ADN commun, et on ne va pas passer son temps à l’extraire des croquis qui fonctionnent. Trois domaines seront incontournables :
• La déclaration de la ligne SCI,
• La saisie et la mémorisation des groupes de données,
• L’attente de données cohérentes à la mise sous tension.
• Éventuellement la mesure de la tension de la batterie.

Affectations des Entrées/Sorties de l’ATmega 328.

Bien que ce ne soit pas obligatoire, pour faciliter au maximum les manipulations lors de l’élaboration du programme, on va réserver D0 et D1 exclusivement au téléchargement du code objet par la ligne USB. L’entrée de mesure de la tension de la batterie se fait sur A7 car c’est une broche qui ne peut servir que d’entrée analogique. Pour le codeur incrémental rotatif KY-040 il faut impérativement utiliser D2 et D3 qui se servent des interruptions 0 et 1. Pour l’entrée de détection du bouton central on va prendre dans l’ordre D4. C’est possible car pour l’afficheur LCD avec sa bibliothèque LiquidCrystal.h on peut choisir à notre guise les broches de l’ATmega328. On va les affecter dans l’ordre de D5 à D10. Du coup, toujours dans l’ordre croissant on affecte la broche D11 à la sortie SCI du module GPS. Il reste inutilisées les broches D12 et D13, cette dernière pouvant éventuellement servir à piloter la LED d’Arduino. La Fig.33 détaille les branchements de l’afficheur LCD. Le potentiomètre P peut être un linéaire de 4,7KΩ, 10KΩ, 22KΩ, sa valeur est sans importance. On peut même imposer le contraste maximal en réunissant la broche VO directement à GND.

Experience_20 : Implanter le LCD.

Plutôt que de vous présenter directement le programme complet dont le listage sera long « comme un jour sans pain », il me semble plus judicieux de procéder par étapes. Ainsi chaque démonstrateur sera plus aisé à analyser dans ses spécificités. Par ailleurs, ainsi on valide le matériel au fur et à mesure des manipulations. Dans ce démonstrateur Expérience_20.ino on n’intègre matériellement et dans le croquis que l’afficheur LCD qui se contente d’afficher la PAGE_1 c’est à dire la date et l’heure. Dès que l’activation de la PAGE_1 en Fig.34 est possible la LED d’Arduino s’illumine le temps du rafraichissement du petit écran. Durant l’attente des quatre satellites Fig.35 un compteur dans l’encerclé rouge qui recycle à 255 s’incrémente pour nous informer du déroulement du programme. Penser à mettre à jour le booléen dans le #define Hiver situé en tête de listage pour que l’heure légale soit correcte. Pour comprendre certaines séquence du démonstrateur, je vous invite fortement à prendre connaissance des informations données en Fiche n°3 et Fiche n°4. Les fiches au format A5 sont prévues pour être à portée de main quand on développe un programme en Arduino. Elles sont disponibles dans le fichier FICHES A5.pdf qui accompagne le didacticiel.

Experience_21 : Ajout du codeur incrémental KY_040.

À partir du moment où l’on inclus dans l’appareil un potentiomètre, un codeur rotatif ou un clavier à deux, cinq touches ou plus, l’utilisation de l’ensemble « explose » en possibilités de fonctions opérationnelles. Le démonstrateur Expérience_21.ino apporte la preuve qu’il est possible d’exploiter avec un simple codeur rotatif, de façon conviviale, un appareil fournissant déjà pas mal de fonctions diverses. Les photographies de la Fig.36A à la Fig.36G présentent les différentes « pages-écran » disponibles avec P21. Inutile de présenter à nouveau l’écran de la Fig.34 qui n’a pas été modifié. Sur RESET c’est cette page qui sera affichée tant que le codeur incrémental rotatif ne sera pas actionné. Quand on le tourne dans le sens horaire, les pages défilent dans l’ordre des écrans représentés sur la Fig.36 et dans l’ordre inverses si le sens de rotation est en antihoraire. Par contre, la Fig.35 a muté en celle de la Fig.36A toujours avec le compteur en bas à droite. Entre parenthèses est précisé le nombre de satellites en poursuite, c’est à dire fournissant un signal fiable. Justification fondamentale d’un GPS, en Fig.36B ce sont les coordonnées sphériques du mobile qui sont affichées. En Fig.36C l’information de position est complétée par l’altitude au niveau moyen des océans. Sur la ligne du bas on précise le nombre de satellites en poursuite, et le nombre de ceux situés au-dessus de l’horizon local. En Fig.36D est précisé le facteur de dilution complété sur la ligne du bas par la fiabilité du positionnement. Un peu plus technique, l’écran de la Fig.36E indique le mode de détermination du positionnement ainsi que le décalage en hauteur du géoïde. Quand on active l’écran Fig.36F une LED bleue dédiée s’illumine. Elle signale que l’on est dans une fonction à plusieurs pages. Pour sortir de cette fonction il faut cliquer sur le bouton central du codeur incrémental. Ce mode présente les caractéristiques des satellites enregistrés dans le premier Tampon_GSV qui en contient quatre ordonnés de S1 à S4. Sous ce numéro d’ordre est indiquée la référence du satellite en poursuite. Puis viennent les informations de l’élévation en Hauteur et d’Azimut et enfin la valeur de l’intensité de réception du Signal. Lorsque cette donnée n’est pas disponible la valeur est représentée par « **« . (Collé à Sig le symbole d’une antenne.) Enfin en Fig.36G l’écran affiche la tension aux bornes de la batterie d’alimentation. Pour comprendre comment est exploité ce codeur incrémental KY-040 la Fiche n°6 en détaille les spécificités.

Caractères spéciaux sur un afficheur LCD.

Particularité des afficheurs LCD qui utilisent pratiquement tous la même « racine électronique », leur police de caractère est limitée à celle de la Fiche n°1, mais nous offre la possibilité de créer jusqu’à huit caractères personnels sous forme d’une matrice de 8 x 5 PIXELs. Les instructions idoines sont précisées dans la Fiche n°5. En particulier vous pouvez observer que dans la police standard il n’y a pas les accentués ni les lettres avec tréma. On doit donc dans cette application se créer le ‘é‘ et le ‘ï‘. Par ailleurs, je trouve que les lettres minuscules de la police standard avec jambage telles que le g, le j, le p et le q décalées vers le haut ne sont pas très esthétiques. C’est la raison pour laquelle, en plus du ‘ö‘ et du symbole de la petite antenne, j’ai ajouté dans le logiciel la génération d’un ‘g‘ personnel. Enfin, la lettre Delta pour Δh de la Fig.36E complète judicieusement notre collection matricielle. Cette information représente la correction de la hauteur du géoïde en mètres par rapport à l’ellipsoïde WGS84. Comme le terme « correction » contient bien trop de caractères, j’ai choisi de le remplacer par la lettre Δ qui traditionnellement en physique traduit un gradian ou la variation d’un paramètre dont on étudie le comportement. Je vous invite au passage de consulter la Fiche n°14 qui précise la notion assez théorique de WGS84.

Experience_22 : Ajout de la détermination d’une loxodromie.

Maintenant que le programme d’application n°1 est globalement élaboré, il importe de définir le schéma électronique complet et éventuellement d’ajouter d’autres fonctions qui rendront notre appareil encore plus séduisant. Dans l’état actuel, le code objet n’occupe que 40% de l’espace réservé au programme. Autant dire que nous avons encore beaucoup de place pour loger d’autres fonctions éventuelles. Encore faut-il trouver des idées pertinentes. Commençons par analyser le schéma électronique complet. Il est défini en Fiche n°17. Pour comprendre en détails l’utilité de la résistance R consulter la Fiche n°11 et la Fiche n°12. Comme déjà précisé j’utilise une carte Arduino NANO pour des raisons d’encombrement dont les caractéristiques et le brochage sont précisés sur la la Fiche n°7 et la Fiche n°8. Il faudra impérativement placer l’inverseur sur AR lorsque la mini-fiche USB sera reliée à une prise de l’ordinateur pour téléverser une version modifiée du logiciel par exemple. (Un programme est appelé à « vivre »).

Affichage de la distance à « vol d’oiseau » d’un point CIBLE.

Restons réalistes, ce n’est pas avec la puissance « dérisoire » d’un ATmega328 que l’on va pouvoir développer un GPS cartographique avec calcul d’itinéraire et autres fonctionnalités d’une puissance telle que l’on finit par croire que c’est élémentaire. Par contre, avec un appareil aussi rudimentaire, on peut définir un point géographique qui nous concerne, et le dispositif sera apte à nous indiquer en permanence la distance curviligne sur le géoïde qui nous en sépare. Si par exemple on se déplace en véhicule automobile, nous allons constater que suivant les impératifs routiers on s’en éloigne par moment, et puis plus notre route nous en approche, plus cette distance va diminuer pour finir par afficher zéro quand on aura atteint notre destination. Si ce n’est pas fabuleux, ce n’est déjà pas si mal pour un projet purement ludique. Pour obtenir le résultat montré sur la Fig.37 qui indique la distance entre PARIS et l’île de Paquës, les traitements mathématiques sont assez indigestes et nous obligent à faire un petit tour en trigonométrie sphérique. Aussi, pour ne pas encombrer inutilement le didacticiel sur la détermination d’une loxodromie représentée en Fig.38, pour celles et ceux qui désirent en savoir plus sur les traitements effectués dans P22 je vous invite à consulter dans <Documents> le fichier Cartographie et Loxodromie.pdf.

Google Maps pour déterminer une position géographique et une distance.

Que ce soit plus tard pour intégrer dans la petite machine des points d’intérêts ou pour engager une « campagne de tests » pour valider le logiciel avec une forte probabilité de vraisemblance, il nous faudra obtenir des coordonnées sphériques à la surface de la Terre et des distances mesurées sur cette dernière. Nous avons vu dans l’encadré page 19 que les valeurs obtenues seront approximatives. Peu importe, elles seront suffisamment précises pour satisfaire notre besoin. Le but de ce chapitre est de vous proposer une technique simple pour procéder à cette collecte d’informations.
Coordonnée géographique d’un point d’intérêt :
1) Activer Google Maps, (Voir la Fig.39)
2) En haut à gauche en 1 donner le nom de la Cible. Quand on valide le logiciel effectue un grand zoom et centre sa fenêtre sur la cible.
3) En bas à droite avec la puce + agrandir au maximum jusqu’à voir en détails la cible,
4) Avec le bouton droit de la souris cliquer exactement sur le point dont vous désirer les coordonnées géographiques,
5) S’ouvre juste en dessous du point visé une petite fenêtre contextuelle qui nous fournit les coordonnées géographiques de ce point.

Distance entre deux points : (Ce sera pour nous autre le GPS et un point d’intérêt.)
Pour exemple on suppose que vous habitez Concarneau. Tante Émilie habite Quimper. Vous désirez connaitre à vol d’oiseau la distance qui sépare vos deux adresses :
1) Activer Google Maps, (Voir la Fig.40 bis)
2) Effectuer un agrandissement de la région.
3) Tracer en C un trait reliant les deux points.
4) En bas à droite en A est indiquée l’échelle.
5) Sur une bande de papier tracer une échelle mobile comme représenté en B.
6) Avec cette règle improvisée vous mesurez la distance en D soit environ 23km.

Comme précisé dans le document Cartographie et Loxodromie.pdf la distance mesurée par cette méthode sera un peu imprécise. Elle le sera d’autant plus que la surface représentée sur la carte sera importante puisque l’on construit à plat une réalité qui est sphérique. Toutefois, l’ordre de grandeur est suffisant pour vérifier le programme et nous avons en main tous les outils pour le faire.

Vérification des calculs effectués dans Experience_22.

Pour pouvoir faire confiance à un logiciel quel qu’il soit, il importe d’effectuer une « campagne de tests » pertinente pour le valider avec une fiabilité raisonnable. L’une des étapes cruciales lors de telles vérification consiste à déterminer un jeu d’essais pertinent. Si vous avez consulté le document Cartographie et Loxodromie.pdf vous avez immédiatement compris que les traitements permettant de calculer la distance curviligne sur le géoïde qui sépare le GPS d’une cible imposent des essais établis avec attention. Lors du développement, toutes les étapes intermédiaires ont été vérifiées pas à pas pour valider ligne à ligne chaque phase des calculs. Dans le démonstrateur Expérience_22.ino vous avez téléversé un programme supposé validé. Aussi, pour vous la « campagne de tests » va se résumer à quelques manipulations faciles de validation « globale ».

Située vers le début du listage de P22 on trouve la zone de la Fig.41 dans laquelle se trouvent des coordonnées géographiques « trouvées » dans Google Maps avec les techniques décrites dans le chapitre précédent. Dans les remarques telles que celle repérée dans l’encadré rouge on trouve le rappel du format des données fournies par Google Maps. Ces données ont été légèrement modifiées en supprimant le signe négatif éventuel et en remplaçant par N, S, E et W. En première utilisation de ce croquis la Cible active est l’île de Pâques car elle est éloignée au maximum de la France, située à l’ouest et dans l’hémisphère sud. Il est évident qu’en fonction de votre lieu d’habitation la valeur que vous prouverez sera différente. Il n’en reste pas moins vrai que les 13000Km déterminés par le démonstrateur correspondent assez bien à la distance que l’on évalue sur Google Maps.

Pour le deuxième test en 2, on passe en remarques les deux lignes 79 et 80 et on valide la 82 et la 83. En choisissant comme Cible la ville de New York on sélectionne une destination lointaine située à l’Ouest et dans l’hémisphère Nord. Quand on téléverse la nouvelle mouture du programme on va alors obtenir une distance qui ressemble à 6100km. C’est bon signe, le logiciel retourne des ordres de grandeurs assez conformes aux prédictions mesurées avec Google Maps.
Comme exemples suivants, j’ai choisie en 3 un charmant petit village dans la Drôme et une autre petite commune en 4 ancrée vers le centre de la France. Je ne vous en livre pas les valeurs de distance à trouver, laissant à votre sagacité le plaisir d’aller les déterminer par vous-même.

Achever cette courte campagne d’essais se termine par deux tests particuliers et impératifs. Le premier en 5 consiste à appliquer la technique détaillées en Fig.40 c’est à dire sélectionner une Cible relativement proche entre dix et vingt kilomètres de chez vous. Ce sont les conditions où la mesure approximative effectuée sur l’écran vidéo sera la plus précise. Enfin, le test final en 6 consiste à donner comme coordonnées celles que vous trouvez dans Google Maps en pointant le plus finement possible l’emplacement de votre maison. En théorie Arduino devrait indiquer une distance nulle. Dans la pratique on aura une valeur comme 0.01km. Dix mètres d’erreur avec un tout petit calculateur qui mouline des données issues de satellites situés à des centaines de kilomètres … avouez que c’est presque de la magie ! Nos algorithmes étant validés, on va pouvoir passer à un premier programme d’application dans lequel on pourra facilement indiquer des points d’intérêt. L’idée de base consiste à pouvoir enregistrer les coordonnées de plusieurs points d’intérêts en mémoire EEPROM pour s’en servir à notre convenance. Comme le matériel est limité à un simple codeur incrémental, pour inscrire les coordonnées des Cibles en EEPROM on va utiliser pour le dialogue Homme/Machine le Moniteur de l’IDE. Par contre, une fois que ces données seront en EEPROM l’appareil sera autonome pour les utiliser. Il nous reste à en définir les protocoles …

Application_GPS_1.ino.

Cette application est la plus simple au niveau matériel puisqu’elle se résume à une carte Arduino NANO, Un module GPS du commerce, en afficheur de type LCD, un codeur incrémental rotatif et un accumulateur rechargeable de 9v. (Ou une pile de type 6F22 ou 6LR61.) La première étape pour élaborer ce petit projet consiste à optimiser l’usage des ressources de l’ATmega328.

Protocole de sélection à l’usage d’un point d’intérêt.
Compte tenu du matériel disponible, on va se servir du bouton poussoir central du codeur incrémental. On suppose naturellement que des adresses sont déjà disponibles en EEPROM. À la mise sous tension, si le bouton central du codeur rotatif est activé, l’écran va afficher une page du genre de celle représentée en Fig.43 qui indique le numéro d’ordre de la Cible ainsi que son libellé. En tournant le codeur on balaye les adresses disponibles. Quand on clique à nouveau sur le bouton poussoir central, on passe au fonctionnement du GPS qui calculera alors la longueur de la Loxodromie entre sa position actuelle et celle de la Cible.
(En réalité le protocole à été complété et l’on enchaîne avec le choix des options.)

Organisation des données en mémoire non volatile EEPROM.
Pour les coordonnées du point d’intérêt il faut 17 octets. Pour le texte à l’écran il faut 16 octets. Pour une cible il faut 33 octets. On pourra donc loger 1024 / 33 = 31 adresses au maximum. On va se limiter à 30 points d’intérêt, plus en accord avec des habitudes où les dizaines ont tendance à s’imposer. Surtout, avec 31 P.I. il ne resterait qu’un seul octet de disponible pour les informations non volatiles. Hors on va vouloir mémoriser le nombre de P.I. disponibles, celui qui sera rechargé sur RESET, l’option Été/Hiver, les affichages en km ou en MN etc. L’organisation de l’EEPROM montrée sur la Fig.44 consiste à placer les P.I. En partant de l’adresse 0000 et en « montant » dans l’ordre des cellules. Pour les données des variables initialisées lors du RESET on part de l’adresse la plus « haute » 1023 et on loge les valeurs vers le bas au fur et à mesure des besoins exprimés. (Voir le tableau de la Fig.45 établi à ce stade du développement du programme.)
Pour pouvoir facilement développer et vérifier le comportement du programme d’application, il importe d’avoir des données cohérentes en mémoire non volatile. Aussi, un petit outil nommé Ecrire_en_EEPROM_1.ino place en mémoire sept points d’intérêt, impose le n°6 au rechargement sur RESET, impose l’heure d’hiver ainsi que les unités de distance et de vitesse en Km et Km/H.
La Fig.45 bis présente le contenu de la mémoire l’EEPROM de l’ATmega328 lorsque Ecrire_en_EEPROM_1.ino à été téléversé et exécuté au moins une fois. Toute la zone qui contient des points d’intérêt est affichée en forma texte, car ce sont des éléments de type char. Chaque point d’intérêt est mis en évidence par coloriage. Il est ainsi facile d’en déduire l’adresse de début et de fin pour effectuer les essais de validation. Les derniers octets sont de type boolean ou byte et sont présentés en Hexadécimal. Les $FF correspondent à des « 225 », c’est à dire des cellules vierges qui n’ont encore jamais été écrites.

Le MENU qui s’ouvre sur RESET.
Lorsque l’appareil est mis sous tension, il recharge les données de base depuis l’EEPROM, c’est à dire le nombre de P.I. disponibles en EEPROM, celui qui sera rechargé automatiquement durant le RESET, si le GPS est utilisé en heure d’hiver ou d’été et si les distances et les vitesses sont en unités métriques ou en unités nautiques. Si durant le RESET le bouton central du codeur incrémental est cliqué, on ouvre le Menu du RESET à son relâcher. Le protocole de sélection des diverses options est résumé sur la Fig.46 qui précise les actions à effectuer sur le codeur rotatif.
L’écran 1 indique en B le nombre de P.I. disponibles et en A celui qui sera pris en compte dans les calculs. En C sur la ligne du bas est indiqué le libellé de ce P.I. En faisant tourner dans un sens ou dans l’autre le codeur incrémental, on fait « défiler » les divers points d’intérêt en permutation circulaire. Quand celui qui est désiré est affiché sur l’écran LCD, en cliquant sur le BPC on passe à la sélection de l’option suivante en 2 et 3 pour le choix de l’heure légale. Dans cette configuration la rotation du codeur fait alterner entre Été et Hiver. En cliquant sur le BPC on valide l’option et on enchaîne en 4 et 5 à la sélection des unités utilisées pour afficher les distances et le jour où elles seront disponibles si j’y parviens, les unités des vitesses. À ce stade cliquer une dernière fois sur le BPC fait quitter le Menu du RESET et débute l’exploitation avec le Menu du GPS.

Protocole du dialogue Homme/Machine avec le Moniteur de l’IDE.
ATTENTION : Lorsque l’appareil sera relié à une ligne USB de l’ordinateur, il sera impératif de couper l’alimentation locale de l’accumulateur 9v. Passons à l’analyse préalable :
Avec un seul codeur rotatif comme périphérique pour assurer le dialogue
Homme/Machine, proposer à l’appareil du texte est inenvisageable. Aussi, comme inscrire des P.I. dans la mémoire non volatile de l’ATmega328 reste une fonction marginale de l’utilisation du GPS, cette opération sera réalisée en reliant l’appareil à un quelconque ordinateur dont on utilisera le clavier très convivial.
Pour que l’usage de notre petit dispositif soit agréable, il importe de proposer un maximum de souplesse opérationnelle. Le Moniteur de l’IDE devra permettre d’effacer un P.I, d’en obtenir la liste et bien entendu d’en ajouter à convenance dans la limite des places disponibles. Dans la ligne de saisie du Moniteur on sera amené à choisir des actions et consigner des valeurs.
• Le prompt donné dans le tableau Fig.47 indique la nature de l’information attendue.
• Le Menu du GPS sera l’un des caractères de la Fig.48.

Pour faciliter le travail de l’utilisateur, la touche affectée au caractère de commande pourra librement être frappée en minuscule. Par exemple le ‘,’ sera équivalent à ‘?‘. Chaque commande ne contiendra qu’un seul caractère validé immédiatement. On entrera alors dans une phase de saisie d’une donnée et le prompt sera contextuel. (Prompt : Caractère ou texte d’invitation à saisir une donnée.)

La suite est ICI.