Gobalement, les consoles de maîtrise du suivi de JEKERT commencent à fonctionner correctement. Les procédures les plus importantes ont passé les tests de validation. Manifestement, en S4 les ingénieurs logiciels commencent à se détendre, ils sont visiblement moins soucieux. Il reste encore beaucoup de code à écrire. Ceci dit, si le planning reste très chargé, tous savent que dans l’état actuel la sonde pourra débarquer en toute sécurité. Le calendrier sera respecté au point de vue « balistique ». Ce n’est pas une raison pour lambiner. Aussi, on n’entend pratiquement que le ronron apaisant des ordinateurs et les cliquetis frénétiques sur les claviers. Pour ce chapitre, ce sont P21G_Démonstrateur_Raquette.ino et P22G_Démonstrateur_Sonde.ino qui doivent être téléversés sur les deux cartes NANO Arduino. Il est évident que la route est encore très longue avant d’aboutir à un programme complet. Les embûches seront nombreuses, les essais innombrables et laborieux. Il importe de prévoir des outils d’aides logicielles pour faciliter l’analyse :
Quelques outils logiciels pour aider le programmeur.
Développer un programme qui exploitera les possibilités graphique de l’afficheur OLED est manifestement un projet très ambitieux. On va forcément se « cogner à du dur de dur », avec à la clef un comportement du programme strictement incompréhensible. Dans une telle situation, il faut que le programmeur puisse placer des « points de test » qui déclenchent une alerte quand le processeur déroule des instructions qui viennent d’être ajoutées dans le Source et qui manifestement ne produisent pas l’effet escompté. La première question à se poser est :
– Le programme passe t’il vraiment dans la procédure ajoutée au programme ?
Ce n’est pas évident, surtout si la subroutine est invoquée suite à une combinaison un peu complexe de booléens. Une parenthèse mal placée, un ET à la place d’un OU … qui ne s’est jamais fourvoyé dans de telles instructions ? Pour savoir si le programme emprunte bien un chemin particulier, il suffit d’introduire provisoirement l’instruction BIP(); de la Sonde. Si le buzzer reste silencieux et que la procédure devrait se voir activée … c’est qu’il y a un problème en amont, la séquence n’est pas en cause. Si il y a un BIP, alors le diagnostic s’oriente vers un questionnement du genre :
РLa proc̩dure est bien invoqu̩e, quelle est alors la valeur de la variable X en entr̩e / sortie ?
Pour suivre les variations d’une variable dans une séquence de code quelconque, il suffit d’en faire afficher la valeur sur l’écran OLED, peu importe l’endroit sur sa matrice de pixels. L’idée consiste dans ce cas à ajouter au programme une subroutine spécifique à laquelle on fait appel à des emplacements stratégiques dans le programme. Comme ce type d’action sera rencontré souvent, autant rédiger une procédure « propre ». À partir de la version G des démonstrateurs nous aurons à notre disposition la routine de servitude :
L’instruction display.update(); est indispensable pour que la donnée soit affichée à l’écran. Le délai d’une seconde n’est utile que si l’on fait appel plusieurs fois à cette procédure. Il faut nous laisser le temps de voir les diverses valeurs évoluer durant le déroulement du programme. Enfin, comme pour plusieurs autres lignes stratégiques dans le programme, la remarque composée d’une ribambelle de @@@@@@@@@@@@@@@ permet facilement de retrouver la séquence avec une recherche de cette chaîne de caractères dans Édition > Trouver …
– Nom d’un Octet mal placé, j’en ai ma dose de cheminer dans les menus jusqu’à la nouvelle option à tester, je vais finir par destroyer mon beau codeur rotatif !
Pour gagner un temps considérable, on impose durant le développement d’ouvrir le menu en cours de mise au point directement sur l’Item à tester. Dans ce but, il suffit de modifier la constante adéquate dans les déclarations. Lorsque l’on désire revenir à la page d’accueil normale, on rétablit la constante et le tour est joué :
Par exemple, la valeur 4 est provisoirement substitué au 6. Pour pouvoir rétablir facilement le fonctionnement prévu en standard, dans les lignes de remarque sont précisées les valeurs prévues pour la version ultime. Nous avons les outils nécessaires pour poursuivre nos études. Notons au passage que cette version G fait appel à un changement de gestion des fonctions QUITTER et Reveiller JEKERT : On quitte les dialogues entre sonde et pupitre par la consigne (61) qui positionne le booléen Hibernation à true. Reveiller JEKERT par la consigne (55) le repasse à false.
Changement de stratégie.
Forcément, les nombreuses campagnes de tests font émerger des difficultés d’exploitation. Aussi, et ce n’est pas la première fois du reste, il faut changer les protocoles, revoir l’implantation du pupitre etc. Pour cette version du démonstrateur, plusieurs virages s’imposent. Un changement important concerne l’affichage du spectre colorimétrique qui fait l’objet du chapitre suivant. De plus, on se rend inévitablement compte que l’usage du Clavier / Codeur rotatif devient confus. Quatre LEDs vont assister l’opérateur : Une Verte qui clignote et signale une attente clavier pour passer à la suite. En impulsif elle témoigne de l’appui sur une touche quelconque. Une LED rouge signale une erreur, (« BIP optique ».) ou que le B.R. fonctionne en gradateur lumineux ou que le menu
> MOUVEMENTS < est actif agissant sur la motorisation. Une LED jaune signale qu’une fin de fonction doit être impérativement effectuée avec la touche FIN. Enfin une LED bleue non clignotante signale le mode > MOUVEMENTS <. Les couleurs du rouge au bleu sont fonction de la « dangerosité » de la configuration signalée par ces témoins lumineux.
Certaines fonctions sont « muettes ». Quand on les valide avec OUI il ne se passe rien sur l’écran OLED et l’on peut douter de leur prise en compte par la sonde. Pour lever le doute, ces dernières génèrent le faux code d’erreur E99 qui signale que la consigne a été effectuée avec succès. Cette information comme tout accusé de réception de type erreur issue de la sonde provoque un BIP d’alerte. Les fonctions concernées par les fausses E99 sont les suivantes :
• Calage du gyroscope. (Car si le CAP magnétique affiché ne change pas lors de cette manipulation, rien n’évolue à l’écran.)
• Phares et LASER forcés à 127.
• Sauvegarder la posture actuelle en EEPROM.
Traitement du spectre colorimétrique.
Eenregistrer la lumière totale ainsi que six couleurs différentes imposent un écran particulier pour afficher toutes ces données. Le 
démonstrateur G met en place les routines pour pouvoir dans le menu > EXPLOITER. < enregistrer un spectre couleur, (Voir Fig.266 A) ou le faire afficher. (Commande de la Fig.266B) La Fig.267 présente la façon dont sont listées les diverses données d’un enregistrement spectrométrique. Un petit point de détail qui a son importance doit être souligné : Quand la Jambe A vient vers l’avant pour que le dernier secteur couleur verte soit au dessus de la cellule photorésistante, la ligne d’alimentation des moteurs du Genou et du Pied peut venir au dessus du capteur de lumière. De ce fait la mesure serait faussée et les rapports de sensibilité entre les divers filtres ne seraient plus respectés. Pour éliminer ce petit problème on réunit toutes les lignes des sorties S1 à S5 en un seul toron comme montré sur les photographies de la Fig. 268 et sur Image 57.JPG conduisant à un parfait dégagement vers le haut. Remarquant que les informations issues d’un spectre colorimétrique constituent des valeurs 
« scientifiques », on devrait assez logiquement les obtenir dans le menu des DONNEES SONDE. Après diverses tentatives pour évaluer la commodité réelle des solutions adoptées, il ressort que placer cette page dans le menu
> EXPLOITER. < est plus judicieux dans la mesure où cet item suit celui de la SAuVegarde du spectre colorimétrique.
Fonctions ajoutées à la version G.
Étant en phase de développement, il importe d’avancer avec prudence, c’est à dire que chaque version sauvegardée doit faire évoluer le programme, mais raisonnablement. Ainsi, si pour une quelconque raison une « catastrophe » se produit et qu’il faut repartir sur de nouvelles bases, revenir en arrière est plus facile. Toutefois, l’excès contraire doit aussi se voir éviter, chaque étape devant apporter un nombre suffisant d’améliorations. Conciliant prudence et mutation notable, la Fig.269 présente les nouvelles fonctions du menu > EXPLOITER. < qui maintenant ouvre sur la page Reveiller JEKERT. Puis, Test Gyroscope suit et se trouve actuellement avant Calage GYRO car dans l’optique d’une reprise d’activités, cet ordre est plus cartésien. Arrivent alors les fonctions « éclairages ». C’est à leur suite que l’on trouve les fonctions listées sur la Fig.269 qui commencent par Utiliser le LASER.
Comme il faut prendre en compte les problèmes de sécurité pour les personnes qui éventuellement se trouvent dans la pièce où se trémousse la sonde, consultez le Manuel d’utilisation (1) à la page Protocole d’utilisation du LASER. (ATTENTION : Le livret a été rédigé avec la version « définitive » du logiciel. La version actuelle G n’est pas forcément 100% compatible.) Les valeurs des balayages angulaires possibles sont détaillées dans le chapitre Gestion du pointage LASER disponible dans le livret de maintenance nommé DOSSIER TECHNIQUE. (1) Après l’usage du LASER on arrive à l’émulation de la fonction TORSION active. Le codeur incrémental engendre du Lacet relatif dans une direction qui est fonction du sens de rotation.
(1) Cet deux livrets sont fournis avec les fichiers du TOME 6.
ATTENTION : On peut aller dans une configuration avec interférence de certains éléments des Jambes sur des organes du châssis. Il n’y a pas de détection des collisions, donc surveiller visuellement et surtout ne pas exagérer la déviation latérale.
Les commandes pour réaliser un panoramique télémétrique sont présentées sur la Fig.270 respectivement en A pour l’enregistrement en EEPROM, et en B pour sa visualisation. L’approche pour effectuer la saisie des échantillons (Résumée sur la Fig.272) est un peu différente de celle du développement initial inspiré par des manipulations mettant en Å“uvre un potentiomètre matériel. Les valeurs retournées par le convertisseur analogique numérique s’étendaient alors de [4 à 1000]. La valeur pour le centrage avait été de ce fait fixée à 502. Pour balayer la totalité du spectre, on procédait par des incréments de 15 unités. Avec 
l’approche numérique, on peut à notre convenance utiliser la pleine plage binaire [0 à 1023]. Il devient alors naturel de placer le centrage à la moyenne de 512. En observant l’affichage sous forme graphique montré sur la Fig.271 on peut déduire que la définition verticale du cadre bleu ne laisse à notre disposition que quarante trois lignes de pixels. Trente deux enregistrements optimisent l’aspect programmation et sont suffisants vu la médiocre ouverture angulaire des transducteurs ultrasons et la présence de parasites comme ceux présents en α et β par exemple. On optimise dans ce cas l’amplitude du balayage par des pas de 31 unités. Répartis à partir du centrage, les valeurs extrêmes seront donc comprises dans la plage [47 à 1008] bornes comprises.
La suite est ici.
