IMA4 2016/2017 P31 : Différence entre versions
(→Semaine 9) |
(→Fichiers Rendus) |
||
(5 révisions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 106 : | Ligne 106 : | ||
| | | | ||
| 4h | | 4h | ||
− | | | + | | 6h |
| | | | ||
| | | | ||
Ligne 130 : | Ligne 130 : | ||
| | | | ||
|- | |- | ||
− | | Etude des capteurs via | + | | Etude des capteurs via Raspberry |
| | | | ||
| | | | ||
Ligne 138 : | Ligne 138 : | ||
| | | | ||
| 3h | | 3h | ||
+ | | 4h | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Choix et implémentation des trajets dans l'application | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 4h | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | Construction du code principal de l'application | ||
| | | | ||
| | | | ||
+ | | | ||
| | | | ||
| | | | ||
| | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | 8h | ||
+ | | | ||
|} | |} | ||
Ligne 251 : | Ligne 279 : | ||
[[Fichier:Capteur1.JPG|400px]] | [[Fichier:Capteur1.JPG|400px]] | ||
+ | |||
+ | |||
+ | |||
+ | * Cette semaine nous avons étudié plus en détails le corps du programme principal de l'application. Celui-ci contient une vingtaine de fonctions remplissant des tâches diverses et variées : | ||
+ | - Une fonction permettant d'ajouter un marqueur sur la carte du monde à l'endroit ou l'utilisateur clique,<br> | ||
+ | - Une fonction permettant d'ouvrir un sous-menu pour fixer les caractéristiques du vol,<br> | ||
+ | - Une fonction permettant de valider les waypoints (WP) indiqués par l'utilisateur et de préparer le plan de vol,<br> | ||
+ | - Et plus d'une dizaine d'autres fonctions que nous ne détaillerons pas ici car leur utilité dans le cadre de ce projet est moindre. <br> | ||
+ | |||
+ | L'objectif des prochaines séances et de réaliser à partir de ce code l'application finale qui nous permettra, via l'appui sur un UNIQUE bouton de l'écran, d'à la fois choisir une place, de créer le plan de vol, et de faire décoller le drone. Afin de réaliser cet objectif, nous avons utilisé la fonction "addWaypointMarker (?)" : cette fonction, initialement, permettait d'autoriser l'ajout de WP sur l'écran, puis un second appui sur cette même touche sauvegardait les marqueurs puis interdisait l'ajout de nouveaux WP (jusqu'au prochain appui sur ce bouton) ; dorénavant un appui sur ce bouton permet à la fois de créer automatiquement les WP associés au parcours jusqu'à une place libre, de créer le plan de vol, puis de faire démarrer le drone. | ||
+ | |||
+ | |||
+ | '''(Ajouter photo du code ici)''' | ||
===Semaine 9=== | ===Semaine 9=== | ||
Ligne 274 : | Ligne 315 : | ||
* Un problème est parfois rencontré lorsque nous lançons le programme à cause de la communication i2c entre l'ADC et la raspberry. Ce problème est soit dû à la non libération du canal de transmission à la fin du programme soit dû à des adresses mémoires "volatiles". | * Un problème est parfois rencontré lorsque nous lançons le programme à cause de la communication i2c entre l'ADC et la raspberry. Ce problème est soit dû à la non libération du canal de transmission à la fin du programme soit dû à des adresses mémoires "volatiles". | ||
* Il faut maintenant chercher un moyen de faire communiquer cette nacelle avec le téléphone afin d'envoyer une commande de stop au drone. La communication bluetooth ne sera pas utilisée car sa portée est trop courte. Nous essayerons donc de communiquer par Wi-fi. Nous savons qu'il est possible de faire communiquer un téléphone et une raspberry. Nous allons donc désormais orienter nos recherches vers l'envoi d'une variable via Wi-fi. | * Il faut maintenant chercher un moyen de faire communiquer cette nacelle avec le téléphone afin d'envoyer une commande de stop au drone. La communication bluetooth ne sera pas utilisée car sa portée est trop courte. Nous essayerons donc de communiquer par Wi-fi. Nous savons qu'il est possible de faire communiquer un téléphone et une raspberry. Nous allons donc désormais orienter nos recherches vers l'envoi d'une variable via Wi-fi. | ||
+ | |||
+ | * Du coté de l'application, la grosse partie du travail de cette semaine aura été d'implémenter dans le code de celle-ci des tableaux contenant les coordonnées GPS des places de parking que nous avons soigneusement sélectionné. L'idée est simple : nous avons une superposition de tableaux : | ||
+ | 1. Le tableau principal est le tableau de places, | ||
+ | 2. Ce tableau de places contient un certain nombre de sous-tableaux, | ||
+ | 3. Enfin, chaque sous-tableau contient la longitude et la latitude d'un point "clé" du chemin que suivra le drone jusqu'à la place caractérisée. | ||
+ | |||
+ | Ici, nous avons fais le choix (logique) de ne pas implémenter la totalité des places du parking, mais seulement un échantillon d'une demi-douzaine de places, situées à des endroits assez espacés du parking. De plus, par soucis d'équité, nous avons ajouté un tableau copié sur le premier, mais contenant uniquement les coordonnées de places pour handicapés. | ||
== Fichiers Rendus == | == Fichiers Rendus == | ||
+ | Ci-dessous, vous pouvez consulter le compte rendu de nos séance en un rapport reprenant l'ensemble de notre travail: <br> | ||
+ | |||
+ | [[Fichier:Rapport_P31_PROFIT_HART.pdf]] |
Version actuelle datée du 11 mai 2017 à 21:58
Cahier des charges
Présentation générale du projet
L'enceinte de Polytech Lille est bien connue de ses occupants, élèves ou professeurs. Cependant, pour un nouvel arrivant, qu'il soit simple visiteur ou conférencier, se rendre dans la salle D'Arsonval ou simplement trouver une place libre sur le parking peut se révéler être une épreuve. L’intérêt de notre projet est de faciliter à ces derniers l'accès à tous les recoins des bâtiments de Polytech Lille grâce à l'utilisation d'un drone d'accueil personnalisé.
Objectifs du projet
L'objectif de notre projet est, à terme, de pouvoir guider un utilisateur de l'entrée du parking de Polytech jusqu'à une salle à l'intérieur de l'enceinte de l'école. La réalisation de ce projet passe par deux objectifs intermédiaires :
- Accueillir un visiteur depuis l'entrée du parking de Polytech et le mener jusqu'à une place de parking libre.
- Guider ce même visiteur depuis sa place de parking jusqu'à une salle.
Il est envisageable de pouvoir réaliser le second objectif dans les deux sens, à savoir : guider un visiteur d'une salle de Polytech jusqu'à sa place de parking.
Description du projet
Nous disposons d'un drone Phantom3 d'1,2 Kg capable de supporter une charge utile d'1Kg. Nous devons utiliser cette charge utile à bon escient afin de ne pas perdre en autonomie. Nous envisageons donc d'utiliser environ 500g de matériel à monter sur le drone. Le système final doit remplir les fonctions suivantes :
- L'utilisateur devra pouvoir choisir sa destination via une interface portable soit par Bluetooth entre un téléphone mobile sur lequel sera préalablement installé une application soit par le biais d'une page internet hébergée sur une Raspberry.
- Le drone se déplacera à une hauteur conséquente et sera capable d'éviter et de contourner les obstacles présents sur son chemin.
- Le drone devra pouvoir se repérer automatiquement à l'extérieur.
Choix techniques : matériel et logiciel
Nous utiliserons probablement la plateforme ROS (Robot Operating System), qui nous permet d'utiliser différents modules (par exemple le SLAM). Nous aurons aussi recours à des bases de données, afin de recenser les utilisateurs, les salles, etc ; nécessitant alors une machine capable de les gérer via un logiciel du type MySQL.
Afin de réaliser notre projet, nous envisageons d'utiliser :
- un drone modèle Phantom3, fourni par Polytech Lille, cœur de notre projet ;
- une carte Raspberry, sur laquelle l'utilisateur pourra se connecter et accéder à la page d'accueil du drone ;
- un GPS, déjà intégré au drone, pour le localiser en permanence ;
- un écran LCD, que nous monterons sur le drone afin de faciliter l'utilisation du drone par le visiteur ;
- un module Wi-Fi ESP8266, afin de créer un serveur ouvert à tous ;
- un jeu de capteurs de proximité (Ultrasons/Infrarouge), afin de garantir l'intégrité physique du personnel et matérielle du drone.
Calendrier prévisionnel
Liste des tâches à effectuer
- Préliminaires :
- Étude du mode de communication entre le drone et l'application qui lui est dédiée.
- Étude de ROS (Robot Operating System) et des algorithmes de SLAM pour voir si ces composants logiciels peuvent faciliter le développement du projet.
- Installation de ROS sur RaspberryPi.
- Partie 1 :
- Installation du SDK de DJI.
- Essais sur les capteurs de proximité qui seront couplés à la RaspberryPi.
- Gestion d'un itinéraire par le drone, plus précisément la gestion d'un vol automatique avec le Phantom3.
- Communication drone/capteur par le biais de la carte RaspberryPi.
- Identification d'une personne grâce à une connexion Bluetooth entre un visiteur et la Raspberry.
- Mener une voiture à sa place de parking grâce aux éléments travaillés précédemment.
- Partie 2 :
- Se repérer dans Polytech grâce à un algorithme de SLAM intégré à la Raspberry.
- Se rendre dans une salle donnée en partant de l'entrée de Polytech. (coté parking)
Feuille d'heures
Tâche | Prélude | Heures S1 | Heures S2 | Heures S3 | Heures S4 | Heures S5 | Heures S6 | Heures S7 | Heures S8 | Heures S9 | Heures S10 | Total |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Définition cahier des charges | 2h | |||||||||||
Installation du SDK DJI et de Android Studio, téléchargement de tous les packages manquants | 4h | 6h | ||||||||||
Etude des différents moyens de communication avec le drone | 4h | |||||||||||
Etude des capteurs via Raspberry | 3h | 4h | ||||||||||
Choix et implémentation des trajets dans l'application | 4h | |||||||||||
Construction du code principal de l'application | 8h |
Avancement du Projet
Semaine 1
- Correction du cahier des charges.
- Établissement de la liste du matériel nécessaire à la réalisation de notre projet.
Pour ce projet, nous pensons qu'il serait en effet judicieux d'acheter du matériel supplémentaire afin de mener à bien notre projet. Il serait question d'utiliser:
- Carte RaspberryPi 3. Ce modèle est équipé d'un module bluetooth afin d'assurer la communication entre l'utilisateur et le drone, ainsi qu'entre le drone et les capteurs.
- 3 Capteurs de mesure Sharp GP2Y0A02YK. (référence : [1]). Nous avons choisi ce capteur sur 2 critères: Le prix et la plage de détection. En effet, il nous fallait un capteur de proximité ayant une plage de détection maximale entre 1 et 2 mètres afin que le drone puisse détecter les obstacles assez tôt pour pouvoir les éviter.
- Appareil mobile sous OS Android (portable ou tablette ). Cet appareil mobile pourra nous servir à installer les applications qui gérerons le drone. C'est également sur ce téléphone que sera gérer la base de données des itinéraires nécessaires aux déplacement du drone jusque à une place de parking.
- Étude des différents modes de fonctionnement du drone (Point Of Interest, Homelock, etc).
Le mode POI présenté ci-contre pourrait par exemple être utilisé dans le cas où le drone serait arrivé à sa destination. Il attendrait en vol que la voiture se soit garé à sa place.
Nous pourrions également définir les places de parking comme des "homes" que le drone rejoindrait en suivant un itinéraire pré-défini et où il attendrait que la voiture arrive.
- Première découverte de ROS pour l'installer sur RaspberryPi.
Robot Operating System (ROS) est une plateforme de développement logicielle pour utilisée en robotique.[2]. Il s'agit d'un pseudo OS qui peut fonctionner sur ordinateur. ROS a pour intérêt d'offrir des fonctionnalités telles abstraction du matériel, le contrôle des périphériques de bas niveau, mise en œuvre de fonctionnalités couramment utilisées ainsi que la transmission de messages entre les processus.
La communication entre les processus s'opère de la façon suivante:
Un premier node avertit le master qu'il a une donnée à partager. -> Un deuxième node avertit le master qu'il souhaite avoir accès à une donnée.
Une connexion entre les deux nodes est créée. -> Le premier node peut envoyer des données au second.
L'implémentation d'un OS ROS sur une RaspberryPi pourrait donc être une bonne idée qu'il faudrait continuer à creuser afin de faire communiquer la Raspberry et le drone.
Semaine 2
- Approfondissement de l'étude du drone phantom3 de DJI.
- Suite à des problèmes au niveau de la communication avec le drone, une solution alternative est envisagée. Il s'agirait de concevoir nous même notre propre drone.
- Préparation d'un argumentaire à présenter aux encadrants du projet.
Semaine 3
- Nous envisageons désormais de créer une application permettant de communiquer avec le drone. Nous faisons donc des recherches autour de l'API du drone.
- Découverte du SDK (Software Development Kit ) proposé par le site "DJI-developper" qui permet de créer des applications pouvant communiquer avec notre drone.
- Installation de Android studio, application nécessaire à la création des applications via le SDK de DJI-developper.
Semaine 4
- Installation du SDK de DJI-developper sur notre ordinateur portable.
Semaine 5
- Nous tentons de créer une application Android permettant de diriger le drone Phantom3 en pointant au doigt sur un appareil mobile un emplacement sur une carte virtuelle. L'application est développée via Android Studio, et son code nous est fourni par le site DJI-developper (https://developer.dji.com/mobile-sdk/documentation/android-tutorials/GSDemo-Google-Map.html), site regroupant un ensemble non négligeable de codes exemple, dont celui que nous utilisons ici.
Semaine 6
- Lors de cette semaine nous rencontrons de nombreux problèmes avec le drone. En effet, il nous est impossible de faire démarrer les moteurs.Nous sommes donc dans l'impossibilité de tester l'application que nous venons terminer de coder. Nous nous lançons donc dans une phase de recherche au travers du manuel d'utilisation et d'internet afin de debugger notre drone. Après quelques recherches, nous pensons que le firmware de la télécommande ou du drone a besoin d'être updaté. Nous mettons donc à jour le drone. Le problème est que nous n'arrivons plus à faire communiquer l'API avec le drone car nous sommes constamment "déconnectés" malgré que le câble soit relié entre notre téléphone et le drone. Or, pour mettre à jour notre drone, nous devons avoir touts les éléments connectés.
- En parallèle, nous avons reçu nos capteurs de proximité. Nous décidons donc de commencer la partie communication capteur-Raspberry. Nous rencontrons de nouveau des problèmes, en effet nous n'arrivons pas à communiquer avec la Raspberry via la liaison série. La solution est de mettre dans le fichier "config.txt" de la partition /boot une ligne de commande < enable_uart = 1 > et < core_freq = 250 > afin de lancer dès le démarrage de la Raspberry la liaison série qui n'est plus lancée par défaut sur les Raspberry Pi 3.
Semaine 7
- Premier vols avec le drone. Nous le testons dehors en volant tout d'abord en mode manuel, c'est-à-dire en utilisant la télécommande fournie. Après nous être familiarisé avec le drone et ses déplacements, nous essayons maintenant de le faire voler en utilisant notre application. Cette application est installée sur un téléphone portable sous Android, de plus, ce téléphone est connecté par liaison filaire avec la télécommande afin d'assurer la communication entre le drone et le téléphone.
Cette application permet entre autre :
- De localiser le drone sur la carte mondiale tirée de Google Map. Une fois localisé, le drone est symbolisé par un avion sur la carte.
- De définir des paramètres de vols du drone tels que l'altitude de vol ou la vitesse de vol.
- De créer des "Waypoints", ou "points d’intérêt. Ces points sont définis par l’utilisateur en cliquant sur l'écran tactile du téléphone. Il peut définir autant de points qu'il désire. Lorsque le drone décollera, il ira à chacun des points d'intérêt définis.
- Lorsque les Waypoints et les paramètres de vols sont définis, et une fois que la mission a bien été compilée en appuyant sur la touche "Prepare", l'utilisateur peut lancer la session de vol en appuyant sur "Start".
La vidéo suivante montre le résultat d'un plan de vol en 2 "Waypoints". L'altitude est définie à 5m et la vitesse de vol à "lent":
https://drive.google.com/open?id=0ByKP9w_p1fHAR09EVFozZjVvRlE
- En parallèle, nous entamons également le travail sur le capteur de proximité couplé à la raspberry. Après quelques recherches, nous trouvons le schéma de montage suivant que nous allons réutiliser:
Semaine 8
- Nous continuons la configuration de la Raspberry Pi3 afin de pouvoir utiliser le GPIO et lire les valeurs reçues sur les pins. Pour cela, nous devons tout d'abord relier la carte avec le réseau afin de pouvoir installer des paquets. Pour cela nous écrivons dans le fichier /etc/dhcpcd.conf les lignes suivantes:
Nous allons désormais installer le paquet "wiringPi". Ce wiringPi est un outil qui permet de contrôler les différentes broches du port GPIO. Il permet entre autre de visualiser les valeurs et les fonctions de chaque pin du gpio et de changer mode en entrée ou en sortie. Cet outil est donc bien utile pour configurer notre Raspberry.
Un problème apparaît directement lorsque nous regardons le tableau. En effet, la colonne 'V' du tableau indique que la valeur sur la pin est de 1. Or, cette valeur reste la même lorsque l'obstacle bouge. cela signifie qu'il y a un système de seuil dans la Raspberry qui fait qu'au delà d'une certaine valeur, le signal détecté est un 1 logique. Pour remédier à ce problème, nous utilisons donc un convertisseur Analogique-Digital.
Ce convertisseur sur 12-bits va nous permettre de convertir la valeur analogique du capteur de proximité et de l'envoyer à la Raspberry. De plus, ce convertisseur possède 4 entrées analogiques, ce qui est suffisant pour accueillir nos 3 capteurs de proximités.
Après avoir installé quelques librairies et installé python sur notre carte, nous entamons la création d'un programme qui lira la valeur du capteur 1 (branché sur l'entrée analogique 0 ) et l'affiche dans le terminal. Nous nous servons de quelques programmes exemple trouvés sur internet afin de nous aider. Le résultat est le suivant:
- Cette semaine nous avons étudié plus en détails le corps du programme principal de l'application. Celui-ci contient une vingtaine de fonctions remplissant des tâches diverses et variées :
- Une fonction permettant d'ajouter un marqueur sur la carte du monde à l'endroit ou l'utilisateur clique,
- Une fonction permettant d'ouvrir un sous-menu pour fixer les caractéristiques du vol,
- Une fonction permettant de valider les waypoints (WP) indiqués par l'utilisateur et de préparer le plan de vol,
- Et plus d'une dizaine d'autres fonctions que nous ne détaillerons pas ici car leur utilité dans le cadre de ce projet est moindre.
L'objectif des prochaines séances et de réaliser à partir de ce code l'application finale qui nous permettra, via l'appui sur un UNIQUE bouton de l'écran, d'à la fois choisir une place, de créer le plan de vol, et de faire décoller le drone. Afin de réaliser cet objectif, nous avons utilisé la fonction "addWaypointMarker (?)" : cette fonction, initialement, permettait d'autoriser l'ajout de WP sur l'écran, puis un second appui sur cette même touche sauvegardait les marqueurs puis interdisait l'ajout de nouveaux WP (jusqu'au prochain appui sur ce bouton) ; dorénavant un appui sur ce bouton permet à la fois de créer automatiquement les WP associés au parcours jusqu'à une place libre, de créer le plan de vol, puis de faire démarrer le drone.
(Ajouter photo du code ici)
Semaine 9
- Cette semaine nous nous attaquons à la création d'un support pour nos capteurs. Le but de ce support est d'accueillir nos 3 capteurs, la Raspberry Pi3 ainsi que le convertisseur Analogique-Digital. Ce support dit être le plus léger possible et prendre le moins de place possible.
Nous utilisons donc du balza, une sorte de bois léger utilisé pour le modélisme pour fabriquer entre autre les maquettes d'avions:
Comme indiqué précédemment lors de la dernière semaine. La lecture de la valeur d'un capteur passe un programme Python. Il faut désormais lire la valeur des 2 autres capteurs pour les afficher.De nombreux exemples sont disponibles sur la toile et le langage Python est assez intuitif. Nous arrivons rapidement au code suivant:
Il a tout d'abord fallu importer la librairie RPi.GPIO qui permet de gérer les entrées/sorties du GPIO de la raspberry. A partir de là, le programme est assez simple, la seule difficulté est de retrouver les bons code qui correspondent à un convertisseur ADS1015. Ici le programme affiche la valeur de chaque capteur ( droit, avant ou gauche ) et si celle ci est trop petite, affiche un message puis allume la LED de la breadboard.
Une temporisation a été nécessaire afin d'apercevoir l'allumage de la LED et surtout afin d'éviter de surcharger le buffer.
Le résultat retourné sur le terminal est le suivant:
En conclusion:
- Nous disposons d'une nacelle de 300 grammes qui pourra être embarquée par le drone. Celle ci détecte un obstacle jusque à 1 mètre apparaissant dans un angle de 130° à l'avant du drone.
- L'utilisation d'une batterie externe a été privilégiée afin d'éviter une trop grosse perte d'autonomie du drone si la raspberry avait été alimenté par le drone (via un câble double micro-usb).
- Un problème est parfois rencontré lorsque nous lançons le programme à cause de la communication i2c entre l'ADC et la raspberry. Ce problème est soit dû à la non libération du canal de transmission à la fin du programme soit dû à des adresses mémoires "volatiles".
- Il faut maintenant chercher un moyen de faire communiquer cette nacelle avec le téléphone afin d'envoyer une commande de stop au drone. La communication bluetooth ne sera pas utilisée car sa portée est trop courte. Nous essayerons donc de communiquer par Wi-fi. Nous savons qu'il est possible de faire communiquer un téléphone et une raspberry. Nous allons donc désormais orienter nos recherches vers l'envoi d'une variable via Wi-fi.
- Du coté de l'application, la grosse partie du travail de cette semaine aura été d'implémenter dans le code de celle-ci des tableaux contenant les coordonnées GPS des places de parking que nous avons soigneusement sélectionné. L'idée est simple : nous avons une superposition de tableaux :
1. Le tableau principal est le tableau de places, 2. Ce tableau de places contient un certain nombre de sous-tableaux, 3. Enfin, chaque sous-tableau contient la longitude et la latitude d'un point "clé" du chemin que suivra le drone jusqu'à la place caractérisée.
Ici, nous avons fais le choix (logique) de ne pas implémenter la totalité des places du parking, mais seulement un échantillon d'une demi-douzaine de places, situées à des endroits assez espacés du parking. De plus, par soucis d'équité, nous avons ajouté un tableau copié sur le premier, mais contenant uniquement les coordonnées de places pour handicapés.
Fichiers Rendus
Ci-dessous, vous pouvez consulter le compte rendu de nos séance en un rapport reprenant l'ensemble de notre travail: