P18 Localisation of quadrotors : Différence entre versions

De Wiki de Projets IMA
(→‎Avancement du Projet)
 
(131 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
 +
<include nopre noesc src="/home/pedago/pimasc/include/video-LocalisationDrone-iframe.html" />
 +
__TOC__
 +
<br style="clear: both;"/>
 
==<span style="color:#000080">'''Cahier des charges'''</span>==
 
==<span style="color:#000080">'''Cahier des charges'''</span>==
  
Ligne 45 : Ligne 48 :
  
  
−
====<span style="color:#6B8E23">Calendrier</span>====
+
====<span style="color:#6B8E23">Calendrier prévisionnel</span>====
  
 
''[[Avant le 29/09/17]]'' - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel
 
''[[Avant le 29/09/17]]'' - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel
Ligne 57 : Ligne 60 :
 
Répartition du volume de travail (***h):
 
Répartition du volume de travail (***h):
  
−
* Recherche sur les technologies à utiliser (**h)
+
* Recherche sur les technologies à utiliser
−
* Développement du serveur de collecte de données (**h)
+
* Développement du serveur de collecte de données
−
* Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
+
* Réalisation de l'interface logicielle (Web//Logiciel/Application)
−
* Intégration des différentes parties (**h)
+
* Intégration des différentes parties
−
* Test et débuguage (**h)
+
* Test et débuggage
  
 
====<span style="color:#6B8E23">Choix techniques : matériel et logiciel</span>====
 
====<span style="color:#6B8E23">Choix techniques : matériel et logiciel</span>====
  
 
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.
 
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.
 +
 +
====<span style="color:#6B8E23">Choix technologiques</span>====
 +
 +
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)
  
 
===<span style="color:#4169E1">'''Calendrier prévisionnel'''</span>===
 
===<span style="color:#4169E1">'''Calendrier prévisionnel'''</span>===
Ligne 71 : Ligne 95 :
 
====<span style="color:#6B8E23">Liste des tâches à effectuer</span>====
 
====<span style="color:#6B8E23">Liste des tâches à effectuer</span>====
  
−
'''A modifier'''
+
# 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
  
−
# Documentation sur le réseau LoRa
+
 
−
##moyen de transmission
+
===<span style="color:#4169E1">Replanification du cahier des charges / calendrier</span>===
−
##format de modulation
 
−
##trame des paquets
 
−
# Réalisation du premier montage brouillant toute la plage
 
−
##contrôler l'émetteur RF du cc430
 
−
##programmer un bruitage sur la plage 863-870MHz
 
−
##test et optimisation
 
−
# Ajout d'un récepteur LoRa pour détecter et brouiller une seule communication
 
−
##contrôler le récepteur LoRa avec le cc430 par protocole spi
 
−
##détecter une communication LoRa à une fréquence donnée
 
−
##contrôler l'émetteur RF afin de brouiller cette communication de manière brutale
 
−
##brouiller cette communication en tentant de changer les données du paquet
 
−
##test et optimisation
 
  
 
==<span style="color:#000080">'''Feuille d'heures'''</span>==
 
==<span style="color:#000080">'''Feuille d'heures'''</span>==
  
 
{| class="wikitable"
 
{| class="wikitable"
−
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Après les vacances !! Total
+
!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
+
| Cahier des charges / Wiki / Gitlab / Rapport
−
| 2h
+
| 4h
−
| 1h
+
|  3h
−
| 1h
+
|  1h
−
| 0,5h
+
|  x
 +
|  1h30
 +
|  1h
 +
|  2h
 +
| 1h
 +
| 2h30
 +
|  1h
 +
| 3h
 +
|  3h30
 +
|  2h
 +
|  5h
 +
|  x
 +
|  1h
 +
|  2h
 +
| 
 +
|
 
|
 
|
−
|0,5h
 
−
|0,5h
 
−
|0,5h
 
 
|
 
|
−
|0,5h
 
−
|0,5h
 
−
|0,5h
 
−
| 7,5h
 
 
|-
 
|-
−
| Documentation sur le réseau LoRa
+
| Documentation sur les technos utilisées
−
| 2h
+
| 2h
−
| 4h
+
| 4h
−
| 1,5h
+
| 3h
−
| 4h
+
|  2h
−
|
+
|  3h
 +
|  4h
 +
|  5h
 +
| 5h30
 +
|  4h30
 +
|  3h30
 +
|  2h
 +
|  3h
 +
|  1h
 +
|  3h
 +
|  4h
 +
| x
 +
|  2h
 +
| 
 
|
 
|
 
|
 
|
 
|
 
|
 +
|-
 +
| Documentation sur le matériel
 +
|  2h
 +
|  1h
 +
|  1h
 +
|  2h
 +
|  1h
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  1h
 +
|  1h
 +
|  x
 +
|  x
 +
| 
 
|
 
|
 
|
 
|
 
|
 
|
−
|
 
−
|11,5h
 
 
|-
 
|-
−
| Documentation sur le matériel
+
| Recherche et développement du serveur de collecte
−
| 1h
+
| x
−
| 3h
+
|  1h
−
| 2h
+
| 2h
−
| 3h
+
|  3h
 +
| 3h30
 +
|  4h
 +
|  5h
 +
|  7h
 +
|  4h30
 +
|  0,5h
 +
|  3h
 +
|  4h
 +
| 3h
 +
|  x
 +
|  4h
 +
|  7h30
 +
|  5h
 
|
 
|
 
|
 
|
−
| 1h
 
−
| 1h
 
−
| 1h
 
 
|
 
|
 
|
 
|
−
|
 
−
|12h
 
 
|-
 
|-
−
| Recherche de solution pour la fonction 1
+
| Recherche et développement de l'interface Web
−
|  
+
| x
−
|  
+
| 2h
−
| 2h
+
|  1h
−
| 1,5h
+
|  3h
−
| 2h
+
|  5h
−
| 2h
+
| 6h
 +
|  4h
 +
|  7h
 +
|  5h30
 +
|  2h30
 +
|  6h
 +
|  8h
 +
| 5h
 +
| 1h
 +
|  8h
 +
|  4h
 +
|  4h
 +
|
 
|
 
|
 
|
 
|
 
|
 
|
 +
|-
 +
| Recherche et intégration du serveur de localisation
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  x
 +
|  6h
 +
|  5h
 +
|  3h
 +
| 
 
|
 
|
 
|
 
|
 
|
 
|
−
| 7,5h
 
 
|-
 
|-
−
| Recherche de solution pour la fonction 2
+
| Intégration des différentes parties
−
|  
+
| x
−
|  
+
| x 
 +
|  x
 +
|  x
 +
|  2h
 +
|  2h
 +
|  2h
 +
|  3h
 +
|  1h30
 +
|  x
 +
|  3h
 +
|  6h
 +
|  5h
 +
|  x
 +
|  3h30
 +
|  2h
 +
|  2h
 +
| 
 
|
 
|
 
|
 
|
 
|
 
|
 +
|-
 +
| Tests et débuggage
 +
|  x
 +
|  1h
 +
|  2h
 +
|  1h
 +
|  1h
 +
|  1h
 +
|  2h
 +
|  3h
 +
|  4h
 +
|  0,5h
 +
|  3h
 +
|  1h
 +
|  3h
 +
|  3h
 +
|  2h
 +
|  1h
 +
|  4h
 +
| 
 
|
 
|
 +
|
 
|
 
|
−
| 2h
 
−
| 1h
 
−
| 2h
 
−
|
 
−
| 2h
 
−
| 7h
 
 
|-
 
|-
−
| Initialisation des registres
+
| Optimisation/Correction des programmes
 
|  
 
|  
 
|  
 
|  
 
|
 
|
 
|
 
|
−
|3h
 
−
|3h
 
 
|
 
|
 +
|
 +
|
 +
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
 
|
−
|2,5h
 
−
| 8,5h
 
−
|-
 
−
| Code 1ère fonction
 
−
|
 
−
|
 
 
|
 
|
−
|1,5h
 
−
|3h
 
−
|3h
 
−
|4h
 
 
|
 
|
 
|
 
|
Ligne 196 : Ligne 319 :
 
|
 
|
 
|
 
|
−
| 11,5h
 
−
|-
 
−
| Code 2ème fonction
 
 
|  
 
|  
 
|  
 
|  
 
|
 
|
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
| 3h
 
−
| 2h
 
−
| 2h
 
−
| 1h
 
−
| 8h
 
 
|-
 
|-
−
| Optimisation/Correction fonction 1
+
| Vidéo
−
|
 
 
|  
 
|  
 
|
 
|
 
|
 
|
 
|
 
|
−
| 1h
 
−
| 2h
 
−
| 2h
 
−
|
 
−
| 2h
 
 
|  
 
|  
 
|  
 
|  
−
| 7h
+
|  
−
|-
 
−
| Optimisation/Correction fonction 2
 
 
|
 
|
 
|
 
|
Ligne 239 : Ligne 341 :
 
|
 
|
 
|
 
|
−
| 2h
 
−
| 4h
 
−
| 6h
 
−
|-
 
−
| Tests et mesures
 
 
|  
 
|  
 
|  
 
|  
 
|
 
|
 
|
 
|
−
|
 
−
|
 
−
| 1h
 
−
| 2h
 
−
| 3h
 
−
| 2h
 
−
| 3h
 
−
| 5h
 
−
| 16h
 
−
|-
 
−
| Modification de la carte
 
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
|
 
−
| 3h
 
−
|
 
−
| 3h
 
 
|}
 
|}
  
Ligne 283 : Ligne 356 :
 
*Elaboration de la page Wiki (préparation de la mise en page et présentation du sujet)
 
*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
 
*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ée celle-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 une '''Mind map''' afin d'y voir plus clair sur la ligne à suivre.
 +
 +
Vous trouverez cette Mind map juste ci-dessous. Nous ne mettrons pas à jour cette Mind map chaque semaine mais il est fort probable que nous en refaisions 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 auraient semblés trop vague au début du projet.
 +
 +
 +
[[Fichier:Projet de fin d'étude.png|centre|600px]]
  
 
===<span style="color:#4169E1">'''Semaine 1'''</span>===
 
===<span style="color:#4169E1">'''Semaine 1'''</span>===
  
−
''[[28/09/17 - 29/09/17]]''  
+
''[[Jeu 28/09/17 - Ven 29/09/17]]''  
−
*Revue du Cahier des Charges
+
*Revue du Cahier des Charges avec les encadrants
 
*Lecture et recherches sur les technologies adaptées
 
*Lecture et recherches sur les technologies adaptées
 
*Construction de la suite de la Mind Map
 
*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 dès à 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 dépôt 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.
  
 
===<span style="color:#4169E1">'''Semaine 2'''</span>===
 
===<span style="color:#4169E1">'''Semaine 2'''</span>===
  
−
''[[30/01/17 - 05/02/17]]''   
+
''[[Jeu 05/10/17 - Ven 06/10/17]]''   
 
*Précisions sur le cahier des charges
 
*Précisions sur le cahier des charges
 
*Listage du matériel
 
*Listage du matériel
 
*Recherche et détermination de solutions technologiques possibles pour les fonctions demandées
 
*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 Raspberry Pi et le serveur de position déjà créé.
 +
Nous avons donc pu commencer à nous former sur les technologies qui nous serviraient par la suite. Nous avons donc utilisé le cours d'Openclassrooms sur les serveurs Flask pour en apprendre les bases. Ce serveur Flask est programmé en Python et nous permet donc une grande liberté au niveau de l’exécution de certains scripts. En effet, les scripts de connexion Bluetooth et de redirection de port qui nous permettent de récupérer les données de distance sont eux-mêmes codés en Python et sont directement appelés 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.
  
 
===<span style="color:#4169E1">'''Semaine 3'''</span>===
 
===<span style="color:#4169E1">'''Semaine 3'''</span>===
  
−
''[[06/02/17 - 12/02/17]]''
+
''[[Mer 11/10/17 - Jeu 12/10/17]]''
−
*validation du matériel
+
*Recherche et développement initial du serveur de collecte de données
−
Nous allons utiliser un cc430f5137 (MCU+RF) monté sur une carte optimisée pour les communications autours de 868Mhz.
+
*Complément du Git sur les tâches à effectuer
−
Nous pouvons commencer à étudier son fonctionnement, particulièrement celui du module RF (cc1101).
+
 
−
Nous avons aussi récupéré des exemples de code en c sur le site de Texas Instrument et vu l'utilisation de ces codes sur un projet IMA5 de l'an passé.
+
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.
 +
 
 +
[[Fichier:Requete s3.PNG|300px|serveur Flask]]
 +
 
 +
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 pourrons gérer le traitement des données récupérées.
  
 
===<span style="color:#4169E1">'''Semaine 4'''</span>===
 
===<span style="color:#4169E1">'''Semaine 4'''</span>===
−
''[[13/02/17 - 19/02/17]]''
 
−
*Recherche de solutions pour répondre à la 1ère fonction (brouiller la plage 863-870Mhz).
 
  
−
Après une lecture approfondie de la datasheet du module RF du cc430, nous avons choisi d'utiliser la fréquence de base du module (pouvant être définie grâce aux registres) couplée au registre CHANNR. Cela nous permettra de modifier plus facilement la fréquence de la porteuse, en suivant la formule suivante : [[Fichier:rampe.png]].
+
''[[Mer 18/10/17 - Jeu 19/10/17]]'' 
 +
*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 pourrons alors balayer la plage de fréquence en changeant la valeur de CHANNR.
+
Nous avons reçu des fonctions Python de notre tuteur afin d'obtenir une connexion Bluetooth entre notre Raspberry Pi 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 nécessitons une explication de notre tuteur n'étant pas disponible à ce moment. Pour ne pas perdre de temps, nous attaquons la création de l'interface web à proprement parler, c'est à dire la création des pages HTML ainsi que le document Javascript qui nous servira de bibliothèque de fonctions. Chaque route de notre serveur est reliée à une série de fonctions Python s'exécutant à l'appel des url puis suivies 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êmes 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 ce fichier '''JSON''' renvoyé vers notre page, nous nous servons du fichier Javascript afin de créer du code HTML contenant la matrice.
  
 
===<span style="color:#4169E1">'''Semaine 5'''</span>===
 
===<span style="color:#4169E1">'''Semaine 5'''</span>===
−
''[[27/02/17 - 05/03/17]]''
 
  
−
A l'aide de la datasheet du cc1101 ([http://www.ti.com/lit/ds/symlink/cc1101.pdf datasheet_cc1101] pages : 70 à 95), nous avons défini les registres du module RF de la manière suivante (sachant que la fréquence du quartz est de 26MHz, soit Fxosc=26MHz) :
+
''[[Mer 25/10/17 - Ven 27/10/17]]'' 
 +
*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
  
−
*La fréquence de base a été fixée à 862,999MHz en suivant la formule donnée dans la data sheet[[Fichier:carrier_formula.png]]
+
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ées au format JSON et à l'afficher dans le code HTML. Toutefois nous créons nous-mêmes ce set, il est maintenant nécessaire que nous arrivions à récupérer les sets de distance réels reçus par la connexion 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.
−
ce qui nous a donné les valeurs FREQ2=0x21, FREQ1=0x31 et FREQ0=0x3A (FREQ=2 175 290)
 
  
−
*Nous avons suivi la formule [[Fichier:chanspace_formula.png]] afin d'avoir un espacement entre les cannaux d'environ 100Khz
+
===<span style="color:#4169E1">'''Semaine 6'''</span>===
−
ce qui nous a donné  MDMCFG1=0x02 (CHANSPC_E=2) et MDMCFG0=0x00(CHANSPC_M=0)
 
  
−
*Pour le moment, nous avons choisi le mode de modulation AM, nous avons donc initialisé les registres MDMCFG2=0x30 (mode ASK/OOK) et FREND0=0x50(patable=0 donnant le mode ASK)
+
''[[Mer 08/11/17 - Ven 10/11/17]]'' 
 +
*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
  
−
*Nous avons créé une bibliothèque RFconfig.h regroupant les valeurs de tous les registres :
+
Après avoir regardé le code de ces différentes fonctions nous avons pu faire des tests manuels via le Shell pour récupérer des données de distances et les stocker dans un fichier '''JSON''' sur notre ordinateur.
  
−
#define SMARTRF_CC430F5137_H
+
Nous utilisons les commandes suivantes pour se connecter via Bluetooth:
−
#define SMARTRF_RADIO_CC430F5137
 
−
 
−
#define SMARTRF_SETTING_IOCFG2    0x29 //default
 
−
#define SMARTRF_SETTING_IOCFG1    0x2E //default
 
−
#define SMARTRF_SETTING_IOCFG0    0x02 //assert if TX fifo above trsh
 
−
#define SMARTRF_SETTING_FIFOTHR    0x07 //default (0x0F may be better)
 
−
#define SMARTRF_SETTING_SYNC1      0xD3 //default
 
−
#define SMARTRF_SETTING_SYNC0      0x91 //default
 
−
#define SMARTRF_SETTING_PKTLEN    0xFF //default (disabled by PKCTRL0 set to 0x05)
 
−
#define SMARTRF_SETTING_PKTCTRL1  0x04 //default
 
−
#define SMARTRF_SETTING_PKTCTRL0  0x05 //normal pkt format, variable pkt lenght
 
−
#define SMARTRF_SETTING_ADDR      0x00 //default (device address)
 
−
#define SMARTRF_SETTING_CHANNR    0x00 //0 (will be incremented in main.c)
 
−
#define SMARTRF_SETTING_FSCTRL1    0x0F //default (IF frequency)
 
−
#define SMARTRF_SETTING_FSCTRL0    0x00 //default (freq offset)
 
−
#define SMARTRF_SETTING_FREQ2      0x21 /*freq*/
 
−
#define SMARTRF_SETTING_FREQ1      0x31 //868Mhz
 
−
#define SMARTRF_SETTING_FREQ0      0x3A /*freq*/
 
−
#define SMARTRF_SETTING_MDMCFG4    0x8C //default (BW=203KHz)
 
−
#define SMARTRF_SETTING_MDMCFG3    0x22 //default (data rate)
 
−
#define SMARTRF_SETTING_MDMCFG2    0x30 // ASK/OOK,no sync-word
 
−
#define SMARTRF_SETTING_MDMCFG1    0x02 // 2 bytes preamble, chanspc_e=2
 
−
#define SMARTRF_SETTING_MDMCFG0    0x00 //chanspc_m=0
 
−
#define SMARTRF_SETTING_DEVIATN    0x47 //default (no effet on ASK/OOK mode)
 
−
#define SMARTRF_SETTING_MCSM2      0x07 //default timeout disable
 
−
#define SMARTRF_SETTING_MCSM1      0x18 //stay in TX mode
 
−
#define SMARTRF_SETTING_MCSM0      0x18 //autocal when going in TX or RX
 
−
#define SMARTRF_SETTING_FOCCFG    0x36 //default (frenquency offset not used)
 
−
#define SMARTRF_SETTING_BSCFG      0x6C //default
 
−
#define SMARTRF_SETTING_AGCCTRL2  0x03 //default (maximum possible gain)
 
−
#define SMARTRF_SETTING_AGCCTRL1  0x40 //default
 
−
#define SMARTRF_SETTING_AGCCTRL0  0x91 //default
 
−
#define SMARTRF_SETTING_WOREVT1    0x87 //default
 
−
#define SMARTRF_SETTING_WOREVT0    0x6B //default
 
−
#define SMARTRF_SETTING_WORCTRL    0xF8 //default
 
−
#define SMARTRF_SETTING_FREND1    0x56 //default
 
−
#define SMARTRF_SETTING_FREND0    0x50 //patable=0 -> ASK
 
−
#define SMARTRF_SETTING_FSCAL3    0xE9 //smartRF studio
 
−
#define SMARTRF_SETTING_FSCAL2    0x2A //high VCO choosen
 
−
#define SMARTRF_SETTING_FSCAL1    0x00 //smartRF studio
 
−
#define SMARTRF_SETTING_FSCAL0    0x1F //smartRF studio
 
−
#define SMARTRF_SETTING_FSTEST    0x59 //default (test only)
 
−
#define SMARTRF_SETTING_PTEST      0x7F //default (test only)
 
−
#define SMARTRF_SETTING_AGCTEST    0x3F //default (test only)
 
−
#define SMARTRF_SETTING_TEST2      0x81 //smartRF studio
 
−
#define SMARTRF_SETTING_TEST1      0x35 //smartRF studio
 
−
#define SMARTRF_SETTING_TEST0      0x0B //default
 
  
−
===<span style="color:#4169E1">'''Semaine 6'''</span>===
+
rfcomm connect /dev/rfcomm0 B8:27:EB:80:DC:89 1
−
''[[06/03/17 - 12/03/17]]''
+
 
−
*Nous avons préparé un premier code réalisant une rampe sur la plage 863-870MHz. Ce code est basé sur une boucle infinie qui incrémente le registre chann de 0 à 69 (pour passer de 863 à 870Mhz) et envoie des paquets 0xFF grâce aux fonctions ChangeChannel(chann) et send_comand().
+
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:
  
−
  #include <msp430.h>
+
  echo "cu -s9600 -lttyACM0"| nc localhost 7777
−
#include <stdint.h>
+
  nc localhost 7777 | grep distance > static/log/dist-capture'+date+'.log
−
 
−
#include "RF1A.h"
 
−
  #include "RF_Connection.h"
 
−
#include "PMM.h"
 
−
#include "ports.h"
 
−
#include "RFconfig.h"
 
−
 
−
#define BUFFER_SIZE 1 // maximum size of data sent by rf
 
−
 
−
#define PWM_PERIOD 255
 
−
#define DELAY 10000
 
−
 
−
volatile uint8_t buffer[BUFFER_SIZE];
 
−
 
−
void send_cmd(void)
 
−
{
 
−
  buffer[0] = 0xFF;
 
−
  rf_transmit((uint8_t *)buffer, 2);
 
−
}
 
−
 
−
int main(void)
 
−
{
 
−
  unsigned char chann=0x00;
 
−
  WDTCTL = WDTPW + WDTHOLD;  // Stop WDT
 
−
  rf_init();
 
−
  ReceiveOff();
 
−
  _BIS_SR(GIE);
 
−
 
−
  while(1)
 
−
    {
 
−
      ChangeChannel(chann);
 
−
      send_cmd();
 
−
      if(chann>=69)
 
−
{
 
−
  chann=0x00;
 
−
}
 
−
      else
 
−
{
 
−
  chann++;
 
−
}
 
−
      __delay_cycles(DELAY);
 
−
    }
 
−
  return 0;
 
−
}
 
  
 +
Nous pouvons '''parser''' le flux de données avant de le stocker dans le fichier via cette commande:
  
−
*Après quelques corrections du code, nous avons pu le compiler grâce au Makefile
+
Python lps-collector/lps_parse.py static/log/dist-capture"+date+".log
  
−
*Avec la commande (exécutée en root) et le montage suivants, nous avons upload le main sur le cc430
+
Il est donc nécessaire d'inclure via des '''thread''' ces différentes 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'appui sur des boutons.
−
mspdebug rf2500 "prog main"
 
−
[[Fichier:montage001.png]]
 
  
 
===<span style="color:#4169E1">'''Semaine 7'''</span>===
 
===<span style="color:#4169E1">'''Semaine 7'''</span>===
−
''[[13/03/17 - 19/03/17]]''
 
  
−
Nous avons commencé les premiers tests sur l'analyseur de spectre afin de vérifier que le code fonctionne bien.
+
''[[Mer 15/11/17 - Ven 17/11/17]]'' 
 +
*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é
  
−
*Dans un premier temps, nous avons essayé une fréquence fixe pour voir la calibration du cc430.
+
Nous avons continué à travailler sur le serveur de collecte: les données que nous avons récupérées via Bluetooth sont stockées dans un fichier .log. Apres avoir bien compris comment marchait la fonction '''parse''' manuellement (lors de son utilisation dans le Shell), nous l'avons implémentée dans notre serveur de collecte qui lance cette commande lors de l’appui sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêter. Nous avons donc rajouté un temps à entrer nous-même sur l'interface. La fonction '''parse''' est effectuée 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êmes. Nous voulions utiliser des Sockets pour pouvoir définir nous-mêmes la gestion de la communication mais l'idée a été abandonné car nous avons réussi à 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.  
−
[[Fichier:862.png]]
 
−
Avec un exemple à 862Mhz, on remarque bien que les registres ont bien été initialisés et que la carte émet à la fréquence demandée.
 
  
−
*Ensuite, nous avons testé le code effectuant le balayage sur la plage de fréquence 863-870Mhz, en augmentant le sweep time de l'analyseur de spectre pour voir les différentes fréquences auxquelles la carte émet.
+
Toutes nos fonctions Pythons étant regroupées dans notre serveur '''requete.py''', nous avons décidé de créer un module qui regroupera toutes ces fonctions que nous pourrons utiliser dans '''requete.py'''. ceci nous permet de voir plus clair dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.
−
[[Fichier:sweep.png]]
 
−
En observant de 861 à 872 Mhz sur l'écran de l'analyseur, on peut voir que le code effectue bien le balayage.
 
  
−
*La puissance d'émission de la carte étant faible, nous avons essayé de l'augmenter en modifiant certains registres notamment ceux que l'on peut optimiser à l'aide du logiciel smart RF studio. Cependant, nous pensons qu'il faudra changer l'antenne patch actuelle de la carte pour une antenne connectée en SMA.
+
Nous essayons en continu d'adapter le layout du site pour le rendre le plus attractif et simple possible, de façon à ce que chaque bouton et tableau soient clairs et compréhensibles.
  
−
*Nous avons aussi tenté de brouiller les communications d'autres groupes de projet utilisant des modules LoRa. Ces derniers étant configurés à 433Mhz, nous avons dû changer la fréquence de notre carte. Le brouillage ne fonctionnait pas mais notre carte étant optimisée pour une émission autour de 868Mhz, les résultats n'étaient pas pertinents.
+
Nous avons commencé à récupérer les fichiers '''JSON''' créés à partir des fichier '''log''', c'est-à-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 fichiers 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.
  
 
===<span style="color:#4169E1">'''Semaine 8'''</span>===
 
===<span style="color:#4169E1">'''Semaine 8'''</span>===
  
−
''[[20/03/17 - 26/03/17]]''  
+
''[[Mer 22/11/17 - Ven 24/11/17]]''
 +
*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
 +
*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 avons emprunté à M. Vantroys 3 modules SX1276 montés sur des cartes NUCLEO-F401RE afin de pouvoir tester notre carte sur une communication LoRa à 868Mhz
+
Nous continuons à développer les points énoncés la semaine dernière. Nous avons décidé de nous diriger 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.
−
[[Fichier:lorambed.png]]
 
−
*Le code utilisé pour le test a été récupéré sur le forum des développeurs du site mbed.com. C'est un code "ping pong" effectuant une communication continue entre deux modules LoRa à une fréquence de 868Mhz. Il nous a suffit d'utiliser le compilateur du site (qui regroupe toutes les bibliothèques nécessaires) en indiquant que la carte utilisée est une F401RE pour que le binaire produit soit compatible. La carte NUCLEO étant reconnue comme un système de fichier par Linux, pour la flasher il faut la monter en usb à l'aide des commandes fdisk et mount puis de copier le binaire dedans avec la commande cp.
 
−
[[Fichier:lora pingpong.zip]]
 
−
*Une fois les modules NUCLEO flashés, la communication LoRa est établie dès que deux modules sont alimentés. Nous avons donc branché en USB deux modules sur deux machines différentes afin d'observer la communication sur des terminaux. La communication se fait bien, l'un envoie "ping" tandis que l'autre envoie "pong" lorsqu'il reçoit "ping". Malheureusement, comme nous l'avions prédit, notre carte a une puissance d'émission trop faible et ne parvient pas à brouiller efficacement.
 
−
*Les modules peuvent aussi communiquer en modulation FSK, dans ce cas notre système arrive à effectuer le brouillage. Néanmoins, il serait plus intéressant de parvenir à brouiller la communication LoRa.
 
−
*Après plusieurs changements dans le code du cc430, n'ayant pas de résultats positifs, nous avons diminué la puissance d'émission des modules LoRa en changeant un header dans le code lora_pingpong.cpp. En passant cette puissance de 14dBm à 6dBm, nous sommes parvenus à brouiller la communication entre les deux modules LoRa.
 
  
−
*En parallèle, nous avons commencé à rechercher des solutions pour la fonction 2. Un pseudo code est donné sur le site ti.com ([https://www.ti.com/lit/an/swra315/swra315.pdf pseudo_code_frequency_scanning]) qui permet de faire un scan sur une plage de fréquence et de récupérer la fréquence ou le signal reçu est le plus fort. Ce code pourra être écrit en C puis incorporé dans notre main pour détecter une communication et la brouiller.
+
Nous rencontrons depuis le début des problèmes avec les fonctions de connexion qui peuvent ne pas marcher à un moment donné. 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 bugguent seulement parfois et non à chaque essai de connexion.
 +
 
 +
Nous avons nettoyé notre dépot '''Git''' car il s’avère que nous utilisions une mauvaise méthode de fusion et de stockage des documents.
  
 
===<span style="color:#4169E1">'''Semaine 9'''</span>===
 
===<span style="color:#4169E1">'''Semaine 9'''</span>===
  
−
''[[27/03/17 - 02/04/17]]''
+
''[[Mer 29/11/17 - Jeudi 30/11/17]]''
 +
*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
 +
*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
  
−
*Même si le brouillage ne s’effectue qu'à puissance réduite, nous avons cherché à l'optimiser
+
*Revue de code avec Roudy DAGHER:
−
**Nous avons premièrement réalisé que le mode de modulation choisi au départ (ASK) n'était pas adapté au brouillage d'une communication LoRa. Nous avons donc essayé le mode GFSK qui est le plus proche du format de modulation du réseau LoRa. Nous avons aussi essayé les modes 2FSK et 4FSK qui sont relativement proches du GFSK. Nous en avons conclu que le mode de modulation à utiliser est GFSK (ce mode fonctionne aussi pour brouiller la modulation FSK)
+
**Structure globale des codes ok
−
**Ensuite, nous avons réduit la plage de fréquence balayée par le cc430 afin de voir si il y avait une influence sur le brouillage. Nous avons remarqué que le brouillage était plus efficace pour un balayage de 866 à 870 Mhz (au lieu de 863-870 initialement)
+
**Fonctionnement presque ok: fonctionnalités implémentées ok, mais parsage csv ne marche pas
−
**Dans le même ordre d'idée, nous avons décidé de réduire le nombre d'incrémentations du registre CHANNR afin d'augmenter la rapidité du balayage. Pour ce faire, nous avons augmenté la taille de chaque canal, passant de 100kHz à 200kHz
+
**Refactoring nécessaire
−
**La puissance d'émission de la carte a été changée dans la fonction WritePATable (appelée par rfinit() dans le main), afin d'être maximale (12dBm)
+
**Correction de la fonction STOP et amélioration de la fonction de COLLECTE
−
**Enfin, nous avons augmenté le nombre de paquets à envoyer
+
**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
  
−
Nouvelle bibliothèque RFconfig.h :
 
  
−
#define SMARTRF_CC430F5137_H
+
Nous avons d'abord revu l'ensemble de notre code et les méthodes utilisées avec notre tuteur '''Roudy Dagher'''. Nous nous approchons d'un serveur de collecte de données 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 est possible de commencer la deuxième partie qui est l'envoi de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrices de positions.
−
#define SMARTRF_RADIO_CC430F5137
+
Nous pourrons grâce à ces matrices afficher une carte 3D des balises et du TAG dans l'espace.
−
 
−
#define SMARTRF_SETTING_IOCFG2    0x29 //default
 
−
#define SMARTRF_SETTING_IOCFG1    0x2E //default
 
−
#define SMARTRF_SETTING_IOCFG0    0x02 //assert if TX fifo above trsh
 
−
#define SMARTRF_SETTING_FIFOTHR    0x07 //default (0x0F may be better)
 
−
#define SMARTRF_SETTING_SYNC1      0xD3 //default
 
−
#define SMARTRF_SETTING_SYNC0      0x91 //default
 
−
#define SMARTRF_SETTING_PKTLEN    0xFF //default (disabled by PKCTRL0 set to 0x05)
 
−
#define SMARTRF_SETTING_PKTCTRL1  0x04 //default
 
−
#define SMARTRF_SETTING_PKTCTRL0  0x05 //normal pkt format, variable pkt lenght
 
−
#define SMARTRF_SETTING_ADDR      0x00 //default (device address)
 
−
#define SMARTRF_SETTING_CHANNR    0x00 // (will be incremented in main.c)
 
−
#define SMARTRF_SETTING_FSCTRL1    0x06 //default 0f (IF frequency)
 
−
#define SMARTRF_SETTING_FSCTRL0    0x00 //default (freq offset)
 
−
#define SMARTRF_SETTING_FREQ2      0x21 /*freq*/
 
−
#define SMARTRF_SETTING_FREQ1      0x4E //866
 
−
#define SMARTRF_SETTING_FREQ0      0xC2 /*freq*/
 
−
#define SMARTRF_SETTING_MDMCFG4    0x8C //default (BW=203KHz)
 
−
#define SMARTRF_SETTING_MDMCFG3    0x83 // data rate
 
−
#define SMARTRF_SETTING_MDMCFG2    0x13 // GFSK
 
−
#define SMARTRF_SETTING_MDMCFG1    0x22 // 2 bytes preamble, chanspc_e=2
 
−
#define SMARTRF_SETTING_MDMCFG0    0xF8 //chanspc_m=248
 
−
#define SMARTRF_SETTING_DEVIATN    0x47 // default 47khz deviation
 
−
#define SMARTRF_SETTING_MCSM2      0x07 //default timeout disable
 
−
#define SMARTRF_SETTING_MCSM1      0x18 //stay in TX mode
 
−
#define SMARTRF_SETTING_MCSM0      0x18 //autocal when going in TX or RX
 
−
#define SMARTRF_SETTING_FOCCFG    0x36 //default (frenquency offset for demodulation)
 
−
#define SMARTRF_SETTING_BSCFG      0x6C //default
 
−
#define SMARTRF_SETTING_AGCCTRL2  0x07 // (maximum possible gain)
 
−
  #define SMARTRF_SETTING_AGCCTRL1  0x77 //
 
−
#define SMARTRF_SETTING_AGCCTRL0  0x91 //default
 
−
#define SMARTRF_SETTING_WOREVT1    0x87 //default
 
−
#define SMARTRF_SETTING_WOREVT0    0x6B //default
 
−
#define SMARTRF_SETTING_WORCTRL    0xF8 //default
 
−
#define SMARTRF_SETTING_FREND1    0x56 //default
 
−
#define SMARTRF_SETTING_FREND0    0x10 //patable=0 (useless for gfsk)
 
−
#define SMARTRF_SETTING_FSCAL3    0xE9 //smartRF studio
 
−
#define SMARTRF_SETTING_FSCAL2    0x2A //high VCO choosed
 
−
#define SMARTRF_SETTING_FSCAL1    0x00 //smartRF studio
 
−
#define SMARTRF_SETTING_FSCAL0    0x1F //smartRF studio
 
−
#define SMARTRF_SETTING_FSTEST    0x59 //default (test only)
 
−
#define SMARTRF_SETTING_PTEST      0x7F //default (test only)
 
−
#define SMARTRF_SETTING_AGCTEST    0x3F //default (test only)
 
−
#define SMARTRF_SETTING_TEST2      0x81 //smartRF studio
 
−
#define SMARTRF_SETTING_TEST1      0x35 //smartRF studio
 
−
#define SMARTRF_SETTING_TEST0      0x09 //
 
  
−
Nouveau main.c :
+
===<span style="color:#4169E1">'''Semaine 10'''</span>===
−
#include <msp430.h>
 
−
#include <stdint.h>
 
−
 
−
#include "RF1A.h"
 
−
#include "RF_Connection.h"
 
−
#include "PMM.h"
 
−
#include "ports.h"
 
−
#include "RFconfig.h"
 
−
#include "led_commands.h"
 
−
 
−
#define BUFFER_SIZE 10 // maximum size of data sent by rf
 
−
 
 
−
#define PWM_PERIOD 255
 
−
#define DELAY 5000 //15ms 
 
−
 
−
 
−
volatile uint8_t buffer[BUFFER_SIZE];
 
−
 
−
void send_cmd(void)
 
−
{
 
−
  buffer[0] = 0xFD;
 
−
  buffer[1] = 0xAA;
 
−
  buffer[2] = 0xFF;
 
−
  buffer[3] = 0x11;
 
−
  buffer[4] = 0xFF;
 
−
  buffer[5] = 0x66;
 
−
  buffer[6] = 0xFF;
 
−
  buffer[7] = 0x33;
 
−
  buffer[8] = 0x1F;
 
−
  buffer[9] = 0xF8;
 
−
  rf_transmit((uint8_t *)buffer, 2);
 
−
}
 
−
 
−
int main(void)
 
−
{
 
−
  port_mapping();
 
−
  unsigned char chann=0x00;
 
−
  unsigned char led2=0x10;
 
−
  WDTCTL = WDTPW + WDTHOLD;  // Stop WDT
 
−
  rf_init(); //reset, setVcore & patable
 
−
  ReceiveOff();
 
−
  _BIS_SR(GIE);
 
−
  set_color(0x10, 0x00, 0x00, 0x00, 0x00, 0x00); //led1 allumée quand le cc430 est sous tension
 
−
 
−
  while(1)
 
−
  {
 
−
    ChangeChannel(chann);
 
−
    send_cmd();
 
−
    if(chann>=20) //866-870
 
−
    {
 
−
      chann=0x00;
 
−
      led2=led2^0x10;
 
−
      set_color(0x10, 0x00, 0x00, led2, 0x00, 0x00); //led2 s'allume toutes les 2 rampes
 
−
    }
 
−
    else
 
−
    {
 
−
      chann++;
 
−
    }
 
−
    __delay_cycles(DELAY);
 
−
  }
 
−
  return 0;
 
−
}
 
  
−
Fonction WritePATable :
+
''[[Mer 06/12/17 - Jeudi 07/12/17]]''
 +
*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
  
−
void WritePATable(void)
+
*Développement de l'interface Web
−
{
+
**Travail sur l'affichage des fichiers JSON
−
  unsigned char valueRead = 0;
+
***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
−
  //while(valueRead != 0x03)    // Output Power: -30  [dBm]
 
−
  //while(valueRead != 0x25)    // Output Power: -12  [dBm]
 
−
  //while(valueRead != 0x2D)    // Output Power: -6  [dBm]
 
−
  //while(valueRead != 0x8D)    // Output Power:  0  [dBm]
 
−
  //while(valueRead != 0xC3)    // Output Power:  10  [dBm]
 
−
  while(valueRead != 0xC0)    // Output Power:  Maximum  [dBm]
 
−
  //while(valueRead != 0xC6)    // Output Power(default):  8.8  [dBm]
 
−
  {
 
−
    /* Write the power output to the PA_TABLE and verify the write operation.  */
 
−
    unsigned char i = 0;
 
−
 
−
    /* wait for radio to be ready for next instruction */
 
−
    while( !(RF1AIFCTL1 & RFINSTRIFG));
 
−
    //RF1AINSTRW = 0x7E03; // PA Table write (burst), Output Power: -30  [dBm]
 
−
    //RF1AINSTRW = 0x7E25; // PA Table write (burst), Output Power: -12  [dBm]
 
−
    //RF1AINSTRW = 0x7E2D; // PA Table write (burst), Output Power: -6  [dBm]
 
−
    //RF1AINSTRW = 0x7E8D; // PA Table write (burst), Output Power: 0    [dBm]
 
−
    //RF1AINSTRW = 0x7EC3; // PA Table write (burst), Output Power: 10  [dBm]
 
−
    RF1AINSTRW = 0x7EC0; // PA Table write (burst), Output Power: Maximum  [dBm]
 
−
    //RF1AINSTRW = 0x7EC6; // PA Table write (burst), Output Power(default):  8.8  [dBm]
 
−
   
 
−
    /* wait for radio to be ready for next instruction */
 
−
    while( !(RF1AIFCTL1 & RFINSTRIFG));
 
−
      RF1AINSTR1B = RF_PATABRD;                // -miguel read & write
 
−
   
 
−
    // Traverse PATABLE pointers to read
 
−
    for (i = 0; i < 7; i++)
 
−
    {
 
−
      while( !(RF1AIFCTL1 & RFDOUTIFG));
 
−
      valueRead  = RF1ADOUT1B;   
 
−
    }
 
−
    while( !(RF1AIFCTL1 & RFDOUTIFG));
 
−
    valueRead  = RF1ADOUTB;
 
−
  }
 
−
}
 
  
−
===<span style="color:#4169E1">'''Semaine 10'''</span>===
+
*Nettoyage du dépôt Git
 +
 
 +
===<span style="color:#4169E1">'''Semaine 11'''</span>===
 +
 
 +
''[[Mer 13/12/17]]'' 
 +
*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
 +
 
 +
Nous nous sommes réunis avec l'un de nos tuteurs, qui a réalisé certains bouts de code de base, pour nous mettre au point sur les fonctions en question et leur utilisation.
 +
 
 +
===<span style="color:#4169E1">'''Semaine 12'''</span>===
 +
 
 +
''[[Mer 20/12/17 - Jeudi 21/12/17]]''
 +
*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'''.
 +
 
 +
===<span style="color:#4169E1">'''Semaine 13'''</span>===
 +
 
 +
''[[Mer 10/01/18 - Ven 12/01/18]]'' 
 +
*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
 +
 
 +
**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)
 +
 
 +
**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
 +
 
 +
**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
 +
 
 +
*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
 +
 
 +
===<span style="color:#4169E1">'''Semaine 14'''</span>===
 +
 
 +
''[[Mar 16/01/18 - Ven 19/01/18]]'' 
 +
*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)
 +
 
 +
**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
 +
 
 +
**Interface Web
 +
***Implémentation de plotly.js, un module Javascript qui permet d'afficher des graphes en 3D
 +
 
 +
*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
 +
 
 +
===<span style="color:#4169E1">'''Semaine 15'''</span>===
 +
 
 +
''[[Mar 23/01/18 - Ven 26/01/18]]''
 +
*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
 +
***Fait: Si distance négative car Tag trop près, la valeur négative générée par une balise est remplacée par un "0" (cela modifie la position réelle modélisée dans plotly, mais évite une impossibilité de générer la position à partir de la distance -> par des tests, il faudra déterminer la valeur limite à partir de laquelle les cartes donnent des valeurs de distance négatives
 +
***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); Ainsi que le cas où il y un saut/bug inattendu et donc une disparition d'une ou plusieurs valeurs de distance
 +
***Début de résolution du cas où une distance n'est pas prise en compte, c'est à dire où il y a une valeur qui disparaît et désaligne les valeurs lors de la création du JSON
 +
 
 +
**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
 +
***Création d'un script bash /etc/init.d/autoconnect.sh pour connecter automatiquement la RPi au lancement du système (si la RPi est déjà allumée au démarrage)
 +
 
 +
**Interface Web
 +
***Perfectionnement de l'utilisation de Plotly pour les visualisations
 +
 
 +
*Implémentation du serveur de localisation fourni par les tuteurs (algorithme de localisation pas fonctionnel pour le moment)
 +
**Requêtes manuelles à l'API avec la fonction curl OK
 +
**Fait: Implémentation des requêtes Ajax pour automatiser les requêtes au serveur de localisation
 +
***Liaison entre les différentes requêtes ajax grâce à des variables: permet de stocker l'adresse du job récupérée par la méthode GET
 +
 
 +
===<span style="color:#4169E1">'''Semaine 16'''</span>===
 +
 
 +
''[[Lun 29/01/18 - Ven 02/02/18]]''
 +
*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
 +
***déterminer la valeur limite à partir de laquelle les cartes donnent des valeurs de distance négatives
 +
***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); Ainsi que le cas où il y un saut/bug inattendu et donc une disparition d'une ou plusieurs valeurs de distance
 +
***Fait: gestion des bugs/sauts de valeurs de balises - remplacement par une valeur nulle sur balise existe, par rien sinon (implémentation d'un tableau caractérisant l'existence ou pas de chaque balise 1 à 6), optimisation des temps de calculs/exécution dans le script
 +
**Interface Web
 +
***Ajout d'une barre de progression de la collecte remplaçant le bouton de Lancement de collecte lors de l'appui
 +
***Ajout d'un bouton dropdown pour afficher les fichiers de position qu'on reçoit du serveur de localisation
 +
***Ajout d'une scrollbar dans les deux dropdown
 +
 
 +
*Implémentation du serveur de localisation fourni par les tuteurs (algorithme de localisation pas fonctionnel pour le moment)
 +
**Fait: Implémentation des requêtes Ajax pour automatiser les requêtes au serveur de localisation
 +
***Création d'une requête Ajax GET qui demande le fichier JSON de position au serveur de localisation jusqu'à ce qu'il soit retourné
 +
 
 +
===<span style="color:#4169E1">'''Semaine 17'''</span>===
 +
 
 +
''[[Lun 05/02/18 - Ven 09/02/18]]''
 +
 
 +
*Algorithme de localisation mis en ligne par le tuteur
 +
**test du bon fonctionnement des connections entre parties après intégration de l'algorithme
 +
**test su la qualité de l'algorithme
 +
**test sur la précision de l'algorithme
 +
*Rapport partie Front-end
 +
*Rapport partie Back-end
 +
*Nettoyage du code requete.py
 +
*Mise à jour final des de certes pages du site
 +
** matrice.html à jour
 +
**3D.html à jour
 +
 
 +
===<span style="color:#4169E1">'''Semaine 18'''</span>===
 +
 
 +
''[[Lun 12/02/18 - Ven 16/02/18]]''
  
−
''[[03/04/17 - 09/04/17]]''
+
*Algorithme de localisation mis en ligne par le tuteur
 +
**test de perturbation et des limites du systeme d'antenne Locopositioning
 +
*Rapport partie III
 +
*rapport partie I
 +
*réalisation de la vidéo de présentation
  
−
*La puissance d'émission étant trop faible pour brouiller la communication entre les 2 modules LoRa, nous avons décidé de changer l'antenne de la carte. Il a fallu couper l'antenne patch à l'aide d'une scie afin de souder un connecteur SMA.
+
===<span style="color:#4169E1">'''Semaine 19'''</span>===
−
[[Fichier:cc430antenne.png]]
 
−
*Grâce à cette nouvelle antenne, la communication peut maintenant être brouillée à une puissance de 10dBm (contre 6 auparavant). Mais il faut que la carte reste relativement proche d'un des modules.
 
−
*Pour réussir le brouillage quand les modules LoRa sont à leur puissance maximale (14dBm), il faudra sûrement ajouter un amplificateur entre la sortie de la carte et son antenne.
 
−
*Nous avons codé la fonction de scan en c et l'avons incorporé dans le main
 
−
**Cette fonction autorise le module à entrer en mode RX pour recevoir les communications. Elle incrémente ensuite le canal pour parcourir la plage 863-870MHz afin de détecter une communication. Toute les incrémentations, la variable rssi récupère la valeur contenue dans le registre qui correspond à la valeur du RSSI. Cette valeur étant en binaire complément 2, elle est convertie en dBm et placée dans un entier. Enfin, si cette valeur est supérieur à la valeur maximale déjà mesuré ou à un palier prédéfini (ici 0dBm), on stocke le numéro du canal correspondant qui sera utilisé dans le main par la suite.
 
  
−
fonction de scan :
+
''[[Lun 19/02/18 - Ven 23/02/18]]''
−
void freq_scan(void)
 
−
{
 
−
  unsigned char rssi;
 
−
  long rssi_dbm;
 
−
  unsigned char chan_scan=START_FREQ_CHAN;
 
−
  long rssi_max=0; //scan will take communication above 0dbm
 
−
  set_color(led1, 0x00, 0x00, 0x00, led2, 0x00); //led2 blue while scanning
 
−
 
 
−
  ChangeChannel(chan_scan);
 
−
  ReceiveOn();    //enable RX
 
−
  while((Strobe(RF_SNOP) & 0x70) != 0x10); //make sure RX is ready
 
−
  while(chan_scan<STOP_FREQ_CHAN)
 
−
  {
 
−
    ChangeChannel(chan_scan);
 
−
    rssi = ReadSingleReg(RSSI);  //define in cc430f5137.h RSSI=0x34 corresponding to addr of rssi value
 
−
    if (rssi >= 128)
 
−
    {
 
−
      rssi_dbm = (long)((long)( rssi - 256) / 2) - RSSI_OFFSET;
 
−
    }
 
−
    else
 
−
    {
 
−
      rssi_dbm = (rssi / 2) - RSSI_OFFSET;
 
−
    }
 
−
    if(rssi_dbm>rssi_max)
 
−
    {
 
−
      rssi_max=rssi_dbm;
 
−
      chan_jam=chan_scan-10; //start jamming 2Mhz below max dbm received
 
−
    }
 
−
    chan_scan++;
 
−
    Strobe( RF_SFRX); //flush the RX FIFO
 
−
  }
 
−
  set_color(led1, 0x00, 0x00, 0x00, 0x00, 0x00);
 
−
}
 
  
−
nouveau main :
+
*Présentation de l'application à l'un des chercheurs de l’INRIA en charge de la suite du projet et de l'algorithme de localisation
 +
*création de la diapositive de la soutenance.
  
−
int main(void)
+
==<span style="color:#000080">'''Délivrables'''</span>==
−
{
 
−
  unsigned char chan_main=0x00;
 
−
  port_mapping();
 
−
  WDTCTL = WDTPW + WDTHOLD;  // Stop WDT
 
−
  rf_init(); //reset, setVcore & patable
 
−
  _BIS_SR(GIE);
 
−
  set_color(led1, 0x00, 0x00, 0x00, 0x00, 0x00); //led1 on if cc430 powered
 
−
  int i;
 
−
 
 
−
  while(1)
 
−
  {
 
−
    freq_scan();
 
−
    ReceiveOff();
 
−
    chan_main=chan_jam;
 
−
    if (chan_main != 0)  //jam only if a communication xas detected with freq_scan
 
−
    {
 
−
      for(i=0 ; i<(20*NUM_JAM_RAMP) ; i++) //ramp start 2Mhz below chan_jam and stop 2Mhz above
 
−
      {
 
−
        ChangeChannel(chan_main);
 
−
        if (chan_main>= (chan_jam+20))
 
−
        {
 
−
          send_cmd();
 
−
          chan_main=0x00;
 
−
          led2=led2^0x10;
 
−
          set_color(led1, 0x00, 0x00, led2, 0x00, 0x00); //led2 blink red every two ramp of jamming
 
−
        }
 
−
        else
 
−
        {
 
−
          send_cmd();
 
−
          chan_main++;
 
−
        }
 
−
      }
 
−
    }
 
−
    chan_main=0x00; 
 
−
    __delay_cycles(DELAY);
 
−
  }
 
−
  return 0;
 
−
}
 
  
−
header :
+
Rapport de mi-PFE
−
#define DELAY 100 //300us 
+
[[Fichier:RapportMi-PFE-UNG DELATTE.pdf]]
−
#define DELAY_RSSI 10 //30us
 
−
 
−
#define START_FREQ_CHAN 15
 
−
#define STOP_FREQ_CHAN 50    //scanning 863-870Mhz with 200khz steps
 
−
#define RSSI_OFFSET 74 //cf datasheet
 
−
 
−
#define NUM_JAM_RAMP 50
 
−
 
−
unsigned char chan_jam=0x00;
 
−
unsigned char led2=0x10;
 
−
unsigned char led1=0x10;
 
  
−
===<span style="color:#4169E1">'''Après les vacances'''</span>===
+
Rapport de PFE
 +
[[Fichier:RapportPFE-UNG DELATTE-final.pdf]]
  
−
*Nous avons effectué des tests pour vérifier si la fonction de scan fonctionne. Malheureusement, le cc430 n'a pas l'air de détecter de communications. La fréquence des modules LoRa a été fixée à 868MHz en mettant le header LORA_FHSS_ENABLE à false (ceci désactive le glissement de fréquence) pour faire des tests dans des conditions plus optimales. Cependant, le cc430 ne détecte toujours aucune communication.
+
Vidéo
−
*Nous avons donc vérifié plusieurs éléments du code : la conversion en dBm du registre RSSI, la lecture dans le registre, le temps de mise à jour du registre RSSI.
 
−
**D'après le pseudo-code fourni par texas instrument, et ce que nous avons pu lire sur les forums des développeurs, la conversion fonctionne. Nous avons tout de même essayé d'autre moyens​ de conversion, mais aucune de ces méthodes n'a permis au cc430 de détecter une communication.
 
−
**En ce qui concerne la lecture dans le registre, nous avons effectué des tests en lisant dans d'autres registres et en allumant une led, nous en avons conclu que la fonction ReadSingleReg fonctionne. Nous nous sommes donc portés sur l'adresse de ce registre, en vérifiant la bibliothèque cc430f5137.h, nous avons constaté que la variable RSSI était bien définie dans les adresses de registres.
 
−
**Enfin, d'après les datasheets du cc430 et du cc1101, le registre RSSI met un certain temps a s'actualiser, ce temps peut être calculé et dépend de la taille des paquets reçus​. Ne pouvant pas connaître pas la taille des paquets de la communication que l'on cherche à brouiller à l'avance, nous avons décidé de fixer un temps d'attente 2 fois supérieur au temps caractéristique (~15us), soit 30 micro seconde.
 
−
*Malgré ces essais et corrections de code, nous ne sommes pas parvenus​ à faire fonctionner la détection de communication.
 

Version actuelle datée du 15 juin 2018 à 22:37


Vidéo HD


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 prévisionnel

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
  • Développement du serveur de collecte de données
  • Réalisation de l'interface logicielle (Web//Logiciel/Application)
  • Intégration des différentes parties
  • Test et débuggage

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

  1. Se documenter sur le projet
    1. Langages et technologies utilisées
    2. Matériel utilisé
    3. Mettre en place du travail sur le Git
  2. Réaliser le serveur de collecte
    1. Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
    2. Intégrer le serveur de localisation pour interpréter les trames
    3. Tester et optimiser
  3. Réaliser l'interface Web utilisateur
    1. Implémenter le serveur de collecte et de localisation
    2. Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
    3. 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 / Rapport 4h 3h 1h x 1h30 1h 2h 1h 2h30 1h 3h 3h30 2h 5h x 1h 2h
Documentation sur les technos utilisées 2h 4h 3h 2h 3h 4h 5h 5h30 4h30 3h30 2h 3h 1h 3h 4h x 2h
Documentation sur le matériel 2h 1h 1h 2h 1h x x x x x x x x 1h 1h 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 4h 7h30 5h
Recherche et développement de l'interface Web x 2h 1h 3h 5h 6h 4h 7h 5h30 2h30 6h 8h 5h 1h 8h 4h 4h
Recherche et intégration du serveur de localisation x x x x x x x x x x x x x x 6h 5h 3h
Intégration des différentes parties x x x x 2h 2h 2h 3h 1h30 x 3h 6h 5h x 3h30 2h 2h
Tests et débuggage x 1h 2h 1h 1h 1h 2h 3h 4h 0,5h 3h 1h 3h 3h 2h 1h 4h
Optimisation/Correction des programmes
Vidéo

Avancement du Projet

Phase préparatoire

Jeu 21/09/17 - Ven 22/09/17

  • 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ée celle-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 une Mind map afin d'y voir plus clair sur la ligne à suivre.

Vous trouverez cette Mind map juste ci-dessous. Nous ne mettrons pas à jour cette Mind map chaque semaine mais il est fort probable que nous en refaisions 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 auraient semblés trop vague au début du projet.


Projet de fin d'étude.png

Semaine 1

Jeu 28/09/17 - Ven 29/09/17

  • 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 dès à 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 dépôt 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

Jeu 05/10/17 - Ven 06/10/17

  • 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 Raspberry Pi et le serveur de position déjà créé. Nous avons donc pu commencer à nous former sur les technologies qui nous serviraient par la suite. Nous avons donc utilisé le cours d'Openclassrooms sur les serveurs Flask pour en apprendre les bases. Ce serveur Flask est programmé en Python et nous permet donc une grande liberté au niveau de l’exécution de certains scripts. En effet, les scripts de connexion Bluetooth et de redirection de port qui nous permettent de récupérer les données de distance sont eux-mêmes codés en Python et sont directement appelés 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

Mer 11/10/17 - Jeu 12/10/17

  • 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.

serveur Flask

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 pourrons gérer le traitement des données récupérées.

Semaine 4

Mer 18/10/17 - Jeu 19/10/17

  • 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çu des fonctions Python de notre tuteur afin d'obtenir une connexion Bluetooth entre notre Raspberry Pi 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 nécessitons une explication de notre tuteur n'étant pas disponible à ce moment. Pour ne pas perdre de temps, nous attaquons la création de l'interface web à proprement parler, c'est à dire la création des pages HTML ainsi que le document Javascript qui nous servira de bibliothèque de fonctions. Chaque route de notre serveur est reliée à une série de fonctions Python s'exécutant à l'appel des url puis suivies 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êmes 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 ce fichier JSON renvoyé vers notre page, nous nous servons du fichier Javascript afin de créer du code HTML contenant la matrice.

Semaine 5

Mer 25/10/17 - Ven 27/10/17

  • 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ées au format JSON et à l'afficher dans le code HTML. Toutefois nous créons nous-mêmes ce set, il est maintenant nécessaire que nous arrivions à récupérer les sets de distance réels reçus par la connexion 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

Mer 08/11/17 - Ven 10/11/17

  • 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 tests 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 suivantes 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 données 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érentes 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'appui sur des boutons.

Semaine 7

Mer 15/11/17 - Ven 17/11/17

  • 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 continué à travailler sur le serveur de collecte: les données que nous avons récupérées via Bluetooth sont stockées dans un fichier .log. Apres avoir bien compris comment marchait la fonction parse manuellement (lors de son utilisation dans le Shell), nous l'avons implémentée dans notre serveur de collecte qui lance cette commande lors de l’appui sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêter. Nous avons donc rajouté un temps à entrer nous-même sur l'interface. La fonction parse est effectuée 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êmes. Nous voulions utiliser des Sockets pour pouvoir définir nous-mêmes la gestion de la communication mais l'idée a été abandonné car nous avons réussi à 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éer un module qui regroupera toutes ces fonctions que nous pourrons utiliser dans requete.py. ceci nous permet de voir plus clair dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.

Nous essayons en continu d'adapter le layout du site pour le rendre le plus attractif et simple possible, de façon à ce que chaque bouton et tableau soient clairs et compréhensibles.

Nous avons commencé à récupérer les fichiers JSON créés à partir des fichier log, c'est-à-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 fichiers 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

Mer 22/11/17 - Ven 24/11/17

  • 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
  • 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 à développer les points énoncés la semaine dernière. Nous avons décidé de nous diriger 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 à un moment donné. 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 bugguent seulement parfois et non à chaque essai de connexion.

Nous avons nettoyé notre dépot Git car il s’avère que nous utilisions une mauvaise méthode de fusion et de stockage des documents.

Semaine 9

Mer 29/11/17 - Jeudi 30/11/17

  • 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
  • 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
  • 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 revu l'ensemble de notre code et les méthodes utilisées avec notre tuteur Roudy Dagher. Nous nous approchons d'un serveur de collecte de données 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 est possible de commencer la deuxième partie qui est l'envoi de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrices de positions. Nous pourrons grâce à ces matrices afficher une carte 3D des balises et du TAG dans l'espace.

Semaine 10

Mer 06/12/17 - Jeudi 07/12/17

  • 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
  • Nettoyage du dépôt Git

Semaine 11

Mer 13/12/17

  • 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

Nous nous sommes réunis avec l'un de nos tuteurs, qui a réalisé certains bouts de code de base, pour nous mettre au point sur les fonctions en question et leur utilisation.

Semaine 12

Mer 20/12/17 - Jeudi 21/12/17

  • 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

Mer 10/01/18 - Ven 12/01/18

  • 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
    • 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)
    • 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
    • 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
  • 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

Mar 16/01/18 - Ven 19/01/18

  • 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)
    • 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
    • Interface Web
      • Implémentation de plotly.js, un module Javascript qui permet d'afficher des graphes en 3D
  • 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

Semaine 15

Mar 23/01/18 - Ven 26/01/18

  • 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
      • Fait: Si distance négative car Tag trop près, la valeur négative générée par une balise est remplacée par un "0" (cela modifie la position réelle modélisée dans plotly, mais évite une impossibilité de générer la position à partir de la distance -> par des tests, il faudra déterminer la valeur limite à partir de laquelle les cartes donnent des valeurs de distance négatives
      • 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); Ainsi que le cas où il y un saut/bug inattendu et donc une disparition d'une ou plusieurs valeurs de distance
      • Début de résolution du cas où une distance n'est pas prise en compte, c'est à dire où il y a une valeur qui disparaît et désaligne les valeurs lors de la création du JSON
    • 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
      • Création d'un script bash /etc/init.d/autoconnect.sh pour connecter automatiquement la RPi au lancement du système (si la RPi est déjà allumée au démarrage)
    • Interface Web
      • Perfectionnement de l'utilisation de Plotly pour les visualisations
  • Implémentation du serveur de localisation fourni par les tuteurs (algorithme de localisation pas fonctionnel pour le moment)
    • Requêtes manuelles à l'API avec la fonction curl OK
    • Fait: Implémentation des requêtes Ajax pour automatiser les requêtes au serveur de localisation
      • Liaison entre les différentes requêtes ajax grâce à des variables: permet de stocker l'adresse du job récupérée par la méthode GET

Semaine 16

Lun 29/01/18 - Ven 02/02/18

  • 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
      • déterminer la valeur limite à partir de laquelle les cartes donnent des valeurs de distance négatives
      • 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); Ainsi que le cas où il y un saut/bug inattendu et donc une disparition d'une ou plusieurs valeurs de distance
      • Fait: gestion des bugs/sauts de valeurs de balises - remplacement par une valeur nulle sur balise existe, par rien sinon (implémentation d'un tableau caractérisant l'existence ou pas de chaque balise 1 à 6), optimisation des temps de calculs/exécution dans le script
    • Interface Web
      • Ajout d'une barre de progression de la collecte remplaçant le bouton de Lancement de collecte lors de l'appui
      • Ajout d'un bouton dropdown pour afficher les fichiers de position qu'on reçoit du serveur de localisation
      • Ajout d'une scrollbar dans les deux dropdown
  • Implémentation du serveur de localisation fourni par les tuteurs (algorithme de localisation pas fonctionnel pour le moment)
    • Fait: Implémentation des requêtes Ajax pour automatiser les requêtes au serveur de localisation
      • Création d'une requête Ajax GET qui demande le fichier JSON de position au serveur de localisation jusqu'à ce qu'il soit retourné

Semaine 17

Lun 05/02/18 - Ven 09/02/18

  • Algorithme de localisation mis en ligne par le tuteur
    • test du bon fonctionnement des connections entre parties après intégration de l'algorithme
    • test su la qualité de l'algorithme
    • test sur la précision de l'algorithme
  • Rapport partie Front-end
  • Rapport partie Back-end
  • Nettoyage du code requete.py
  • Mise à jour final des de certes pages du site
    • matrice.html à jour
    • 3D.html à jour

Semaine 18

Lun 12/02/18 - Ven 16/02/18

  • Algorithme de localisation mis en ligne par le tuteur
    • test de perturbation et des limites du systeme d'antenne Locopositioning
  • Rapport partie III
  • rapport partie I
  • réalisation de la vidéo de présentation

Semaine 19

Lun 19/02/18 - Ven 23/02/18

  • Présentation de l'application à l'un des chercheurs de l’INRIA en charge de la suite du projet et de l'algorithme de localisation
  • création de la diapositive de la soutenance.

Délivrables

Rapport de mi-PFE Fichier:RapportMi-PFE-UNG DELATTE.pdf

Rapport de PFE Fichier:RapportPFE-UNG DELATTE-final.pdf

Vidéo

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=P18_Localisation_of_quadrotors&oldid=58740 »