Le but de cette partie est de poser le cadre conceptuel permettant d’aborder le contrôle-commande du dirigeable, ainsi que d’expliciter ce qui a été fait au S4.

La discipline s’occupant de ce type de problème s’appelle l’automatique des systèmes, c’est pourquoi nous tenterons d’utiliser son vocabulaire.

Nous nous sommes beaucoup appuyé sur le mémoire de Elyes Haouas « Modélisation et commande d’un dirigeable gros porteur dédié au transport de matières premières » soutenu le 23 novembre 2018, dont nous pouvons recommander la lecture des pages 54 à 74.

Pour toute question, s'adresser à Tristan Malleville, Georges Taaoum ou Yuxin Fu

I. Position du problème

Un dirigeable est un aéronef qui peut être approximativement considéré comme un objet rigide contrôlé en 3 dimensions. Le paramétrage de son mouvement se fait par rapport à un repère R0, considéré comme fixe, et selon 6 coordonnées :

- x et y, pour la position dans le plan

- z, l’opposé de l’altitude

- φ : l’angle de roulis, correspondant à une rotation autour de l’axe x

- θ : l’angle de tangage, correspondant à une rotation autour de l’axe y

- ψ : l’angle de lacet, correspondant à une rotation autour de l’axe z

On utilise donc les angles d’Euler ; plus précisément, on considère que l’orientation du dirigeable se fait d’abord par une rotation autour de l’axe z, puis par une rotation autour du nouvel axe y’, puis par une rotation autour du nouvel axe x’’. On prendra garde que lorsque l’on écrira matriciellement (ou avec des quaternions) les rotations, il faudra prendre l’ordre inverse pour les matrices de passage (voir équation 2.3 et 2.5 du mémoire, p.56-57). Il faut également noter que les rotations ne commutent pas. Ces coordonnées dans R0 sont notées X1 dans le code de simulation.

Ces angles et ces coordonnées ont des dérivées temporelles, on est donc face à un système à 12 états du point de vue l’automatique des systèmes.

Il est fortement utile d’introduire les vitesses (y compris les vitesses angulaires) exprimées dans le repère mobile de l’appareil (attention, on parle bien de repère et pas de référentiel), noté Rm. Ce repère est donné sur la figure : l’axe x va de l’avant vers l’arrière, l’axe y de babord vers tribord, et l’axe z du haut vers le bas. Initialement, à φ = θ = ψ = 0, Rm et R0 sont confondus. Dans le mémoire et dans le code, ces vitesses sont dans un vecteur à 6 composantes, X2 (u,v,w,p,q,r). On prendra garde que X1 et X2 ne sont pas homogènes : l’un est une position et l’autre une vitesse (au sens large). On a alors vraiment autour des axes x,y,z les roulis, tangage et lacet à proprement parler. C’est dans ce repère que l’on fera le calcul de la dynamique.

L’utilisateur, via la télécommande, peut donner une commande virtuelle à 4 coordonnées : il paraît raisonnable de choisir les vitesse u et w désirées, et les vitesses angulaires q et r désirées, exprimées dans le repère Rm.

Cette commande virtuelle est transcrite (auprès des actionneurs par l’Arduino) en commande réelle à 6 coordonnées. On a ainsi :

- les moteurs babord et tribord, fournissant des poussées Fmg et Fmd. (mg comme moteur gauche, md comme moteur droite)

- l’angle α des moteurs : les moteurs se trouvent sur un axe transverse (selon y) donc l’angle avec l’horitontale est commandé par un servomoteur. La force du moteur babord projetée selon l’axe z est par exemple -Fmb*sin(α).

- les angles βg et βd des servogouvernes babord et tribord, qui ont une influence sur le Cx et le Cz des gouvernes. Les polaires ont été calculées par Antoine. On a alors par exemple pour la gouverne babord, selon x, une force -0.5*ρ*Cx(βg)*v² approximativement au centre de la gouverne, avec ρ la densité de l’air et v la vitesse du centre de la gouverne.

- L’angle βb de la servogouverne du bas, dont l’influence s’écrit similairement à celle des autres servogouvernes.

Les commandes dépendent également de la position des actionneurs (pour les moments surtout, et pour les vitesses au centre des gouvernes), qu’il faut renseigner.

On notera que pour une gouverne, la commande dépend de la vitesse de l’air en son centre. Cela oblige à voler sans vent, faute d’avoir un anémomètre placé en chaque point utile de l’appareil : la vitesse de l’air est alors l’opposé de la vitesse de la gouverne relativement au référentiel fixe R0.

On constate ainsi que les équations gouvernant l’appareil sont a priori non linéaires. Les 6 équations gouvernant le mouvement sont données p.69 du mémoire :

Quelques commentaires :

- On se place dans le repère mobile (mais les calculs ont été faits dans le référentiel galiléen), et on fait un calcul sur X2.

- La matrice des masses représentent à la fois l’inertie de l’appareil et son inertie due à son déplacement dans un fluide (voir p.60). L’hypothèse est faite que celle-ci ne dépend pas de l’accélération. Certains coefficients viennent du fait que le centre du repère n’est pas G, le centre de masse, mais un point de référence géométrique a priori quelconque, noté R.

- Le vecteur des forces et moments aérodynamiques de l’appareil peut en première approximation être calculé grâce aux Cx, Cy et Cz de quelques points de l’appareil. Néanmoins, ce terme est inconnu en cas de vent, faute d’anémomètre (qui de toute façon aurait été placé dans la nacelle). Ce terme oblige, pour le contrôle, à naviguer sans vent.

- Le vecteur dynamique est un terme d’inertie dû au fait que l’on n’est a priori pas au centre de masse.

- Le vecteur de poids et de poussée d’Archimède dépend de X1 (des angles d’Euler en particulier), car la gravité est selon l’axe z du repère fixe.

- Notre commande se trouve dans les termes U1 à U6, obtenues en projetant les forces et moments dûs aux actionneurs, qui ont été données plus haut.

I. Choix du type d’asservissement

Lors du choix des accéléromètres, nous avons dû nous demander quel type de contrôle que nous allions faire, et ce que nous en attendions ; ce sont en effet les premières questions que le CAS nous a posé lorsque nous avons sollicité leur expertise.

Pour réaliser un asservissement, il faut connaître la valeur de la variable que l’on veut asservir. Un accéléromètre 6 axes est intégré à l’arduino.

Pour la vitesse, nous ne disposons que de la valeur de la dérivée de la vitesse, l’accélération. Cela signifie qu’il faut intégrer l’accélération. Le problème est que cette accélération est bruitée. Le CAS nous a assuré qu’une une intégration du type v += a*dt allait être rapidement trop mauvaise. Habituellement, on utilise du filtrage avec par exemple un filtre de Kalmann pour contourner le problème ; néanmoins, cela suppose de bien connaître la dynamique du système ; celle-ci est cependant d’une part non linéaire, et d’autre part a priori inconnue faute de connaître le torseur aérodynamique. Il paraît donc à ce stade impossible d’asservir le système en vitesse. Une discussion avec le CAS pourra être réalisée afin de voir s’il n’y a pas d’autres méthodes de filtrage ne demandant pas de connaître la dynamique du système, mais elles risquent de toute façon de manquer de précision.

Pour l’orientation, nous connaissons les vitesses angulaires ; la problématique est donc identique à celles des vitesses : il sera difficile d’asservir les angles du systèmes. Un asservissement en vitesse angulaire est à la limite possible, bien qu’il faille bien réfléchir aux gains ; cela néanmoins semble peu pertinent.

Le choix a donc été fait de réaliser un contrôle en boucle ouverte, en estimant que pour de la navigation à vue, le retour de l’utilisateur serait suffisant. Le CAS nous a fait la remarque que pour des systèmes similaires, c’était le contrôle en boucle ouverte qui avait été choisi, en donnant l’exemple des requins à l’hélium : https://youtu.be/eBIcmCO1FdU .

Il n’a pas été mené de réflexion en profondeur sur la façon de contrôler le système, néanmoins on peut faire les quelques remarques suivantes en première analyse, et en négligeant les portances longitudinales :

- Le contrôle en vitesse selon x se fait principalement grâce à la somme des forces des moteurs ; les termes de Cx des gouvernes sont plutôt des termes indésirables

- Le contrôle en vitesse selon z, utile pour le décollage et la stabilisation de l’altitude en vol se fait principalement en redirigeant la somme des forces des moteurs vers l’axe z, via le contrôle de l’angle α des moteurs

- La vitesse en y n’est pas intéressante à contrôler ; le Cz (ou plutôt Cy ici) de la gouverne du bas semble néanmoins être le terme dominant.

- Le lacet se contrôle principalement par le différentiel de force des moteurs, le différentiel de Cx des gouvernes arrière et le Cz (ou plutôt Cy ici) de la gouverne du bas étant encore une fois plutôt des termes indésirables.

- Le roulis se contrôle principalement par le différentiel de Cz des gouvernes babord et tribord, ainsi que le Cz (ou plutôt Cy ici) de la gouverne du bas. Il faut faire attention qu’à alpha non nul, le différentiel de force des moteurs peut devenir prédominant.

- Le tangage se contrôle principalement par la somme des Cz des gouvernes babord et tribord. Il faut faire attention que la somme des vitesses des moteurs peut augmenter le tangage, selon leur bras de levier.

II. Commentaires sur la simulation 3D

Afin de permettre de tester si le modèle de commande est bon, il a été choisi de réaliser un programme permettant de contrôler le dirigeable en temps réel. Le plus simple a semblé être de l’écrire depuis zéro ; les simulateurs de vol sont en effet le plus souvent mal adapté aux dirigeables (qui sont des aéronefs assez peu fréquents), et prendre en main un outil totalement configurable tel que jsb simulator (http://jsbsim.sourceforge.net/JSBSimReferenceManual.pdf ) ou Gazebo (http://gazebosim.org/) nous a paru plus compliqué que de vérifier par nous même que notre modèle dynamique fonctionnait en écrivant un script python, ce qui nous permettait également de mieux comprendre la dynamique de l’objet.

Concernant le rendu 3D, il a été choisi d’utiliser Ratcave en python (https://ratcave.readthedocs.io/en/latest/) ; cette bibliothèque a en effet l’avantage d’être extrêmement simple d’utilisation : il suffit d’importer un .obj et de l’afficher. Elle souffre un peu néanmoins de sa simplicité, et la documentation est assez pauvre. La gestion des rotations a été un pensum, et il a fallu plusieurs heures de réflexion pour arriver à un résultat satisfaisant, en utilisant notamment des quaternions. Le problème en effet est que les axes du repère qu’utilise Ratcave sont tournés de 90° par rapport à ceux utilisés dans le repère R0 du mémoire (l’axe z vient vers nous au lieu d’être vers le bas). À cela se rajoute le fait que le .obj utilisé est initialement tourné, puisque le logiciel de CAO met l’axe z vers le haut. Si Ratcave utilise un système de rotation similaire à celui du mémoire, c’est-à-dire les angles d’Euler à axes mobiles, seul le recours aux quaternions – d’utilisation assez simple via la bibliothèque pyquaternions - a permis de résoudre de façon satisfaisante le problème de la composition des rotations. Il pourra être envisagé à l’avenir d’importer un environnement 3D en .obj à des fins esthétiques, cependant cela semble inutile pour le pur contrôle commande. Enfin, le dirigeable pourra être texturé en ré-exportant le .obj depuis Fusion 365 et en gardant le .mtl.

La bibliothèque pyglet gère d’autre part le temps réel, c’est-à-dire les tâches en parallèle. L’utilisation se fait principalement en écrivant une fonction prenant en argument dt et en écrivant pyglet.clock.schedule(fonction). Le contrôle des entrées clavier est également assez facile, les autres fonctions nécessaires au fonctionnement ayant été trouvées dans le tutoriel de ratcave.

III. Commentaires sur le code de modélisation

Concernant le modèle dynamique, il consiste principalement en l’application des équations du mémoire. On définit les matrices d’Euler et la matrice permettant de changer de repère les vitesses angulaires, afin d’obtenir une relation du type d/dt(X1) = R(X1)*X2, ce qui permet d’obtenir les coordonnées dans le référentiel fixe (les trois dernières composantes de X1), ce qui est nécessaire pour calculer le torseur résultant de la poussée d’archimède et du poids. Les autres torseurs ne nécessitent que X2 a priori et la commande sur les moteurs. On intègre ensuite les équations avec odeint.

Faute d’avoir les paramètres physiques pertinents (matrice de masse, position des moteurs et des gouvernes, etc.), que l’on peut obtenir par la CAO, nous n’avons pas pu ajouter le poids. La simulation est assez rapide, ce qui laisse espérer la possibilité d’avoir une simulation en temps réel après avoir permis à l’utilisateur de rentrer la commande virtuelle au clavier, qui sera passée dans le contrôleur puis injectée dans le modèle physique.