Jekert se déplace comme une grande. Une bonne partie du cahier des charges fonctionnel est satisfaite. Mais le planning est impitoyable. Le temps s’évapore à une allure inquiétante. Il faut en terminer avec tout ce qui concerne la gestuelle de la petite sonde. Les ingénieurs système qui vont devoir se charger de l’intégration commencent à piétiner d’impatience. On a donc réuni tous les personnels pour ventiler les responsabilités et avancer le projet sur plusieurs plans simultanément. La matière grise va être soumise à rude épreuve. Tout le monde se mobilise avec ténacité.
Avec P13_Toutes_les_postures.ino le démonstrateur des nouvelles fonctions dont sera dotée le petit animal mécanique, on change radicalement de perspective. Sans bouleverser fondamentalement la stratégie actuelle, on adopte dans la structure du programme une philosophie et une organisation probablement définitive, tout au moins dans les grandes lignes. L’exploitation sera conduite soit par des commandes à un caractère, soit des programmes de type « pNN* ». Il y aura plus de possibilités, plus de commandes, mais l’analyseur syntaxique ne va plus vraiment changer et la structure du logiciel conserver une architecture stable. C’est bon pour le moral, on a un peu l’impression bien agréable de tenir du « solide ». La Fiche n°12 anticipe largement sur l’avenir de l’ambitieux projet et précise la totalité des commandes et des programmes qui seront embarqués par JEKERT lors de son lancement vers Mars. En particulier les programmes qui sont mis en évidence par un arrière plan en couleur jaune sont ceux qui utilisent le caractère de répétition pour des mouvements de base. Nous commencerons ce dossier par les mouvements de base complémentaires qui viennent enrichir les fondamentaux actuels, mais avant parlons un peu architecture :
Implantation de la mémoire EEPROM.
Bien que l’écriture du didacticiel semble nous placer aux premiers balbutiements du développement du programme, en réalité je dois vous avouer que pour ne pas risquer trop de remises en cause, et surtout de nous engager fortement sur de longues études qui s’avéreraient vaines et illusoires, j’ai avancé le développement logiciel pratiquement jusqu’à la version définitive. Ainsi non seulement la faisabilité des possibilités espérées a été vérifiée, mais également mon aptitude à les émuler en langage C++. Pour l’heure, l’utilisation des 1024 octets de la mémoire non volatile EEPROM est totalement définie, y compris les données à y loger pour faire fonctionner les démonstrateurs qui vont suivre. Aussi, il me semble incontournable d’expliciter le contenu de cette ressource de l’ATmega328, et ce d’autant plus qu’une nouvelle commande « z* » va nous permettre d’aller « voir réellement » ce qui est préservé dans ce logement binaire. Dans ce but, je vous conseille fortement d’imprimer les Fiche n°13 et Fiche n°14. Pour économiser au maximum le gaspillage de papier, le verso de la Fiche n°14 présente le dessin de certains circuits imprimés, alors que ce thème ne sera concrètement abordé qu’au TOME 4. Les deux procédures indiquées en bas de la Fiche n°14 sont un peu équivalentes aux instructions Serial.print() et Serial.println() du langage C++ d’Arduino sauf qu’au lieu de leur passer une chaîne de caractère à afficher comme paramètre, on indique l’adresse relative en EEPROM du texte avec le pointeur PTR et la longueur du texte avec le byte LGR. Par exemple l’instruction Aff_TEXTE_EEPROM(667,3); aura pour effet de faire afficher » > « . Pour augmenter la lisibilité des textes proposés dans les listages de la fiche de travail, les espaces sont remplacés par des « soulignés « _ ».
Puisque nous en sommes à explorer l’intimité binaire de l’ATmega328, je vous propose une petite visite guidée dans les méandres de la « puce électronique ». Cette expérience ne sera possible que si vous avez au préalable téléversé et activé les deux programmes indispensables P28_Ecrire_les_textes_en_EEPROM.ino et P29_Definitif_Ecriture_des_tableaux_en_EEPROM.ino AVANT de charger le démonstrateur P13_Toutes_les_postures.ino. Par curiosité proposez la commande « b* ». Nous savons qu’elle a pour effet de bloquer la luminosité des phares. Ceci dit, en cachette elle sert également de booléen pour l’affichage du contenu de l’EEPROM. Si ce booléen est égal à true, le contenu des Octets sera exprimé en binaire sous forme Hexadécimale. C’est une façon de traduire les « 0 » et les « 1 » constituant un octet bien connue des programmeurs qui développaient directement en binaire ou en langage assembleur. En particulier, si l’EEPROM était vierge avant d’avoir fait fonctionner P28 et P29, les $FF signifient que les huit Bits de l’octet sont à « 1 ». Cette façon de « lire le journal » est très pratique pour repérer les octets occupés, voir si une donnée a été inscrite au bon endroit etc. Pouvoir « regarder » directement les octets est absolument indispensable lorsque l’on tente d’écrire des procédures délicates, et en particulier celles qui vont permettre de loger ou de récupérer des données en EEPROM. En revanche, l’Hexadécimal n’est absolument pas convivial pour repérer des textes. Donc, si avant de faire lister la mémoire non volatile par la commande « z* » vous inversez le mode de présentation par la commande « b* » chaque octet sera considéré par le programme comme un caractère textuel codé en ASCII. Comme ce standard presque aussi ancien que les ordinateurs définit une foule de codes spéciaux, pour ne pas détruire la présentation à l’écran tout caractère différent d’une lettre, d’un chiffre ou d’une ponctuation sera représenté par le symbole « .. ». Avant de reprendre les études de la gestuelle de JEKERT amusez-vous. Visualisez la mémoire EEPROM dans son état actuel. Quand on abordera certaines fonctions nouvelles, nous irons voir ce qui a changé dans les octets. Et observer après plusieurs jours de non activité que tout ce qui était préservé dans le petit cerveau de JEKERT s’y trouve toujours est qu’on le veille ou non assez magique … tout au moins c’est mon sentiment.
Dominer son sujet.
Prendre de la hauteur peut s’avérer avantageux en exploitation martienne. Supposons qu’un rocher masque en partie la caméra hypothétique qui retourne des images de l’environnement aux ingénieurs de maîtrise. Est-il plus avantageux de décaler à gauche ou à droite ? Un ravin situé en face barre t’il le chemin ? Auquel cas il faut changer de route. Les exemples sont nombreux où pouvoir observer de plus haut font partie des spécificités du « cahier des charges fonctionnel ».
Nous pouvons vérifier sur la Fig.89 que passer de la posture Stable Transversal à Hauteur maximale ne génère pas un gain en altitude très important. Comme la séquence ne coûte pas grand chose en octets, il serait bien dommage de ne pas ajouter « p10* » et « p11* » à la liste des facultés opérationnelles de la sonde d’exploration. La technique utilisée pour ménager la mécanique est strictement analogue à celle qui fait passer du mode VEILLE à Stable Transversal et réciproquement.
Pas grand chose à souligner pour ces deux procédures pratiquement évidentes. Le paramètre 288 correspond à l’adresse en EEPROM du tableau de la posture Avant hauteur maximale. C’est le mouvement progressif vers 144 qui fait passer en configuration Hauteur maximale après un petit délai de 0,3S. Quand à REVEILLER(), pour mémoire c’est le retour à la posture Stable Transversal suivi de la libération des efforts parasites. Avouez que pour économiser quelques octets consommés de plus il aurait été bien dommage de ne pas ajouter ces deux fonctions motrices à JEKERT.
Protocoles et préalables.
Naturellement vous allez vous précipiter sur le clavier du P.C. pour expérimenter tout de suite ces deux nouvelles possibilités de mouvement. Lors de vos manipulations, l’obstination et le caractère pointilleux de Madame l’exploratrice risque fort de vous opposer de multiples
« !ERR 21! » un tantinet agassifs. Il se trouve que toute activité humaine peut engendrer des risques, voir des drames, si des conditions préalables ne sont pas satisfaites. Par exemple sauter du plus haut plongeoir de la piscine … sans avoir vérifié au préalable s’il y avait de l’eau ! Aussi, chaque fois que c’est possible, les techniciens prévoient des sécurités quand les conséquences d’un oubli peuvent avoir des effets dévastateurs. Par exemple tenter de poser un avion de ligne alors que le train d’atterrissage n’est pas sorti déclenchera immédiatement une alerte sonore dans le cockpit.
Perdre une sonde spatiale suite à une manipulation malheureuse peut ruiner des années d’investissements et d’études, sur le plan scientifique. C’est dramatique. Aussi, des sécurités automatiques viennent systématiquement protéger les machines envoyées dans le système solaire. Il est évident que JEKERT doit bénéficier de telles protections. Par exemple déclencher deux fois de suite « p12* » amènerait les Jambes D et A en collision, incident inacceptable dans la mesure où un peu de logiciel peut parer ce type de problème. (Nous verrons plus tard l’utilité de ce programme d’exploitation particulier.) Comme plusieurs sortes de protection sont envisagés, un chapitre particulier leur sera dédié. Pour l’heure, contentez-vous de savoir que des « garde-fous » sont et seront ajoutés dans le logiciel et engendreront des messages d’erreur éventuels. « !ERR 21! » signale que la posture actuelle avant
un mouvement n’est pas la bonne. La liste des programmes donnée sur la Fiche n°12 précise en bas
de page en bleu le programme préalable à celui indiqué en rouge.
Neutre opérationnel sur tous les moteurs.
Puisque les procédures de base sont entièrement rédigées, adopter une nouvelle posture se résume à peu de chose. Quelques appels à subroutines, et la sonde adopte une nouvelle configuration. Aussi, dans ce contexte « économique » en octets de code objet, toute facilité d’exploitation se justifie amplement. Par exemple, le programme « p15* » se contente de faire passer tous les moteurs au neutre opérationnel. Il n’augmente pas significativement les aptitudes martienne de la sonde. En revanche, durant des manipulations expérimentales de recherche de configurations particulières, commencer par placer toutes les articulations « à zéro » constitue une possibilité tout à fait utile. Le coût en taille de programme est dérisoire puisque la nouvelle fonction ne fait qu’ajouter un appel à procédure dans l’instruction d’aiguillage :
Du reste pour savoir « combien ça coûte », il suffit de transformer cette ligne de programme en remarque. Le code source diminue de six octets. Avouez que six octets pour une posture de plus dans les facultés motrices de JEKERT représente une sacré promotion commerciale.
L’expérimentation d’innombrables essais fait ressortir un besoin opérationnel très utile. Celui de pouvoir déclencher un mouvement de base en ayant le minimum de caractères à frapper au clavier de l’ordinateur. Dans ce but, P13 propose une nouvelle commande à « zéro caractère ». On se contente de n’envoyer que la sentinelle « * » et le dernier mouvement imposé à la machine est réitéré sans avoir à le désigner. (À condition toutefois que son préalable l’autorise.) Attention, un ordre ne comportant que la sentinelle concernera LE DERNIER DÉPLACEMENT DE BASE envoyé à la machine. Par exemple si on propose « i* » suivi de « * » on n’aura pas un nouveau listage de l’état de la sonde, mais le déclenchement de « p14« si c’était le dernier mouvement demandé. À tout moment l’ordre « i* » précise en fin de listage le dernier mouvement effectué, celui qui serait réitéré avec « * ».
Posture stable raisonnable … le retour.
C’est la saison des soldes, il faut en profiter. La posture Stable Raisonnable décrite en Fig.88 avait été abandonnée pour des raisons stratégiques. Il lui avait été substituée la configuration Stable transversal plus apte à résoudre les problèmes dynamique lors des mouvements de base. Toutefois, vu le faible prix de vente des postures en cette période promotionnelle, il devient tout à fait pertinent de la réhabiliter. Depuis la posture de base Stable transversal écarter les Jambes pour octroyer plus de stabilité à l’exploratrice constituera dans l’arsenal de JEKERT une facilité opérationnelle de plus. Par exemple améliorer la stabilité du châssis lors d’une expérience particulière, lorsque la machine se trouve sur un terrain à pente élevée.
Consulter P29 montre que la configuration 0 correspond à Stable Raisonnable que l’on obtient par un mouvement coordonné. Les Jambes n’étant pas soulevées, les « chaussettes » frottent sur le sol. Donc, après avoir positionné avec précision les orientations des moteurs on libère les efforts. Il aurait été possible de revenir à Stable transversal ce que l’on fait avec Coordonne(120), mais il a été estimé plus sécuritaire de terminer la séquence par un retour au mode VEILLE qui de surcroît libère les efforts puisque les Griffes sont alors en l’air et ne touchent plus le sol.
Les configurations de lancement et de déploiement de la sonde.
Logiquement, trois configurations sont incontournables pour déposer un explorateur robotisé sur une planète ou un satellite. Bien que pour « s’amuser » avec le petit robot ces trois configurations ne seront pas très utiles, pour la crédibilité du projet et surtout pour le plaisir d’effectuer une étude complète, P21 à P23 vont encombrer la mémoire de programme de leurs octets. Chronologiquement c’est « p23* » qui sera invoqué en premier. Abordé sur la Fig.80 c’est l’ancien programme P02 à peine modifié. Potentiellement, il ne faut déclencher cette mise en configuration QUE si la sonde est placée sur le berceau du lanceur. Aussi, dans le cadre des vérifications sécuritaires automatique, un capteur a été ajouté au matériel. Ce dernier n’est pas installé de façon banale, et il importe d’ouvrir une parenthèse pour en décrire l’agencement.
Capteur de « contact du bouclier avec le sol ».
Plusieurs circonstances en exploitation imposeront de vérifier que la sonde est bien au repos, son bouclier posé sur le sol martien. Il sera à tout moment possible aux ingénieurs de maîtrise de tester l’état de JEKERT par la commande « i* ». Surtout, des vérifications automatiques seront intégrées dans les programmes si cette attitude constitue un préalable à une action potentiellement risquée. Considérons la Fig.114 sur laquelle on retrouve la masse virtuelle @ coupée par le transistor disjoncteur. Pour élaborer le schéma électrique, la première contrainte résulte de la LED bleue qui indique visuellement que le bouclier est en contact avec le sol. Elle doit s’illuminer lorsque le micro contact passe à l’état travail. Cette LEL s’allume lorsque le +5Vcc alimente R1, c’est à dire que l’inverseur étant au travail T n’intervient plus. Si le mode Sommeil n’est pas validé, la ligne @ est au potentiel de GND. La LED est alors traversée par un courant limité par R1 et R2 qui sont placées en série. Comme logiquement la sonde passera un maximum de temps sur ses Jambes, l’inverseur restera globalement au repos. Un courant permanent sera « gaspillé » à travers R1, raison pour laquelle on cherche à donner à cette dernière la plus grande valeur possible. Avec 22kΩ le courant permanent sera de 250µA. Si l’on désire une luminosité confortable pour la LED, il faut qu’elle soit traversée par un courant suffisant. Aussi il est souhaitable de donner à R2 la valeur la plus faible possible. Hors D3 est une entrée binaire qui réagit à des niveaux TTL. Pour que la tension présente soit considérée comme un état logique « 1 » il faut que la tension soit supérieure à +2,5V. En adoptant une valeur de 10kΩ pour R2 cette tension monte à +3,2V ce qui ménage une marge de sécurité fiable. En revanche, avec 32kΩ en série, le courant qui traverse la LED n’est que de 90µA. Cette solution est tout à fait acceptable car les diodes électroluminescentes actuelles présentent des rendements lumineux étonnants. À l’époque où il fallait au minimum 20mA pour allumer ce type de composant, cette solution n’aurait pas été possible. Vive les progrès techniques.
Le tableau de la Fig.114 établit un lien entre la logique et les aspects électriques. Il est amusant de noter au passage que nous nous trouvons en présence d’un cas rares pour lequel la consommation électrique est plus importante quand une lampe est éteinte que lorsqu’elle est allumée. Cet oxymore toutefois nous évite d’avoir à utiliser un micro contact à deux sections.
La première opération que fait la procédure Configure_pour_Decollage() consiste à vérifier en (1) si le bouclier est bien « en contact avec le sol », c’est à dire avec le berceau hypothétique d’une fusée Ariane. Si ce n’est pas le cas, recroqueviller les Jambes vers le dessous serait préjudiciable pour la mécanique. Si la vérification échoue, la sonde va rester en l’état et activer en (6) la procédure Erreur_N_BIP(Num Erreur) qui génère un BIP sonore et retourne en accusé de réception un message d’alerte de type « !ERR NN! ». Le numéro de l’erreur est passé en paramètre à cette procédure qui sera invoquée chaque fois que le logiciel détecte une anomalie.
Si le bouclier est posé, alors en (2) un BIP sonore attire l’attention de l’opérateur et sur l’écran du P.C. s’affiche la requête : « Sonde sur berceau ? ». Puis en (3) le programme attend une chaîne de caractères terminée par la sentinelle ‘*’. L’instruction (4) vérifie si la réponse affirmative attendue « o* » est effective. Si c’est la cas un mouvement progressif Coordonne(72) procède à l’adoption de la posture de décollage. Dans le cas contraire un BIP d’erreur est généré pour accuser réception d’une saisie incorrecte, éventuellement volontaire pour ne pas poursuivre, ou non.
Complémentaire au décollage, il y a aussi l’arrivée qui se fait en deux phases. Déjà détaillées ces deux étapes sont représentées sur la Fig.83 pour l’atterrissage obtenue par la commande « p22* » suivie du programme « p21* » qui permet de déployer la sonde. À l’instar du programme « p15* », adopter la posture pour poser est une copie conforme et ne coûte également que six octets :
Déployer la sonde est légèrement plus subtil car il faut vérifier si le bouclier est bien en contact avec le sol. Si ce n’est pas le cas c’est que la sonde a effectué un mauvais atterrissage et se trouve peut être dans une situation critique. Il faut alors que les ingénieurs puissent analyser le contexte et ne pas aggraver les circonstances. La structure de la procédure reste cependant triviale :
En (1) le logiciel vérifie que le contact avec le sol est effectif. Si ce n’est pas le cas, le message d’alerte « !ERR 12! » est envoyé en compte rendu, et dans la salle de contrôle c’est la consternation. La mission commence bien mal. Si le capteur a mordu la poussière, l’instruction (2) commence par placer tous les moteurs au neutre opérationnel. Un délai en (3) d’une seconde laisse le temps aux servomoteurs d’adopter les positions de consigne. Cette posture intermédiaire est favorable au passage en douceur à la configuration VEILLE en (4). Un autre délai d’une seconde est octroyé à la motorisation. On peut alors en (5) « monter » en posture Stable transversal et libérer les efforts :
Dans la salle de contrôle c’est la joie. JEKERT va commencer sa vie d’exploratrice. Le plus délicat a été franchi avec succès, maintenant les scientifiques vont pouvoir commencer leur moisson d’informations pour mieux comprendre l’histoire et le vécu de la planète rouge …
La suite est ici.
