IMA3/IMA4 2018/2020 P21 : Différence entre versions
(→Analyse du second concurrent) |
|||
| (337 révisions intermédiaires par 3 utilisateurs non affichées) | |||
| Ligne 5 : | Ligne 5 : | ||
==Description== | ==Description== | ||
| − | |||
De nos jours, les drones sont présents dans de nombreux domaines : industrie, agriculture, sports, loisirs… etc. Dans les airs ou dans la mer, ils ont tous des buts différents selon leur utilisation. | De nos jours, les drones sont présents dans de nombreux domaines : industrie, agriculture, sports, loisirs… etc. Dans les airs ou dans la mer, ils ont tous des buts différents selon leur utilisation. | ||
| − | Nous allons nous concentrer sur les | + | Nous allons nous concentrer sur les drones de développement. Ils sont utilisés dans la recherche, l’éducation et par les amateurs de robotique. Ils présentent de nombreux enjeux, comme la commande automatique, l’évitement d’obstacles, la détection d’intrus. |
L’ouverture à la programmation et à la modification hardware/software peut être un frein dans la mise en place d’une application d’un drone de développement. C’est pourquoi nous allons nous concentrer sur un drone open source au niveau hardware et software. | L’ouverture à la programmation et à la modification hardware/software peut être un frein dans la mise en place d’une application d’un drone de développement. C’est pourquoi nous allons nous concentrer sur un drone open source au niveau hardware et software. | ||
| Ligne 17 : | Ligne 16 : | ||
==Objectifs== | ==Objectifs== | ||
| − | Le fil directeur de notre projet est le contrôle d'un drone sous les facettes d'informatique, | + | Le fil directeur de notre projet est le contrôle d'un drone sous les facettes d'informatique, microélectronique et automatique. Au niveau informatique, nous nous concentrerons sur le développement d'algorithmes de déplacement et d'évitement d'obstacle. Pour la partie microélectronique nous nous pencherons sur le fonctionnement des moteurs, des cartes électroniques et des capteurs. Enfin nous nous servirons de l'automatique pour réguler en vitesse et en position de notre drone. |
| − | L'objectif final est de développer le drone mis à notre disposition afin qu'il puisse se déplacer d'un point | + | L'objectif final est de développer le drone mis à notre disposition afin qu'il puisse se déplacer point d'un A point à un B tout en étant stable. Au cours de son déplacement il devra transmettre sa position à l'utilisateur. |
| − | Dans un premier temps, nous étudierons le fonctionnement | + | Dans un premier temps, nous étudierons le fonctionnement général d'un drone à 4 branches. Ensuite, nous allons étudier les différentes commandes à envoyer au drone afin de le déplacer selon l'axe voulu. Puis, du côté pratique nous allons asservir une position statique à notre drone qu'il devra maintenir quelle que soit la perturbation (vent, etc). Dans un second temps, nous développerons les fonctions de déplacement dans l'espace. Enfin, nous lui donnerons une trajectoire qu'il devra respecter tout au long de son parcourt. |
| − | |||
| − | |||
=Analyse du projet= | =Analyse du projet= | ||
| Ligne 31 : | Ligne 28 : | ||
====Caractéristiques principales du drone Quadricopter Crazyflie 2.0®==== | ====Caractéristiques principales du drone Quadricopter Crazyflie 2.0®==== | ||
| − | + | [[Fichier:crazyfly.jpg|320px|right]] | |
Radio: | Radio: | ||
| Ligne 78 : | Ligne 75 : | ||
Modèle : ''' Tello Drone EDU ''' | Modèle : ''' Tello Drone EDU ''' | ||
| − | [[Fichier: | + | [[Fichier:dji_tello_drone_etu.png|280px|right]] |
| − | Initialement conçu pour l' | + | Initialement conçu pour l'enseignement, le tello Drone a de nombreux atouts. Pour seulement 100 euros, nous avons un drone compact, résistant (protection des hélices), et programmable. Il est compatible avec scratch, Python et Swift. Pour une utilisation avancée, on peut même embarquer ROS et utiliser le SDK. Il dispose aussi de petites balises pour se repérer dans l'espace et être contrôlé en essaim. |
| − | Cependant, nous ne pouvons pas nous en servir dans notre projet, car ni le hardware, ni le software ne sont | + | Cependant, nous ne pouvons pas nous en servir dans notre projet, car ni le hardware, ni le software ne sont ouverts. Nous ne pouvons donc pas modéliser efficacement les moteurs, ni même faire une étude approfondie au niveau hardware. En fait, il s'agit plutôt d'un drone de programmation du fait de sa compatibilité avec plusieurs langages de programmation, on ne peut pas s'en servir dans un projet à dominante "automatique". |
==Analyse du second concurrent== | ==Analyse du second concurrent== | ||
| Ligne 91 : | Ligne 88 : | ||
Modèles : ''' Pixhawk 4 et Pixhawk mini ''' | Modèles : ''' Pixhawk 4 et Pixhawk mini ''' | ||
| + | [[Fichier:pixhawk4.jpg|120px|right]] | ||
Pixhawk est un projet open source visant à developper un contrôleur de vol libre et indépendant. De nombreux projet aussi bien dans la recherche que dans le monde professionnel se servent d'une carte de vol Pixhwak. Cette carte, très réputée, est notamment compatible avec les projets open source PX4 (Dronecode) et Ardupilot. Dronecode et Ardupilot proposent des outils libres pour simuler, contrôler et analyser son drone tout au long de ses déplacements. Dans un projet comme le notre, Dronecode semble être adapté tant les ressources et la documentation qu'ils proposent sont fournis. | Pixhawk est un projet open source visant à developper un contrôleur de vol libre et indépendant. De nombreux projet aussi bien dans la recherche que dans le monde professionnel se servent d'une carte de vol Pixhwak. Cette carte, très réputée, est notamment compatible avec les projets open source PX4 (Dronecode) et Ardupilot. Dronecode et Ardupilot proposent des outils libres pour simuler, contrôler et analyser son drone tout au long de ses déplacements. Dans un projet comme le notre, Dronecode semble être adapté tant les ressources et la documentation qu'ils proposent sont fournis. | ||
| + | |||
Cependant, bien que nous avons effectuer de nombreuses recherches sur Dronecode, que nous avions conclu qu'il fallait une carte Pixhawk, nous avons finalement abandonné cette piste. | Cependant, bien que nous avons effectuer de nombreuses recherches sur Dronecode, que nous avions conclu qu'il fallait une carte Pixhawk, nous avons finalement abandonné cette piste. | ||
| + | |||
En effet, de notre point de vue, il nous aurait fallu un groupe supplémentaire qui aurait assembler notre drone, pendant que l'autre se penche sur la partie automatique. Un drone embarquant une carte Pixhawk avec PX4 installé dessus nécessite une équipe focalisée sur le hardware. En effet, en plus de la carte, il faut commander le châssis, les moteurs, les antennes, la télécommande, la baterrie, les chargeurs... etc. Nous avons préféré partir sur un drone 'ready to fly', c'est-à-dire déja assemblé et en état de marche. | En effet, de notre point de vue, il nous aurait fallu un groupe supplémentaire qui aurait assembler notre drone, pendant que l'autre se penche sur la partie automatique. Un drone embarquant une carte Pixhawk avec PX4 installé dessus nécessite une équipe focalisée sur le hardware. En effet, en plus de la carte, il faut commander le châssis, les moteurs, les antennes, la télécommande, la baterrie, les chargeurs... etc. Nous avons préféré partir sur un drone 'ready to fly', c'est-à-dire déja assemblé et en état de marche. | ||
| Ligne 101 : | Ligne 101 : | ||
==Scénario d'usage du produit ou du concept envisagé== | ==Scénario d'usage du produit ou du concept envisagé== | ||
| − | Notre projet visant à asservir en position un drone de façon autonome, il existe de très nombreux | + | Notre projet visant à asservir en position un drone de façon autonome, il existe de très nombreux scénarios d’usage pouvant s’inscrire dans notre projet.Par exemple, on pourrait imaginer un agriculteur souhaitant contrôler l’état de ses arbres. On pourrait installer des petites balises sur chacun des troncs, et effectuer un vol autonome afin de filmer chacun de ces arbres. L’agriculteur n’aurait qu’à observer la vidéo, sans avoir à se déplacer dans tout le verger. Notre drone étant asservi en position, il décollera et se maintiendra à une altitude supérieure aux arbres (par exemple 3 mètres) et reliera tous les points indiqués par les balises pour ensuite revenir à son point de départ. |
| − | Par exemple, on pourrait imaginer un agriculteur souhaitant contrôler l’état de ses arbres. On pourrait installer des petites balises sur chacun des | ||
==Réponse à la question difficile== | ==Réponse à la question difficile== | ||
| Ligne 122 : | Ligne 121 : | ||
=Préparation du projet= | =Préparation du projet= | ||
| − | + | '''Notre groupe est constitué d'une seule équipe de 3 personnes.''' | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Cahier des charges du groupe== | ==Cahier des charges du groupe== | ||
| − | Tout d’abord notre drone doit être capable de décoller, d’atterrir et de maintenir une position fixe. Il doit être capable de réguler la vitesse de ses moteurs pour se maintenir en altitude, en fonction des contraintes | + | Tout d’abord notre drone doit être capable de décoller, d’atterrir et de maintenir une position fixe. Il doit être capable de réguler la vitesse de ses moteurs pour se maintenir en altitude, en fonction des contraintes extérieures (comme le vent) qui lui seront imposées. Dans un second temps, il doit pouvoir se déplacer dans l’espace en se repérant via des balises radio. De la même manière, il devra pouvoir exécuter ses déplacements en ayant une précision (à définir) et une marge de résistance aux contraintes physique (à préciser). Par exemple, il devra être capable de se stabiliser et effectuer son vol autonome, avec une précision de 10 centimètres, et un vent limite de 30 km/h. |
| − | Dans un second temps, il doit pouvoir se déplacer dans l’espace en se repérant via des | ||
==Choix techniques : matériel et logiciel== | ==Choix techniques : matériel et logiciel== | ||
| Ligne 154 : | Ligne 146 : | ||
Au niveau logiciel, nous avons besoin de : | Au niveau logiciel, nous avons besoin de : | ||
| − | + | ||
| + | *Betaflight | ||
| + | *Matlab - Simulink | ||
==Liste des tâches à effectuer== | ==Liste des tâches à effectuer== | ||
| + | A ce stade, nous avons définis notre projet en plusieurs axes : | ||
| + | |||
| + | *se documenter sur le fonctionnement d’un drone 4 hélices, appelé aussi quadrotor ou quadcopter | ||
| + | *modélisation d’un moteur brushless | ||
| + | *modélisation des quatre moteurs | ||
| + | *envoie des commandes sur les moteurs sur un banc de test | ||
==Calendrier prévisionnel== | ==Calendrier prévisionnel== | ||
| − | + | ''Diagramme de Gantt de notre projet : '' | |
| + | |||
| + | [[Fichier:diagramme_de_gantt_p21.png|1080px]] | ||
=Réalisation du Projet= | =Réalisation du Projet= | ||
| Ligne 168 : | Ligne 170 : | ||
===Semaine 4=== | ===Semaine 4=== | ||
| − | + | Tout d'abord nous sommes documentés sur les fonctionnalités du In tel Aero ready To Fly. Embarquant une carte Pixhawk, nous pouvons nous servir de Dronecode ou bien d'Ardupilot afin d'effectuer notre vol autonome. Nous avons une préférence pour Dronecode. | |
| + | |||
| + | |||
| + | ''Qu'est-ce que Dronecode ?'' | ||
| + | |||
| + | |||
| + | Dronecode est une plateforme Open Source lancée par la fondation Linux. Elle fournit l'ensemble des outils nécessaire à la réalisation d'une application utilisant un drone. On dispose ainsi d'un contrôleur de vol (hardware), d'un pilote de vol (software), d'une station de contrôle (typiquement sur ordinateur), et d'une API pour développer notre pilote de vol. Ainsi, on a l'ensemble des outils pour contrôler notre drone, qui fonctionne les uns avec les autres car ils sont entièrement compatibles. | ||
| + | |||
| + | |||
| + | https://www.dronecode.org/about/ | ||
| + | |||
| + | |||
| + | |||
| + | ''Qu'est ce que Ardupilot ?'' | ||
| + | |||
| + | Ardupilot propose un ensemble à la réalisation d'une application d'objet volant, comme Dronecode. Très répandu Ardupilot est utilisé dans plus d'un million d'appareils dans le monde. Il propose aussi une liste d'appareils compatibles et de logiciel permettant le contrôle et le suivi de notre drone. | ||
| + | |||
| + | |||
| + | |||
| + | http://ardupilot.org/about | ||
| − | + | ===Semaine 5=== | |
| − | |||
| − | + | Dans une seconde partie, nous nous sommes concentrés sur les façons d'intéragir avec les valeurs des différents capteurs de l'intel aero. Comme il embarque de nombreux capteurs, ROS semble le plus adapté afin de pouvoir interagir avec les différentes valeurs renvoyés et demandées par nos capteurs. | |
| − | |||
| − | |||
| − | + | ''Qu'est ce que ROS ?'' | |
| − | |||
| − | + | Robot operating system (ROS), est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Le principe de base d’un ROS robotique est de faire fonctionner en parallèle un grand nombre d’exécutables qui doivent pouvoir échanger de l’information de manière synchrone ou asynchrone. Afin de répondre à cette problématique, ROS s’appuie sur plusieurs notions: | |
| − | + | les nœuds: | |
| − | Un topic est un système de transport de l’information basé sur le système de l’abonnement / publication (subscribe / publish). Un ou plusieurs nœuds pourront publier de l’information sur un topic et un ou plusieurs nœuds pourront lire l’information sur ce topic. | + | dans ROS, un nœud est une instance d’un exécutable. Un nœud peut correspondre à un capteur, un moteur, un algorithme de traitement, de surveillance… Chaque nœud qui se lance se déclare au master. |
| − | Les nœuds envoient ou reçoivent des messages sur des topics. | + | |
| + | le master: | ||
| + | le master est un service de déclaration et d’enregistrement des nœuds qui permet ainsi à des nœuds de se connaître et d’échanger de l’information.L’échange de l’information s’effectue soit de manière asynchrone via un topic ou de manière synchrone via un service.Les topics:un topic est un système de transport de l’information basé sur le système de l’abonnement / publication (subscribe / publish). Un ou plusieurs nœuds pourront publier de l’information sur un topic et un ou plusieurs nœuds pourront lire l’information sur ce topic.Les nœuds envoient ou reçoivent des messages sur des topics. | ||
Les Services: | Les Services: | ||
| − | + | le service en revanche répond à celle d’une communication synchrone entre deux nœuds. | |
[[Fichier:Ros.jpg]] | [[Fichier:Ros.jpg]] | ||
| − | |||
===Semaine 6=== | ===Semaine 6=== | ||
| + | |||
| + | Nous avons contacté RS component et Mousser afin de nous renseigner sur la disponibilité du drone. De plus nous avons effectué le bon de commande suivant : | ||
| + | |||
| + | *batterie LiPo 4s 4000mah xt60(taille max 150x50x32 mm) | ||
| + | *le chargeur de la batterie | ||
| + | *un adaptateur micro usb (mâle) - usb (femelle) | ||
| + | *un câble micro hdmi - hdmi (mâle-mâle) | ||
| + | *un câble d'alimentation 12V DC 4A 5.5mm x 2.1mm barrel connector | ||
| + | *un adaptateur xt60 (femelle) - 1x jack 5.5mm (femelle) | ||
| + | *un hub usb 4 ports auto-alimenté | ||
| + | |||
| + | |||
| + | Cependant après avoir contacté Mousser, '''nous nous sommes aperçus que le drone était en fin de vie''' : cela semble être la raison pour laquelle le drone n'était plus disponible chez certain fournisseur. Tout est à refaire, le wiki, le cahier des charges, le positionnement, etc. Nous avons contacté RS component et Mousser afin de nous renseigner sur la disponibilité du drone : il nous a été conseillé de partir sur un autre modèle. | ||
| + | |||
===Semaine 7=== | ===Semaine 7=== | ||
| + | |||
| + | Nous nous sommes rencontrés à de nombreuses reprises avec M. Nakrachi, en fin de journée, afin de trouver une solution le plus vite. Il nous fallait à tout pris un drone 'ready to fly', prêt à voler, et embarquant un module de déveleppoment open source. Pour ce faire, seul les drones avec une carte Pixhawk nous semblait adéquat. Cependant peut de drone 'ready to fly' sont disponibles. Ou ils ne sont plus produit, ou bien la carte a été intégré dans des drones avec du matériel non libre et une carte reprogrammé avec du code propriétaire. | ||
| + | |||
===Semaine 8=== | ===Semaine 8=== | ||
| + | |||
| + | ====Analyse des degrès de liberté du Crazyflie==== | ||
| + | |||
| + | '''Nous sommes parvenus à trouver un nouveau drone : le Crazyflie 2.0'''. Nous avons refait notre wiki en conséquence et ajusté notre cahier des charges. | ||
| + | |||
| + | |||
| + | Tout d’abord, posons le cadre de notre étude. Nous allons étudier un drone à 4 rotors. Nous le représenterons selon le modèle suivant : | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_1.jpg|200px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | Les quadrotors existent sous deux formes : en croix et en plus | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_2.jpg|360px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | Afin de contrôler notre drone, nous allons poser certaines hypothèses quant aux capteurs nous renseignant sur l’état de notre drone en fonction du temps. | ||
| + | |||
| + | |||
| + | '''Hypothèses : nous travaillons avec un quad rotors, configuration en X''' | ||
| + | |||
| + | Au niveau des capteurs, on considère que nous avons : | ||
| + | |||
| + | *Capteurs de distance par ultrasons | ||
| + | *Caméra pour estimer les mouvements (horizontaux) du drone et sa vitesse | ||
| + | *Capteur de pression pour l'altitude | ||
| + | *IMU : Inertial Measurement Unit ; acceleration + gryroscope 3 axes → pour déterminer l'accélération, et l’inclinaison du drone selon les 3 axes du gyroscope | ||
| + | |||
| + | |||
| + | En posant ces hypothèses, nous pouvons analyser notre système de la façon suivante : | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_3.jpg|650px]] | ||
| + | |} | ||
| + | |||
===Semaine 9=== | ===Semaine 9=== | ||
| + | |||
| + | |||
| + | ====Fonctionnent d’un quadcopter – principe de base==== | ||
| + | |||
| + | Afin de pouvoir réaliser un mouvement quelconque avec notre drone, il faut tout d’abord entraîner les moteurs opposés dans le même sens et les deux autres en sens contraire. | ||
| + | Lors de notre étude, nous nous baserons sur le schéma suivant : | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_4.jpg|280px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | Au niveau du repère, nous adopterons une base cartésienne, de centre 0 : | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_5.jpg|140px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | Enfin, nous utiliserons les coupes suivantes : | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_6.jpg|500px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | '''Un drone possède 6 degrés de liberté''' | ||
| + | |||
| + | *Tangage (pitch) – axe Y | ||
| + | *Roulis (roll) – axe X | ||
| + | *Lacet (yaw) – axe Z | ||
| + | *Avant – arrière (foreward/backward) – axe X | ||
| + | *Droite – gauche (rigth/left) – axe Y | ||
| + | *Haut – bas (up/down) – axe Z | ||
| + | |||
| + | |||
| + | ''Schéma des 6 degrés de liberté : '' | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_7.jpg|200px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | Au cours de son vol, le drone est soumis à plusieurs forces : | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_8.jpg|340px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | *la traînée : force formée par le vent relatif, et qui s’oppose au déplacement | ||
| + | *la portance : force formée par l’incidence de la main et qui pousse la main vers le haut | ||
| + | *la traction : force formée par les moteurs induisant un mouvement vers l’avant | ||
| + | *poids : force exercée sur le drone du fait de la force de pesanteur | ||
| + | *l’incidence : angle formée par l’inclinaison de la main par rapport au vent relatif | ||
| + | *force de sustentation : composante verticale des résultantes des forces aérodynamiques s’exerçant sur le drone. | ||
| + | |||
| + | En tournant, les hélices vont engendrer une force de sustentation, qui va compenser le poids du drone. Lorsque cette force dépasse le poids du drone, le quadrocopter s’envole. | ||
| + | |||
===Semaine 10=== | ===Semaine 10=== | ||
| + | '''Après avoir posé notre cade d’étude, passons à l’analyse des mouvements du drone : quelle commande envoyer aux moteurs pour réaliser un mouvement selon un des 6 degrés de liberté ?''' | ||
| + | |||
| + | |||
| + | Tout d’abord, intéressons-nous au '''lacet'''. Il s’agit d’une rotation du drone selon l’axe Z. | ||
| + | Pour ce faire, on augmente la vitesse de deux moteurs tournant dans le même sens. Les deux autres tournent à la même vitesse, mais moins vite. | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_9.jpg|480px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | Ensuite, le drone a la possibilité d’effectuer un '''roulis'''. Il s’agit d’une rotation du drone selon l’axe X. | ||
| + | Pour ce faire, on augmente la vitesse de deux moteurs situés du même côté du drone. Les deux autres tournent à la même vitesse, mais moins vite. | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_10_2.jpg|480px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | De plus, le drone a la possibilité d’effectuer un '''tangage'''. Il s’agit d’une rotation du drone selon l’axe Y. | ||
| + | Pour ce faire, on augmente la vitesse de deux moteurs situés sur l’avant ou l’arrière de notre drone. Les deux autres tournent à la même vitesse, mais moins vite. | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_11.jpg|480px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | Après avoir étudié le tangage, roulis, lacet, étudions le '''mouvement vertical du quadrocopter'''. Par mouvement vertical, nous entendons un mouvement parallèle à l’axe Z, c’est-à-dire la montée en altitude ou la descente du drone. Pour ce faire, on doit augmenter simultanément et de façon égale les quatre moteur pour gagner en altitude et inversement pour redescendre. | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_12.jpg|480px]] | ||
| + | |} | ||
| + | |||
| + | |||
| + | |||
| + | Pour finir, étudions les '''mouvements horizontaux''' du quadrotor. Selon la configuration du drone (en « X »ou en « plus » ), et les stratégies de développement des fonctions de déplacement, ces mouvements se réalisent de plusieurs façons. Typiquement, le drone réalisera un lacet (rotation axe Z) et/ou roulis (rotation axe X), suivi d’un tangage (rotation axe Y) puis utilisera ces fonctions pour suivre une trajectoire rectiligne. | ||
| + | |||
| + | Pour ce faire, on augmente la vitesse d’un moteur et on diminue celle du moteur tournant dans le même sens. Les deux autres moteurs restent à la même vitesse, c’est-à-dire entre la vitesse du moteur que l’on a augmenté et celle du moteur que l’on a diminué. | ||
| + | {| | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_13.jpg|480px]] | ||
| + | | style="border: 1px solid #bbb;" valign="top" |[[Fichier:P21_14.jpg|480px]] | ||
| + | |} | ||
| + | |||
===Semaine 11=== | ===Semaine 11=== | ||
| + | ====Simulation d'un moteur brushless sur Matlab==== | ||
| + | '''Nous nous sommes ensuite consacré à la modélisation d’un moteur brushless de notre Drone.''' | ||
| + | |||
| + | Un moteur brushless de notre drone peut être schématisé de cette manière: | ||
| + | |||
| + | |||
| + | [[Fichier:Moteur-helice.png]] | ||
| + | |||
| + | '''Nomenclature :''' | ||
| + | |||
| + | *U : Tension au borne du moteur | ||
| + | *Rm : Résistance du moteur | ||
| + | *i : courant traversant le moteur | ||
| + | *Lm : inductance | ||
| + | *kfem : coefficient de force électro-motrice | ||
| + | *wh : vitesse de rotation du moteur | ||
| + | *Jm : inertie du moteur | ||
| + | *fem : force électro-motrice | ||
| + | |||
| + | |||
| + | [[Fichier:Capture1.PNG]] | ||
| + | |||
| + | |||
| + | [[Fichier:Capture2.JPG]] | ||
| + | |||
===Semaine 12=== | ===Semaine 12=== | ||
| + | ====Analyse Simulink==== | ||
| + | Grâce à la modélisation faite la semaine d'avant, nous avons pu établir le schéma bloc sur Matlab/Simulink. | ||
| + | |||
| + | Voici le schéma : | ||
| + | |||
| + | [[Fichier:Schéma_bloc.PNG]] | ||
| + | |||
| + | Pour pouvoir étudier la réponse de notre système, nous devons disposer des coefficients nécessaire au fonctionnement du moteur. | ||
| + | |||
| + | [[Fichier:Coeff_et_matlab.PNG]] | ||
| + | |||
| + | Nous fixerons donc le point de fonctionnement I0, qui est le courant d’entrée du moteur, pour pouvoir obtenir les autres points de fonctionnement U0 et omega0. | ||
| + | Il faut savoir que l’on a pris à 2,5A qui est une valeur choisis arbitrairement avec comme contrainte la valeur max du courant 4,2A et la valeur min de démarrage du moteur qui est de 0,8A. | ||
| + | En consigne, nous lui envoyons une vitesse (200 rad/s « arbitrairement ») et voici la vitesse du moteur en sortie: | ||
| + | |||
| + | [[Fichier:RésultatWenGros.PNG]] | ||
| + | |||
| + | [[Fichier:RésultatWzoomer.PNG]] | ||
| + | |||
| + | |||
| + | On remarque que notre système est en régime apériodique donc que son coefficient d’amortissement est supérieur à 1. | ||
| + | Il a un temps de réponse de 1,95s et un temps de monté 1,43s car on a la période qui vaut environ 0,65s (étude du schéma selon une réponse indicielle d’un système apériodique qui ressemble à celui d’un premier ordre). | ||
| + | Nous étudierons par la suite le système motorisé complet du moteur pour pouvoir asservir correctement les moteurs pour la deuxième année. Nous avons pour l'instant étudié qu'un seul moteur du drone. | ||
| + | |||
| + | ===Maquette=== | ||
| + | |||
| + | Afin de mettre en pratique le comportement des moteurs, nous avons réaliser une maquette. Pour ce faire : | ||
| + | |||
| + | 1) nous avons assemblé le crazyflie, comme indiqué sur le site suivant : | ||
| + | |||
| + | https://www.bitcraze.io/getting-started-with-the-crazyflie-2-0/ | ||
| + | |||
| + | 2) ensuite, nous avons téléchargé l'application Crazyflie Client pour android : | ||
| + | |||
| + | https://play.google.com/store/apps/details?id=se.bitcraze.crazyfliecontrol2&hl=fr | ||
| + | |||
| + | 3) on règle les paramètres de l'application de la façon suivante : | ||
| + | |||
| + | [[Fichier:mode_pour_les_controles.png|540px]] | ||
| + | |||
| + | [[Fichier:parametres_p21.png|540px]] | ||
| + | |||
| + | 4) on fixe le drone sur une planche de bois, de taille 12x18cm à l'aide de 4 trombones. | ||
| + | Astuce : tordre les 4 trombones de sortes à enrouler avec un crochet les supports moteurs et de l'autre côté ressérer la planche avec une forme de L. | ||
| + | |||
| + | [[Fichier:maquette_p21.jpg|360px]] | ||
| + | |||
| + | NOTE 1 : nous avons marqué l'avant de notre drone avec un peu de rouge, car de loin, il nous est difficle de repérer l'avant du drone | ||
| + | |||
| + | NOTE 2 : notre montage nous permet d'observer, seulement, de manière qualitatif le comportement des moteurs, en effet, nous ne disposons pas d'informations temps-réels sur l'état des moteurs (vitesse, température etc.). | ||
| + | |||
| + | |||
| + | 5) on envoie les commandes aux moteurs à l'aide de l'application | ||
| + | Afin de bien lire les captures d'écran, faire attention à la ligne "P : R : T : Y : ", situé au milieu de l'écran, ces lettres correpondent respectivement à : Pitch (tangage), Roll (roulis), Thrust (poussée), Yaw (lacet). | ||
| + | |||
| + | 5.1) un lacet (rotation axe Z) dans un sens : | ||
| + | |||
| + | [[Fichier:Lacet_yaw_sens1.png|360px]] | ||
| + | |||
| + | puis dans l'autre : | ||
| + | |||
| + | [[Fichier:Lacet_yaw_sens2.png|360px]] | ||
| + | |||
| + | |||
| + | 5.2) un déplacement horizontal dans un sens | ||
| + | |||
| + | [[Fichier:horizontal_sens1.png|360px]] | ||
| + | |||
| + | un déplacement horizontal dans un autre sens : | ||
| + | |||
| + | [[Fichier:horizontal_sens2.png|360px]] | ||
| + | |||
| + | |||
| + | Pour finir, on obtient : | ||
| + | |||
| + | [[Fichier:capture_horizontal_sens1.png|360px]] | ||
| + | |||
| + | ''commande moteur pour effectuer un déplacement horizontal'' | ||
| + | |||
| + | [[Fichier:capture_horizontal_sens2.png|360px]] | ||
| + | |||
| + | ''commande moteur pour effectuer un déplacement horizontal'' | ||
| + | |||
| + | [[Fichier:capture_lacet_yaw_sens1.png|360px]] | ||
| + | |||
| + | ''commande moteur pour effectuer un lacet - sens 1'' | ||
| + | |||
| + | [[Fichier:capture_lacet_yaw_sens2.png|360px]] | ||
| − | + | ''commande moteur pour effectuer un lacet - sens 2'' | |
==Projet S7== | ==Projet S7== | ||
| − | === | + | ===Semaine 1=== |
| + | |||
| + | ====Objectifs du semestre 7==== | ||
| + | |||
| + | |||
| + | Cette semaine a été l'occasion pour nous de définir les objectifs de notre projet pour le semestre 7. Nous utilisons le Crazyflie 2.0, ainsi que le flow deck et l'antenne USB crazyradio. | ||
| + | |||
| + | Nous allons lors de ce semestre envoyer à notre drone des premières commandes Python en utilisant les librairies cflib. Nous allons aussi expliquer le fonctionnement des différents capteurs qui vont intervenir lors de la réalisation de notre projet. Le but final ést d'effectuer un vol autonome d'un point A à un point B en évitant les obstacles. | ||
| + | |||
| + | |||
| + | |||
| + | Voici les capteurs que nous allons étudier : | ||
| + | |||
| + | |||
| + | Flow deck v2 : | ||
| + | https://www.bitcraze.io/flow-deck-v2/ | ||
| + | |||
| + | Multi-ranger deck : | ||
| + | https://www.bitcraze.io/multi-ranger-deck/ | ||
| + | |||
| + | Loco Positioning system : | ||
| + | https://www.bitcraze.io/loco-pos-system/ | ||
| + | |||
| + | Loco Positioning deck : | ||
| + | https://www.bitcraze.io/loco-pos-deck/ | ||
| + | |||
| + | Loco Positioning node : | ||
| + | https://www.bitcraze.io/loco-pos-node/ | ||
| + | |||
| + | |||
| + | |||
| + | Par ailleurs, nous utilisons aussi : | ||
| + | |||
| + | |||
| + | Antenne USB Crazyradio PA : | ||
| + | https://www.bitcraze.io/crazyradio-pa/ | ||
| + | |||
| + | Battery charger : | ||
| + | https://www.bitcraze.io/battery-charger-500mA/ | ||
| + | |||
| + | |||
| + | |||
| + | Enfin, nous allons expliquer le fonctionnement des bibliothèques Python cflib, et plus précisément la mise en place de l'environnement de développement sous machine virtuelle, la mise à jour du drone et l'envoie de code Python à notre drone via l'antenne USB Crazyradio PA. | ||
| + | |||
| + | |||
| + | Cflib : | ||
| + | https://github.com/bitcraze/crazyflie-lib-python | ||
| + | |||
| + | ===Semaine 2=== | ||
| + | |||
| + | |||
| + | ==== Capteur Multi-ranger deck ==== | ||
| + | ---- | ||
| + | |||
| + | [[Fichier:Multi-ranger_deck.jpg|200px]] | ||
| + | |||
| + | '''Introduction''' | ||
| + | |||
| + | Le Multi-ranger deck est un module contenant 5 capteurs lasers (haut, gauche, droite, avant, arrière) qui se fixe sur le dessus du drone. Il permet au drone Crazy-Flie de détecter des objets à proximité jusqu’à 4 mètres.Grâce à ce module et le Flow deck (capteur du dessous) le drone peut évoluer dans l’espace en détectant les éventuels obstacles. Ses 5 capteurs de distance IR sont les mêmes que celui présent sur le Flow Deck, il s’agit du VL53L1x ToF de chez STMicroelectronics®. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | '''Fonctionnement''' | ||
| + | |||
| + | La mesure de distance est basée sur le principe de la triangulation : | ||
| + | |||
| + | |||
| + | Le rayon laser atteint l’objet sous la forme d’un petit point. L’impact du rayon laser sur l’objet est matérialisé sous la forme d’un petit point. Le récepteur du détecteur (ligne de photodiodes) détecte la position de ce point. En fonction de la distance, l’angle d’incidence varie et également la position du point laser sur le récepteur. La ligne de photodiodes est analysée par microcontrôleur intégré. Selon la répartition de la lumière sur la ligne de photodiodes, le contrôleur est en mesure de calculer la valeur de l’angle d’incidence et, en se référant à cette valeur, de déterminer la distance par rapport à l’objet. Cette distance est alors transférée soit vers un port de communication série soit transformée en un courant de sortie proportionnel à la distance. | ||
| + | Les capteurs lasers sur le Multi-ranger deck sont des multi-spots (Mesures stables sur surfaces non uniformément brillantes et extrêmement rugueuses de plus de 600 valeurs avec une ligne laser extra longue < 72 mm). Le signal reçu est traité grâce au DSP(Digital Signal Processeur) intégré dans le microcontrôleur (Cortex-M4). | ||
| + | |||
| + | |||
| + | |||
| + | Source (plus d'information sur la triangularisation) : | ||
| + | |||
| + | https://www.baumer.com/ch/fr/service-assistance/savoir-faire/fonctionnement/le-fonctionnement-et-la-technologie-des-detecteurs-de-distance-optiques/a/Know-how_Function_optical-distance-sensors | ||
| + | |||
| + | ====Loco Positioning System==== | ||
| + | ---- | ||
| + | |||
| + | |||
| + | '''Intérêt de ces capteurs :''' | ||
| + | |||
| + | Jusqu’à maintenant, nous n'avons toujours programmé le drone en position relative, c'est-à-dire que le drone ne se repérer pas dans l'espace par rapport à un repère fixe dans l'espace, mais seulement par rapport à sa position précédente. Pour le localiser nous pouvons utiliser un GPS, mais le crazyflie étant un petit drone d'intérieur, il est difficile de le localiser avec un GPS. Pour ce faire, il faut utiliser un réseau de capteurs pour la localisation "in door" (en intérieur) de notre drone. | ||
| + | |||
| + | |||
| + | '''Constitution du système:''' | ||
| + | |||
| + | Le Loco Positioning system permet donc de trouver la la position absolue du drone dans l’espace. La base de ce système est composé d’un ensemble "d’ancrages" réparties dans la pièce. L’autre partie du système correspond à une ou plusieurs balises fixés sur le drone , appelés "Tags". | ||
| + | |||
| + | |||
| + | '''Principe de fonctionnement :''' | ||
| + | |||
| + | Le système envoie par radiofréquence des messages court entre les Ancrages et les Tags placés dans la pièce. Le système peut donc ensuite mesurer la distance entre chaque Ancrage et Tag et ainsi déterminer la position du drone dans la pièce. Pour évaluer cette distance entre les Ancrages et les Tags, différents protocoles peuvent être utilisés. | ||
| + | |||
| + | |||
| + | ''Protocoles utilisables avec le Crazyflie :'' | ||
| + | |||
| + | https://www.bitcraze.io/loco-pos-system/ | ||
| + | |||
| + | https://archive.fosdem.org/2017/schedule/event/loco_positioning_crazyflie/attachments/slides/1734/export/events/attachments/loco_positioning_crazyflie/slides/1734/FOSDEM17__Loco_positioning_system.pdf | ||
| + | |||
| + | ''Principe et algorithmes : '' | ||
| + | |||
| + | https://www.linuxembedded.fr/2018/06/la-localisation-indoor-2/ | ||
| + | |||
| + | |||
| + | '''Le Loco Positioning Deck:''' | ||
| + | |||
| + | Le Loco Positioning Deck est une expansion de la plateforme du Crazyflie 2.X qui réalise la fonctionnalité du Tag dans le Loco Positioning System. | ||
| + | |||
| + | [[Fichier:Deck.jpg|200px]] | ||
| + | |||
| + | |||
| + | '''Le Loco Positioning Node:''' | ||
| + | |||
| + | Le Loco Positioning Node est un nœud Multi fonctionnel dans un Loco Positioning system, qui peut occuper la fonction de Tag ou d’Ancrage, donc être fixé sur le drone ou être réparti dans la pièce. | ||
| + | [[Fichier:Node.jpg|200px]] | ||
| + | |||
| + | ====Capteur Flow Deck V2 : VL53L1x ToF + PMW3901==== | ||
| + | ---- | ||
| + | Le flow deck V2 est une petite carte électronique que nous venons placer en dessous du drone. | ||
| + | |||
| + | [[Fichier:Photo_flow_deck_v2.jpg|200px]] | ||
| + | |||
| + | Cette carte permet d'évaluer la distance du drone par rapport au sol et d'obtenir sa position relative. Elle est composée de deux capteurs : le VL53L1x ToF de chez STMicroelectronics®, et le capteur optique PMW3901 de chez PixArt®. | ||
| + | |||
| + | |||
| + | Le capteur VL53L1x ToF mesure la distance entre le drone et le sol. Il envoie un laser invisible à l'oeil nu de longeur 940nm (capteur IR), et calcul le temps qu'il met pour revenir à la base. | ||
| + | |||
| + | [[Fichier:Module_distance_flow_deck_v2.png|200px]] | ||
| + | |||
| + | |||
| + | Il possède les caractéristiques suivantes : | ||
| + | |||
| + | |||
| + | • Taille : 4.9x2.5x1.56 mm | ||
| + | |||
| + | • Longueur d'onde : 940 nm | ||
| + | |||
| + | • Fréquence : 50 Hz | ||
| + | |||
| + | • Distance max de mesure : 4 mètres | ||
| + | |||
| + | Ce capteur mesure la distance sur le principe de triangularisation, pour plus de détails, voir la partie « Multi-ranger deck | ||
| + | |||
| + | |||
| + | Datasheet : | ||
| + | |||
| + | https://www.st.com/content/ccc/resource/technical/document/datasheet/group3/7d/85/c8/95/fb/3b/4e/2d/DM00452094/files/DM00452094.pdf/jcr:content/translations/en.DM00452094.pdf | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | |||
| + | Le capteur optique PMW3901 utilise la méthode de flux optique pour déterminer la direction dans laquelle se déplace le drone. | ||
| + | |||
| + | |||
| + | Il possède les caractéristiques suivantes : | ||
| + | |||
| + | |||
| + | • Taille : 6x6x2.28 mm | ||
| + | |||
| + | • Distance minimale pour fonctionner : 80mm (du à la distance focale de la lentille de la caméra) | ||
| + | |||
| + | |||
| + | |||
| + | Fonctionnement : | ||
| + | |||
| + | Tout d'abord on a une petit laser qui va éclairer en permanence le sol. En parallèle une minuscule caméra va prendre en photo le sol qui est pointé par le laser. Ensuite un microprocesseur compare les clichés entre eux et arrive à estimer la direction et la vitesse de déplacement du drone. C'est exactement le même fonctionnement que l'on retrouve dans les souris d'ordinateur, en les retournant, on peut apercevoir une petite lumière rouge. La caméra a une très faible définition, dans l'ordre de 8x8 pixels, 16x16... etc | ||
| + | |||
| + | |||
| + | Par exemple, si on considère l'exemple suivant : | ||
| + | |||
| + | |||
| + | [[Fichier:Opticalflow.png|600px]] | ||
| + | |||
| + | |||
| + | Si on considère par exemple que le flow deck analyse les images 5 par 5, et que chaque cliché est pris dans une période de T = 100ms. En combinant les images 5 par 5, on peut observer que le drone s'est déplacé vers la droite à une vitesse de (x0 - x4) / 5*T selon l'axe X et( y0 - y5) / 5*T selon l'axe Y. | ||
| + | |||
| + | |||
| + | Datasheet : | ||
| + | |||
| + | https://wiki.bitcraze.io/_media/projects:crazyflie2:expansionboards:pot0189-pmw3901mb-txqt-ds-r1.00-200317_20170331160807_public.pdf | ||
| + | |||
| + | ===Semaine 3=== | ||
| + | |||
| + | ====Mise en place de l'environnement de développement du Crazyflie.==== | ||
| + | ---- | ||
| + | |||
| + | |||
| + | |||
| + | Matériels utilisés : | ||
| + | |||
| + | - 1x drone Crazyflie | ||
| + | |||
| + | Assemblage : https://www.bitcraze.io/getting-started-with-the-crazyflie-2-0/ | ||
| + | |||
| + | - 1x Bitcraze Flow Deck | ||
| + | |||
| + | Branchement : https://www.bitcraze.io/getting-started-with-expansion-decks/ | ||
| + | |||
| + | Fonctionnement : https://www.bitcraze.io/getting-started-with-flow-deck/ | ||
| + | |||
| + | - 1x Bitcraze Crazyradio PA | ||
| + | |||
| + | |||
| + | Système d’exploitation pour installer la machine virtuelle : | ||
| + | |||
| + | - Windows 7, 8, et 10 (tutoriel dans ce PDF) | ||
| + | |||
| + | - L’environnement peut être mis en place aussi sur Linux et OS X, avec ou sans machine virtuelle (non traités ici) | ||
| + | |||
| + | |||
| + | Ressources nécessaires : | ||
| + | |||
| + | - La machine virtuelle tourne sous Xubuntu et utilise au minimum 1Go de Ram et 1 Thread | ||
| + | |||
| + | - Configuration minimale que nous recommandons pour la machine hôte : 6Go de Ram et un CPU à 4 threads (on allouera 2 Go de RAM et 2 threads à notre machine virtuelle) | ||
| + | |||
| + | |||
| + | Documentation : | ||
| + | |||
| + | - Site internet : https://www.bitcraze.io/getting-started-with-the-crazyflie-2-0/ | ||
| + | |||
| + | - Wiki : https://wiki.bitcraze.io/ | ||
| + | |||
| + | - Forum : https://forum.bitcraze.io/ | ||
| + | |||
| + | - Github : https://github.com/bitcraze | ||
| + | |||
| + | - Pour utiliser PX4, Betaflight, ROS… etc : https://www.bitcraze.io/external-projects/ | ||
| + | |||
| + | - Blog , nouveauté, travaux de recherche, etc. : https://www.bitcraze.io/blog/ | ||
| + | |||
| + | |||
| + | =====Téléchargement===== | ||
| + | ---- | ||
| + | |||
| + | 1.1. Téléchargement de VirtualBox | ||
| + | |||
| + | Télécharger l’exécutable et le pack d’extension de VirtualBox : | ||
| + | |||
| + | VirtualBox 6.0.12 platform packages > Windows hosts | ||
| + | |||
| + | VirtualBox 6.0.12 Oracle VM VirtualBox Extension Pack > All supported platforms | ||
| + | |||
| + | https://www.virtualbox.org/wiki/Downloads | ||
| + | |||
| + | |||
| + | 1.2. Téléchargement de la machine virtuelle de Bitcraze | ||
| + | |||
| + | Télécharger la dernière version sur le GitHub de Bitcraze | ||
| + | |||
| + | Bitcraze VM 2018.12 > Download link (2.9Gb) | ||
| + | |||
| + | https://github.com/bitcraze/bitcraze-vm/releases/ | ||
| + | |||
| + | |||
| + | 1.3. Téléchargement du driver de l’antenne USB Bitcraze Radio PA | ||
| + | |||
| + | Aller dans la partie « Download » un peu plus bas : | ||
| + | |||
| + | Updated 2018.07.26 > Zadig 2.4 (4.9Mb) | ||
| + | |||
| + | https://zadig.akeo.ie/ | ||
| + | |||
| + | =====Installation===== | ||
| + | ---- | ||
| + | |||
| + | 2.1. Installation de VirtualBox et du pack d’extension | ||
| + | |||
| + | 1) Installer VirtualBox : il faut les privilèges administrateurs | ||
| + | On clique sur "VirtualBox.... .exe" (laisser les paramètres par défaut si pas de raison particulière pour les changer) | ||
| + | |||
| + | 2) Ajouter le pack d’extension : il faut les privilèges administrateurs* | ||
| + | NOTE : pour utiliser la machine virtuelle, nous n’avons pas besoin des privilèges administrateurs, il les faut juste lors de l’installation du logiciel et du pack d’extension | ||
| + | |||
| + | Tout d’abord lancer VirtualBox en tant qu’administrateur : | ||
| + | |||
| + | Dans VirtualBox, cliquer sur Fichier > Paramètres > Extensions > "Symbole +" et choisir le pack d'extension | ||
| + | Ensuite parcourir l’arborescence des fichiers jusqu’au répertoire contenant le pack d’extension que l’on a téléchargé | ||
| + | |||
| + | |||
| + | 2.2. Installation du driver pour l’antenne radio USB | ||
| + | |||
| + | 1) Brancher l'antenne sur le port USB | ||
| + | |||
| + | 2) Attendre le message d'erreur de Windows disant qu'il ne trouve par le driver | ||
| + | |||
| + | Note : parfois aucun message n’apparaît, mais cela n’est pas grave | ||
| + | |||
| + | 3) Quitter le message disant « Windows n’a pas pu trouver le driver » | ||
| + | |||
| + | 4) Laisser brancher l'antenne sur le port USB ! | ||
| + | |||
| + | 5) Cliquer sur "zadig-2.4.exe" : il faut les privilèges administrateurs | ||
| + | |||
| + | 6) Une fenêtre apparaît, on doit voir écrit "Crazyradio USB Dongle" | ||
| + | |||
| + | 7) Sélectionner "linusb-win32 (v1.2.6.0)" (important : bien choisir cette version !) | ||
| + | |||
| + | 8) Et cliquer sur installer | ||
| + | |||
| + | |||
| + | |||
| + | 2.3. Installation de la machine virtuelle sous VirtualBox et configuration | ||
| + | |||
| + | 1) On ouvre VirtualBox (plus besoin d’être administrateur), puis on clique sur "Importer" et ensuite on choisit la VM que l'on a téléchargé | ||
| + | On laisse tous les paramètres par défaut " (sauf si on a une raison particulière pour les changer) | ||
| + | |||
| + | 2) Cliquer sur la nouvelle fenêtre « BitcrazeVM » et ensuite sur « Configuration » | ||
| + | |||
| + | Cliquer sur configuration > USB > "Symbole plus" > Bitcraze Crazyradio PA USB Dongle" | ||
| + | Si on doit ajouter une manette USB, il faut aussi l'ajouter | ||
| + | |||
| + | ===Semaine 4 - Chorégraphie=== | ||
| + | '''Déplacement selon les 6 degrés de liberté (chorégraphie)''' | ||
| + | |||
| + | Dans un premier temps, nous avons mis en place une chorégraphie retraçant les 6 degrés de liberté du drone. A tour de rôle, le drone va effectuer un mouvement selon l’un de ses 6 degrés de liberté.Cela nous a permis de prendre en main la librairie cflib. | ||
| + | |||
| + | |||
| + | Nous avons pu aussi apporter un regard critique sur notre code. En effet nous avons remarqué que lors de l’utilisation de structure trop complexe, le drone recevait trop tard ses instructions, entrainant des mouvements saccadés. De plus la lecture des différents capteurs met du temps à retourner la valeur. | ||
| + | |||
| + | |||
| + | En travaillant par scrutation, cela doit être pris en compte et il faut bien choisir à quel moment lire la valeur des capteurs retournés par le drone. Nous avons utilisé la fonction send_hover_setpoint. Par exemple : | ||
| + | |||
| + | |||
| + | '''Décollage : on augmente progressivement l'altitude.''' | ||
| + | On définit l'altitude à atteindre (la consigne) et le pas de boucle, c'est-à-dire l'incrément qui va nous permettre d'atteindre l'altitude consigne. | ||
| + | |||
| + | definir : decollage(pas_de_boucle) | ||
| + | consigne <- 0.4m | ||
| + | pas_de_boucle <- 1/consigne * 10 | ||
| + | Pour i allant de 0 à 10 : | ||
| + | altitude <- i/pas_de_boucle | ||
| + | attendre 100ms | ||
| + | Fin Pour | ||
| + | |||
| + | |||
| + | Par la suite, nous allons nous servir de ces algorithmes pour définir des fonctions de déplacement vers la gauche, droite, l’avant, l’arrière... qui seront réutilisés tout au long du projet pour le déplacement du drone. | ||
| + | |||
| + | |||
| + | Le fait de définir nos propres fonctions de déplacement au lieu d'utiliser celles fournies dans les librairies cflib, nous permettent de mieux paramétrer nos déplacement (par exemple un décollage plus doux), mais surtout de pouvoir intérrompre directement nos mouvement en cas de détection d'un obstacle. '''Nous gérons directement l'évaluation de l'obsatcle au cours du déplacement''', par exemple : | ||
| + | |||
| + | |||
| + | definir : mouvement_gauche(vitesse, temps, altitude) | ||
| + | y<=0 | ||
| + | tant que y < 10*temps | ||
| + | Si est_proche(capteur_gauche) alors | ||
| + | retourner -1 | ||
| + | Fin Si | ||
| + | send_hover_setpoint(vitesse,0,0,altitude) | ||
| + | attendre 100ms | ||
| + | Fin tant que | ||
| + | retourner 0 | ||
| + | |||
| + | vitesse en m/s, temps en seconde, altitude en mètre | ||
| + | |||
| + | |||
| + | La fonction '''send_hover_setpoint(vx, vy, yawrate, zdistance)''' prends en paramètre : | ||
| + | |||
| + | *vx : vitesse de déplacement horizontale selon l’axe X (m/s) | ||
| + | *vy : vitesse de déplacement horizontale selon l’axe Y (m/s) | ||
| + | *yawrate : vitesse de rotation selon l’axe Z (degrés/s), sens positif = sens horaire | ||
| + | *zdistance : altitude à atteindre en vol (mètre) | ||
| + | |||
| + | |||
| + | |||
| + | Après avoir défini nos 6 fonctions de déplacement, nous obtenons le résultat suivant : | ||
| + | |||
| + | [[File:VIDEO1_P21.mp4]] | ||
| + | |||
| + | ===Semaine 5=== | ||
| + | |||
| + | Dans cette partie, on définit 6 fonctions de déplacement qui décrivent les mouvements suivants : décollage, atterrissage, gauche, droite, avant , arrière. Pour ce faire, on utilise les algorithmes définis dans la section « Déplacement selon les 6 degrés de liberté ». Ces fonctions prennent en paramètre une vitesse, un temps d’exécution, et une altitude. Par exemple, si on veut se déplacer de 30 centimètres sur la gauche, on fera appel à la fonction gauche(0.3 , 1 , 0.5). La fonction gauche a pour prototype gauche(vitesse, temps, altitude). La vitesse est un entier strictement positif, exprimé en m/s, le temps est un entier positif exprimé en seconde, et enfin l’altitude est exprimée en mètre. Ainsi, gauche(0.3 , 1, 0.5), déplacera le drone à une vitesse de 0.3m/s pendant une 1 seconde à une altitude de 0.5 mètre. | ||
| + | Dans un seconde temps, on définit la fonction is_close(entier x) qui retourne un booléen. Elle renvoie True si x est inférieur à notre seuil, False si non. X est un entier positif exprimé en mètre. Le seuil est la distance à partir de laquelle on doit éviter l’obstacle. Par exemple, nous avons défini notre seuil à 20 centimètres : si un objet se situe à 20 centimètres au plus de notre objet, alors il est considéré comme un obstacle et on doit ainsi l’éviter. | ||
| + | |||
| + | Une fois que nous avons défini les fonctions de déplacement et notre fonction is_close(), nous les utilisons dans une boucle infinie qui correspond à la séquence de vol de notre drone. Ici, pour notre étude, nous allons considérer que notre drone est en vol stationnaire (c’est-à-dire qu’il reste à une altitude constante sans se déplacer dans aucune direction) pendant une durée indéterminée. '''Au cours de son vol, s’il détecte un obstacle, il se déplace automatiquement de 30 centimètres dans le sens opposé.''' Au cours du vol nous enregistrons les valeurs des capteurs dans tableaux. | ||
| + | |||
| + | |||
| + | |||
| + | Dans un premier temps, voici les valeurs des capteurs d’altitude et de hauteur en fonction du temps lors de la session de test. Le capteur d’altitude est un capteur évaluant la distance entre le sol et le drone. Le capteur de hauteur est en fait un capteur évaluant la distance entre le drone et les objets situés au-dessus du drone. | ||
| + | |||
| + | |||
| + | [[Fichier:GRAPHIQUE1.jpg|500px]] | ||
| + | |||
| + | |||
| + | Ensuite, nous plaçons plusieurs obstacles sur la gauche du drone de manière répétée. Nous observons que le drone détecte un obstacle, puis s’en éloigne, jusqu’à ce qu’un nouvel obstacle survienne et ainsi de suite. | ||
| + | |||
| + | |||
| + | [[Fichier:GRAPHIQUE2.jpg|500px]] | ||
| + | |||
| + | |||
| + | Pour finir, nous plaçons des objets à l’arrière du drone à plusieurs intervalles de temps. Là encore, nous observons que le drone détecte l’obstacle, puis s’en éloigne, et ainsi de suite. | ||
| + | |||
| + | |||
| + | [[Fichier:GRAPHIQUE3.jpg|500px]] | ||
| + | |||
| + | ===Semaine 6 et Semaine 7=== | ||
| + | |||
| + | Dans la section précédente, nous avons établi un algorithme permettant d’éviter un obstacle lorsque le drone était en vol stationnaire. Maintenant, nous allons supposer que le drone effectue un mouvement rectiligne uniforme vers l’avant pendant une durée indéterminée. Au cours de son vol, s’il détecte un obstacle vers l’avant, il doit pouvoir le contourner, et reprendre le cours de son vol, sur le même axe rectiligne, selon une vitesse constante. Pour ce faire, nous devons implémenter un algorithme permettant de détecter l’obstacle, de l’éviter, puis de le franchir, et enfin revenir sur le même axe que précédemment. Par la suite, nous allons présenter l’idée générale de l’algorithme que nous avons implémenté. | ||
| + | |||
| + | |||
| + | [[Fichier:IMAGE GENERALE2.jpg|500px]] | ||
| + | |||
| + | |||
| + | Nous obtenons le résultat suivant : | ||
| + | |||
| + | |||
| + | |||
| + | [[File:VIDEO2.mp4]] | ||
| + | |||
| + | ===Bonus=== | ||
| + | |||
| + | Afin de protéger notre drone lors de la programmation des algorithmes d'évitement d'obstacle nous avons imprimé des protections d'hélices au Fabricarium. | ||
| + | |||
| + | |||
| + | [[Fichier:IMAGE3.jpg|360px]] | ||
| + | |||
| + | |||
| + | ''Sources :'' | ||
| + | |||
| + | https://www.thingiverse.com/thing:2554194 | ||
| + | |||
| + | https://www.thingiverse.com/thing:1151252 | ||
| + | |||
| + | ===Bilan et perspective pour le semestre 8=== | ||
| + | |||
| + | '''Au cours du semestre 8, notre travail va se concentrer sur la mise en place d'un réseau de capteurs de localisation d'intérieur "in door".''' En effet, jusqu'à présent nous avons utilisé la position relative du drone pour le programmer (c'est-à-dire que le repère était situé au niveau du centre de gravité de celui-ci). Avec le réseau de capteurs "Loco Positionning System", nous aurons un repère cartésien fixe, ancré dans la salle, et le drone sera assimilé à un point se déplaçant dans le repère fixe. | ||
| + | |||
| + | |||
| + | Enfin, pour résumer, au cours du semestre 7 nous avons redoublé d'efforts afin de pouvoir avoir un drone apte à évoluer dans le réseau de capteurs que nous allons mettre en place au S8. En effet, nous avons seulement reçu tout le matériel en septembre 2019, nous avons donc dû anticiper tout la partie capteur d'obstacle et programamtion, afin d'être prêt pour le S8. Nous avons fait, entre autres : | ||
| + | |||
| + | |||
| + | 1) '''Mise en place de l'environnement de développement''' sous machine virtuelle : c'est le seul outil qui contient tous les logiciels et drivers à jour. Nous aurions pu directement mettre en place cet environnement sous Windows mais nous aurions eu certains programmes non mis à jour. | ||
| + | |||
| + | |||
| + | 2) Documentation sur les librairies cflib : nous sommes rendus compte qu'il fallait '''programmer nos propres fonctions de déplacement''' afin de mieux contrôler le mouvement du drone et d'évaluer les capteurs de distance directement lors de son déplacement | ||
| + | |||
| + | |||
| + | 3) '''Mise en place d'un alogrithme d'évitement d'obstacle''' : nous avons vu que les capteurs mettent un temps non négligeable pour envoyer leur valeur au PC, aussi il est important de ne pas scruter trop régulièrement l'état des capteurs sous peine de perdre le contrôle du drone. En effet, le drone fonctionne seulement quand on lui envoie des commandes, si à t=0 on lui donne une consigne en vitesse, à t+t1, il faut lui renvoyer cette consigne pour qu'il continue à l'exécuter... Si t1 est trop grand, alors le temps entre la 1ere consigne et la 2eme sera trop grand, et on aura un dela t pendant lequel le drone ne recevra pas de consigne, les moteurs se coupent et il crash. | ||
| + | |||
| + | |||
| + | 4) Après avoir pris en compte les contraintes temporelles présentées en 3), nous nous sommes servies des fonctions de déplacement définies en 2) pour proposer un '''premier algorithme de contournement d'obstacle'''... Cependant il reste encore beaucoup de travail à effectuer là-dessus. En effet se reposer entièrement sur la valeur des capteurs peut poser problème quand l'obstacle n'est pas régulier. De plus notre alogrithme définit seulement un contournement vers la droite, qu'en est-il si un obstacle se trouve également sur la droite ? | ||
==Projet S8== | ==Projet S8== | ||
| + | ===Objectifs du semestre 8=== | ||
| + | |||
| + | '''Le premier objectif du projet''' était de comprendre le fonctionnement d'un quadcopter : par l'intermédiaire de simulation Matlab, de schéma que nous avons mis sur le wiki et par confirmation avec nos expérimentations sur une maquette, cet objectif a été rempli au cours du semestre 6. | ||
| + | |||
| + | |||
| + | '''Le second objectif du projet''' était de pouvoir programmer des algorithmes de déplacement pour que le drone se déplace d'un point A à un point B : à travers nos 3 codes python, nous avons fait déplacer le drone selon ses 6 degrés de liberté (chorégraphie), nous l'avons fait éviter les obstacles, et enfin nous avons réussi à le faire contourner les obstacles (cf. vidéos et schémas sur le wiki). | ||
| + | |||
| + | |||
| + | '''Semestre 8 : ''' nos objectifs étant atteints, nous avons défini une nouvelle orientation pour notre projet. Lors de notre soutenance à la fin du S7, on nous a conseillé de creuser un peu plus dans l'architecture matérielle et logicielle du drone afin de mieux comprendre son fonctionnement et éviter l'utilisation d'un PC et de lib python pour faire voler le drone. Ce ne sont pas des fonctionnalités disponibles par défaut sur le drone, mais son code source étant open source, nous allons essayer de nous pencher dessus pour voir s'il y a quelque chose à faire dans ce sens-là. De plus nous allons mettre en place un réseau de capteur nous permettant de localiser la position de notre drone par rapport à un repère fixe cartésien (x,y,z). | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | ===Architecture matérielle=== | ||
| + | |||
| + | |||
| + | [[Fichier:materielle_p21.png|900px]] | ||
| + | |||
| + | |||
| + | Le Crazyflie est constitué des composants suivants : | ||
| + | |||
| + | *STM32F405: Cortex-M4, 168 MHz, 192 kB SRAM, 1 MB flash | ||
| + | *nRF51822: Cortex-M0, 32 MHz, 16 kB SRAM, 128 kB flash | ||
| + | *MPU-9250: centrale à inertie 9 axes (IMU) | ||
| + | *LPS25H: capteur de pression | ||
| + | *8 kB EEPROM. | ||
| + | *port micro USB | ||
| + | *ports d’ expansion : I2C, UART, SPI, GPIO | ||
| + | |||
| + | |||
| + | '''Le nRF51''' | ||
| + | |||
| + | Le nRF51 contient un Cortex-M0, 16kB de RAM et 256kB de Flash, qui lui permettent de gérer la communication radio et la gestion d’alimentation du drone. Cependant il n’est pas assez puissant pour faire tourner les algorithmes de contrôle de vol du drone. | ||
| + | |||
| + | |||
| + | '''Le STM32F405''' | ||
| + | |||
| + | Le STM32F405 est composé d’un Cortex-M4, de 196kB de RAM et de 1MB de Flash. Le cortex M4 lui permet de faire des calculs puissants, d’exécuter des algorithmes pour contrôler son vol. | ||
| + | |||
| + | |||
| + | '''Protocoles de communication''' | ||
| + | |||
| + | Le nRF51 permet de communiquer avec le drone par Bluetooth et par CRTP (Crazy RealTime Protocol). Le Bluetooth sert à contrôler le drone via l’application smartphone développée par le constructeur. Le CRTP, Crazy RealTime Protocol, est un protocole de communication qui permet de communiquer entre une antenne, la CrazyRadio PA, et le drone, en 2,4GHz. La CrazyRadio PA est une antenne que l’on branche en USB sur notre PC. | ||
| + | |||
| + | |||
| + | '''Rôles des microcontrôleurs''' | ||
| + | |||
| + | Le nRF51 et le STM32 communiquent entre eux par UART. Le nRF51 agit en tant qu’esclave et le STM32 en tant que maître. | ||
| + | |||
| + | |||
| + | Le nRF51 gère : | ||
| + | *le bouton (physique) ON/OFF | ||
| + | *l’alimentation du système (STM32, capteurs et cartes d’extensions) | ||
| + | *le chargement de la batterie | ||
| + | *communication radio et Bluetooth (protocoles Bluetooth et CRTP) | ||
| + | *détecter, installer les cartes d’extensio | ||
| + | |||
| + | |||
| + | Le STM32 gère toutes les autres tâches du drone, par exemple : | ||
| + | *contrôle et régulation des moteurs | ||
| + | *contrôleur de vol | ||
| + | *mesures (lecture des valeurs des capteurs) | ||
| + | *Les tâches implémentées dans le firmware | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | ===Architecture logicielle=== | ||
| + | |||
| + | Le firmware du drone est open source, il est accessible sur le git du constructeur. Le firmware est constitué d’un ensemble de tâches utilisant FreeRTOS. Toutes les tâches du drone sont temps-réels et implémentées sous formes de tâches FreeRTOS. Pour avoir une idée de ces tâches, voici par exemple voici les principales tâches de stabilisation du drone et de contrôle du système sous forme de diagramme de bloc : | ||
| + | |||
| + | |||
| + | [[Fichier:logicielle-1_p21.png|900px]] | ||
| + | [[Fichier:logicielle-2_p21.png|900px]] | ||
| + | |||
| + | |||
| + | Lien du firmware du drone : https://github.com/bitcraze/crazyflie-firmware | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | ===Réseau de capteur pour la localisation en intérieur=== | ||
| + | Nous avons commencé par mettre en place le réseau de capteur nécessaire pour travailler avec la position absolue (i.e. dans un répère fixe) du drone. Le réseau de capteur utilisé est le loco positioning system. Ce système a été présenté durant le semestre précédent. Pour rappel, le Loco Positionning System est composé de deux types de capteurs : | ||
| + | |||
| + | -les "ancrages", qui sont repartis dans la pièce. (6 en tout) | ||
| + | |||
| + | -le capteur "node" qui se situe sur le drone. | ||
| + | |||
| + | Les ancrages possèdent chacun un numéro précis et doivent être placés selon une disposition particulière dans la pièce. Avant de placer les capteurs dans la pièce, nous avons flashé nos ancrages afin de leur attribuer un numéro à l'aide du logiciel LPS node firmeware. | ||
| + | |||
| + | Nous avons ensuite fixé les ancrages dans la pièce à l'aide de boites en bois que nous avons fabriqués au fabricarium. | ||
| + | |||
| + | Les ancrages sont alimentés par une batterie externe : | ||
| + | |||
| + | [[Fichier:Ancrage.jpg|300px]] | ||
| + | |||
| + | Le capteur "node" est placé sur le drone de cette manière : | ||
| + | |||
| + | [[Fichier:Node2.jpg|300px]] | ||
| + | |||
| + | Nous avons décidé de placer les ancrages dans la pièce de cette manière les ancrages : | ||
| + | |||
| + | [[Fichier:Plansalle.PNG|400px]] | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | ===Vol autonome=== | ||
| + | ====Test des capteurs avec Python==== | ||
| + | |||
| + | Une fois notre réseau de capteurs installé, nous avons fait quelques tests afin de nous assurer que tout était fonctionnel. Comme nous avons rencontré de nombreux problèmes, une partie du groupe s’est occupé du réseau de capteurs et des tests avec Python et une autre de l’implémentation de tâche sous FreeRTOS. | ||
| + | |||
| + | |||
| + | =====Les limites du système de positionnement et des valeurs que l’on reçoit===== | ||
| + | Pour visionner la valeur des capteurs, nous sommes obligés d’utiliser le logiciel Crazyflie Client. Nous ne pouvons pas avoir de retour sur les capteurs une fois que le drone est en vol. En effet, pour que le drone décolle, il ne faut qu’aucun autre programme ne communique avec lui. Comme le code est interprété sur notre ordinateur puis envoyé sur le drone, il ne faut pas que le logiciel communique avec le drone au même moment, car seul un programme à la fois peut envoyer des paquets au drone. Donc si le logiciel envoie des paquets, on ne peut pas exécuter notre code python et vice versa. | ||
| + | |||
| + | Le problème est que l’on n’arrive pas à implémenter un code python afin d’avoir les coordonnées en x,y,z pendant le vol, on est dépendant du logiciel pour cela. Le drone envoie seulement des données brutes qui sont traitées par filtre de Kalman. Nous n’avons pas réussi à ce jour à tirer des informations exploitables sur ces données bruts. Une piste pourrait être de se concentrer davantage sur ces données afin d’en tirer quelque chose. | ||
| + | |||
| + | D’un autre côté on ne peut pas exécuter de code depuis le logiciel Crazyflie Client, impossible donc avec ce logiciel d’évaluer les valeurs de retour de ces capteurs tout en exécutant du code. | ||
| + | |||
| + | =====1. Problème au sol===== | ||
| + | Au repos, lorsque l’on étudiait les valeurs de retour des capteurs, ils indiquaient une valeur négative en Z ou très élevé (supérieur à 3 mètres). Nous avons étudié la position des capteurs et nous nous sommes rendu compte que les capteurs posés au sol étaient situés légèrement au-dessus du drone. Pour résoudre ce problème nous avons décidé de surélever le drone en le posant sur le carton afin qu’il soit situé au-dessus des capteurs lorsqu’il est posé sur le sol. | ||
| + | |||
| + | =====2. Problèmes en vol===== | ||
| + | Afin de tester nos capteurs en vols, nous avons essayé de lancer un code Python. | ||
| + | |||
| + | En cours de vols, notre drone est incapable de suivre les coordonnés qui lui sont imposées. Dès qu’il décolle il se crash. Nous avons dû l’attacher afin de réduire les dégâts. D’après les limites que nous avons décrites plus haut, il nous est impossible de savoir les coordonnées que le drone a lues avant de se crasher. La seule chose que l’on peut savoir est la valeur des coordonnées que l’on a donnée comme consigne à notre drone. | ||
| + | |||
| + | Afin de résoudre ce problème, nous avons essayé de diminuer la précision qui était de 1mm initialement à 1 cm. Ce que nous appelons précision est l’écart relatif entre la position que l’on veut atteindre et la position où l’on est. En réduisant la précision, nous avons espéré avoir un mouvement plus souple. Malheureusement, nous n’avons pas obtenu de résultats fructueux avec cette méthode. | ||
| + | |||
| + | Une seconde méthode, que nous n’avons pas pu tester, consiste à changer les algorithmes de calculs de position. | ||
| + | |||
| + | ====Implémentation d’une tâche de vol autonome sous FreeRTOS==== | ||
| + | La programmation de tâche autonome n’est pas permise par le constructeur. Nous avons accès au firmware, mais il sert surtout à développer des drivers pour intégrer de nouvelle carte d’extension pour le drone, comme par exemple : https://www.bitcraze.io/products/flow-deck-v2/ | ||
| + | |||
| + | Cependant, comme le drone est composé de mémoire flash, avec un firmware open source et une architecture matérielle connue, il est envisageable de programmer des tâches FreeRTOS. Comme le constructeur ne le recommande pas, il n’a pas documenté son wiki sur la façon d’implémenter ses propres tâches temps-réelles. Nous nous sommes documentés sur une thèse de master écrite par Mr Luke Beumont Barrett. | ||
| + | |||
| + | Il est possible de programmer des tâches temps-réelles en écrivant notre code FreeRTOS dans le répertoire Crazyflie-firmware/src/modules/src du firmware du Crazyflie. Ensuite il faudra déclarer notre tâche dans le config.h qui se trouve dans crazyflie-firmware/src/config. | ||
| + | |||
| + | https://github.com/bitcraze/crazyflie-firmware/tree/master/src/modules/src | ||
| + | |||
| + | https://github.com/bitcraze/crazyflie-firmware/blob/master/src/config/config.h | ||
| + | |||
| + | Nous avons seulement eu le temps de lire le mémoire et d’implémenter l’un des exemples de code fourni dans ce mémoire. Nous n’avons pas pu aller plus loin en raison de la fermeture des écoles dû au COVID19. | ||
| + | |||
| + | ==Covid 19== | ||
| + | ===(Situation du projet le 13/03/2020)=== | ||
| + | |||
| + | |||
| + | Notre projet se basant sur un réseau de capteur vissé sur les murs (support en aluminium) de la C305, il nous est impossible de poursuivre sur les mêmes objectifs. | ||
| + | De plus, comme nous programmions des tâches autonomes pour notre drone, il est impératif d'avoir une salle avec des filets (comme la C305). | ||
| + | |||
| + | |||
| + | Nous allons donc revoir les objectifs de notre projet. | ||
| + | |||
| + | ===(Situation du projet le 25/03/2020)=== | ||
| + | |||
| + | |||
| + | Suite à l'impossibilité de poursuivre le projet initial, un nouveau projet nous a été confié par Mr. Redon. | ||
| + | |||
| + | == Objectif du nouveau projet == | ||
| + | |||
| + | L’objectif est de modéliser puis simuler un drone sous Godot avec une régulation externe sous Simulink. A partir de l'inclinaison du drone, Simulink doit pouvoir envoyer une consigne sur les quatres moteurs, afin de pouvoir réguler le drone sur Godot. | ||
| + | |||
| + | Dans le moteur graphique Godot nous devons modéliser un drone (son aspect), l'effet de chaque moteur à une vitesse donnée (équations dynamiques) et un "capteur" qui donne l'inclinaison du drone. On se limitera à l'assiette du drone, on ne tente pas un déplacement contrôlé. | ||
| + | |||
| + | Les valeurs des 4 moteurs doivent pouvoir être donner via UDP. De plus via une requête en UDP nous devons être en mesure d’envoyer la valeur de l’inclinaison du drone. | ||
| + | |||
| + | |||
| + | Nous avons défini le projet en 4 étapes : | ||
| + | |||
| + | * Modélisation d’un drone quadricoptère sous Godot (simulation physique) | ||
| + | * Calcul avec Simulink des vitesses des 4 moteurs en fonction de l’inclinaison et de la vitesse de déplacement en entrée | ||
| + | * Communication Godot <-> Simulink en boucle par UDP | ||
| + | |||
| + | |||
| + | |||
| + | ===Godot=== | ||
| + | |||
| + | Dans un premier nous avons téléchargé puis installé Godot. Certains membres du groupe ont eu du mal à installer Matlab à cause de leur connexion wifi et aussi de la taille (SSD de petite capacité). Nous sommes donc passés à Godot le temps que tout le monde puisse l'avoir sur son PC. | ||
| + | |||
| + | |||
| + | Nous avons utilisé plusieurs scènes pour pouvoir simuler le drone, les voici : | ||
| + | |||
| + | |||
| + | '''1.Une scène nommée "le_drone" de type KinematicBody''' (pour les déplacements 3D), à l'intérieur : un drone importé depuis internet (format .obj), et un contour (CollisionShape) qui nous permettra d'interagir avec d'autre solides (typiquement poser le drone sur le sol). Il y a différentes manières de définir les contours, nous avons choisi un cube qui englobe le drone pour faciliter son contact avec le sol. | ||
| + | |||
| + | |||
| + | [[Fichier:Godot-base-drone-1.PNG|300px]] | ||
| + | |||
| + | |||
| + | '''2.Une scène nommée "le_sol" de type StaticBody''', à l'intérieur : un pavé de couleur verte, et des contours qui épousent la forme du sol | ||
| + | |||
| + | |||
| + | '''3.Une scène principale "Environnement global"''' de type Spatial (environnement 3D), à l'intérieur, on instancie nos scènes "le_drone" et "le_sol" en tant qu'enfant de notre scène principale. On définit aussi 2 caméras : une caméra principale, et une caméra secondaire qui sera affichée en bas à droite lors de la simulation. | ||
| + | |||
| + | |||
| + | [[Fichier:Godot-base-1.PNG|500px]] | ||
| + | |||
| + | |||
| + | Enfin, on place notre drone et nos caméras dans l'espace. Et puis on écrit un script pour faire déplacer notre drone (juste pour apprendre les commandes de base). Dans notre script on peut faire déplacer le drone linéairement en donnant une vitesse de déplacement en x,y,z. On peut aussi lui donner un angle d'inclinaison en donnant une valeur en radian. | ||
| + | |||
| + | |||
| + | [[Fichier:Godot-base-2.PNG|500px]] | ||
| + | |||
| + | ===Communication UDP=== | ||
| + | |||
| + | |||
| + | Nous avons parallèlement travaillé sur la partie communication UDP. Nous avons d'abord créé un serveur et un client sur Matlab. | ||
| + | |||
| + | Nous avons ensuite réalisé le même travail sur Godot, en programmant un serveur et un client. | ||
| + | |||
| + | Nous devons maintenant faire échanger des données entre Matlab et Godot via une communication UDP. | ||
| + | |||
| + | '''Pour la première simulation Matlab''' (simulation des 4 moteurs sur Simulink), nous avons tout d'abord établi un protocole qui définit le type du message envoyé et son contenu entre Matlab et Godot. | ||
| + | Concernant la communication dans le sens Godot → Matlab, le message envoyé contient en tout 5 informations, qui seront envoyées à la suite. Le protocole est le suivant : | ||
| + | |||
| + | * le mot "Start" qui indique le début d'une trame. | ||
| + | * Vitesse angulaire phi | ||
| + | * Vitesse angulaire psi | ||
| + | * Vitesse angulaire theta | ||
| + | * Vitesse de translation sur z | ||
| + | |||
| + | les valeurs des vitesses des moteurs et angulaires sont des floats. | ||
| + | |||
| + | Le client Godot envoie ces données sous formes de chaines de caractères. Elles sont converties sous la forme de float par le serveur Matlab à l'aide de la méthode str2double. Ces données seront exploitées par la suite lors de la régulation. | ||
| + | |||
| + | Le Client Matlab quant à lui envoie six données: | ||
| + | |||
| + | * le mot "Start" qui indique le début d'une trame. | ||
| + | * Vitesse du moteur 1 | ||
| + | * Vitesse du moteur 2 | ||
| + | * Vitesse du moteur 3 | ||
| + | * Vitesse du moteur 4 | ||
| + | * le mot "quit" qui indique la fin d'une trame. | ||
| + | |||
| + | Les vitesses des quatre moteurs qui seront appliquées sur le drone dans la simulation Godot. Ces vitesses sont envoyées sous forme de chaîne de caractères et converties en float par le serveur Godot. | ||
| + | |||
| + | Voici notre script Godot qui assure le rôle de serveur. | ||
| + | |||
| + | Nous intégrons nos clients et serveurs UDP Godot dans notre script de simulation Godot et nos clients et serveurs UDP Matlab dans un script Matlab dans lequel on récupère des valeurs de moteurs transmises par la première simulation effectuée sur Simulink ''(partie Matlab/Simulink plus bas dans le wiki)''. La communication est en forme de boucle entre Matlab et Godot. | ||
| + | |||
| + | Dans la simulation Godot, le drone est à l’arrêt jusqu’à ce que le script Matlab lui envoie les valeurs des 4 moteurs. On observe alors le drone décoller. Le client UDP présent sur Godot envoie en continue les valeurs des vitesses des 4 moteurs du drone ainsi que les valeurs des vitesses angulaires. Ces données sont récupérées par le Serveur UDP Matlab qui écoute en continue sur le port. | ||
| + | |||
| + | |||
| + | '''Concernant le deuxième script''' simulink qui gère la régulation en cas de perturbation, les données échangées via UDP sont différentes. Godot envoie : | ||
| + | |||
| + | * le mot "Start" qui indique le début d'une trame. | ||
| + | * Le moment du vent selon X | ||
| + | * Le moment du vent selon Y | ||
| + | * Le moment du vent selon Z | ||
| + | |||
| + | Le script Matlab envoie lui les données des quatre moteurs qui permettent de réguler le drone. | ||
| + | |||
| + | |||
| + | Voici un exemple de données envoyées par le client Godot et récupérées sur Matlab : | ||
| + | |||
| + | [[Fichier:Don1matlab.png]] | ||
| + | |||
| + | Data , Data 1, Data 2 : moment du vent selon x,y et z | ||
| + | |||
| + | Cette communication UDP est utilisée dans les scripts VariableDrone.m (simulation des moteurs sous Simulink) et resolution_equation.m (régulation du drone), '''les résultats sont présentés à l'aide de vidéos à la suite du wiki.''' | ||
| + | |||
| + | ===Modèle physique du drone sur Godot=== | ||
| + | |||
| + | '''Pour modéliser le drone, nous travaillerons dans 2 repères, un fixe Oned (earth frame), et un mobile Oabc (body frame).''' | ||
| + | |||
| + | [[Fichier:repere_equation-godot-1.PNG|480px]] | ||
| + | |||
| + | |||
| + | Dans ces deux repères, on définit 2 vecteurs : | ||
| + | |||
| + | [[Fichier:vecteur_equation-godot-1.PNG|200px]] | ||
| + | |||
| + | qui contient la '''position''' linéaire et angulaire du drone dans le '''repère fixe.''' | ||
| + | |||
| + | [[Fichier:vecteur_equation-godot-2.PNG|200px]] | ||
| + | |||
| + | qui contient la '''vitesse''' linéaire et angulaire du drone dans le '''repère mobile.''' | ||
| + | |||
| + | |||
| + | '''En entrée, nous prenons les vitesses des 4 moteurs qui nous permettront de calculer les forces et moments générés par ces vitesses.''' | ||
| + | |||
| + | avec | ||
| + | |||
| + | *ft : force de poussée verticale | ||
| + | *τx,y,z : les moments selon x,y,z | ||
| + | *l : distance moteur – centre du drone | ||
| + | *d : facteur de trainée (drag coefficient) | ||
| + | *b : facteur de poussée (thrust coefficient) | ||
| + | *Ωn : la vitesse du moteur | ||
| + | |||
| + | [[Fichier:equation-216-godot-2.PNG|560px]] | ||
| + | |||
| + | Pour les valeurs de d, l, b de l’équation (2.16) nous prendrons celles du Crazyflie obtenues pages 12 et 13 de ce papier : https://arxiv.org/pdf/1608.05786.pdf | ||
| + | |||
| + | |||
| + | De même pour les éléments de la '''matrice d’inertie, diagonale''', car on considère que notre drone a '''deux plans de symétrie''' : | ||
| + | |||
| + | |||
| + | [[Fichier:matrice-inertie-godot-1.PNG|360px]] | ||
| + | |||
| + | |||
| + | Enfin après avoir défini nos repères, nos constantes et nos entrées, on modélise le ''' modèle linéaire du drone : ''' | ||
| + | |||
| + | [[Fichier:equation-236-godot-2.PNG|560px]] | ||
| + | |||
| + | |||
| + | Avec les '''perturbations du vent définies par :''' | ||
| + | |||
| + | [[Fichier:equation-233-godot-1.PNG|400px]] | ||
| + | |||
| + | |||
| + | Après avoir implémenté l’équation 2.36 en se basant sur 2.16, 2.33, on procède à quelques tests afin de vérifier si le modèle est correct et nous permet bien de simuler les 6 degrés de liberté du drone. Pour ce faire, nous nous baserons sur le travail que nous avons effectué au semestre 6. En effet nous avions défini les 6 degrés de liberté du drone en fonction de la vitesse de ses 4 moteurs. | ||
| + | |||
| + | Ici, nous avons relevé les vitesses angulaires et linéaires dans le repère fixe en fonction des vitesses des 4 moteurs ( = Vmn dans notre code, = Ωn dans les équations) afin d ‘observer si oui ou non on obtient nos 6 mouvements. | ||
| + | |||
| + | Pour rappel notre '''repère fixe est le suivant''' : | ||
| + | |||
| + | [[Fichier:repere_equation-godot-2.PNG|200px]] | ||
| + | |||
| + | Pour les '''vitesses maximales du moteur, ''' nous avons pris celles du Crazyflie, qui peuvent aller jusqu’à 6160 rad/s. Les moteurs 1 et 3 tournent dans le sens horaire et sont situés de part et d’autre du quadricoptère et les moteurs 2 et 4 dans le sens antihoraire (cf. travail du semestre 6). '''Toutes les mesures seront faites avec un vent nul.''' | ||
| + | |||
| + | |||
| + | [[Fichier:tableau-vmax-axe-Z.PNG|600px]] | ||
| + | |||
| + | Dans un premier temps nous calculons la '''vitesse maximale théorique''' de translation horizontale selon l’axe Z négatif. Z est négatif car le drone se déplace vers le haut, alors que l’axe Z est orienté vers le bas. | ||
| + | |||
| + | Ainsi, selon notre modèle, le Crazyflie peut aller au maximum à 1,47 m/s vers le haut lorsque les moteurs tournent à leur maximum (ce qui n’arrive pas car la batterie LiPo 240mAh ne tiendrait pas, il faudrait 4.2V et 1A sur chaque moteur pour atteindre la vitesse max théorique). | ||
| + | |||
| + | |||
| + | Maintenant, tentons de trouver la vitesse minimale qu’il faut donner aux moteurs pour que le drone commence à décoller. Nous considèrerons que le drone décolle lorsqu’il atteint une vitesse de -1cm/s selon Z. Notre modèle ne fonctionne qu’avec des petits angles en φ et en θ (simplification cos et sin) et il néglige l’aspiration du drone par le sol lorsque celui est très proche du drone. En résolvant : | ||
| + | |||
| + | |||
| + | ż = (fwz-ft)/m = -0.01, '''on trouve Ω1= Ω2= Ω3= Ω4=507rad/s ''' | ||
| + | |||
| + | |||
| + | avec fwz = 0 (vent négligé dans cette partie) | ||
| + | |||
| + | Ainsi, notre drone décolle lorsque ses 4 moteurs tournent à 507rad/s. | ||
| + | |||
| + | |||
| + | '''Les translations selon les axes X et Y''' sont en fait une combinaison de mouvement (tangage/pitch) et de variations des vitesses des 4 moteurs. Nous ne nous intéresserons pas ici à ces mouvements car nous étudions seulement la rotation du drone selon les axes X,Y,Z et non ses déplacements linéaires selon ces axes. | ||
| + | |||
| + | |||
| + | '''Etudions maintenant les rotations du drone selon la vitesse des moteurs.''' | ||
| + | |||
| + | [[Fichier:tableau-rotation-axe-Z.PNG|600px]] | ||
| + | |||
| + | En faisant tourner les moteurs 2 et 4 moins rapidement que les 1 et 3, on engendre une rotation d’axe Z de -0.43 rad/s, soit environ 25°/s. De plus les 4 moteurs tournant à ~3000rad/s, ils entrainent un déplacement selon Z de 34cm/s. | ||
| + | |||
| + | |||
| + | [[Fichier:tableau-rotation-axe-X.PNG|600px]] | ||
| + | |||
| + | En faisant tourner légèrement moins rapidement les moteurs 1 et 2, on engendre une forte rotation d’axe X de 2.73 rad/s, soit environ 156°/s. Cette forte vitesse angulaire s’explique par les équations définissant le moment en X des moteurs du drone (cf. équation 2.16). De plus les 4 moteurs tournant à ~3000rad/s, ils entrainent un déplacement selon Z de 35cm/s. | ||
| + | |||
| + | |||
| + | [[Fichier:tableau-rotation-axe-Y.PNG|600px]] | ||
| + | |||
| + | En faisant tourner les moteurs 2 et 4 moins rapidement que les 1 et 3, on engendre une rotation d’axe Y de 1.07 rad/s, soit environ 61°/s. De plus les 4 moteurs tournant à ~3000rad/s, ils entrainent un déplacement selon Z de 35cm/s. | ||
| + | |||
| + | |||
| + | En nous basons sur notre étude du semestre 6, on peut dire que notre simulation Godot est en adéquation avec notre étude théorique qui définissait les mouvements du drone en fonction de la variation de vitesse sur ses quatre moteurs. | ||
| + | |||
| + | ===Simulation du drone sur Godot=== | ||
| + | |||
| + | Après avoir implémenté les équations sur Godot, nous simulons les rotations du drone à l'aide de deux fonctions. La première nous permet de simuler la rotation du drone pendant un temps indéfini. L'autre nous permet de visualiser la réponse du système lorsque les vitesses des 4 moteurs lui sont assignées pendant un temps défini. | ||
| + | |||
| + | |||
| + | Voici par exemple ce que l'on obtient pendant 1,5s pour Vm1 = 3000 rad/s, Vm2 = 2800 rad/s, Vm3 = 3000 rad/s et Vm4 = 2900 rad/s, en négligeant les perturbations dues au vent. | ||
| + | |||
| + | [[Fichier:simu-drone-3000-2800-3000-2900-2sec-1.PNG|500px]] | ||
| + | |||
| + | |||
| + | |||
| + | Pour finir nous avons fait une vidéo avec plusieurs simulations : un décollage sans le vent, un décollage avec un vent en x et z et un décollage avec un vent en y. Nous avons aussi simulé un lacet. En effet, conformément à nos travaux du S6, pour Vm1 = 3000 rad/s, Vm2 = 2900 rad/s, Vm3 = 3000 rad/s et Vm4 = 2900 rad/s on obtient bien un lacet (rotation sur lui-même selon Z). La vidéo a été faite sans régulation Matlab.''' Voici une compilation de plusieurs mouvements avec et sans vent : ''' | ||
| + | |||
| + | [[File:Simulation_godot.mp4|500px]] | ||
| + | |||
| + | ===Simulink=== | ||
| + | |||
| + | Dans la partie Simulink, notre but est de simuler les 4 moteurs du drone pour par la suite les réguler en cas de perturbation. | ||
| + | |||
| + | |||
| + | '''I) Équations pour modélisation des moteurs''' | ||
| + | |||
| + | Nous allons recevoir dans notre modèle Simulink, les valeurs des différentes inclinaisons du drone ainsi que sa vitesse de translation sur l'axe z qui permet au drone de monter ou descendre. | ||
| + | Il est donc nécessaire d'obtenir les équations des moteurs en fonction de ses différentes variables. | ||
| + | |||
| + | Grâce aux équations 2.36 et 2.16, nous pouvons obtenir les équations suivantes : | ||
| + | |||
| + | [[Fichier:Equation.PNG|200px]] | ||
| + | |||
| + | Avec p, q et r les vitesses d'inclinaison du drone et w la vitesse de translation sur z. | ||
| + | |||
| + | |||
| + | '''II) Modélisation des moteurs sous Simulink''' | ||
| + | |||
| + | Après avoir déterminé les équations qui nous serons nécessaires, nous pouvons établir les moteurs du drone avec les caractéristiques du crazyflie, '''la simulation se fera d'abord sans régulation'''. | ||
| + | |||
| + | Voici le modèle global : | ||
| + | |||
| + | [[Fichier:MoteurGlobal.PNG|500px]] | ||
| + | |||
| + | Moteur 1 : | ||
| + | |||
| + | [[Fichier:Moteur1.PNG|500px]] | ||
| + | |||
| + | Moteur 2 : | ||
| + | |||
| + | [[Fichier:Moteur2.PNG|500px]] | ||
| + | |||
| + | Moteur 3 : | ||
| + | |||
| + | [[Fichier:Moteur3.PNG|500px]] | ||
| + | |||
| + | Moteur 4 : | ||
| + | |||
| + | [[Fichier:Moteur4.PNG|500px]] | ||
| + | |||
| + | Moment en X généré par la vitesse des 4 moteurs, Tx : | ||
| + | |||
| + | [[Fichier:Tx.PNG|500px]] | ||
| + | |||
| + | Moment en Y généré par la vitesse des 4 moteurs, Ty : | ||
| + | |||
| + | [[Fichier:Ty.PNG|500px]] | ||
| + | |||
| + | Moment en Z généré par la vitesse des 4 moteurs, Tz : | ||
| + | |||
| + | [[Fichier:Tz.PNG|500px]] | ||
| + | |||
| + | Force de poussée verticale, Ft : | ||
| + | |||
| + | [[Fichier:Ft.PNG|500px]] | ||
| + | |||
| + | Fichier Matlab : | ||
| + | |||
| + | [[Fichier:FichierMatlab.PNG|400px]] | ||
| + | |||
| + | |||
| + | '''III) Expérimentation''' | ||
| + | |||
| + | La modélisation mise en place, nous pouvons maintenant tester si nos moteurs donnent les mêmes valeurs que sur Godot grâce aux expérimentations précédentes. '''Toutes les expérimentations seront faites avec un vent nul.''' | ||
| + | |||
| + | Premièrement, nous allons démarrer avec une vitesse maximale de translation sur z de 1,47 m/s pour pouvoir observer si les moteurs vont tourner à la même vitesse que ceux de la simulation sur Godot. (Voir expérimentation sur Godot). | ||
| + | |||
| + | [[Fichier:Test_1.PNG|500px]] | ||
| + | |||
| + | On remarque qu'on est très proche du résultat sur Godot qui été théoriquement de 6160 rad/s pour chaque moteur avec les mêmes configurations. | ||
| + | |||
| + | Pour la deuxième expérimentation, nous allons faire une rotation sur l'axe Y de 1,07 rad/s (61 °/s). | ||
| + | |||
| + | [[Fichier:Test2.PNG|500px]] | ||
| + | |||
| + | On remarque que les moteurs ont la même configuration que sur Godot mais les valeurs ne sont pas les mêmes. Elles sont sûrement dues à la non-régulation des moteurs puis peut-être, également, à une meilleure interprétation dans Simulink. '''Voici un exemple de communication Matlab-Simulink/Godot en boucle :''' | ||
| + | |||
| + | [[Fichier:Simulation-drone.mp4|500px]] | ||
| + | |||
| + | ===Régulation sous Matlab=== | ||
| + | |||
| + | Après avoir créé un Simulink contenant les 4 moteurs du drone, nous nous sommes tournés vers un script Matlab pour la régulation qui nous semble être la meilleure option. | ||
| + | |||
| + | Avec les équations 2.16, nous avons posé un système de 3 équations que l'on a résolu avec un calculateur formel Xcas pour avoir 8 solutions valables dans un certain domaine de validité. Nous avons résolu moment_moteurs = - moment_vent en fonction de Vm1,Vm2,Vm3,Vm4 (vitesses des moteurs). Ainsi en résolvant cette équation, on obtient 4 valeurs de moteurs qui compenseront les moments engendrés par le vent. Vx, vy, vz dans le solveur correspondent aux moments du vent (avec le signe moins, vx=-T_wx). | ||
| + | |||
| + | [[Fichier:Systeme-d-equations.png|500px]] | ||
| + | |||
| + | |||
| + | Nous avons choisi la meilleure d’entre elles car elle a un domaine de validité intéressant (les vitesses des moteurs et de vent correspondent à des solutions physiquement possibles par rapport à la vitesse max et min des moteurs du drone) : | ||
| + | |||
| + | |||
| + | [[Fichier:Equation4moteurs.PNG|600px]] | ||
| + | |||
| + | |||
| + | Ces équations expriment les moments du drone en fonction des perturbations du vent. Les trois premières vitesses des moteurs dépendent des perturbations mais également de la vitesse du 4ème moteur. Cette vitesse a été fixée par son domaine de validité, qui dépend uniquement de la perturbation du vent selon l’axe y. Ainsi, les valeurs des vitesses calculées permettent aux moteurs du drone de se réguler et de rester stable. | ||
| + | |||
| + | Dans le script, on reçoit les données du vent via Godot avec la communication UDP pour que, par la suite, on ait la correction des moteurs à envoyer sur Godot pour que le drone se stabilise (voir partie Communication UDP). | ||
| + | |||
| + | |||
| + | '''Régulation d'une perturbation selon Z avec un moment T_wz = 0.5 Nm :''' | ||
| + | |||
| + | [[Fichier:Regulation-finale.mp4|500px]] | ||
| − | + | Pour une cause encore inconnue, quand il y a un tangage ou un roulis sur le drone, la régulation s’emballe, on pense que cela est dû à Godot dans le calcul de l’intégrale qui a peut-être été mal faite. | |
Version actuelle datée du 26 août 2021 à 16:55
Sommaire
- 1 Présentation générale
- 2 Analyse du projet
- 3 Préparation du projet
- 4 Réalisation du Projet
- 4.1 Projet S6
- 4.2 Projet S7
- 4.3 Projet S8
- 4.4 Covid 19
- 4.5 Objectif du nouveau projet
Présentation générale
Description
De nos jours, les drones sont présents dans de nombreux domaines : industrie, agriculture, sports, loisirs… etc. Dans les airs ou dans la mer, ils ont tous des buts différents selon leur utilisation.
Nous allons nous concentrer sur les drones de développement. Ils sont utilisés dans la recherche, l’éducation et par les amateurs de robotique. Ils présentent de nombreux enjeux, comme la commande automatique, l’évitement d’obstacles, la détection d’intrus.
L’ouverture à la programmation et à la modification hardware/software peut être un frein dans la mise en place d’une application d’un drone de développement. C’est pourquoi nous allons nous concentrer sur un drone open source au niveau hardware et software.
Plus particulièrement notre projet se servira du drone Quadricopter Crazyflie 2.0.
Objectifs
Le fil directeur de notre projet est le contrôle d'un drone sous les facettes d'informatique, microélectronique et automatique. Au niveau informatique, nous nous concentrerons sur le développement d'algorithmes de déplacement et d'évitement d'obstacle. Pour la partie microélectronique nous nous pencherons sur le fonctionnement des moteurs, des cartes électroniques et des capteurs. Enfin nous nous servirons de l'automatique pour réguler en vitesse et en position de notre drone.
L'objectif final est de développer le drone mis à notre disposition afin qu'il puisse se déplacer point d'un A point à un B tout en étant stable. Au cours de son déplacement il devra transmettre sa position à l'utilisateur.
Dans un premier temps, nous étudierons le fonctionnement général d'un drone à 4 branches. Ensuite, nous allons étudier les différentes commandes à envoyer au drone afin de le déplacer selon l'axe voulu. Puis, du côté pratique nous allons asservir une position statique à notre drone qu'il devra maintenir quelle que soit la perturbation (vent, etc). Dans un second temps, nous développerons les fonctions de déplacement dans l'espace. Enfin, nous lui donnerons une trajectoire qu'il devra respecter tout au long de son parcourt.
Analyse du projet
Positionnement par rapport à l'existant
Caractéristiques principales du drone Quadricopter Crazyflie 2.0®
Radio:
- amplificateur radio de 20 dBm testé à plus de 1 km (portée à vue) avec le Crazyradio PA
- bluetooth Low Energy compatible iOS et Android
- radio compatible avec Crazyflie et Crazyradio
Microcontrôleurs:
- STM32F405, microcontroleur principal (Cortex-M4, 168 MHz, 192 KB SRAM, 1 MB de mémoire flash)
- nRF51822, gestion alimentation et radio (Cortex-M0, 32 MHz, 16 KB SRAM, 128 KB de mémoire flash)
- EEPROM 2 KB
Connecteur USB:
- chargeur LiPo integré avec trois modes (100 mA, 500 mA, 980 mA)
- utilisation en USB OTG possible
Capteurs:
- gyroscope 3 axes (MPU-9250)
- accéléromètre 3 axes (MPU-9250)
- magnétomètre 3 axes (MPU-9250)
- capteur de pression haute précision (LPS25H)
| Chiffres clés |
|---|
|
A noter que l'ensemble de l'architecture matérielle et logicielle (hardware/software) est accessible sur le wiki (hardware) et sur le git (software) indiqués dans la bibliographie.
Analyse du premier concurrent
Constructeur : DJI et Ryze
Modèle : Tello Drone EDU
Initialement conçu pour l'enseignement, le tello Drone a de nombreux atouts. Pour seulement 100 euros, nous avons un drone compact, résistant (protection des hélices), et programmable. Il est compatible avec scratch, Python et Swift. Pour une utilisation avancée, on peut même embarquer ROS et utiliser le SDK. Il dispose aussi de petites balises pour se repérer dans l'espace et être contrôlé en essaim.
Cependant, nous ne pouvons pas nous en servir dans notre projet, car ni le hardware, ni le software ne sont ouverts. Nous ne pouvons donc pas modéliser efficacement les moteurs, ni même faire une étude approfondie au niveau hardware. En fait, il s'agit plutôt d'un drone de programmation du fait de sa compatibilité avec plusieurs langages de programmation, on ne peut pas s'en servir dans un projet à dominante "automatique".
Analyse du second concurrent
Constructeur : Pixhawk
Modèles : Pixhawk 4 et Pixhawk mini
Pixhawk est un projet open source visant à developper un contrôleur de vol libre et indépendant. De nombreux projet aussi bien dans la recherche que dans le monde professionnel se servent d'une carte de vol Pixhwak. Cette carte, très réputée, est notamment compatible avec les projets open source PX4 (Dronecode) et Ardupilot. Dronecode et Ardupilot proposent des outils libres pour simuler, contrôler et analyser son drone tout au long de ses déplacements. Dans un projet comme le notre, Dronecode semble être adapté tant les ressources et la documentation qu'ils proposent sont fournis.
Cependant, bien que nous avons effectuer de nombreuses recherches sur Dronecode, que nous avions conclu qu'il fallait une carte Pixhawk, nous avons finalement abandonné cette piste.
En effet, de notre point de vue, il nous aurait fallu un groupe supplémentaire qui aurait assembler notre drone, pendant que l'autre se penche sur la partie automatique. Un drone embarquant une carte Pixhawk avec PX4 installé dessus nécessite une équipe focalisée sur le hardware. En effet, en plus de la carte, il faut commander le châssis, les moteurs, les antennes, la télécommande, la baterrie, les chargeurs... etc. Nous avons préféré partir sur un drone 'ready to fly', c'est-à-dire déja assemblé et en état de marche.
Scénario d'usage du produit ou du concept envisagé
Notre projet visant à asservir en position un drone de façon autonome, il existe de très nombreux scénarios d’usage pouvant s’inscrire dans notre projet.Par exemple, on pourrait imaginer un agriculteur souhaitant contrôler l’état de ses arbres. On pourrait installer des petites balises sur chacun des troncs, et effectuer un vol autonome afin de filmer chacun de ces arbres. L’agriculteur n’aurait qu’à observer la vidéo, sans avoir à se déplacer dans tout le verger. Notre drone étant asservi en position, il décollera et se maintiendra à une altitude supérieure aux arbres (par exemple 3 mètres) et reliera tous les points indiqués par les balises pour ensuite revenir à son point de départ.
Réponse à la question difficile
Le drone étant livré monté, prêt à l'emploi, qu'est ce que vous apporter en plus par rapport à ce qui est déjà possible de faire avec ce drone ?
Notre but est de développer une suite d’algorithme de contrôle automatisé de notre drone. Pour ce faire, nous allons étudié le fonctionnement d’un drone à quatre hélices. Tout d’abord, nous allons isoler puis modéliser un moteur brushless. Ensuite nous allons modéliser les quatre moteur, ensemble. Enfin, sur un banc de test, nous allons envoyer nos commandes sur les quatre moteurs afin de réaliser 4 mouvements élémentaires d’un drone 4 hélices.
Bibliographie et webographie
https://www.gotronic.fr/art-quadricopter-crazyflie-2-0-110990440-23791.htm
https://wiki.bitcraze.io/projects:crazyflie2:index
Préparation du projet
Notre groupe est constitué d'une seule équipe de 3 personnes.
Cahier des charges du groupe
Tout d’abord notre drone doit être capable de décoller, d’atterrir et de maintenir une position fixe. Il doit être capable de réguler la vitesse de ses moteurs pour se maintenir en altitude, en fonction des contraintes extérieures (comme le vent) qui lui seront imposées. Dans un second temps, il doit pouvoir se déplacer dans l’espace en se repérant via des balises radio. De la même manière, il devra pouvoir exécuter ses déplacements en ayant une précision (à définir) et une marge de résistance aux contraintes physique (à préciser). Par exemple, il devra être capable de se stabiliser et effectuer son vol autonome, avec une précision de 10 centimètres, et un vent limite de 30 km/h.
Choix techniques : matériel et logiciel
Afin de mener à bien notre projet, nous avons besoin de :
- Quadricopter Crazyflie 2.0 : 2
- Adaptateur debug pour Crazyflie : 2
- Moteur pour Crazyflie 2.0 : 4
- Jeu d'hélices pour Crazyflie : 1
- Jeu de 4 supports moteurs : 1
- Module Crazyradio PA 114990112 : 2
- Loco positioning deck : 2
- Flow deck v2 : 2
- 240mAh LiPo battery including 500mA USB charger : 2
- SD-card deck : 2
- Loco positioning node : 4
Au niveau logiciel, nous avons besoin de :
- Betaflight
- Matlab - Simulink
Liste des tâches à effectuer
A ce stade, nous avons définis notre projet en plusieurs axes :
- se documenter sur le fonctionnement d’un drone 4 hélices, appelé aussi quadrotor ou quadcopter
- modélisation d’un moteur brushless
- modélisation des quatre moteurs
- envoie des commandes sur les moteurs sur un banc de test
Calendrier prévisionnel
Diagramme de Gantt de notre projet :
Réalisation du Projet
Projet S6
Semaine 4
Tout d'abord nous sommes documentés sur les fonctionnalités du In tel Aero ready To Fly. Embarquant une carte Pixhawk, nous pouvons nous servir de Dronecode ou bien d'Ardupilot afin d'effectuer notre vol autonome. Nous avons une préférence pour Dronecode.
Qu'est-ce que Dronecode ?
Dronecode est une plateforme Open Source lancée par la fondation Linux. Elle fournit l'ensemble des outils nécessaire à la réalisation d'une application utilisant un drone. On dispose ainsi d'un contrôleur de vol (hardware), d'un pilote de vol (software), d'une station de contrôle (typiquement sur ordinateur), et d'une API pour développer notre pilote de vol. Ainsi, on a l'ensemble des outils pour contrôler notre drone, qui fonctionne les uns avec les autres car ils sont entièrement compatibles.
https://www.dronecode.org/about/
Qu'est ce que Ardupilot ?
Ardupilot propose un ensemble à la réalisation d'une application d'objet volant, comme Dronecode. Très répandu Ardupilot est utilisé dans plus d'un million d'appareils dans le monde. Il propose aussi une liste d'appareils compatibles et de logiciel permettant le contrôle et le suivi de notre drone.
Semaine 5
Dans une seconde partie, nous nous sommes concentrés sur les façons d'intéragir avec les valeurs des différents capteurs de l'intel aero. Comme il embarque de nombreux capteurs, ROS semble le plus adapté afin de pouvoir interagir avec les différentes valeurs renvoyés et demandées par nos capteurs.
Qu'est ce que ROS ?
Robot operating system (ROS), est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Le principe de base d’un ROS robotique est de faire fonctionner en parallèle un grand nombre d’exécutables qui doivent pouvoir échanger de l’information de manière synchrone ou asynchrone. Afin de répondre à cette problématique, ROS s’appuie sur plusieurs notions:
les nœuds: dans ROS, un nœud est une instance d’un exécutable. Un nœud peut correspondre à un capteur, un moteur, un algorithme de traitement, de surveillance… Chaque nœud qui se lance se déclare au master.
le master: le master est un service de déclaration et d’enregistrement des nœuds qui permet ainsi à des nœuds de se connaître et d’échanger de l’information.L’échange de l’information s’effectue soit de manière asynchrone via un topic ou de manière synchrone via un service.Les topics:un topic est un système de transport de l’information basé sur le système de l’abonnement / publication (subscribe / publish). Un ou plusieurs nœuds pourront publier de l’information sur un topic et un ou plusieurs nœuds pourront lire l’information sur ce topic.Les nœuds envoient ou reçoivent des messages sur des topics.
Les Services: le service en revanche répond à celle d’une communication synchrone entre deux nœuds.
Semaine 6
Nous avons contacté RS component et Mousser afin de nous renseigner sur la disponibilité du drone. De plus nous avons effectué le bon de commande suivant :
- batterie LiPo 4s 4000mah xt60(taille max 150x50x32 mm)
- le chargeur de la batterie
- un adaptateur micro usb (mâle) - usb (femelle)
- un câble micro hdmi - hdmi (mâle-mâle)
- un câble d'alimentation 12V DC 4A 5.5mm x 2.1mm barrel connector
- un adaptateur xt60 (femelle) - 1x jack 5.5mm (femelle)
- un hub usb 4 ports auto-alimenté
Cependant après avoir contacté Mousser, nous nous sommes aperçus que le drone était en fin de vie : cela semble être la raison pour laquelle le drone n'était plus disponible chez certain fournisseur. Tout est à refaire, le wiki, le cahier des charges, le positionnement, etc. Nous avons contacté RS component et Mousser afin de nous renseigner sur la disponibilité du drone : il nous a été conseillé de partir sur un autre modèle.
Semaine 7
Nous nous sommes rencontrés à de nombreuses reprises avec M. Nakrachi, en fin de journée, afin de trouver une solution le plus vite. Il nous fallait à tout pris un drone 'ready to fly', prêt à voler, et embarquant un module de déveleppoment open source. Pour ce faire, seul les drones avec une carte Pixhawk nous semblait adéquat. Cependant peut de drone 'ready to fly' sont disponibles. Ou ils ne sont plus produit, ou bien la carte a été intégré dans des drones avec du matériel non libre et une carte reprogrammé avec du code propriétaire.
Semaine 8
Analyse des degrès de liberté du Crazyflie
Nous sommes parvenus à trouver un nouveau drone : le Crazyflie 2.0. Nous avons refait notre wiki en conséquence et ajusté notre cahier des charges.
Tout d’abord, posons le cadre de notre étude. Nous allons étudier un drone à 4 rotors. Nous le représenterons selon le modèle suivant :
|
Les quadrotors existent sous deux formes : en croix et en plus
|
Afin de contrôler notre drone, nous allons poser certaines hypothèses quant aux capteurs nous renseignant sur l’état de notre drone en fonction du temps.
Hypothèses : nous travaillons avec un quad rotors, configuration en X
Au niveau des capteurs, on considère que nous avons :
- Capteurs de distance par ultrasons
- Caméra pour estimer les mouvements (horizontaux) du drone et sa vitesse
- Capteur de pression pour l'altitude
- IMU : Inertial Measurement Unit ; acceleration + gryroscope 3 axes → pour déterminer l'accélération, et l’inclinaison du drone selon les 3 axes du gyroscope
En posant ces hypothèses, nous pouvons analyser notre système de la façon suivante :
|
Semaine 9
Fonctionnent d’un quadcopter – principe de base
Afin de pouvoir réaliser un mouvement quelconque avec notre drone, il faut tout d’abord entraîner les moteurs opposés dans le même sens et les deux autres en sens contraire. Lors de notre étude, nous nous baserons sur le schéma suivant :
|
Au niveau du repère, nous adopterons une base cartésienne, de centre 0 :
|
Enfin, nous utiliserons les coupes suivantes :
|
Un drone possède 6 degrés de liberté
- Tangage (pitch) – axe Y
- Roulis (roll) – axe X
- Lacet (yaw) – axe Z
- Avant – arrière (foreward/backward) – axe X
- Droite – gauche (rigth/left) – axe Y
- Haut – bas (up/down) – axe Z
Schéma des 6 degrés de liberté :
|
Au cours de son vol, le drone est soumis à plusieurs forces :
|
- la traînée : force formée par le vent relatif, et qui s’oppose au déplacement
- la portance : force formée par l’incidence de la main et qui pousse la main vers le haut
- la traction : force formée par les moteurs induisant un mouvement vers l’avant
- poids : force exercée sur le drone du fait de la force de pesanteur
- l’incidence : angle formée par l’inclinaison de la main par rapport au vent relatif
- force de sustentation : composante verticale des résultantes des forces aérodynamiques s’exerçant sur le drone.
En tournant, les hélices vont engendrer une force de sustentation, qui va compenser le poids du drone. Lorsque cette force dépasse le poids du drone, le quadrocopter s’envole.
Semaine 10
Après avoir posé notre cade d’étude, passons à l’analyse des mouvements du drone : quelle commande envoyer aux moteurs pour réaliser un mouvement selon un des 6 degrés de liberté ?
Tout d’abord, intéressons-nous au lacet. Il s’agit d’une rotation du drone selon l’axe Z.
Pour ce faire, on augmente la vitesse de deux moteurs tournant dans le même sens. Les deux autres tournent à la même vitesse, mais moins vite.
|
Ensuite, le drone a la possibilité d’effectuer un roulis. Il s’agit d’une rotation du drone selon l’axe X. Pour ce faire, on augmente la vitesse de deux moteurs situés du même côté du drone. Les deux autres tournent à la même vitesse, mais moins vite.
|
De plus, le drone a la possibilité d’effectuer un tangage. Il s’agit d’une rotation du drone selon l’axe Y.
Pour ce faire, on augmente la vitesse de deux moteurs situés sur l’avant ou l’arrière de notre drone. Les deux autres tournent à la même vitesse, mais moins vite.
|
Après avoir étudié le tangage, roulis, lacet, étudions le mouvement vertical du quadrocopter. Par mouvement vertical, nous entendons un mouvement parallèle à l’axe Z, c’est-à-dire la montée en altitude ou la descente du drone. Pour ce faire, on doit augmenter simultanément et de façon égale les quatre moteur pour gagner en altitude et inversement pour redescendre.
|
Pour finir, étudions les mouvements horizontaux du quadrotor. Selon la configuration du drone (en « X »ou en « plus » ), et les stratégies de développement des fonctions de déplacement, ces mouvements se réalisent de plusieurs façons. Typiquement, le drone réalisera un lacet (rotation axe Z) et/ou roulis (rotation axe X), suivi d’un tangage (rotation axe Y) puis utilisera ces fonctions pour suivre une trajectoire rectiligne.
Pour ce faire, on augmente la vitesse d’un moteur et on diminue celle du moteur tournant dans le même sens. Les deux autres moteurs restent à la même vitesse, c’est-à-dire entre la vitesse du moteur que l’on a augmenté et celle du moteur que l’on a diminué.
|
|
Semaine 11
Simulation d'un moteur brushless sur Matlab
Nous nous sommes ensuite consacré à la modélisation d’un moteur brushless de notre Drone.
Un moteur brushless de notre drone peut être schématisé de cette manière:
Nomenclature :
- U : Tension au borne du moteur
- Rm : Résistance du moteur
- i : courant traversant le moteur
- Lm : inductance
- kfem : coefficient de force électro-motrice
- wh : vitesse de rotation du moteur
- Jm : inertie du moteur
- fem : force électro-motrice
Semaine 12
Analyse Simulink
Grâce à la modélisation faite la semaine d'avant, nous avons pu établir le schéma bloc sur Matlab/Simulink.
Voici le schéma :
Pour pouvoir étudier la réponse de notre système, nous devons disposer des coefficients nécessaire au fonctionnement du moteur.
Nous fixerons donc le point de fonctionnement I0, qui est le courant d’entrée du moteur, pour pouvoir obtenir les autres points de fonctionnement U0 et omega0. Il faut savoir que l’on a pris à 2,5A qui est une valeur choisis arbitrairement avec comme contrainte la valeur max du courant 4,2A et la valeur min de démarrage du moteur qui est de 0,8A. En consigne, nous lui envoyons une vitesse (200 rad/s « arbitrairement ») et voici la vitesse du moteur en sortie:
On remarque que notre système est en régime apériodique donc que son coefficient d’amortissement est supérieur à 1.
Il a un temps de réponse de 1,95s et un temps de monté 1,43s car on a la période qui vaut environ 0,65s (étude du schéma selon une réponse indicielle d’un système apériodique qui ressemble à celui d’un premier ordre).
Nous étudierons par la suite le système motorisé complet du moteur pour pouvoir asservir correctement les moteurs pour la deuxième année. Nous avons pour l'instant étudié qu'un seul moteur du drone.
Maquette
Afin de mettre en pratique le comportement des moteurs, nous avons réaliser une maquette. Pour ce faire :
1) nous avons assemblé le crazyflie, comme indiqué sur le site suivant :
https://www.bitcraze.io/getting-started-with-the-crazyflie-2-0/
2) ensuite, nous avons téléchargé l'application Crazyflie Client pour android :
https://play.google.com/store/apps/details?id=se.bitcraze.crazyfliecontrol2&hl=fr
3) on règle les paramètres de l'application de la façon suivante :
4) on fixe le drone sur une planche de bois, de taille 12x18cm à l'aide de 4 trombones. Astuce : tordre les 4 trombones de sortes à enrouler avec un crochet les supports moteurs et de l'autre côté ressérer la planche avec une forme de L.
NOTE 1 : nous avons marqué l'avant de notre drone avec un peu de rouge, car de loin, il nous est difficle de repérer l'avant du drone
NOTE 2 : notre montage nous permet d'observer, seulement, de manière qualitatif le comportement des moteurs, en effet, nous ne disposons pas d'informations temps-réels sur l'état des moteurs (vitesse, température etc.).
5) on envoie les commandes aux moteurs à l'aide de l'application
Afin de bien lire les captures d'écran, faire attention à la ligne "P : R : T : Y : ", situé au milieu de l'écran, ces lettres correpondent respectivement à : Pitch (tangage), Roll (roulis), Thrust (poussée), Yaw (lacet).
5.1) un lacet (rotation axe Z) dans un sens :
puis dans l'autre :
5.2) un déplacement horizontal dans un sens
un déplacement horizontal dans un autre sens :
Pour finir, on obtient :
commande moteur pour effectuer un déplacement horizontal
commande moteur pour effectuer un déplacement horizontal
commande moteur pour effectuer un lacet - sens 1
commande moteur pour effectuer un lacet - sens 2
Projet S7
Semaine 1
Objectifs du semestre 7
Cette semaine a été l'occasion pour nous de définir les objectifs de notre projet pour le semestre 7. Nous utilisons le Crazyflie 2.0, ainsi que le flow deck et l'antenne USB crazyradio.
Nous allons lors de ce semestre envoyer à notre drone des premières commandes Python en utilisant les librairies cflib. Nous allons aussi expliquer le fonctionnement des différents capteurs qui vont intervenir lors de la réalisation de notre projet. Le but final ést d'effectuer un vol autonome d'un point A à un point B en évitant les obstacles.
Voici les capteurs que nous allons étudier :
Flow deck v2 :
https://www.bitcraze.io/flow-deck-v2/
Multi-ranger deck : https://www.bitcraze.io/multi-ranger-deck/
Loco Positioning system : https://www.bitcraze.io/loco-pos-system/
Loco Positioning deck : https://www.bitcraze.io/loco-pos-deck/
Loco Positioning node : https://www.bitcraze.io/loco-pos-node/
Par ailleurs, nous utilisons aussi :
Antenne USB Crazyradio PA :
https://www.bitcraze.io/crazyradio-pa/
Battery charger : https://www.bitcraze.io/battery-charger-500mA/
Enfin, nous allons expliquer le fonctionnement des bibliothèques Python cflib, et plus précisément la mise en place de l'environnement de développement sous machine virtuelle, la mise à jour du drone et l'envoie de code Python à notre drone via l'antenne USB Crazyradio PA.
Cflib :
https://github.com/bitcraze/crazyflie-lib-python
Semaine 2
Capteur Multi-ranger deck
Introduction
Le Multi-ranger deck est un module contenant 5 capteurs lasers (haut, gauche, droite, avant, arrière) qui se fixe sur le dessus du drone. Il permet au drone Crazy-Flie de détecter des objets à proximité jusqu’à 4 mètres.Grâce à ce module et le Flow deck (capteur du dessous) le drone peut évoluer dans l’espace en détectant les éventuels obstacles. Ses 5 capteurs de distance IR sont les mêmes que celui présent sur le Flow Deck, il s’agit du VL53L1x ToF de chez STMicroelectronics®.
Fonctionnement
La mesure de distance est basée sur le principe de la triangulation :
Le rayon laser atteint l’objet sous la forme d’un petit point. L’impact du rayon laser sur l’objet est matérialisé sous la forme d’un petit point. Le récepteur du détecteur (ligne de photodiodes) détecte la position de ce point. En fonction de la distance, l’angle d’incidence varie et également la position du point laser sur le récepteur. La ligne de photodiodes est analysée par microcontrôleur intégré. Selon la répartition de la lumière sur la ligne de photodiodes, le contrôleur est en mesure de calculer la valeur de l’angle d’incidence et, en se référant à cette valeur, de déterminer la distance par rapport à l’objet. Cette distance est alors transférée soit vers un port de communication série soit transformée en un courant de sortie proportionnel à la distance.
Les capteurs lasers sur le Multi-ranger deck sont des multi-spots (Mesures stables sur surfaces non uniformément brillantes et extrêmement rugueuses de plus de 600 valeurs avec une ligne laser extra longue < 72 mm). Le signal reçu est traité grâce au DSP(Digital Signal Processeur) intégré dans le microcontrôleur (Cortex-M4).
Source (plus d'information sur la triangularisation) :
Loco Positioning System
Intérêt de ces capteurs :
Jusqu’à maintenant, nous n'avons toujours programmé le drone en position relative, c'est-à-dire que le drone ne se repérer pas dans l'espace par rapport à un repère fixe dans l'espace, mais seulement par rapport à sa position précédente. Pour le localiser nous pouvons utiliser un GPS, mais le crazyflie étant un petit drone d'intérieur, il est difficile de le localiser avec un GPS. Pour ce faire, il faut utiliser un réseau de capteurs pour la localisation "in door" (en intérieur) de notre drone.
Constitution du système:
Le Loco Positioning system permet donc de trouver la la position absolue du drone dans l’espace. La base de ce système est composé d’un ensemble "d’ancrages" réparties dans la pièce. L’autre partie du système correspond à une ou plusieurs balises fixés sur le drone , appelés "Tags".
Principe de fonctionnement :
Le système envoie par radiofréquence des messages court entre les Ancrages et les Tags placés dans la pièce. Le système peut donc ensuite mesurer la distance entre chaque Ancrage et Tag et ainsi déterminer la position du drone dans la pièce. Pour évaluer cette distance entre les Ancrages et les Tags, différents protocoles peuvent être utilisés.
Protocoles utilisables avec le Crazyflie :
https://www.bitcraze.io/loco-pos-system/
Principe et algorithmes :
https://www.linuxembedded.fr/2018/06/la-localisation-indoor-2/
Le Loco Positioning Deck:
Le Loco Positioning Deck est une expansion de la plateforme du Crazyflie 2.X qui réalise la fonctionnalité du Tag dans le Loco Positioning System.
Le Loco Positioning Node:
Le Loco Positioning Node est un nœud Multi fonctionnel dans un Loco Positioning system, qui peut occuper la fonction de Tag ou d’Ancrage, donc être fixé sur le drone ou être réparti dans la pièce.
Capteur Flow Deck V2 : VL53L1x ToF + PMW3901
Le flow deck V2 est une petite carte électronique que nous venons placer en dessous du drone.
Cette carte permet d'évaluer la distance du drone par rapport au sol et d'obtenir sa position relative. Elle est composée de deux capteurs : le VL53L1x ToF de chez STMicroelectronics®, et le capteur optique PMW3901 de chez PixArt®.
Le capteur VL53L1x ToF mesure la distance entre le drone et le sol. Il envoie un laser invisible à l'oeil nu de longeur 940nm (capteur IR), et calcul le temps qu'il met pour revenir à la base.
Il possède les caractéristiques suivantes :
• Taille : 4.9x2.5x1.56 mm
• Longueur d'onde : 940 nm
• Fréquence : 50 Hz
• Distance max de mesure : 4 mètres
Ce capteur mesure la distance sur le principe de triangularisation, pour plus de détails, voir la partie « Multi-ranger deck
Datasheet :
Le capteur optique PMW3901 utilise la méthode de flux optique pour déterminer la direction dans laquelle se déplace le drone.
Il possède les caractéristiques suivantes :
• Taille : 6x6x2.28 mm
• Distance minimale pour fonctionner : 80mm (du à la distance focale de la lentille de la caméra)
Fonctionnement :
Tout d'abord on a une petit laser qui va éclairer en permanence le sol. En parallèle une minuscule caméra va prendre en photo le sol qui est pointé par le laser. Ensuite un microprocesseur compare les clichés entre eux et arrive à estimer la direction et la vitesse de déplacement du drone. C'est exactement le même fonctionnement que l'on retrouve dans les souris d'ordinateur, en les retournant, on peut apercevoir une petite lumière rouge. La caméra a une très faible définition, dans l'ordre de 8x8 pixels, 16x16... etc
Par exemple, si on considère l'exemple suivant :
Si on considère par exemple que le flow deck analyse les images 5 par 5, et que chaque cliché est pris dans une période de T = 100ms. En combinant les images 5 par 5, on peut observer que le drone s'est déplacé vers la droite à une vitesse de (x0 - x4) / 5*T selon l'axe X et( y0 - y5) / 5*T selon l'axe Y.
Datasheet :
Semaine 3
Mise en place de l'environnement de développement du Crazyflie.
Matériels utilisés :
- 1x drone Crazyflie
Assemblage : https://www.bitcraze.io/getting-started-with-the-crazyflie-2-0/
- 1x Bitcraze Flow Deck
Branchement : https://www.bitcraze.io/getting-started-with-expansion-decks/
Fonctionnement : https://www.bitcraze.io/getting-started-with-flow-deck/
- 1x Bitcraze Crazyradio PA
Système d’exploitation pour installer la machine virtuelle :
- Windows 7, 8, et 10 (tutoriel dans ce PDF)
- L’environnement peut être mis en place aussi sur Linux et OS X, avec ou sans machine virtuelle (non traités ici)
Ressources nécessaires :
- La machine virtuelle tourne sous Xubuntu et utilise au minimum 1Go de Ram et 1 Thread
- Configuration minimale que nous recommandons pour la machine hôte : 6Go de Ram et un CPU à 4 threads (on allouera 2 Go de RAM et 2 threads à notre machine virtuelle)
Documentation :
- Site internet : https://www.bitcraze.io/getting-started-with-the-crazyflie-2-0/
- Wiki : https://wiki.bitcraze.io/
- Forum : https://forum.bitcraze.io/
- Github : https://github.com/bitcraze
- Pour utiliser PX4, Betaflight, ROS… etc : https://www.bitcraze.io/external-projects/
- Blog , nouveauté, travaux de recherche, etc. : https://www.bitcraze.io/blog/
Téléchargement
1.1. Téléchargement de VirtualBox
Télécharger l’exécutable et le pack d’extension de VirtualBox :
VirtualBox 6.0.12 platform packages > Windows hosts
VirtualBox 6.0.12 Oracle VM VirtualBox Extension Pack > All supported platforms
https://www.virtualbox.org/wiki/Downloads
1.2. Téléchargement de la machine virtuelle de Bitcraze
Télécharger la dernière version sur le GitHub de Bitcraze
Bitcraze VM 2018.12 > Download link (2.9Gb)
https://github.com/bitcraze/bitcraze-vm/releases/
1.3. Téléchargement du driver de l’antenne USB Bitcraze Radio PA
Aller dans la partie « Download » un peu plus bas :
Updated 2018.07.26 > Zadig 2.4 (4.9Mb)
Installation
2.1. Installation de VirtualBox et du pack d’extension
1) Installer VirtualBox : il faut les privilèges administrateurs On clique sur "VirtualBox.... .exe" (laisser les paramètres par défaut si pas de raison particulière pour les changer)
2) Ajouter le pack d’extension : il faut les privilèges administrateurs* NOTE : pour utiliser la machine virtuelle, nous n’avons pas besoin des privilèges administrateurs, il les faut juste lors de l’installation du logiciel et du pack d’extension
Tout d’abord lancer VirtualBox en tant qu’administrateur :
Dans VirtualBox, cliquer sur Fichier > Paramètres > Extensions > "Symbole +" et choisir le pack d'extension Ensuite parcourir l’arborescence des fichiers jusqu’au répertoire contenant le pack d’extension que l’on a téléchargé
2.2. Installation du driver pour l’antenne radio USB
1) Brancher l'antenne sur le port USB
2) Attendre le message d'erreur de Windows disant qu'il ne trouve par le driver
Note : parfois aucun message n’apparaît, mais cela n’est pas grave
3) Quitter le message disant « Windows n’a pas pu trouver le driver »
4) Laisser brancher l'antenne sur le port USB !
5) Cliquer sur "zadig-2.4.exe" : il faut les privilèges administrateurs
6) Une fenêtre apparaît, on doit voir écrit "Crazyradio USB Dongle"
7) Sélectionner "linusb-win32 (v1.2.6.0)" (important : bien choisir cette version !)
8) Et cliquer sur installer
2.3. Installation de la machine virtuelle sous VirtualBox et configuration
1) On ouvre VirtualBox (plus besoin d’être administrateur), puis on clique sur "Importer" et ensuite on choisit la VM que l'on a téléchargé On laisse tous les paramètres par défaut " (sauf si on a une raison particulière pour les changer)
2) Cliquer sur la nouvelle fenêtre « BitcrazeVM » et ensuite sur « Configuration »
Cliquer sur configuration > USB > "Symbole plus" > Bitcraze Crazyradio PA USB Dongle" Si on doit ajouter une manette USB, il faut aussi l'ajouter
Semaine 4 - Chorégraphie
Déplacement selon les 6 degrés de liberté (chorégraphie)
Dans un premier temps, nous avons mis en place une chorégraphie retraçant les 6 degrés de liberté du drone. A tour de rôle, le drone va effectuer un mouvement selon l’un de ses 6 degrés de liberté.Cela nous a permis de prendre en main la librairie cflib.
Nous avons pu aussi apporter un regard critique sur notre code. En effet nous avons remarqué que lors de l’utilisation de structure trop complexe, le drone recevait trop tard ses instructions, entrainant des mouvements saccadés. De plus la lecture des différents capteurs met du temps à retourner la valeur.
En travaillant par scrutation, cela doit être pris en compte et il faut bien choisir à quel moment lire la valeur des capteurs retournés par le drone. Nous avons utilisé la fonction send_hover_setpoint. Par exemple :
Décollage : on augmente progressivement l'altitude.
On définit l'altitude à atteindre (la consigne) et le pas de boucle, c'est-à-dire l'incrément qui va nous permettre d'atteindre l'altitude consigne.
definir : decollage(pas_de_boucle)
consigne <- 0.4m
pas_de_boucle <- 1/consigne * 10
Pour i allant de 0 à 10 :
altitude <- i/pas_de_boucle
attendre 100ms
Fin Pour
Par la suite, nous allons nous servir de ces algorithmes pour définir des fonctions de déplacement vers la gauche, droite, l’avant, l’arrière... qui seront réutilisés tout au long du projet pour le déplacement du drone.
Le fait de définir nos propres fonctions de déplacement au lieu d'utiliser celles fournies dans les librairies cflib, nous permettent de mieux paramétrer nos déplacement (par exemple un décollage plus doux), mais surtout de pouvoir intérrompre directement nos mouvement en cas de détection d'un obstacle. Nous gérons directement l'évaluation de l'obsatcle au cours du déplacement, par exemple :
definir : mouvement_gauche(vitesse, temps, altitude)
y<=0
tant que y < 10*temps
Si est_proche(capteur_gauche) alors
retourner -1
Fin Si
send_hover_setpoint(vitesse,0,0,altitude)
attendre 100ms
Fin tant que
retourner 0
vitesse en m/s, temps en seconde, altitude en mètre
La fonction send_hover_setpoint(vx, vy, yawrate, zdistance) prends en paramètre :
- vx : vitesse de déplacement horizontale selon l’axe X (m/s)
- vy : vitesse de déplacement horizontale selon l’axe Y (m/s)
- yawrate : vitesse de rotation selon l’axe Z (degrés/s), sens positif = sens horaire
- zdistance : altitude à atteindre en vol (mètre)
Après avoir défini nos 6 fonctions de déplacement, nous obtenons le résultat suivant :
Semaine 5
Dans cette partie, on définit 6 fonctions de déplacement qui décrivent les mouvements suivants : décollage, atterrissage, gauche, droite, avant , arrière. Pour ce faire, on utilise les algorithmes définis dans la section « Déplacement selon les 6 degrés de liberté ». Ces fonctions prennent en paramètre une vitesse, un temps d’exécution, et une altitude. Par exemple, si on veut se déplacer de 30 centimètres sur la gauche, on fera appel à la fonction gauche(0.3 , 1 , 0.5). La fonction gauche a pour prototype gauche(vitesse, temps, altitude). La vitesse est un entier strictement positif, exprimé en m/s, le temps est un entier positif exprimé en seconde, et enfin l’altitude est exprimée en mètre. Ainsi, gauche(0.3 , 1, 0.5), déplacera le drone à une vitesse de 0.3m/s pendant une 1 seconde à une altitude de 0.5 mètre. Dans un seconde temps, on définit la fonction is_close(entier x) qui retourne un booléen. Elle renvoie True si x est inférieur à notre seuil, False si non. X est un entier positif exprimé en mètre. Le seuil est la distance à partir de laquelle on doit éviter l’obstacle. Par exemple, nous avons défini notre seuil à 20 centimètres : si un objet se situe à 20 centimètres au plus de notre objet, alors il est considéré comme un obstacle et on doit ainsi l’éviter.
Une fois que nous avons défini les fonctions de déplacement et notre fonction is_close(), nous les utilisons dans une boucle infinie qui correspond à la séquence de vol de notre drone. Ici, pour notre étude, nous allons considérer que notre drone est en vol stationnaire (c’est-à-dire qu’il reste à une altitude constante sans se déplacer dans aucune direction) pendant une durée indéterminée. Au cours de son vol, s’il détecte un obstacle, il se déplace automatiquement de 30 centimètres dans le sens opposé. Au cours du vol nous enregistrons les valeurs des capteurs dans tableaux.
Dans un premier temps, voici les valeurs des capteurs d’altitude et de hauteur en fonction du temps lors de la session de test. Le capteur d’altitude est un capteur évaluant la distance entre le sol et le drone. Le capteur de hauteur est en fait un capteur évaluant la distance entre le drone et les objets situés au-dessus du drone.
Ensuite, nous plaçons plusieurs obstacles sur la gauche du drone de manière répétée. Nous observons que le drone détecte un obstacle, puis s’en éloigne, jusqu’à ce qu’un nouvel obstacle survienne et ainsi de suite.
Pour finir, nous plaçons des objets à l’arrière du drone à plusieurs intervalles de temps. Là encore, nous observons que le drone détecte l’obstacle, puis s’en éloigne, et ainsi de suite.
Semaine 6 et Semaine 7
Dans la section précédente, nous avons établi un algorithme permettant d’éviter un obstacle lorsque le drone était en vol stationnaire. Maintenant, nous allons supposer que le drone effectue un mouvement rectiligne uniforme vers l’avant pendant une durée indéterminée. Au cours de son vol, s’il détecte un obstacle vers l’avant, il doit pouvoir le contourner, et reprendre le cours de son vol, sur le même axe rectiligne, selon une vitesse constante. Pour ce faire, nous devons implémenter un algorithme permettant de détecter l’obstacle, de l’éviter, puis de le franchir, et enfin revenir sur le même axe que précédemment. Par la suite, nous allons présenter l’idée générale de l’algorithme que nous avons implémenté.
Nous obtenons le résultat suivant :
Bonus
Afin de protéger notre drone lors de la programmation des algorithmes d'évitement d'obstacle nous avons imprimé des protections d'hélices au Fabricarium.
Sources :
https://www.thingiverse.com/thing:2554194
https://www.thingiverse.com/thing:1151252
Bilan et perspective pour le semestre 8
Au cours du semestre 8, notre travail va se concentrer sur la mise en place d'un réseau de capteurs de localisation d'intérieur "in door". En effet, jusqu'à présent nous avons utilisé la position relative du drone pour le programmer (c'est-à-dire que le repère était situé au niveau du centre de gravité de celui-ci). Avec le réseau de capteurs "Loco Positionning System", nous aurons un repère cartésien fixe, ancré dans la salle, et le drone sera assimilé à un point se déplaçant dans le repère fixe.
Enfin, pour résumer, au cours du semestre 7 nous avons redoublé d'efforts afin de pouvoir avoir un drone apte à évoluer dans le réseau de capteurs que nous allons mettre en place au S8. En effet, nous avons seulement reçu tout le matériel en septembre 2019, nous avons donc dû anticiper tout la partie capteur d'obstacle et programamtion, afin d'être prêt pour le S8. Nous avons fait, entre autres :
1) Mise en place de l'environnement de développement sous machine virtuelle : c'est le seul outil qui contient tous les logiciels et drivers à jour. Nous aurions pu directement mettre en place cet environnement sous Windows mais nous aurions eu certains programmes non mis à jour.
2) Documentation sur les librairies cflib : nous sommes rendus compte qu'il fallait programmer nos propres fonctions de déplacement afin de mieux contrôler le mouvement du drone et d'évaluer les capteurs de distance directement lors de son déplacement
3) Mise en place d'un alogrithme d'évitement d'obstacle : nous avons vu que les capteurs mettent un temps non négligeable pour envoyer leur valeur au PC, aussi il est important de ne pas scruter trop régulièrement l'état des capteurs sous peine de perdre le contrôle du drone. En effet, le drone fonctionne seulement quand on lui envoie des commandes, si à t=0 on lui donne une consigne en vitesse, à t+t1, il faut lui renvoyer cette consigne pour qu'il continue à l'exécuter... Si t1 est trop grand, alors le temps entre la 1ere consigne et la 2eme sera trop grand, et on aura un dela t pendant lequel le drone ne recevra pas de consigne, les moteurs se coupent et il crash.
4) Après avoir pris en compte les contraintes temporelles présentées en 3), nous nous sommes servies des fonctions de déplacement définies en 2) pour proposer un premier algorithme de contournement d'obstacle... Cependant il reste encore beaucoup de travail à effectuer là-dessus. En effet se reposer entièrement sur la valeur des capteurs peut poser problème quand l'obstacle n'est pas régulier. De plus notre alogrithme définit seulement un contournement vers la droite, qu'en est-il si un obstacle se trouve également sur la droite ?
Projet S8
Objectifs du semestre 8
Le premier objectif du projet était de comprendre le fonctionnement d'un quadcopter : par l'intermédiaire de simulation Matlab, de schéma que nous avons mis sur le wiki et par confirmation avec nos expérimentations sur une maquette, cet objectif a été rempli au cours du semestre 6.
Le second objectif du projet était de pouvoir programmer des algorithmes de déplacement pour que le drone se déplace d'un point A à un point B : à travers nos 3 codes python, nous avons fait déplacer le drone selon ses 6 degrés de liberté (chorégraphie), nous l'avons fait éviter les obstacles, et enfin nous avons réussi à le faire contourner les obstacles (cf. vidéos et schémas sur le wiki).
Semestre 8 : nos objectifs étant atteints, nous avons défini une nouvelle orientation pour notre projet. Lors de notre soutenance à la fin du S7, on nous a conseillé de creuser un peu plus dans l'architecture matérielle et logicielle du drone afin de mieux comprendre son fonctionnement et éviter l'utilisation d'un PC et de lib python pour faire voler le drone. Ce ne sont pas des fonctionnalités disponibles par défaut sur le drone, mais son code source étant open source, nous allons essayer de nous pencher dessus pour voir s'il y a quelque chose à faire dans ce sens-là. De plus nous allons mettre en place un réseau de capteur nous permettant de localiser la position de notre drone par rapport à un repère fixe cartésien (x,y,z).
Architecture matérielle
Le Crazyflie est constitué des composants suivants :
- STM32F405: Cortex-M4, 168 MHz, 192 kB SRAM, 1 MB flash
- nRF51822: Cortex-M0, 32 MHz, 16 kB SRAM, 128 kB flash
- MPU-9250: centrale à inertie 9 axes (IMU)
- LPS25H: capteur de pression
- 8 kB EEPROM.
- port micro USB
- ports d’ expansion : I2C, UART, SPI, GPIO
Le nRF51
Le nRF51 contient un Cortex-M0, 16kB de RAM et 256kB de Flash, qui lui permettent de gérer la communication radio et la gestion d’alimentation du drone. Cependant il n’est pas assez puissant pour faire tourner les algorithmes de contrôle de vol du drone.
Le STM32F405
Le STM32F405 est composé d’un Cortex-M4, de 196kB de RAM et de 1MB de Flash. Le cortex M4 lui permet de faire des calculs puissants, d’exécuter des algorithmes pour contrôler son vol.
Protocoles de communication
Le nRF51 permet de communiquer avec le drone par Bluetooth et par CRTP (Crazy RealTime Protocol). Le Bluetooth sert à contrôler le drone via l’application smartphone développée par le constructeur. Le CRTP, Crazy RealTime Protocol, est un protocole de communication qui permet de communiquer entre une antenne, la CrazyRadio PA, et le drone, en 2,4GHz. La CrazyRadio PA est une antenne que l’on branche en USB sur notre PC.
Rôles des microcontrôleurs
Le nRF51 et le STM32 communiquent entre eux par UART. Le nRF51 agit en tant qu’esclave et le STM32 en tant que maître.
Le nRF51 gère :
- le bouton (physique) ON/OFF
- l’alimentation du système (STM32, capteurs et cartes d’extensions)
- le chargement de la batterie
- communication radio et Bluetooth (protocoles Bluetooth et CRTP)
- détecter, installer les cartes d’extensio
Le STM32 gère toutes les autres tâches du drone, par exemple :
- contrôle et régulation des moteurs
- contrôleur de vol
- mesures (lecture des valeurs des capteurs)
- Les tâches implémentées dans le firmware
Architecture logicielle
Le firmware du drone est open source, il est accessible sur le git du constructeur. Le firmware est constitué d’un ensemble de tâches utilisant FreeRTOS. Toutes les tâches du drone sont temps-réels et implémentées sous formes de tâches FreeRTOS. Pour avoir une idée de ces tâches, voici par exemple voici les principales tâches de stabilisation du drone et de contrôle du système sous forme de diagramme de bloc :
Lien du firmware du drone : https://github.com/bitcraze/crazyflie-firmware
Réseau de capteur pour la localisation en intérieur
Nous avons commencé par mettre en place le réseau de capteur nécessaire pour travailler avec la position absolue (i.e. dans un répère fixe) du drone. Le réseau de capteur utilisé est le loco positioning system. Ce système a été présenté durant le semestre précédent. Pour rappel, le Loco Positionning System est composé de deux types de capteurs :
-les "ancrages", qui sont repartis dans la pièce. (6 en tout)
-le capteur "node" qui se situe sur le drone.
Les ancrages possèdent chacun un numéro précis et doivent être placés selon une disposition particulière dans la pièce. Avant de placer les capteurs dans la pièce, nous avons flashé nos ancrages afin de leur attribuer un numéro à l'aide du logiciel LPS node firmeware.
Nous avons ensuite fixé les ancrages dans la pièce à l'aide de boites en bois que nous avons fabriqués au fabricarium.
Les ancrages sont alimentés par une batterie externe :
Le capteur "node" est placé sur le drone de cette manière :
Nous avons décidé de placer les ancrages dans la pièce de cette manière les ancrages :
Vol autonome
Test des capteurs avec Python
Une fois notre réseau de capteurs installé, nous avons fait quelques tests afin de nous assurer que tout était fonctionnel. Comme nous avons rencontré de nombreux problèmes, une partie du groupe s’est occupé du réseau de capteurs et des tests avec Python et une autre de l’implémentation de tâche sous FreeRTOS.
Les limites du système de positionnement et des valeurs que l’on reçoit
Pour visionner la valeur des capteurs, nous sommes obligés d’utiliser le logiciel Crazyflie Client. Nous ne pouvons pas avoir de retour sur les capteurs une fois que le drone est en vol. En effet, pour que le drone décolle, il ne faut qu’aucun autre programme ne communique avec lui. Comme le code est interprété sur notre ordinateur puis envoyé sur le drone, il ne faut pas que le logiciel communique avec le drone au même moment, car seul un programme à la fois peut envoyer des paquets au drone. Donc si le logiciel envoie des paquets, on ne peut pas exécuter notre code python et vice versa.
Le problème est que l’on n’arrive pas à implémenter un code python afin d’avoir les coordonnées en x,y,z pendant le vol, on est dépendant du logiciel pour cela. Le drone envoie seulement des données brutes qui sont traitées par filtre de Kalman. Nous n’avons pas réussi à ce jour à tirer des informations exploitables sur ces données bruts. Une piste pourrait être de se concentrer davantage sur ces données afin d’en tirer quelque chose.
D’un autre côté on ne peut pas exécuter de code depuis le logiciel Crazyflie Client, impossible donc avec ce logiciel d’évaluer les valeurs de retour de ces capteurs tout en exécutant du code.
1. Problème au sol
Au repos, lorsque l’on étudiait les valeurs de retour des capteurs, ils indiquaient une valeur négative en Z ou très élevé (supérieur à 3 mètres). Nous avons étudié la position des capteurs et nous nous sommes rendu compte que les capteurs posés au sol étaient situés légèrement au-dessus du drone. Pour résoudre ce problème nous avons décidé de surélever le drone en le posant sur le carton afin qu’il soit situé au-dessus des capteurs lorsqu’il est posé sur le sol.
2. Problèmes en vol
Afin de tester nos capteurs en vols, nous avons essayé de lancer un code Python.
En cours de vols, notre drone est incapable de suivre les coordonnés qui lui sont imposées. Dès qu’il décolle il se crash. Nous avons dû l’attacher afin de réduire les dégâts. D’après les limites que nous avons décrites plus haut, il nous est impossible de savoir les coordonnées que le drone a lues avant de se crasher. La seule chose que l’on peut savoir est la valeur des coordonnées que l’on a donnée comme consigne à notre drone.
Afin de résoudre ce problème, nous avons essayé de diminuer la précision qui était de 1mm initialement à 1 cm. Ce que nous appelons précision est l’écart relatif entre la position que l’on veut atteindre et la position où l’on est. En réduisant la précision, nous avons espéré avoir un mouvement plus souple. Malheureusement, nous n’avons pas obtenu de résultats fructueux avec cette méthode.
Une seconde méthode, que nous n’avons pas pu tester, consiste à changer les algorithmes de calculs de position.
Implémentation d’une tâche de vol autonome sous FreeRTOS
La programmation de tâche autonome n’est pas permise par le constructeur. Nous avons accès au firmware, mais il sert surtout à développer des drivers pour intégrer de nouvelle carte d’extension pour le drone, comme par exemple : https://www.bitcraze.io/products/flow-deck-v2/
Cependant, comme le drone est composé de mémoire flash, avec un firmware open source et une architecture matérielle connue, il est envisageable de programmer des tâches FreeRTOS. Comme le constructeur ne le recommande pas, il n’a pas documenté son wiki sur la façon d’implémenter ses propres tâches temps-réelles. Nous nous sommes documentés sur une thèse de master écrite par Mr Luke Beumont Barrett.
Il est possible de programmer des tâches temps-réelles en écrivant notre code FreeRTOS dans le répertoire Crazyflie-firmware/src/modules/src du firmware du Crazyflie. Ensuite il faudra déclarer notre tâche dans le config.h qui se trouve dans crazyflie-firmware/src/config.
https://github.com/bitcraze/crazyflie-firmware/tree/master/src/modules/src
https://github.com/bitcraze/crazyflie-firmware/blob/master/src/config/config.h
Nous avons seulement eu le temps de lire le mémoire et d’implémenter l’un des exemples de code fourni dans ce mémoire. Nous n’avons pas pu aller plus loin en raison de la fermeture des écoles dû au COVID19.
Covid 19
(Situation du projet le 13/03/2020)
Notre projet se basant sur un réseau de capteur vissé sur les murs (support en aluminium) de la C305, il nous est impossible de poursuivre sur les mêmes objectifs. De plus, comme nous programmions des tâches autonomes pour notre drone, il est impératif d'avoir une salle avec des filets (comme la C305).
Nous allons donc revoir les objectifs de notre projet.
(Situation du projet le 25/03/2020)
Suite à l'impossibilité de poursuivre le projet initial, un nouveau projet nous a été confié par Mr. Redon.
Objectif du nouveau projet
L’objectif est de modéliser puis simuler un drone sous Godot avec une régulation externe sous Simulink. A partir de l'inclinaison du drone, Simulink doit pouvoir envoyer une consigne sur les quatres moteurs, afin de pouvoir réguler le drone sur Godot.
Dans le moteur graphique Godot nous devons modéliser un drone (son aspect), l'effet de chaque moteur à une vitesse donnée (équations dynamiques) et un "capteur" qui donne l'inclinaison du drone. On se limitera à l'assiette du drone, on ne tente pas un déplacement contrôlé.
Les valeurs des 4 moteurs doivent pouvoir être donner via UDP. De plus via une requête en UDP nous devons être en mesure d’envoyer la valeur de l’inclinaison du drone.
Nous avons défini le projet en 4 étapes :
- Modélisation d’un drone quadricoptère sous Godot (simulation physique)
- Calcul avec Simulink des vitesses des 4 moteurs en fonction de l’inclinaison et de la vitesse de déplacement en entrée
- Communication Godot <-> Simulink en boucle par UDP
Godot
Dans un premier nous avons téléchargé puis installé Godot. Certains membres du groupe ont eu du mal à installer Matlab à cause de leur connexion wifi et aussi de la taille (SSD de petite capacité). Nous sommes donc passés à Godot le temps que tout le monde puisse l'avoir sur son PC.
Nous avons utilisé plusieurs scènes pour pouvoir simuler le drone, les voici :
1.Une scène nommée "le_drone" de type KinematicBody (pour les déplacements 3D), à l'intérieur : un drone importé depuis internet (format .obj), et un contour (CollisionShape) qui nous permettra d'interagir avec d'autre solides (typiquement poser le drone sur le sol). Il y a différentes manières de définir les contours, nous avons choisi un cube qui englobe le drone pour faciliter son contact avec le sol.
2.Une scène nommée "le_sol" de type StaticBody, à l'intérieur : un pavé de couleur verte, et des contours qui épousent la forme du sol
3.Une scène principale "Environnement global" de type Spatial (environnement 3D), à l'intérieur, on instancie nos scènes "le_drone" et "le_sol" en tant qu'enfant de notre scène principale. On définit aussi 2 caméras : une caméra principale, et une caméra secondaire qui sera affichée en bas à droite lors de la simulation.
Enfin, on place notre drone et nos caméras dans l'espace. Et puis on écrit un script pour faire déplacer notre drone (juste pour apprendre les commandes de base). Dans notre script on peut faire déplacer le drone linéairement en donnant une vitesse de déplacement en x,y,z. On peut aussi lui donner un angle d'inclinaison en donnant une valeur en radian.
Communication UDP
Nous avons parallèlement travaillé sur la partie communication UDP. Nous avons d'abord créé un serveur et un client sur Matlab.
Nous avons ensuite réalisé le même travail sur Godot, en programmant un serveur et un client.
Nous devons maintenant faire échanger des données entre Matlab et Godot via une communication UDP.
Pour la première simulation Matlab (simulation des 4 moteurs sur Simulink), nous avons tout d'abord établi un protocole qui définit le type du message envoyé et son contenu entre Matlab et Godot. Concernant la communication dans le sens Godot → Matlab, le message envoyé contient en tout 5 informations, qui seront envoyées à la suite. Le protocole est le suivant :
- le mot "Start" qui indique le début d'une trame.
- Vitesse angulaire phi
- Vitesse angulaire psi
- Vitesse angulaire theta
- Vitesse de translation sur z
les valeurs des vitesses des moteurs et angulaires sont des floats.
Le client Godot envoie ces données sous formes de chaines de caractères. Elles sont converties sous la forme de float par le serveur Matlab à l'aide de la méthode str2double. Ces données seront exploitées par la suite lors de la régulation.
Le Client Matlab quant à lui envoie six données:
- le mot "Start" qui indique le début d'une trame.
- Vitesse du moteur 1
- Vitesse du moteur 2
- Vitesse du moteur 3
- Vitesse du moteur 4
- le mot "quit" qui indique la fin d'une trame.
Les vitesses des quatre moteurs qui seront appliquées sur le drone dans la simulation Godot. Ces vitesses sont envoyées sous forme de chaîne de caractères et converties en float par le serveur Godot.
Voici notre script Godot qui assure le rôle de serveur.
Nous intégrons nos clients et serveurs UDP Godot dans notre script de simulation Godot et nos clients et serveurs UDP Matlab dans un script Matlab dans lequel on récupère des valeurs de moteurs transmises par la première simulation effectuée sur Simulink (partie Matlab/Simulink plus bas dans le wiki). La communication est en forme de boucle entre Matlab et Godot.
Dans la simulation Godot, le drone est à l’arrêt jusqu’à ce que le script Matlab lui envoie les valeurs des 4 moteurs. On observe alors le drone décoller. Le client UDP présent sur Godot envoie en continue les valeurs des vitesses des 4 moteurs du drone ainsi que les valeurs des vitesses angulaires. Ces données sont récupérées par le Serveur UDP Matlab qui écoute en continue sur le port.
Concernant le deuxième script simulink qui gère la régulation en cas de perturbation, les données échangées via UDP sont différentes. Godot envoie :
- le mot "Start" qui indique le début d'une trame.
- Le moment du vent selon X
- Le moment du vent selon Y
- Le moment du vent selon Z
Le script Matlab envoie lui les données des quatre moteurs qui permettent de réguler le drone.
Voici un exemple de données envoyées par le client Godot et récupérées sur Matlab :
Data , Data 1, Data 2 : moment du vent selon x,y et z
Cette communication UDP est utilisée dans les scripts VariableDrone.m (simulation des moteurs sous Simulink) et resolution_equation.m (régulation du drone), les résultats sont présentés à l'aide de vidéos à la suite du wiki.
Modèle physique du drone sur Godot
Pour modéliser le drone, nous travaillerons dans 2 repères, un fixe Oned (earth frame), et un mobile Oabc (body frame).
Dans ces deux repères, on définit 2 vecteurs :
qui contient la position linéaire et angulaire du drone dans le repère fixe.
qui contient la vitesse linéaire et angulaire du drone dans le repère mobile.
En entrée, nous prenons les vitesses des 4 moteurs qui nous permettront de calculer les forces et moments générés par ces vitesses.
avec
- ft : force de poussée verticale
- τx,y,z : les moments selon x,y,z
- l : distance moteur – centre du drone
- d : facteur de trainée (drag coefficient)
- b : facteur de poussée (thrust coefficient)
- Ωn : la vitesse du moteur
Pour les valeurs de d, l, b de l’équation (2.16) nous prendrons celles du Crazyflie obtenues pages 12 et 13 de ce papier : https://arxiv.org/pdf/1608.05786.pdf
De même pour les éléments de la matrice d’inertie, diagonale, car on considère que notre drone a deux plans de symétrie :
Enfin après avoir défini nos repères, nos constantes et nos entrées, on modélise le modèle linéaire du drone :
Avec les perturbations du vent définies par :
Après avoir implémenté l’équation 2.36 en se basant sur 2.16, 2.33, on procède à quelques tests afin de vérifier si le modèle est correct et nous permet bien de simuler les 6 degrés de liberté du drone. Pour ce faire, nous nous baserons sur le travail que nous avons effectué au semestre 6. En effet nous avions défini les 6 degrés de liberté du drone en fonction de la vitesse de ses 4 moteurs.
Ici, nous avons relevé les vitesses angulaires et linéaires dans le repère fixe en fonction des vitesses des 4 moteurs ( = Vmn dans notre code, = Ωn dans les équations) afin d ‘observer si oui ou non on obtient nos 6 mouvements.
Pour rappel notre repère fixe est le suivant :
Pour les vitesses maximales du moteur, nous avons pris celles du Crazyflie, qui peuvent aller jusqu’à 6160 rad/s. Les moteurs 1 et 3 tournent dans le sens horaire et sont situés de part et d’autre du quadricoptère et les moteurs 2 et 4 dans le sens antihoraire (cf. travail du semestre 6). Toutes les mesures seront faites avec un vent nul.
Dans un premier temps nous calculons la vitesse maximale théorique de translation horizontale selon l’axe Z négatif. Z est négatif car le drone se déplace vers le haut, alors que l’axe Z est orienté vers le bas.
Ainsi, selon notre modèle, le Crazyflie peut aller au maximum à 1,47 m/s vers le haut lorsque les moteurs tournent à leur maximum (ce qui n’arrive pas car la batterie LiPo 240mAh ne tiendrait pas, il faudrait 4.2V et 1A sur chaque moteur pour atteindre la vitesse max théorique).
Maintenant, tentons de trouver la vitesse minimale qu’il faut donner aux moteurs pour que le drone commence à décoller. Nous considèrerons que le drone décolle lorsqu’il atteint une vitesse de -1cm/s selon Z. Notre modèle ne fonctionne qu’avec des petits angles en φ et en θ (simplification cos et sin) et il néglige l’aspiration du drone par le sol lorsque celui est très proche du drone. En résolvant :
ż = (fwz-ft)/m = -0.01, on trouve Ω1= Ω2= Ω3= Ω4=507rad/s
avec fwz = 0 (vent négligé dans cette partie)
Ainsi, notre drone décolle lorsque ses 4 moteurs tournent à 507rad/s.
Les translations selon les axes X et Y sont en fait une combinaison de mouvement (tangage/pitch) et de variations des vitesses des 4 moteurs. Nous ne nous intéresserons pas ici à ces mouvements car nous étudions seulement la rotation du drone selon les axes X,Y,Z et non ses déplacements linéaires selon ces axes.
Etudions maintenant les rotations du drone selon la vitesse des moteurs.
En faisant tourner les moteurs 2 et 4 moins rapidement que les 1 et 3, on engendre une rotation d’axe Z de -0.43 rad/s, soit environ 25°/s. De plus les 4 moteurs tournant à ~3000rad/s, ils entrainent un déplacement selon Z de 34cm/s.
En faisant tourner légèrement moins rapidement les moteurs 1 et 2, on engendre une forte rotation d’axe X de 2.73 rad/s, soit environ 156°/s. Cette forte vitesse angulaire s’explique par les équations définissant le moment en X des moteurs du drone (cf. équation 2.16). De plus les 4 moteurs tournant à ~3000rad/s, ils entrainent un déplacement selon Z de 35cm/s.
En faisant tourner les moteurs 2 et 4 moins rapidement que les 1 et 3, on engendre une rotation d’axe Y de 1.07 rad/s, soit environ 61°/s. De plus les 4 moteurs tournant à ~3000rad/s, ils entrainent un déplacement selon Z de 35cm/s.
En nous basons sur notre étude du semestre 6, on peut dire que notre simulation Godot est en adéquation avec notre étude théorique qui définissait les mouvements du drone en fonction de la variation de vitesse sur ses quatre moteurs.
Simulation du drone sur Godot
Après avoir implémenté les équations sur Godot, nous simulons les rotations du drone à l'aide de deux fonctions. La première nous permet de simuler la rotation du drone pendant un temps indéfini. L'autre nous permet de visualiser la réponse du système lorsque les vitesses des 4 moteurs lui sont assignées pendant un temps défini.
Voici par exemple ce que l'on obtient pendant 1,5s pour Vm1 = 3000 rad/s, Vm2 = 2800 rad/s, Vm3 = 3000 rad/s et Vm4 = 2900 rad/s, en négligeant les perturbations dues au vent.
Pour finir nous avons fait une vidéo avec plusieurs simulations : un décollage sans le vent, un décollage avec un vent en x et z et un décollage avec un vent en y. Nous avons aussi simulé un lacet. En effet, conformément à nos travaux du S6, pour Vm1 = 3000 rad/s, Vm2 = 2900 rad/s, Vm3 = 3000 rad/s et Vm4 = 2900 rad/s on obtient bien un lacet (rotation sur lui-même selon Z). La vidéo a été faite sans régulation Matlab. Voici une compilation de plusieurs mouvements avec et sans vent :
Simulink
Dans la partie Simulink, notre but est de simuler les 4 moteurs du drone pour par la suite les réguler en cas de perturbation.
I) Équations pour modélisation des moteurs
Nous allons recevoir dans notre modèle Simulink, les valeurs des différentes inclinaisons du drone ainsi que sa vitesse de translation sur l'axe z qui permet au drone de monter ou descendre. Il est donc nécessaire d'obtenir les équations des moteurs en fonction de ses différentes variables.
Grâce aux équations 2.36 et 2.16, nous pouvons obtenir les équations suivantes :
Avec p, q et r les vitesses d'inclinaison du drone et w la vitesse de translation sur z.
II) Modélisation des moteurs sous Simulink
Après avoir déterminé les équations qui nous serons nécessaires, nous pouvons établir les moteurs du drone avec les caractéristiques du crazyflie, la simulation se fera d'abord sans régulation.
Voici le modèle global :
Moteur 1 :
Moteur 2 :
Moteur 3 :
Moteur 4 :
Moment en X généré par la vitesse des 4 moteurs, Tx :
Moment en Y généré par la vitesse des 4 moteurs, Ty :
Moment en Z généré par la vitesse des 4 moteurs, Tz :
Force de poussée verticale, Ft :
Fichier Matlab :
III) Expérimentation
La modélisation mise en place, nous pouvons maintenant tester si nos moteurs donnent les mêmes valeurs que sur Godot grâce aux expérimentations précédentes. Toutes les expérimentations seront faites avec un vent nul.
Premièrement, nous allons démarrer avec une vitesse maximale de translation sur z de 1,47 m/s pour pouvoir observer si les moteurs vont tourner à la même vitesse que ceux de la simulation sur Godot. (Voir expérimentation sur Godot).
On remarque qu'on est très proche du résultat sur Godot qui été théoriquement de 6160 rad/s pour chaque moteur avec les mêmes configurations.
Pour la deuxième expérimentation, nous allons faire une rotation sur l'axe Y de 1,07 rad/s (61 °/s).
On remarque que les moteurs ont la même configuration que sur Godot mais les valeurs ne sont pas les mêmes. Elles sont sûrement dues à la non-régulation des moteurs puis peut-être, également, à une meilleure interprétation dans Simulink. Voici un exemple de communication Matlab-Simulink/Godot en boucle :
Régulation sous Matlab
Après avoir créé un Simulink contenant les 4 moteurs du drone, nous nous sommes tournés vers un script Matlab pour la régulation qui nous semble être la meilleure option.
Avec les équations 2.16, nous avons posé un système de 3 équations que l'on a résolu avec un calculateur formel Xcas pour avoir 8 solutions valables dans un certain domaine de validité. Nous avons résolu moment_moteurs = - moment_vent en fonction de Vm1,Vm2,Vm3,Vm4 (vitesses des moteurs). Ainsi en résolvant cette équation, on obtient 4 valeurs de moteurs qui compenseront les moments engendrés par le vent. Vx, vy, vz dans le solveur correspondent aux moments du vent (avec le signe moins, vx=-T_wx).
Nous avons choisi la meilleure d’entre elles car elle a un domaine de validité intéressant (les vitesses des moteurs et de vent correspondent à des solutions physiquement possibles par rapport à la vitesse max et min des moteurs du drone) :
Ces équations expriment les moments du drone en fonction des perturbations du vent. Les trois premières vitesses des moteurs dépendent des perturbations mais également de la vitesse du 4ème moteur. Cette vitesse a été fixée par son domaine de validité, qui dépend uniquement de la perturbation du vent selon l’axe y. Ainsi, les valeurs des vitesses calculées permettent aux moteurs du drone de se réguler et de rester stable.
Dans le script, on reçoit les données du vent via Godot avec la communication UDP pour que, par la suite, on ait la correction des moteurs à envoyer sur Godot pour que le drone se stabilise (voir partie Communication UDP).
Régulation d'une perturbation selon Z avec un moment T_wz = 0.5 Nm :
Pour une cause encore inconnue, quand il y a un tangage ou un roulis sur le drone, la régulation s’emballe, on pense que cela est dû à Godot dans le calcul de l’intégrale qui a peut-être été mal faite.
