Projet QuadriCoptère¶

Introduction¶

Étapes de la conception du drone¶

Carte électronique¶

Communication¶

Android¶

Simulateur du drone¶

Modélisation 3D¶

Asservissement du Drône¶

Bendaoud-Joubert Amaury Béreaux Aurélien Boudin Julie Chambodut Pierre Donaux Baptiste Godichaud Félix Jallet Anthony Kayhal Walid
Lesage Logan Mikotajewski Maxime
Projet Quadricoptère
Année 2011-2012
2 | P a g e
Projet Quadricoptère – mars 2012
Donnons autorisation à l'IUT de Clermont-Ferrand de diffuser sur son site Intranet notre rapport.
3 | P a g e
Projet Quadricoptère – mars 2012
Sommaire
Remerciements…………………………………………………………………………………………………………………… 5 Introduction………………………………………………………………………………………………………………………… 6
Présentation synthétique du projet…………………………………………………………………………………….. 7
1 - Gestion de projet……………………………………………………………………………………………………………. 8
1.1. Diagramme de GANTT
1.2. Gestion de La Forge 2 - Construction du drone…………………………………………………………………………………………….……. 10
2.1. Matériel
2.2. Pilotage du drone avec la radiocommande 2.3. Les différentes étapes de la construction
3 - Microcontrôleur Renesas……………………………………………………………………………………………... 12
3.1. Matériel
3.2. Fonctionnement
3.3. Programmation
3.4. Difficultés
4 - Carte électronique et asservissements du drone…………………………………………………………… 15 4.1. Modification de la carte
4.1.a. Portage sous KiCad
4.1.b. Actualisation de la carte 4.2. Asservissements
4.2.a. Asservissement en altitude
4.2.b. Développement du code permettant d'utiliser le sonar
4.2.c. Asservissement en x et y
5 - Application Android……………………………………………………………………………………………………… 21
5.1. Présentation de l’environnement de développement
5.2. Différences entre tablette et téléphone
5.3. Fonctionnement de l’application
5.4. Autonomie
5.5. Gestion de la caméra
5.5.a. Configuration
5.5.b. Fonctionnement
6 - Communications…………………………………………………………………………………………………………… 26
6.1. Routeur 6.2. Module Wi-Fi
6.2.a. Présentation
6.2.b. Configuration
6.3. Le Protocole de communication 6.4. Différents types de communication
6.4.a. Communication Module WiFi - PC par port série
6.4.b. Communication directe Android-PC
6.4.c. Communication écriture sur le port série du microcontrôleur
6.4.d. Gestion du simulateur du simulateur par le clavier
7 - Modélisation 3D…………………………………………………………………………………………………………… 33 7.1. Outil Blender
4 | P a g e
Projet Quadricoptère – mars 2012
7.2. Modélisation
7.3. Adaptation des modèles à Blender
7.4. Gestion de la Forge 8 - Simulateur…………………………………………………………………………………………………………………… 40 8.1. Présentation générale de cette partie du projet
8.2. Particularités d'un programme incluant Raydium
8.3. Déroulement du projet Bilan Technique……………………………………………………………………………………………………………….. 45 Conclusion……………………………………………………………………………………………………………………….. 46 Résumé en anglais……………………………………………………………………………………………………………. 47 Bibliographie……………………………………………………………………………………………………………………. 48
Lexique…………………………………………………………………………………………………………………………….. 49 Annexe…………………………………………………………………………………………………………………………….. 50 Page d'évaluation………………………………………………………………………………………………………….…. 51
5 | P a g e
Projet Quadricoptère – mars 2012
Remerciements Nous remercions : - Monsieur LAFFONT et Monsieur KAUFFMANN pour nous avoir encadrés tout au long de ce projet, et également pour avoir financé personnellement le matériel pour la réalisation du drone ainsi que pour nous avoir permis d’utiliser un AR Drone pour nos tests. - Monsieur GIRAUD pour nous avoir aidé dans la rédaction et la présentation de notre projet. - Monsieur COUDERC, pour nous avoir aidé et laissé à disposition sa salle et son matériel pour la construction du drone.
6 | P a g e
Projet Quadricoptère – mars 2012
Introduction
Notre projet consistait à réaliser matériellement un drone quadricoptère ainsi que le simulateur 3D représentant celui-ci dans un environnement virtuel. L'objectif final était de le piloter à partir d'une télécommande (hertzienne – FM) ou par un produit disposant d'Android (tablette ou smartphone) via Wi-Fi. L'autre partie importante était de simuler le comportement du quadricoptère. Le projet a été encadré par deux tuteurs, à savoir M. LAFFONT et M. KAUFFMANN.
Notre groupe de projet était composé de dix étudiants. Nous nous sommes répartis le travail en cinq groupes de manière à travailler en binômes. Les différents objectifs étaient les suivants :
 Un premier binôme a porté le schéma de la carte électronique sous le logiciel KiCad dans le but d’intégrer les gyromètres et accéléromètres, si possible de la simplifier pour diminuer sa taille, et par la même occasion de diminuer sa consommation électrique. La seconde mission consistait à développer un programme gérant l'élévation et l'asservissement du drone. Ce code avait pour but principal d'être intégré dans la carte mais également, par la même occasion, d'être utilisé par le simulateur.
 Le second binôme a développé une application Android. Ces deux personnes se sont également occupé de structurer la liaison entre l'application Android et les moteurs. La tablette avait pour but d'envoyer les informations sur l'évolution des déplacements à suivre par le drone. Elle devait aussi être en mesure d'afficher les coordonnées et autres informations envoyées par le drone.
 Le troisième duo a mis en marche le module Wi-Fi permettant l’émission et la réception des données. Il s'agit de la charnière indispensable, nécessaire pour réaliser en intégralité le projet. Le module permet d’établir une communication entre une tablette ou un smartphone Android et le drone. Installé sur le drone, il devait permettre au microcontrôleur d'envoyer les coordonnées de l'objet volant et de recevoir les paramètres concernant l'évolution des déplacements.
 Le quatrième binôme a travaillé sur la modélisation 3D du drone et de son environnement, en utilisant Blender. Cette partie devait être intégrée dans le simulateur de manière à reproduire visuellement le drone dans un environnement 3D. Il leur a également était demandé de gérer la Forge qui était utilisé par toutes les personnes du groupe.
 Le dernier binôme a travaillé sur le moteur du simulateur, à savoir la gestion des forces, la poussée des moteurs, la gravité... Avec le binôme précédent, le simulateur final devait pouvoir représenter le drone conçu par nos soins en intérieur et simuler son comportement. L’intérêt était double, permettre à l’utilisateur final de constater son comportement, et donc de s’entraîner. Le second intérêt était pour l’équipe de développement, qui a pu essayer différents algorithmes et programmes, de l’implémentation de la stabilisation au contrôle du drone virtuel, grâce à un terminal Android. Le simulateur nous a permis de tester nos avancées sans mettre en danger le quadricoptère.
7 | P a g e
Projet Quadricoptère – mars 2012
Présentation synthétique du projet :
Notre projet fait suite à un projet tuteuré de l’année dernière portant sur la réalisation d’un simulateur pour l’AR Drone de la société Parrot. Nos objectifs étaient donc de construire un drone physique, d’améliorer le simulateur existant, et d’établir une connexion entre une application Android et ces deux supports.
A la base, nous étions deux équipes de cinq : une sur le drone et l’application Android, et une sur la simulation et la modélisation. Néanmoins, la complémentarité des deux projets ne faisant aucun doute, nous avons décidé d’un commun accord avec nos tuteurs de rassembler les deux projets et de faire une refonte de l’attribution des tâches, de sorte que l’on puisse travailler organisés en binômes.
Ce projet tuteuré est remarquable, car il regroupe des domaines diamétralement opposés, tels que l’informatique embarquée, la modélisation en 3D, la programmation Android, la programmation en C, utilisant une bibliothèque orientée vers la simulation, ainsi que l'établissement d’un réseau reliant plusieurs périphériques.
Ces domaines très différents sont néanmoins complémentaires dans le cadre de notre projet.
8 | P a g e
Projet Quadricoptère – mars 2012
1 - Gestion de projet
1.1. Diagramme de GANTT
Figure 1 : Diagramme de GANTT du projet
9 | P a g e
Projet Quadricoptère – mars 2012
1.2. Gestion de La Forge
Afin de faciliter la communication entre les différents binômes, nous avons utilisé le logiciel TortoiseSVN. Celui-ci permet le « subversionning » des fichiers. Ainsi nous avons pu versionner nos fichiers et principalement le code du simulateur, puisque celui-ci était utilisé et régulièrement modifié par plusieurs binômes ainsi que par l’un de nos tuteur. Ce logiciel fonctionne sur la base d’ajouts de fichiers « ADD », puis de « COMMIT » permettant aux utilisateurs de ces fichiers de les mettre à jour pour l’ensemble du projet. De plus pour récupérer la dernière version du projet il suffit d’utiliser le « SVN UPDATE ». Cet outil nous a fortement facilité la tâche.
10 | P a g e
Projet Quadricoptère – mars 2012
2 - Construction du drone
2.1. Matériel
Nous avons eu besoin d’un grand nombre d’équipements pour la réalisation de ce quadricoptère. Tout d’abord, nous avons commandé les pièces pour la construction du drone sur internet, que nous avons assemblées nous-même, comme vous pouvez le voir sur les schémas de la partie suivante. Plus précisément, nous avons commandé 4 moteurs, une dizaine d’hélices, 4 contrôleurs (un par moteur), une carte préprogrammée, ainsi qu’une batterie.
Ensuite pour certains tests nous avons utilisé le matériel de l’année précédente, c’est-à-dire un moteur monté sur une structure en bois, équipé d’un sonar, et également une radiocommande et un récepteur. Afin de stabiliser le drone, en plus du sonar nous avions également un capteur barométrique.
D’autre part, nous avons également récupéré la carte embarquée qui a été réalisée l’année passée, que nous devions reprendre et sur laquelle nous il fallait ajouter des gyroscopes, ainsi que le module Wi-Fi, afin que ce soit la carte finale embarquée sur le drone. Le microcontrôleur, qui contient le programme embarqué, devait lui aussi être installé sur cette carte.
Tous ces composants, et équipements seront décrits dans leur partie du dossier correspondante.
2.2. Les différentes étapes de la construction
1- Assemblage de la structure en bois léger avec de la colle.
2- Soudage des contrôleurs aux moteurs et fixation des moteurs au bout de chaque bras du drone. Et installation de la carte embarquée.
3- Installation du récepteur de la radiocommande et des hélices.
4- Montage de pieds afin de surélever le drone.
(cf. figure page suivante)
11 | P a g e
Projet Quadricoptère – mars 2012
Figure 2 : Etapes de la construction du drone (de gauche à droite et de haut en bas)
2.3. Pilotage du drone avec la radiocommande
Dans un premier temps, nous avons donc assemblé le quadricoptère, grâce à l’aide de M. Couderc, qui nous a mis à disposition sa salle et son matériel, afin, notamment, de souder les contrôleurs, de fixer les moteurs sur la structure, ou encore de réparer la batterie de la radiocommande.
Autrement dit, notre premier objectif physique par rapport au drone, était de pouvoir le piloter grâce à la radiocommande. Pour cela, nous avons utilisé la carte préprogrammée, commandée sur Internet, ainsi que la radiocommande qui provient du projet de l’an passé.
Dans ce but, nous avons rencontré un problème majeur par rapport au matériel. En effet, la configuration du matériel chinois n’est pas forcément évidente. Ceci est dû aux différences de normes entre nos deux continents.
12 | P a g e
Projet Quadricoptère – mars 2012
3 - Microcontrôleur Renesas
3.1. Matériel
Afin de développer la partie sur microcontrôleur, nous nous sommes servis du matériel que nous avons utilisé tout au long de l’année en TP de système embarqué. Nous avons choisi de programmer sur microcontrôleur Renesas M32C, car il s’agissait d’un kit de développement que nous connaissions très bien. De plus, la documentation, qui est une part importante dans ce type de développement, nous était déjà familière. Ainsi qu’au niveau logiciel, où l’IDE utilisé était également celui utilisé lors des TP, c’est-à-dire High-Embedded Workshop (HEW). Cet IDE est fourni pour développer sur microcontrôleur Renesas.
3.2. Fonctionnement général
Le microcontrôleur Renesas est le coeur du drone. En effet, il s’agit de la partie qui va recevoir les données provenant du module Wi-Fi, les analyser et renvoyer l’état du drone par le module Wi-Fi.
L’analyse de ces données va permettre au drone d’évoluer dans son environnement conformément aux données rentrées par l’utilisateur, mais elle va également lui permettre de se stabiliser et de rester en vol même sans intervention humaine.
Le microcontrôleur dispose également de nombreuses entrées/sorties qui lui permettent d’analyser l’environnement grâce à un sonar, des gyromètres et une caméra. Les données venant de ces périphériques une fois traitées sont renvoyées vers l’utilisateur pour l’informer de la situation courante du drone.
3.3. Programmation
Concrètement, la programmation d’un tel programme s’effectue en deux parties. La première étant la configuration du microcontrôleur, et la seconde l’implémentation des fonctions.
Le contrôle des moteurs au travers du microcontrôleur Renesas se fait en envoyant des impulsions. En effet, nous avons dû configurer le microcontrôleur pour pouvoir lui envoyer des impulsions. C’est à dire que pour actionner le moteur nous envoyons, une impulsion électrique.
Nous sommes donc aujourd’hui uniquement capables de traiter les informations liées à l’altitude afin d’agir sur un moteur, plus précisément de le faire accélérer et ralentir.
Le fonctionnement technique du programme est que lorsque le programme reçoit un ordre de monter, alors il actionne les moteurs pour s’élever d’une certaine hauteur et reprend son régime stationnaire, et pour descendre c’est le même principe sauf qu’il suffit de faire ralentir les moteurs.
13 | P a g e
Projet Quadricoptère – mars 2012
Pour exécuter tout cela, nous avons dû utiliser le timer ta1 du microcontrôleur, que nous avons programmé en sortie, en mode one-shot. Les périodes des impulsions que l’on peut envoyer au moteur sont comprises entre 0.5ms et 1.5ms, et les valeurs à affecter au registre ta1 (sortie) sont comprises entre 4000 et 8000. Pour nos tests, nous avons alors découpé cette plage en dix, ce qui nous donnait des paliers de 400. Par la suite, nous avons découvert que la valeur à affecter afin de démarrer le moteur est 400, ce qui veut donc dire qu’il faut dans un premier temps affecter 400 au registre ta1 pour pouvoir interagir avec le moteur. Une fois cette initialisation effectuée, nous pouvons faire varier la vitesse du moteur grâce à l’application Android, par palier de 400.
Ci-dessus, nous pouvons voir la partie du code correspondant à l’explication précédente.
« alt » est récupéré dans la variable globale reception_RS, qui est ce que l’on récupère du port série.
Dans le registre ta1 nous mettons la valeur souhaitée. Afin d’activer et lancer le timer il faut mettre « 1 » dans ta1os. Et la dernière ligne correspond à l’affectation de la valeur correspondant à l’altitude.
Figure 3 : Code de l’interruption du port série
Ci-dessus, le code correspondant à la réception des données sur le port série, qui est une fonction d’interruption.
14 | P a g e
Projet Quadricoptère – mars 2012
Pour lire une donnée sur le port série, il faut récupérer cette valeur dans le registre « u0rb » (1ère ligne). Ensuite, nous contrôlons si le paquet reçu est bien la valeur de l’altitude en vérifiant que la lettre correspondant au type de valeur est bien « Z ». Une fois cette vérification effectuée, « Altitude », qui est un booléen est mis à 1. Et si « Altitude » est égal à 1, alors on met le paquet reçu dans « reception_RS », que l’on traite dans la partie de code vu précédemment.
Pour pouvoir tester ce programme, nous avons branché, au kit de développement, le moteur du même type. Ces tests nous ont permis d’arriver à contrôler un moteur à partir de l’application Android. De plus, de ce fait nous avons pu également tester l’application Android.
3.4. Difficultés
La principale difficulté de cette partie, qui sera une amélioration à apporter lors des prochaines années, était de passer le programme du microcontrôleur en temps réel. En effet, par manque de temps, dû au fait que nous n’avons eu les cours sur le temps réel que durant les dernières semaines du projet, nous n’avons pas eu le temps de finaliser ce passage à une programmation temps réel.
15 | P a g e
Projet Quadricoptère – mars 2012
4 - Carte électronique et asservissement du drone
4.1. Modification de la carte
Une des missions de ce projet à été d'actualiser la carte de l'année dernière et de faire un schéma électronique de la carte sous KiCad. Cette carte est le cerveau du drone, en effet c'est elle qui contient toute l’électronique du drone.
Figure 4 : Carte réalisée lors de l’année précédente
4.1.a. Portage sous KiCad
Lors du projet de l'année précédente, une modélisation électronique a été réalisée sur OrCad. Or nous voulions pouvoir diffuser les schémas librement. Le problème vient du fait que OrCad est un logiciel propriétaire et payant et donc on ne pouvait pas distribuer nos schémas librement. Nos tuteurs nous donc imposé le logiciel KiCad. Ce logiciel a les mêmes fonctionnalités que OrCad, c'est à dire la schématisation de circuits imprimés, et la modélisation en 2 dimensions et 3 dimensions, mais sans les désavantages. En effet KiCad est libre, gratuit et permet la distribution car il est sous licence GNU GPL, de plus il est mis à jour régulièrement.
Pour porter le schéma électronique sous KiCad, nous avons dû nous familiariser avec ce logiciel qui est destiné à un usage professionnel. Pour cela nous avons consulté quelques tutoriels. Ensuite nous avons créé les représentations des différents modules qui ne sont pas dans la bibliothèque originale de KiCad pour créer notre propre bibliothèque de composants.
Après recherches pour le microcontrôleur nous avons trouvé une bibliothèque de schématisation pour les composants Renesas sur le site internet de la forge des universités de Clermont-Ferrand (lien : https://forge.clermont-
16 | P a g e
Projet Quadricoptère – mars 2012
universite.fr/svn/p10ab04/trunk/carte_tel_receptrice/carte_receptrice/clock_oscillator_x014s/).
Une fois les composants réalisés séparément, nous avons réalisé la schématisation globale en associant les composants. Pour cela nous les avons disposés de manière à ce que la compréhension soit la plus aisée possible par rapport aux broches du microcontrôleur et pour que les connexions entre modules ne se croisent pas.
Le schéma électronique complet de la carte est fourni en annexe.
4.1.b. Actualisation de la carte
Une autre de nos missions était de mettre à jour la carte électronique et d'essayer d'optimiser son poids et sa consommation en énergie.
Pour réaliser notre nouvelle carte nous sommes donc partis de la version réalisée l'année d'avant qui était tout à fait fonctionnelle d'après les schémas réalisés. Nous l'avons donc reprise intégralement, à une modification près et non des moindres. En effet le module capable de gérer la position du drone n'était pas présent sur la carte. Ce module est une unité de mesure d'inertie (IMU) sur 6 axes, il est composé de trois gyromètres et trois accéléromètres. M. KAUFFMAN a donc commandé le module qui devait nous servir cette année. Or le modèle commandé disposait d'une connectique I²C. Le bus I²C est un bus créé par PHILIPS pour connecter simplement les composants à un microcontrôleur sur un port série.
Il nous a donc fallu revoir la liaison entre l'IMU et le microcontrôleur, pour cela il dispose de plusieurs ports prêts pour être directement utilisé avec un bus I²C. Nous avons donc choisi le port P7_0 qui est sur la broche numéro 30 du M32C pour la transmission de données et le port P7_1 qui est relié à la broche numéro 29 pour le signal d'horloge. De plus, l'IMU possède aussi trois broches pour les interruptions des gyromètres et des accéléromètres. Le microcontrôleur dispose de six broches pour utiliser les interruptions générées par les modules. Nous avons donc prévu de les relier au broches numéro 18, 19 et 20 du M32C qui sont respectivement les interruptions générées par INT2, INT1 et INT0. Pour finir, ce module dispose d'une alimentation électrique en courant continu sur 3,3 volts.
Les schémas ont été réalisés avec le nouvel IMU en revanche la carte n'a pas pu être fabriquée car le module attendu n'est arrivé que dans la dernière semaine de ce projet. L'optimisation n'a pas été effectuée, en effet les recherches pour optimiser le matériel auraient été trop longues. Nous avons préféré nous concentrer sur d'autres tâches plus importantes et indispensables au bon déroulement du projet.
4.2. Asservissements
Cette partie consiste à établir un code permettant de stabiliser le drone. Elle a été sous-divisée en trois autres axes de manière à décomposer le travail. Cette partie a pour but d'être intégrée au microcontrôleur et au simulateur. Elle constitue une partie centrale du
17 | P a g e
Projet Quadricoptère – mars 2012
projet permettant de simuler le comportement du drone dans un environnement virtuel, ainsi que la liaison entre un terminal Android, les moteurs et le sonar.
4.2.a. Asservissement en altitude
Pour établir la première partie du code de stabilisation, nous avons dû travailler sur un tableur et simuler le comportement en z du drone en fonction de la force exercée. Pour simplifier cette première tâche, nous considérions que les quatre moteurs ne faisaient plus qu’un pour n’appliquer qu’une seule force. Les premières simulations grâce au tableur se portaient sur le décollage et la stabilisation.
Figure 5 : Décollage et asservissement du drone
Les données en y correspondent à l’altitude en mètre et les données en x correspondent au temps en millisecondes.
Dans cet exemple, notre but était de stabiliser le drone à une hauteur de un mètre. Nous avons pu réaliser ce schéma en prenant en compte un maximum de paramètres permettant une simulation la plus proche possible de la réalité :
 Masse du drone
 Consigne d'altitude (altitude visée) et altitude réel
 Différents coefficients (gain proportionnel, gain dérivée, alpha moteur)
 La force à appliquer à l'instant Δt
 Accélération et vitesse à l'instant Δt
En générant le code, nous avons voulu éviter une approche trop simpliste, consistant à effectuer une poussée maximum tant que la consigne d'altitude n'est pas atteinte, et à couper les gaz lorsque l'altitude est atteinte ou dépassée. Cette solution facile à réaliser aurait posé un réel problème. Nous aurions donc constaté un comportement difficile à
18 | P a g e
Projet Quadricoptère – mars 2012
maîtriser car il aurait effectué des oscillations. Nous aurions pu représenter ce comportement par la figure ci-dessous.
Figure 6 : Oscillation de l'altitude du drone avec une approche trop simpliste
Pour résoudre ce problème, nous avons mis en place un code utilisant des dérivées. Le calcul de la force à appliquer prend en compte, la différence entre la consigne d'altitude et l'altitude réelle, l'évolution de l'erreur, l'accélération ainsi que la vitesse à un moment Δt. Cette nouvelle approche est représentée par la figure du décollage et de l’asservissement du drone (Figure 1).
La formule appliquée pour calculer la force à appliquer à un instant Δt est celle-ci :
Force actuelle à appliquer = Force appliqué à l'instant t-1 * (Gain proportionnel * Différence entre la consigne d'altitude et l'altitude) + (Gain dérivé * Différence entre l'erreur d'altitude réel à t et l'erreur d'altitude à t-1)
Détail : On prend en considération la force appliquée précédemment et l'évolution de l'erreur d'altitude pour déterminer la force à appliquer.
Cette formule a pour but de diminuer la force appliquée au rapprochement de la consigne d’altitude et par conséquence, de limiter l'accélération. En limitant de plus en plus, l’accélération, on doit atteindre une erreur d’altitude (consigne d’altitude - altitude courante) à zéro en même temps que l’accélération deviendra nulle. Le drone s'élevant, va ralentir sa vitesse jusqu'à atteindre l'altitude visée. De cette manière, le drone va limiter sa montée en altitude au-dessus de l'altitude visée. Il n'aura plus qu'à appliquer une force plus ou moins constante (dans la théorie) pour compenser le poids (P = masse * 9,81) et le rendre immobile en altitude. La figure ci-dessous en est représentative.
19 | P a g e
Projet Quadricoptère – mars 2012
Figure 7 : Théorie de stabilisation du drone
4.2.b. Développement du code permettant d'utiliser le sonar
La mesure de l'altitude du drone a été confiée à un sonar. Un sonar est un capteur de distance. La distance est calculée par l’émission d'ultrasons, et en fonction du temps de réflexion sur un objet, on en déduit l’éloignement. Cependant, le capteur ne peut pas mesurer une distance supérieure à trois mètres, mais les distances mesurées sont très précises.
Pour incorporer ce matériel à la carte électronique, il a fallu développer le code associé. Ce code a été ajouté ensuite au code du microcontrôleur dans un handler cyclique (« fonction » en programmation temps réel), exécuté toutes les 20 millisecondes. Ainsi pour déclencher une mesure, il faut envoyer une impulsion de 10μs au sonar. Il faut donc configurer un temporisateur pour générer cette impulsion. De plus, puisque la mesure de distance fonctionne en fonction du temps, il nous a fallu utiliser un temporisateur capable de mesurer les largeurs d'impulsion. Nous avons donc paramétré le temporisateur TB0 en mode “mesure de largeur d'impulsion” (ou mode PWM).
Nous disposions également d’un second dispositif de calcul d’altitude permettant de prendre le relais au sonar lorsque le quadricoptère dépasserait une altitude de trois mètres. Il s’agit d’un capteur barométrique. Ce type de capteur fonctionne avec la pression atmosphérique, il n'est donc pas très précis car les variations de pression sont minimes sur une petite distance. Cela reste quand même suffisamment exploitable, car nous pouvons mesurer un changement d'environ 10 cm. Au-delà de trois mètres d’altitude, une variation de plus ou moins dix centimètres est négligeable pour l’utilisateur qui ne verra qu’une
20 | P a g e
Projet Quadricoptère – mars 2012
estimation. Le capteur a été mis en place sur la carte de l'année dernière. Sur les schémas réalisés cette année de la carte sous KiCad, l'implantation a été prévue sur le même port que sur la carte électronique précédente. En revanche en raison d'un manque de temps, le code pour que le microcontrôleur gère ce capteur n'a pas été implémenté.
4.2.c. Asservissement en x et y
La seconde partie concernant la stabilisation du drone consistait à rendre plus complet l'algorithme de manière à asservir en x et en y le drone. Cette partie a été facilement réalisable grâce à M. LAFFONT. Le code développé a été exclusivement intégré dans le moteur du simulateur pour deux raisons.
La première raison est qu'il nous était difficile de simuler le comportement du drone en x et en y dans un tableur. Pour cette raison, nous avons développé l'asservissement directement dans le simulateur car nous pouvions directement le tester.
La deuxième raison était par soucis de temps. En effet, cette partie a été développée dans les dernières semaines et nous savions que les algorithmes de stabilisation ne pourraient pas être compilés et chargés sur le microcontrôleur. Nous avons donc décidé de mettre la priorité sur cette partie pour pouvoir finaliser le simulateur. Nous avons pu dans les mêmes moments, associer les parties du simulateur, à savoir les modélisations 3D et le moteur physique (avec l'algorithme de stabilisation), le module Wi-Fi ainsi que l’application Android. Nous avons alors pu assister à un deuxième aboutissement dans le projet, à savoir que nous pouvions diriger le drone virtuel dans le simulateur grâce à un terminal Android, via une connexion sans fil.
21 | P a g e
Projet Quadricoptère – mars 2012
5 - Application Android
5.1. Présentation de l’environnement de développement
Le développement d’une application Android se fait en utilisant le langage java, qui est un langage orienté objet, ce qui permet une programmation plus claire et organisée pour ce genre de développement. Nous avons effectué la programmation en utilisant l’environnement de développement Eclipse. Cet IDE est tout à fait adapté à la programmation sous Android du fait de son intégration du SDK Android. En effet, le SDK Android, qui est la bibliothèque qui permet de programmer en utilisant les composants Android, ainsi que le matériel, comme la caméra ou les accéléromètres, est parfaitement interprété par Eclipse.
5.2. Différences entre tablette et téléphone
D’autre part, nous avions pour projet de développer une application pour tablette, ainsi qu’une autre pour téléphone. Nous avons disposé des deux appareils car la tablette était une tablette personnelle, et de plus une des raisons pour lesquelles nous avions choisi ce projet. Quant au téléphone, il nous a été fourni par l’IUT, qui l’a acheté spécialement pour ce projet, et il s’agit de l’appareil, et de l’application correspondante, qui resteront à l’IUT pour les étudiants qui poursuivront ce projet.
Concernant l’application elle-même, la différence principale vient de la différence de version entre ces deux Android. Nous avons tout d’abord décidé de développer sur la tablette, qui est en version 3.1, avec une disposition graphique spécifique, ainsi que des widgets uniquement disponibles pour cette version. Quand nous avons porté cette application sur le téléphone, qui possède une version 2.2.3, nous nous sommes alors rendu compte de ce problème. Nous avons alors décidé de reprendre le code lui-même, car le traitement des données reste le même, et de développer une interface graphique différente. Et à partir de là, nous avons séparé les deux applications, étant donné qu’uniquement le téléphone restera à l’IUT.
22 | P a g e
Projet Quadricoptère – mars 2012
Figure 8 : Application de la tablette Samsung Galaxy Tab 2
Figure 9 : Application du Samsung Galaxy S 2
5.3. Fonctionnement de l’application
Le fonctionnement de l’application est simple, elle reçoit les informations liées à l’environnement, c’est-à-dire l’orientation du terminal (tablette ou téléphone), vers l’avant ou sur les côtés, ainsi que l’altitude et la commande de rotation à plat, par la pression sur des boutons. Ces informations sont récupérées 50 fois par seconde puis envoyées à l’aide d’une trame UDP au module Wi-Fi. Les trames sont composées d’un caractère pour le type d’information suivies de « : » et enfin de la valeur calculée en virgule flottante.
Exemple pour envoyer une altitude : « Z:2.38 ».
23 | P a g e
Projet Quadricoptère – mars 2012
Une fois ces informations réceptionnées par le drone, il les traite et les retourne à l’application qui affiche l’état du drone à l’écran. De plus, nous avons intégré l’affichage du flux vidéo récupéré depuis la caméra embarquée, et nous pouvons également changer l’adresse IP à laquelle l’application se connecte, afin de pouvoir changer de cible (drone réel ou simulateur) facilement.
Figure 10 : Fonction onSensorChanged de l’application Android
Dans le code précédent, nous pouvons voir un exemple de ce qui se fait régulièrement dans la programmation Android, c’est-à-dire la définition d’une méthode d’un objet lors de l’instanciation de celui-ci.
Ici, l’objet SensorEventListener sert à « écouter » les accéléromètres. Ainsi, la méthode onSensorchanged, qui prend en paramètre un SensorEvent, c’est-à-dire ce que l’on capte des accéléromètres, va permettre d’effectuer un traitement avec chaque valeur que l’on récupère des accéléromètres. De plus on envoi également la valeur de l’altitude et de la rotation à plat (yaw), qui sont tous deux des attributs de l’application, et qui sont changés grâce aux boutons de l’application. L’altitude étant limitée de 0 à 9, car il n’y a pas de hauteur négative, et d’autre part pour ne pas pouvoir faire monter le drone indéfiniment.
24 | P a g e
Projet Quadricoptère – mars 2012
Figure 11 : Fonction periph_write de l’application Android
La fonction ci-dessus permet d’envoyer l’information passée en paramètre, expliquée dans la partie précédente, au travers d’un paquet qui correspond à une trame, que l’on envoie par socket UDP.
Cette fonction crée une chaine de caractère avec l’information à envoyer, mais avant de pouvoir mettre tout cela dans le paquet à envoyer il faut tout d’abord la transformer en tableau d’octets. Ensuite on construit le paquet avec l’information, sa taille, l’adresse IP à laquelle l’envoyer, ainsi que le port sur lequel l’envoyer. Et enfin, on envoie ce paquet grâce à la socket.
5.4. Autonomie
Pour cette partie du projet nous avons eu à travailler en totale autonomie. En effet, nos professeurs ne maitrisant pas le sujet et n’ayant pas encore eu les cours de java, nous avons dû chercher sur internet des tutoriels ainsi que des astuces sur de nombreux forums pour régler nos problèmes. Nous avons également beaucoup utilisé la documentation Android, sur le site officiel, qui offre des exemples d’utilisation de certaines fonctions, ainsi que la liste complète des méthodes disponibles.
5.5. Gestion de la caméra embarquée
5.5.a. Configuration
La caméra embarquée sur le drone est une caméra IP Wi-Fi de marque Dlink. La configuration de la caméra se fait grâce au routeur destiné au projet, le même qui permet l’échange de données avec le module Wi-Fi présent sur le drone. La configuration pour pouvoir utiliser cette caméra se fait au travers de l’interface web présent sur la caméra. Il a donc fallu brancher la caméra en Ethernet au routeur, et ainsi nous avons pu configurer la connexion.
25 | P a g e
Projet Quadricoptère – mars 2012
5.5.b. Fonctionnement
Nous avons intégré la gestion du flux vidéo dans l’application Android afin d’afficher en temps réel les images. Cet affichage peut permettre notamment de pouvoir contrôler le drone à distance sans avoir une vision directe de celui-ci.
La caméra enregistre continuellement une image dans sa mémoire, le but est alors de télécharger cette image et de l’afficher à l’écran. Afin d’avoir un compromis entre fluidité d’affichage et fluidité de l’application, celle-ci récupère 20 images par seconde.
26 | P a g e
Projet Quadricoptère – mars 2012
6 - Communications
Pour permettre l'interaction entre la tablette Android et le drone ou le simulateur, il fallait gérer la communication entre ces deux périphériques. Tout d'abord les deux éléments principaux de cette interaction étaient le routeur et le module WIFI. C’est deux éléments ont des caractéristiques et des configurations bien différentes que nous allons détailler.
6.1. Routeur
Figure 12 : Le routeur
Nous avons commencé par configurer le routeur afin d'établir un réseau sur lequel l'ensemble des équipements se connectaient.
Cette configuration s’est faite, après installation via un CD, à partir d'une interface Web. Nous avons donc commencé par préciser quelles adresses IP (fixes) utiliserait chaque périphérique. Ainsi chacun d’entre eux pouvait contacter l’autre. Nous avons donc configuré le routeur de façon à ce que seules ces adresses soient autorisées sur le réseau.
6.2. Module Wi-Fi
6.2.a. Présentation
Ce module sans fil est un module WIFI Matchport b/g de Lantronix. Ce module supporte deux versions de la norme IEEE 802.11, les versions b et g. La dernière version est la version n, qui a été conçue pour améliorer le débit de la communication sans fil. Cette dernière version n'est pas supportée par notre module Wi-Fi. Dans notre cas, cela ne pose pas vraiment de problème car nous n'avons pas besoin d'un fort débit pour ce que l'on souhaite réaliser.
Figure 13 : Module WIFI Lantronix MatchPort b/g
27 | P a g e
Projet Quadricoptère – mars 2012
Ce module est assez complet, en effet il inclut plusieurs services, comme par exemple un serveur web ou encore un serveur de messagerie. Dans notre contexte nous avons seulement utilisé l'interface web pour mener à bien la configuration de notre module. Il est aussi possible de configurer le module par Telnet via le port série. Pour le configurer nous avons aussi utilisé le logiciel DeviceInstaller.
6.2.b. Configuration
Tout d'abord la tablette Android ne supporte pas le réseau Ad-Hoc, donc il a fallu configurer le module en mode infrastructure. De plus il a fallu fixer une adresse IP pour le module WIFI, ainsi la tablette envoie ses informations sur cette adresse directement. Pour débuguer la configuration du module nous avons utilisé l'hyperterminal qui nous permettait d'obtenir les mêmes options que DeviceInstaller.
Figure 14 : Détails du module Wi-Fi avec DeviceInstaller
Ici nous pouvons voir l’ensemble de la configuration du module Wi-Fi grâce au logiciel DeviceInstaller.
28 | P a g e
Projet Quadricoptère – mars 2012
Figure 15 : Configuration du module Wi-Fi avec DeviceInstaller
Sur cette page de configuration nous avons pu nommer le Module, fixer son adresse IP. Les autres onglets permettent de modifier les paramètres des channels, de la sécurité ainsi que les autres multiples fonctionnalités du module dont nous ne nous sommes pas servis.
6.3 Le protocole de communication :
Pour pouvoir analyser les données envoyées par l’application Android, il fallait définir un protocole. Nous avons donc choisi d’utiliser le protocole suivant:
Figure 16 : Représentation du protocole
Nous avons utilisé certaine lettre pour représenter un mouvement du drone. Ainsi le Z représente l’altitude, le Y le cap (Yaw), le P le tangage (Pitch) et le R le roulis (Roll). De plus, les deux points permettent de séparer le type de commande des valeurs. Le protocole inclus également le point d’interrogation permettant une demande effectuée par le simulateur à l’application Android. Cet envoi de données par le simulateur n’a pas été géré. Les valeurs sont des inclinaisons (de 10 à 10), correspondant à celles de la tablette ou du smartphone, provenant ses accéléromètres.
29 | P a g e
Projet Quadricoptère – mars 2012
Figure 17 : Schéma de représentation des mouvements du drone
Ce schéma représente les différentes orientations que peut adopter notre drone. Pour gérer ces différents mouvements, nous avons analysé à l’aide d’un parseur les différentes trames envoyées par l’application Android. L’implémentation du parseur a été faite comme indiquée ci-après.
Figure 18 : Variables d'orientations reçues de l’application Android et envoyées au simulateur
30 | P a g e
Projet Quadricoptère – mars 2012
6.4. Différents type de communication
Figure 19 : Ensemble des communications
6.4.a. Communication Module Wi-Fi - PC par port série
La communication par le port série s’est faite par le biais de la reprogrammation d’un hyperterminal en langage C. Nous avons utilisé ce type de communication afin d’envoyer les données récupérées de la tablette grâce au module Wi-Fi par le port série. Ce programme fut complexe à réaliser puisque Windows ne gère pas l’utilisation directe des ports série. Il a donc fallu, après quelques recherches sur Internet, utiliser une structure complexe représentant un port série.
31 | P a g e
Projet Quadricoptère – mars 2012
Figure 20 : Ouverture et initialisation du port série
Dans le code ci-dessus, nous pouvons voir l’ouverture et surtout la configuration du port série (COM 4) en langage C sous Windows. L’étape principale a été l’initialisation de la structure DCB permettant de respecter la configuration de l’envoi des données par le module Wi-Fi. Comme par exemple l’initialisation à 9600 bauds pour la vitesse de réception des données.
6.4.b. Communication directe Android-PC
La communication directe en UDP, sans passer par le module Wi-Fi, permet l'interaction entre l'application Android et le simulateur. Celle-ci, réalisée en langage C, est intégrée au simulateur. En résumé nous avons donc intégré un serveur UDP à Raydium, afin de récupérer les valeurs d’orientation envoyées par la tablette ou le smartphone Android au simulateur. La fonction les récupérant est ensuite appelée par la fonction « step » du simulateur.
Figure 21 : Code de la création de la socket non bloquante
32 | P a g e
Projet Quadricoptère – mars 2012
Les deux lignes de codes précédentes, nous ont permis de créer une socket non bloquante, afin que l’appel à upd_loop() dans le simulateur n’interrompt pas le programme de virtualisation.
6.4.c Communication, écriture sur le port série du microcontrôleur
Cette communication permet au simulateur, qui reçoit les données, de les envoyer au microcontrôleur qui ensuite effectuera les calculs pour gérer les mouvements du drone, dans le but d’alléger le simulateur 3D. Ce code est contenu dans le programme du port série mais cette partie n’a pas été intégrée au simulateur.
6.4.d. Gestion du simulateur par le clavier
Cette interaction est directement liée au simulateur. Nous pouvons donc commander le drone virtuel directement au clavier. Cette partie a été réalisée par le binôme s’occupant du simulateur.
33 | P a g e
Projet Quadricoptère – mars 2012
7 - Modélisation 3D
7.1. Outil Blender
Figure 22 : Logo de Blender
Blender est un logiciel libre assez complexe qui permet la modélisation de forme en trois dimensions. Il permet de faire de l'imagerie numérique, ainsi que des animations 3D, comme par exemple certains courts métrages. Il s'agit également d'un logiciel gratuit et multiplateforme. Depuis quelques années, il est disponible en open source, ce qui a permis à la communauté de le développer et de l'améliorer très rapidement. Blender est basé sur OpenGL, ce qui implique un apprentissage assez long pour les novices, car beaucoup de fonctionnalités sont gérées par les raccourcis clavier. Il fonctionne sous forme d'objets qui peuvent être ensuite exportables via des scripts Python. Dans notre cas, nous nous sommes servis d'un script qui permet d'exporter les objets générés en « .blend », en « .tri, » utilisables dans Raydium, le moteur de jeu vidéo.
Figure 23 : Exemple de modélisation avancée avec le logiciel Blender
34 | P a g e
Projet Quadricoptère – mars 2012
7.2 Modélisation
Étant totalement novices en matière de modélisation 3D, notre première tâche a été de nous former et de nous adapter à cette technologie. Nous avons donc parcouru les différents tutoriels en ligne, par exemple ceux du "Site Du Zéro". Cela nous a permis d'acquérir les bases de la modélisation 3D.
Après cela, nous avons donc directement entrepris la représentation des objets qui intervenaient dans le simulateur. Pour cela, une répartition du travail a été faite de la manière suivante: une personne s'est occupée de la virtualisation du drone et de ses hélices (aussi bien à l'arrêt qu'en marche) et l'autre de l'environnement comprenant la salle, les bâtiments et tous les objets qui s'y trouvent.
Nous avons donc commencé une modélisation peu détaillée, qui nous a permis surtout de nous adapter plus sérieusement à l'interface du logiciel Blender.
Dans cette phase, des retouches ont été faites au fur et à mesure. Par exemple le drone réel a été modifié plusieurs fois en peu de temps. En effet, un accident de vol a cassé les quatre bras du drone qui ont donc dû être remplacés. Le modèle 3D a en conséquence lui aussi dû être revu, ceci afin de s'adapter à ce changement pour plus de réalisme.
Figure 24 : Modélisation du drone avant l’accident
35 | P a g e
Projet Quadricoptère – mars 2012
Figure 25 : Modélisation du drone après la modification des bras
On constate bien la modification qu'il y a eu entre autre au niveau des bras. Ceux-ci étaient bien plus gros avant l’accident car de la même épaisseur que la structure, alors qu'après les bras ont été remplacés par des baguettes de bois, beaucoup plus fine.
Puis, lorsque les techniques de modélisation ont été acquises, nous avons pu modéliser plus en détails, tout en respectant un niveau de précision en accord avec les ressources dont nous disposions. En effet, les objets sont divisés en faces, ce qui donne un réalisme supérieur à la virtualisation. Le nombre de faces et d'arêtes détermine ainsi le maillage d’un objet.
Figure 26 : Modélisation de la pale du drone à mi-parcours
36 | P a g e
Projet Quadricoptère – mars 2012
Figure 27 : Modélisation de la pale à la fin du projet
On peut donc constater qu’après reprise du modèle, la pale correspondait plus à ce qu'elle était en vrai, c'est-à-dire qu’elle n'était pas plate. De même les deux pales n'étaient pas symétriques par rapport au moyeu.
Dès le départ, nous avons pris en compte les erreurs qui ont été faites l'année précédente en essayant d’avoir un maillage aussi faible que possible, et cela aussi bien au niveau du drone, qu’au niveau de l'environnement. En effet, il faut savoir qu’un maillage trop élevé entraîne des ralentissements au niveau de Raydium. Il a donc fallu trouver le meilleur compromis entre qualité de la représentation et performance du moteur de jeu vidéo.
Figure 28 : Maillage du corps du drone
37 | P a g e
Projet Quadricoptère – mars 2012
Toutefois, certains maillages sont obligatoires, comme par exemple lorsque il a fallu découper les fenêtres de la salle de cours pour laisser entrer assez de lumière. Ceci a notamment posé problème pour l’apposition des textures sur le sol ou les murs, qui se sont vus divisés en plusieurs faces.
7.3 Adaptation des modèles à Raydium
L'adaptation des modèles à Raydium s'est faite en plusieurs étapes. Tout d’abord, nous avons dû trouver et intégrer à Blender le script Python qui permet d'exporter les modèles 3D Blender pour que ceux-ci soient utilisables dans Raydium. En effet, les objets générés sous Blender sont des fichiers de formats « .blend ».
Ce script est donc celui qui permet d'importer ou d'exporter des fichiers en « .tri ». Il s’agit en fait du format de fichier dans lequel Raydium stocke donc les objets 3D. Il y place les coordonnées des points en x, y, z de l’objet, les coordonnées de texturage ainsi que les textures utilisées qui sont converties au préalable de « .png » vers le format « .tga » lors du premier export du fichier sous Blender.
Pour donner un style à notre scène, nous avons commencé par appliquer certaines couleurs sous Blender. Nous avons ensuite essayé de tester ces dernières dans Raydium. Nous nous sommes vite rendu compte que celles-ci n'apparaissaient pas lorsque nous lancions la simulation. Nous avons donc conclu que les couleurs imposées sous Blender n'étaient pas gérées, ce qui a ensuite été confirmé par l'un de nos tuteurs M. Laffont.
À partir de cette constatation, nous avons donc remplacé toutes les couleurs appliquées aux objets par des textures.
Dans un premier temps, les textures apposées n’apparaissaient toujours pas lors de la simulation. M. Laffont nous a donc expliqué comment appliquer des textures qui puissent être visibles en temps réel.
Les images d’origine doivent avoir une taille en largeur et hauteur multiple de deux pour pouvoir être appliquées convenablement dans Raydium car certaines parties fines comme les côtés fins des bras du drone ne pourront pas gérer les textures. Ce travail de texturage a été long mais a permis d'obtenir des modèles 3D qui correspondent au mieux à la réalité.
38 | P a g e
Projet Quadricoptère – mars 2012
Figure 29 : Drone réel et corps final du drone modélisé
Figure 30 : Salle de cours réel et salle de cours modélisé sous Blender
Le travail suivant consistait au redimensionnement des différents objets. Par exemple, le drone modélisé au départ était bien trop grand par rapport à la scène de test "cocorobix". Il a donc fallu le mettre à l'échelle, ainsi que ses hélices. Le même travail de redimensionnement a été effectué sur notre scène. En effet, après avoir fini l’apposition de texture, il a fallu tester le décor qui a été créé. La scène a donc ainsi été remaniée plusieurs fois afin que l’échelle corresponde au mieux avec celle du drone. Cela n'était pas possible sous Blender car dans ce logiciel, il n'y a pas réellement de notion d'échelle (en m ou cm). Il a
39 | P a g e
Projet Quadricoptère – mars 2012
également été nécessaire de repositionner l’environnement pour que le drone ait le champ libre pour décoller sans rentrer dans un objet présent dans la salle.
40 | P a g e
Projet Quadricoptère – mars 2012
8 – Simulateur
8.1. Présentation générale
Le simulateur du drone a pour objectif final de reproduire exactement les mouvements du drone afin de le tester dans un environnement virtuel, ce qui réduit les risques de destructions inopinées.
Le drone, dans l'espace de simulation, peut-être contrôlé de deux manières : par le clavier, ou par un appareil sous Android dont on reçoit les consignes via Wi-Fi.
Nous sommes donc partis d'un existant, et nous sommes appuyés sur le wiki de Raydium disponible sur internet, contenant les descriptions des fonctions, ainsi que des exemples.
Les principaux outils utilisés pour développer le simulateur sont :
Raydium :
Raydium est une bibliothèque regroupant plusieurs bibliothèques plus bas niveau ayant toutes une application dans le domaine du jeu vidéo 3D. De plus, Raydium propose une API composée de fonctions haut-niveau ayant pour but de faciliter l'écriture de morceaux de code communs à tous les jeux vidéo. Raydium dispose donc de moteurs pour gérer tout ce qui est relatif aux jeux vidéo, des graphismes au son, en passant par la physique et le réseau. Dans le cadre du simulateur, nous nous sommes surtout attachés aux moteurs qui gèrent la physique et les graphismes, respectivement ODE et OpenGL.
Figure 31 : Logo de Raydium
- Code::Blocks :
Code::Blocks est l'environnement de développement intégré au SDK de Raydium. Il nous a donc fallu apprendre à l'utiliser, vu qu'il est nécessaire. C'est un IDE assez facile à prendre en main grâce à son compilateur intégré et son interface modifiable à souhait.
8.2 Particularités d'un programme incluant Raydium
Raydium étant codé en C, une fonction main est nécessaire à tout programme l'incluant. De plus, Raydium a besoin d'une fonction d'affichage, et nous avons utilisé une
41 | P a g e
Projet Quadricoptère – mars 2012
autre fonction propre à Raydium (plus précisément à ODE), destinée à être appelée de façon très régulière : step().
main : la fonction main servira à initialiser des paramètres propres à Raydium concernant l'application, notamment la résolution de la fenêtre, le filtre des textures, le champ de vision, la (non-)activation des ombres, tout ce qui est relatif à la lumière, les « .tri » à utiliser, la gravité, ainsi qu'à définir quelles fonctions correspondront à la fonction d'affichage et la fonction appelée de façon récurrente.
affichage : tâche effectuée par la fonction display(), dans le cas de notre simulateur. Sert à rafraîchir la caméra ainsi que les différents viewports, elle se doit donc d'être appelée souvent. On appelle aussi la fonction servant à la gestion du clavier dans display(). De par sa nature gourmande en CPU (à cause des traitements graphiques réguliers et nombreux), sa fréquence d'appel dépend directement du processeur.
step : fonction censée être appelée très régulièrement. Elle provient d'ODE, il convient donc de lui faire effectuer tout ce qui tient de la physique.
Figure 32 : Fonctionnement d’un programme Raydium
8.3 Déroulement du projet
- Analyse de l'existant:
Etant partis d'un existant suffisamment conséquent, il nous incombait d'analyser sa structure, son fonctionnement, ainsi que de comprendre la raison d'être de chacun des appels de fonctions de Raydium. Cette partie nous a pris du temps car il fallait non-seulement comprendre le but de chaque partie du code, mais aussi maitriser les concepts propres à Raydium, tels que, notamment, celui des viewports, et ce qui, plus généralement, concerne le fonctionnement d'une application avec des animations en 3D.
42 | P a g e
Projet Quadricoptère – mars 2012
Cette analyse nous a permis de repérer ce qui n'allait pas dans l'agencement des différentes parties du code du simulateur. Ainsi, nous avons remarqué que la gestion du clavier était mise dans step(), qui est censée contenir uniquement ce qui concerne la physique et les asservissements. En effet, step() est une fonction appelée beaucoup plus souvent que display() (Ceci étant dû au fait que display() est une fonction faisant du traitement graphique, qui ne nécessite donc pas d'être appelée plus de 25 fois par seconde environ (le minimum nécessaire pour que l'être humain voit une action fluide)). De plus, il nous semblait inutile et coûteux d'effectuer une scrutation du clavier plus de 25 fois par seconde (la fréquence d'appel de step(), qui était la fonction contenant le code de gestion du clavier, est de 200Hz, ce qui est beaucoup plus que nécessaire pour faire une gestion du clavier réactive).
Nous avons aussi pu constater que l'ébauche de physique présente sur l'existant n'était pas vraiment cohérente. Notamment une tentative pour gérer le déplacement du drone avec une variable speed, ce qui n'a pas vraiment de sens vu que la vitesse du drone dépend de son inclinaison par rapport à l'horizontale (en effet, d'un point de vue physique, le drone ne peut produire qu'une force vers le bas. Or, plus il est penché en avant, plus la force produite est dirigée vers l'arrière, plus la vitesse du drone augmente). De plus, les valeurs possibles de la variable speed donnaient au drone un comportement tout sauf réaliste.
De plus, les prototypes des fonctions prenaient en paramètres des pointeurs sur des variables qu'on ne modifiait, voire, n'utilisait pas. De plus, certaines fonctions, notamment celle concernant la régulation, avaient besoin de paramètres provenant de fonctions qui ne les appelaient pas. Il nous a donc fallu choisir un moyen de communication entre fonctions différent de la simple utilisation de paramètres et de codes de retour.
- Refonte du code :
Nous nous sommes donc attachés à reprendre le code dans son intégralité afin d’obtenir un résultat plus en adéquation avec nos attentes. Le déplacement du code de gestion du clavier dans une fonction différente nous a ainsi poussés à définir de quelle façon allaient communiquer nos différentes fonctions. Plusieurs options nous étaient proposées, notamment par structure, proposant ainsi de réunir toutes les consignes (l’angle en x, l’angle en y, et la consigne en altitude), par pointeur, ou par variable globale. Cette dernière option a été choisie pour des raisons de praticité. En effet, le choix de la structure nous aurait obligé à remplir tous les champs, ce qui implique l’envoi d’informations probablement redondantes, si jamais une consigne ne changeait pas d’une application des forces à l’autre. Et les pointeurs n’étaient pas envisageables car les fonctions ne s’appelaient pas entre elles. La variable globale présente, de plus, l’avantage d’être visible dans toutes les fonctions du fichier (voire plus, à l’aide du mot-clé « extern »).
Nous nous sommes ensuite occupés de nettoyer la partie physique du simulateur, et de poser les bases de ce qui nous semblait être une physique plus saine et plus réaliste. Cela passait par l’évincement de variables inutiles afin de garder ce qui allait vraiment être utile
43 | P a g e
Projet Quadricoptère – mars 2012
par la suite. Toutes les occurrences à certaines variables ayant été enlevées, les prototypes des fonctions ont donc dû être modifiés en conséquence.
- Contrôles au clavier
Le drone simulé sur l’existant n’étant pas stable et sa gestion au clavier peu satisfaisante, il nous a fallu mener une réflexion pour définir, en coopération avec l’équipe chargée de la tablette Android, comment le drone allait être manipulé, afin de proposer des contrôles au clavier assez similaires à ce que fait la tablette Android. Nous avons donc opté de concert pour une manipulation séparant d’un côté le contrôle de l’altitude, se faisant via deux boutons, servant à monter ou descendre le drone par paliers d’une taille prédéfinie, et de l’autre, l’inclinaison du drone, contrôlée via un joystick (qui est, de base, émulé par les flèches directionnelles du clavier, mais Raydium gère très bien les vrais joysticks, ainsi que les manettes type XBox360).
- Mise au point de la physique et implémentation du code de l’asservissement
Une fois les contrôles faits, et des consignes cohérentes envoyées, nous devions faire en sorte que les consignes soient interprétées correctement afin que le drone soit stable et respecte les consignes sans oscillation, ce qui le rend incontrôlable. Pour cela, nous devions utiliser un asservissement utilisant la correction par PID. Néanmoins, n’étant pas à l’aise avec les calculs, nous avons dû nous en remettre à M. Laffont.
Une fois l’asservissement fait, nous avions donc un simulateur capable de prendre de l’altitude, et de se déplacer dans toutes les directions. Néanmoins, l’absence totale de frottements rendait le pilotage du drone simulé absurde : une fois le drone lancé avec une certaine vitesse, celui-ci dérive indéfiniment sans jamais ralentir ! Il fallait donc simuler des frottements de sorte que lorsque le drone se retrouve à l’horizontal, sa vitesse diminue petit à petit.
- Gestion de la camera
La caméra dans l’existant était en mode “freemove” : On pouvait se déplacer à volonté à travers les textures et les décors, et il fallait la contrôler manuellement pour qu’elle suive le drone dans ses déplacements, ce qui n’est pas acceptable. Il a donc fallu faire en sorte qu’elle suivre les mouvements du drone, afin d’en faciliter la manipulation. Cependant, la camera telle que nous l’avons codée reste fixe par rapport au drone.
44 | P a g e
Projet Quadricoptère – mars 2012
Figure 33 : Fonctionnement de Raydium avec la bonne configuration de la caméra
45 | P a g e
Projet Quadricoptère – mars 2012
9 - Le Bilan Technique
A l’origine le but de notre projet était de piloter un quadricoptère à partir d’une plateforme Android. Cet objectif n’a pas été entièrement atteint puisque, à l’heure d’aujourd’hui nous sommes seulement capables d'interagir avec les moteurs grâce à l’application Android. En revanche nous pouvons le piloter avec une radio commande et nous pouvons également contrôler celui-ci dans un environnement virtuel 3D. On peut donc envisager pour les projets à venir la réalisation des asservissements du drone physique dans le but de le piloter réellement grâce à n’importe quelle plateforme Android munie de notre application.
Durant ce projet nous avons été confrontés à certaines difficultés. Le principal obstacle que nous avons eu à surmonter était un accident du drone, lors d’un test, entraînant des dégâts matériels que nous avons dû réparer. Parallèlement, le module Wi-Fi, n’était pas reconnu suite à une mauvaise configuration du projet de l’année précédente. Ainsi nous avons perdu énormément de temps pour le reconfigurer. De plus, l’apprentissage de certains outils comme Blender ou Raydium fut assez complexe puisque nous ne les avions jamais utilisés auparavant. De plus, l’avancée du simulateur a été compromise un temps de par le fait que nous avons attendu que Parrot libère les sources pour son simulateur pendant plusieurs semaines, ce qui n’arriva pas, et nous avons été obligés de reprendre le simulateur de l’année dernière.
46 | P a g e
Projet Quadricoptère – mars 2012
10 - Conclusion
Ce projet nous a permis de découvrir le fonctionnement d’un groupe de travail sur un projet conséquent. L’organisation des tâches entre les différentes personnes sur un projet conséquent a été quelque chose de nouveau, ce qui nous a permis d’avoir une vision concrète d’un projet professionnel. Étant donné le nombre d’étudiants investis dans ce projet, la communication a été un facteur important dans la bonne conduite de cette réalisation, ce que nous avons réussi à mettre en place au fur et à mesure que le projet avançait.
Cette expérience nous a aussi montré l’importance d’une gestion de projet a priori afin de nous guider pas à pas dans durant ces trois mois. De plus, le fait de respecter une date de livraison du travail, nous a imposé un travail rigoureux et méthodique.
Nous sommes cependant déçus de ne pas avoir pu aller au bout de ce que nous avions prévu de réaliser, car malgré le fait que le drone puisse voler, cela aurait été une vraie satisfaction que nous puissions le contrôler uniquement avec notre propre matériel.
47 | P a g e
Projet Quadricoptère – mars 2012
11 - Résumé en anglais
The goal of this project was to be able to control a real drone, and also a virtual one with an Android device.
So we were a team of ten students, and we have split this project in five parts, in order to work in pair, and each pair had a well-defined part, composed with many tasks.
We first had to order the parts of the drone, one by one, on a Chinese website in order to build it with our own hands.
The first objective was to make the drone fly with a radio control, what we managed to do.
The pair of students in charge of the communication part of the project had to do the interaction between the Android device and the real drone or the simulated one.
There are three types of communication: the original one with Wi-Fi module and microcontroller, the second one between Wi-Fi module and simulator, and the third one directly between Android and the simulator.
A student was in charge of both drone’s enslavement, the real one and the simulated one. The code developed this way was integrated in the simulator and could have been added to the M32C microcontroller.
Another student was in charge of transposing the schema of the electronic card on KiCad in order to be able to distribute the representations of it. Then, we modified these schemas, because we had to remove the inertial measurement unit from it and replace it by another one, more recent.
We also modeled the classroom and the drone with the software Blender, and tested it with Raydium, the pair of students in charge of the Blender part also took care of the forge with TortoiseSVN.
One other big part of this project was to make an Android application which is able to control the real drone and also the virtual one. So we had to learn how to do this kind of program, because we did not learn it. So we have learned on our own to develop the application, and it works pretty well. We had to manage the connection to the devices, and also to get the video stream from the embedded camera.
Then, we had to make a simulator capable of reproducing the behavior of the real drone, in order to test the Android application. For this, we had to work on the physics of the simulator, the frictions, and the stabilization of the drone. We also tried to make it more convenient, by managing the camera of the simulator, so it can follow the drone while moving in its environment, and the keyboard, in order to test the simulator when we don’t have an Android device with us.
Right now, the simulated drone can be controlled with an android device and has quite a realistic behavior, and the real drone works with a radio controller.
48 | P a g e
Projet Quadricoptère – mars 2012
12 - Bibliographie
Asservissement :
fr.wikipedia.org
Android :
developer.android.com
android.developpez.com
Documentation module Wi-Fi :
MatchPort_DemoKit_QS
MatchPort_IG
MatchPort_PB
MatchPort_UG
Modélisation 3D :
Tutoriel sur Blender : www.siteduzero.com
Raydium :
www.raydium.org
49 | P a g e
Projet Quadricoptère – mars 2012
13 - Lexique
IDE : Integrated Development Environment (Environnement de développement intégré), environnement de développement logiciel.
API : Application Programming Interface (Interface de programmation) est une interface fournie par un programme informatique.
PID : Proportionnel Intégral Dérivé, est un correcteur utilisé afin de réaliser un asservissement.
Protocole : Ensemble de contraintes permettant d'établir une communication entre deux entités.
Routeur : Dispositif permettant l’interaction de périphériques via un réseau informatique, assurant le transfert et la redirection de données.
Maillage : Division d’un objet en différents éléments géométriques permettant une simplification d'un système par un modèle le représentant.
Microcontrôleur : Circuit intégré qui rassemble les éléments essentiels d'un ordinateur : le processeur, la mémoire (mémoire vive et mémoire morte), périphérique d’entrée/sortie.
SDK : Software Development Kit (Kit de développement), est un ensemble d'outils permettant aux développeurs de créer des applications.
Asservissement : Algorithme permettant de stabiliser un système, en l’occurrence, la stabilisation du drone durant son vol.
Viewports : Texture représentant un angle de vue à partir d’un point donné. Utilisé pour simuler une caméra.
50 | P a g e
Projet Quadricoptère – mars 2012
14 - Annexe
Annexe 1 : Schéma de la carte électronique
51 | P a g e
Projet Quadricoptère – mars 2012