TOME 6 : Les fichiers du TOME 6 sont ici.
Pour mémoire, l’ouvrage précédent s’était achevé tragiquement sur la foudre qui est tombée inopinément sur le complexe de la NDRMSE provoquant une perte de donnée sur ZARIA le gros ordinateur qui héberge l’ensemble des fichiers produits sur les ordinateurs de la salle informatique S4. Pour couronner le tout, les systèmes informatiques de traitement de texte ont sombré dans une saturation matérielle qui a définitivement paralysé la rédaction des documents de suivi du projet, réunis dans ce que l’on nomme à la NDRMSE le TOME 5. Des mesures de sauvegarde sont heureusement régulièrement engagées, et malgré ces aléas fréquents dans le monde de la technique, les personnels peuvent reprendre le travail comme si rien ne s’était passé. Les modules logiciels d’exploitation P21J_Démonstrateur_Raquette.ino associé à P22J_Démonstrateur_Sonde.ino ont été réimplantés sur les machines informatiques. La journée continue sereinement …
53) 11/01/2018 : Reprise des activités à la NDRMSE (MJD 58129)
Revenant en salle informatique après avoir pris le repas de midi en compagnie des techniciens, je m’attendais à ce que les informaticiens planchent sur le pilotage manuel des moteurs, conformément au planning. Force est de constater que l’activité actuelle de Ferrando sur son terminal ne semble avoir aucun rapport.
– Jour Max, vous ne travaillez pas sur la motorisation cet après midi ?
– Ben non, c’est Tassin qui s’en charge. Comme on galère trop sur les échanges de données entre les pupitres et la sonde, on va appliquer une nouvelle stratégie. On modifie le contenu des écrans de maîtrise, ainsi l’opérateur aura sous les yeux aussi bien l’information relative à la consigne envoyée sur le canal montant que l’accusé de réception sur la voie descendante.
– Ha bon, la direction est au courant ?
– Naturellement, du reste c’est le Derlo qui nous l’a expressément demandé.
Changement de protocole d’exploitation de l’écran OLED.
Concrètement, ce changement de stratégie a été inspiré par la lourdeur d’avoir à se servir du moniteur de l’IDE pour surveiller les consignes envoyées par le pupitre vers la sonde. Il en a résulté l’idée de faire afficher cette information sur l’écran OLED, artifice d’autant plus justifié qu’il consiste à n’écrire au maximum que deux chiffres sur la matrice de pixels du petit écran. Pas bien compliqué dans ces conditions de trouver un emplacement dans cette optique. Par ailleurs, sur le plan de la crédibilité, cette procédure est parfaitement justifiée. Dans les stations de poursuite ou de gestion de satellites, les opérateurs ont des écrans pour toutes les informations descendantes, mais également vers celles qui sont envoyées aux lointains vaisseaux. La nouvelle répartition des informations sur la surface utile est représentée sur la Fig.273 avec en haut à droite le petit cadre qui ne contiendra désormais que Rot ou CLV. En 1 les titres des menus ont été réduits en largeur pour occuper moins de place : Les
caractères ‘<‘ et ‘>‘ ont été enlevés. Ainsi, sur la petite zone à gauche du cadre jaune en 2 seront affichés les accusés de réception. On retrouve en 3 l’information sur l’item des OPTIONS actuellement indexé dans la liste « déroulante ». En 4, s’affiche ici de l’état de l’option. Le code 72 a été envoyé pour sortir du mode apprentissage. JEKERT à satisfait cette consigne et retourné OK. C’est précisément l’accusé de réception qui reste présent en 2. Puis le logiciel du pupitre à transmit la directive 44 affichée en 5. La sonde a alors retourné la donnée d’état du système. Le programme ayant analysé cet ACR en a déduit qu’actuellement la sonde est hors mode apprentissage, et 4 reflète une réalité physique effective.
Ajout du pilotage manuel des servomoteurs.
Ayant logé les textes définitifs en EEPROM, téléversez P21J_Démonstrateur_Raquette.ino sur la carte Arduino du pupitre et son associé P22J_Démonstrateur_Sonde.ino sur celle de la sonde. Nous allons, pour cette journée Julienne 58129 passer en revue les apports de la défunte version H dont les octets reposent en paix dans les oubliettes du software. Les fonctions de base étant en place, on commence par ajouter et tester le Pilotage MANUEL et individuel des divers servomoteurs de la petite machine. Pour mémoire les limites de consigne ne sont pas surveillées. Il faut par conséquence ne pas aller chercher les valeurs qui engendrent une divergence des asservissements. Évitez soigneusement d’amener les mouvements trop vers les extrémités des débattements angulaires … et ne placez pas trop loin le bouton de panique. Pourvoir à tout moment se faire afficher les valeurs des consignes de la posture actuelle permet par comparaison avec celles de la Fiche n°10 de visualiser l’approche des zones de fonctionnement critiques. Quand on valide la fonction avec OUI, la LED rouge de « motorisation en action » se met à clignoter. La 
LED jaune de « Sortie par FIN impérative » aussi. L’écran de la Fig.275 s’affiche, mais surtout, il ne se passe rien sur les moteurs. Pourtant nous n’avons pris aucune précaution de centrage du potentiomètre comme c’était le cas pour la version initiale du système. L’avantage considérable d’un potentiomètre numérique, c’est de pouvoir l’initialiser à une valeur quelconque. Donc, chaque fois que l’on change de servomoteur, le programme va chercher sa valeur actuelle de consigne et la recopie dans la variable gérée par le codeur incrémental. L’ensemble des moteurs reste maintenant totalement inerte, seule l’action sur le codeur engendrera des mouvements. En 4 est indiqué le dernier code envoyé par la raquette avec en 1 l’accusé de réception. En 2 sera indiqué la Jambe sur laquelle on agit actuellement, et en 3 quel servomoteur est sollicité. Vous pouvez aussi remarquer qu’en 5 la LED clignotante jaune est complétée par une directive visuelle du genre « j’insiste lourdement ! ».
Pour des raisons d’agrément, dans ce mode le bouton central du capteur rotatif permet d’alterner entre des incréments angulaires importants ou faibles. Il est ainsi facile à tout moment d’adapter la finesse avec laquelle on engendre les mouvements individuels. Dans sa version ultime, le programme de la raquette de pilotage a considérablement évolué, et telles qu’elles était présentées sur la Fig.243, la disposition des touches et des LEDs du clavier n’est plus idéale. La Fig.276 propose un réaménagement envisagé actuellement pour améliorer la convivialité opérationnelle.
Bien que toutes les LEDs actuellement gérées par l’ATmega328 ne sont pas regroupées sur le clavier, on note que la LED
d’incitation à cliquer sur une touche est toujours voisine de la touche OUI mais de couleur verte. La diode jaune qui clignote pour sortir d’un mode impérativement par la touche FIN est maintenant juste au dessus de la touche concernée. Changement de stratégie qui sera effectif dans la version du logiciel qui traite de l’APPRENTISSAGE, un menu spécifique sera réservé à ce mode particulier d’exploitation de la sonde sur le terrain. En version ultime, APPRENTISSAGE a considérablement évolué, le nombre de ses options encombrerait exagérément le menu EXPLOITER. Aussi, on a abandonné la touche dédiée à l’annulation des efforts, 
item qui fait alors partie des POSTURES. La touche A est donc devenue une fonction permanente au même titre que les cinq autres touches fonctionnelles. Du coup la zone B relative aux mouvements n’encadre plus S10. Naturellement cette zone coloriée en bleu regroupe tous les boutons rouges tel que D, générant les déplacements élémentaires. Quand on pilote un moteur en mode manuel, il devient évident de savoir instinctivement sur quelle touche agir pour changer d’articulation. Dans ce but la sérigraphie comporte deux zones vertes C et E. Quand on est en mode pilotage manuel des servomoteurs, il faut oublier l’usage standard des diverses touche du clavier, seules celles coloriées sur la Fig.277 auront un effet. En particulier les deux boutons F n’agissent plus sur les phares et sur le LASER. La zone verticale C doit faire penser à une Jambe dont les boutons en partant du haut vers le bas représentent respectivement la Hanche, le Genou et le pivot du Pied.
La zone rectangulaire E représente la sonde vue par dessus, les touches situées dans les angles symbolisant les Jambes. Dans cette symbolique, l’Avant de la petite machine est indiquée par la flèche verte. Quand on désire changer de servomoteur, on désignera dans un ordre arbitraire l’articulation concernée et avec A, B, C ou D la Jambe sur laquelle on désire agir.
Lorsque l’on a abouti à une configuration intéressante, on peut à tout moment sauvegarder les valeurs de la posture actuelle en EEPROM avec Sauver la POSTURE ? la commande dédiée qui suit l’écriture en EEPROM la commande d’affichage d’un balayage panoramique télémétrique. (Voir éventuellement la Fig.259 B) Il sera ainsi rapide et facile d’imposer cette configuration avec la commande de la Fig.278 en étant bien conscient qu’une telle manipulation peut présenter un danger pour la mécanique. Par exemple vous avez enregistré la posture de décollage. Puis, quelques temps plus tard, la sonde étant posée au sol, vous croyez que la dernière sauvegarde concernait la posture Stable transversal. Passer d’une machine posée au sol à la rétractation vers le bas des Jambes ne sera absolument pas apprécié par la motorisation qui subira des efforts exagérés, sans compter les « chaussettes » qui vont copieusement frotter sur le sol. Donc à utiliser cet item avec prudence.
Affichage des consignes d’une posture.
Particulièrement utile pour effectuer des analyses diverses, on peut par deux items du menu EXPLOITER se faire
afficher à convenance les douze consignes de motorisation correspondant soit à la configuration actuelle, soit à la posture sauvegardée en EEPROM. La première s’obtient avec la commande de la Fig.279 X alors que la posture logée en EEPROM sera listée par l’item Y.
Quand on valide avec la touche OUI on obtient un écran comme celui représenté sur la Fig.280 et la LED jaune se met à clignoter annonçant 
qu’il sera important de quitter par usage de la touche FIN. La copie d’écran montre que les valeurs des consignes sont organisées sous forme d’une matrice dont les lignes sont concernées par les articulations et les colonnes sont représentatives des Jambes de l’insecte mécanique. Compte tenu de la répartition des
touches sur le clavier ergonomique, la Fig.281 situe la référence des divers boutons poussoir. En rouge le dessin est complété pour chaque touche par la valeur du code consigne qui permet au logiciel de la Raquette de dialoguer avec celui de la sonde. Analysons la chaîne logicielle qui anime les moteurs dans le mode manuel d’exploration sur le sol poussiéreux.
La première instruction que reçoit la sonde est codée 73 et le switch case qui trie les ordres reçus se contente de forcer la variable Debattement à 12 pour générer par défaut des amplitudes de mouvements importantes. Cette ligne d’instructions initialise l’identificateur Cible_Codeur_incremental à la valeur 5. Ce sélecteur chiffre signifie que le codeur incrémental concerne la motorisation en mode manuel. Par défaut la raquette transmet aussi les consignes 75 et 79 pour forcer par défaut la Jambe A et le servomoteur de la Hanche pour cible. Quand sur la raquette on clique sur l’une des touches coloriées en rose ou en bleu sur la Fig.281 la voie montante transmet l’instruction associée telle que 80 ou 77 notée en rouge à proximité de chaque bouton poussoir sur le dessin. Le logiciel de la sonde change alors de servomoteur cible. Quand on clique sur le bouton central du codeur rotatif, la variable Debattement alterne entre 12 et 2 changeant les balayages angulaires entre « grands » et « petits » :
Les mouvements sont déclenchés par la rotation du codeur incrémental qui, en fonction du sens de rotation, fait envoyer à la sonde le code 40 ou le code 41 :
L’observation des listage partiels de ces procédures montre qu’en fin de compte une seule subroutine Ajuste_la_position_du_servomoteur(sens) réalise l’intégralité des « mouvements manuels ». Pour en saisir le fonctionnement, la Fig.282 présente le comportement des servomoteurs des Hanches en fonction du signe de la consigne qu’ils doivent recevoir, alors que la Fig.283 résume l’action des moteurs qui animent les Griffe. Cette procédure optimisée se résume à peu de chose :
La variable locale Augmente passée en paramètre sous la forme d’un booléen à la procédure en (1) précise si la valeur de Consigne doit augmenter ou diminuer. En (2) on déclare en local Consigne pour ne pas interférer sur les variables globales. L’instruction (3) récupère la valeur actuelle de configuration du servomoteur cible. En fonction du sens de rotation désiré, les lignes (4) et (5) ajustent la valeur de Consigne pour la nouvelle position angulaire à adopter. Enfin, en (6), si les moteurs ne sont pas sur OFF, la procédure Mouvoir transmet la Consigne au multiplexeur et met à jour le tableau Configuration_actuelle[Num_Sortie].
Notez au passage que ce sont les ordres compris entre 75 et 81 qui initialisent la variable Num_Sortie. La valeur affectée à Num_Sortie est obtenue par une « astuce de programmation » en vue d’optimiser le code. Comme on peut le constater sur le listage de la Fig.284 chaque code reçu pour changer de cible modifie le contenu des 
deux variables dédiées Jambe et Articulation. Pour en déduire la valeur du moteur concerné et de Num_Sortie associé du multiplexeur, le calcu dans la subroutine Calcule_num_sortie devient élémentaire. Cette technique est infiniment plus économe en taille de programme que si le traitement s’était orienté de manière « banale » vers un switch case ou une batterie de test de type if. Le petit tableau de la Fig.285 résume ces traitements.
Simulation de tirs au LASER.
Expérience scientifique qui a été mise au point par nos chercheurs et nos techniciens toulousains, cette technologie (Cocorico !) a été sélectionnée par les Américains pour se voir embarquer à bord du plus gros « rover » posé sur Mars : L’explorateur Curiosity, une machine absolument hors du commun. Le fondement de cette manipulation consistait à bombarder un rocher avec un laser très puissant pour faire fondre le matériau. L’analyse spectrale de la couleur des gaz qui en résulte permet aux savants d’en déduire une foule d’informations relatives à la planète rouge. La petite simulation présentée ici consiste à réaliser une rafale d’éclairs de quelques secondes à la puissance maximale quelle que soit l’état actuel du LASER. Seule limite à cette action : Le système électrique de bord ne peut en aucun cas passer outre le disjoncteur s’il est déclenché. Dans ce cas il n’y aura aucun effet mis à part l’accusé de réception OK qui termine l’action issue de l’instruction ayant pour code 9.
Pas besoin de se torturer les méninges pour comprendre que c’est l’item de la Fig.286 qui permet de déclencher un tir LASER.
ATTENTION : Le « rayon de la mort » sera émis inconditionnellement et sans aucune vérification, y compris si le LASER est actuellement éteint ou à un niveau énergétique minimal de 1. N’activez cette fonction avec la touche OUI que si la direction du canon à photons est dirigée loin du regard de toute personne présente dans le local.
Sur la sonde, la procédure invoquée pour réaliser cette action est du genre presque dérisoire :
En (1) on organise une boucle qui va faire 35 fois la séquence (2) : Allumer le LASER à 254 le maximum, durant 25 millisecondes. Puis l’éteindre durant 50 millisecondes. Concrètement on ne l’éteint pas complètement, car le code généré est plus compact si on se contente de ramener la valeur à 1. Cette méthode est induite par le fait que la sortie binaire nommé LASER fonctionne en P.W.M. Tout compris, elle n’augmente la taille du programme de la sonde que de 40 octets.
Avec cette description nous en avons terminé la liste des apports qui étaient le fait de la version H des deux programmes. Nous allons pouvoir passer en revue les compléments qui émanent de la version J actuellement dans les méandres binaires des deux microcontrôleurs.
La suite est ici.
