RAPPORT DE PROJET : Simulateur de Drone
publicité
JOUGLA Benoit : responsable Modélisation
PARAN Guillaume : responsable Imagerie & Réseau
SILVENTE Gérard : responsable Physique
RAPPORT DE PROJET :
Simulateur de Drone
Année 2010 - 2011
Projet AR.Drone
1
Autorisation à diffuser sur l’intranet de l’IUT :
Par la présente, nous autorisons la diffusion de ce rapport, code de l’application et tous ses
composants, images et objets 3D sur le réseau intranet de l'Université d'Auvergne.
Projet AR.Drone
2
Remerciement :
Nous remercions Mr Laffont et Mr Kauffmann, nos responsables de projet qui ont su nous
apporter leurs soutiens et leur aide tout au long de notre travail.
Nous voulons aussi remercier Mr Coudeyr, d'avoir installé Tortoise SVN sur les postes où
nous travaillions et de nous avoir laissé une place où sauvegarder Raydium sur les machines afin de
gagner du temps et de ne plus travailler sur nos clefs USB.
De même merci à Mr Delon, de nous avoir fourni le matériel nécessaire (iPod Touch et
ordinateur portable wifi) pour la réalisation de notre projet.
Projet AR.Drone
3
Sommaire :
Remerciements ............................................................................................................................ 3
Introduction ................................................................................................................................. 6
1. Présentation synthétique du projet ........................................................................................... 7
2. Outils ....................................................................................................................................... 8
2.1. Blender ..........................................................................................................................................8
2.2. Raydium .........................................................................................................................................8
2.3. OpenGL ..........................................................................................................................................9
2.4. ODE ................................................................................................................................................9
2.5. Tortoise SVN ............................................................................................................................... 10
2.6. Wireshark ................................................................................................................................... 10
3. Structure d’un programme Raydium ........................................................................................11
3.1. Fonction main() .......................................................................................................................... 11
3.2. Fonction d’affichage ................................................................................................................... 11
3.3. Fonction step()............................................................................................................................ 11
4. Partie modélisation .................................................................................................................12
4.1. La 3D temps réel et la 3D pré-calculée ....................................................................................... 12
4.2. Création des objets 3D ............................................................................................................... 13
5. Partie physique........................................................................................................................15
5.1. Création du drone dans Raydium ............................................................................................... 15
5.2. Intégration des objets 3D dans le moteur physique .................................................................. 16
5.3. Gestion des forces ...................................................................................................................... 17
5.4. Gestion de l’asservissement ....................................................................................................... 18
5.5. Gestion des logs et du PHP ......................................................................................................... 19
6. Réseau ....................................................................................................................................20
6.1. L'établissement du lien ............................................................................................................... 20
6.2. Déroulement de la communication............................................................................................ 20
6.3. Optimisation de la communication ............................................................................................ 21
Projet AR.Drone
4
7. Imagerie ..................................................................................................................................22
7.1. Le rendu ...................................................................................................................................... 22
7.2. L’acquisition ................................................................................................................................ 23
7.3. L’encodage.................................................................................................................................. 24
7.4. L’envoi ........................................................................................................................................ 25
8. Bilan technique........................................................................................................................26
Conclusion ..................................................................................................................................27
English Summary .........................................................................................................................28
Bibliographie - Webographie .......................................................................................................29
Lexique .......................................................................................................................................30
Projet AR.Drone
5
Introduction :
Parrot, société française spécialisée dans les équipements sans fil, a développé AR.Drone, un
hélicoptère quadri moteur. Il dispose de nombreux équipements comme une caméra frontale pour le
pilotage, une seconde caméra verticale pour la stabilisation, un système de sonar, etc. Il peut être
piloté avec un iPhone, un iPod ou un iPad via l’application gratuite AR.FreeFlight. De plus, deux
autres applications payantes (à ce jour) développées par Parrot permettent de jouer à plusieurs dans
un environnement en réalité augmentée : les drones sont réels et, grâce à des capteurs, l’application
simule des tirs de missiles, etc.
L’objectif de ce projet, sous la direction de MM. Laffont et Kauffmann, était de réaliser un
logiciel de simulation du drone quadri moteur de Parrot et de pouvoir le contrôler, comme le drone
réel, en wifi avec l’application AR.FreeFlight.
Le projet a été découpé en quatre tâches distinctes. Une partie modélisation chargée de
créer une copie du drone réel de façon réaliste, ainsi qu’un environnement graphique. Une partie
physique visant à simuler les forces exercées sur le drone. Une partie réseau établissant le lien entre
le simulateur et le contrôleur et une partie imagerie consistant à émuler les deux caméras
embarquées et à envoyer les images au contrôleur.
Au début de ce rapport, nous aborderons les outils sur lesquels nous avons travaillé, puis,
après une rapide explication de la structure d’un programme Raydium, nous verrons plus en détails
le déroulement des différentes tâches. Nous verrons donc la création des objets 3D, les différentes
forces exercées sur le drone et leur introduction dans le moteur physique. Nous terminerons par la
connexion entre le simulateur et le contrôleur, et enfin la gestion des caméras et l’envoi des images.
Projet AR.Drone
6
1. Présentation synthétique du projet :
L’AR.Drone est un produit de la société Parrot. Il comporte une caméra frontale, une caméra
ventrale, un accéléromètre, deux gyroscopes, deux émetteurs récepteurs à ultrasons ainsi qu’un
microcontrôleur embarqué fonctionnant sous Linux. La caméra frontale et la caméra verticale, dont
les images sont retransmises sur le contrôleur, permettent à l’utilisateur de voir ce que « voit » le
drone.
Pour ce projet nous nous sommes inspirés des exemples de Raydium et de nombreux
tutoriels pour avoir une idée de l’utilisation des fonctions de ce moteur. Ainsi, nous avons
rapidement été capables de créer des objets simples et de les faire bouger.
Figure 1 : Exemple Raydium
Pour la création des objets 3D sous Blender, nous avons procédé de la même manière. Avant
de réaliser le drone et son environnement, nous avons essayé de suivre quelques tutoriels afin de
maîtriser les fonctionnalités de bases de Blender. C'est-à-dire réaliser un objet complexe en 3D ainsi
que de lui appliquer une texture. Blender bénéficiant d’une grande communauté, il fût aisé de
trouver ces tutoriels. Cependant pour les fonctionnalités plus avancés, les tutoriels devenaient rares.
Nous avons donc sollicité l’aide de Mr Laffont.
Figure 2 : Exemple de réalisation sous Blender
Projet AR.Drone
7
2. Outils :
2.1. Blender :
Blender est un logiciel libre et gratuit de modélisation, d’animation et de rendu 3D. Il gère
également la physique permettant de simuler la collision et la déformation d’objet 3D, et comporte
de nombreuses fonctionnalités comme la possibilité de créer un jeu vidéo directement dans le
logiciel. De plus il est multiplateformes.
Figure 3 : Logo Blender
2.2. Raydium :
Raydium est un moteur de jeu (game engine), c'est-à-dire un ensemble de composants
logiciels qui effectuent des calculs de géométrie et de physique utilisée dans les jeux vidéo. Cela
permet ainsi l’écriture d’un jeu plus rapide et plus souple. Les développeurs se concentrent sur le
contenu et le déroulement du jeu plutôt que sur des problèmes informatiques. Le moteur de jeu
regroupe plusieurs moteurs comme le système qui s’occupe de l’interface utilisateur (gère la
mémoire, les entrées/sortie), le graphisme, le son, le réseau et la physique qui simule la pesanteur
par exemple. Raydium est un logiciel libre, sous licence GPL. Il intègre
OpenGL (Open Graphics Library) pour les graphismes ainsi que ODE (Open Dynamics Engine) pour
le moteur physique.
Figure 4 : Logo Raydium
Projet AR.Drone
8
2.3. OpenGL (Open Graphics Library) :
OpenGL est une API (Application Programming Interface) multiplateformes pour la
conception d’applications générant des images 3D mais également 2D. L'interface regroupe
environ 250 fonctions différentes qui peuvent être utilisées pour afficher des scènes
tridimensionnelles complexes à partir de simples primitives géométriques, généralement des
triangles.
Figure 5 : Logo OpenGL
2.4. ODE (Open Dynamics Engine) :
ODE est une bibliothèque logicielle libre et multiplateformes. C’est un moteur physique qui
permet de simuler l’interaction physique de corps rigides (exemple la gravité, les collisions entre
différents corps).
Figure 6 : Logo ODE
Projet AR.Drone
9
2.5. Tortoise SVN :
Subversion abrégé en SVN est un système de gestion de version qui regroupe toutes les
sources. On peut ainsi garder toutes les versions d’un projet. Tortoise SVN apporte aux utilisateurs de
Windows la possibilité d’utiliser SVN via une interface graphique. Il ajoute également de nouvelles
fonctionnalités qui permettent de voir instantanément l’état du projet à l’aide d’icônes (à jour,
modifié, en conflit, …).
Figure 7 : Tortoise SVN
2.6. Wireshark :
Wireshark est un logiciel libre multiplateformes anciennement connu sous le nom d’Ethereal.
Il permet l'analyse de protocole, ou « packet sniffer », et est utilisé dans le dépannage et l'analyse de
réseaux informatiques, le développement de protocoles, l'éducation et la rétro-ingénierie, mais aussi
le piratage.
Figure 8 : Wireshark
Projet AR.Drone
10
3. Structure d’un programme Raydium :
Pour qu’un programme Raydium fonctionne correctement, il est nécessaire de respecter une
certaine structure. Il faut au minimum, une fonction main et une fonction d’affichage. Dans notre
cas, nous avons également rajouté à la structure de base une fonction step().
3.1 Fonction main() :
Pour la fonction main(), le code de base à utiliser est l’appel à la fonction d’initialisation de
Raydium. On appelle ensuite la fonction de création de la fenêtre en lui précisant sa résolution, dans
notre cas 1024*600, le type de fenêtre à ouvrir, c’est-à-dire mode fenêtré ou mode plein écran, puis
le nom de la fenêtre voulu.
Il est également important d’appeler la fonction de changement de filtre des textures afin de
pouvoir bénéficier du filtrage trilinéaire* qui est la meilleure qualité d’image actuellement supportée
par Raydium.
3.2 Fonction d’affichage :
La fonction d’affichage est une fonction qui est appelée en boucle par Raydium, ainsi il faut
créer une fonction, dans notre cas display(), puis indiquer dans le main() que c’est la fonction
d’affichage qu'il doit appeler en boucle.
Une fois cette étape réalisée il faut rajouter le code minimum dans la fonction d’affichage,
c’est-à-dire la gestion de la caméra, l’appel de la fonction qui vide les tampons matériels ainsi que la
fonction qui permet de rafraîchir tous les éléments.
3.3 Fonction step() :
La fonction step() est une fonction qui est appelée en boucle tout comme la fonction
d’affichage à la différence que celle-ci est appelée à une période fixe. En effet, le nombre d’appels de
la fonction display() par seconde dépend du processeur de la machine tandis que pour la fonction
step(), il est fixe. Dans notre cas la fonction step() est appelé à 200 Hz. C’est cette fonction qui gère
l’asservissement évitant ainsi que le drone ait un comportement différent d’une machine à l’autre.
Projet AR.Drone
11
4. Partie Modélisation :
4.1. La 3D temps réel et la 3D pré-calculée :
La différence principale entre ces deux aspects de la 3D est la contrainte temporelle. Celle-ci
n’est pas la même dans les deux cas. En effet, en 3D temps réel, on recherche une animation fluide
quasi immédiate alors qu’en 3D pré-calculée on recherche un meilleur rendu visuel. En 3D précalculé, chaque image est pré-calculée une à une afin d’augmenter la qualité du rendu.
La 3D temps réel est utilisé principalement dans les jeux vidéo. Elle permet d’interagir avec la
scène 3D. Le temps de rendu d’un objet 3D dépend du maillage de l’objet, c'est-à-dire le nombre de
triangle que doit afficher la carte graphique. En effet, avant de pouvoir afficher un objet 3D, il faut
d’abord la subdiviser en triangle. Chaque objet 3D peut être divisé en triangle, d’où leur utilisation
par la carte graphique.
Figure 9 : Maillage d'un cercle
Ainsi il est plus facile d’afficher un ensemble de polygones simples qu’une forme complexe
surtout si elle possède des courbes. On peut également pré-calculer les éclairages d’un objet
inanimé, qui serra combiné avec les textures afin de gagner du temps au rendu.
La 3D pré-calculée est utilisé surtout dans les effets spéciaux au cinéma et la réalisation de
film d’animation où la priorité est la qualité de l’image. Pour réaliser une animation, chaque image
doit être calculé une à une. Le calcul d’une image peut prendre plusieurs heures voire plusieurs jours.
D’où l’utilisation de ferme de calcul, afin d’augmenter le temps de calcul.
Cependant avec les cartes graphiques dernières cris, certains jeux vidéo proposent aux
utilisateurs une grande qualité d’image proche du photoréalisme tout en ayant une fluidité d’image.
Figure 10 : Film d'animation Shrek
Projet AR.Drone
Figure 11 : Jeux vidéo photo-réaliste Crysis 2
12
4.2. Création des objets 3D :
Dans ce projet, Blender nous a permis de créer les objets en trois dimensions dont nous
avions besoin, c'est-à-dire le drone et le décor. Cette partie s’est déroulée en deux étapes : la
modélisation de l'objet et le rendu.
La modélisation va consister à créer l’objet. La modélisation fait appel à un espace vectoriel
de 3 dimensions qui va contenir les axes x, y et z. Chaque point de l’objet est représenté par un
triplet unique. On représente ainsi l’objet par un ensemble de valeurs, appelé matrice
tridimensionnelle.
Prenons par exemple un cube de longueur 4 ayant pour origine O de coordonnée (0, 0, 0)
Figure 12 : Exemple de représentation d'un cube
Ces sommets sont définis par les coordonnées de ces huit points :
(-2, -2, -2) (2, -2, -2) (-2, 2, -2) (2, 2, -2)
(-2, -2, 2) (2, -2, 2) (-2, 2, 2) (2, 2, 2)
C’est la matrice tridimensionnelle du cube.
Il existe de nombreuses techniques de modélisation comme la modélisation par courbes
(NURBS) qui permet de modéliser des surfaces le plus précisément possible. Mais La principale
technique de modélisation, utilisée dans la plupart des jeux vidéo et des films d’animation, est la
modélisation polygonale. Celle-ci consiste à définir un objet par un ensemble de polygones décrit par
des sommets (vertex), arrêtes (edge) et faces (face). Elle permet de différencier l’intérieur et
l’extérieur du modèle. En effet, lors de l’application des textures sur l’objet, la texture n’est visible
que d’un côté. Il est donc important d’avoir les polygones orientés dans le bon sens. Sinon, lors du
rendu de la scène sous Raydium, des parties de l’objet risque d’être invisible.
C’est donc cette technique que nous avons utilisé tout le long du projet.
Projet AR.Drone
13
La principale difficulté était de réaliser des objets réalistes tout en ayant un faible maillage,
afin de ne pas ralentir les performances du programme. Il fallait trouver un compromis entre les
performances et la qualité de la représentation de ces objets. Lors de la réalisation du drone nous
n’avions pas pensé au maillage qui est vite devenu énorme. Cependant ayant compris notre erreur
nous avons réalisé l’environnement du drone avec un maillage le plus petit possible.
Figure 13 : Maillage du drone
Figure 14 : Maillage de la salle
Le rendu va permettre de donner une couleur, une texture à l’objet. C’est généralement la
partie la plus longue et la plus importante car elle va permettre de rendre l’objet le plus proche du
modèle réel. Elle se décompose à son tour en plusieurs étapes :
L’application des textures va permettre d’appliquer une image sur une surface ou un volume
en trois dimensions.
Le calcul de l’éclairage permet de calculer les ombres sous forme d’image. Elle va être
ensuite combinée avec la texture pour rendre une scène encore plus réaliste. C’est le principe du
MultiTexturing*.
Figure 15 : Rendu du décor
Après avoir créé les différents objets, il ne reste plus qu’à les exporter. Pour cela Raydium
propose un script Python qui permet d’importer ou exporter des .tri. Le .tri est le format de fichier
dans lequel Raydium stocke les objets 3D. Il stocke les coordonnées des points en x, y et z, ainsi que
les coordonnées de texturage et la texture utilisée, stockée dans un autre fichier ayant pour
extension .tga.
Projet AR.Drone
14
5. Partie physique
5.1. Création du drone dans Raydium :
Afin de pouvoir représenter au mieux le modèle physique du drone nous avons dû nous
renseigner sur les caractéristiques du drone.
L’AR.Drone de Parrot, pèse 380g sans la protection, et 420g avec la protection. Pour ce qui
est des dimensions : 52,5x 51,5 cm avec carène et 45x29 cm sans carène. Les hélices font 20 cm de
longueur et 1,5 cm de largeur.
Figure 16 : Drone avec la protection
Figure 17 : Drone sans la protection
Pour le modèle physique nous avons créé un objet Raydium, puis nous y avons ajouté
différentes boxes pour représenter les différentes parties du drone tel que le corps, les moteurs, et
les avons jointes ensemble.
Figure 18 : Modèle Physique du drone sous Raydium
Projet AR.Drone
15
5.2. Intégration des objets 3D dans le moteur physique :
Raydium nous donne la possibilité de créer deux types d'éléments, une sphère ou une boite.
Ces éléments permettent au moteur physique de calculer les collisions entre les objets et les forces
exercées sur eux. Cependant, au niveau graphique, ils ne sont visibles qu’en mode DEBUG. Ils servent
juste d’enveloppe pour les objets 3D.
Figure 19 : Drone en mode DEBUG
Pour représenter le drone, nous avons utilisé une boîte pour le corps. Pour donner encore
plus de réalisme, nous avons utilisé les moteurs ainsi que les joints que Raydium nous proposait,
pour faire tourner les hélices. Les joints permettent de créer des liens entre les différents éléments
d’un objet.
Nous avons créé quatre charnières, attachées au corps du drone et aux hélices, que nous
avons réglées pour qu’elles puissent tourner selon l’axe z. Ensuite nous avons créé deux moteurs.
Raydium nous propose trois moteurs :
Moteur à force: permet de motoriser un joint.
Moteur angulaire : permet de donner un ordre directionnel à un joint.
Réacteur : permet d’appliquer directement une force à un objet.
Pour faire tourner nos hélices nous avons utilisé le moteur à force de Raydium. On en a créé
un pour le côté droit et un pour le côté gauche. Ces deux moteurs ont été ensuite rattachés aux
charnières correspondant. Ces deux moteurs ont été ensuite rattachés aux charnières
correspondant. Ensuite il ne reste qu’à donner une vitesse à nos moteurs pour qu’ils puissent
tourner.
Projet AR.Drone
16
5.3. Gestion des forces :
Pour gérer les déplacements nous utilisons des moteurs de Raydium sur lesquels on applique
des forces. Nous appliquons quatre forces, chacune de ces quatre forces est appliquée sur un moteur
afin de pouvoir générer les mouvements.
Nous avons également ajouté des forces plus globales comme la force de gravité, mais aussi
des forces de perturbation. Parmi ces forces, les effets de sol déstabilisent le drone lorsque qu’il est
proche du sol ou proche des murs.
Les forces de perturbations que nous avons créées, sont des forces qui s’appliquent sur un
des moteurs de façon aléatoire avec une puissance aléatoire, nous avons mis en place une valeur
maximale pour cette force afin d’éviter de rendre le drone instable.
Figure 20 : Schéma des forces sur le drone
Projet AR.Drone
17
5.4. Gestion de l’asservissement* :
L’asservissement est un algorithme qui permet de stabiliser et d’améliorer le comportement
du drone. Ainsi, lorsque nous lui donnons une consigne en Z, l’asservissement permet au drone de ne
pas monter instantanément mais progressivement à la position demandée. Il permet également de le
stabiliser lorsque le drone est en vol.
Pour réaliser l’asservissement du drone nous utilisons deux boucles, une boucle de bas
niveau qui stabilise le drone par rapport à ses angles réel et les angles théorique qu’il devrait avoir,
puis une seconde boucle que l’on peut qualifier de plus haut niveau. Cette dernière s’occupe
d’améliorer la stabilisation, en effet elle gère les comparaisons des positions, mais aussi la
comparaison des vitesses en X et en Y. La boucle de haut niveau tourne cinq fois moins vite que la
boucle de bas niveau, ce qui permet d’économiser ainsi un maximum de puissance machine.
Figure 21 : Schéma des boucles d’asservissement
Pour réaliser l’asservissement du drone nous récupérons tout d’abord les angles de rotation
de ce dernier, ensuite nous récupérons la position réelle du drone, puis sa vitesse actuelle.
On utilise ensuite une fonction qui permet de transformer les coordonnées du drone dans les
coordonnées du monde virtuel. Cette fonction a pour but de faire en sorte que le vecteur du drone
ait toujours l’abscisse et l’ordonnée dans le même sens que le monde virtuel, ce qui permet ainsi de
ne pas fausser les calculs en confondant les axes X, et les axes Y.
Une fois ceci réalisé, nous calculons les erreurs en vitesse de X et en vitesse de Y, c’est-à-dire
l'écart entre la vitesse réelle du drone et la vitesse théorique et nous réglons la consigne en X et la
consigne en Y.
Ensuite on définit un maximum et un minimum pour ces variables afin d'éviter que le drone
ne se déplace trop vite ou trop lentement.
Une autre étape consiste à calculer l'erreur de l'angle en x, y, z. Pour cela, il calcule tout
d’abord l’erreur entre sa position en Z et la consigne qui lui a été fournie, plus cette erreur sera
importante et plus le drone montera vite. Ce système permet que lorsque la position du drone se
rapproche de la consigne, alors il ralentit évitant ainsi de dépasser la consigne donnée.
Projet AR.Drone
18
5.5. Gestion des logs et du PHP :
Pour le réglage de cet asservissement nous avons dû effectuer beaucoup de tests. Pour
rendre ces tests plus productifs nous avons intégré une gestion des logs du drone pour sauvegarder
les données qui nous intéressaient dans un fichier, afin de les étudier. Dans la même optique
d’optimisation des réglages, nous avons intégré une gestion en PHP de certaines variables de notre
programme dans le but de pouvoir modifier ces variables. Ceci nous a permis de modifier les
variables pendant l’exécution du programme ce qui nous évitait ainsi une grande perte de temps
pour recompiler le projet à chaque test.
Toujours pour effectuer nos différents tests, nous avons développé une fonction qui permet
au drone de réaliser un scénario particulier, c’est-à-dire qu’il effectue toujours au même moment un
même déplacement mais avec des réglages différents, ce qui permet ainsi d’exploiter au maximum
nos fichiers de log.
Figure 22 : Aperçu de la console PHP
Projet AR.Drone
19
6. Réseau :
La communication entre le simulateur et le contrôleur s'effectue via un réseau wifi.
6.1. L'établissement du lien :
La principale difficulté dans l'établissement du lien était de respecter les séquences de
connexion et de communication de l'application AR.FreeFlight. En effet, nous avons dû étudier en
détails la manière avec laquelle l'application et le drone réel communiquent afin de simuler les
réponses du drone dans notre simulateur. Cette étude a pu être réalisée grâce à des outils tels que
Wireshark et à la documentation « AR.Drone Developer Guide SDK 1.5 ».
Le simulateur utilise les protocoles TCP et UDP. En effet, la connexion entre le contrôleur et
le simulateur utilise le protocole TCP (ports 21, 23, 5551 et 5559) alors que la communication (après
connexion) est en UDP (ports 5554, 5555, 5556). Réalisée par la fonction ardrone_socket_init(), la
connexion se déroule de la manière suivante :
Connexion FTP sur port 5551
Connexion FTP sur port 21
Connexion Telnet sur port 23
Une fois ces trois opérations réalisées avec succès, l'application AR.FreeFlight est connectée
au simulateur.
6.2. Déroulement de la communication :
Chaque socket possède un callback (fonction appelée en cas de réception d'un paquet). La
communication entre l'application et le simulateur peut être résumée dans le fonctionnement des
quatre fonctions principales : socket_loop(), send_navdata(), send_video() et atport().
La fonction socket_loop() est la fonction qui gère le réseau. Appelée en boucle, elle permet
de rafraîchir les données de navigation ainsi que le flux vidéo et de les envoyer au contrôleur grâce à
send_navdata() et send_video().
La fonction send_navdata() informe le contrôleur de l'état du drone. Elle gère la construction
et l'envoi des données de navigation, sous forme d'une structure de type navdata_t (cf. 3.4.3.
Optimisation de la communication).
La fonction send_video() s'occupe d'encoder (cf. explication du pipeline dans le paragraphe
3.4. Imagerie) et d'envoyer la vidéo de la caméra frontale.
Enfin, la fonction atport() interprète les trames* reçues par le simulateur. Ces trames
envoyées par l'application AR.FreeFlight renseignent le simulateur des commandes émises par le
Projet AR.Drone
20
contrôleur (décoller, monter, descendre, etc.). Ainsi, atport() est à l'origine de tout mouvement du
drone virtuel (hormis le pilotage local via clavier).
6.3. Optimisation de la communication :
Grâce au code du contrôleur de drone exécutable sur PC fournit par Parrot, nous avons donc
identifié les structures essentielles constituant les trames de communication. Ainsi, nous avons pu
développer le code de base de contrôle du simulateur, reposant sur la fonction socket_loop() et le
protocole UDP.
Cependant, la gestion de socket_loop() de manière linéaire était très lourde et ralentissait
notre programme du fait du nombre déjà important de fonctions appelées en boucle (display(),
step(), …). C'est pourquoi nous avons choisi de threader toute la partie réseau du programme. Pour
cela, nous avons simplement développé la création d'un thread exécutant toutes les primitives liées
au réseau (dont l'appel à socket_loop() en boucle) dès le lancement du programme. Ainsi, nous avons
grandement amélioré la communication entre notre simulateur et l'application.
void *network_thread_runtime (void * arg)
{
vlib_init();
ardrone_socket_init();
while ( ! STOP_THREAD )
{
socket_loop();
}
return NULL;
}
Figure 23 : Code du thread réseau
Une fois la connexion fluide et stable, nous nous sommes penchés sur le cœur des trames
circulant du simulateur vers l'application : la structure navdata_t. Cette structure contient toutes les
informations indispensables au contrôleur comme l'état du drone (posé, décollé) mais également
toute une série d'options facultatives qui peuvent être ajoutées via une autre structure
(navdata_demo_t) comme son altitude, sa position exacte (en trois dimensions), son inclinaison
(tangage, roulis et lacet), ou encore le niveau de batterie restant au drone. Nous avons donc ajouté
une structure navdata_demo_t dans le champ 'options' de la structure navdata_t existante. Cela
nous a permis de développer une petite fonction émulant la batterie du drone et donc d'envoyer
cette valeur (battery_simu_level) à l'application, imitant ainsi la consommation de batterie du vrai
drone en utilisation standard. Une autre fonction implémentée dans le même temps permet, si on
préfère, de transmettre à l'application non plus un niveau linéaire mais le niveau réel de la batterie
du PC (s'il s'agit d'un ordinateur portable).
Projet AR.Drone
21
7. Imagerie :
La partie imagerie repose sur la construction et la maintenance d'un élément essentiel au
réalisme du drone : le pipeline*. Le pipeline regroupe tout le traitement vidéo nécessaire au
simulateur, de l'acquisition à l'envoi en passant par l'encodage.
7.1. Le rendu :
Première étape de notre pipeline, le rendu consiste à simuler les vues déportées. L'AR.Drone
propose deux vues déportées grâce à ses caméras frontale et ventrale. Du côté du simulateur, la
reproduction de ces caméras a donc été la première préoccupation du responsable Imagerie.
Après diverses recherches dans la documentation Raydium et les exemples d'application, la
solution a été trouvée. En effet, Raydium offre la possibilité de créer des caméras déportées et de les
afficher en simultané sur un seul écran. Ces éléments déportés s'appellent des viewports.
Du point de vue implémentation, une fois les viewports créés (on leur attribue un nom et une
résolution), il suffit de positionner leur caméra puis de les afficher dans la fenêtre, à l'endroit voulu.
Dans notre cas, la caméra du viewport « viewport_frontal » a été positionnée à l'avant du drone et
celle du viewport « viewport_ventral » sous le drone. Les viewports, quant à eux, ont été placés en
haut a gauche (viewport_ventral) et en haut à droite de l'écran (viewport_frontal ).
Figure 24 : Illustration des viewports
Projet AR.Drone
22
La principale difficulté dans l'établissement des viewports fut le respect d'une résolution en
4/3 en vue de l'envoi du rendu vers l'application AR.FreeFlight qui affiche du 320x240. En effet, la
résolution des viewports se configure en fonction de celle de la fenêtre. Concrètement, il faut
indiquer à la fonction de rendu raydium_viewport_draw() le pourcentage de la largeur et le
pourcentage de la hauteur de la fenêtre que l'on souhait attribuer au viewport. Ainsi, si on entre un
pourcentage identique en x et en y, le viewport possède le même ratio que la fenêtre (et donc pas
toujours 4/3).
Il a donc fallu établir une formule pour recalculer à chaque frame*, en fonction d'un
pourcentage constant de la largeur de la fenêtre, le pourcentage optimal de la hauteur, à inscrire
dans la fonction de rendu, permettant de conserver continuellement un ratio de 4/3 sur le viewport,
et ce quelle que soit la résolution de la fenêtre.
Figure25: Formule de conservation de la résolution du viewport
7.2. L'acquisition :
L'acquisition désigne le fait de stocker, à chaque frame*, l'image affichée par les viewports
dans un buffer afin de pouvoir ensuite l'encoder et l'envoyer. Les viewports de Raydium ne
permettant pas directement cet enregistrement, nous nous sommes tout d'abord tournés vers une
méthode de capture d'écran. Cette méthode consistait à faire une capture d'écran régulière au
niveau du viewport, puis de l'enregistrer sur le disque dur, pour ensuite l'envoyer. Très lourde, elle
n'était pas du tout adaptée à la situation. Cependant, l'analyse du fonctionnement des primitives
Raydium de capture d'écran comme raydium_capture_frame_jpeg_now() nous a révélé l'unique
fonction dont nous avions besoin.
La fonction gl_ReadPixels() provient de l'API OpenGL et permet de remplir un buffer avec les
données des pixels demandés. Grâce à cette fonction, nous avons pu récupérer les données du
viewport simulant la caméra frontale dans une variable « char img[] » de la manière suivante :
if ( ! strcmp(nom,"camera_frontale") )
{
glReadPixels(0,0,VIDEO_WIDTH,VIDEO_HEIGHT,
GL_RGB,GL_UNSIGNED_BYTE,img);
}
Figure 26 : Code d'acquisition d'un viewport
Projet AR.Drone
23
7.3. L'encodage :
Le flux vidéo étant destiné à l'application AR.FreeFlight, nous avons dû respecter l'encodage
employé par le microprocesseur du vrai drone. Comprendre et reproduire l'algorithme de cet
encodage fut la tâche la plus compliquée de la partie Imagerie mais nous avons pu compter sur M.
Laffont et la documentation « AR.Drone Developer Guide SDK 1.5 » pour nous fournir toutes les
explications nécessaires.
L'encodage des images filmées par le drone est proche de l'encodage JPEG. Ces images sont
tout d'abord converties au format YCBCR. Concrètement, chaque image est découpée en blocs de
16x16 pixels appelés macroblocs. Chaque macrobloc est ensuite divisé en 6 blocs de 8x8 pixels : 4
blocs (Y0, Y1, Y2 et Y3) forment la composante lumineuse du macrobloc (correspondant à une
version noir et blanc de celui-ci) et les 2 autres (Cb et Cr) représentent sa couleur (en composante
bleue et rouge).
Figure 27 : Le format YcbCr
Ensuite, la matrice de données de chacun de ces blocs de 8x8 pixels subit une DCT*
(transformée en cosinus discrète), une quantification* et un ordonnancement en zig-zag*. L'étape
finale de compression est alors effectuée par un algorithme propriétaire. Cet algorithme, proche de
la compression RLE/Huffman* utilisée pour l'encodage JPEG, consiste à optimiser la matrice, tant
pour les valeurs nulles (RLE) que pour les valeurs non-nulles (Huffman) de sorte à obtenir une
matrice finale aussi « épurée » que possible tout en restant assez similaire à l'originale pour
conserver une image de qualité.
Du point de vue implémentation, nous avons récupéré et adapté les fonctions d'encodage
utilisées dans les exemples fournit par le SDK : vlib_encode(), rgb2yuy() et video_encode_picture().
Nous sommes donc parvenus à obtenir, à partir d'une capture d'un viewport, une image respectant
les règles d'encodage exigées par l'application AR.FreeFlight.
Projet AR.Drone
24
Figure 28 : Le processus d'encodage
7.4. L'envoi :
Une fois l'image encodée, il ne nous reste plus qu'à la faire parvenir au contrôleur. Pour cela,
nous utilisons le réseau wifi établit entre le simulateur et l'application (voir 3.4. Réseau). Ainsi, il
suffit d'envoyer cette image sur la socket UDP créée à cet effet (port 5555).
Projet AR.Drone
25
8. Bilan Technique :
Le bilan de ce projet est positif, en effet après la phase de compréhension et d’appropriation
du projet, nous avons réussi à atteindre les objectifs qui nous avaient été soumis.
Pour la partie modélisation, il nous était demandé de créer un modèle réaliste du drone.
Cette étape est une réussite car nous avons réussi à modéliser le drone avec et sans sa protection.
Cependant nous nous sommes rendu compte que nos modèle graphique utilisait beaucoup de vertex
ce qui demande de la puissance de calcul à la machine, c’est pourquoi nous pensons qu’il est possible
d’améliorer le modèle en économisant ces vertex.
Pour la partie physique, il nous était demandé de créer un simulateur dans lequel serait
représenté le modèle physique du drone avec un comportement proche de celui de la réalité, nous
sommes parvenus à ce résultat, cependant il est toujours possible d’améliorer le simulateur en
mesurant les temps que met le drone pour décoller, se déplacer, etc. et en appliquant ces temps sur
le simulateur.
Pour la partie imagerie, nous avons réussi à faire ce qui nous était demandé : nous avons
émulé des caméras embarquées sur le faux drone et réussi à afficher leurs images dans des vues
déportées du simulateur. Puis nous sommes parvenus à les encoder afin de les rendre
compréhensibles et donc affichable par l’application AR.FreeFlight.
Pour la partie réseau, il nous était demandé de gérer les connections entre l’ordinateur et le
contrôleur afin de pouvoir utiliser l’application de pilotage du vrai drone pour contrôler le
simulateur. Ceci fut une réussite, il est actuellement possible de lancer le simulateur de s’y connecter
avec un iPhone et de le contrôler. De plus, plusieurs optimisations ont été apportées au réseau
comme un thread ou la gestion de la batterie du drone.
Nous avons pensé à d’autres idées d’améliorations qui pourraient être apportées au
simulateur. Il serait envisageable de le rendre multiplateforme, en effet le simulateur n’est
actuellement fonctionnel que sur Windows. Il serait également possible d’ajouter la gestion de la
connexion d’autres contrôleurs pour avoir plusieurs drones au même moment dans le simulateur.
Cela pourrait être intéressant dans le cadre du développement d’un jeu visant à imiter le
comportement des applications de combat entre drone actuellement vendues par Parrot. Le jeu
n’utiliserait que l’application gratuite AR.FreeFlight, tous les effets d’explosions et de missiles étant
obtenus au niveau du simulateur (et non de l’application).
Pour conclure, nous sommes très satisfaits d’avoir rempli nos objectifs et d’avoir créé un
logiciel fonctionnel.
Projet AR.Drone
26
Conclusion :
Ce projet fut l'un des exercices les plus complexes et techniques que nous avons pu
rencontrer tout au long de notre cursus scolaire à l'IUT. En effet nous avons dû faire des recherches
concernant la modélisation 3D, les asservissements et l’encodage d’images, des domaines qui juste
que là nous étaient totalement inconnus.
De même, nous n'avions jamais réalisé de programme 3D et avons donc dû apprendre à nous
servir du moteur de Jeu Raydium, avec son moteur physique ODE, ce qui fut une expérience très
enrichissante.
D'un point de vue technique, le projet nous a permis d'améliorer nos connaissances en C. La
partie réseau gérant la connexion entre l'ordinateur et le périphérique iPod, iPhone, ou iPad nous a
également permis de consolider les notions de réseau que nous avions vues en cours.
Enfin, ce projet fut très enrichissant au niveau relationnel. Nous avons pu améliorer nos
capacités de travail en équipe et d’organisation. En effet lors de l'analyse du projet nous avons
réfléchi tous ensemble aux différentes parties afin de pouvoir diviser le travail et le rendre le plus
rapide et le plus efficace possible.
Pour conclure, ce projet fut un excellent moyen de consolider nos connaissances en
informatique, tant du point de vue de l’analyse que du codage. Il nous a également permis d’enrichir
notre expérience du travail en équipe ainsi que d’acquérir des notions qui ne sont pas abordées en
DUT Informatique.
Projet AR.Drone
27
English Summary :
Thinking we have not learned enough about real-time 3D virtualization and wanting to know
more about this, we chose the "AR.Drone simulator" project. With this project, we wanted to
improve our knowledge in network, 3D and forces management.
At the beginning, with our supervisor, there were five of us involved in the project. The goal
of this project was to build on a PC a drone simulator of Parrot four-engine drone, named AR.Drone.
The drone had to be driven, like the real drone, by an iPod, an iPhone or an iPad, through a Wifi
connection and the "AR.FreeFlight" (developed by Parrot) application.
In this project, we used different tools, Blender for the graphics and Raydium for the physics.
Blender is a free software animation, 3D modelling and rendering tool. It permits us to create 3D
objects and Raydium, the physics engine, uses these objects to apply forces on them.
The project was divided into four stages. The graphics part had to deal with creating the 3D
drone and its environment. The physics part had to simulate the different forces applied on the
drone in order to mimic the behaviour of the maximum true drone. The imagery part consisted in
creating, managing and encoding the two camera streams. The network part had to deal with
establishing the link between the drone and the controller on which video, statement and movement
streams are broadcast.
During our development, we encountered several problems. The main difficulty was the link
between the controller and the application, and about half of the project, our fourth partner who
was responsible for the network part left the team. To complete the project, we had to review the
way we had shared our tasks. Fortunately, our supervisor was really involved and so helped us to
manage with the link part.
In this project, we learned how to work in group and how to share out the tasks, to work
faster and more efficiently. We had to learnt how to use Blender to create the 3D objects and how to
program in 3D with Raydium.
The project is finished and it runs. There are still some graphics problems like two shadows
for the drone and for the moment it only works with Windows.
In the future, our project could be completed by building a game in which several players
could join a server and play on the same map, controlling their own virtual drone.
Projet AR.Drone
28
Bibliographie - Webographie :
Documentation officielle « AR.Drone Developer Guide » (Parrot SA)
Site web : http://raydium.org/
Site web : http://www.blender.org/
Site web : http://www.ode.org/
Site web : http://tortoisesvn.tigris.org/
Site web : http://www.wireshark.org/
Site web : http://fr.wikipedia.org/
Projet AR.Drone
29
Lexique :
Asservissement : « Un asservissement en automatique est un algorithme dont l'objet principal est de
stabiliser et d'améliorer la réaction d'un système par rapport à sa consigne. Le principe général est de
comparer la consigne et l'état du système de manière à le corriger. »
Référence : http://fr.wikipedia.org/wiki/Asservissement_%28automatique%29
Compression RLE/Huffman : « La compression RLE/Huffman s'effectue sur la matrice résultant de
l'ordonnancement en zig-zag, le résultat est compressé selon un algorithme RLE basé sur la valeur 0,
puis un codage entropique de type Huffman. »
Référence : http://fr.wikipedia.org/wiki/JPEG
DCT : « La transformée DCT (Discrete Cosine Transform, en français transformée en cosinus discrète),
est une transformation numérique qui est appliquée à chaque bloc et pour chaque « couleur ». Cette
transformée est une variante de la transformée de Fourier. Cette méthode permet de décrire chaque
bloc en une carte de fréquences et en amplitudes plutôt qu'en pixels et couleurs. »
Référence : http://fr.wikipedia.org/wiki/JPEG
Filtrage trilinéaire : « Filtrage des textures sur le plan horizontal, vertical et en profondeur (3D),
permettant d’augmenter encore plus la qualité d’image. » « Ce filtrage intervient sur la jointure
d’une même texture répété plusieurs fois sur une grande surfaces. »
Référence : http://www.pc-code.com/base/numetlet/let/f/filtrage_trilineaire.php
Frame : Dans Raydium, une frame correspond à un tour de la boucle display(). C'est donc un
rafraichissement de tous les objets.
MultiTexturing : « Le Multi-texturing est une technique de graphisme qui consiste à créer plusieurs
niveaux de textures sur le même polygone. »
Référence : http://www.metaboli.fr/lexique-jeux-video/definition-de-multi-texturing.htm
Ordonnancement en zig-zag : L'ordonnancement en zig-zag d'une matrice M consiste à créer une
autre matrice réalisée à partir du parcours de M en suivant un zig-zag. Cette technique est utilisée
pour la compression JPEG afin d'éliminer tous les zéros de la matrice résultant de la quantification.
Pipeline : « Un pipeline est un élément d'un circuit électronique dans lequel les données avancent les
unes derrière les autres, au rythme du signal d'horloge »
Référence : http://fr.wikipedia.org/wiki/Pipeline_%28informatique%29
Quantification : « La quantification est l’étape dans laquelle on perd réellement des informations (et
donc de la qualité visuelle), mais c'est celle qui fait gagner beaucoup de place (contrairement à la
DCT, qui ne compresse pas). La quantification consiste à diviser la matrice résultant de la DCT par une
autre, appelée matrice de quantification, et qui contient 8×8 coefficients savamment choisis par le
codeur. Le but est ici d’atténuer les hautes fréquences, c’est-à-dire celles auxquelles l’œil humain est
très peu sensible. Ces fréquences ont des amplitudes faibles, et elles sont encore plus atténuées par
Projet AR.Drone
30
la quantification (les coefficients sont même ramenés à 0). »
Référence : http://fr.wikipedia.org/wiki/JPEG
Simulateur : « Programme informatique visant à simuler un phénomène physique complexe »
Référence : http://fr.wikipedia.org/wiki/Simulation_informatique
Trames: « Une trame est un paquet d'information véhiculé au travers d'un support physique. »
Référence : http://fr.wikipedia.org/wiki/Trame
Projet AR.Drone
31
