Drone

PROJET de 2ème année
N° du projet : 7220
Date : 08/06/2006
RAPPORT FINAL
Promo : 2007
CONCEPTION DE MINI-DRONES
AVIONS : QUADRICOPTERE
Sommaire
1. PRESENTATION DU PROJET .........................................................6

1.1. Titre du projet et numéro d’enregistrement................................................. 6
1.2. Les parties signataires ............................................................................. 6
1.3. Analyse de la situation ............................................................................. 6
1.4. Les raisons qui ont conduit à ce contrat, l’historique..................................... 7
1.5. Les difficultés rencontrées actuelles et à venir : analyse des risques ............... 7
1.6. Objectifs du projet .................................................................................. 7
1.6.1. Enoncé général ................................................................................ 7
1.6.2. Les objectifs intermédiaires................................................................ 7
1.7. Processus opératoire ............................................................................... 8
1.7.1. L'organisation de l'équipe .................................................................. 8
1.7.2. Le planning du projet ........................................................................ 8
1.7.3. Le financement du projet ................................................................... 8
1.7.4. La structure et l'organisation de l'équipe projet ..................................... 8
2. PROPULSION ...............................................................................9
2.1. Les batteries .......................................................................................... 9
2.1.1. Choix du type de batteries utilisées ..................................................... 9
2.1.2. Précautions d’emploi spécifiques ....................................................... 10
2.1.3. Calcul de l’autonomie du quadricoptère.............................................. 10
2.2. Disjoncteur .......................................................................................... 12
2.2.1. Fonction du disjoncteur ................................................................... 12
2.2.2. Principe de fonctionnement .............................................................. 12
2.2.3. Modélisation de la solution ............................................................... 12
2.2.4. Résultats ....................................................................................... 15
2.2.5. Configuration retenue et améliorations possibles ................................. 16
2.2.6. Exemples de calculs des valeurs des potentiomètres ............................ 17
2.3. Moteurs et Variateurs ............................................................................ 18
2.3.1. Principe de fonctionnement des moteurs BLDC : nécessité de variateurs. 18
2.3.2. Principe de fonctionnement d’un variateur.......................................... 18
2.3.3. Description des variateurs actuels et limitations .................................. 22
2.3.4. Principe de fonctionnement et architecture des nouveaux variateurs ...... 27
2.3.5. AT90PWM3 .................................................................................... 29
2.3.6. Carte de test de l’étage de puissance ................................................ 34
2.3.7. Protocole de validation .................................................................... 36
3. CAPTEURS ..................................................................................37
3.1. Prise en main ATMEGA ........................................................................... 40
3.1.1. Lecture de la documentation ............................................................ 40
3.1.2. Kit de développement et logiciels utilisés ........................................... 40
3.1.3. Flasher un programme sur le microcontrôleur ..................................... 40
3.1.4. Information importante quand à l’utilisation des portables IBM.............. 40
3.1.5. Apprendre à programmer en langage C.............................................. 41
3.2. La centrale inertielle – MIDGII ................................................................ 42
3.2.1. Fonctionnement de la centrale inertielle ............................................. 42
3.2.2. Tests effectués ............................................................................... 43
3.3. Capteurs ultrasons ................................................................................ 45
3.3.1. Le capteur SRF10 ........................................................................... 45
3.3.2. Protocole I²C ................................................................................. 46
3.3.3. Code source utilisé.......................................................................... 48
3.4. Détection d’obstacles ............................................................................. 59
3.4.1. Définition du besoin et solution mise en place ..................................... 59
3.4.2. Structure de test et Logiciels ............................................................ 60
3.4.3. Tests de performances avec deux capteurs : Mise en évidence des
problèmes d’interférences ............................................................................. 62
3.4.4. Expérience 2 : Test sur le quadricoptère ............................................ 65
3.4.5. Rappel : Test grossier de la portée d’un capteur ultrason avec un
gain de 5 ................................................................................................... 66
3.4.6. Rappel fonctionnement du code 3 ..................................................... 67
3.4.7. Synthèse et conclusions .................................................................. 67
3.4.8. Fonction de détection d’obstacles complète ........................................ 67
3.4.9. Fonction de détection d’obstacle simplifiée ......................................... 68
3.5. Capteurs de vitesse ............................................................................... 69
4. TRANSMISSION .........................................................................70
4.1. Etude des modems en vue d’une liaison bidirectionnelle.............................. 72
4.1.1. 1 Prise en main du modem Maxstream .............................................. 72
4.1.2. La transmission descendante............................................................ 72
4.1.3. Etude des caractéristiques du modem pour la liaison bidirectionnelle...... 73
4.1.4. Réaliser des tests de portée pour le Maxstream avec le réglage de SY .... 76
4.2. Objectif 2 : Mise en place de la liaison bidirectionnelle ................................ 77
4.2.1. Solutions possibles ......................................................................... 77
4.2.2. Prise en main ATMega et kit STK500 ................................................. 78
4.2.3. Tests de communication bidirectionnelle à travers un port UART............ 79
4.2.4. Transfert des informations descendantes à travers l’ATMega ................. 80
4.3. Câblage d’un gamepad sur l’ATMega au sol ............................................... 81
4.4. Protocole de tests : Séparation des problématiques.................................... 84
4.4.1. Liaison bidirectionnelle avec radiocommande de modélisme .................. 84
4.4.2. Test du gamepad en pratique ........................................................... 86
4.4.3. Mise en place de la liaison bidirectionnelle avec le gamepad.................. 86
4.5. Problématique de la navigation par waypoints ........................................... 87
4.6. Conclusion ........................................................................................... 88
5. STRUCTURE................................................................................89
5.1. Introduction ......................................................................................... 89
5.2. Les pré-requis ...................................................................................... 90
5.3. Objectifs .............................................................................................. 90
5.4. Solutions possibles ................................................................................ 91
5.4.1. Optimisation de la structure et gain de poids ...................................... 91
5.4.2. Nouvelle fixation moteur.................................................................. 91
5.4.3. Méthode d’adaptation des hélices...................................................... 91
5.4.4. Structure démontable ..................................................................... 92
5.4.5. Autres évolutions............................................................................ 93
5.5. Solutions choisies.................................................................................. 95
5.6. Mise en application ................................................................................ 98
5.7. Conclusions ........................................................................................ 100
5.8. Améliorations de la carte actuelle .......................................................... 101
5.8.1. Les connecteurs ........................................................................... 101
5.8.2. Fonction Reset de lÁTMEGA .......................................................... 102
5.8.3. Intégration des éléments oubliés lors de la conception ....................... 102
5.8.4. Réalisation dúne carte de communication au standard RS232............ 102
5.9. Banc d’essai ....................................................................................... 104
5.9.1. Objectif ....................................................................................... 104
5.9.2. Le banc d’essais ........................................................................... 104
5.9.3. Les capteurs ................................................................................ 105
5.9.4. Conclusions ................................................................................. 106
6. INTERFACE HOMME MACHINE (IHM) .......................................107
6.1. Objectifs du groupe Interface Homme-Machine........................................ 108
6.2. Capitalisation et travail sur le logiciel VB6 ............................................... 112
6.3. Restructuration de la station sol ............................................................ 113
6.3.1. L’objectif de la restructuration de la station sol ................................. 113
6.3.2. Solution actuelle........................................................................... 113
6.3.3. Première solution alternative .......................................................... 114
6.3.4. Deuxième solution alternative ........................................................ 115
6.3.5. Troisième solution alternative......................................................... 116
6.3.6. Évaluation des différentes solutions................................................. 117
6.3.7. Faisabilité de la solution envisagée.................................................. 117
6.4. Matlab ou VisualBasic ? ........................................................................ 119
6.4.1. Expérience pendant le concours...................................................... 119
6.4.2. Justification du choix Matlab........................................................... 119
6.4.3. Les codes en Visual Basic et Matlab ................................................. 119
6.4.4. Objectifs pour l’avenir ................................................................... 120
7. HARDWARE IN THE LOOP (HIL) ...............................................121
7.1. Objectifs du groupe HIL et organisation du travail .................................... 121
7.1.1. Objectifs de notre groupe .............................................................. 121
7.1.2. General Design of Process Controls ................................................. 123
7.1.3. Conception générale ..................................................................... 125
7.1.4. Les sous-tâches de notre groupe .................................................... 126
7.2. Réalisation ......................................................................................... 128
7.2.1. Choix du modèle et du contrôleur ................................................... 128
7.2.2. Intégrations des interfaces............................................................. 130
7.2.3. Les tests des systèmes.................................................................. 135
7.2.4. Visualisation du vol : FlightGear...................................................... 141
7.3. Perspectives de développement............................................................. 151
7.3.1. Bilan du groupe HIL ...................................................................... 151
7.3.2. Perspectives de développement ...................................................... 152
8. CALCULATEUR EMBARQUE .......................................................153
8.1. Introduction ....................................................................................... 153
8.1.1. Présentation du sous-groupe :........................................................ 153
8.1.2. Présentation du matériel................................................................ 153
8.2. Objectifs de l’année ............................................................................. 156
8.3. Démarche suivie ................................................................................. 157
8.3.1. Rentrer des waypoints................................................................... 157
8.3.2. Automatique/asservissement en position ......................................... 158
8.3.3. Détection d’obstacles .................................................................... 161
8.3.4. Définition du mode de passage entre mode manuel et automatique ..... 165
8.3.5. Etablissement d’une procédure d’atterrissage en cas d’urgence ........... 166
8.4. Mise en application .............................................................................. 168
8.4.1. Rentrer des waypoints................................................................... 168
8.4.2. Automatique/asservissement en position ......................................... 168
8.4.3. Détection d’obstacles .................................................................... 169
8.5. Activité expérimentale ......................................................................... 171
8.5.1. Limites de l’ATmega...................................................................... 171
8.5.2. Solution du SC520 ........................................................................ 173
9. ANNEXES PROPULSION............................................................186
10. ANNEXES CAPTEURS ................................................................191
10.1. Annexe 1 : code source de la MIDG II................................................. 191
10.2. Annexe 2 : Code 1 : lancer des ranging dès que possible pour chaque capteur
individuellement. .......................................................................................... 195
10.3. Annexe 3 : Code 2 : ranging de tous les capteurs en même temps.......... 198
10.4. Annexe 4 : Code 3 : faire fonctionner les capteurs les uns après
les autres .................................................................................................... 201
10.5. Annexe 5 : Code de changement de l’adresse d’un capteur .................... 204
11. ANNEXES TRANSMISSION........................................................208
11.1. Exemple de programme de test de communication bidirectionnelle à travers
un port UART ............................................................................................... 208
11.2. Programme de l’ATMega au sol – Transfert des données descendantes et
affichage de l’INS.......................................................................................... 210
11.3. Programme de décodage de la trame PPM de la radiocommande............. 212
12. ANNEXES STRUCTURE ..............................................................215
13. ANNEXES IHM ..........................................................................216
13.1. Code de la station sol en Visual Basic 6.0 ............................................ 216
13.1.1. Explications préliminaires ........................................................... 216
13.1.2. Explication détaillée du code de l’année 2005 ................................ 216
13.1.3. Les fonctions Form_Load et Form_Unload ..................................... 217
13.1.4. La fonction MSComm1_OnComm ................................................. 218
13.1.5. La fonction Traitement ............................................................... 218
13.1.6. Explication des compléments de cette année ................................. 219
13.2. Code de la station sol en Matlab......................................................... 220
13.2.1. Le GUI ..................................................................................... 220
13.2.2. Le code derrière le GUI .............................................................. 221
13.2.3. La fonction d’ouverture .............................................................. 221
13.2.4. La fonction de fermeture ............................................................ 222
13.2.5. La fonction serial_callback .......................................................... 222
13.2.6. La fonction data_processing........................................................ 223
13.2.7. La fonction visualisation ............................................................. 223
14. ANNEXES HIL ...........................................................................224
14.1. Planches et Code importants ............................................................. 224
14.1.1. PWM........................................................................................ 224
14.1.2. RS232 ..................................................................................... 225
14.1.3. MIDG II ................................................................................... 227
14.2. Réalisation d'un contrôleur ................................................................ 228
14.3. Commandes MATLAB pour RS232....................................................... 229
14.4. Ranges de la télécommande .............................................................. 229
14.5. Si ça ne fonctionne pas..................................................................... 230
14.5.1. Versions de MATLAB .................................................................. 230
14.5.2. Backward Propagation................................................................ 230
14.5.3. Variables externes..................................................................... 231
14.5.4. TCP/IP erreur ........................................................................... 231
14.5.5. Rebuild .................................................................................... 231
14.5.6. xPC Target Scopes .................................................................... 231
14.5.7. Working directory...................................................................... 232
14.5.8. Erreurs incompréhensibles !........................................................ 232
14.5.9. Reset Atmel.............................................................................. 232
14.5.10. Vérification des connexions......................................................... 232
14.5.11. Configuration de l’Atmega .......................................................... 232
14.6. Les contrôleurs dans Simulink et sur l’ATmega ..................................... 233
14.7. Fichiers pour l’I²C ............................................................................ 237
14.7.1. Objectif.................................................................................... 241
14.7.2. Branchement Liaisonvia RS232.................................................... 241
14.7.3. Branchement Connexion via Ethernet ........................................... 248
15. ANNEXES CALCULATEUR ..........................................................250
15.1. Structure du Programme principal (Version main500_4) ........................ 250
15.2. Boucle automatique principale ........................................................... 251
15.2.1. Boucle d’altitude ....................................................................... 251
15.2.2. Boucle horizontale en X (en Y pareille) ......................................... 253
15.2.3. Détection d’obstacles ................................................................. 255
Projet Quadricoptère 2005/2006
1. PRESENTATION DU PROJET
1.1. Titre du projet et numéro d’enregistrement
Projet de mini-drone : Quadricoptère, mini-drone d’observation.

Numéro d’enregistrement : 7220
1.2. Les parties signataires
Encadrant du projet : Philippe Martin.

Chef de projet : Nicolas de Laleu
Elèves ingénieurs :
de Laleu Nicolas Chef de projet

Desaedeller Maxime Cellule Structure
Fiocchi Guillaume Cellule propulsion
Khammari Aymen Cellule calculateur embarqué
Klein Michael Cellule IHM
Kober Jens Cellule HIL
Lajmi Wissem Cellule calculateur embarqué
Lazreg Aymen Cellule électronique
Moineau Jean-georges Cellule HIL
Moulin Lucas Cellule transmission
Nölle Alexander Cellule HIL
Ossola Baptiste Cellule capteurs
Pellegrino Jeremy Cellule transmission
Prevot Sylvain Cellule capteurs
Slissa Thierry Cellule propulsion
Theissen Pascal Cellule IHM
Mastère Technologie et
Management
Carteau Sébastien Cellule Projet

Benassila Tarik Cellule Projet
1.3. Analyse de la situation
Le projet DRONE 2006 est un projet complexe de R&D qui s’inscrit dans la continuité du
quadricoptère primé au concours « Drone, œil du fantassin » organisé par l’ONERA et la
DGA en septembre 2005. Malgré la première place obtenue le drone développé par
l’Ecole Centrale et l’Ecole de Mines n’a pas atteint l’ensemble des fonctionnalités de haut
niveau attendues lors du concours.
L’année 2006 a été une année de transition qui a consisté en un développement de
nouvelles fonctionnalités et à faire évoluer celles existantes pour améliorer le
comportement global du drone dans l’optique d’un nouveau concours ONERA en 2007 ou
en 2008.
6
1.4. Les raisons qui ont conduit à ce contrat, l’historique
Le projet créé en 2003 lors du regroupement des enseignements d’automatique,

d’électronique et de traitement du signal créer des sujets de travaux dirigés
(étude/fonctionnement du système). Le concours créé par la DGA et l’ONERA est devenu
le principal objectif de ce groupe de travail.
L’équipe ECP/Ecole des mines a présenté un dossier technique et financier pour obtenir
une subvention de 40 000 € en vue du concours organisé par la DGA et l’ONERA.
L’équipe a été retenue et a pu continuer le développement du quadricoptère qui intégrait
des fonctionnalités avancées, en terme d’intelligence embarquée et d’automatique.
Cette première phase a abouti au premier prix décerné au quadricoptère concours
organisé en septembre 2005. Lors de ce concours, le drone est arrivé premier ex æquo
et a reçu un prix de 8000 €.
1.5. Les difficultés rencontrées actuelles et à venir : analyse

des risques
Le quadricoptère existant au début du projet est l’aboutissement de deux de travail et a

présenté une accumulation de nouveautés pour l’ensemble des étudiants du projet 2006.
Par ailleurs la quasi-totalité de l’équipe projet a été renouvelée cette année et elle a du
en premier lieu comprendre et capitaliser ce qui avait été fait sur le drone existant. Cette
phase s’est avérée plus importante que prévue initialement et a rendu difficile la prise en
charge concrète d’évolution ou de fonctionnalités nouvelles.
1.6. Objectifs du projet
1.6.1. Enoncé général
Le projet drone est issu du concours lancé en 2003par la DGA et l’ONERA pour la création
d’un drone « œil du fantassin ». Les minis drones, destinés aux fantassins du futur,
doivent être conçu comme une aide dans la progression en milieu hostile. L’aide attendue
est non agressive : le système drone doit permettre d’obtenir une vision déportée (au-
delà de son horizon naturel).
D’un point de vue organisation et gestion de groupe, l’objectif de l’année 2006 était de
continuer ce qui avait déjà été fait les années précédentes sur la répartition des taches et
le suivi pour éviter tout gâchis ou forme de redondance mais également de mettre en
place une méthode de suivi facile. En effet, dès les débuts du projets, nombreux furent
les élèves qui eurent du mal à s’approprier le projet et donc à être rapidement efficaces.
Notre objectif dans la cellule projet fût donc de mettre en place des fiches séances pour
permettre une meilleure prise en main du projet l’année prochaine.
D’un point de vue technique, l’objectif de l’année 2006 s’est inscrit dans ce cadre et a eu
pour but de rendre le drone autonome (fonctions algorithmiques avancées, suivi d’un
parcours GPS, autonomie de vol plus importantes, etc…).Malheureusement, tous les
objectifs n’ont pu être atteints bien que le drone présente aujourd’hui des fonctionnalités
nouvelles détaillées dans les parties des différents groupes de ce rapport.
1.6.2. Les objectifs intermédiaires
L’objectif du projet était donc de faire un drone plus autonome avec des fonctionnalités
de haut niveau afin de pourvoir présenter un dossier technique complet pour l’appel à
candidature du prochain concours organisé par l’ONERA et la DGA.
Les fonctionnalités à développer ont donc été les suivantes :
Vol autonome GPS avec évitement d’obstacles (inachevé)
7
Miniaturisation et évolution de la station sol (accompli en grande partie)

Simulation sur ordinateur (achevé)
Évolution des fonctionnalités existantes (liaison bi-directionnelle, nouvelle structure…)
1.7. Processus opératoire
Le projet Quadricoptère étant mené sur plusieurs années et impliquant tous les ans un
nombre important d’élève, l’organisation des ressources doit être tout particulièrement
soigné afin d’être exploitées au maximum.
1.7.1. L'organisation de l'équipe
L’équipe a été organisée en sous-groupe orienté par spécifications techniques. Ainsi,

chaque sous-groupe comporte deux ou trois élèves et se trouve sous la responsabilité
d’un des membres de la cellule projet. Chaque sous-groupe se voit attribuer un
responsable de sous-groupe qui est responsable de la bonne évolution de son équipe.
Néanmoins, les sous-groupes sont liés les uns aux autres. Pour éviter de faire les mêmes
choses en double, des réunions régulières sont réalisées entre les responsables de sous-
groupe durant lesquelles ils tiennent compte de leur état d’avancement et du travail
qu’ils comptent réaliser. Chaque sous-groupe est tenu de faire une fiche séance lors de
chaque séance dans laquelle il explicite l’objectif de leur séance, le protocole utilisé pour
atteindre ces objectifs ainsi que les conclusions ou les réflexions personnelles qui s’y
attachent. De ce fait, les autres sous-groupes peuvent accéder à des résultats facilement
sans perte de temps inutile. Ces fiches séances sont mises en partage commun sur le
site du projet.
1.7.2. Le planning du projet
Trois réunions avec tous les participants au projet ont été organisées dans l’année pour
choisir les grandes orientations, faire des comptes rendus d’avancement et être sur de
garder l’adhésion de tous. Les objectifs de chacun ont été définis lors de la première de
ces réunion.
1.7.3. Le financement du projet
Le détail du budget tel qu’il a été prévu initialement est exposé en annexe. Hors
dépenses de fonctionnement interne (encadrant, doctorant de l’école des mines et salle)
dont le financement est assuré, les dépenses en matériel prévu sur le projet s’élèvent à
16 400€ dont le financement est assuré à 70% par le budget non utilisé de la subvention
ONERA/DGA.
Le reste du financement a été effectué grâce à une subvention de l’école centrale suite à
une demande de 3 000€ et par des subventions externes pour 2 000€.
1.7.4. La structure et l'organisation de l'équipe projet
Le projet quadricoptère est composé d’une équipe nombreuse animée par un fort esprit
de groupe et par la volonté de réaliser le travail nécessaire pour parvenir à faire évoluer
les fonctionnalités du drone.
8
2. PROPULSION
Le groupe Propulsion est responsable de tout ce qui concerne la puissance sur le

quadricoptère : les batteries, les moteurs et leurs variateurs. Les années précédentes, les
groupes propulsion se sont occupés de trouver un couple {moteur+hélice} optimal pour
notre utilisation et d’en faire un modèle physique. Cette année, nos objectifs étaient :
• Faire de la veille technologique sur les batteries disponibles sur le marché.
• Identifier la source des appels de courant qui ont fait brûler la carte en 2005 et
améliorer le disjoncteur.
• Améliorer les performances des variateurs des moteurs BLDC du quadricoptère.
2.1. Les batteries
2.1.1. Choix du type de batteries utilisées
Le critère déterminant dans la choix du type de batteries utilisées est, pour une
application de type engin volant, la densité d’énergie. Le choix de l’utilisation de batteries
Lithium-Polymère (LiPo) a été fait il y a deux ans, et à ce jour, il s’agit encore de la
technologie offrant une densité d’énergie maximale : ce choix est toujours pertinent.
Voici à titre d’exemple quelques caractéristiques typiques des différentes technologies de
batteries :
Densité Tension
Auto Nombre Résistance
d’énergie nominale
Technologie décharge de interne
gravimétrique d’un
par mois cycles (mΩ)
(Wh/kg) élément
Plomb acide 30-50 5% 250 2V 0,3 à 100

Nickel Cadmium 45-80 20% 1500 1,2 V 100 à 200
Nickel Métal Hydride 60-120 30% 400 1,2 V 200 à 300
Lithium Ion 110-160 5% 800 3,6 V 150 à 250
Lithium Ion Polymère 170 5% annuel 300 3,7 V 200 à 300
Alcalines rechargeables 80 0,3% 100 1,5 V 200 à 2000
Actuellement le quadricoptère utilise des batteries 3 cellules (11,1 V) de 2000 mAh

pesant environ 160 g. Depuis 2004, cette technologie a progressée et on trouve des LiPo
de capacités allant jusqu’à 6000 mAh et offrant des densités d’énergie de 170 à plus de
300 Wh/kg. Les principaux fabricants sont Kokam, Lipotech et Thunder Power. Voici les
caractéristiques de certains modèles du marché :
9
Densité
Format Poids de la 11.1 V d’énergie Décharge
Type
(mmxmmxmm) cellule (3 cellules) (Wh/kg) maximale
2000 mAh 77x41x8 51 g 87.70 € 134 < 30A
2100 mAh 109x64x6 68 g 130.80 € 83 < 40A
2500 mAh 40x90x12 50 g 91 € 179 < 40A
3200 mAh 131x43.5x7.6 82 g 167.40 € 137 < 64A
3300 mAh 22x51x152 75 g 119 € 137 < 40A
4200 mAh 105x38x30 85 g 160 $ 175 < 40A
6000 mAh 34x98x25 65 g 179.95 $ 333 N/A
2.1.2. Précautions d’emploi spécifiques
Comme ces batteries contiennent du Lithium, en cas d’incendie il s’agirait d’un feu de
classe D qu’il n’est pas possible d’éteindre avec un extincteur classique.
Certaines règles de sécurité spécifiques sont à respecter :
• Ne jamais laisser la batterie dans un modèle.
• La tension de la batterie ne doit jamais descendre en dessous de 3V par élément,
soit 9V pour une batterie 3 éléments. Après une décharge, il est bon d’attendre
une heure et de recharger la batterie à 20%.
• Ne jamais dépasser le courant de décharge indiqué par le constructeur (le
formalisme est : un batterie 1500mAh de 15C est déchargée au maximum à
15*1,5=22,5A).
• Ne jamais dépasser le courant de charge (il est en général marqué sur la
batterie). Il est d’environ 1C.
• Ne jamais dépasser la tension de charge : le plus sûr est d’utiliser un chargeur du
commerce. Pour batterie de 3 éléments elle est de 12,6V.
• Ne jamais court-circuiter (évidemment).
• Ces batteries n’aiment ni les chocs ni la chaleur.
• Pas plus d’un cycle charge/décharge par jour.
• …
En cas de problème, ou de doute, le plus simple est d’appeler le service de sécurité
(poste 13 49) pour qu’ils évacuent la batterie endommagée. Le gonflement d’une batterie
est le symptôme caractéristique du fait qu’elle est endommagée : si vous observez un
gonflement, isolez la batterie tout en minimisant les manipulations (la placer
délicatement dans un lavabo, au milieu d’une zone dégagée…).
2.1.3. Calcul de l’autonomie du quadricoptère
L’autonomie est calculée comme étant le rapport entre l’énergie utile embarquée sur la
puissance nécessaire pour manœuvrer l’engin. Le calcul de l’autonomie suppose donc la
connaissance de plusieurs éléments :
• La masse à vide de l’engin
• La masse d’un élément de batterie
• L’énergie utile par élément de batterie (on ne peut descendre en dessous de 3V
par élément, donc cette énergie est directement liée à la capacité de l’élément)
• Le nombre d’éléments utilisés
• La puissance nécessaire aux moteurs pour fournir une poussée donnée.
Pour avoir la relation puissance/poussée, nous avons utiliser la régression polynomiale
obtenue à partir des mesures effectuées en 2005 pour le couple {moteur,hélice} que
10
nous utilisons (moteur MFLY 34L et hélices Todd’s 10x4,5"). Le résultat est :
y = 2,5358998E-04x² + 2,8024681E-02x + 3,2462112 avec un R² = 0,99967856, où y
est la puissance à fournir en Watts et x la poussée développée en grammes.
La masse à vide du quadricoptère est 620g, une batterie de 3 éléments pèse 160g. La
tension de batterie en charge est d’environ 12,3V, l’énergie utile embarquée vaut donc,
pour nos batteries 3 éléments de 2000 mAh, (12,3-3*3)*2000*3600/1000=23760J par
batterie. Pour calculer la puissance, on ne peut se contenter de considérer qu’il faille
juste équilibrer le poids du quadricoptère. On peut alors soit supposer que chaque
moteur doit développer une poussée égale à la moitié de la masse du quadricoptère (et
pas uniquement un quart comme pour du vol stationnaire sans vent), soit que les
moteurs travaillent en moyenne à 66% de leur maximum et développent donc 66% de
leur poussée maximale. Dans tous les cas, on appliquera un facteur de
surdimensionnement de 1,5 correspondant au décalage entre théorie et pratique. Ainsi
N batteries * Eutile / batterie
Autonomie =
1,5* Ptotale P = 4* Pmoteur ( mquadri / 2)
on a : avec totale dans le premier
P = 4* 66% * Pmoteur _ max
cas et totale dans le deuxième cas.
On obtient les résultats suivants :
Nombre de batteries Cas n°1 Cas n°2

1 5 minutes 1 minute 15 secondes
2 7 minutes 20 secondes 2 minutes 30 secondes
On s’aperçoit que l’hypothèse 1 correspond plus à la réalité, on retiendra cette

hypothèse. Cependant il faut noter que l’on est bien loin des 30 minutes spécifiées par le
règlement du concours DGA 2005. Lorsqu’on applique ce calcul aux batteries de 6000
mAh décrites plus haut, on atteint une autonomie de 19 minutes avec 2 batteries.
La mise en parallèle des batteries pose cependant certains problèmes. En effet, les
batteries doivent toute être chargées de la même façon. Il existe un dispositif réalisant
cette fonction, mais nous n’avons pas eu le temps de le tester. Il faut également
s’assurer en principe que l’on ne dépasse pas le courrant maximum par batterie (ce qui
est difficile à contrôler dans la pratique quand toutes les batteries sont en parallèle, mais
qui, vu les courants maximaux de décharge admissibles, n’est pas un problème pour
nous).
Il est à noter que nous avons modifié le modèle de calcul de l’autonomie par rapport à
celui de 2005 qui présentait une erreur dans le calcul de l’énergie embarquée (ils avaient
considéré que l’on pouvait décharger totalement les batteries alors que la tension ne peut
en réalité pas descendre en dessous de 9V pour une batterie 3 éléments). Cela conduit
évidemment à des autonomies beaucoup plus faibles, mais réalistes.
11
2.2. Disjoncteur
2.2.1. Fonction du disjoncteur
En 2004-2005, deux cartes électroniques ont successivement pris feu lorsque le

quadricoptère était en vol, à cause d’un courant d’intensité trop importante. Pour palier
cela, il a été décidé d’équiper temporairement le quadricoptère d’un disjoncteur afin de
limiter le courant et ainsi protéger la carte, le temps de trouver la cause des appels de
courants (problème non résolu à ce jour).
Nous avions également pensé utiliser des composants chimiques réalisant la fonction de
disjoncteur réarmable, les polyswitch. Ces composants présentent deux inconvénients
majeurs : le courant limite est non réglable et le temps de commutation est beaucoup
trop important. Nous avons donc abandonné cette solution.
2.2.2. Principe de fonctionnement
On a retenu la solution d’un disjoncteur réglable (courant maximal admissible réglable)

et réarmable manuellement. Le principe est simple : on compare une tension image du
courant à une référence fixe (c’est donc la valeur de cette référence qui détermine la
valeur du courant limite admissible) et lorsque l’image du courant est supérieure ou
égale à la référence, on commande l’ouverture d’un interrupteur. Ensuite on doit réarmer
manuellement le circuit pour reprendre le fonctionnement normal.
2.2.3. Modélisation de la solution
2.2.3.1. Première version
Voici le schéma électrique de la première version du disjoncteur, la charge (le

quadricoptère) étant branchée sur les deux fils de droite, la batterie sur ceux de gauche.
12
L’image du courant est donnée par la tension entre la source et le drain du transistor de
puissance NMOS, la résistance interne de celui-ci étant de l’ordre de 25 mOhms. Celle-ci
est amplifiée d’un rapport (1+R2/R1) par l’AO noté « AMPLIFICATEUR ». L’utilisation de
deux potentiomètres R1 et R2 permet de régler le rapport d’amplification suivant les
besoins.
L’image amplifiée du courant est ensuite comparée à une fraction de VCC (la référence)
par l’AO noté « COMPARATEUR ». Le réglage de la référence se fait à l’aide du
potentiomètre R3, dont la valeur élevée limite le courant qui le traverse (du point de vue
de la charge, c’est un courant de fuite).
La sortie du comparateur pilote le transistor (sortie du comparateur connectée au gate
du transistor). Tant que l’image du courant est inférieure à la référence, la sortie du
comparateur est en saturation basse c'est-à-dire proche de 0V, le transistor est passant.
Quand le courant augmente, le comparateur passe en saturation haute, la sortie passe à
environ VCC, ce qui ouvre le transistor NMOS (transistor commandé en tension positive)
et donc le circuit. Le transistor étant ouvert, la tension à ses bornes vaut environ VCC,
l’amplificateur est en saturation haute, donc le comparateur aussi, le circuit reste ouvert,
l’état ouvert est bien stable.
Lorsque le circuit est ouvert, pour armer le disjoncteur il suffit de presser le bouton
poussoir « REARMEMENT » : à cet instant, on amplifie la tension aux bornes d’un
interrupteur fermé, soit 0V, le comparateur est donc en saturation basse, le transistor
devient passant. Lorsque l’on relâche le bouton poussoir, on a rétabli le fonctionnement
normal.
Cette méthode présente plusieurs inconvénients :

Tout d’abord, l’image du courant circulant dans le circuit est construite à partir de la
résistance interne du transistor. Or celle-ci est difficile à connaître, elle dépend de
13
beaucoup de paramètres, dont la température. De plus, la référence de tension utilisée

ici est une fraction de la tension aux bornes de la batterie. Cette tension baisse au cours
du vol, diminuant ainsi le courant limite admissible. Et de façon plus sensible, cette
tension baisse fortement lors de gros appels de courant. Cela rend difficile le réglage du
disjoncteur.
Afin de palier ce deuxième inconvénient, nous avons installé sur le disjoncteur un

régulateur de tension 7805 qui fournit une référence fixe et stable de 5V, constante au
cours du vol, quelque soit le courant demandé par le quadricoptère.
2.2.3.2. Deuxième version
Voici le schéma électrique de la deuxième version du disjoncteur, la charge (le

quadricoptère) étant branchée sur les deux fils de droite, la batterie sur ceux de gauche.
On a substitué la fraction de la tension de batterie par un régulateur de tension 5V pour

s’affranchir des variations de cette tension. Cela implique que le réglage du courant limite
admissible ne se fait plus en modifiant la référence, mais en changeant le rapport
d’amplification à l’aide des potentiomètres R1 et R2.
Les capacités C1 et C2 en parallèle de l’entrée et de la sortie du régulateur de tension
assurent un fonctionnement optimal de celui-ci.
2.2.3.3. Protocole utilisé et tests réalisés
L’impossibilité de détermination théorique de la valeur du courant limite (résistance

interne du transistor variable) nous a mené à déterminer celle-ci de façon expérimentale.
A cette fin, nous avons réglé le disjoncteur sur différentes valeurs théoriques calculées,
et nous avons mesuré la valeur réelle de ce courant limite.
Pour réaliser cela, nous avons utilisé un variateur de modélisme Tsunami 10 et un
moteur brushless comme charge variable, afin d’augmenter progressivement le courant.
Pour le fonctionnement du variateur, voir datasheet constructeur.
14
La principale difficulté provient de la limitation du courant que peut fournir le

générateur : 10A sous 12V, alors que le courant limite souhaité sur le quadricoptère est
de l’ordre de 25A à 30A.
2.2.4. Résultats
Voici deux régressions réalisées à partir de séries de mesures. Si on suppose qu’on peut
extrapoler la courbe jusqu’à des valeurs mesurée de 25A, on peut alors savoir comment
régler le disjoncteur.
Disjoncteur v1
48
46 y = 1,5203x + 1,7092
44 R2 = 0,9868
42
40
38
36
34
Valeur théorique
32
30
28
26 courbe disjoncteur
24
22 Régression linéaire
20
18
16
14
12
10
8
6
4
2
0
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
Valeur mesurée
15
Disjoncteur v2
28
26 y = 3,0625x 0,6221
24 R2 = 0,9947
22
20
Valeur théorique
18
16
Courbe disjoncteur
14 Régression puissance
12
10
8
6
4
2
0
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
Valeur mesurée
Il est important de noter que ces résultats sont parfaitement reproductibles.
2.2.5. Configuration retenue et améliorations possibles
On a retenu la configuration avec le régulateur de tension 5V.

Pour les AO, il faut prendre en compte la contrainte de l’alimentation : étant donné qu’on
utilise une batterie, ils doivent être alimentés en mono-tension 0-VCC. Les AO choisis
sont une plaquette LM324 qui comprend quatre A0 mono-tension. Ceci explique le fait
que la saturation basse des AO vaut 0V en sortie et la saturation haute +VCC.
Le transistor est un mosfet de puissance NMOS, c’est un IRF3710 (il en reste 2 neufs en
réserve).
Au cas où on ne trouve pas la cause des appels de courant et qu’il faille encore améliorer
les performances du disjoncteur, voici quelques pistes : pour s’affranchir des variations
de la résistance interne du transistor, utiliser un capteur de courant (dispositif délivrant
une tension proportionnelle au courant dans une plage de fonctionnement donnée) pour
construire l’image du courant ; pour améliorer la commutation du transistor, insérer une
petite résistance (typiquement 22 Ohms) entre la sortie du comparateur et le gate du
transistor. Voici deux références de capteurs de courant qui semblent convenir : capteur
Allegro ACS750xCA-050 et capteur LEM LAH 50-P. Vous pouvez aussi utiliser des
résistances de précision ou shunts pour faire la mesure du courant : attention à la
puissance que doit supporter le boîtier de la résistance. Pour un courant de 40A, il faut
un boîtier pouvant dissiper 1600*R watts. En prenant R = 0,01 Ω, il faut un boîtier 16W ;
cela correspond à des résistances dites film (à choisir parmi les modèles disponibles chez
Radiospares). Vous pourrez aussi travailler sur la miniaturisation du disjoncteur, en
dessinant un circuit imprimé par exemple, sachant que la partie puissance ne pourra pas
être réalisée sous forme de pistes car le matériel du LEE ne permet de faire des circuits
supportant des courants de 40A (il faudrait des pistes de 2cm de large…).
L’utilisation de la résistance interne du mosfet ou d’un shunt pour avoir la mesure du
courant présente cependant un inconvénient majeur : la puissance dissipée par effet
Joule est très importante (jusqu’à 25W avec le mosfet) du fait des courants mis en jeu.
Les capteurs de courant ne fonctionnant pas sur le même principe, la puissance perdue
devient négligeable.
16
2.2.6. Exemples de calculs des valeurs des potentiomètres
2.2.6.1. Disjoncteur v1
On souhaite un courant limite de 25A. L’image du courant est 25 mΩ * 25 A = 0,625 V.

Pour pouvoir le comparer à une fraction non négligeable de la tension de batterie, on
prend un gain d’amplification de 10, soit un rapport R2/R1 de 9. On choisit par exemple
R1=200 Ω et R2=1800 Ω.
On postule alors la valeur moyenne de la tension de batterie : prenons 11,5 V. on a alors
R3 = (10*0,625/12)*47 kΩ = 24480 Ω.
Le réglage des potentiomètres se fait avec un multimètre et un tournevis.
2.2.6.2. Disjoncteur v2
On souhaite un courant limite de 25A. L’image du courant est 25 mΩ * 25 A = 0,625 V.

On doit comparer ceci à 5V, soit un gain d’amplification de 5/0,625 = 8. Donc R2/R1 = 7,
on choisit par exemple R1=250 Ω et R2=1750 Ω.
17
2.3. Moteurs et Variateurs
2.3.1. Principe de fonctionnement des moteurs BLDC : nécessité de

variateurs
Le quadricoptère est équipé de quatre moteurs brushless dits BLDC (Brushless Direct
Courant). Ce sont des moteurs de type synchrone sans balais ni collecteurs.
Pour nos moteurs la cage constitue le rotor (à aimants permanents) et le stator est formé
des bobinages (7 pôles). Le couple électromagnétique est dû à l'interaction de deux
champs magnétiques, le champ tournant créé par les courants qui circulent dans les
enroulements du stator et le champ tournant produit par les aimants du rotor. Le champ
magnétique des aimants « suit » le champ tournant créé par les courants statoriques, la
cage tourne à la fréquence du champ statorique d’où le nom de machine synchrone. Pour
une étude théorique complète, se reporter au rapport projet 2005 ou au cours de classes
préparatoires PSI.
Sur le quadricoptère, la seule source d’énergie disponible est la batterie qui délivre par
conséquent du courant continu, et se comporte en première approximation comme une
source de tension. Pour créer un champ magnétique tournant, il faut au moins trois
courants identiques et déphasés de 120° électriques. Il faut donc générer à partir d’une
tension fixe trois courants identiques et déphasés. C’est le rôle des variateurs de
puissance. Il faut un variateur par moteur (soit quatre variateurs complets pour le
quadricoptère) qui alimente les trois phases du moteur avec les courants déphasés de
120° électriques.
2.3.2. Principe de fonctionnement d’un variateur
Un variateur de puissance est constitué de deux parties : une partie commande qui
génère les signaux commande pour l’étage de puissance, et l’étage de puissance qui
permet de générer les courants des trois phases moteur.
2.3.2.1. Etage de puissance
Vu les puissances mises en œuvre pour alimenter un moteur (jusqu’à 10A sous 12V), il
est indispensable d’avoir un rendement très élevé (de l’ordre de 90%), ce qui rend
impossible l’utilisation de filtres analogiques. L’étage est donc formé de trois ponts de
deux transistors, un pont par phase moteur. Dans notre cas, il s’agit de transistors
mosfet, utilisés comme des interrupteurs commandés en tension. Voici un exemple de
séquence de commutation sur chaque phase (à gauche) et le schéma du pont de
transistors (NMOS ici) :
18
La vitesse de rotation du moteur est égale à la fréquence des courants des phases. Le
couple est déterminé pour sa part par la valeur efficace du courant. Il faut donc que le
variateur permette, d’une part de contrôler la fréquence des commutations des ponts, et
d’autre part de modifier la valeur efficace du signal.
Pour modifier cette valeur efficace, on se base sur le principe du hacheur. Cela revient à
multiplier un signal d’amplitude fixée par la batterie par un créneau de fréquence très
élevée par rapport à celle du signal et de rapport cyclique variable. Ce créneau est appelé
signal PWM (Pulse Width Modulation). Voici un exemple de signal PWM, où on nomme
rapport cyclique la fraction t/T :
En réalité la vitesse de rotation du moteur n’est pas égale à la fréquence du courant dans
les phases, mais elle est proportionnelle à celle-ci. Ce coefficient de proportionnalité
dépend de la structure du moteur. L’intérieur de nos moteurs MFly 290-05-34L est
constitué par :
• Un stator qui crée le champ magnétique tournant, il possède six enroulements
clairement visibles (6 pôles).
• Un rotor externe avec 14 aimants.
Le fonctionnement est le suivant. D’un certain point de vue, le champ tournant passe
d’un enroulement à l’autre. Ces enroulements sont disposés tous les 2π/6=7π/21 et les
aimants tous les 2π/14=3π/21. Initialement supposons le champ dans la direction d’un
enroulement à l’angle 0, et un aimant en face, donc à l’angle 0 lui aussi (les moments
magnétiques cherchent à maximiser le champ extérieur qui passent par eux). L’instant
d’après le champ, schématiquement, se trouve dans l’axe de l’autre enroulement en
π/3=7π/21 ; il voit à son voisinage deux aimants : 6π/21 en amont et 9π/21 en aval.
Celui en 6π/21 va donc se déplacer de π/21 pour s’aligner avec le bobinage créateur du
champ (qui se trouve en 7π/21), ce qui fait tourner le moteur.
Soit f la fréquence du triphasé entrant : le champ prend un temps 1/f pour faire 2π, donc
1/6f pour faire π/3. Sur ce temps, le moteur tourne de π/21, donc pour 2π, il faut
2*21*1/6f=7/f secondes, donc la fréquence de rotation du moteur est de f/7
tours/seconde.
A partir de ce coefficient, on peut déterminer la fréquence à utiliser pour le PWM. La

fréquence de rotation maximale des moteurs est de l’ordre de 7200 tr/min, soit 120 Hz,
ce qui implique une fréquence maximale du courant de 7*120=840 Hz. On souhaite une
fréquence de PWM grande par rapport à cette fréquence, en pratique on prendra au
moins 30 kHz (sachant qu’actuellement le PWM généré par le variateur Toshiba TB9060
est à 16 kHz).
19
Sur nos variateurs, seuls les mosfets « du haut » (connectés à +VCC) des ponts ont une
commande modulée par le PWM :
Par exemple durant la séquence AB, le transistor A « haut » (A+) oscille entre les états
passant et bloqué à la fréquence du PWM, pendant que B- reste passant et A- et B+
sont bloqués.
Voici le schéma équivalent pour la séquence AB lorsque A+ est passant (PWM On) :
Lorsque le PWM est Off, on a :
On constate que le courant circule au travers de la diode dite de roue libre du mosfet A-.
20
2.3.2.2. Partie commande de l’étage de puissance
Afin de pouvoir changer de séquence quand le rotor rattrape le champ tournant du

stator, il faut avoir une information sur la position du rotor. Pour ce faire, certains
moteurs BLDC sont équipés de capteurs de position (par exemple à effet Hall). Dans les
applications aéronautiques, le poids est un facteur limitant ; ont donc été choisis des
moteurs sans capteurs (BLDC sensorless). Ces moteurs peuvent cependant avoir des
démarrages difficiles ou perdre la synchronisation lors du fonctionnement et donc
décrocher.
En réalité, il suffit, pour la commutation, de connaître le moment où le rotor passe par
une position donnée, associée à un angle électrique fixé et connu, et ce pour chaque
séquence. On a vu que pour générer un champ magnétique tournant, il fallait un
enchaînement de 6 séquences de 60° électriques chacune. Si on détecte le passage du
rotor à 30° électriques, on sait qu’il faudra déclencher la commutation 30° électriques
plus tard, en supposant que le rotor met le même temps pour les parcourir que les 30°
précédents.
Il existe un moyen autre que les capteurs pour détecter le passage à 30° du rotor : la
mesure de la force contre-électromotrice (Back EMF). Cette mesure se fait normalement
en mesurant la tension entre le point central N du moteur et la phase non utilisée de la
séquence en cours (phase « en l’air »). Si on n’a pas accès physiquement à ce point (ce
qui est le cas général, et le nôtre) on doit simuler ce point en créant un point au même
potentiel à l’aide de trois résistances en étoile (voir ci-dessous).
Cette solution avec un point neutre virtuel est celle actuellement utilisée sur le
quadricoptère avec les variateurs Toshiba.
Comme spécifié dans la thèse de Jianwen Shao « Direct Back EMF Detection Method for
Sensorless Brushless DC (BLDC) Motor Drives », on peut se passer de la mesure du
potentiel du point central. Cette méthode est détaillée clairement dans la thèse
(disponible dans les documents du projet 2006) qu’il est indispensable de lire.
21
Voici un extrait de l’animation gif « 4-pole-bldc-motor.gif » disponible dans les

documents du projet 2006 qui montre le fonctionnement d’un moteur 4 pôles à noyau
tournant avec capteurs à effet Hall (attention nous avons des moteurs 6 pôles à cage
tournante, sensorless) :
2.3.3. Description des variateurs actuels et limitations
Les variateurs actuels sont constitués, pour la partie commande, de contrôleurs Toshiba
TB9060 et d’amplificateurs opérationnels rapides, et pour l’étage de puissance, de trois
NMOS pour les demi-ponts inférieurs et de trois PMOS pour les demi-ponts supérieurs.
Pour plus de détails, se référer au rapport projet 2005.
Lávantage du variateur Toshiba est quíl est conçu spécialement pour la commande des
moteurs BLDC sensorless. Il suffit de lui envoyer le signal PWM (envoyé dans notre cas
par lÁTMEGA128) qui traduit le régime voulu et il se charge de mesurer la back EMF et
de la commutation (voir schéma électrique du variateur Toshiba en annexe).
2.3.3.1. Limitations des variateurs Toshiba
On peut remarque que cette architecture souffre de certains inconvénients :

• Le Toshiba n’intègre pas les limitations de l’étage de puissance et des moteurs et
n’est pas adapté à l’étage de puissance (nécessité des AO). Il se peut que
lálgorithme central exige des moteurs des régimes très élevés qui les poussent à
consommer énormément de courant, ou des régimes très faibles qui finissent par
les arrêter dóù láugmentation du courant signalée.
• Pas de retour d’informations vers le contrôleur central (ATMEGA128)
• Utilisation du point central virtuel
• Transistors sous-dimensionnés (limités à 6A alors que l’on a besoin de 10A).
2.3.3.2. Diagnostic et tests sur les variateurs Toshiba
Il faut donc faire les tests nécessaires pour voir si lórigine du problème est le moteur ou
le variateur.
Si le problème est dans le moteur (1er point), deux solutions se proposent à nous :
• Remplacer les moteurs brushless sensorless que nous avons par des moteurs
brushless avec les capteurs évoqués (problème de poids).
• Revenir aux moteurs DC à courant continu et chercher des modèles qui puissent
produire la puissance nécessaire (ceci n´était pas le cas lánnée dernière mais il
faut voir si des évolutions sont apparues entre temps).
Dans tous les cas il faut revoir le schéma du circuit du variateur pour ládapter au
nouveau moteur.
22
Si par contre le problème est au niveau de lálgorithme (ce qui est souhaitable car ne
nécessitant pas de changements de composants et donc de carte !), il pourra être résolu
en revoyant les boucles dálgorithmes et modifier les valeurs limites envoyées aux
moteurs !
Une autre solution serait de commander les moteurs en fonction des courants qui leurs
sont nécessaires, c’est à dire de prendre leurs intensités en compte dans les boucles
dáutomatique comme contrainte limitante. Pour ceci il faut pouvoir mesurer leurs
variations en temps réel et de manière très rapide pour que les boucles puissent réagir
avant que les valeurs limites soient atteintes ou dépassées. Ceci impose aussi que le
temps de traitement nécessaire dans les boucles soit beaucoup plus rapide que les
variations de courant elles mêmes.
Pour trancher, la construction dún petit banc déssai : carte portant juste le circuit du
variateur, avec seuls lálimentation et le signal PWM comme entrés, sávère
indispensable. Elle nous permettra en variant nous même le signal PWM de façon
brusque mais calculée de voir la réaction du moteur et aussi de mesurer en fonction des
sollicitations le courant consommé et sa variation. Lídée derrière ça est de simuler le
fonctionnement de Quadri en voyant pour quelles valeurs de PWM, parmi celles qui sont
dans líntervalle utilisé par notre programme, les surintensités apparaissent. Si elles
apparaissent pour des variations brusques du PWM, une solution serait de lisser ces
variations en augmentant líntervalle de temps entre valeur initiale et finale. Si par
contre elles apparaissent même en régime stationnaire ou pour des variations très lentes
du PWM, le problème vient sûrement du Toshiba qui se trompe peut être dans le calcul
de la position. On devra donc soit revenir aux solutions proposées plus haut ou envisager
un autre composant qui serait plus fiable lors des mesures de la Back EMF.
Sur le schéma complet de la carte de lánnée dernière nous avons donc pris la partie
correspondante à un seul circuit de puissance pour un moteur et nous lávons redessiné
sur EAGLE. On ne peut pas malheureusement juste le copier directement car la version
démonstrative de EAGLE dont on dispose génère plusieurs problèmes lorsquón veut
travailler sur le schéma (shematic) copié : refuse de faire des liaisons et de connecter les
nouveaux composants correctement sur les liaisons existantes etc…
Remarque : un régulateur 5V (IC3) a été ajouté à la carte pour assurer lálimentation du

Toshiba à partir des 12V nécessaires pour le moteur, ainsi quún connecteur (J1) pour le
signal PWM, qui sera fourni soit par un générateur de PWM dont on dispose dans le labo
soit par KIT STK500 portant un ATMEGA128 programmé pour lóccasion.
23
• En rouge : L étage de puissance composée de 6 transistors, 3 NPN et 3 PNP

• En Bleu : Le Toshiba.
• En vert : léntrée PWM
• En jaune : Lálimentation 12V
2.3.3.3. Réalisation :
Par un souci de compacité, les composants retenus pour les cartes sont tous de type
CMS, cést á dire de très petites tailles (les résistances font 2 á 3 millimètres de
longueur). En plus, le Toshiba est dúne taille tellement réduite que ses pattes, très
proches les unes des autres sont presque impossibles á souder avec les fers á souder
classiques dont on dispose au Labo LEE, surtout que la plus petite tête disponible est
déjà plus grosse que quelques composants (condensateurs..)
Pour y arriver, on doit donc utiliser toute une autre technique que lántique fer à souder.
Dans le Laboratoire LEE, on dispose dún appareil qui est une sorte de plate forme sur
laquelle lópération se fera dans lórdre suivant :
La carte dénuée de tout composants est posée sur deux petits appuis.
Avec une sorte de seringue, on pose des gouttes de brasure (produit chimique peu
visqueux contenant des graines d´étain). On dispose dúne sorte de pédale en dessous
de la table qui en appuyant dessus permet dénvoyer des pulsations dáir compressé
dans la seringue pour faire sortie le gel.
Une fois quón a mis des gouttes de ce gel sur toutes les traces de pattes des
composants sur la carte, ces derniers sont pris un à un par une sorte dáspirateur à vide
monté sur un bras articulé et placés sur ce gel à leurs endroits. Cette opération est très
facile car il suffit dáppuyer sur le composant pour láspirer et de même pour le relâcher
une fois quíl est á sa place.
Ceci fait, la carte doit être prise avec beaucoup dáttention et placée sur des supports
dans un petit four programmable (voir son guide dútilisation disponible dans la même
salle). La chaleur du four fait solidifie ce gel ce qui soude les pattes des composants à la
carte. Le résultat est impressionnant car même si on a límpression quón en a mis un
24
peu trop et quáinsi deux pattes voisines vont se touchaient, le gel a lávantage de se
contracter lorsquíl se solidifie et le risque dún tel problème est très minime.
Un contrôle avec le microscope est toujours recommandable pour vérifier quand même
que toutes les pattes sont bel et bien soudées á leurs traces sur la carte.
2.3.3.4. Résultats :
Pour tester la carte après lávoir réalisée, le banc déssai suivant a été réalisé :
• En rouge : Lálimentation de 12V. Cella la est limitée en courant sur des paliers
de 0,1 à 2,5 A. Elle est donc très appropriée pour chercher la source du court-
circuit sans risquer dábîmer les composants.
• En noir : La mesure est faite sur la grille du transistor Q4 (voir schéma
électrique).
• En vert : Le générateur du signal PWM, fixé á 16 KHz.
• En jaune : Sur lóscilloscope, on voit le signal carré envoyé par le Toshiba et
amplifié par lÁmpliOp comparateur.
Il faut faire attention à tester les composants électriques séparément, surtout quíl
ságit ici dúne carte de puissance, où des tensions différentes sont à appliquer aux
différents composants et des courants assez élevés circulent dans le pont de transistors.
Un mauvais branchement peut facilement provoquer la mise hors fonctionnement dún
des éléments.
Il Faut donc ouvrir le circuit reliant lálimentation principale au pont (il suffit de gratter
la piste reliant les sources des P MOSFETS à lálimentation), et vérifier que le Toshiba,
les comparateurs génèrent bien les bons signaux en appliquant le PWM (comparer à la
doc du Toshiba). Nous pouvons après remettre la liaison et tester avec le moteur.
25
La partie commande (Toshiba + comparateurs) a été testée avec un PWM à 16KHZ et un

Quartz à 16MHZ (et aussi à 4 MHZ, comme dans léxemple de la Datasheet du
Toshiba). Les grilles des transistors PMOS reçoivent un signal carré comme indiqué dans
la Datasheet.
Malheureusement, lors du test dénsemble, une tension de 1,3V est imposée par le
circuit de puissance aux bornes de lálimentation et un courant allant jusqu´à 8A est
consommé par la carte.
2.3.3.5. Diagnostic
Lórigine de ce problème est clairement un court-circuit causé par lún des points
suivants :
• Les deux pistes +12V et GND se touchent á cause dúne mauvaise réalisation.
• Deux transistors dúne même branche ferment simultanément. Ceci peut avoir
deux origines possibles :
o Les transistors ont fondu de líntérieur lors de la réalisation de la carte à
cause dúne longue exposition à la très haute chaleur dans le four.
o Les signaux de commutation envoyé par le Toshiba aux deux transistors
NMOS et PMOS dúne même branche (une même phase) ne présentent
pas le déphasage nécessaire ce qui implique que pour líntervalle du
temps dans lequel ils se superposent, les deux transistors sont passants au
même temps et donc un court circuit est crée.
2.3.3.6. Démarche pratique :
A láide de la fonction détection de contact avec signal sonore quón trouve sur chaque
multimètre, nous avons fait le tour de toutes les pistes sur la carte. Aucune liaison
directe néxistait entre les pistes dálimentation. Le premier point est donc à oublier.
Les deux entrées de lóscilloscope sont utilisées pour pouvoir regarder deux signaux sur
deux grilles de transistors P MOS de demi ponts différents et vérifier que le Toshiba
envoie bien les signaux de commutations avec le bon déphasage (Voir Datasheet du
Toshiba).
Les signaux affichés sont un peu parasités et non parfaitement stables, une mesure
précise du déphasage directement sur l´écran est difficile à réaliser mais on peut bien
voir quíl existe. Cette hypothèse est aussi à laisser.
Pour voir si les transistors ont craqués, nous avons mesuré à vide la résistance entre
SOURCE et DRAIN (toujours avec le multimètre) sur chaque transistor. Cette résistance
doit théoriquement être infiniment grande.
Les mesures ont donné des valeurs suivantes :
Transistor Q1 Q2 Q3 Q4 Q5 Q6
Vds 1,2MΩ 0,8MΩ 1MΩ 17Ω 0.7MΩ 13Ω
Les valeurs entre 600KΩ et 1MΩ peuvent être pratiquement considérées comme très
grandes ou de lórdre de línfini. On remarque cependant que les valeurs de Q4 et Q6
sont de lórdre de l´Ω !! Ces deux transistors ont donc lâchés.
En fait, lors des tous premiers tests, nous avons eu des problèmes de disfonctionnement
étranges de la carte. Après un certain temps nous nous sommes rendu compte que la
place ces deux transistors étaient inversés. Nous avons utilisés la pince chauffée à très
haute température pour les enlever et nous avons utilisés ensuite le gel de soudure que
nous avons chauffé avec le souffleur dáir chaud pour les fixer après les avoir mis dans
26
les bons emplacements. Ce traitement à haute température qui en plus a duré assez
longtemps a du les détruire. Ceci explique le fait que les autres transistors sont restés
intacts…
Nous avons refait la même procédure mais cette fois pour les changer. En réessayant la
carte, le problème a disparu.
2.3.4. Principe de fonctionnement et architecture des nouveaux

variateurs
Les nouveaux variateurs se basent sur ceux utilisés dans le kit de développement
ATAVRMC100.
La partie commande des nouveaux variateurs est désormais constituée d’un
microcontrôleur par moteur qui communique d’une part avec trois drivers (un par phase)
et d’autre part avec le contrôleur central. Les drivers sont des composants chargés de
transformer les signaux de commande sortant du microcontrôleur en signaux capables de
faire commuter des transistors. Le contrôleur permet de générer un signal de commande
par mosfet, en fonction de la mesure de Back EMF qu’il reçoit et des consignes du
contrôleur central. Le microcontrôleur retenu est un AT90PMW3 qui offre, entre autres, la
possibilité de générer des signaux PWM sur au moins trois voies. De plus c’est un
composant Atmel, comme l’ATMEGA128, ce qui facilite le développement. Pour les
drivers, nous utilisons des IR2101S, conformément au schéma de l’ATAVRMC100.
L’étage de puissance est formé de 6 NMOS par boîtiers de 2. Le fait d’utiliser des mosfets
Dual N a pour objectif un gain de place.
Les fils H_(A,B,C), L_(A,B,C), Hall(A,B,C), V_Shunt(+,-), DAC_OUT et Over_Current sont

connectés aux I\O de même de nom de l’AT90PWM3. Le schéma électronique de
l’environnement du microcontrôleur est disponible en annexe.
27
Les drivers requièrent une alimentation stabilisée : c’est le rôle de la diode D7 (en haut à
gauche) montée à l’envers. Ceci est indispensable lorsque l’alimentation Vbus est la
batterie mais inutile lors des tests où nous utilisons un générateur de tension.
Plusieurs points du circuit doivent être alimentés en 5V, à cette fin nous utilisons un
régulateur de tension 7805 non représenté ici.
La mesure du courant total se fait à l’aide d’une résistance de précision dite résistance
shunt (R18) suivie d’un filtre RC.
La partie en haut à droite correspond à un filtrage des signaux des capteurs avant de les
envoyer vers le microcontrôleur ; puisque nos moteurs n’ont pas de capteurs, cette
partie devrait disparaître. Cependant il se peut qu’il faille « adapter » (adaptation à
définir) les signaux de Back EMF avant de les envoyer vers le microcontrôleur.
Kits STK520 et ATAVRMC100 : protocoles de tests et validation de l’étage de puissance et

du code
Le kit ATAVRMC100 est un kit de développement qui comprend un moteur BLDC avec
capteurs à effet Hall et un variateur complet (microcontrôleur AT90PWM3, drivers et
étage de puissance avec les environnements respectifs). Il est livré avec un programme
flashé dans le contrôleur. Le contrôleur est évidemment reprogrammable, il faut pour
cela le connecter au STK500 avec le bus ISP (voir le Hardware User Guide
ATAVRMC100).
Le kit STK520 est un adaptateur qui permet de monter un contrôleur AT90PWM3 sur le
STK500. Voir les documentations respectives des STK.
Pour l’instant on utilise le compilateur C WinAVR. Lors de la compilation, on a besoin d’un
fichier makefile spécifique différent de celui utilisé par tous les autres groupes du projet :
nous sommes les seuls à utiliser un AT90PWM3, les autres travaillant avec un
ATMEGA128. Il faut en particulier prêter attention aux lignes concernant le type de
contrôleur (MCU name) et la fréquence d’horloge (Processor frequency).
Dans les exemples de code fournis par Atmel, les librairies sont celles utilisées par un
autre compilateur C, IAR. Ces librairies ne sont malheureusement pas toutes compatibles
avec WinAVR. IAR est disponible en version d’essai d’un mois.
Pour pouvoir communiquer avec le processeur monté sur le STK et le programmer, on
utilise AVR Studio (voir manuel utilisateur et le rapport des groupes Capteurs et
Transmission).
Pour l’instant, nous n’avons pas réussi à faire correctement fonctionner le kit
ATAVRMC100. Le programme d’usine du kit permet en théorie de contrôler la vitesse de
rotation du moteur à partir d’un PC. Pour cela, on doit dialoguer avec le microcontrôleur
à l’aide du logiciel terminal.exe ; il faut connecter les ports ISP de l’ATAVRMC100 et du
STK500 (bus ISP) ainsi que les ports Rx et Tx des deux kits. Ensuite il faut connecter le
PC au STK500 sur le port RS232 CTRL. Lorsqu’on a fait cela, le moteur tournait à vitesse
constante, indépendamment des commandes envoyées depuis le PC. Il semblerait que
dans le code flashé sur le kit, la partie correspondant aux instructions de commande soit
entourée de balises de commentaires. Nous n’avons pas pu flasher la version sans ces
balises car WinAVR n’a pas toutes les librairies.
Une des tâches pour l’an prochain est d’écrire un programme pour commander les
moteurs et de réaliser un étage de puissance. Il faut pouvoir valider séparément le
software et le hardware du variateur.
Il s’agit d’une part de valider l’ensemble drivers+ponts de transistors (voir paragraphe
suivant).
D’autre part, il faut valider un code, dans un premier temps en utilisant les capteurs à
effet Hall, puis avec la mesure de la Back EMF. Pour le code avec les capteurs, il suffit de
flasher le programme sur l’AT90PWM3 de l’ATAVRMC100 et d’utiliser ce kit. Pour le code
sans capteur, il faut utiliser hardware précédemment validé, connecté au STK520.
Enfin il faudra interfacer les 4 AT90PWM3 avec l’ATMEGA128.
28
2.3.5. AT90PWM3
Le problème avec les anciens variateurs cést quíls ne prenaient pas en compte les
courants consommés par les moteurs. Ce point sést avéré très gênant puisquón avait
toujours affaire à des augmentation de ces courants pendant le vol qui enclenchaient le
disjoncteur et donc faisaient tomber le Quadricoptère. M. Philippe Martin nous a proposé
de travailler sur un nouvel variateur, lÁT90PWM3. A la différence du Toshiba ce
composant est en fait un petit microprocesseur non préprogrammé et qui possède des
fonctions très développées pour générer des signaux PWM spécifique aux applications de
commande des moteurs BLDC. Il possède aussi une entrée dédiée à la mesure de
courant utilisant les shunts (pour plus de détails voir le descriptif des variateurs plus
haut).
Le plus grand inconvénient est quíl faut savoir mesurer la Back EMF et en déduire la
position du rotor (cette fonction est implantée dans le Toshiba) et dínclure ça dans le
code pour générer la séquence de commutation adéquate.
LÁt90PWM3 dispose de trois sources PWM PSC (Power Stage Control) PSC0, PSC1,
PSC 2
Qui présentent les caractéristiques suivantes :
• Chaque source est en fait composée de 2 sorties différentes, c’est.à.dire 2 pattes
différentes de microcontrôleur (PSC0 et PSC1, le PSC2 possède 4 sorties) mais
complémentaires de PWM. Elles sont bien sur programmables. Cette
implémentation nous donne le choix entre utiliser une seule sortie pour
commander un seul transistor, utiliser les deux sorties pour commander un demi
pont ou utiliser le PSC2 et es 4 sorties pour commander avec un seul PSC un pont
complet.
• Dead Time contrôlable (voir explication plus bas).
• Fréquence allant jusqu´à 64Mhz.
• Prise en compte des événements externes par les PSC inputs (notamment
sensibilité aux intensités de courant).
• Fonction de protection contre lÓverload.
• Fonction de protection contre les anormalités (entré dúrgence pour mettre tous
les outputs en impédance haute ou en mode inactif).
En plus les PSC peuvent être configurés et synchronisés pour commander 3 demi pont,
ce qui correspond exactement á notre application à savoir la commande de moteurs
BLDC.
29
2.3.5.1. Architecture du PSC 0 et 1
Les deux sorties de PSC seront nommées PSCn0 et PSCn1, avec n = 0,1.
A Chaque PSCni (i = 0,1) correspond un générateur PWM proprement dit. Appelant B le
générateur correspondant à PSCn1 par exemple. Ce générateur est relié á deux registres
OCRnRB (R comme Reset) et OCRnSB (S comme Set). Dans ces registres, on va
enregistrer des valeurs à 12 bits.
Registre OCRnB
.Un comparateur va comparer les valeurs de ces registres avec celles livrées par un
compteur (dont la fréquence est programmable). Lorsquíl y a égalité un signal est
envoyé au générateur B : la pulsation envoyée pour l´égalité avec le registre OCRnSB
correspond au début du signal et celle avec le registre OCRnRB correspond à sa fin. Le
signal peut aussi être interrompu ou prolongé suivant les instructions envoyées par le
module du PSCn Input. La forme du signal (High Level ou Low Level peut être définie par
mettre 1 ou 0 le bit « PELEVnx » du registre de control « PFRCnB ».
Chaque PSCn possède en outre 5 registres supplémentaires à 8bits appelés registres de
contrôles : PCNFn, PFRCnB, PFRCnA, PSOCn, PCTLn (le PSC2 possède un registre
supplémentaire appelée POM2).
Architecture interne dún PSC0/1
Ces registres permettent dáccéder aux plusieurs fonctionnalités qui sont implémentées
dans lÁT90PWM. Par exemple :
30
Le registre de contrôle PCTLn :

Bit0 [PRUNn] : permet de enclencher/ arrêter le cycle PWM du PSCn
Bit 6et7 [PPREn1/0] : ils permettent de choisir le PSC Input clock divider (1, 4, 16 ou
64)
Etc.…
Les possibilités offertes sont vraiment très diverses et permettent un contrôle très poussé
et des interventions à tout moment sur le signal PWM de sortie.
Modes de fonctionnement :
Léxistence des 4 registres de comparaison (les OCRnXX) par PSC permettent 4 modes
de fonctionnement possibles (voir figure ci-dessous) :
• one ramp mode
• two ramp mode
• 4 ramp mode.
Le mode qui est recommandé pour la commande de moteur BLDC est par contre le 4ème
mode : le mode centré
Dans ce dernier cas, on a :
On-Time0 = 2*OCRnSA * 1/Fclkpsc

On-Time1 = 2*(OCRnRB –OCRnSB +1)* 1/Fclkpsc
31
Dead-Time = (OCRnSB - OCRnSA) * 1/Fclkpsc
Comme la période du cycle PWM dans tous ces modes est :

T = OT0 + OT1 + DT0 + DT1
On obtient pour le mode centré T = 2*(OCRnRB +1)* 1/Fclkpsc c.a.d un min de 2/
Fclkpsc
La fréquence du signal PWM : Fclkpsc peut etre finement ajustée en utilisant le mode
avancée (Enhanced Mode), la fréquence mesurée est la fréquence moyenne calculée sur
16 cycles, lors de ces cycles deux fréquences voisines Fpll/n (la fréquence la plus proche
en dessous de la valeur souhaitée) et Fpll/n+1 (la valeur la plus proche en dessus) sont
permutées en fonction dún paramètre d suivant la formule suivante :
F moyenne = (16-d/16 *Fpll/n) + (d/16 * Fpll/n+1)

(Pour plus de détails, voir AT90PWM3 datasheet, pages 140/141.)
Fpll est le signal d´horloge reçu dúne horloge interne PLL de 64 Mhz. On peut choisir
entre des fréquences de 64 ou 32 Mhz en configurant le pin PLLF (bit2) du registre
PLLCSR .
On peut aussi choisir léntrée horloge I/O.
Le choix entre PLL ou I/O Horloge se fait en configurant le pin PCLKSELn du registre
PCNFn. On peut ensuite choisir entre 4 diviseurs de fréquence possibles en configurant
les bits PPREn1/0 du registre PCTLn (voir datasheet pages 159/160).
2.3.5.2. Programmation
Lún des avantages théoriques de lÁT90PWM3 est quíl est un produit Atmel, tout
comme lÁTMEGA 128. La programmation de ce microcontrôleur devait etre donc assez
proche de láutre. Le problème, lors de déroulement de la liste des composants Atmel
supportés par le compilateur WIN AVR, notre AT90PWM était bien présent, mais puisque
pour compiler il fallait utiliser un fichier MakeFile, dans lequel il ný a pas la possibilités
de choisir le microcontrôleur. Alors nous n´ étions pas sur que même si on se contentait
de changer le nom du MCU dans le fichier MakeFile, quón pouvait compiler
correctement.
Il faut avouer que comme nous návons aucune idée sur la procédure de compilation, il
nous était impossible de trancher sur la validité du choix de WINAVR comme compilateur,
même en arrivant à compiler et faire marcher des programmes simples, car nous ne
savions pas exactement les différences dárchitectures et donc de registres entre les
deux composants et si ceci pouvait affecter la compilation, puisque à priori le MakeFile
dont nous disposons est spécifique à lÁTMEGA128. Les programmes de tests que nous
avons et que nous étions capables de comprendre à ce stade sont pour allumer et
éteindre des diodes. Ils nútilisent donc que les ports de lÁt90pwm et pas ses registres
intrinsèques.
En plus de ça, les seuls exemples de codes quón peut retrouver sur le site Atmel, sont
des bouts de codes écrits pour le compilateur IAR, pour des raisons historiques de
coopérations et de proximité géographique entre les deux entreprises .
Nous avons envoyés des requêtes à Atmel et AVR pour leurs demander si leurs
composants est supporté par WINAVR en utilisant un MakeFile classique, ils se
contentaient de répondre quíls ne le savaient pas mais quíl fonctionne très bien avec
le compilateur IAR. Nous návons pas par contre remarqué que WINAVR ET AVR étaient
deux entreprises complètement indépendantes. Nous avons estimé donc les réponses
reçues suffisantes pour se lancer dans le travail sur le compilateur IAR. Après que Mr.
Philippe Martin a attiré notre attention sur ce point, une autre requête envoyée à
AVRfreak (www.avrfreaks.net) a fini par nous informer sans pourtant confirmer
certainement, que les dernières versions de WINAVR, c’est à dire à partir du numéro
20060125.
32
Mais le vrai plus dans cette réponse est quén incluant la librairie <avr/io.h>, qui
supporte lát90pwm3 ce qui est le cas pour celle livrée avec la dernière version de
WINAVR, le compilateur va inclure le IO Header file correct pour notre composant en
lisant juste son nom á partir du MakeFile. Nous sommes surs maintenant que nous
pouvons utiliser le WINAVR pour la suite de notre travail.
Le travail investi sur les codes pour IAR n´était pas par contre en vain. Comme ils sont
développés spécialement pour lÁT90PWM3, ils nous permettaient de mieux comprendre
le fonctionnement de notre composant.
Mais le plus grand avantage de lÍAR, et sans lequel nous náurions pas pu écrire notre
code C pour le WINAVR, réside dans ces bibilotheques dont la plupart contiennent de très
nombreuses définitions, très bien commentées dáilleurs, de fonctions qui réalisent les
différentes configurations nécessaires pour générer les signaux PWM pour chaque PSC (la
bibliothèque <psc-drv.h >) ou pour configurer la source PLL (< PLL-drv.h >)
La lecture de la datasheet nous a permis de déduire l’algorithme suivant pour générer un

PWM :
Choisir l´horloge:
PLL ou I/O
Láffecter au PSC
choisi
Choisir la sortie
PSCn0/1
Choisir le type du
signal PWM
Choisir le mode
(1/2/4 rampes, ou
Remplir les registres

OCRnS/R-A/B
Enclencher le cycle
PWM
La traduction de cet algorithme en code se trouve en annexe. Ce code a été flashé sur le
microcontrôleur monté sur le KIT ST500+STK520. Le résultat était un signal PWM de la
fréquence 7.77 KHZ sur les sorties PC0 (PSCOUT10) et PB7 (PSCOUT11).
33
Ce résultat nést bien évidemment quúne première étape dans le travail demandée. La
suite serait de mesurer la back EMF suivant la théorie proposée dans la thèse fournie par
Mr. Philippe Martin :
“Direct Back EMF Detection Method for Sensorless Brushless DC (BLDC) Motor Drives “
Réalisée par Jianwen Shao et présentée á la “Virginia Polytechnic Institute and the State
University “.
• En Bleu : LÁVR Studio4 est utilisé pour flasher le fichier « main.hex » crée par le
compilateur WinAVR à partir du code C.
• En Vert : le signal PWM mesuré sue le pin PC0. Pour les valeurs utilisées dans le
code source (voir annexe), on obtient une fréquence de 7.77KHZ.
2.3.6. Carte de test de l’étage de puissance
Nous avons réalisé une carte de test destinée à la validation du hardware du variateur
(drivers+mosfets). Elle a été réalisée sous Eagle : voir schéma électronique, routage et
schéma d’implantation en annexe. Les fichiers sources (.sch et .brd) sont disponibles
dans les documents du projet 2006. Pour générer une tension de 5V, nous utilisons un
régulateur de tension 7805 monté avec une capacité de 1µF en parallèle sur l’entré et
une identique sur la sortie. Cela nous permet de supprimer les capacités de lissage C6 et
C15, en parallèle de la capacité en sortie du régulateur, et C5, C8 et C14, en parallèle de
celle d’entrée du régulateur.
Cette carte permet une utilisation avec ou sans capteurs à effet Hall, pour des courants
allant jusqu’à 4A. Le calcul de la largeur de piste pour un courant maximal donné se fait
à l’aide d’abaques (voir graphique en annexe). Les pistes des cartes réalisées au LEE font
35µm d’épaisseur, alors que celles de la carte présente sur le quadricoptère, sous-traitée
à l’extérieur, font 70µm d’épaisseur.
Voici la carte de test réalisée, avec le moteur du kit ATAVRMC100 :
34
Les cinq fils rouges connectent la carte de test à une carte servant d’adaptateur pour
l’amplificateur opérationnel : nous n’avons pas reçu l’AO LMV7219M5 en boîtier SOT23-5,
nous l’avons remplacé provisoirement par un AD8051AR en boîtier SO-8.
Voici les deux faces de la carte :
Carte de test vue de dessous
35
Carte de test vue de dessus
2.3.7. Protocole de validation
Avant de tester l’ensemble de la carte, il sera préférable de tester les parties

« indépendantes » afin de valider le hardware. Ainsi pour chaque driver on testera
successivement les voies haute et basse en envoyant un signal PWM connu sur une
entrée d’un driver et en vérifiant que le mosfet associé commute en conséquence. Une
fois ceci fait, on peut tester l’ensemble de la carte en l’utilisant comme hardware d’un
programme validé su l’ATAVRMC100 (programme d’usine ou autre), en le connectant au
STK500 comme sur la photo suivante :
Lors d’un test optimiste, nous avons connecté toute la carte sans avoir validé les sous-
éléments, en utilisant le code d’usine de l’ATAVRMC100 : un mosfet a pris feu. D’où
l’importance de tester les sous-parties et d’utiliser un code opérationnel.
36
3. CAPTEURS
Le détail des objectifs de groupe est détaillé dans ce tableau :
GROUPE CAPTEUR
% NIVEAU TEMPS
OBJECTIFS - Liste des taches LIVRABLE
AVANCEMENT DIFFICULTE CONSACRE
Prise en main de l'ATMEGA
Première lecture de la doc de l'ATMEGA 100% ++ 10
Branchements du kit de développement 100% + 2
Installation des logiciels nécessaires pour flasher

le microcontroleur (attention logiciels différents
100% - 2
selon le kit de développement utilisé: STK 300 ou
STK 500)
Apprendre à flasher des programmes sur le
100% + 4
microcontroleur du kit de développement
Ecriture de programmes simples pour

s'entraîner à flasher le microcontroleur, et
100% 10
pour mieux comprendre le fonctionnement
de l'ATMEGA:
-> Programme permettant d'allumer les programme
100% ++
LEDS du kit de développement test
-> Programme avec une boucle qui fait programme
100% ++
clignoter les LEDS (utilisation de la fonction delay) test
-> Utilisation des boutons en entrée pour programme
100% ++
commander l'allumage des LEDS test
MIDGII
Prise de contact avec la liaison série UART 100% + 2
Installer et apprendre à utiliser les programmes

permettant de réceptionner des données sur la
100% - 1
liaison série: hyperterminal, Portmon, Terminal
v1.9b
Ecriture de programmes simples utilisant la
4
liaison série:
-> programme qui envoie une donnée en
programme
continu sur la liaison série, réception de cette 100% ++
test
donnée sur le PC.
Prise de contact avec la Midg II (visite du site du
constructeur, lecture des docs: notamment
message specification qui permet de connaître le 100% + 3
contenu des différents messages envoyés par la
MidgII.
37
Branchement direct Midg II - PC grâce à un

2
adaptateur MidgII-PC
-> Installation du logiciel fourni par
100% -
Microrobotics pour visionner les données reçues
-> Réglage grâce au logiciel des
messages effectivement envoyés par la MidgII, de 100% +
la fréquence de ces messages… etc
-> Test de réception du GPS 100% -

Branchement de la Midg II sur le kit de
développement (utilisation de deux liaisons
séries UART0 et UART1, l'une pour la
transmission Midg II -> kit de
développement, l'autre pour la transmission
kit de développement -> PC
-> Compréhension grâce aux docs du
100% + 3
protocole d'envoie de données de la Midg II
-> Ecriture d'un programme permettant
la récupération des messages envoyés par la Midg
II au microcontroleur. Ce programme permet programme
100% +++ 5
également de retirer du message envoyé les test
données utiles et exploitables pour la boucle
d'asservissement.
Perturbation magnétique des capteurs par le

Rapport
fonctionnement des moteurs
-> définition du problème 100% + 1
-> relevé des mesures des capteurs de la

MIDG II pour analyser leurs perturbations pour 100%
différentes vitesses des moteurs
-> interprétation des résultats 100%
Capteurs Ultrasons
Prise de contact avec le protocole I2C 100% + 3
Prise de contact avec les capteurs utilisés

100% + 3
(SRF10): documentation du capteur sur Internet
Compréhension du message envoyé par le
100% ++ 3
capteur
Compréhension du programme existant pour
récupérer le message sur le microcontroleur et en 100% +++ 5
extraire les données utiles
Commentaires des programmes existants pour code
100% + 2
qu'ils soient plus faciles à comprendre commenté
Test d'un capteur ultrason grâce au programme

de récupération des données, récupération des 100% rapport ++ 3
données sur le PC grâce à la liaison série
Ecriture d'un programme permettant de changer
100% programme +++ 4
très facilement l'adresse d'un capteur
Détection d'obstacles:
-> Définition de notre besoin 100% + 2
38
-> Branchement de 2 capteurs ultrasons sur

100% + 2
le bus I2C
-> Ecriture d'un programme permettant de
récupérer les données envoyées par les 2 100% programme +++ 4
capteurs ultrasons.
-> Test de ce premier programme,
100% rapport ++ 2
interprétation des résultats
-> Ecriture d'un programme plus joli,
configurable, pour récupérer les données 100% programme +++ 5
envoyées par n capteurs ultrasons
-> Définition d'un premier protocole
expérimental de test pour 3 capteurs ultrasons, 100% rapport ++ 2
placés dans trois direction orthogonale.
-> Cablage des trois capteurs (soudure des
fils adéquates, utilisation d'une d'essai 100% + 2
électronique)
-> Montage de trois capteurs sur une
structure de test ressemblant à celle du 100% + 2
quadricoptère
relevé de
-> Première campagne de mesures 100% + 8
mesures
-> Interprétation des résultats 100% rapport ++ 2
-> Ecriture de deux autres programmes

pour l'utilisation de n capteurs: l'un tel que les US
soient lancés les uns après les autres, un autre tel programme
100% +++ 8
que tous les US soient toujours relancés en même s
temps dès que le plus lent a fini (en général
toutes les 60 ms)
-> Définition d'un protocole expérimental de
test pour 3 capteurs ultrasons plus précis que le 100% rapport ++ 4
précédent et utilisant les nouveaux programmes
-> Campagne de mesure précise pour
évaluer les véritables performances des 3 relevé de
100% +++ 10
capteurs, et permettant de valider son opérabilité mesures
pour répondre à notre besoin.
-> Interprétation des résultats 100% rapport +++ 5
39
3.1. Prise en main ATMEGA
3.1.1. Lecture de la documentation
Cette documentation est donnée en document pdf ATmega128(L) Complete. Cette

documentation nous a énormément servi tout au long de l’année. Il est important de la
survoler une fois au début pour au moins être au courant de ce qu’elle contient.
3.1.2. Kit de développement et logiciels utilisés
Pendant l’année nous avons utilisé deux kit de développement : un stk 500 puis un stk
300.
La principale différence entre les deux kits est que le 300 ne contient qu’un port UART,
tandis que le stk 500 en contient deux. Comme cela est détaillé dans la partie centrale
inertielle, pour certains tests effectués avec la MIDGII, deux ports UART sont
nécessaires, il est donc nécessaire d’utiliser le stk 500. En revanche pour tout ce qui
concerne la partie sur les capteurs ultrason le stk 300 est tout à fait utilisable.
Les deux types de kit de développement n’utilisent pas les mêmes logiciels pour flasher
le microcontrôleur. Avec les stk 500 on utilise AVR Studio, tandis qu’avec les stk 300 on
utilise Pony Prog.
En ce qui concerne les branchements du kit de développement en lui-même, tout est

indiqué dans la doc. Il est nécessaire de connecter certains pins avec d’autres par
l’intermédiaire de fils, notamment pour le port UART.
3.1.3. Flasher un programme sur le microcontrôleur
Description rapide de comment flasher un programme sur le microcontrôleur :

• écriture d’un programme en langage C à l’aide du logiciel programmer notepad
• pour pouvoir effectuer la compilation du programme il faut qu’il soit appelé main.c
et que dans le même dossier que le main.c soit présent le makefile. Il s’agit d’un
fichier que l’on pourra également trouver sur le cd contenant les données de cette
année.
• dans le logiciel programmer notepad, il faut réaliser la fonction make all.
• Une fenêtre s’affiche alors en bas dans laquelle est indiqué si la compilation s’est
bien déroulée ou bien si le programme contient des erreurs. S’il contient des
erreurs, il faut les corriger, et recommencer la compilation, jusqu’à ce que tout se
passe bien et que la compilation soit réalisée.
• cette étape de compilation crée dans le dossier contenant le makefile d’autres
fichiers dont un .hex.
• Il faut ensuite flasher ce .hex sur le microcontrôleur par l’intermédiaire du logiciel
adéquat (AVR Studio pour un stk 500, Pony Prog pour un stk 300).
• Si cette étape se passe sans problème, le programme est alors flashé sur le
microcontrôleur.
3.1.4. Information importante quand à l’utilisation des portables IBM
Attention ! Pour faire fonctionner le port parallèle d’un portable IBM / Lenovo avec
Ponyprog, il faut configurer ce port (imprimante / LPT) dans le bios du PC. Vérifier qu’il
est configuré en « ECP » ou « EPP » mais surtout pas en « bi-directional » ! Cette
remarque peut être valable pour d’autres PC.
40
3.1.5. Apprendre à programmer en langage C
Pour nous initialiser à la programmation en C, nous avons réalisé de petits programme

très simple : Allumer des leds, faire clignoter des leds, utilisation des boutons en
entrée…etc.
Nous nous sommes également aidé d’un TP trouvé sur Internet, appelé TP
microprocesseur ATMEL - Programme en C et dans lequel on nous apprend à réaliser des
programmes très simple. Ce TP peut être téléchargé à l’adresse suivante :
http://www.ac-orleans-tours.fr/sti-gel/MICROCONTROLEUR/AVR.HTM
Mais il sera également présent sur le cd dans la partie capteur.
Une fois réalisé ces petits programmes, on a alors pu commencer à essayer de

comprendre les diverses parties du code source concernant la partie capteur. Ces codes
sont détaillés et expliqués dans les parties Centrale Inertielle et MIDG II dans la suite de
ce rapport.
41
3.2. La centrale inertielle – MIDGII
3.2.1. Fonctionnement de la centrale inertielle
3.2.1.1. La MIDG II et ses capteurs
La centrale inertielle utilisée sur le quadricoptère est la MIDG II. La MIDG II est un
système de navigation à inertie (INS) incluant un GPS, le tout formant un ensemble
incroyablement compact. Elle est idéale pour toute application qui requiert une solution
de navigation à inertie.
Le site internet du constructeur http://microboticsinc.com est relativement complet. Il

décrit les différents dispositifs inclus dans le boîtier ainsi que l’interface de
communication.
La MIDG II inclut 3 magnétomètres, 3 accéléromètres, 3 gyroscopes ainsi qu’une

antenne GPS. Avec tous ces capteurs, cette centrale est capable de délivrer toutes ces
informations :
Attitude : tangage, roulis, lacet

Accélérations angulaires
Vitesses angulaires
Cap : position du nord
Vitesses par rapport au sol (GPS requis)
Position au sol (GPS requis)
L’antenne GPS permet d’avoir la position de la centrale au sol. C’est en dérivant cette
position que la centrale calcule le vecteur vitesse (c’est pour ça qu’il arrive qu’on ait une
dérive sur le vecteur vitesse). Dans le logiciel de configuration de la MIDG II (voir plus
bas), on peut configurer la façon dont la centrale va retourner les valeurs.
Actuellement, elle est configurée en mode ENU (East North Up). C’est donc les deux
premières coordonnées qui sont intéressantes. La centrale renvoie les données en
centimètres. Cette précision est absurde dans le sens où une antenne GPS n’arrivera
jamais à une précision plus fine qu’1 mètre. Retirer les 2 bits de poids les plus faibles
(voir plus bas) est donc tout à fait envisageable.
La documentation du constructeur est assez pauvre en ce qui concerne la fusion des

données de ses capteurs. Ce n’est toutefois pas très grave dans la mesure où les
résultats qu’elle fournit sont tout à fait satisfaisants.
42
3.2.1.2. Le port UART et les messages envoyés par la MIDG II
La MIDG II est connectée à l’ATMega par un des ports UART. Le port UART est aussi
appelé port série. Le port UART est beaucoup plus simple à utiliser que le port I²C.
Quand un message (un octet) arrive sur le port UART, il arrive dans le registre UDR0
(pour le port UART 0, UDR1 pour le port UART1). De plus quand un octet est copié dans
ce registre, l’interruption SIG_UART0_RECV est appelée.
SIGNAL( SIG_UART0_RECV ) //s'active quand un byte du message de la midg II

arrive sur l'uart 0
{
volatile char c = UDR0; //copie le byte du message qui est arrivé
}
C’est tout ce qu’il faut savoir sur la réception d’un octet par le port UART. Pour ce qui est
de la transmission sur ce port, voir la partie « transmission ».
La MIDG II est configurée pour envoyer les données à la vitesse de 57600 bauds.
La MIDG II envoie à intervalles réguliers des messages (50Hz par défaut, configurable
dans le logiciel de configuration). Ces messages contiennent les mesures de la centrale
(vitesse, attitude, position etc.). Au total elle peut envoyer 13 messages différents.
Actuellement 3 messages sont envoyés au microcontrôleur (messages 2, 10 et 12). Pour
voir à quoi correspondent exactement ces messages il faut lire sur la page du
constructeur (http://microboticsinc.com/ins_gps.html) la partie MIDG II Message
Specification.
3.2.1.3. Le logiciel de configuration de la MIDG II
Sur le site du constructeur, le logiciel est dans la catégorie MIDG II INS/GPS Software.
Une fois installé, il faut configurer le bon port série et le bon débit (57600 bauds par
défaut). Dans le menu Options -> MIDG Config. Appuyer sur « Set » pour appliquer les
modifications puis « Save configuration » pour flasher la MIDG II (et donc pouvoir
rebooter la centrale sans perdre les modifications)
Ce logiciel permet aussi d’avoir les informations sortantes de la centrale. Ne pas oublier
qu’il faut être en extérieur pour faire fonctionner l’antenne GPS.
3.2.1.4. Le code source utilisé
Le code source utilisé et commenté est attaché en annexe 1.
3.2.2. Tests effectués
3.2.2.1. Perturbations liés aux moteurs
Nous avons voulu voir quelle était l’influence de la rotation des moteurs sur les
magnétomètres de la MIDG II. En effet, la MIDG II utilise les magnétomètres pour
trouver le cap et calculer l’attitude du quadricoptère et les moteurs gérèrent des champs
magnétiques qui se superposent au champ magnétique terrestre.
Le teste est relativement simple à mettre en œuvre :
On accède aux 3 valeurs du champ magnétique mesuré par le logiciel de la MIDG II
On alimente les moteurs par une alimentation externe (on ne peut pas utiliser le
quadricoptère normalement car la MIDG II est déconnectée de l’ATMega)
43
Les valeurs obtenues sont les suivantes :
Moteurs éteints
Moteurs allumés
Les 3 courbes représentent les 3 coordonnées du champ magnétique. Z en bleu, X et Y

en vert et rouge.
44
On voit qu’il y a effectivement des perturbations. Toutefois, l’amplitude des oscillations

reste faible et la valeur moyenne des champs reste la même. On en a donc conclu qu’on
pouvait continuer à se fier aux valeurs retournées par la centrale.
3.2.2.2. Position GPS
Les données de position GPS n’était pas utilisées par le code source actuel. Pour faire du
pilotage totalement automatique, nous allons avoir besoin de la position GPS délivrée par
la centrale.
Ces données sont contenues dans le message 12. Chaque coordonnée est codée sur 4
octets. La précision est du centimètre. Toutefois la précision de n’importe quel système
GPS n’est jamais meilleure que le mètre. On peut donc tout à fait envisager de ne garder
que 2 octets parmi les 4. On peut donc réduire la précision (en enlevant quelques bits de
poids faibles) et réduire la valeur max (pour ne garder qu’un maximum de quelques
kilomètres en enlevant des bits de poids forts).
Les tests ont été effectués en extérieur, ils étaient tout à fait satisfaisants. En fait, nous
nous sommes rendu compte que la centrale se sert de l’antenne GPS et de ses
accéléromètres pour calculer sa position. Entre 2 mesures GPS, la centrale arrive donc à
donner une valeur plus ou moins précise en permanence de sa position. Elle arrive en
particulier « deviner » sa position même lors d’un passage sous un arbre (antenne GPS
masquée).
Le système de coordonnées ENU permet d’avoir directement les valeurs East et North,
qu’on peut donc utiliser en valeurs X et Y.
Dernier point, actuellement, la centrale est configurée pour donner sa position en

fonction de la position à laquelle elle a effectuée sa première mesure GPS. C’est donc une
position relative à la position de son allumage qu’on obtient. A chaque allumage, elle
remet son « zéro » à jour.
3.3. Capteurs ultrasons
3.3.1. Le capteur SRF10
Fonctionnement, documentation
3.3.1.1. Documentation
Les capteurs utilisé sur le quadricoptère est un capteur à ultrasons nommé SRF10 de la
marque robot-electronics. Nous avons choisi ce capteur car il était déjà utilisé sur le
quadricoptère existant en tant qu’altimètre. Il existait donc déjà un code source
fonctionnel et le capteur était réputé pour marcher correctement.
45
La documentation du capteur est disponible sur cette page web : http://www.robot-

electronics.co.uk/htm/srf10tech.htm. Elle présente rapidement son fonctionnement,
quelques informations sur les performances et comment l’utiliser avec un protocole I²C
(appelé aussi TWI : Two-Wire Interface)
Cette documentation était cependant largement incomplète selon nous. Si le

fonctionnement du capteur est à peu près bien expliqué, ses performances sont
inconnues (de l’aveu du constructeur lui-même, elles dépendent trop de l’environnement)
et son utilisation avec un bus I²C est complètement incompréhensible si on ne maîtrise
pas un minimum ce protocole.
3.3.1.2. Branchements
Le capteur présente 5 connecteurs. Comme indiqué sur le schéma ci-dessus, il y a une

pin masse, une pin 5v et deux pins SDA et SCL (bus I²C). La 5ème pin ne sert à rien. Il
faut donc souder des fils sur ces pins pour les connecter où ou veut (sur le quadricoptère,
sur un kit de développement …)
3.3.1.3. Fonctionnement du capteur
Pour faire une mesure avec ce capteur, il faut procéder en 2 étapes. Demander au
capteur de démarrer une mesure puis, une fois la mesure effectuée, demander au
capteur de renvoyer la mesure.
Lors du démarrage d’une mesure, le capteur envoie une impulsion ultrason. Pendant
l’envoie, il « n’écoute pas » pendant un court instant pour éviter d’entendre le son qu’il
vient de produire. Puis, il se met en mode « écoute » pour capteur le premier écho qui
reviendra sur le capteur.
Etant donné que plus l’écho met du temps à arriver, plus il est susceptible de venir de
loin, l’intensité sonore de l’écho sera donc de plus en plus faible au fur et à mesure que le
temps passe. Le capteur va donc automatiquement augmenter le gain de l’écoute pour
détecter l’écho qui sera plus faible.
C’est un point important car on peut régler le gain maximum du capteur (lors de son
initialisation, voir plus loin) pour éviter de capter des échos trop faibles qui sont
susceptibles d’être des échos parasites. De tels échos parasites peuvent provenir d’autres
capteurs ultrasons ou d’une réflexion sur plusieurs objets.
Il y a donc deux points importants à retenir ici :
Le capteur ne verra que l’objet le plus proche : seul le premier écho est enregistré.
Régler le gain maximum permet de limiter la détection d’échos parasites
3.3.2. Protocole I²C
Le capteur SRF10 est fait pour fonctionner avec un microcontrôleur et ils communiquent
entre eux sur le bus I²C. Il faut donc comprendre comment marche ce bus.
Nous avons trouvé un site très clair expliquant ce protocole : http://www.planete-

sciences.org/robot/ressources/electronique/protocoleI2C/index.html. Il est *fortement*
conseillé de le lire et de bien le comprendre pour la suite.
Tous les périphériques sont branchés sur le même bus (i.e. : sur les même deux fils). On
peut donc brancher facilement les 6 capteurs ultrasons requis pour la détection
46
d’obstacles (voir plus bas). Tous les périphériques ont une adresse (0xE0 par exemple).
Cette adresse permet au maître de définir à quel périphérique il parle.
Bien que ce tutorial soit un bon départ pour comprendre le protocole I²C, nous nous
sommes rendu compte que ce n’était pas suffisant. En effet, nous avons dû regarder le
code source des années passées, et faire de multiples essais sur le kit de développement.
Prenons un exemple pour illustrer ce protocole. Pour demander à un capteur ultrason

d’effectuer une mesure (un « ranging »), on doit écrire dans le registre n°0 du capteur la
valeur 0x51 (ceci permet de définir que le résultat sera donné en centimètres). On doit
alors faire les actions suivantes à partir d’un ATMega sur le bus I²C :
Envoyer un START sur la ligne

Attendre l’envoie du START
Envoyer l’adresse du capteur à commander (par exemple 0xE0) + Write. Le write précise
au capteur que l’on va écrire dans un registre.
Attendre l’acknowledge (ack) de l’esclave (ici le capteur)
Envoyer le numéro du registre dans lequel on souhaite écrire. Ici on veut écrire dans le
registre 0. On peut donc soit envoyer 0x00 soit un message vide. C’est pareil.
Attendre l’ack de l’esclave
Envoyer 0x51 (pour demander un ranging et un résultat en centimètre)
Attendre l’ack de l’esclave
La mesure est envoyée. Après un certain temps (60ms max), on peut demander au
capteur de renvoyer le résultat. C’est une deuxième manipulation expliquée dans le code
source.
Il y a deux registres important à connaitre sur l’ATMega :
TWDR : (Two-Wire Data Register) registre où se situe l’information (1 octet) que l’on
veut envoyer. On doit y copier l’information avant de l’envoyer.
TWCR : (Two-Wire Control Register) registre qui permet d’effectuer une action sur le bus
I²C. Les 8 bits correspondent à des actions différentes :
TWINT : autorise les interruptions
TWIE : active les interruptions
TWEN : active l’interface I²C
TWSTA : envoie un start
Voici le code source associé à cette manip. Il faut savoir que ce bout de code est inclus
dans une interruption dont le « case » s’incrémente à la fin de chaque appel de cette
interruption.
// -- START RANGING SRF10_1 --

case 0: // ranging
switch (TW_STATUS) // TW_STATUS = TWSR avec les bit 3 à 7 seulement.
Voir la librairie compat/twi.h et la doc de l'ATMega pour plus d'info
{
case TW_REP_START: // OK, now send SLA+W
TWDR = SRF10_1 | TW_WRITE;
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWIE);
break;
default: // restart ranging
I2cState = 0;
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWIE) | _BV(TWSTA);
break;
}
break ;
case 1:
switch (TW_STATUS)
47
{
case TW_MT_SLA_ACK: // OK, now send register number
break;
I2cState = 0;
break;
}
break ;
case 2:
switch (TW_STATUS)
{
case TW_MT_DATA_ACK: // OK, now send ranging command
TWDR = 0x51; // range in centimeters
break;
I2cState = 0;
break;
}
break ;
case 3:
switch (TW_STATUS)
{
case TW_MT_DATA_ACK: // OK, now start MT mode
break;
default: // restart get range, MT mode
I2cState = 3;
break;
}
if (premier_cycle_I2c == 1)
{
I2cState = 10;
premier_cycle_I2c = 0;
}
break ;
Le reste du code source est expliqué plus bas (notamment pour l’initialisation et pour la
boucle complète de dialogue avec les capteurs).
Il y a quelques caractéristiques à retenir pour le bus I²C :
On n’utilise que 2 fils (SCL et SDA).

On peut brancher une grande quantité de périphériques en même temps sur ce bus.
On ne parle qu’à un périphérique à la fois.
3.3.3. Code source utilisé
3.3.3.1. Fonctionnement de l’ancien code
Nous allons décrire comment marchait la boucle d’interruption correspondant aux

ultrasons présente dans l’ancien code source utilisé sur le quadricoptère. En effet nous y
avons effectué quelques modifications (branchement de plusieurs capteurs, plusieurs
mesures simultanées), mais le fonctionnement général reste le même
48
SIGNAL(SIG_2WIRE_SERIAL)
{
static uint8_t led_controle;
volatile static uint16_t sonar_1;
switch (I2cState)
{
// -- START RANGING SRF10 --
case 0: // ranging
{
TWDR = SRF10 | TW_WRITE;
break;
I2cState = 0;
break;
}
break ;
case 1:
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
case 2:
switch (TW_STATUS)
{
TWDR = 0x51; // range in centimeters
break;
I2cState = 0;
break;
}
break ;
case 3:
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
break ;
// -- Lecture de la mesure de SRF10 --
49
case 4:
switch (TW_STATUS)
{
TWDR = SRF10 | TW_WRITE;
break;
I2cState = 3;
break;
}
break ;
case 5:
switch (TW_STATUS)
{
TWDR = 2;
break;
I2cState = 14; // SRF10_1 non pret. va essayer SRF10_2
break;
}
break ;
case 6:
switch (TW_STATUS)
{
case TW_MT_DATA_ACK: // OK, now send rep start
break;
I2cState = 3;
break;
}
break ;
case 7: // get range, MR mode

switch (TW_STATUS)
{
case TW_REP_START: // OK, now send SLA+R
TWDR = SRF10 | TW_READ;
break;
default: // restart get range, MR mode
I2cState = 7;
break;
}
break ;
case 8:
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWIE) | _BV(TWEA);
break ;
case 9:
//Read high Byte
sonar = TWDR;
if (sonar_1==0xFF) {LED2on;} else LED2off;
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWIE);// | _BV(TWEA); //pas de TWEA
pour dernier octet
break ;
case 10:
50
//Read low Byte

I2cState= -1 ; //retourne au case 0 au prochain appel de l’interruption
sonar = (sonar<<8) + TWDR;
gsonar = sonar;
if (led_controle++<64) LED0on;
else {LED0off; if (led_controle==128) led_controle=0;}
break ;
}
I2cState++;
return;
}
Ce code source peut sembler assez indigeste au premier abord. Il n’est pourtant pas
compliqué.
Il faut savoir qu’à chaque fois qu’il y a de l’activité sur le bus I²C, l’interruption
SIGNAL(SIG_2WIRE_SIGNAL) est activée. A ce moment, le programme va dans le
« case » correspondant à la valeur contenue dans I2cState. Au départ, cette valeur est à
0. Le programme ira donc dans le case 0 en premier. Il le traite, saute tout les autres,
incrémente I2cState (via le I2cState++) et sort de l’interruption.
Au prochain appel de l’interruption, il sautera le case 0, ira dans le case 1 et sautera tous
les autres, etc. …
Le principe de lecture d’une mesure est le suivant :
Envoyer l’adresse du capteur + W (pour écrire dans le registre)

Attendre l’ack
Envoyer 2 (pour écrire dans le registre 2)
Attendre l’ack
Envoyer un start
Attendre l’envoie du start
Envoyer l’adresse du capteur + R (pour lire le registre)
Attendre l’activité sur le bus I²C (le capteur envoie le premier octet de la mesure)
Lire ce qui est arrivé dans le registre TWDR (mettre dans « sonar »)
Attendre une autre activité (le capteur envoie le second octet)
Lire le second octet et l’associer au premier pour former la valeur de la mesure sur 2
octets.
On voit donc qu’il y a 2 grands blocs dans ce code :
Envoie ranging
Lecture mesure
3.3.3.2. Algorithme permettant de faire fonctionner n capteurs en même

temps sur le même port I²C
Brancher plusieurs capteurs sur le quadricoptère est nécessaire si on veut faire de la

détection d’obstacles. Au final, le but serait de brancher 6 capteurs au total :
1 en dessous pour l’altitude

1 en dessous de chaque moteur pointant vers l’horizon (donc 4 au total)
1 au dessus (à coté de l’antenne GPS) pour le cas où le quadricoptère de retrouverait
sous un toit ou autre obstacle au dessus.
51
La détection d’obstacles est détaillée plus bas.
Dans cette partie, nous ne mettons pas le code entier (par soucis de clarté). Il n’y aura
que des bouts. Les codes sources entiers se trouvent en annexe.
Bout de code à mettre au début du code source :
#define nombre_capteurs_us 2 //nombre de capteurs utilisés

volatile uint8_t adresse_capteur_us[nombre_capteurs_us] = {0xE0, 0xE8}; //tableau
regroupant les k adresses des k capteurs
volatile uint16_t gsonar_new[nombre_capteurs_us]; //tableau regroupant les mesures
des capteurs
Point important : pour des raisons qui nous échappent, certaines valeurs d’adresse pour
les capteurs US sont inutilisables avec les codes détaillés plus bas. Selon la doc du
constructeur, les adresses disponibles sont 0xE0, 0xE2 … 0xFE. C'est-à-dire toutes les
adresses paires entre E0 et FE. Les adresses inutilisables sont les E2, E6, EA etc. On doit
donc utiliser les adresses paires et en plus, une seule sur deux.
Typiquement, les adresses à utiliser sont les E0, E4, E8, EC, F0, F4, F8 et FC (ce qui est
suffisant pour brancher 6 capteurs)
3.3.3.3. Code 3 : faire fonctionner les capteurs les uns après les autres
Code complet en annexe 1
La première idée pour faire fonctionner n capteurs sur le quadricoptère est de les faire
fonctionner les uns après les autres. On prend simplement le code précédent, et on
change l’adresse du capteur quand on veut passer au capteur suivant.
{
volatile static uint16_t sonar;
switch (I2cState)
{
// -- START RANGING SRF10_k --

case 0:
switch (TW_STATUS)
{
TWDR = adresse_capteur_us[k] | TW_WRITE;
break;
I2cState = 0;
break;
}
break ;
[case 1 à 9]
case 10:
I2cState= -1 ; //repasse au case 0 au prochain appel de l’interruption
gsonar_new[k] = sonar;
52
k ++;
if (k == nombre_capteurs_us)
{
k = 0; //Retour au premier capteur quand on a fini le dernier
}
break ;
}
I2cState++;
return;
}
A la fin du case 10, on incrémente le compteur pour passer au capteur suivant.
Les valeurs sont stockées dans la liste gsonar_new. On accède donc à l’altitude par
gsonar_new[0] par exemple.
Ce code a l’avantage d’être très flexible. Pour changer un capteur, il suffit de changer
l’adresse correspondante dans la liste adresse_capteur_us. Pour en rajouter un, on
change la valeur de nombre_capteurs_us et on rajoute l’adresse dans la liste des
adresses. Il n’y a donc qu’un ou deux paramètre à changer dans le début du code.
Avantage :
Aucune perturbations possible puisque les capteurs n’envoient jamais d’impulsion en
même temps
Inconvénient :
Code lent. Mettre 2 capteurs à la place d’1 rend des mesures qui se rafraîchissent deux
fois plus lentement. Cela peut causer des problèmes dans l’asservissement.
3.3.3.4. 2 autres algorithmes pour faire plus rapidement des mesures

avec plusieurs capteurs
Code 2 : lancer les rangings de tous les capteurs en même temps
Code complet en annexe 2
Ce code a pour but de lancer les mesures de tous les capteurs présents en même temps.
L’idée derrière ça est d’accélérer le rafraîchissement des données sans pour autant créer
de perturbations. En effet, si tous les capteurs lancent leurs mesures en même temps, ils
ne capteront pas le son produit directement par les autres capteurs. Ils peuvent
cependant capter des échos provenant des autres capteurs.
En pratique, bien que le code soit effectivement plus rapide, on a vite vu que les
perturbations étaient présentes et qu’il fallait y faire attention. Ceci est détaillé plus bas,
dans la partie sur la détection d’obstacles.
Le principe de ce code est de faire les cases 0 à 3 pour tous les capteurs, puis les cases 4
à 10 pour tous les capteurs, dans l’ordre.
{
switch (I2cState)
{
53

case 0: // ranging
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
[case 1 et 2]
case 3:
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
I2cState = -1;
k ++;
{
I2cState = 3; //On passe à la phase de lecture des mesures
uniquement lorsque l'on a lancé le ranging des k capteurs
}
break ;
// -- Lecture de la mesure de SRF10_k --

case 4:
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
break ;
[case 5 à 9]
case 10:
I2cState= 3 ;

54
k ++;
{
I2cState= -1 ; //On relance le ranging de tous les capteurs
quand on a récupéré les mesures des k capteurs
}
break ;
}
I2cState++;
return;
}
Avantage :
Perturbations à priori moins probable (mais présentes selon nos tests)
Code assez rapide. Il sera ralenti par le capteur le plus long. Par exemple, si un capteur
pointe l’infini (il aurait mis 60ms pour renvoyer la valeur infinie), la fréquence de
rafraîchissement des données sera de 60ms.
Inconvénient :
Perturbations en pratique
3.3.3.5. Code 1 : lancer des ranging dès que possible pour chaque
capteur individuellement.
Code complet en annexe
Dans ce code, on fait en sorte de gérer tous les capteurs individuellement. Le principe est
le suivant :
On lance tous les rangings de tous les capteurs en même temps (comme dans le code 2).
Cette étape est en fait uniquement faite au lancement du drône.
On regarde si le capteur 1 est prêt à nous renvoyer la mesure.
Si oui :
On lit la mesure du capteur 1
On lance un ranging du capteur 1
Si non, on passe à l’étape suivante
On regarde si le capteur 2 est prêt à nous renvoyer la mesure.
Si oui :
On lit la mesure du capteur 2
On lance un ranging du capteur 2
Si non, on passe à l’étape suivante
Etc.
Une fois arrivé au dernier capteur, on repasse à l’étape 2 et ainsi de suite.
{
switch (I2cState)
{
case 0: // ranging
//putc(TW_STATUS);
//putc(I2cState);
55

{
break;
I2cState = 0;
break;
}
break ;
[case 1 et 2]
case 3:
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
if (premier_cycle_I2c != nombre_capteurs_us - 1)
{
I2cState = -1;
premier_cycle_I2c ++;
}
k ++;
{
}
break ;
case 4:
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
break ;
[case 5 à 9]
case 10:
I2cState= -1 ;

56
break ;
}
I2cState++;
return;
}
Avantage :
Code très rapide. Un capteur pointant l’infini ne ralentira pas les autres.
Inconvénient :
Perturbations à gérer.
3.3.3.6. Code d’initialisation des capteurs
Le code suivant permet l’initialisation des capteurs ultrasons. C’est un code qui marche
parfaitement.
L’ancien code d’initialisation des capteurs avait un défaut. Il envoyait des messages sans
attendre une quelconque confirmation provenant des capteurs. Même s’il pouvait
marcher dans certains cas, il peut ne pas marcher si on essaie d’initialiser les capteurs
trop tôt avant la mise sous tension de ceux-ci. Il inclut donc une simple pause (voir
_delay_ms(200); aux deux premières lignes).
Dans ce code, le gain est de 8.
void i2cInit(void)
{
_delay_ms(200);
_delay_ms(200); //pour laisser le temps aux capteurs US de
s'initialiser eux même
premier_cycle_I2c = 0;
TWBR = 152;// SCL 50khz avec horloge 16Mhz
// Initialize SRF10 (not required if default values)
for(i=0; i < nombre_capteurs_us; i++)

{
putc(adresse_capteur_us[i]); //pour savoir à quel capteur on
parle
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWSTA); // start
transmission
while ( (TWCR & _BV(TWINT)) == 0); // wait for transmission
putc(TW_STATUS);
TWDR = adresse_capteur_us[i] | TW_WRITE; // envoi de l'adresse
du capteur "i" et du bit signalant qu'on va écrire dans un registre
TWCR = _BV(TWINT) | _BV(TWEN); // send SLA+W
while ( (TWCR & _BV(TWINT)) == 0 ); // wait for transmission
putc(TW_STATUS);
TWDR = 1; // écriture dans le registre numéro 1
TWCR = _BV(TWINT) | _BV(TWEN); // send register location
putc(TW_STATUS);
TWDR = 8;//gain du capteur
TWCR = _BV(TWINT) | _BV(TWEN); // write max gain value (default
16)
57
putc(TW_STATUS);
TWDR = 255; // écriture de 255 sur le registre 2 (le fait que
ce soit sur le registre 2 après le registre 1 est implicite)
TWCR = _BV(TWINT) | _BV(TWEN); // write range (default 255)
putc(TW_STATUS);
}
//Initialisation terminée. Activation des interruptions
I2cState = 0;
k = 0; //pour commencer avec le premier capteur
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWIE) | _BV(TWSTA); // start
transmission
}
/!\ Ce délais rajouté peut ne pas se retrouver dans tous les codes. Il est
assez récent.
3.3.3.7. Code de changement de l’adresse d’un capteur
Les capteurs ultrasons SRF10 sont livrés à la sortie d’usine avec l’adresse 0xE0. Pour la
changer, nous avons créé le code situé dans l’annexe 4.
Les deux seuls paramètres à régler dans ce code sont : l’ancienne adresse du capteur et
l’adresse que l’on veut lui donner.
Exemple :
#define ancienne_adresse 0xE0

#define nouvelle_adresse 0xE4
Avec ces paramètres, on changera l’adresse d’un capteur de E0 vers E4.
58
3.4. Détection d’obstacles
Un des objectifs de l’année pour le groupe capteur était d’étudier comment réaliser une
fonction de détection d’obstacles sur le quadricoptère.
3.4.1. Définition du besoin et solution mise en place
3.4.1.1. Définition du besoin
A terme la fonction détection d’obstacles doit permettre au quadricoptère de repérer un

obstacle (de type mur ou arbre) en connaissant sa distance et ensuite d’utiliser cette
donnée dans la boucle d’asservissement pour empêcher le quadricoptère de le percuter.
Le groupe capteur avait pour but de trouver les capteurs qui rempliront cette fonction et
d’écrire le code qui pilotera les capteurs et récupèrera les données envoyées. La partie
programmation et écriture d’un algorithme d’évitement d’obstacles revenant au groupe
« Algorithme Programmation ».
La première étape a été de définir de manière précise le besoin par rapport à la détection
d’obstacle :
Etant donné la vitesse du quadricoptère et pour faire en sorte que la réaction ne soit pas
trop brutale, nous avons conclut que le drone devait repérer un objet de type arbre
(environ 20 cm de diamètre) à une distance d’environ 1,50 m.
3.4.1.2. Utilisation de capteurs ultrasons
Raisons de ce choix
Nous avons choisi ce type de capteur car il était déjà utilisé sur le quadricoptère existant
en tant qu’altimètre. De plus le code correspondant à l’altimètre permet de remplir une
fonction très proche de celle que l’on cherche à obtenir et le capteur était réputé pour
marcher correctement.
Une autre raison importante est que les capteurs ultrasons utilisent le protocole I²C. Pour
ce protocole tous les périphériques sont branchés sur le même bus (i.e. : sur les même
deux fils). Il est donc très simple au niveau des branchements de rajouter des capteurs
ultrasons à celui ou ceux existant.
Sur le quadricoptère
Nous avons envisagé de placer à terme 6 capteurs ultrasons dans les 6 directions
caractéristiques du quadricoptère. Dans un premier temps nous nous sommes donné
pour objectif de faire fonctionner une première fonction de détection d’obstacle pour une
direction caractéristique. Au terme de cette année le quadricoptère ne comporte donc
que deux capteurs ultrasons : l’altimètre et un autre dirigé vers l’avant. L’étape suivante
lorsque la détection dans une direction fonctionnera parfaitement (bon réglage des
capteurs, code d’évitement d’obstacles au point) sera donc pour le groupe capteur
d’intégrer d’autres capteurs ultrasons pour que la fonction d’évitement d’obstacles
fonctionne quelle que soit la direction.
3.4.1.3. Validation expérimentale de la solution envisagée
Le but de cette phase expérimentale est de tester notre solution pour voir s’il est
envisageable de l’utiliser sur le quadricoptère.
59
3.4.2. Structure de test et Logiciels
3.4.2.1. Structure de test
Pour tester les « performances » des capteurs ultrasons nous avons effectué un montage
de plusieurs capteurs sur une ancienne structure du drone. Nous avons placé dans un
premier temps 3 capteurs dans les trois directions caractéristiques x, y et z.
Nous avons ensuite branché ces trois capteurs sur le kit de développement STK 300 par
l’intermédiaire d’une plaque d’essai. Le kit de développement étant ensuite relié à un PC
par l’intermédiaire du port série.
Photo de notre montage de test :
Les branchements fait ainsi n’étaient pas toujours très bons, on a plusieurs problèmes de
faux contacts. De plus les soudures des capteurs étaient assez fragiles ; nous avons été
retardé pendant nos tests par des soudures qui cassaient. Pour effectuer des tests plus
poussés il pourrait être intéressant de fabriquer de beaux connecteurs, cela éviterait ce
type de désagréments.
On a effectué la plupart des tests en extérieurs en utilisant un adaptateur permettant

d’alimenter l’ATMEGA grâce à une batterie du quadricoptère.
Pour faire les tests de capteurs il est nécessaire de flasher sur l’ATMEGA un code
permettant de récupérer les données envoyés par les capteurs sur le port série. Pour cela
nous avons utilisés trois codes différents :
Code1 : Dès qu’un capteur a fini de faire une mesure on le relance pour qu’il puisse à
nouveau mesurer
Code2 : On relance les capteurs uniquement quand les trois capteurs ont fini de mesurer
Code3 : On lance les capteurs les uns après les autres
Nous verrons par la suite quel est l’impact du choix d’un programme par rapport à un
autre dans les résultats des tests.
60
3.4.2.2. Logiciels utilisés
Pour pouvoir visualiser nos mesures, on branche le STK300 sur le port série d’un PC par
l’intermédiaire de l’UART du kit de développement. Les mesures des trois capteurs
arrivent donc sur le port série du PC. Pour pouvoir visualiser les données arrivant sur le
port série du PC on utilise HyperTerminal, et PortMon. HyperTerminal permet d’ouvrir le
port en question mais affiche les données en code ASCII… ce qui n’est pas très lisible. On
utilisait donc PortMon, logiciel qui scrute le port une fois qu’il est ouvert (d’où l’obligation
d’ouvrir également HyperTerminal) et qui affiche les données directement en hexa.
Un autre logiciel intéressant pour visualiser les données est Terminal v1.9b, notamment
utilisé par le groupe transmission. Ce logiciel est très bien mais l’affichage des données
(en lignes) nous plaisait moins que celui de PortMon (en colonnes).
3.4.2.3. Tests de Performances d’un capteur
La première chose importante est de tester les performances d’un capteur ultrason en
fonction de son gain. Pour voir plus en détail le fonctionnement d’un capteur ultrason et
notamment le réglage du gain, voir partie fonctionnement des capteurs ultrasons.
3.4.2.4. Protocole expérimental
Pour tester les performances d’un capteur, nous avons décidé de faire une mise en
situation. Nous avons effectué des tests pour trois types d’obstacles différents :
• Un mur de face
• Un arbre de face
• Un arbre décalé (voir schéma ci dessous)
Obstacle de type arbre décalé
Ces tests devaient nous permettre de voir quels gains sont acceptables en situation de
vol.
Pour tester un capteur, il n’y a pas de problème de choix de programme à flasher sur
l’ATMEGA, ils sont tous équivalents. On utilise donc le programme de récupération des
données pour un capteur.
Pour tous les tests on remarque que pour une distance grande le capteur ultrason capte
l’infini. Lorque l’on rapproche le capteur de l’obstacle il commence à voir l’obstacle tout
en continuant à donner souvent l’infini, puis à partir d’une certaine distance les mesure
deviennent stables. On a effectué ces tests des trois situations pour 4 valeurs de gain
différentes : 4, 8, 12 et 16.
61
Remarque en passant :
Selon les capteurs, l’infini est donné par 0xFF ou 0x00… Cette différence semble être due
à une différence de génération des capteurs. En effet les capteurs sont identiques mais
n’ont pas été commandés en même temps. Ceci est à vérifier.
3.4.2.5. Résultats
On a regroupé les résultats de nos tests sur les performances d’un capteur dans un
tableau. Les résultats inscrits dans le tableau correspondent à la distance à partir de
laquelle les mesures relevées étaient devenues stables.
Passage à
Gain \ Mur de Valeur Arbre de Valeur Valeur en
côté d’un
Situation face en cm face en cm cm
arbre (*)
Ne voit pas
4 00 EE 238 00 4E 78 -
l’arbre
Voit des
trucs, mais
8 01 4A 330 00 77 119 -
rien de
stable
12 01 D6 470 00 AD 173 00 70 112
16 02 4F 591 00 FA 253 00 D7 215
3.4.2.6. Interprétation des résultats
On observe bien que plus le gain est fort mieux l’obstacle est détecté, ou de plus loin.
A gain égal un mur de face est détecté de plus loin qu’un arbre.
On voit qu’un gain de 8 n’est pas suffisant pour détecter un arbre légèrement décalé.
Cela peut être gênant dans le cas où l’on n’utiliserait qu’un seul capteur devant.
On observe donc que si on avait comme unique objectif la performance d’un capteur, on
utiliserait sans hésiter un gain de 16. On verra par la suite les problèmes engendrés par
un gain trop fort.
3.4.3. Tests de performances avec deux capteurs : Mise en évidence

des problèmes d’interférences
3.4.3.1. Protocole expérimental
On a observé au cours de nombreux essais des capteurs qu’il peut y avoir apparition
d’interférences lorsque l’on utilise plusieurs capteurs ultrasons en même temps. Ces
interférences ont deux conséquences principales : les mesures ne sont plus stables dans
des situations pour lesquelles avec un seul capteur elles étaient parfaitement stables, et
les capteurs ne détecte plus l’infini lorsqu’ils n’ont aucun obstacles face à eux.
Ces interférences ont été observé pour des essais avec trois capteurs : l’altimètre placé
sous le quadricoptère dans la direction z, et de capteurs sur les côtés en bout de
structure dans les directions x et y. Nous avons voulu dans un premier temps savoir
exactement quels capteurs interféraient parmi ces trois. Pour cela nous avons décidé de
nous intéresser au critère détection de l’infini. Nous avons donc dirigé les capteurs vers le
ciel (aucun obstacle détectable) et nous avons relevé les mesures pour voir si les
capteurs donnaient bien l’infini. On a effectué ces tests pour différentes positions
relatives des capteurs, pour les trois codes et pour différentes valeurs des gains.
62
3.4.3.2. Résultats
En ce qui concerne les codes : les tests effectués avec le code 3, dans lequel les mesures
sont réalisés sur les capteurs les uns après les autres, nous ont confirmé qu’il n’y a pas
d’interférences avec ce code. Cela est rassurant car on a écrit ce code justement pour
avoir un code avec lequel aucune interférence n’est possible. En revanche il convient de
garder en tête que ce code est le plus lent. Si plusieurs capteurs sont placés à terme sur
le quadricoptère cela peut poser un problème de rafraîchissement des données.
En revanche nous allons voir par la suite qu’avec les codes 1 et 2 il y a apparition
d’interférences.
En ce qui concerne les positions relatives des capteurs, deux situations ont été testés :
un capteur situé en bout de structure + le capteur mesurant l’altitude et la situation avec
deux capteurs situés en bout de structure dans les directions x et y. Un résultat très
important de notre campagne de mesure est que dans la deuxième situation, on
n’obtient pas d’interférences, même pour un gain de 16 (le plus nuisible pour les
interférences comme on va le voir immédiatement après) (en considérant toujours le
critère détection de l’infini décrit dans le protocole).
En revanche la première situation avec un capteur dirigé vers le bas et un capteur sur le
côté fait apparaître des interférences (pour les codes 1 et 2): ces interférences
apparaissent pour un gain supérieur à 12. Dans ce cas on observe que les capteurs ne
donnent plus l’infini mais deviennent instables.
Cette phase de test concernant la mise en évidence des interférences par la détection de
l’infini permet de tirer plusieurs conclusions : il y a un problème d’interférences au sens
de détection de l’infini uniquement entre les capteurs de côtés et le capteur d’altitude et
dès que les gains sont assez élevés (supérieur à 12). En revanche, avec ce protocole les
capteurs situés dans les directions x et y n’interfèrent pas entre eux. Enfin, on constate
que nos tests effectués ne mettent pas en évidence de différences entre les codes 1 et
les codes 2.
En revanche nous n’avons pas eu le temps de tester une autre situation qui peut être
problématique : Si l’on considère le quadricoptère en train de longer un mur, le capteur
de côté va mesurer la distance au mur, et le capteur avant est censé mesurer l’infini.
Hors il y un risque que les ondes envoyées par le capteur de côté et réfléchies sur le mur
puissent engendrer des interférences sur le capteur avant. Comme cette situation, bien
d’autres peuvent poser des problèmes d’interférences et méritent d’être étudiées de plus
près.
On voit que dans ce problème de détection d’obstacle, une des difficultés majeure pour le
groupe capteur est que les tests sont tous des tests effectués en situation. Il n’est pas
possible de trouver un protocole expérimental qui nous donnerait exactement comment
se comportent les capteurs ultrasons vis-à-vis des interférences dans toutes les
situations.
Ainsi le réglage des gains devra également se faire par tests progressifs.
3.4.3.4. Remarque importante:
Ces tests ont été effectués sur une structure de tests, il n’est pas garanti que l’on ait
exactement les mêmes résultats si l’on effectue les tests sur le quadricoptère. Une chose
qui serait donc importante à faire est de monter trois capteurs dans les directions
caractéristiques sur le quadricoptère et d’effectuer les mêmes tests. Il faut également
prendre en compte que, étant donné que c’est le capteur d’altitude qui semble être à
l’origine des interférences, cela peut dépendre de l’altitude à laquelle se trouve le
quadricoptère : il y a peut être plus d’interférences au décollage qu’en situation de vol.
63
Etant donné que l’on a vu que la phase de décollage est une phase critique, il convient de
s’en préoccuper particulièrement. C’est pour cette raison que nous avons effectué des
tests relatifs à cette phase importante.
3.4.3.5. Tests relatifs à la phase de décollage
Nous avons noté au cours de différents tests que les capteurs ultrasons, pour des gains
importants ne sont pas très directifs. Cela peut être un avantage en phase de vol puisque
cela permet de réduire les angles morts et permet avec des gains assez élevés de
détecter les obstacles même s’ils ne sont pas exactement dans l’axe du capteur. Nous
avons vu précédemment que cela permet notamment pour des gains supérieurs à 12 de
détecter un obstacle de type arbre même s’il est légèrement décalé. En revanche cette
non directivité des capteurs peut poser un problème lors de la phase de décollage. En
effet lorsque le quadricoptère est posé, pour certaines valeurs du gain, le capteur placé à
l’avant détecte le sol.
Nous avons réalisé deux expériences nous permettant de mieux quantifié le problème.
Expérience 1 : Quantification de la directivité des capteurs ultrasons
Protocole expérimental
Dans un premier temps, nous avons placé un seul capteur sur notre structure de test, et
pour chaque valeur du gain (entre 1 et 15), nous avons noté à partir de quelle hauteur le
capteur (pointant vers l’avant) donnait l’infini. Dans les cas où il ne capte pas l’infini, cela
signifie qu’il capte le sol puisqu’il n’y a aucun obstacle ni d’autres capteurs qui pourraient
faire des interférences. Nous avons également noté quelles valeurs donnait le capteur
juste avant de donner l’infini ; cela peut nous donner une certaine idée de l’ouverture
angulaire du capteur. Il faut toutefois se méfier de cette notion d’ouverture angulaire, car
elle est spécifique à une situation donnée. Elle sera différente selon le type d’obstacle
(forme, matériaux, orientation… etc.)
3.4.3.6. Résultats
Hauteur à Valeur
partir de mesurée « Ouverture
laquelle il Valeur en juste avant Valeur en angulaire »
Gain
mesure une cm qu’il ne cm (angle du demi
distance mesure cône)
infinie l’infini
1 < 5cm - Très faible
2 < 5cm - Faible
3 < 5cm - Faible
4 < 5cm - Faible
5 < 5cm - Faible
6 < 5cm - Faible
7 < 5cm - Faible
8 < 5cm - Faible
9 < 5cm - Faible
10 0x22 34 0x50 80 23°
11 0x29 41 0x60 96 23°
12 0x35 53 0x60 96 29°
13 0x38 56 0x70 112 27°
14 0x3B 59 0x80 128 25°
15 0x42 66 0x90 144 25°
64
Remarque : Les valeurs placées dans la colonne 3 ne sont pas très précises car les
mesures de détection du sol ne l’étaient pas non plus.
On peut noter tout d’abord que jusqu’à un gain de 9 le capteur ne voit jamais le sol.
En revanche pour des gains supérieurs ou égaux à 10, l’ouverture angulaire du capteur
devient telle qu’il capte le sol au lieu de mesurer l’infini.
On voit que plus la valeur du gain augmente, plus longtemps il captera le sol (si on pense
à une éventuelle phase de décollage)
On peut noter que l’ouverture angulaire du capteur reste à peu près constante, autour de
25°, pour des valeurs de gain à partir de 10. On a également noté pendant l’expérience
que le capteur était extrèmement directif pour des gains faibles.
3.4.3.8. Conclusion
Avec cette expérience on ne s’est intéressé qu’à la détection du sol par un capteur. Si on
tirait des conclusions concernant la phase de décollage à partir de cette première phase
expérimentale, on pourrait dire, sachant que notre capteur avant sur le quadricoptère est
placé à environ 25 cm du sol, qu’il faut lors de la phase de décollage un gain strictement
inférieur à 10. Toutefois cette expérience ne tient pas compte d’un autre phénomène que
l’on a mis en évidence précédemment : les interférences dues à l’altimètre.
Nous avons donc réalisé une deuxième phase d’expérimentation directement sur le
quadricoptère, et avec les deux capteurs.
3.4.4. Expérience 2 : Test sur le quadricoptère
3.4.4.1. Protocole
Nous avons installé deux capteurs ultrasons sur le quadricoptère : l’altimètre et un

capteur dirigé vers l’avant. Pendant toute la phase de test le quadricoptère restera posé
au sol. Le but de notre expérience est de voir selon les valeurs des gains des capteurs, le
résultat mesuré par le capteur dirigé vers l’avant. Détecte-t-il l’infini ? S’il ne détecte pas
l’infini, détecte-t-il le sol ou est-ce du aux interférences à cause du capteur d’altitude ?
Pour cela nous avons donc relevé les résultats des mesures avec les deux capteurs
branchés, et dans les cas où l’on n’obtenait pas l’infini, on a arrêté l’altimètre pour voir
d’où provenait le « problème ».
Dans un premier temps on a utilisé le code 1 (le plus rapide), pour bien mettre en
évidence les cas où il y a des problèmes d’interférences. On a ensuite utilisé le code 2,
pour voir si les résultats différaient de ceux du code 1
65
3.4.4.2. Résultats
Avec le code 1 :
Capteur avant
Capteur avant
(altimètre arrêté,
Gain (altimètre en Valeur en cm Valeur en cm
pas de possibilités
fonctionnement)
d’interférences)
16 0x20 32 0x20 32
12 0x48 72 0x4B 75
11 0x7A 122 Infini -
10 0x7C 124 Infini -
8 0x8A 138 Infini -
6 0x85 133 Infini -
5 Infini - Infini -
4 Infini - Infini -
A partir d’un gain de 6 il y a des interférences entre l’altimètre et le capteur ultrason

placé à l’avant.
Les problèmes dus à la détection du sol n’interviennent qu’à partir d’un gain de 12. Le
capteur étant positionné à une hauteur d’environ 25 cm, cela ne correspond pas
exactement au résultat trouvé dans la première expérience de détection du sol, mais
reste dans le même ordre de grandeur. Cette différence peut provenir du fait que l’on
était pas exactement sur le même sol (au dessus d’herbe dans l’expérience 1, de béton
dans l’expérience 2) ou bien que les capteurs ne sont pas tout à fait orienté pareil (l’un
légèrement plus dirigé vers le haut que l’autre). On voit donc encore une fois que ces
tests sont vraiment totalement dépendants des situations.
Le problème des interférences est très important dans la phase de décollage, il s’agit
d’un élément très limitant. Il prend de l’importance par rapport aux tests de détection de
l’infini décrits précédemment car il y a pendant la phase de décollage du quadricoptère
réflexion des ondes envoyées par l’altimètre sur le sol.
3.4.4.4. Avec le code 2
On obtient exactement les mêmes résultats qu'avec le code 1.

Il commence à capter le sol à partir d'un gain de 12, et les reflets du capteur altitude sur
le sol perturbent le capteur avant à partir d'un gain de 5
3.4.4.5. Conclusion
La conclusion de ces tests est que l'on peut utiliser le capteur avant correctement en
phase de décollage avec un gain au maximum égal à 5.
La question qui se pose alors est de savoir si un gain de 5 est suffisant pour la détection
d'obstacle.
3.4.5. Rappel : Test grossier de la portée d’un capteur ultrason avec

un gain de 5
Le capteur avant capte une personne à environ 1 mètre
Le capteur avant capte un mur de face à environ 2 mètres
(Pour plus de précision voir ci-dessus dans la partie performances d’un capteur)
66
Une autre conclusion de cette séance de test est que si on a uniquement 2 capteurs:
l'altitude et un vers l'avant, le code 2 n'apporte aucun avantage par rapport au code 1,
qui part ailleurs est plus rapide. On va donc continuer, à priori à travailler avec le code 1.
Si on n’avait pas de problèmes d'interférences, la séance de test nous a montré qu'une
valeur de 11 du gain serait acceptable lors de la phase de décollage.
Le code 3, plus lent, nous permet d'éviter ces problèmes d'interférences. Il faut donc voir
selon le nombre de capteurs utilisés au final si on peut se contenter de se code et avoir
alors une meilleure performance des capteurs ultrasons.
3.4.6. Rappel fonctionnement du code 3
Le code 3 fonctionne de telle manière qu'il termine une mesure avec un capteur avant de
passer au suivant.
La durée max de mesure est de 60 ms. Si on a deux capteurs, sachant que l'altitude
n'est jamais très élevée et donc que cette mesure est réalisée très rapidement, on aurait
en général une mesure de l'altitude toute les 60 ms. La question a étudier est de savoir
s’il est suffisant d'avoir une mesure de l'altitude toute les 60 ms pour stabiliser le
quadricoptère?
3.4.6.1. Remarques
On n’a pas réfléchi de manière précise à l’orientation idéale à donner au capteur dirigé
vers l’avant. Serait-ce une bonne idée de l’orienter légèrement vers le haut pour
repousser la détection du sol ?
A-t-on des résultats différents si on soulève le quadricoptère de quelques cm. Le début

de la phase de décollage est-elle la plus critique ?
3.4.7. Synthèse et conclusions
La conclusion de cette partie devrait être un paramétrage idéal pour les capteurs et un
choix de code source permettant de réaliser la fonction complète de détection d’obstacle.
Ce problème de la détection d’obstacle fait que l’on doit arbitrer entre la performance des
capteurs ultrasons et les problèmes parasites qui gênent leurs fonctionnements. En effet
si l’on veut que la solution mise en place détecte un objet à une distance raisonnable, il
faut un gain assez élevé pour le capteur. Mais si l’on règle le capteur avec un gain élevé
cela augmente les problèmes d’interférences.
La solution pour véritablement éviter tous les problèmes d’interférences est de choisir le
code3 (voir précédemment pour explication). Cette solution est-elle envisageable ? Pour
cela il faut réfléchir à quel doit être le rafraîchissement des données envoyées par les
capteurs pour que le quadricoptère fonctionne bien. Ce rafraîchissement nécessaire est
sans doute différent selon les capteurs : l’altimètre, directement utilisé dans la boucle
d’asservissement et dans la stabilisation du quadricoptère nécessite sans doute un
rafraîchissement plus rapide que les capteurs servant à la détection d’obstacles. Ce
problème sera totalement différent selon le nombre de capteurs que l’on veut installer
sur le quadricoptère.
3.4.8. Fonction de détection d’obstacles complète
A terme il serait souhaitable de placer 6 capteurs ultrasons. Dans ce cas il est

inenvisageable d’utiliser le code 3 tel que, le rafraîchissement des données pour les
capteurs ultrasons seraient d’environ 6*60 = 360ms. Cela parait un peu trop élevé,
surtout pour l’altimètre. La chose à laquelle il faut réfléchir de manière plus poussée de
manière à avoir les données nécessaires pour résoudre ce problème est donc de savoir le
temps maximal de rafraîchissement des données toléré (peut être différent selon les
capteurs). Exemples de solutions à étudier pour résoudre le problème complet :
67
- Trouver un autre code qui permettent que chacun des capteurs ait le
rafraîchissement de données nécessaire tout en évitant les interférences (un code3
amélioré).
- Lancer les mesures des capteurs qui n’interfèrent pas entre eux en même temps
(Ce n’est pas facile car on ne sait pas exactement lesquels interfèrent selon les
situations)
On voit donc que pour ce qui est de la solution complète encore pas mal de problèmes
restent à résoudre.
3.4.9. Fonction de détection d’obstacle simplifiée
On peut toutefois penser dans un premier temps à réaliser une détection d’obstacles
simplifiée. Cela consiste à placer sur le quadricoptère uniquement un seul capteur
ultrason en plus de l’altimètre. On peut également tenir compte du fait que pour le
moment le quadricoptère ne vole pas très haut, la mesure de l’altitude peut être
considérée comme quasi instantanée. Le rafraîchissement des données des capteurs sera
donc légèrement supérieur à 60 ms si l’on utilise le code 3. Cette valeur est semble-t-il
suffisante. On a donc dans ce cas une solution valable. La seule contrainte au niveau du
réglage des gains est en relation avec la phase de décollage. Nous avons vu dans nos
expériences précédentes que, s’il n’y a pas d’interférences le gain doit être au maximum
de 11 pour ne pas détecter le sol lorsqu’il est posé à terre. On peut donc pour prendre un
peu de marge régler les gains des capteurs à 8. Le groupe capteur est donc capable de
fournir la distance à un objet situé devant le quadricoptère à une distance d’environ 3m
pour un mur et 1m50 pour un arbre. Il ne reste alors au groupe algorithme qu’à écrire un
programme permettant d’empêcher le quadricoptère de rentrer dans l’obstacle.
Cette détection d’obstacle simplifiée permet d’avoir une première approche intéressante.
Une fois que cette solution simplifiée fonctionne parfaitement il sera plus facile d’intégrer
de nouveau capteur et de réaliser la fonction complète.
Remarque :
La donnée limitante pour le réglage du gain étant notamment la phase de décollage, on
pourra réfléchir à la possibilité de faire varier le gain des capteurs entre le décollage et la
situation de vol, simplement en réinitialisant les capteurs après le décollage avec des
réglages différents.
68
3.5. Capteurs de vitesse
Pour le moment, l’unique mesure de vitesse, utilisée dans l’algorithme du drone, est
donnée par la centrale inertielle par l’intermédiaire du GPS. Hors en intérieur le GPS ne
fonctionne plus ; le drone est donc totalement dépendant du GPS et ne fonctionne plus
dès que le GPS ne reçoit plus les signaux des satellites. Nous n’avons pas eu le temps
cette année de nous occuper de ce problème. Il faudra donc commencer à réfléchir à des
capteurs de vitesse alternatifs. Les premières pistes conduisent notamment à l’utilisation
du flux vidéo, aux capteurs doppler ou encore aux anémomètres. Toutes ces pistes
doivent être approfondies pour savoir si ces solutions ou d’autres solutions alternatives
sont envisageables. Des premières études ont été réalisées les années précédentes, il
peut donc être intéressant de partir de celles-ci pour essayer de trouver une solution à ce
problème.
Toutefois il convient avant d’étudier les solutions envisageables, de bien réfléchir sur le
besoin que l’on a et sur les caractéristiques du capteur de vitesse nécessaires au bon
fonctionnement du drone. Par exemple certains des capteurs envisagés sont
directionnels. Il faut donc se poser sérieusement la question de savoir si la mesure de la
vitesse dans une seule direction peut suffire, s’il faut alors mettre plusieurs capteurs dans
différentes directions, un peu à l’image des capteurs ultrasons pour la détection
d’obstacle ou si l’on doit obligatoirement trouver un autre capteur, qui comme le GPS ne
soit pas directionnel. De plus il faut se poser la question de la précision et de la fiabilité
nécessaire pour pouvoir être utilisé dans la boucle d’asservissement.
On voit que de nombreuses problématiques se posent autour de ce capteur de vitesse et

nécessitent d’être approfondies.
69
4. TRANSMISSION
Cette année a été très intéressante pour nous même si nous avons mis beaucoup de
temps pour être efficaces. En effet, l’équipe précédente ne nous a laissé aucune piste de
travail. De plus il y avait très peu de documents donnant les connaissances de base de
l’utilisation des différents kits de développement.
De ce fait nous n’avons pas pu réaliser tout ce que nous avions prévu pendant cette
année. Voici le récapitulatif de nos objectifs avec leur avancement en cette fin d’année.
DEAD % TEMPS
OBJECTIFS
LINE AVANCEMENT CONSACRE
Travail préliminaire
22-nov.-
Capitalisation et présentation des objectifs 100% 10h
05
Etude du modem et des données envoyées

29-nov.-
Prise en main du modem Maxstream 100% 8h
05
13-déc.-
La transmission descendante 100% 16h
05
Etude des caractéristiques du modem pour 17-janv.-
100% 18h
liaison bidirectionnelle 06
Compréhension du programme du 24-janv.-
100% 20h
calculateur du quadricoptère 06
24-janv.-
Réaliser des tests de portée 100% 7h
06
Réaliser des tests de portée en prenant
9-mai-06 10% 1h
compte l'occultation
Mise en place de la liaison bidirectionnelle

Préliminaires : définition des flux
d'information dans le kit ATMega à travers 21-avr.-
100% 2h
les UART pour l'objectif de liaison 06
bidirectionnelle
21-mars-
Prise en main ATMega et kit STK500 100% 25h
06
Test : Communication unidirectionnelle à
4-avr.-06 100% 4h
travers un port UART
Test : Communication bidirectionnelle à
4-avr.-06 100% 4h
travers un port UART
Transfert des informations descendantes à 19-avr.-
100% 30h
travers l'ATMega + Tests quadri 06
Cablâge d'un controleur (joypad) sur un 25-avr.-
100% 6h
ATMega destiné à être au sol 06
Traitement des données provenant du
9-mai-06 50% 4h
Gamepad
--- Tester les nouvelles solutions en
découplant les problèmes en sous-tâches qui
se rejoindront plus tard :
70
Tester la liaison bidirectionnelle avec

30-mai-
l'utilisation de la radiocommande de 70% 30h
06
modélisme
Test sur quadricoptère : Si insuffisants, test
de nouveaux modems
Tester le gamepad en utilisant deux liaisons
unidirectionnelles
Tester les deux solutions combinées si elles
sont validées
Problèmatique de navigation par waypoints
On distingue donc trois grands objectifs :

Etude des caractéristiques du modem pour envisager une liaison bidirectionnelle.
Mise en place de cette liaison en pratique.
Utilisation de cette liaison pour la problématique de navigation par waypoints.
A chaque fois que nous disposions d’une solution nous la testions seule (modems,
gamepad, station sol…), puis dans un second temps nous la mettions en place pour une
utilisation plus complexe. Tout cela en vue de ne pas cumuler les difficultés.
71
4.1. Etude des modems en vue d’une liaison bidirectionnelle
4.1.1. 1 Prise en main du modem Maxstream
Le modem Maxstream est utilisé sur le quadricoptère pour assurer la liaison descendante
qui permet de récolter des informations sur la position du drone par rapport à son
environnement.
En résumé, la centrale inertielle MIDG II reçoit des informations de la part de son capteur
GPS et de ses accéléromètres et les transmet au calculateur embarqué qui les analyse et
les envoie à la station sol (IHM) par l’intermédiaire du modem.
Ce modèle de modem a été choisi par l’équipe précédente parmi 3 autres modèles : le
TX1/RX1, SPM2 et Bim2.
Le choix a été effectué en fonction des données utiles annoncées par les constructeurs, à
savoir la portée, la fréquence d’utilisation et le poids. Après une étude expérimentale
comparative, le choix de l’équipe s’est porté sur le Maxstream 24XStream.
La première étape de l’utilisation de ce modem passe par la prise en main grâce au kit de
développement. Celui-ci est constitué d’un support sur lequel le modem vient s’implanter
pour relier le modem à un PC et un logiciel X-CTU qui permet de régler les différents
paramètres du 24XStream (et d’utiliser un test de communication entre 2 modems
« range test »).
Grâce à ce logiciel on va pouvoir régler le débit de transmission des données (9600

bauds, 57600 bauds…) et le SY Time Before Initialization (donnée importante pour la
bidirectionnalité des modems) qui sont les paramètres prépondérants pour notre
utilisation.
On peut aussi utiliser Matlab pour communiquer avec les modems.
4.1.2. La transmission descendante
Revenons maintenant sur la fonctionnalité actuelle des modems, la transmission

descendante. Le message qui est envoyé à la station sol a une taille de 23 octets (par
exemple, ce message a changé au long de l’année) et comprend :
• Un header (début du signal) (2 octets) : put_uint8_t(0xFA) et
put_uint8_t(0xFF)
• Les vitesses des 4 moteurs (4 octets) : put_uint8_t(moteurN) où N=1..4
• Les 3 angles (6 octets) :
• put_uint16_t(data[MX]), put_uint16_t(data[MY]) et
put_uint16_t(data[MZ]) roulis, tangage lacet
• Les 3 coordonnées du vecteur vitesse (6 octets) put_uint16_t(data[VX]),
put_uint16_t(data[VY]) et put_uint16_t(data[VZ])
• L’altitude sonar (2 octets) : put_uint16_t(zf)
• Le mode de fusion de données de la MIDG2 (mode INS ou pas) (1 octet) :
put_uint8_t(INS)
• La tension de la batterie (1 octet) : Vbat = (ADCH << 6)|(ADCL>>2) et
put_uint8_t(Vbat)
• Un checksum pour contrôler la bonne transmission du message (1 octet) :
_uint8_t(moteur1+….+(data[MX]>>8)+data[MX]+…)
Toutes ces informations arrivent sur la station sol et sont affichées grâce à l’IHM
(Interface Homme Machine) qui est un programme écrit en Visual Basic 6.0 et permet de
piloter le quadricoptère.
72
La liaison vidéo est elle aussi reliée à l’IHM mais elle ne transite pas par les modems. Elle
consiste en une caméra avec émetteur intégré choisie par l’équipe de l’année précédente.
La vidéo n’a pas été un sujet de travail pour notre année bien que nous ayons vérifié ses
fonctionnalités.
Cette sous-tâche nous a permis de nous familiariser avec les modems et avec le code du
quadricoptère et de mieux comprendre l’étendue du travail à venir.
4.1.3. Etude des caractéristiques du modem pour la liaison

bidirectionnelle
Pour comprendre les paramètres importants en ce qui concerne la bidirectionnalité des

modems il faut se référer à la documentation du constructeur.
Non seulement il est important de prendre en compte le débit des données dans l’air
(9600 bauds ou bits par seconde) mais il faut aussi faire attention au temps
d’initialisation des modems entre la fonction émetteur et récepteur : l’option SY Time
Before Initialization permet d’influer sur celui-ci.
Lorsque le modem change de mode (Transmit ou Receive), il doit initialiser le canal de

transmission. L’initialisation prend 35ms.
Si on règle l’option SY à x secondes, le modem n’initialisera que x.10-1 secondes après
un nouvel envoi.
Pour étudier le réglage de cette option, nous avons fait communiquer les modems en
bidirectionnel avec le logiciel X-CTU et avec Matlab.
X-CTU possède un « range test » qui permet aux modems de communiquer entre eux.
On peut ainsi régler le message que l’on désire échanger, le nombre, voir quel est le
pourcentage de messages que l’on a correctement reçu…
Le même type d’expérience a été réalisé avec Matlab. Le programme utilisé est le
suivant :
Déclarer le port série : s=serial(‘com4’)

Ouvrir le port : fopen(s)
Fermer le port : fclose(s)
function test(s,number,data)
% Fonction de test permettant d'envoyer et de recevoir alternativement des
% données sur le port com. Il faut d'abord déclarer le port et l'ouvrir.
% Attention il faut envoyer des données de 23 octets.
% s : variable associée au port série.
% number : nombre de messages envoyés.
% data : données envoyées. (par exemple data=1, data=[2,3]...)
k=0;
l=23;
tic
while k<=number
while s.BytesAvailable<l
end
fread(s,l);
fwrite(s,data)
k=k+1;
end
toc
73
4.1.3.1. Etude en détail du réglage de SY et des débits obtenus
Envoi d’un message entre 2 modems
TST = temps d'initialisation du canal = 35ms. RF analyzer
TTX = transmission
à 19200 bps
B= Bytes
0<B<64 T = 41,6 + (0,4*B) ms
B>63 T = 66,8 ms
à 9600 bps (notre cas actuellement)
0<B<40 T = 46,27 + (0,73*B) ms

B>39 T = 74,8 ms
Actuellement nous envoyons 23 octets en liaison descendante toutes les 40ms.

Le premier envoi prend 63ms (d'après les données précédentes) puis 28ms (il n'y a plus
d'initialisation ensuite car on fait du streaming dans un seul mode).
Voilà pourquoi on n'envoie pas le message toutes les 20ms (timer du message '10' de la
MIDG II) mais toutes les 40ms (une fois sur deux).
Par contre, en cas de liaison bidirectionnelle alternée (ce que l'on veut mettre en place),
il faudrait que le canal soit réinitialisé à chaque fois.
74
On peut cependant régler une option (SY (Time before Initialization) Command) qui
permet de ne réinitialiser que x secondes après le changement de mode. Il est ainsi
possible de ne jamais envoyer ce RF analyzer s’il y a une alternance continue de
messages montants et descendants.
Par exemple : on règle le SY à 300ms et le temps entre deux envois est de 100ms. Etant
donné que le compteur est remis à zéro à chaque envoi il n’atteint jamais 300ms et on
n’a jamais de RF analyzer.
Il faut aussi prendre en compte le temps de commutation entre les différents modes :
Transmit -> Receive : 20ms
Receive -> Transmit : 16,8ms
4.1.3.2. Théorie
• Pour des messages de 23 octets sans SY :

Envoi : 28ms
Transition : 20ms
Channel Initialization : 25ms
Réception : 28ms
Transition : 16,8ms
Channel Initialization : 25ms
Durée d’un cycle = 162,6ms
• Pour des messages de 23 octets avec SY > 200ms :

Envoi : 28ms
Transition : 20ms
Réception : 28ms
Transition : 16,8ms
Durée d’un cycle = 92,6ms
Gain du SY = 70ms
En pratique (moyenne sur 100 envois) :
sans SY = 175ms
avec SY = 110ms
On a seulement un gain de 65ms. En effet, de temps en temps, le canal est réinitialisé

car les modems sont désynchronisés. On perd donc parfois 35ms.
La pratique se rapproche assez bien de la théorie.
75
Nous nous sommes donc aperçu que le réglage du SY à une valeur supérieure à 200 ms
permet de faire passer le temps entre 2 messages envoyés de 175ms à 110ms pour des
paquets montants et descendants de 23 octets. Ces 110ms sont conformes à la
documentation fournie par le constructeur.
Ce débit peut être suffisant car on a un drone asservi qui, normalement, est stabilisé
sans consigne. Cette sous-tâche a permis de valider un débit correspondant à 23 octets
toutes les 110ms en bidirectionnel. Reste à savoir les conditions de réception des
modems.
4.1.4. Réaliser des tests de portée pour le Maxstream avec le réglage

de SY
Pour mesurer effectivement la portée des Maxstream, nous avons utilisé le « range test »
du X-CTU et nous sommes allés au Parc de Sceaux. Le réglage de SY ne modifie en rien
les résultats.
4.1.4.1. Test de portée
• En ligne droite sans aucun obstacle entre les 2 modems la portée peut atteindre
1400m (limite maximale qui représente la largeur du parc de Sceaux, nous
n’avons pas pu aller plus loin). A cette distance on reçoit 100% des messages.
• En revanche à cette distance si on met un obstacle devant un modem (par
exemple la main), la communication est rompue.
• A n’importe quelle distance si il y a des obstacles du type rangée d’arbre, la
communication est rompue. Il parait indispensable à un moment de réaliser des
tests prenant en compte l’occultation.
4.1.4.2. Conclusion
On a donc validé les modems (et eux seuls) pour une liaison bidirectionnelle. Il
faut maintenant mettre en place la liaison avec le quadricoptère pour affirmer que les
débits suffisent. Reste le problème de l’occultation, il faudra donc faire des tests
approfondis.
76
4.2. Objectif 2 : Mise en place de la liaison bidirectionnelle
La configuration de communication au début de l’année est la suivante :
Il s’agit dans notre cas de pouvoir envoyer des données au quadricoptère en vue
d’exécuter des vols en mode automatique et pour s’affranchir de la radiocommande de
modélisme.
4.2.1. Solutions possibles
1° Rajout de deux modems : un au sol et un sur le quadricoptère. Ces modems

fonctionneraient en liaison montante. Le PC recevrait les données via un modem et les
enverrait vers un autre.
2° Utilisation des modems en bidirectionnel. Interfaçage d’un contrôleur type joystick ou
joypad sur l’ordinateur.
3° Utilisation des modems en bidirectionnel. Utilisation d’un microcontrôleur au sol pour
interfacer le joypad.
Solutions Avantages Inconvénients

-Multiplication des liaisons
1 -Simplicité de mise en place -Poids
-Débits optimums -Manque de ports sur le
microcontrôleur du quadri
-Centralisation sur l’ordinateur -Complexité des protocoles de
-Beaucoup de joypads gestion des contrôleurs sur PC
2 disponibles -Manque de timers pour
-Simplicité architecturale synchroniser les envois
-Choix d’un ATMega, processeur

3 connu -Mise en œuvre plus longue
-Interfaçage plus simple
77
Au final nous avons choisi la troisième solution, la plus évoluée et celle dont on connaît
déjà les technologies.
4.2.2. Prise en main ATMega et kit STK500
Cette prise en main a été réalisée avec l’aide des groupes Capteurs et Algo/Calculateur
embarqué qui avaient déjà fait ce travail. Ainsi nous avons pu accélérer notre processus
d’apprentissage de l’utilisation du kit de développement et du langage C.
Nous avons fait des programmes simples d’allumage de LED en C pour comprendre les
« réactions » du système.
Ce qui nous a posé problème, c’est la disponibilité de ces kits de développement. En

effet, nous sommes arrivés à un point où chaque sous-groupe a besoin d’un kit de
développement. Ainsi, il ne faut pas espérer avoir un kit attitré il faut savoir partager, ce
qui permet en outre un échange approfondi entre les groupes.
Programmes utilisés : ATMEL AVR Studio 4, WinAVR Programmer’s Notepad, Terminal.
Cette sous-tâche nous a permis de mieux comprendre la syntaxe et l’algorithmique du

programme du quadricoptère.
Pour introduire les sous-objectifs suivants, voici un schéma explicitant le transit des
informations dans l’ATMega au sol :
78
Le premier test consistera en une vérification des capacités bidirectionnelles des entrées-
sorties de l’ATMega.
Ensuite nous nous occuperons de mettre en place et tester la liaison descendante à
travers l’ATMega.
Enfin nous nous chargerons d’interfacer un dispositif de commande manuelle sur le kit de
développement et de mettre au point le message montant.
4.2.3. Tests de communication bidirectionnelle à travers un port UART
Nous avons commencé simplement par communiquer de façon unidirectionnelle avec

l’UART1 pour apprendre à se servir des entrées-sorties.
Ensuite nous avons fait un programme qui renvoie ce qu’il reçoit sur le même port.
L’ATMega gère parfaitement le bidirectionnel via ports UART, la transition Envoi-
Reception est immédiate. Ces programmes sont très simples. Il n’est pas indispensable
de comprendre toutes les subtilités d’une interruption comme SIGNAL(
SIG_UART1_DATA ). Il suffit de savoir l’utiliser. Le programme correspondant est donné
en Annexe 1.
Il reste encore à coordonner précisément les flux alternatifs de données pour assurer une
liaison optimale.
79
4.2.4. Transfert des informations descendantes à travers l’ATMega
Il est très facile d’envoyer les informations d’un UART à l’autre.
Cependant, nous avons réalisé que nous devrons mettre en place plusieurs fonctions de
type « putc ». Les fonctions « put » servent à envoyer des données sur un port UART.
Il faut également noter que nous procédons à une vérification supplémentaire des
headers et du checksum pour supprimer les erreurs de transmission.
Nous avons discuté de ce transfert avec l’équipe IHM et il nous a paru intéressant de
pouvoir afficher certaines informations sur les LED du kit de développement notamment
des informations indispensables au décollage du mini-drone comme l’activation du GPS.
Cette information est donnée par le mode de fusion des données de la MIDG II, l’INS.
Nous avons donc créé un programme que nous avons testé avec succès en vol avec le
quadricoptère. Ainsi si INS=1 alors on a une LED du kit allumée sur deux, si INS=0 alors
toutes les LED sont allumées. On peut bien sur changer ce réglage facilement pour
n’avoir l’information que sur une LED et afficher d’autres informations sur les autres LED
(détection d’obstacle…).
Le programme final correspondant à ce transfert en disponible en Annexe 2.

Les étapes suivantes permettront de compléter ce programme pour avoir en plus la
gestion de la manette pour la liaison montante.
80
4.3. Câblage d’un gamepad sur l’ATMega au sol
La manette est un gamepad de Playstation 2.
L’interface retenue est le SPI (Serial Protocol Interface). On nous a fourni un rapport très
complet que nous laisserons à la future équipe quadricoptère. Le message provenant du
gamepad se présente comme ça :
Mode dual shock 2
Lors d'une requête de lecture, le gamepad renvoie l'état des boutons sur 2 octets (4e et
5e octet) la position des 2 sticks sur quatre octets (6e, 7e, 8e et 9e octet) ainsi que la
pression des 12 boutons (les boutons des stick droit et gauche ne sont pas équipés
de capteur de pression)
La pression des boutons est codée de 0 à 255 (0 = bouton relâché).
81
byte data
b7 b6 b5 b4 b3 b2 b1 b0
1st byte 0xFF (255)
2nd byte 0xF3 (243)
3rd byte 0x5A (90)
4th byte gauche bas droite haut start * ** select
5th byte carré croix rond triangle R1 L1 R2 L2
6th byte Stick droit gauche<-> droite Gauche:00h,Centre:80h,Droite:FFh
7th byte Stick droit haut <-> bas Haut:00h,Centre:80h,Bas:FFh
8th byte Stick gauche gauche<-> droite Gauche:00h,Centre:80h,Droite:FFh
9th byte Stick gauche haut <-> bas Haut:00h,Centre:80h,Bas:FFh
10th byte pression : droite
11th byte pression : gauche
12th byte pression : haut
13th byte pression : bas
14th byte pression : triangle
15th byte pression : rond
16th byte pression : croix
17th byte pression : carré
18th byte pression : L1
19th byte pression : R1
20th byte pression : L2
21th byte pression : R2
* bouton stick droit (pression sur le stick).
** bouton stick gauche (idem).
On a également pu essayer une interface personnalisée développée sous Matlab. Il faut

noter que le mode vibration faisait planter l’ATMega sur lequel le gamepad était interfacé.
82
Remarque : nous avons eu un problème qui nous a bloqués pendant un bon moment.
Pour utiliser la manette nous devions être réglés en horloge interne alors que pour tous
les autres programmes nous étions en horloge externe avec un cristal 16MHz. Voici le
cavalier à changer et le cristal sur la gauche :
83
4.4. Protocole de tests : Séparation des problématiques
Désirant ne se confronter qu’à un problème à la fois, nous avons décidé de séparer les
difficultés.
Test de la liaison bidirectionnelle seule en branchant la radiocommande de modélisme sur
l’ATmega au sol qui fait transiter l’info via les Maxstream.
Test du gamepad seul en utilisant comme liaison montante l’émetteur de la
radiocommande.
Si les deux tests sont concluants, rencontre des deux nouveautés : liaison
bidirectionnelle et gamepad.
4.4.1. Liaison bidirectionnelle avec radiocommande de modélisme
Voici le schéma de principe :
4.4.1.1. Décodage du signal délivré par la radiocommande
La radiocommande délivre un signal PPM (Pulse Position Modulation). C’est une trame de
créneaux d’amplitude constante où l’information est contenue dans l’écart entre ces
créneaux. Le détail de cette trame PPM peut être trouvé dans les rapports des années
précédentes.
Il s’agit de pouvoir distinguer ces créneaux du bruit et d’enregistrer dans une liste ces
ppm_pulses.
On envoie une liste accompagnée de headers et d’un checksum sur l’UART1.
Le programme de décodage de la trame PPM peut être trouvé en Annexe 3.
84
Les correspondances sont les suivantes :

ppm_pulses[0] = roulis (gauche-droite sur le stick directionnel de gauche)
ppm_pulses[1] = tangage (haut-bas sur le stick directionnel de gauche)
ppm_pulses[2] = altitude (gaz) (haut-bas sur le stick directionnel de droite)
ppm_pulses[3] = lacet (gauche-droite sur le stick directionnel de droite)
Le récepteur de la radiocommande est interfacé sur un compteur, l’ICP3 du kit STK501

(pin7 du port E). Cela implique une syntaxe et des commandes particulières dans le
programme correspondant (voir la documentation constructeur et notre programme).
Nous avons eu un problème de masse. Le récepteur et le kit doivent être alimentés avec
une masse commune pour avoir des grandeurs compatibles. Ce problème nous a
longuement bloqués car nous alimentions le récepteur par un générateur extérieur.
4.4.1.2. Mise en place de la liaison bidirectionnelle
Il faut ensuite corriger le programme embarqué du quadricoptère pour prendre en

compte le décodage qui n’est plus fait à bord. Le problème vient également du fait qu’on
ne reçoit plus les données sur un compteur mais sur l’UART consacré au modem du
quadricoptère.
Le difficulté suivante est de régler la communication bidirectionnelle en elle-même : en
effet la radiocommande envoie trente trames valides par seconde. Ceci demande un
85
débit trop élévé pour nos modems, même pour un message de 11 octets (2 headers, 2x4
octets, 1 checksum).
Il faut donc coordonner les envois et mettre en place une alternance tout en prévoyant
les pertes de transmission (timeout…).
Nous avons besoin de deux kits de développement STK500-501 pour tester cette liaison
au sol avant d’effectuer des tests sur le quadricoptère mais, en cette fin d’année, nous
avons eu du mal à obtenir tout le matériel nécessaire car tout le monde en a besoin…
Nous n’avons pas eu le temps de procéder à ces réglages mais nous mettons tout de
même nos idées et nos pistes pour permettre à l’équipe suivante de commencer plus vite
que ce que nous avons pu le faire. Nous fournirons les programmes que nous n’avons
pas pu tester avec nos réflexions sur leur amélioration.
4.4.1.3. Validation des modems pour la liaison bidirectionnelle :
Un test sur le quadricoptère permettra de déterminer si les modems sont suffisants pour
notre projet de liaison bidirectionnelle. Sinon, il faudra procéder au test de nouveaux
modems.
4.4.2. Test du gamepad en pratique
Voici le schéma de principe :
Il s’agit de se servir de la radiocommande de modélisme comme émetteur via la prise

« trainer ». On utilise ici deux liaisons unidirectionnelles pour tester seulement
l’utilisation du gamepad sur le quadricoptère. La sensibilité du gamepad semble moins
convaincante que celle de la radiocommande mais il faut tester pour savoir si elle est
suffisante. Encore une fois on se repose sur l’asservissement pour assurer une stabilité
optimale, il ne s’agit pas de piloter un jouet.
4.4.3. Mise en place de la liaison bidirectionnelle avec le gamepad
Si les modems sont validés et le gamepad fonctionnel sur le quadricoptère, l’équipe

Transmission pourra procéder à la réunion de ces deux technologies.
86
4.5. Problématique de la navigation par waypoints
Cet objectif ne pourra être entrevu que lorsque nous aurons une liaison bidirectionnelle
parfaite entre le quadricoptère et la station sol via les modems et l’ATMega au sol. C’est
donc un objectif primordial de nos successeurs.
Il faudra rajouter la liaison suivante (en vert) :
Cet objectif ne pourra être atteint qu’en collaborant avec les équipes IHM et Algorithme
qui ne sont pour l’instant pas encore prêtes à envisager la navigation par waypoints. A
priori l’équipe Transmission n’aura qu’à faire transiter l’information. Il faut tout de même
prendre en compte les problématiques de passage du mode automatique au mode
manuel et surtout le débit des modems qui peut encore une fois être insuffisant.
87
4.6. Conclusion
Au final, nous n’avons pas réalisé tous nos objectifs pour l’année. Cependant nous
laissons une base importante de travail pour l’équipe qui prendra le relai. Nous tenons
réellement à éviter à cette équipe les difficultés que nous avons rencontrées en début
d’année.
Il est dommage que nous n’ayons pas eu plus de temps pour finaliser notre liaison
bidirectionnelle, le travail est devenu de plus en plus intéressant au long de l’année. Il
semble que cette liaison puisse être réalisée et qu’elle apportera beaucoup au
quadricoptère en proposant des envois montants de données.
88
5. STRUCTURE
5.1. Introduction
Le sous groupe structure fut constitué par une personne cette année-ci comme l’année
précédente. A cause des difficultés rencontrées au début du projet pour définir les
priorités du projet et les tâches à accomplir, la répartition des membres dans les
différents sous-groupes a été difficile. Par conséquent, le sous-groupe structure a été
« dissous » pour pouvoir travailler avec le sous-groupe interface homme-machine (IHM)
sur du code. Nous pensions que l’enjeu principal était de gagner du poids en optimisant
la structure actuelle, mais nous nous sommes rendu compte que le groupe structure
avait bien plus de points à traiter (par exemple, les réparations suite aux nombreux
crashes,…)
Le seul objectif de cette année se résumait au gain de poids grâce à l’optimisation de la

structure actuelle. Cette tâche fut effectuée en parallèle avec la recherche de solutions de
code pour l’IHM et devait s’achever pour janvier 2006.
En avril, nous avons remarqué que la structure actuelle avait du mal à endurer les
nombreux crashes de cette année malgré tous les renforts ajoutés l’année passée (ce qui
constitue un excédent de poids non négligeable). En effet, le carbone est assez difficile à
assembler et nous avons remarqué que les collages au niveau des assemblages avaient
tendance à casser ou à lâcher lors des chocs. D’autres solutions devaient être apportées,
et le groupe structure s’est penché sur des alternatives de structure envisageables grâce
à l’usinage de pièces. Après une formation rapide aux techniques de fraisage et de
tournage, le responsable du sous groupe développait et fabriquait en parallèle de
nouvelles structures. L’usinage et la fabrication d’un nouveau banc d’essai pour les
moteurs fut prise en charge par cette même personne et un autre membre du projet.
En définitive, le sous-groupe structure est indispensable et doit être effectif durant toute
l’année. La structure nécessite sans cesse des améliorations, des réparations et la
fabrication de pièces nouvelles ou de rechange. L’ennemi principal est le poids. Mais la
résistance aux crashes du quadricoptère reste un impératif important à ne pas négliger
(par exemple : solidifier les assemblages, améliorer la rigidité, protéger les hélices,…)
89
5.2. Les pré-requis
Les outils de base de la conception sont fournis de nos jours par la CAO (conception
assistée par ordinateur). Mais nous rencontrons un problème majeur : l’impossibilité de
construire les maquettes numériques dessinées sous Catia. Nous avons la possibilité de
sous-traiter la fabrication à une firme extérieure, mais le prix d’une telle fabrication et
nos connaissances limités dans la fabrication (basée principalement sur l’expérience) en
matériaux composites est un des freins principaux à cette option. De plus nous n’avons
pas la possibilité de réparer le drone en cas de casse.
Le point clé du sous-groupe structure reste la réalisation de la structure. Par conséquent,
la maîtrise des moyens de fabrication utilisés pour la structure du drone est
indispensable.
Nous pouvons dresser une liste des éléments formateurs intéressants à faire dès le début
de l’année :
• formation usinage (voir M. Le Gal, très compétent dans tous les domaines)
• formation Catia proposée par M. Pascal Morenton pour les projets de 2ième année
(attention, Catia est très complet mais aussi très complexe, la maîtrise de ce
logiciel peut prendre plus d’un an dans certains cas…)
• acheter les équipements nécessaires à la découpe du carbone (masques, outils au
diamant,…) et les matières premières (aller chez Weber Métaux, Paris 3ième)
• se familiariser avec les matériaux composites (shows,… par exemple
www.jeccomposites.org)
• bricoler et se familiariser avec les outils disponibles (voir dans les différents
labos : LEE-E=M6, labo de M. Le Gal,…).
5.3. Objectifs
Les objectifs du groupe structure autres que le gain de poids n’apparaissent que durant
l’utilisation au cours de l’année du drone et sont limités par les compétences acquises par
les membres du sous-groupe structure. Par conséquent, il est très difficile de fixer des
objectifs réalisables en début d’année. Par contre, la fabrication de pièces de rechange et
les améliorations qui en découleront doivent rester au programme (ce qui avait été un
peu négligé cette année-ci) dès le début du projet et guideront les évolutions de la
structure et objectifs de ce sous-groupe.
Par conséquent, nous ne listerons pas des objectifs, mais les objectifs et les tâches
effectués au cours de cette année :
• optimisation de la structure existante et gain de poids
• nouvelle fixation des moteurs
• établissement d’une méthode pour adapter les hélices à nos moteurs
• structure démontable
• autres évolutions
90
5.4. Solutions possibles
5.4.1. Optimisation de la structure et gain de poids
L’objectif était de conserver la structure actuelle pour limiter

le temps investi dans cette sous partie du projet et avancer
dans d’autres parties, et de gagner du poids en réorganisant
les différents éléments (mécaniques et électroniques) et en
supprimant ceux superflus.
Deux possibilités nous sont offertes : effectuer les
manipulations sur le quadricoptère ou utiliser une maquette
numérique.
La première est plus efficace, plus pratique et beaucoup
plus facile, mais elle nécessite de se procurer un deuxième quadricoptère dans son
entièreté. Notre budget ne permet pas d’acheter en double exemplaire tous les
composants électroniques et la réalisation de la structure du quadricoptère requière
beaucoup de temps et du matériel qui fait défaut dans notre labo. De plus, les éléments
actuels risquent d’être remplacés par de plus performants qui n’étaient pas alors
disponibles sur le marché ce qui rend obsolète le modèle optimisé.
La modélisation en maquette numérique nous permet quant à elle une flexibilité virtuelle
des éléments sans limite et nous est également utile pour la détermination de matrices
d’inerties, de bilan de masse, de centre de gravité,… Cette solution a été retenue pour
l’étude de l’optimisation de la disposition des éléments électroniques et mécaniques sur
l’étagère centrale.
5.4.2. Nouvelle fixation moteur
Les moteurs utilisés sur le quadricoptère ont un

système de fixation peu conventionnel : ils ont à leur base
une tige fileter sur laquelle vient se serrer un écrou. La
seule solution est donc de serrer le moteur sur une plaque
et de coller cette plaque à la structure en croix du
quadricoptère. Cependant, les écrous restent des pièces
assez massives (inconcevable en acier, tolérable en
nylon).
Un problème s’est déclaré au milieu de l’année : la colle qui fixe la plaque en carbone au
tube en carbone de la structure se décolle à cause des chocs. Le moteur garde sa
position grâce aux fils de fibre de carbone qui renforcent le collage, mais il bouge un peu
autour de cette position. Un tel problème ne peut en aucun cas persister et causer à long
terme le risque que la fixation lâche.
La seule alternative à la plaque et à l’écrou est l’usinage d’un embout dans lequel le
moteur se visserait et dans lequel s’insérerait le tube en carbone de la structure. Ensuite,
on devrait le fixer soit par collage, soit par serrage.
La solution apportée fut l’usinage d’un bloc en PVC muni d’un taraudage qui accueille la
fixation du moteur, dans lequel se glisse le bras de la croix de la structure et qui
maintenu dans sa position par serrage. Ce montage offre divers avantages : fixation
solide qui ne craint pas les chocs, remplacement facile en cas de casse, modularité,…
5.4.3. Méthode d’adaptation des hélices
Le quadricoptère ne peut se stabiliser sur son lacet que

si deux moteurs tournent dans le sens horlogique et deux
autres dans le sens anti-horlogique, tout en ayant les mêmes
caractéristiques aérodynamiques. Par conséquent toutes les
hélices doivent être rigoureusement identiques mais
91
énantiomorphes deux à deux. Très peu de ces hélices sont disponibles sur le marché et
nous devons composer avec celles qui nous conviennent le mieux. Malheureusement,
elles ne se montent pas facilement sur les moteurs qui équipent le quadricoptère.
Jusqu’à présent, nous percions le moyeu des hélices au diamètre du filet de la cage
tournante du moteur et nous limions l’excédent de matière qui nous empêchait de serre
l’écrou. Cette manipulation était assez imprécise et peu reproductible (comme illustré
dans cette photo où deux hélices modifiées ne sont pas pareilles).
Nous avons mis au point un protocole beaucoup plus net et précis pour modifier les
hélices qui repose sur l’usinage des hélices sur un tour et sur la fixation des hélices au
moyen d’un adaptateur spécifique dans les mords de l’étau de la machine-outil. L’hélice
ainsi modifiée possède des surfaces de contact plates, parallèles et est percée dans son
axe de part en part et avec une encoche à sa base.
5.4.4. Structure démontable
Toujours dans l’optique de supprimer les collages pour améliorer la solidité des
assemblages et le démontage de la structure, nous avons profité de l’usinage des
supports moteurs pour appliquer cette même méthode au centre de la structure. L’idée
est de séparer la structure en un moyeu central sur lequel vient se monter l’étagère,
quatre tubes constituant les bras de la croix, et les supports des moteurs. Ainsi, nous
bénéficions d’une structure démontable et nous explorons d’autres perspectives pour la
structure.
Les variantes sont nombreuses et il est difficile de prédire quelle structure donnera les
meilleurs résultats sans l’avoir construite au préalable. De même, il est difficile de définir
des cotations sans avoir réaliser une pièce à blanc : soit les contraintes appliquées à la
pièce peuvent être trop importante, soit nous ne pouvons pas l’usiner avec de petites
épaisseurs, ou alors nous pouvons utiliser un autre matériau.
Une des solutions envisagées est l’usinage d’un bloc central dans lequel viendraient se
loger les quatre tubes en carbone. Ils se solidariseraient par serrage au moyen d’une
petite vis. Différentes solutions sont proposées dans les modèles Catia ci-dessous :
- Ici, une plaque en PVC est usinée en un seul bloc pour réaliser le premier étage de
l’étagère et les fixations des bras.
- Cette pièce se placerait

sous une plaque de
l’étagère. Deux tubes
glissés dans les orifices
forment la croix.
Nous n’avons pas eu le temps de les réaliser,

c’est pourquoi nous encourageons nos
successeurs à considérer ce sous-groupe comme
« sous-groupe à plein temps », afin d’exploiter de
nombreuses solutions qui seront autant de
structures de rechange en cas de casse, ce qui
est toujours bon à avoir.
Cependant, nous avons décidé d’élaborer un
centre de structure « composite » réalisée d’une
part en matériaux composites (plaque en fibres
92
de carbone tressées à matrice époxy) et d’autre part au moyens de pièces usinées en

PVC : nous avons quatre supports pour les tubes qui sont solidarisés par deux plaques,
chacune aux faces inférieure et supérieure. Encore une fois, la structure réalisée a
nécessité des adaptations et certains petits « trucs » pour arriver à un résultat qui est
assez probant…
5.4.5. Autres évolutions
Nous aimerions ajouter quelques évolutions auxquelles nous avions pensées, mais que
nous n’avons pas réalisées par manque de temps, d’utilité, de matériel, ou simplement
parce qu’elles ne sont pas réalisables. Nous listerons ci-dessous certains de ces points
avec quelques commentaires :
5.4.5.1. Atterrisseur
Si le quadricoptère atterrit trop brusquement et avec une assiette qui n’est pas
horizontale, une des tiges en carbone qui lui sert d’atterrisseur peut s’enfoncer et une
des hélices peut heurter le sol.
Le problème pourrait disparaître si une balle de ping-pong est collée à l’extrémité du
tube. Une autre solution serait de changer les atterrisseurs, mais nous n’avons pas
encore trouvés de solutions mieux adaptées.
5.4.5.2. élargissement des plateaux de l’étagère
Les plateaux de l’étagère sont des carrés de 8x8cm. Ils ont été dimensionnés suivant la
disposition des éléments électroniques qu’ils accueillaient. Cependant, si nous désirons
augmenter le nombre de batteries, nous devrons peut-être envisager de passer à des
carrés de 10x10cm. La structure pourrait alors embarquer 4 packs d’accus LiPo (~20
minutes d’autonomie de vol). Ce choix est conditionné par la taille des accus qui évoluent
tous les mois en fonction des avancées technologiques et conditionne le
dimensionnement des nouvelles cartes électroniques. La prochaine équipe devra accorder
une importance particulière à la détermination de ce point. Un telle adaptation est assez
difficilement applicable à la structure actuelle, mais se réalise relativement rapidement
sur la structure démontable.
5.4.5.3. protection des hélices – nouveau design de structure
Malheureusement, les crashes sont inévitables, et une de leurs premières conséquences

se traduit par la casse d’une ou de plusieurs hélices. Or ces hélices nécessitent une
adaptation minutieuse et ne sont disponibles que chez Todd’s Models aux USA. Par
conséquent un dispositif protectif pourrait être souhaitable. Mais nous ne pouvons pas
ajouter un montage pour protéger les hélices sans augmenter de manière significative le
poids de la structure (gain de poids estimé : 30 à 75%).
La seule solution valable à long terme est de dessiner une nouvelle structure basée sur
un concept différent de celui de la croix. L’idée est d’avoir une soucoupe carénée dans
laquelle il y aurait 4 trous pour laisser place aux hélices.
Cette idée est réalisable, mais en aucun cas à l’Ecole Centrale Paris. Ce type de structure
nécessite la mise en forme de tissus en fibres de carbone par un technique de moulage
complexe qui nous est d’une part interdite dans les laboratoires de l’Ecole et d’autre part
pas accessibles avec les moyens disponibles dans les labos.
L’élaboration d’une maquette numérique est assez difficile car les fonctions du module de
manipulation de surface de Catia sont assez complexes et difficiles à utiliser. Nous
devrions donc réaliser une première maquette physique pour réaliser la coque en
carbone.
Toutes ces difficultés ne laissent place à aucune modularité de la structure. Cette solution
telle qu’elle est envisagée ici ne doit pas forcément être écartée, mais doit être réservée
pour la fin du projet, quand tous les éléments du drone seront choisis définitivement,
93
leurs positions dans l’espace fixés ingénieusement et qu’un local équipé soit mis à la
disposition des élèves.
D’autres solutions telles que des « boudins » qui s’adapteraient sur la structure actuelle
et entoureraient les hélices peuvent être envisagées. Mais là encore, la réalisation de tels
dessins nécessite la mise en forme de matériaux composites qui ne nous est pas
autorisée et qui nécessitent une expérience pratique assez importante. L’usage de
mousse renforcée par des tubes ou tiges en carbone pourrait être envisagé, mais cette
réalisation doit être capable de résister aux chocs.
Beaucoup de questions restent sans réponses et de nombreuses perspectives sont

offertes à nos successeurs. Ces différentes perspectives avaient été écartées cette année,
mais nous nous sommes rendu compte que ces points de préoccupations reviennent sans
cesse lors des essais. Nous encourageons vivement les prochains membres du projet à
ne pas écarter trop rapidement le développement de l’architecture du quadricoptère.
94
5.5. Solutions choisies
Nous avons choisi de modéliser le quadricoptère sous Catia. Tous les éléments ont été
modélisés numériquement. Un matériau a été associé à chaque composant. Le tout a été
assemblé et nous tirons de cette maquette sa matrice d’inertie au centre de gravité, son
poids total,…
L’avantage est que nous pouvons changer tous les composants de la structure et les
remplacer par des alternatives. Nous pouvons ainsi calculer le gain de poids, vérifier si le
positionnement est possible, s’il n’y a pas de risque de collision,…
Nous pouvons appliquer la même démarche pour le matériel électronique embarqué.
Nous pouvons ainsi déterminer la disposition de chaque élément sur le quadricoptère afin
d’avoir l’architecture la plus simple, la plus légère, tout en conservant un centre de
gravité correcte.
Nous nous affranchissons ainsi de toute contrainte de matériel et le drone reste

opérationnel pour les autres sous-groupes lorsque nous étudions des solutions
alternatives pour le drone (effectuées de manière virtuelle).
En conclusion, cette méthode nous permet de valider une idée sur un objet qui
s’approche le plus de la réalité avant de la mettre en œuvre sur le drone. Cette opération
permet de mettre en évidence certains désavantages ou inconvénients de solutions
possibles qui ne seraient apparus que pendant la modification de la structure, évitant
ainsi une éventuelle manipulation inutile voire irréversible. Même dans les autres tâches,
Catia nous aura souvent permis de valider une solution avant de la mettre en application.
Toute la structure repose sur les propriétés des matériaux composites en carbone :
légèreté, rigidité,… L’inconvénient est que la colle ne tient pas très bien sur ces surfaces
et l’usinage et la mise en forme du carbone sont très difficiles. Tout perçage ou usinage
du carbone induit une faiblesse dans la structure et représente une amorce de fissure qui
peut se propager dans tout le tube et causer la destruction (en vol ou au sol) de toute la
structure. Nous avons donc fabriqué des pièces qui assurent la jonction entre les tubes
en carbone de la structure et les moteurs.
95
Ces pièces ont un design très simple. Ce sont des

rectangles usinés en PVC, percés sur leur face
supérieure avec un taraudage pour accueillir le
moteur et sur une de leurs petites faces latérales
pour accueillir le tube en carbone de la croix
centrale. Cette pièce est entaillée latéralement, et
une vis vient écraser la matière en PVC entourant
le tube en carbone. Ce serrage s’applique sur tout
le contour du tube et ne présente aucun risque de
destruction du tube par écrasement (ce cas se
produirait si le tube était serré sans un étau par
exemple).
Nous disposons ainsi d’un assemblage démontable. Les avantages sont multiples. Nous
citerons la modularité de la structure, le remplacement rapide des pièces cassées, les
possibilités d’avoir une structure démontable pour le transport et de changer facilement
de type/marque de moteur… La pièce usinée en PVC pèse 9gr avec la vis et l’écrou. Il est
possible de reprendre un peu de matière sur chaque face et de faire une entaille en
dessous de la tige filetée du moteur. Ces modifications nous permettraient d’arriver en
dessous des 7gr qui sont le poids actuel du support (plaque en carbone et écrou). Ces
nouveaux supports sont donc déjà plus légers que les anciens car le poids de la colle et
des fibres pour fixer la plaque excède largement 2gr.
L’usinage est assez simple mais requiert de la rigueur et donc du temps. Les pièces ont
été réalisées sur la fraiseuse de l’atelier du L.E.E. et nous disposons du matériel
nécessaire pour réaliser des pièces convenables (attention à ne pas laisser s’exprimer de
manière déraisonnable ses inspirations lors de la conception, les formes un peu
complexes nécessitent rapidement une machine-outil numérique…)
D’autre part, des variantes peuvent-être imaginées. Par exemple, le
moteur peut être légèrement surélevé pour laisser un accès direct au
tube en carbone et y glisser les fils électriques d’alimentation du moteur.
Nous pouvons également penser à adapter les atterrisseurs à ces
supports,…
Il ne fait aucun doute que l’utilisation de pièces usinées a sa place au sein de ce projet.
Les assemblages s’en trouvent largement facilité, la modularité est belle et bien
présente, la fabrication des pièces n’est pas nocive pour la santé (contrairement à la
poudre de carbone) et nous disposons d’un atelier équipé pour les usiner.
La maîtrise des machines-outils est bien précieuse pour notre

projet. Nous avons usiné une pièce qui permet de fixer les
hélices dans l’étau de la fraiseuse. Par conséquent, nous avons
la possibilité de retravailler les hélices à la fraiseuse. Il en
résulte un travail de qualité, reproductible avec une très bonne
précision (au moins 0,1mm). Suite au succès de l’usinage de
quelques exemplaires d’hélice, nous conseillons de conserver
cette méthode (décrite en annexe) et de mettre au placard les
perceuses et limes qui ne fournissent qu’un résultat grossier et aléatoire.
La structure du quadricoptère est basée sur la forme d’une croix. Lors des années
précédentes, nous avons utilisés des tubes en carbone de 8mm de diamètre que nous
emboitions ensemble après avoir effectué une encoche en leur centre et que nous
collions avec de l’époxy. Ce collage était renforcé par le bobinage de fibres de carbone et
de résine époxyde. Ce montage résiste assez bien, mais casse facilement en cas de
96
crash. Nous avons donc renforcé la structure avec un cadre réalisé en tubes de carbone
également. Son rôle est bien assuré, mais seulement au détriment d’un alourdissement,
inutile tant que le drone ne tombe pas.
La seule façon de remédier ce problème est de concevoir de nouvelles architectures de
croix et de les tester en vol ou par des tests sur une structure achevée. Le caractère
démontable d’une nouvelle structure rend donc le remplacement de pièces cassées
possible. Par conséquent, nous avons adapté la solution des supports pour les moteurs
au centre de la croix, et nous avons remplacé le collage par un assemblage mécanique
un peu plus complexe, mais qui fournit de très bons résultats.
Les bras de la croix deviennent indépendants : ils se résument à de simples tubes en
carbone. Ils viennent s’emboiter dans la partie centrale qui est une « grosse plaque » de
l’étagère. Par conséquent l’étagère s’adapte
sans problème à notre nouvelle structure, et
de l’extérieure, rien ne laisse distinguer le
changement de structure. Cette pièce
centrale se compose de deux plaques en
carbone horizontale de la taille de l’étagère.
Entre celles-ci viennent se loger des
embouts, parallélépipèdes rectangles,
usinés en PVC, percés puis fissurés sur une
de leur face latérale pour permettre leur
déformation et ainsi serrer le tube. Ces
embouts sont maintenus en place par deux
vis et deux écrous qui traversent également
les deux plaques et assurent ainsi le
maintien et le serrage du bras de la croix.
Pour supprimer tout jeu résiduel, nous avons collés ces blocs aux plaques en carbone en
utilisant de la colle cyano. Nous obtenons ainsi un centre de croix rigide, peu déformable,
démontable et léger, sur laquelle est fixé rigidement l’étagère (plus de collage) et
présentant un système de fixation des tubes sure et efficace (le collage est remplacé par
un serrage périphérique mécanique).
En conclusion, cette solution combine la rigidité et la légèreté du carbone (les deux

plaques supportent les contraintes et servent de support à l’électronique) et l’efficacité
du serrage des tubes en carbone dans des pièces usinées en PVC. Comme les bras de la
croix sont indépendants, cette structure offre la possibilité d’introduire les fils électriques
dans les tubes, mais également de proposer un drone démontable pour le transport et
facilement réparable. Encore une fois, cette structure ne peut être déclarée comme la
meilleure, mais comme une possibilité qu’il faut essayer sur le terrain et comparer
concrètement avec d’autres alternatives. Aucune théorie ne peut déterminer si une
structure est meilleure qu’une autre seule l’expérimentation peut le faire. Mais nous
pouvons cependant nous fier à notre expérience et prédire certains avantages et
inconvénients.
97
5.6. Mise en application
La modélisation sous Catia nous permet d’effectuer des modifications sur le drone
de manière virtuelle. Elle nous donne également des informations sur les propriétés
massiques du drone (poids, matrice d’inertie, centre de gravité,…) et ce même après
modifications. Ces données sont précieuses et ne peuvent se calculer facilement de
manière théorique.
Nous avons donc modélisé la structure actuelle du drone. Lorsque toute l’électronique
sera choisie par les autres sous-groupes, nous modéliserons ces éléments, et nous seront
en mesure de les implanter sur la maquette du drone. Nos pourrons ainsi déterminer les
positions optimales pour chaque composant afin de limiter le poids de la structure et de
comparer les différentes solutions structurales.
Cette modélisation constitue donc un outil de décision pour le choix de nouveaux

éléments tels que modem, batteries, capteurs, récepteur, cartes ou autres ainsi que leur
positionnement sur le drone.
98
Nous avons pour l’instant réalisé que quelques supports pour les
moteurs. Nous essayons à chaque fois d’y apporter une
différence. Par exemple, une géométrie différente, un gain de
poids par la réduction des épaisseurs,… L’objectif est d’obtenir
une pièce qui est rigide, légère, simple à produire, qui assure
une fixation efficace du moteur et qui est fonctionnelle
(possibilité de laisser passer les fils électrique dans le tube en
carbone).
La pièce illustrée ci-joint en est la première version. Elle est
légère et robuste. Nous avons essayé de la faire pivoter
lorsqu’elle était montée sur un tube en carbone. Même au moyen d’une clé anglaise,
nous n’avons pas pu la tourner. Cet exemple illustre l’efficacité d’un tel serrage et
explique donc notre engouement pour une telle solution.
Actuellement, deux des hélices qui équipent le quadricoptère ont été adaptée par
cette méthode et présentent un fonctionnement sans reproche.
Cette méthode nous permet d’effectuer un serrage sur deux surfaces planes parallèles et
nous garantit une précision de l’ordre de quelques centièmes de millimètres si l’usineur
est bon. De plus, la méthode de fixation et la pièce usinée à
cet effet garantit une fixation dans l’axe et donc un
reperçage des hélices centré, propre et reproductible.
Nous avons donc défini un protocole qui permet de
reproduire sur des machines-outils la démarche que nous
effectuions manuellement avec des limes et une perceuse
pour adapter sur le quadricoptère un des éléments les plus
essentiels que sont les hélices. Nul ne peut mettre en doute
que cette méthode est plus efficace.
Nous avons réalisé en cette fin d’année un centre de structure démontable. Par
manque de temps, nous n’avons pas pu achever la structure dans son entièreté et il
reste à déterminer quels atterrisseurs vont s’y adapter et comment. Cependant, avant de
traiter ces questions, nous devons d’abord observer la structure ainsi réaliser, s’assurer
qu’elle est assez solide et ensuite terminer l’assemblage et réaliser une structure
complète en y ajoutant les tubes, les supports moteurs et l’étagère.
Les essais actuels montrent que ce centre de croix permet un léger déplacement des
tubes des bras de la croix. Ces déplacements sont dus au jeu des vis qui assurent
l’assemblage dans les trous des différents
composants. Nous avons donc collé les
blocs en PVC aux plaques en carbone et
nous obtenons un résultat très
satisfaisant : tout le jeu a disparu. La
rigidité est très bonne car les efforts sont
repris par les plaques en carbone. Les
déformations angulaires dans toutes les
orientations sont réduites. Ces
améliorations mécaniques conduisent à
des solutions et ouvrent des voies
d’amélioration, par exemple, la rigidité de
l’ensemble nous permettrait de nous
passer du cadre de renfort installé sur la
99
structure actuelle. De même, nous pourrions essayer de diminuer le diamètre des tubes
pour gagner du poids.
En conclusion, nous avons réalisé une structure alternative dont la différence de
poids par rapport à l’ancienne est négligeable (ancienne structure de croix sans cadre
rigidifiant ~95gr, nouvelle structure : centre 41gr, 4 tubes : 24gr, attache moteur : 9gr,
total : 101gr) et qui présente des solutions (cadre rigidifiant superflu) et de nombreux
avantages tels (rigidité, modularité, démontage, réparations,…). Si nous tenons comptes
de tous ses avantages, nous avons une croix de structure plus performante et plus légère
dans l’absolu (bien que des progrès puissent encore être faits pour alléger les nouvelles
pièces)
5.7. Conclusions
Cette année, la structure n’était pas au centre de nos préoccupations car nous
désirions évoluer en priorité dans les autres domaines. Mais nous nous sommes aperçu
que le drone nécessitait sans cesse de la maintenance et des réparations suite aux
crashes. Comme la structure actuelle n’est pas démontable, elle est destinée à mourir.
Par conséquent, nous nous sommes à nouveau pencher sur la question de la structure,
malheureusement trop tard pour fournir des solutions complètes.
Par contre, nous avons progressé dans nos méthodes de production. Nous avons des
contacts au près de plusieurs techniciens usineurs et nous maitrisons un minimum les
machines outils de l’atelier du LEE. Ce point est sans doute la première compétence que
doit acquérir les élèves du groupe structure. La réalisation est la base de la conception
des pièces et un minimum d’expérience est nécessaire pour arriver à des résultats
probants.
100
5.8. Améliorations de la carte actuelle
La carte actuelle est bien fonctionnelle sur le plan électrique, mais lors des tests de vol,
plusieurs problèmes essentiellement de connectique sont apparus. Il fallait donc revoir la
carte en lui ajoutant certaines modifications
5.8.1. Les connecteurs
Les connecteurs étant tous bricolés de façon assez grossière nássuraient pas une bonne
accroche et plusieurs fils se détachaient même soudainement lors des tests.
Ce problème affectait aussi les connecteurs de lÁTMEGA que ceux des moteurs.
On a donc procédé à la recherche de connecteurs adéquats pour chacune de ces
fonctions
5.8.1.1. Connectique moteurs
Ces connecteurs doivent transmettre des courants assez puissants, des connecteurs du
type PIN HEADER qui sont utilisés sur la carte sont dáilleurs pas conçus pour ce type
dútilisation. Nous avons eu deux choix possibles : garder la même forme de connecteur
mais chercher un autre modèle qui tient mieux.
Exp. : les connecteurs de la marque JST (www.jst.com) sous Wire to Board /
Disconnectable/ VL connector.
Ou utiliser des connecteurs à vis, qui sont généralement retenus pour cette application.
Le choix sést fait sur les derniers, car comme on ne touchait que très rarement aux fils
du moteur, ils garantissent un maintient absolu du contact. En plus des différents
modèles étaient disponibles dans le catalogue Radiospare ce qui facilite la commande:
des connecteurs phoenix (www.phoenixcontact.com) assez compacts…
Moteur Alim
Ce choix a été aussi fait pour lálimentation de la carte. La seule contrainte était de
trouver un connecteur à vis assez compact et qui serait capable de transmettre jusquá
40A. Línconvénient de cette solution cést que ces connecteurs sont toujours plus
imposants que les connecteurs PIN Header. Il faut donc prendre leurs tailles en compte.
101
5.8.1.2. Connectique ATMEGA
Les Pin Header de type femelle utilisés ici maintenaient les fils dúne manière
quelconque et un décrochage survenait fréquemment lors des vols. L idée était dútiliser
les mêmes pin header mais de type male pour pouvoir accrocher dessus des connecteurs
à câble plat. Ces derniers assurent une bonne accroche une fois montés et une facilité de
maniement (accroche/décroche) très pratique. Línconvénient est quíls ont une cage
assez importante. On a donc décidé dálterner la direction des connecteurs males de la
carte entre les deux faces (voir figure).
5.8.2. Fonction Reset de lÁTMEGA
Ceci se faisait toujours en court-circuitant avec un bout de fil 2 entrées dans le bloc de
connecteurs de l atmega. Lídée était de rendre l ópération plus pratique en ajoutant un
bouton poussoir sur la carte qui ne relie ces deux entrées que lorsquón appuie dessus.
5.8.3. Intégration des éléments oubliés lors de la conception
La mesure de la tension dálimentation a été pensée après la réalisation de la carte par

le sous-traitant. Un pont diviseur et une connexion ont été ainsi ajoutés par soudage. On
devait donc les intégrer proprement sur la carte.
Une deuxième LED, dont la fonction sera définie selon les besoins, est ajouté aussi.
Comme le port C (pins 35 à 42 du microcontrôleur) est défini par défaut comme port OUT
dans lÁTMEGA et quíl nést pas utilisé, la LED supplémentaire a été ajouté sur le pin
C0.
Pour apporter toutes ces modifications, il fallait donc reprendre le Lay-out (Board) de
láncienne carte, tracer les pistes à la main, et changer la disposition des composants
pour créer de la place pour les nouveaux.
5.8.4. Réalisation dúne carte de communication au standard RS232
Une telle carte permet de communiquer directement avec nímporte quel composant
électronique supportant ce standard (c.a.d possède des entrées/sorties Tx, Rx) en
utilisant le port série de lórdinateur et le logiciel « Terminal ». Nous avons décidé de
102
construire une pour communiquer directement avec lát90pwm sans devoir passer par le
Stk500 et donc écrire un code.
Le schéma dúne telle carte se retrouve facilement sur internet. Lálimentation est
fournie (5V) par le kit STK520.
• En rouge : le composant RS232 en format CMS

• En Bleu : La liaison série avec le PC par le biais dún connecteur DB9 femelle.
• En vert : La connection avec lÁT90PWM3 à travers le module STK520.
Lálimentation de la carte est fournie par cette liaison
• En jaune : LÁT90PWM3 monté sur le stk520. Il faut faire attention à le mettre
dans le bon sens
103
5.9. Banc d’essai
5.9.1. Objectif
Pour déterminer le groupement de propulsion du quadricoptère, nous devons

tester les performances des moteurs, mais aussi des hélices. Or la poussée d’un moteur
(un des critères de performance) est liée à la qualité de l’hélice. Par conséquent, il est
bon de caractériser les essais effectués sur les moteurs par le facteur de mérite de
l’hélice. A la fin des essais, nous pourrons adapter au mieux le choix du couple moteur
hélice. Pour arriver à faire ce choix, il faut recueillir le résultat d’essais effectués sur un
banc et qui fournissent la poussée du couple moteur hélice et le couple exercé par le
moteur (du aux
frottements de l’air et
opposé à la rotation de
l’hélice). Notre objectif
est de mettre au point un
banc d’essais pour
moteurs qui nous
permettent de suivre la
poussée, le couple, la
consommation et la
vitesse de rotation du
moteur en fonction de sa
tension d’alimentation et
de l’ordre donnée au
variateur qui commande
le moteur. Il est possible
d’obtenir toutes ses
données avec les moyens
à notre disposition, mais
nous devons effectuer
plusieurs manipulations
avec des moteurs différents (à courant continu par exemple). L’avantage de ce nouveau
banc d’essais est l’obtention de toutes les mesures en un seul essai.
5.9.2. Le banc d’essais
Il ressemble au banc d’essai de l’année passée mais présente des améliorations

significatives. Sa structure est entièrement réalisée en aluminium (dural) et toutes les
articulations sont montées sur roulement à billes, éliminant ainsi tout jeu. Le balancier
est ancré par une jauge de contrainte à la base du banc pour mesurer de manière précise
la traction du moteur (au lieu de l’utilisation périlleuse d’une
balance pour l’ancien montage). Le moteur est monté sur
une plate-forme mobile : elle peut tourner sur son axe
vertical. Ce mouvement est empêché par une deuxième
jauge de contrainte qui nous fournit donc la force exercée à
une certaine distance du centre de rotation par le couple du
moteur. Un capteur optique monté sur le support moteur
nous donne la vitesse de rotation du moteur. Et enfin, un
ampèremètre monté en série sur l’alimentation du variateur
nous donne la consommation du moteur. Toutes ses
mesures s’obtiennent simultanément au cours de la même
manipulation.
104
La plate-forme mobile nous fournit la possibilité de monter tous les types de moteurs. Et
si un moteur nécessite un montage particulier, toutes les pièces du banc d’essais sont
démontables. Nous pouvons donc les remplacer à notre guise.
Ci-dessous se trouvent quelques images de la modélisation du banc d’essais :
5.9.3. Les capteurs
Ce banc d’essais s’appuie sur différents capteurs. Ce

sont principalement des capteurs de forces (munis de
jauges de contraintes) et nous pouvons également
adapter un capteur optique pour récupérer la vitesse de
rotation de l’hélice.
Les moteurs exercent au maximum une poussée de
900gr. Nous avons donc choisi un capteur de force de
9N environs. Pour le couple, une hélice 9x6 produit, à
10.000 tours/minutes sur moteur à courant continu, un
couple dont le poids mesuré à la balance avec un bras
de levier de 20cm est de 35gr. Par conséquent, un capteur de force dont la charge
nominale est d’une demi-livre convient parfaitement à cette application (le bras de levier
du banc d’essais est de 3,5cm). Nous avons trouvé de tels capteurs chez un fabricant
américain (www.futek.com) qui dispose de revendeurs en France. La documentation du
capteur se trouve en annexe, leurs numéros de référence sont FSH1460 et FSH1462 pour
une mesure de force allant de0N à, respectivement, 2,2 et 8,9N.
Des capteurs optiques pour mesurer la vitesse de rotation

peuvent également se trouver dans le commerce. Nous n’avons
pas poussé les recherches mais nous avons déjà trouvé une
solution possible issu de l’aéromodélisme : un capteur optique
qui s’interface comme une sonde à effet hall. Une bande
réfléchissante est placée sur la cage tournante du moteur, et
lorsque cette bande passe devant le capteur, une différence de
potentiel apparaît aux bornes des connecteurs du capteur.
En illustration, le kit de capteur optique pour régulateur de moteurs thermiques de
modèles réduits d’hélicoptère « Throttle Jocket Optical Sensor ». Ce capteur coute une
trentaine d’euros…
105
5.9.4. Conclusions
La conception de la partie mécanique du banc d’essais est complètement achevée.

Les plans ont été livrés aux techniciens et les pièces devraient être achevées pour la date
de la soutenance. A cause de délais de livraison trop importants, nous n’avons pas pu les
commander cette année, mais toutes les références sont données dans ce rapport et les
indications pour commander les composants sont très claires sur le site de Futek. Le banc
d’essais sera donc opérationnel pour l’année prochaine et ne nécessite plus que
l’implémentation des capteurs (jauges de contraintes). De telles expériences ont déjà été
effectuées dans les laboratoires de l’ECP et ne devraient, par conséquent, pas poser de
trop gros problèmes. De plus, le banc d’essais étant monté entièrement sur capteur, les
membres du projet des prochaines années peuvent établir une procédure automatisée
via un programme sur ordinateur muni de cartes d’acquisitions et des sorties de
commande du variateur adéquates.
106
6. INTERFACE HOMME MACHINE (IHM)
L’interface homme- machine joue un rôle important pendant le pilotage du drone sur le
terrain militaire. Elle assure plusieurs fonctions de la communication de la machine avec
le pilote/ navigateur et vice-versa. Lors de l’opération, après avoir perdu le contact visuel
avec le drone, la station sol offre le seul moyen de communication avec le quadricoptère.
Ainsi, c’est d’une importance primordiale pour l’avertissement du drone que la station sol
ne tombe pas en panne ; ceci pourrait conduire à la perte totale du quadricoptère sur le
terrain militaire.
Les enjeux apportés par le groupe IHM de cette année consistent en la restructuration
globale de la station sol afin d’assurer son fonctionnement propre. Le danger principal est
l’ordinateur avec sa dépendance du système d’exploitation Windows qui constitue une
incertitude et donc un point faible.
La restructuration de la station sol consiste en l’intégration d’un microcontrôleur dans la
station sol qui assure le fonctionnement du quadricoptère même si l’ordinateur est déjà
planté. Donc, le microcontrôleur diminue la probabilité de perdre la connexion avec le
quadricoptère lors du vol.
Le développement de la station sol peut être subdivisé en deux parties : le côté hardware
et le côté software.
Le côté hardware est décrit dans la partie transmission, parce que le groupe transmission
a effectué l’étude du microcontrôleur et ses tests. Vu que le microcontrôleur est relié
avec le modem, c’est le groupe transmission qui a géré cette partie.
En ce qui concerne la partie software, la nouveauté est l’interface graphique sous le
logiciel Matlab.
Cette solution permet l’incrustation des données sur le flux vidéo afin d’améliorer le
pilotage et la navigation du drone. Pendant le concours de la DGA, le groupe du projet de
l’année 2004 à 2005 a constaté que la fenêtre vidéo était trop petite et que c’était
impossible de surveiller toutes les données affichées en même temps. Un pilotage facile
pour une personne inexpérimentée avec l’interface graphique était impossible. C’est la
raison pour laquelle l’incrustation des données sur le flux vidéo améliore énormément la
situation.
107
6.1. Objectifs du groupe Interface Homme-Machine
Afin de suivre le développement du groupe IHM, nous avons créé un tableau. Celui-ci a
permis de retracer toutes les tâches effectuées et leurs avancements ainsi que les futurs
objectifs du sous-groupe.
Les objectifs du groupe IHM, grosso modo, consistaient en

La capitalisation et la continuation des travaux sur l’interface graphique qui ont été
développés sous Microsoft Visual Basic 6.0 pour assurer la réalisation des tests pendant
toute l’année
La réalisation d’une nouvelle structure de la station sol afin d’éviter la dépendance de
l’ordinateur
L’implémentation d’une nouvelle interface graphique pour incruster l’image de la caméra
Pour plus de détail, voici le tableau des objectifs :
PROJET DRONE QUADRICOPTERE 2006
GROUPE IHM
DEAD % TEMPS
OBJECTIFS AUTEUR
LINE AVANCEMENT CONSACRE
Etude de la station sol
Discussion avec P. Martin sur les

14-mars- Michael et
possibilités de la structure de la 100% -
06 Pascal
station sol
Brainstorming pour trouver des
14-mars- Michael et
solutions différentes pour la station 100% -
06 Pascal
sol
Evaluation des avantages/ 14-mars- Michael et
100% -
inconvénients des solutions 06 Pascal
Evaluation de la faisabilité technique 14-mars- Michael et
100% -
des solutions 06 Pascal
14-mars- Michael et
Conclusions/ résumés des solutions 100% -
06 Pascal
14-mars- Michael et En total 2
Choix final 100%
06 Pascal séances
Stagiaire et
14-mars-
Problématique joystick / Interfaçage 100% Groupe
06
Transmission
Commentaires
108
Fonctions de l'interface utilisateur
Affichage des informations = Output

Quelles infos est-ce qu’on veut
100% 1 séance
afficher?
• Brainstorming pour trouver toutes

25-avr.- Michael et
les infos d’affichage Flux vidéo 100%
06 Pascal
Batterie Vidéo …
• Evaluation : Distinction entre

pilote et navigateur ? Qu’est-ce qu’il Michael et
9-mai-06 100%
faut chacun pour bien commander Pascal
le drone ?
• Evaluation de la faisabilité de
chaque info est-ce qu’il est possible
de récupérer les données pour
chaque info ? 25-avr.- Michael et
100%
Est-ce que les valeurs pour chaque 06 Pascal
info sont mesurables/ accessibles ?
Est-ce qu’on peut les transmettre
(débit maximal) ?
Michael et
Comment va-t-on les afficher? 100% 1 séance
Pascal
• Brainstorming pour trouver

plusieurs solutions Solutions
software : Quelle représentation
graphique, par exemple horizon
25-avr.- Michael et
artificielle ? Quels symboles ? 100%
06 Pascal
Seulement l’affichage des valeurs
actuelles ou aussi l’affichage des
valeurs précédentes ? Solutions
hardware : Lunettes, PC, LEDs…
• Evaluation des solutions par les

critères suivants :
Utilité des différentes solutions
Lisibilité
Michael et
Espace ; combien d’espace faut-il 9-mai-06 100%
Pascal
sur l’écran ?
Simple/possible à programmer ?
Compatibilité avec l’affichage
d’autres infos
• Sélection des infos et les types Michael et

9-mai-06 100%
d’affichage Pascal
109
Michael et
Programmation 30-mai-06 90% 5 séances
Pascal
Commentaires
Mise en oeuvre = Programmation en MatLab
Flux vidéo
Initialiser la caméra 9-mai-06 100% Michael 1/2 séance
Réglage des paramètres pour bien
9-mai-06 70% Michael 1/2 séance
afficher le flux vidéo
Commentaires Le flux vidéo n'est pas encore testé avec la caméra du quadricoptère, parce que la
batterie était vide.
Connexion sérielle
Ouvrir le port sériel 9-mai-06 100% Pascal 2h
Récupérer les bytes transmis 16-mai-06 100% Pascal 2h
Décoder les infos 16-mai-06 100% Pascal 4h
Enregistrer les données transmises 30-mai-06 60% Pascal 1/2 séance

Commentaires
GUI
Implémentation d'une interface sans Pascal et
26-mai-06 100% 3 séances
utilisation du modem Michael
Michael et
Intégrer le flux vidéo 9-mai-06 100% 1 séance
Pascal
Michael et
Incruster les éléments graphiques 30-mai-06 100% 1 séance
Pascal
Michael et
Intégrer les infos transmises 30-mai-06 100% 1 séance
Pascal
Commentaires
OPTIMISATION de l'IHM actuel en Visual Basic
Enregistrement des données

4-avr.-06 100% Pascal 1 séance
transmises par le quadri
Enrichissement des flux de données 25-avr.-
100% Pascal (ME)
récupérées par la station sol 06
Changement du déchiffrement pour 1h + 2h de
9-mai-06 100% Pascal
les tests du groupe Algorithme tests
25-avr.-
Récupération des données GPS 100% Pascal 20min
06
110
Commentaires
Tests
11-avr.- Michael et
Tester l'enregistrement des données 100% 1 séance
06 Pascal
Tester la transmission des 25-avr.- Michael et
100% 2h
coordonnées GPS 06 Pascal
Tester le changement de VB à 25-avr.- Michael et
100% 3h
MatLab 06 Pascal
Tester la connexion de l'ordinateur 18-avr.- Michael et
100% 1h
avec l'ATMega de la station sol 06 Pascal
Commentaires
RAPPORTS
Rédaction pour le rapport final - Michael et

16-mai-06 100% 1 séance
Vbeta Pascal
Rédaction pour le rapport final - Michael et
30-mai-06 100% 2 séances
Vdef Pascal
Commentaires
111
6.2. Capitalisation et travail sur le logiciel VB6
Le début de notre travail consistait en la capitalisation et la compréhension de l’interface

graphique implémentée sous VB6. Afin de faciliter ce travail lourd pour le groupe IHM
suivant, nous allons expliquer le source code en détail en annexe.
Un des problèmes de l’interface graphique était que les données envoyées par le
quadricoptère étaient toutes perdues à la fin du vol.
Pour assurer et mieux tester le fonctionnement du quadricoptère en vol nous avons
ajouté du code source qui permet d’écrire toutes les données du quadricoptère dans un
fichier .txt. Chaque paquet de données transmis du quadricoptère à la station sol est
ainsi enregistré et sert à retracer le fonctionnement du quadricoptère lors du vol.
Les données envoyées sont :

M1, M2, M3, M4
Roll, Yaw, Pitch
Vx, Vy, Vz
Altitude
GPS
Batterie
PositionXr, PositionYr
Voici un extrait du fichier « data 18-04-06 11h52.txt » :
Counter Time M1 M2 M3 M4 Roll Yaw Pitch
5023 11:55:36 140 160 158 127 7,7 2,11 -114,39

5024 11:55:36 148 158 151 128 8,02 2,22 -114,26
5025 11:55:36 150 161 149 131 8,3 1,76 -114,24
5026 11:55:36 159 165 151 129 8,43 0,89 -114,33
Pos. Pos.
Counter Vx Vy Vz Alt. GPS Batt.
Xr Yr
5023 0,37 -0,21 0 72 192 10,15 0 0
5024 0,39 -0,19 0 73 192 10,15 0 0
5025 0,41 -0,17 -0,02 73 192 10,15 0 0

5026 0,43 -0,16 -0,04 73 192 10,15 0
112
6.3. Restructuration de la station sol
Pour la suite du rapport de la partie IHM, nous allons vous montrer et commenter les
solutions possibles pour un problème précis. Ensuite, nous allons vous expliquer le choix
pour la meilleure solution (ou la moins mauvaise). Pour conclure chaque problème, nous
allons vous montrer la mise en application de cette solution.
6.3.1. L’objectif de la restructuration de la station sol
Pour la restructuration de la station, on s’est fixé les buts principaux suivants :

Diminution de la dépendance de l’ordinateur. Un arrêt ou redémarrage abrupt de
l’ordinateur lors d’une opération militaire pose un grand danger et signifie la perte du
quadricoptère.
Réduction du nombre de transmission du quadricoptère vers la station sol Ceci entraîne
une diminution de la complexité de la station sol ainsi qu’une diminution éventuelle du
poids sur le drone.
6.3.2. Solution actuelle
Afin de présenter des nouvelles solutions pour la restructuration, on va examiner les

avantages et inconvénients de la situation actuelle.
L’état initial de la station sol est présenté sur le schéma suivant :
Vidéo
PCTV
Manettes PC Modem
Interface
Pilote
Navigateur
113
Pour évaluer la situation actuelle, on regarde les avantages et les inconvénients en

détail :
Avantages Inconvénients
Solution fonctionne Dépendance du PC
Pas d’interfaçage des manettes Trois dispositifs de transmission
Il faut deux utilisateurs
Pas d’infos pour le pilote (vidéo, vitesse,
carte,…)
Conclusion
Il faut constater que la solution actuelle fonctionne sans avoir de bugs. Un
développement de l’interface graphique serait possible, mais ne résout pas les objectifs
fixés. La dépendance de la station sol de l’ordinateur est l’inconvénient principal de la
situation actuelle qu’il faut abandonner.
6.3.3. Première solution alternative
Elle est constituée de deux sections principales

Un microcontrôleur AVR qui est relié avec le modem, l’ordinateur et les manettes du
pilote
Un ordinateur qui reçoit le flux vidéo par le PCTV et les données du quadricoptère par le
microcontrôleur ; il est aussi relié avec l’interface du navigateur (clavier, souris, manche
à balai, …)
Vidéo
LED Modem PCTV

Infos
ou AVR PC
Affichage
Infos
Manettes Interface
Pilote Navigateur
114
Les avantages et inconvénients de cette solution sont décrits en détail dans le tableau
suivant :
Seulement deux dispositifs de transmission Il faut deux utilisateurs
Indépendance (du pilotage) du PC Coûts élevés à cause du microcontrôleur
Pas de retard à cause du PC Redondance AVR-PC
Pilotage sans navigation/ PC Grande différence par rapport à la situation
actuelle
Avec l’objectif d’éviter la dépendance de l’ordinateur et diminuer les transmissions vers le

quadricoptère en gagnant du poids sur celui-ci, cette solution sait répondre à tous les
objectifs principaux de la restructuration de la station sol.
6.3.4. Deuxième solution alternative
est basée sur l’ordinateur comme élément principal de la station sol. En diminuant le
nombre de connexion avec le quadricoptère, l’ordinateur est le cœur de cette solution.
Vidéo
PCTV
Manettes PC Modem
Interface
Pilote
Navigateur
115
En regardant les avantages et les inconvénients en détail, on arrive au tableau suivant :
Seulement deux dispositifs de transmission Dépendance du PC
Il faut deux utilisateurs
Le principal inconvénient de cette solution est que la station sol dépend fortement de
l’ordinateur, une solution qui n’est pas du tout envisageable.
6.3.5. Troisième solution alternative
L’idée est de réunir le navigateur et le pilote et de piloter/diriger le quadricoptère à partir

du flux vidéo envoyé sur l’ordinateur. Voici le schéma de la solution :
Vidéo
PCTV
PC Modem
Interface
Pilote et
Navigateur
Les avantages et les inconvénients sont décrits dans le tableau suivant :
Il faut une personne pour le pilotage et la Dépendance du PC
navigation
Seulement deux dispositifs de transmission
116
Cette solution a les mêmes inconvénients comme la solution précédente ce qui mène à
l’abandonner.
6.3.6. Évaluation des différentes solutions
Pour mieux comparer les quatre possibilités d’une nouvelle structure, on les regroupe
dans un tableau en évaluant chaque solution par les critères suivants :
Dépendance de l’ordinateur
Coûts
Nombre de dispositifs de transmission
Nombre de personnes (navigateur et pilote, navigateur- pilote)
Solution Solution AVR Solution Solution

actuelle Ordinateur I Ordinateur II
Dépendance de
l’ordinateur - + - -
(x2)
Coûts = - = =
Nombre de
dispositifs de
- + + +
transmission
(x2)
Nombre de
= = = +
personnes
Total ---- +++ = +
Les catégories de l’évaluation sont (+, =, -) qui représente respectivement (positive,

égal, négative).
Le total de l’évaluation des solutions est calculé en pondérant les différents critères.
Le choix final de la solution du microcontrôleur était pris après avoir fait une étude de
faisabilité. Donc, ensuite on va examiner la faisabilité technique de la solution.
6.3.7. Faisabilité de la solution envisagée
Les questions et problèmes techniques à résoudre pour la réalisation de la solution avec

le microcontrôleur sont :
Intégration du flux vidéo sous Matlab/ VisualBasic
L’intégration du flux vidéo sous VisualBasic était déjà réalisée par l’équipe 2004- 2005.
Donc, il reste à déterminer si c’est possible d’intégrer un flux vidéo sous le logiciel
Matlab. Après le conseil de M. Martin et des recherches sur le site web
www.mathworks.com du développeur de Matlab, on a trouvé l’« Image Acquisition
Toolbox » qui permet d’intégrer un flux vidéo sur un port série avec le protocole RS232.
Connexion AVR- PC : comptabilité du protocole RS232 avec Matlab/ VisualBasic
D’après la documentation d’ATMEL AVR STK500, une connexion est établie avec le PC par
le protocole RS232 (http://www.atmel.com/dyn/resources/prod_documents/doc2591.pdf
(vue le 21/03/2006)). C’est-à-dire qu’il reste à déterminer si les deux logiciels Mathworks
Matlab et VisualBasic savent communiquer avec le protocole RS232. La documentation
de Matlab
(http://www.mathworks.com/access/helpdesk/help/toolbox/xpc/io_ref/index.html (vue le
21/03/2006)) montre qu’il est possible d’ouvrir un port série et communiquer avec le
protocole RS232.
117
La connexion de VisualBasic avec un contrôleur se fait avec le Microsoft Comm Control

6.0 de VisualBasic 6.0 et la liaison RS-232 (http://vostock.cliranet.com/vb-rs232.php,
http://grafikm.developpez.com/portcomm/,
http://support.microsoft.com/default.aspx?scid=kb;en-us;194922 (vue le 21/03/06).
Interfaçage des Manettes : Quelles manettes ? Interfaçage possible ? Avec quel

protocole ?
Principalement toutes les manettes utilisant le protocole RS232 sont capables de
communiquer avec un microcontrôleur. Une étude plus détaillée sur la manette
Playstation était faite par un stagiaire de l’Ecole des Mines de Paris. La manette
Playstation sait utiliser le protocole RS232 sur un port série
(http://www.gamesx.com/controldata/psxcont/psxcont.htm (vue le 21/03/06)) pour la
communication. Vu que le développement de la manette Playstation va évoluer avec la
sortie de la Playstation III, ces manettes sont une possibilité envisageable ainsi que facile
pour le pilotage du drone.
Pilotage du drone à travers de l’AVR possible (retard, précision) ?

Le pilotage du drone à travers d’un microcontrôleur est possible vu que le
microcontrôleur transmet simplement les données vers le modem et ensuite vers le
quadricoptère. La précision de piloter le drone ne va pas être dégradé, parce que le
retard de la transmission est supposé négligeable.
Comme conclusion, on peut constater que la solution envisagée ne pose pas de problème
de faisabilité technique.
118
6.4. Matlab ou VisualBasic ?
Les critères principaux pour le choix entre les logiciels Matlab et VisualBasic étaient,
grosso modo, le flux vidéo et l’incrustation des images sur le flux vidéo.
6.4.1. Expérience pendant le concours
L’interface graphique de VisualBasic utilisée pendant le concours de la DGA en juillet

2005 avait un trou à l’intérieur pour afficher le flux vidéo du logiciel MeuhMeuhTV.
Il s’avérait que la fenêtre du flux vidéo était trop petite pour bien naviguer et piloter le
drone. En plus, il était impossible de regarder l’horizon artificiel, la position, la boussole
ou le vecteur de vitesse et le flux vidéo en même temps.
Afin de faciliter le vol du quadricoptère avec l’interface graphique, il faut agrandir la
fenêtre du flux vidéo et incruster les données sur l’image.
6.4.2. Justification du choix Matlab
Il existe plusieurs raisons pourquoi nous avons décidé d’implémenter l’interface

graphique sous Matlab. Premièrement, Matlab sait intégrer un flux vidéo assez facilement
avec l’« Image Acquisition Toolbox ». Deuxièmement il est possible d’incruster les
données sur le flux vidéo ce qui permet d’avoir une meilleure vue globale des données et
du flux vidéo lors du vol du quadricoptère. En plus, Matlab est construit pour afficher
facilement des traitements et grandeurs mathématiques. Conséquemment, il est possible
d’afficher une évolution d’une grandeur envoyée par le drone dans un graphe avec deux
axes ce qui offre une meilleure vue globale de l’état du drone. Ceci est très utile pour les
tests où on veut trouver des peaks dans l’évolution d’une grandeur.
L’explication détaillée du code source est présentée dans l’annexe.
6.4.3. Les codes en Visual Basic et Matlab
Comme il n’existait pas encore une documentation détaillée du code en Visual Basic,
nous avons commencé avec celle-ci pour bien comprendre le code qui était programmé
par l’équipe de l’année 2004/2005. Ceci était aussi important parce que tous les tests
n’étaient possibles qu’avec ce programme. Pour améliorer les tests nous avons après
intégré la possibilité d’enregistrer les données transmises.
Du côté Matlab, nous avons essayé d’intégrer des solutions du code en Visual Basic et
d’un programme de M. Martin, qu’il avait écrit pour tester l’intégration du flux vidéo et du
port sériel en Matlab. Le but principal du nouveau programme est d’améliorer l’utilité et
la clarté du GUI. Tous les programmes sont expliqués en détail dans l’annexe.
Bien que l’affichage du flux vidéo et la récupération simultanée des données par le port
sériel aient bien fonctionné lors des tests avec la vieille centrale inertielle, le programme
ne fonctionnait plus au dernier moment lorsque nous avons assemblé les deux parties du
code pour le flux vidéo. Ce problème, déjà rencontré en Visual Basic, est décrit dans le
rapport 2005. Malheureusement, nous n’avons pu trouver de solution à ce jour.
En outre la qualité du flux vidéo n’est pas toujours excellente. Bien que l’image soit très
bonne quand on l’affiche avec le logiciel PCTV, elle se dégrade fortement quand on
l’affiche avec Matlab.
119
6.4.4. Objectifs pour l’avenir
Nous pourrions imaginer une version du programme avec une petite carte (« minimap »)
du terrain pour afficher la position du drone et son environnement. Pour le moment nous
avons juste mis une image du terrain de rugby à la place de cette carte.
Comme le navigateur veut peut-être regarder quelques informations plus en détail
pendant le vol du drone, on pourrait imaginer qu’il pourrait agrandir quelques éléments
du GUI en posant la souris en dessus ou d’afficher plus d’informations si nécessaires.
120
7. HARDWARE IN THE LOOP (HIL)
7.1. Objectifs du groupe HIL et organisation du travail
7.1.1. Objectifs de notre groupe
En une phrase, le but global de notre projet est le vol autonome du Quadricoptère.
Les tests Hardware-in-the-Loop (HIL) combinent dans une même boucle de simulation
des composants softwares et hardwares afin de tester des systèmes dans les conditions
du monde réel, sans pour autant devoir disposer du véhicule complet.
L’intérêt du HIL est de fournir une validation des contrôleurs hors véhicule.
L’objectif de notre groupe est de fournir un système Hardware-in-the-loop (HIL) aux
autres groupes. Ce système devant permettre la simulation du comportement du
Quadricoptère ainsi que le test et la validation de nouveaux algorithmes de contrôle.
Les données dont nous disposions étaient le résultat des travaux de développement des
années précédentes à l’Ecole Centrale Paris : structure physique, capteurs, et
implémentation hardware du contrôleur
Il existe différentes versions et types de contrôleurs, ces derniers ont été optimisés au
cours des essais en vol ou à l’aide d’outils d’optimisation fournis par MATLAB. Leur rôle
est d’assurer un comportement « stable » et « satisfaisant » en fonction des consignes et
références choisies. Avec le système HIL, il est facile de tester des paramètres modifiés
ou même de nouvelles lois de contrôle (par exemple la compensation de saturation).
La simulation offre beaucoup plus de possibilités que l’expérience réelle pour récupérer et
afficher les variables de vol. Ainsi, la modélisation du drone et l’intégration des
algorithmes existants apportent de nouvelles connaissances sur le contrôle en général.
GROUPE HIL
DEAD
OBJECTIFS % AVANCEMENT
LINE
Connaisances de base
21-mars-
S'initier au développement sur STK500 99%
06
Commentaires
Interface MIDGII simulée (RS232)

Comprendre la communication via RS232 dans le
4-avr.-06 100%
main.c
11-avr.-
établir un lien ATMEGA-Target PC via RS232 100%
06
29-nov.-
Comprendre le protocole de la MIDGII 100%
05
29-nov.-
Simuler les messages de la MIDGII (encodage) 100%
05
Valider l'encodage des messages de la MIDGII 17-janv.-
100%
(décodage) 06
Commentaires
Interface moteurs simulés (PWM)
121
17-janv.-
Comprendre la communication via PWM dans le main.c 90%
06
17-janv.-
établir un lien ATMEGA-Target PC via PWM 100%
06
17-janv.-
connexion basique PCI-CTR05 100%
06
17-janv.-
affichage PWM sur xPC 100%
06
17-janv.-
créer 1 PWM avec l'Atmega 100%
06
17-janv.-
créer 4 PWM avec l'Atmega 100%
06
17-janv.-
filtrage des pertubations 80%
06
Commentaires
Interface capteur à ultrasons simulé (I2C)

28-mars-
comrendre l'interaction ATMEGA-capteur 80%
06
25-avr.-
Utiliser le capteur réel 100%
06
Intervenir dans le main.c pour simuler un vol 25-avr.-
50%
stationnaire 06
Utiliser l'évaluation de l'altitude de la MIDGII simulée 2-mai-06 100%
25-avr.-
Simuler le capteur à ultrasons sur le STK500 (software) 100%
06
Simuler le capteur à ultrasons (hardware système 25-avr.-
100%
complet) 06
Commentaires
Bouclage xPC-Atmega
établir une communication o xPC (RS232) Atmel (PWM) 14-mars-
100%
xPC (Scope) 06
établir une communication o Atmel (PWM) xPC (RS232) 14-mars-
100%
Atmel (Leds) 06
établir un système simple de stabilisation en boucle 21-avr.-
100%
fermée (1 PWM-RS232) 06
établir un système simple de stabilisation en boucle
2-mai-06 100%
fermée (timer = RS232, 1 PWM)
établir un système proche de Quadri de stabilisation en
2-mai-06 100%
boucle fermée (timer = RS232, 1 PWM)
2-mai-06 100%
boucle fermée (4 PWM-RS232)
2-mai-06 100%
boucle fermée (I2C-RS232)
2-mai-06 100%
boucle fermée (PWM-I2C&RS232)
simulation du Quadri sous xPC 16-mai-06 80%
Réaliser le bouclage (stable) ATmega-Target PC (avec le
16-mai-06 50%
main.c et le modèle de quadri)
Commentaires
Assurer la pérennité du savoir-faire acquis
122
28-mars-
Rédiger un guide de démarrage pour HIL 100%
06
Plateformes de tests Vdef our les groupes 16-mai-06 0%
Synthèse méthode déf. pour rapport (2/3 pages) 16-mai-06 100%
Commentaires
FOURNIR UNE PLATEFORME DE TESTS POUR ATMEGA

Plateformes de tests V1 pour les groupes 16-mai-06 30%
Plateformes de tests Vdef pour les groupes 23-mai-06 0%
Synthèse méthode déf. pour rapport (2/3 pages) 23-mai-06 100%
Commentaires
INTEGRER LES MODIFICATIONS DU DRONE

Etude et tests sur la modifications des variateurs et des
23-mai-06 0%
moteurs
Etude et coordiantaion avec le groupe transmission sur
23-mai-06 0%
les modifications du circuit de transmission des infos
Etude et coordinataion avec le groupe IHM sur les
23-mai-06 0%
modifications du boîtier de commande
Commentaires
VISUALISATION HIL (OPTIONNEL)

Etude théorique sur les moyens de créer une interface
2-mai-06 100%
graphique pour HIL
Mise en place de l'interface graphique 23-mai-06 90%
Tests et synthèses des avancées 23-mai-06 60%
Commentaires
RAPPORTS
14-mars-
Rédaction du rapport intermédiaire II - Vbeta 0%
06
28-mars-
Rédaction du rapport intermédiaire II - Vdef 0%
06
Rédaction du rapport final - Vbeta 16-mai-06 100%
Rédaction du rapport final - Vdef 30-mai-06 100%
Commentaires
7.1.2. General Design of Process Controls
The sciences automation and control engineering provide a wide range of algorithms for
the identification and control of systems. The keyphases for practical implementation of
process controls are the design of a controller and the tuning of the same.
7.1.2.1. Rapid Control Prototyping
This step includes the modeling and simulation of the process as well as the design of an
appropriate controller.
One possibility for the analysis and modeling of the system is to compare the behaviour
of the process (step response, nyquistplot) to general models. The parameters are
123
obtained through a parameter-fit. A manyfold of examples on this subject can be found

in [1]
Another way is the direct modeling of the system through physical assumptions and the
derivation of a model from the mathmatical equations. Practical experiences may still be
needed to obtain all relevant parameters.
Tools like Matlab/ Simulink can now be used to simulate the process and examine the
open-loop behaviour. These results, the linearization of the model and general
knowledges about the system may imply a certain type of controller for this process. The
toolbox Matlab/Sisotool gives a wide range of possibilities for the design of the
appropriate controller to stabilize the linearized system.
7.1.2.2. Tuning of the controller
The controller obtained in the previous section has a priori several issues:
it does not consider the non-linearities of the model
it has been designed in a "perfect" environment without noise and delays due to the
interfaces
it does not consider the discretization in the "real" controller
All those issues could be included in the previous phase, exceeding a more complex
model. However, an efficient and reliable test is only possible with a closed loop test
including the hardware-interfaces and the implementation of the controller.
An alternative to experiments on the real process (which may be difficult or even

impossible) is connecting the controller to a PC with a real-time simulation of the process
- Hardware-in-the-Loop (HIL).
This method allows to test the controller in a "real" environment and to apply all criteria
for tuning, including those reaching critical states of the system. Several iterations of the
modelling and tuning may be needed to obtain satisfying results. Besides risks, HIL saves
time, costs and includes the imperfections of data transmission.
Rapidcontrol Prototyping (RCP) and Hardware-in-the-loop (HIL) constitute the key

methods for the modern design of process controls.
The Matlab/Simulink package xPC-Target has the purpose to create the Hardware-in-the-
Loop-environment using a personal computer for the Real-Time-Simulation of the
process. The setup is a Host-Target-combination of two individual PCs communicating via
the serial Port (RS232) or Ethernet (TCP/IP). The Host is any desktop PC able to run
Matlab, the forms of the target are ranging from Desctop PCs to Single-Board
computers.[2]
The Target loads a Real-Time-Kernel enabling it to communicate with the Host and to run
the compiled C-Code representing the model downloaded from the Target-PC.
Finally the controller is to believe to communicate with the sensors of a real process. A
wide range of PCI-cards is available to support the engineers work to integrate the
protocol of the sensors communication interfaces on the Target PC.
As for the Human-machine-interface, Matlab currently lacks a flexible Realtime solution.

Visualisation can be realized through scopes on the screen of the Target-PC and some
parameters of the model can be updated in realtime through the Target-Host-connection.
There exist different hardware and software solutions to complete the Simulation
environment, for instances using LabVIEW [3].
124
hos targ
MT 9
RS232
télécommand
PWM
e
PPM
MIDG II
RS422
ATmega128
capteurs
I2C, etc.
PWM
7.1.3. Conception générale
Le cahier des charges demande un moyen de tester rapidement les nouveaux

programmes (sans modification) sans risque de casse. Il est donc indispensable de
garder le microcontrôleur (ATmega 128) « physique » et on peut remplacer tout le reste
du hardware par une simulation. Ceci est la démarche classique d'une simulation
« hardware in the loop ». Un logiciel souvent utilisé dans ce but est xPC Target, qui a
l'avantage additionnel d'appartenir à MATLAB/Simulink, un logiciel déjà utilisé par le
projet.
Il faut donc simuler toutes les interfaces et protocoles utilisés par le Quadricoptère et
créer un modèle qui simule son comportement.
Pour le comportement, le modèle Simulink utilisé pour tester les boucles d'automatique
est disponible, il a été refait pendant l'été par Erwan. Il faut l'adapter pour le xPC Target
(contraintes sur la puissance de calcul en temps réel, fixed-step, etc.).
Le Target PC doit interpréter les consignes pour les moteurs transmises via PWMs par
l’ATmega et envoyer les résultats de la simulation du comportement par le protocole de
la MIDG II via RS422, par le protocole du capteur ultrason via I2C et éventuellement par
des autres capteurs intégrés par les autres sous-groupes pendant l'année.
La radiocommande « physique » va être branchée sur l’ATmega pour avoir un meilleur
contrôle du vol. Il serait aussi possible de simuler l'interface et le protocole de la
télécommande pour pouvoir tester le modèle avec une suite prédéfinie de consignes.
Pour l'instant aucun autre groupe n’a exprimé ce besoin et on a donc décidé d’utiliser la
télécommande « physique ». L'autre fonctionnalité pourra être ajoutée plus tard, si
nécessaire.
Pour les interfaces il existait déjà une planche Simulink avec une ancienne simulation du
comportement, avec les PWMs comme entrée et le protocole de la MT9 via RS232 comme
sortie.
Comme la visualisation sur le Target PC est très limitée, on va envoyer les données
nécessaires à un autre PC (soit le host ou un troisième PC si il y a des problèmes de
puissance ou interférence) puis les traiter et les afficher. L'idéal serait d'obtenir un
simulateur de vol de qualité pour le Quadricoptère sur PC.
125
7.1.4. Les sous-tâches de notre groupe
Nous allons spécifier ici les différentes tâches ainsi qu’une estimation du temps consacré
et des problèmes rencontrés. Le temps est souvent reparti sur toute l’année. Pour les
solutions veuillez regarder aussi la partie « Réalisation », surtout pour des précisions
techniques.
7.1.4.1. Familiarisation avec l’environnement du projet
Temps consacré : important (~25 séances)

C’est une partie essentielle des projets deuxième année. Deux membres de notre groupe
étaient déjà sur le projet l’année dernière. Ainsi les objectifs du projet, les enjeux du
développement du Quadricoptère étaient connus. Pourtant, nous avons rencontré dès le
démarrage des difficultés lors de l’utilisation d’un STK500, consacrant alors beaucoup de
temps à la résolution de problèmes parfois élémentaires mais fondamentaux. Cela est à
rapprocher des problèmes auxquels nous avons été confrontés toute l’année quand nous
utilisions de ce kit de développement.
Nous avons réalisé que pour les groupes complètement nouveaux sur le projet, le
démarrage a été encore plus délicat. C’est naturellement dans l’intérêt du projet de
minimiser ce temps de compréhension en transmettant les connaissances de base assez
rapidement aux membres de l’équipe.
Cela peut se faire avec des élèves de première année qui passent déjà du temps dans le
labo, pas nécessairement seulement des TIMEs dans le cadre des projets de
remplacement. Bien sûr, il faut faire un peu la promotion du projet.
Une autre solution serait de faire une collection d’articles contenant les réponses aux
questions simples sur le Quadricoptère. On peut penser à : « Comment programmer un
Atmel ? », « Comment faire un essai en vol ? », « Quelles sont les Does & Don’ts ? »… Un
exemple est le document illustré « HIL for Dummies » qui figure en annexe. Le résultat
de cette collecte de renseignement et de savoir-faire est une sorte d’encyclopédie du
Quadricoptère.
L’organisation de la concrétisation de ces propositions est une tâche du management du
projet. Cela nécessite un peu plus de temps et d’énergie, mais apporterait des
améliorations durables pour le projet Quadricoptère voire les projets du Laboratoire.
7.1.4.2. Compréhension du concept HIL et Identification des problèmes
Temps consacré : peu (~ 3 séances)

Le concept de HIL a été compris assez rapidement au cours des premières séances. Il
fallait d’une part comprendre l’idée générale, et d’autre part analyser le problème pour le
Quadricoptère. Pour le concept général, on peut se reporter à la partie précédente,
notamment les schémas.
Dans la mesure où M. Martin avait déjà un certain nombre d’idées concrètes de
développement, et de solutions disponibles, nous avons consacré relativement peu de
temps à la recherche d’alternatives. De plus, les solutions Hardware disponibles n’étaient
pas très nombreuses. Par exemple il n’y a pas de cartes PCI pour le Target PC
permettant de communiquer directement par I²C.
7.1.4.3. Choix et modification du modèle
Temps consacré : moyen (~8 séances)

Le modèle pour la simulation pure sous Simulink avait été réalisé l’an passé. Il nous a
fallu un peu de temps de réflexion pour identifier les parties de la structure qu’il
convenait d’intégrer sur le Target PC.
De plus nous avons fait des essais pour réaliser la simulation pure (système
Quadri+Contrôleurs) en « fixed step » (comme sur le Target PC). Jusqu’à la fin nous
n’avons pas réussi puis abandonné avant de faire la simulation du système Quadricoptère
sur le Target PC, stabilisé par les contrôleurs extérieurs sur l’Atmel.
126
7.1.4.4. Intégration des interfaces
Temps consacré : beaucoup (> 60 séances)

C’était la majeure partie de notre travail cette année. Il a fallu comprendre les
protocoles, puis le codage des messages. Le main.c utilisé sur le quadri a aidé à faire les
premiers essais de communication. Pour bien comprendre, nous nous sommes bien sûr
appuyés sur les documentations des fournisseurs de Hardware.
La compréhension du protocole Midg2 et le codage des messages ont été relativement
faciles. Cependant le fait de mettre les paquets des messages dans l’ordre a posé
problème sous Simulink. Pour les PWM nous avons rencontré des problèmes de bruit que
nous n’avons pas encore résolus. Enfin, l’I²C a posé un certain nombre de problèmes au
niveau hardware (connexion) et software (conflit entre plusieurs protocoles/ plusieurs
interrupts). L’intégration de la télécommande à la fin de l’année a été relativement facile
grâce à l’aide du groupe transmission.
Pour des détails sur les problèmes rencontrés, voir la partie « Réalisation » ainsi que le
« Top-Ten-Bug-List » de notre groupe.
Il est intéressant de noter qu’en intégrant ces interfaces on a plus ou moins refait le
main.c du Quadricoptère, mais moins compliqué. Quelques parties du code (par exemple
le décodage des messages de la télécommande) n’ont pas fonctionné sur notre système
et représentent des erreurs potentielles. Une erreur Hardware peut être représentée par
l’absence des résistances de pull-up pour le bus I²C. A étudier pour le groupe
programmation et Electronique.
7.1.4.5. Les tests des systèmes
Temps consacré : beaucoup (> 40 séances)

Nous avons réalisé des essais en boucle fermée qui vont des essais simples (stabilisation
d’un système 1/(s-1) ) jusqu’à la stabilisation du système non-linéaire du Quadricoptère.
Nous avons successivement assemblé des systèmes plus complexes qui utilisent de plus
en plus d’interfaces décrites dans la partie amont.
Les problèmes rencontrés étaient souvent des problèmes de la partie interface, mais
également des erreurs de simulation sur le Target PC et des conflits avec les nouvelles
versions de Matlab.
7.1.4.6. La visualisation du vol
Temps consacré : beaucoup (>20 séances)

La seule interface homme-machine disponible avec le Target PC sont les Target-
Scopes. Pour comprendre ce qu’il fait, le pilote doit « voir » ce qu’il fait, comment évolue
l’objet qu’il contrôle. Le simulateur de vol FlightGear associé à MATLAB/Simulink permet
de réaliser cet affichage. Les problèmes étaient surtout les conflits de version ainsi que le
paramétrage de FlightGear qui est un peu différent de celui de notre Quadricoptère. Voir
la partie Réalisation.
127
7.2. Réalisation
7.2.1. Choix du modèle et du contrôleur
La qualité d’un système HIL dépend de la qualité du modèle utilisé pour simuler le
comportement du drone. Nous avons utilisé le modèle basé sur les équations du rapport
2003 et 2004. La réalisation peut être trouvée dans le fichier « simulation_x.mdl ».
Le fichier principal de « simulation_x.mdl ». A gauche les trois contrôleurs sur l’altitude,

vx-vy et le lacet. A droite le système quadrotor et les boîtes qui simule la MIDG2 et les
ultrasons.
Ce modèle a une approche « directe » du problème : les équations d’états sont basées
sur les équations dynamiques du système à un corps rigide et non sur les estimations à
partir des mesures. Les entrées sont les PWM consignes pour les moteurs, les sorties
toutes les paramètres de vol. La commande s’effectue en Psi, Vx, Vy et Z. Voir le rapport
2003 et 2004 pour des détails sur le découplage.
Les contrôleurs ont été obtenus à partir du système linéarisé en utilisant SISOtool. Ce
sont des cascades de contrôleurs Proportionnel et Dérivée. Pour les réaliser sur l’ATmega,
une discrétisation est nécessaire. Les commandes Matlab nécessaires et les résultats
pour l’ATmega peuvent être trouvés en Annexe.
Remarque : Il est utile de s’interroger sur l’éventuelle utilisation de contrôleurs PI pour
éliminer l’erreur finale. Cela a bien fonctionné avec nos systèmes simples qui utilisaient
déjà toutes les interfaces : on a tenu compte des effets du bruit.
Un modèle ne peut décrire le vrai système qu’à quelques approximations et hypothèses
près. Par exemple on peut se demander s’il est bien justifié de prendre les hypothèses
concernant la poussée et la trainée pour une meilleure performance du système. En effet
le Quadricoptère n’a pas toujours inclinaison faible.
128
La structure interne de la boîte Quadricoptère.

C’est exactement la structure qu’on a également utilisé sur le système Target. Voir la
partie des tests des systèmes pour les différentes connexions.
L’interieur de la boîte 4dri.

C’est la couche fondamentale. Dans les boîtes « f(u) » on trouve les équations d’états
dérivées des lois fondamentale de la dynamique.
129
7.2.2. Intégrations des interfaces
7.2.2.1. Moteurs – PWM (CTR05)
http://fr.wikipedia.org/wiki/PWM
On a déjà une carte PCI compatible avec xPC Target pour la capture des PWMs. Il s'agit
de la carte CTR05 de Measurement Computing. Selon ses spécifications la carte est bien
adaptée à nos besoins. Elle contient 5 compteurs qui permettent de mesurer la période
et le temps passé en « 1 » du signal PWM. Le rapport de ces deux valeurs donne un
pourcentage qui correspond à la valeur transmise. On a donc besoin de 2 compteurs par
signal PWM. Cependant comme l'ATmega envoie tous les signaux avec la même période,
un seul compteur dédié à la mesure de la période de n'importe quel signal peut être
utilisé pour tous les autres signaux. Un bloc ne donnant que le temps passé à 1 n'est pas
inclus dans xPC Target mais a été créé par M. Martin.
L'ATmega envoie les PWMs à 30 kHz, on doit donc utiliser la « frequency base »
maximale de 5 Mhz pour disposer d’un nombre correct des niveaux distinguables.
Malheureusement les compteurs donnent souvent 0 et on a ainsi x/0 ou 0/0 qui donnent
respectivement « inf » ou « -nan ». Ces deux valeurs plantent la simulation du
Quadricoptère. On a donc saturé (subsystem « U anti-nan ») le signal entre 0 et 1, le
block « saturation » de Simulink ne marche pas pour les « -nan » et en conséquence on
utilise des « switch ».
Un passe-bas ou un autre filtre devrait améliorer les résultats.
Pour des premiers essais on a utilisé un générateur de signaux. Il faut respecter les
voltages maximaux. L’ATmega utilise les même plages de tensions que le CTR05 ce qui
permet un branchement direct (selon « Connexion Atmega.doc »).
La simulation du Quadricoptère et le programme en C utilisent des valeurs entre 0 et 255
au lieu des valeurs entre 0 et 1. Cela nécessite une simple multiplication.
En comparant la mesure à celle obtenue avec l'ATmega « 0 » et « 1 » sont échangés et
on doit donc prendre « 1-pwm_mesuré » pour avoir les mêmes valeurs.
« Sample time » impose au Target PC une fréquence de lecture des valeurs de la carte
CTR05. Les valeurs ne semblent pas être moyennées, même si le CTR05 a pris plusieurs
valeurs entre les requetés du target.
Le programme C utilise des compteurs dédiés aux PWMs et donne des noms aux
registres pour un accès plus facile.
Fichiers:
testCTR05ATmega.mdl avec main.c dans PWM
Quadri HIL Jens KOBER 24.06.05.doc
7.2.2.2. MIDG II – RS422 (port série onboard)
http://en.wikipedia.org/wiki/Rs422
http://stielec.ac-aix-marseille.fr/cours/abati/rs232.htm
La MIDG II envoie les données via le bus RS422. Il existe un adaptateur pour convertir
ce signal en RS232 afin de le brancher sur le port série d'un PC. De plus sur la carte du
Quadricoptère un tel convertisseur est implémenté et l'ATmega ne traite en fait pas du
RS422 mais du RS232. xPC Target permet d'utiliser des ports séries et notre Target PC
possède un port série RS232 intégré. Si on branche notre simulation sur un kit, il est
donc inutile de convertir le signal en RS422 puis en RS232, mais on peut brancher les
deux ports série RS232 directement.
On avait une simulation de la MT 9 comme exemple. Depuis sa réalisation les blocs de
RS232 de xPC Target ont évolué et il n’est plus nécessaire d'utiliser Stateflow pour le
décodage du message.
Les messages sont décrits dans 2Message1b.pdf. Le logiciel « MIDG II Display » permet
d’afficher les données sur un PC et de configurer la MIDG II. Le Quadricoptère n'utilise
pas tous les messages de la MIDG II, elle est configurée pour n’envoyer que les
messages utiles. Les messages 10 et 12 sont utilisés, le message 2 (alternative non-
filtrée du message 10) est aussi implémenté dans le main.c . On ne veut envoyer que les
130
messages 10 et 12 donc il est inutile de simuler les autres messages. En suivant

l'exemple des messages déjà implémentés on peut très facilement et rapidement
implémenter des autres messages. Pour avoir une compatibilité maximale avec le main.c
on a aussi implémenté le message 2.
Pour le Quadricoptère la MIDG II est configurée pour envoyer les messages 10 et 12
toutes les 20ms à un baud rate de 57600.
RS232
Notre mode de transmission correspond à FIFO et on utilise donc le bloc « Baseboard
Serial F ». On doit le configurer au baud rate adapté et « Com1/none ». A priori on met à
l'entrée du block Simulink un vecteur des nombres qui vont être envoyés. Les détails
sont configurés avec « Transmit FIFO data type ». Il faut respecter le type des données
et il faut donc mettre un « Data Type Conversion » avant en cas d’incohérence. Les noms
de « Transmit FIFO data type » sont décevants, si on utilise un port série physique ce
sont toujours 8 bit (lowbyte) qui sont envoyés par composante du vecteur. Par contre si
on utilise FIFO sur une simulation Simulink pure tous les 16/32 bits sont transmis. Par
conséquent il faut découper chaque message en parties de 8 bit. Le bloc doit savoir
quand il doit envoyer le message. Avec « null terminated » le message va être tronqué
après la première composante du vecteur valant « 0 » : le reste du vecteur ne va pas
être transmis. Les formats disponibles sur 8bit sont tous « null terminated ». Dans la
mesure où certaines valeurs envoyées par la MIDG II peuvent être nulles, on ne peut pas
utiliser ce mode de transmission. Avec « count + ... » on donne d'abord la longueur du
vecteur à envoyer (comme première composante du vecteur, elle-même ne comptant
pas). Cet octet ne va pas être transmis.
Le message est donc découpé en morceaux de 8 bit qui constituent le vecteur qui va être
envoyé. Comme on veut utiliser un format « count + ... » il faut convertir toutes les
composantes du vecteur en 16 bit avant l’envoi (par exemple : 0xAB12 Î [0xAB,0x12]
Î [0x00AB,0x0012] Î envoi)
« FIFO bin read » permet de décoder et séparer un ou plusieurs messages avec des
entêtes facilement.
Le message complet est écrit dans le buffer du port série tous les « Fixed-step size
(fundamental sample time) » et ensuite envoyé avec le baud rate choisi. L’envoi s’arrête
si le buffer est vide et recommence s’il y a des nouvelles données. Si on écrit plus de
données par unité de temps dans le buffer que ce qui peut être envoyé à ce baud rate,
on obtient un « buffer overflow » une fois le buffer complètement rempli. Il faut donc soit
augmenter le baud rate, soit écrire le message moins souvent dans le buffer. On peut
soit augmenter le « Fixed-step size » (souvent impossible à cause du reste du modèle),
soit mettre un « Zero-Order Hold » à cette fin devant l’entrée du block RS232. Le « Zero-
Order Hold » fixe la période d’écriture dans le buffer et en conséquence aussi la période
d’envoi des messages via le port série.
On a commencé nos essais avec rs232.mdl et un loopback plug.

Fichiers : xpcserialbinarytest.mdl, rs232.mdl
La carte Quatech QSC100 (block « QSC-100 F ») a un comportement identique. Il y a un
câble spécial qui converti le port de la carte (ressemblant à un port parallèle) en quatre
port séries (qui peuvent être configurés individuellement en choisissant « Port to
modify »). Malheureusement le « build » est extrêmement lent.
Fichiers : QSC100.mdl
MIDG II
Le but est d’assembler toutes les valeurs simulées de la même manière que la MIDG II
« physique ». Les détails se trouvent dans 2Message1b.pdf . Il faut aussi ajouter les
entêtes et les checksums. Comme quelques paramètres utilisent des formats plus grands
que 8 bit, l'ordre des octets est important. Le protocole de la MIDG II prend des big-
endians, Simulink des little-endians.
Le block « byte reversal » inverse l'ordre des octets (mais pas celle des bits!).
131
« Pack » permet de découper ces entrées en un vecteur avec des composants de 8 bit
(par exemple 16 bit deviennent deux fois 8 bit, le high-byte et low-byte). « Unpack » fait
l'inverse.
Les « Mux » permettent de combiner des vecteurs. Le checksum0 est réalisé par une
sommation simple, checksum1 par une multiplication matricielle. Le protocole de calcul
des checksums ne conserve que 8 bits et tronque tous les bits supérieurs après chaque
sommation. Comme on fait des calculs sur 8 bit MATLAB fait la même chose
automatiquement.
On a pris l'exemple de la MT9 pour créer un décodage des messages. Ensuite on a
branché la MIDG II « physique » sur le Target PC et vérifié qu'on arrive à décoder les
messages et on a comparé ces valeurs avec les valeurs données par « MIDG II Display ».
On a analysé les messages envoyés par notre simulation en regardant les octets envoyés
bruts avec MATLAB. Ensuite on a vérifié que notre simulation des messages est
correctement décodée par le décodage testé avant. Puis on a branché notre simulation
sur un PC et vérifier avec « MIDG II Display » que nos messages sont corrects. On a
modifié la partie MIDG II du main.c pour allumer des LEDs du kit si la routine arrive à
décoder nos messages et si les valeurs (recombinés des 8 bits) correspondent à celles
qu’on à mis comme entrée à notre simulation.
Fichiers : midg2neu2rs232_42.mdl et main.c dans le dossier MidgII.
7.2.2.3. Télécommande – PPM (récepteur)
On a profité du travail du groupe transmission. Ils nous ont montré les branchements et
nous ont donné le code C nécessaire.
ppm_pulses est en « int » et stocke les valeurs directement reçus via PPM. Les décalages
(pour centrer les valeurs et avoir aussi des valeurs négatives) dans le code n'étaient pas
assez précis pour nos besoins, car le système est instable si on ne commence pas avec
des références proches de zéro. On a donc affiché les valeurs reçues via les LEDs de deux
kits pour les combinaisons extrêmes de chaque réglage et manette. Les résultats se
trouvent en annexe. Il reste à vérifier si des typecast manquants posent aussi des
problèmes pour le Quadricoptère « physique ». cf. 060525.txt
Des divisions transforment les ranges reçues en ranges correspondants en unités
physiques.
La télécommande est utilisée pour donner des consignes en psi', le Quadricoptère est
commandé en psi. On a donc implémenté une intégration numérique (zero-order-hold).
Fichiers:
decodage.c dans session0523/telecom
CRT05_xPC_AVR_horiz_midg2x4_nonlin2c avec main.c dans session0523/v29
7.2.2.4. I²C
Le but était de remplacer les capteurs ultrasons « SRF10 », qui sont en boucle fermé
pour l’altitude z, par le Target PC. Sur le vrai Quadricoptère, ils communiquent via I²C
avec l’ATmega128 :
132
Schéma de la Tâche Communication I²C
Le SRF envoie l’information sur l’altitude en deux parties au Master : le Lowbyte et le

Highbyte.
L’altitude est bien une sortie de la boîte quadri, mais il n’existe pas de cartes PCI qui
permettent une liaison directe via I²C avec l’ATmega. Il fallait passer par l’intermédiaire
d’un autre contrôleur qui reçoit la valeur de l’altitude par RS232 et le transmet via I²C à
l’ATmega128. Comme intermédiaire on a choisi un ATmega16 sur un deuxième kit de
développement STK500. Dans l’avenir ce système Mega16-STK500 peut aussi être
remplacé par un petit module pour la communication i2c, parce qu’on ne change plus
grand chose dans le Mega16 pendant les testes avec le Target system.
Pour détails sur la liaison série (RS232), qui est fait avec la carte Quatech, voir la parti
précédente les liaisons RS232.
Le protocole I2C :
I²C est un protocole série développé par Philipps, qui n’utilise que deux fils (SDA, SCL)
sur lesquels on peut brancher jusqu’à 128 interlocuteurs. La communication est basée
sur des interruptions, c’est-à-dire que les objets peuvent faire d’autres calculs à coté.
Dans les AVR de Atmel, I²C est, pour des raisons de marques, appelé TWI (Two-wire-
serial-interface).
Principes de fonctionnement (voir les docs sur l’ATmega pour plus de détails) :
Sur le Port, il y des Master est des Slaves. Dans notre cas on a un Master (l’ATmega128)
et un Slave (le Mega16, qui remplace le SRF10). Tous les participants « écoutent » si
quelque chose se passe sur le port, c’est-à-dire les deux files. Il y a une quinzaine de
types de messages différents, qui on tous la même structure (une suite de 1 et 0).
Le Master peut commencer tout seul à faire quelque-chose, le Slave seulement réagir, si
on lui demande. (Notons qu’il y a une exception : le Slave peut « bloquer » le Port s’il est
occupé dans le mode d’interruption-TWI). Le message qui est arrivé détermine le
comportement après le interrupt, par exemple la préparation d’un nouveau message
avec des « mesures ».
La Tâche :
Il fallait simuler complètement le comportement des Ultrasons, c’est-à-dire avec les
délais éventuels.
133
Le datasheet des SRF10 affirme, que pendant le ranging, le vrai SFR10 « découpe » le
SDA. (On lit toujours 0xFF=5V par le pull-up).
La durée de découpage T est variable :
T = 2d/Vson si 2d < Dmax ...
Tmax si 2d > Dmax ...
Avec :
Vson... vitesse du son
Tmax... temps de mesure maximale (=64µs ~ d=11,6m)
Dmax... Distance maximale où l’écho est encore reconnaissable, déterminé par le Gain,
normalement fixe pendant la simulation Æ ici on a pris 300 cm
Après chaque message sur le bus I²C, l’expéditeur (dans les pluparts le Master) attend
une réponse, un ACK (acknowledge). En termes imagés, c’est un bit qui dit « Oui, je suis
là » ou « Merci, j’ai bien reçu le dernier message ».
On peut réaliser cela avec le TWEA-flag, ce qui est probablement aussi fait en vrai. Cela
signifie qu’on envoie toujours un NACK (no-acknowledge) pendant le « ranging ». La
durée est calculée et est prise pour lancer un Timer, qui permet de reprendre les ACK
après cette durée.
Alimentation :
Le premier problème était l’alimentation. Avec toutes les informations des datasheets et
des forums d’Internet il semble nécessaire de mettre des pull-ups externes. Au moins, ça
n’a pas d’influence négative sur la communication. Pour la simulation externe avec xPC-
Target, l’utilisation des Pull-ups et incontournable.
Voilà le schéma d’alimentation pour la communication I²C :
Alimentation électrique pour la communication I²C : en haut le Master avec les

contrôleurs du Quadricoptère, en bas le Slave. C’est important d’avoir un common
Ground (GND) qui doit être établi avant l’alimentation externe. (C’est-à-dire mettre le
câble avant Power-On)
134
Sur le Slave le Port série UART0 est connecté avec le Target PC. Sur le Master sont aussi
alimenté les câbles pour les autres parties de la communication (PWM, RS232)
Programmation :
En annexe on trouve le fichier Simulink (xPC-Target) avec la carte Quatech pour envoyer
les données d’altitude via RS232, ainsi que les lignes de code essentiel pour la
communication I²C entre les deux AVR.
Rappelons ici seulement la structure du transfert des données :

• Simulation de Z sur le Target
• Conversion de double en unsigned-int16-bit, découpage en paquets 8 bit
• Envoi via la carte Quatech sur le port série (115'200 bit/s baud rate)
• Réception sur le Mega16, retransformation en un variable 16 bit
• Recommence avec 1
En parallèle :
• Comparaison de l’altitude à 300 cm, mise à l’infini si plus grand
calcul de « TimeToCount » pour le Timer (entre 3ms et 64 ms selon l’altitude)
• Après la réception du commande de range « 0x51 » envoyé par le Master
démarrage du Timer, TWEA = 0 pour envoyer des NACK.
• Le Master continue à essayer de lire les données de l’altitude, mais le slave
répond seulement NACK.
• Le Timer a fini et permet des TWEA=1. Le Slave envoie les données après le
prochain essai du Master.
• Recommence avec 6
La programmation était accompagnée par de nombreux problèmes Hardware et

Software. La documentation de ATmega inclut des commandes pour des cas beaucoup
plus complexes que le notre. La compréhension de l’ordre des activités sur le Bus I²C
n’est pas évidente.
Normalement ce n’est pas nécessaire, seulement pour comprendre les détails d’un
problème comme le suivant :
Le Grand bug :
C’était le plus grand bug qu’on ait eu avec l’I²C. Il arrêtait la communication, lorsqu’on
voulait envoyer une valeur dans le Lowbyte, qui était égale à la commande 0x51.
Le problème était qu’il n’y avait qu’une seule variable ( TWI_buf[1] ) pour la réception et
l’envoi qui n’était pas mise à zéro après l’envoi. Le interrupt a pensé qu’il devait
recommencer à faire le ranging et a activé le Timer, tandis que le Master voulait toujours
lire le lowbyte sur le Bus I²C.
La raison pour laquelle la communication s’est complètement arrêtée n’est pas claire
(probablement le slave met un zéro sur le Port).
Avec la mise à zéro de cette variable, le problème n’existait plus.
7.2.3. Les tests des systèmes
Il y avait trois grandes étapes pour l’intégration des systèmes à stabiliser dans notre
système HIL (et beaucoup d’étapes intermédiaires).
La première stabilisation d’un système simple 1/(s-1) avec un P/ PI
La stabilisation du système Quadricoptère linéarisé
La stabilisation du système Quadricoptère non linéaire
Pourquoi stabiliser ?
On sait, que la stabilisation du drone est à priori possible, comme l’ont montré les
expériences et aussi la « simulation_x.mdl » qui a pris en compte les imperfections des
liaisons. C’est donc un test pour la simulation. Un bon système HIL donne sensiblement
135
le même résultat que « simulation_x ». De plus un mauvais système n’a aucune chance
d’être stabilisé
Tous les systèmes ont été stabilisés avec nos propres contrôleurs.
La quatrième étape, la stabilisation du système non-linéaire par le main.c actuellement

utilisé dans le Quadricoptère n’est pas encore réalisée. Le main.c est différent du notre
notamment à cause du découplage réalisé sur le drone, des différences d’unité et de
l’existence de variables supplémentaires (superflues ?).
La « cinquième » étape, la visualisation du vol virtuel a déjà été développée mais pas
encore intégrée. Voir le chapitre correspondant.
7.2.3.1. Système simple
Ce système était la première vérification d’une stabilisation en boucle fermée. On envoie

des données par RS232, applique un P ou PI et renvoie la commande par les PWM :
Planche Simulink de « CRT05_5_xPC_AVR_3.mdl » : à gauche la carte PWM, à droite le

système.
Dans la boîte pour envoyer les données sur le Port série, il y a une conversion de double
en 8 bits. Il y a aussi un zéro-order hold de 20ms qui a comme effet l’envoi des données
est effectué toutes les 20 ms (comme dans la MIDG II). Ca sert aussi pour synchroniser
l’intégrateur dans le cas du PI.
Partie essentielle du code sur le ATmega (version « PWM7 ». C’est la transformé Z du

contrôleur 5*(1+ 1/s) qui peut être trouvé dans pwmrs232_ja3_stab_simulink.mdl
SIGNAL( SIG_UART0_RECV )
{ IncomingData = UDR0;
e = (float) IncomingData;
//difference par rapport au reference
e = 60 - e;
//PI controller
u = u_old + 5.032*e - 4.968*e_old;
//sortie
m2 = (255-((u/10)+50));
if (m2>255) m2 = 255;
if (m2<0) m2 = 0;
moteur2 = (uint8_t) m2;
136
//anciens valeurs
e_old=e;
u_old=u;
}
Résultat de l’application d’un PI sur notre système et comparaison avec la

simulation.
137
7.2.3.2. Le système Quadricoptère linéarisé
On prend le système linéarisé qui était utilisé pour concevoir les contrôleurs dans
« simulation_x.mdl » Comme ça on obtient la plus grande robustesse possible.
Le système sur le Target PC est le suivant :
planche simulink CRT05_xPC_AVR_horiz_midg2x4_us.mdl
A gauche on voit les 4 entrées PWM, après le décodage on voit 4 bloc qui correspondent
aux 4 systèmes SISO indépendants, crées dans les fichiers *.m pour les contrôleurs qui
peuvent être trouvés en annexe.
Le bloc de décodage opère un ajustement parce que les PWM n’ont qu’un range de
[0...255]. On a fait une transformation simple avec une addition et une multiplication
pour atteindre un range de valeurs plus grand avec des valeurs négatives.
sysp,sysq et sysr sont en boucle fermée via le protocole de MIDG II par le Port RS232.
sysaz est connecté via le Port série supplémentaire de la carte Quatech à l’ATmega16. On
a mis une saturation pour éviter toute valeur négative.
Les consignes sont envoyées de manière indirecte par des variables de MIDG II non-
utilisées. (C’était avant l’intégration de la télécommande). Un rate limiter doit éviter des
changements brutaux.
138
Partie essentielle du code sur le ATmega (version « v21 ».
u = ref - vy;
//P controller (vy)
u = 23*u;
//difference par rapport au phi
u= u - phi;
//P controller (phi)
u = 7*u;
//difference par rapport au p
e = u - p;
//controller (p)
u = .1353*u_old + .01146*e -
0.00886*e_old;
u = ref2 - vx;
//P controller (vx)
u = -23*u;
//difference par rapport au theta
u= u - theta;
//P controller (theta)
u = 7*u;
//difference par rapport au q
e = u - q;
//controller (q)
u = .1353*u_old2 + .01146*e -
0.00886*e_old2;
u = ref3 - z;
//P controller (z)
u = 2*u;
//difference par rapport au vz
u= u - vz;
//P controller (vz)
u = 20*u;
//difference par rapport au az
u= u - az;
//P controller (az)
u = -.28*u;
u = ref4 - psi;
//P controller (psi)
u = 2.62*u;
u= u - r;
//P controller (r)
u = 0.0372337*u;
C’est le codage des quatre contrôleurs que l’on trouve dans « simulation_x »
Une fois que les interfaces de la partie précédente ont été intégrées sur le Target et
l’AVR, on a pu établir la stabilisation assez facilement. Le problème était plutôt d’avoir
oublié d’ajuster un paramètre ou d’avoir connecté les blocs en Simulink d’une façon
incorrecte.
Pour debugger on a successivement réalisé les quatre systèmes, l’un après l’autre.
139
7.2.3.3. Le système Quadricoptère non linéaire
C’est le système final qui permet de simuler le comportement du Quadricoptère sous

l’action d’un contrôleur. En théorie il suffisait de changer les blocs linéarisés du système
précédent (sysq, sysp, sysr, sysaz) par les blocs non-linéaires utilisés dans la planche
« simulation_x » (voir chapitre sur le choix de modèle)
La version CRT05_xPC_AVR_horiz_midg2x4_nonlin_us.mdl
Trois variables sont envoyées via le protocole MIDG II, 1 via la carte Quatech au Mega16
qui le renvoie via I²C à l’ATMega128.
Il y a deux blocs MIDG II. Le bloc à droite est celui du système précédent, qui réalise le
protocole.
Le bloc MIDG II au milieu réalise la conversion des unités. Dans ce bloc il fallait enlever
aussi les « transport delays » pour atteindre une stabilisation. On a placé des délais de
transport dans « simulation_x.mdl » pour simuler le retard éventuel dû aux calculs dans
la vraie MIDG II.
Les contrôleurs sont les mêmes. En pratique il faut pourtant ajouter quelques paramètres
dans le main.c. On a ajouté G=1000 à la variable z.
L’ensemble obtenu est proche de l’objectif principal du groupe HIL Quelles sont les
différences par rapport au vrai main.c, la quatrième étape ?
• La transformation des variables vx et vy le dans repère « bis » du quadri et
toujours effectuée sur le Target. Normalement la MIDG II transmet les vitesses du
repère terrestre.
• La constante « Eqaz » qui fixe le point d’équilibre et toujours ajoutée dans le
Target.
• Les Wi reçus via PWM ne sont pas les vraies consignes des moteurs. Le
découplage est toujours effectué sur le Target PC et pas dans le contrôleur
• L’ordre des PWM peut être différent de celui dans notre version
• Le main.c (~main500_2.c) sur le quadri n’est pas programmé de manière très
claire. Il y a beaucoup de variables supplémentaires, peut-être superflues. A
priori, après corrections des quatre différences ci-dessus on devrait être capable
de stabiliser le système non-linéaire avec le main500_2.c
A part cela le système correspond bien au système Quadricoptère du point de vue du
contrôleur. Voila trois versions avec des communications différentes qui utilisent le
140
système non linéaire et sont stables. Les « V_i » sont des classeurs qui comprennent les
main.c à mettre sur l’ATmega.
Le résultat de « v29 » avec CRT05 xPC AVR horiz midg2x4 nonlin2c.mdl
Ici, on peut modifier les consignes avec la télécommande, z, vx, vz de manière directe,
Psi indirectement car la télécommande donne la consigne dPSI/dt. Sur l’image on voit un
programme de vol pour (de gauche en haut à droite en bas) : Psi, Z, Vx, Vy
« v23 » avec CRT05_xPC_AVR_horiz_midg2x4_nonlin2c.mdl

Æ les 4 variables sont envoyées via le protocole MIDG II, les consignes sont fixées dans
le programme
« v24 » avec CRT05_xPC_AVR_horiz_midg2x4_nonlin_us.mdl

Æ 3 variables sont envoyées via le protocole MIDG II, 1 via le Mega16 et I²C (voir le
chapitre correspondant pour l’alimentation)
« v29 » avec CRT05_xPC_AVR_horiz_midg2x4_nonlin2c.mdl

Æ C’est comme « v23 » mais les consignes sont variables et envoyées avec la
Télécommande (voir le chapitre correspondant pour l’alimentation)
Une source d’erreurs était la connexion des angles entre les blocs Quadricoptère et
MIDG : On a [phi, thêta, psi] correspond à [y(aw), p(itch), r(oll)]
Une autre source d’erreurs était la « connexion » dans le code de l’ATmega, c’est-à-dire
l’utilisation des variables correctes.
7.2.4. Visualisation du vol : FlightGear
http://www.flightgear.org/
Cette partie rappelle la démarche suivie par le groupe HIL dans le but de visualiser
l’évolution du Quadricoptère simulé ainsi que les étapes suffisantes à la mise en œuvre
de la communication MATLAB – FlightGear.
141
La lecture de l’aide MATLAB / Aerospace Blockset est recommandée :

Using the Aerospace Blockset / Working with the Flight Simulator Interface
Blocks / FlightGear Preconfigured 6DoF Animation
Blocks / Pilot Joystick
7.2.4.1. Présentation de FlightGear
Le projet FlightGear Flight Simulator (FG) est un projet

Open-Source (libre) multiplateforme, coopératif de
développement d'un simulateur de vol. Il est défini comme
« un cadre sophistiqué, mais ouvert de simulation pouvant
être étendu, amélioré par toutes les personnes
intéressées ».
Un exemple de cette ouverture est la possibilité de ne pas
utiliser le modèle dynamique des aéronefs de FG mais de
fournir directement ses coordonnées et attitude au module
d’affichage.
7.2.4.2. FlightGear et le Quadricoptère
Justification
Même si les « Scopes » fournis par xPC Target nous ont permis de contrôler la stabilité
de nos modèles, l’efficacité des contrôleurs... ils ne rendent pas vraiment possible une
représentation mentale de l’évolution du drone simulé. C’est pour cela que FG nous est
utile. Il pourra permettre de détecter des anomalies du modèle, d’identifier les
« consignes à risque »… La représentation graphique est en résumé le dernier élément de
la démarche HIL rappelée ci-après.
Démarche
Installation des logiciels nécessaires
Vérification au moyen d’une démonstration MATLAB
Intégration du module d’envoi de données vers FG à un modèle simple
Simulink - FlighGear
Définition de consignes à partir d’une manette de jeu
Pilotage du modèle Simulink du Quadricoptère avec la manette (affichage Scope)
Réalisation des interfaces : Manette // Modèle // FlightGear
Pilotage de l’aéronef FlightGear avec la manette de jeu
Pilotage du Quadricoptère réel avec la manette de jeu ?
xPC Target - FlightGear
Définition de consignes à partir de la radiocommande (ppm_pulses)
Pilotage du Quadricoptère du Target PC avec la radiocommande (affichage xPC Scope)
Réalisation de l’interface Target PC // PC avec FlightGear (via RS232)
Pilotage de l’aéronef FlightGear avec la radiocommande
7.2.4.3. Interfacer FlightGear et MATLAB
Versions des logiciels

MATLAB R2006a (7.2.0.232) & Aerospace Blockset v2.1. FlightGear Simulator Interface
(de la version 2 .1) supporte la version 0.9.9 de FlightGear mais pas la dernière version
disponible (v0.9.10).
FlightGear v0.9.9 (17 novembre 2005) téléchargeable à partir de
http://flightgear.en.softonic.com/ie/47000 http://www.indirmax.com/indir.asp?id=3528
Installation de FlightGear v0.9.9 – Choix du dossier d’installation
142
Avec FG installé dans C:\Program Files\FlightGear, il est plus délicat de le lancer à partir
d’un script MS-DOS. Son installation dans un dossier à adresse courte et sans caractère
spécial, par exemple C:\FlightGear, simplifiera son initialisation par fichier .bat.
Exécution de la démonstration NASA HL-20

(Aide : Running the NASA HL-20 Demo with FlightGear)
Ajouter le modèle d’aéronef HL20 à FlightGear :

Copier le dossier : matlabroot\toolbox\aeroblks\aerodemos\HL20 dans
C:\FlightGear\data\Aircraft
Par curiosité on peut ouvrir le fichier HL20-set.xml avec le bloc-notes et remarquer la
présence de <flight-model>network</flight-model>. Cela dispense FG du calcul du vol
du modèle. Il sera donc possible d’utiliser avec MATLAB des modèles présents dans le
package FG, en remplaçant le paramètre encadré par ces balises : (JSBSim, YASim,
UIUC ; cf http://www.flightgear.org/features.html - Flight Dynamics Models) par
network.
Ouvrir la démo en entrant asbhl20 dans le prompt MATLAB ou en la trouvant dans

l’explorateur de de démonstrations
Ouvrir le sous-système toFlightGear, puis « Pack net_fdm Packet for FlightGear » et

changer la version de FlightGear (v0.9.9). Remarquer la présence d’un « sample time »
qui aura son importance lors de l’association de ce bloc au modèle Simulink du
Quadricoptère. Même remarque pour les blocs « Send net_fdm Packet for FlightGear » et
« Simulation Pace ».
Ouvrir le bloc « Generate Run Script » et mettre à jour le dossier de base de FlightGear
(C:\FlightGear) Les différents paramètres placent le modèle HL20 en dans l’axe (Offset
Azimuth = 0°) de la piste 10L (Runway ID ; cap 100, piste de gauche) de l’aéroport
KSFO à une altitude, cap et distance fixés respectivement à 7224ft, 113° et 4.72miles.
Nous verrons par la suite comment simplifier le fichier runfg.bat généré.
143
C:
cd C:\FlightGear
SET FG_ROOT=C:\FlightGear\\data.\\bin\\win32\\fgfs --aircraft=HL20 --
fdm=network,localhost,5501,5502,5503 --fog-fastest --disable-clouds --
start-date-lat=2004:06:01:09:00:00 --disable-sound --in-air --enable-freeze
--airport-id=KSFO --runway=10L --altitude=7224 --heading=113 --offset-
distance=4.72 --offset-azimuth=0
Dans le prompt MATLAB, entrer dos('runfg

&') ou, comme indiqué dans l’aide
« Starting FlightGear » , créer un
Raccourci, ou encore créer un raccourci
Windows vers matlabroot\work\runfg.bat.
Laisser le temps à FG de se charger
complètement.
Lorsque l’affichage n’évolue plus, on

devine qu’on se trouve à bord de l’avion, à
l’emplacement défini dans le script. En
appuyant sur la touche v du clavier, on
change de vue. « Chase view » et
« Helicopter view » sont assez
confortables. En appuyant sur la touche h,
on fait apparaître le Head-Up Display
(HUD), Viseur Tête haute. Le HUD est utile
pour le contrôle numérique des paramètres
transmis à FG.
Ce n’est qu’une fois FG initialisé qu’il faut

démarrer la simulation
ÆEchec !
Corriger les Signal Data Types des Source Block : num_engines, num_tanks,
num_wheels en uint32 au lieu de int32.
144
Lorsqu’on démarre la simulation, une nouvelle erreur de Data Type intervient : elle
concerne le bloc unixtime_sec. On applique la même correction (Output data type mode
int32 devient uint32)
Lorsqu’on démarre la simulation une erreur concernant le aramètre wow apparaît… Celui-
ci, issu du Bus (PlantData.LGData.WOW) est une variable booléenne liée à la sortie du
train d’atterrissage… Il est acceptable de ne pas en tenir compte et de déconnecter
l’entrée wow du bloc d’envoi.
Démarrer la simulation… Le HL-20 va atterrir ! (Une version de la démonstration corrigée

pour la version 0.9.9 de FlightGear est : asbhl20_adaptation_v099.mdl à placer dans le
dossier matlabroot\toolbox\aeroblks\aerodemos)
145
Intégration du module d’envoi de données vers FG à un modèle simple
Le modèle
UsingPreconfiguredBlock_v4.mdl
permet d’initialiser FG. L’aéronef
est en approche de la piste 10L
comme défini dans le bloc qui
génère le script. En démarrant la
simulation, on peut lui imposer
translations et rotations.
On pourra par la suite utiliser la
librairie
UsingPreconfiguredBlock_v5_library.mdl
construite à partir de ce modèle pour
envoyer à FlightGear position relative à
l’origine de la piste et attitude. Cette version
5 attend en entrée des angles exprimés en
degrés pour faciliter l’interprétation.
Pour réaliser ce modèle d’envoi à FlightGear
réduit au strict nécessaire, on a isolé les
éléments essentiels de la démonstration
fournie par MATLAB :
146
Le bloc « FlightGear Preconfigured 6DoF Animation »

Il réalise le lien entre MATLAB et
FG. Ce bloc transmet à FG les
informations de position et
d’attitude de l’aéronef à partir
de la longitude, la latitude, et
des angles de roulis, tangage et
lacet.
On remarque que l’adresse IP

de destination 127.0.0.1 est
celle de la machine mais qu’on
pourrait aussi bien envoyer ces
informations à une machine
dédiée au seul affichage. Cela
serait utile pour obtenir par
exemple un affichage en plein
écran pour une simulation
complexe, gourmande en
ressource systèmes.
Le bloc « Flat Earth to LLA »

Présent dans la démonstration asbhl20 dans « HL-20 Vehicle Systems
Model/Vehicle/Xe2LLA », il permet la conversion des coordonnées du type
« Flat-earth 6-DoF » (Xe = (x, y, z)) en Longitude, Latitude, et Altitude
("Mercator Earth").
On rappelle que le modèle FlatEarth est celui

utilisé pour positionner le Quadricoptère : la
Terre est plate autour d’une origine.
Cette dernière doit être identifiée par ses
coordonnées géodésiques : latitude et
longitude ainsi que la hauteur géodésique
(href ~altitude du sol).
Dans la démonstration, elle est naturellement
prise au niveau de l’aéroport. Afin d’utiliser ce
bloc dans un modèle différent tout en faisant
évoluer l’aéronef dans la même zone, on
récupère les valeurs des paramètres LongLat0
et heading0 :
LongLat0 = -122.3896 37.6272
heading0 = 117.
Ainsi dans la démonstration X pointe vers le
cap 117, Y vers le 207, et Z est croissant vers
le centre de la Terre.
Le repère North-East-Down présenté page 28 du rapport 2004 implique un « heading »
de 0°. Même si cela n’entraine pas de bug (tant que z est bien négatif) il faudra tout de
même vérifier la cohérence de l’exploitation de ces coordonnées NED et des coordonnées
GPS transmises par la MIDGII.
Le sélecteur intervertit Longitude et Latitude
147
7.2.4.4. Interfacer une manette de jeu et MATLAB
Nous disposons d’une manette de jeu Logitech Wingman Precision (voir photo). Dans le
modèle ManetteWingMan_v7_consignes_VxVyVz_PQR.mdl on utilise le bloc Pilot Joystick.
On pourra par la suite utiliser la librairie ManetteWingMan_v7_library.mdl construite à
partir de ce modèle.
Le bloc Pilot Joystick :

Il permet d’extraire les données fournies par la
manette. Deux modes sont disponibles : FourAxis et
All Outputs.
On choisit le mode All Output afin de pouvoir

exploiter toutes les actions sur la manette. On
remarque ici aussi la présence du sample time.
Définition de consignes
Le Quadricoptère simulé est asservi en Vitesse selon X, Y (axes de roulis et de tangage)
et Altitude ainsi qu’en vitesse de rotation autour de l’axe de lacet (vitesse angulaire R).
On réalise l’association suivante, assez intuitive :
Bas/Haut Æ Ax = -1/+1
Gauche/Droite Æ Ay = -1/+1
A/X Æ Az = -1/+1
L/R Æ R’ (= psi’’) = -1/+1
A la différence d’un joystick, une manette de jeu ne fournit que des informations
binaires : chaque bouton est pressé ou non (état 1 ou 0). La présence de switchs assure
que les valeurs de sortie appartiennent à {-1, 0, 1}. En effet l’action sur la croix
directionnelle ne correspond pas à -1/1 mais à environ -0.9/0.9… Les switchs
transforment donc un x>0 en 1 et un x<0 en -1.
Enfin, un intégrateur permet d’obtenir des consignes de vitesse.
148
7.2.4.5. Interfacer une manette de jeu, MATLAB et FlightGear
A l’aide des librairies ManetteWingMan_v7_library.mdl et

UsingPreconfiguredBlock_v5_library.mdl définies plus haut, on crée le modèle
Manette_FG.mdl.
La croix directionnelle
permet de modifier les
vitesses selon l’axe Nord-
Sud (Haut-Bas) et Est-
Ouest (Droite-Gauche). La
vitesse angulaire de lacet
et la vitesse
ascensionnelle sont
commandées par les
boutons comme indiqué
précédemment.
On peut introduire une
matrice de rotation
exploitant l’angle de lacet,
afin de prendre comme
consigne des vitesses dans
le repère de l’aéronef
(VxÆaxe longitudinal et
VyÆaxe de tangage). Cela
serait beaucoup plus
ergonomique.
149
7.2.4.6. Interfacer une manette de jeu, MATLAB et FlightGear (Vitesse

dans le repère de l’aéronef)
On utilise dans le modèle Manette_FG_rotation_y.mdl le bloc « Quaternion Rotation » de

l’Aerospace Blockset, ainsi que le bloc « Sine and Cosine » pour réaliser la rotation du
vecteur de vitesses exprimées dans le repère de l’aéronef autour de l’axe de lacet.
7.2.4.7. Piloter le Quadricoptère simulé (Manette, Simulink, FlightGear)
Rappel sur le modèle

Le modèle simulation_v.mdl doit être ouvert une fois le fichier simu_erwan.m exécuté. Il
accepte des Commandes Z, Vx, Vy (repère du Quadricoptère) et Psi, calcule l’évolution
dynamique du Quadricoptère et les consignes moteurs permettant d’atteindre l’état
commandé. Il fournit les informations disponibles en sortie de MIDGII, suffisantes pour la
visualisation sous FlightGear.
Connexion des blocs

On utilise les librairies : simulation_v_library.mdl, ManetteWingMan_v7_library.mdl,
UsingPreconfiguredBlock_v5_library.mdl et des blocs de redimensionnement pour
adapter les grandeurs des paramètres à la simulation d’une part, à FlightGear d’autre
part. Les grandeurs qui interviennent sont des degrés/0.01degrés, m/cm…
150
Remarque sur les paramètres de la simulation

On réalise la simulation en « Variable-step ». On peut remarquer que le modèle
simulation_v.mdl s’exécute à l’origine en Fixed-step. On peut trouver intéressant de
travailler en fixed step, dans la mesure où cela se rapproche des conditions de calcul du
microcontrôleur et de communication entre les différentes unités. Si l’on désire travailler
en Fixed-Step, des étapes nécessaires sont :
la modification des « Sample Time » du Joystick et des blocs d’envoi à FlightGear, en
accord avec le pas de temps choisi : ils doivent en être des multiples.
L’insertion de « Rate Transition »
7.3. Perspectives de développement
7.3.1. Bilan du groupe HIL
En implémentant sous MATLAB les différents protocoles de communication, nous avons

finalement été capables de constituer sur le Target PC une modélisation du drone
intégrant la MIDGII et un capteur à ultrasons.
Le résultat obtenu est un modèle de drone stabilisé par des contrôleurs codés dans un
main.c.
L’objectif ultime du groupe HIL est de fournir une plateforme de test et de simulation.
Celle-ci devant permettre de valider des main.c chargés sur l’Atmega d’un kit ou du
drone immobile avant respectivement de charger le main.c sur l’Atmega du drone ou de
rétablir les connexions aux moteurs et périphériques simulés.
Il est important de rappeler ici (cf partie du système non linéaire) ce qui distingue
le main.c actuel du drone de celui que nous sommes aujourd’hui capables d’utiliser avec
le Target PC. Nous travaillons en float et non en integers, la boucle d’atterrissage
automatique est absente, ce ne sont pas les consignes moteur qui sont transmises via
PWM mais 4 variables découplées, le changement de système de coordonnées est
effectué sur le Target PC et non sur l’Atmega.
Nous livrons un système opérationnel complet correspondant au cadre général du
HIL Maintenant, chacun de ces écarts au main.c du drone pourra être corrigé étape par
étape, en s’assurant de maintenir le bon fonctionnement de l’ensemble.
Au-delà de ces corrections, nous présentons ci-dessous des développements qui
nous semblent intéressants et réalisables. L’étude de leur utilité et le choix de leur
réalisation éventuelle revient à la nouvelle équipe…
151
7.3.2. Perspectives de développement
7.3.2.1. Récupérer sur un autre PC les informations du Quadricoptère

simulé par le Target PC.
Il est facile d’envoyer sur un autre port série les messages de la midg2 grâce à la carte
Quatech Target PC. A l’aide du module de décodage de messages 10 et 12, on sera en
mesure de fournir à FlightGear les paramètres nécessaires. Cependant nous n’avons pas
encore trouvé de bloc dans Simulink prévu pour la réception des paquets du port série.
On note que groupe Interface Homme-Machine est déjà capable d’exploiter le flux
montant vers la station sol. Voir fonctions Data_processing.m et serial_Callback.m.
7.3.2.2. Visualisation sur FlightGear du vol simulé sur Target PC
L’utilité du point précédent est désormais évidente. On utilisera les informations de la

MIDGII pour une meilleure représentation que les Scopes de xPC Target… C’est un
objectif très prioritaire !
7.3.2.3. Permettre la réinitialisation des consignes de vitesse
Il serait utile de réinitialiser les consignes de vitesse. En effet cela permettrait de rétablir
le vol stationnaire. Le plus simple serait néanmoins de disposer d’un joystick.
Idéalement, il même faudrait un double joystick, comme sur la radiocommande. En
conservant la manette, une boucle d’automatique devrait permettre de ramener la
consigne intégrée à 0.
7.3.2.4. Développer un modèle 3D du Quadricoptère pour FlightGear.
Dans un premier temps, on pourrait se contenter d’un modèle d’hélicoptère existant. On

peut se reporter à http://www.flightgear.org/Docs/fgfs-model-howto.html et lire que
FlightGear supporte grace à plib de nombreux formats de fichiers 3D parmi lesquels
VRML1, AC3D, DXF, MDL… Il semble possible d’exporter le modèle CATIA en VRML.
(http://zone.ni.com/devzone%5Cconceptd.nsf/webmain/22C754E85A8BD6D3862571340
0656199?opendocument&node=dz00000_us)
7.3.2.5. Développer une carte de la région que l’on veut survoler.
Utiliser GoogleEarth pour obtenir des images précises de l’Ecole Centrale par exemple et
améliorer la texture de la zone fournie dans le package de base. On se reportera à la
documentation en ligne de FlighGear pour plus d’informations.
7.3.2.6. Utiliser un Joystick/une manette de jeu et MATLAB pour piloter

le Quadricoptère.
Développer en accord avec le groupe transmission un flux descendant du PC de contrôle

au Quadricoptère. Il serait alors possible de reproduire une séquence de consignes. Ce
développement s’inscrit dans la démarche qui conduira à l’asservissement en position du
Quadricoptère.
7.3.2.7. Utiliser FlightGear sur « l’interface Homme-Machine ».
On disposerait ainsi d’un horizon artificiel fortement amélioré, puis un moyen de

reproduire et d’analyser le vol réalisé. Cela serait particulièrement impressionnant si
l’amélioration de la carte proposée plus haut était réalisée. On peut se reporter à
http://www.flightgear.org/Gallery-v0.9.10/ (bas de page, recherche du texte « synthetic
view ») et http://www.flightgear.org/~curt/Models/Special/Rascal110_2/.
152
8. CALCULATEUR EMBARQUE
8.1. Introduction
8.1.1. Présentation du sous-groupe :
Le sous-groupe Algorithmique /Calculateurs embarqués est le groupe chargé du

microcontrôleur embarqué sur le drone et leur programmation afin de leur permettre de
pouvoir lire les données reçues des capteurs et de la radiocommande et les interpréter
pour pouvoir commander les moteurs, ce qui permet au drone de voler dans la direction
et avec la vitesse qu’on souhaite. Ce microcontrôleur est en effet rien d’autre que le
cerveau pensant du drone grâce auquel on peut lui transférer de l’intelligence artificielle.
Pour être membre de ce sous-groupe il est préférable d’avoir des connaissances de base
sur la programmation en C pour pouvoir programmer le microcontrôleur, sur
l’électronique pour pouvoir effectuer des mesures de grandeurs électriques sur la carte
électronique principale contenant le microprocesseur, et enfin sur l’automatique, les
boucles d’asservissement et les différents contrôleurs pour pouvoir comprendre
rapidement la partie boucle automatique du programme principal et les simulations
Simulink/Matlab correspondantes afin de pouvoir les élargir.
8.1.2. Présentation du matériel
Notre microcontrôleur principal pour cette année est l’ATMEGA128L. Ce dernier est un
microcontrôleur de basse alimentation 8-bit contenant 128 Ko de mémoire Flash basé sur
l’architecture AVR enhanced RISC (Reduced Instruction SET Computer).
Pour pouvoir manipuler ce microcontrôleur il nous faut un kit de développement

permettant de l’alimenter et de nous donner accès à tous ses ports. Dans notre labo on
dispose de deux kits de ce genre avec chacun un microcontrôleur ATmega128L dessus.
Le premier kit est le STK300 qui contient un connecteur d’alimentation, un interrupteur
on/off, un connecteur RS232 et connecteur de programmation ainsi que des connecteurs
correspondants aux différents ports de l’ATmega. Il contient également 8 diodes LED
avec 8 interrupteurs permettant de les contrôler. Ce kit réagit avec deux logiciels : AVR-
ISP qui est livré en CD accompagnant le kit et PoneyProg 2000 qui nous a été conseillé
par nos prédécesseurs. Ce dernier est important comme logiciel car il sera toujours utilisé
pour flasher le programme principal sur la mémoire de l’ATmega embarqué sur le drone.
Un manuel détaillé de l’utilisation de PoneyProg et du branchement nécessaire avec le
quadri se trouve dans la documentation appelé « Rapport quadri » faite par Mathieu de
l’équipe Quadri 2004-2005.
Pour traduire un programme écrit en C ou en assembleur en langage hexadécimal on

utilise respectivement les logiciels de traduction WinAVR et AVR Studio. Cette traduction
s’effectue après avoir compilé le code et se manifeste par la création d’un fichier
d’extension hex qui sera ouvert par PoneyProg ou AVR Studio et flashé sur le
microcontrôleur.
153
Schéma simplifié du STK300
Le deuxième kit le STK500/501 est un kit plus développé qui contient en plus du STK300
deux ports séries permettant au même temps la lecture et la programmation de
l’ATmega. Ce kit fonctionne exactement pareil comme le STK300 sauf qu’il communique
avec le pc via un autre logiciel qui est AVRstudio (il est indispensable d’avoir toujours la
dernière version de ce logiciels pour éviter toute sorte de bug, vous trouverez cela sur
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725)
Kit STK500
154
Sur la partie encadrée en vert sera fixé le STK501 qui contiendra l’ATmega128 :
Kit STK501
On dispose d’un autre microcontrôleur plus sophistiqué, contenant 8Mo de mémoire Flash
(64 fois plus que l’ATmega128) et beaucoup plus facile à programmer. La question qui
vient à l’esprit toute de suite est, pourquoi on ne l’utilise pas au lieu de l’ATmega128
puisqu’il est plus performant. Une réponse détaillée à cette question sera donnée à la
partie 4 « Travail supplémentaire/Activité expérimentale » de ce travail.
155
8.2. Objectifs de l’année
Rentrer des waypoints :

• Système explicite des coordonnées
• Possibilité de rentrer les coordonnées (Hardware et interface)
• Vérification des coordonnées
• Sauvegarder les coordonnées sur l’ordinateur et sur le drone
• Transmettre les coordonnées
• Procédure de lancement
Voler de A à B en mode automatique :

• Déterminer le chemin à suivre (quel type d’asservissement, vitesse ou position)
• Tenir le vol (résoudre le problème court-circuit, augmentation de l’autonomie)
• Se déplacer
• Action à la fin du parcours
• Se déplacer de A vers B
Détection d’obstacles :
• Arrêter le drone / vol stationnaire
• Propositions de possibilités
o Conduite manuelle
o Atterrissage automatique
o Nouvelles coordonnées
o Manœuvre d’esquive automatique
• Rentrer et transmettre le choix
Définition du mode de passage entre mode manuel et automatique :

• Moyen d’activer la conduite manuelle (bouton, mouvement du contrôleur…)
• Moyen pour rentrer des commandes (Manette, joystick…)
• Traduction et transmission des commandes
• Possibilité de rentrer des nouvelles coordonnées en vol
• Possibilité de repasser en automatique
Etablissement d’une procédure d’atterrissage en cas d’urgence :

• Notification
• Définition d’une ou des procédures automatiques (atterrissage, rentrée…)
• Possibilité d’interagir (de changer le chemin/de rentrer des nouvelles
coordonnées)
156
8.3. Démarche suivie
8.3.1. Rentrer des waypoints
8.3.1.1. Comment définir le circuit
On souhaite que le drone se déplace suivant un circuit bien défini d’une manière
automatique. Il faut disposer de la trajectoire à suivre avec des mesures précises. La
façon qu’on propose de modéliser le chemin est la suivante.
L3
L2 1
L5 L1
Drone
A=> (0,0) est la position initiale.

B=> (L1, Ө1)
C=> (L2, Ө2)
…
On peut donc coder le circuit par la suite numérique 0,0,L1,Ө1,L2,Ө2,L3,Ө3,L4,Ө4,L5,Ө5)
L’équipe de la station au sol envoie par la liaison sans fil le circuit codé.
En mode manuel, on déplace le drone dans le point A et on le fait tourner pour qu’il soit
dans la bonne orientation de départ. Ensuite, on appuie sur le bouton qui bascule vers le
mode automatique.
Le drone commence ainsi son parcours programmé. Il repère le sommet suivant à
atteindre (B), et prend le plus court chemin à savoir une ligne droite [AB] avec une
vitesse uniforme défini. En réalité, la vitesse de mouvement ne peut pas être uniforme
(effet du vent, accélération de démarrage, perturbations extérieures)
Le drone doit être capable à tout moment de connaître sa position dans la trajectoire.
Pour ce faire, il faut que dans des intervalles de temps égaux Δτ assez courts, il aille
chercher la vitesse v. Comme ça, en intégrant la vitesse, on peut connaître avec
précision sa position qu’il communique à la station au sol.
Supposons, qu’à un instant t0, on bascule au mode manuel et on dévie de la trajectoire
prédéfinie pour éviter un obstacle qu’on ne s’est pas rendu compte dans la définition de
la trajectoire. Une fois l’obstacle contourné et le drone remis de nouveau dans sa
trajectoire, il n’est pas capable de connaître ou il est dans le circuit à cause de
l’interruption, et par conséquent, une reprise du mode automatique n’est plus faisable.
157
Il est donc nécessaire d’avoir la rotation Ө régulièrement et grâce à un algorithme

spécifié, l’engin est capable de connaître sa position dans le circuit et reprendre
éventuellement le mode automatique.
8.3.1.2. Comment récupérer les waypoints à partir de la MIDGII
Ce travail a été l’interface des travaux de quatre sous-groupes : les calculateurs qui
devaient avoir une information sur la position pour pouvoir programmer l’asservissement
en position, la transmission car ces positions devraient être transmises pendant le vol via
le modem, la station sol car la récupération de ces données s’effectue sur cette interface
et évidemment les capteurs car la MIDGII fait partie des capteurs du drone.
L’interdépendance de tous ces groupes pour effectuer ce travail a représenté un obstacle

non négligeable face à la résolution de cette problématique. En fait dans le dernier
programme principal fonctionnel livré de l’équipe 2004-2005, il n’y a pas d’ordre de
transmission de ces données importantes à la station sol et on n’était même pas sur que
les valeurs data[PX] et data[PY] (position en X et position en Y : revoir l’annexe « code
source/boucles automatiques ») existaient, et si c’est le cas si elles représentent des
valeurs plausibles.
8.3.2. Automatique/asservissement en position
8.3.2.1. problématique
Pour la conception de l’automatique notre équipe a adopté la modélisation réalisée par

les équipes précédentes. Pour cela il est nécessaire pour comprendre cette partie d’aller
avoir les rapports quadri05 et quadri04. En effet nos prédécesseurs nous ont laissé un
drone capable de voler, bien asservi en vitesse et stabilisé en position verticale. Ce
résultat semble être excellent mais est malheureusement encore très loin des objectifs
principaux du concours, qui consistent à avoir un drone intelligent capable de détecter
des objets et des obstacles, les éviter et signaler leur présence à sa station sol, un drone
plutôt asservi en position de telle sorte qu’il pourra faire un parcours prédéfini en mode
automatique sans dépendre des commandes du pilote.
Notre équipe avait pour ambition de s’approcher aux maximum des objectifs de ce
concours même si lui n’existe plus pour cette année 2006, dans l’espoir qu’il sera relancé
par l’ONERA l’année prochaine. Cette tâche, de voler en automatique, n’était pas du tout
facile à réaliser vu sa dépendance très forte de la première tâche « rentrer les
waypoints » et de la quatrième tâche « mode de passage du manuel en automatique ».
Des règles de sécurité devraient impérativement être respectées afin de pourvoir
récupérer le contrôle du drone au cas où il commence à faire des déplacements
imprévus.
8.3.2.2. Solutions possibles
Pour ce faire on a réfléchi à la forme du fonctionnement du mode automatique. On peut

imaginer:
• un vol rectangulaire (en hauteur en changeant seulement l’altitude Z puis vol du
point A au point B en choisissant deux point A et B de même ordonnée pour
simplifier la programmation au début, et à la fin on déclenche la manœuvre
d’atterrissage déjà programmée par l’équipe 2004-2005 dès qu’on atteint le point
B)
• un vol triangulaire (le drone s’élèvera obliquement jusqu'à atteindre le point C
sommet du triangle isocèle en C ABC, l’angle α est à optimiser)
• un vol parabolique (le drone fera une branche de parabole avec les points nuls A
et B et de sommet C)
158
La réalisation du vol rectangulaire est la plus simple, puisqu’elle demande moins de

programmation. Cependant les deux autres alternatives sont plus élégantes.
Pour réaliser le vol rectangulaire, plusieurs alternatives sont disponibles :

• Utiliser les coordonnées relatives au drone : coordonnées ENU (voir partie
MIDGII) puis rotation par rapport à l’angle du lacet ψ (d’axe (oz)), dans ce cas le
vol en automatique s’agira d’un déplacement horizontal de x mètres selon l’avant
du drone.
• Utiliser les coordonnées ENU (coordonnées terrestres translatées d’un vecteur
liant le centre de la terre et le premier point où la MIDGII détecte les satellites)
pour pouvoir entrer des waypoints et demander au drone de s’y diriger.
• Utiliser les coordonnées terrestres ECEF (coordonnées par rapport au centre de la
terre) pour éviter de dépendre d’un point de repère facilement perdable en cas de
perte de liaison ponctuelle avec les satellites (solution optimale)
8.3.2.3. Réalisation
Pour réaliser le vol rectangulaire on a choisi d’adopter la première solution, bien qu’elle
ne corresponde pas directement aux conditions du concours. Par contre cette solution
présente une simplicité de réalisation et son succès nous permettra de passer à la
deuxième alternative et puis même à la troisième si la bande passante de transmission le
permet. En effet un éventuel succès d’une telle manipulation représente un grand pas
vers l’automatique, puisque cela prouverait que le drone est bien asservi en position et
que le régulateur de position est bien dimensionné.
Voici les boucles d’asservissement en position réalisé par Erwan :
Boucles de contrôle dans le plan Horizontale : asservissement en position

(Planches Simulink Erwan)
Il existe de nombreuses méthodes permettant de définir les paramètres d’un régulateur.

L’une des méthodes les plus utilisées est celle de Ziegler-Nichols qui permet d’ajuster des
régulateurs P, PI et PID en boucle ouverte ou en boucle fermée sans connaître la fonction
de transfert du système. Cependant ces méthodes n’offrent pas toujours des résultats
satisfaisant surtout si le système étudier est complexe et très oscillant.
159
Le Régulateur PID est théoriquement idéal, mais son application en pratique présente des
problèmes techniques de dimensionnement de ses paramètres. Selon le critère de Zigler-
Nichols les paramètres du contrôleur peuvent être dimensionnés ainsi :
Type Kp Ti Td
P 0.5 Kpc - -
PI 0.45 Kpc 0.83Tc -
PID 0.6 Kpc 0.5Tc 0.125Tc
Ici Kpc et Tc représentent les valeurs critiquent de la limite de stabilité, qui peuvent être
déterminées soit empiriquement soit analytiquement par le critère de stabilité de Nyquist
ou celui de Routh-Hurwitz (voir cours d’automatique de deuxième année).
Dans notre cas on a adopté le cas simple du régulateur proportionnel pour les trois
régulateurs Kxd entre x (pour y c’est pareil) et Vx, Kvxd entre Vx et Phi (roulis) et Kphid
entre Phi et p (vitesse angulaire en roulis). Bien sûr il est toujours mieux d’adopter un
PID mais le terme intégrateur est défavorable aux erreurs de mesure, car il servira à les
amplifier et le terme différentiel peut conduire à des instabilités en dérivant le bruit. Tous
ces facteurs rendent le dimensionnement des paramètres d’un tel régulateur
extrêmement difficile. Des tests sur les paramètres d’un éventuel régulateur PID sont
effectués par M. martin et Erwan.
Pour le régulateur Kpd un filtre passe-bas a été mis pour réduire l’effet dérivateur de ce
régulateur PD.
Le réglage du contrôleur proportionnel peut se faire de façon empirique en utilisant une

procédure qu’on peut résumer ainsi :
1. Mettre le gain à une faible valeur
2. Faire une petite variation de consigne et observer la réponse de la variable contrôlée.
Comme le gain est petit, la réponse sera très amortie.
3. Augmenter le gain et refaire une variation de consigne. Continuer ainsi de suite
jusqu’à ce que la réponse devienne fortement oscillante. Cette valeur de gain est appelée
Ku. On obtient par exemple Ku=5.5
4. Mettre le gain à Ku /2->Kp=2.75
Un exemple de simulation en réponse d’un échelon consigne en X à partir de la 5s pour

aller 300cm plus loin donne :
160
La courbe du haut est évidemment celle de la position x et celle de bas est de y. On voit
bien que la simulation est tout à fait acceptable avec les contrôleurs proportionnels.
La simulation étant bien fonctionnelle, il fallait programmer la boucle d’asservissement en

position et de l’intégrer dans le programme principal. Cette étape a nécessité beaucoup
de travail, car pour la faire il fallait comprendre la boucle automatique déjà programmée.
Cette boucle a été très difficile à comprendre pour des raisons liées à l’ATmega qui seront
développés plus tard. Une explication détaillée de la boucle automatique déjà existante et
de la nouvelle partie programmée sera faite dans l’annexe « code source/boucles
automatiques ».
8.3.3. Détection d’obstacles
La détection des obstacles se fait grâce au capteur ultrason qui fonctionne avec le même
principe que le radar. Ce capteur émet une onde acoustique dont la fréquence est trop
élevée pour être audible par l’être humain. En cas d’obstacle le capteur pourra calculer la
distance qui les sépare en recevant les échos des ondes réfléchies á partir du temps que
l’onde a effectuée pour faire l’allée retour.
8.3.3.1. problématique
Une étude détaillée d’une manœuvre de détection d’obstacles a été faite par nos
prédécesseurs dans l’annexe IX « détection d’obstacle ». Cette étude semble être
parfaite théoriquement mais aucun essai expérimental n’a été fait. Nos objectifs sont de
programmer une manœuvre d’évitement d’obstacle pour éviter le choc frontal. Cela nous
permettra de nous approcher mieux du drone intelligent capable de détecter des objets
et de les éviter conçu par le concours de l’ONERA.
Le télémètre (capter ultrason) mesure la distance la plus courte parcourue par l’onde
réfléchie et n’a donc aucune information sur la géométrie de l’obstacle. Aussi on n’a
aucune garantie que le capteur ne capte pas le sol pendant son vol horizontal vu que le
drone se penche en roulis ou en tangage pour bouger dans cette direction. Une étude
plus détaillée de cette problématique est faite par le groupe capteurs.
D’après le travail effectué par nos prédécesseurs l’algorithme d’évitement d’obstacle se

décompose en deux parties :
Détection :
Le quadri animé d’une vitesse v détecte un obstacle à une distance Xm. On appelle
Xevit(v) la distance de freinage du quadri à la vitesse initiale v. On utilise un facteur de
sécurité fs par exemple égal à 5 %.
• Cas 1: Xevit(v) * (1 + fs) < Xm -> Freinage simple.

• Cas 2: Xevit(v) * (1 + fs) >= Xm -> Manoeuvre d’évitement.
Evitement :
Pour tenir compte du sol :
Le but de l’algorithme est de ne pas tenir compte du cas où l’obstacle détecté est le sol.
Il faut de plus que l’algorithme marche dans des situations instationnaires, par exemple
quand le quadri se met en mouvement ou freine.
En fait, une méthode consiste à comparer la valeur mesurée à celle qu’on mesurerait si
161
C’est effectivement le sol qui est détecté. On a la relation :
Am ≈ Xm sin (θ + β)
Soit ε = 1 - Xm sin (θ + β) / Am
Le test sera alors par exemple : ε < 5 % (facteur de sécurité)

Il faut évidemment disposer de Am.
Un problème posé par cet algorithme si il est utilisé brut est qu’il peut empêcher
l’évitement d’un obstacle situé plus loin que le sol. Il faut donc l’adapter à un tel cas de
figure. Pour ce faire on peut lors de l’évitement diminuer la vitesse jusqu’à se situer en
dessous du seuil de sécurité, et ce seulement si le test sur ε est positif. On évite alors
tout problème.
Attention, on voit qu’il faut mesurer Am pour appliquer l’algorithme. Il vaudra mieux ne
l’appliquer qu’à partir d’une altitude minimum.
• On calcule ε = 1 - Xm sin (θ + β) / Am
• Si ε < 5 % è On se donne une vitesse de consigne inférieure (de 5 % par ex.) au
seuil de sécurité
• Sinon vitesse de consigne = 0
• Ensuite il s’agit pour le pilote de rediriger manuellement le quadri pour pouvoir
éviter l’obstacle.
Puisque le télémètre ne donne aucune information sur la géométrie de l’obstacle, pour

éviter un obstacle on peut soit :
• Lancer une manœuvre qui consiste à augmenter l’altitude du drone tant que le
capteur ultrason indique encore l’existence de l’obstacle, et dès que l’obstacle
disparaît en altitude le drone s’élève de quelques centimètres de sécurité et puis
continue sa trajectoire. Au cas où l’obstacle persiste comme dans le cas d’un
poteau par exemple, on peut déclencher une manœuvre d’esquive latérale.
• Brancher une caméra et faire l’interfaçage entre l’image de l’obstacle et le
programme principal.
Pour réaliser la détection d’obstacles on choisit de faire marcher d’abord la détection et le

freinage, avant de commencer à programmer la manœuvre d’évitement. Un
dimensionnement adéquat fait par l’équipe capteurs nous a épargné à ce stade la
problématique de détection du sol. Concernant la géométrie de l’obstacle on a choisit de
considérer le cas simple pour commencer qui est le cas d’une planche rectangulaire
facilement détectable par le télémètre.
162
Pour tester la capacité de freinage du drone, on a conçu une modélisation Simulink qui
est encadrée en bleue dans la planche suivante :
Boucles de contrôle dans le plan Horizontale : asservissement en vitesse

(Planches Simulink Erwan)
Cette modélisation est basée sur un travail effectué par le groupe capteurs qui on spécifié
empiriquement la portée du capteur ultrason qu’on possède qui est d’environ 100 cm.
Notre capteur rend en fait une valeur infinie lorsqu’il ne capte rien et la distance le
séparant de l’obstacle s’il capte quelque chose.
La fonction d’entrée d_obstacle_y (simulation avec y dans ce cas, pour x c’est
exactement pareil) a une valeur très grande de 65535 cm (FFFF en hexadécimal) puis à
partir d’un certain instant (souvent simulé à partir de la sixième seconde) elle descend à
une valeur de 100 cm, en effet c’est l’instant virtuel de détection d’obstacle. Un test de
comparaison est effectué juste après par rapport à une valeur qui est égale à 200 cm.
Cette valeur est choisie arbitrairement, cependant elle doit impérativement être comprise
entre 100 et 65535 cm. La comparaison nous donne un booléen qui est 1 le signal
d’entrée est supérieur ou égal à 200cm, cela veut dire concrètement qu’il n’y a pas
d’obstacle et 0 s’il y a un obstacle. Juste après il y a une conversion en type Double car
la variable de sortie du Block « Compare to constant » est seulement de 8 bits ce qui
n’est pas compatible le type de variable de la consigne de vitesse. Cette valeur
booléenne converti en Double sera multipliée grâce au Block « Product » avec la consigne
de vitesse. S’il n’y a pas d’obstacle il ne se passe rien et sinon la consigne de vitesse sera
immédiatement annulée.
Le Rate Limiter juste après est un block de sécurité qui sert à amortir les changements
brusques de consigne. En effet il est réglé de telle façon que le changement de consigne
ne doit dépasser en aucun cas la valeur de 300 cm/s en valeur absolue.
163
A une vitesse de consigne en y égale à 100 cm/s à partir de la seconde 5 et une

détection d’obstacle à la seconde 6, la simulation nous donne les courbes suivantes :
Réponse des vitesses horizontales Vx et Vy
On voit bien ici que la vitesse Vx reste négligeable et que Vy obéit à la consigne jusqu’à
l’instant de détection d’obstacle, et puis s’annule au bout d’une seconde comme on a
souhaité. Cela signifie concrètement que le drone s’est arrêté après avoir fait la
détection. La question qui se pose maintenant est, est-ce qu’il s’est arrêté au bon
moment ? Une réponse à cette question se trouve dans la courbe suivante :
164
Réponse des positions horizontales x et y
D’après cette deuxième courbe la détection d’obstacle a lieu à la position relative de 60

cm (instant 6s) et le drone s’arrête à la position relative de 100cm, alors la distance de
freinage est de 40 cm qui est inférieure à la distance séparant le drone de l’obstacle qui
est environ 100cm. Avec cette vitesse ce résultat est tout à fait acceptable.
Mais dès qu’on augmente la vitesse de consigne et par la suite la vitesse réelle du drone,
ce dernier freine moins vite et sa distance de freinage devient de plus en plus grande.
D’après les simulations effectuées, il ne faut jamais dépasser la vitesse de 180 cm/s pour
éviter le choc frontal avec l’obstacle.
Maintenant que les simulations marchent, il faut programmer cette procédure de

détection et de freinage. La programmation de cette partie était moins problématique
que celle du mode automatique. En fait elle ne demande pas beaucoup de ligne de code
mais doit être faite avec précision surtout pour bien dimensionner le Rate Limiter. Le
bout de code ajouté pour effectuer cette procédure sera commenté en détails dans
l’annexe « code source/boucles automatiques ».
8.3.4. Définition du mode de passage entre mode manuel et

automatique
Cette problématique nous a occupé pendant pas mal de temps surtout avant d’effectuer
l’essai de vol en automatique. En fait il s’agissait de définir une manière sécurisée qui
nous permet de reprendre le contrôle sur le drone au cas où il commence à faire des
déplacements imprévus.
L’idéal est de posséder une radiocommande ou un joystick contenant un bouton qui nous
permet de passer d’un mode à l’autre, mais cela n’était pas malheureusement le cas.
Alors on a pensé à effectuer un mode de passage qui consistait à déclencher le mode
automatique dès qu’on atteigne une certaine altitude, dans l’attente d’avoir une
commande plus sophistiquée. Pour plus de détails sur cette problématique, consultez la
partie Transmission de ce rapport.
165
8.3.5. Etablissement d’une procédure d’atterrissage en cas d’urgence
8.3.5.1. Problématique
Notre but est de définir une stratégie en cas d’une perte de liaison avec la station au sol.
Un autre problème peut surgir est la perte de liaison GPS qui peut avoir lieu en endroit
fermé. Pour l’instant, on ne peut s’affranchir de la midg2 car elle fournit des informations
importantes et on ne dispose pas d’autres capteurs qui peuvent le substituer. C’est pour
cela que le 2ème problème n’a pas été vraiment abordé.
Une première solution consiste à s’arrêter et attendre le rétablissement de la liaison.

Après l’écoulement de quelques secondes, il atterrit à l’endroit ou il est coincé. Cette
solution a d’ailleurs été retenu par le groupe de l’année dernière mais il présente
quelques inconvénients, car on ne sait pas trop la nature du terrain sur le quel le
quadricoptère va atterrir.
Une autre solution envisagée consiste à définir un tableau qui contient les coordonnées
de points de stationnement sécurisés. Dans ce cas, la station au sol doit fournir 2
tableaux. Le premier trace le chemin à suivre par le drone en mode automatique : Le
chemin est codé par une série de points par lesquels le drone doit passer. Il prend une
trajectoire rectiligne entre 2 points. Le 2ème tableau contient plutôt une série de points
de stationnement. Quand la liaison se rompt en cours de route, le drone s’arrête,
compare sa position courante aux valeurs dans le 2ème tableau et détermine ainsi le
point de stationnement le plus proche, et après une durée prédéfini (de 30 secondes par
exemple) il se dirige vers ce point et atterrit automatiquement.
Une autre idée consiste à revenir en arrière en cas de rupture de liaison en suivant
exactement le même chemin parcouru. Pour ce faire, on met un tableau dans le quel on
stocke le chemin parcouru et ainsi, le drone peut revenir en arrière jusqu’à ce que la
liaison se rétablisse.
La solution qu’on a finalement retenue est l’atterrissage automatique à l’endroit ou la

rupture survient après une certaine durée d’attente.
Nous avons prévu des points d’atterrissage sécurisés à quoi l’engin peut avoir recourt en
cas de perte de liaison. Ces points sont communiqués au microcontrôleur et l’algorithme
de codage est le même que celui du circuit.
En cas de rupture de la liaison, le mini drone s’arrête et attend trente secondes son
rétablissement. Si rien ne se produit, le drone se dirige vers le point d’atterrissage le plus
proche à moins que la liaison restaure entre-temps.
L’idée qu’on a envisagée, était définir un tableau qui contient les coordonnées de points
de stationnement sécurisés.
En effet, le drone reçoit les valeurs référence des paramètres de position par
communication UART et ensuite un contrôleur assure l’asservissement et permet
d’atteindre le plus rapidement possible l’état final avec des performances statiques et
dynamiques satisfaisantes.
Ce contrôleur a été préalablement construit sur Matlab, puis introduit dans le
programme embarqué. Le drone récolte des données issus des capteurs et notamment
du midg2 :Le capteur de son fournit par exemple l’altitude courante de l’engin et la
midg2 mesure surtout les angles d’euler. Se fait ensuite la comparaison avec les valeurs
souhaités et puis on envoie l’ordre aux moteurs pour ajuster leurs vitesses.
166
Le drone renvoie par ailleurs des données pour déclarer sa position, l’état de la batterie
et ainsi que d’autres paramètres décrivant son état pour permettre à la station au sol de
statuer sur la suite de son chemin.
Message Midg2 :
On fait une interruption qui s'active quand un byte du message de la midg II arrive sur
l'uart 0
On vérifie la bonne réception du message en examinant les 2 premiers octets : Il faut
que le 1er et le 2ème octets soient respectivement égaux à 129 et 161 en décimal.
Quand on est à la fin du message, on effectue une opération arithmétique de
vérification.
cksum0 = 0 <- unsigned character

cksum1 = 0 <- unsigned character
for each byte from ID to Payload_N (inclusive)
cksum0 = cksum0 + byte <- only 8 bits preserved
cksum1 = cksum1 + cksum 0
si on a égalité entre cksum0 et cksum1 indiqués à la fin du message et ceux calculés

selon cet algorithme, alors le message a été reçu intact. Sinon, il y a eu une déformation
et on ne le prend pas en considération.
Maintenant qu’on a le message validé, on commence à le traiter pour en extraire les
informations dont on a besoin qui sont notamment les positions, vitesses axiales et
angulaires. Il est à signaler qu’à un instant donné, on ne peut pas avoir toutes ces
valeurs car ceci dépend du type de message auquel on a affaire. C’est l’octet ID qui sert
à identifier le type de message.(voir la documentation pour plus de détails)
Ces données sont ensuite enregistrées dans un tableau Data décrit ci dessous :
Data Gx Gy Gz Mx My Mz Vx Vy Vz Px Py Pz
167
8.4. Mise en application
8.4.1. Rentrer des waypoints
Manipulations effectuées :
Après avoir modifié le code source de telle sorte qu’il envoie les positions X et Y à la
station sol, On a effectué un premier test qui a échoué puisqu’on a récupérer que des
zéros au lieu des X et Y. Alors un test à l’aide de l’équipe capteur a été effectué
directement sur la MIDGII avec le logiciel de communication livré avec. Bien que ça a été
pénible de maintenir la liaison avec câble MIDGII fixée sur le drone et le PC, on est
parvenu à récupérer des données plausibles dans les deux formats ECEF (de l’ordre de
10e9 Cm )et ENU (de l’ordre de 10e2 cm). Plus de détails sur ces formats de coordonnées
est donnée dans la partie capteurs de ce rapport ou dans la documentation de la MIDGII.
Alors on a constaté que c’est soit un problème de code puisque la transmission par
modem a été testé et elle marchait parfaitement.
Pour résoudre ce problème une réflexion a été faite sur les bits signifiants des 32 bits
contenant la position. En effet en format ENU on n’est pas obligé d’envoyer tous les bits
des 32 puisque ceux de gauches ne seraient pas très intéressant puisqu’ils contiennent
que le signe (1 pour une coordonnée négative et 0 pour une positive). Alors on a choisi
d’envoyer à l’aide de la fonction put_unit16 du programme principal que les 16 premiers
bits intéressants de droite et ainsi ça a fonctionné parfaitement.
Problèmes encore à résoudre :
Un problème peut se poser au cas ou on choisit d’utiliser les coordonnées ECEF pour ne
plus dépendre du point de référence arbitraire (ce cas est plus proche des modalités de
déroulement du concours). Dans ce cas on aura besoin des 32 bits ou bien des 4 octets
complets des coordonnées ce qui pose un problème car la bande passante de la
transmission est limitée à 30 octets au maximum (dans ce cas on doit envoyer 4 octets
pour chacune des coordonnées ce qui nous fait 8 octets au total ce qui est beaucoup)
Un autre problème très gênant auquel on n’a pas de solution géniale pour le résoudre est
que la MIDGII ne marche qu’en plein air. En effet dès qu’il y a un toit ou un mur à
proximité d’elle, elle ne capte plus rien en position et vitesse. Cela rend les tests de vol à
l’intérieur d’un bâtiment impossibles, et bien sûr aussi dehors si les condition climatiques
sont défavorables.
8.4.2. Automatique/asservissement en position
Faute de temps aucune manipulation n’a été effectuée pour tester l’asservissement en
vitesse. On compte sur l’équipe prochaine pour faire ce test avec le programme
main502_0 détaillé dans l’annexe « code source »
168
Travail encore à faire :
• Test de l’asservissement en position avec la version main502_0 du code source.

• Des tests de robustesse devraient être effectués. La robustesse d’un système,
c’est à dire sa capacité à résister à différents aléas dus à son environnement
d’exécution.
• Insertion de waypoints, changement des boucles de simulation de telle sorte
d’enlever le Subsystem de rotation d’angle ψ, et modification du programme
principal de telle sorte que la rotation soit déprogrammée.
• Eventuelle programmation de régulateurs PID.
première manipulation :
Une première manipulation a été faite le mardi 25 avril 2005. Le résultat de cette
manipulation n’était pas optimal, bien qu’elle ait prouvé que la détection d’obstacles était
bien fonctionnelle.
Déroulement :
On a flashé le programme principal modifié version « main501_0 nouveau code détection

d’obstacles » sur la mémoire de l’ATmega. Le pilote de l’opération était Nicolas de Laleu
(chef de projet). Le drone s’est élevé progressivement en altitude, puis à partir d’une
certaine hauteur Nicolas a commencé à diriger le drone horizontalement vers une
planche portée par Erwan. Le drone s’est approché de la planche lentement puis
brusquement il s’est incliné gravement dans le sens contraire du vol et puis il a tombé.
Un deuxième essai a produit le même résultat.
Interprétation :
Le drone a bien détecté l’obstacle et a essayé par conséquent de freiner afin de l’éviter
comme prévu. Le bon coté de cette expérience est que le choc n’a pas eu lieu. Pour
savoir pourquoi le drone perd le contrôle et tombe, on a analysé le code flashé avec M.
Martin. Il s’est avéré que la consigne d’annulation de vitesse n’était pas suivie d’un Rate
Limiter ce qui provoque des variations importantes et aléatoires d’angles de roulis et de
tangage allant jusqu’à 50°, ce qui fait un appel de courant excessif des moteurs pour
pouvoirs se redresser ce qui entraîne en finale la disjonction. Cette expérience nous a
prouvé l’importance du rôle du Rate Limiter et heureusement elle n’avait pas causé de
dégâts.
deuxième manipulation :
La deuxième manipulation a eu lieu fin mai 2006. Beaucoup de vent nous a empêché de
d’éviter la détection du sol. Plusieurs tests ont été faits sans aboutir à un résultat
satisfaisant à cause de ces conditions climatiques. Mais ce qui est sûr, est que le capteur
Ultrason en amont du drone capte les obstacles et le drone y réagit.
169
Travail encore à faire :
• Retester le programme de détection d’obstacle main501_0 afin d’améliorer la

réaction du drone face à une obstacle
• Un filtre passe-bas devrait être rajouté à la procédure de détection d’obstacle
pour éviter que le drone freine ou lance une manœuvre d’évitement d’obstacle
après une détection d’un aléa ponctuel détecté par l’ultrason
• La manœuvre d’évitement d’obstacle devrait être programmée déjà détaillée plus
haut après avoir réfléchi à la méthode de savoir quelle géométrie l’obstacle a.
• Notre programme désactivait totalement les commandes horizontales en annulant
la vitesse, une amélioration de cet algorithme pourra prévoir la possibilité de
reculer ou d’éviter l’obstacle manuellement.
• L’intégration d’une caméra pour ce test pourra permettre de détecter des
obstacles en dehors du champ de vision du pilote.
170
8.5. Activité expérimentale
Le microcontrôleur AT MEGA peut remplir les tâches suivantes :
• lire ce que lui fournit les capteurs et la radiocommande

• calculer les commandes qu’il faut appliquer aux moteurs
• générer les signaux de commande et les fournir aux moteurs
Il a des entrées/sorties pour lire les capteurs et la radiocommande, et générer les

signaux de commandes des moteurs et peut faire des calculs. Mais ce microcontrôleur
reste limité sur d’autres plans.
8.5.1. Limites de l’ATmega
Pour améliorer les performances du drone il faut améliorer les contrôleurs implémentés
dans l’ATmega. Or il est difficile de programmer un contrôleur sur l’ATmega, ceci pour
deux raisons décrites ci-dessous : la discrétisation et les calculs sur entiers
La discrétisation des contrôleurs :
Un fois les contrôleurs calculés, il faut pouvoir les implémenter dans l’ATmega. Les
contrôleurs que l’on calcule grâce à la modélisation du quadri sont des contrôleurs
continus. L’ATmega, quand il tourne, ne fait les calculs qu’à une certaine fréquence. Il
faut donc discrétiser les contrôleurs. Ceci n’est pas évident et demande certaines
précautions.
Le calcul en virgule fixe :
Mais il faut savoir que l’ATmega est un microcontrôleur 8 bits et à virgule fixes : c'est-à-
dire qu’il n’est pas très puissant (8 bits), et surtout il n’est pas assez puissant pour faire
des calculs à résultas flottants. Or, les contrôleurs nécessaires sur le quadri n’ont aucune
raison d’être à coefficients entiers.
Pour mieux connaître les limites de l’ATmega dans le calcul avec des flottants une
manipulation expérimentale a été effectuée afin comparer la vitesse de calcul de
l’ATmega entre deux opérations à résultat entier et flottant.
Protocole expérimental :
• Utilisation de UART0 (port série) pour établir la communication entre le kit

STK500 et le AVR Studio (COM1)
• Programmation d’un code de calcul de temps d’exécution d’une l’opération de
multiplication simple.
• Récupération du temps d’exécution d’une opération de multiplication simple de
deux flottants contenu dan le registre TCNT3H (du TIMER 16 bits TCCR3B voir la
doc. ATmega page 136) grâce à la fonction put_uint16.
• Visualisation du résultat sur le PC à l’aide des programmes Hyperterminal et de
Portmon (pour plus d’informations sur cette procédure de communication avec
l’ATmega avec le port série revoir la documentation faite par le groupe capteurs).
• Récupération du temps d’exécution d’une opération de multiplication équivalente
des deux flottants transformés en entiers.
• Récupération du résultat de la multiplication (fonction d’envoie put_float,
utilisation de Hyperterminal)
171
Résultats obtenus :
Pour être sur d’avoir une durée d’exécution crédible deux méthodes ont été utilisée pour
calculer le temps d’exécution de l’opération de multiplication :
• une méthode approchée à l’aide d’un chronomètre (en fait le programme a été
conçu de telle sorte qu’il allume les quatre LEDS à droite du PORT B pendant la
durée du calcul)
• une méthode exacte en utilisant le TIMER 16 bits TCCR3B et son registre TCNT3H
Le temps d’exécution étant très court, on a choisit de refaire la boucle 128 000 fois, pour
pouvoir avoir un temps mesurable à notre échelle.
Ainsi les résultats obtenus peuvent être récapitulés dans ce tableau :
Temps d’exécution T1 T2 T3 T4 T5 Tmoy

(en seconde)
Multiplication 3,79 3,73 3,76 3,61 3,61 3,724
flottante
Multiplication entière 0,341 0,352 0,348 0,351 2,355 0,349
équivalente
Méthode manuelle (avec chronomètre)
Dans le tableau suivant les variables sont définies ainsi :
Nhex : valeur du Timer lue sur Portmon en Hexadécimal

Ndec : valeur du Timer convertie en décimal
Texec : temps d’exécution calculé par la formule suivante :
Texec = (prescaler* Ndec)/ (fréquence du quartz)
Cette formule se trouve dans la documentation de l’ATmega à la page 126. La fréquence

du quanrtz du STK500/501 est de 16Mhz. Le prescaler a pour valeur 1024 pour réduire
au la fréquence du quartz pour ne pas dépasser la barre de 2^16 du Timer.
Nhex Ndec Texec
Multiplication C63F 50751 3,248

flottante
Multiplication 1500 5376 0,344
entière
équivalente
Méthode exacte (avec Timer interne de l’ATmega)
Interprétation et conclusion :
On remarque d’après les deux approches que le temps d’exécution d’une opération
flottante prends environ 10 fois plus de temps qu’une opération entière. Cela veut dire
que si le programme principale utilisait une ou plusieurs valeurs flottante, il sera 10 fois
plus lent que celui qui existe aujourd’hui.
Pour cela nos boucles automatiques sont faites de telle manière de convertir tous les
flottant en entiers puis de les shifter à droite pour ramener l’opération au résultat entier
le plus proche que celui d’une opération flottante. Ceci complexifie grandement le travail
de programmation et nous empêche de modifier les paramètres des contrôleurs
172
rapidement. Tout cela explique la difficulté rencontrée pour comprendre le rapport entre
les paramètres des planches Simulink et ceux du programme principal.
L’ATmega a donc de nombreuses qualités pour servir de calculateur central,

communiquer avec les capteurs et la radiocommande, et commander les moteurs.
Néanmoins il reste limité par la petite taille de sa mémoire et la complexité de sa
programmation.
8.5.2. Solution du SC520
Pour perfectionner la performance de notre microcontrôleur, on a pensé à intégrer le

SC520. Le SC520 est une carte électronique sur laquelle se trouve un microprocesseur de
type PC. Ce contrôleur est capable de faire des calculs avec des flottants en toute vitesse
(puisqu’il contient une Unité Arithmétique et Logique) et est directement programmable à
l’aide de l'outil « C target » de Matlab (on n’a plus besoin d’écrire des lignes de code).
Cet outil permet à partir d’une planche Simulink de coder un programme capable de
tourner sur une architecture PC.
L’intérêt, c’est que toutes les difficultés de programmations disparaissent. En effet,

toutes les parties de la planche Simulink qui décode les capteurs et qui envoient les
commandes restent toujours les mêmes, et pour essayer un nouveau contrôleur, il suffit
de rajouter la boîte LTI system avec la variable où le nouveau contrôleur est défini, et
laisser faire Matlab. On ne s’occupe ni de la discrétisation du contrôleur ni de la
programmation en C. Il faut cependant définir le « sample time » c'est-à-dire le temps de
discrétisation.
Au final on peut donc tester en quelques minutes un nouveau contrôleur sur le

quadricoptère.
8.5.2.1. Pourquoi utilise-t-on encore l’ATmega128 ?
Le problème est le SC520 n’a presque pas d’entrées/sorties excepté 4 ports série et un
bus. Il ne peut en aucun cas lire les données de la radiocommande ni des capteurs
ultrasons et surtout commander les moteurs.
Au final, la solution retenue est la suivante :

• la carte électronique embarquée comporte l’ATmega et le SC520
• l’ATmega lit les données de la radiocommande et des capteurs (excepté la
centrale envoie les données par communication série, donc lisible par le SC 520
directement)
• elle envoie ensuite ces données sur un port série au SC520 qui calcul les
commandes qu’il faut envoyer au moteur
• Le SC 520 envoie par port série ces résultats à l’ATmega qui commande alors les
moteurs avec ces données.
173
8.5.2.2. Connexions du SC520 :
Les cadres représentent :

• Rouge : COM 2 et 3 (de haut en bas). Des connecteurs on été fait pour les
transformer en sortie db9. (si il faut refaire ces connecteurs, il faut faire attention
à la documentation décrivant les connections car les mini fils sont un peu à
croiser.)
• Bleu : le SC520. On ne peut pas le brancher à l’envers car il y a des détrompeurs
sur les connecteurs (ils ne sont pas totalement symétrique).
• Vert : connexion clavier
• Jaune : connexion écran
• Bleu fluo : bouton reset (très utile !!)
• Blanc : lecteur de disquette : ATTENTION SUR LA PHOTO IL EST BRANCHE A
L’Envers : la nappe doit recouvrir le SC520
Le SC520 sort sur des connecteurs molex (180 petites pattes) plein de connexions. Par
exemple on y retrouve les ports COM etc.…
Quand il est sur son kit de développement, la plupart de ses connexions ressortent des
formes plus ou moins standard. Par exemple les 4 ports COM ressortent : le premier en
prise DB 9 (port série) les autres un peu différemment.
Mais entre les sorties du module et les sorties du kit, il y a des circuits. Ces circuits
peuvent changer la nature même de la connexion : en embarqué, un port COM peut être
TTL, et en sortie du Kit, il peut être RS 232 V24.
Pour cela il faut bien lire les documentations respectives du module et du kit de
développement. Le problème est que la documentation du kit, n’est pas très précise car il
existe plusieurs versions de kit et en fonction de ce qu’on a demandé, certains circuits
sont présents ou non.
Pour nous voici les normes des liaisons séries.

En sortie du module
COM 1 et 2 : RS 232 V24 (ie +12/-12V). On peut d’ailleurs voir des max232 sur le
module.
174
COM 3 et 4 : TTL (0-5V).
En sortie du kit
COM 1, 2 et 3 en RS232 V24 (on peut voir un max 232 sur le kit avant la sortie de
COM3)
COM 4 : je ne me souviens plus trop. Apparemment il n’y a pas de circuit, donc je dirais
que c’est comme sur le module, mais avec le multimètre j’avais l’impression que ce
n’était pas connecté. Il faudra trouver ce que c’est.
Au final, il faut faire très attention pour chaque connexion avec les ports que tout est
compatible. Par exemple on utilisait COM3 pour la liaison ATMEGA SC520. L’ATmega sort
en brut du TTL mais sur la carte électronique il est suivi d’un max232 et passe en RS232
V24. D’où, quand on faisait les tests avec SC520 sur kit de développement, on connectait
le SC520 à la sortie du max de la carte électronique. Mais, quand on faisait les tests avec
le SC520 embarqué, (com3 est alors en TTL), il fallait le connecter en amont du max 232
pour « parler » directement à l’ATmega en TTL.
Au final, faites attention à chaque connexion et lisez bien les documentations du SC520.
Il y en a trois : L-555e.pdf pour le kit de développement, L-554e.pdf pour le module
(SC520), et 1183-3-001.pdf pour tous les schéma de connexion du kit.
Des fois il faut compléter les informations de ces documentations avec des tests au
multimètre.
Le branchement avec le drone s’effectue ainsi :
Midg
2 RS 422
à N’ont pas
vérifier convertisseur encore été faits
RS232 V24 :câble
COM 2
SC 520
COM 3
AT
MEGA TTL
COM0
Schéma du branchement du SC520 embarqué
Le branchement s’effectue ainsi :

• Un convertisseur pour passer de RS 422 de la midg2, le RS232V24 à faire et le
câble rallonge à faire.
• La communication avec l’ATmega doit se faire par TTL. On utilise donc un câble
croisé fait à la main pour connecter le com0 de l’ATmega AVANT LE MAX 232 situé
sur la carte au COM 3 du SC520.
175
8.5.2.3. Planches Simulink/C target de l’asservissement du drone
Rouge : décodage des PPM pulses envoyés par l’ATmega

Marron : contrôleurs (ce ne sont que des LTI system blocks)
Bleu clair : découplage des commandes
Jaune : décodage Midg2
Rose : transcription sur un entier uint8 (entre 0 et 254, pas 255 car header), des volts
qui sortent des boucles d’asservissements.
Bleu foncé : boîte qui gère démarrage linéaire des moteurs quand la manette des gaz est
basse et qui passe ensuite en mode pilotage assisté par contrôleurs.
Vert : envoi des données à l’ATmega avec header
Rouge :
Décodage ATMEGA :
Quand on ouvre le subsystem rouge on trouve :
Les gains sont juste des coefficients de sensibilité. Le 48 est sur la manette des gaz.
Avant le gaz, les données qui arrivent appartiennent à [0 1], et on multiplie par 48 pour
être entre 0 et 48 Volts car cela représente la somme des 4 moteurs, et que tout à été
fait pour des contrôleurs en unité S.I..
Quand on rentre dans le deuxième Subsystem on trouve :
176
Au départ, on utilise deux blocks, dont un stateflow pour décoder les données : cf. aide
Matlab. Attention, cela ne peut pas marcher sans le block « RS232 setup » de la planche
générale. Si l’ATmega envoie des données différentes, il faut modifier le block stateflow
en conséquence.
Remarque : il existe une autre possibilité pour décoder une liaison série plus simplement
mais nous sommes obligés d’utiliser celle là pour des raisons décrites en annexe.
Suit, deux blocks « unpack » et « byte reversal » qui permettent de regrouper les octets
par deux (puisque les données sont en uint16) et intervertissent les octets de poids fort
et faible car l’ATmega envoie les octets de poids fort en premier (little endian) et le
SC520 travaille en big endian.
On convertit le tout en double (c’est tout l’intérêt du SC 520).
On retranche les valeurs des PPM lorsque les manches sont à zéro.
Puis on met des gains pour ramener les commandes entre -1 et 1 sauf les gaz (ppm3)
entre 0 et 1.
Remarque pour retrouver les coefficients, on a, avec le tream des gaz tout en bas :
PPM1 (roulis) : appartient à 3030 plus ou moins 850.
Et respectivement voir planche pour les autres
Remarque tout est fait en Nord East down (contrôleur, capteurs)
Or les ppm sont comme suit :
Ppm3 Ppm2
Ppm4 Ppm1
177
D’où les coefficients négatifs en roll et pitch dans le décodage des ppm.
Jaune :
Le premier block est relié à un autre de la planche principale et permet de décoder très
facilement les données de la midg2. cf. annexe.
On transforme le tout en uint8 car « FIFO bin binary » sort des uint16.
La partie du milieu permet de vérifier le cheksum (à regarder soi même), ce n’est pas
compliqué)
Idem que pour l’ATmega pour « unpack » et byte reversal.
Les gains permettent de passer de centième de degré en radian car les contrôleurs sont
en unité SI.
Marron :
Ce sont les contrôleurs :

La dernière planche ne fait que les contrôleurs au niveau des angles (pb. de temps). On
voit ici, les deux premiers LTI system qui sont des précompensateurs (on y a rentré
precompd2 qui est une variable où un précompensateur s/ (to+s) a été rentré (et c’est
tout, xPC target, fait le reste).
Les gains 7.8 sont des simples proportionnels qui sont les contrôleurs entre la couche en
angle et en PQR.
Les deux derniers LTI system sont des pd qui correspondent aux contrôleurs au niveau
des pqr.
178
Bleu foncé:
Ce block permet de gérer le démarrage des moteurs. Le switch permet de switcher entre
le cas du haut, et celui du bas. Sa condition de switch est basée sur la donnée des gazs
comparé à un chiffre (10).
En haut, on me
Pour la mannette des gaz au dessous de 10 volts (sur 48), on rentre dans les moteurs les
mêmes commandes, qui correspondent juste à la manette des gaz.
Pour la mannette des gaz au dessus de 10 volts, on rentre dans les moteurs les
commandes calculées par les contrôleurs.
Remarque : lorsque l’on utilise le block « uint8 », il faut impérativement cocher
« saturate on integer overflow » dans les options pour éviter tout bug.
8.5.2.4. Utilisation du SC520 avec xPC Target
Tout d’abord j’ai pu réalisé cette partie du travail grâce au rapport et à l’aide de Pierre de
l’équipe quadri 2004-2005 qui a toujours répondu à mes mails et même à mes appels
téléphoniques. Je tiens à le remercier beaucoup avant de commencer.
Pour effectuer cette expérience il faut utiliser la version 7.0.4 de Matlab. Pour pouvoir
programmer le SC520 avec xPC target, il fallait lire un nombre de documentations :
• La documentation de XPC Target surtout le Getting started, le Basic Tutorial et le
paragraphe Embedded Options (voir le Help de Matlab)
• La documentation du SC520 et de son kit de développement (surtout la partie
Bios) se trouvant soit dans le CD en version pdf soit en version imprimée avec le
SC520.
179
Protocole expérimental :
Les branchements de l’expérience ont été effectués ainsi :
Les cadres indiquent :

• Bleu foncé : connexion du SC520 avec lecteur de disquette.
• Vert : lecteur de disquette
• Jaune : alimentation du lecteur de disquette
• Orange : interrupteur pour alimenter ou non le lecteur de disquette
• Rouge : COM1 lié au port série de pc Host avec un câble croisé (câble série
femelle-femelle)
• Noir : COM 2 du SC520
• Marron : COM 3 du SC520
• Bleu fluo : alimentation du kit.
• Vert : Connexion avec l’écran (à gauche)
• Mauve : Connexion avec le clavier
180
Le pc de droite est le pc Host sur lequel une application XPC Target marche. Le Target
dans notre cas ici est le SC520 lui-même. Sa réponse sera visualisée sur l’écran de
gauche. Voici une photo générale de l’ensemble :
Photo du Target : SC520 fonctionnant comme un pc
Pour commencer il fallait tout d’abord configurer le Bios pour permettre le SC520 de
booter sur la le lecteur disquette. Pour ce faire on a suivi la démarche suivante :
• Pour lancer le bios, appuyer sur CTRL-C (du clavier branché au SC520 bien sûr)
au lancement du SC520.
• Une liste apparaît : choisir « configuration CMOS »
• choisir Floppy 0 comme premier Boot Device et Flash 7340 K qui correspond à la
taille de flash du SC520 actuel grâce aux touches claviers décrites sur écran.
Choisir tout d’abord A : pour le lecteur disquette et B: pour la flash
• Boot order : choisir ce qu’on veut.
• Appuyer sur Echap
• Sélectionner “write to CMOS and exit”.
NB: il y a un bouton reset sur le kit de développement qui évite de débrancher et

rebrancher le SC520 à chaque fois qu’on veut le rebooter.
Pour utiliser XPC Target avec le SC520 il existe 3 modes :

• Mode Boot Floppy : Boot floppy permet de télécharger des programmes
rapidement mais on doit garder une connexion avec l’ordinateur et on ne peut
utiliser ce mode en embarqué. Néanmoins pour vérifier que les commandes ne
sont pas folles, on peut quand même laisser pour les premiers tests le SC520 sur
son kit et le connecter au quadri via un cordon. Ce mode est très pratique pour
tous les débugages
181
• Mode DosLoader : Ce mode permet d’éviter la dépendance du SC520 du lecteur

disquette. En fait il sert à configurer la Flash et installer DOS dessus. Dans notre
cas ce mode n’a pas une grande importance.
• Mode Standalone : Le mode Stanalone est le mode le plus intéressant. En effet il
permet de tout mettre sur la flash du SC520 et donc l’utiliser en vol embarqué. Il
faut l’utiliser que quand tout a déjà été débuggé avec le mode Boot Floppy.
Configuration du mode Boot floppy :
• taper la commande « xpcexplr » qu’on tape sur la fenêtre de commande de

Matlab (version 7.0.4 ou plus !!). Si cette commande ne marche pas aller sur le
site http://www.mathworks.com/support/solutions/data/1-
13B6EL.html?solution=1-13B6EL et télécharger le fichier xpc_register_ocx.m et le
placer dans le répertoire $MATLAB\toolbox\rtw\targets\xpc\xpc\ (écraser l’ancien
défectueux). Après redémarrer Matlab et écrire dans la fenêtre principale les
commandes
rehash toolboxcache
xpc register-ocx
xpcexplr
et la fenêtre xpcexplr s’ouvre.
• Dans l’onglet Compiler choisir Visual C (l’installer s’il n’existe pas)
• Aller à l’onglet Configuration et choisir le mode Boot Floppy
• Créer une disquette Boot Floppy
• La mettre dans le lecteur connecté au kit de développement.
• Rebooter le kit et le SC520 lance (si bios bien configuré) sur la disquette le kernel
de xPC target.
• Sur la planche de l’ordinateur hôte, aller au menu « Tool » puis « Real Time
workshop » puis « Build Model » ou bien directement CTRL-B. Ainsi la planche
Simulink se télécharge dans le SC520. En cas de bug, vérifier la connexion entre
le Host et le COM1 du SC520
On a téléchargé alors sur le kit le programme qui peut ensuite tourner quand on choisit le
mode « external » dans le menu « Simulation » et on clique sur « connect to Target »
puis sur lecture de la planche Simulink.
Pour plus de détails sur ce mode, consultez l’annexe HIL de ce rapport. Une démarche
détaillée y est expliquée.
Configuration du mode Standalone :
Ici seulement le cas du SC520 de mémoire 8Mo est traité, puisque c’est lui le
microprocesseur dont on dispose actuellement.
Avant tout il fallait faire une disquette DOS. Pour cela, (car DOS n’est pas logiciel libre)
un fichier boot622.exe est disponible dans un CD contenant les archives du Groupe
Calculateurs (Surtout ne pas le chercher sur Internet, il y a d’autres fichiers qui ont le
même nom mais qui non rien à voir avec !!). Après il suffit de mettre une disquette
formatée dans le lecteur disquette du Host et cliquer sur le fichier boot622.exe. Il crée
alors une disquette DOS.
182
Sinon il existe déjà une disquette Dos qui s’appelle « Dos compatible SC520
Boot622.exe » écrit avec le crayon. On peut l’utiliser directement pour configurer la Falsh
du SC520.
• Insérer la disquette dans le lecteur connecté au SC520.

• Configurer le BIOS pour qu’il boote sur le lecteur de disquette (donner comme
nom au lecteur de disquette A: et B : pour la Flash du SC520, et rebooter le
SC520 : DOS se lance.
• Taper « format /s b : pour formater la Flash et le kernel de DOS y est installé
La flash est alors configurée, il fallait maintenant créer l’application sur un fichier séparé
et le copier dessus.
• Configurer xPC Target en mode Standalone (grâce à xpcexplr).

• Choisir Mode « normal » dans le menu « Simulation »
• Builder la planche Simulink (comme c’est décri en mode Boot Floppy), Matlab crée
un dossier dans le dossier courrant appelé nomfichier_xpc_emb contenant trois
fichiers dans un sous dossier : autoexec.bat, xpcboot.com et nomfichier.rtb. En
cas de Bug revoir le dimensionnement du "Solver" dans le menu « Simulation »
« Configuration Parameters »
• Copier sur une disquette (de préférence vide) les fichiers précédents du Host, puis
les transférer à la mémoire Flash du SC520 avec la commande DOS « A:\>Copy
*.* b : », on peut vérifier après que les fichiers sont bien transférés avec la
commande DOS « dir b : »
Ce qu’il y a dans la flash au final :

Command.com (là après formatage DOS)
Autoexec.bat
xpcboot.com
nomfichier.rtb
• Une fois nomfichier.rtb sur la flash, si celle-ci est bien configurée, il suffit alors de
rebouter le SC520, d’avoir reconfiguré le BIOS de sorte que le Premier Boot
Device soit la Flash 7340 K (qui est le SC520).
• Rebouter, l’application xPC Target se lance automatiquement
Ainsi on s’est débarrassé complètement de la disquette et du câble croisé liant le Host et

le Target. C’est mode Standalone ou le mode du calculateur embarqué en vol.
Résultas et problème critiques:
La manipulation déjà décrite a marché sans problème dans le mode Boot Floppy, mais
était un peu plus problématique pour le mode Standalone. Faute de temps la réalisation
d’un essai de vol en mode Standalone n’a pas été réalisée mais cella a déjà été faite par
nos prédécesseurs (cf. Rapport SC520enforme de Pierre). En Fait il reste juste de
brancher le SC520 avec les capteurs et l’ATmega selon le schéma de branchement du
SC520 embarqué en le fixant sur sa carte fabriquée par Pierre.
Un premier problème critique en mode standalone. Il faut savoir tout d’abord que dans
xPC target en mode boot floppy, il existe une connexion host/target qui permet de
télécharger les programmes etc…
Cette connexion host.target peut se faire soit par liaison série ou par éthernet. Lorsque
l’on fait sa floppy (à partir de xpcexplr, on peut choisir quoi choisir : RS 232 ou TCP/IP).
Nous choisissons pour le SC520 une liaison série car la carte ethernet n’est pas
compatible avec xPC target. Evidemment, dans ce cas, on pers une liaison série (COM 1).
Mais on peut se débrouiller sans.
183
Le problème est qu’en mode standalone, cette communication Host/target (inutile alors)
existe encore et monopolise encore COM 1. Si on veut utiliser un block envoyant des
données sur COM 1, le programme bug.
Ensuite, il faut également savoir qu’il existe deux block pour lire les liaisons séries (cf.
Philippe Martin). L’un doit être suivi d’un block stateflow et pas l’autre. Le deuxième est
beaucoup plus évolué car il cherche lui-même les headers etc. du point de vu historique il
est apparu après d’où l’utilisation du compliqué). Cependant, dans la pratique un autre
point important les différencie.
Le deuxième (facile d’utilisation) « relie » COM 1 et COM 3 (tout comme COM 2 et COM
4), car ils fonctionnent sur la même interruption. Il faut d’ailleurs n’utiliser qu’un seul
block qui s’occupe des deux ports en même temps. Ce qui pose problème, c’est qu’une
liaison host/target ne peut pas partager son interruption. Donc si la liaison Host/target
est sur COM 1, on ne peut pas utiliser COM 3.
Le premier block (compliqué à utiliser) a en revanche l’avantage de quand même
marcher (bien qu’indiqué le contraire dans la documentation). C'est-à-dire que malgré
une communication Host/target sur COM 1, on peut utiliser COM 3 !
Le premier block est donc utilisé pour la liaison avec l’ATmega (un seul header à lire donc
décodage encore faisable à la main) et sur COM 3. Le deuxième block qui peut lire
facilement plusieurs headers (pour la midg2 par exemple), est alors utilisé pour lire la
midg2 sur COM 2. Pour plus de détail sur ce problème, consultez M. Martin qui a déjà
contacté Mathworks à ce propos.
Un deuxième problème important a provoqué l’arrêt des essais de vol avec le SC520 de
nos prédécesseurs avant le concours 2005. En fait en faisant un essai de vol, l’ancien
SC520 de mémoire Flash 1Mo a été grillé. Alors on a commandé un deuxième. Ce
deuxième a pour mémoire 8Mo, ce qui est mieux théoriquement, mais ce SC520
présentait un gros désavantage : son BIOS se déconfigure dès qu’il n’est plus alimenté.
Or, le BIOS par défaut est préconfiguré pour se lancer sur une flash de 1 Mo. Avec le
premier SC520 (celui qui ne fonctionne plus), aucun problème n’est donc apparu. Mais
pour celui avec une flash de 8 Mo (donc le nouveau), cela rend impossible le mode
Standalone. En effet le SC520 n’arrive plus dans ce cas à booter sur sa propre Flash car il
fallait l’enlever de son kit (alors il n’est plus alimenté) pour le brancher sur le drone.
Ainsi, même si l’on a configuré la Flash pour que le SC520 boot sur la flash de 8 Mo, le
BIOS se reconfigure et quand on alimente la carte électronique du quadricoptère, le
SC520 essaye de booter sur un flash de 1 Mo, qui n’existe pas.
184
Solutions et piste pour l’avenir:
Pour résoudre ce problème on a contacté Phytec on Allemagne qui nous ont dit qu’il faut
brancher une batterie 3V entre le pin 6C Vbat et la masse. Ainsi la BIOS pourra être
sauvegardée. Une batterie bouton Litium a été soudée sur le module SC520 et ceci a
résolu définitivement le problème.
Schéma du branchement du SC520 avec sa carte d’embarquement
La flèche bleue indique le Molex utilisé pour le branchement avec la carte réalisée par
Pierre (à gauche). A droite de ce Molex il y a la rangée C et à gauche la rangée D dont
les pins sont indicés du haut vers le bas selon cette photo. Pour ne pas se tromper la pile
couverte avec le scotch jaune est branché au pin 6C (fil rouge) et à la masse (fil jaune).
Ces fils sont très fragiles !
Ainsi on dispose d’un système opérationnel prêt à voler. Ceci est très utile pour
dimensionner rapidement les paramètres des contrôleurs à partir des essais de vol ciblés.
Néanmoins à cause de son poids non négligeable (environ 50g), on ne peut pas
envisager une solution finale avec le SC520 embarqué. C’est pour cela on l’utilisera juste
comme outil d’ajustement des paramètres des contrôleurs (surtout si on y rajoute des
termes intégrateurs et dérivateurs aux régulateurs) et une fois on a trouvé les
paramètres idéaux on les programme sur l’ATmega une fois pour toute.
185
9. ANNEXES PROPULSION
Environnement AT90PWM3 dans un variateur
Board carte de test - dessus
186
Board carte de test - dessous
Schéma d’implantation carte de test
187
Schéma électronique carte de test
188
Schéma électronique variateurs actuels (Toshiba)
Courant maximal admissible par piste
189
Code source génération PWM sur PSC1 AT90PWM3
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <inttypes.h>
// choisit le PLL à 64MHz
Start_pll_64_mega()
{PLLCSR = 0x06;}
// vérifie que l´horloge PLL est verrouillée
Wait_pll_ready()
{While (! (PLLCSR & (1<<PLOCK)));} //!Retourne 1 si le PLL est verrouillé
//! Connecte le signal PLL au PSC1
Psc1_use_pll_clock()
{ PCNF1 |= (1<<PCLKSEL0); }
//! Active les deux sorties A et B de PSC1
Enable_both_psc1_outputs()
{PSOC1 |= ((1<<POEN1A) | (1<<POEN1B));}
//!< PSC1 outputs sont active High
Psc1_outputs_active_high()
{PCNF1 |= (1<<POP1) ;}
//! Enclencher le PLL à 64MHz et le connecter au PSC1
Psc1_use_64_mega_pll_clock()
{Start_pll_64_mega();
Wait_pll_ready();
Psc1_use_pll_clock();
}
//! Configurer PSC1 en mode centré
Psc1_in_centered_aligned_mode()
{PCNF1 |= ( (1<<PMODE11) | (1<<PMODE10) ) ;}
//!< Enclencher le cycle pwm de PSC1
Start_psc1()
{ PCTL1 |= (1<<PRUN1); }
main()
{
// PSC est sur 12 BITS de 0X0000 à 0x0FFF
//remplir les registres de comparaison
OCR1SAH = 0x04; OCR1SAL = 0X00;
OCR1SBH = 0X07; OCR1SBL = 0X00;
OCR1RBH = 0X0F; OCR1RBL = 0Xff;
Psc1_use_64_mega_pll_clock();
Enable_both_psc1_outputs();
Psc1_outputs_active_high();
Psc1_in_centered_aligned_mode();
Start_psc1();
while (1);
}
190
10. ANNEXES CAPTEURS
10.1. Annexe 1 : code source de la MIDG II
SIGNAL( SIG_UART0_RECV ) //s'active quand un byte du message de la midg II

arrive sur l'uart 0
{
// déclaration de variables
volatile char c = UDR0; //copie le byte du message qui est arrivé
static uint8_t CHECKSUM0_MIDG2, CHECKSUM1_MIDG2, bytecounter_MIDG2,
envoi;
uint8_t y, Vbat;
midg2_valid=1; //un byte est arrivé, la midg II est considérée comme
fonctionnelle
TCNT2=0; // ??
bytecounter_MIDG2++; //compteur pour savoir où on en est dans le
message. Il commence donc à 1
// lecture du header (129 161, 81 A1 en hexa)
if (bytecounter_MIDG2==1)
{if(c!=129)
{bytecounter_MIDG2=0;CHECKSUM0_MIDG2=0;CHECKSUM1_MIDG2=0;}
return;}
if (bytecounter_MIDG2==2)
{if(c!=161)
{bytecounter_MIDG2=0;CHECKSUM0_MIDG2=0;CHECKSUM1_MIDG2=0;}
return;}
// Protocole d'envoi des données quand on est à la fin du message
envoyé par la midg2 et mises des données dans data utilisé dans la boucle
if (bytecounter_MIDG2==(rx_buf_MIDG2[1]+6)) //on est à la fin du
message quand on a bytecounter=count+ 4 bytes de header+2 bytes pour les
checksum
{
// vérification de la validité du message en vérifiant
que les checksums sont bons
if ((CHECKSUM0_MIDG2==rx_buf_MIDG2[bytecounter_MIDG2-
4])&&(CHECKSUM1_MIDG2==c))// -4 parce qu'on enregistre pas le header dans
le buffer (2 bytes), qu'on veut l'avant dernier byte, et que le premier
indice c'est 0
{
// LEDon;
// LED1on;
// imu=1;
switch (rx_buf_MIDG2[0]) //traitement différents
selon le message reçu (cf ID du message, qui a été copié dans
rx_buf_MIDG2[0])
{
case(10): // message ID = 10
{
//je veux que les angles d'Euler
for(y=0; y<3; y++)
{
data[y] =
(int16_t)((rx_buf_MIDG2[y+y+6] << 8)|(rx_buf_MIDG2[y+y+7]>>0));//les gyros:
X,Y et Z Axis Angular Rate
// +6: parce qu'on a enregistré
dans le buffer l'ID (1 byte), le count (1 byte), le timestamp (4 bytes)
// à chaque fois une valeur
intéressante est codée sur 2 octets consécutifs (cf doc midg2)
191
// +6 et +7 et << : processus
d'assemblage de deux octets en un seul octet double
data[y+3] =
(int16_t)((rx_buf_MIDG2[y+y+18] << 8)|(rx_buf_MIDG2[y+y+19]>>0));//les
angles : Yaw, Pitch, Roll
//+18 parce qu'on a enregistré
dans le buffer l'ID (1 byte), le count (1 byte), le timestamp (4 bytes),
les 3 gyros (6 bytes) et les 3 acceleros (6 bytes) (1+1+4+6+6=18)
// Remarque: est-il nécessaire de
mettre dans le buffer toutes ces données qui ne servent pas, possibilité de
gagner du temps?
//+18 et +19 car à chaque fois une
valeur intéressante est codée sur 2 octets consécutifs
}
INS=(rx_buf_MIDG2[40]); //cf doc midg2,
le 38ème octet du payload
data[AZ] = (int16_t)((rx_buf_MIDG2[16]
<< 8)|(rx_buf_MIDG2[17]>>0));//rajout az, Z Axis Acceleration
//protocole d'envoi des données

//message 10 de la midg2 envoyé à 50Hz.
On envoie une fois sur deux pour avoir une fréquence de 25Hz car le
baudrate 'on air' est assez faible (d'où le envoi=!envoi)
LEDon;
LED1on;
imu=1;//important: imu=1 toutes les
20ms
envoi=!envoi;
if (envoi)
{
put_uint8_t(0xFA);
put_uint8_t(0xFF);
put_uint8_t(moteur1);
put_uint16_t(data[MX]);//roll
put_uint16_t(data[MY]);//pitch
put_uint16_t(data[MZ]);//yaw
put_uint16_t(data[VX]);//VX
put_uint16_t(data[VY]);//VY
put_uint16_t(data[VZ]);//VZ
// put_uint16_t(gsonar);//altitude
put_uint16_t(zf);//altitude
put_uint8_t(INS);//INS
Vbat = (ADCH << 6)|(ADCL>>2);
put_uint8_t(Vbat);//batterie
// put_uint16_t(data[AZ]);//VZ
put_uint16_t(gsonar);//VZ
put_uint8_t(moteur1+moteur2+moteur3+moteur4+(data[MX]>>8)+data[MX]
+(data[MY]>>8)+data[MY]+(data[MZ]>>8)+data[MZ]+(data[VX]>>8)
+data[VX]+(data[VY]>>8)+data[VY]+(data[VZ]>>8)+data[VZ]
+(gsonar>>8)+gsonar+INS
// +(gsonar>>8)+gsonar+Vbat);
+(zf>>8)+zf+Vbat);
}
break;
}
{
for (y=0;y<3;y++)
192
{
data[y] =
(int16_t)((rx_buf_MIDG2[y+y+6] << 8)|(rx_buf_MIDG2[y+y+7]>>0));//je ne
prends que les gyros (X,Y et Z Axis Angular Rate)
}
data[AZ] = (int16_t)((rx_buf_MIDG2[16]
<< 8)|(rx_buf_MIDG2[17]>>0));//rajout az, Z Axis Acceleration
break;
}
{
for (y=0;y<3;y++)
{
data[y+6]=(((uint32_t)
rx_buf_MIDG2[4*y+18]) << 24)
|(((uint32_t)
rx_buf_MIDG2[4*y+19])<< 16)
|(((uint32_t)
rx_buf_MIDG2[4*y+20]) << 8)
|(rx_buf_MIDG2[4*y+21]);
//on place les vitesses (X,Y,Z
Axis velocity) dans data aux positions 6,7,8
//les vitesses sont codées sur
quatre bytes, on les regroupe sur un byte quadruple
data[y+10]=(((uint32_t)
rx_buf_MIDG2[4*y+6]) << 24)
|(((uint32_t)
rx_buf_MIDG2[4*y+7])<< 16)
|(((uint32_t) rx_buf_MIDG2[4*y+8])
<< 8)
//on place les positions (X,Y,Z
Axis Position) dans data aux positions 10,11,12
//les positions sont codées sur
quatre bytes, on les regroupe sur un byte quadruple
}
break;
}
default: //message valide, mais autre que
2,10,12
{
//cbi( PORTE, LED_RED);
LEDoff;//inutile???
break;
}
}
}
else {LEDoff;} // si le message n'est pas valide, on ne
tient pas compte du message et on remet tout à zéro
bytecounter_MIDG2=0;CHECKSUM0_MIDG2=0;CHECKSUM1_MIDG2=0;
return;
}
rx_buf_MIDG2[bytecounter_MIDG2-3]=c; //écriture du byte qui est

arrivé dans rx_buf_MIDG2, à la suite des octets précédants. rx_buf_MIDG2 ne
contient pas les 2 bytes de header (d'où le -3)
//le checksum est la somme des bytes du message (sans les 2 bytes du
header et les 2 des checksum)
if (bytecounter_MIDG2==(rx_buf_MIDG2[1]+5)) return; //il s'agit du
cas où le checksum 0 est arrivé. Return pour ne pas faire les deux lignes
suivantes.
//rx_buf_MIDG2[1]+5 = count + 5 (2 headers + ID + count + checksum 0)
193
// calcul des cheksums qui pourront ensuite (plus haut dans le

programme!!!) nous permettre de vérifier la validité du message provenant
de la midg2
CHECKSUM0_MIDG2 +=c;
CHECKSUM1_MIDG2 +=CHECKSUM0_MIDG2;
}
194
10.2. Annexe 2 : Code 1 : lancer des ranging dès que possible

pour chaque capteur individuellement.
{
switch (I2cState)
{
case 0: // ranging
//putc(TW_STATUS);
//putc(I2cState);
{
break;
I2cState = 0;
break;
}
break ;
case 1:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
case 2:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0x51; // Pour que le capteur nous retourne la valeur
mesurée en centimètres
break;
I2cState = 0;
break;
}
break ;
case 3:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
195
{
break;
I2cState = 3;
break;
}
if (premier_cycle_I2c != nombre_capteurs_us - 1)
{
I2cState = -1;
}
k ++;
{
}
break ;
case 4:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
break ;
case 5:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
TWDR = 2;
break;
I2cState = 3; // SRF10_k non pret. va essayer SRF10_k+1
k ++;
{
k = 0; //Retour au premier capteur quand on a fini le
dernier
}
break;
}
break ;
case 6:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
196

break;
I2cState = 3;
break;
}
break ;
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
TWDR = adresse_capteur_us[k] | TW_READ;
break;
I2cState = 7;
break;
}
break ;
case 8:
//putc(TW_STATUS);
//putc(I2cState);
break ;
case 9:
//Read high Byte
//putc(TW_STATUS);
//putc(I2cState);
sonar = TWDR;
if (sonar==0xFF) {LED2on;} else LED2off;

pour dernier octet
break ;
case 10:
//Read low Byte
//putc(I2cState);
//putc(TW_STATUS);
I2cState= -1 ;
break ;
}
I2cState++;
return;
}
197
10.3. Annexe 3 : Code 2 : ranging de tous les capteurs en même

temps
{
switch (I2cState)
{
case 0: // ranging
//putc(TW_STATUS);
//putc(I2cState);
{
break;
I2cState = 0;
break;
}
break ;
case 1:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
case 2:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
case 3:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
198
{
break;
I2cState = 3;
break;
}
I2cState = -1;
k ++;
{
I2cState = 3; //On passe à la phase de lecture des mesures
uniquement lorsque l'on a lancé le ranging des k capteurs
}
break ;

case 4:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
break ;
case 5:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
TWDR = 2;
break;
break;
}
break ;
case 6:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
199
break ;
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 7;
break;
}
break ;
case 8:
//putc(TW_STATUS);
//putc(I2cState);
break ;
case 9:
//Read high Byte
//putc(TW_STATUS);
//putc(I2cState);
sonar = TWDR;
pour dernier octet
break ;
case 10:
//Read low Byte
//putc(I2cState);
//putc(TW_STATUS);
//I2cState= -1 ;
I2cState= 3 ;
k ++;
{
I2cState= -1 ; //On relance le ranging de tous les capteurs
quand on a récupéré les mesures des k capteurs
compteur_0 ++;
}
break ;
}
I2cState++;
return;
}
200
10.4. Annexe 4 : Code 3 : faire fonctionner les capteurs les uns

après les autres
{
switch (I2cState)
{
case 0: // ranging
//putc(TW_STATUS);
//putc(I2cState);
{
break;
I2cState = 0;
break;
}
break ;
case 1:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
case 2:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 0;
break;
}
break ;
case 3:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
201
{
break;
I2cState = 3;
break;
}
/* if (premier_cycle_I2c != nombre_capteurs_us - 1)
{
I2cState = -1;
}
*/
// k ++;
/* if (k == nombre_capteurs_us)
{
}
break ;
*/
case 4:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 3;
break;
}
break ;
case 5:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
TWDR = 2;
break;
break;
}
break ;
case 6:
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 3;
202

break;
}
break ;
//putc(TW_STATUS);
//putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 7;
break;
}
break ;
case 8:
//putc(TW_STATUS);
//putc(I2cState);
break ;
case 9:
//Read high Byte
//putc(TW_STATUS);
//putc(I2cState);
sonar = TWDR;
pour dernier octet
break ;
case 10:
//Read low Byte
//putc(I2cState);
//putc(TW_STATUS);
I2cState= -1 ;
k ++;
{
compteur_0 ++;
}
break ;
}
I2cState++;
return;
}
203
10.5. Annexe 5 : Code de changement de l’adresse d’un capteur
// CHANGEMENT D'ADRESSE D'UN CAPTEUR ULTRASON

// Il suffit de changer uniquement "ancienne adresse" et "nouvelle adresse"
dans le "define" ci-dessous pour que le programme remplace automatiquement
l'ancienne adresse par la nouvelle.
// Attention: Il faut pour changer l'adresse d'un capteur qu'il n'y ait
qu'un seul capteur de connecté.
// Si le programme est flashé dans le processeur, si
vous branchez un autre capteur de même adresse que le précédent, dès que
vous allez faire un reset, il va être également changé d'adresse.
// -> Reflasher un autre programme immédiatement
après avoir changé l'adresse d'un capteur pour ne pas avoir de mauvaises
surprises.
#include <avr/io.h>
#include <avr/delay.h>
#include <avr/signal.h>
#include <compat/twi.h>
volatile uint8_t I2cState;
#define ancienne_adresse 0xEC
#define nouvelle_adresse 0xE4
void i2cInit(void)
{
TWBR = 152;// SCL 50khz avec horloge 16Mhz
I2cState = 0;
TWCR = _BV(TWINT) | _BV(TWEN) | _BV(TWIE) | _BV(TWSTA); // start
transmission
}
{
switch (I2cState)
{
case 0: // ranging
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = ancienne_adresse | TW_WRITE;
break;
I2cState = -1;
break;
}
break ;
case 1:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0x00;
204
break;
I2cState = -1;
break;
}
break ;
case 2:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0xA0; // premier élément de la séquence
break;
I2cState = -1;
break;
}
break ;
case 3: // ranging
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 2;
break;
}
break ;
case 4:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0x00;
break;
I2cState = 2;
break;
}
break ;
case 5:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0xAA; // premier élément de la séquence
break;
I2cState = 2;
break;
}
205
break ;
case 6: // ranging
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 5;
break;
}
break ;
case 7:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0x00;
break;
I2cState = 5;
break;
}
break ;
case 8:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = 0xA5; // premier élément de la séquence
break;
I2cState = 5;
break;
}
break ;
case 9: // ranging
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
break;
I2cState = 8;
break;
}
break ;
case 10:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
206
{
TWDR = 0x00;
break;
I2cState = 8;
break;
}
break ;
case 11:
//putc(TW_STATUS);
putc(I2cState);
switch (TW_STATUS)
{
TWDR = nouvelle_adresse; // premier élément de la séquence
break;
I2cState = 8;
break;
}
break ;
}
I2cState++;
return;
}
void main()
{
PORTD = _BV(1) | _BV(0); //activation des résistances de pull-up sur les
ports D0 et D1
i2cInit();
sei(); //autorise toutes les interruptions
}
207
11. ANNEXES TRANSMISSION
11.1. Exemple de programme de test de communication

bidirectionnelle à travers un port UART
#include <avr/io.h>
#define TX_BUF_SIZE 23
#define RX_BUF_SIZE 23
volatile uint8_t tx_head;
volatile uint8_t tx_tail;
volatile uint8_t tx_buf[ TX_BUF_SIZE ];
volatile uint8_t data[ RX_BUF_SIZE];
volatile uint8_t bytecounter;
// Programme de test
// Lorsque l'UART1 a reçu 23 bits, l'ATMega renvoie le message sur l'UART1
void USART1_Transmission_Reception_Init(void)
{
UCSR1B |= _BV(TXEN) | _BV(RXCIE) | _BV(RXEN);
UBRR1L = 103;
}
void putc(uint8_t c)
{
uint8_t tmp_head;
tmp_head = tx_head + 1;
if( tmp_head >= TX_BUF_SIZE )
tmp_head = 0;
if( tmp_head == tx_tail )
return;
tx_buf[ tx_head = tmp_head ] = c;
UCSR1B |= _BV(UDRIE1); //autorise l'interruption SIG_UART1_DATA
}
SIGNAL( SIG_UART1_DATA ) //s'active quand le buffer UDR1 est vide
{
uint8_t tmp_tail;
if( tx_head == tx_tail )
{
UCSR1B &= ~_BV(UDRIE1); //désactive l'interruption
SIG_UART1_DATA (message envoyé)
return;
}
tmp_tail = tx_tail + 1;
if( tmp_tail >= TX_BUF_SIZE )
tmp_tail = 0;
tx_tail = tmp_tail;
UDR1 = tx_buf[tmp_tail];
}
SIGNAL( SIG_UART1_RECV ) //s'active quand un octet du message descendant

arrive sur l'uart1
{
volatile uint8_t rx_buf[ RX_BUF_SIZE + RX_BUF_SIZE];
volatile char c = UDR1; //copie le byte du message
qui est arriv
208
bytecounter++; //un octet est arrivé

data[bytecounter-1]=c;
}
void main(void)
{
volatile uint8_t k;
USART1_Transmission_Reception_Init();
DDRB=0xFF ; //leds en sortie
while(1)
{
if (bytecounter==23)
{for (k=1; k<24; k++)
{
putc(data[k-1]);
}
PORTB=0x55;
bytecounter=0;
}
}
}
209
11.2. Programme de l’ATMega au sol – Transfert des données

descendantes et affichage de l’INS
#include <avr/io.h>
#define taille 29
volatile uint8_t data[ RX_BUF_SIZE ];
volatile uint8_t CHECKSUM, bytecounter;
// Programme partiel de l'ATMega au sol : Liaison descendante.
// Transfert du message provenant du quadri [ 250 255 x x x x CHECKSUM ] de

'taille' octets de l'UART0 sur l'UART1. On affiche le 21ème octet sur les
LED (INS).
// Si INS=1 alors une LED allumée sur deux, si INS=0 alors toutes les LED
allumées.
void USART0_Reception_Init(void)
{
UCSR0B |= _BV(RXCIE) | _BV(RXEN);
UBRR0L = 103;
}
void USART1_Transmission_Init(void)
{
UCSR1B |= _BV(TXEN);
UBRR1L = 103;
}
{
uint8_t tmp_head;
tmp_head = 0;
return;
}
{
uint8_t tmp_tail;
{
return;
}
tmp_tail = 0;
tx_tail = tmp_tail;
}
210
SIGNAL( SIG_UART0_RECV ) //s'active quand un octet du message descendant

arrive sur l'uart0
{
volatile char c = UDR0;
uint8_t y;
bytecounter++;
CHECKSUM +=c;
data[bytecounter-1]= c;
if (bytecounter==1)
{
if(c!=250) //premier header
{
bytecounter=0;CHECKSUM=0;
}
}
if (bytecounter==2)
{
if(c!=255) //second header
{
bytecounter=0;CHECKSUM=0;
}
CHECKSUM=0;
}
if (bytecounter==(taille)) //on est à la fin quand on a 'taille'
octets
{
if ((CHECKSUM-c)==data[taille-1])
{
if (data[20]>127) //INS est sur le bit 7 du 21ème octet.
Si il est égal à 1 alors data[20]>=128
{
PORTB=0b01010101;
}
else
{
PORTB=0b00000000;
}
for(y=0; y<taille; y++)
{
putc(data[y]);
}
}
bytecounter=0; CHECKSUM=0;
}
}
void main(void)
{
USART0_Reception_Init();
USART1_Transmission_Init();
while(1)
{
}
}
211
11.3. Programme de décodage de la trame PPM de la

radiocommande
#include <avr/io.h>

#define PPM_MAX_PULSES 5
#define CLOCK 16
volatile int32_t data[ RX_BUF_SIZE];
volatile uint16_t ppm_pulses[ PPM_MAX_PULSES ];
volatile uint8_t ppm_valid;
// Programme de test
// Decodage des trames ppm, envoi des données sur l'UART1
void USART1_Transmission_Init(void)
{
UCSR1B |= _BV(TXEN);
UBRR1L = 103;
}
{
uint8_t tmp_head;
tmp_head = 0;
return;
}
void put_uint8_t(uint8_t i)
{
putc(i);
}
void put_uint16_t(uint16_t i)
{
put_uint8_t( (i >> 8) & 0xFF );
put_uint8_t( (i >> 0) & 0xFF );
}

{
uint8_t tmp_tail;
{
return;
}
212
tmp_tail = 0;
tx_tail = tmp_tail;
}
SIGNAL( SIG_INPUT_CAPTURE3 ) // PPM decoding

{
volatile uint16_t this;
static uint16_t last;
static uint8_t state;
uint16_t width;
uint8_t y;
uint8_t CHECKSUM;
this = ICR3;
width = this - last;
last = this;
/* La période d'une trame est d'environ 20ms.

Une pulsation dure de 1.05ms à 2.150ms.
Le temps de sychronisation est d'au moins 7ms (temps minimum entre 2
trames)
*/
if( width > 800ul * CLOCK ) // temps de synchronisation détecté
{
state = 1;
return;
}
if( width < 70ul * CLOCK || width > 270ul * CLOCK || state==0 )
// il s'agit d'un bruit ou d'une pulsation valide qui arrive avant le
temps de synchronisation
{
state=0;
return;
}
//now read pulse sequence

ppm_pulses[ state++ - 1 ] = width; //incrémente state après avoir
rempli la liste ppm_pulses
if( state == PPM_MAX_PULSES+1 ) // frame completed

{
putc(250);
putc(255);
for(y=0; y<PPM_MAX_PULSES-1; y++)
{
CHECKSUM+=((ppm_pulses[y]>>8)+ppm_pulses[y]);
put_uint16_t(ppm_pulses[y]);
}
putc(CHECKSUM);
ppm_valid = 1;
TCNT3 = 0;
last = 0;
state = 0;
CHECKSUM = 0;
}
213
void main(void)
{
//PPM init (TC3)
ppm_valid=0;
// TCCR3A = 0 (default)
// Normal port operation
// WGM33:0=0 (TC3 normal mode of operation)
TCCR3B = _BV(ICNC3) | _BV(ICES3) | _BV(CS31);
// Input Capture Noise Canceler: enabled
// Input Capture Edge Select: rising
// CS = b010: prescaler/8
ETIMSK |= _BV(TICIE3) | _BV(TOIE3);
USART1_Transmission_Init();
while(1)
{
PORTB=0x55;
}
214
12. ANNEXES STRUCTURE
Méthode d’adaptation des hélices
Les hélices telles qu’elles nous arrivent de chez le vendeur Todd’s Models ne se fixent pas
sur le moteur. Le filet du moteur est trop grand pour le trou de l’hélice et le moyeu de
l’hélice ne permet pas de serre l’écrou sur le filet. Nous devons donc limer et repercer les
hélices. Nous avons mis au point une méthode pour les usiner sur la fraiseuse de l’atelier
du LEE. Il est essentiel de suivre la méthode point par point pour effectuer avec succès la
modification :
• Placer les cales en bois dans l’étau de part et d’autre

d’une cale étalon en métal sur lequel est placé
l’adaptateur qui accueillera l’hélice. S’assurer que tout soit
bien horizontal.
• Insérer l’hélice dans le montage, base vers le haut

(« face avant » de l’hélice vers le bas). Serrer
modérément (assez pour caler l’hélice sans la
déformer). Utiliser une tige de 3mm de diamètre
(mèche par exemple) pour centrer l’hélice et le
centre (l’axe) de la tête de la fraiseuse. Remarque :
si vous ne déplacez l’hélice que latéralement
(« gauche ou droite »), vous ne devrez plus réaligner
l’hélice dans l’axe de la profondeur (« avant
arrière »).
• Utiliser une fraise de 8mm de diamètre et percez un trou de
4,0mm de profondeur.
• Retourner l’hélice et recentrer la avec la tige de 3mm (face
avant vers le haut).
• Percez l’hélice jusqu’au bout avec une mèche de 6mm.
Attention à ne pas percer les pièces qui maintiennent
l’hélice.
• Utiliser une fraise (de 6 à 10mm) pour retirer 2 à 2,5mm
d’épaisseur sur la face supérieure du moyeu de l’hélice.
215
13. ANNEXES IHM
13.1. Code de la station sol en Visual Basic 6.0
13.1.1. Explications préliminaires
À la fin de l’année précédente le groupe du quadricoptère 2004/2005 a programmé la

première version du code de la station sol. A ce moment-là, ils ont choisi de le
programmer en Visual Basic 6.0, parce qu’il y avait un membre du groupe qui connaissait
déjà Visual Basic. Comme c’était juste avant le concours de l’ONERA, ils n’avaient plus le
temps d’écrire une documentation détaillée. Malheureusement, ceci nous a compliqué le
travail au début de l’année parce qu’il était difficile de comprendre toutes les détails du
code tout de suite. Pour capitaliser le travail du groupe de l’année précédente et le notre,
on présentera d’abord le code à l’état du début de l’année, et après les compléments que
nous avons ajoutés.
Au début nous avons essayé de convertir le code en MS Visual Basic 2005, mais on a
rencontré plusieurs problèmes qui étaient dus à des changements du mode « run-time ».
Certains éléments ne pouvaient plus être utilisés en run-time. C’est la raison pour
laquelle nous avons alors travaillé en Visual Basic 6.0.
Comme nous n’avions pas encore travaillé en Visual Basic avant, en particulier avec des
GUIs (Graphical User Interface), nous avons d’abord suivi quelques tutoriaux. Pour
apprendre les bases de la programmation d’un GUI, on conseille de regarder le film
« BEGIN01_04 - Creating a User Interface.wmv » qui est accessible par le portail du
projet.
13.1.2. Explication détaillée du code de l’année 2005
Le code est reparti en trois éléments :
• La description graphique de l’interface qui est sauvegardée dans la forme du

fichier recep.frm
• Le corps du code, c’est-à-dire les boucles qui font tourner le programme, qui est
sauvegarder dans la partie « code » du fichier recep.frm
• La définition des variables dans le fichier Module1.bas
Dans la forme on définit l’interface graphiquement. Comme ceci fonctionne intuitivement

de la manière « drag-and-drop » et comme les différents éléments sont bien expliqués
dans le rapport 2005, on présentera ici les éléments moins évidents et en particulier le
code derrière la visualisation.
Dans la forme en bas à droite il y a un élément « MSComm » qui est utilisé pour établir
la liaison sérielle avec le modem pour recevoir les données envoyées par le drone. Cet
élément est aussi représenté graphiquement dans la forme, parce que comme ça il sera
initialisé chaque fois que la forme est créée. On va encore détailler les propriétés de cet
élément dans les explications du corps du code.
216
13.1.3. Les fonctions Form_Load et Form_Unload
Le corps du code commence avec la sub-fonction Form_Load() qui est appelée chaque
fois que la forme graphique est créée, c'est-à-dire directement après le lancement du
programme. Dans cette fonction on initialise tous les éléments, les variables et la liaison
sérielle. Le plus important dans cette partie est la liaison sérielle qui est initialisée au
début. Le code pour ça est le suivant :
With MSComm1
.CommPort = 6 'on utilise le port COM6
.Handshaking = 2
.RThreshold = 1
.RTSEnable = True
.Settings = "9600,n,8,1"
.SThreshold = 1
.PortOpen = True
.InputMode = 1
End With
Bytecounter = 0
Checksum = 0
217
En utilisant la commande with MSComm1 on n’est plus obligé de répéter le préfixe

MSComm1. De cette manière Visual Basic sait que les lignes suivantes définissent les
propriétés de MSComm1. Ces propriétés sont les suivantes :
.CommPort = 6 On choisit le numéro du port sériel.
.Handshaking = 2 Définition d’une propriété du protocole utilisé pour

la transmission.
.RThreshold = 1 et Définit le nombre des caractères à recevoir pour

.SThreshold = 1 que l’élément déclenche.
.RTSEnable = True Définit si on veut utiliser la ligne RTS (Request to
send) pour la transmission.
.Settings = "9600,n,8,1" Fixe les caractéristiques de la connexion, à savoir

la vitesse de communication, l’utilisation ou non
du bit de parité, le nombre de bits de données et
le nombre de bits d’arrêt. On utilise le réglage
standard.
.PortOpen = True Permet d’ouvrir le port si on la positionne à TRUE
et de le fermer si on le positionne à FALSE.
.InputMode = 1 Changer entre le mode binaire et le mode text de

la transmission.
Dans le reste de cette première fonction on initialise juste toutes les variables qui sont
nécessaires dans la suite.
Comme on a ouvert le port sériel lors de l’initialisation, il le faut aussi fermer en

terminant le programme. Ceci est fait dans la sub-fonction suivante Form_Unload(Cancel
As Integer).
13.1.4. La fonction MSComm1_OnComm
Après les fonctions pour la réception des données et leurs traitements viennent. Chaque
fois que l’événement OnComm de l’élément MSComm déclenche, c’est-à-dire quand il a reçu
un certain nombre de caractères, la sub-fonction MSComm1_OnComm() est appelée. Dedans
les données reçues et stockées dans le buffer de l’élément MSComm sont copiées dans la
variable Tampon de type non précisé (Dim Tampon As Variant). Pour pouvoir facilement
vérifier que des informations sont reçues on les visualise sans traitement dans la case
text1 du GUI.
13.1.5. La fonction Traitement
Dans la suite, on appelle la fonction Traitement(Tampon As Variant) pour traiter les

messages reçus. Dans cette fonction on veut d’abord trouver les paquets individuels et
après vérifier que les messages sont bien transmis sans perte des informations. Chaque
paquet commence avec le header qui dans notre cas consiste de deux bytes qui valent
250 respectivement 255 (FA respectivement FF en hexadécimal). On scan alors le
message dans la variable tampon pour trouver une suite de ces deux bytes. Si on la
trouve on copie les 22 bytes suivants, qui contiennent les informations utiles, dans la
variable message. Le vingt-cinquième byte contient la checksum qui est la somme sur
tous les bytes d’un paquet. Ceci vérifie que toutes les informations ont été bien
transmises. Si la checksum est la bonne on augmente le counter qui enregistre le
nombre de paquets reçus et l’on appelle la fonction Traitementdonnees(Message As
Variant) pour visualiser les données.
218
Comme les données sont transmises comme une suite de chiffres de zéro à 256, il faut
les encore interpréter. Ceci veut dire que l’on calcule les grandeurs qui ont été
transmises en deux bytes et celles qui peuvent atteindre des valeurs négatives. Par
exemple, l’altitude est stockée sur les bytes 16 et 17 du message. Le byte numéro 16 est
appelé le « most significant byte », le byte numéro 17 le « least significant byte ». La
valeur de l’altitude est alors calculer de la façon suivante :
Alti = 256 * Message(16) + Message(17)
Par contre la vitesse en direction x, par exemple, peut aussi atteindre des valeurs
négatives. Ses valeurs sont alors stockées de la façon suivante :
256 -1 65536 -1
- -
-127 -32767
128 32768
+ +
0 0 0 0
unsigne signed unsigne signed

8 bit 16 bit
Ce pour ça qu’il faut utiliser un calcul peu clair :
If (256 * Message(10) + Message(11)) > 32767 Then

vx = -(65536 - (256 * Message(10) + Message(11))) / 100
Else
vx = (256 * Message(10) + Message(11)) / 100
End If
Une fois qu’on a interprété le message et qu’on a stocké les informations dans les
variables correspondantes il faut juste attribuer ces variables aux éléments du GUI.
Comme ce sont des calculs plutôt mathématiques et faciles on ne va pas détailler chaque
attribution.
13.1.6. Explication des compléments de cette année
Dans la version 1.01 nous avons intégré la possibilité de sauvegarder toutes les données
transmises dans un fichier « .txt ». Ceci a été fait en particulier pour trouver la cause de
la disjonction que nous ne pouvions toujours pas expliquer. Mais on peut bien sûr
l’utiliser aussi pour d’autres fins comme par exemple pour récupérer des positions
comme dans la version 1.02.
Pour sauvegarder les données il faut d’abord créer un fichier .txt. Pour ceci on récupère
un numéro de fichier libre par la commande freefile et on assemble le nom du fichier
pour que l’on n’écrase pas les fichiers créés précédemment. Enfin on ouvre le fichier par
la commande open.
219
file_nr = FreeFile
file_name = "data " & Format(Date, "dd-mm-yy") & " " & Hour(Time) & "h" &
Minute(Time) & ".txt"
Open file_name For Output As #file_nr
Les données sont alors ajoutées dans le fichier dans la fonction save_data en utilisant la
commande print (#file_nr, valeur).
Dans la version 1.02 « GPS coordinates added » on a ajouté les coordonnées x et y sur
deux fois deux bytes. Elles sont traitées comme toutes les autres données et sont enfin
affichées dans deux nouvelles cases sur le GUI. Dans la version 1.03 « Détection
obstacle » ces quatre derniers bytes peuvent être utilisés pour observer des données
quelconques. Les quatre bytes sont affichés dans quatre cases sur le GUI. Dans cette
version nous avons par exemple observé les informations des capteurs de détection
obstacle pour vérifier leurs fonctionnements.
13.2. Code de la station sol en Matlab
Généralement le code en Matlab a la même structure qu’en Visual Basic. Les différences
sont l’intégration du flux vidéo, la visualisation de quelques grandeurs en utilisant des
graphes et la répartition des fonctions en différents fichiers.
13.2.1. Le GUI
Pendant le concours de la DGA, il était impossible d’observer toutes les données en

même temps et de bien piloter ou naviguer le drone.
Lors de nos tests de vol avec le quadricoptère, nous avons constaté que l’écran de
l’interface VisualBasic est trop chargé et qu’il est impossible de contrôler toutes les
données. En plus, il y avait des données qui donnaient plus de sens si on les considérait
en évolution du temps.
C’est la raison pour laquelle nous avons décidé de changer l’interface graphique pour
supprimer les données moins utiles et pour agrandir la vue sur l’image.
En tapant « guide » dans le « command window », on ouvre une interface où on peut

manipuler le GUI d’une façon graphique. Dans le « Property Inspector », on peut
configurer les éléments mis sur le GUI. Une autre manière d’initialiser l’état initial d’un
élément GUI est d’ajouter du code source dans la fonction « CreateFcn » qui est générée
automatiquement dans le fichier *.m.
Dans la première version de l’interface graphique sous Matlab, nous avons fait les
changements principaux suivants (ce qui ne dit pas qu’il peut y avoir des changements
lors des futures versions) :
• L’altitude est affichée de manière numérique et en évolution du temps dans un

graphe. Comme ça il est possible de retracer l’altitude du quadricoptère pendant
le vol et en même temps, un regard rapide permet de voir la valeur exacte de
l’altitude.
• Les états des moteurs sont aussi affichés par rapport au temps. Ceci permet de
surveiller le régime dans lequel fonctionne chaque moteur et ceci est d’une
importance primordiale pour le pilote. Pour éviter qu’un moteur ne tourne pas à
plus de 98% de son maximum, nous avons décidé d’afficher ces grandeurs en
fonction du temps.
• Les coordonnées GPS suivant les positions x et y sont affichées pour savoir où se
trouve le drone à chaque instant. Une image du terrain est affichée pour une
future version éventuelle où il sera possible de retracer le chemin ou la position
du quadricoptère sur le terrain.
220
• L’horizon artificiel est incrusté au milieu de l’image ce qui a pour l’avantage de

regarder et observer l’image et l’horizon en même temps. (pas encore fait…)
• Les angles et les grandeurs de vitesses ne sont pas affichés. Lors de tests, nous
avons constaté que ces grandeurs étaient moins utiles. Nous avons plutôt utilisé
le vecteur de vitesse et l’horizon artificiel pour observer l’inclinaison et les
directions de vitesse du drone. Donc, les valeurs numériques ne nous semblent à
priori pas intéressantes.
13.2.2. Le code derrière le GUI
Le fichier contenant la fonction principale correspondante au GUI s’appelle myguiv02.m.

Dans ce fichier il y existe beaucoup de fonctions qui sont créés automatiquement par
Matlab. Seulement quelques unes sont vraiment importantes pour notre programmation.
La première fonction function varargout = myguiv02(varargin), par exemple, définit
quelques propriétés du GUI et est automatiquement ajoutée par Matlab. En outre, la
plupart des fonctions type « callback » et « createfcn » ne contiennent pas du code.
C’est pour ça que l’on ne va pas traiter toutes les fonctions ici.
13.2.3. La fonction d’ouverture
La première fonction importante est la fonction function

myguiv02_OpeningFcn(hObject, eventdata, handles, varargin). Elle est appelée en
initialisant la fenêtre du GUI. hObject est le « handle », c’est-à-dire le pointeur, qui
désigne la fenêtre du GUI. eventdata et varargin sont des variables qui sont
automatiquement transmises mais que nous n’avons pas utilisées. handles est une
structure dans laquelle un pointeur pour chaque objet du GUI est enregistré. Elle est
alors nécessaire pour accéder ces objets, mais elle peut aussi être utilisé pour stocké des
données.
Dans cette fonction on vide d’abord la fenêtre des commandes. Après on définit deux
structures globales myvis et mydata, qui sont utilisées pour stocker les données
transmises. Pour accéder ces structures dans les sub-fonctions il faut juste les définir au
début de chaque sub-fonction.
Dans la suite le flux vidéo est intégré. Pour cela, on crée un « video input object » qui est
sauvegardé dans la structure handles. « winvideo » est le nom d’un « adoptor » qui
permet l’accès à l’« image acquisition device » connecté à l’ordinateur.
handles.vid = videoinput(‘winvideo’) ;
On affiche « video port created » dans le command window.

disp(‘video port created’)
On crée l’« image object » pour qu’on puisse afficher le « video preview data ». Après, on
calcule la taille de l’image et l’on ajuste les dimensions de la fenêtre de la vidéo.
vidRes = get(handles.vid, ‘VideoResolution’) ;

nBands = get(handles.vid, ‘NumberOfBands’) ;
hImage = image (zeros(vidRes(2), vidRes (1), nBands) ) ;
On affiche le « video data » dans le GUI.

preview (handles.vid, hImage) ;
Après le flux vidéo on initialise le port sériel. Comme en Visual Basic le port sériel est un
objet qu’il faut initialiser au début mais cette fois-ci on n’a pas d’élément prédéfini
comme l’élément MSComm en Visual Basic. C’est pour ça que l’on le sauvegarde dans la
221
structure handles. Voilà les commandes pour créer l’objet du port sériel et pour le
sauvegarder dans la structure handles:
s = serial('com6','Baudrate',115200,'InputBufferSize',128);
handles.s = s;
Comme en Visual Basic on définit alors ses propriétés :
s.BytesAvailableFcnMode = 'byte';
s.BytesAvailableFcnCount = mydata.N;
s.BytesAvailableFcn = {@serial_callback, handles};
La première commande fixe le mode de la liaison sérielle come ‘byte’ pour que
l’événement « BytesAvailable » déclenche après un certain nombre de bytes et pas après
un caractère déterminé. Le nombre de bytes qui sont nécessaires pour déclencher
l’événement est défini par la commande suivante. La troisième ligne fixe quelle fonction
va être appelée en cas de déclenchement et quelles variables supplémentaires sont
transmises. Pour finalement ouvrir le port on utilise la commande suivante :
fopen(s)
Maintenant que l’on a initialisé nos structures globales, le flux vidéo et le port sériel il
faut encore définir les éléments du GUI que l’on ne veut pas redéfinir à chaque itération.
C’est par exemple la ligne du vecteur de vitesse qui est créée par la commande
suivante :
line(myvis.vel_vect(:,1), myvis.vel_vect(:,2), 'Color', 'r', 'LineWidth',

2)
Ceci signifie que l’on crée une ligne du point P1 au point P2 en rouge avec une épaisseur
de 2. Les coordonnées des points sont stockées dans la matrice myvis.vel_vect.
Enfin il faut encore sauvegarder les changements de la structure handles. Ceci est fait
par la commande :
guidata(hObject, handles);
Par cette commande on sauvegarde la copie de la structure handles, que nous avons
modifiée, dans la structure handles associe au handle hObject de notre GUI.
13.2.4. La fonction de fermeture
A la fin, c’est-à-dire quand on ferme la fenêtre du GUI, il faut bien sûr refermer et
supprimer les liaisons que l’on a créées au début. Ceci est nécessaire pour que ces
liaisons soient libérées et puissent être réutilisées après. Pour cela on utilise les
commandes suivantes :
fclose(handles.s)
delete(handles.s)
delete(handles.vid)
13.2.5. La fonction serial_callback
Pour améliorer la clarté nous avons sauvegardé la fonction serial_callback dans un

fichier séparé. Elle est appelée par l’objet sériel s chaque fois que l’événement
« BytesAvailable » déclenche. Comme nous l’avons défini plus haut, cet événement
déclenche après la réception de mydata.N bytes. La fonction est appelée en passant
l’objet s qui a déclenché le callback (s), une variable event qui caractérise l’événement
et la structure handles que nous avons ajoutée pour pouvoir accéder aux objets du GUI.
222
D’abord on définit les variables. On utilise les structures globales myvis et mydata que
nous avons déjà définies dans la fonction d’ouverture. En plus on a besoin d’une variable
persistante frame pour stocker les bytes transmis. Par ailleurs on définit encore les trois
variables h1, h2 et N qui signifient les deux bytes de start et la longueur -1 du message.
Après on lit les bytes reçus et on les ajoute à la fin du vecteur frame en utilisant la
commande suivante :
frame = [frame, fread(s,s.BytesAvailable).'];
Maintenant on a obtenu une chaîne de bytes dans laquelle il faut trouver les paquets
transmis. Pour cela on cherche d’abord tous les bytes de la valeur h1. Après on vérifie
qu’ils sont suivis d’au moins N bytes et que les bytes directement après les h1 ont la
valeur h2. Alors on a trouvé tous les paquets complets et on stocke ces indices dans le
vecteur ind.
ind = find(frame==h1);
ind = ind(find(ind<=length(frame)-N));
ind = ind(find(frame(ind+1)==h2));
Bien sûr on veut maintenant traiter le paquet le plus récent. C’est pour ça que l’on
renverse le vecteur ind et on copie les bytes utiles du dernier paquet dans le vecteur
msg. Si la checksum (la somme sur les bytes 1 à N-1 du paquet modulo 256) est la bonne
on appelle les sub-fonctions data_processing et visualization et on sort de la boucle
par la commande break. Sinon on prend le paquet précédent et on répète les actions.
Une fois que l’on sort de la boucle on supprime encore les paquets inutiles dans le
vecteur frame.
13.2.6. La fonction data_processing
Cette fonction interprète la chaîne des bytes utiles comme nous l’avons fait en Visual
Basic et reconstruit les données transmises. Comme ce sont les mêmes calculs pour
générer la structure mydata qu’en Visual Basic on ne va pas répéter les explications et on
renvoie le lecteur au chapitre correspondant de la présentation du code en Visual Basic.
Par contre à la fin de cette fonction on actualise la structure myvis qui n’existe pas en
Visual Basic. On utilise cette structure pour visualiser les évolutions de quelques
grandeurs comme par exemple l’altitude ou la batterie. C’est pour ça qu’il faut
sauvegarder une suite des valeurs les plus récentes. Dans notre cas on a pris cent
dernières valeurs. Dans la fonction data_processing il faut alors actualiser la structure
myvis en virant pour chaque grandeur la plus vieille valeur et en ajoutant la nouvelle
valeur à la fin.
13.2.7. La fonction visualisation
Dans cette fonction on dessine juste les valeurs de la structure myvis dans les différents
graphes en utilisant la commande plot. En outre on écrit les valeurs que l’on veut voir
comme chiffres, comme par exemple la position ou l’altitude, dans les cases
correspondantes en utilisant la commande
set(handles.txt_alti, 'String', mydata.alti)
La construction du vecteur de vitesse est un peu plus compliquée. D’abord il faut calculer
les coordonnées du point P2 (le bout du vecteur partant de l’origine du graphe) en
utilisant les variables vx, vy et yaw. Après on récupère le handle de la ligne que nous
avons créée dans la fonction d’ouverture et on l’actualise :
vel_line = get(handles.VelocityVector, 'Children');

set(vel_line, 'XData', myvis.vel_vect(:,1), 'YData', myvis.vel_vect(:,2))
223
14. ANNEXES HIL
14.1. Planches et Code importants
14.1.1. PWM
#define moteur1 OCR0

#define moteur2 OCR1BL
#define moteur3 OCR1CL
#define moteur4 OCR1AL
TCCR0 = 0x71;
TCCR1A = 0xFD;
TCCR1B |= 0x01;
OCR1AH = 0;
OCR1BH = 0;
OCR1CH = 0;
DDRB = 0xFF;
PORTB = 0;
moteur1 = 127; //0,5
moteur2 = i;
moteur3 = 30; //0,12
moteur4 = 200; //0,79
testCTR05*.mdl donne des tests variés pour le fonctionnement des PWMs.

testCTR05_filtered*.mdl sont des essais pour remplacer des valeurs fausses par des
valeurs évaluées. On a séparé les deux compteurs (avec « look under mask ») mais
bizarrement le compteur n'as plus de sortie une fois on a enregistré la planche, fermé et
ouvert MATLAB et le bloc ne fonctionne plus.
224
cf fiches de séance 051129, 060131, 060411, 060509
14.1.2. RS232
pour recevoir des données
volatile uint8_t Donnees_Recues;

void USART0_Reception_Init(void)
{ UCSR0B |= _BV(RXCIE) | _BV(RXEN);
UBRR0L = 16; //baudrate}
{ Donnees_Recues = UDR0;}
void main()
225
{USART0_Reception_Init();
DDRB = 0xFF;
sei();
Donnees_Recues = 0x00;}
et pour envoyer des données
void USART0_Transmition_Init( unsigned int baud )
{ UBRR0H = (unsigned char)(baud>>8);
UBRR0L = (unsigned char)baud;
UCSR0B |= _BV(TXEN); //Enable transmitter }
{ uint8_t tmp_head;
if( tmp_head >= TX_BUF_SIZE ) tmp_head = 0;
if( tmp_head == tx_tail ) return;
UCSR0B |= _BV(UDRIE0); } //autorise SIG_UART0_DATA
SIGNAL( SIG_UART0_DATA ) //buffer UDR0 est vide
{ uint8_t tmp_tail;
{UCSR0B &= ~_BV(UDRIE0); //désactive SIG_UART0_DATA
return; }
if( tmp_tail >= TX_BUF_SIZE ) tmp_tail = 0;
tx_tail = tmp_tail;
UDR0 = tx_buf[tmp_tail]; }
{ Donnees_Recues = UDR0; }
void main()
{USART0_Transmition_Init(103);
sei();
int b[5]; b[0]=52; b[1]=100; b[2]=114; b[3]=105; b[4]=32;
int i;
while(1){
for(i=0;i<5;i++){
_delay_ms(200);
putc(b[i]); }
}
}
rs232.mdl, QSC100.mdl
Code C: tous les dossiers avec uart dans avr_exemples
226
14.1.3. MIDG II
On a utilisé le code du main.c actuel. On a juste désactivé la liaison via la station sol.
Les variables importantes sont :
c = UDR0; dernier octet arrivé par RS232
bytecounter_MIDG2++; initialisé à 0, incrémenté à chaque boucle en accord avec la
structure d’un message, remise à 0 en fin de message
SYNC 0 | SYNC 1 | ID | COUNT | …
1 |2 |3 |4 |…
rx_buf_MIDG2[bytecounter_MIDG2-3]=c; mettre ID à rx_buf_MIDG2[0] et ensuite
data[y+6]=
(((uint32_t) rx_buf_MIDG2[4*y+18]) << 24)
|(((uint32_t)rx_buf_MIDG2[4*y+19])<< 16)
|(((uint32_t) rx_buf_MIDG2[4*y+20]) << 8)
Pour y=0,1,2 (~X,Y,Z) on assemble 4 octets consécutifs, pour former un uint32 : une
mesure de MIDG2
pour simplifier l’accès aux variables de mesure on établit une correspondance (~index)
en ligne 130
le main.c prévoit l’utilisation des messages 2 comme 10 Æ problèmes si la MIDG2 envoie
les 2 messages : actualisation des G* et du AZ avec ceux des messages 2 puis 10
G* : 2, 10 ; AZ : 2, 10 ; P* : 12 ; M* : 10 ; V* : 12
imu est très important, car utilisé comme horloge pour les contrôleurs
tous les midg2neu*.mdl pour la simulation et midg2reel*.mdl pour le décodage
main.c dans le dossier MidgII
cf fiches de séance 051129..060124
227
14.2. Réalisation d'un contrôleur
On définit le système à contrôler par exemple :

A = [0 1 0; 0 0 1; 0 0 -1/.1]
B = [0;0;1/.1]
C = [1 0 0]
D=0
pour avoir le système complet :
sys=ss(A,B,C,D)
pour le transformer en transfert :
syst=zpk(sys)
ou on le définit directement en transfert
0.2
exemple : systr=tf([.2],[1 .2 0 0]) pour
s + 0.2 s 2
3
ensuite on utilise SISO Tools pour faire un contrôleur : sisotool(sys)

on peut aussi mettre syst ou systr au lieu de sys
on met des zéros et des pôles et on définit une fonction de transfert à partir de l’équation
donnée par SISO Tools
exemple : contr=tf(3.*[.68 1],[.05 1])
on le discrétise : contrd=c2d(contr,20e-3,'foh')
ici avec 20e-3 comme « sampling time »
Ca donne p.ex.
34.15 z - 33.17
---------------
z - 0.6703
34.15 z − 33.17
e est la différence à la référence, u le sortie : u = e
z − 0.6703
u = 0.6703uz −1 + 34.15e − 33.17ez −1
une multiplication avec z-1 correspond à un décalage temporel de « sampling time » vers
le passé, du coup on programme en C :
u = .6703*u_old + 34.15*e - 33.17*e_old;
e_old=e;
u_old=u;
et on fait répéter cela tous les « sampling time »
228
14.3. Commandes MATLAB pour RS232
s1=serial('COM1','baudrate',57600);
definir le port série COM1 avec baudrate=57600
fopen(s1)
ouvrir port défini par s1
buf=fread(s1,512)
lire 512*1 octet du port dans le vecteur « buf » [1x512], attention ses valeurs sont lues
d’un buffer (de taille 512) qu’il faut d’abord vider pour avoir des valeurs actuelles (par
exemple on lit des valeurs à t=5, on attend jusqu’à t=50, on lit les valeurs à t=50 et on
obtient les valeurs de t=5, pour avoir les valeurs de t=50 il faut lire très rapidement une
deuxième fois à t=50), répéter
fwrite(s1,92)
émettre le nombre 92 sur le port, répéter
fclose(s1)
fermer le port
14.4. Ranges de la télécommande
Si les réglages correspondants sont au milieu les

manettes ont des valeurs :
MX = vx = pitch = ppm_pulses[1] :
ca. 2960±840, min en bas
MY = vy = roll = ppm_pulses[0] :
ca. 3042±820, min à droite
MX MZ
RX RZ
MZ = z = gaz = ppm_pulses[2] :
ca. 3040±690, min en bas
MY MP
MP = psi' = yaw = ppm_pulses[3] :
RY ca. 3020±840, min à gauche
RP
Les régalages permettent des décalages de :

RX : ca. ±232, min en bas
RY : ca. ±236, min à droite
RZ : ca. ±203, min en bas
RP : ca. ±228, min à gauche
229
14.5. Si ça ne fonctionne pas
14.5.1. Versions de MATLAB
Pour tout notre travail on a utilisé MATLAB R14SP2 (7.0.4). Il y a un petit problème avec
xPC Target (on ne peut même pas ouvrir xPC Target Explorer) qui est facilement résolu
avec un patch (http://www.mathworks.com/support/solutions/data/1-13B6EL.html).
Comme compilateur on a utilisé Microsoft Visual C v7.1 (Microsoft Visual Studio .NET
2003 disponible chez VIA, .NET 2005 ne marche pas).
On a essayé R14SP3 qui ne permet pas de faire un « build » pour le xPC Target avec le
modèle d’Erwan.
R2006a permet d’utiliser le compilateur Open Watcom (uniquement la version indiquée
dans la documentation de xPC Target) au lieu de Visual C. Ce compilateur est Open
Source est prend beaucoup moins d’espace sur le disque dur. Si on utilise la carte
QSC100 le « build » prend énormément de temps avec Visual C, mais est rapide avec
Open Watcom. En revanche le port série de la carte mère ne semble pas fonctionner avec
Open Watcom : on ne mesure rien à l’oscilloscope. Le comportement de la simulation
avec xPC Target a changé en comparaison avec R14SP2 : une fois connecté avec le
Target PC, si on utilise le bouton « stop », puis qu’on change ensuite quelques valeurs
des constantes et enfin qu’on clique sur le bouton « start » le Target PC utilise les
anciennes valeurs, celles qu’il avait juste avant le « stop ». R14SP2 réinitialise les
simulations avec les valeurs changées « hors connexion ». Il faut donc un peut de
débogage pour faire marcher notre travail avec une autre version de MATLAB.
Pour la visualisation on a dû utiliser R2006a car les blocs d’Aerospace Blockset, qu’on
souhaitait utiliser, ont été introduits après R14SP2.
14.5.2. Backward Propagation
Si on essaie de faire un « build » d’une planche avec un block « pack » on a des fois
l’erreur « backward propagation not supported » pour le block « pack ». Un « demux » et
un « mux » constituent une solution que nous avons trouvée par hasard (subsytem
« anti bprop »). On a demandé à Mathworks qui nous ont donnés les détails :
230
'Simulink:
Necessity to use a Demux/Mux before a Pack Block'
Reproduction steps: - First Test : Run the simulation with the anti-bprop block
- Second Test : Run the simulation without the anti-bprop block
Whats wrong: - First test : it runs
Second Test : it does not run
Réponse:
The source of the issue is the final MUX block of your model and its input port
specifications. The final MUX block has input parameter [4 , 1], which implies that it
expects vector-type signals of length 1x4 and 1x1.
Your workaround of the issue using a MUX and DEMUX block with input/output port
parameters [1,1] creates two 1x1 vector signals which are then combined back into a
1x2 signal of 1x1 vector signals. Therefore there is no datatype mismatch at the final
MUX.
However, without the MUX and DEMUX blocks in place, the input to the GAIN block is 4
scalar signals combined and thus gives a scalar signal output which rather than a 1x1
vector signal.
Because there is a UDP byte-packing block in place, it cannot back-propagate the signal
type. The UDP PACK block is completely dependent on the input and thus cannot force or
back-propagate the datatype of the input to match what is expected of its output.
Another workaround of this issue is to omit the 'anti-bprop' subsystem and change the
Number of Inputs parameter of the last MUX block to 2 instead of [4 1]. This will create 2
input ports expecting 2 scalar signals of any size. Therefore, the 1x4 vector of scalar
signals and a scalar signal are acceptable.
14.5.3. Variables externes
Beaucoup de nos planches Simulink utilisent des constantes qui sont fixées dans des
fichiers externes. checksum1.m est nécessaire pour notre implémentation du protocole
de la MIDG II (et aussi quelques autres planches utilisent « trun »), simu_erwan.m pour
le modèle du Quadri (les autres .m sont lancés automatiquement avec). Un double-clic
les ouvre et il faut ensuite cliquer sur le bouton « run ».
14.5.4. TCP/IP erreur
Si le Target PC plante MATLAB indique souvent une erreur TCP/IP. Un reboot du Target
PC est nécessaire. Si on a d’autres problèmes bizarres, un reboot du Target PC est
parfois une solution.
14.5.5. Rebuild
Il arrive qu’on obtienne un message d’erreur bizarre lors d’un « build ». Il vaut toujours
mieux essayer à nouveau le « build ». En cas de problèmes inexplicables (p.ex. instabilité
de la simulation) on peut essayer de nettoyer le « working directory » de tous les
vestiges d’un ancien « build » (c’est à dire effacer les dossiers « slprj » et
« NomDuFichier_xpc_rtw », et effacer les documents « NomDuFichier.dlm »,
« NomDuFichier.xml », « NomDuFichierbio.m » et « NomDuFichierpt.m »).
14.5.6. xPC Target Scopes
Ne fonctionnent pas s’ils sont directement connectés à des constantes, il faut mettre par
exemple un gain de 1 entre les deux.
231
14.5.7. Working directory
« Current Directory » de la fenêtre de MATLAB doit être le dossier où se trouve le .mdl

dont on essaie de faire un « build » sinon ça donne un message d’erreur.
14.5.8. Erreurs incompréhensibles !
Il est arrivé, que sans aucun changement dans le système et selon la même façon de
faire le démarrage, le système HIL devienne instable. Même les modèles plus simples
chargés sur le système étaient tout d’un coup instable (ou sont devenus instables après
quelques secondes). Quelques essais plus tard, le phénomène avait disparu et le système
restait stable pendant des heures.
14.5.9. Reset Atmel
Il est clair, qu’il faut relancer l’Atmel (les Atmel dans le cas de l’I²C) avant un nouvel
essai, parce qu’il a sauvegardé les anciennes variables. Apparemment cela marchait aussi
mieux quand on attendait 5 secondes après l’avoir éteint (pour décharger tous les états
internes). Finalement ça a aussi aidé parfois de relancer le Target PC, Matlab ou bien
nettoyer les dossiers de simulation de Matlab (voir l’autre point de la Top Ten Buglist)
14.5.10. Vérification des connexions
Il est utile de vérifier systématiquement que l’on a branché tous les câbles nécessaires.
Surtout pour les PWM il ne faut pas mélanger les Pins, une mesure avec l’oscilloscope est
utile.
14.5.11. Configuration de l’Atmega
Un problème plus subtil est la configuration de l’ATmega.

L’horloge peut être soit « externe »sur le board (qu’on ne voit pas), soit avec une horloge
externe (comme les 16 MHz). Pour choisir celle que l’Atmega doit utiliser, il faut verifier
deux choses :
Le jumper OSCSEL, petit cavalier plastique à mettre sur deux des trois pins OSCSEL. Il
est en position ++0 (sur les deux pins à gauche) pour l’oscillator externe (par exemple
16 MHz).
L’onglet « Fuses », qui apparaît dans AVR studio quand on est branché avec le STK500. Il
faut choisir pour l’horloge oscillator externe le dernier élément : « Ext. Crystal/Resonator
High Freq. Start up time +64ms ». Pour l’oscillateur on-board on prend l’option « ext.
Clock ; start-up time 6CK + 64ms »
On peut tester les horloges facilement en utilisant le programme « UART test » (envoyer
quelque chose sur le port série, affichage avec Hyperterminal.)
232
14.6. Les contrôleurs dans Simulink et sur l’ATmega
Control_altitude.m
%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Bouclages Vz - Az %%%
%%%%%%%%%%%%%%%%%%%%%%%%%
Eqaz=4*(R*I0+R*b*wb^2/Ki+wb*Kw)*256/12; % point d'équilibre pour l'axe

vertical
K1z=a*2*wb/M;
K2z=(Ki*Kw/R+2*wb*b)/Jm;
K3z=Ki/(Jm*R);
%% Création du système linéarisé tangent

%% état : Vz, Az , Wz (pas de correspondance physique)
%% sortie : z(cm), Vz(cm/s), Az(milli-g)
Az = [0 1 0; 0 0 -K1z; 0 0 -K2z];
Bz = [0; 0; K3z]*12/255;
Cz = [100 0 0; 0 100 0; 0 0 -a*2*wb/M*1000/g];
sysaz = ss(Az,Bz,Cz,0); % Création du système linéarisé tangent
vertical
%sisotool(sysaz(3,1)) Ajustement d'un correcteur P pour la
% boucle sur Az
Kaz = -.28; % Correcteur pour Az
sysvz = feedback(sysaz*Kaz,1,1,3);
%sisotool(sysaz(2,1)) Ajustement d'un correcteur P pour la
% boucle sur Vz
Kvz = 20; % Correcteur pour Vz
sysz=feedback(sysvz*Kvz,1,1,2);
Kzd=2; % Correcteur P pour la boucle sur Z
%sisotool(sysz(1,1),Kzd,filson)
sur l’ATmega :
//difference par rapport au reference (z)
u = ref3 - z;
//P controller (z)
u = 2*u;
u= u - vz;
//P controller (vz)
u = 20*u;
//difference par rapport au az
u= u - az;
233
//P controller (az)

u = -.28*u;
//sortie
Control_horizontal.m
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Bouclages Vy - Phi - P %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
K1p=a*l*2*wb/c;
K2p=(Ki*Kw/R+2*wb*b)/Jm;
K3p=Ki/(Jm*R);
%% état : Vy, Phi, P, Wp (pas de correspondance physique)
%% sortie : Vy(cm), Phi(.01deg), P(0.01deg/s)
Ap=[0 g 0 0;0 0 1 0;0 0 0 K1p;0 0 0 -K2p];
Bp=[0;0;0;K3p]*12/255;
Cp=[100 0 0 0;0 180*100/pi 0 0;0 0 180*100/pi 0];
sysp=ss(Ap,Bp,Cp,0);
%sisotool(sysp(3,1),1,filter,1) Ajustement d'un correcteur PID pour la

% boucle sur P
Kp=0.8*0.00376*tf([0.075 1],[0.01 1]); % Correcteur pour P
Kpd=c2d(Kp,20e-3,'foh'); % Correcteur discrétisé
sysphi=feedback(sysp*Kp,filter,1,3); % Système avec Phi
%sisotool(sysphi(2,1)) Ajustement d'un correcteur P pour la
% boucle sur Phi
Kphi=7; % Correcteur pour Phi
%Kphid=c2d(Kphi,20e-3,'foh'); % Correcteur discrétisé
Kphid=7; % Car Kphi est uniquement proportionnel
sysvy=feedback(sysphi*Kphi,1,1,2); % Système avec Vy
%sisotool(sysvy(1,1)) Ajustement d'un correcteur P pour la
% boucle sur Vy
Kvy=23; % Correcteur pour Phi
%Kvyd=c2d(Kvy,20e-3,'foh'); % Correcteur discrétisé
Kvyd=23; % Car Kvy est uniquement proportionnel
Kyd=1.5; % Correcteur P pour la boucle sur Y
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Bouclages Vx - Theta - Q %%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
234
K1q=a*l*2*wb/d;
K2q=(Ki*Kw/R+2*wb*b)/Jm;
K3q=Ki/(Jm*R);
%% état : Vx, Theta, Q, Wq (pas de correspondance physique)
%% sortie : Vx(cm), Theta(.01deg), Q(0.01deg/s)
Aq=[0 -g 0 0;0 0 1 0;0 0 0 K1q;0 0 0 -K2q];
Bq=[0;0;0;K3q]*12/255;
Cq=[100 0 0 0;0 180*100/pi 0 0;0 0 180*100/pi 0];
sysq=ss(Aq,Bq,Cq,0); %% Création du système linéarisé tangent
%sisotool(sysq(3,1),1,filter) Ajustement d'un correcteur PID pour la
% boucle sur Q
Kq=0.8*0.00376*tf([0.075 1],[0.01 1]); % Correcteur pour Q
Kqd=c2d(Kq,20e-3,'foh'); % Correcteur discrétisé
systheta=feedback(sysq*Kq,filter,1,3); % Système avec Phi

%sisotool(systheta(2,1)) Ajustement d'un correcteur P pour la
% boucle sur Theta
Ktheta=7; % Correcteur pour Theta
%Kthetad=c2d(Ktheta,20e-3,'foh'); % Correcteur discrétisé
Kthetad=7; % Car Kphi est uniquement proportionnel
sysvx=feedback(systheta*Ktheta,1,1,2); % Système avec Vx
%sisotool(sysvx(1,1)) Ajustement d'un correcteur P pour la
% boucle sur Vx
Kvx=-23; % Correcteur pour Phi
%Kvxd=c2d(Kvx,20e-3,'foh'); % Correcteur discrétisé
Kvxd=-23; % Car Kvx est uniquement proportionnel
Kxd=1.5; % Correcteur P pour la boucle sur X
sur l’ATmega :
//difference par rapport au reference (vy)
u = ref - vy;
//P controller (vy)
u = 23*u;
//difference par rapport au phi
u= u - phi;
//P controller (phi)
u = 7*u;
//difference par rapport au p
e = u - p;
//controller (p)
u = .1353*u_old + .01146*e - 0.00886*e_old;
//sortie
//...
//difference par rapport au reference (vx)
u = ref2 - vx;
//P controller (vx)
u = -23*u;
//difference par rapport au theta
u= u - theta;
//P controller (theta)
u = 7*u;
//difference par rapport au q
e = u - q;
//controller (q)
u = .1353*u_old2 + .01146*e - 0.00886*e_old2;
//sortie
Control_lacet.m
235
%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Bouclages Psi - R %%%
%%%%%%%%%%%%%%%%%%%%%%%%%
K1r=b*2*wb/e;
K2r=(Ki*Kw/R+2*wb*b)/Jm;
K3r=Ki/(Jm*R);
%% état : Psi, R, Wr (pas de correspondance physique)
%% sortie : Psi(.01deg), R(.01deg/s)
Ar=[0 1 0;0 0 K1r;0 0 -K2r];
Br=[0;0;K3r]*12/255;
Cr=[180*100/pi 0 0;0 180*100/pi 0];
sysr=ss(Ar,Br,Cr,0); %% Création du système linéarisé tangent

Krd=10*pi/(180*100)*256/12;
syspsi = feedback(sysr*Krd,filter,1,2);
Kpsid=2.62;
%sisotool(syspsi(1,1),Kpsid)
sur l’ATmega :
u = ref4 - psi;
//P controller (psi)
u = 2.62*u;
//difference par rapport au r
u= u - r;
//P controller (r)
u = 0.0372337*u;
//sortie
236
14.7. Fichiers pour l’I²C
Générale :
Definir des variable globales dans un projet avec plusieurs fichiers c :
En plus des fichiers .c, il faut aussi des fichier .h (comme les .c à éditer par exemple
dans WinAVR)
les en-têtes des fichiers :

-file2.c :
#include "file2.h"
volatile uint8_t a,b;
-file2.h:
extern volatile uint8_t a,b;
-file1.c (avec mainfunction):

#include "file2.h"
Maintenant on peut utiliser et modifier les variables a et b partout (dans toutes les
fonctions Matlab)
La planche Simulink pour envoyer l’altitude:
Notons le « 221 » qui est envoyé comme en tête arbitraire.

Le fichier du Slave, v7-8e:
L’essentiel de I2c_slave.c
SIGNAL( SIG_UART_RECV ){
IncomingData = UDR;
//PORTB=0x77;
// Protocol UART1 to receive range by Target PC: 3 Bytes
// Byte1 - 0xFF (command for new message), Byte2 - Range-
highbyte, Byte3 - Range-Lowbyte
// Byte2 must be different from Byte3, Byte2 and Byte3 must
be different from 0xFF
switch (uart_next){
case 0:
if (IncomingData == 0xDD) {uart_next = 1; break;} //
continue after start condition
uart_next = 0;
// wait until start condition
break;
case 1:
if (IncomingData == 0xDD) {uart_next = 1; break;} // new
start condition
237
uart_next = 2;
// continue after high_byte of Data
range_high_temp = IncomingData;
break;
case 2:
if (IncomingData == 0xDD) {uart_next = 1; break;} // new
start condition
uart_next = 0;
// wait for start condition after low_byte of Data
range16 = IncomingData;
// range_low + range_high -> range16
temp16 = range_high_temp;
range16 |= (temp16<<8);
// no object is in range
if (range16>MAXRANGE16) { // test if no object in
range
range_high=0xFF ; // send range 0xFFFF
if no object detectable
range_low=0xFF ;
TimeToCount = 29491; // count 64 ms
if no object detectable
break;
}
// object is in range
range_high = range_high_temp; // write the two bytes at
once
range_low = IncomingData;
rangefloat = (float) range16; // range in cm

TimeToCountfloat = (2*rangefloat*36864/(343*8));
TimeToCount=(uint16_t) TimeToCountfloat; // Calculer
les pas pour le temps de decoupage, with prescaler 8 and 3,6864 MHz
break;
}
}
SIGNAL( SIG_OVERFLOW1 ){
//PORTB=TWCR;
TWCR |= 0x40; // TWEA=1, allow ACK
TIMSK &= 0xFB; // disactivate Timer1 Overflow Interrupt
RangeFlag=0; // TWEA will no longer be pulled to 0
//UCSRB &= 0x6F; // disable UART-interrupt
//uart_next = 0;
}
La partie essentiel de TWI_slave.c
SIGNAL( SIG_2WIRE_SERIAL )
{ // SendString(" Slave-INT: ");
static uint8_t TWI_bufPtr;
switch (TWSR) {
case TWI_STX_ADR_ACK: //SendString(" ST-ownAdr-rec-ACK-transm ");
// Own SLA+R has been received; ACK has been returned
// case TWI_STX_ADR_ACK_M_ARB_LOST: // Arbitration lost in SLA+R/W
as Master; own SLA+R has been received; ACK has been returned
TWI_bufPtr = 0; // Set buffer
pointer to first data location
if (I2cGlobal == 0x02){
TWI_buf[0]=range_high;
//if(range_low==0x51) range_low++;
//Assurer que i2c continue toujours (conflict avec command 0x51! )
238
TWI_buf[1]=range_low;
} // if asked, send 2-byte-range
else {TWI_buf[0]=0x33; TWI_buf[1]=0x44;} // Error, Read
without Register command
I2cGlobal=0; // after transmission clear command
case TWI_STX_DATA_ACK: //SendString(" ST-Data-transm-ACK-rec ");
// Data byte in TWDR has been transmitted; ACK has been received
TWDR = TWI_buf[TWI_bufPtr++];
TWCR = (1<<TWEN)| // TWI Interface
enabled
(1<<TWIE)|(1<<TWINT)| // Enable TWI
Interupt and clear the flag to send byte
(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| //
(0<<TWWC); //
if (RangeFlag==1) TWCR &= 0xBF; // TWEA = 0 while ranging
break;
case TWI_STX_DATA_NACK: //SendString(" ST-Data-transm-NACK-rec ");
// Data byte in TWDR has been transmitted; NACK has been received.
// I.e. this could be the end of the transmission.
PORTB=RangeCounter++;
if (TWI_bufPtr == TWI_msgSize) // Have we transceived all expected
data?
{ TWI_statusReg.lastTransOK = TRUE; // Set status
bits to completed successfully.
}else // Master has sent a NACK before all
data where sent.
{ TWI_state = TWSR; // Store TWI
State as errormessage.
}
TWI_buf[1]=0; //reset car conflit avec commande 0x51
// Put TWI
Transceiver in passive mode.
TWCR = (1<<TWEN)| // Enable TWI-
interface and release TWI pins (NO!)
(1<<TWIE)|(1<<TWINT)| // Disable
Interupt(NO!)
(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| // Do not
acknowledge on any new requests.(NO!)
(0<<TWWC); //
break;
case TWI_SRX_GEN_ACK: //SendString(" SR-GC-rec-ACK-transm ");
// General call address has been received; ACK has been returned
TWI_statusReg.genAddressCall = TRUE;
case TWI_SRX_ADR_ACK: //SendString(" SR-ownAdr-rec-ACK-transm ");
// Own SLA+W has been received ACK has been returned
TWI_statusReg.RxDataInBuf = TRUE;
TWI_bufPtr = 0; // Set buffer
pointer to first data location
// Reset the TWI
Interupt to wait for a new event.
enabled
(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| // Expect ACK on
this transmission
(0<<TWWC); //
break;
case TWI_SRX_ADR_DATA_ACK: //SendString(" SR-ownAdr-Data-rec-ACK-transm ");
// Previously addressed with own SLA+W; data has been received; ACK has
been returned
case TWI_SRX_GEN_DATA_ACK: //SendString(" SR-GC-Data-rec-ACK-transm ");
// Previously addressed with general call; data has been received; ACK has
been returned
TWI_buf[TWI_bufPtr++] = TWDR;
TWI_statusReg.lastTransOK = TRUE; // Set flag
transmission successful.
239
// Reset the TWI

Interupt to wait for a new event.
enabled
(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| // Send ACK after
next reception
(0<<TWWC); //
I2cGlobal=TWI_buf[0]; // first databyte received
is the command
if (TWI_buf[1]==0x51) {
TWI_buf[1]=0;
RangeFlag = 1;
TWCR &= 0xBF; // TWEA = 0
TCNT1 = (0xFFFF - TimeToCount) ; // initial Timer1
Value for 64 ms: 64535
TIMSK |= 0x04; // activate Timer1 Overflow
Interrupt//
}
break;
case TWI_SRX_STOP_RESTART: //SendString(" SR-Stop/Restart-rec ");
// A STOP condition or repeated START condition has been received while
still addressed as Slave
interface and release TWI pins
(1<<TWIE)|(1<<TWINT)| // Disable
Interupt-> Enable, wir wollen ja weiter machen!
(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| // DO acknowledge
on any new requests (0<<TWWC);
//
break;
case TWI_SRX_ADR_DATA_NACK: //SendString(" SR-ownAdr-Data-rec-NACK-
transm "); //Previously addressed with own SLA+W; data has been
received; NOT ACK has been returned
case TWI_STX_DATA_ACK_LAST_BYTE:// SendString(" ST-Lastbyte-transm-ACK-rec
");// Last data byte in TWDR has been transmitted (TWEA = “0”); ACK has
been received
case TWI_BUS_ERROR: //SendString(" "); // Bus error due to an
illegal START or STOP condition
default:
TWI_state = TWSR; // Store TWI State as
errormessage, operation also clears the Success bit.
interface and release TWI pins
(0<<TWIE)|(0<<TWINT)| // Disable Interupt
(0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| // Do not
acknowledge on any new requests.
(0<<TWWC); //
} }
240
HIL for Dummies - Comment démarrer avec xPC Target
(basé sur l’aide de Matlab/Help/xPC Target/ Getting Started, pour plus d’informations le
consulter à l’adresse suivante :
http://www.mathworks.com/access/helpdesk_r13/help/pdf_doc/xpc/xpc_target_gs.pdf–
pour tout détails voir cette tutorial)
14.7.1. Objectif
On suppose qu’on sait comment simuler.
Le but est de faire tourner un modèle Matlab en regime temps réel sur un « PC cible »
(Target PC). En pratique, cela pemettrapermettra d’utiliser la simulation pour remplacer
des objets réels, comme des capteurs ou même le quadricoptère physique. Pour gérer
(charger et lancer la simulation, changer des paramètres) le Target PC on le branche
avecrelie à un Host PC.
14.7.2. Branchement Liaisonvia RS232
14.7.2.1. MatérielHardware nécessaire (Hardware)
Pour le Target PC : PC avec port série RS232 et lecteur disquette 3.5’

Pour le Host PC : PC avec port série RS232, MATLAB, Visual C (par exeample Visual
Studio Net 2003), lecteur disquette 3.5’ (pour créer la disquette de démarrage (boot
diskque))
CableCâble série Nullmodem, disquette 3.5’ viergede
HIL Hardware, vue avant : Deux PC et une disquette
241
HIL Hardware, vue arrière : Branchement via RS232 et Ethernet
14.7.2.2. Configuration HIL
Tayper « xpcexplr » dans l’ongletsur la ligne de commande de Matlab

Choisir le classeur de Visual C pour le compiler
Créer la Bootdisk
242
Pour communication, choisir « RS-232 »
Avec le Target Boot Mode « Boot Floppy », appuy cliquer sur « Create Bootdisk »
Inserer la disquette dans le Target PC, lancer le PC (BIOS configuration « boot from
floppy »)
Image Ce qui devrait être affiché sur l’écran du Target PC

Tayper « xpctest » dans l’ongletsur la ligne de commande de Matlab, éventuellement
avec le complément « noreboot ». Les tests prennent un peu de temps. parce-qu’iIls font
243
un y a en effet redémarrage, compilation et téléchargement d’un programme (reboot,

build et download) d’une application.
Image après les tests dans lLe Command Window de MATLAB sur le Host-PC, après les
tests
14.7.2.3. Configuration Simulation
En Dans Simulink, ouvrir et ajuster le menu « Configuration Parameters »
Ouvrir le menu « Configuration Parameters » in dans Simulink
244
Paramètres à choisir pour « Solver »
Paramètres à choisir pour « Real-Time-Workshop »
245
Paramètres à choisir pour « xPC Target options »
14.7.2.4. Simulation sous Simulink
Créer un modèle avec des sources continues et des scopes Simulink ainsi que des xPC-
Target Scopes (celles-cis derniers peuvent être trouvés dans la « library browser » sous
xPC-Target)
Dans le menu « Simulation » choisir « Normal », puis « Start » pour démarrer la

simulation sur Simulink
246
Résultat pour une simulation Simulink avec un signal « square », Amplitude = 1,

Frequency = 20 rad/sec.
14.7.2.5. HIL – Hardware in the Loop
Dans le menu « Tools » choisir « Real-Time-Workshop »-« Build Model »

Le modèle est donc compilé avec Visual C et chargé sur le Target PC
Dans le menu « Simulation » choisir « External », puis « Connect to target » puis « Start
Real Time code » pour démarrer la simulation sur le Target-PC
Résultat de la simulation HIL sur le Target PC avec un Target Scope
247
Paramètres du Target Scope utilisé
Alternativement on peut lancer la simulation avec le « xPC-Explorer » avec les

commandes « connect to target » et « start Application »
14.7.3. Branchement Connexion via Ethernet
14.7.3.1. Hardware Matériel nécessaire
Dans les deux PC un Network adapter carde carte réseau, Celle du pour le Target PC,
c’est une carte spéciale doit être compatible avec xPC-Target
A la place du cable Nullmodem il faut un « cable croisé » (Ethernet UTP : (Unshielded
Twisted Pair cable)
14.7.3.2. Configuration HIL
Avant de créer la Bootdisk, on fixe une adresse IP dans le « xPC-Explorer »-

« configuration »-« communication »
248
Exemple pour de paramètres deles communications-settings pour une liaison du

branchement via Ethernet
Dans le Host-PC il faut utiliser une adresse physique similaire
Le reste fonctionne comme avec le branchement via la liaison RS232
249
15. ANNEXES CALCULATEUR
15.1. Structure du Programme principal (Version main500_4)
• de la ligne 3 à la ligne 11 : Déclaration des librairies

• 14-48 : définitions de paramètres et des LEDs du port B
• 70-87 : déclaration des variables
• 90-138 : définition des paramètres de la centrale inertielle, de vitesse et de
position
M : angles d’Euler de la Migd2
G : vitesses angulaires de la midg2
Gsonar : variable d’altitude mesurée par rapport au sol à l’aide d’un capteur
ultrason
Envoie : variable binaire qui permet de filtrer les données envoyées
ppm-pulses : tableau des données de la radiocommande
my-pulses : variable sans biais de la radiocommande (cf. le signal PPM)
• 161-175 : fonction put_c : sert à écrire un octet (8bits) sur le pin TX1 de
l’ATmega pour l’envoyer
• 178-218 : Initialisation du bus I2C (qui communique avec l’ultrason)
• 220-236 : Interruption de la boucle automatique
• 241-267 : fonctions d’envoie de plusieurs octets
Vertical : bibliothèque qui contient les paramètres de la boucle d’altitude
Trigo : bibliothèque contenant les valeurs de sinus et cosinus utilisés dans la
rotation transformant la vitesse et la position en repère du drone
• 277-291 : configuration des Timers
• 313-317 : configuration du convertisseur analogique numérique de référence
2,56V
• 376-392 : déclaration des variables de la boucle automatique
• 394-578 : boucle automatique principale (détaillée plus bas)
• 622-759 : boucle de communication avec la Midg2
• 770-774 : atterrissage automatique
• 776- 837 : décodage du signal ppm de la radiocommande
• 846-fin : décodage du bus I2C de lecture de l’ultrason
250
15.2. Boucle automatique principale
Les commentaires de cette partie ne sont en aucun cas complets ou précis mais ils vous
donnent le nécessaire à comprendre pour élargir l’automatique du code. Pour plus de
détails il faut s’adresser à M. Martin.
15.2.1. Boucle d’altitude
Pour comprendre cette boucle du programme principale, il faut avoir observé les
planches Simulink d’Erwan, en particulier le Subsystem « Contrôle Altitude ». Le schéma
suivant détaille l’asservissement de cette boucle et établit un rapport logique entre les
variables du programme principal et celles des planches de simulation :
Les filtres sont conçus en continu, mais pour les intégrer dans le programme principal il
faut les discrétiser grâce à la fonction c2d de Matlab (voir help Matlab). Par exemple le
filtre ultrason est discrétisé à l’aide de Matlab ainsi :
filson=tf([1],[.2 1]); % filtre passe-bas
filsond = c2d(filson,20e-3,'foh'); % filtre discrétisé
On tapant filsond sur la fenêtre de commande Matlab avec avoir exécuté le programme
.m contenant ce filtre on obtient la fonction de transfert suivante :
0.04837 z + 0.04679
-------------------
z - 0.9048
Sampling time: 0.02
Pour programmer ce filtre il faut effectuer une Tansformation en z de la sortie du filtre

(cf. cours de traitement de signal).
La transformation nous donne la relation:
251
zf(k) = 0,9048*zf(k-1) + 0,04837*gsonarfix(k)+ 0,04679*gesonarfix(k-1)
k est ici l’instant discret et gsonarfix est la variable d’altitude donnée par le capteur
ultrason fixé au bas du drone.
La boucle d’altitude dans le programme principale (souvent appelé boucle gaz) est la
suivante :
zf = ( 3280l*state_zf + 1585l*gsonarfix)>>15; // >> division binaire sur

2e15
//ici 1585 = 0,04837 * 2^15, en fait il faut transformer les paramètre
réels en entier pas trop petit pour ne pas manquer de précision et pas trop
grand pour éviter l’overflow.
state_zf = (14825l*(state_zf+gsonarfix))>>14;
(attention cette ligne est tout en bas de la boucle automatique)
//ici 14825 = 0,9048 * 2^14
prezr = ( ( -209715l*(my_pulses[2]+380) )>>20) +21;
// variable de commande après le préfiltre (discrétisation pareille que le
filtre untrason)
prezr = prezr + max( -1 , min(1,my_pulses[0]-prezr) );
//rate limiter 20e-3*50cm/s, 20e-3 est le temps d’échantionnageavec lequel

on discrétise sur Matlab (voir help Rate limiter du matlab)
state_zr = ( Azr*state_zr+Bzr*prezr )>>14;
(attention cette ligne est tout en bas de la boucle automatique)
zr = (Czr*state_zr + Dzr*prezr )>>18;

// Variable Ultrason mesurée filtrée
Vzr = 2*(zr+zf);
// Correcteur sur Z, il y a un plus car la valeur zr mesurée par rapport au
sol est déjà néagtive (repère oz dirigé vers le bas)
dazr = 20*(Vzr+data[VZ]);
// Correcteur sur Vz
daz = data[AZ]+1000;
// accélération mesurée plus la gravité
loop[0] = -73400l*(dazr-daz) + 157286400l;

//734001 = 0,28 *2^18 hovering//157286400=600*2^18, 600 est Eqaz, loop[0]
est l’accélération d’altitude
252
15.2.2. Boucle horizontale en X (en Y pareille)
15.2.2.1. Déjà programmé
//boucle roulis (roll)
Vlatr = Vlatr + max( -30 , min(30,my_pulses[0]-Vlatr) );

//rate limiter 20e-3*300/0.2 sur la valeur de Vx consigne Vlatr
On divise le rate limiter sur 0.2 pour ajuster la vitesse avec les crans de
la radiocommande
phir = ( -fKVtilde*Vlatr+KV_Spsi*data[VX]-KV_Cpsi*data[VY] )>>shift_alpha;

// schift_alpha est égale à 14
FKVtilde se trouve dans la librairie trigo ainsi que KV_Spsi et KV_Cpsi.
KV_Spsi et KV_Cpsi désignent respectivement sin(psi) et cos(psi) fois une
constante. Attention le correcteur en Vx 23 est déjà dans cette constante.
En effet
KV_Spsi = 23.37* 2^14*sin(psi) ; 23.37 est la valeur exacte du correcteur
en Vx
fKVtilde = 76579 = 23.37 * 2^14 * 0,2
la rotation en x a pour équation Vx_rot= –
sin(psi).data[VX]+cos(psi)*data[VY]
pr = ( K*(phir - data[MX]) )>>shift_alpha;

// K est aussi dans Trigo et est égale à 122880 = 7.5 * 2^14 (correcteur en
Phi)
253
Pour le correcteur en P qui est un contrôleur PD avec un filtre passe-bas,

il faut faire le même travail qu’avec le filtre ultrasons en boucle
altitude pour le discrétiser.
La discrétisation avec Matlab donne :
0.01146 z - 0.00886
-------------------
z - 0.1353
Sampling time: 0.02
La transformée en z donne théoriquement :
loop[3](k) =0,1353*loop[3](k-1) + 0,01146 (pr(k)-data[GX](k)) +

0,00886*(pr(k-1)-data[GX](k-1))
les lignes de code décrivant ce correcteur sont :

loop[3] = 3756l*(x[3] + pr - data[GX]);
tmp = -14167l*x[3] - 10449l*(pr-data[GX]);
x[3] = x[3] + (tmp>>shift_alpha);
// X[3] est une valeur intermédiaire de loop[3]

en remplaçant dans la ligne 3 tmp par sa valeur en la ligne 2 on a :
1 - 14167/2^14 = 0,1353
Pour avoir le même ordre de grandeur et assurer une valeur ni trop grande
ni trop petite des paramètres entiers, M. Martin utilise un autre modèle de
système d’état. Pour plus de détails demandez lui.
15.2.2.2. Asservissement en position (main 502_0)
le code modifié est :
if (zf<=-50)
// condition de passage de manuel en automatique
{
xr = xr + max( -2 , min(2,0-xr) );
//rate limiter 20e-3*100 très lent pour un premier test, ici la consigne de
position est de 0 (rester sur place)
xf = (KV_Cpsi*data[PY]-KV_Spsi*data[PX])>>14;
// Rotation exactement pareille que celle en vitesse mais avec valeurs
KV_Spsi et KV_Cpsi ajusté au correcteur de x qui vaut 1,5
Vlatr = (24*xr - 1*xf)>>4;

// 24 = 1.5*2e4 et 1 = 2^4*1.5/23.37
}
Le reste est pareil
254
if ((gsonar_new[1] > 200) || (my_pulses[0]<0))

Vlatr = Vlatr + max( -30 , min(30,my_pulses[0]-Vlatr) );
//rate limiter 20e-3*300/0.2
else Vlatr = Vlatr + max( -6 , min(6,0-Vlatr) ); // rate limiter
300*20e-3
// Ici la variable gsonar_new[1] a été introduite par le groupe capteur et
contient la valeur renvoyé par le capteur ultrason branché à l’amont du
drone.
Si cette valeur est supérieure à 200 cm alors pas de risque d’obstacle
alors on garde la même consigne en vitesse à partir de la radiocommande
Sinon il y a obstacle et l’ordre de freiner est donné immédiatement au
drone (amorti avec un rate limiter bien sûr).
En cas d’obstacle et de con
255

Drone

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Drone

Hochgeladen von

Copyright:

Verfügbare Formate

PROJET de 2ème année

1. PRESENTATION DU PROJET .........................................................6

1.1. Titre du projet et numéro d’enregistrement

Projet de mini-drone : Quadricoptère, mini-drone d’observation.

1.2. Les parties signataires

Encadrant du projet : Philippe Martin.

de Laleu Nicolas Chef de projet

Carteau Sébastien Cellule Projet

1.3. Analyse de la situation

1.4. Les raisons qui ont conduit à ce contrat, l’historique

Le projet créé en 2003 lors du regroupement des enseignements d’automatique,

1.5. Les difficultés rencontrées actuelles et à venir : analyse

Le quadricoptère existant au début du projet est l’aboutissement de deux de travail et a

1.6. Objectifs du projet

1.6.1. Enoncé général

1.6.2. Les objectifs intermédiaires

Miniaturisation et évolution de la station sol (accompli en grande partie)

1.7. Processus opératoire

1.7.1. L'organisation de l'équipe

L’équipe a été organisée en sous-groupe orienté par spécifications techniques. Ainsi,

1.7.2. Le planning du projet

1.7.3. Le financement du projet

1.7.4. La structure et l'organisation de l'équipe projet

Le groupe Propulsion est responsable de tout ce qui concerne la puissance sur le

2.1. Les batteries

2.1.1. Choix du type de batteries utilisées

Plomb acide 30-50 5% 250 2V 0,3 à 100

Actuellement le quadricoptère utilise des batteries 3 cellules (11,1 V) de 2000 mAh

2000 mAh 77x41x8 51 g 87.70 € 134 < 30A

2100 mAh 109x64x6 68 g 130.80 € 83 < 40A

2500 mAh 40x90x12 50 g 91 € 179 < 40A

3200 mAh 131x43.5x7.6 82 g 167.40 € 137 < 64A

3300 mAh 22x51x152 75 g 119 € 137 < 40A

4200 mAh 105x38x30 85 g 160 $ 175 < 40A

6000 mAh 34x98x25 65 g 179.95 $ 333 N/A

2.1.2. Précautions d’emploi spécifiques

2.1.3. Calcul de l’autonomie du quadricoptère

Nombre de batteries Cas n°1 Cas n°2

On s’aperçoit que l’hypothèse 1 correspond plus à la réalité, on retiendra cette

2.2.1. Fonction du disjoncteur

En 2004-2005, deux cartes électroniques ont successivement pris feu lorsque le

2.2.2. Principe de fonctionnement

On a retenu la solution d’un disjoncteur réglable (courant maximal admissible réglable)

2.2.3. Modélisation de la solution

2.2.3.1. Première version

Voici le schéma électrique de la première version du disjoncteur, la charge (le

Cette méthode présente plusieurs inconvénients :

beaucoup de paramètres, dont la température. De plus, la référence de tension utilisée

Afin de palier ce deuxième inconvénient, nous avons installé sur le disjoncteur un

2.2.3.2. Deuxième version

Voici le schéma électrique de la deuxième version du disjoncteur, la charge (le

On a substitué la fraction de la tension de batterie par un régulateur de tension 5V pour

2.2.3.3. Protocole utilisé et tests réalisés

L’impossibilité de détermination théorique de la valeur du courant limite (résistance

La principale difficulté provient de la limitation du courant que peut fournir le

Il est important de noter que ces résultats sont parfaitement reproductibles.

2.2.5. Configuration retenue et améliorations possibles

On a retenu la configuration avec le régulateur de tension 5V.

2.2.6. Exemples de calculs des valeurs des potentiomètres

On souhaite un courant limite de 25A. L’image du courant est 25 mΩ * 25 A = 0,625 V.

On souhaite un courant limite de 25A. L’image du courant est 25 mΩ * 25 A = 0,625 V.

2.3. Moteurs et Variateurs

2.3.1. Principe de fonctionnement des moteurs BLDC : nécessité de

2.3.2. Principe de fonctionnement d’un variateur

On-Time0 = 2OCRnSA 1/Fclkpsc

F moyenne = (16-d/16 Fpll/n) + (d/16 Fpll/n+1)