Le déroulement du projet¶

Découverte¶

N’ayant jamais utilisé Raydium, lorsque nous avons récupéré le projet de l’an dernier la compréhension du code était difficile, les noms de variables utilisées n’étant pas toujours très clairs il nous a fallu nous plonger dans une étude approfondie de ce code. Ainsi cette première étape d’éclaircissement nous a menés à bien comprendre les tenants et aboutissants du projet ainsi que le fonctionnement des algorithmes.

En étudiant le projet et grâce aux tutoriels Raydium, nous avons pu comprendre la structure d’une application Raydium à savoir le découpage en callback de physique et d’affichage, la génération de la scène ainsi que le paramétrage du moteur à l’initialisation et l’intégration des fonctions d’ODE dans Raydium. La documentation de l’API Raydium disponible sur le wiki du moteur nous a également était d’une grande utilité, nous permettant de comprendre l’action de chaque fonction et ce que représentait chaque paramètre.

Le code se découpe en trois parties fonctionnelles : une mise en place (main()), un callback d’affichage (display()) et un callback de gestion de la physique (regulation()). Concernant la mise en place, elle consiste à paramétrer le simulateur comme par exemple la fréquence de la physique, le modèle 3D à utiliser pour le monde (ground) ou encore un nombre limité d’images par secondes ou le type de filtre à appliquer aux textures. Le callback d’affichage gère notamment le rendu de la scène ainsi que les caméras pour chaque image générée. Enfin le callback de physique, il est chargé d’assurer la régulation du drone en vol et de gérer les forces qui entrent en jeu.

Premières modifications¶

L’étape suivante a consisté en la remise à l’endroit des contrôles du drone via les touches fléchées, c’est-à-dire que le drone volait en direction de la caméra et non vers l’avant quand on appuyer sur flèche du haut. Il nous a paru logique d’inverser ce comportement en repositionnant la caméra de l’autre côté du drone afin de respecter le sens du drone réel.

Pour ce qui est des caméras, la caméra frontale était bien trop en avant du drone et elle avait tendance à se retrouver de l’autre côté du mur contre lequel se trouver le drone, quant à la caméra ventrale, elle aussi était un peu trop loin à notre goût pour être vraiment exploitable et elle a nécessité elle aussi d’être rapproché du drone.

Régulation¶

En poursuivant notre analyse du code, nous nous sommes aperçus que la force appliquée pour simuler l’effet de la trainée n’était effective que lorsque l’utilisateur ne demandait aucun déplacement. Ayant pour objectif d’améliorer le réalisme du simulateur, nous avons rectifié cela en la rendant permanente sous la forme d’une force contraire et proportionnelle à la vitesse sur les 3 axes.

Toujours dans la régulation, l’algorithme repose sur des variables globales représentant des consignes pour le drone. L’intérêt de mettre ses consignes dans des variables globales est de pouvoir influer sur cette partie du code de façon simple depuis n’importe quel point du programme, la programmation basée sur des callback rendant d’autres méthodes plus complexes à mettre en œuvre.

En tant qu’habitués à la programmation-objet et dans le but de clarifier et regrouper les informations, nous avons mis en place une structure : struct Drone. Elle regroupe différentes informations concernant le drone comme sa position ou encore ses angles de rotation. Et c’est tout naturellement que les variables globales de consignes se retrouvèrent dans cette structure drone déclarée comme globale. Côté regroupement des informations, l’intérêt d’une structure parait évident. En ce qui concerne la clarification, l’avantage est que désormais les différentes données qui sont associées au quadricoptère sont précédées d’un « drone » qui permet d’éclaircir les algorithmes de stabilisation et de régulation en marquant bien la différence entre les valeurs propre au drone et celle qui résulte de calcul ou autres.

Afin de pouvoir adapter l’algorithme de régulation au différent cas et pour conserver une stabilisation cohérente, il était nécessaire de définir plusieurs états pour le drone. Il faut en effet effectuer des actions différentes selon que le drone soit en train de décoller, d’atterrir ou encore en plein vol.

Nous avons donc mis en place différentes énumérations à travers notre code afin d’expliciter au mieux ce que chaque variable représente et sa valeur, par exemple pour repérer les moteurs (AVD, ARD etc…) ou encore pour les angles ou positions selon les axes (X, Y et Z).

De nouvelles fonctionnalités¶

Bien qu’après tous ces efforts faits sur la stabilisation et la régulation le drone soit beaucoup plus maniable, le manque du contrôle en rotation posait un réel problème de maniement. Il était évident pour nous qu’il faudrait le plus vite possible implémenter cette fonctionnalité. Une longue réflexion a été faite autour de ce sujet.

Rotation réaliste¶

Il fallait que la rotation soit infinie malgré les contraintes logicielle et physique. La rotation allant de -180° à +180°, la difficulté était de rendre le passage de -179° à +179° possible sans que le drone ne fasse un tour complet dans l’autre sens. Pour cela un algorithme simple, mais longuement pensé a était réalisé, il permet de ramener la consigne dans les bornes, c’est-à-dire entre –Pi et +Pi (les angles étant exprimés en radian), de même pour l’erreur en rotation (voir algorithme ci-dessous.) Cette rotation est inculquée par l’application d’un couple (torque) au corps du drone.

Caméra¶

Mais désormais, c’est la caméra qui doit elle aussi pouvoir tourner afin de suivre le drone dans ses rotations sans quoi la maniabilité reste sommaire. Pour cela, la caméra doit orbiter autour d’un point représenté par le centre du drone en fonction de l’angle de rotation de celui-ci. Pour cela à partir de l’angle, il nous faut calculer les cosinus et sinus du triangle formé par les 2 positions de la caméra (actuelle et derrière le drone) et du drone lui-même. Grâce à ces 2 valeurs et à la distance constante Drone-Camera on peut permettre calculer le déplacement a appliqué à la caméra afin de la faire orbiter autour du drone au fil de ses rotations.

Au départ, la caméra était fixe par rapport au drone. C’est-à-dire qu’elle se contenter de suivre le drone dans son déplacement en restant exactement au même point par rapport à lui et en fixant toujours son centre. Désormais la caméra dispose d’un effet qui simule l’effet des accélérations du drone, en effet en avançant la caméra s’éloigne légèrement du drone, elle se rapproche en freinant. De même en montant elle se tasse au plus près du drone, mais se positionne plus en dessus lorsque l’on descend. Pour parvenir à cela, nous avons utilisé une caméra du type smooth utilisant un temps de latence pour déterminer le retard au mouvement de la caméra par rapport aux mouvements du drone et la caméra regarde désormais en avant de la direction dans laquelle se déplace le drone ce qui améliore la visibilité et améliore le dynamisme de la caméra. L’implémentation de cette caméra a été grandement facilitée par l’étude et la partielle réutilisation de l’algorithme de caméra du jeu mania drive, inclus à Raydium.

Les touches F7 et F8 permettent de désactiver ou d’activer ces caméras. Et dans un but d’optimiser notre code, cela ne se fait qu’avec l’aide d’une seule variable.

Gestion des moteurs¶

Une fonctionnalité mineure, mais qui apporte une touche de réalisme et qui fut de plus facile à implémenter est la possibilité de pouvoir allumer ou couper les moteurs du quadricoptère à l’aide de la touche ‘E’ qui agit comme un interrupteur. Ce choix a été motivé par notre volonté de réalisme et d’ajout de fonctionnalité afin d’enrichir au plus le simulateur de diverses fonctionnalités.

Collisions plus réalistes¶

Toujours dans notre quête de réalisme, il nous a paru bon de rendre les hélices du quadricoptère cassable en cas de collision tout en passant le drone dans un état ou aucune action ni stabilisation n’est applicable. Pour cela, il nous a fallu mettre en place un callback de gestion de collision appelé à chaque collision de 2 éléments du simulateur.

Dans cette fonction, on teste le type des 2 éléments entrant en contact et s’il s’agit d’une collision hélices/scène alors on rompt le joint reliant le moteur au drone.

Toutefois, cette fonctionnalité, bien que totalement implémentée, n’est pas utilisable. En effet, les boites de collision entourant chaque élément et déterminant les points de collision entre les différents objets, empêche cette collision, car leur taille pose un souci et les boites des hélices sont contenues dans celle du corps du drone.

Atterrissage et Décollage¶

Dans l’addition de fonctionnalité et l’amélioration du drone, il ne fallait surtout pas oublier l’implémentation de 2 phases importantes : l’atterrissage et le décollage. Ces phases ont donné lieu à un état de pseudo stabilisation du drone. En effet, la solution la plus simple était de jouer avec la consigne du drone, pour un atterrissage on diminue légèrement la consigne jusqu’à toucher le sol (et donc ne plus avoir de variation d’altitude), pour le décollage on augmente légèrement la consigne jusqu’à atteindre une certaine altitude. D’ailleurs tout comme un vrai drone, pour pouvoir décoller le quadricoptère simulé démarre ses moteurs jusqu’à ce qu’ils atteignent une certaine vitesse puis il s’envole.

Une amélioration graphique majeure allant avec les pales était de rendre ces phases le plus réelle possible. Il est évident qu’en vol les hélices du vrai drone sont en rotation, nous devions donc modifier ce critère dans le simulateur, car au départ les hélices étaient remplacées par des disques noirs pendant le vol. Pour cela, nous avons choisi de mettre en rotation le modèle des hélices dans le simulateur, toutefois l’effet de flou de mouvement étant inexistant, les résultats n’étaient pas à la hauteur de nos attentes et plusieurs solutions furent envisagées.

Nous souhaitions créer un modèle de disque sur lequel nous aurions appliqué un dégradé de transparence via les textures afin de simuler le flou de mouvement des pales de chaque hélice. Mais n’ayant pas trouvé de moyens de mettre en place cette transparence en dégradé c’est notre deuxième idée qui est actuellement en place dans le simulateur.

En analysant le problème, nous nous sommes aperçus que la vitesse de rotation seule n'allait pas créer l’effet de rotation réaliste que nous souhaitions. Solution : Créer un modèle de pale plus allongée afin d’augmenter cet effet de rotation. Cet effet ne pourra être montré en captures d’écran, mais visible en démonstration. Le chargement de ces nouvelles pales créait un ralentissement au moment du changement de texture. Pour pallier cela, nous avons fait en sorte que Raydium charge la texture en mémoire avant de l’afficher via la méthode de chargement d’objet raydium_object_load(char *file).

Au cours du projet, nous nous sommes dit que l’ajout des ombres serait un vrai plus pour le réalisme. Pour les ombres des décors, cet aspect est traité dans la partie suivante du rapport. En ce qui concerne l’ombre du drone, après avoir longuement réfléchi à comment les mettre en place, nos recherches nous ont conduites à la fonction raydium_shadow_enable() qui permet d’afficher les ombres générées automatiquement par Raydium. Bien que n’étant pas de la meilleure des qualités, elles ont le mérite d’exister et d’apporter une fonctionnalité présente dans tout bon simulateur. Ces ombres sont visibles sur les différentes captures présentes dans le rapport.