L’une des spécificités les plus appréciables du C++ d’Arduino est son aptitude à gérer un réseau de périphériques sur une ligne au standard I2C. Dès que l’on envisage en informatique de loisir une application un tant soit peu riche en périphériques, inévitablement nous serons confrontés à l’utilisation d’un BUS I2C. Heureusement pour nous, le C++ du compilateur intègre la bibliothèque <Wire.h> et les fournisseurs de modules électroniques accompagnent leurs productions de bibliothèques complémentaires (Library.) adaptées à leurs références. C’est le démonstrateur P15_Plusieurs_modules_I2C.ino qui sera chargé dans un premier temps de nous montrer comment faire cohabiter plusieurs esclaves sur le bus commun.
Avant de poursuivre, on s’informe de toutes les explications sommaires relatives à la ligne I2C proposées dans la Fiche n°22. Sans que nous n’y avons apporté une attention particulière, le bus de dialogue était déjà occupé par un module : Le multiplexeur de sorties pour les servomoteurs. La documentation de ce produit commercial indique que par défaut en sortie d’usine l’adresse de ce périphérique est 40HEX. (01000000 exprimé en Hexadécimal.) Sachant que ce module peut être chaîné facilement avec d’autres compères, pour en changer l’adresse I2C il suffit de forcer des « 0 » sur l’un des 6 « Bits » disponibles dans la zone qui sur la Fig.136 est repérée en rouge. Pour l’application en cours nous n’aurons pas besoin d’effectuer cette petite modification matérielle, autant vous l’éviter.
Une boussole magnétique sur GEKERT.
Consultons la Fiche n°23 qui décrit le tout petit module magnétique qui sera ajouté sur le bus I2C de la sonde et qui va fonctionner en esclave avec le démonstrateur. Basée sur l’effet Hall, la « puce électronique » contient matériellement deux périphériques indépendants pouvant dialoguer sur le bus I2C avec pour adresses respectives 42HEX et 43 HEX. Chaque entité mesure séparément la valeur du champ magnétique dans une orientation cartésienne. Puis un module de calcul combine les deux valeurs pour déterminer l’orientation des « lignes de force » pour les traduire sous forme d’un CAP. La Fig.137 présente une copie d’écran quand on a envoyé à JEKERT la commande « o* » qui retourne l’orientation magnétique du petit robot.
Initialement pour appréhender ce petit module, la bibliothèque spécialisée hmc6352.h avait été intégrée dans le programme d’évaluation. Mais l’utilisation actuelle sur la sonde n’en a pas besoin, il faut juste inclure les routines de gestion de la ligne I2C <Wire.h> qui de toute façon est dès le début indispensable pour dialoguer avec le multiplexeur PCA9685.
Conflits d’adressages sur une ligne I2C.
Interroger une personne pour dialoguer quand on est en présence d’une classe, implique de désigner de façon univoque celle à laquelle on s’adresse. Par exemple l’institutrice qui sollicite l’une de ses gamines par : « Alice tu veux bien venir au tableau s’il te plait » va avoir la surprise de constater que cinq de ses fillettes se lèvent pour obtempérer. Nous sommes en présence d’un conflit d’adressage verbal. Quand une « séquence Maître » sollicite un périphérique sur la ligne commune I2C, elle précise en premier l’adresse, puis la nature de la réaction attendue. Si deux entités ont une adresse identique, elles vont répondre simultanément et les données vont mutuellement polluer leur accusé de réception par le phénomène Dominant/Récessif. Le Maître recevra alors du « bruit binaire incompréhensible ». Aussi, il est IMPÉRATIF de s’assurer que tous les modules branchés en parallèle sur une ligne I2C soient conditionnés à des adresses matérielles différentes.
Considérons la Fig.138 qui représente l’assemblage électronique actuel quand on branche simultanément le multiplexeur de motorisation PCA9685 et la petite boussole HMC6352.
Si vous étudiez à nouveau la Fig.22 vous constaterez qu’il n’a pas été nécessaire d’ajouter des résistances « Pull Up » au module PCA9685 pour forcer le niveau haut +5Vcc. Généralement les fournisseurs de modules prêts à l’emploi intègrent tout ce qu’il faut sur leur circuit imprimé pour que l’utilisateur n’ait strictement rien d’autre à ajouter dans son application. Dans ce but, le module PCA9685 dispose de résistances de 10kΩ entre le +5Vcc et les deux lignes SDA et SCL. Hors ce petit module est prévu pour coexister avec plusieurs autres. Supposons que l’on chaîne huit PCA9685 en ayant bien évidemment modifié les adressages sur au moins sept d’entre eux. C’est donc huit résistances de 10kΩ qui vont se trouver montées en parallèle soit une résultante de 1.25kΩ. Dans ce cas, les transistors à collecteur ouvert devront drainer un courant de 4mA au lieu de 50µA. Il n’y a aucune raison de s’inquiéter. Ces transistors fonctionnant en « saturé/bloqué » pourraient facilement commuter des courants cent fois plus importants. (Sans compter qu’à ce pris on pilote cent vingt huit servomoteurs … sacré machine !)
Conflits électroniques sur la ligne I2C.
Observant plus attentivement la Fiche n°23 de la boussole HMC6352 on déduit que les deux adresses des entités B et C sont différentes de celle du module A. Sans 
avoir à modifier l’adresse du multiplexeur de motorisation, les trois entités peuvent dialoguer sans conflit d’adressage sur le bus I2C. Si le Maître sollicite l’un des trois, ce sera le seul à répondre et la cacophonie informatique est évitée. Beaucoup de périphériques sont conçus pour fonctionner en 3,3Vcc régulé. C’est la raison pour laquelle les cartes Arduino anticipent en intégrant un régulateur +3,3Vcc que l’on peut utiliser à notre guise. Comme précisé expressément sur la Fig.1 de la Fiche n°23 la minuscule carte électronique de la boussole DOIT ÊTRE ALIMENTÉE EN +3Vcc.
Du coup, ses deux résistances intégrées de 10kΩ reçoivent « un contre courant » arrivant du bus qui est déjà forcé à +5V par le module PCA9685. Cette configuration ressemble fortement à un conflit électronique, et l’on pourrait craindre une surcharge du HMC6352. Rassurez-vous, ce n’est qu’une apparence, il n’en est strictement rien. Les transistors de commutation TC de ce dernier se trouvent dans la situation de la Fig.139 et doivent commuter la somme des courants I1 et I2 soit 0,83mA. À ce régime il faudra placer la sonde en plein soleil pour que TC chauffe … et encore ! On peut donc brancher sans problème ce module, il n’y aura pas de conflit électronique à craindre sur la ligne de dialogue commune I2C.
La cohabitation I2C logicielle.
Trop impatients de voir fonctionner la petite boussole, vous avez rapidos branché le petit module rouge et téléversé le démonstrateur P15_Plusieurs_modules_I2C.ino qui fait vivre tout ce petit monde électronicoinformaticorobotique. Magique, quand on tourne dans tous les sens le module, il ne perd pas trop le Nord à condition qu’il soit bien à l’horizontale. Manifestement cette manipulation démontre qu’il est possible de faire cohabiter au moins trois entités sur un bus I2C. Nous allons dans ce chapitre passer en revue les étapes et les détails logiciels qui aboutissent à ce résultat très séduisant, au prix pour le programmeur d’un minimum d’efforts. Cette simplicité à mettre en œuvre des systèmes d’une complexité technique vertigineuse résulte de programmes « faramineux » qui font tout le travail pour nous, que ce soit câblé en local sur le module électronique, ou par l’entremise de bibliothèques spécifiques bien pensées. Remercions au passage les Ingénieurs qui ont développé ces aides rendant évident et ludique des domaines qu’il y a peu de temps relevait de laboratoires pourvus de très hautes technologies, pratiquement de la science fiction …
Première étape à toute utilisation d’un quelconque périphérique : Les déclarations et les directives. Si l’un des modules branchés sur l’ATmega328 doit dialoguer sur un BUS I2C, nous savons déjà qu’il faut déclarer la bibliothèque #include <Wire.h> et que cette dernière en standard va s’octroyer A4 et A5 et qu’ils devront respectivement se brancher sur SDA et SCL. Pour P15 c’est la directive (1) qui se charge d’informer le compilateur.
Puis on peut déclarer dans un ordre quelconque les bibliothèques spécifiques. Dans notre cas, historiquement nous avons commencé par celle du multiplexeur déclarée en (2). En général, il faut « instancier » un périphérique matériel pour qu’il soit connu de sa bibliothèque. C’est les cas pour la carte PCA9685. Aussi, immédiatement après avoir déclaré la « library » en (3) on déclare le module connecté à Arduino. Connue de l’IDE, il n’est pas obligatoire d’inclure une bibliothèque pour la boussole HMC6352. Par contre, quand on désire faire référence aux « octets internes » du module électronique, on devra utiliser des identificateurs. C’est la directive en ligne (4) qui se charge de déclarer 0x41, soit la lettre « A » en code ASCII. ATTENTION, cette information ressemble à une adresse I2C. Rien à voir. Elle désigne une cellule binaire interne au circuit électronique qui permettra de récupérer la valeur du CAP codée en décimal sur deux octets. (Intrinsèquement un type float.)
Enfin en (5) on définit une autre constante d’adressage interne dont aura besoin le logiciel.
Deuxième étape : Réserver de la place en mémoire pour que le logiciel puisse traiter des variables et leur affecter un identificateur. Pour nos trois modules périphériques et surtout pour leurs traitements informatiques, on doit déclarer des variables. Voici les informations relatives à la petite boussole HMC6352 :
La valeur calculée du CAP est délivrée sous forme de deux octets qui seront concaténés (Mis bout à bout.) pour obtenir une valeur numérique complète. Pour préserver ces deux octets temporaires, les programmes fournit pour évaluation de la boussole électronique réservent deux byte ce que font les lignes (1) et (2). Enfin le réel CAP_construit sera affecté en (3) à la valeur calculée du CAP.
Quand les constantes, les variables et les bibliothèques disponibles sont mises en place, on complète le logiciel de l’application par les séquences qui exploitent toutes ces ressources. Pour la boussole HMC6352 le gros du travail se résume à une procédure copiée presque sans changement sur celle qui accompagne le composant. En réalité, sur tous les programmes que vous trouverez sur Internet, l’adresse Adresse_du_HMC6352 est décrite sous forme d’une variable de type int qui lors de sa déclaration est initialisée à 0x42. Ensuite pour l’utiliser on la divise par deux par un décalage logique >> 1 pour devenir 0x21. Autant éliminer la variable ce qui économise deux octets dans la RAM dynamique. Éliminez aussi le calcul >> 1, ce qui réduit encore le code. Ainsi déclarée en constante valant directement 0x21, on gagne 30 octets dans le code objet. Examinons maintenant la procédure suggérée sur Internet pour mesurer la valeur du CAP magnétique retournée dans CAP_construit. Nous verrons plus avant que cette procédure est encore loin d’être optimisée, on peut faire bien mieux. Ceci étant précisé, elle a le grand mérite de bien montrer comment procéder.
Compilant le démonstrateur, lorsque l’on ajoute l’appel à cette fonction « o* » dans la liste des commandes à un caractère, la procédure de mesure et de calcul ainsi que celle d’affichage, le code objet enfle d’environ 236 octets. (Pour avoir cette information on compile sans, puis avec la nouvelle fonction.) C’est au final très peu pour compléter les performances de JEKERT. Cependant, le modules fonctionnel entièrement ajouté ne comporte au total que dix sept instructions, ligne d’appel « o* » comprise. C’est que des lignes comme Wire.beginTransmission() par exemple font appel au contenu de la bibliothèque et exigent rapidement des quantités d’octets pour le programme binaire. Il faut donc toujours avoir présent à l’esprit qu’une simple ligne de source faisant appel à du « code externe » peut engendrer un taux d’inflation important.
Avant de décortiquer le fonctionnement de la procédure Mesure_orientation_magnetique() il me semble utile d’ouvrir une petite parenthèse consacrée à du vocabulaire traditionnel. Pour illustrer ce propos, nous allons considérer en Fig.140 un cas concret. Par exemple on va supposer qu’une variable nommée CAP_construit est de type int, c’est à dire qu’elle contient 16 BITs. Chaque BIT peut se trouver à l’état « 0 » ou à l’état « 1 ». Quel que soit son ordre dans la représentation du nombre rangé dans CAP_construit les « 0 » vaudront « 0 », c’est à dire pas grand chose. Par contre, les « 1 » en fonction de leur position représentent des valeur de plus en plus grande 
quand on les examine de la gauche vers la droite. Dans le système décimal chaque « décalage » multiplie par dix, le tout premier « 1 » valant la valeur unitaire. En binaire c’est exactement pareil, sauf que la base étant 2 au lieu de 10, on multiplie par 2. Le poids de chaque BIT vaut donc 1, puis 2, puis 4, 8 etc. En conclusion, celui le plus à droite est le moins significatif. Il est nommé Least Significant Bit dans la littérature spécialisé et symbolisé par LSB. Celui le plus à gauche devient le Most Significant Bit et se représente par le sigle MSB. Il se trouve que dans les exemples de programme donnés pour la boussole les auteurs utilisent LSB et MSB, sauf que dans ce cas ces deux identificateurs trompeurs ne font plus référence à des BITs mais à des OCTETs. Ce n’est pas tragique, mais durant l’analyse avec LSB il faudra penser Least Significant Octet et avec MSB raisonner sur l’Octet de poids fort, Most Significant Octet avec pour corollaire le fait qu’un mot binaire sur 16 BITs peut être considéré comme deux OCTETs concaténés c’est à dire placés l’un contre l’autre MSB à gauche, LSB à droite.
Exemple de protocole de dialogue sur un bus I2C.
Première action, la procédure Mesure_orientation_magnetique() amorce en (1) un dialogue c’est à dire qu’elle signale que le périphérique habitant à Adresse_du_HMC6352 de la rue I2C doit se mettre à l’écoute, qu’il va recevoir une instruction. Dans ce but, il devra surveiller le signal d’horloge sur SCL et les données sur SDA pour lire le code instruction. Puis le Maître par la ligne (2) « écrit » sur le bus le caractère ASCII « A » qui en protocole HMC6352 demande de retourner la valeur du CAP magnétique actuel. Enfin en (3) le Maître informe l’esclave qu’il peut parler à son tour. Pour laisser le temps à l’esclave de décoder le massage la documentation précise qu’il faut faire une pause de 2mS. Avec un délai de 6mS en (4), ce qui ne change pas grand chose à la rapidité de réaction de la sonde, on prend une marge de sécurité. Puis en (5) le logiciel prévient qu’il désire récupérer successivement les deux octets pour « A » dans la « puce électronique ». C’est ce que fait l’instruction en ligne (7). C’est ici que la remarque donnée en préambule prend tout son sens. Ce sera d’autant plus vrai que dans le programme optimisé, la variable CAP_construit sera réellement déclarée comme un int donc une grandeur binaire codée sur 16BITs. Pour la suite des explications, considérez-donc que la déclaration définitive en tête de programme est :
int CAP_construit; // CAP calculé codé sur un entier et non comme un réel.
Considérons la Fig.141 qui résume les opérations effectuées par la procédure et dans le circuit intégré. Le premier MSB = Wire.read(); de la ligne (7) impose au périphérique esclave d’envoyer l’OCTET de poids fort, la valeur est alors préservée dans MSB. (Action A) À la deuxième instruction de la ligne (8) c’est le poids faible du CAP magnétique qui est transmis sur la ligne I2C, puis rangé dans LSB par le programme. (Action B) La valeur calculée du CAP magnétique dans l’électronique interne au circuit intégré de la boussole a été recopié à l’extérieur de l’esclave, et se trouve dans l’électronique du Maître dans deux cellules de RAM qui pour le programme sont des emplacements repérés par MSB et LSB. En l’état ces données sont complètement inutilisables car la valeur complète est coupée en deux morceaux de taille OCTET, il faut reconstituer la grandeur sur 16 BITs pour pouvoir l’afficher sur le moniteur de l’IDE. C’est l’instruction de la ligne (8) qui se charge de ce travail en plusieurs étapes. Décortiquons le processus qui dans son intégralité s’écrit :
• CAP_construit = (MSB : Réalise C c’est à dire que les huit BITs de MSB vont dans les huit BITs de poids faible de la variable CAP_construit. Les bits de poids forts pour le moment sont quelconques et coloriés en gris sur la Fig.141 car ce sont des résidus d’opérations « anciennes ».
• << : Effectue un décalage logique à gauche du contenu intégral de la variable CAP_construit. Les 16 BITs se décalent d’une position à gauche, le premier à droite est forcé à « 0 » et colorié en gris car non significatif pour le moment. Ce décalage (SHIFT left) est représenté en D.
• 8 : Le décalage à gauche est répété huit fois, ce qui fait que MSB qui avant ces décalages était entièrement « à droite » se retrouve entièrement « à gauche » en E. C’est la place que doit occuper tout OCTET de poids fort bien élevé. L’OCTET de poids faible ne contient que des « 0 » non significatifs.
• + LSB : Ajouter LSB à CAP_construit revient à « transporter » comme symbolisé en F l’OCTET en poids faible, car avant l’addition des huit premiers BITs ne contiennent que des « 0 ».
Il ne reste plus qu’à afficher le résultat ; informatiquement une simple formalité :
En ligne (1) l’esclave effectue la mesure, puis la valeur est placée dans la variable CAP_construit. Pour pouvoir bénéficier le la meilleure définition possible sur le capteur, la valeur est fournie multipliée par dix en degrés, donc sur quatre chiffres significatifs. La ligne (2) fait passer le curseur écran à la ligne suivante sur le moniteur vidéo. Puis le texte « Orientation : « est affiché. En ligne (3) on commence par diviser CAP_construit par 10. Enfin ,0 impose au programme de n’afficher aucun chiffre après la virgule. Notez au passage que si vous voulez les dixièmes de degré, il suffit de remplacer le format d’affichage par « ,1« . Pour notre application c’est inutile, sans compter le fait que ce chiffre ne sera pas fiable puisque les valeurs ne sont garanties qu’à 0,5° prés. Enfin la ligne d’instruction se termine par l’affichage du caractère char (186) qui sur le moniteur série de l’IDE est le symbole du « ° ». (Degré angulaire soit 360 de ces unités sur un tour complet.)
Optimiser le programme de traitement de la boussole.
Quelle que soit l’origine d’un exemple que l’on trouve sur Internet, le code source n’est pas forcément idéal et ce pour plusieurs raison. Il peut avoir pour origine la gentillesse d’un programmeur amateur qui a résolu un problème et qui désire en faire profiter la collectivité. Amateurs avertis et débutants se retrouvent sur les sites spécialisés, tous contribuent à leur façon à l’édifice. Si celui qui a mis en ligne un exemple qui fonctionne est un débutant, son « Sketch » sera « brut de décoffrage ». Si vous avez plus d’expérience, alors apporter de l’élégance au premier jet, améliorez ce dernier et à votre tour augmentez la richesse de ce qui se trouve en magasin. Les exemples issus de fournisseurs ne sont pas forcément optimisés. Car le facteur commercial incite à publier le plus rapidement possible, la concurrence est forte. Bien entendu, vous aurez toutes et tous compris qu’il ne s’agit surtout pas de critiquer, seulement d’apporter une amélioration quand c’est possible. Du reste on s’inscrit dans cette ligne de conduite qui consiste à toujours chercher à optimiser à outrance un programme qui fonctionne, c’est un principe qui a été énoncé avec ferveur le jour de notre mémorable arrivée à l’entreprise NDRMSE. Nous allons dans ce qui suit optimiser Mesure_orientation_magnetique() et ainsi gagner encore de précieux octets. Et surtout, par une analyse soignée des variables, ce qui normalement doit se faire au moment où on les intègre au logiciel, améliorer l’élégance de cette procédure qui effectue un travail remarquable. Pour ne pas chambouler tous les autres démonstrateurs actuellement terminés, seul le programme définitif P31_PGM_COMPLET_pour_Raquette.ino bénéficiera de ces quelques optimisations.
La première optimisation consiste à déclarer la variable CAP_construit comme étant un int. Elle ne consommera que deux octets au lieu de quatre dans la RAM dynamique. Vous pourriez penser que c’est du « gagne petit ». C’est oublier que maintenant le microcontrôleur n’aura plus qu’à décaler 16 BITS au lieu de 32, on gagne aussi du code objet. N’oubliez-bas que pour effectuer une opération, l’ATmega328 doit commencer par amener les données dans son unité arithmétique et logique. Il faut charger tous les octets, faire l’opération, stocker à nouveau en RAM le résultat. Mal choisir sa variable engendre un effet boule de neige sur la taille du programme, avec pour conséquence un ralentissement de son exécution. Bref, réfléchissez bien au moment de définir des variables …
Notons que le module logiciel Wire.read() fournit par la bibliothèque n’est pas une procédure, mais une FONCTION. C’est à dire qu’il RETOURNE une valeur typée. On peut donc le placer dans toute instruction à un endroit qui attend une donnée de son type. Comme Wire.read() est une fonction qui retourne une donnée sous forme d’un byte, on peut donc parfaitement remplacer la variable MSB ou la variable LSB par Wire.read(). C’est exactement ce que fait la ligne (3). Du coup la ligne (1) ne sert plus à rien, on l’enlève du programme source. Les deux variables MSB et LSB ne sont plus utiles non plus, et sont également effacées des déclarations. À résumer l’instruction de la ligne (3), on peut la simplifier par CAP_construit = Valeur 1 + Valeur 2. Hors mathématiquement une addition est commutative, calculer CAP_construit = Valeur 2 + Valeur 1 doit donner un résultat identique. Et bien pas en informatique, car une instruction telle que celle de la ligne (3) est bien plus qu’un calcul mathématique. Se sont plusieurs opérations mathématiques et logiques qui doivent se succéder dans un ordre bien précis. Donc nous n’obtiendrons absolument pas le même résultat avec CAP_construit = Wire.read() + (Wire.read() << 8);
Reste à résoudre un petit aléas qui résulte de la façon dont le compilateur traite les affichages et en particuliers ceux de la voie série USB du moniteur de l’IDE. Si on laisse inchangée la procédure Indique_orientation_sur_USB(), l’affichage de la valeur du CAP sera étrange et incompréhensible, car la donnée numérique est un entier int au lieu d’un float. Pour que tout puisse rentrer dans l’ordre il suffit d’imposer à la procédure d’affichage Serial.print() de considérer que la variable CAP_construit 
n’est pas un entier, mais un réel. La correction de type est « soulignée » en rouge dans le listage. Ces quelques modifications font gagner deux octets dans la RAM dynamique et surtout 18 Octets dans le programme objet. Additionné à toutes les optimisations effectuées, le bénéfice devient significatif. Au risque de rabâcher, c’est plus « un mode de comportement » qu’un principe. Affiner un programme devrait systématiquement conclure un développement qui donne satisfaction. C’est la clef pour arriver à traiter un nombre considérable d’actions avec un microcontrôleur en saturant ses possibilités, et éviter de se voir obligé éventuellement à passer à une carte électronique plus puissante …
Disponible dans le dossier <Galerie d’Images>, l’Image 12.JPG permet de situer l’emplacement de la boussole magnétique sur la sonde. Dans le Tome 4 seront précisé en détails l’implantation des connecteurs, les options à prendre en compte, le positionnement des divers trous etc. Dans l’attente de sa publication, vous allez vous contenter de prendre le petit module en main et de l’orienter à convenance. Néanmoins, un petit regard sur Image 15.JPG montre comment est installé le petit circuit imprimé sur la plaque qui supporte le multiplexeur et Image 16.JPG la façon de relier le connecteur au circuit électronique principal.
La mesure pragmatique d’un CAP magnétique.
Contrairement au GPS qui permet de déterminer le CAP géographique du mobile qui s’en sert, le CAP magnétique par nature fournit une orientation fausse par rapport à la carte. Le magnétisme d’une planète, quand il est d’une intensité suffisante pour le rendre mesurable, n’est pas homogène, les lignes « de force » se déforment de façon considérable en fonction de la nature des masses rocheuses environnantes. De ce fait, une boussole magnétique prend par rapport à la référence géographique des orientations « quelconques ». Considérons la Fig.142 qui représente les « lignes de force » du champ magnétique dans une région vue par dessus. Une boussole n’indique pratiquement jamais réellement la direction des points cardinaux, mais ne s’oriente qu’en fonction des « lignes de forces » du champ magnétique planétaire local. Hors ce dernier peut diverger du nord géographique jusqu’à 80° en fonction des « mascons » locaux profondément enfouis dans le sol, surtout si ces derniers sont fortement magnétiques et « aspirent » les lignes de force et ainsi peuvent dévier considérablement le « flux magnétique ». Qu’elle soit constituée d’un petit aimant où de cellules à effet Hall, une boussole s’aligne en 1 sur les lignes de champ magnétique qui sont relativement parallèles. Toutes les boussoles de la région adoptent une même direction. Dans cette zone, la déclinaison magnétique δ qui traduit l’écart entre la direction du nord géographique N et celle indiquée par la boussole Nm est relativement constante. En 2 se trouvent des masses ferreuses qui « attirent et concentrent » le flux magnétique régional. Les directions indiquées par les boussoles sont alors beaucoup plus divergentes.
Deuxième source d’imprécision qu’il faudra impérativement prendre en compte : La pente du terrain sur lequel évolue JEKERT. Il est clairement précisé en Fiche n°23 sur la face (2/2) que la boussole ne donnera des résultats crédibles que si l’assiette du module est parfaitement horizontale. Si la sonde se trouve sur une pente à forte déclivité, le calcul du cap sera faussé. Une expérience amusante consiste à placer la sonde bien à l’horizontale et faire afficher son CAP. Puis incliner en ROULIS, en TANGAGE tout en vérifiant qu’en LACET elle pointe en permanence l’avant du vaisseau dans une direction constante. Aidez-vous du LASER par exemple. Vous pourrez ainsi évaluer les effets des inclinaisons transversales et longitudinales. Puis combinez les deux. Vous allez rapidement arriver à la conclusion qu’indiquer les dixièmes de degrés n’est pas vraiment pertinent.
Troisième source d’incertitude induite non pas par l’environnement, mais générée par le robot. Ce dernier comporte des masses métalliques, certaines sont ferreuses. Par ailleurs les servomoteurs intègrent dans leur technologie des aimants permanents qui joyeusement « diffusent » des champs magnétiques parasites qui faussent les lignes de force de la région où se déplace le mobile. Sur un petit avion de tourisme monomoteur à hélice, le tableau de bord est souvent équipé d’un gyroscope. Ce que les pilotes nomment le conservateur de CAP. Hors cet instrument doit être régulièrement calibré. Dans ce but, généralement placé un peu comme un rétroviseur d’automobile, un compas magnétique se trouve au centre du pare-brise. Hors le moteur sur ces avions constitue une masse ferreuse importante proche du compas et fausse les indications de ce dernier. Pour palier ce problème, la boussole de bord est accompagnée d’une table de corrections. Ainsi un pilote sérieux recalant son gyroscope compensera l’indication du compas, et ajoutera ou retranchera la valeur de la déclinaison magnétique du lieu qu’il survole. (Les cartes marines ou aviation permettent de la calculer.) Alors, pourquoi ne pas établir une correction de la boussole magnétique de JEKERT ?
La technique à utiliser sera précisée dans le prochain chapitre, car nous disposerons d’une aide considérable apportée par la centrale gyroscopique.
La suite est ici.
