Version actuelle datée du 20 avril 2014 à 15:22

Contrôle de drone avec télécommande à gestes

Cahier des charges

Présentation générale du projet

Contexte

Les télécommandes à gestes sont en passe de devenir des outils incontournables dans les domaines de l’informatique, de la robotique et du multimédia. Déjà présente dans nos consoles et nos télévisions, ces dispositifs proposent différents types de reconnaissance de nos mouvements.
On peut notamment citer les dispositifs suivants :

• La Kinect pour une reconnaissance des gestes par caméra.
  
• La Wiimote qui dispose d’un accéléromètre et d’un gyroscope (en option) afin de détecter les angles d’inclinaisons.
  
• Le Leap motion qui permet dans un espace limité de détecter les mouvements des doigts
  

La start-up canadienne Thalmic Labs a mis au point une technologie peu commune pour piloter une interface ou des objets communicants. Il s’agit d’un brassard nommé « Myo » . Myo est un brassard qui se porte à l’avant-bras, il interprète l’activité électrique des muscles lors de l’utilisation de la main, des doigts et du bras. Cela permet d’associer les mouvements de l’utilisateur à des tâches à envoyer aux appareils compatibles Bluetooth.

Objectif du projet

Le but du projet est de piloter un drone quadcoptère du commerce par le biais d’une interface à geste. Par défaut l’interface utilisée sera le brassard Myo de Thalmic Lab. En cas d’indisponibilité de celui-ci nous utiliserons une télécommande Wiimote.

Description du projet

Le projet s’articule autour de 3 entités :

• La télécommande qui communique les mouvements de l’utilisateur par liaison Bluetooth au système embarqué.
  
• Le système embarqué qui sera la passerelle entre l’interface à geste et le drone. Le système embarqué doit disposer du Wifi et du Bluetooth afin de pouvoir communiquer avec les autres entités.
  
• Le drone qui doit être pilotable par le Wifi.
  
  
  

Choix techniques : matériel et logiciel

Dans le cadre du projet, les matériels et logiciels suivants vont être utilisés :

• Un ArDrone version 1 de la société française Parrot
  
• Un smartphone sous Android (version 4.3 ou ultérieure)
  

Afin de disposer d’un système embarqué léger qui puisse être porté par l’utilisateur nous avons décidé de développer la passerelle directement sur un smartphone de type Android.

• Un brassard Myo et/ou une télécommande Wiimote
  

Pour éviter de bloquer le projet suite à une indisponibilité du brassard Myo, qui est en précommande, nous allons travailler en parallèle avec une Wiimote. Il sera donc nécessaire de bien penser notre application (au niveau conception objet) afin de disposer d’un système dynamique.

• La conception de l’application Android se fera en langage Java qui est largement préconisé pour ce type de système.
  

Le logiciel Netbeans (version 7.4) a été choisi pour concevoir les applications Android.

• Une clé bluetooth (emprunté à l'école)

Etapes du projet

Afin de mener à bien le projet, différentes étapes ont étés posées.

=> Prise en main du drone

L’objectif de cette partie est de développer des classes permettant d’envoyer au Drone les routines nécessaires au pilotage de celui-ci en passant par le Wifi. Un soin tout particulier devra être apporté quant à l’aspect marche dégradé de cette partie. Que se passera-t-il pour le drone si l’application plante…

=> Prise en main de la wiimote (en attendant Myo)

Dans cette partie il est question de développer des classes permettant la communication avec une Wiimote à l’aide de la librairie VRPN. Cette étape va permettre de récupérer les informations venant de la Wiimote comme par exemple, l'ordre de déplacement, de décollage ou d'atterrissage.

=> Prise en main du brassard myo

Une fois le brassard en notre possession, il va falloir réaliser une batterie de test avec le sdk de thalmic afin d’étudier la précision du brassard. En effet, il va falloir déterminer les mouvements à utiliser pour le pilotage. Une fois cette phase d’étude terminée nous allons pouvoir réaliser les classes de contrôle correspondantes.

=> Réalisation d'un protoype sur PC

Une fois les classes des étapes précédentes réalisées, nous allons dans un premier temps essayer de piloter le drone avec avec une wiimote en utilisant un pc comme passerelle.

=> Intégration dans Android

Cette ultime étape consistera à intégrer les librairies conçues dans une application Android. Cette étape nécessitera une adaptation au niveau de la surcouche spécifique du système ainsi que la réalisation d'une interface homme machine pour l'application.

Avancement du Projet

Semaine 1

Préparation de l'environnement de développement

Nous avons installé et configuré l'environnement de développement nécessaire à la réalisation du projet sur nos machines cela comprend :

• le Java
• Netbeans(+plugins NbAndroid et plantUML)
• le SDK Android
• une machine virtuelle avec Android sous VirtualBox (pour les tests et déboguage car nous n'avions qu'un seul smartphone compatible avec la version 4.3 d'android)
• création et utilisation d'un repository sous GitHub pour gérer les sources

Semaine 2

Etude du diagramme de classes

Nous devons disposer d'un système générique, permettant l'utilisation de multiple contrôleur et assurant une portabilité PC, Android. Ces différentes contraintes ont été étudiées lors de la réalisation du diagramme de classe de l'application dont voici la représentation UML :

Le diagramme n'est pas exhaustif. En effet toutes les méthodes et propriétés ne sont pas présentes de plus il évoluera dans le temps. Mais il nous permet d'avoir une bonne vision d'ensemble de la librairie de base du projet.
Le rôle de chacune des classes sera expliqué en détail dans le compte rendu.
Un des points essentiels à retenir du diagramme est l'utilisation du pattern Abstract Factory qui nous permettra de construire dynamiquement nos contrôleurs ainsi que nos classes utilitaires en fonction du système cible.
Cela nous permettra en théorie de conserver une librairie en tant que moteur "DroneControllerLib" et de la réutiliser aussi bien sur PC que sur Android.
Principe d'utilisation :

On voit bien que, selon le système d'exploitation cible, il sera nécessaire de créer une surcouche spécifique. Dans notre projet nous aurons une librairie DroneControllerLibStd qui apportera la surcouche pour PC et DroneControllerLibAndroid qui fera la même chose pour android. Chacune de ces librairies spécifiques devra redéfinir ces propres classes Factory, Utility et Controlleur qui dériveront des classes de la librairie de base DroneControlleurLib.

Semaine 3

Nous avons séparé le travail en 2 parties (une partie par personne).

Partie Commande du drone

Dans cette séance nous avons recherché les différentes techniques possibles pour communiquer avec le drone. Nous nous sommes naturellement renseigné sur le SDK (software développement kit) fournit par la société Parrot qui commercialise le drone.

Nous avons donc téléchargé le SDK ainsi que sa documentation. Lors de la lecture de celle-ci nous nous sommes aperçu que le SDK était une librairie développée en langage C sous linux.
Nous avons également appris que les sources de l’application Android officiel de pilotage du drone, de la société, étaient disponibles et réutilisables.

Partie Contrôle de la wiimote

Comme pour le drone nous avons recherché dans cette partie une façon de communiquer avec la Wiimote en Bluetooth. Nous avons tout d’abord concentré nos recherches sur une librairie disponible sur Windows en vue de la réalisation du premier Prototype.
Lors de nos recherches, nous avons trouvé une librairie Java dénommé WiiuseJ correspondant à nos attentes. Cette librairie doit s’utiliser conjointement avec un driver permettant la communication avec la Wiimote.
Ce driver est nécessaire car la Wiimote utilise deux niveaux de protocole bien particulier pour communiquer :

• Le protocole L2CAP qui permet de définir des canaux de communication de type bluetooth c’est la couche logicielle la plus proche du matériel.
  
• Le protocole HID qui est un standard permettant de définir la façon dont doivent être constitué les messages échangés.

Semaine 4

Partie Commande du drone

Nous avons dans cette séance téléchargé l’application mise à disposition par Parrot pour pouvoir l’étudier. Lors de nos observations nous avons établi plusieurs constats :

• L’application est très riche et contient de nombreuses parties inutiles dans le cadre de notre projet
• Le niveau de complexité du code est très élevé, il nous est donc difficile de détecter les parties du code permettant de réellement communiquer avec le drone
• Le projet, une fois compilé, ne fonctionne pas sur les différents smartphones testés
• L'utilisation du mode debug avec NetBeans est inutilisable en raison de la volumétrie de l'application.

A la suite de ces constats, le temps d’adaptation de l’application nous a paru trop conséquent comparer au temps de réécriture de notre propre application en utilisant le SDK. Nous avons donc décidé d’abandonner cette piste.

Une autre contrainte nous a restreint à ne pas pouvoir utiliser le SDK tel quel. En effet sur Android toutes les librairies de base ne sont pas forcément disponibles. Il est donc difficile d’être certain que le SDK lui-même n’utilise pas une librairie incompatible. D’ailleurs lors de l’analyse de l’application Android officiel nous n’avons pas détecté de trace de l’utilisation du SDK.

En revanche la documentation du SDK nous a tout de même était très utile car elle explique le principe de base de la communication avec le quadricoptère en UDP. Les informations du SDK relatent également de façon précise les trames des différentes commandes à utiliser pour les échanges avec le drone.

Nous avons donc décidé pour être sûrs de n’avoir aucun problème de compatibilité lors de notre passage sur Android, de créer notre propre librairie en java permettant la communication avec le drone. L’avantage de cette solution est que nous nous reposons sur du code simple qui sera multiplateforme et dont nous avons la maitrise.

Nous avons ensuite débuter le développement de la librairie DroneControllerLib.

Partie Contrôle de la wiimote

Afin de pouvoir mener à bien le prototype sur Windows, nous avons cherché un driver compatible avec WiiuseJ. Nous avons testé lors de cette séance BlueSoleil qui est un driver payant. Nous disposions d'une version d’évaluation de 30 jours. Nous n'avons pas approfondi nos recherches sur les différents drivers disponibles étant donné que Windows n'est pas la plateforme cible. En effet, le but du prototype est de valider notre architecture. La reconnaissance de la Wiimote avec BlueSoleil semble fonctionné correctement.

Début du développement du Contrôleur utilisant WiiuseJ pour le prototype.

Semaine 5

Partie Commande du drone

Le développement de la librairie DroneControllerLib a bien avancé, des premiers tests de vol avec le drone ont été réalisés par le biais d'une classe de type Contrôleur Clavier (implémenté dans DronecontrollerLibStd).
Nous avons eu quelques problèmes de stabilité et de communication avec le drone. En effet toutes les commandes n’étaient pas documentées, des recherches supplémentaires ont été nécessaires. Elles étaient basées sur des exemples de communication réalisés par d’autres développeurs dans d’autres langages afin de trouver l’ensemble des commandes manquantes.

Voici la communication qui a été faite :

Partie Contrôle de la wiimote

Le développement du Contrôleur est terminé. En effet, nous avons tout d'abord lors de cette séance commencé à gérer les boutons sans l’accéléromètre (phase 1). Nous gérions seulement dans un premier temps la communication entre la Wiimote et l'ordinateur et nous simulions l'envoi des ordres au drone par le biais de traces. Et nous avons aussi testé par la suite, la gestion avec l'accéléromètre (phase 2).

En effet, nous avons décidé de procéder ainsi pour une question de sécurité. Nous commencions donc les tests par une phase de simulation et lorsque celle-ci était concluante, nous faisions les tests directement sur le drone.

Voici la communication faite pour cette partie :

Le prototype

Le but du prototype PC était de valider le principe de fonctionnement avant de commencer à travailler sur Android. Nous avons pour cela créé du code qui utilise la librairie WiiuseJ tout en utilisant en parallèle le moteur de commande du drone. Nous avons rapidement obtenu un résultat satisfaisant qui nous a confortés dans nos choix techniques de conception. En effet nous arrivions à piloter le drone avec des commandes basiques mais également avec l’accéléromètre.

Une fois que la phase 1 fonctionnait entre l'ordinateur et la Wiimote, nous avons fait ces tests sur le drone.
- décollage, atterrissage
- décollage, mouvements, réglages de l'altitude et atterrissage

Ensuite, nous avons intégré la gestion de l'accéléromètre dans le code (phase 2). Nous avons simulé les envois d'ordre au drone puis nous avons testé sur le drone directement pour plus de sécurité au niveau du drone afin d'éviter qu'il se détériore.
- décollage, atterrissage
- décollage, mouvements, réglages de l'altitude et atterrissage
- décollage, activation accéléromètre, atterrissage
- décollage, activation accéléromètre, gestion des mouvements, altitude, atterrissage
- décollage, activation accéléromètre, inclinaison pour faire pivoter le drone, avancer, reculer, atterrissage.

Voici une vidéo qui montre un premier jet du prototype:

Semaine 6

Partie Commande du drone

Pour cette partie, il a fallu réécrire la partie spécifique à Android dans la librairie DroneControllerLibAndroid car nous avions fait en sorte d'avoir un code multiplateformes.

Certains problèmes ont été rencontrés lors de la compilation. En effet le JDK Android ne permettait pas l'utilisation de certaines syntaxes disponibles dans les dernières versions de Java.

Le JDK représente les librairies Java permettant de concevoir un programme sous Android. Cependant peu de modifications ont été nécessaires pour arriver à faire fonctionner cette partie directement sous Android.

L'importation sous Android entre le drone et la passerelle est terminée.

Partie Contrôle de la wiimote

Après validation du prototype, nous avons recherché comment intégrer la gestion de la Wiimote sur Android. Nous avons remarqué que le protocole L2CAP était intégré directement par le système d'exploitation.
L'application Bluez trouvée permet de faire de la communication avec plusieurs types de manettes dont la Wiimote par le biais du Bluetooth.
De nombreux tests ont été effectués sans succès afin de faire fonctionner la Wiimote avec Bluez IME.
Le problème est dû à la version d'Android du smartphone. En effet, la version utilisée est 4.3 et depuis la version 4.2, la communication Bluetooth a été modifiée.
Après recherche nous avons découvert de nombreux problèmes de compatibilités, notamment avec le protocole L2CAP, qui étaient présent depuis cette mise à jour. Une anomalie traitant de ce sujet a depuis un certain temps était répertorié dans le système de bug tracking de Google concernant Android.
Sachant qu'il ne restait plus beaucoup de temps, nous avons essayer de trouver une solution simple afin de résoudre le problème.
Nous en avons trouvé deux :
- gestion de la Wiimote par une version antérieure 4.0.3 par rapport à celle du smartphone déjà utilisé (version 4.3)
- gestion de la Wiimote par le biais d'une passerelle ayant comme système d'exploitation, Linux. Il s'agit du PcDuino.

Le travail a été séparé en deux parties :
- la partie avec une ancienne version d'Android
- la partie avec le PcDuino

Partie ancienne version d'Android

Pour cette partie, nous avons pris en main la librairie Bluez IME. Pour cela, nous avons fait une étude du code.

Partie PcDuino

Prise en main de la librairie WiiC. Comme WiiC est une librairie faite en C et n'existant pas en Java, nous avons dû trouver le moyen d'utiliser la librairie WiiC afin de récupérer les informations de la Wiimote et d'interpréter les mouvements afin d'envoyer les ordres au drone.

Nous avons rencontré un problème de compatibilité avec une de nos Wiimotes. En effet, nous utilisions deux versions différentes. Nous avons donc adapté le code de la librairie WiiC afin de gérer les deux types de Wiimote.

Semaine 7

Pour éviter de faire de la redondance dans le code, nous avons décider de créer une fonction qui permette d'interpréter les ordres à envoyer au drone quelque soit le type de contrôleur.

Partie ancienne version d'Android

Premiers tests de cette partie assez concluants sans gestion de l'accéléromètre.

Partie PcDuino

Nous avons choisi d'utiliser une communication client/serveur avec le protocole TCP pour envoyer les informations récupérées par la librairie Wiic afin de les envoyer au programme Java pour qu'il puisse interpréter les gestes et envoyer les ordres au drone.
De ce fait on pourrait très bien envisager facilement de créer à l’avenir un autre client qui utilise un autre contrôleur pour se connecter à notre partie serveur. Il suffira alors d’utiliser le même format de message qu’actuellement.

Quelques modifications dans la librairie Wiic ont été nécessaires pour envoyer les données au serveur (programme Java) et pour envoyer des données précises comme bouton A appuyé, relâché, etc.
La partie avec accéléromètre nous a posé un petit problème. En effet, lorsqu'on appuyait sur le bouton pour activer l'accéléromètre, il passait dans ce mode et ne pouvait plus en sortir. De plus, les valeurs données par celui-ci ne nous donnait pas les bons paramètres. Par exemple, nous inclinions l'accéléromètre sur la droite, ce dernier ne prenait pas en compte l'inclinaison. Cependant lorsqu'on l'inclinait fortement, la valeur était prise en compte.

A la fin de la semaine la fonction qui permet d'interpréter les ordres à partir de n'importe quel contrôleurs a été terminée. Le programme sur l'ancienne version d'Android fonctionne correctement sans l'accéléromètre et présente un défaut avec ce dernier. En effet, lorsque l'on active l'accéléromètre, nous n'avons plus accès aux boutons. La partie sur Wiic fonctionne correctement sans l'accéléromètre.

Semaine 8

Partie ancienne version d'Android

Le problème des boutons non fonctionnels quand l'accéléromètre est activé a été résolu.
Cette partie fonctionne.

Partie PcDuino

Le problème lié à l'inclinaison a été réglé en passant par une autre fonction de la librairie Wiic qui permettait de renvoyer directement la valeur de l'inclinaison. Ensuite le problème de l'accéléromètre a été réglé.

Cette partie fonctionne également.

Semaine 9

Cette dernière semaine nous a permis de tourner la vidéo qui explique le projet et qui montre une démonstration du projet terminé.

Pour récapituler, le projet fonctionne avec :

Le cahier des charges a été respecté. Nous aurions toutefois aimé faire le projet avec le brassard Myo qui n'est toujours pas arrivé et nous aurions voulu adapter le programme sur les récentes versions d'Android (version 4.2 ou ultérieures).

Fichiers Rendus

• Rapport de projet : Fichier:Rapport projet DeltombeGerier.pdf