Piloter l’AR.Drone 2.0 avec le capteur Leap Motion

Retour sur une journée de Coding Marathon riche en surprises

AR Drone 2.0En vue de la préparation de mon Barcamp “Premiers pas avec Leap Motion”, je souhaitais fédérer mes collaborateurs autour d’un projet innovant. Le 20 avril dernier, je proposais l’organisation d’une journée de Coding Marathon multi-technologies dans les locaux de Palo IT. Il me restait à déterminer le sujet.

Conçu par la société française Parrot SA, l’AR.Drone 2.0 est un hélicoptère quadrirotor équipé d’une caméra embarquée. Habituellement télécommandé via une application iPhone ou Androïd, j’avais déjà eu l’occasion de le tester chez un ami. Et si nous tentions de le diriger avec le capteur Leap Motion ? D’autant que le pilotage d’un Drone est beaucoup plus impressionnant que les applications souris ou encore piano au feedback visuel limité déjà proposées par d’autres développeurs !

Préparation

Voici quels étaient les objectifs de cette journée de Coding Marathon : approfondir nos connaissances sur le capteur afin de produite un retour d’expérience significatif, et bien sûr, parvenir à piloter le Drone. Pour ce faire, nous disposions de :
– deux capteurs Leap Motion
– un AR.Drone 2.0 mis gracieusement à disposition par Palo IT 🙂
– diverses machines : Windows 8, Mac OS X et Linux.

Developpeurs Palo ITLes 8 participants se sont répartis en équipe par technologie afin d’offrir l’expérience la plus large possible : .NET, Java et Web (Javascript et PHP). Xavier Warzee, notre Directeur Technique et également Président du French Scrum User Group, nous a proposé de procéder en itérations de deux heures. Après avoir présenté le Leap Motion Controller à mes collaborateurs, je leur ai fourni les SDK pour les différentes plateformes (non disponibles en libre accès pour le moment) et leur explique que le capteur propose des notions communes à chaque technologie : doigts, mains et gestuelles.

1…2…3…codez !

Sprint 1

Avec mon équipe .NET, nous décidons d’adopter une approche Peer Programming. Connaissant bien le Leap Motion, je lui présente les notions de Controller et de Listener et lui fournis le code pour récupérer les trames du capteur, puis nous nous mettons rapidement à la recherche d’une API pour piloter le Drone. Nous avons trouvé un projet Open Source permettant de le diriger au clavier et au joystick. Cependant, l’application ne se lance pas. Après analyse, nous comprenons que nous aurions dû installer le SDK de DirectX. 30 minutes de téléchargement plus tard, l’installation échoue 🙁 En cherchant un peu sur Google, une page MSDN nous indique qu’il faut d’abord désinstaller un runtime C++ avant de mettre à jour le SDK, puis de le réinstaller.

Microsoft SDK X10Ca y est : le SDK DirectX10 est enfin correctement installé ! La solution compile : nous lançons alors l’application AR Drone trouvée dans Visual Studio 2012. Malheureusement, une exception LoaderLock se lance au démarrage. Encore un obstacle ! Malgré tout, mon équipe ne se démonte pas et finit par trouver une explication : “L’Assistant Débogage managé (MDA, Managed Debugging Assistant) LoaderLock détecte des tentatives d’exécution du code managé sur un thread qui détient le verrou du système d’exploitation Microsoft Windows. Toute exécution de ce type est illégale car elle peut mener à des blocages et à l’utilisation de DLL avant qu’elles aient été initialisées par le chargeur du système d’exploitation” (source : page MSDN). Finalement, nous comprenons qu’il s’agit d’une simple précaution de l’IDE Visual Studio. Ayant déjà rencontré ce genre d’exception, je savais qu’il suffisait de la désactiver (Menu Déboggage> Exceptions). L’application se lance et le drone décolle. Nous avons du mal à le stabiliser et à le diriger au clavier : il finit par s’écraser, mais notre joie est énorme 🙂

Sprint 2

A l’issue d’une rétrospective sur l’application utilisée, nous choisissons de ne pas nous appuyer sur les gestuelles prédéfinies, mais de partir sur le modèle “Main”. Nous tentons alors de nous interfacer correctement avec l’application de pilotage. Cependant, nous nous rendons compte que cette dernière est trop orientée “usine à gaz” pour nos besoins. Nous décidons donc de ne pas créer un nouveau “InputDevice”, mais de court-circuiter le pipe de pilotage. 30 minutes plus tard, nous parvenons enfin à envoyer des commandes depuis le Leap Motion. La complexité de la gestuelle est cependant très importante : notre capteur invoque la commande “Take Off” au moindre mouvement. D’autant plus que l’AR Drone est un peu capricieux ! Un mouvement vers le haut entraînant forcément un mouvement retour vers le bas, il nous fallait de temps à autre envoyer la commande “Flat Trim”, parfois “Emergency” puis de nouveau “Flat Trim” et enfin “Take Off”.

Sprint 3

Nous sommes quelque peu frustrés de ne pas avoir de gestuelle opérationnelle ! Difficulté supplémentaire : une mise à jour obligatoire du SDK Leap Motion est apparue en plein Coding Marathon ! Du coup, le sprint 3 est entièrement consacré à la recherche d’un algorithme de gestuelles, à partir des trames Leap Motion. Cependant, il me faut accéder à l’historique. Fort heureusement, une fonction “historique de frames” existe. A l’appel de la méthode Frame(), il suffit de fournir un paramètre n, où n est un entier correspondant à la n-ième frame avant la frame courante. Ceci me permet donc de simplifier mon algorithme. Attention :  au-delà de 30, le capteur a du mal à me remonter les trames. Le nombre de frames par seconde chute drastiquement, ce qui est prévisible, puisque le capteur doit historiser ses trames. Rien n’est gratuit ni magique en ce monde !

Décollage AR DroneJe découvre également la fonction “translation d’une main”. Cette fonction me permet d’accéder à la magnitude du mouvement par rapport à une autre frame d’une main. Ainsi, au lieu de tracer chaque frame, j’utilise ma frame courante, et la n-ième frame précédente, puis je demande au capteur de me remonter la translation correspondante. J’ai enfin de quoi déclencher le décollage et l’atterrissage du Drone. Les autres mouvements de navigation seront donnés par les informations des frames entre ces deux états. En effet, le modèle de la main me remonte les informations “Pitch, Roll et Yaw” qui correspondent aux différentes inclinaisons de la main, paramètres permettant également de contrôler le Drone. Ma première tentative se solde par un cuisant échec : le Drone part tel un missile. Je comprends qu’un calibrage est absolument nécessaire. Le Pitch de la main n’est pas calibré sur la même échelle que le Pitch de l’AR Drone.

Et pour l’équipe Web (Javascript / PHP) ?

L’équipe Web a fait le choix de s’appuyer sur les gestuelles nativement supportées par le capteur. Le résultat était intéressant mais a montré quelques limites. En effet, les gestuelles ne sont pas toutes correctement reconnues, et une gestuelle “droite vers la gauche” pour avancer, et “gauche vers la droite” n’est pas forcément pertinente (ce qui est facile à comprendre après coup puisqu’à l’un, succède l’autre).

C’est parti pour la démonstration !

AR DRONE 2.0 2Nous avons testé le pilotage du Drone dans l’atrium de Palo IT. Les essais me donnaient plus l’impression d’un Harry Potter à l’école des sorciers, tentant de faire décoller le drone par une gesture, qu’à une ergonomie améliorée par rapport à un joystick! Cependant, je reste conscient de la difficulté de l’exercice, et ne remet pas en cause tout le potentiel du capteur, le jour où nos algorithmes seront au point, et le jour où nous saurons éliminer le bruit ambiant, quant aux remontées des trames. La fin du pilotage de l’AR Drone est un peu plus joyeuse tout de même, car le lundi suivant, je décide de retenter ma chance avec mon application LeapMotion, en calibrant un peu mieux les inclinaisons et la vitesse du drone. Le résultat est un peu plus probant : le drone décolle, avance, tourne, et se pose désormais à partir des gestuelles que je lui indique. Le calibrage est en effet très important.

Pour conclure…

Ce Coding Marathon fut riche d’enseignements pour chacune des équipes. Sachez que le capteur fonctionne aussi bien sur Windows, Mac ou Linux, mais que le paquetage de ce dernier laisse un peu à désirer. La connectivité au capteur se fait aisément, quelque soit la technologie sous-jacente. La grande difficulté consiste en la reconnaissance des actions utilisateurs. Deux choix s’offrent clairement à vous : s’appuyer sur des gestuelles nativement supportées, ou développer vos propres gestuelles. Dans le cas d’une application où les premières suffisent, la mise en place du Leap Motion Controller est aussi simple que celle d’une souris (rotation, tapotage sur un clavier ou un écran, balayement gauche-droite, etc.). Si vous souhaitez transformer un écran non tactile en pseudo-tactile, alors ces gestuelles vous permettront de réaliser facilement des navigations dans des applications de type caroussel, click de souris, etc. A ce niveau d’utilisation, il s’agit d’un monde que je pourrais qualifier de 2D, dans lequel la 3D n’a pas de véritable valeur ajoutée.

En revanche, là où Leap Motion prend tout son sens, c’est dans les gestuelles complexes de la main, des mouvements de doigts ou des outils, là où la 3D intervient. Dans le cas d’un pilotage à la Google Earth, les données “Pitch, Roll et Yaw” de la main permettent d’intégrer rapidement Leap Motion à un applicatif, sans avoir à penser à un algorithme trop complexe pouvant mettre en oeuvre des réseaux de neurones du NoSql par exemple. Ce qui est sûr, c’est que le Leap Motion Controller promet. Espérons que ces promesses se concrétisent un jour en réalité, à la condition expresse que les développeurs parviennent à maîtriser les flots de données remontées.

 

Retrouvez notre projet en vidéo ici !

 

Share
Patrick LEGRAND
Patrick LEGRAND

1957

Comments

  1. Bonjour,
    J’aurais voulu plus d’informations au sujet de l’équipe web? Quelle méthode a-t-elle suivi? des échecs, succès?…
    Merci

Leave a Reply

Your email address will not be published. Required fields are marked *