1 Projet AR.Drone

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

2 Projet AR.Drone

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.

3 Projet AR.Drone

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.

4 Projet AR.Drone

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

5 Projet AR.Drone

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

6 Projet AR.Drone

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.

7 Projet AR.Drone

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

8 Projet AR.Drone

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

9 Projet AR.Drone

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

10 Projet AR.Drone

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

11 Projet AR.Drone

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.

12 Projet AR.Drone

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 Figure 11 : Jeux vidéo photo-réaliste Crysis 2

13 Projet AR.Drone

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.

14 Projet AR.Drone

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.

15 Projet AR.Drone

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

16 Projet AR.Drone

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.

17 Projet AR.Drone

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

18 Projet AR.Drone

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.

19 Projet AR.Drone

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

20 Projet AR.Drone

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

21 Projet AR.Drone

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.

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).

void *network_thread_runtime (void * arg) { vlib_init(); ardrone_socket_init(); while ( ! STOP_THREAD ) { socket_loop(); } return NULL; }

22 Projet AR.Drone

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

23 Projet AR.Drone

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 :

Figure 26 : Code d'acquisition d'un viewport

if ( ! strcmp(nom,"camera_frontale") )

{

glReadPixels(0,0,VIDEO_WIDTH,VIDEO_HEIGHT,

GL_RGB,GL_UNSIGNED_BYTE,img);

}

24 Projet AR.Drone

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.

25 Projet AR.Drone

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).

26 Projet AR.Drone

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.

27 Projet AR.Drone

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.

28 Projet AR.Drone

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.

29 Projet AR.Drone

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/

30 Projet AR.Drone

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

31 Projet AR.Drone

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