Drône contrôlé par gestes : Différence entre versions

De Wiki de Projets IMA
Ligne 165 : Ligne 165 :
  
 
Une fois que la phase 1 fonctionnait entre l'ordinateur et la Wiimote, nous avons fait ces tests sur le drone
 
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, atterrissage
- décollage, mouvements, réglages de l'altitude et 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.
 
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, atterrissage
- décollage, mouvements, réglages de l'altitude et 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, atterrissage
- décollage, activation accéléromètre, gestion des mouvements, altitude, 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.
+
- décollage, activation accéléromètre, inclinaison pour faire pivoter le drone, avancer, reculer, atterrissage.
  
  

Version du 13 avril 2014 à 08:25

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.


Description du projet


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

SDK

Semaine 2

Etude du diagramme de classe

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 :

Diagramme de classe du moteur

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 :

Description des librairies

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.

Diagramme de classe du moteur

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.
SDK

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)Seul.
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 :

communication entre le drone et l'ordinateur


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).

ajouter la photo des traces

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 :

communication entre le drone et l'ordinateur


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

Implémentation du code sur Android.