18) La stabilisation gyroscopique et les centrales inertielles.

Omniprésente dans pratiquement « tous les domaines » de la technologie, la stabilisation gyroscopique ou la navigation inertielle s’imposent depuis des décennies. Initialement la stabilisation gyroscopique a vu le jour dans les aéronefs sous forme de conservateur de cap. Puis s’est imposée la navigation inertielle. Dans un premier temps elle a colonisé les missiles, puis est venue en aide à la navigation aérienne et s’imposer dans les vaisseaux Apollo. Les gyroscopes mécaniques ont été remplacés par des dispositifs électroniques dont les dimensions sont devenus dérisoires. Ces composants envahissent tout, dans les petits drones de loisir, les caméscopes, partout où on désire stabiliser un quelconque dispositif. Bien que le petit module que nous allons utiliser rentre dans la catégorie des modules pour Arduino, ce domaine d’expérimentation est assez particulier pour suggérer de lui consacrer un chapitre particulier.

Le principe de la stabilisation gyroscopique.

Pas question dans le cadre de nos loisir de vous saturer d’informations théoriques et d’équations à n’en plus finir. On va se contenter une fois de plus du minimum. Le but est d’expliquer très très très succinctement les bases de la navigation inertielle pour pouvoir apprécier la magie qui est concentrée et qui se cache dans le petit module qui va servir d’exemple concret. Pour ne pas encombrer le didacticiel par des explications dont vous pouvez allègrement faire l’impasse, les développements techniques (Et culturels.) sont regroupés dans le document Navigation INERTIELLE.pdf que vous trouverez dans le dossier <Documents\FASCICULES>.

Experience_123 et 124 : Accéléromètre trirectangle.

Incontournable dans le domaine de la stabilisation gyroscopique, le tout petit module MPU-6050 joue toutefois dans la cour des grands par ses performances. La Fiche n°54 le présente brièvement. Grâce à sa bibliothèque dédiée MPU6050.h qui fait appel à Wire.h et du complément I2Cdev.h, son utilisation est presque facile. Naturellement ces bibliothèques sont disponibles dans <! BIBLIOTHEQUES>. Également logé dans <Documents\Composants> se trouve Registres du MPU 6050.pdf qui peut vous faciliter l’interprétation des démonstrateurs proposés. Et surtout, dans <Documents\FASCICULES> est proposé Fiches MPU-6050.pdf explicitant les notions de quaternions et d’angles d’Euler. Le module compact GY-521 est basé sur le circuit intégré MPU-6050 et combine un gyroscope 3 axes et un accéléromètre à 3 axes avec un processeur de mouvement numérique (DMP) et un capteur de température. Les données du capteur sont lues via le bus I²C. (Deux lignes SCL et SDA). Grâce à la broche AD0, on peut sélectionner l’adresse I²C en 0x68 si état « 0 » et en 0x69 si état « 1« . Le MPU-6050 dispose d’un tampon de données de type FIFO de 1024 octets qui peut être lu par le microcontrôleur. Les deux démonstrateurs Experience_123.ino et Experience_124.ino sont manifestement issus de la même fratrie. Ils effectuent strictement le même traitement sur les données. Ces dernières montrées sur le montage de la Fig.240 sont nombreuses et occupent toute la largeur de l’écran vidéo de l’ordinateur. Les données sont classées par colonne, (Les colonnes sont mises en évidence par coloration.) avec des décalages verticaux car je n’ai pas trouvé le courage de traiter la longueur des chaînes de texte. Les données issues des deux logiciels sont « brutes de décoffrage ». Le but visé par ces deux manipulations consiste à montrer que si l’on filtre les données en B les fluctuations des valeurs sont plus faibles que si l’on se contente d’une mesure par affichage en A.

Experience_125 : Découverte du MPU6050.

Avec l’expérience précédente on affichait des valeurs non traitées, et sans aucune vérification de la présence du module de mesures. Experience_125.ino améliore bien les choses et commence à nous approcher d’un logiciel plus opérationnel. Il vérifie la présence de la plateforme inertielle et fournit des données plus compréhensibles sous forme des trois angles d’inclinaison du capteur par rapport au champ de gravitation terrestre. Sur la Fig.241 en A le capteur est en place alors qu’en B la broche SDA a été débranchée. Du coup nous avons les deux textes d’erreur mis en évidence par la coloration en jaune et en vert. La Fig.242 présente le petit module en vue de dessus. La sérigraphie relative à la direction des axes est ambigüe, car ils sont représentés à 45° pour 0X et 0Y situés dans le plan du circuit imprimé. Dans la pratique ces deux axes cartésiens sont parallèles aux bord du circuit imprimé. Leurs directions et leurs sens sont représentés en rouge sur la Fig.242.

Une alternative à Serial.print.

Force est de constater que le langage C++ comporte des variantes à certaines instructions qui à mon sens ne vont pas dans le sens de la lisibilité des programme. Dans P125 j’en ai volontairement glissé une avec laquelle j’avais fait connaissance lorsque je cherchais à utiliser la bibliothèque MPU6050.h dans certains de leurs listages pour les exemples. Cette variante pour Serial.print s’applique également
à Serial.println. Considérons l’instruction suivante qui est en ligne 84 du démonstrateur :

Personnellement je préfère de loin la deuxième écriture certes plus banale, mais plus lisible. Aussi, la forme utilisée exceptionnellement dans P125 ne sera pas fréquente dans mes logiciels.

Experience_126 : Mesure des accélérations.

Véritable accéléromètre, pour minimiser le matériel impliqué, les résultats de ces manipulations seront présentés sur le Moniteur de l’IDE. Pour cette quatrième expérimentation le module MPU-6050 est relié à Arduino par des fils souples pour que l’on puisse le faire gigoter. Pour « travailler en temps réel » les mesures ne sont pas filtrées. Dans cette exercice le démonstrateur Experience_126.ino lit en permanence les trois composantes de l’accélération et en calcule le module. Il retire la valeur de l’accélération de la pesanteur traditionnellement représentée par g. Les accélérations et chocs détectés sont donc affichés quand le module dépasse les 10m/s/s. L’affichage se fait alors en numérique et en analogique sous la forme d’un « ruban d’étoiles » sur le Moniteur de l’IDE. Il n’y a des affichages que lorsque le module est « gigoté » pour subir des accélérations. S’il est laissé au repos, l’affichage est figé. Sur la Fig.243 A le capteur est posé sur le bureau et on a frappé modérément à proximité. Le dispositif enregistre le choc puis les vibrations subissent un décrément logarithmique. En B on a frappé plus fortement et le capteur accuse en C un deuxième rebond suivi en zone D d’une suite de « vibrations qui s’atténuent en quelques cycles. Dans ces deux manipulations on n’a pas touché le capteur. Il est posé sur le bureau et on a frappé la surface à environ 5cm. Sur la Fig.245 on a saisi le petit module entre le pouce et l’index et on le fait « gigoter » par des mouvements alternatifs. Quand on s’active à ce genre de gestuelle, le mouvement alternatif est constamment « contrarié ». À peine on accélère que pour repartir dans l’autre sens on freine. Le freinage n’étant pas autre chose qu’une accélération qui est en sens inverses de la vitesse. Cette dernière diminue, s’annule puis augmente dans l’autre sens pour ralentir et contrer à nouveau le mouvement. Compte tenu des inerties, un tel mouvement alternatif est toujours pseudo-sinusoïdal comme symbolisé en E. On devrait retrouver ce phénomène sur la Fig.244, sauf que le démonstrateur se contente d’afficher la valeur du module de l’accélération et ne tient pas compte du sens du mouvement. Du coup l’affichage des valeurs en A et C de la Fig. 244 est toujours positif. Dans la pratique il faut interpréter le signe du sens de déplacement ce qui est fait en B et en D. On remarque nettement sur les deux zones qu’il y a une courte période où l’accélération est constante. C’est la conséquence de faire bouger avec précautions le module car il est relié à Arduino avec des fils que par paresse j’ai choisi trop courts. Si l’on pouvait faire bouger librement sans cette contrainte où l’amplitude est trop limitée, l’évolution de l’accélération serait nettement plus sinusoïdale.

Experience_127 : Recopie le roulis sur un servomoteur.

Premier tremplin vers la stabilisation d’une plateforme par une motorisation asservie à la centrale inertielle, Experience_127.ino se contente de recopier les inclinaisons en roulis sur un servomoteur MG90S par rapport à son orientation médiane. (Voir la Fig.246) Le pilotage se fait en degrés d’inclinaison, le moteur adoptant son neutre opérationnel lorsque le circuit imprimé de MPU-6050 est placé à l’horizontale. Toute inclinaison en roulis sera recopiée « à l’échelle un » sur le servomoteur. Placé en vis à vis avec le MG90S le plan du circuit imprimé restera parallèle au palonnier. La Fig.247 montre les données typiques affichées sur le Moniteur de l’IDE. Une LED verte et une LED rouge s’allument lorsque l’inclinaison de la centrale inertielle arrive sur les « butées angulaires logicielles » de 10° et de 30°. Le protocole d’utilisation est en tête de listage du démonstrateur.

Experience_128 : Tester la mise en veille du servomoteur.

Programme jumeau de P127 le démonstrateur Experience_128.ino effectue des traitements totalement identiques. Seule différence : Le servomoteur est mis en veille lorsqu’il n’y a pas de changement de mouvement. Dans ce but on se contente de couper l’alimentation du +5Vcc sur le servomoteur pour le placer en veille. C’est D4 qui pilote le petit relais RL avec sa diode de roue libre D. (Voir P062.) La tension nominale de fonctionnement de RL est de 5Vcc. Pour stabiliser le comportement lorsque l’alimentation est établie, elle le reste pendant une temporisation dépendant du paramètre Nb_fois 50. Lorsqu’un servomoteur est en attente d’une consigne, seule son électronique embarquée consomme un courant assez dérisoire. Aussi couper son alimentation comme dans cette expérience est une « fausse bonne idée ». Le but réel de cette approche consiste à « dégrossir » un projet dans lequel la motorisation serait constituée de moteurs PAS à PAS qui eux au repos consomment beaucoup d’énergie et ont tendance à chauffer. Pour des servomoteurs cette solution n’est pas à copier. Toutefois, brancher des servomoteurs à la place de moteurs PAS à PAS est bien plus simple car il n’y a pas besoin d’un module d’interfaçage. Tester avec un servomoteur est donc bien plus simple.

Experience_129 : Rotation sur toute la plage du servomoteur.

Dernière expérience avec un servomoteur, dans Experience_129.ino on supprime les butées logicielles pour couvrir toute la plage de rotation de 180° du MG90S. en ligne n°112 du démonstrateur on trouve l’instruction R = ((LTR[2] * 180/M_PI) * 1.2) * (-1.0) qui calcule en degrés l’angle de rotation R en ROULIS pour envoyer en consigne au servomoteur. La multiplication par -1.0 impose une inversion de signe dans le but d’incliner dans le bon sens. Le coefficient multiplicateur 1.2 devrait être indiqué en paramètre en tête de listage. C’est lui qui permet d’atteindre entièrement la plage de rotation du MG90S qui peut varier d’un composant à un autre. L’utilisation du programme est élémentaire et comme pour les démonstrateurs précédents figure en tête de listage.

Experience_130 : Visualisation de l’assiette et du CAP du mobile.

Neuvième expérience avec le MPU-6050, ce démonstrateur mesure les orientations sur les trois axes de la centrale inertielle et affiche les valeurs sur le Moniteur de l’IDE. Il se comporte à la fois comme l’horizon artificiel et le conservateur de CAP dans les aéronefs. Comme on va le voir, il permet en outre de constater la « dérive gyroscopique ». Concrètement, il constitue un préambule pour préparer P131 qui constitue un vrai petit projet. Avant d’envisager une visualisation graphique élaborée, dans un premier temps il importe d’obtenir des données fiables.
Sur RESET, Experience_130.ino procède à l’attente de la stabilisation des mesures. En effet, jusqu’à présent on a constaté que lorsque l’on provoque un redémarrage du microcontrôleur, les résultats effectuée fluctuent durant une centaine de mesures. (C’est la température interne qui se stabilise. Il faut plus ou moins de temps.) Il faut donc attendre que les numérisations soient stabilisées avant de commencer à traiter le programme. Le test de stabilité est réalisé sur l’axe de LACET, car c’est lui qui pose le plus de problèmes. Sur la Fig.249 qui est un petit montage dans lequel apparait les divers cas possibles, la zone jaune correspond au démarrage du système. Puis, durant une à trois secondes, l’affichage est figé. Dès que les mesures sont stables le listage des données commence. Mais se pose un problème fondamental : La centrale gyroscopique n’a aucune idée de l’orientation du mobile autour de l’axe de LACET et encore moins du CAP, c’est à dire de la direction vers laquelle est orienté le mobile par rapport au NORD géographique. C’est la raison pour laquelle, dès que les mesures sont stables, l’orientation gyroscopique en LACET est annulée considérant que c’est le CAP que désire suivre le pilote de l’avion. Dans la zone bleue, vont alors être affichés les ECARTs de CAP. S’ils sont négatif c’est que la déviation se fait vers la gauche, et positif vers la droite. C’est donc cette indication d’ECART par rapport à la route désirée qui est indiquée. L’inclinaison en ROULIS est coloriée en vert sur la copie d’écran. Pour le pilote cette inclinaison sur Bâbord ou sur Tribord est une information capitale, car c’est elle qui sera responsable de la perte de CAP. Enfin, dans la colonne rose sont indiquées les valeurs du TANGAGE. C’est lui qui sera responsable de la dérive d’altitude. (Naturellement, pour un navire le TANGAGE ne sera responsable … que du mal de mer !) Cabre l’avion monte, Pique l’avion perd de l’altitude. En faisant changer l’orientation dans les trois directions, vous allez rapidement vous rendre compte que ces valeurs qui défilent ne sont pas faciles à appréhender, et si vous cherchez à placer le module bien à l’horizontale et à stabiliser l’orientation en LACET, ces chiffres qui défilent ne sont vraiment pas adaptés. C’est pour ça qu’en aviation on cherche à présenter ces données de façon « plus instinctives », objet du prochain démonstrateur. À tout moment un bouton poussoir branché sur D5 permet de recaler le gyroscope pour un ECART nul.

La dérive gyroscopique.

Phénomène physique connu depuis l’invention des conservateurs de CAP gyroscopique, pour vous informer vous commencez par prendre en compte les informations dans le document CAP et HORIZON ARTIFICIEL.pdf disponible dans le sous-dossier <Documents\FASCICULES>. Puis, pour constater ce phénomène, vous immobilisez le petit circuit imprimé MPU-6050 dans un petit étau de maquettiste par exemple pour qu’il soit d’une immobilité garantie. Lorsque les mesures sont totalement stables, vous cliquez sur le bouton poussoir de recalage gyroscopique pour imposer un ECART nul. Vous notez l’heure. Puis, vous attendez 15 minutes par exemple. (Profitez-en pour arroser les fleurs dans l’appartement !) Au bout de ce laps de temps ECART indiquera une valeur de l’ordre de 3 à 4 degrés ce qui prouve que … la Terre tourne !

Experience_131 : Conception d’un petit tableau de bord graphique.

Nous avons constaté avec P130 qu’une cascade de nombres qui changent rapidement est particulièrement indigeste pour interpréter instinctivement et corriger des écarts d’assiette ou de CAP. La solution à cette difficulté consiste à présenter les paramètres fondamentaux du pilotage sous forme graphique. Les dessins symboliques immédiats à interpréter sont toujours complétés par les valeurs numériques que le pilote peut lire pour avoir s’il le désire la grandeur du paramètre avec précision. Concevoir un système de visualisation graphique est toujours très délicat, car il résultera de contraintes sévères, et en particulier de la définition de l’écran graphique utilisé. Ce thème est passionnant, mais impose trop d’explications pour venir alourdir ce didacticiel. Tous les renseignements à ce sujet sont donnés dans CAP et HORIZON ARTIFICIEL.pdf avec la justification des choix effectués, les données géométriques et les traitements mathématiques assez conséquents qui font appel à la trigonométrie.

Experience_132 : MPU-6050 et tableau de bord graphique.

C’est l’aboutissement de P130 et de P131 qui fusionnés conduisent à Experience_132.ino qui puisant ses données dans le module inertiel les affiche sur le petit tableau de bord virtuel de la Fig.251 complété par l’affichage peu opérationnel sur le Moniteur de l’IDE. Comme dans le programme de P130 la valeur du CAP souhaité par le pilote est purement informationnelle et peut être modifiée à convenance en changeant la valeur du paramètre CAP. Pour prouver qu’un afficheur OLED monochrome peut parfaitement remplacer le bicolore bleu et jaune, sur la Fig.251 c’est un composant entièrement bleu qui est utilisé. Lorsque la fusion de deux derniers démonstrateur à été opérée, au début le croquis c’est mis à faire « du n’importe quoi ». Pourtant, je n’ai fais que réunir deux listages qui ont fait leurs preuves. J’ai mis plus de trois heures à en trouver la cause du comportement erratique constaté. En général je subodore assez rapidement le problème de collision de PILE avec le TAS. Pour savoir de quoi il retourne, il vous faudra effectuer les manipulations de P157 et consulter plus tard le document Collision_entre_la_PILE_et_le_TAS.pdf. (Plus tard, car ici ces précisions sont justes pour justifier le coté sommaire des texte en rose.) Mais cette fois je ne me suis pas méfié, car le croquis occupe à peine 75% de la place réservée au programme et laisse libre 1200 octets pour les variables locales. Dans la réalité, en fin d’initialisation l’espace entre la PILE et le TAS fait 152 Octets ce qui habituellement est largement suffisant. Et bien dans notre cas c’est peu, car visiblement la bibliothèque MPU6050.h doit consommer pas mal de place sur la PILE et sur le TAS. Résultat, il a fallu faire des économies drastiques de place. Quand vous aborderez P157 vous apprendrez que l’un des moyens les plus efficace consiste à diminuer la taille des textes affichés ou à les loger en EEPROM. Ici, comme le montre la Fig.252, les textes du dialogue H/M ont été réduits au maximum. Sur cette copie d’écran, dans l’encadré rouge figure l’information relative à la place qui reste disponible entre la PILE et le TAS en fin de RESET. La Fig.253 précise l’orientation que doit présenter la petite centrale inertielle par rapport à l’aéronef.

Stabilisation gyroscopique et moteurs PAS à PAS.

Tous les démonstrateurs proposés qui gèrent une motorisation utilisent des servomoteurs, aucun exemple avec des unités PAS à PAS. Ce choix est volontaire. En effet, des composants tels que le MG90S sont disponibles en ligne pour des sommes très acceptables. Je pense à celles et ceux pour lesquels l’achat de deux moteurs PAS à PAS nettement plus onéreux commence à faire réfléchir. Aussi, cette approche m’a semblé plus abordable pour la majorité d’entres nous. Reste que m’en tenir à ces exemples engendrerait le manque d’un chapitre dans notre « bible du C++ ». C’est la raison pour laquelle deux projets un peu « costauds » viennent combler ce vide. Représenté sur la Fig.254 un dispositif constitué de deux motorisations cartésiennes peuvent recevoir sur la petite équerre 1 un module électronique de votre choix 2. Trois démonstrateurs CARDANS_A.ino, CARDANS_B.ino et CARDANS_C.ino sont disponibles dans le sous-dossier <! Petits PROJETS\Théodolite LASER et cinéthéodolite>. En particulier CARDANS_C.ino est assez amusant, car c’est un œil artificiel qui se dirige en permanence vers la source lumineuse locale la plus intense. Enfin, si vous désirez analyser un projet dans lequel figure une vraie stabilisation gyroscopique pour une petite plateforme expérimentale comportant divers capteur :
https://www.robot-maker.com/ouvrages/presentation-projet-robot-sonde-jekert/ (PUB !)

EXERCICE vraiment fastoche : En vous inspirant de Experience_132.ino et du logiciel sur la sonde JEKERT, réaliser la stabilisation gyroscopique de la petite équerre 2 sur la Fig.1 de la page 1 du tutoriel SHIELD_Adafruit_5.pdf reproduite ici pour rappel. S’est tout à fait élémentaire, et reste à votre portée, et vous allez voir que c’est bien plus simple que sur la sonde JEKERT car ici il n’y a que deux rotations à piloter au lieu de six servomoteurs et une géométrie pour le moins assez « scabreuse ».

Experience_133 : Stabilisation gyroscopique avec des moteurs PAS à PAS.

Naturellement il n’a jamais été question de vous laisser sans un démonstrateur « solution », et ce d’autant plus que pour frimer dans le chapitre EXERCICE j’affirme péremptoirement que c’est enfantin alors que dans la réalité le développement n’a rien d’élémentaire et m’a consommé plus de cinq heures de cogitations ! J’ai profité de ce dernier programme pour travailler avec des moteurs PAS à PAS et effectuer des mesures avec filtrage. Le logiciel à été simplifié au maximum, et l’axe de LACET a été oublié. Au départ le croquis intégrait l’affichage du tableau de bord sur OLED et les trois axes étaient pris en compte. Et puis j’ai renoncé car OLED plus le module MPU-6050 généraient sans cesse une collision entre la PILE et le TAS. Pour arriver à gagner assez de place, il aurait fallu y consacrer trop de temps et j’ai été paresseux, je vous prie de m’en excuser. Avec Experience_133.ino on en profite pour utiliser le mode VEILLE sur les moteurs, que l’on peut imposer ou suspendre à notre guise par un bouton poussoir branché sur D2. Sur la Fig.255 ainsi que sur Image 081.JPG et sur Image 082.JPG la plateforme H’H reste horizontale alors que le banc de test est incliné en ROULIS et en TANGAGE, et posé en biais sur une boite en carton C et une gomme G. Durant le fonctionnement, le logiciel rend compte sur le Moniteur de l’IDE. La copie d’écran de la Fig.256 présente les données qui sont affichées. En 1 le programme se présente et précise ce qu’il fait. En 2 la centrale inertielle est initialisée et mise en service. En 3 on constate que le fait d’éliminer l’affichage sur OLED libère une place considérable entre la PILE et le TAS ce qui tendrait à prouver que sa bibliothèque charge considérablement la zone des données dynamiques. Du coup il aurait été possible de proposer des textes moins abscons … mais j’ai eu un peu la flemme de tous les reprendre. Comme il ne s’agit pas d’une application mais juste d’un exercice, je m’autorise à « bâcler un peu l’aspect esthétique » ! Pour simplifier, le logiciel ne traite pas simultanément les deux axes, car je désirais que le listage soit facile à analyser. Aussi, en 4 le programme commence par stabiliser en ROULIS. Puis, Rls étant à zéro, il s’occupe alors du Tangage Tge en 5. En 6 on a libéré l’énergie sur les moteurs par commande du bouton de VEILLE. Le couple des moteurs étant alors nul, le roulis et le tangage ont un peu divergé. À la reprise en 7 les moteurs reprennent immédiatement du service et le ROULIS Rls est corrigé en premier pour retrouver l’horizontale. Sur la sonde JEKERT on peut à la fois stabiliser gyroscopiquement et avoir l’écran OLED, mais il y a deux microcontrôleurs et la motorisation étant à base de servomoteurs il n’y a pas besoin de la bibliothèque AFMotor.h.

La suite est ici.