Satisfaction généralisée pour les personnels du complexe toulousain. Avoir assisté en direct derrière la baie vitrée de la salle blanche S6 aux premiers pas de JEKERT a été pour eux un moment inoubliable. Chaque personne a été conviée, et tous éprouvent de la fierté à avoir participé au projet. Il faut maintenant reprendre le travail car le planning est impitoyable et ne laisse que peu de temps pour les réjouissances. Se mettre en VEILLE ou se relever, avancer, reculer constituent des programmes fondamentaux mais totalement insuffisants pour autoriser une exploitation sur site digne de ce nom. Si face à la sonde se trouve un gros rocher, il sera impératif de le contourner sans compter que les expériences scientifiques vont exiger parfois des orientations bien spécifiques. Enrichir la gestuelle de l’insecte martien constitue l’objectif des journées qui vont suivre.
Et pourtant elle tourne !
Encore une citation célèbre qui traverse les siècles, dans ce didacticiel elle n’est pas murmurée comme durant le procès de l’infortuné Galilée. Au même titre qu’un véhicule automobile ne peut pas tourner sur place, il faut obligatoirement qu’il avance ou qu’il recule, la giration sans déplacement n’a rien de naturel pour un animal. (Pas plus que pour un humain du reste.) Quand on se déplace et que le chemin à suivre présente une courbe, ce sont les pas effectués qui vont nous orienter progressivement. Si stable on désire observer un événement latéral, il est rare de « piétiner » pour réorienter son corps. En général on tourne la tête sauf si l’angle de torsion est important et dépasse les amplitudes confortables pour notre cou. Et bien pour le robot d’exploration, nous allons adopter un type de comportement assez inhabituel, c’est à dire que les orientations pour changer de direction vont se faire sur place sans avancer ni reculer. (On va générer du pivotement.)
Vous allez rapidement vous rendre compte si vous cherchez à développer vos propres déplacements que les essais à conduire sont très nombreux, les consignes à fournir innombrables. Aussi, pour rendre plus aisé le travail du programmeur, le démonstrateur P12_Tous_les_mouvements.ino inaugure une nouvelle fonctionnalité : Un « message vide » ne contenant que le caractère sentinelle ‘*‘ fait réitérer le dernier programme de mouvement de base envoyé comme instruction à la sonde sur la voie montante. Cette facilité s’avère particulièrement commode quand on désire voir se dandiner JEKERT plusieurs fois de suite par un mouvement de base répété. L’observation coup sur coup facilite également l’analyse de ce qui se produit et ainsi induit plus rapidement des interventions correctives dans le logiciel. Outre la répétition possible du dernier déplacement, ce programme s’oriente résolument vers du « définitif. À ce titre il introduit les commandes à un seul caractère du type « a* », « b* », « c* » etc, dont nous allons découvrir les effets plus avant. On ajoute également des LED pour avoir un « contrôle visuel » du comportement du programme. Comme le logiciel est très bavard, on loge les textes en EEPROM. La répartition des Entrées/Sorties sera « définitive » à partir de cette version des démonstrateurs. Enfin, on ajoute à la commodité des commandes de mouvement la notion de caractère de répétition. Revenons au pivotement :
La Fig.101 explicite la technique qui sera utilisée, la rotation souhaitée pour cet exemple se fait vers la gauche. La première étape consiste à faire avancer la paire de Jambes gauche, et à faire reculer la paire droite en partant de la posture Stable Transversal. Les contacts des Griffes avec le sol se font en a, en b, en c et en d. Puis, la machine étant bien « ancrée » sur ses « chaussettes », simultanément on fait tourner Ra, Rb, Rc et Rd dans des mouvements coordonnés, les Hanches balayant des angles α.
La posture finale ressemble à celle de la Fig.102 sur laquelle les contacts initiaux au sol a, b, c et d ont été représentés sans changement. Lorsque la sonde reçoit la consigne de reprendre en mouvements coordonnés la configuration Stable Transversal elle ignore somptueusement ce qui se passe dans son environnement. Le programme ne fait que réorienter les quatre Hanches par rapport au châssis pour aligner les Griffes sur les droites transversales des axes de la motorisation. La forme géométrique vue de dessus redevient celle montrée sur la Fig.98 sauf que les « chaussettes » étant en contact avec le sol, il se produit une giration du châssis. Il se trouve que le quadrilatère des quatre points a, b, c et d n’est pas identique au rectangle de sustentation de la configuration Stable Transversal mis en évidence en rouge sur le dessin. Il se produit des frottements induits notables au sol, avec des glissements.
La Fig.102 représente la nouvelle posture en ayant « réparti » assez régulièrement les dérapages, ce qui du reste ressemble assez à la vérité. Nous savons que ces glissements engendrent des efforts parasites dans les éléments mécaniques, la procédure de rotation se termine donc par la libération de ces efforts. Les frottements au sol lors de cette rotation sont relativement importants. De ce fait plusieurs consignes successives n’engendreront pas un écart angulaire d’orientation identique. Il sera impossible par cette stratégie de pouvoir faire adopter au châssis une direction précise dans l’espace. Rassurez-vous, un programme de correction de pointage précis sera mis au point pour palier cette difficulté. La technique utilisée est assez délicate à décrire, mais ses programmes sont élémentaires.
À l’observation du listage des deux procédures de pivotement il est manifeste que l’architecture est strictement identique à celles pour avancer et reculer. Seule la combinatoire des appels et la fourniture des booléens est différente. On récupère ici le bénéfice d’avoir construit des routines paramétrables à « tout faire ». Ces deux fonctions en termes de consommations d’octets sont négligeables.
L’arbre de Noël.
Le démonstrateur P12_Tous_les_mouvements.ino est copieusement documenté. Une fois l’avoir téléversé sur Arduino NANO, en tête de listage vous trouverez les détails de branchement des broches d’Entrées / Sorties de l’ATmega328. Vous avez aussi, (Et surtout !) la liste des commandes supportées par ce logiciel expérimental. Pour le moment ignorez la présence du LASER nous y reviendrons. Les phares seront concrétisés par deux LEDs de couleur blanche orientées vers l’avant sur la machine quand cette dernière sera entièrement assemblée. Bien que sur Mars il n’y aura personne pour les contempler, une multitude de LEDs de couleur sont ajoutées pour informer l’opérateur de l’état de la sonde. Ces témoins visuels sont précieux quand on procède à une campagne d’essais. Pour l’heure, vous allez vous contenter de brancher les éléments sur une plaque à essais comme indiqué dans les remarques du programme. Chaque LED indiquée sera reliée entre la sortie d’Arduino et provisoirement sur GND avec en série une résistance de 470Ω à 1kΩ. La valeur n’est pas du tout à ce stade du développement. Une résistance de 220Ω à 470Ω est mise en série avec le BUZZER pour éviter de sursauter à chaque alerte sonore.
Vous pouvez observer à lecture du démonstrateur le commentaire : A3 : Clignotement de la LED de « boucle de PGM active ». Cette information induit deux commentaires. Le premier est relatif à l’utilisation des ressources de l’ATmega328. Dans cette application nous avons besoin de relativement peu d’ENTRÉES, et de beaucoup de SORTIES. Pouvoir utiliser des entrés analogiques en sorties binaires est une caractéristique très séduisante de ce microcontrôleur et du langage C++ associé.
Durant la mise au point d’un programme, il arrive fréquemment que le démonstrateur devienne inerte en apparence. Problème de la boucle de base void loop ou blocage du processeur dans une autre séquence du programme ? Pour aider au diagnostic, chaque fois que l’application en cours de développement laisse une sortie de disponible, quelques lignes de code ajoutées à la boucle principale génèrent par interruption le clignotement d’une LED à cadence rapide. Ainsi, un simple regard permet d’observer les battements de ce cœur visuel et nous assure : « et pourtant elle tourne ».
Prendre le temps …
Particularité étonnante des automatismes : Quand on déclenche une séquence robotisée, tout se déroule très rapidement. Nous savons exactement ce qui va s’enchaîner, et pourtant, la motorisation est tellement rapide, qu’après plusieurs répétitions d’une séquence nous n’avons pas vraiment eu le temps de voir réellement ce qui s’est passé. Aussi, pour permettre au programmeur ou à l’observateur de mieux comprendre la gestuelle de JEKERT, la commande à un caractère « r* » se comporte comme une bascule de type OUI/NON. En mode mouvements lents, quand une séquence coordonnée est déclenchée, un petit délai entre chaque étape intermédiaire est généré. Nous avons alors le loisir de regarder « un film au ralenti ».
Puisque nous avons ouvert une parenthèse sur les commandes à un caractère, dès ce démonstrateur on peut envoyer à la sonde l’instruction « i* » qui retourne en ACR une foule d’informations sur l’état actuel de la machine scientifique. En particulier l’état des mouvements Mvt lents ou rapides. OUI, je sais que vous frétillez à l’envie de faire bouger le petit insecte et voir comment il apprend à marcher. Vous avez fébrilement téléversé P12_Tous_les_mouvements.ino, branché en urgence les divers éléments électriques et Pafffff … sur l’écran de l’ordinateur ça affiche n’importe quoi ! C’est normal bande de Dudules, c’est précisé au début de ce chapitre :
IL FAUT IMPÉRATIVEMENT AU PRÉALABLE INSCRIRE LES TEXTES EN EEPROM avec le programme dédié P29_Ecriture_des_tableaux_en_EEPROM.ino. N’oubliez pas de le faire chaque fois que vous allez soumettre les démonstrateurs à une éventuelle autre carte Arduino NANO.
Toujours dans le cadre des commandes à un caractère testez également « f* » qui fige ou réactive la motorisation. Quand les moteurs sont inertes, la LED rouge branchée sur D7 s’illumine. Cette option est bien commode pour tester le programme, analyser les ACcusés de Réception, manipuler à outrance sans incident pour la motorisation. D’une part de nombreux essais n’imposent pas de faire bouger la machine, autant ménager « les potentiels moteurs ». D’autres parts nous sommes en contexte de développement. De nombreux fils électriques viennent encombrer l’environnement immédiat de l’insecte qui régulièrement se prend les pattes dans le « filet ». Alors pensez à « f* » qui « calme le jeu ».
Un peu de repos de temps en temps.
L’évolution du projet va enrichir JEKERT d’un nombre significatif d’options, chacune exigeant du contrôle tant sur les ordinateurs de pilotage que visuellement. Sur la version la plus aboutie, ce n’est pas moins de douze LEDs de contrôle qui équiperont l’explorateur robotisé. Aussi, pour simuler le mode SOMMEIL, la commande « s* » permet à tout moment de suspendre tous les électriques « inutilement consommateurs d’énergie ». Toutes les LEDs sont alors éteintes y compris les deux des phares ainsi que le LASER. Ce mode sera activé par exemple lorsqu’une tempête s’annonce, rendant les expériences scientifiques inutilisables. Durant l’intempérie il devient logique de couper sur le robot toute consommation parasite. La commande « s* » ne fait que couper l’énergie. Un deuxième appel à cette commande restaure l’état initial, ce qui était allumé s’éclaire à nouveau. Pour exploiter cette nouvelle commande, il faut brancher le disjoncteur électronique, c’est à dire ajouter sur le petit bloc de contacts électriques un transistor et sa résistance de base. Examinons le fonctionnement de ce petit dispositif très simple et fonctionnant du premier coup.
La Fig.103 présente le branchement ultra classique d’une LED pilotée par la sortie binaire d’un microcontrôleur. Une résistance de limitation de courant Rlc est insérée en série. On peut la placer librement avant ou après la LED. (Et ainsi faciliter la conception du circuit imprimé.) La valeur de Rlc n’est pas critique et n’influence que la luminosité de la LED. Dans un premier temps prendre n’importe quelle valeur située entre 470Ω à 1kΩ. Pour réaliser le circuit imprimé définitif, se munir d’une variété de résistances, et tester pour chaque LED la valeur qui aboutit à la luminosité que vous souhaitez. Sur le schéma du circuit électronique que je proposerai lors de l’intégration des systèmes seront précisées les valeurs adoptées sur le prototype. Certaines seront à respecter, mais ceux des LEDs devront être adaptées à vos désirs en fonction des modèles que vous aurez approvisionné.
Fonctionnement du disjoncteur :
Les différents consommateurs électriques ne sont plus directement reliés à GND mais connectés à la masse virtuelle désignée par @. Le « Strap » S coupe éventuellement la ligne @ pour pouvoir effectuer des vérifications électroniques. Si vous pontez avec un fil la ligne @ à GND l’ensemble lumineux est fonctionnel. Au contraire, si vous enlevez la languette de contact S tout sera éteint quel que soit l’état de déroulement du logiciel. Établir ou couper la liaison électrique entre @ et GND est précisément le rôle du disjoncteur électronique piloté informatiquement par la sortie binaire D4. Le transistor T est de type NPN et très banal. Tout modèle pour petite puissance tel que les 2N2222 ou 2N1711 conviendront. Quand D4 est à l’état logique « 0 » aucun courant n’est envoyé dans la base b de T qui se trouve alors à l’état bloqué. Aucun courant ne peut circuler entre son collecteur C et son émetteur E. Lorsque D4 bascule à l’état logique « 1 » la sortie « monte » à environ +5v. La résistance Rb de 1kΩ injecte alors un courant de presque 1mA dans la base de T qui passe alors à l’état saturé. Il se comporte dans ce cas comme un court-circuit entre collecteur C et émetteur E. La ligne @ se trouve immédiatement au même potentiel que celui de GND et les électriques sont alimentés au nominal.
Au point de vue logique informatique, il serait envisageable de brancher directement D4 sur @ et d’éliminer le transistor T et sa résistance de base Rb. Le problème vient de la « sortance » des broches de l’ATmega328 qui ne peuvent fournir que 40mA avec un total cumulé sur toutes les sorties de 200mA. J’avoue que le total des consommateurs embarqués reste en dessous de ces limites, une telle solution est donc parfaitement envisageable. Toutefois, et c’est la grande différence entre « fabriquer pour sois » et « décrire pour les autres ». Vous allez approvisionner des composants forcément différents. Rien ne prouve que vous n’allez pas installer un LASER plus puissant. Vos LED seront peut être de rendements plus faibles, il faudra y injecter plus de courant. Aussi, par mesure de sécurité et de fiabilité, vu le prix dérisoire d’un petit transistor, j’ai préféré opter pour la sécurité. Le transistor T largement dimensionné pour commuter de tels courants joue le rôle d’amplificateur.
Un pas chassé.
Décaler latéralement peut s’avérer avantageux en diverses circonstances durant l’exploration martienne. Par exemple quand un rocher situé devant empêche de passer. Décaler à droite ou à gauche évite de perdre la direction de l’orientation actuelle. On peut également se translater face à une paroi rocheuse qui serait devant la sonde. Pour minimiser les problèmes générés par les glissements et les frottements, la chorégraphie pour effectuer un pas à gauche ou à droite sans pivotement, comme on va le voir est assez particulière. En « standard », pour ces deux déplacements de base on « part » de la situation initiale Stable Transversal. La technique utilisée et décrite par la Fig.105 et s’avère assez particulière, car pour minimiser le code Objet l’animal mécanique brasse pas mal d’air, il joue un peu les sémaphores. De la posture Stable Transversal on commence par poser le bouclier en invoquant le mode VEILLE. Puis on adopte la Posture Atterrissage, les Griffes étant dégagées sur le dessus. Le but de ces deux mouvements élémentaires consiste à adopter une géométrie qui ensuite facilite l’acquisition de la configuration « Posture Avant décalage« . Cette configuration étant effective, on coordonne ensuite pour engendrer le déplacement latéral. Pour terminer on fait appel à la fonction void REVEILLER(); qui ici replace la sonde en posture Stable Transversal et libère les efforts.
À voir se dérouler la séquence on a l’impression d’une grande complexité. En réalité, si l’on compare à un déplacement Animal ou humain, on imagine assez bien que le mouvement biologique ou copié sur ce dernier ne peut avoir la simplicité des machines roulantes. Par contre, si la gesticulation semble exagérément « dynamique », elle ne fait appel qu’à quelques appels de procédure et très peu d’octets consommés en mémoire de programme. Pratiquement de la routine, décaler à bâbord ou a tribord sera réalisé par une seule procédure pour laquelle on indiquera par paramètre la « Posture Avant décalage« .
Pour vous convaincre de la discrétion du code source, vous avez ci-dessous le listage des diverses procédures de service impliquées dans les mouvements de translations latérales :
Pour les deux mouvements de base de décalage latéral on fait appel à une procédure unique. En (1) l’adresse 360 correspond à la posture initiale pour une translation vers la droite alors qu’en (2) le pointeur 384 correspond à une préparation pour décaler à gauche. En (3) la procédure reçoit en paramètre l’adresse EEPROM du tableau à utiliser. En (4) on prépare la géométrie, on temporise de 0,2S pour laisser aux moteurs le temps de « brasser de l’air ». Puis par un mouvement coordonné on réalise le décalage. L’instruction (5) relève l’animal mécanique. Dans l’instruction de la ligne (6) l’adresse 120 correspond au tableau des consignes pour aboutir à la posture Stable Transversal.
Les schémas donnés ci-dessous résument les valeurs des consignes correspondant sur le prototype aux configurations à adopter pour décaler à gauche ou à droite. Sur ces dessins la sonde est vue de derrière en regardant vers l’avant. En noir sont précisés les moteurs concernés, en violet les valeurs des consignes à leur envoyer. Les moteurs des Hanches 1, 4, 7 et 10 ne sont pas indiqués car leurs consignes correspondent à celles de la posture Stable Transversal.
S’orienter avec précision : Les mouvements de TORSION.
Pouvoir orienter l’axe longitudinal avec précision est indispensable en exploitation pour satisfaire les exigences de certaines expériences embarquées. Nous savons que la technologie globale n’est pas apte à satisfaire cet impératif avec les deux mouvements de base Tourner à droite et Tourner à gauche. Aussi, le cahier des charges fonctionnel prévoit la faculté pour JEKERT de changer finement de posture par mouvement de torsion en LACET, la configuration initiale étant en standard la géométrie du Stable Transversal. C’est la commande à un seul caractère « t* » qui active ce mode de pilotage en manuel avec le potentiomètre.
Le principe de la Torsion ressemble à celui de la rotation. Pour tourner, on changeait la position des Hanches, donc des contacts avec le sol. Puis on faisait tourner les moteurs dans un sens contraire à bâbord et à tribord. Pour effectuer une torsion, on procède par une technique réciproque. On ne modifie pas les contacts au sol, on se contente de faire tourner les Hanches dans des sens contraires de chaque coté. C’est en manœuvrant le potentiomètre que l’on provoque le « déhanchage ». Durant la boucle de base void loop(), un booléen nommé Torsion_Active précise si le mode est effectif. Si c’est le cas la valeur de la tension potentiométrique est mesurée puis transposée pour que la course totale du composant rotatif engendre une torsion d’environ ±13° de part et d’autre de l’axe longitudinal du châssis. L’orientation peut se voir ainsi finement ajustée. La séquence qui dans la boucle de base se charge de gérer la torsion ne comporte que quelques instructions. Elle effectue un traitement qui mérite d’être détaillé.
Théoriquement, quand on utilise une entrée analogique câblée comme sur la Fig.110 on devrait obtenir en U sur A1 une différence de potentiel avec GND qui varie entre 0 et +5Vcc, la tension d’alimentation théorique de l’ATmega328. Cette variation appliquée sur le Convertisseur Analogique/Numérique CAN devrait logiquement engendrer une plage de valeurs variant entre 0 et 1023. La pratique est un peu différente. Technologiquement, Pot. ne retournera pas exactement les tensions U attendues. La piste conductrice dont la résistance varie au cours de la rotation du curseur de contact n’est pas idéale. Et l’on observe une variation qui ressemble à [+0.12v à +4,94v]. La numérisation CAN sera alors comprise entre des limites de l’ordre de [4 à 1000]. Si l’on désire utiliser la pleine plage de variation sans se voir tributaire du composant que nous avons inséré dans le montage électrique, il importe de corriger par logiciel.
Dans ce but, deux directives sont prévues en tête de programme :
Comme il y aura d’autres corrections logicielles à effectuer dans les démonstrateurs ainsi que dans le programme définitif, ces ajustements virtuels sont regroupés en tête du listage source. Vous les trouverez facilement car les lignes qui les contiennent sont terminées par des commentaires visuels repérables sans hésitation de type : //@@@@@@@@@@@@@@@@@@@@@@@@@
Avant d’analyser les séquences de programme qui émulent la torsion, « l’exploitation sur le terrain » montre que parfois il serait souhaitable de neutraliser le potentiomètre, c’est à dire d’imposer comme valeur de CAN la moitié de la valeur théorique. (1023 / 2 » 511) La commande qui impose de prendre en compte une valeur moyenne « n* » permettra d’imposer un éclairage moyen aux phares, un centrage d’orientation des moteurs, une puissance moyenne du LASER etc. (On adopte ‘n‘ pour signifier Neutraliser.) Décortiquons le code source :
La boucle principale se termine par la séquence qui traite le mouvement de torsion en (1). Si la torsion est validée par la commande « t* », le test en sera positif et les diverses actions associées effectuées. En (2) CAN prend la valeur actuelle traduisant directement la tension U appliquée sur A1. La ligne (3) vérifie si le potentiomètre est actif ou neutralisé. S’il est neutralisé, l’instruction consiste à calculer la moyenne réelle des valeurs limites possibles sur le composant électrique matériel. Il suffit de prendre la valeur entière de (CAN_Inf + CAN_Sup) / 2. Nous avons déjà vu que pour imposer par logiciel ce type d’opération arithmétique l’instruction de décalage à droite >>1 est optimale. Enfin en (4) qu’elle soit neutralisée ou « actuelle », la valeur CAN sera prise en compte par la procédure Bouge_pour_un_balayage_en_torsion() qui se charge de « déhancher » l’insecte mécanique. La Fig.111 représente la vue de dessus. On désire une amplitude de torsion de ±13° de part et d’autre de l’axe longitudinal du châssis. Pour atteindre cette plage angulaire il faut tenir compte des glissements et frottements entre les Griffes et le sol ainsi que des projections géométriques « biaises ». Ces phénomènes engendrent des pertes de déplacement. Aussi, pour atteindre les ±13° de changement d’orientation, il faut imposer aux Hanches des débattements plus importants de ±20°. Sur la Fig.111 sont représentés les contacts au sol, et surtout les valeurs des consignes limites à imposer aux différents moteurs pour atteindre les angles de déviations les plus grands.
La procédure intègre quatre instructions, une pour chaque Hanche. Elle fait appel à la subroutine Mouvoir élémentaire qui reçoit en paramètre byte le numéro de la sortie à commander et la consigne de positionnement. Le mouvement ne sera déclenché que si les moteurs ne sont pas figés avec la commande « f* ». Si le mouvement est effectif, le tableau Configuration_actuelle est mis à jour.
Chaque instruction de Bouge_pour_un_balayage_en_torsion() doit effectuer une transposition entre la valeur angulaire contenue dans CAN avec la plage de variation relative au moteur concerné et surtout tenir compte de son déphasage par rapport au neutre opérationnel. Pour comprendre les valeurs des données insérées dans le programme, nous allons raisonner sur la Hanche A. Concernant le moteur n°1 la procédure devra actionner la sortie 0 correspondante sur le multiplexeur. L’instruction C++ map établit une proportionnalité entre la valeur de CAN, CAN_Inf, CAN_Sup, 325 et 247. Sur le dessin de la Fig.112 le CAN est susceptible de retourner la valeur de 143. Positionné entre 4 et 1000 qui sont les valeurs extrêmes issue d’un balayage potentiométrique, l’image entre 325 et 247 se situe à 314, valeur retournée par la fonction map. Ce n’est toutefois pas cette grandeur qui est soumise comme consigne au moteur, car il faut tenir compte du déphasage d’orientation des moteurs. On va donc retrancher 47 à la consigne pour que le balayage soit bien de 13° de chaque coté de l’orientation « centrale » qui correspond à la posture Stable Transversal. Le tableau de la Fig.113 résume les valeurs idoines.
Des petits pas pour une longue route.
Jekert sachant se trémousser et effectuer des figures de style, vous n’avez plus qu’une envie : Titiller les touches du clavier de l’ordinateur pour lui envoyer des commandes. Le programme démonstrateur P12_Tous_les_mouvements.ino est précisément disponible pour vous faire ce plaisir, le début du listage indiquant la totalité des commandes disponibles sous forme de remarques. Alors surtout ne vous en privez pas. Puis arrivera certainement la phase où vous désirerez mieux comprendre, établir le lien entre le logiciel et ce qui en résulte sur la motorisation. Pour démonter le mécanisme des déplacements de la sonde, il faudra parfois faire exécuter quatre, cinq, huit pas identiques, voir plus. Frapper à répétition une même consigne devient rapidement fastidieux. Aussi, tous les programmes conduisant à des mouvements de base ont été placés en tête de liste. Ainsi, devant comporter quatre caractères, les instructions de type « p04* » présentent forcément un zéro en tête. C’est ici qu’une évolution améliore l’expérimentation. Si au lieu de frapper « p04* » vous saisissez un ordre du genre « p4c* », c’est bien le programme 04 qui sera activé. La lettre qui suit, soit c dans notre cas, si elle est valide provoquera une répétition du mouvement invoqué un nombre de fois correspondant à son rang alphabétique.
N’oubliez-pas que la commande « t* » qui active le mode torsion est non suspensive, c’est à dire qu’elle n’empêche absolument pas d’envoyer les autres commandes valides du démonstrateur. Si vous ne modifiez pas la position du bouton du potentiomètre il ne se passera rien de particulier, et vous risquez d’oublier « sa présence ». Déclencher des déplacements de base risquera alors d’engendrer des mouvements brusques car il y aura « détorsion » brutale. Aussi, la procédure de torsion doit respecter un protocole qui impose dès que l’on a terminé l’expérience qui la justifie, de sortir de ce mode par la commande dédiée « p* » qui rePositionne en configuration Stable Transversal. Du reste, diverses phases en exploitation imposent des manipulations rigoureuses. Aussi, une fiche spécialisée sera dédiée aux protocoles importants, la torsion en faisant partie.
Cependant, durant une torsion on peut librement utiliser « i* » pour avoir l’état actuel de la machine par exemple. Parmi les commandes sur un caractère on dispose de « a* » qui se comporte comme une bascule pour Allumer ou éteindre les phares. Quand le LASER ou les phares sont actif, le fait de modifier la position du potentiomètre modifie leur état de clarté. Hors, si l’on désire effectuer une manipulation de torsion, on préférera certainement que l’état actuel des éclairages ne soit pas influencé. C’est la raison pour laquelle dans la liste des commandes sur un caractère a été ajouté « b* » une instruction de type OUI / NON qui change l’état de « Éclairages Bloqués ». On peut alors librement changer la position du bouton rotatif du potentiomètre sans influencer la valeur « mémorisée » d’énergie pour les phares et pour le LASER.
Notez au passage, que pour simplifier le logiciel, l’action sur Pot. agit simultanément sur les deux périphériques ce qui du reste ne pénalise absolument pas l’exploitation du robot. Naturellement, l’état du booléen Bloquer_niveaux est visualisé sur l’une des LEDs d’état et indiqué dans les informations fournies par la commande « i* ».
Toujours dans le but de fournir au personnel de gestion de la sonde quand cette dernière sera posée sur l’astre rouge, un maximum de commodités, chaque commande peut compléter son ACR par une ligne d’information qui donne les douze valeurs d’état de la configuration actuelle des moteurs. Cette information s’avère très utile quand on manipule un moteur en manuel est que l’on désire obtenir la valeur de consigne qui correspond à son attitude. Cette ligne de données peut s’avérer indigeste quand on n’en a pas besoin. Le booléen ACR_configuration_sur_USB peut s’initialiser à notre convenance par la commande donnée sur un seul caractère« c* ». (C pour Configuration.)
Enfin, la commande de « confort » « q* » sera à utiliser chaque fois que l’on Quitte le programme. Elle valide les moteurs s’ils sont figés, fait passer les mouvements en mode Rapide pour gagner du temps, valide le mode VEILLE, temporise une seconde, désactive les phares et le mode torsion. Pour achever cette séquence, « FIN ! » est envoyé sur le moniteur série. Pour mémoire la procédure VEILLE dépose proprement la sonde sur son bouclier par un mouvement coordonné. Cette séquence qui place la sonde dans une configuration propice à une reprise devrait s’utiliser chaque fois que l’on quitte le programme, que ce soit pour modifier ce dernier, ou tout simplement pour la remiser en vue d’une longue période de repos dans le placard.
La suite est ici.
