Structure générale du côté simulation¶

Introduction¶

Afin d’appliquer les méthodologies et les notions enseignées en DUT Informatique à l’Université Clermont I, nous devons réaliser un projet de fin d’études.
L’équipe se compose de 4 étudiants sous la tutelle de Philippe Kaufmann et Jacques Laffont.

Le but de notre projet était de créer un simulateur de drone quadricoptère qui devait servir à tester et simuler le fonctionnement d’un drone réel.
Le projet était à la base prévue sur Windows dont la conception était configurée pour l’IDE Code::Blocks.
Nous n’avions à la base, pas réellement de piste de développement et une grande liberté nous a été laissé afin de déterminer nos pistes de travail.
Compte tenu de la pertinence de nos choix et de nos idées, la décision fût prise de nous laisser cette liberté.
En effet nous avons décidé de créer une Interface Homme Machine (C++ Qt/SFML) afin de visualiser plus précisément les données de navigation du drone (simulé ou non).
De plus nous avons apporté de nombreuses optimisations et fonctionnalités au simulateur existant tant sur le plan fonctionnel que graphique et l’avons rendu multiplateformes, Windows et Linux.
Nous avons notamment utilisé Sketchup et Blender afin de réaliser l’intégralité du site de l’IUT des Cézeaux en 3D et de préparer nos applications à recevoir les données du drone réel.

La finalité qui nous a été proposée est de pouvoir utiliser le simulateur tout en recevant les informations du drone simulé en moyen de l’IHM, mais aussi de pouvoir contrôler le simulateur via une application Android basée sur smartphone ou sur tablette.
De plus, l’IHM doit pouvoir recevoir les informations du drone réel pour mettre à jour sa position angulaire, son altitude, son positionnement GPS …

Mise en réseau des applications du projet¶

L'intégralité des applications constituant notre projet sont interconnectées selon un réseau interne simple que nous avons décidé de mettre en place. La connectivité de ces applications était nécessaire dès le début de notre projet, car l'intérêt principal de ce dernier était de pouvoir communiquer à la fois entre nos applications, mais aussi avec le drone réel et afficher les informations vitales du drone pour un suivi et une compréhension utilisateur simplifiés du bon fonctionnement d'un drone quadricoptère.

La mise au point de l'IHM s'est déroulée en parallèle de celui du simulateur et nous a permis de mettre en place une interface entre ces 2 applications nous permettant d'afficher directement un certain nombre d'informations du drone (telle que l'assiette, son altitude ou encore sa position GPS).

L'application Android quant à elle nous permet d'envoyer des ordres simples au simulateur et de contrôler le Drone à travers une interface simplifiée de commande facilitant l'utilisation du simulateur par une personne externe au projet.

L'intégralité de notre réseau fonctionne selon le protocole UDP nous permettant une intégration des différentes couches réseau de nos applications plus rapidement, mais également nous permettant d'intégrer nos méthodes d'identifications de trames propres aux fonctionnements des différents parseurs constituant notre architecture.

Choix du Serveur Java¶

Lorsque nous avons commencé à mettre en place les communications entre nos applications un problème s'est rapidement présenté. Quelle application intégrera le côté serveur afin d'identifier la provenance d'une trame et de la retransmettre à l'application qui en a besoin ?

Ce besoin a été rapidement résolu, tout d'abord pour une utilisation de débogage, mais qui s'est rapidement imposée comme la dernière application de notre projet. En effet, notre tuteur ne souhaitant pas devoir dépendre d'une des applications que nous étions en train de mettre en place afin de faire fonctionner l'ensemble de notre réseau, nous avons décidé de mettre en place une petite application Java qui ne servirait seulement que de routeur de trames.

Le choix du langage Java s'est imposé pour sa rapidité d'intégration, mais également pour une compatibilité Windows et Linux grandement facilitée.

De plus, nous ne souhaitions pas perdre de temps sur cette application tout en nous permettant de simplifier chaque application puisqu'elles ne demandaient plus qu'une connexion à ce serveur, dont nous connaissions tous son adresse IP et son port d'écoute, afin de pouvoir fonctionner avec les autres applications.

Ce serveur Java nous permet donc d'analyser la provenance des trames et selon la configuration que l'on souhaite, les rediriger vers la ou les applications où l'on souhaite recevoir cette trame.

Puisque nous souhaitions simplifier au maximum le travail de cette application (pouvant recevoir quelques dizaines de trames à la seconde), nous avons utilisé le patron de conception « Object Pool ». Ce dernier nous permet de gérer de façon multithread le traitement des trames arrivant sur le serveur, et ainsi augmenter sa rapidité de traitement tout en assurant une synchronisation et l'ordre des trames en utilisant une file de messages. L'autre avantage de ce patron est d'éviter une allocation/désallocation à chaque nouveau traitement de trame d'où un gain sérieux en terme de performance.

Chaque trame reçue est alors déposée dans une file de messages et un thread d’exécution est alors lancé, ce dernier va s'occuper du message le plus ancien de cette file (cela nous permet de garder l'ordre des messages intact). Lorsque le thread a terminé son traitement, il redevient disponible pour un nouveau traitement.

Voici quelques captures d'écran lorsque les différents périphériques sont connectés, cette interface est surtout utilisée à des fins de test, mais elle pourra être maintenue et améliorée.

Serveur Java lancé sans périphérique connecté
On peut voir sur quels port et adresse ce serveur écoute les trames entrantes

Lorsque le simulateur est connecté, on peut ainsi voir sur quel port il s'est connecté
ainsi que son adresse de connexion (ici localhost),
mais également la dernière trame reçue par le serveur

Lorsque l'IHM est connecté

Enfin lorsque tous les périphériques sont connectés