Version du 29 janvier 2019 à 11:27 (voir la source) Rsimonin (discussion | contributions) (→‎Objectifs) ← Modification précédente		Version actuelle datée du 6 mai 2020 à 10:01 (voir la source) Rsimonin (discussion | contributions) (→‎Semaine 14 et 15 : coupure pédagogique)
(445 révisions intermédiaires par 5 utilisateurs non affichées)
Ligne 1 :		Ligne 1 :
		+	<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
	__TOC__		__TOC__
	<br style="clear: both;"/>		<br style="clear: both;"/>
Ligne 6 :		Ligne 7 :
	==Description==		==Description==
−	Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un trône volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin, quatre étudiant séparés ensuite en deux équipes de deux.	+	Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
		+	Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
		+	Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.
	==Objectifs==		==Objectifs==
−	A terme, l'objectif est de construire un drone "made in Polytech Lille".	+	A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"
−	Dans un premier temps, en s'occupant de la partie régulation et implémentation des capteurs au châssis.	+	Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.
−	Dans un deuxième temps, en réalisant la conception mécanique du modèle physique du drone.	+	Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.
−	L'objectif principal de ce projet est de concevoir un drone capable de porter une charge d'environ 2 kilos, de type colis de livraison.	+
		+	Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.
		+
		+	Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.
	=Analyse du projet=		=Analyse du projet=
	==Positionnement par rapport à l'existant==		==Positionnement par rapport à l'existant==
−	==Analyse du premier concurrent==	+
−	==Analyse du second concurrent==	+	[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
		+	[[Fichier:udi.jpg|right|thumb|UDI U818S]]
		+
		+	===Analyse du premier concurrent : PARROT AR.DRONE 2.0===
		+
		+	Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.
		+
		+	Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.
		+
		+	===Analyse du second concurrent : UDI U818S===
		+
		+	Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
		+	En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
		+	Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.
		+
	==Scénario d'usage du produit ou du concept envisagé==		==Scénario d'usage du produit ou du concept envisagé==
		+
		+	'''A qui notre drone peut-il servir ?'''
		+
		+	Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''
		+
		+	Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.
		+
		+	'''Pour quel type d'utilisation ?'''
		+
		+	Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.
		+
		+	Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.
		+
	==Réponse à la question difficile==		==Réponse à la question difficile==
		+
		+	'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''
		+
		+	Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.
		+
		+	En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.
		+
		+	C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.
		+
	==Bibliographie et webographie==		==Bibliographie et webographie==
		+
		+	===Arducopter===
		+
		+	https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
		+	http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
		+	https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
		+	https://www.arduino.cc/en/Reference/Servo
		+
		+
		+	* Manuel d'utilisation
		+	http://ardupilot.org/copter/index.html
		+
		+	* Tutoriels vidéos
		+	Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
		+	Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
		+	Calibration des ESC : https://youtu.be/gYoknRObfOg
	=Préparation du projet=		=Préparation du projet=
	==Cahier des charges du groupe==		==Cahier des charges du groupe==
		+
		+
		+
		+	'''Diagramme bête à cornes'''
		+
		+	Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.
		+
		+	[[Fichier:Bete_a_cornes.png | center]]
		+
		+
		+	'''Diagramme en pieuvre'''
		+
		+	Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet
		+
		+	[[Fichier:pieuvredrone.png | center]]
		+
		+	'''Tableau de fonctions'''
		+
		+	Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.
		+
		+	[[Fichier:tableau_fonctions.jpeg | 500px | center]]
		+
	==Cahier des charges des équipes==		==Cahier des charges des équipes==
−	===Equipe 1===	+	===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===
−	===Equipe 2===	+
−	===Equipe 3===	+	L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.
		+
		+	===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===
		+
		+	L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.
	==Choix techniques : matériel et logiciel==		==Choix techniques : matériel et logiciel==
	===Equipe 1===		===Equipe 1===
		+
		+	'''Émetteur'''
		+
		+	Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.
		+
		+	'''Récepteur'''
		+
		+	Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.
		+
	===Equipe 2===		===Equipe 2===
−	===Equipe 3===	+
		+	Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.
		+
		+	Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.
		+
		+	Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.
		+
		+	===Bilan===
		+
		+	[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]
		+
		+	* '''Matériel''' :
		+	**2 joysticks
		+	**Emetteur Xbee
		+	**Récepteur Xbee
		+	**Arduino NANO
		+	**Arduino UNO
		+	**Ardupilot 2.8
		+	**Câblage
		+
		+	* '''Logiciels''' :
		+	**Arduino
		+	**Mission Planner
		+	**APM Planner 2.0
	==Liste des tâches à effectuer==		==Liste des tâches à effectuer==
	===Equipe 1===		===Equipe 1===
		+
		+	Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
		+	* Analyse du projet
		+	* Découverte Xbee
		+	* Prise en main Xbee
		+	* Envoi de trames
		+	* Réception de trames
		+	* Optimisation de la programmation
		+	* Test sur maquette
		+	* Réalisation du PCB
		+	* Mise en œuvre sur notre drone
		+
	===Equipe 2===		===Equipe 2===
−	===Equipe 3===	+
		+	Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
		+	* Analyse du projet
		+	* Choix d'une carte de contrôle
		+	* Documentation, recherche d'un software
		+	* Calibration de la carte
		+	* Réalisation des branchements
		+	* Mise en application sur la maquette
		+	* Mise en relation avec la partie commande
	==Calendrier prévisionnel==		==Calendrier prévisionnel==
−	Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.	+	Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
−	===Equipe 1===	+	===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===
−	===Equipe 2===	+
−	===Equipe 3===	+	[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]
		+
		+
		+	===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===
		+
		+	[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]
	=Réalisation du Projet=		=Réalisation du Projet=
Ligne 54 :		Ligne 195 :
	==Projet S6==		==Projet S6==
−	Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.	+	===Semaine 5 et 6===
		+
		+	Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.
−	===Semaine 4===
−	===Semaine 5===
−	===Semaine 6===
	===Semaine 7===		===Semaine 7===
		+
		+	[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]
		+
		+	'''Equipe 1'''
		+
		+	Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.
		+
	===Semaine 8===		===Semaine 8===
		+
		+	[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]
		+
		+	'''Equipe 1'''
		+
		+	Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.
		+
		+	Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.
		+
		+
		+
		+	'''Equipe 2'''
		+
		+	Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
		+	Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.
		+
	===Semaine 9===		===Semaine 9===
		+
		+	'''Equipe 1'''
		+
		+	Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:
		+
		+	[[Fichier:inixbeedrone.png]]
		+
		+	'''Equipe 2'''
		+
		+	En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.
		+
		+	[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]
		+
		+
		+	En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.
		+
	===Semaine 10===		===Semaine 10===
		+
		+	'''Equipe 1'''
		+
		+	Nous avons travaillé sur la transmission, la réception et le traitement des trames.
		+
		+	Pour la transmission, nous avons mis en place le système suivant:
		+
		+	*On lit la valeur des potentiomètres
		+	*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
		+	*On envoie la chaîne de caractère par liaison série.
		+
		+
		+	Pour la réception, nous avons mis en place le système suivant:
		+
		+	*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
		+	*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
		+	*On transmet la consigne à l'ardupilot.
		+
		+
		+	'''Equipe 2'''
		+
		+	Idem semaine 9.
		+
	===Semaine 11===		===Semaine 11===
		+
		+	'''Equipe 1'''
		+
		+	Débogage de la communication entre les modules XBee et l'ardupilot.
		+
		+	En utilisant deux terminaux, la communication était réalisé entre les deux XBee  cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.
		+
		+	De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.
		+
		+	'''Equipe 2'''
		+
		+	Idem semaine 9.
		+
	===Semaine 12===		===Semaine 12===
		+
		+	'''Equipe 1'''
		+
		+	Optimisation du format des trames et réglage de la vitesse de transmission.
		+
		+	Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.
		+
		+	'''Equipe 2'''
		+
		+	A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.
		+
		+	La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
		+	La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)
		+
		+	[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]
		+
		+	===Semaine 13===
		+
		+	'''Equipe 1'''
		+
		+	Réglage des trames pour la commande du prototype.
		+
		+	Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.
		+
		+	En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.
		+
		+	'''Equipe 2'''
		+
		+	Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
		+	Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
		+	Ainsi, tous les composants nécessaires au drone sont alimentés.
		+
		+	===Semaine 14===
		+
		+	'''Equipe 1'''
		+
		+	Conception du PCB pour la commande en essayant de limiter le plus possible les vias.
		+
		+	[[Fichier:pcbdrone.png|400px|PCB]]
		+
		+	Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.
		+
		+	'''Equipe 2'''
		+
		+	Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.
		+
		+	[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]
		+
		+	===Semaine 15===
		+
		+	'''Equipe 1'''
		+
		+	Fabrication de la manette
		+
		+	[[Fichier:manettedrone.jpg|400px|PCB]]
		+
		+	Modification de l'envoie des trames. Tests de transmission.
		+	Implémentation du programme sur le prototype.
		+
		+	Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.
		+
		+	'''Equipe 2'''
		+
		+	A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.
	===Documents Rendus===		===Documents Rendus===
		+
		+	Rapport : [[fichier:rapport_groupe_4.pdf]]
	==Projet S7==		==Projet S7==
		+
		+	===De nouveaux objectifs===
		+
		+	Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.
		+
		+	Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
		+	*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
		+	*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
		+	*'''de concevoir notre propre contrôleur de vol'''
		+	*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal
		+
		+	===Reprise du cahier des charges===
		+
		+	'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''
		+
		+	L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.
		+
		+	'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)
		+
		+	L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.
		+
		+	===Nouveaux choix techniques===
		+
		+	'''Equipe 1 :'''
		+
		+	Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).
		+
		+	'''Equipe 2 :'''
		+
		+	Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.
		+
		+	'''Conception générale du drone :'''
		+
		+	Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.
		+
		+	Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].
		+
		+	'''Bilan'''
		+	*'''Matériel'''
		+	**Chassis
		+	**4 ESCs EMAX BLHELI 20A
		+	**4 moteurs A2212/13T
		+	**Batterie LI-PO 11,1V - 2700mAh
		+	**Arduino UNO
		+	**Télécommande Flysky FS-I6X
		+	**Récepteur FS-X6B
		+	**Centrale inertielle MPU6050
		+	*'''Logiciel'''
		+	**Arduino
		+
		+	'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.
		+
		+	===Liste des tâches à effectuer===
		+	'''Equipe 1'''
		+
		+	Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
		+	* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
		+	* Configurer la télécommande
		+	* Lecture des joysticks par Arduino
		+	* Initialiser les extremums des joysticks
		+	* Optimisation de la programmation
		+	* Test de transmission sur les ESCs
		+	* Mise en œuvre sur notre drone
		+
		+	'''Equipe 2'''
		+
		+	Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
		+	* Découverte du MPU6050
		+	* Configuration des registres du MPU6050
		+	* Récupération des mesures angulaires en °/s
		+	* Intégration des mesures pour récupérer les positions en degrés
		+	* Calcul de la consigne
		+	* Calcul de l'erreur
		+	* Calcul du correcteur
		+	* Application de la correction aux ESCs
		+
		+	===Semaine 45===
		+
		+	[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]
		+
		+	'''Equipe 1 :'''
		+
		+	*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.
		+
		+	*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.
		+
		+	'''Equipe 2 :'''
		+
		+	*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
		+	*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.
		+
		+	===Semaine 46===
		+
		+	'''Equipe 1 :'''
		+
		+	*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.
		+
		+	*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.
		+
		+
		+	'''Equipe 2 :'''
		+
		+	*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.
		+
		+	===Semaine 47===
		+
		+	'''Equipe 1 :'''
		+
		+	*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.
		+
		+	*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.
		+
		+	*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.
		+
		+	'''Equipe 2 :'''
		+
		+	*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
		+	*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.
		+
		+	===Semaine 48===
		+
		+	'''Equipe 1 :'''
		+
		+	*Correction du calibrage des ESCs à travers l'Arduino.
		+	*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.
		+
		+	'''Equipe 2 :'''
		+
		+	*Mise en commun de la partie programmation Arduino avec l'équipe 1.
		+	*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.
	===Documents Rendus===		===Documents Rendus===
		+
		+	Soutenance : [[fichier:soutenance_S7_P4.pdf]]
	==Projet S8==		==Projet S8==
		+
		+	[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]
		+
		+	===Liste des tâches à effectuer===
		+	'''Equipe 1'''
		+
		+	Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
		+	*Conception d'un PCB (pour l'ensemble du système)
		+	*Optimiser la distribution de la puissance (esthétiquement)
		+	*Finition de la partie communication envoie/reception de trame validé
		+
		+	'''Equipe 2'''
		+
		+	Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
		+	*Mise en place et réglage de la régulation PID:
		+	**Calcul de la consigne
		+	**Calcul des erreurs
		+	**Calcul des consignes à appliquer aux moteurs après correction
		+	**Application des consignes
		+
		+	*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)
		+
		+	===Semaine 3===
		+	'''Equipe 1 :'''
		+
		+	*Réflexion et réalisation du PCB sur ''Altium Designer''
		+	*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
		+	*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs
		+
		+	'''Equipe 2 :'''
		+
		+	*Finalisation du programme, y compris la partie régulation PID
		+	*Reste encore à régler les coefficients du PID
		+	*Mise en relation du programme avec l'équipe 1
		+
		+	===Semaine 4===
		+
		+	'''Equipe 1 :'''
		+
		+	* Finition du PCB sur altium et création du même PCB sur Fritzing.
		+	* Reprise de l'ancienne maquette pour effectuer la régulation
		+
		+	'''Equipe 2 :'''
		+
		+	*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
		+	*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
		+	*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.
		+
		+	===Semaine 5===
		+
		+	[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]
		+
		+	'''Equipe 1 :'''
		+
		+	*Impression du PCB et branchement sur la maquette (2)
		+	*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)
		+
		+	'''Equipe 2 :'''
		+
		+	*Tests de régulation en mode suspendu (avec l'équipe 1)
		+	*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)
		+
		+	===Semaine 6===
		+
		+	'''Equipe 1 :'''
		+
		+	*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
		+	* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).
		+
		+	[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]
		+
		+	'''Equipe 2 :'''
		+
		+	*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
		+	*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
		+	*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.
		+
		+	[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]
		+
		+	===Semaine 7 : coupure pédagogique===
		+
		+	===Semaine 8===
		+
		+	'''Equipe 1 & 2 :'''
		+
		+	* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
		+	Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
		+	Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
		+	Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
		+	Sur la maquette n°2, un moteur et un ESC sont obsolètes.
		+	Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.
		+
		+	===Semaine 9===
		+
		+	'''Equipe 1 & 2 :'''
		+
		+	* Commande et attente des ESC pour finaliser la régulation.
		+	* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.
		+
		+
		+	*Le boitier comporte 3 potentiomètres, un pour la valeur du I, un autre pour la valeur du P et le dernier pour la valeur du D.
		+
		+	===Semaine 10===
		+
		+	Re-structuration du projet suite aux événements du COVID-19:
		+
		+	* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
		+	* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
		+	* Avancée rapport et présentation. (Maxime)
		+
		+	===Semaine 11===
		+
		+	'''Régulation avec 2 ESCs (Lukas) :'''
		+
		+	* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.
		+
		+	[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]
		+
		+	'''Application mobile :'''
		+
		+	* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO
		+
		+	===Semaine 12===
		+
		+	[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]
		+
		+
		+	'''Application mobile :'''
		+	*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
		+	*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
		+	*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
		+	[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]
		+
		+	'''Régulation avec 2 ESCs'''
		+	*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo des derniers tests à Polytech ci-contre
		+	*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct
		+
		+	===Semaine 13===
		+
		+	* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.
		+
		+	* Modification du code pour appliquer la régulation uniquement sur deux moteurs.
		+
		+	===Semaine 14 et 15 : coupure pédagogique===
		+
		+	* Communication telephone-ESP32  fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32. A chaque lancement l'application crash.
		+
		+	* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.
		+	* Le problème venait du lancement de la communication TCP dans le mainactivity alors que la communication TCP est obligatoirement géré par des threads sur Android
		+
		+	[[fichier:Video_P4_Appli_+_esp32.mp4|500px]]
		+	*Cette vidéo comporte une prise d'écran du moniteur série de l'ESP32 avec une vidéo de l'application. Ces deux vidéos ont été filmé à deux moments différents. Il y aura pas de concordance entre les deux mais cette vidéo permet de visualiser le fonctionnement.
		+
		+	'''Régulation avec deux moteurs'''
		+
		+	Après avoir constaté que la fonction compensateBatteryDrop (fonction permettant de prendre en compte la décharge de la batterie dans le calcul de la correction) était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre programme. Cependant la fonction est resté un certains temps dans notre programme, notamment pendant des tests, et nous pensions alors que la tension étant stable, cette fonction n’influençait pas sur le bon fonctionnement du programme. Cependant un pin était utilisé dans cette fonction pour récupérer la tension, et ayant laissé tombé cette fonction, nous avons aussi ignoré l'utilisation de ce pin et de ce fait nous avons faussait les calculs de correction. Finalement cette suppression nous a permis, de constater une nette amélioration de la régulation.
		+
		+	Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe. Malheureusement nous somme tombé à court de batterie (nous nous rechargions à Robotech) et nous ne disposons pas d'alimentation 12V pouvant supporter le courant demandé par les moteurs. Il reste donc encore l'axe pitch à réguler. Le roll est régulé avec les valeurs suivantes :
		+	*kp Roll = 1.25  ki Roll = 0.05  kd Roll = 22.00
		+
		+	L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.
	===Documents Rendus===		===Documents Rendus===
		+
		+	*Rapport : [[fichier:Rapport_drone_P4.pdf]]
		+	*Présentation orale : [[fichier:Soutenance_S8_drone_P4.pdf]]

---

Version actuelle datée du 6 mai 2020 à 10:01

Présentation générale

Description

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : Construction d'un drone volant. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin. Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir". Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie Objectifs de notre présentation.

Objectifs

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent : PARROT AR.DRONE 2.0

Le PARROT AR.DRONE 2.0, tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

Analyse du second concurrent : UDI U818S

Fabriqué par la marque UDI, le UDI U818S est un drone au caractéristiques similaires au précédent, à l'exception de la camera. En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros. Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

Scénario d'usage du produit ou du concept envisagé

A qui notre drone peut-il servir ?

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

Pour quel type d'utilisation ?

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

Réponse à la question difficile

Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

Bibliographie et webographie

Arducopter

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

• Manuel d'utilisation

http://ardupilot.org/copter/index.html

• Tutoriels vidéos

Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

Préparation du projet

Cahier des charges du groupe

Diagramme bête à cornes

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

Diagramme en pieuvre

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

Tableau de fonctions

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

Cahier des charges des équipes

Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

Choix techniques : matériel et logiciel

Equipe 1

Émetteur

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que deux joysticks et un émetteur Xbee. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une Arduino NANO. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

Récepteur

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une Arduino UNO mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un récepteur Xbee afin de recevoir les trames.

Equipe 2

Nous avons choisi pour notre carte de contrôle un Ardupilot 2.8, son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les ESC du drone. Nous sommes donc ensuite passés sur APM Planner car il permet d'éviter ce problème de mises à jour.

Bilan

• Matériel :
  • 2 joysticks
  • Emetteur Xbee
  • Récepteur Xbee
  • Arduino NANO
  • Arduino UNO
  • Ardupilot 2.8
  • Câblage

• Logiciels :
  • Arduino
  • Mission Planner
  • APM Planner 2.0

Liste des tâches à effectuer

Equipe 1

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes

• Analyse du projet
• Découverte Xbee
• Prise en main Xbee
• Envoi de trames
• Réception de trames
• Optimisation de la programmation
• Test sur maquette
• Réalisation du PCB
• Mise en œuvre sur notre drone

Equipe 2

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes

• Analyse du projet
• Choix d'une carte de contrôle
• Documentation, recherche d'un software
• Calibration de la carte
• Réalisation des branchements
• Mise en application sur la maquette
• Mise en relation avec la partie commande

Calendrier prévisionnel

Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.

Equipe 1 : Calendrier prévisionnel pour la gestion de la commande

Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol

Réalisation du Projet

Projet S6

Semaine 5 et 6

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

Semaine 7

Equipe 1

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

Semaine 8

Equipe 1

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

Equipe 2

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande. Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

Semaine 9

Equipe 1

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

Equipe 2

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

Semaine 10

Equipe 1

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

• On lit la valeur des potentiomètres
• On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
• On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

• On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
• On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
• On transmet la consigne à l'ardupilot.

Equipe 2

Idem semaine 9.

Semaine 11

Equipe 1

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

Equipe 2

Idem semaine 9.

Semaine 12

Equipe 1

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

Equipe 2

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées. La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

Semaine 13

Equipe 1

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

Equipe 2

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC. Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs. Ainsi, tous les composants nécessaires au drone sont alimentés.

Semaine 14

Equipe 1

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

Equipe 2

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

Semaine 15

Equipe 1

Fabrication de la manette

Modification de l'envoie des trames. Tests de transmission. Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

Equipe 2

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

Documents Rendus

Rapport : Fichier:Rapport groupe 4.pdf

Projet S7

De nouveaux objectifs

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource Ardupilot 2.8. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :

• d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)
• d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee
• de concevoir notre propre contrôleur de vol
• Bonus : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

Reprise du cahier des charges

Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

Nouveaux choix techniques

Equipe 1 :

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande Flysky FS-I6X accompagnée de son récepteur FS-X6B qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte Arduino UNO (qui servira également au contrôleur de vol).

Equipe 2 :

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle MPU6050 possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte Arduino UNO.

Conception générale du drone :

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte Arduino UNO qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant (EMAX BLHELI SERIES 20A). Nous avons également choisi de nouveaux moteurs brushless : les A2212/13T.

Bilan

• Matériel
  • Chassis
  • 4 ESCs EMAX BLHELI 20A
  • 4 moteurs A2212/13T
  • Batterie LI-PO 11,1V - 2700mAh
  • Arduino UNO
  • Télécommande Flysky FS-I6X
  • Récepteur FS-X6B
  • Centrale inertielle MPU6050
• Logiciel
  • Arduino

Note : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

Liste des tâches à effectuer

Equipe 1

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes

• Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
• Configurer la télécommande
• Lecture des joysticks par Arduino
• Initialiser les extremums des joysticks
• Optimisation de la programmation
• Test de transmission sur les ESCs
• Mise en œuvre sur notre drone

Equipe 2

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes

• Découverte du MPU6050
• Configuration des registres du MPU6050
• Récupération des mesures angulaires en °/s
• Intégration des mesures pour récupérer les positions en degrés
• Calcul de la consigne
• Calcul de l'erreur
• Calcul du correcteur
• Application de la correction aux ESCs

Semaine 45

Equipe 1 :

• Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

• Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

Equipe 2 :

• Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
• Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

Semaine 46

Equipe 1 :

• Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

• Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

Equipe 2 :

• Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

Semaine 47

Equipe 1 :

• Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

• Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque servo.h d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

• Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

Equipe 2 :

• Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
• Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

Semaine 48

Equipe 1 :

• Correction du calibrage des ESCs à travers l'Arduino.
• Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

Equipe 2 :

• Mise en commun de la partie programmation Arduino avec l'équipe 1.
• Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

Documents Rendus

Soutenance : Fichier:Soutenance S7 P4.pdf

Projet S8

Liste des tâches à effectuer

Equipe 1

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :

• Conception d'un PCB (pour l'ensemble du système)
• Optimiser la distribution de la puissance (esthétiquement)
• Finition de la partie communication envoie/reception de trame validé

Equipe 2

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :

• Mise en place et réglage de la régulation PID:
  • Calcul de la consigne
  • Calcul des erreurs
  • Calcul des consignes à appliquer aux moteurs après correction
  • Application des consignes

• Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

Semaine 3

Equipe 1 :

• Réflexion et réalisation du PCB sur Altium Designer
• Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
• Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

Equipe 2 :

• Finalisation du programme, y compris la partie régulation PID
• Reste encore à régler les coefficients du PID
• Mise en relation du programme avec l'équipe 1

Semaine 4

Equipe 1 :

• Finition du PCB sur altium et création du même PCB sur Fritzing.
• Reprise de l'ancienne maquette pour effectuer la régulation

Equipe 2 :

• Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
• Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
• Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

Semaine 5

Equipe 1 :

• Impression du PCB et branchement sur la maquette (2)
• Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

Equipe 2 :

• Tests de régulation en mode suspendu (avec l'équipe 1)
• Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

Semaine 6

Equipe 1 :

• Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
• Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).

Equipe 2 :

• Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
• Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
• Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

Semaine 7 : coupure pédagogique

Semaine 8

Equipe 1 & 2 :

• Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.

Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant. Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation. Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant. Sur la maquette n°2, un moteur et un ESC sont obsolètes. Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

Semaine 9

Equipe 1 & 2 :

• Commande et attente des ESC pour finaliser la régulation.
• Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

• Le boitier comporte 3 potentiomètres, un pour la valeur du I, un autre pour la valeur du P et le dernier pour la valeur du D.

Semaine 10

Re-structuration du projet suite aux événements du COVID-19:

• Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
• Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
• Avancée rapport et présentation. (Maxime)

Semaine 11

Régulation avec 2 ESCs (Lukas) :

• Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

Application mobile :

• Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

Semaine 12

Application mobile :

• Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
• Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
• L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.

Régulation avec 2 ESCs

• Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo des derniers tests à Polytech ci-contre
• Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

Semaine 13

• Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

• Modification du code pour appliquer la régulation uniquement sur deux moteurs.

Semaine 14 et 15 : coupure pédagogique

• Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32. A chaque lancement l'application crash.

• La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.
• Le problème venait du lancement de la communication TCP dans le mainactivity alors que la communication TCP est obligatoirement géré par des threads sur Android

• Cette vidéo comporte une prise d'écran du moniteur série de l'ESP32 avec une vidéo de l'application. Ces deux vidéos ont été filmé à deux moments différents. Il y aura pas de concordance entre les deux mais cette vidéo permet de visualiser le fonctionnement.

Régulation avec deux moteurs

Après avoir constaté que la fonction compensateBatteryDrop (fonction permettant de prendre en compte la décharge de la batterie dans le calcul de la correction) était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre programme. Cependant la fonction est resté un certains temps dans notre programme, notamment pendant des tests, et nous pensions alors que la tension étant stable, cette fonction n’influençait pas sur le bon fonctionnement du programme. Cependant un pin était utilisé dans cette fonction pour récupérer la tension, et ayant laissé tombé cette fonction, nous avons aussi ignoré l'utilisation de ce pin et de ce fait nous avons faussait les calculs de correction. Finalement cette suppression nous a permis, de constater une nette amélioration de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe. Malheureusement nous somme tombé à court de batterie (nous nous rechargions à Robotech) et nous ne disposons pas d'alimentation 12V pouvant supporter le courant demandé par les moteurs. Il reste donc encore l'axe pitch à réguler. Le roll est régulé avec les valeurs suivantes :

• kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

Documents Rendus

• Rapport : Fichier:Rapport drone P4.pdf
• Présentation orale : Fichier:Soutenance S8 drone P4.pdf