Revenir dans la salle informatique S4 n’est pas fait pour nous déplaire. Développer les programmes d’exploitation est assez excitant, car sur le grand mur frontal un vidéo projecteur éclaire tout l’écran des images fournies par quatre caméras à haute résolution qui entourent l’exploratrice confortablement installée sur son berceau. Chaque consigne de mouvement peut s’observer de tous les cotés de l’insecte quadrupède. Coté planning nous sommes un peu en avance, constat de bonne augure. Nous dirigeant vers l’ordinateur qui nous est réservé, Crouzet, l’un des ingénieurs logiciels vient à notre rencontre.
– Jour GC, (Les personnels s’amusent à nous nommer Grand Chef, il s’agit d’un surnom bon-enfant.)
РYa un prob avec la r̩partition des moteurs.
– Ha oui, lequel Julien ? (Nous avons à cÅ“ur d’appeler les personnels par leurs prénoms respectifs pour instaurer des relations amicales.)
– Ben c’est bien beau de les avoirs regroupés par connecteurs, mais ça bouffe 116 octets.
– Tant que ça ? Mazette, t’as raison Julien, faut immédiatement revoir notre copie.
MACHINE ARRIÈRE TOUTE !
Maitre mot en développement d’un projet qui évoluera probablement vers la saturation de l’espace mémoire réservé au programme : OPTIMISER EN PERMANENCE LE CODE. Le projet ludique en gestation est « ambitieux » et ouvre la porte à une foule de possibilités. Hors la mémoire réservée au programme est limitée. Il n’y a que deux voies pour pouvoir « tasser » le maximum de comportements opérationnels dans le programme qui animera l’insecte :
• Utiliser toutes les ressources de l’ATmega328.
• Minimiser en permanence la taille du code objet généré par le compilateur.
STRATÉGIE DE PROGRAMMATION :
Nous allons écrire des séquences qui seront chargées de réaliser une action ciblée. Quand les routines qui se chargent d’une fonction seront au point, avant de les considérer comme « définitives », il faudra systématiquement faire un bilan de leur coût en termes de nombre d’octets qu’elles mobilisent en octets dans la zone programme et dans celle des données dynamiques. Puis, analysant finement le code source écrit en C++ voir si des économies sont possibles.
Quand je vous livrerai un programme, globalement cette approche sera respectée sans le préciser, c’est à dire que je fournirai les démonstrateurs sans autre forme de procès. Ce n’est que ponctuellement que l’on abordera la phase optimisation. Notez que cette optique devrait guider tous les programmeurs et … en permanence quand émoustillés par leurs envies ils titilleront le clavier de l’ordinateur.
Lorsque l’on compare les deux programmes P04 et P06 on constate que P06 consomme effectivement 116 octets de programmes de plus que P04. Pourtant il ne gère que douze moteurs au lieu de seize. Le seul bénéfice que l’on tire de cette évolution c’est la facilité à brancher les servomoteurs. Encore que les connecter en ligne n’est pas vraiment délicat. Repérer facilement un membre était aussi annoncé comme avantageux. Ce n’est pas faux. Cependant, maintenant que l’on a vérifié le matériel, nous allons oublier somptueusement les n° de sorties, les références de traçabilité etc. Seuls les n° des moteurs indiqués sur la fiche Repérage et caractéristiques des articulations seront utiles en programmation. Après réflexion, le rapport Qualité / Prix n’y est pas. Avec 116 octets il sera possible d’ajouter une ou deux fonctions de plus dans l’ordinateur de bord. Alors … on débranche, on rebranche, on revient en arrière avec reprise de P04_Piloter_un_moteur.ino raison pour laquelle c’est ce dernier qui est mentionné dans Protocoles de dialogues avec la sonde.
Stratégie de développement.
Globalement, nous allons procéder par « paquets ». C’est à dire que l’on va écrire toutes les subroutines et fonctions qui permettront de faire fonctionner un programme d’exploitation. Quand ces dernières seront optimisées, nous les « transporterons » dans un programme COMPLET qui cumulera toutes les avancées au fur et à mesure que des fonctionnalités opérationnelles auront été mises au point. Comme le nombre de démonstrateurs est encore inconnu, pour ne pas avoir à le renommer en permanence le logiciel « définitif » sera identifié par P30_Programme COMPLET.ino et sera le reflet de ce que peut faire JEKERT actuellement, comportant l’ensemble des fonctionnalités mises au point. On se doute que ce programme va subir des chamboulements sévères si l’optimisation remet en cause les écritures précédentes. Peu importe. Le principal, c’est d’avoir une référence qui tient à jour l’intégralité des améliorations apportées, car à la fin, regrouper tous les morceaux provoquerait un effet « boule de neige » dévastateur. De plus, comme le programme est complet, à tout moment nous connaîtrons sa taille et n’ajouter de nouvelles fonctions que si le matériel le permet. Rien ne serait plus frustrant que de ne pas pouvoir tout faire entrer dans la mémoire …
Les premières briques de l’édifice.
Engendrer des déplacements d’un dispositif artificiel sur pattes en copiant la nature constitue l’une des approches les plus compliquées pour motoriser un engin mobile. Le roulage est de loin la solution la plus simple techniquement, que ce soit avec deux roues directionnelles, ou par des rotations synchrone ou opposées comme sur les engins munis de chenilles. Déplacer consiste à enchaîner des mouvements élémentaires. Aussi, avant de partir à l’aventure de la marche à pied, nous allons commencer par créer des programmes de configuration. Dans la version définitive du projet, ils seront réordonnés en plaçant en tête dans la liste les plus utilisés quand la sonde sera posée sur Mars. Pour l’heure, nous les nommerons dans l’ordre d’élaboration.
Premier à encombrer la liste, nous allons reprendre « p01*« et nous contenter d’optimiser ses procédures avant de les intégrer dans P30_Programme COMPLET.ino. Ce module ne permet pas à la sonde de se déplacer. Il ne fait que lui imposer une configuration particulière, c’est à dire une combinaison réfléchie d’orientations précises pour les douze articulations. Il est fort probable que pour déplacer JEKERT nous aurons à invoquer plusieurs configurations successives. Aussi l’idée d’optimisation consiste à créer une procédure paramétrée.
C’est P07_Optimiser_la_procedure_Configurer.ino qui va constituer les fondations de l’édifice logiciel. Dans ce programme deux approches ont été tentées. La première consiste à faire appel à une instruction Switch (Sortie) insérée dans une boucle à douze incrémentations pour envoyer les consignes aux moteurs. Une deuxième tentative d’optimisation a consisté à supprimer la boucle et faire appel à douze instructions du type pwm.setPWM(Num_Sortie, 0, Mn); pour piloter chaque moteur. Cette deuxième version n’est pas la bonne, elle consomme 38 octets de plus.
Ce que montre également ce démonstrateur, c’est que chaque chaîne de caractères consomme autant d’octets dans la mémoire dynamique qu’elle contient de caractères. Tout « bavardage » est donc pénalisant. Il serait judicieux de ranger ces textes dans la mémoire non volatile EEPROM du microcontrôleur. Reste à en évaluer la rentabilité car il faut ajouter les routines d’échanges de données.
Méthode pour développer une configuration.
L’exploitation de la sonde martienne fait apparaître dès le départ la nécessité de prévoir plusieurs configurations typiques. De plus, quand on va chercher à gérer les déplacements, il sera certainement indispensable de déterminer des postures intermédiaires. La première action consiste à utiliser les dessins et à construire une épure précise de ce que l’on désire obtenir. Logiquement, il suffirait alors sur le dessin de mesurer les angles de position angulaire. Portant ces angles dans douze consignes, normalement nous obtiendrions ce qui est prévu. Ça c’est de la théorie. Dans la pratique, on a limité les amplitudes de déplacement, on interpole entre les deux pour « linéariser » le positionnement. La dispersion de caractéristiques engendre des positionnements un peu imprécis.
Concrètement, on va établir un lien entre théorie et pratique de la façon suivante :
• À partir de l’épure on estimera les positions angulaires,
• On codera les valeurs théoriques dans le démonstrateur et on déclenchera le programme concerné,
• À l’aire du démonstrateur on affinera les positions manuellement,
• Position « parfaite » on reportera servomoteur par servomoteur la valeur de consigne affichée Ã
  l’écran dans le programme démonstrateur.
P02 : Configuration décollage.
Logée sous la coiffe du lanceur Ariane et bien calée sur son berceau, il importe de configurer la charge utile de la fusée pour qu’elle occupe le volume le plus réduit possible. Plus le diamètre et la hauteur de la coiffe seront faibles, et moins sera onéreux le coût du lancement. On gagne en poids de la coiffe, en résistance à la traversée atmosphérique etc. La Fig.80 simule l’agencement plausible d’une sonde sur un lanceur comme Ariane. La fusée se contente généralement de satelliser la charge utile en orbite haute. Puis, le vaisseau en partance pour une exploration du système solaire possède son propre moteur d’injection en orbite trans-planétaire. Il doit posséder des petits moteurs de manÅ“uvre qui assurent son orientation précise lors des poussées du moteur principal. Quand la sonde « déboule » dans la sphère d’influence de la planète visée, elle s’oriente en rétrograde et freine pour se mettre en orbite. Ce n’est qu’ensuite, l’orbite étant affinée avec précision, que sera produit la séparation et le largage de la sonde, à un instant critique pour qu’elle se pose sur le « landing site » prévu pour la mission.
Dans le but d’évaluer les optimisations logicielles dans P07_Optimiser_la_procedure_Configurer.ino on va comme deuxième programme faisant appel à la routine void CONFIGURER(…) établir la configuration de lancement. Ce sera le premier programme « opérationnel » qui sera invoqué lors de l’une des phases primordiale de la mission. Après avoir imaginé d’escamoter les Griffes vers le dessus de la structure de la sonde, (Ce qui ne serait pas avantageux car la zone est encombrée par le moteur orbital et ses réservoirs d’ergols.) diverses études sur épures montrent que le volume le plus faible sera celui de la Fig.81 compatible avec un « maître couple » raisonnable. Le « maître couple » est la surface du mobile vu face à son déplacement. Il est significatif de la résistance aérodynamique qui sera subie par le mobile. Cette configuration est obtenue en plaçant les Tibias à la verticale, les Griffes étant escamotées sur le dessous en ménageant un espace de sécurité avec le bouclier. Par ailleurs, l’encombrement latéral qui conditionne directement le diamètre de la coiffe devra être minimisé. On optimise ce paramètre en plaçant les deux Fémurs convergents dans la direction transversale Bâbord / Tribord sans pour autant se toucher. Dans cette posture des quatre Jambes on obtient la Largeur minimale. Le programme « p02*« se charge de réaliser la configuration de décollage. Pour développer cette séquence il est précisé en fin du chapitre précédent :
À l’aire du démonstrateur on affinera les positions manuellement. Vous pouvez le faire avec le clavier et le dialogue USB avec P07_Optimiser …ino. Ceci dit, si vous préférez obtenir les consignes en utilisant le potentiomètre, rien n’interdit de téléverser P08_Piloter_au_potentiometre.ino associé à sa fiche d’utilisation.
L’atterrissage : Une phase particulièrement critique de la mission.
Optimiser la procédure de service void CONFIGURER(…) va nous amener à tenter divers codages, puis de comparer la taille de la routine et le coût en octets chaque fois que l’on fait appel à cette dernière. Plusieurs approches sont envisageables. Pour effectuer cette étude, vous avez compris qu’il faudra deux autres postures. Chaque fois que l’on ajoutera une configuration, il sera facile d’observer l’augmentation de taille du logiciel. Il serait envisageable de réutiliser les valeurs angulaires de « p01*« ou « p02*« sachant que la taille du logiciel ne dépend pas des données de position. C’est un peu « idiot », car on a téléversé P08_Piloter_au_potentiometre.ino par exemple, alors autant se faire un petit tableau dans lequel on collecte les valeurs pour d’autres postures. Dans le chapitre qui suit, nous allons établir la configuration atterrissage.
Diverses techniques ont été utilisées pour poser des explorateurs sur Mars. L’une des plus simples, celle qui sera utilisée pour JEKERT, consiste à utiliser des parachutes. Le déroulement de la descente à été explicité dans le chapitre La bestiole robotique prend corps en bas de la page 25 du didacticiel. Nous allons nous contenter dans ce chapitre d’examiner les dangers qui guettent la sonde au moment de son impact avec le sol. Sur la Fig.82 sont représentés les dangers les plus probables. En A la vitesse V1 est un peu trop importante, l’arrivée se faisant par une météo pas très favorable. L’impact avec le sol est suffisamment énergique pour plier la Griffe qui touche en premier. (Ou sans la plier endommage les articulations des moteurs.) En B la vitesse d’arrivéeV1 est convenable, mais pas de chance juste sous l’une des Griffes critiques se trouve un vilain rocher. Il en résulte un début de rotation R1 qui peut s’avérer suffisant pour que l’impact de l’autre Griffe la détruise. Pour peu que le parachute tire sur le mauvais coté, associé à R1 il peut engendrer le basculement R2, la sonde se couchant sur le coté. Dans tous les cas la mission serait un triste échec.
P03 : Configuration atterrissage.
Éliminer radicalement le risque A revient à ce que la sonde percute le sol non pas sur ses Jambes, mais sur le bouclier très résistant et conçu à cet effet. Le choc vers les organes de la sonde étant atténué par des amortisseurs élastiques de type « silentblocs ». Pour éliminer au maximum le risque B on va minimiser la surface de JEKERT vue du sol. Ainsi, si elle se pose à proximité d’un rocher, elle ne basculera pas le contact rocheux étant alors peu probable. Comme montré sur la Fig83 l’idée qui préside consiste à ramener les quatre Jambes complètement au dessus de la sonde. La morphologie adoptée envisageait dès le début cette configuration qui est obtenue en plaçant les Tibias à la verticale et les Pieds en butée logicielle α. Par ailleurs, l’encombrement latéral qui conditionne directement le risque de toucher un rocher devra être minimisé. On optimise ce paramètre en plaçant les divers Fémurs dans une direction qui inscrit, vu de dessus, le volume enveloppe dans le cercle le plus petit possible. Dans cette posture des quatre Jambes on obtient la Largeur minimale. Le programme « p03*« se chargera de réaliser la configuration d’atterrissage. Pour développer cette séquence profiter du programme P08_Piloter_au_potentiometre.ino qui a été téléchargé dans l’ATmega328 pour étudier la posture de décollage. Je vous invite fortement à en profiter pour trouver les angles correspondant aux deux autres configurations abordées dans les chapitres qui suivent.
Instabilité et risque de basculement.
Fondamentale, c’est la posture qui sera la plus utilisée lors de l’exploitation de l’engin scientifique. Tout au moins si l’élaboration du logiciel s’en tient aux premières estimations. En effet, des études préliminaires semblent s’orienter vers des déplacements qui seront tous initiés à partir de cette posture. En quoi la configuration est-elle STABLE et surtout RAISONNABLE ?
Un ensemble matériel sera d’autant plus stable :
• Que son centre de gravité est proche du sol, (Attention à la garde au sol pour un mobile.)
• Que sa surface de sustentation est importante.
Considérons la Fig.84 qui montre l’ensemble mobile vu de dessus avec son centre de gravité G. Les points C1, C2, C3 et C4 sont les divers contacts entre le mobile et le sol à l’instant considéré. Par définition la surface de sustentation S est la zone au sol qui « encercle » les divers points de contact avec ce dernier. Plus cette surface est grande, plus nous aurons des chances que le centre de gravité G se trouve au dessus. Dès qu’il sort verticalement de cette zone, l’ensemble bascule. Augmenter l’empattement améliore l’équilibre, raison pour laquelle il sera avantageux pour la stabilité d’écarter au maximum les contacts des divers membres avec le sol. (Ce serait également vrai avec un mobile roulant.)
Envisageons maintenant le cas particulier de la Fig.85 pour lequel la sonde s’est posée sur une surface pas trop inclinée. Pas de change, l’une des pattes est arrivée en contact exactement sur un vilain rocher R. On retrouve les divers contacts C1… C2 avec la surface martienne et l’on en déduit le contour S de la surface de sustentation. Placer le centre de gravité proche du sol diminue le risque de basculement si la surface est inclinée. Dans le cas G1 le centre de gravité étant assez bas, la verticale place le poids P1 au dessus de S. La sonde ne bascule pas. Par contre, si l’ensemble posé est relativement haut, le 
centre de gravité G2 voit sa verticale sortir de la surface de sustentation S. Le poids P2 engendre alors un basculement et la mission restera un tristounet échec. Dommage !
CONCLUSION : Chercher à placer le centre de gravité le plus bas possible sur l’engin d’exploration conduira à minimiser les risques de basculement sur plan incliné. C’est du reste la raison qui avait présidé lorsque l’on a décidé de placer les servomoteurs des hanches sur le dessus du châssis. la structure étant plus basse la stabilité n’en serait que meilleure. La garde au sol restait acceptable : Agencement adopté !
Configuration raisonnable.
Posture à soigner avec attention puisqu’elle va jouer un rôle important dans les déplacements de JEKERT, elle va forcément résulter de compromis, comme pour tout agencement d’un matériel technique. Assurément, l’attitude de la Fig.86 est rassurante au point de vue de la stabilité. On a écarté les Jambes au maximum pour étaler le plus possible la surface de sustentation. Malheureusement cette géométrie n’est pas raisonnable pour deux raisons. La première, une garde au sol
bien trop faible. Le plus petit caillou va frotter sous le bouclier. Et surtout, la force F exercée par le sol sur la Griffe présente un bras de levier B vraiment exagéré qui va soumettre les articulations à des contraintes insupportables sur le long terme. Ce phénomène sera d’autant plus préjudiciable à la longévité du matériel que cette posture sera adoptée la majorité du temps en exploitation. (Revoir les notions de contraintes chapitre Propagation des efforts dans un mécanisme.)
Sans dégrader de façon significative la stabilité de l’explorateur, la Fig.87 présente la géométrie
qui sera adoptée pour une configuration stable réputée RAISONNABLE. La Griffe sera placée en orientation verticale. Ainsi le Pied ne sera plus du tout soumis à de la torsion, il ne subira que la poussée F. Le Tibia sera orienté à 45° par rapport au châssis. Cet angle maintient un étalement largement suffisant des contacts avec le sol tout en infligeant au Genou et surtout à la Hanche des moments de torsions raisonnables. C’est cette épure transversale représentée dans un plan vertical qui va conditionner l’attitude de Stabilité raisonnable, assurant une garde au sol confortable.
P04 : Configuration Stable Raisonnable.
Entièrement déterminées en élévation, la géométrie de cette posture doit aussi se voir optimisée en vue de dessus. C’est le critère « surface de sustentation la plus grande possible » qui va guider la construction de l’épure relative à cette phase des missions martiennes. Le dessin est donné en Fig.88 (En haut de la page 11 du didacticiel.) sur laquelle les moteurs des Pieds sont coloriés en bleu pour les situer plus facilement. Les rectangles mis en évidence en jaune situent les Griffes qui sont en orientation verticale et sur cette représentation observées en vue de dessus. Pour obtenir la stabilité maximale dans la direction longitudinale ET dans la direction transversale, nous arrivons rapidement à la conclusion que la surface de sustentation sera carrée et centrée sur le châssis. Les articulations des Hanches imposent la valeur du coté qui avoisine 163mm. Le tracé précis de l’épure situe les angles tels que α à environ 48°. Programmer les angles typiques dans « p04*« n’est pas spécialement facile, car il faut les transposer en valeurs de consigne. De plus, les divers moteurs n’ont pas des caractéristiques identiques. Aussi, d’une façon pragmatique, déterminer les grandeurs numériques à affecter aux entiers pour orienter les Hanches consiste à se faire un petit gabarit. On découpe un carré de 163mm de coté dans un morceau de carton quelconque. Au centre on pratique un trou circulaire de 20mm de diamètre, c’est suffisant. Puis, à l’aide du « Sketch » démonstrateur P08_Piloter_au_potentiometre.ino quand il est encore présent dans l’ATmega328, disposez les Tibias à 45° vers le bas. 
Orientez verticalement les Griffes. Puis, carré en carton déposé sur le dessus des jambes, bien centré sur le châssis en regardant à travers le trou central, dégrossir l’orientation des Hanches. Affiner la direction de chaque Jambe en regardant le patron de guidage bien à la verticale en vue plongeante. Quand l’ensemble présente un aspect bien symétrique, avec un réglet mesurer les écarts entre les dessus des Griffe. Corriger finement les positionnements jusqu’à ce que les quatre distances soient identiques et que la symétrie « visuelle » par rapport au châssis soit parfaite. (Elles devraient avoisiner toutes les 163mm prédits sur l’épure.) Noter alors les valeurs des consignes, « p04*« en découle directement.
P05 : Configuration Hauteur Maximale.
Nous n’avons aucune certitude à ce stade de l’élaboration du projet que cette posture sera réellement utile sur le terrain. Il reste toutefois légitime d’imaginer que pour améliorer la vue vers l’avant du mobile, ou pour passer au dessus d’un rocher qui dépasse légèrement plus que la hauteur permise par la garde au sol « standard », on veuille organiser géométriquement les Jambes pour que le châssis soit le plus haut possible. Vraiment pas de quoi en donner des boutons sur la figure à nos ingénieurs logiciel. Pour se hisser au plus haut de la morphologie de la sonde il suffit de placer verticalement les Tibias et les Griffes. C’est assez enfantin. Comme on va forcément diminuer la surface de sustentation, il est logique de conserver pour les Hanches celles « du carré » qui optimise ce paramètre. On profite de ces manipulations pour tester la posture avec « p05*« , ceci dit, on n’y passera pas directement. Il faudra probablement user de mouvements coordonnés pour passer de « p04*« à cette attitude, technique qui sera explicitée et justifié plus avant dans le didacticiel …
La suite est ici.
