Projets_Etudiants » Projets IUT SI » Iut Si Polytech QuadriCoptère

h1. Communications

Pour permettre l'interaction entre la tablette Android et le drone ou le simulateur, il fallait gérer la communication entre ces deux périphériques. Tout d'abord les deux éléments principaux de cette interaction étaient le routeur et le module WIFI. C’est deux éléments ont des caractéristiques et des configurations bien différentes que nous allons détailler.

h2. Routeur

!http://forge.clermont-universite.fr/attachments/1246/routeur.jpg!

Figure 12 : Le routeur

Nous avons commencé par configurer le routeur afin d'établir un réseau sur lequel l'ensemble des équipements se connectaient.

Cette configuration s’est faite, après installation via un CD, à partir d'une interface Web. Nous avons donc commencé par préciser quelles adresses IP (fixes) utiliserait chaque périphérique. Ainsi chacun d’entre eux pouvait contacter l’autre. Nous avons donc configuré le routeur de façon à ce que seules ces adresses soient autorisées sur le réseau.

h2. Module Wi-Fi

h3. Présentation

Ce module sans fil est un module WIFI Matchport b/g de Lantronix. Ce module supporte deux versions de la norme IEEE 802.11, les versions b et g. La dernière version est la version n, qui a été conçue pour améliorer le débit de la communication sans fil. Cette dernière version n'est pas supportée par notre module Wi-Fi. Dans notre cas, cela ne pose pas vraiment de problème car nous n'avons pas besoin d'un fort débit pour ce que l'on souhaite réaliser.

!http://forge.clermont-universite.fr/attachments/1247/lantronix.png!

Figure 13 : Module WIFI Lantronix MatchPort b/g

Ce module est assez complet, en effet il inclut plusieurs services, comme par exemple un serveur web ou encore un serveur de messagerie. Dans notre contexte nous avons seulement utilisé l'interface web pour mener à bien la configuration de notre module. Il est aussi possible de configurer le module par Telnet via le port série. Pour le configurer nous avons aussi utilisé le logiciel DeviceInstaller.

h3. Configuration

Tout d'abord la tablette Android ne supporte pas le réseau Ad-Hoc, donc il a fallu configurer le module en mode infrastructure. De plus il a fallu fixer une adresse IP pour le module WIFI, ainsi la tablette envoie ses informations sur cette adresse directement.

Pour débuguer la configuration du module nous avons utilisé l'hyperterminal qui nous permettait d'obtenir les mêmes options que DeviceInstaller.

!http://forge.clermont-universite.fr/attachments/1248/wi1.png!

Figure 14 : Détails du module Wi-Fi avec DeviceInstaller

Ici nous pouvons voir l’ensemble de la configuration du module Wi-Fi grâce au logiciel DeviceInstaller.

!http://forge.clermont-universite.fr/attachments/1249/wi2.png!

Figure 15 : Configuration du module Wi-Fi avec DeviceInstaller

Sur cette page de configuration nous avons pu nommer le Module, fixer son adresse IP. Les autres onglets permettent de modifier les paramètres des channels, de la sécurité ainsi que les autres multiples fonctionnalités du module dont nous ne nous sommes pas servis.

h3. Le protocole de communication 

Pour pouvoir analyser les données envoyées par l’application Android, il fallait définir un protocole. Nous avons donc choisi d’utiliser le protocole suivant:

*LETTRE : Valeur* 

Figure 16 : Représentation du protocole

Nous avons utilisé certaine lettre pour représenter un mouvement du drone. Ainsi le Z représente  l’altitude, le Y le  cap (Yaw), le P le  tangage (Pitch) et le R le roulis (Roll). De plus, les deux points permettent de séparer le type de commande des valeurs. Le protocole inclus également le point d’interrogation permettant une demande effectuée par le simulateur à l’application Android. Cet envoi de données par le simulateur n’a pas été géré. Les valeurs sont des inclinaisons (de -10 à 10), correspondant à celles de la tablette ou du smartphone, provenant ses accéléromètres.

!http://forge.clermont-universite.fr/attachments/1250/ypr.jpg!

Figure 17 : Schéma de représentation des mouvements du drone

Ce schéma représente les différentes orientations que peut adopter notre drone. Pour gérer ces différents mouvements, nous avons analysé à l’aide d’un parseur les différentes trames envoyées par l’application Android. L’implémentation du parseur a été faite comme indiquée ci-après. 

!http://forge.clermont-universite.fr/attachments/1251/code4.png!

Figure 18 : Variables d'orientations reçues de l’application Android et envoyées au simulateur

h2. Différents type de communication

!http://forge.clermont-universite.fr/attachments/1252/sch1.png!

Figure 19 : Ensemble des communications

h3. Communication Module Wi-Fi - PC par port série

La communication par le port série s’est faite par le biais de la reprogrammation d’un hyperterminal en langage C. Nous avons utilisé ce type de communication afin d’envoyer les données récupérées de la tablette grâce au module Wi-Fi par le port série. Ce programme fut complexe à réaliser puisque Windows ne gère pas l’utilisation directe des ports série. Il a donc fallu, après quelques recherches sur Internet, utiliser une structure complexe représentant un port série. 

!http://forge.clermont-universite.fr/attachments/1253/code1.png!

Figure 20 : Ouverture et initialisation du port série

Dans le code ci-dessus, nous pouvons voir l’ouverture et surtout la configuration du port série (COM 4) en langage C sous Windows. L’étape principale a été l’initialisation de la structure DCB permettant de respecter la configuration de l’envoi des données par le module Wi-Fi. Comme par exemple l’initialisation à 9600 bauds pour la vitesse de réception des données.

h3. Communication directe Android-PC

La communication directe en UDP, sans passer par le module Wi-Fi, permet l'interaction entre l'application Android et le simulateur. Celle-ci, réalisée en langage C, est intégrée au simulateur. En résumé nous avons donc intégré un serveur UDP à Raydium, afin de récupérer les valeurs d’orientation envoyées par la tablette ou le smartphone Android au simulateur. La fonction les récupérant est ensuite appelée par la fonction « step » du simulateur.

!http://forge.clermont-universite.fr/attachments/1254/code2.png!

Figure 21 : Code de la création de la socket non bloquante

Les deux lignes de codes précédentes, nous ont permis de créer une socket non bloquante, afin que l’appel à upd_loop() dans le simulateur n’interrompt pas le programme de virtualisation.

h3. Communication, écriture sur le port série du microcontrôleur

Cette communication permet au simulateur, qui reçoit les données, de les envoyer au microcontrôleur qui ensuite effectuera les calculs pour gérer les mouvements du drone, dans le but d’alléger le simulateur 3D. Ce code est contenu dans le programme du port série mais cette partie n’a pas été intégrée au simulateur.

h3. Gestion du simulateur par le clavier

Cette interaction est directement liée au simulateur. Nous pouvons donc commander le drone virtuel directement au clavier. Cette partie a été réalisée par le binôme s’occupant du simulateur.