3. Asservissement¶

Notre modèle étant maintenant connu et validé, il fallait mettre en place l’asservissement des deux galvanomètres. Le correcteur en structure RST est le plus adapté pour notre utilisation, aux vues de ses performances, puisque l’on a besoin que les galvanomètres se déplacent très rapidement (tdéplacement < 400µs) pour que l’opticien ne voit pas un scintillement des points du laser.

3.1. Structure du correcteur RST¶

Le correcteur en structure RST est intéressant puisqu’il est robuste et qu’il est à deux degrés de liberté. En effet, il est possible d’assurer des performances différentes en régulation et en poursuite. La structure générale d’un RST est la suivante. Sur ce schéma bloc sont repérés, en rouge les éléments du correcteur et en bleu la fonction de transfert du système avec le retard. Il faut savoir également que tous les éléments à l’intérieur des blocs sont des polynômes.

Figure 10 : structure générale d'un correcteur RST

La première étape pour calculer les coefficients des différents polynômes R, S et T est de discrétiser la fonction de transfert des galvanomètres. Cette opération se fait à partir d’une décomposition en éléments simples et d’un bloqueur d’ordre zéro avec un retard d’une période d’échantillonnage. On obtient à la fin une fonction de transfert en discret de la forme suivante :

Équation 3 : fonction de transfert discrète

Les coefficients des polynômes B et A sont données plus en détails sur le script Scilab modele_galvanometre_discret.

Pour la suite des calculs des coefficients des polynômes R et S, il est nécessaire de se référer au cahier des charges. Le dépassement accepté pour notre système est de D% = 0.01 et notre temps de réponse à 5% est de tr(5%) = 400µs. Cette dernière valeur correspond au temps de déplacement des galvanomètres avant stabilisation. A partir de ces informations, il est possible de définir les pôles de notre fonction cible en régulation grâce au tableau suivant.

Tableau 2 : modèle du 2nd ordre pour amortissement inférieur à 1

Ensuite, grâce à l’identité de Bézout donnée en équation 4, on peut définir les coefficients des polynômes R et S en résolvant le système matriciel (équation 5) où thêta est l’inconnue (coefficients R et S).

Équation 4 : identité de Bézout

Équation 5 : système matriciel pour le calcul des coefficients de R et S

Les matrices M et X sont données dans le script Scilab Bezout.sce et les étapes de calcul pour obtenir h1, h2, R et S sont dans le script nommé RST_general.sce.

Concernant le polynôme T, son expression est donnée par la formule suivante :

Équation 6 : polynôme T

Pour finir, il reste à définir le modèle en poursuite, c’est-à-dire les polynômes Am et Bm. Cette fonction de transfert cible en poursuite peut être choisi plus rapide que celle en régulation. Ici, les performances entre la régulation et la poursuite sont similaires et sont extraites du cahier des charges. Les coefficients des polynômes T, Am et Bm sont indiqués plus en détail sur le script Scilab RST_general.sce.

Il faut savoir également que le correcteur possède un adoucisseur d’ordre 3 qui est donné dans le script Adoucisseur.

Pour s’assurer que le correcteur en structure RST asservi bien le système comme on le souhaite, les simulations Scilab nécessaires sont nommées SimuRST_consigne_echelon.zcos et SimuRST_consigne_reelle.zcos. Avec l’utilisation de la première simulation qui réalise un essai avec un échelon en consigne d’une valeur de 10, on obtient le résultat suivant.

Figure 11 : essai en boucle fermée pour un échelon de 10

Sur cet essai, la position est bien centrée sur la valeur de la consigne et les oscillations que l’on voit sont dues à l’ajout d’un bruit qui est également présent sur le système réel.

3.2. Régulation RST embarquée¶

3.2.1. Validation¶

Après avoir défini les paramètres du correcteur à structure RST à partir du modèle en boucle ouverte, il est nécessaire de valider ce nouveau système à l’aide de son implémentation en simulation sur microprocesseur. Cette implémentation a été réalisée en langage C avec l’IDE CodeBlocks avant d’être cross-compilé. Retrouvez la structure du programme ainsi que la mise en place de la chaine de tests sur cible dans la note d’application suivante :

Pour réaliser les tests en simulation, nous comparons la courbe de réponse obtenue avec le logiciel Scilab (cf. note Jordan) ainsi que celle obtenue avec l’implémentation sur la cible (De0_Nano-SoC), à partir d’un essai de plusieurs échelons. Cet essai simule la commande d’un moteur galvanomètre pour la diffusion d’une ligne de cinq points. La fonction de transfert discrétisée de notre système, les coefficients polynomiaux des correcteurs RST, ainsi que les consignes sont fournies à l’aide de fichiers de commande comme décrit dans la note d’application. Notre programme de simulation renvoie quant à lui un fichier de points au format .csv décrivant la réponse simulée du système. Le tracé graphique est obtenu sous Scilab en concaténant les résultats obtenus.

Figure 12 : validation de l'asservissement en C

L’analyse graphique des résultats obtenus permet de valider le modèle implémenté en langage C ainsi que les paramètres du correcteur à structure RST. En effet, le cahier des charges fonctionnel défini d’une part un temps de montée de 400 µs (mesuré à 95% de la valeur finale). D’autre part, la précision requise est de 10 µm, cependant même si les courbes semblent très bien corréler, nous pouvons remarquer un léger décalage entre les deux courbes obtenues (rouge et noire). Cette légère imprécision d’ores-et-déjà présente en simulation est surement source d’une imprécision plus grande sur le système réel qui est bruité en raison notamment de la chaine de commande et lecture des positions des galvanomètres.

Afin de qualifier l’algorithme, comme décrit dans la note présentant la structure du programme, une fonction clock_gettime permet de mesurer au niveau du processus le temps d’exécution d’une boucle de régulation RST. Le programme peut également renvoyer ce temps mesuré par boucle dans le même fichier au format .csv que précédemment, ce qui facilite l’analyse à partir d’un tableur par exemple (moyennage, extremums, etc). Ainsi les temps d’exécution relevés sont les suivants :

Tableau 3 : temps d'exécution d'une boucle de régulation RST

Ces temps relèvent de l’exécution de la régulation RST effectuée à l’aide de calculs polynomiaux. La régulation numérique fait intervenir une quarantaine d’opérations, soit une vingtaine pour chaque moteur, dont quatre polynômes de degré cinq.

A savoir que la partie HPS (Hard Processor System) de la carte De0-Nano-SoC traite en parallèle le fonctionnement d’un noyau linux. Bien que le processeur Cortex-A9 possède deux cœurs, c’est l’OS qui contrôle la répartition de la charge des threads, et donc cela peut se traduire par un temps de boucle très supérieur. Ce phénomène se traduit lors de la diffusion de la matrice 5x5 par des perturbations.

De plus, si l’on se réfère aux études précédentes sur les temps de lecture et écriture des données entre la partie FPGA et les galvanomètres à l’aide des convertisseurs analogiques numériques, on en déduit que la période d’échantillonnage optimale se situe entre 8 et 9 µs. En effet, la période d’échantillonnage se doit d’être le plus proche possible d’un temps de cycle complet (lecture + exécution + écriture) [cf. partie période d’échantillonnage].

3.2.2. Mise en œuvre¶

Une fois le comportement du correcteur RST validé, nous avons mis en action les deux galvanomètres simultanément. Pour cela, nous avons utilisé 2 correcteurs RST (un pour chaque galvanomètre) dont les coefficients (R, S et T) ont été calculés en simulation sur Scilab. Au niveau de la gestion des données de position dans le programme de régulation sur la partie HPS, il a fallu prendre en compte le fait que les positions qui sont reçues et les commandes qui sont envoyées pour les deux galvanomètres sont concaténées dans un registre de 32 bits. Il a donc été nécessaire de séparer les données de positions (en utilisant un masque) avant d’effectuer les calculs des commandes et de les rassembler pour envoi (en utilisant des décalages et une concaténation) une fois les calculs terminés.

Le motif de 25 points que l’on a choisi de réaliser avait pour objectif de solliciter de manière équivalente les deux galvanomètres (voir figure suivante).

Figure 13 : Motif de 25 points

Etant donné, que les valeurs de position sont codées sur 14 bits, ces dernière peuvent donc aller de -8192 à +8191. Or nous verrons que le système, dans sa version actuelle, présente une erreur constante, ce qui signifie qu’il est difficile d’atteindre des positions aux limites de la zone visible par les convertisseurs Numérique-Analogique. (Voir figure 1 dans la partie I.2). C’est pour cela que nous avons choisi de prendre une marge sur les valeurs de consigne maximales et minimales.

Avec ces consignes, on peut alors écarter les points d’une distance d’environ 1 cm, ce qui est très proche des attentes du client.

De plus, le déplacement du laser entre chaque est rendu invisible en éteignant le laser lors de la phase transitoire (pendant 400µs) en utilisant la fonctionnalité d’allumage/extinction du laser présent sur le FPGA. (Bit 4 du Registre 1)

En réalisant ce motif de points, on obtient les courbes suivantes :

Figure 14 : Comparaison courbes réelles/simulation - Axe X

Figure 15 : Comparaison courbes réelles/simulation - Axe Y

Comme nous pouvons le voir, les courbes de notre système réel sont très proches de celles générées en simulation. On remarque cependant que pour certaines des consignes il a une erreur non négligeable qui ne semble pas venir du bruit présent sur les signaux. Pour corriger ce problème d’offset par rapport à la consigne, il pourrait être judicieux de modifier la valeur du « zéro » de la position ou encore d’ajouter aux consignes une valeur qui permettra d’effectuer l’étalonnage du retour des positions de notre système réel.

En projetant le motif sur une surface éloignée de 30 cm de la source, on obtient la matrice que l’on peut voir sur la figure 16. On remarque que l’erreur par rapport à la consigne mentionnée précédemment est visible sur l’image. Les points sur une ligne ne sont pas parfaitement alignés. Cependant, les 25 points de la matrice ne scintillent pas, c’est donc une partie du cahier des charges qui est validée.

Figure 16 : projection de la matrice de 25points avec le système

3.3. Limite du système¶

Une fois que nous sommes arrivés à afficher une matrice de 25 points sans scintillement, nous voulions définir les limites de notre système en jouant sur la période d’échantillonnage et en mesurant la précision.

3.3.1. Période d’échantillonnage¶

Le temps théorique supposé optimal pour la période d’échantillonnage est estimé entre 8 et 9 µs comme vu précédemment. En pratique, différents tests ont été réalisés pour visualiser l’impact de ce paramètre. Pour cela, le protocole mis en place consiste à tester les deux moteurs galvanomètres afin d’afficher la matrice de points, pour différentes périodes d’échantillonnage allant de 5µs à 50µs. La réponse du système réel est comparée à celle obtenue en simulation sous Scilab.

Figure 17 : Test en boucle fermée pour Te=8us – Axe X

Figure 18 : Test en boucle fermée pour Te=8us – Axe Y

Figure 19 : test en boucle fermée pour Te=15us

Ainsi, les essais réalisés montrent que pour une période d’échantillonnage strictement inférieure à 8µs, la matrice ne présente pas de stabilité. De même lorsque la période excède 15µs. Donc la valeur optimale est bornée entre 8 et 15µs, tout en sachant qu’au-delà de 8µs, plus la période est grande, plus notre système perd en précision. En conclusion, ces essais confirment la valeur de 8µs en ce qui concerne la période d’échantillonnage optimale dans l’état actuel. Cette valeur peut être affinée en réalisant des essais entre 8 et 9µs par pas de 0,1.

D’autre part, une piste d’amélioration de la précision repose sur la réduction du temps de cycle de régulation afin de réduire la période d’échantillonnage sans lire de mauvaises valeurs en provenance du convertisseur analogique numérique. Le goulot d’étranglement d’un cycle de régulation se situe au niveau du temps d’exécution de la régulation numérique. Une piste qui reste à étudier est donc l’optimisation de ce code avec notamment la mise en fonctionnement des calculs en virgule fixe.

3.3.2. Précision du système¶

Afin de déterminer la précision de notre système, nous avons réalisé des tests en boucle fermée en utilisant une période de 8µs et des consignes volontairement longues (4ms) pour avoir une zone de stabilisation suffisamment importante. Nous avons également mis en concurrence le correcteur PID et RST afin de comparer les performances de l’un par rapport à l’autre.

Figure 20 : Test performances (Régulation PID & RST)

Comme nous pouvons le voir sur les courbes ci-dessus, le temps de réponse du système utilisant les correcteurs RST est deux fois plus rapide que celui qui utilise les correcteurs PID.

En zoomant sur la partie stable des courbes, on observe également que l’erreur par rapport à la consigne est plus grande avec notre correcteur RST (328µm) qu’avec le PID (208µm). Cependant, si on considère que l’erreur par rapport à la consigne est constante, et que l’on ne regarde que la variation de la position, on s’aperçoit que l’erreur n’est que d’environ 100µm avec un correcteur PID et d’environ 115µm avec un correcteur RST. Cette précision ne permet pas de respecter le cahier des charges mais celle-ci pourrait être améliorée en modifiant les adoucisseurs qui interviennent sur la commande.

<-- 2. Identification du modèle des galvanomètres

Conclusion -->