MISE EN ŒUVRE D’UN SYSTEME

DE CONTROLE DE BARRE

FRANCHE

Synthèse et mise en œuvre des systèmes.

Rapport Final.

Alirio ARIZA MENDEZ

Mario EL HAYEK

Master 2. Electrique Electronique Automatique

Systèmes et Microsystèmes Embarqués

Université Toulouse III Paul Sabatier

15/12/2017

Table de matières

1. Introduction ............................................................................................................ 1

2. Exigences et contexte ........................................................................................... 2

3. Conception générale ........................................................................................... 3

4. Développement matériel ..................................................................................... 4

4.1 Circuit de gestion de boussole. .................................................................... 4

4.2 Circuit de transmission NMEA RS232. ........................................................... 6

4.3 Circuit de réception NMEA RS232. ............................................................... 8

4.4 Mise en œuvre des interfaces Avalon. ......................................................10

4.5 Intégration du SOPC. ...................................................................................12

5. Développement logiciel .....................................................................................13

5.1 Architecture Développée. ..........................................................................13

5.2 Algorithme implémenté. ..............................................................................14

6. Résultats obtenus .................................................................................................17

6.1 Vérification du circuit de gestion de boussole .........................................17

6.2 Vérification du circuit de gestion de réception NMEA ...........................18

6.3 Vérification du circuit de gestion de transmission NMEA .......................19

6.4 Validation du système. ................................................................................19

7. Conclusions ...........................................................................................................20

1

1. INTRODUCTION

En général, le cycle de vie d’un système part d’un besoin donné. C’est ainsi que la définition

des éléments (technologies, techniques, méthodologies) qui devraient constituer ce

système, devient un enjeu essentiel dans l’étape de conception. Dans le cadre de la

formation en Master de Systèmes et Microsystèmes Embarqués, un bureau d’étude a été

organisé avec l’objectif de mettre en œuvre une solution logicielle/matérielle qui répond

au besoin de gestion et contrôle de trajectoire d’un voilier de barre franche.

La procédure abordée contient une première étape dans laquelle les besoins et le contexte

ont étés analysés pour identifier les différentes interfaces du système. Ensuite, dans l’étape

de conception le système a été décomposé en un ensemble de blocs fonctionnels. Le

développement a été réalisé en deux sous-étapes : une partie matérielle qui intègre les

circuits d’acquisition, communication et commande. Dans cette partie, trois modules ont

été conçus et implémentés en utilisant le langage de description de matériel VHDL. La

deuxième sous-étape correspond à une partie logicielle sur un processeur qui gère

l’algorithme de contrôle de trajectoire.

L’intégration des différents modules a été effectuée en utilisant les outils de développement

de systèmes sur puce programmable d’Altera sur une carte DE0 NANO. Un ensemble de

tests unitaires ont été réalisés pour vérifier le bon fonctionnement de chaque module intégré

et finalement, le système a été validé sur une maquette de simulation.

Dans ce document, les différentes étapes de développement seront expliquées ainsi que

les résultats obtenus. Finalement, l’ensemble des difficultés rencontrées et des possibles

améliorations, ainsi que les conclusions du projet seront exposées dans le dernier chapitre.

2

2. EXIGENCES ET CONTEXTE

La mission principale du système demandé est de fournir un contrôle de trajectoire d’un

voilier en deux modes de fonctionnement possibles (automatique et manuel). Le réglage

de la direction est réalisé en faisant varier l’angle de la barre franche qui est commandé

par un moteur DC. Le système doit être capable de récupérer les informations de trajectoire

réelle (fournit par une boussole), position de la barre (fournit par un potentiomètre au travers

un signal de tension analogique), mode de fonctionnement et trajectoire de consigne

(fournis par une interface de boutons poussoirs). Le système doit disposer aussi d’une

interface de communication NMEA sur un standard RS232 pour récupérer la trajectoire

réelle d’un GPS et transmettre la position de la barre.

La figure 1 explique le contexte du système réalisé. L’interface de boutons poussoirs contient

aussi un ensemble de diodes LED pour l’affichage de certains informations ainsi qu’un haut-

parleur. Les diodes LED et du haut-parleur sont gérés par un circuit matériel décrit

auparavant en langage VHDL et donc son fonctionnement n’est pas expliqué à profondeur

dans ce document.

Figure 1. Diagramme de contexte du système réalisé.

D’ailleurs, il a été demandé de développer des modules matériels sur une FPGA (field-

programmable gate array) DE0 - NANO pour la gestion des éléments externes et d’intégrer

ces modules dans un système sur puce programmable (SOPC) avec un processeur NIOS II

sur lequel un logiciel de contrôle de trajectoire doit être exécuté. Cette architecture sera

expliquée dans le chapitre 3 tandis que la procédure suivi pour le développement et

intégration matérielle/logiciel sera détaillée dans les chapitres 4 et 5.

Nous remarquons en avance que parmi les différents modules matériels, nous avons

effectué la conception et l’implémentation des modules de gestion de communication

NMEA sur RS232 et d’acquisition de cap réel fournit par la boussole. Les autres circuits

intégrés (gestion de vérin et gestion d’IHM) correspondent à des circuits déjà existants.

3

3. CONCEPTION GENERALE

Pour la mise en œuvre, le système a été décomposé en 6 blocs fonctionnels bien définis. La

figure 2 montre le diagramme fonctionnel du système dont les 5 blocs en couleur vert

correspondent aux fonctionnalités gérées par des circuits combinatoires et séquentiels

implémentés sur une FPGA en utilisant le langage de description de matériel VHDL.

Figure 2. Diagramme fonctionnel du système.

Parmi les circuits périphériques intégrés au système, nous avons fait la conception et

l’implémentation de ceux correspondants à la gestion de transmission et réception NMEA

sur RS232 et la gestion de boussole. Les circuits de transmission et réception permettent

d’envoyer et de recevoir respectivement des trames de données composées par un

caractère ascii d’identification ou synchronisation suivi de 3 chiffres également codifiées en

code ascii sur un canal série avec un débit de 4800 bauds. Le circuit de gestion de boussole

est chargé de mesurer et d’envoyer la valeur de l’angle d’orientation fourni par une

boussole à partir d’un signal PWM dont le rapport cyclique dépend de l’angle. Le

fonctionnement des 3 circuits est détaillé dans les chapitres 4.1, 4.2 et 4.3.

Les circuits de gestion de vérin et de boutons poussoirs ont été intégrés à partir des codes

de description en VHDL déjà existants.

L’échange d’information entre le processeur et les circuits matériels est possible grâce à

l’interface Avalon. Cette interface simplifie l’intégration du système en permettant de

connecter facilement les différents composants avec le processeur. L’utilisation de

l’interface sera détaillée dans le chapitre 4.4.

4

4. DEVELOPPEMENT MATERIEL

Pour la mise en œuvre des circuits combinatoires et séquentiels, une analyse

comportementale de chaque circuit a été réalisée afin de le découper en composants

fonctionnels et d’identifier les signaux d’interconnexion entre chaque composant. Ensuite,

le comportement de chaque composant a été décrit en utilisant une approche de

machine à état.

Chaque composant a été implémenté en utilisant le langage VHDL sur Quartus, un

environnement pour l'analyse et la synthèse de designs matériels, permettant de compiler

les designs, d'effectuer des analyses temporelles, d'examiner les diagrammes RTL, de simuler

le comportement d’un circuit et de configurer le dispositif cible avec le programmeur.

Finalement les différents composants de chaque circuit ont été intégrés en utilisant

l’instanciation de « components » dans un fichier VHDL de haut niveau.

4.1 Circuit de gestion de boussole.

Le circuit de gestion de boussole permet d’acquérir l’angle d’orientation mesuré par une

boussole électronique CMPS03. La boussole fournit un signal PWM dont le rapport cyclique

est fonction de l’angle d’orientation et peut être exprimé avec l’équation suivante :

𝑎𝑛𝑔𝑙𝑒[°] = (𝑑𝑢𝑡𝑦[𝑚𝑠] ∗ 10) − 10

Par exemple, pour un rapport cyclique de 19ms l’angle d’orientation est 180°.

Le circuit doit fonctionner en deux modes possibles : continu lorsque l’entrée « continu » est

mise à 1, et mono-coup dans le cas contraire. Dans le mode continu, le circuit fait une

acquisition toutes les secondes alors que dans le mode mono-coup, un front montant sur

l’entrée « start_stop » est nécessaire pour démarrer une acquisition. En mode mono-coup,

une sortie « data_valide » est mise à 1 lorsque le calcul est terminée. « data_valide » revient

à 0 lorsque l’entrée « start_stop » est remise à zéro.

La figure 3 montre le diagramme fonctionnel du module d’acquisition de Cap. Le circuit est

composé de 3 composants chargés d’un ensemble de fonctionnes.

Figure 3. Diagramme fonctionnel du circuit de gestion de boussole.

5

Le composant « clock management » fournis deux horloges avec des fréquences de 1Hz et

10KHz. L’horloge de 1Hz est utilisée pour démarrer les acquisitions lorsque le circuit est en

mode continu et l’horloge de 10KHz est utilisée comme signal de sensibilisation des

processus dans les autres deux composants. Cette horloge de 10KHz permet de mesurer des

rapports cycliques du signal PWM avec une sensibilité de 0.1ms, c’est-à-dire 1°. Les horloges

sont générées à partir de diviseurs de fréquences sur l’horloge d’entrée de 50MHz.

Le deuxième composant « Mode Management » est chargé de gérer le mode de

fonctionnement du circuit et de déclencher une nouvelle acquisition lorsque les conditions

nécessaires sont vérifiées. Le fonctionnement de ce composant est expliqué par la machine

à états de la figure 4. Les conditions de chaque transition sont résumées dans le tableau 1.

Figure 4. Machine à états du composant Mode Management.

Tableau 1. Conditions de transition du composant Mode Management.

Le composant angle calcul est chargé de calculer l’angle en utilisant un compteur qui

s’incrémente tous les 0.1ms (1°) pendant toute la durée d’un niveau haut du signal PWM. La

machine à états de la figure 5 explique le fonctionnement du bloc « Angle Calcul ». La

machine, initialement dans l’état SUSPENDED, entre dans l’état READY si le composant

« Mode Management » met le signal « enable » à 1. Une transition de l’état READY vers l’état

INIT est effectuée lorsque le niveau du signal PWM est bas et ensuite la transition vers l’état

TICK_CNT est réalisée quand le signal PWM est dans le niveau haut. Cela permet de garantir

6

que le comptage démarre uniquement sur les fronts montants du signal PWM. Dans l’état

TICK_CNT, le comptage est réalisé et dans l’état ENDED qui représente la fin de l’acquisition,

l’offset de 10° est enlevé du résultat.

Figure 5. Machine à états du composant Angle Calcul.

Tableau 2. Transitions du composant Angle Calcul.

4.2 Circuit de transmission NMEA RS232.

Ce circuit permet la transmission de trames sur un canal UART avec un débit de 4800 bauds,

1 bit de stop et sans bit de parité. Si un signal d’entrée « start_stop » est mise à 1, le circuit

fait la transmission toutes les secondes des trames composées de 4 caractères fixées à partir

des entrées S, C, D et U.

Le fonctionnement du circuit a été décomposé en 2 modules ou composants montrées

dans la figure 6.

Figure 6. Diagramme fonctionnel du circuit de transmission.

7

Le composant « Clk Management » fournit deux horloges avec des fréquences de 1Hz (Pour

déclencher des transmissions) et 4800Hz (qui permet le débit de 4800 bauds). Les horloges

sont générées à partir de diviseurs de fréquence sur l’horloge principale de 50MHz.

Le composant « Tx Management » contient un registre à décalage fait la conversion

parallèle/série des données pour réaliser les transmissions lorsque les conditionnes

nécessaires sont vérifiées. Le fonctionnement du bloc « Tx Management » est expliqué par

la machine à états de la figure 7. Le signal de sortie « Fin_Tx » est mise à 1 si la machine est

dans l’état END_TX ou WAITING. Sinon la valeur de cette sortie est 0.

Figure 7. Machine à états du composant TX Management.

Tableau 3. Conditions de transition du composant Tx Management.

8

4.3 Circuit de réception NMEA RS232.

Le circuit de réception NMEA permet de recevoir des trames de données en 2 modes

possibles : continu lorsque l’entrée « mode » est mise à 1, et mono-coup dans le cas

contraire. Dans le mode continu, le circuit fait des acquisitions constantes alors que dans le

mode mono-coup, un front montant sur l’entrée « start_stop » est nécessaire pour démarrer

une réception. En mode mono-coup, une sortie « data_valide » est mise à 1 lorsque la

réception est terminée. « data_valide » revient à 0 lorsque l’entrée « start_stop » est remise à

zéro. Les trames reçues sont formées par 4 caractères ascii (S, C, D, U).

La décomposition fonctionnelle implémentée pour le circuit de réception est montrée dans

la figure 8.

Figure 8. Diagramme fonctionnel du circuit de réception.

Le composant « Clk Management » fournit deux horloges avec des fréquences de 4800Hz

(qui permet le débit de 4800 bauds) et 76,8KHz (qui gère le fonctionnement du composant

Synchronisation). Les horloges sont générées à partir de diviseurs de fréquence sur l’horloge

principale de 50MHz.

D’ailleurs, l’horloge de 4800Hz est réinitialisée lorsqu’un bit de START est détecté par le

composant « Synchronisation » sur l’entrée Rx. Cela garantit la synchronisation entre le

module de réception le signal reçu puisque les fronts montants de l’horloge de 4800Hz se

placeront toujours au milieu de chaque bit reçu.

Le composant « Synchronisation » est chargée aussi de gérer le mode de fonctionnement

et démarrer une lecture de message si les conditions nécessaires sont vérifiées. La machine

à états de la figure 9 explique le fonctionnement du bloc « Synchronisation ».

Figure 9. Machine à états du composant Synchronisation.

9

Tableau 4. Conditions de transition du composant Synchronisation.

Le composant « Rx Management » correspond à un registre à décalage qui permet la

conversion série/parallèle du message reçu. Le fonctionnement de ce composant est décrit

par la machine à états de la figure 10. Si la valeur du premier caractère reçu ne correspond

pas à la valeur fixée dans l’entrée « S_Ctrl » du circuit, la machine entre dans l’état ERR_RX

qui représente une erreur du caractère de début de trame et ensuit revient à l’état WAITING

sans mettre à 1 la sortie « data_valide ».

Figure 10. Machine à états du composant Rx Management.

Tableau 5. Conditions de transition du composant Rx Management.

10

4.4 Mise en œuvre des interfaces Avalon.

L’interface Avalon correspond à un bus de communication intégré dans les FPGA d’Altera

qui permet l’interconnexion entre le processeur NIOS II et les circuits périphériques

embarqués dans le FPGA comme montré dans la figure 11. Le bus Avalon est intégré et

gérée par l’outil SOPC Builder de Quartus lors de la génération d’un système sur puce.

Figure 11. Interconnexion processeur/circuit esclave via le bus Avalon.

Cependant, pour mettre en œuvre cette interconnexion, il a été nécessaire d’implémenter

des interfaces entre le bus Avalon et chaque circuit matériel développé. Ces interfaces

correspondent à des circuits combinatoires et séquentiels qui permettent de lire et d’écrire

sur quelques entrées/sorties de chaque circuit périphérique selon les signaux de contrôle du

bus (chip select, write_n, addresse). La figure 12 montre l’interaction entre les interfaces

ajoutées et les différents circuits périphériques implémentés auparavant.

Figure 12. Interfaces Avalon implémentées pour chaque circuit périphérique.

A mode d’exemple, les figures 13 et 14 montrent les circuits implémentés pour interfacer les

circuits d’acquisition de cap et réception NMEA respectivement. Le circuit d’interface

implémenté pour la transmission NMEA n’est pas montré dans ce document étant donnée

sa taille. Egalement le tableau 6 montre les registres de l’interface Avalon associés aux

différents ports de chaque circuit périphérique.

11

Figure 13. Circuit d'interface Avalon/Compass.

Figure 14. Circuit d'interface Avalon/NMEA_Rx

Circuit Registre adresse type Bits concernés

Gestion de

Transmission

NMEA

config 0 R/W

b2=fin_transmit, b1=Start/Stop,

b0=raz_n

synchro 1 (4) R/W b7...b0=code ASCII carac. synchro

centaine 2 (8) R/W b7...b0=code ASCII centaine

dizaine 3 (12) R/W b7...b0=code ASCII dizaine

unité 4 (16) R/W b7...b0=code ASCII unité

Gestion de

Réception NMEA

config 0 R/W b2=mode, b1=Start/Stop, b0=raz_n

synchro 1 (4) R/W b7...b0=code ASCII carac. synchro

centaine 2 (8) R/W b7...b0=code ASCII centaine

dizaine 3 (12) R/W b7...b0=code ASCII dizaine

unité 4 (16) R/W b7...b0=code ASCII unité

Gestion de

Boussole

config 0 R/W b2=Start/Stop, b1=continu, b0=raz_n

compass 1 (4) R/W b9=valid, b8...b0= data_compas

Figure 15. Registres de l’interface Avalon associés à chaque périphérique.

12

4.5 Intégration du SOPC.

Après l’implémentation des circuits périphériques, il était nécessaire de les intégrer dans un

système qui regroupe les fonctionnalités exigées. Cette intégration est réalisée en utilisant

l’outil SOPC Builder (System On Programmable Chip Builder) de Quartus qui permet de

générer automatiquement des systèmes sur puce en connectant des composants

logiciel/matériel.

Dans le système généré nous avons intégré les circuits périphériques et un ensemble de

composants fournis par la bibliothèque de SOPC Builder. Les composants ajoutés sont

montrés dans la figure 16. Nous avons ajouté un processeur NIOS II de 32 bits qui exécutera

le logiciel de contrôle de trajectoire, une mémoire (sram) de 20Ko et un composant JTAG

qui fournit une interface entre le SOPC et l’environnement NIOS II pour réaliser la

programmation et le débogage de logiciel. Un périphérique d’identification du système a

été aussi intégré.

Figure 16. Composants ajoutés dans le SOPC.

Le résultat de la génération du SOPC est un ensemble de fichiers VHDL qui décrivent le

circuit du système généré. La figure 17 montre le SOPC en vue de boite noire.

Figure 17. Ports du SOPC généré.

13

5. DEVELOPPEMENT LOGICIEL

Altera fournit l’environnement de programmation, compilation et débogage NIOS II pour

l’implémentation de logiciel sur des processeurs intégrés dans les FPGA. L’environnement

contient un outil de création d’application et paquet de support de matériel (Application

and board support package) qui a été utilisé pour rédiger le code de contrôle et pour

générer une bibliothèque (fichier .h) qui définit les différents registres de lecture/écriture du

SOPC cible.

5.1 Architecture Développée.

Le diagramme de blocs de la figure 18 explique l’architecture définie pour le logiciel

implémenté. L’objet « contrôle trajectoire » est implémenté dans un fichier .c qui contient la

fonction principale du logiciel. Ce bloc est composé d’un ensemble de blocs qui gèrent les

différents périphériques en fournissant des fonctions de configuration, lecture et écriture.

Chaque bloc de gestion de périphérique est implémenté dans un fichier .c et un fichier .h.

La fonction principale de contrôle de trajectoire fait appel aux fonctionnalités fournis par

les blocs périphériques.

Figure 18. Diagramme de blocs du logiciel de contrôle de trajectoire.

14

5.2 Algorithme implémenté.

Le diagramme de flux de la figure 19 représente l’algorithme de la fonction principale

(main).

Figure 19. Diagramme de flux de la fonction main.

L’initialisation de différents modules de gestion de périphériques (boutons, vérin, compass,

UART) et des différents paramètres du logiciel (Cap de consigne, dernier code de fonction

reçu par le périphérique des boutons, Constante proportionnelle du contrôleur, et compteur

de 100ms) est effectuée en un premier lieu.

Après les initialisations, l’algorithme entre dans une boucle infinie qui comporte l’acquisition

du cap réel selon le mode de test de validation (niveau 1 dans lequel le cap réel est

déterminé avec les données de la boussole, ou niveau 2 dans lequel le cap réel est reçu

d’un GPS via RS232).

Le mode de test de validation est géré par la définition d’une macro (#define

MODE_TEST_PC) ; si la macro est définie le logiciel exécute le mode niveau 2, sinon il exécute

le mode niveau 1. La procédure implémentée pour l’acquisition est montrée dans le

diagramme de flux de la figure 20.

15

Figure 20. Algorithme d'acquisition du cap réel.

Après la lecture du cap réel, le logiciel fait une mise à jour du code de fonctionnement en

réalisant une lecture de la fonction get_func_code du module boutons. D’après le code

retourné par la fonction une action est exécutée. Le tableau 6 explique les différentes

actions selon le code.

Code fonction Description du code

0 Pas d'action, le pilote est en veille.

1 Mode manuel action vérin bâbord.

2 Mode manuel action vérin tribord.

3 Mode pilote automatique. Si last_code_fonction < 3 donc la

valeur de consigne prend celle du cap réel.

4 Incrément de 1° consigne de cap.

5 Incrément de 10° consigne de cap.

6 Décrément de 10° consigne de cap.

7 Décrément de 1° consigne de cap. Tableau 6. Instructions executées selon le code de fonctionnement.

Ensuite, dans la routine de calcul d’erreur et du sens de rotation, si le système est en mode

automatique (code de fonctionnement ≥ 3), le logiciel détermine la magnitude de l’erreur

entre le cap réel et la consigne en exécutant l’algorithme de la figure 21. Cette procédure

permet aussi de déterminer le sens de rotation du vérin.

Figure 21. Calcul d'erreur.

16

Dans la routine de contrôle, si le système est en mode automatique, la valeur de l’erreur est

multipliée par une constante Kp et le résultat est mis dans le registre qui gère le rapport

cyclique du signal PWM appliqué au moteur du vérin et le sens de rotation est mis à jour. La

figure 22 montre le comportement du rapport cyclique pour une valeur de Kp de 100. Si le

système est en mode manuel, le rapport cyclique et le sens de rotation sont mis à jour à

partir des valeurs déterminées dans la routine d’acquisition du code de fonctionnement.

Figure 22. Rapport cyclique du signal PWM vs Erreur de cap.

Finalement, la position du vérin est acquise et transmise via RS232, le compteur de 100ms est

mis à jour, et un affichage de donnés est réalisé en utilisant le module JTAG du processeur

NIOS II et la console du logiciel NIOS II.

17

6. RESULTATS OBTENUS

Dans la phase ascendante du cycle de développement du système, nous avons réalisé un

ensemble de tests unitaires pour valider les différents composants. Ces tests correspondent

à des simulations des circuits décrits en VHDL en utilisant l’environnement de simulation

Model-Sim ou bien à travers de vérifications faites sur des circuits implémentés en FPGA.

Finalement deux tests de validation ont été réalisés pour s’assurer que le système répond au

cahier de charges. Les résultats obtenus sont expliqués ci-dessous.

6.1 Vérification du circuit de gestion de boussole

Une simulation a été réalisée pour vérifier le comportement du circuit de gestion de

boussole dans les deux modes de fonctionnement. La figure 23 montre le résultat de

simulation du circuit « compass » en mode continu.

Figure 23. Simulation du circuit de gestion de boussole en mode continu.

Egalement le mode mono-coup a été vérifié en simulation et le résultat obtenu est montré

dans la figure 24.

Figure 24. Simulation du circuit de gestion de boussole en mode mono-coup.

18

Pour le mode mono-coup nous avons aussi vérifié la transition de la sortie Data_Valid de

l’état bas vers l’état haut lorsque le calcul de l’angle est terminé et de l’état haut vers l’état

bas lorsque l’entrée Start_Stop est mise à zéro. Cette vérification est montrée dans la figure

25. Ces transitions sont synchronisées par l’horloge de 10 KHz.

Figure 25. Signal Data_Valid du circuit de gestion de boussole en mode mono-coup.

6.2 Vérification du circuit de gestion de réception NMEA

Le circuit de réception de trames NMEA a été vérifié aussi en simulation. La figure 26 montre

le résultat obtenu pour une simulation en mode mono-coup. Le chronogramme permet de

vérifier l’évolution des signaux importantes et de la machine à états Rx Management. Pour

ce mode de fonctionnement la remise à zéro de la sortie Data_Valide a été aussi vérifiée

lorsque l’entrée Start/Stop revient à 0.

Figure 26. Simulation du circuit de gestion de réception NMEA.

19

6.3 Vérification du circuit de gestion de transmission NMEA

Le test de vérification du circuit de transmission a été fait sur la carte FPGA DE2 avec un

oscilloscope capable d’identifier des trames RS232. La figure 27 montre le résultat obtenu

pour les entrées : S=’$’, C=’0’, D=’7’ et U=’3’.

Figure 27. Trame de test transmise par le circuit de transmission NMEA.

6.4 Validation du système.

La validation du système développé a été faite sur une maquette qui intègre une carte DE0

NANO et les différents éléments acteurs tels que les boutons poussoirs, les diodes LED, le

haut-parleur, une boussole, un vérin commandé par un moteur DC, un circuit de conversion

A/N pour l’acquisition de la position du vérin et un circuit d’interface RS-232 pour la

communication avec un simulateur de voilier.

Figure 28. Maquette de validation.

Deux tests de validation ont été effectués : pour le premier test, le cap réel est acquis avec

la boussole, alors que pour le deuxième test, le cap est transmis par une maquette de

simulation via RS-232 à partir de la position de la barre franche (envoyé par le système

développé via RS-232).

Nous avons constaté que le fonctionnement du système est correct dans le mode de

manuel et automatique. Nous avons observé cependant, que dans le mode automatique

la trajectoire du voilier fait des oscillations avant de se stabiliser dans la trajectoire de

consigne. Ce résultat est conséquence du contrôleur proportionnel qu’on a mis en œuvre

dans le logiciel de contrôle. Un facteur dérivatif dans la stratégie de contrôle pourrait

permettre d’atténuer les oscillations.

20

7. CONCLUSIONS

A la fin du projet, la mise en œuvre d’un système de contrôle de trajectoire d’un voilier a

été faite avec succès en répondant aux exigences fonctionnels, technologiques,

opératives, de contrainte et d’interface imposés dans le cahier de charges.

Le développement matériel des modules fonctionnels a impliqué une difficulté au moment

de décrire le fonctionnement de ces modules en VHDL étant donné notre manque

d’expérience dans ce domaine.

Par ailleurs, au niveau personnel, le bureau d’étude réalisé a été l’occasion de mettre à

profit et de renforcer les connaissances sur les différentes méthodes définies par l’ingénierie

de systèmes tels que l’analyse d’exigences, la conception basé sur une approche

fonctionnelle, la définition d’architectures logiques et physiques pour la phase

d’implémentation et aussi la planification et exécution des activités de vérification et de

validation.

De plus, cette expérience nous a permis d’acquérir la connaissance de la technologie de

systèmes sur puce programmables comme solution pratique pour la mise en œuvre de

systèmes complexes dont l’intégration entre les éléments de type logiciel et matériel devient

un enjeu important pour l’optimisation du système. Surtout quand il est nécessaire de réaliser

un distribution de certains fonctionnalités critiques ou spécifiques d’un système sur la forme

de composants physiques afin de réduire les calculs dans le logiciel embarqué quand le

processeur est limité en performance.

Finalement, dans une évolution future du système de pilotage de barre franche, il serait

intéressant d’ajouter les facteurs dérivatif et intégratif à la stratégie de contrôle

automatique mise en place sur le logiciel embarqué. Le facteur dérivatif permettrait

d’atténuer les oscillations de la trajectoire du voilier grâce à ses caractéristiques prédictives

alors que le facteur intégratif peut garantir l’élimination de l’erreur de cap, ce qui permet

d’éliminer les valeurs petites du rapport cyclique appliqué au moteur de vérin (insuffisantes

pour surmonter son inertie). Le résultat de cette amélioration est de grand intérêt en termes

d’optimisation de l’énergie.