Chamboulement du planning. Les informaticiens avancent bien plus rapidement que prévu. JEKERT est encore loin du freinage de mise en orbite. Aussi, la direction a réuni les utilisateurs et les programmeurs. Puisque les ingénieurs logiciel disposent de bien plus de temps que prévu, fait assez rare dans le domaine de l’astronautique pour être souligné, les divers participants à la réunion ont mis en commun leurs spécificités pour ajouter au cahier des charges fonctionnels des fonctions qui n’avaient pas été envisagées initialement. Les campagnes d’essais ont montré qu’il était possible d’améliorer substantiellement les outils de pilotage du petit robot. Les dernières télémesures montrent qu’il hiberne parfaitement. Tous va bien pour JEKERT. Nous retournons en salle S4.
Améliorer la lisibilité du programme.
Graphismes désirés en place, petit tableau de bord affiché en temps réel, SÉCURITÉ à tout va et tout y quanti … rien à faire, nous n’en sommes qu’à 80% d’utilisation de l’espace réservé au programme dans le circuit ATmega328. Au sens de la rentabilité c’est encore tristounet. Plus exactement, ayant assouvi nos désirs « graphiques », il nous reste encore beaucoup de place pour perfectionner le pupitre. Les chapitres qui suivent seront consacrés aux nouvelles fonctions. Toujours affectés des défauts de présentation des logiciels précédents, ce sont P21N_Démonstrateur_Raquette.ino associé à P22N_Démonstrateur_Sonde.ino qui sont à télécharger sur Arduino pour expérimenter les nouveautés. Un programme lisible ne doit pas contenir une boucle de base void loop() comportant des dizaines de ligne. Une bonne pratique consiste à agencer une séquence qui ne fait appel qu’à quelques procédures dont les identificateurs se lisent « comme un livre ordinaire ». Dans les versions précédentes, la boucle de base était devenue inutilisable car infiniment trop encombrée. Le remède qui s’impose a consisté à remplacer chaque « bloc fonctionnel » par l’appel d’une routine indépendante. Je vous invite à consulter le nouveau listage, car P21N fait peau neuve. Et encore, si nous poussions la logique jusqu’à créer une procédure pour les clignotements, la boucle principale du programme ne contiendrait que cinq instructions. Pour la lisibilité il serait impossible de faire mieux.
Imposer numériquement la valeur du Cap désiré.
Initialement, cette fonction n’avait pas été envisagée, car imposer la valeur d’un cap oblige à saisir un nombre, et notre clavier ergonomique n’a pas de touches numériques. Ce serait envisageable, il suffirait en mode saisie que certaines touches soient affectées aux dix chiffres. Cette idée simple n’est pas exploitable, car visuellement la « sérigraphie » du clavier deviendrait confuse, sans compter le fait que géométriquement les touches seraient mal réparties. Aussi, quand cette possibilité d’imposer un Cap a été éludée, caler le gyroscope avec la commande 59 se contentait d’affecter la valeur du Cap magnétique actuel. Si l’opérateur désirait suivre une route particulière, la première étape consistait à faire tourner la sonde jusqu’à ce qu’elle soit correctement orientée. Ensuite, on calait le gyroscope. Le pilotage consistant alors à corriger vers la gauche ou vers la droite quand en se déplaçant JEKERT dérive. Outre que cette procédure est contraire aux concepts fondamentaux du pilotage, elle s’avère pratiquement irréalisable sur le petit insecte mécanique.
Contraire au concepts de base de la conduite d’un mobile car « à l’envers ». En toute logique on ajuste les systèmes de navigation pour la route désirée. Ensuite, on corrige la trajectoire en fonction des écarts indiqués par les systèmes de bord. Irréalisable, car JEKERT n’est pas un véhicule sur roues que l’on peut orienter finement en direction. La petite machine se dandine. Quand elle avance, les Griffes frottent, glissent, engendrant des dérives angulaires significatives. Quand on lui fait effectuer une rotation, l’amplitude du changement angulaire est de plusieurs degrés. Il sera impossible de l’orienter finement avec les mouvements élémentaires. On peut utiliser la Torsion pour caler la navigation, c’est faisable et prévu dans ce but. N’est pas très conviviale est cette méthode …
Imposer un Cap Magnétique désiré peut se faire agréablement par utilisation du codeur incrémental. Dans les items du menu EXPLOITER, avec cinq pas dans le sens négatif à son appel, on fait afficher la fenêtre de la Fig.325 qui validée avec le BPccr ouvre 
la page de saisie. Par défaut sur un RESET la route désirée est plein Nord, donc un Cap Magnétique nul. C’est ce que montre la Fig.326, le code 96 servant à récupérer la valeur initialisée sur la sonde. Comme plusieurs fois abordé, nous savons que pour des raisons de fiabilités des informations affichées sur la console, les valeurs sont préservées sur la sonde et c’est par interrogation de cette dernière que l’on rafraîchit l’écran OLED. Les deux touches de « déplacement latéral S6 et S14 servent à déplacer en permutation circulaire le curseur d’écriture sur les trois chiffres du Cap. (Trois chiffres significatifs sont affichés systématiquement avec éventuellement des zéros en tête.) Ce curseur symbolisé par une flèche verticale indique le chiffre qui sera modifié si on tourne le codeur rotatif quand on est en mode de saisie de la route souhaitée. Quand le codeur incrémental est manipulé dans un sens ou dans l’autre, on a l’impression visuelle que seul le chiffre pointé est modifié. En réalité, on agit sur un nombre, c’est à dire que l’entité complète est augmentée ou diminuée. Par exemple faire un pas négatif d’une unité quand le cap vaut 100° fait passer l’affichage à 099°. En négatif une butée virtuelle bloque la valeur à zéro. En positif, si arrivé à 359° on tourne le capteur dans le sens horaire, quel que soit le chiffre indexé la valeur repasse à 000°. La sortie du mode « Saisie du cap pour la route souhaitée » se fait impérativement avec FIN. Pour des raisons de convivialité la saisie du cap s’ouvre avec l’index sur un Poids_Decimal = 10. Tout B.P. autre que FIN, S6 et S14 génèrent un BIP sonore d’erreur.
Référence Magnétique, référence Gyroscopique.
Information secondaire, la référence Gyroscopique interne est une donnée technique qui concerne plus la maintenance que la gestion du robot sur le sol de Mars. Quand le mode affichage continu des données est actif et que l’on visualise le petit tableau de bord graphique, chaque action sur le BPccr change la référence. Lorsque c’est la route magnétique initialisée par la procédure décrite dans le chapitre précédent qui est prise en compte, la lettre M indique clairement que c’est le Cap Magnétique actuel comparé à la Route Magnétique désirée qui génèrent la valeur de l’Ecart de route. Si on clique sur le BPccr la référence devient alors la donnée interne du MPU-6050 associée au gyroscope de Lacet. La lettre M est changée par G pour informer l’opérateur de l’option en cours. Cette référence est initialisée chaque fois que l’on valide dans le menu EXPLOITER l’item Calage GYRO. qui prend une valeur qui n’a rien à voir avec l’orientation en Lacet de la sonde. On peut considérer que cette valeur dépend de l’orientation du moment par rapport à l’univers. L’Ecart de route correspond alors à la différence entre l’orientation en Lacet actuelle et cette valeur préalablement enregistrée. En référence Gyroscopique on affiche bien un écart d’orientation entre la direction initiale et celle actuelle de la sonde, MAIS PAR RAPPORT AUX ÉTOILES. La rotation de l’astre sur lequel se trouve la sonde intervient comme déjà explicité en détails dans le chapitre sur la dérive gyroscopique. On peut considérer que la référence Gyroscopique conduit à une observation absolue par rapport à l’Univers, alors que la référence Magnétique est relative par rapport à l’astre sur lequel se trouve posé JEKERT. L’opérateur préfère généralement se repérer par rapport à l’environnement local, il privilégie en standard le Cap Magnétique pour s’orienter.
Utilité pratique de la référence Gyroscopique.
Puisque par nature la référence magnétique est plus facile à prendre en compte par le pilote de la sonde, pourquoi se préoccuper de cette référence interne qui s’oriente par rapport à l’Univers et ignore le lieu sur lequel on se trouve ? Plusieurs raisons techniques viennent plaider sa cause. Initialement, le Gyroscope vient remplacer le compas magnétique quand ce dernier n’est plus crédible. Par exemple, quand sur un petit avion on engage un virage standard, on incline l’appareil en roulis. Si à cette inclinaison acquise relativement vite on ajoute de plus des turbulences, la boussole s’affole. Un navire, même de taille imposante, peut se faire chahuter fortement en roulis et en tangage par une mer forte. (Rien n’est grand par rapport à la mer.) Le compas de route dans ces conditions se dandine avec frénésie. Dans ces exemples, le gyroscope reste de « marbre ». C’est l’outil idéal pour assurer la navigation … sauf qu’il dérive car la Terre tourne par rapport à sa référence universelle. C’est alors le compas de route, quand il n’est pas perturbé, qui sert pour le pilote à recaler le gyroscope de bord. Il est clair qu’avec l’avènement du GPS, surtout comparé au coût important d’un gyroscope mécanique, les conservateurs de cap « à l’ancienne » sont en voie de disparition …
Reste que la centrale gyroscopique est bien plus précise que la boussole. Nous savons que celle utilisée à bord de JEKERT est corrigée, le calcul assurant cette fonction conduit à une imprécision angulaire de plusieurs degrés. Enfin, notre petit robot est aussi un vaisseau spatial. Ces machines que l’on éjecte à des distances phénoménales se déplacent loin loin loin de tout astre. Pour les orienter en vue d’effectuer les corrections de trajectoire ou pour le freinage de capture gravitationnelle pour se mettre en orbite, elles n’ont que les étoiles pour faire le point. La centrale gyroscopique est alors la technologie incontournable pour assurer la navigation et ce d’autant plus qu’il n’y a plus présence de champs magnétiques pour orienter une boussole.
* Par défaut, sur un RESET de l’ATmega328, c’est le Cap Magnétique qui est initialisé, correspondant à une donnée plus opérationnelle que celle de la référence gyroscopique.
* La page de navigation dans le menu des DONNEES continue à afficher la valeur gyroscopique même si l’on est en option référence Magnétique car ce menu concerne la maintenance. C’est donc la dérive de l’Ecart gyroscopique qui observée à divers moments permet de s’assurer du bon fonctionnement de la centrale de navigation MPU-6050.
Calculer l’Ecart de route avec la convention ±180°.
Illustré par les Fig.319 et Fig.320 le chapitre Faciliter le travail du navigateur consiste à raisonner en relatif à exprimé en détails l’avantage à placer « en haut » la direction dans laquelle on désire aller. Puis, par rapport à cette route souhaitée, effectuer une dichotomie Gauche / Droite pour indiquer l’écart de route avec les valeurs 
limitées à +179° / -180°. Pour mémoire, la Fig.327 résume le but à atteindre. Le petit cercle noir nommé parfois « bug » quand on parle d’un index spécifique à l’aviation, précise sur la rose des vents la direction que l’on désire emprunter. Par rapport à cette direction, on affecte par convention à gauche le signe positif, et à droite le signe négatif. L’écart de route sera ainsi limité en amplitude à 180°. Par exemple, sur la Fig.327 E sera égal à +150° pour le navire cas A et -120° pour la direction B. Pour calculer la valeur de l’écart, il serait possible de partir de la définition E = Cap actuel – Cap désiré. Si on dépasse 180° on prend la différence avec 360°. Puis on affecte le signe conventionnel. Cette approche qui se résume à une soustraction et deux comparaisons semble idéale de simplicité. Testez et vous allez vous rendre compte que l’on ne peut pas faire aussi élémentaire. Soit les amplitudes calculées ne sont pas bonnes, soit le signe ne convient pas. J’ai pourtant effectué de nombreux tests, aligné du code à profusion : Rien à faire, pas moyen de traiter par des calculs !
C’est la deuxième fois que confronté à ce type de problème, je n’ai pas réussi à trouver un algorithme de calcul relativement simple. Dans une telle situation, il faut bien trouver une solution. Pour ma part je fais alors appel à des boucles pour simuler le phénomène. Pour qu’une telle solution soit raisonnable il importe que la boucle de détermination ne comporte pas trop d’itérations, car alors le temps de calcul deviendrait prohibitif et ce d’autant plus que dans cette application ludique on désire un affichage en temps réel.
Considérons le listage de la procédure qui sert à calculer l’écart de route. Quand on fait appel à cette subroutine, préalablement la variable Angle est initialisée à la valeur du Cap Magnétique actuel d’orientation de la sonde. La variable Ecart_gyroscopique va servir à calculer la grandeur de l’écart de route, limitée à une amplitude maximale de 180°, et affectée du signe conventionnel, quel que soient au départ les valeurs de l’entier Angle codé sous la forme d’un int et de l’entier Cap_magnetique_de_consigne également préservé dans un int. Dans le premier cas le choix d’un int se justifie car la valeur manipulée peut aller jusqu’à 359 et dépasse donc les 124 d’un byte. Ecart_gyroscopique quand à lui ne dépassera pas 180. Toutefois un byte ne peut contenir cette variable, car elle est signée. (Signée au sens de signe algébrique.)
L’idée pour déterminer la valeur d’Ecart_gyroscopique consiste à imaginer que l’on est actuellement dans la bonne direction, donc en (1) on indique une déviation nulle. Puis on simule une rotation du vaisseau, arbitrairement dans le sens positif. En ligne (3) Ecart_gyroscopique augmente de 1° ainsi que la valeur Angle. En (4) on « franchit » la valeur 360, donc on recycle à zéro. Puis, en (2) on recommence tant que l’orientation fictive n’est pas égale à la direction souhaitée. Le programme sort alors de la boucle while. Enfin, l’instruction (5) détecte si l’on a tourné de plus d’un demi-tour. Si c’est le cas, en (6) on recalcule le complément à 360 et l’on inverse le signe. Dans le pire des cas, la boucle sera parcourue 359 fois. Elle ne compote que deux petites additions binaires et une comparaison. Compte tenu de la rapidité de fonctionnement de 
l’ATmega328, le temps pour effectuer cette simulation reste dérisoire : Solution adoptée. Pour faciliter l’analyse à ceux qui le désirent, la Fig.328 résume la méthode utilisée, sauf que cette fois le dessin décrit la scène le Nord étant conventionnellement vers le haut. La route souhaitée correspond aux 225° de la Fig.315 et nous évoluons actuellement au 355°.
1) Calculer par incréments de 1° la grandeur de l’écart ici montré par la flèche courbe rouge,
2) Si l’angle dépasse 359 degrés le forcer à zéro, (Ici ce n’est pas le cas.)
3) Quand la flèche rouge = le Cap actuel du vaisseau stopper l’évolution, (Ici Ecart = 240°)
4) Si Ecart > 180 recalculer : Ecart = 360 – Ecart = 120, et changer de signe.
(Dans notre exemple on trouve -120° qui correspond bien à la flèche courbe verte sur le dessin.)
ATTENTION : Avec une ou deux petites formules, vous aller coder un calcul et voir que ça fonctionne. Du coup vous en déduirez que Nulentout s’est fourvoyé. Les cas particuliers sont nombreux, les pièges variés. Pour savoir si votre programme est correct, il faut impérativement établir un jeu d’essais exhaustif. Le tableau donné ci-contre propose ma campagne de vérification. Toutes ces variantes réfléchies ont été soigneusement vérifiées. Surtout ne pas imaginer que 
moins de vérifications suffise.
Optimisation de la saisie du cap magnétique désiré.
Optimiser le code fait partie de la routine du programmeur. Toutefois, pour saisir la valeur de la route désirée et l’indiquer à la sonde, plusieurs spécificités viennent particulariser cette fonction. Il n’est pas question d’envoyer la valeur chaque fois qu’elle change lorsque le codeur rotatif fait un pas. Les échanges « radio » entre le pupitre et la sonde seraient trop nombreux et ralentiraient le processus. L’ouverture du mode saisie de Cap fait appel à la procédure void Saisie_du_CAP_magnetique() dont la Fig.329 représente globalement le déroulement. En (1) on prévient l’opérateur qu’il faut sortir par la touche FIN. Puis en (2) la valeur actuelle préservée dans JEKERT est téléchargée en envoyant le code 96. En (3) l’écran de l’afficheur OLED est effacé et la page de saisie est affichée, y compris le pointeur du caractère qui sera modifié. En (4) on informe la boucle de base que le mode de saisie d’un CAP est en cours ce qui conditionnera le comportement de la procédure qui traite le codeur incrémental. Enfin en (5) on précise que par défaut c’est le chiffre des dizaines qui sera modifié.
Durant la boucle de base, le programme vérifie si le codeur rotatif a été utilisé. Si c’est la cas, alors void loop() fait appel à TRAITE_LA_ROTATION_DU_CODEUR_INCREMENTAL() qui teste quel mode est actuellement en cours. Si Mode_saisie_de_CAP_magnetique est à true alors cette procédure modifiera la valeur de l’identificateur Cap_magnetique_de_consigne en fonction du sens de rotation détecté et de la valeur actuelle de la variable Poids_decimal.
Transmettre la valeur du cap souhaité pose un problème particulier, qui du reste avait fortement influencé l’abandon initial de cette fonction. Au début du projet, un bilan pessimiste prévoyait entre trente et quarante consignes, et déjà autant de fonctions semblaient beaucoup. Pour optimiser le programme, les messages envoyés sur TX ont donc été envisagés avec trois caractères. Deux pour le code compris entre 1 et 40, suivi de la sentinelle ‘*‘. Et puis une idée en attire une autre. Une nouvelle fonction induit parfois plusieurs consignes. La liste s’est allongée. L’optimisation du code a repoussé en permanence les limites, et arrivé vers 90 codes il restait encore de la place pour de nouvelles séquences. Les dernières commandes ont imposé une étude sévère, car la limite à deux chiffres pour le code imposait au maximum 99 consignes. Aussi n’imaginez-pas que le code 96 indispensable pour interroger la sonde était prévu d’avance. Tous les codes étaient déjà pris. Pour dégager une consigne, diverses modifications ont été apportées, raison pour laquelle du reste, la répartition des ordres dans le tableau des consignes n’est pas forcément constituée de regroupements logiques et ne respecte pas obligatoirement l’historique de leurs affectations.
Problème : Non seulement il faut transmettre une valeur sur trois chiffres, et surtout il n’y a plus de codes disponibles dans les étagères informatiques. La solution consiste à envoyer une consigne particulière qui par sa structure sera différenciée de toutes les autres. Avant d’analyser le code reçu, l’esclave commence par tester s’il s’agit de cette dernière. La technique adoptée consiste à transmettre la consigne sous la forme d’une chaîne de caractères de la forme « Cnnn*« . Contrairement à tous les autres messages, celui-ci commence par C indiquant qu’il s’agit d’un Cap magnétique à enregistrer. L’esclave détectant ce caractère en tête de chaîne sait alors qu’il doit convertir le reste de la chaîne en nombre et affecter cette valeur à Cap_magnetique_de_consigne. Invoquée quand on clique sur FIN, la séquence qui traite la transmission de cette directive se résume à très peu de chose :
La ligne (1) en trois instructions transmet la chaîne de cinq caractères commençant par l’identificateur spécifique ‘C‘. Puis en (2) la maître attend l’accusé de réception retourné par l’esclave. L’écran est alors modifié puis affiché pour informer l’opérateur de la prise en compte par la sonde. Pour finir, en ligne (3) ferme le mode de saisie et éteint la LED clignotante jaune.
La suite est ici.
