Embed Size (px)
DESCRIPTION
Réalisation d’un quadricoptère stabilisé
Citation preview
Réalisation d’un
quadricoptère
stabilisé
COSNARD Nicolas
FAURE Axel
GUINAULT Pierre
RIVRAY Benjamin
Université d’Auvergne Année 2012-2013
Nous autorisons la diffusion de notre rapport sur l'intranet de l'IUT
Remerciements
Dr Philippe Kauffmann & M. Jacques Laffont, maîtres de projet,
Pour leur investissement et leur aide tout au long de ce projet.
Francisco Sanchez, technicien à Polytech Clermont-Ferrand,
Pour son assistance dans la réalisation des montages électroniques.
Christian Couderc, service informatique CR2I,
Pour son aide lors de la réalisation de divers montages.
2
Sommaire Remerciements ........................................................................................................................ 2
Introduction .............................................................................................................................. 5
Bilan de l’existant ..................................................................................................................... 6
Choix techniques ..................................................................................................................... 7
Construction du nouveau cadre ....................................................................................... 7
RX62 ou M32 .......................................................................................................................... 7
ArduPilot Mega 2.5 ............................................................................................................... 8
Module Wi-Fi WizFi 220 ......................................................................................................... 8
Moteurs & ESC....................................................................................................................... 8
Matériel ................................................................................................................................... 10
Carte ArduPilot et capteurs .............................................................................................. 10
Descriptif .......................................................................................................................... 10
Modifications apportées ............................................................................................... 10
Schéma d’assemblage ................................................................................................. 11
Centrale inertielle, MPU-6000 ........................................................................................ 11
Puce GPS, Mediatek MT3329 ........................................................................................ 12
Détecteur d’obstacles et mesure de l’altitude, Sonar SRF-04 ................................. 12
Sonde de température .................................................................................................. 14
Microcontrôleur RX62......................................................................................................... 14
Le RX62N .......................................................................................................................... 14
Le RX62T ........................................................................................................................... 15
Moteurs, ESC & hélices ...................................................................................................... 15
Algorithmes & Stabilisation ................................................................................................... 16
Mixage des voies RC ......................................................................................................... 16
Traitement de la centrale inertielle .................................................................................. 18
Filtre de Kalman .............................................................................................................. 18
AHRS: Attitude Heading Reference System ................................................................ 19
Aspect physique et algorithmes de stabilisation ........................................................... 22
Définitions utiles dans le domaine du quadricoptère : ............................................. 22
Effet à prendre en compte pour le vol d'un drone. .................................................. 22
Analyse mécanique ....................................................................................................... 24
PID (Proportionnel, Intégral, Dérivé) ............................................................................. 28
Implémentation embarquée ............................................................................................... 33
3
La RPDL ................................................................................................................................ 33
Exemple : création d’une temporisation : .................................................................. 33
Exemple : envoi de messages via le port série : ........................................................ 33
Exemple : paramétrage du port série : ....................................................................... 34
Implémentation sur l’Arduino ........................................................................................... 35
Communications .................................................................................................................... 36
Protocole de communication Wifi ................................................................................... 36
Valeurs numériques ........................................................................................................ 36
Format général de la trame ......................................................................................... 37
Communication TTL entre ArduPilot & RX ....................................................................... 38
Bilan technique ...................................................................................................................... 39
Project Summary .................................................................................................................... 40
Bibliographie ........................................................................................................................... 41
Annexes ................................................................................................................................... 42
Annexe 1 : Identificateurs de trame ................................................................................ 42
Annexe 2 : Commandes de configuration du module Wifi ......................................... 44
Annexe 3 : Schéma RX62T ................................................................................................. 45
Annexe 4 : Schéma Module Wifi ...................................................................................... 45
4
Introduction
Entre mécanique, électronique et informatique, la conception d'un drone autonome
met en jeu des problématiques variées. Ce sont ces problématiques que nous avons
essayé de traiter au cours de ces quatorze semaines de projet.
Notre but était en effet de parvenir à la réalisation d'un quadricoptère capable d'un
vol stabilisé et autonome. Dans cette optique, les réalisations des différentes équipes
ayant contribué à ce projet au cours des années précédentes devaient initialement
nous servir de base de travail.
Au-delà de la simple réalisation des algorithmes, notre travail a consisté en une
contribution à la prise de décision entourant les aspects matériels et les objectifs
précis du projet. D'autre part la nature de notre projet a rendu nécessaire la prise en
main, voire la réalisation, de divers montage électroniques liés au drone.
Par ailleurs, le système réalisé au sein de notre équipe devait s'intégrer dans un projet
plus vaste comportant un simulateur dont le développement était à la charge d'une
seconde équipe. Il nous a donc fallu prendre en compte cette contrainte
supplémentaire et faire en sorte que les deux projets puissent avancer en parallèle et
aboutissent à des programmes compatibles.
Au cours de notre progression dans ce projet, nous avons rencontré plusieurs
difficultés, à divers niveaux tant du point de vue informatique que matériel. Afin d'en
faciliter la compréhension, nous présenterons ici tout d'abord, les différents domaines
techniques traités puis nous reviendrons sur la chronologie du projet, l'interconnexion
entre ces domaines et la répartition des différentes tâches.
5
Bilan de l’existant
Le bilan de l’existant que nous avons réalisé dès les premières semaines du
projet nous a permis de déterminer les problèmes existant et de définir ce qui
pourrait être conservé et ce qui devrait être remplacé. Il nous été en effet apparu
lors d’une tentative de démonstration de la capacité de vol du drone par M.
Kauffmann que ce dernier présentait en l’état un certain nombre de problèmes. Ces
problèmes rendaient presque impossible le vol du drone et devait donc être résolus.
Voici un résumé synthétique de ce bilan.
Commençons par la partie matérielle. L’armature du drone était en bois, de
conception artisanale, partiellement cassée et offrant une prise au vent importante
elle devait être changée. Sur cette armature étaient fixés quatre moteurs Turnigy
2204-14T, offrant une puissance théorique suffisante, les chocs reçus au cours de
séances de tests les années précédentes avaient faussé les arbres de certains
d’entre eux, leur remplacement semblait également souhaitable. Les hélices quant
à elle était assez fortement endommagées et fixées par des élastiques usés, elles ne
pouvaient donc être conservées. Le drone était également équipé de quatre ESC
(un par moteur) dont l’état semblait satisfaisant, une carte de distribution répartissait
le courant entre ces ESC, cette carte était mal positionnée et présentait des faux
contacts. Avec le drone, nous ont été confiés, une carte équipée d’un processeur
Atmel, capable de faire voler le drone à l’aide d’un code pré-chargé, un module
RC (et une télécommande) que nous avons décidé de conserver et un module wifi
dont le remplacement était d’ores et déjà programmé.
Concernant la partie logicielle, le simulateur repris par l’équipe de projet avec
laquelle nous travaillions présentait une base de travail sous Raydium, toutefois la
qualité du code était assez décevante. L’application Android quant à elle était
incomplète mais globalement utilisable. Enfin le code source destiné au
microcontrôleur M32 comportait uniquement un code de contrôle du décollage qui
n’a pu être testé et dont les sources étaient éparpillées et difficilement récupérables.
Au terme de ce bilan, il est donc apparu que l’essentiel du code et du
matériel présent au démarrage de ce projet devrait faire l’objet d’un remplacement
ou d’une révision importante. Il allait donc nous falloir déterminer ce qui devrait le
remplacer.
6
Choix techniques
Construction du nouveau cadre
Le cadre est constitué de tubes en fibre de carbone, ce qui permet d'allier
légèreté et robustesse. La plaque centrale et les supports des moteurs sont en
merisier, ce qui permet de fixer facilement toute l'électronique embarquée. Des
patins en polystyrène fixés au bout des bras permettent d'amortir les rebonds au
posé, et offrant une garde au sol importante pour protéger les composants fixés sous
le drone.
Les moteurs ne sont pas fixés au bout des bras, ce qui permet de protéger les
hélices puisque les patins toucheraient un éventuel obstacle avant les hélices mais
leur distance par rapport au centre du drone est réglable, ce qui peut servir à
modifier la dynamique de vol.
RX62 ou M32
La famille de microcontrôleur RX62 produite par Renesas a été choisie par
l’équipe pour remplacer le microcontrôleur utilisé par les équipes précédentes, le
M32.
L’objectif de ce microcontrôleur est double : il doit à la fois assurer la
communication avec l’ArduPilot, donc vers les capteurs et actionneurs, mais aussi
vers un terminal Android ou un ordinateur, pour être contrôlé par ce biais et envoyer
les informations nécessaires au simulateur.
Cet objectif double nécessitait donc une puissance suffisante, puisque la
nature même du projet nous forçait à avoir des temps de traitements très brefs. C’est
donc ce premier souci de rapidité qui nous a fait pencher vers le RX, puisqu’il
dispose d’une horloge cadencée à 100MHz, contre 32MHz pour le M32.
En outre, concernant le développement logiciel, le compilateur fourni permet
d’utiliser du C++, et Renesas fournit un ensemble de bibliothèques appelées RPDL
(Renesas Peripheral Driver Library) permettant d’utiliser de manière simplifiée les
différents périphériques, comme les ports série ou les broches d’entrées sorties.
Enfin, le fait que le RX remplace le M32 dans les cours d’informatique
embarquée implique que les prochaines équipes ne connaitront pas le M32, il est
donc logique de se baser sur le RX, qui en plus dispose d’une configuration
technologique bien plus récente que le M32.
La carte réalisée l’année précédente n’ayant jamais fonctionné, nous
n’avons donc pas eu de regret à l’abandonner pour travailler avec le nouveau
microcontrôleur RX62.
7
ArduPilot Mega 2.5
Nos recherches préliminaires sur les nouveaux composants nous ont amené
vers l'ArduPilot. Cette carte de prototypage rapide est basée sur un Arduino Mega
2560. Dans sa dernière révision (2.5), l'ArduPilot se compose d'une seule carte
(plusieurs shields auparavant) intégrant les composants nécessaires au vol d'un avion
ou d'un hélicoptère comme une centrale inertielle 6 axes (3 gyroscopes, 3
accéléromètres), une boussole 3 axes, d'un baromètre et d'une puce GPS.
Cet ensemble étant rassemblé sur une seule et même carte permet
d'optimiser la place nécessaire sur le drone et diminuer les câblages. Par la qualité
de ces composants et sa compactibilité, les nombreuses entrées/sorties et sa facile
prise en main, le choix de l'ArduPilot semble incontestable.
Module Wi-Fi WizFi 220
Le module WizFi 220 est un module Wi-Fi produit par la société WIZnet. Il s’agit
d’un module compatible avec les normes Wi-Fi IEEE 802.1 b/g/n, idéal pour
l’embarqué grâce à sa faible consommation et sa petite taille.
Il intègre un grand nombre de fonctionnalités, parmi lesquelles une interface
série, un serveur DHCP, un serveur http minimaliste, une implémentation des
encryptions WEP et WPA2 et des protocoles TCP et UDP.
En outre, il bénéficie d’un mode classique, permettant de se connecter à un
réseau existant, d’un mode ad-hoc, permettant la connexion direct à un
périphérique compatible (un ordinateur le plus souvent) et enfin d’un mode point
d’accès (AP, pour Access Point), qui autorise le module à créer son propre réseau
sur lequel viennent se connecter différents périphériques. Ici, le mode AP encore en
développement ne permet une connexion stable qu’avec deux ou trois
périphériques en même temps. (cf. annexe 2 : Commandes de configuration)
Le rôle de ce module Wi-Fi, relié au RX62T par un port série, est d’assurer la
communication entre d’une part le drone, et d’autre part un périphérique de
contrôle (application PC ou android) et/ou le simulateur.
Moteurs & ESC
Nous avons utilisé le même type de moteurs que les
années précédentes, des moteurs Turnigy 2204-14T de
type « brushless » ; nous expliquerons leur fonctionnement
plus tard.
Ce type de moteur a l’avantage de ne pas chauffer, d’avoir un bon
rendement (supérieur à 70%), une faible consommation, un faible poids (19g) et
peuvent supporter des hélices de 8 pouces comme celles dont nous disposons.
8
Le seul reproche possible à ces moteurs est la longueur de l’arbre. En effet ce
dernier ne dépassant pas, les hélices sont donc simplement posées dessus et
maintenues par 2 élastiques.
9
Matériel
Carte ArduPilot et capteurs
Descriptif
En plus de ces nombreux capteurs, elle possède de nombreuses
entrées/sorties et ports:
8 entrées PWM
8 sorties PWM/PPM
9 entrées/sorties analogiques
4 ports séries (UART0 : USB et Xbee par défaut,
UART1 : GPS, UART2: Xbee après modification, UART3 : ...)
1 port I2C pour des circuits externes
1 port SPI
Pour toutes les entrées/sorties, les broches se composent
de 3 pins, un pin +5V, GND et un dernier pour le signal.
Modifications apportées
Afin de permettre une alimentation de l’ArduPilot par les moteurs à la place
de l’USB, un dispositif a été mis en place par les concepteurs. Il a suffit de placer un
cavalier sur les broches JP1 comme montré sur le schéma ci-dessous. Cette
modification permet alors d’avoir l’alimentation par les moteurs et de pouvoir rester
connecter en USB.
Pour la mise en place des communications série, nous devions utiliser un port
série libre. Le port 0 étant réservé à l’USB, le port 1 pour le GPS, nous avons décidé
d’utiliser le port 2, initialement prévu pour la communication Xbee, et qui disposait
déjà d’un connecteur. Initialement, ce connecteur était relié au port 0, le même
que le port USB. Il a donc fallu modifier la carte pour fixer le port 2 à cette
connectique. Pour cela des soudures et des coupures de pistes étaient nécessaires
10
(comme indiqué sur le schéma ci-dessous), ces interventions furent réalisées par M.
KAUFFMANN.
Schéma d’assemblage
Centrale inertielle, MPU-6000
La MPU-6000, fabriquée par Invensense, fait partie des meilleurs composants
utilisés dans les tablettes, smartphones et différents capteurs. Elle est très appréciée
car elle a un faible coût, une faible consommation et de hautes performances.
11
C'est une centrale inertielle 6 axes, c'est-à-dire qu'elle
associe selon les axes X, Y, Z: 3 gyroscopes (vitesse angulaire)
et 3 accéléromètres (accélérations). Cette génération
intègre un DMP (Digital Motion Processor) afin d'ajouter 3
axes supplémentaires avec l'utilisation de magnétomètres
externes dans le but de corriger la dérive des mesures. Pour
communiquer, elle peut utiliser 2 systèmes de bus: I2C et SPI.
De plus, on peut configurer leur sensibilité que cela soit pour
les gyroscopes et les accéléromètres.
Désormais intégrée à la carte ArduPilot, nous avons utilisé la bibliothèque mise à
disposition qui utilise la communication SPI pour récupérer les valeurs des capteurs.
Une tache future possible sera de réécrire cette bibliothèque.
Puce GPS, Mediatek MT3329
Cette puce fabriquée par MediaTek fait partie des composants les plus utilisés
dans les systèmes de localisation. Sa faible consommation et sa haute précision,
même dans les milieux urbains (<3 dans 50% des cas), sont des atouts majeurs. Son
taux de rafraichissement peut varier de 1 à 10 kHz, et il lui faut au plus 35 secondes à
froid pour se localiser. Par défaut on utilise le port avec une
vitesse de 38400 bauds.
Détecteur d’obstacles et mesure de l’altitude, Sonar SRF-04
Afin de permettre à notre drone de voler sans
dommage, nous avons choisi d'utiliser de multiples sonars
afin de détecter les obstacles environnants. Nous avons pris
les sonars SRF-04 que nous utilisons en TP.
Ces composants conçus par la société Devantech
permettent de mesurer des distances entre 3cm et 3m.
Notre drone possèdera 5 sonars, 1 situé dessous pour nous donner son altitude
(dans le cas de faibles hauteurs) et 1 entre chaque bras du quadricoptère, cela
permettant d'éviter un obstacle qui passerait entre les bras. Le spectre de ce sonar
n'étant pas trop large (cf. diagramme ci-contre), les bras n'entraineront pas de
perturbations dans les mesures.
Ce capteur peut être utilisé avec une communication I2C ou par des
entrées/sorties analogiques. Nous utilisons cette dernière.
12
Pour cela, nous avons 4 broches :
Son fonctionnement est assez simple, comme le montre le diagramme ci-dessous.
On envoie une impulsion pendant au moins 10µs sur le TRIGGER pour démarrer
la mesure. Ensuite il envoie 8 cycles d'ultrasons à 40 kHz et met la voie ECHO au
niveau haut. Il écoute alors et dès que l'écho revient, il la passe au niveau bas.
L'écho est donc une pulsation proportionnelle à la distance de l'objet. Si rien n'est
détecté alors le SRF04 baissera sa voie ECHO de toute façon après 36ms d'attente.
13
Voici un code d'exemple pour Arduino:
La possibilité d'utiliser le même port TRIGGER pour les différents sonars a permis
d'économiser le nombre de broches, car sinon il aurait fallu 4*5 = 20 broches et donc
10 broches de signal alors que nous n'en avons que 9 libres. Il faut répéter la
séquence des « digitalWrite » avant chaque mesure de distance.
Sonde de température
Afin de contrôler la température de la batterie, nous avons décidé d'utiliser la
sonde utilisée en TP. En cas de suralimentation de la batterie, la température
augmente fortement, on pourra donc essayer de l’anticiper.
Lors de son acquisition, une idée supplémentaire était évoquée, c'était de
faire du retro engineering sur le code fourni avec, mais la complexité et l’obscurité
de ce dernier n'ont pas permis de le faire. Pour les successeurs, réécrire les
bibliothèques pourrait être une nouvelle piste de travail. Au final, nous utiliserons
cette carte comme un macro-capteur intelligent qui enverra simplement les valeurs
de ses capteurs au RX62T par le port série UART2.
Microcontrôleur RX62
Le RX62N
Le RX62N est une carte utilisée pour le développement, avec ses nombreux
périphériques qui permettent un débogage bien plus facile qu’avec une carte
embarquée.
Parmi ces périphériques, on notera les deux qui nous ont le plus servi, le port
série relié directement à un connecteur DB9 ce qui rend la liaison avec un ordinateur
beaucoup plus facile, et la présence d’un afficheur de 2 lignes de 8 caractères qui
permet de suivre le déroulement du code. Cette carte de développement possède
14
aussi un port USB, un port ethernet et de nombreuses broches pouvant servir à
différents usages.
Nous avons donc commencé par travailler avec le RX62N pour prendre en
main cet outil étant donné que nous avions travaillé avec le M32 dans nos cours
d’embarqué. Toutefois, n’utilisant que très peu des possibilités fournies par le RX62N
et celui-ci étant trop volumineux pour être embarqué, nous avons rapidement
continué le développement sur la carte embarquée que nous avons dessiné avec
l’aide de M. Kauffmann et réalisée par M. Sanchez, qui était, elle équipée d’un
RX62T.
Le RX62T
Le RX62T est la version que nous avons embarquée sur le quadricoptère. La
carte de développement devant être de taille et de poids minimaux, nous avons
réduit les périphériques au minimum.
Au final, la carte embarque en plus du microcontrôleur deux ports série pour
communiquer avec le module wifi et avec l’ArduPilot, une diode pour s’assurer de la
mise sous tensions, trois connecteurs pour brancher d’autres diodes, utiles pour le
débogage, un oscillateur pour s’assurer du bon cadencement du RX et du circuit
d’alimentation.
Moteurs, ESC & hélices
Nos moteurs sont de type brushless (ou moteur synchrone courant continu),
c’est-à-dire qu’ils sont constitués d’aimants permanents et de capteurs à effet Hall,
qui permettent de détecter la position du rotor en mesurant les variations des
champs magnétiques. On trouve également un système électronique de
commande pour permettre la commutation du courant dans le strator (sur le
schéma : anneau à l’extérieur).
Leur fonctionnement se base sur la répulsion magnétique. Quand le pôle nord
du rotor passe devant le sud du bobinage, ils se repoussent, comme le fait un
aimant avec une boussole. Ainsi sans contacts, il n’y a ni usure, ni frottements
contrairement au moteur à courant continu.
Pour contrôler la vitesse des moteurs, ils sont associés avec des ESC (Electronic
Speed Controller). Le rôle de ces contrôleurs est de réguler la tension pour donner
plus ou moins de vitesse au moteur en abaissant la tension
d'entrée par découpage de celle-ci. Il y a donc deux systèmes
distincts dans le contrôleur : le premier réagit à la consigne
venant de la carte et fournit une tension d’alimentation, mais
laisse passer l'ampérage dont il aura besoin. Le second, en
fonction de la position du rotor, commute le bon circuit (en se
servant des informations sur la position du rotor reçue par le
moteur et donc quel circuit il faut commuter), aux bornes
duquel on va retrouver cette tension.
15
Algorithmes & Stabilisation
Mixage des voies RC
Lors de l’utilisation de la commande RC, il est nécessaire de mixer les canaux
pour appliquer les mouvements réalisés à l’aide des joysticks. Ces actionnements
vont agir sur la commande envoyée à chaque moteur : soit une augmentation du
signal PWM soit une diminution.
L’élaboration de cet algorithme a été simple, il a suffi de réfléchir à l’incidence de la
manœuvre demandée sur chaque moteur. Pour chaque moteur, la commande
principale est le « Throttle » (les gaz qui permettent de faire monter ou descendre le
drone, à laquelle on ajoutera ou soustraira les autres commandes affectée d’un
coefficient.
Par exemple, pour avancer le drone va s’incliner vers l’avant. Les moteurs avant, 1 et
2, vont devoir ralentir et les moteurs arrière, 3 et 4, vont accélérer. On va donc
soustraire le signal reçu sur le canal 2, responsable de cette inclinaison, aux
commandes des moteurs 1 et 2 et l’ajouter aux 2 autres. Afin d’améliorer la réponse,
on applique un coefficient déterminé expérimentalement à chaque commande.
Pour rappel, voici la disposition des moteurs de notre drone :
16
Le tableau suivant résume l’état de chaque moteur selon les mouvements :
Joystick Commandes Commande Incidences sur
moteur
M1,M2,M3,M4 +
M1,M2,M3,M4 -
M2,M4 –
M1,M3 +
M2,M4 +
M1,M3 -
M1,M2 +
M3,M4 -
M1,M2 -
M3,M4 +
M1,M4 -
M2,M3 +
M1,M4 +
M2,M3 -
17
Traitement de la centrale inertielle
D’après Kalman Filter for Beginners : with MATLAB Examples, Phil Kim and Lynn Huh
Afin de connaitre la position de notre drone, il nous faut récupérer et traiter les
valeurs de la centrale inertielle. Comme pour tout capteur, afin d’éviter le bruit et
diminuer les erreurs, il était important de filtrer ces valeurs. C’est pourquoi nous avons
utilisé le filtre de Kalman.
Filtre de Kalman
Le premier filtre de Kalman a été utilisé pour l’aérospatial lors des missions
Apollo. Effectivement s'il existe un domaine où la connaissance exacte de la position
et de l'état d'un objet est importante, c'est bien l'aérospatial.
Il serait difficile d'avoir un système de navigation sans un filtre de Kalman. En
effet lorsqu'on désire suivre une cible, des données sur sa position, sa vitesse et son
accélération sont mesurées à chaque instant mais avec énormément de
perturbations dues au bruit ou aux erreurs de mesure. Le filtre de Kalman utilise la
dynamique de la cible pour définir son évolution dans le temps et ainsi obtenir de
meilleures données, en éliminant le bruit.
On peut définir ce filtre comme un estimateur récursif, car la prédiction de
l'état suivant se base sur l'état précédent et les mesures actuelles.
On peut donc découper ce filtre en 2 phases: la prédiction et la mise à jour. La
phase de prédiction utilise l'état estimé précédemment afin d'estimer l'état courant.
La phase de mise à jour se base sur l'état courant pour corriger l'état prédit.
0. Initialisation des valeurs initiales
I. Prédiction de l'état et matrice de covariance*
II. Calcul du gain du filtre
III. Mise à jour avec mesure et calcul de l'estimée.
IV. Mise à jour de la covariance de l'erreur.
* : mesure de la précision
de l'état estimé
18
Avoir des valeurs propres c’est bien, mais il est nécessaire de bien savoir les exploiter.
AHRS: Attitude Heading Reference System
AHRS se traduit par système d’attitude et de cap. Il s’agit d’un système conçu
pour obtenir l’orientation en 3D de l’objet, utilisant des gyroscopes et des capteurs
de référence comme les accéléromètres et/ou magnétomètres.
Nous allons donc présenter comment avoir un drone positionné à l'horizontal
à l'aide de la centrale inertielle (gyroscopes, accéléromètres).
Ces capteurs vont nous donner des vitesses angulaires et des accélérations selon 3
axes (x, y, z). Si nous prenons notre drone, il suffit de connaitre les 3 angles (roulis,
tangage et lacet) pour le positionner précisément. C'est donc ce que nous obtenir
pour définir l'horizontalité de notre quadricoptère. Etant donné que nous
recherchons à le positionner horizontalement, nous ne tiendrons pas compte du
3ème angle : le lacet (selon z).
Détermination à partir des gyroscopes
Nous ne pouvons pas obtenir directement les angles d'Euler en intégrant les
vitesses angulaires, car il n'y a pas de dérivés avec ces angles. Ces vitesses sont en
rad/sec. On doit donc transformer les vitesses angulaires mesurées puis les intégrer
pour obtenir les angles d'Euler. Mais au long des calculs, des erreurs s’accumulent et
les valeurs dérivent.
Si on observe les mesures ci-dessous, on remarque que pendant la manœuvre
sur le roulis, le tangage augmente. Cela est dû à l'accumulation des erreurs liées à
l’intégration.
On constate donc qu'un gyroscope est très précis sur une courte période mais peu
sur une longue.
19
Détermination à partir des accéléromètres
Dans les accélérations mesurées, on retrouve différentes accélérations comme
l'accélération gravitationnelle, qui sont modifiés lors du changement de vitesse que
ce soit en amplitude ou lors d'un changement de direction.
Si on retire l’accélération gravitationnelle, on peut obtenir les positions à partir de ces
mesures.
𝜃 = sin−1 (𝐴𝑥
𝑔)
𝜑 = sin−1 (−𝐴𝑦
𝑔 ∗ cos 𝜃)
Ax,Ay : accélérations selon x et y
θ : angle de roulis
φ : angle de tangage
Les graphes ci-dessus montrent les valeurs des angles obtenues à partir des
accéléromètres. On voit qu'il n'y a pas d'accumulation d'erreurs mais que la valeur
maximale tourne autour de 9° alors que la centrale est inclinée de 30°. La différence
étant trop importante, on ne peut pas utiliser les accéléromètres seuls.
Détermination en fusionnant les capteurs
On a remarqué que séparément, ces capteurs n'étaient pas efficaces pour
positionner le drone. Mais si on pouvait associer les avantages de chacun, on
pourrait obtenir quelque chose d'intéressant. C’est ici qu’intervient le système AHRS
mais Pour pouvoir s'accommoder des accélérations passagères ainsi que des
perturbations et vibrations magnétiques, il est nécessaire de fusionner les données de
tous les capteurs dans un filtre de Kalman.
20
Le schéma suivant montre comment nous allons combiner nos mesures.
L'attitude obtenue par les accéléromètres deviendra la mesure nécessaire au filtre
de Kalman. Ainsi l'erreur des gyroscopes sera corrigée par les accéléromètres dès
que les mesures des gyroscopes divergeront.
La difficulté supplémentaire vient du fait qu'on ne peut pas appliquer le filtre
de Kalman sur ces mesures. Nous devons donc transformer les angles d'Euler à l’aide
de matrices de quaternions. Suite à ces changements nous pourrons appliquer le
filtre. Nous passerons sur les différents calculs, il suffit de se reporter à la
documentation nous ayant servi de référence.
Finalement, cette fusion aura permis d'éliminer les inconvénients de chaque
type de capteur et donc d’avoir des valeurs précises comme le montrent les
courbes ci-dessus.
Correction supplémentaire
Dans l'idée d'un vol autonome, on pourra apporter une correction
supplémentaire à l'aide de la boussole et de ses magnétomètres. Ainsi à l'aide du
champ magnétique terrestre nous pourrons corriger les dérives restantes.
AcceleromètresDétermination de l'attitude
Filtre de Kalman
Gyroscopes Mesures Attitude
21
Aspect physique et algorithmes de stabilisation
Définitions utiles dans le domaine du quadricoptère :
Angle de calage : angle entre la corde et le plan de rotation de l'hélice
Traînée : résistance de l'air sur l'hélice sur une hélice en rotation.
Vitesse induite : vitesse communiquée à la molécule d'air lors de son
passage au travers du disque rotor.
Effet à prendre en compte pour le vol d'un drone.
Cette partie relate des contraintes de l'environnement extérieur au drone et qui
agisse dessus.
L'effet de couple : Du fait que le l'hélice tourne dans un sens, le moteur tend à
tourner dans le sens opposé en raison de la traînée induite par les pales. Il en
résulte une légère inclinaison du moteur concerné. L'effet de couple dépend
de la masse du l'hélice, de son pas, de son diamètre et de son régime, mais
aussi et surtout à la puissance disponible : plus la puissance est grande, plus
l'effet de couple est grand.
L'inclinaison de l'axe du moteur en dû à l'effet de couple dépend de la
résistance qui lui est opposé. Pour réduire cet effet, on peut appliquer deux types de
« contre-mesures » :
- les mesures passives qui ont lieu lors de la conception.
- les mesures actives qui sont celle que l'on peut induire durant le vol
(comme le report de poids d'un côté ou de l'autre, un réglage
asymétrique du Trim, une réduction de poussée...).
La précession gyroscopique : Une hélice qui tourne agit comme un
gyroscope, qui initialement tend à résister à toute force qui pourrait lui faire
changer d'axe de rotation.
Ainsi, si une telle force persiste ou est assez intense, l'hélice en rotation ne
dérive pas dans la direction cette force, mais dans une direction de 90° de celle-ci
dans le sens trigonométrique.
22
F la force instantanée appliquée au système en rotation, et R la résultante à 90
degrés dans le sens de rotation que le système va réellement "ressentir".
La poussée asymétrique des pales : celle-ci a trois facteurs qui sont :
- Elle se manifeste lorsque l'hélice n'est pas dans le plan horizontal, chacune
des pales lorsqu'elle descend est entraînée vers l'avant, et lorsqu'elle monte
vers l'arrière (phénomène dû bien entendu à la force de pesanteur).
D'où en descente : vitesse air = vitesse sol + vitesse de rotation + vitesse
d'entraînement.
Et en montée : vitesse air = vitesse sol + vitesse de rotation – vitesse
d'entraînement.
Le poids de la pale P vient dans un cas s'additionner à la trainé f, et dans l'autre
cas s'en soustraire. Il y a donc asymétrie dès lors que le drone n'est pas à l'horizontal.
- Du fait de l'inclinaison du moteur, l'angle d'attaque de chaque pale est plus
élevé dans la phase de descente que dans la phase de montée. Cela
provoque plus de poussée d'un côté de l'hélice que de l'autre.
- Les deux facteurs précédents induisent le fait que le côté où la pale descend
est exposée à un flux d'air dit « propre » alors que l'autre subit un masquage
aggravant. Cela provoque une poussée accrue du coté de descente, et
réduit de l'autre, ce qui s'ajoute encore aux facteurs précédents, et on a
donc une boucle.
A noter que la principale différence entre la précession gyroscopique et la
poussée asymétrique des pales est que la première est une force momentanée qui
disparaît dès le prochain changement d'assiette ; alors que la seconde est à peu de
23
chose près permanente, de sorte que la direction réelle de l'appareil est toujours
décalée par rapport à la direction souhaitée.
Il est également intéressant de noter que la poussée asymétrique des pales et
la précession gyroscopique sont rapidement contrariées par une réduction de
puissance et par l'évitement de changement d'assiette trop brut.
Analyse mécanique
Afin de déterminer quelles sont les contraintes internes aux quadricoptère, il
nous a fallu réaliser une analyse mécanique, et déterminer, si ces contraintes
engendrent des problèmes, si une approche mécanique (classique) pouvait les
paliers.
Théorie de l'élément de la pale (Froude)
La théorie de l'élément de la pale a été initialement développée par Froude
qui assimile dans cette théorie l'élément de la pale à une plaque mince, soumise à
un vent relatif. Cette théorie a été améliorée depuis par Drzewiecki qui calcule les
caractéristiques aérodynamiques des hélices.
La pale est ici découpée en un nombre fini de tranches (éléments) à l'aide de
surfaces cylindrique.
On suppose que l'écoulement dans un anneau, limité par deux surfaces
voisines, est indépendant de l'écoulement dans les autres anneaux. Il est ainsi
possible d'obtenir de façon indépendante les forces de traînée dD, et les forces de
portance dL appliquée sur chaque tranche, sans tenir compte de l'écoulement dans
les éléments voisins.
Enfin, en intégrant les efforts élémentaires, on peut calculer es caractéristique
aérodynamique intégrales du rotor.
24
Pour obtenir l'effort élémentaire, chaque élément de la pale est donc
représenté comme une aile cylindrique (aile à allongement infini), avec une surface
dS = c*dr.
L'aile est soumise au vent résultant W, qui est une composition de la vitesse du vent à
l'infini Vinf et celle de rotation U = Ωr.
W = √Vinfini² + Ω²r² , c’est la vitesse relative en m/s (pas le travail)
Vinfini est la vitesse à l’amont en m/s.
Ω = vitesse angulaire en rad /r.
r = rayon local, correspond au r sur le schéma précédent
L'angle d'incidence α est calculé à partir de l'angle d'écoulement φ =
arctan(Vinf / U), et l'angle de calage de la pale β : α =(φ-β).
La portance et la traînée peuvent maintenant être calculées à partir des
formules :
𝑑𝐿 = ½ . ρ . W2. CL . α . c . dr
𝑑𝑆 = ½ . ρ . W² . CD . α . c . dr
Où CL et CD sont les coefficients, respectivement, de traînée et de portance
du profil d'aile.
Les valeurs de ces coefficients dépendent de l'angle d'incidence entre la corde du
profil et la vitesse résultante. De façon générale, ces coefficients sont obtenus à
partir d'essais de profils ou des simulations numériques prenant en compte la
viscosité du milieu ; dans notre cas la méthode de recherche des coefficients par
essais nous a semblé être plus facilement réalisable que la seconde méthode, qui
nécessiterait des moyens d'envergures à son application.
25
Afin d'obtenir la force tangentielle et la force axiale, appliquée à chaque
élément de la pale, on projette les forces de traînée et de portance sur le plan de
rotation et sur l'axe de rotation :
𝑑𝐹𝑎 = ½ . 𝜌 . 𝑊² . [ CL . 𝛼 . 𝑐𝑜𝑠 𝛽 + CD . 𝛼 . 𝑠𝑖𝑛 𝛽 ] . 𝑐 . 𝑟 . 𝑑𝑟
𝑑𝐹𝑡 = ½ . 𝜌 . 𝑊² . [ CL . 𝛼 . 𝑠𝑖𝑛 𝛽 − CD . 𝛼 . 𝑐𝑜𝑠 𝛽 ] . 𝑐 . 𝑟 . 𝑑𝑟
Finalement l'intégration de ces forces le long de la pale, du pied à l'extrémité
permet d'obtenir la force axiale et la puissance du rotor.
En prenant en compte le nombre de pale N et la vitesse angulaire du rotor Ω, on
obtient la force axiale Fa et la poussée P (en Watts) :
𝐹𝑎 = ½ . 𝜌 . 𝑁 . ∫ [𝑟𝑝, 𝑅] ( 𝑊² . [ CL . 𝛼 . 𝑐𝑜𝑠 𝛽 + CD . 𝛼 . 𝑠𝑖𝑛 𝛽 ] . 𝑐 . 𝑟 . 𝑑𝑟 )
𝑃 = ½ . 𝜌 . 𝑁 . ∫ [𝑟𝑝, 𝑅] ( 𝑊² . [ CL . 𝛼 . 𝑠𝑖𝑛 𝛽 − CD . 𝛼 . 𝑐𝑜𝑠 𝛽 ] . 𝑐 . 𝑟 . 𝑑𝑟 )
La théorie de l'élément de la pale donne des résultats satisfaisant à condition
que les vitesses induites soient faibles.
Théorie de l'hélice
Comme la théorie de l'élément de la pale ne nous convient pas totalement
nous nous sommes alors penchés sur la théorie de l'hélice, plus générale, et qui ne
prend pas en compte le profil des pales.
Soient (i) l'angle d'incidence de la pale, (θ) l'angle de pas et (β) l'angle de
conicité.
26
Plus l'angle d'incidence augmente, plus ρ us la portance augmente, jusqu'à une
valeur limite où le profil décroche. Au décrochage, la portance s'écroule et la
traînée croît brutalement.
La vitesse en chaque point de la pale augment proportionnellement à
l'éloignement de l'axe de rotation, et la portance croît en fonction du carré de la
vitesse.
La vitesse de rotation de la pale vaut : ωR, V est la vitesse de la pale et Vt la
vitesse de translation.
27
La résultante aérodynamique en hauteur Rz est : Rz = ½ . ρ . S . V² . CZ . ẑ
ρ = masse volumique du fluide du milieu en Kg/m3
S = maître couple en m²
V = vitesse en m/s
CZ = coefficient portance
Conclusion de l'analyse
Dans le cadre de notre projet, nous avons préféré substitué la résolution
mécanique de l'instabilité du drone par une résolution mathématique utilisant un
asservissement PID.
Ce choix est dû à la quantité de traitement qu'il n'est pas possible de réaliser avec le
matériel présent sur le drone ou avec le budget qu'il nous est fourni. De plus la
complexité des équations demanderait trop de temps pour pouvoir avoir un vol
stabilisé dans les délais impartis.
Dans la prochaine partie nous aborderons donc la solution de stabilisation par
PID que nous avons implémenté de façon concrète, et nous étudierons également
la recherche des coefficients nécessaires à sa mise en place.
PID (Proportionnel, Intégral, Dérivé)
Pour pouvoir obtenir un asservissement satisfaisant et applicable sur notre
matériel, le PID constitue une solution ad-hoc.
Afin de pouvoir éviter une mise en équation totale du quadricoptère nous
avons dû nous pencher sur les différents algorithmes de stabilisation. Au cours ces
recherches, il est apparu que dans notre cas une méthode semblait parfaitement
adaptée : le PID, respectivement Proportionnel, Intégral, Dérivé.
Cette méthode semblait présenter un double avantage, elle était d'un part
robuste et fiable car largement éprouvée dans un large panel de contextes et
d'autre part elle semblait assez facile à mettre en œuvre.
Principe du PID : le principe du PID est relativement simple. Lorsque que le
système étudié – ici le drone – se trouve déséquilibré, l'algorithme envoie une
28
commande qui donne une réaction dont le sens est opposée à celui déséquilibre, et
ce afin que le drone retrouve l'état souhaité.
A première vue cela peut sembler simple à mettre en œuvre : il suffit,
d'apparence, que la réponse envoyée soit proportionnelle à l'erreur provoquée par
le déséquilibre pour que le système soit stabilisé. Toutefois si l'on se contente d'un
algorithme aussi simple, on se rend vite compte qu'à défaut d'être stable, le
quadricoptère réagit souvent trop lentement.
De façon à augmenter les performances de l'algorithme il nous faut ajouter
au terme directement proportionnel (P), un terme proportionnel à la dérivée de
l'erreur (D).
Ce second terme permet alors au système de regagner plus vite son état stable et
règle ainsi le problème de réactivité du système.
Mais encore un fois, les choses restent là encore imparfaites : le système réagit en
effet souvent trop brusquement donnant lieu à des oscillations (parfois même
explosives).
Afin d'obtenir une réponse plus stable du système un dernier terme doit donc
être ajouté.
Ce terme est quant à lui proportionnel à l'intégrale de l'erreur dans le temps, c'est le
« I ».
Lorsque ces 3 termes sont présents le PID est complet et le système peut enfin être
stable.
Si le principe de l'algorithme s'arrête là et demeure assez simple une des
grandes difficultés qu'il induit réside dans la détermination des trois coefficients de
proportionnalité permettant de calculer chacun des termes du PID. Ces coefficients
sont généralement nommés Kp, Kd et Ki.
Leur détermination est dans la plupart des cas fruit d'une démarche entièrement
empirique.
Il est préconisé de fixer d'abord le Kp de sorte de la réponse soit correcte, puis le Kd
afin qu'elle soit suffisamment rapide et en dernier lieu le Ki jusqu'à obtenir une
stabilité suffisante.
Au sein d'un quadricoptère, un seul PID ne suffit pas, il faut en effet asservir le
drone à la fois en hauteur et sur trois angles (lacet, tangage et roulis). Nous avons
donc décidé dans un premier temps de ne pas traiter le lacet qui ne nous a pas
29
semblé être prioritaire, en effet une combinaison du tangage, du roulis et de la
hauteur permettent déjà un déplacement sur les 3 axes de l'espace tridimensionnel.
La stabilisation en hauteur est simple à vérifier : si on place le drone trop bas
par rapport à sa position de consigne, il doit augmenter la vitesse de rotation de tous
ces moteurs simultanément pour s'élever. Si on dépasse la position des consignes les
moteurs doivent alors ralentir.
Les stabilisations en tangage et en roulis sont régies par le même principe. Si
l'on incline le drone en suivant l'axe avant/arrière ou l'axe gauche/droite, le drone
doit augmenter la vitesse des deux moteurs abaissés et diminuer celle des moteurs
surélevés afin de se retrouver à nouveau à la position de consigne (l'implication de
deux moteurs tient ici à la configuration en X du drone).
Enfin la stabilisation en lacet consiste simplement à contrôler la rotation du
quadricoptère autour de son centre de gravité et dans le plan formé par les
moteurs. Pour cela il faut intervenir sur les vitesses des quatre moteurs en augmentant
la vitesse de deux moteurs (opposés sur le drone) et diminuer celle des deux autres.
La stabilisation en lacet utilise le fait que les moteurs tournent dans des sens différent
et induisent donc des couples opposés. Par exemple, pour avoir un couple du
système quadricoptère positif, on augmente la vitesse de rotation moteurs ayant un
couple positif et abaisse celle des moteurs ayant un couple négatif, et inversement
pour avoir un couple négatif.
Concrètement, dans notre cas, nous avons dans un premier temps réalisé une
modélisation primitive de la physique du drone dans un tableur. Nous avons ensuite
tenté d'ajuster les coefficients jusqu'à obtenir un système stable. Nous avons ensuite
implémenté nos algorithmes sur le drone et avons procédé avec prudence à des
tests.
PID en angle
30
PID en hauteur
On peut observer l'action théorique de l'application d'un PID pour la suppression des
oscillations. Dans la courbe du PID angle comme celle du PID hauteur on a : en bleu
la consigne, et en rouge la valeur mesurée.
Il est apparu rapidement que les résultats déterminés dans le tableur étaient trop
grossiers pour être appliqués sur le modèle réel. Nous avons donc procédé à une
nouvelle série d'expérimentations qui fût relativement longues du fait des
précautions qu'il nous a fallu prendre pour ne pas risquer d'endommager le drone.
Une autre difficulté de ces expérimentations résidait dans la difficulté à juger
sans banc de test ni moyen de mesure spécifique de l'impact réel des modifications
réalisées sur le système.
Au cours de ces expérimentations nous avons constaté qu'une partie de nos
obstacles à la stabilisation était liée à un problème bien différent de ceux que nous
envisagions, le générateur de laboratoire que nous utilisions ne délivrait en effet plus
un courant suffisant pour permettre au drone de se stabiliser. L'apport de courant
nécessaire à l'augmentation de puissance de certains des moteurs entraînait en
effet une pénurie sur les autres. Il est donc bon de noter qu'il faut s'assurer d'avoir
assez de puissance pour appliquer un PID, puisque celui-ci en nécessitera plus dès
son application.
Après des heures à rechercher des coefficients en adéquation avec le profil
de notre quadricoptère, nous sommes parvenus à obtenir une stabilisation sans
doute trop imparfaite pour permettre le vol prolongé du drone dans un espace
restreint, mais néanmoins suffisamment satisfaisante pour que nous décidions de
nous en tenir là et mettre à profit notre temps dans la poursuite des recherches sur
d'autres parties de notre projet.
31
Formules associées au PID :
Erreur i = consigne - valeur mesurée i
Dérivée i = (valeur mesurée i – valeur mesurée i-1) / (ti - ti-1)
Intégrale i = Intégrale i-1 + Erreur i * (ti – ti-1)
Erreur i *= Kp
Erreur i += Intégrale i * Ki
Erreur i -= Dérivée * Kd
Pistes d'optimisations
Cohen-Coon et Ziegler-Nichols sont des algorithmes offrant la possibilité
d’automatiser la détermination des coefficients du PID.
32
Implémentation embarquée
La RPDL
La RPDL, Renesas Peripheral Driver Library, est une bibliothèque de périphériques
fournie par Renesas permettant de manipuler ces derniers avec des fonctions de
haut niveau.
Cela permet un gain de temps très important puisque l’utilisation est très largement
simplifiée, et les fonctions sont bien documentées.
Exemple : création d’une temporisation :
Par exemple, voici le code utilisé pour générer une temporisation de 100 ms avec un
timer :
R_CMT_CreateOneShot(1,PDL_NO_DATA,0.1,PDL_NO_FUNC,0);
La fonction R_CMT_CreateOneShot permet de configurer un timer pour un
évènement unique.
Ses paramètres sont :
- Le numéro du timer à utiliser, un entier compris entre 0 et 3 inclus, ici le 1.
- La configuration à utiliser. Ici, on utilise la constante PDL_NO_DATA qui permet
d’utiliser les valeurs par défaut.
- Le temps d’attente en secondes, dans un float.
- La fonction à appeler à la fin de l’attente. Ici on souhaite simplement
continuer l’exécution du flux courant donc on utilise la constante
PDL_NO_FUNC.
- La priorité de l’interruption (la fonction appelée à la fin). Le paramètre est
ignoré s’il n’y en a pas, comme dans le cas présenté.
Exemple : envoi de messages via le port série :
Voici un exemple plus important avec une partie de l’envoi de la configuration au
module wifi :
R_SCI_Send(2,PDL_NO_DATA,"AT+WD\r\n",0,PDL_NO_FUNC);
R_CMT_CreateOneShot(2,PDL_NO_DATA,0.1,PDL_NO_FUNC,0);
R_SCI_Send(2,PDL_NO_DATA,"AT+WM=2\r\n",0,PDL_NO_FUNC);
R_CMT_CreateOneShot(2, PDL_NO_DATA,0.1,PDL_NO_FUNC, 0);
R_SCI_Send(2,PDL_NO_DATA,"AT+WAUTH=0\r\n",0,PDL_NO_FUNC);
Ici, on alterne un envoi de trame série avec une attente de 100 ms. Nous avons dû
mettre en place cette temporisation pour s’assurer que le module wifi ait le temps
de traiter la configuration, puisqu’avant cet ajout le module n’arrivait pas à gérer la
réception de toutes les informations.
33
La fonction R_SCI_Send permet l’envoi d’un message sur le port série paramétré
auparavant.
Ses paramètres sont :
- Le port à utiliser, un entier compris entre 0 et 6 inclus mais différent de 4.
- La configuration à utiliser. Ici, on utilise la constante PDL_NO_DATA qui permet
d’utiliser les valeurs par défaut.
- L’adresse de début du message à envoyer, sous forme d’un uint8_t (créé ici à
partir d’un tableau de char)
- Le nombre d’octets à envoyer dans le cas d’un envoi de données binaires. Ici
on le met à 0 puisqu’on envoie des données ASCII, il repère tout seul la fin de
la chaîne.
- La fonction à appeler à la fin de l’envoi. Ici on souhaite simplement continuer
l’exécution du flux courant donc on utilise la constante PDL_NO_FUNC.
- La priorité de l’interruption (la fonction appelée à la fin). Le paramètre est
ignoré s’il n’y en a pas, comme dans le cas présenté.
Exemple : paramétrage du port série :
Cet ensemble de fonctions permet de paramétrer le port série et l’interruption de
réception.
R_SCI_Set active le port sur lequel série on travaille, ici le port représenté par la
constante PDL_SCI_PIN_SCI2_A.
R_SCI_Create crée le port au niveau logiciel. Ses paramètres sont :
- Le numéro de port série à utiliser.
- Configuration du channel : 8 bits, sans parité, 1 bit d’arrêt.
- Le taux de transfert en bauds
- La priorité de l’interruption de réception
R_SCI_Receive permet d’activer la fonction d’interruption pour la réception. Ses
paramètres sont :
- Le numéro de port série à utiliser.
- La configuration à utiliser. Ici, on utilise la constante PDL_NO_DATA qui permet
d’utiliser les valeurs par défaut.
- Le buffer de récupération des caractères.
- Le nombre de caractères à lire avant de lancer l’interruption.
- L’interruption à déclencher le nombre atteint.
R_SCI_Set(PDL_SCI_PIN_SCI2_A);
R_SCI_Create(2,PDL_SCI_8N1,115200,5);
R_SCI_Receive(2,PDL_NO_DATA,&gSCI_RXBuffer,1,CB_SCIReceive,P
DL_NO_FUNC);
34
- Une deuxième fonction d’interruption à exécuter en cas d’erreur.
Implémentation sur l’Arduino
L’Arduino permet de programmer en C/C++ pour le code à proprement
parler et nous fournit des bibliothèques de base pour la gestion des périphériques
(SPI, I2C, IO,…). Nous avons également utilisé des bibliothèques C++ fournies par le
projet Arducopter afin de gagner du temps dans un premier temps. Ces codes de
haut niveau ont permis de faciliter l’utilisation des périphériques intégrés. Une des
tâches futures pourrait être de réécrire ces bibliothèques.
Par rapport au projet, nous avons seulement utilisé les bibliothèques fournies
pour récupérer les valeurs brutes des périphériques. Nous avons ensuite implémenté
tous les algorithmes présentés précédemment ainsi que les classes nécessaires au
fonctionnement des nouveaux périphériques comme les sonars et le protocole de
communication.
L’avantage du développement en C/C++ a été de pouvoir programmer sur
un ordinateur afin d’avoir un vrai débuggeur et ensuite d’obtenir un code
facilement adaptable au RX ou l’Arduino. Nous suivons ainsi l’objectif de généricité
du code.
L’implémentation du traitement de la centrale inertielle a nécessité en plus le
développement d’une classe de gestion des matrices avec les différentes
opérations nécessaires. Quant à la gestion du protocole, il respecte celui défini dans
ce projet.
Finalement, notre programme principal est un programme de calibrage des
différentes PID, où en temps réel nous pouvons modifier les différents coefficients et
la vitesse. A côté, des programmes annexes permettent de tester les différents
composants du drone.
35
Communications
Protocole de communication Wifi
La mise au point du protocole de communication Wifi, bien qu'apparemment
simple, était une tâche qui comportait tout de même certaines difficultés. Au
premier rang de ces difficultés figure la nécessité de réaliser un protocole
suffisamment évolutif pour s'adapter aux évolutions futures du projet. De plus le
protocole Wifi devant jouer le rôle d'interface entre les travaux de notre équipe et
ceux de l'équipe en charge du simulateur, il se devait de répondre autant que
possible aux attentes des deux équipes.
Le protocole de communication présenté ci-après constitue le protocole final
pour notre projet, toutefois il a été prévu qu'à l'avenir il puisse être remplacé par un
protocole repensé pour offrir une plus grande vitesse de communication. Le
protocole présenté ici est donc un protocole simplifié afin d'offrir une plus grande
facilité de débogage lors des phases de développement.
Dans le but d'éviter une trop grande lenteur du protocole, il fut décidé de
privilégier les communications UDP aux communications TCP.
Valeurs numériques
Toutes les valeurs numériques (récupérées depuis un capteur ou transmises
comme consigne) doivent être converties de sorte que leurs valeurs varient entre -
32767 (la valeur minimale réelle est en fait -32678 mais -32767 a été préféré pour des
raisons de symétrie) et 32767 (valeur maximale théoriquement atteignable).
Un champ de valeur aussi important doit assurer une précision suffisante pour
les calculs à effectuer par la suite.
L'usage de int16_t définis dans stdint.h a donc été jugé pertinent dans le
cadre des manipulations de ces valeurs.
Une formule permettant d'obtenir un formatage efficace est alors :
Val_formatée = (65534 . (Val_Réelle - Val_Min)/(Val_Max - Val_Min)) – 32767
Cette formule rendra des valeurs entre 32767 et -32767.
Les calculs doivent autant que possible être réalisés en float afin d'éviter des pertes
importantes au cours de la division.
La formule de récupération des valeurs est alors :
Val_récup = (((Val_formatée + 32767) / 65534) . (Val_Max – Val_Min)) +Val_Min
36
Format général de la trame
Le format de trame choisi est le suivant :
<NUM_PAQUET><!><TYPE_TRAME><< ?>|<<:><VAL>[,VAL[,...]]>><!><CTRL_SUM><CRLF>
Avec :
<NUM_PAQUET> : numéro du paquet, auto-incrémental, sur 4 chiffres, non signé, en
décimal.
<!> : caractère "!" utilisé comme séparateur
<TYPE_TRAME> : suite de 2 caractères en ASCII indiquant les informations portées par
la trame (voir plus bas)
<< ?>|<<:><VAL>[,VAL[,...]]>> valant soit :
-- "?" dans le cadre de la demande d'une (série de) valeurs
-- ":" suivi d'une série de valeurs séparés par des virgules
<CTRL_SUM> consiste en la somme des valeurs ASCII de toute la trame jusqu'au
caractère "!" précédant cette somme ("!" inclus)
<CRLF> : caractères "\r\n" C'est la lecture de ces caractères qui indiquera la fin de
la trame.
Liste des TYPE_TRAME
Les TYPES_TRAME sont des suites de 2 caractères ASCII
TYPE_TRAME commençant par un 0
Ces types sont réservés à des fins de test et ne doivent pas être utilisé dans le cadre
d'une implémentation finale.
TYPE_TRAME commençant par un 1
Ces types sont réservés à la transmission des erreurs.
Identificateurs de trame
La liste des identificateurs actuellement attribués est disponible en annexe 1.
Exemples
On aura ainsi par exemple
0010!Gx?!513
correspond au dixième message échangé, le contrôleur demande au drone la
valeur de son gyroscope en x
37
0011!Gx:21!608
serait la réponse du drone
ou encore
0101!0B:21,22,58!828
qui serait le 101e message d'une série, utilisant un protocole de test (commençant
par 0) et renvoyant 3 valeurs
Le rôle des communications est primordial puisque chaque carte aura, à
terme, son propre rôle : ArduPilot comme macro-capteur, RX comme centre de
calcul et au bout un ordinateur pour envoyer les commandes ou une liaison avec le
simulateur.
Nous avons donc privilégié les connexions séries car elles sont simples à mettre
en œuvre et chaque carte possède plusieurs ports.
Communication TTL entre ArduPilot & RX
La mise en place des communications a été contrainte par le respect les
tensions utilisées. Le RX62T fonctionnant en 3.3V, il fallait donc diminuer la tension de
sortie du port UART2 de l’Arduino.
Il a suffi d’ajouter 2 résistances sur la broche TX : 1.5kΩ et 3.3kΩ. Il fallait
également faire la même démarche avec l’ordinateur lors de nos tests sans RX62T.
Nous utilisions un adaptateur USB/RS-232 qui sortait avec un connecteur DB9. Afin de
faire le pont entre ce connecteur et la carte Arduino, nous avons mis en place un
montage autour d’un MAX202.
Après l’adaptation des tensions, la connexion entre ArduPilot et RX est simple. Une
même masse, et la broche RX de l’un sur la broche TX de l’autre.
38
Bilan technique
Ces quatre mois de projet nous ont permis de réaliser de nombreuses choses,
bien que l’intégralité des objectifs n’ait pas été atteinte. En effet, les nombreuses
difficultés techniques rencontrées nous ont poussés à réviser nos objectifs, pour
finalement nous concentrer sur l’essentiel.
Ainsi, nous avons réussi à faire voler le drone avec le nouveau matériel, en utilisant la
carte ArduPilot, en contrôlant via la télécommande RC. De plus, nous avons
déterminé un algorithme de stabilisation efficace qui permet de stabiliser le drone
en lui donnant une consigne de hauteur, malgré d’éventuelles perturbations.
Nous avons aussi réussi à développer les premières fonctionnalités sur le RX62T, après
une période d’apprentissage nécessaire à la prise en main de ce nouveau
microcontrôleur et des outils associés. Nous avons réalisé un code fonctionnel pour
l’utilisation des ports série servant à la communication avec d’une part l’ArduPilot et
d’autre part le module WizFi 220.
Concernant ce dernier, nous avons défini un ensemble de commandes de
configuration qui permettent d’assurer un fonctionnement optimal et le plus simplifié
possible, en limitant les interventions de connexions aux seuls périphériques, plus aisés
de paramétrage.
39
Project Summary
Our project consisted in making a self-stabilized quad-copter
The global idea is to make a drone which can be either remote controlled with a
radio command or an android smartphone, or self-controlled using an Inertial
Measurement Unit and GPS coordinates. The drone must also be able to
communicate its sensors' data so its state can be seen in real time in a simulator
through Wi-Fi communication
This project was already started in previous years, but the lack of usable code as well
as the poor state of the existing drone forced us to restart everything from scratch
after making a complete and exhaustive analysis of the state of the existing project.
We decided to use an ArduPilot Mega, a microcontroller based on Arduino Mega,
with embedded IMU, magnetometers, GPS, and I/O pins to control the motors and
the radio command. But its Atmel chip wasn't powerful enough to process the
calculations needed, so we chose the Renesas RX62T as an embedded chip to
perform these calculations. The idea was to start coding everything on the Arduino,
then to move it step by step on the RX, so it would force us to do generic code which
could be used with any microcontroller and any peripheral.
Each of us four had a dedicate task: Benjamin had to find algorithms in order to
stabilize the drone, Pierre worked with the ArduPilot to create the code to use the
RC, the motors and the sensors, Axel defined protocols for communication between
the drone and its peripherals (simulator, Android remote control…) and Nicolas had
to create a configuration for the Wi-Fi chip and start coding with the new RX62.
We encountered various difficulties, mostly due to the material aspect of our project
: our syllabus deals with coding, including coding for embedded systems, but we
don’t have any electronics lectures, so we weren’t able to solve the problem we
were confronted to, or even find them. Moreover, the stabilization part requires
advanced knowledge in certain fields of mathematics and physics we didn’t have,
so we based our work on some PhDs’ and Masters’ theses.
At this date, we have reached some our goals, but several electronics issues prevent
us from finishing this project. So far, our achievements are the stabilization of the new
drone using the ArduPilot, some basic communication code executed on the
embedded RX62T, and an efficient configuration for the Wi-Fi module.
We strongly recommend continuing this project next year as we took care into
making an efficient and clear code. We also documented our work and researches
as we had at heart to provide an easy to maintain and improve project.
40
Bibliographie
- Kalman Filter for Beginners : with MATLAB Examples, Phil Kim and Lynn Huh
- Thèse I.Dobrev (Arts et métiers, 2009)
- Primary Propeller Forces, as pertaining to powered paragliding, Keith Pickersgill
Xplorer
- http://aeroquad.com/showthread.php?1167-Stable-Mode-Explained
- http://technicaladventure.blogspot.fr/2012/03/quadrocopter-firmware-4-
rotor-explained.html
- http://arduino.cc/
- http://code.google.com/p/arducopter/
- https://groups.google.com/forum/?fromgroups#!forum/diy-pid-control
- http://quadcopterpourlesnuls.over-blog.com/article-ardupirates-
77870656.html
- http://code.google.com/p/ardupirates/
- http://robots.dacloughb.com/
- http://fr.scribd.com/doc/45617335/Regulation-PID
- http://www.ferdinandpiette.com/blog/2011/08/implementer-un-pid-sans-
faire-de-calculs/
- http://jeremie.sangare.fr/coriolis_uav/pfe_coriolis_rapport_de_projet.pdf
- http://gnexkopter.gnexlab.com/dokumanlar/Rapport_PIP_Quadrirotor.pdf
41
Annexes
Annexe 1 : Identificateurs de trame
"Ca" suivi d'une série de 11 valeurs est utilisé pour envoyer l'ensemble des valeurs des
capteurs dans l'ordre suivant :
accéléro_x,accéléro_y,accéléro_z,gyro_x,gyro_y,gyro_z,magnéto_x,magnéto_y,
magnéto_z,baromètre,thermomètre
Accéléromètres
"Ax" suivi d'une valeur correspond à l'accéléromètre x
"Ay" suivi d'une valeur correspond à l'accéléromètre y
"Az" suivi d'une valeur correspond à l'accéléromètre z
"Aa" suivi de trois valeurs correspond aux valeurs des trois accéléromètres dans
l'ordre x,y,z
Gyroscopes
"Gx" suivi d'une valeur correspond au gyroscope x
"Gy" suivi d'une valeur correspond au gyroscope y
"Gz" suivi d'une valeur correspond au gyroscope z
"Ga" suivi de trois valeurs correspond aux valeurs des trois gyroscopes dans l'ordre
x,y,z
Magnétomètres
"Mx" suivi d'une valeur correspond au magnétomètre x
"My" suivi d'une valeur correspond au magnétomètre y
"Mz" suivi d'une valeur correspond au magnétomètre z
"Ma" suivi de trois valeurs correspond aux valeurs des trois magnétomètres dans
l'ordre x,y,z
Sonars
"Sf" suivi d'une valeur correspond au sonar avant (front)
"Sb" suivi d'une valeur correspond au sonar arrière (back)
"Sl" suivi d'une valeur correspond au sonar gauche (left)
"Sr" suivi d'une valeur correspond au sonar droit (right)
"Su" suivi d'une valeur correspond au sonar haut (up)
"Sd" suivi d'une valeur correspond au sonar bas (down)
"S6" suivi de 6 valeurs correspond à la valeur des 6 sonars (ordre : avant, arrière,
gauche, droite, bas, haut)
42
Autres capteurs
"B0" suivi d'une valeur correspond au baromètre
"TH" suivi d'une valeur correspond au thermomètre
"GP" suivi de 8 valeurs correspond aux valeurs du : latitude, longitude, vitesse,
direction, nombre de satellites, état du first fix, temps
Moteurs
Du drone vers le contrôleur
"M1" suivi d'une valeur correspond à la valeur actuelle du moteur 1
"M2" suivi d'une valeur correspond à la valeur actuelle du moteur 2
"M3" suivi d'une valeur correspond à la valeur actuelle du moteur 3
"M4" suivi d'une valeur correspond à la valeur actuelle du moteur 4
"Me" suivi de 4 valeurs correspond à la valeur actuelle des 4 moteurs (1,2,3,4)
"Mc" suivi d'une valeur correspond à la valeur actuelle de la consigne moteur
"M+" suivi de 5 valeurs correspond à la valeur actuelle des 4 moteurs suivi de la
consigne moteur
Du contrôleur vers le drone
"M1" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 1
"M2" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 2
"M3" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 3
"M4" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 4
"Me" suivi de 4 valeurs correspond à la valeur à atteindre pour les 4 moteurs (1,2,3,4)
"Mc" suivi d'une valeur correspond à la valeur à atteindre pour la consigne moteur
"M+" suivi de 5 valeurs correspond à la valeur à atteindre pour les 4 moteurs suivi de
la consigne moteur
43
Annexe 2 : Commandes de configuration du module Wifi
Voici la configuration adoptée pour le module WizFi 220. Les différentes
commandes sont détaillées dans la documentation du module.
AT+WD
AT+WM=2
AT+WAUTH=0
AT+NDHCP=0
AT+NSET=192.168.1.1,255.255.255.0,192.168.1.1
AT+WA=QuadNetwork,,8
AT+DHCPSRVR=1
AT+NSUDP=5000
ATA2
Configuration :
- Module en mode Point d'accès
- Pas d'authentification requise
- Serveur DHCP
- Réseau sans fil "SICopter"
- Ip 192.168.1.1, masque 255.255.255.0
- Serveur UDP mis en place sur le port 5000
Signification des différentes commandes :
AT+WD
Réinitialise la configuration.
AT+WM=2
Active le mode point d'accès.
AT+WAUTH=0
Pas d'authentification.
AT+NDHCP=0
Désactive le client DHCP
AT+NSET=192.168.1.1,255.255.255.0,192.168.1.1
Paramétrage du réseau sur le module :
IP : 192.168.1.1, Masque : 255.255.255.0 ,Passerelle : 192.168.1.1
AT+WA=SICopter,,8
Définit le SSID "SICopter" sur le canal 8
AT+DHCPSRVR=1
Active le serveur DHCP.
AT+NSUDP=5000
Active un serveur UDP sur le port 5000.
Pour lancer un serveur TCP, remplacer par "AT+NAUTO=1,1,,5000"
ATA2
Active la connexion et bascule en mode DATA
44
Annexe 3 : Schéma RX62T
45
Annexe 4 : Schéma Module Wifi
46
47
