P18 Localisation of quadrotors
Sommaire
Cahier des charges
Présentation générale du projet
Contexte
Dans un monde de plus en plus connecté, de nombreux drones sont déployés pour diverses applications comme l'espionnage, la surveillance, la cartographie de lieux et la livraison de colis. Les technologies nécessaires pour contrôler ces drones sont des sujets de recherche actuels.
Le contrôle de ceux-ci passe tout d'abord par la maîtrise de leur position dans l'espace. Le développement des applications liées à l'utilisation de drones nécessite un travail important sur la localisation spatiale d'objets connectés.
De plus, dans un souci d'utilisation, il est essentiel de développer des interfaces logicielles permettant d'exploiter ces données.
Objectif du projet
L'objectif de ce projet est de développer une interface logicielle permettant de traiter en temps réel les informations de localisation d'un drone et de balises, dans le but de définir leur localisation dans l'espace, en intérieur.
Description du projet
Pour réaliser le contrôle de drones, la première étape importante est de donner ses informations de position. Le but du projet est de développer une interface logicielle permettant de localiser le drone en temps réel en intérieur. Le drone se déplace dans un environnement dans lequel ont été installées de multiples balises. Il est équipé d'une carte, lui permettant de recevoir les distances relatives entre lui-même et les balises, sur laquelle différents algorithmes vont être implémentés pour effectuer la localisation en temps réel. Le projet requiert des compétences en développement hardware (Crazyflie 2.0, voir https://wiki.bitcraze.io/) et software (langage C/C++/Python/Javascript/HTML...).
Il se divise en 4 étapes principales, qui sont:
- 1) Choisir les technologies utilisées
- 2) Choisir l'architecture (OS / APIs)
- 3) Développer les différentes parties du projet
- 4) Intégrer et connecter les différentes parties du projet
La localisation étant en intérieur, le protocole GPS n'est donc pas assez précis pour les applications ciblées. La mise en place d'un tel dispositif permettrait grâce à l'utilisation d'un algorithme d'estimer avec une bonne précision les positions en intérieur d'une balise centrale (appelée Tag) et de balises (appelées Anchor). Le Tag scanne en temps réel la distance relative aux différentes balises, et il nous est retourné la position des balises et du Tag grâce à l'algorithme de localisation.
Le projet se compose de 3 parties:
- Collect & parse: collecter les données envoyées par les balises en communiquant avec un serveur et récupérer les données adéquates par un tri
- Localise: déterminer la matrice de position des balises et du Tag en traitant les données récupérées
- Display: développer l'interface homme machine pour afficher, étudier et utiliser les données traitées
Nous travaillerons dans un premier temps dans une optique temps différé avant de travailler en temps réel. Cela nous permettra d'acquérir des données utiles et réutilisables en aval.
A l'aboutissement du projet, nous devrions être capable via l'interface homme machine développée d'afficher précisément la position spatiale des balises ainsi que du Tag, grâce àl'utilisation d'un algorithme de localisation et des données récupérées, et d'afficher d'autres données relatives au déplacement du Tag ou des balises dans l'espace.
Si le temps le permet, nous pourrons aussi être amenés à adapter et utiliser l'interface développée pour l'utilisation d'un drone.
Sujet originel
To achieve the control of quadrotors, the first important task to give its position information. This project is to develop a software(GUI) to localize the quadrotors in real-time. The quadrotor is flying in an environment where several transmitters have been installed. The quadrotor is equipped with a deck to receive the relative distances between the deck and all transmitters, based on which different algorithms will be implemented to realize the real-time localization. The candidates need to have both experiences on hardware (Crazyflie 2.0, see https://wiki.bitcraze.io/) and software development (C/C , Python…).
Calendrier
Avant le 29/09/17 - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel
Avant fin Octobre - Serveur de collecte et début du développement de l'interface logicielle
Avant fin Décembre - Interface logicielle
A la fin du PFE - Intégration finale des différentes parties (Serveur de collecte des données & Serveur de localisation & Interface logicielle)
Répartition du volume de travail (***h):
- Recherche sur les technologies à utiliser (**h)
- Développement du serveur de collecte de données (**h)
- Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
- Intégration des différentes parties (**h)
- Test et débuggage (**h)
Choix techniques : matériel et logiciel
Afin de développer ce dispositif, nous allons utiliser une Raspberry Pi 3 associée à une carte réceptrice, qui communique avec 4 balises composées chacune d'un microcontrôleur et d'une carte émettrice radio (UWB5C) et alimentées par batteries. La carte réceptrice joue le rôle du drone à localiser et communiquera les données émises par les balises vers l'ordinateur via Bluetooth.
Choix technologiques
Voici les technologies que nous utilisons pour chacune des parties de ce projet.
1) Serveur de collecte des données:
Scanne et parse les données récupérées pour fournir la matrice D des distances relatives du tag aux 4 balises
- API
- Python / Serveur Flask
2) Serveur de localisation (fourni):
Calcule grâce à l'algorithme de localisation et la matrice D les positions spatiales des 4 noeuds et du tag
- API
- Bootstrap
- Jquery
- Python
3) Interface utilisateur:
Affiche courbes, visualisation 3D, boutons ou données des fichiers envoyées par le serveur de localisation
- HTML5 / Javascript
- Fichiers JSON (serveurs de collecte et de localisation)
Calendrier prévisionnel
Liste des tâches à effectuer
- Se documenter sur le projet
- Langages et technologies utilisées
- Matériel utilisé
- Mettre en place du travail sur le Git
- Réaliser le serveur de collecte
- Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
- Intégrer le serveur de localisation pour interpréter les trames
- Tester et optimiser
- Réaliser l'interface Web utilisateur
- Implémenter le serveur de collecte et de localisation
- Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
- Tester et optimiser
Replanification du cahier des charges / calendrier
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 | Heures S11 | Heures S12 | Heures S13 | Heures S14 | Heures S15 | Heures S16 | Heures S17 | Heures S18 | Heures S19 | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cahier des charges / Wiki / Gitlab | 4h | 3h | 1h | x | 1h30 | 1h | 2h | 1h | 2h30 | 1h | 3h | 3h30 | 2h | 5h | |||||||
| Documentation sur les technos utilisées | 2h | 4h | 3h | 2h | 3h | 4h | 5h | 5h30 | 4h30 | 3h30 | 2h | 3h | 1h | ||||||||
| Documentation sur le matériel | 2h | 1h | 1h | 2h | 1h | x | x | x | x | x | x | x | x | ||||||||
| Recherche et développement du serveur de collecte | x | 1h | 2h | 3h | 3h30 | 4h | 5h | 7h | 4h30 | 0,5h | 3h | 4h | 3h | x | |||||||
| Recherche et développement de l'interface Web | x | 2h | 1h | 3h | 5h | 6h | 4h | 7h | 5h30 | 2h30 | 6h | 8h | 5h | 1h | |||||||
| Recherche et intégration du serveur de localisation | x | x | x | x | x | x | x | x | x | x | x | x | x | x | |||||||
| Intégration des différentes parties | x | x | x | x | 2h | 2h | 2h | 3h | 1h30 | x | 3h | 6h | 5h | x | |||||||
| Tests et débuggage | x | 1h | 2h | 1h | 1h | 1h | 2h | 3h | 4h | 0,5h | |||||||||||
| Optimisation/Correction des programmes |
Avancement du Projet
Phase préparatoire
- Rendez-vous de mise au point du cahier des charges avec les encadrants/intervenants (M. ZHENG Gang et M. DAGHER Roudy)
- Elaboration du cahier des charges
- Elaboration de la page Wiki (préparation de la mise en page et présentation du sujet)
- Préparation du travail sous forme de Mind Map
Nous nous sommes tout d’abord rendus au laboratoire de l'INRIA afin de pouvoir définir le plus précisément possible le cahier des charges avec nos tuteurs.
Nous avons donc défini avec eux les technologies qu'il faudrait étudier. Vous retrouverez le choix des technologies dans la partie choix technologiques
Nous avons en même temps créé notre page Wiki, et structuré celui-ci avec les parties qui nous seraient utiles pour développer nos explications par la suite.
Nous avons de plus découpé le travail en sous-parties que nous avions mis dans un Mind map afin d'y voir plus clair sur la ligne à suivre.
Vous trouverez ce Mind map juste ci-dessous. Nous ne mettrons pas à jour ce Mind map chaque semaine mais il est fort probable que nous en referions un en milieu de projet pour pouvoir cibler les objectifs réussis et ceux à atteindre. Nous pourrons de plus redéfinir certains objectifs qui nous aurait semblé trop vague au début du projet.
Semaine 1
- Revue du Cahier des Charges avec les encadrants
- Lecture et recherches sur les technologies adaptées
- Construction de la suite de la Mind Map
- Création du Gitlab
Nous commençons les recherches sur le projet et sur les premières technologies engagées dans celui-ci. Nous en profitons pour formuler des à présent des questions sur le bon choix de celles-ci. Nous commençons donc des tests ayant seulement pour but de nous familiariser avec l'environnement de travail et de réellement comprendre les fonctions déjà présentes qu'il faudra exploiter et implanter notre interface web. Nous créons un gitlab avec notre tuteur et commençons a définir les taches premières sur celui-ci. Nous en profitons pour affiner le Mind Map.
Semaine 2
- Précisions sur le cahier des charges
- Listage du matériel
- Recherche et détermination de solutions technologiques possibles pour les fonctions demandées
- Début du travail sur le serveur de collecte
- Apprentissage du langage Python et de l'utilisation du framework Flask
Nous avons finalisé les précisions sur le cahier des charges. Nous avons donc pu cibler le matériel dont nous nous servirons pour ce Projet. Vous trouverez donc cette liste la section correspondante. Il est évident que le matériel utilisé est dans l'ensemble déjà fourni par le laboratoire et qu'il nous reste dans l'ensemble à créer l'interface web et les API qui nous permettrons de faire communiquer cette interface avec la Raspberrypi et le serveur de position déjà créé. Nous avons donc pu commencer a ce former sur les technologies qui nous serviraient par la suite. Nous avaons donc utilisé le cours d'openclassroom sur les serveur flask pour en apprendre les bases. Ce serveur flask est programmé en python et nous permets donc une grande liberté au niveau de l’exécutions de certains scripts. En effet les script de connexion bluetooth et de redirection de port qui nous permette de recuperer les données de distance sont eux meme codé en python et sont directement appelé via le serveur. Dans ce serveur, représentant notre interface web, vous retrouverez la page /collecte qui représentera notre partie collecte de données ainsi que l'affichage de ces distances. Nous appellerons cette partie le serveur de collecte.
Semaine 3
- Recherche et développement initial du serveur de collecte de données
- Complément du Git sur les tâches à effectuer
Nous avons commencé à créer un serveur flask renvoyant pour l'instant une matrice aléatoire. Lors de la requête URL "../matrice", nous voyons bien une matrice aléatoire apparaître sur la page Web. Nous essayons de nous connecter à la Raspberry Pi en redirigeant son port série vers le Bluetooth de façon à récupérer de vraies matrices de distance entre le drone (ie commutateur central) et les balises. Nous pourrons afficher ensuite ces matrices, ou alors les stocker dans un fichier en attendant le traitement de celles-ci.
Nous avons plusieurs problèmes avec le Bluetooth pour se connecter avec la Raspberry Pi. Quand nous aurons réussi à nous connecter au port série de la Raspberry pi alors nous pour gérer le traitement des données récupérées.
Semaine 4
- Configuration de la Raspberry Pi car problèmes de connectivité Bluetooth rencontrés
- Nous arrivons à connecter la Raspberry Pi sous Windows mais la connexion sous Linux pose problème (travail en suspens en attendant la disponibilité de l'encadrant)
- Début du développement de l'interface Web
- Traitement d'une matrice dans un fichier JSON
- Affichage sous forme de tableau de la matrice
- Utilisation du serveur de requête en Python avec chargement de template HTML
- Mise en forme de la trame de la page en HTML/CSS avec le framework Bootstrap
- Ajout d'un set de distances (d1, d2, d3, d4) dans la matrice lors d'un appui sur un bouton Chargement en utilisant un fichier Javascript
Nous Avons reçus des fonctions pythons de notre tuteurs afin d'obtenir une connexion bluetooth entre notre raspberrypi et notre ordinateur ainsi qu'une redirection de port de celle ci vers la connexion. Nous n'arrivons pas à utiliser ces fonctions sous linux et nous necessitons une explication de notre tuteur n'etant pas disponible a ce moment. Pour ne pas perdre de temps nous nous attaquons la creation de l'interface web a proprement parler. c'est a dire la création des pages html ainsi que le document javascript qui nous servira de bibliotheque de fonctions.chaque route de notre serveur sont relié a une series de fonctions python s'executant a l'apelle des url puis suivis d'un template de la page HTML en question. Nous en profitons de plus pour explorer le framework CSS bootstrap afin de mettre un premier design et une structure a notre page collecte qui sera la page principale de notre site pour ce début de projet.
Nous nous essayons de plus à différents tests sur des fichiers de format Json que nous devrons réussir à traiter correctement plus tard dans notre projet. Nous récupérons une matrice que nous créons nous même en python (simulation d'une série de distances récupérée) que nous transformons au format Json pour ensuite l'afficher sur notre page web. Pour pouvoir proprement afficher se fichier Json renvoyé vers notre page, nous nous servons du fichier javascript afin de créer du code html contenant la matrice.
Semaine 5
- Résolution des problèmes de connectique Bluetooth sur la Raspberry Pi
- Développement de l'interface Web
- Traitement d'une matrice dans un fichier JSON
- Début de l'ajout d'un set de distances depuis une matrice contenue dans un fichier JSON
Nous avons pu nous entretenir avec notre tuteur et donc comprendre les fonctions de connexion et de redirection de port. Nous pouvons donc continuer le développement de notre interface web. Nous arrivons à traiter un set de donné au format json et à l'afficher dans le code html. Toutefois nous créons nous mème ce set, il est maintenant nécessaire que nous arrivions à récupérer les set de distance réels reçus par la connexions bluetooth. Nous commencerons par un traitement asynchrone. L'idée est d’enregistrer les sets de distances dans un fichier Json stocké dans un dossier. Nous appellerons ce dossier plus tard via une requête ajax.
Semaine 6
- Travail sur le serveur de collecte des données
- Mise en place de la communication entre le port série de notre machine et le port série de la carte via Bluetooth de la RPi3
- Récupération et traitement (parse) manuels des données de distances dans un fichier .log via TCP/IP<->Bluetooth
- Début de l'automatisation du procédé par script Python (requete.py) et mise en place de sockets de communication
- Développement de l'interface Web
- Chargement sur commande d'un set de distances depuis une matrice contenue dans un fichier JSON
- Travail sur le layout du site
Après avoir regardé le code de ces différentes fonctions nous avons pu faire des test manuels via le shell pour récupérer des données de distances et les stocker dans un fichier Json sur notre ordinateur.
Nous utilisons les commandes suivante pour se connecter via bluetooth:
rfcomm connect /dev/rfcomm0 B8:27:EB:80:DC:89 1
Rediriger le port de la raspberrypi3 vers la connexion:
python lps-collector/tcp_serial_redirect.py /dev/rfcomm0 9600
Collecter les données dans un fichier dont nous définissons le nom:
echo "cu -s9600 -lttyACM0"| nc localhost 7777 nc localhost 7777 | grep distance > static/log/dist-capture'+date+'.log
Nous pouvons parser le flux de donner avant de le stocker dans le fichier via cette commande:
python lps-collector/lps_parse.py static/log/dist-capture"+date+".log
Il est donc nécessaire d'inclure via des thread ces différente fonctions dans notre serveur python (Flask) afin d'automatiser le processus. Le but est de pouvoir choisir sur l'interface web quels fonctions il faut exécuter et les déclencher via l'appuie sur des boutons.
Semaine 7
- Travail sur le serveur de collecte des données
- Récupération et traitement (parse) manuels des données de distances dans un fichier .log via TCP/IP<->Bluetooth
- Automatisation du procédé par script Python (requete.py)
- Mise en place de sockets de communication pour le contrôle de la collecte -> abandonné (servait à commander la collecte manuellement)
- Développement d'un script engine.py regroupant les commandes exécutables par l'utilisateur via la page Web
- Début du travail sur la fonction "STOP" manuel d'une action de collecte de données (liaison entre script html, javascript, et script python)
- Développement de l'interface Web
- Chargement sur commande d'un set de distances depuis une matrice contenue dans un fichier JSON
- Travail sur le layout du site
- Ajout des différentes commandes (connexion bluetooth, lancement commande cu, collecte des données, collecte durée donnée)
- Début de l'implémentation de la visualisation des fichiers .json obtenus après collecte et affichage dans un tableau matriciel du fichier sélectionné
Nous avons continuez a travaillez sur le serveur de collecte: Les données que nous savons récupérer via bluetooth sont stockée dans un fichier .log. Apres avoir bien compris comment marchait la fonction parse manuellement( lors de son utilisation dans le shell, nous l'avons implanter dans notre serveur de collecte qui lance cette commande lors de l’appuie sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêté. nous avons donc rajouté un temps à entré nous même sur l'interface. La fonction parse est effectué commence et le sous processus va attendre le temps donné avant de lancer une commande permettant de tuer le processus et mettant donc fin au remplissage du fichier .log. Nous voulons de plus réussir à lancer une fonction de collecte sans temps. c'est à dire que nous coupons la collecte via un bouton par nous même. nous voulions utiliser des Sockets pour pouvoir définir nous même la gestions de la communication mais l'idée a été abandonné car nous avons réussi a sauvegarder le PID du processus lancé. Il nous suffit donc de l’arrêter grâce à un autre bouton qui récupère cette variable et l’arrête ensuite.
Toutes nos fonctions pythons étant regroupées dans notre serveur requete.py nous avons décidé de créé un module qui regroupera toutes ces fonction que nous pourrons utilisé dans requete.py. ceci nous permet de voir plus claire dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.
Nous essayons en continues d'adapter le layout du site pour le rendre le plus attractif et simple possible. de facon a ce que chaque bouton et tableau soient claires et compréhensibles.
Nous avons commencé à récupéré les fichier json créé à partir des fichier log. c'est a dire que ces fichiers sont automatiquement stockés coté serveur dans un dossier nommé static/log. Notre but est de récupérer le nom des fichier json et de les afficher dans un composant sur notre interface web. il nous sera donc possible ensuite de sélectionner le nom d'un fichier. lors de la sélection de ce nom de fichier, un tableau apparaît avec les valeurs de distances à l’intérieur.
Semaine 8
- Travail sur le serveur de collecte des données
- Automatisation du procédé de collecte par script Python (requete.py qui fait appel à engine.py)
- Développement d'un script engine.py regroupant les commandes exécutables par l'utilisateur via la page Web
- Travail sur la fonction "STOP" manuel d'une action de collecte de données (liaison entre script html, javascript, et script python)
- Mise en place d'un serveur HTTP Simple sous Python pour accéder aux fichiers de données à partir de la page Web
- Mise à jour de fonctions de connexion
- Automatisation du procédé de collecte par script Python (requete.py qui fait appel à engine.py)
- Développement de l'interface Web
- Travail sur le layout du site (ajout de pages, navigation entre les pages, apparence, nettoyage des codes)
- Bon fonctionnement de l'ensemble serveur collecte + serveur HTTP + client Web
- Affichage de la liste des fichiers de données de distance (log, csv, json) via serveur HTTP en Python sur port 9999
- Corrections et nettoyage du dépôt GIT
Nous continuons a développer les points énoncé la semaine dernière. Nous avons décidé de nous dirigé vers un serveur HTTP Simple pour accéder à nos fichiers. il s’avère que nous finirons par ne pas utiliser ce serveur. Nous irons récupérer les fichiers en question via des requêtes ajax faites à la sélection du nom du fichier.
Nous rencontrons depuis le début des problèmes avec les fonctions de connexion qui peuvent ne pas marcher a un moment donner. Nous essayons de trouver pourquoi ce bug est un bug qui ne se produit pas à chaque fois. Nous avons déterminé qu'il ne se produisait seulement lorsque les fonctions de connexions étaient lancée dans des threads. Nous ne savons toujours pas pourquoi ces thread bug seulement parfois et non à chaque essaie de connexion.
Nous avons nettoyé notre dépot Git car il s’avère que nous utilisions une mauvais méthode de fusion et de stockage des documents.
Semaine 9
- Travail sur le serveur de collecte des données
- Automatisation du procédé de collecte par script Python (requete.py qui fait appel à engine.py)
- Travail sur la fonction "STOP" manuel d'une action de collecte de données (liaison entre script html, javascript, et script python)
- Recherches sur l'utilisation de fichiers json accessibles via le serveur HTTP
- Automatisation du procédé de collecte par script Python (requete.py qui fait appel à engine.py)
- Développement de l'interface Web
- Travail sur le layout du site
- Travail sur la liaison entre fichiers json et affichage Web des données de distance
- Recherches et tests de solutions
- Affichage depuis un fichier
- Affichage à la volée lors d'une action de collecte
- Recherches et tests de solutions
- Revue de code avec Roudy DAGHER:
- Structure globale des codes ok
- Fonctionnement presque ok: fonctionnalités implémentées ok, mais parsage csv ne marche pas
- Refactoring nécessaire
- Correction de la fonction STOP et amélioration de la fonction de COLLECTE
- Faire plus de requêtes Javascript que de requêtes HTML
- Discussion pour l'implémentation du serveur de localisation (= algorithme de localisation) et des visualisations de données sur le site Web
Nous avons d'abord revue l'ensemble de notre code et les méthode utilisé avec notre tuteur Roudy Dagher. Nous nous approchons d'un serveur de collecte de donné stable et fonctionnel. Nous avons refait les différentes connexions entre l'interface et le serveur afin de ne faire que des requêtes sur des WebServices. Il nous ai possible de commencer la deuxième partie qui est l'envoie de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrice de positions.
Nous pourrons grâce a ces matrices afficher une carte 3d des balises et du TAG dans l'espace.
Semaine 10
- Travail sur le serveur de collecte des données
- Travail sur la fonction STOP
- Réalisation d'une expression régulière pour le parsage des fichiers log en fichier json
- Développement de l'interface Web
- Travail sur l'affichage des fichiers json
- Réalisation de toutes les requêtes Ajax
- Réalisation d'un menu déroulant dropdown pour charger le contenu des fichiers JSON dans le tableau de distances
- Travail sur l'affichage des fichiers json
- Nettoyage du dépôt Git
Semaine 11
- Travail sur le serveur de collecte des données
- Revue de code avec Roudy DAGHER:
- Discussion sur la partie système du projet et correction de certaines fonctions
Semaine 12
- Revue, correction et nettoyage des codes
- Finalisation du rapport
- Planification de semaines restantes
- Préparation de la soutenance
- Revue de mi-projet avec tous les tuteurs
Cette dernière semaine a servi à finaliser le rapport et à discuter de l'avancée du projet, notamment avec nos tuteurs pour déterminer le travail restant, présenter le travail abouti et replanifier précisément les échéances pour le travail restant. Nous avons réalisé la soutenance de mi-projet le jeudi 21/12/17 à 8h.
Semaine 13
- Travail sur la collecte des données (serveur de collecte et interface Web)
- Redéfinition du fichier de parsage car il crée des conflits et ne produit pas un fichier formaté de la façon attendue
- Nombre de balises réel n'est pas bien déterminé par le code
- ID de la première et de la dernière balise ne sont pas déterminés correctement
- Redéfinition du fichier de parsage car il crée des conflits et ne produit pas un fichier formaté de la façon attendue
- Automatisation de la collecte par un script shell lançant toutes les commandes de CONNEXION, REDIRECTION, LANCEMENT CU, FERMETURE DU PROGRAMME (kill rfcomm / kill tcp_redirect)
- Dans le but d'automatiser la procédure
- Dans le but de résoudre un problème de gestion de ressources (le bug thread apparu plus tôt dans le projet)
- Automatisation de la collecte par un script shell lançant toutes les commandes de CONNEXION, REDIRECTION, LANCEMENT CU, FERMETURE DU PROGRAMME (kill rfcomm / kill tcp_redirect)
- Travail sur la résolution du bug thread car l'automatisation n'a pas résolu le problème
- Identification du ou des causes potentielles: gestion des ressources (synchrone, asynchrone ?), connexion bluetooth, lancement des commandes dans le même script, lancement en fg/bg, conflit dû au temps d'exécution de chaque processus ?
- Lancement des commandes manuellement dans des terminaux ne pose aucun problème: solution la plus simple
- Travail sur la résolution du bug thread car l'automatisation n'a pas résolu le problème
- Redesign de la page Collecte
- Remplacement des boutons de commande par un bouton unique d'initialisation
- Travail sur une mise à jour du menu déroulant dropdown régulière sans avoir à recharger la page Web
- Implémentation de plotly.js, un module javascript qui permet d'afficher des graphes en 3D
- Redesign de la page Collecte
- Mise au point post-soutenance avec Roudy DAGHER pour valider le travail restant, effectué et redéfinir certains objectifs atteignables ou pas selon les éléments réalisés dans le projet
- Recherches et début de l'implémentation du serveur de localisation fourni par les tuteurs
- Gestion du Git pour créer des branches additionnelles
- Recréation du rapport de projet suite à une perte du fichier éditable d'origine + Mise à jour avec les remarques suite à la soutenance ainsi que les nouveaux éléments
Semaine 14
- Travail sur la collecte des données (serveur de collecte et interface Web)
- Redéfinition du fichier de parsage car il crée des conflits et ne produit pas un fichier formaté de la façon attendue
- Corrigé: Nombre de balises réel n'est pas bien déterminé par le code
- Corrigé: ID de la première et de la dernière balise ne sont pas déterminés correctement
- Reste à faire: Traiter le cas où il y a un ajout ou suppression d'une balise pendant la collecte (pour le moment, lorsque c'est le cas, toutes les données se décalent au lieu de laisser des trous)
- Redéfinition du fichier de parsage car il crée des conflits et ne produit pas un fichier formaté de la façon attendue
- Automatisation de la collecte par un script shell lançant toutes les commandes de CONNEXION, REDIRECTION, LANCEMENT CU, FERMETURE DU PROGRAMME (kill rfcomm / kill tcp_redirect)
- Mis en suspens: pour le moment, on lance les commandes manuellement dans le terminal
- Automatisation de la collecte par un script shell lançant toutes les commandes de CONNEXION, REDIRECTION, LANCEMENT CU, FERMETURE DU PROGRAMME (kill rfcomm / kill tcp_redirect)
- Interface Web
- Implémentation de plotly.js, un module javascript qui permet d'afficher des graphes en 3D
- Interface Web
- Implémentation du serveur de localisation fourni par les tuteurs (mais algorithme de localisation pas fonctionnel pour le moment)
- Mise à jour de l'affichage des positions des éléments: précédemment seule la matrice X de position du Tag s'affichait, et pas la matrice A des balises
- Requêtes manuelles à l'API avec la fonction curl OK: on arrive à récupérer les matrices X et A (aléatoires pour le moment) par une requête GET à l'API du serveur de localisation
- Implémentation des requêtes Ajax pour automatiser les requêtes au serveur de localisation
- Mise à jour du rapport les nouveaux éléments du travail réalisé
- Réflexion sur la possibilité ou non de réaliser la partie temps réel du projet au vu des moyens à disposition
Observations
Problèmes rencontrés
Solutions apportées
Délivrables
Rapport de mi-PFE Fichier:RapportMi-PFE-UNG DELATTE.pdf
Rapport de PFE
Vidéo
