1 Simulateur du drone¶

1.1 Présentation générale de cette partie du projet :¶

Le simulateur du drone a pour objectif final de reproduire exactement les mouvements du drone afin de le tester dans un environnement virtuel, ce qui réduit les risques de destructions inopinées.
Le drone, dans l'espace de simulation, peut-être contrôlé de deux manières : Par le clavier, ou par une tablette sous Android dont on reçoit les consignes via wi-fi.

Nous sommes donc partis d'un existant, et nous sommes appuyés sur le Wiki de Raydium disponible sur internet, contenant les descriptions des fonctions, ainsi que des exemples.

Les principaux outils utilisés pour développer le simulateur sont :

Raydium :¶

Raydium est une bibliothèque regroupant plusieurs bibliothèques plus bas niveau ayant toutes une application dans le domaine du jeu vidéo 3D. De plus, Raydium propose une API composée de fonctions haut niveau ayant pour but de faciliter l'ecriture de morceaux de code communs à tous les jeux vidéos. Raydium dispose donc de moteurs pour gérer tout ce qui est relatif aux jeux vidéos, des graphismes au son, en passant par la physique et le réseau. Dans le cadre du simulateur, nous nous sommes surtout attachés aux moteurs qui gèrent la physique et les graphismes, respectivement ODE et OpenGL.

Code::Blocks :¶

Code::Blocks est l'environnement de développement intégré au SDK de Raydium. Il nous a donc fallu apprendre à l'utiliser, vu qu'il est nécessaire. C'est un IDE assez facile à prendre en main grâce à son compilateur intégré et son interface modifiable à souhait.

1.2 Particularités d'un programme incluant Raydium¶

Raydium étant codé en C, une fonction main est nécessaire à tout programme l'incluant. De plus, Raydium a besoin d'une fonction d'affichage, et nous avons utilisé une autre fonction propre à Raydium (plus précisément à ODE), destinée à être appelée de façon très régulière : step().

main : La fonction main servira à initialiser des paramètres propres à Raydium concernant l'application, notamment la résolution de la fenêtre, le filtre des textures, le champ de vision, la (non-)activation des ombres, tout ce qui est relatif à la lumière, les .tri à utiliser, la gravité, ainsi qu'à définir quelles fonctions correspondront à la fonction d'affichage et la fonction appelée de façon récurrente.

affichage : Tâche effectuée par la fonction display(), dans le cas de notre simulateur. Sert à rafraîchir la caméra ainsi que les différents viewports, elle se doit donc d'être appelée souvent. On appelle aussi la fonction servant à la gestion du clavier dans display(). De par sa nature gourmande en CPU (à cause des traitements graphiques réguliers et nombreux), sa fréquence d'appel dépend directement du processeur.

step : Fonction censée être appelée très régulièrement. Elle provient d'ODE, il convient donc de lui faire effectuer tout ce qui tient de la physique.

1.3 Déroulement du projet¶

Analyse de l'existant¶

Etant partis d'un existant suffisamment conséquent, il nous incombait d'analyser sa structure, son fonctionnement, ainsi que de comprendre la raison d'être de chacun des appels de fonctions de Raydium. Cette partie nous a pris du temps car il fallait non-seulement comprendre le but de chaque partie du code, mais aussi maitriser les concepts propres à Raydium, tels, notamment, celui des viewports, et ce qui, plus généralement, concerne le fonctionnement d'une application avec des animations en 3D.

Cette analyse nous a permis de repérer ce qui n'allait pas dans l'agencement des différentes parties du code du simulateur. Ainsi, nous avons remarqué que la gestion du clavier était mise dans step(), qui est censée contenir uniquement ce qui concerne la physique et les asservissements. En effet, step() est une fonction appelée beaucoup plus souvent que display() (Ceci étant dû au fait que display() est une fonction faisant du traitement graphique, qui ne nécessite donc pas d'être appelée plus de 25 images par seconde environ (le minimum nécessaire pour que l'être humain voit une action fluide)). De plus, il nous semblait inutile et coûteux d'effectuer une scrutation du clavier plus de 25 fois par seconde (La fréquence d'appel de step(), qui était la fonction contenant le code de gestion du clavier, est de 200Hz, ce qui est beaucoup plus que nécessaire pour faire une gestion du clavier réactive).

Nous avons aussi pu constater que l'ébauche de physique présente sur l'existant n'était pas vraiment cohérente. Notamment une tentative pour gérer le déplacement du drone avec une variable speed, ce qui n'a pas vraiment de sens vu que la vitesse du drone dépend de son inclinaison par rapport à l'horizontale (en effet, d'un point de vue physique, le drone ne peut produire qu'une force vers le bas. Or, plus il est penché en avant, plus la force produite est dirigée vers l'arrière, plus la vitesse du drone augmente). De plus, les valeurs possibles de la variable speed donnaient au drone un comportement tout sauf réaliste.

De plus, les prototypes des fonctions prenaient en paramètres des pointeurs sur des variables qu'on ne modifiait, voire, n'utilisait pas. De plus, certaines fonctions, notamment celle concernant la régulation, avaient besoin de paramètres provenant de fonctions qui ne les appelaient pas. Il nous a donc fallu choisir un moyen de communication entre fonctions différents de la simple utilisation de paramètres et de codes de retour. Notre choix s'est porté sur les variables globales.

h3.