UNIVERSITE DE CERGY-PONTOISE. Projet iflybot Document de synthèse

Transcription

1 UNIVERSITE DE CERGY-PONTOISE Projet iflybot 2012 Document de synthèse Conception d un drone intelligent et communicant destiné à réaliser des missions de manière entièrement autonome

2 Liste de diffusion Rôle dans le projet Nom Date / Signature Client Chef de Projet MOE MOE MOE MOE Philippe GAUSSIER Bruce DESSALLE Florian KAISER Julien NOIROT Damien PELLISSON Olivier NESTY Historique N Version Date Auteur Modifications de mise à jour /05/2012 Julien NOIROT /06/2012 Julien NOIROT Migration des «spécifications techniques» vers «document de synthèse 1.0» Complétion et ajout de paragraphes non techniques /06/2012 Julien NOIROT Ajout des derniers travaux /06/2012 Bruce DESSALLE Intégration de l aspect Gestion de projet /06/2012 Bruce DESSALLE Validation du document iflybot2012 Document de synthèse 2

3 SOMMAIRE Introduction... 6 Remerciements Présentation du Client Activité du client Besoins exprimés par le client Périmètre du projet Objectif du projet Acteurs du projet Planification et Organisation Avancement du projet Tableau de suivi de projet Courbe en S Avancement final du projet Conditions de réussite Analyse de l existant I-Flybot IV Etat d avancement Matériels utilisés Projets similaires Environnement de développement SVN Eclipse Linux Gumstix Architecture Matérielle Matériel Architecture «Quadricoptère» Matériel embarqué Comment vole un quadricoptère? Schéma de principe Architecture d origine Architecture année antérieure Architecture cible Architecture «Hélicoptère» iflybot2012 Document de synthèse 3

4 6.3.1 Matériel embarqué Comment vole un hélicoptère? Schéma de principe Commentaires Matériel embarqué Carte Gallop Fonctionnalités Rôle Carte RoboVero Fonctionnalités Rôle Les cartes Gumstix Caractéristiques OveroAir COM Caractéristiques OveroEarth COM Points communs et différences Bus utilisés I2C Série Liste des liaisons série Gallop Conception électronique Interface physique série FunPilot Gallop FunPilot Gallop Connexion Alimentation Liste des composants utilisés Schéma Architecture fonctionnelle Description du projet Fonctionnement Fonctionnement manuel Fonctionnement autonome Cas d utilisation Contraintes Contraintes d environnement iflybot2012 Document de synthèse 4

5 Poids à transporter Météo Sécurité Contraintes en temps Temps de traitement d images Temps de communication Contraintes d énergie Architecture Logicielle Langage et architecture Protocoles de communication L UAV FunPilot Communication Gallop43 avec FunPilot L interface graphique Développements Capteurs Accéléromètre Caméra GPS FunPilot Traitement de l'image Optical Flow Sens de déplacement Communication Réseau Wifi Série Temps de boucle IHM Présentation générale Fonctionnalités Evolutions Conclusions Glossaire Annexes iflybot2012 Document de synthèse 5

6 INTRODUCTION Ce document présente une vision finale du projet «iflybot2012». La partie technique est destinée principalement aux «repreneurs / successeurs» du projet afin qu ils puissent aisément repartir de nos travaux grâce à des documentations détaillées et un code soigné. Pour rappel, ce projet est proposé aux étudiants pour la 5 e année consécutive avec quelques variantes mais toujours le même objectif final, à savoir rendre autonome une plateforme volante par différents procédés (traitements d image, asservissement moteurs, algorithmes d IA) et dans une optique de remplir une mission particulière. Réalisé dans le cadre du Master 2 Systèmes Intelligents et Communicants (M2 SIC), ce projet est proposé et dirigé par M. Philippe GAUSSIER. Ce document aborde tant les problématiques de conception que les choix pris sur les aspects matériel et logiciel. Il décrit les solutions techniques mises en œuvre et aborde les limites de chacune. De même, il est question de détailler les nombreux problèmes rencontrés par l équipe puis résolus au fur et à mesure. Enfin, il suggère aussi les évolutions futures qu il sera possible à apporter pour la suite du projet. Pour la communication du projet, nous avons eu la tâche de concevoir un site web bilingue FR-EN actualisé régulièrement afin de suivre l évolution : iflybot2012 Document de synthèse 6

7 REMERCIEMENTS En tout premier lieu, nous souhaitons remercier Philippe GAUSSIER pour nous avoir encadrés, s être montré disponible et nous avoir très bien conseillé dans des moments importants. Ses conseils avisés nous ont vraiment aidé à avancer tant sur la vie du projet que sur nos choix technologiques. Merci aussi à Mme Carina ROELS pour son enseignement en matière de gestion de projet. Vos remarques nous ont aidés à progresser dans la rédaction de nombreux documents. Nous tenons également à exprimer notre gratitude envers nos responsables de Master pour leur encadrement : M. Pierre ANDRY (temps-réel & embarqué) et Mme Tuyêt Trâm DANG NGOC (réseaux). Nous adressons enfin nos remerciements à l UFR Sciences et Techniques pour tout le matériel qui a été mis à notre disposition pour la réalisation de ce projet. iflybot2012 Document de synthèse 7

8 1 PRESENTATION DU CLIENT 1.1 ACTIVITE DU CLIENT Philippe GAUSSIER est le responsable du laboratoire ETIS, spécialiste en sciences de l information et de la communication, il travaille sur la modélisation des mécanismes cognitifs impliqués dans la perception visuelle (vision pré-attentive et attentionnelle) et sur la modélisation de structures telles que l'hippocampe (pour des problèmes d'intégration d'informations spatio-temporelles). Ces modèles servent de base pour imaginer des architectures de contrôle permettant à des robots mobiles d'apprendre à survivre dans un environnement à priori inconnu. Ces robots utilisent généralement la vision comme source principale d'information ce qui met en avant l importance du traitement de l image. Les tâches étudiées sont : l'apprentissage de conditionnements visio-moteurs, la reconnaissance de lieux (retour au nid), la construction et l'utilisation de cartes cognitives et enfin l'apprentissage de la discrimination d'objets et/ou de lieux. 1.2 BESOINS EXPRIMES PAR LE CLIENT L objectif du client est de concevoir un drone pouvant se déplacer de façon entièrement autonome, aussi bien au moment du décollage et de l atterrissage que lors de la réalisation d une mission. Ce projet qui est repris par les étudiants de l Université pour la 5 e année consécutive, n avait jusqu alors toujours pas atteint le premier niveau d objectif fixé par le Client, à savoir obtenir un vol stationnaire et stabilisé. Pour cela, il est mis à notre disposition deux plateformes très différentes pour effectuer nos tests : Un modèle réduit de quadricoptère très maniable, simple d accès et plus facile à mettre en œuvre (possibilité de tests en intérieur, en revanche plus sensible aux intempéries) ; Un modèle réduit d hélicoptère bien plus puissant, pouvant embarquer plusieurs kilos de matériels et donc plus difficile à utiliser pour des raisons de sécurité. La plateforme quadricoptère est considérée comme la solution prioritaire et constitue le produit final qui sera présenté au client au terme du projet. Au contraire, nous considérons la plateforme hélicoptère comme un objectif bonus ou secondaire qui sera avancé au fur et à mesure en fonction de l avancement des développements sur l autre plateforme. Les cartes de développement, également commandées en double, pourront nous permettre de répartir les tâches de développement en deux groupes. iflybot2012 Document de synthèse 8

9 Les applications possibles du drone peuvent être très diverses : Exploration de zones difficilement accessibles o Ex : Entretien matériel et vérifications sur les avions, les buildings, les ponts etc. Surveillance d une zone et reconnaissance des lieux et objets o Recherche de personnes disparues (avalanches, naufrages, catastrophes naturelles) o Reconnaissance morphologique de personnes (personnes recherchées, terroristes) o Détection d intrusion, d incendie de forêt Il est essentiel et c est l un des buts finaux du projet d avoir un vol en autonomie au moment où l on vient à perdre le signal radio avec le drone. Ce dernier devra effectuer sa mission avant de revenir au lieu de départ. Le projet est évidemment complexe et présente beaucoup de possibilités. Le client serait très satisfait d avoir une plateforme de développement opérationnelle et un système en boucle fermée sur le quadri qui lui permettrait des déplacements simples en toute autonomie. iflybot2012 Document de synthèse 9

10 2 PERIMETRE DU PROJET 2.1 OBJECTIF DU PROJET L objectif du projet est, comme expliqué ci-dessus, d obtenir dans un premier temps un vol stabilisé en créant une intelligence qui s occuperait des mouvements réflexes (contrebalancer la dérive). Ensuite, il s agit de pouvoir lui envoyer des ordres sous forme de directions GPS qu il devra suivre. Une fois cette étape validée, nous serons en mesure de lui affecter des missions complètes avec un drone totalement autonome dans ses prises de décisions ainsi que ses déplacements. 2.2 ACTEURS DU PROJET Les principaux acteurs du projet sont les suivants : Philippe GAUSSIER, demandeur du projet (Client) Bruce DESSALLE, chef de projet Olivier NESTY, responsable matériel Damien PELLISON, responsable logiciel Florian KAISER, responsable qualité Julien NOIROT, responsable étude & développement Pour tout renseignement, les coordonnées de chacun des membres de l équipe sont disponibles en Annexes. La répartition des tâches au sein de l équipe est également détaillé dans la suite du document D autres intervenants au projet : Pierre ANDRY, validateur des commandes et encadrant Fréderic WROBEL, fournisseur matériel Carina ROELS, encadrant sur la partie «Gestion de Projet» Hamid AGUINI, encadrant sur la partie «Communication» 2.3 PLANIFICATION ET ORGANISATION Répartition du travail : Bruce Julien Florian Damien Olivier Chef de Projet Assistant CP Resp. Qualité Resp. Conception Resp. Matériel Suivi d avancement - Management équipe Documentation Communication série Algorithmes de traitement Site Web Documentation Analyse de l existant Capteur GPS IHM Communication côté Interface Electronique Développement général Gallop43 Spécifications Conception classes (UML) Design IHM Poster Capteur Accéléro Communication côté Gumstix iflybot2012 Document de synthèse 10

11 Le projet a été découpé en 6 grandes sous-parties qui nous ont permis de travailler sur ce projet de façon cohérente et organisée. Management La tâche de management correspond à tout ce qui est gestion de la vie courante du projet : réunions avec les membres de l'équipe et le client, prise de décisions et rédaction des comités de projet et pilotage. C'est une partie qui a vécu tout au long du projet et c'est grâce à elle que l'on en a aujourd'hui une trace. Initialisation/Cadrage Cette partie correspond à la mise en route du projet. Elle permet la création de l'équipe du projet, le choix des membres et met en place une charte de fonctionnement qui décrit le rôle et le devoir de chacun des membres ainsi que les mesures en cas de non respect de cette charte. Nous fixons par la même occasion les termes et aboutissants du projet, ce qui a pour but la création de ce projet et ce qui est hors projet. C'est aussi dans cette phase que l'on fixe la planification du projet (Plan de management), ainsi que la façon dont on va respecter ce planning (Plan assurance qualité). Elaboration/Conception Ici, nous avons conçu toutes les spécifications du projet et son fonctionnement. C'est la phase de réflexion, nous essayons de penser tout ce qui va faire partie intégrante du projet et nous rédigeons les documents de spécification que nous devrons respecter à la lettre lors de la phase de développement. Construction/Développement Cette tâche est la plus longue du projet avec la partie Conception. Nous développons le projet et réalisons les fonctionnalités que nous avons pensées en phase de conception. C'est durant cette phase qu'une partie de la validation se déroule vu que nous avons défini dans le plan de management que chaque développeur est responsable de ses propres tests unitaires. Validation/Recette La partie Validation permet de faire les tests de validation et de performance de l'application. A savoir vérifier que les grandes fonctions réalisées s'emboitent bien entre elles et que les performances correspondent à ce qui est décrit dans le cahier des charges. Présentation Cette phase n'en est pas réellement une étant donné qu'elle ne correspond pas au cycle de développement standard d'un projet. Mais nous avons quand même décidé de compter le temps passé à préparer et réaliser ces présentations du projet car cela représente au final mis bout à bout beaucoup de temps. Nous estimons, sur tout le projet, qu il a fallu préparer au bas mot une dizaine de présentations d où l importance de cette tâche. iflybot2012 Document de synthèse 11

12 3 AVANCEMENT DU PROJET 3.1 TABLEAU DE SUIVI DE PROJET Ce schéma donne un aperçu global de l état actuel du projet et de toutes les phases achevées. * En rouge, les parties en cours de traitement On remarque que le projet arrive à son terme et que toutes les grandes étapes ont été réalisées. Cependant, certaines ont été traitées plus rapidement que d autres comme la validation/recette qui, étant effectuée en interne, nous avons décidé de valider les fonctionnalités au fur et à mesure pendant les tests de conception. Nous avons tout de même essayé de confier la recette à des personnes de l équipe n ayant pas touchées à certaines parties pour ne pas fausser leur jugement. Il nous reste encore quelque jours jusqu à la démonstration pour parfaire le fonctionnement de l application, c est pour cette raison que les phases «Réalisation» et «Déploiement» sont toujours en cours. Les manuels seront tout de même mis à jour mais ces modifications ne feront pas parties de la recette. 3.2 COURBE EN S Valeur planifiée Valeur acquise Valeur réelle iflybot2012 Document de synthèse 12

13 Coût Courbe en S Valeur réel Valeur planifiée Valeur acquise Semaine 23 Semaine 22 Semaine 21 Semaine 20 Semaine 19 Semaine 18 Semaine 17 Semaine 16 Semaine 15 Semaine 14 Semaine 13 Semaine 12 Semaine 11 Semaine 10 Semaine 9 Semaine 8 Semaine 7 Semaine 6 Semaine 5 Semaine 4 Semaine 3 Semaine 2 Semaine 1 Semaine 52 Semaine 52 Semaine 51 Semaine 50 Semaine 49 Semaine 48 Semaine 47 Semaine 46 Semaine 45 Semaine 44 Semaine 43 Semaine 42 Semaine 41 Semaine 40 Semaine 39 Semaine 38 Semaine 37 Cette courbe nous permet d avancer jusqu à l étape finale du projet, T3 T4 T1 T Des tâches planifiées ont été annulées ou réduites de taille, car la valeur planifiée diminue ; Le coût réel du projet explose ce qui montre que nous avons mal évalué le travail à réaliser sur certaines tâches ou que celles-ci nous ont mis en difficulté ; La valeur acquise est inférieure à la valeur planifiée ce qui signifie que nous n avons pas réalisé tout ce que nous avions prévu. 3.3 AVANCEMENT FINAL DU PROJET Tâche Initial Réactualisé %Avancement Reste à faire Management 56,47H 169,38H 100% 0H Initialisation/Cadrage 88,90H 128,38H 100% 0,00H Elaboration/Conception 347,12H 326,52H 100% 0,00H Construction/Développement 524,35H 546,50H 88% 0,00H Validation/Recette 430,98H 554,50H 81% 75,60H Présentations 35,00H 129,00H 100% 71,50H TOTAL PROJET 1519,82H 1854,28H 91% 147,10H La majorité des tâches de ce projet ont été largement sous-dimensionnées lors du cadrage du projet aussi bien en complexité, qu en quantité de travail nécessaire à leur bonne réalisation. iflybot2012 Document de synthèse 13

14 Could have Must have Should have Won t have La seule tâche qui a été plus courte que prévue est celle de conception. Cette tâche a été plus courte non pas car la conception a été simple mais pour le fait que dès la réception du matériel, nous avons été très pressés de commencer la phase de développement. Voici l'avancement du développement du projet lot par lot, Tâche Initial Réactualisé %Avancement Reste à faire LOT1 - Hélico ANNULEE ANNULEE ANNULEE ANNULEE LOT2 - Quadri-Rotor 418.6H 231.3H 70% 75.6H LOT3 - Communication 37.8H 220.5H 100% 0H LOT4 - IHM 63.0H 152.3H 100% 0H 3.4 CONDITIONS DE REUSSITE Le tableau ci-dessous nous a permis tout au long du projet d avoir en vue les différents objectifs que nous nous étions fixés au commencement, les fonctionnalités qui devraient être conçues et celles qui étaient optionnelles. Guidage manuel du drone depuis le PC à terre (Comm. Xbee clavier) Récupération des paramètres de vol (capteurs accéléro & GPS) Récupération du flux vidéo depuis le drone Interface intuitive et communicante Système de mission avec création de logs Décollage (autonome) Atterrissage (autonome) Vol stationnaire et stabilisé (traitement d image) Fait Suivi de points GPS En cours Fait Fait Fait Fait Fait Fait En cours Programmation d une mission totalement autonome Développement générique multi-plateformes (adaptable à l hélicoptère) En cours Fait Amorçage de la plateforme Hélicoptère Annulé Hélicoptère autonome Annulé * Les niveaux à atteindre sont établis par le client comme des paliers de progression au niveau de la conception finale du produit. iflybot2012 Document de synthèse 14

15 L objectif minimal fixé par le client correspond au niveau 0 du quadricoptère, à savoir obtenir un vol stationnaire grâce notamment à une stabilisation visuelle par le biais de traitements d images. Même si le fonctionnement n est pas parfait, nous avons quasiment couvert tous nos objectifs (partie «Must have»). Nous sommes en cours d intégration du GPS dans l application afin de pouvoir utiliser les points GPS dans les missions et aussi au niveau de l IHM, avoir un affichage dynamique d une carte qui permettrait de suivre les déplacements du drone hors de notre champ de vision. Pour cela, nous avons intégrer un équivalent du module GoogleMaps facile d utilisation et permettant de cliquer sur la carte pour récupérer des positions GPS. La plateforme Hélicoptère a été mise de côté sur conseil du client pour des raisons de contraintes d utilisation : utilisation dangereuse, nécessite un modéliste pour le pilotage, plateforme plus difficile à prendre en main. NB : En cette fin de projet, une carte d origine intégrée sur le quadri a grillé empêchant toute communication avec le drone. Cette pièce est irremplaçable dans le délai restant avant la présentation, ce coup dur vient mettre en péril nos objectifs. Nous cherchons un moyen de secours qui consisterait à intégrer le PC dans la boucle de traitement pour relayer les ordres en Xbee. iflybot2012 Document de synthèse 15

16 4 ANALYSE DE L EXISTANT 4.1 I-FLYBOT IV Il convient de rappeler que ce projet est une reprise de travaux d étudiants des années antérieures. En arrivant dans notre salle au tout début du projet, nous avons récupéré tout le matériel des dernières années dans des cartons, ainsi que les 2 plateformes volantes. En premier lieu, ce que nous avons fait, c est essayer de regrouper toutes les documentations pour comprendre ce qui avait déjà été développé, les choix techniques et technologiques qui avaient été pris. Nous nous sommes très largement inspirés de leurs solutions matérielles pour préparer notre commande principale. Autrement, il faut savoir que nous n avons pas pu exploiter leurs développements qui n étaient que bouts de code éparpillés et non commentés. Ainsi, le seul programme que nous avons réussi à exécuter est «testxbee.c» qui permettait d envoyer des ordres aux servo-moteurs avec le protocole ZigBee. Un module Xbee étant déjà embarqué sur le drone et relié aux PWM des moteurs, il suffisait de connaître le format des messages à envoyer (indicateurs + héxadécimal) Etat d avancement L équipe précédente a travaillé à la fois sur le quadri et sur l hélicoptère. Cela explique peut-être pourquoi ils n ont jamais mis la carte embarquée en conditions réelles de vol. Leur communication avec le quadri passait directement par des ordres de bas niveau aux servomoteurs en Xbee. Autrement dit, il n y avait aucun asservissement des moteurs et aucune IA embarquée. C est sur ces points que nous avons principalement travaillé. En revanche, il leur était possible de piloter le quadri assisté par un joystick ce qui leur a demandé de s approprier un nouveau matériel. Enfin, ils ont également développé un certains nombres d algorithmes de traitement d images tels qu un suivi de cible, détection d horizon Matériels utilisés Pour l intelligence à embarquer sur le drone, ils ont opté pour des Gumstix qui sont des processeurs relativement fiables et puissants, mais surtout très légers. Nous avons choisi de suivre leur choix en travaillant sur Gumstix également. Pour la communication avec le drone, ils ont utilisé le module Xbee déjà implanté sur le drone. Nous avons également travaillé quelques temps sur les Xbee avant de réaliser qu il n était pas possible de coupler le module à notre carte intelligente. Ainsi, nous avons abandonné cette technologie pour utiliser du Wifi, protocole simple et déjà disponible sur la Gumstix Nous avons également récupéré une armature en polystyrène très efficace pour protéger les hélices, et un montage de Gumstix dans une boite plastique allégée par des trous et équipée de patins pour amortir les atterrissages. iflybot2012 Document de synthèse 16

17 4.2 PROJETS SIMILAIRES En discutant avec le Client, celui-ci nous a orientés sur des projets déjà existants traitant globalement des mêmes thématiques : Drone volant, intelligence embarquée, capteurs et vision. The Paparazzi Project ( C est un projet libre open-source, tant sur le côté hardware que software, réalisé à l ENAC (Ecole Nationale d Aviation Civile) de Toulouse. Leur but étant de concevoir un système fiable d autopilote pour toute sorte d aéronefs. Leurs travaux sont très complets mais portent globalement sur des plateformes d avion avec des ailes ce qui relativement différent d un quadrirotor comme le notre. Aeryon Scout est un drone de surveillance volant, destiné à la police. Présenté à l AlwaysOn Stanford Summit, il est capable d aller prendre des photos ou de la vidéo à l endroit demandé. Ce drone réalise exactement les mêmes actions que nous souhaitons inculquer à notre UAV. (Cf. Annexes pour avoir un résumé complet) iflybot2012 Document de synthèse 17

18 5 ENVIRONNEMENT DE DEVELOPPEMENT Le développement logiciel se réalisera avec les langages C++ et Java, sous Windows 7 ou Linux avec les logiciels suivants : Logiciels Eclipse SVN GCC 5.1 SVN Description IDE multi-langages Logiciel de gestion de versions Compilateur pour le langage C++ Afin d améliorer la performance du développement au sein de l équipe, un serveur SVN a été mis en place. Il permet de synchroniser les codes sources, ainsi que tous nos documents techniques et fonctionnels : Un compte anonyme avec un accès en lecture seul sera mis à disposition pour les personnes souhaitant récupérer nos programmes. Ils seront également stockés sur un DVD, comme le requiert l Université. 5.2 ECLIPSE Eclipse IDE est un environnement de développement intégré libre extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en œuvre n importe quel langage de programmation. La spécificité d Eclipse IDE vient du fait de son architecture totalement développée autour de la notion de plugin : toutes les fonctionnalités de cet atelier logiciel sont développées en tant que plug-in. Lors de notre projet, nous nous sommes servis de cet outil uniquement pour le développement en JAVA de notre interface. De plus, grâce au plugin «subclipse», nous avons accès au SVN avec la possibilité de contrôler les différentes versions de développement et d avoir toujours un code à jour. La dernière version d Eclipse IDE pour Java est disponible à l adresse suivante : Voici la liste des plugins que nous avons utilisés en complément : - Subclipse (Subversion) : - En option : CDT (C/C++ Development Tools) iflybot2012 Document de synthèse 18

19 5.3 LINUX Pour les développements en C/C++, il est d usage de coder sous Linux pour avoir une console complète à la disposition du développeur. Par défaut, Linux possède tous les outils pour compiler dans ce langage. La connaissance que l on a du monde UNIX est un plus pour débugger sur toute sorte de ports, pour faire du réseau ou bien de l embarqué. Même si l équivalent existe sur Windows avec PuTTY, Linux propose des outils idéals pour toutes les manipulations sur les liaisons série, les connexions Wifi : Minicom, SSH etc. 5.4 GUMSTIX De même, c est un noyau Linux Angstrom qui est embarqué sur la carte. Elle dispose d un boot normal, avec une navigation et un système de fichiers communs à tous les Linux. Cette carte est accessible par une liaison type USB->Série, ou par le Wifi (un script s exécutant au démarrage de la carte pour l initialiser). Une chaine de compilation pour le C/C++ a été installée sur la carte afin de développer directement sur la carte via l éditeur VIM. D autres modules ont été intégrés sur la carte tels que : - Librairie libc (développement) - Librairie OpenCV (traitements d image) - Drivers Caspa (caméra) Le démarrage de la carte se fait par le biais d une carte SD-bootable qui contient une image du noyau. Au final, ce type de carte est très performant et très utilisé en embarqué pour sa puissance et sa légèreté. En revanche, elle demande un grand savoir-faire pour être configurée sans soucis. iflybot2012 Document de synthèse 19

20 6 ARCHITECTURE MATERIELLE 6.1 MATERIEL Le système utilise le matériel suivant : Deux plateformes volantes : Hélicoptère Un hélicoptère de modélisme, référence Benzin Trainer de Vario Quadricoptère Un quadri-rotor de développement, référence Hummingbird XD3D UFO de Asctec iflybot2012 Document de synthèse 20

21 Deux interfaces : o Une Télécommande, pour un contrôle standard de l hélicoptère ; o Un PC, pour récupérer les informations de vol, programmer un vol autonome et faire certains traitements durant les phases de test. Des équipements embarqués sur l UAV : o Une Gumstix Overo Air couplée à la carte Gallop43 ; o Une Gumstix RoboVero (ou FunPilot carte propriétaire AscTec) ; o Un commutateur ou équipement de Switch automatique/manuel. Le projet peut être déployé sur 2 aéronefs que nous allons détailler ci-dessous, un quadricoptère et un hélicoptère. Cependant, nous allons concentrer nos développements sur la plateforme du quadricoptère pour des raisons de facilité de développement et de test. 6.2 ARCHITECTURE «QUADRICOPTERE» Matériel embarqué Pour ce projet, nous avons utilisé un quadricoptère de chez Ascending Technologies. Le modèle est un X3D-BL (BlackBird). Les principaux éléments du X3D-BL sont : l armature en croix, la carte mère X-Base, la carte Funpilot, la carte X-ACC, les contrôleurs de moteur X- BLDC et les 4 moteurs Brushless de chez HACKER Motors (moteurs et hélices neufs). Caractéristique X3D-BL Autonomie Charge utile Surface Type de Structure Masse à vide (Hors Equipment embarqué) Surface (sans les hélices) 12 Minutes 200g 53cm² Fibre de Carbonne 75g 32cm² iflybot2012 Document de synthèse 21

22 Le quadricoptère embarque 2 cartes de contrôle X-Base et X-Funpilot (nous détaillerons leurs rôles dans le schéma de principe) dont voici les caractéristiques : Processeur Contrôleur USB Radio X-Base ATMega88 16MHz Moteur X-BLDC X-USB PPM / ACT DSL Processeur Capteur USB Bus Firmware X-Funpilot LPC2146 ARM7 60MHz 3 gyroscopes / Barométrique (contrôle altitude) X-USB I2C/SPI 4 Sélectionnables par jumper La carte X-ACC est une option qui est présente sur notre modèle. C est un accéléromètre 3 axes. L obtention des accélérations sur chaque axe permet de calculer l orientation absolue de l engin en tangage et en roulis pour permettre de le stabiliser. Avec l utilisation de cette carte, le quadri-rotor tend à revenir à une position horizontale. iflybot2012 Document de synthèse 22

23 Un moteur Brushless est placé en bout de chaque branche, les caractéristiques des moteurs sont les suivantes : HACKER Motors XBLC Pôles 14, rotor extérieur Intensité Max 8 A, 1,25 nominal Tension 12V Masse 27,5g Le quadri-rotor dispose de 4 contrôleurs X-BLDC pour contrôler chaque moteur. Les contrôleurs reçoivent les données par I2C. Contrôleurs X-BLDC Processeur ATMege88 14,7MHz Bus I2C Courent 20A Max, 12A Optimal Tension 8-15V Masse 8g Temps de réponse 1ms Comment vole un quadricoptère? Le quadri-rotor possède 4 types de déplacements : déplacement vertical, tangage, roulis et lacet. Pour chaque type de déplacement, il s agit de jouer sur la vitesse de rotation des moteurs. Dans notre cas, les moteurs avant et arrière tournent dans le sens horaire et les moteurs gauche et droit dans le sens antihoraire. iflybot2012 Document de synthèse 23

24 Déplacement vertical : il s obtient en augmentant ou en diminuant la vitesse de rotation des quatre moteurs : Mouvement de tangage : il s obtient en agissant sur les moteurs avant et arrière, en diminuant la vitesse de rotation de l un tout en augmentant celle de l autre. Ainsi, si l on souhaite incliner le quadri-rotor vers l avant, il faut diminuer la vitesse de rotation du moteur avant et augmenter celle du moteur arrière : Mouvement de roulis : il s obtient de la même manière mais cette fois ci en agissant sur les moteurs gauche et droit. Ainsi, si l on souhaite incliner le quadri-rotor vers la droite, il faut diminuer la vitesse de rotation du moteur droit et augmenter celle du moteur gauche : Mouvement de lacet : il s obtient en diminuant la vitesse de rotation d un couple de moteurs opposés tout en augmentant celle de l autre couple. Ainsi, pour obtenir un lacet sur la droite, il faut diminuer la vitesse de rotation des moteurs avant et arrière tout en augmentant celle des moteurs gauche et droit : iflybot2012 Document de synthèse 24

25 6.2.3 Schéma de principe Architecture d origine Voici le schéma de l architecture du quadri-rotor d origine lors du pilotage à la manette. Nous ne disposons alors que du pilotage à la manette, la carte X-FunPilot réalisant une première stabilisation sur le roulis et le tangage. Cette configuration est toujours la même lorsqu on souhaite reprendre la main via la télécommande RC iflybot2012 Document de synthèse 25

26 Architecture année antérieure Voici un schéma qui correspond aux réalisations des années passées. Dans ce schéma, la carte Gumstix récupère divers paramètres de vol et les transmet au PC de supervision qui grâce à un module Xbee connecté en USB, peut renvoyer des ordres à la carte FunPilot. Ainsi, dans cette configuration, il est possible d interagir avec les servomoteurs du quadri mais la boucle passe par le PC pour envoyer les ordres de bas niveau. On a donc une grande boucle qui fait Air Sol Air et qui dépend du PC (non idéal pour de l embarqué RT). iflybot2012 Document de synthèse 26

27 Architecture cible L architecture finale a pour objectif de ne plus avoir besoin du PC, mis à part pour la phase de démarrage et de communication des missions. Le PC a alors un rôle de superviseur, il n envoie pas d ordres de bas niveau et n interagit plus directement avec les servo-moteurs. Une boucle fermée est établie entre la Gumstix et la X-FunPilot via une liaison série. C est la Gumstix qui réalise tous les traitements et qui agit intelligemment sur les moteurs du drone. Cela confère donc une autonomie totale au drone. Mis à part que la technologie Zigbee ait été abandonné, il en reste pas moins que ce protocole est totalement maîtrisé et pourra être réutilisé si le besoin s en ressent. 6.3 ARCHITECTURE «HELICOPTERE» Matériel embarqué La seconde plateforme volante que nous avons à notre disposition est une maquette d hélicoptère de chez Vario. Le modèle est un Benzin trainer, qui fait partie des plus gros modèles de maquette d hélicoptère à moteur thermique. Ses caractéristiques sont les suivantes : Benzin trainer Longueur Largeur Diamètre Rotor Principal Diamètre rotor d'anti-couple Hauteur Poids Charge utile 1460 mm 200 mm (320 mm au niveau des patins) 1780 mm 310 mm 500 mm 7,3 kg 3,0 kg iflybot2012 Document de synthèse 27

28 Les caractéristiques motrices sont : Zenoah G230 Cylindré 23 cm 3 Type 2 temps Energie Essence 95 sans plomb Dosage huile 1:25 durant le rodage 1:40 normale Comme toute maquette, la conduite se fait à l aide d une radio commande. Notre but est donc de remplacer la radio par nos systèmes pour contrôler le modèle informatiquement. C est ce que nous allons voir sur les schémas suivants, en revanche l équipe de cette année n a pas eu le temps de travailler sur cette plateforme difficile d accès Comment vole un hélicoptère? L hélicoptère possède, tout comme un quadri-rotor, 4 types de déplacements : déplacement vertical, tangage, roulis et lacet. Pour chaque déplacement il faut jouer sur l incidence des pales, la vitesse de rotation étant plus ou moins constante. Pour le lacet il faut agir sur le rotor d anti-couple. Déplacement vertical : il s obtient en augmentant ou en diminuant l incidence des pales sur tous les axes du plateau cyclique : Mouvement de tangage : il s obtient en agissant sur l incidence des pales lorsqu elle se trouve sur l arrière ou l avant de l hélicoptère. Ainsi, si l on souhaite incliner l hélicoptère vers l avant, il faut diminuer l incidence des pales sur l avant et l augmenter à l arrière : iflybot2012 Document de synthèse 28

29 Mouvement de roulis : il s obtient de la même manière mais cette fois ci en agissant sur l incidence des pales gauche ou droit. Ainsi, si l on souhaite incliner le quadrirotor vers la droite, il faut diminuer l incidence des pales sur la partie droite et augmenter celle de la partie gauche : Mouvement de lacet : il s obtient en diminuant ou en augmentent l incidence du rotor d anti-couple : iflybot2012 Document de synthèse 29

30 6.3.3 Schéma de principe Commentaires Le schéma matériel ci-dessus représente l architecture qui aurait été mis en place sur la maquette de l hélicoptère en cas d utilisation de celle-ci. La réalisation du Switch matériel entre la télécommande et l intelligence sera effectuée ultérieurement. iflybot2012 Document de synthèse 30

31 6.4 MATERIEL EMBARQUE Carte Gallop Fonctionnalités Galllop43 Features Power Connections Computing GPS via the u-blox NEO-5G module 3-axis accelerometer LCD-ready for 4.3" touch-screen LCD 24 bits per pixel Touchscreen controller USB mini-ab with OTG signals USB mini-b console port Coin cell backup battery holder 3.5-mm stereo headset jack MCX antenna connector for GPS Two (2) user-configurable LEDs Two (2) user-configurable push buttons Forty (40) signals available on 0.100" through-holes at 1.8V logic Two (2) two-wire serial ports One 1-wire port PWM lines I2C port SPI bus A/D input lines processor control signals Connect a 5v wall adapter to power this expansion board, the connected Overo COM and the attached LCD touch screen Alternate power jack provided for 2-cell NiMH battery pack Connecting both the 5v wall adapter and a MiMH battery pack will charge the NiMH batteries 2 x 70-pin connectors for connection of any Overo COM 40-pin header (not populated) Requires any Gumstix Overo COM Temperatures Built with components rated -20< T <70C Size 118.2mm x 67.2mm Weight 36.2g 71g (incl. shipping case) Rôle Le rôle de cette carte est de réaliser les fonctions «haut niveau» du système telles que : Repérage GPS Calcul des trajectoires Stabilisation en déplacement grâce à la caméra Communication iflybot2012 Document de synthèse 31

32 6.4.2 Carte RoboVero Fonctionnalités RoboVero Features Computing Power Connections The new HubCommander interface over USB lets an external host commandeer the onboard USB Hub and these devices: Cortex-M3 JTAG Cortex-M3 USB Device Two (2) USB Standard A Jacks Console for the onboard Overo COM (if present) 3-axis accelerometer 3-axis magnetometer 3-axis gyroscope Coin cell backup battery holder Three 3x10 headers Motor Header - 7 lines each for power and return at motor voltage, - 6 PWM lines at 3.3V, - 10 motor control lines at 3.3V-- for control of one 3-phase AC or DC motor AD Header - 7 A/D lines - 2 A/D reference lines - 3 A/D power lines - SPI bus - 7 GPIO - Power lines Communication Header - 2 two-wire serial ports - 1 four-wire serial port - I2C bus - SPI bus - CAN bus - 3 GPIO - Power lines Note that some signals are multiplexed and share the same header pin (refer to schematic) RoboVero comes preflashed with sample libraries from NXP and a command line interface. Solder points for a battery with 5V < V_BATT < 17V provide ultimate mobility. Quickly switch to grid power by connecting a 5V, 3.5A wall adapter. 2 x 70-pin connectors for connection of any Overo COM 3 x 30-pin 0.100" headers Temperatures Built with components rated 0< T <70C Size 118.2mm x 67.2mm Weight 32.2g iflybot2012 Document de synthèse 32

33 Rôle Cette carte a pour rôle de contrôler les fonctions «bas niveau», pour l hélicoptère uniquement. Effectivement, ce contrôle est déjà réalisé par la carte X-FunPilot sur le quadrirotor. Cette carte possède de nombreuses E/S contrôlées par un processeur dédié, ce qui lui confère un grand avantage dans le contrôle des servo-moteurs. Ses fonctions sont donc de : Réaliser le contrôle des servomoteurs ; Stabiliser l assiette Les cartes Gumstix Caractéristiques OveroAir COM Overo Air COM Processor: Texas Instruments OMAP 3503 Applications Processor: - ARM Cortex-A8 CPU Clock(MHz): Performance: 600 MHz Up to 1200 Dhrystone MIPS Memory: 512MB RAM 512MB Flash Features: OMAP3503 Application Processor b/g wireless communications Bluetooth communications microsd card slot TPS65950 Power Management Expandability: Connections: Power: Size: Weight: Products Included: via one 140-pin expansion board of Gumstix Overo series or custom, 140-pin expansion board via 27-pin camera board - (2) 70-pin connectors with 140 signals for: - I2C, PWM lines (6), A/D (6), 1-wire - UART, SPI, Extra MMC lines - Headset, Microphone - Backup battery - High Speed USB Host and USB OTG (1) 27-pin connector with signals for camera board (2) x u.fl antenna connectors Powered via expansion board (Overo series or custom) connected to dual 70-pin connectors 17mm x 58mm x 4.2mm (0.67 in. x 2.28 in in.) 42.6g (incl. shipping case & 2 x antenna) 5.6g GUM3503A includes: - 1 x GS3503T (Overo Air COM)) iflybot2012 Document de synthèse 33

34 - 2 x ANT006 (U.FL Antenna) - 4 x retaining spacers for Overo COM (CONH0020) Temperatures: Built with components rated 0C < T <75C Mounting: Four (4) x #0 mounting holes for securing to Overo-series, or custom, expansion board Caractéristiques OveroEarth COM Overo Earth COM Processor: Clock(MHz): Performance: Memory: Features: Expandability: Connections: Power: Size: Texas Instruments OMAP 3503 Applications Processor: - ARM Cortex-A8 CPU 600 MHz Up to 1200 Dhrystone MIPS 512MB RAM 512MB Flash OMAP3503 Application Processor microsd card slot TPS65950 Power Management via one 140-pin expansion board of Gumstix Overo series or custom, 140-pin expansion board via 27-pin camera board - (2) 70-pin connectors with 140 signals for: - I2C, PWM lines (6), A/D (6), 1-wire - UART, SPI, Extra MMC lines - Headset, Microphone - Backup battery Weight: 4.3g Products Included: - High Speed USB Host and USB OTG (1) 27-pin connector with signals for camera board Powered via expansion board (Overo series or custom) connected to dual 70-pin connectors 17mm x 58mm x 4.2mm (0.67 in. x 2.28 in in.) 15.1g (incl. shipping case) GUM3503E includes: - 1 x GS3503E (Overo Earth COM) - 4 x retaining spacers for Overo COM (CONH0020) Temperatures: Built with components rated 0C < T <85C Mounting: Four (4) x #0 mounting holes for securing to Overo-series, or custom, expansion board Points communs et différences Les deux cartes sont toutes les deux identiques, hormis que la Air COM gère le Wifi et le Bluetooth alors que la Earth COM non. De ce fait, nous utilisons l Air COM là où nous avons iflybot2012 Document de synthèse 34

35 besoin de communiquer sans fils avec le monde extérieur. Nous l utilisons donc exclusivement avec la carte Gallop43 qui est la carte de haut niveau. 6.5 BUS UTILISES I2C Le bus I2C est un bus très utilisé pour faire communiquer des composants ou des circuits imprimés proches entre eux. Il a été inventé dans les années 80 par Philips/Thomson. Dans notre projet, il sert de bus de communication entre les composants et les cartes. Pour plus de détails sur fonctionnement : Série La liaison série permet de faire communiquer les 2 cartes RoboVero et Gallop43 entre elles lors de l utilisation sur l hélicoptère. Elle est également utilisée sur le quadrirotor pour la communication entre la FunPilot et la Gumstix. Cette liaison permet d envoyer les ordres de pilotage au quadrirotor et de récupérer les informations de celui-ci. C est une liaison simple bifilaire Liste des liaisons série Gallop43 La Gumstix possède 5 UART dont 3 sont paramétrables ( Nous avons donc utilisé les ports suivants, ttys0 (STUART) GPS câblé non configurable. ttys1 (BTUART) Bluetooh, configurable (car pin partagé avec HWUART) ttys2 (HWUART) Pin GPIO 166 & 165 ttys3 (HWUART) Kernel serial + GPIO 48 & 49 Pour relier un port d un UART à une sortie : Echo UART DIRECTION(IN ou OUT) > /proc ou /sys + Chemin vers le pin Les pins sont triés par type/lieu de connexion etc. iflybot2012 Document de synthèse 35

36 6.6 CONCEPTION ELECTRONIQUE Interface physique série FunPilot Gallop FunPilot Le port série de la carte FunPilot est une logique TTL avec des valeurs comprise entre 5V et 0V où : 5V représente l état 0 ; 0V l état Gallop43 Le port série de la carte Gumstix est une logique TTL avec des valeurs comprise entre 0V et 1.8V où : 1.8V représente l état 0 ; 0V l état 1. iflybot2012 Document de synthèse 36

37 Mise à jour : Vu que le port ttys0 est utilisé par le GPS, nous avons déplacé le connecteur série Gumstix -> FunPilot sur le port ttys2 (port GPIO 166/GPIO 165). Pour plus d informations, voir la documentation technique du CPU (TI OMAP). Pour paramétrer les liaisons, il faut aller dans /sys/device/ et faire comme avec n importe quel noyau Connexion Pour la connexion finale, nous avons utilisé le connecteur propriétaire ASCTEC et nous l avons soudé à l aide de fils sur la carte Gumstix. Il faut bien penser à croiser le câble série : RX Gumstix -> TX FunPilot, TX Gumstix -> RX FunPilot. A force de brancher/débrancher, les fils se sont abîmés. La connexion n étant déjà pas très fiable (réception de start/stop bits aléatoire), nous avions décidé de faire une soudure pour s assurer un fonctionnement correct avec un montage très propre sans risque de courtcircuit. Aperçu du montage : Alimentation La carte Gumstix était à la base alimentée par un RIT (Régulateur de tension intégré) qui permet de lisser la tension en sortie de batterie pour donner une alimentation «stable» autour de 5V. Cependant, vu que la batterie alimente aussi les moteurs, on peut imaginer que des surtensions et des à-coups au niveau du courant sont fréquents. Nous avions tout de même testé la sortie avec un voltmètre qui indiquait bien 5V, mais nous n avions alors pas pensé qu il puisse y avoir des pics de tension. Ainsi, avant de s apercevoir de quoi que ce soit et après quelques tests, il semblerait que 2 cartes Gallop43 aient été grillées. L alimentation de la Gumstix étant un peu juste (le constructeur n ayant certainement pas prévu cet usage), nous l avons remplacé par une alimentation à découpage beaucoup plus performante et qui ne laisse passer aucune imperfection au niveau de l alimentation. iflybot2012 Document de synthèse 37

38 Liste des composants utilisés PTN78000W Résistance 22K Ohm 1% = R1 Condensateur electrolide 100µF 16V = C1 Condensateur electrolide 2.2µF 16V = C Schéma Ancien montage du connecteur pour l alimentation Gumstix (RIT) iflybot2012 Document de synthèse 38

39 Nouveau montage avec boitier contenant une alimentation à découpage (tension stable) iflybot2012 Document de synthèse 39

40 7 ARCHITECTURE FONCTIONNELLE 7.1 DESCRIPTION DU PROJET Le but du projet iflybot 2012 est de faire voler un drone en autonomie, sans intervention humaine. Un vol autonome ne peut pas durer plus de 15 minutes à cause de la capacité de la batterie. De plus, la qualité du vol n est assurée que s il n y a pas d obstacle sur le chemin du drone, s il capte un signal GPS correct et s il n y a pas de vent. Sans signal GPS, il est cependant possible d effectuer un vol assisté, c est-à-dire de le piloter avec plus de facilité qu avec la télécommande de modélisme standard. En outre, si le pilote ne touche plus aux commandes, le drone se stabilise sur sa position. Pour atteindre ce but, une intelligence est embarquée sur le drone et un ordinateur au sol permet au pilote de lancer un vol autonome ou de prendre la main avec un joystick (pour les vols assistés). NB : le pilotage assisté par le joystick ne fait plus partie des fonctionnalités. Par précaution, le pilote peut reprendre le contrôle de l appareil à tout moment grâce à la télécommande de modélisme. 7.2 FONCTIONNEMENT Fonctionnement manuel Au démarrage, le pilotage est en mode manuel, c est-à-dire que le drone est contrôlé par la télécommande Graupner MC22s. Depuis cette télécommande, nous avons configuré un bouton afin qu il soit possible de passer en mode assistance par ordinateur permettant de prendre le contrôle par la liaison série. Quand aucune commande n est envoyée, l UAV reste en vol stationnaire. Si cette connexion est perdue, alors le système bascule automatiquement en manuel. Il est possible de revenir en mode manuel à tout moment en utilisant la télécommande. iflybot2012 Document de synthèse 40

41 Voir l Erreur! Source du renvoi introuvable. en Annexe Fonctionnement autonome Le pilote peut également lancer le mode autonome avec une mission préenregistrée. Selon la mission, le drone peut décoller, atterrir, suivre une cible ou rejoindre une position GPS en plus des contrôles basiques. Durant le vol, tous les mouvements calculés peuvent être enregistrés dans un fichier de log. Voir l Erreur! Source du renvoi introuvable. en Annexe. 7.3 CAS D UTILISATION 7.4 CONTRAINTES Contraintes d environnement Poids à transporter Pour le quadricoptère, se référer au paragraphe de ce document. Pour l hélicoptère, se référer au paragraphe de ce document Météo Le quadricoptère ne peut être utilisé que dans des conditions climatiques où le vent est quasi-inexistant. La plupart des tests que nous aurons à effectuer se feront dans un milieu clôt (ex : gymnase). L hélicoptère lui n est pas autant affecté par les conditions de météo pendant son vol. iflybot2012 Document de synthèse 41

42 Sécurité L hélicoptère ne peut être piloté, légalement, que par un personnel qualifié. Nos tests ne peuvent donc être faits que par un modéliste : ce qui implique une certaine organisation pour que nos tests soient faits dans le cadre de sessions de pilotage par ce dernier à intervalle régulier. Le quadricoptère lui peut être piloté en intérieur avec un minimum de doigté, les armatures en polystyrène limitant la casse ou les coups d hélice Contraintes en temps Temps de traitement d images Nous distinguons deux cas de figure : le vol stationnaire et la suivi de cible. Le vol stationnaire n a pas besoin de beaucoup d images par seconde, nous estimons que la stabilisation du drone nécessite 5 images par seconde. En revanche, le suivi de cible en nécessite un peu plus : par conséquent, pour suivre une cible se déplaçant à 5km/h, nous aurons besoin d environ 10 images par seconde. Nous devrons donc nous plier à cette dernière contrainte pour avoir un suivi de cible correct Temps de communication Pour éviter que l humain pilotant le drone ait une impression de latence, il faut que l ordre donné au drone soit réalisé par ce dernier dans un délai n excédant pas 250ms, comprenant la communication et l exécution (durée moyenne que l humain met pour exécuter une action qu on lui a ordonné). Ces aspects Temps-réel sont importants, il est vital de maîtriser le temps de nos boucles en embarqué Contraintes d énergie Sur le quadricoptère, le vol ne peut durer plus de 15 minutes, durée maximale des batteries. En effet, une batterie ayant une plus grande autonomie serait trop lourde. Il faut compter plus d 1h pour recharger la batterie li-po ce qui empêche les tests en continu. Pour cette raison, il a été commandé 2 batteries «sport» supplémentaires. Sur l hélicoptère, le vol dure environ 30 à 45 min grâce au réservoir de carburant. Et nous pouvons embarquer une charge plus élevée et utiliser des batteries ayant une meilleure autonomie pour que les cartes embarquées soient alimentées durant la totalité du vol. iflybot2012 Document de synthèse 42

43 8 ARCHITECTURE LOGICIELLE 8.1 LANGAGE ET ARCHITECTURE La partie logicielle qui sera déployée sur la Gumstix en embarqué sera développée avec le langage C++. Nous avons choisi ce langage pour deux raisons : La programmation orientée objet (création d un Main principale simple) La rapidité d exécution Les couleurs sont là pour regrouper les classes travaillant ensemble : Jaune : Les capteurs Vert : Les actions et mouvements Bleu : La communication et les échanges de messages Rouge : La classe principale Gris : les écouteurs Pour plus de détails, une documentation complète Doxygen décrivant toutes les classes est disponible sous le répertoire /html. iflybot2012 Document de synthèse 43

44 PROTOCOLES DE COMMUNICATION Nous avons mis un système de communication commun à l UAV et l interface graphique afin de simplifier et clarifier la communication entre ces deux entités. 8.2 L UAV Nous pouvons distinguer deux parties dans l UAV : FunPilot et Gumstix Gallop FunPilot La carte FunPilot possède une intelligence minimale. Pour rappel, le but de ce projet est de faire la stabilisation du drone d une manière générale. Nous verrons les limites de cette carte dans le chapitre suivant en ce qui concerne la stabilisation. Néanmoins cette carte nous est bien utile car cette dernière communique avec la seconde carte du quadri : la XBase. En effet, la FunPilot connait le protocole de communication pour pouvoir ordonner à la XBase les actions sur les moteurs. La FunPilot est donc une sorte de passerelle entre la Gumstix et la XBase/Servomoteurs Communication Gallop43 avec FunPilot Comme dit précédemment, c est sur la Gumstix Gallop43 que toute notre intelligence est embarquée. Celle-ci connectée directement en série utilise un protocole spécifique. Quel que soit le type de trame envoyé nous devons l agencer d'une certaine façon pour que la FunPilot puisse l'interpréter : c'est ce que nous avons appelé le «formatage». Le format à respecter est le suivant : Startbyte 1: > Startbyte 2: Startbyte 3: > Length of dat in bytes (high byte) Length of data in bytes (low byte) DATA CRC16 of data (high byte) CRC16 of data (low byte) Nous formatons la zone de données avec des structures dans le code. Pour que la taille soit bien détectée, il faut rajouter la directive de préprocesseur suivante : attribute (( packed )) Sinon la taille retournée par sizeof est plus grande. La taille envoyée concerne juste les données et non les bits de start qui sont obligatoires ainsi que le CRC et la taille elle même. La directive de préprocesseur ci-dessus permet de supprimer les bits à 0 entre chaque attribut d une structure. Petit détail mais qui mérite d'être précisé : il faut bien respecter le sens des bits lors de l'envoi. Nous avons cependant remarqué que la FunPilot, lors de l'envoi de ces données, ne respecte pas le formatage de la documentation le bit de poids faible est envoyer en premier pour la taille et pour le CRC. iflybot2012 Document de synthèse 44

45 Type de trame utilisé Le protocole de la FunPilot comporte plusieurs types de trame. Nous en utilisons uniquement 3. Une trame de configuration, une trame de commande et une trame de statut qui est renvoyée par la FunPilot après chaque trame de commande. Le contenu de la trame de statut est paramétré par le contenu envoyé dans la trame de configuration. Les données sont stockées par le programme sous forme de structure : struct FunCommand { unsigned char packetdescriptor; // Pitch/Roll/Thrust/Yaw ( ) unsigned short pitch; unsigned short roll; unsigned short thrust; unsigned short yaw; // Flags // Bit 0: Pitch control through serial interfacae enabled // Bit 1: Roll control through serial interface enabled // Bit 2: Thrust control through serial interface enabled // Bit 3: Yaw control through serial interface enabled // Bit 4: ACC-Mode on/off // Bit 5: Height control - on/off (only with ACC) // Bit 6: Mode selected by RC (0) /Mode selected by Bits 4 and 5 (1) // Bit 7: Trigger Scientific status packet // Bits 8..15: Off (0)/5Hz (1)/100Hz (20)/1kHz (200)/Send once (255) unsigned short flags; } attribute (( packed )); struct FunData { //always PD_SCIENTIFICDATA //#define PD_SCIENTIFICDATA 0x19 unsigned char packetdescriptor; //length of data field in bytes. Packetlength= length + 4 unsigned char length; //flexible data field. Maximum 32 integers or 64 shorts. unsigned char data[128]; } attribute (( packed )); struct FunConfig { //always PD_SCIENTIFICCONFIG //#define PD_SCIENTIFICCONFIG 0x20 unsigned char packetdescriptor; unsigned char data_select[128]; } attribute (( packed )); Le nom des structures est assez explicite pour ne pas être expliqué. iflybot2012 Document de synthèse 45

46 Nous envoyons et lisons les trames en les mixant de la façon suivante, FunCommand > Pour initialiser la communication avec des valeurs de commande aléatoire FunConfig > Permet d'indiquer quelle data nous voulons recevoir lors de la prochaine commande FunCommand FunData > renvoie les informations demandées lors de la configuration FunCommand FunData Etc. La trame de configuration La trame de configuration doit être identifiée avec le descripteur 0x20. Cette trame permet de choisir quelle information renvoyer après une trame de commande (on peut aussi paramétrer une fréquence d'envoi dans la trame de commande plutôt que le pooling). Il faut faire attention à ne pas demander des informations qui ne serait pas utilisées pour éviter de charger la communication série inutilement. Les identifiants à mettre dans la trame de configuration sont disponibles au chapitre page 14 et 15 du research pilot manual. Les informations reçues sur le port série correspondront donc à l ordre défini dans la trame de configuration. Par exemple, dans le cas de notre programme nous avons configuré la trame avec les valeurs suivantes : this->_config.packetdescriptor = 0x20; this->_config.data_select[0] = 0x0C; // Angle Pitch this->_config.data_select[1] = 0x0D; // Angle Roll this->_config.data_select[2] = 0x0E; // Angle Yaw this->_config.data_select[3] = 0x20; // Speed in mm/s this->_config.data_select[4] = 0x1F; // Height compare to the beginning this->_config.data_select[5] = 0x21; // Reference height this->_config.data_select[6] = 0x31; // Up time this->_config.data_select[7] = 0x32; // Battery voltage iflybot2012 Document de synthèse 46

47 La trame de commande La trame de commande permet d envoyer les ordres qui vont s appliquer sur le quadrirotor. Elle comprend quatre ordres principaux, Chaque variable qui contrôle un axe ou une puissance (thrust) doit être comprise entre 0 et Une partie du paquet est un peu particulière : le flag. Cette partie permet de dire quelle partie du drone est contrôlée par le port série ainsi que la fréquence d envoi du paquet d état du drone. Les bits de poids faibles définissent l attribution des commandes (port série ou manette 1 = Série, 0 = Manette). BIT 0 BIT 1 BIT 2 BIT 3 BIT 4 BIT 5 BIT 6 BIT 7 Pitch Roll Thrust Yaw ACC- Height Unused Scientific Mode Controle interface Nous n avons pas compris l utilisation des 4 derniers bits. Les bits de poids forts : la vitesse de transmission des données du drone (Drone -> Gumstix) SendRate BIT 0 BIT 1 BIT 2 BIT 3 BIT 4 BIT 5 BIT 6 BIT 7 Désactivé Hz Hz kHz Poolling Lors de nos tests nous avons toujours laissé le flag a 0xFF de façon à commander tous les axes avec le port série et d obtenir une trame d état du drone après chaque trame de commande. Si aucune commande n est envoyée pendent 50ms la carte FunPilot rendra automatiquement la main a la RadioCommande. iflybot2012 Document de synthèse 47

48 La trame de donnée Selon la configuration mise dans le flag de la trame de commande, la trame de donnée arrive après chaque trame de commande ou à intervalle régulier. Cette trame arrive avec le même formatage que lors de l envoi d une trame mis à part que le bit de poids faible et de poids fort est inversé pour la taille et le CRC. Les éléments contenus dans la trame sont reçus dans l ordre qui a été spécifié dans la trame de configuration. La taille des éléments et leur propriété sont donnés dans le chapitre page 14 et 15 du research pilot manual. Nous plaçons tout le contenu de la trame dans la structure FunData et nous analysons aussi son contenu. Nous avons remarqué plusieurs choses bizarres dans cette trame. Selon la taille les 3 derniers octets envoyés sont à 0 comme si la carte cherchait à compléter les données pour obtenir une certaine taille minimum. Ou alors ces données correspondent à des données obligatoires pour certains programmes comme ceux du constructeur, mais malheureusement cela n est pas documenté. Pour obtenir des informations de cette carte, il faut en premier lieu lui envoyer un ordre avec le paquet qui a le descripteur 0x17 (SCIENFITIC_COMMANDDATA) ce paquet possède un flag que nous avons positionné à FF pour demander l'envoi d'un paquet de statut à chaque fois. Les octets 15 et 16 correspondent au flag et l'octet 16 à la demande d'information par polling. config : 3e 2a 3e c 0d 0e 20 1f this->_config.packetdescriptor = 0x20; this->_config.data_select[0] = 0x0C; // Angle Pitch this->_config.data_select[1] = 0x0D; // Angle Roll this->_config.data_select[2] = 0x0E; // Angle Yaw this->_config.data_select[3] = 0x20; // Speed in mm/s this->_config.data_select[4] = 0x1F; // Height compare to the beginning this->_config.data_select[5] = 0x21; // Reference height this->_config.data_select[6] = 0x31; // Up time this->_config.data_select[7] = 0x32; // Battery voltage Start motor : 3e 2a 3e 00 0b c ff 06 c0 8.3 L INTERFACE GRAPHIQUE Comme pour la Gumstix, nous distinguons deux sens : de l IHM vers le drone et la communication dans l autre sens. Voici, de manière générale, une trame envoyée entre ces deux entités, comme vous pouvez le voir il s agit d une suite d instruction séparée par des «deux points» : Ex : «4:2» signifie une demande d action «Décoller». Voici dans le détail le protocole utilisé pour la communication de l IHM vers le drone : iflybot2012 Document de synthèse 48

49 Caractère de départ Description Valeur Décomposition Valeur Décomposition Valeur Décomposition Valeur Demande les missions enregistrées 1 Demande infos 2 Demande d arrêt des infos -2 Demande vidéo 3 Demande d arrêt de la vidéo -3 «Gum» Demande action 4 Démarrer 1 Arrêter - 1 Décoller 2 Atterrir -2 Stabiliser 3 Aller à 4 Coordonnée GPS «Coordonnée GPS» Revenir -4 Coordonnée GPS «Coordonnée GPS» Enregistre cette mission 5 Nom «Nom de la mission» Nombre action «Nombre action» liste action «liste action» Supprimer une mission -5 Nom «Nom de la mission» Démarrer cette mission 6 Nom «Nom de la mission» Arrêter la mission en cours -6

50 Comme précisé précédemment, nous avons essayé de garder le même type de protocole pour le sens inverse par soucis de clarté. Caractère de départ Description Valeur Variable Valeur Variable Valeur Variable Valeur «Gum» Envoi des missions enregistrées 1 Nom Envoi des infos (roulis, tangage, orientation, position, mode, batterie, action en cours) Envoi vidéo 3 «Nom de la mission» Nombre action «Nombre action» liste action «liste action» 2 roulis «roulis» Ainsi lorsque l IHM demande l information à un instant t, la Gumstix lui répond : «2:<angle_roulis>:<angle_tangage>:<latitudeGPS>:etc.» En ce qui concerne le flux vidéo, initialement prévu en UDP mais finalement implémenter en TCP pour des soucis de réseau et non réimplémenter pour des problèmes de temps et de criticité, possède quelques particularités quant à son envoie vers l IHM. Pour ne pas surcharger le réseau et/ou ralentir le système, les images (sous formes de buffers) sous envoyés 1024 bits par Le détail du protocole de communication est disponible dans les spécifications d architectures logicielles (SAL). iflybot2012 Document de synthèse 50

51 9 DEVELOPPEMENTS Dans ce chapitre nous allons détailler comment nous avons développé les différentes partie de notre quadrirotor et quel sont les difficultés auxquelles nous avons du faire face et comment nous les avons surmontés. 9.1 CAPTEURS Accéléromètre L'accéléromètre est un des derniers capteurs que nous avons eu a implémenté. La raison est que nous pensions à la base récupérer les informations de la FunPilot par le biais du port série malheureusement celui si a été victime d'un court-circuit. Son implémentation a été relativement simple étant donné que nous nous sommes basés sur les travaux de Pierre Andry qui nous a gracieusement fourni son code source. Le seul travail a donc été son intégration dans notre application dans une version en C Caméra La caméra a été un des capteurs le plus dur à prendre en main, néanmoins le plus utile. En effet, comme dit précédemment, la carte FunPilot permet de stabiliser un minimum le drone selon cet axe : Par contre, étant donné que l UAV n a que des capteurs d accélération (les accéléromètres), si la vitesse de déplacement latérale du drone est constante, aucune accélération n est détectée. Le drone pourrait donc continuer à dériver latéralement sans correction. La caméra, via un traitement d image expliqué dans le paragraphe suivant, va corriger cette éventuelle dérive. Mais sa prise en main fut difficile non par pour des raisons de développement mais principalement pour des questions systèmes. En effet l'os livré par le constructeur et que nous avions installé naïvement sur notre carte ne prend pas en charge la camera par défaut. Il nous a donc fallu trouver le driver mt9v032.ko mais il est alors impossible d'activer la caméra et le wifi en même temps. Nous avons donc du trouver un noyau compatible avec l'utilisation de la camera et du wifi et nous nous sommes tournés vers le noyau de Debian compilé pour ARM avec le système de fichiers (rootfs) de base de la distribution Angström compatible avec le noyau et avec les drivers pour cette version de noyau. Nous avons donc eu la joie de faire fonctionner la caméra et le wifi de façon simultanée. Il faut tout de même penser à charger le pilote au démarrage de la carte grâce à un script lancé au démarrage des modules l OS. Une fois le driver chargé nous avons pu obtenir des images fixes png uniquement en utilisant la commande suivante :