Wiki de Projets IMA - Contributions de l’utilisateur [fr]

Projets IMA5 2017/2018

2018-02-21T13:38:21Z

Hdelatte : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Conception d'une pompe automatique à insuline]]</td>
<td>Alice Coffin / Amina Fahem</td>
<td>Belkacem Ould Bouamama</td>
<td>[[Fichier:rapport_mi_PFE_COFFIN_FAHEM.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P18 Localisation of quadrotors]]</td>
<td>Nicky UNG / Hugo Delatte</td>
<td>Jérémie DEQUIDT / Gang ZHENG</td>
<td>[[Fichier:RapportMi-PFE-UNG DELATTE.pdf]] </td>
<td>[[Fichier:RapportPFE-UNG DELATTE-final.pdf]] </td>
<td> </td>
</tr>

<tr>
<td>[[P25 Développement d'un cobot ]]</td>
<td>Tristan HART</td>
<td>Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td>[[Fichier:RapportIntermédiaire_PFE25_HART.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P29 QT pour tablette à retour tactile]]</td>
<td>lValentin BEAUCHAMP / Vivian SENAFFE</td>
<td>Laurent GRISONI</td>
<td>[[Fichier:Rapport_pfe_BEAUCHAMP_SENAFFE.pdf]] </td>
<td> [[Fichier:BEAUCHAMP_SENAFFE_Rapport_Final_PFE.pdf]]</td>
<td> </td>
</tr>

<tr>
<td>[[P30 patcher l’IoT par intrusion]]</td>
<td>Alexis DORIAN</td>
<td>Thomas Vantroys /Worldline</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P33 Utilisation de Nao avec des enfants autistes]]</td>
<td>Antoine ARNAUDET</td>
<td>Thomas VANTROYS</td>
<td> [[Fichier:ARNAUDET_ANTOINE_RAPPORT_DECEMBRE_2017_PFE.pdf]]</td>
<td> [[Fichier:ANTOINE_ARNAUDET_P33_RAPPORT_PFE_FINAL.pdf]]</td>
<td> </td>
</tr>

<tr>
<td>[[P34 Robot reconstructeur de mouvement]]</td>
<td>Baptiste GRILLERE / Jean-Baptiste SAISON</td>
<td>Rochdi MERZOUKI / Guillaume DEWAELE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P21 Projet bras déformable antagoniste]]</td>
<td>Florian GIOVANNANGELI</td>
<td>Thor BIEZE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P20 Projet marionnette déformable interactive ]]</td>
<td>Bacem HAGUI</td>
<td>Félix VANNESTE, Jeremie DEQUIDT</td>
<td> [[Fichier:bacem_mi_parcours.pdf]] </td>
<td> [[Fichier:Rapport_PFE_Hagui_Bacem.pdf]] </td>
<td> </td>
</tr>

<tr>
<td>[[P5 Commande d’une centrale de production de biogaz ]]</td>
<td>Cheikh Soilihi SAID AHMED</td>
<td>Midzodzi PEKPE </td>
<td>[[Fichier:Rapport_intermediaire.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P15 Réseau de capteurs temps réel ]]</td>
<td>Edmur Lopes</td>
<td>Alexandre Boé / Xavier Redon / Thomas Vantroys</td>
<td>[[Fichier:Rapport_mi_parcours.pdf ]]</td>
<td>[[Fichier:Rapport PFE15 LOPES.pdf]]</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Application de gestion de conteneurs pour sites Web]]</td>
<td>Alexis MACHEREZ</td>
<td>Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P36 Robots Mobiles Chorégraphes]]</td>
<td>Joshua LETELLIER</td>
<td>Rochdi MERZOUKI</td>
<td>[[Fichier:RapportAvancementPFE_Letellier_Joshua.pdf]] </td>
<td>[[Fichier:RapportFinalPFE_Letellier.pdf]] </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Réseau de capteurs de pollution]]</td>
<td>Marianne BUTAYE</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td>[[Fichier:Rapport p26 2018 marianne butaye.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P32 Apprentissage automatique pour la détection d’attaques par déni de services ]]</td>
<td>Robin Cavalieri</td>
<td>Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Réseau LoRaWAN ]]</td>
<td>François Lefevre</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P38 Conception par fabrication additive des pièces en plastique à partir d’un robot]]</td>
<td>Diana Marrucho</td>
<td>Rochdi MERZOUKI</td>
<td> </td>
<td>[[Fichier:MARRUCHO Diana Rapport PFE.pdf]]</td>
<td> </td>
</tr>
</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 câbles usb
50 Positions Embase Connecteur 0,100 po (2,54 mm) Trou traversant Or [https://www.digikey.fr/products/fr?keywords=SFH11-PBPC-D25-ST-BK%20]
</td>
</tr>
<tr>
<td> P27 Réseau LoRaWAN </td>
<td> 1 Raspberry Pi 3 + boîtier + alimentation + câble USB 
 3 STM32 Nucleo + 3 câbles mini-USB 

 3 modules émetteurs LoRa 

 1 module récepteur LoRa 

 1 carte SD 

 10 câbles de connexion 
</td>
</tr>

P18 Localisation of quadrotors

2018-02-21T11:36:25Z

Hdelatte : /* Délivrables */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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

Fichier:RapportPFE-UNG DELATTE-final.pdf

2018-02-21T11:36:00Z

Hdelatte :

P18 Localisation of quadrotors

2018-02-20T19:23:57Z

Hdelatte : /* Délivrables */

Fichier:RapportPFE-UNG DELATTE.pdf

2018-02-20T19:23:26Z

Hdelatte :

P18 Localisation of quadrotors

2018-02-16T16:07:25Z

Hdelatte : /* Semaine 19 */

P18 Localisation of quadrotors

2018-02-16T16:07:08Z

Hdelatte : /* Semaine 19 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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 chercheur 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

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:26:32Z

Hdelatte : /* Observations */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:25:37Z

Hdelatte : /* Semaine 18 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:25:01Z

Hdelatte : /* Semaine 18 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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 résultat obtenus
*réalisation de la vidéo de présentation

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:23:24Z

Hdelatte : /* Semaine 17 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

*Rapport partie résultat obtenus
*réalisation de la vidéo de présentation

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:21:30Z

Hdelatte : /* Semaine 18 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

*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]]''

*Rapport partie résultat obtenus
*réalisation de la vidéo de présentation

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:19:33Z

Hdelatte : /* Semaine 17 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

*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]]''

*réalisation de la video de présentation

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:19:04Z

Hdelatte : /* Semaine 18 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

*Rapport partie front
*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]]''

*réalisation de la video de présentation

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:18:53Z

Hdelatte : /* Semaine 17 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

*Rapport partie front
*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]]''

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-16T15:12:16Z

Hdelatte : /* Semaine 16 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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]]''

==='''Semaine 18'''===

''[[Lun 12/02/18 - Ven 16/02/18]]''

==='''Semaine 19'''===

''[[Lun 19/02/18 - Ven 23/02/18]]''

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-07T16:38:36Z

Hdelatte : /* Semaine 16 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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é

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-07T16:38:22Z

Hdelatte : /* Semaine 15 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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
***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
***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é

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-07T16:36:37Z

Hdelatte : /* Semaine 16 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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 commandes curl grace à 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
***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
***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é

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-07T16:36:12Z

Hdelatte : /* Semaine 15 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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 commandes curl grace à 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)
**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
***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é

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2018-02-07T16:35:44Z

Hdelatte : /* Semaine 16 */

=='''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====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! 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.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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.

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

==='''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
***Fait: 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 commandes curl grace à 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)
**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
***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é

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

=='''Délivrables'''==

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

Rapport de PFE

Vidéo

P18 Localisation of quadrotors

2017-12-19T14:19:15Z

Hdelatte : /* Avancement du Projet */

=='''Cahier des charges'''==

===Présentation générale du projet===

====Contexte====

Dans un monde de plus en plus connecté, de nombreux drones sont déployés pour diverses applications comme l'espionnage, la surveillance, la cartographie de lieux et la livraison de colis. Les technologies nécessaires pour contrôler ces drones sont des sujets de recherche actuels.

Le contrôle de ceux-ci passe tout d'abord par la maîtrise de leur position dans l'espace. Le développement des applications liées à l'utilisation de drones nécessite un travail important sur la localisation spatiale d'objets connectés.

De plus, dans un souci d'utilisation, il est essentiel de développer des interfaces logicielles permettant d'exploiter ces données.

====Objectif du projet====

L'objectif de ce projet est de développer une interface logicielle permettant de traiter en temps réel les informations de localisation d'un drone et de balises, dans le but de définir leur localisation dans l'espace, en intérieur.

====Description du projet====

Pour réaliser le contrôle de drones, la première étape importante est de donner ses informations de position. Le but du projet est de développer une interface logicielle permettant de localiser le drone en temps réel en intérieur. Le drone se déplace dans un environnement dans lequel ont été installées de multiples balises. Il est équipé d'une carte, lui permettant de recevoir les distances relatives entre lui-même et les balises, sur laquelle différents algorithmes vont être implémentés pour effectuer la localisation en temps réel. Le projet requiert des compétences en développement hardware (Crazyflie 2.0, voir https://wiki.bitcraze.io/) et software (langage C/C++/Python/Javascript/HTML...).

Il se divise en 4 étapes principales, qui sont:
*1) Choisir les technologies utilisées
*2) Choisir l'architecture (OS / APIs)
*3) Développer les différentes parties du projet
*4) Intégrer et connecter les différentes parties du projet

La localisation étant en intérieur, le protocole GPS n'est donc pas assez précis pour les applications ciblées. La mise en place d'un tel dispositif permettrait grâce à l'utilisation d'un algorithme d'estimer avec une bonne précision les positions en intérieur d'une balise centrale (appelée Tag) et de balises (appelées Anchor). Le Tag scanne en temps réel la distance relative aux différentes balises, et il nous est retourné la position des balises et du Tag grâce à l'algorithme de localisation.

Le projet se compose de 3 parties:
* Collect & parse: collecter les données envoyées par les balises en communiquant avec un serveur et récupérer les données adéquates par un tri
* Localise: déterminer la matrice de position des balises et du Tag en traitant les données récupérées
* Display: développer l'interface homme machine pour afficher, étudier et utiliser les données traitées

Nous travaillerons dans un premier temps dans une optique temps différé avant de travailler en temps réel. Cela nous permettra d'acquérir des données utiles et réutilisables en aval.

A l'aboutissement du projet, nous devrions être capable via l'interface homme machine développée d'afficher précisément la position spatiale des balises ainsi que du Tag, grâce àl'utilisation d'un algorithme de localisation et des données récupérées, et d'afficher d'autres données relatives au déplacement du Tag ou des balises dans l'espace.

Si le temps le permet, nous pourrons aussi être amenés à adapter et utiliser l'interface développée pour l'utilisation d'un drone.

''Sujet originel''

To achieve the control of quadrotors, the first important task to give its position information. This project is to develop a software(GUI) to localize the quadrotors in real-time. The quadrotor is flying in an environment where several transmitters have been installed. The quadrotor is equipped with a deck to receive the relative distances between the deck and all transmitters, based on which different algorithms will be implemented to realize the real-time localization. The candidates need to have both experiences on hardware (Crazyflie 2.0, see https://wiki.bitcraze.io/) and software development (C/C , Python…).

====Calendrier====

''[[Avant le 29/09/17]]'' - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel

''[[Avant fin Octobre]]'' - Serveur de collecte et début du développement de l'interface logicielle

''[[Avant fin Décembre]]'' - Interface logicielle

''[[A la fin du PFE]]'' - Intégration finale des différentes parties (Serveur de collecte des données & Serveur de localisation & Interface logicielle)

Répartition du volume de travail (***h):

* Recherche sur les technologies à utiliser (**h)
* Développement du serveur de collecte de données (**h)
* Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
* Intégration des différentes parties (**h)
* Test et débuggage (**h)

====Choix techniques : matériel et logiciel====

Afin de développer ce dispositif, nous allons utiliser une Raspberry Pi 3 associée à une carte réceptrice, qui communique avec 4 balises composées chacune d'un microcontrôleur et d'une carte émettrice radio (UWB5C) et alimentées par batteries. La carte réceptrice joue le rôle du drone à localiser et communiquera les données émises par les balises vers l'ordinateur via Bluetooth.

====Choix technologiques====

Voici les technologies que nous utilisons pour chacune des parties de ce projet.

1) Serveur de collecte des données:
Scanne et parse les données récupérées pour fournir la matrice D des distances relatives du tag aux 4 balises
- API
- Python / Serveur Flask

2) Serveur de localisation (fourni):
Calcule grâce à l'algorithme de localisation et la matrice D les positions spatiales des 4 noeuds et du tag
- API
- Bootstrap
- Jquery
- Python

3) Interface utilisateur:
Affiche courbes, visualisation 3D, boutons ou données des fichiers envoyées par le serveur de localisation
- HTML5 / Javascript
- Fichiers JSON (serveurs de collecte et de localisation)

==='''Calendrier prévisionnel'''===

====Liste des tâches à effectuer====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! Heures S11 !! Heures S12 !! Après Noël !! Total
|-
| Cahier des charges / Wiki / Gitlab
| 4h
| 3h
| 1h
| x
| 1h30
| 1h
| 2h
| 1h
| 2h30
| 1h
|
|
|
|
|
|-
| Documentation sur les technos utilisées
| 2h
| 4h
| 3h
| 2h
| 3h
| 4h
| 5h
| 5h30
| 4h30
| 3h30
|
|
|
|
|
|-
| Documentation sur le matériel
| 2h
| 1h
| 1h
| 2h
| 1h
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Recherche et développement du serveur de collecte
| x
| 1h
| 2h
| 3h
| 3h30
| 4h
| 5h
| 7h
| 4h30
| 0,5h
|
|
|
|
|
|-
| Recherche et développement de l'interface Web
| x
| 2h
| 1h
| 3h
| 5h
| 6h
| 4h
| 7h
| 5h30
| 2h30
|
|
|
|
|
|-
| Recherche et intégration du serveur de localisation
| x
| x
| x
| x
| x
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Intégration des différentes parties
| x
| x
| x
| x
| 2h
| 2h
| 2h
| 3h
| 1h30
| x
|
|
|
|
|
|-
| Tests et débuggage
| x
| 1h
| 2h
| 1h
| 1h
| 1h
| 2h
| 3h
| 4h
| 0,5h
|
|
|
|
|
|-
| Optimisation/Correction des programmes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|}

=='''Avancement du Projet'''==

==='''Phase préparatoire'''===

''[[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é celui-ci avec les parties qui nous seraient utiles pour développer nos explications par la suite.

Nous avons de plus découpé le travail en sous-parties que nous avions mis dans un '''Mind map''' afin d'y voir plus clair sur la ligne à suivre.

Vous trouverez ce Mind map juste ci-dessous. Nous ne mettrons pas à jour ce Mind map chaque semaine mais il est fort probable que nous en referions un en milieu de projet pour pouvoir cibler les objectifs réussis et ceux à atteindre. Nous pourrons de plus redéfinir certains objectifs qui nous aurait semblé trop vague au début du projet.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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 des à présent des questions sur le bon choix de celles-ci. Nous commençons donc des tests ayant seulement pour but de nous familiariser avec l'environnement de travail et de réellement comprendre les fonctions déjà présentes qu'il faudra exploiter et implanter notre interface web.
Nous créons un gitlab avec notre tuteur et commençons a définir les taches premières sur celui-ci.
Nous en profitons pour affiner le Mind Map.

==='''Semaine 2'''===

''[[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 Raspberrypi et le serveur de position déjà créé.
Nous avons donc pu commencer a ce former sur les technologies qui nous serviraient par la suite. Nous avaons donc utilisé le cours d'openclassroom sur les serveur flask pour en apprendre les bases. Ce serveur flask est programmé en python et nous permets donc une grande liberté au niveau de l’exécutions de certains scripts. En effet les script de connexion bluetooth et de redirection de port qui nous permette de recuperer les données de distance sont eux meme codé en python et sont directement appelé via le serveur.
Dans ce serveur, représentant notre interface web, vous retrouverez la page '''/collecte''' qui représentera notre partie collecte de données ainsi que l'affichage de ces distances. Nous appellerons cette partie le serveur de collecte.

==='''Semaine 3'''===

''[[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.

[[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 pour 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çus des fonctions pythons de notre tuteurs afin d'obtenir une connexion bluetooth entre notre raspberrypi et notre ordinateur ainsi qu'une redirection de port de celle ci vers la connexion. Nous n'arrivons pas à utiliser ces fonctions sous linux et nous necessitons une explication de notre tuteur n'etant pas disponible a ce moment. Pour ne pas perdre de temps nous nous attaquons la creation de l'interface web a proprement parler. c'est a dire la création des pages html ainsi que le document javascript qui nous servira de bibliotheque de fonctions.chaque route de notre serveur sont relié a une series de fonctions python s'executant a l'apelle des url puis suivis d'un template de la page HTML en question. Nous en profitons de plus pour explorer le framework CSS bootstrap afin de mettre un premier design et une structure a notre page collecte qui sera la page principale de notre site pour ce début de projet.

Nous nous essayons de plus à différents tests sur des fichiers de format '''Json''' que nous devrons réussir à traiter correctement plus tard dans notre projet.
Nous récupérons une matrice que nous créons nous même en python (simulation d'une série de distances récupérée) que nous transformons au format Json pour ensuite l'afficher sur notre page web. Pour pouvoir proprement afficher se fichier '''Json''' renvoyé vers notre page, nous nous servons du fichier javascript afin de créer du code html contenant la matrice.

==='''Semaine 5'''===

''[[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é au format json et à l'afficher dans le code html. Toutefois nous créons nous mème ce set, il est maintenant nécessaire que nous arrivions à récupérer les set de distance réels reçus par la connexions bluetooth. Nous commencerons par un traitement asynchrone. L'idée est d’enregistrer les sets de distances dans un fichier '''Json''' stocké dans un dossier. Nous appellerons ce dossier plus tard via une requête ajax.

==='''Semaine 6'''===

''[[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 test manuels via le shell pour récupérer des données de distances et les stocker dans un fichier '''Json''' sur notre ordinateur.

Nous utilisons les commandes suivante pour se connecter via bluetooth:

rfcomm connect /dev/rfcomm0 B8:27:EB:80:DC:89 1

Rediriger le port de la raspberrypi3 vers la connexion:

python lps-collector/tcp_serial_redirect.py /dev/rfcomm0 9600

Collecter les données dans un fichier dont nous définissons le nom:

echo "cu -s9600 -lttyACM0"| nc localhost 7777
nc localhost 7777 | grep distance > static/log/dist-capture'+date+'.log

Nous pouvons '''parser''' le flux de donner avant de le stocker dans le fichier via cette commande:

python lps-collector/lps_parse.py static/log/dist-capture"+date+".log

Il est donc nécessaire d'inclure via des '''thread''' ces différente fonctions dans notre serveur python (Flask) afin d'automatiser le processus. Le but est de pouvoir choisir sur l'interface web quels fonctions il faut exécuter et les déclencher via l'appuie sur des boutons.

==='''Semaine 7'''===

''[[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 continuez a travaillez sur le serveur de collecte: Les données que nous savons récupérer via bluetooth sont stockée dans un fichier .log. Apres avoir bien compris comment marchait la fonction '''parse''' manuellement( lors de son utilisation dans le shell, nous l'avons implanter dans notre serveur de collecte qui lance cette commande lors de l’appuie sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêté. nous avons donc rajouté un temps à entré nous même sur l'interface. La fonction '''parse''' est effectué commence et le sous processus va attendre le temps donné avant de lancer une commande permettant de tuer le processus et mettant donc fin au remplissage du fichier '''.log'''. Nous voulons de plus réussir à lancer une fonction de collecte sans temps. c'est à dire que nous coupons la collecte via un bouton par nous même. nous voulions utiliser des Sockets pour pouvoir définir nous même la gestions de la communication mais l'idée a été abandonné car nous avons réussi a sauvegarder le PID du processus lancé. Il nous suffit donc de l’arrêter grâce à un autre bouton qui récupère cette variable et l’arrête ensuite.

Toutes nos fonctions pythons étant regroupées dans notre serveur '''requete.py''' nous avons décidé de créé un module qui regroupera toutes ces fonction que nous pourrons utilisé dans '''requete.py'''. ceci nous permet de voir plus claire dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.

Nous essayons en continues d'adapter le layout du site pour le rendre le plus attractif et simple possible. de facon a ce que chaque bouton et tableau soient claires et compréhensibles.

Nous avons commencé à récupéré les fichier '''json''' créé à partir des fichier '''log'''. c'est a dire que ces fichiers sont automatiquement stockés coté serveur dans un dossier nommé '''static/log'''. Notre but est de récupérer le nom des fichier json et de les afficher dans un composant sur notre interface web. il nous sera donc possible ensuite de sélectionner le nom d'un fichier. lors de la sélection de ce nom de fichier, un tableau apparaît avec les valeurs de distances à l’intérieur.

==='''Semaine 8'''===

''[[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 a développer les points énoncé la semaine dernière. Nous avons décidé de nous dirigé vers un serveur HTTP Simple pour accéder à nos fichiers. il s’avère que nous finirons par ne pas utiliser ce serveur. Nous irons récupérer les fichiers en question via des requêtes '''ajax''' faites à la sélection du nom du fichier.

Nous rencontrons depuis le début des problèmes avec les fonctions de connexion qui peuvent ne pas marcher a un moment donner. Nous essayons de trouver pourquoi ce bug est un bug qui ne se produit pas à chaque fois. Nous avons déterminé qu'il ne se produisait seulement lorsque les fonctions de connexions étaient lancée dans des threads. Nous ne savons toujours pas pourquoi ces thread bug seulement parfois et non à chaque essaie de connexion.

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

==='''Semaine 9'''===

''[[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 revue l'ensemble de notre code et les méthode utilisé avec notre tuteur '''Roudy Dagher'''. Nous nous approchons d'un serveur de collecte de donné stable et fonctionnel. Nous avons refait les différentes connexions entre l'interface et le serveur afin de ne faire que des requêtes sur des '''WebServices'''. Il nous ai possible de commencer la deuxième partie qui est l'envoie de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrice de positions.
Nous pourrons grâce a ces matrices afficher une carte 3d des balises et du TAG dans l'espace.

==='''Semaine 10'''===

==='''Semaine 11'''===

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

P18 Localisation of quadrotors

2017-12-19T14:17:16Z

Hdelatte : /* Semaine 6 */

=='''Cahier des charges'''==

===Présentation générale du projet===

====Contexte====

Dans un monde de plus en plus connecté, de nombreux drones sont déployés pour diverses applications comme l'espionnage, la surveillance, la cartographie de lieux et la livraison de colis. Les technologies nécessaires pour contrôler ces drones sont des sujets de recherche actuels.

Le contrôle de ceux-ci passe tout d'abord par la maîtrise de leur position dans l'espace. Le développement des applications liées à l'utilisation de drones nécessite un travail important sur la localisation spatiale d'objets connectés.

De plus, dans un souci d'utilisation, il est essentiel de développer des interfaces logicielles permettant d'exploiter ces données.

====Objectif du projet====

L'objectif de ce projet est de développer une interface logicielle permettant de traiter en temps réel les informations de localisation d'un drone et de balises, dans le but de définir leur localisation dans l'espace, en intérieur.

====Description du projet====

Pour réaliser le contrôle de drones, la première étape importante est de donner ses informations de position. Le but du projet est de développer une interface logicielle permettant de localiser le drone en temps réel en intérieur. Le drone se déplace dans un environnement dans lequel ont été installées de multiples balises. Il est équipé d'une carte, lui permettant de recevoir les distances relatives entre lui-même et les balises, sur laquelle différents algorithmes vont être implémentés pour effectuer la localisation en temps réel. Le projet requiert des compétences en développement hardware (Crazyflie 2.0, voir https://wiki.bitcraze.io/) et software (langage C/C++/Python/Javascript/HTML...).

Il se divise en 4 étapes principales, qui sont:
*1) Choisir les technologies utilisées
*2) Choisir l'architecture (OS / APIs)
*3) Développer les différentes parties du projet
*4) Intégrer et connecter les différentes parties du projet

La localisation étant en intérieur, le protocole GPS n'est donc pas assez précis pour les applications ciblées. La mise en place d'un tel dispositif permettrait grâce à l'utilisation d'un algorithme d'estimer avec une bonne précision les positions en intérieur d'une balise centrale (appelée Tag) et de balises (appelées Anchor). Le Tag scanne en temps réel la distance relative aux différentes balises, et il nous est retourné la position des balises et du Tag grâce à l'algorithme de localisation.

Le projet se compose de 3 parties:
* Collect & parse: collecter les données envoyées par les balises en communiquant avec un serveur et récupérer les données adéquates par un tri
* Localise: déterminer la matrice de position des balises et du Tag en traitant les données récupérées
* Display: développer l'interface homme machine pour afficher, étudier et utiliser les données traitées

Nous travaillerons dans un premier temps dans une optique temps différé avant de travailler en temps réel. Cela nous permettra d'acquérir des données utiles et réutilisables en aval.

A l'aboutissement du projet, nous devrions être capable via l'interface homme machine développée d'afficher précisément la position spatiale des balises ainsi que du Tag, grâce àl'utilisation d'un algorithme de localisation et des données récupérées, et d'afficher d'autres données relatives au déplacement du Tag ou des balises dans l'espace.

Si le temps le permet, nous pourrons aussi être amenés à adapter et utiliser l'interface développée pour l'utilisation d'un drone.

''Sujet originel''

To achieve the control of quadrotors, the first important task to give its position information. This project is to develop a software(GUI) to localize the quadrotors in real-time. The quadrotor is flying in an environment where several transmitters have been installed. The quadrotor is equipped with a deck to receive the relative distances between the deck and all transmitters, based on which different algorithms will be implemented to realize the real-time localization. The candidates need to have both experiences on hardware (Crazyflie 2.0, see https://wiki.bitcraze.io/) and software development (C/C , Python…).

====Calendrier====

''[[Avant le 29/09/17]]'' - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel

''[[Avant fin Octobre]]'' - Serveur de collecte et début du développement de l'interface logicielle

''[[Avant fin Décembre]]'' - Interface logicielle

''[[A la fin du PFE]]'' - Intégration finale des différentes parties (Serveur de collecte des données & Serveur de localisation & Interface logicielle)

Répartition du volume de travail (***h):

* Recherche sur les technologies à utiliser (**h)
* Développement du serveur de collecte de données (**h)
* Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
* Intégration des différentes parties (**h)
* Test et débuggage (**h)

====Choix techniques : matériel et logiciel====

Afin de développer ce dispositif, nous allons utiliser une Raspberry Pi 3 associée à une carte réceptrice, qui communique avec 4 balises composées chacune d'un microcontrôleur et d'une carte émettrice radio (UWB5C) et alimentées par batteries. La carte réceptrice joue le rôle du drone à localiser et communiquera les données émises par les balises vers l'ordinateur via Bluetooth.

====Choix technologiques====

Voici les technologies que nous utilisons pour chacune des parties de ce projet.

1) Serveur de collecte des données:
Scanne et parse les données récupérées pour fournir la matrice D des distances relatives du tag aux 4 balises
- API
- Python / Serveur Flask

2) Serveur de localisation (fourni):
Calcule grâce à l'algorithme de localisation et la matrice D les positions spatiales des 4 noeuds et du tag
- API
- Bootstrap
- Jquery
- Python

3) Interface utilisateur:
Affiche courbes, visualisation 3D, boutons ou données des fichiers envoyées par le serveur de localisation
- HTML5 / Javascript
- Fichiers JSON (serveurs de collecte et de localisation)

==='''Calendrier prévisionnel'''===

====Liste des tâches à effectuer====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! Heures S11 !! Heures S12 !! Après Noël !! Total
|-
| Cahier des charges / Wiki / Gitlab
| 4h
| 3h
| 1h
| x
| 1h30
| 1h
| 2h
| 1h
| 2h30
| 1h
|
|
|
|
|
|-
| Documentation sur les technos utilisées
| 2h
| 4h
| 3h
| 2h
| 3h
| 4h
| 5h
| 5h30
| 4h30
| 3h30
|
|
|
|
|
|-
| Documentation sur le matériel
| 2h
| 1h
| 1h
| 2h
| 1h
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Recherche et développement du serveur de collecte
| x
| 1h
| 2h
| 3h
| 3h30
| 4h
| 5h
| 7h
| 4h30
| 0,5h
|
|
|
|
|
|-
| Recherche et développement de l'interface Web
| x
| 2h
| 1h
| 3h
| 5h
| 6h
| 4h
| 7h
| 5h30
| 2h30
|
|
|
|
|
|-
| Recherche et intégration du serveur de localisation
| x
| x
| x
| x
| x
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Intégration des différentes parties
| x
| x
| x
| x
| 2h
| 2h
| 2h
| 3h
| 1h30
| x
|
|
|
|
|
|-
| Tests et débuggage
| x
| 1h
| 2h
| 1h
| 1h
| 1h
| 2h
| 3h
| 4h
| 0,5h
|
|
|
|
|
|-
| Optimisation/Correction des programmes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|}

=='''Avancement du Projet'''==

==='''Phase préparatoire'''===

''[[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é celui-ci avec les parties qui nous seraient utiles pour développer nos explications par la suite.

Nous avons de plus découpé le travail en sous-parties que nous avions mis dans un '''Mind map''' afin d'y voir plus clair sur la ligne à suivre.

Vous trouverez ce Mind map juste ci-dessous. Nous ne mettrons pas à jour ce Mind map chaque semaine mais il est fort probable que nous en referions un en milieu de projet pour pouvoir cibler les objectifs réussis et ceux à atteindre. Nous pourrons de plus redéfinir certains objectifs qui nous aurait semblé trop vague au début du projet.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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 des à présent des questions sur le bon choix de celles-ci. Nous commençons donc des tests ayant seulement pour but de nous familiariser avec l'environnement de travail et de réellement comprendre les fonctions déjà présentes qu'il faudra exploiter et implanter notre interface web.
Nous créons un gitlab avec notre tuteur et commençons a définir les taches premières sur celui-ci.
Nous en profitons pour affiner le Mind Map.

==='''Semaine 2'''===

''[[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 Raspberrypi et le serveur de position déjà créé.
Nous avons donc pu commencer a ce former sur les technologies qui nous serviraient par la suite. Nous avaons donc utilisé le cours d'openclassroom sur les serveur flask pour en apprendre les bases. Ce serveur flask est programmé en python et nous permets donc une grande liberté au niveau de l’exécutions de certains scripts. En effet les script de connexion bluetooth et de redirection de port qui nous permette de recuperer les données de distance sont eux meme codé en python et sont directement appelé via le serveur.
Dans ce serveur, représentant notre interface web, vous retrouverez la page '''/collecte''' qui représentera notre partie collecte de données ainsi que l'affichage de ces distances. Nous appellerons cette partie le serveur de collecte.

==='''Semaine 3'''===

''[[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.

[[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 pour 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çus des fonctions pythons de notre tuteurs afin d'obtenir une connexion bluetooth entre notre raspberrypi et notre ordinateur ainsi qu'une redirection de port de celle ci vers la connexion. Nous n'arrivons pas à utiliser ces fonctions sous linux et nous necessitons une explication de notre tuteur n'etant pas disponible a ce moment. Pour ne pas perdre de temps nous nous attaquons la creation de l'interface web a proprement parler. c'est a dire la création des pages html ainsi que le document javascript qui nous servira de bibliotheque de fonctions.chaque route de notre serveur sont relié a une series de fonctions python s'executant a l'apelle des url puis suivis d'un template de la page HTML en question. Nous en profitons de plus pour explorer le framework CSS bootstrap afin de mettre un premier design et une structure a notre page collecte qui sera la page principale de notre site pour ce début de projet.

Nous nous essayons de plus à différents tests sur des fichiers de format '''Json''' que nous devrons réussir à traiter correctement plus tard dans notre projet.
Nous récupérons une matrice que nous créons nous même en python (simulation d'une série de distances récupérée) que nous transformons au format Json pour ensuite l'afficher sur notre page web. Pour pouvoir proprement afficher se fichier '''Json''' renvoyé vers notre page, nous nous servons du fichier javascript afin de créer du code html contenant la matrice.

==='''Semaine 5'''===

''[[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é au format json et à l'afficher dans le code html. Toutefois nous créons nous mème ce set, il est maintenant nécessaire que nous arrivions à récupérer les set de distance réels reçus par la connexions bluetooth. Nous commencerons par un traitement asynchrone. L'idée est d’enregistrer les sets de distances dans un fichier '''Json''' stocké dans un dossier. Nous appellerons ce dossier plus tard via une requête ajax.

==='''Semaine 6'''===

''[[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 test manuels via le shell pour récupérer des données de distances et les stocker dans un fichier '''Json''' sur notre ordinateur.

Nous utilisons les commandes suivante pour se connecter via bluetooth:

rfcomm connect /dev/rfcomm0 B8:27:EB:80:DC:89 1

Rediriger le port de la raspberrypi3 vers la connexion:

python lps-collector/tcp_serial_redirect.py /dev/rfcomm0 9600

Collecter les données dans un fichier dont nous définissons le nom:

echo "cu -s9600 -lttyACM0"| nc localhost 7777
nc localhost 7777 | grep distance > static/log/dist-capture'+date+'.log

Nous pouvons '''parser''' le flux de donner avant de le stocker dans le fichier via cette commande:

python lps-collector/lps_parse.py static/log/dist-capture"+date+".log

Il est donc nécessaire d'inclure via des '''thread''' ces différente fonctions dans notre serveur python (Flask) afin d'automatiser le processus. Le but est de pouvoir choisir sur l'interface web quels fonctions il faut exécuter et les déclencher via l'appuie sur des boutons.

==='''Semaine 7'''===

''[[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 continuez a travaillez sur le serveur de collecte: Les données que nous savons récupérer via bluetooth sont stockée dans un fichier .log. Apres avoir bien compris comment marchait la fonction '''parse''' manuellement( lors de son utilisation dans le shell, nous l'avons implanter dans notre serveur de collecte qui lance cette commande lors de l’appuie sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêté. nous avons donc rajouté un temps à entré nous même sur l'interface. La fonction '''parse''' est effectué commence et le sous processus va attendre le temps donné avant de lancer une commande permettant de tuer le processus et mettant donc fin au remplissage du fichier '''.log'''. Nous voulons de plus réussir à lancer une fonction de collecte sans temps. c'est à dire que nous coupons la collecte via un bouton par nous même. nous voulions utiliser des Sockets pour pouvoir définir nous même la gestions de la communication mais l'idée a été abandonné car nous avons réussi a sauvegarder le PID du processus lancé. Il nous suffit donc de l’arrêter grâce à un autre bouton qui récupère cette variable et l’arrête ensuite.

Toutes nos fonctions pythons étant regroupées dans notre serveur '''requete.py''' nous avons décidé de créé un module qui regroupera toutes ces fonction que nous pourrons utilisé dans '''requete.py'''. ceci nous permet de voir plus claire dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.

Nous essayons en continues d'adapter le layout du site pour le rendre le plus attractif et simple possible. de facon a ce que chaque bouton et tableau soient claires et compréhensibles.

Nous avons commencé à récupéré les fichier '''json''' créé à partir des fichier '''log'''. c'est a dire que ces fichiers sont automatiquement stockés coté serveur dans un dossier nommé '''static/log'''. Notre but est de récupérer le nom des fichier json et de les afficher dans un composant sur notre interface web. il nous sera donc possible ensuite de sélectionner le nom d'un fichier. lors de la sélection de ce nom de fichier, un tableau apparaît avec les valeurs de distances à l’intérieur.

==='''Semaine 8'''===

''[[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 a développer les points énoncé la semaine dernière. Nous avons décidé de nous dirigé vers un serveur HTTP Simple pour accéder à nos fichiers. il s’avère que nous finirons par ne pas utiliser ce serveur. Nous irons récupérer les fichiers en question via des requêtes '''ajax''' faites à la sélection du nom du fichier.

Nous rencontrons depuis le début des problèmes avec les fonctions de connexion qui peuvent ne pas marcher a un moment donner. Nous essayons de trouver pourquoi ce bug est un bug qui ne se produit pas à chaque fois. Nous avons déterminé qu'il ne se produisait seulement lorsque les fonctions de connexions étaient lancée dans des threads. Nous ne savons toujours pas pourquoi ces thread bug seulement parfois et non à chaque essaie de connexion.

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

==='''Semaine 9'''===

''[[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 revue l'ensemble de notre code et les méthode utilisé avec notre tuteur '''Roudy Dagher'''. Nous nous approchons d'un serveur de collecte de donné stable et fonctionnel. Nous avons refait les différentes connexions entre l'interface et le serveur afin de ne faire que des requêtes sur des '''WebServices'''. Il nous ai possible de commencer la deuxième partie qui est l'envoie de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrice de positions.
Nous pourrons grâce a ces matrices afficher une carte 3d des balises et du TAG dans l'espace.

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

P18 Localisation of quadrotors

2017-12-19T14:16:38Z

Hdelatte : /* Semaine 6 */

=='''Cahier des charges'''==

===Présentation générale du projet===

====Contexte====

Dans un monde de plus en plus connecté, de nombreux drones sont déployés pour diverses applications comme l'espionnage, la surveillance, la cartographie de lieux et la livraison de colis. Les technologies nécessaires pour contrôler ces drones sont des sujets de recherche actuels.

Le contrôle de ceux-ci passe tout d'abord par la maîtrise de leur position dans l'espace. Le développement des applications liées à l'utilisation de drones nécessite un travail important sur la localisation spatiale d'objets connectés.

De plus, dans un souci d'utilisation, il est essentiel de développer des interfaces logicielles permettant d'exploiter ces données.

====Objectif du projet====

L'objectif de ce projet est de développer une interface logicielle permettant de traiter en temps réel les informations de localisation d'un drone et de balises, dans le but de définir leur localisation dans l'espace, en intérieur.

====Description du projet====

Pour réaliser le contrôle de drones, la première étape importante est de donner ses informations de position. Le but du projet est de développer une interface logicielle permettant de localiser le drone en temps réel en intérieur. Le drone se déplace dans un environnement dans lequel ont été installées de multiples balises. Il est équipé d'une carte, lui permettant de recevoir les distances relatives entre lui-même et les balises, sur laquelle différents algorithmes vont être implémentés pour effectuer la localisation en temps réel. Le projet requiert des compétences en développement hardware (Crazyflie 2.0, voir https://wiki.bitcraze.io/) et software (langage C/C++/Python/Javascript/HTML...).

Il se divise en 4 étapes principales, qui sont:
*1) Choisir les technologies utilisées
*2) Choisir l'architecture (OS / APIs)
*3) Développer les différentes parties du projet
*4) Intégrer et connecter les différentes parties du projet

La localisation étant en intérieur, le protocole GPS n'est donc pas assez précis pour les applications ciblées. La mise en place d'un tel dispositif permettrait grâce à l'utilisation d'un algorithme d'estimer avec une bonne précision les positions en intérieur d'une balise centrale (appelée Tag) et de balises (appelées Anchor). Le Tag scanne en temps réel la distance relative aux différentes balises, et il nous est retourné la position des balises et du Tag grâce à l'algorithme de localisation.

Le projet se compose de 3 parties:
* Collect & parse: collecter les données envoyées par les balises en communiquant avec un serveur et récupérer les données adéquates par un tri
* Localise: déterminer la matrice de position des balises et du Tag en traitant les données récupérées
* Display: développer l'interface homme machine pour afficher, étudier et utiliser les données traitées

Nous travaillerons dans un premier temps dans une optique temps différé avant de travailler en temps réel. Cela nous permettra d'acquérir des données utiles et réutilisables en aval.

A l'aboutissement du projet, nous devrions être capable via l'interface homme machine développée d'afficher précisément la position spatiale des balises ainsi que du Tag, grâce àl'utilisation d'un algorithme de localisation et des données récupérées, et d'afficher d'autres données relatives au déplacement du Tag ou des balises dans l'espace.

Si le temps le permet, nous pourrons aussi être amenés à adapter et utiliser l'interface développée pour l'utilisation d'un drone.

''Sujet originel''

To achieve the control of quadrotors, the first important task to give its position information. This project is to develop a software(GUI) to localize the quadrotors in real-time. The quadrotor is flying in an environment where several transmitters have been installed. The quadrotor is equipped with a deck to receive the relative distances between the deck and all transmitters, based on which different algorithms will be implemented to realize the real-time localization. The candidates need to have both experiences on hardware (Crazyflie 2.0, see https://wiki.bitcraze.io/) and software development (C/C , Python…).

====Calendrier====

''[[Avant le 29/09/17]]'' - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel

''[[Avant fin Octobre]]'' - Serveur de collecte et début du développement de l'interface logicielle

''[[Avant fin Décembre]]'' - Interface logicielle

''[[A la fin du PFE]]'' - Intégration finale des différentes parties (Serveur de collecte des données & Serveur de localisation & Interface logicielle)

Répartition du volume de travail (***h):

* Recherche sur les technologies à utiliser (**h)
* Développement du serveur de collecte de données (**h)
* Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
* Intégration des différentes parties (**h)
* Test et débuggage (**h)

====Choix techniques : matériel et logiciel====

Afin de développer ce dispositif, nous allons utiliser une Raspberry Pi 3 associée à une carte réceptrice, qui communique avec 4 balises composées chacune d'un microcontrôleur et d'une carte émettrice radio (UWB5C) et alimentées par batteries. La carte réceptrice joue le rôle du drone à localiser et communiquera les données émises par les balises vers l'ordinateur via Bluetooth.

====Choix technologiques====

Voici les technologies que nous utilisons pour chacune des parties de ce projet.

1) Serveur de collecte des données:
Scanne et parse les données récupérées pour fournir la matrice D des distances relatives du tag aux 4 balises
- API
- Python / Serveur Flask

2) Serveur de localisation (fourni):
Calcule grâce à l'algorithme de localisation et la matrice D les positions spatiales des 4 noeuds et du tag
- API
- Bootstrap
- Jquery
- Python

3) Interface utilisateur:
Affiche courbes, visualisation 3D, boutons ou données des fichiers envoyées par le serveur de localisation
- HTML5 / Javascript
- Fichiers JSON (serveurs de collecte et de localisation)

==='''Calendrier prévisionnel'''===

====Liste des tâches à effectuer====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! Heures S11 !! Heures S12 !! Après Noël !! Total
|-
| Cahier des charges / Wiki / Gitlab
| 4h
| 3h
| 1h
| x
| 1h30
| 1h
| 2h
| 1h
| 2h30
| 1h
|
|
|
|
|
|-
| Documentation sur les technos utilisées
| 2h
| 4h
| 3h
| 2h
| 3h
| 4h
| 5h
| 5h30
| 4h30
| 3h30
|
|
|
|
|
|-
| Documentation sur le matériel
| 2h
| 1h
| 1h
| 2h
| 1h
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Recherche et développement du serveur de collecte
| x
| 1h
| 2h
| 3h
| 3h30
| 4h
| 5h
| 7h
| 4h30
| 0,5h
|
|
|
|
|
|-
| Recherche et développement de l'interface Web
| x
| 2h
| 1h
| 3h
| 5h
| 6h
| 4h
| 7h
| 5h30
| 2h30
|
|
|
|
|
|-
| Recherche et intégration du serveur de localisation
| x
| x
| x
| x
| x
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Intégration des différentes parties
| x
| x
| x
| x
| 2h
| 2h
| 2h
| 3h
| 1h30
| x
|
|
|
|
|
|-
| Tests et débuggage
| x
| 1h
| 2h
| 1h
| 1h
| 1h
| 2h
| 3h
| 4h
| 0,5h
|
|
|
|
|
|-
| Optimisation/Correction des programmes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|}

=='''Avancement du Projet'''==

==='''Phase préparatoire'''===

''[[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é celui-ci avec les parties qui nous seraient utiles pour développer nos explications par la suite.

Nous avons de plus découpé le travail en sous-parties que nous avions mis dans un '''Mind map''' afin d'y voir plus clair sur la ligne à suivre.

Vous trouverez ce Mind map juste ci-dessous. Nous ne mettrons pas à jour ce Mind map chaque semaine mais il est fort probable que nous en referions un en milieu de projet pour pouvoir cibler les objectifs réussis et ceux à atteindre. Nous pourrons de plus redéfinir certains objectifs qui nous aurait semblé trop vague au début du projet.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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 des à présent des questions sur le bon choix de celles-ci. Nous commençons donc des tests ayant seulement pour but de nous familiariser avec l'environnement de travail et de réellement comprendre les fonctions déjà présentes qu'il faudra exploiter et implanter notre interface web.
Nous créons un gitlab avec notre tuteur et commençons a définir les taches premières sur celui-ci.
Nous en profitons pour affiner le Mind Map.

==='''Semaine 2'''===

''[[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 Raspberrypi et le serveur de position déjà créé.
Nous avons donc pu commencer a ce former sur les technologies qui nous serviraient par la suite. Nous avaons donc utilisé le cours d'openclassroom sur les serveur flask pour en apprendre les bases. Ce serveur flask est programmé en python et nous permets donc une grande liberté au niveau de l’exécutions de certains scripts. En effet les script de connexion bluetooth et de redirection de port qui nous permette de recuperer les données de distance sont eux meme codé en python et sont directement appelé via le serveur.
Dans ce serveur, représentant notre interface web, vous retrouverez la page '''/collecte''' qui représentera notre partie collecte de données ainsi que l'affichage de ces distances. Nous appellerons cette partie le serveur de collecte.

==='''Semaine 3'''===

''[[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.

[[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 pour 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çus des fonctions pythons de notre tuteurs afin d'obtenir une connexion bluetooth entre notre raspberrypi et notre ordinateur ainsi qu'une redirection de port de celle ci vers la connexion. Nous n'arrivons pas à utiliser ces fonctions sous linux et nous necessitons une explication de notre tuteur n'etant pas disponible a ce moment. Pour ne pas perdre de temps nous nous attaquons la creation de l'interface web a proprement parler. c'est a dire la création des pages html ainsi que le document javascript qui nous servira de bibliotheque de fonctions.chaque route de notre serveur sont relié a une series de fonctions python s'executant a l'apelle des url puis suivis d'un template de la page HTML en question. Nous en profitons de plus pour explorer le framework CSS bootstrap afin de mettre un premier design et une structure a notre page collecte qui sera la page principale de notre site pour ce début de projet.

Nous nous essayons de plus à différents tests sur des fichiers de format '''Json''' que nous devrons réussir à traiter correctement plus tard dans notre projet.
Nous récupérons une matrice que nous créons nous même en python (simulation d'une série de distances récupérée) que nous transformons au format Json pour ensuite l'afficher sur notre page web. Pour pouvoir proprement afficher se fichier '''Json''' renvoyé vers notre page, nous nous servons du fichier javascript afin de créer du code html contenant la matrice.

==='''Semaine 5'''===

''[[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é au format json et à l'afficher dans le code html. Toutefois nous créons nous mème ce set, il est maintenant nécessaire que nous arrivions à récupérer les set de distance réels reçus par la connexions bluetooth. Nous commencerons par un traitement asynchrone. L'idée est d’enregistrer les sets de distances dans un fichier '''Json''' stocké dans un dossier. Nous appellerons ce dossier plus tard via une requête ajax.

==='''Semaine 6'''===

''[[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 test manuels via le shell pour récupérer des données de distances et les stocker dans un fichier '''Json''' sur notre ordinateur.

Nous utilisons les commandes suivante pour se connecter via bluetooth:

rfcomm connect /dev/rfcomm0 B8:27:EB:80:DC:89 1

Rediriger le port de la raspberrypi3 vers la connexion:

python lps-collector/tcp_serial_redirect.py /dev/rfcomm0 9600

Collecter la données dans un fichier dont nous définissons le nom:

echo "cu -s9600 -lttyACM0"| nc localhost 7777
nc localhost 7777 | grep distance > static/log/dist-capture'+date+'.log

Nous pouvons '''parser''' le flux de donner avant de le stocker dans le fichier via cette commande:

python lps-collector/lps_parse.py static/log/dist-capture"+date+".log

Il est donc nécessaire d'inclure via des '''thread''' ces différente fonctions dans notre serveur python (Flask) afin d'automatiser le processus. Le but est de pouvoir choisir sur l'interface web quels fonctions il faut exécuter et les déclencher via l'appuie sur des boutons.

==='''Semaine 7'''===

''[[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 continuez a travaillez sur le serveur de collecte: Les données que nous savons récupérer via bluetooth sont stockée dans un fichier .log. Apres avoir bien compris comment marchait la fonction '''parse''' manuellement( lors de son utilisation dans le shell, nous l'avons implanter dans notre serveur de collecte qui lance cette commande lors de l’appuie sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêté. nous avons donc rajouté un temps à entré nous même sur l'interface. La fonction '''parse''' est effectué commence et le sous processus va attendre le temps donné avant de lancer une commande permettant de tuer le processus et mettant donc fin au remplissage du fichier '''.log'''. Nous voulons de plus réussir à lancer une fonction de collecte sans temps. c'est à dire que nous coupons la collecte via un bouton par nous même. nous voulions utiliser des Sockets pour pouvoir définir nous même la gestions de la communication mais l'idée a été abandonné car nous avons réussi a sauvegarder le PID du processus lancé. Il nous suffit donc de l’arrêter grâce à un autre bouton qui récupère cette variable et l’arrête ensuite.

Toutes nos fonctions pythons étant regroupées dans notre serveur '''requete.py''' nous avons décidé de créé un module qui regroupera toutes ces fonction que nous pourrons utilisé dans '''requete.py'''. ceci nous permet de voir plus claire dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.

Nous essayons en continues d'adapter le layout du site pour le rendre le plus attractif et simple possible. de facon a ce que chaque bouton et tableau soient claires et compréhensibles.

Nous avons commencé à récupéré les fichier '''json''' créé à partir des fichier '''log'''. c'est a dire que ces fichiers sont automatiquement stockés coté serveur dans un dossier nommé '''static/log'''. Notre but est de récupérer le nom des fichier json et de les afficher dans un composant sur notre interface web. il nous sera donc possible ensuite de sélectionner le nom d'un fichier. lors de la sélection de ce nom de fichier, un tableau apparaît avec les valeurs de distances à l’intérieur.

==='''Semaine 8'''===

''[[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 a développer les points énoncé la semaine dernière. Nous avons décidé de nous dirigé vers un serveur HTTP Simple pour accéder à nos fichiers. il s’avère que nous finirons par ne pas utiliser ce serveur. Nous irons récupérer les fichiers en question via des requêtes '''ajax''' faites à la sélection du nom du fichier.

Nous rencontrons depuis le début des problèmes avec les fonctions de connexion qui peuvent ne pas marcher a un moment donner. Nous essayons de trouver pourquoi ce bug est un bug qui ne se produit pas à chaque fois. Nous avons déterminé qu'il ne se produisait seulement lorsque les fonctions de connexions étaient lancée dans des threads. Nous ne savons toujours pas pourquoi ces thread bug seulement parfois et non à chaque essaie de connexion.

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

==='''Semaine 9'''===

''[[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 revue l'ensemble de notre code et les méthode utilisé avec notre tuteur '''Roudy Dagher'''. Nous nous approchons d'un serveur de collecte de donné stable et fonctionnel. Nous avons refait les différentes connexions entre l'interface et le serveur afin de ne faire que des requêtes sur des '''WebServices'''. Il nous ai possible de commencer la deuxième partie qui est l'envoie de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrice de positions.
Nous pourrons grâce a ces matrices afficher une carte 3d des balises et du TAG dans l'espace.

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

P18 Localisation of quadrotors

2017-12-10T16:40:36Z

Hdelatte : /* Semaine 9 */

=='''Cahier des charges'''==

===Présentation générale du projet===

====Contexte====

Dans un monde de plus en plus connecté, de nombreux drones sont déployés pour diverses applications comme l'espionnage, la surveillance, la cartographie de lieux et la livraison de colis. Les technologies nécessaires pour contrôler ces drones sont des sujets de recherche actuels.

Le contrôle de ceux-ci passe tout d'abord par la maîtrise de leur position dans l'espace. Le développement des applications liées à l'utilisation de drones nécessite un travail important sur la localisation spatiale d'objets connectés.

De plus, dans un souci d'utilisation, il est essentiel de développer des interfaces logicielles permettant d'exploiter ces données.

====Objectif du projet====

L'objectif de ce projet est de développer une interface logicielle permettant de traiter en temps réel les informations de localisation d'un drone et de balises, dans le but de définir leur localisation dans l'espace, en intérieur.

====Description du projet====

Pour réaliser le contrôle de drones, la première étape importante est de donner ses informations de position. Le but du projet est de développer une interface logicielle permettant de localiser le drone en temps réel en intérieur. Le drone se déplace dans un environnement dans lequel ont été installées de multiples balises. Il est équipé d'une carte, lui permettant de recevoir les distances relatives entre lui-même et les balises, sur laquelle différents algorithmes vont être implémentés pour effectuer la localisation en temps réel. Le projet requiert des compétences en développement hardware (Crazyflie 2.0, voir https://wiki.bitcraze.io/) et software (langage C/C++/Python/Javascript/HTML...).

Il se divise en 4 étapes principales, qui sont:
*1) Choisir les technologies utilisées
*2) Choisir l'architecture (OS / APIs)
*3) Développer les différentes parties du projet
*4) Intégrer et connecter les différentes parties du projet

La localisation étant en intérieur, le protocole GPS n'est donc pas assez précis pour les applications ciblées. La mise en place d'un tel dispositif permettrait grâce à l'utilisation d'un algorithme d'estimer avec une bonne précision les positions en intérieur d'une balise centrale (appelée Tag) et de balises (appelées Anchor). Le Tag scanne en temps réel la distance relative aux différentes balises, et il nous est retourné la position des balises et du Tag grâce à l'algorithme de localisation.

Le projet se compose de 3 parties:
* Collect & parse: collecter les données envoyées par les balises en communiquant avec un serveur et récupérer les données adéquates par un tri
* Localise: déterminer la matrice de position des balises et du Tag en traitant les données récupérées
* Display: développer l'interface homme machine pour afficher, étudier et utiliser les données traitées

Nous travaillerons dans un premier temps dans une optique temps différé avant de travailler en temps réel. Cela nous permettra d'acquérir des données utiles et réutilisables en aval.

A l'aboutissement du projet, nous devrions être capable via l'interface homme machine développée d'afficher précisément la position spatiale des balises ainsi que du Tag, grâce àl'utilisation d'un algorithme de localisation et des données récupérées, et d'afficher d'autres données relatives au déplacement du Tag ou des balises dans l'espace.

Si le temps le permet, nous pourrons aussi être amenés à adapter et utiliser l'interface développée pour l'utilisation d'un drone.

''Sujet originel''

To achieve the control of quadrotors, the first important task to give its position information. This project is to develop a software(GUI) to localize the quadrotors in real-time. The quadrotor is flying in an environment where several transmitters have been installed. The quadrotor is equipped with a deck to receive the relative distances between the deck and all transmitters, based on which different algorithms will be implemented to realize the real-time localization. The candidates need to have both experiences on hardware (Crazyflie 2.0, see https://wiki.bitcraze.io/) and software development (C/C , Python…).

====Calendrier====

''[[Avant le 29/09/17]]'' - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel

''[[Avant fin Octobre]]'' - Serveur de collecte et début du développement de l'interface logicielle

''[[Avant fin Décembre]]'' - Interface logicielle

''[[A la fin du PFE]]'' - Intégration finale des différentes parties (Serveur de collecte des données & Serveur de localisation & Interface logicielle)

Répartition du volume de travail (***h):

* Recherche sur les technologies à utiliser (**h)
* Développement du serveur de collecte de données (**h)
* Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
* Intégration des différentes parties (**h)
* Test et débuggage (**h)

====Choix techniques : matériel et logiciel====

Afin de développer ce dispositif, nous allons utiliser une Raspberry Pi 3 associée à une carte réceptrice, qui communique avec 4 balises composées chacune d'un microcontrôleur et d'une carte émettrice radio (UWB5C) et alimentées par batteries. La carte réceptrice joue le rôle du drone à localiser et communiquera les données émises par les balises vers l'ordinateur via Bluetooth.

====Choix technologiques====

Voici les technologies que nous utilisons pour chacune des parties de ce projet.

1) Serveur de collecte des données:
Scanne et parse les données récupérées pour fournir la matrice D des distances relatives du tag aux 4 balises
- API
- Python / Serveur Flask

2) Serveur de localisation (fourni):
Calcule grâce à l'algorithme de localisation et la matrice D les positions spatiales des 4 noeuds et du tag
- API
- Bootstrap
- Jquery
- Python

3) Interface utilisateur:
Affiche courbes, visualisation 3D, boutons ou données des fichiers envoyées par le serveur de localisation
- HTML5 / Javascript
- Fichiers JSON (serveurs de collecte et de localisation)

==='''Calendrier prévisionnel'''===

====Liste des tâches à effectuer====

# Se documenter sur le projet
##Langages et technologies utilisées
##Matériel utilisé
##Mettre en place du travail sur le Git
# Réaliser le serveur de collecte
##Récupérer les trames envoyées par bluetooth par le TAG via la Raspberry Pi
##Intégrer le serveur de localisation pour interpréter les trames
##Tester et optimiser
# Réaliser l'interface Web utilisateur
##Implémenter le serveur de collecte et de localisation
##Afficher et traiter les données stockées dans les fichiers JSON via le serveur (temps différé + temps réel)
##Tester et optimiser

===Replanification du cahier des charges / calendrier===

=='''Feuille d'heures'''==

{| 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 !! Heures S11 !! Heures S12 !! Après Noël !! Total
|-
| Cahier des charges / Wiki / Gitlab
| 4h
| 3h
| 1h
| x
| 1h30
| 1h
| 2h
| 1h
| 2h30
| 1h
|
|
|
|
|
|-
| Documentation sur les technos utilisées
| 2h
| 4h
| 3h
| 2h
| 3h
| 4h
| 5h
| 5h30
| 4h30
| 3h30
|
|
|
|
|
|-
| Documentation sur le matériel
| 2h
| 1h
| 1h
| 2h
| 1h
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Recherche et développement du serveur de collecte
| x
| 1h
| 2h
| 3h
| 3h30
| 4h
| 5h
| 7h
| 4h30
| 0,5h
|
|
|
|
|
|-
| Recherche et développement de l'interface Web
| x
| 2h
| 1h
| 3h
| 5h
| 6h
| 4h
| 7h
| 5h30
| 2h30
|
|
|
|
|
|-
| Recherche et intégration du serveur de localisation
| x
| x
| x
| x
| x
| x
| x
| x
| x
| x
|
|
|
|
|
|-
| Intégration des différentes parties
| x
| x
| x
| x
| 2h
| 2h
| 2h
| 3h
| 1h30
| x
|
|
|
|
|
|-
| Tests et débuggage
| x
| 1h
| 2h
| 1h
| 1h
| 1h
| 2h
| 3h
| 4h
| 0,5h
|
|
|
|
|
|-
| Optimisation/Correction des programmes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|}

=='''Avancement du Projet'''==

==='''Phase préparatoire'''===

''[[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é celui-ci avec les parties qui nous seraient utiles pour développer nos explications par la suite.

Nous avons de plus découpé le travail en sous-parties que nous avions mis dans un '''Mind map''' afin d'y voir plus clair sur la ligne à suivre.

Vous trouverez ce Mind map juste ci-dessous. Nous ne mettrons pas à jour ce Mind map chaque semaine mais il est fort probable que nous en referions un en milieu de projet pour pouvoir cibler les objectifs réussis et ceux à atteindre. Nous pourrons de plus redéfinir certains objectifs qui nous aurait semblé trop vague au début du projet.

[[Fichier:Projet de fin d'étude.png|centre|600px]]

==='''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 des à présent des questions sur le bon choix de celles-ci. Nous commençons donc des tests ayant seulement pour but de nous familiariser avec l'environnement de travail et de réellement comprendre les fonctions déjà présentes qu'il faudra exploiter et implanter notre interface web.
Nous créons un gitlab avec notre tuteur et commençons a définir les taches premières sur celui-ci.
Nous en profitons pour affiner le Mind Map.

==='''Semaine 2'''===

''[[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 Raspberrypi et le serveur de position déjà créé.
Nous avons donc pu commencer a ce former sur les technologies qui nous serviraient par la suite. Nous avaons donc utilisé le cours d'openclassroom sur les serveur flask pour en apprendre les bases. Ce serveur flask est programmé en python et nous permets donc une grande liberté au niveau de l’exécutions de certains scripts. En effet les script de connexion bluetooth et de redirection de port qui nous permette de recuperer les données de distance sont eux meme codé en python et sont directement appelé via le serveur.
Dans ce serveur, représentant notre interface web, vous retrouverez la page '''/collecte''' qui représentera notre partie collecte de données ainsi que l'affichage de ces distances. Nous appellerons cette partie le serveur de collecte.

==='''Semaine 3'''===

''[[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.

[[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 pour 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çus des fonctions pythons de notre tuteurs afin d'obtenir une connexion bluetooth entre notre raspberrypi et notre ordinateur ainsi qu'une redirection de port de celle ci vers la connexion. Nous n'arrivons pas à utiliser ces fonctions sous linux et nous necessitons une explication de notre tuteur n'etant pas disponible a ce moment. Pour ne pas perdre de temps nous nous attaquons la creation de l'interface web a proprement parler. c'est a dire la création des pages html ainsi que le document javascript qui nous servira de bibliotheque de fonctions.chaque route de notre serveur sont relié a une series de fonctions python s'executant a l'apelle des url puis suivis d'un template de la page HTML en question. Nous en profitons de plus pour explorer le framework CSS bootstrap afin de mettre un premier design et une structure a notre page collecte qui sera la page principale de notre site pour ce début de projet.

Nous nous essayons de plus à différents tests sur des fichiers de format '''Json''' que nous devrons réussir à traiter correctement plus tard dans notre projet.
Nous récupérons une matrice que nous créons nous même en python (simulation d'une série de distances récupérée) que nous transformons au format Json pour ensuite l'afficher sur notre page web. Pour pouvoir proprement afficher se fichier '''Json''' renvoyé vers notre page, nous nous servons du fichier javascript afin de créer du code html contenant la matrice.

==='''Semaine 5'''===

''[[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é au format json et à l'afficher dans le code html. Toutefois nous créons nous mème ce set, il est maintenant nécessaire que nous arrivions à récupérer les set de distance réels reçus par la connexions bluetooth. Nous commencerons par un traitement asynchrone. L'idée est d’enregistrer les sets de distances dans un fichier '''Json''' stocké dans un dossier. Nous appellerons ce dossier plus tard via une requête ajax.

==='''Semaine 6'''===

''[[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 test manuels via le shell pour récupérer des données de distances et les stocker dans un fichier '''Json''' sur notre ordinateur.

Nous utilisons les commandes suivante pour se connecter via bluetooth:

///////////////////

Rediriger le port de la raspberrypi3 vers la connexion:

////////////////////

Collecter la données dans un fichier dont nous définissons le nom:

////////////////////

Nous pouvons '''parser''' le flux de donner avant de le stocker dans le fichier via cette commande:

////////////////////

Il est donc nécessaire d'inclure via des '''thread''' ces différente fonctions dans notre serveur python (Flask) afin d'automatiser le processus. Le but est de pouvoir choisir sur l'interface web quels fonctions il faut exécuter et les déclencher via l'appuie sur des boutons.

==='''Semaine 7'''===

''[[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 continuez a travaillez sur le serveur de collecte: Les données que nous savons récupérer via bluetooth sont stockée dans un fichier .log. Apres avoir bien compris comment marchait la fonction '''parse''' manuellement( lors de son utilisation dans le shell, nous l'avons implanter dans notre serveur de collecte qui lance cette commande lors de l’appuie sur un bouton via notre interface virtuelle. Un problème rencontré était de savoir quand la récolte des données devait s’arrêté. nous avons donc rajouté un temps à entré nous même sur l'interface. La fonction '''parse''' est effectué commence et le sous processus va attendre le temps donné avant de lancer une commande permettant de tuer le processus et mettant donc fin au remplissage du fichier '''.log'''. Nous voulons de plus réussir à lancer une fonction de collecte sans temps. c'est à dire que nous coupons la collecte via un bouton par nous même. nous voulions utiliser des Sockets pour pouvoir définir nous même la gestions de la communication mais l'idée a été abandonné car nous avons réussi a sauvegarder le PID du processus lancé. Il nous suffit donc de l’arrêter grâce à un autre bouton qui récupère cette variable et l’arrête ensuite.

Toutes nos fonctions pythons étant regroupées dans notre serveur '''requete.py''' nous avons décidé de créé un module qui regroupera toutes ces fonction que nous pourrons utilisé dans '''requete.py'''. ceci nous permet de voir plus claire dans notre code et de faciliter le travail lorsque nous modifions le code tous les deux.

Nous essayons en continues d'adapter le layout du site pour le rendre le plus attractif et simple possible. de facon a ce que chaque bouton et tableau soient claires et compréhensibles.

Nous avons commencé à récupéré les fichier '''json''' créé à partir des fichier '''log'''. c'est a dire que ces fichiers sont automatiquement stockés coté serveur dans un dossier nommé '''static/log'''. Notre but est de récupérer le nom des fichier json et de les afficher dans un composant sur notre interface web. il nous sera donc possible ensuite de sélectionner le nom d'un fichier. lors de la sélection de ce nom de fichier, un tableau apparaît avec les valeurs de distances à l’intérieur.

==='''Semaine 8'''===

''[[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 a développer les points énoncé la semaine dernière. Nous avons décidé de nous dirigé vers un serveur HTTP Simple pour accéder à nos fichiers. il s’avère que nous finirons par ne pas utiliser ce serveur. Nous irons récupérer les fichiers en question via des requêtes '''ajax''' faites à la sélection du nom du fichier.

Nous rencontrons depuis le début des problèmes avec les fonctions de connexion qui peuvent ne pas marcher a un moment donner. Nous essayons de trouver pourquoi ce bug est un bug qui ne se produit pas à chaque fois. Nous avons déterminé qu'il ne se produisait seulement lorsque les fonctions de connexions étaient lancée dans des threads. Nous ne savons toujours pas pourquoi ces thread bug seulement parfois et non à chaque essaie de connexion.

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

==='''Semaine 9'''===

''[[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 revue l'ensemble de notre code et les méthode utilisé avec notre tuteur '''Roudy Dagher'''. Nous nous approchons d'un serveur de collecte de donné stable et fonctionnel. Nous avons refait les différentes connexions entre l'interface et le serveur afin de ne faire que des requêtes sur des '''WebServices'''. Il nous ai possible de commencer la deuxième partie qui est l'envoie de ces tableaux de données afin de les envoyer vers le serveur de localisation via des API afin de recevoir des matrice de positions.
Nous pourrons grâce a ces matrices afficher une carte 3d des balises et du TAG dans l'espace.

=='''Observations'''==

==='''Problèmes rencontrés'''===

==='''Solutions apportées'''===

P18 Localisation of quadrotors

2017-12-10T16:35:52Z

Hdelatte : /* Semaine 8 */

P18 Localisation of quadrotors

2017-12-10T16:29:27Z

Hdelatte : /* Semaine 7 */

P18 Localisation of quadrotors

2017-12-07T14:37:42Z

Hdelatte : /* Semaine 6 */

P18 Localisation of quadrotors

2017-12-07T14:29:25Z

Hdelatte : /* Semaine 5 */

P18 Localisation of quadrotors

2017-12-07T14:19:17Z

Hdelatte : /* Semaine 5 */

P18 Localisation of quadrotors

2017-12-07T14:13:05Z

Hdelatte : /* Semaine 4 */

P18 Localisation of quadrotors

2017-12-07T13:47:34Z

Hdelatte : /* Semaine 2 */

P18 Localisation of quadrotors

2017-12-07T13:23:18Z

Hdelatte : /* Phase préparatoire */

Fichier:Projet de fin d'étude.png

2017-12-07T13:17:29Z

Hdelatte :

P18 Localisation of quadrotors

2017-12-04T15:03:02Z

Hdelatte : /* Phase préparatoire */

P18 Localisation of quadrotors

2017-12-04T15:01:27Z

Hdelatte : /* Avancement du Projet */

P18 Localisation of quadrotors

2017-12-04T14:54:23Z

Hdelatte : /* Phase préparatoire */

Cahier 2017 groupe n°5

2017-11-17T14:11:25Z

Hdelatte : /* Sécurisation des données */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.179
www IN A 193.48.57.179
@ IN A 193.48.57.179

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.179

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

====Sécurisation des données====

Nous créons trois nouvelles partitions qui vont représenter nos disques.

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

Nous ajoutons ces partitions dans la machine virtuelle via le fichier IMA5-BANANE.conf

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On installe mdadm dans notre MV

apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:

/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:

root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine. On constaste que la premiere partition a été "removed":

root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour remettre la partition dans le raid5 il faut taper la commande suivante

root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau et création de conteneurs sous Machine Virtuelle Linux====

Cahier 2016 groupe n°2

2017-11-17T13:58:29Z

Hdelatte : Annulation des modifications 46348 de Hdelatte (discussion)

== Tâche particulière ==

Câblage de la fibre:
 
Prise de connaissance du sujet de PRA et le choix des tâches particulières. Nous avons également commencer à essayer d'identifier les câbles de fibres déjà existants.
 
Toujours sur la tâche particulière. Identification de tous les câbles déjà tirés. Test de link de chaque câble. Nous avons également commencé à passer les câbles restants.
Tous les câbles nécessaires ont été tirés entre les deux salles, tous les link sont up. Nous avons identifié chaque câble par un scotch de couleur différente. Nous avons également percé la gouttière de la E304 pour laisser passer un raccord de fibre proprement.
 

* Nous avons pu identifier les câbles déjà présents. Il y a donc 2 câbles déjà tirés entre les 2 piles, 2 câbles qui partent de la E306 jusqu'au boîtier ainsi qu'un câble par salle quid descend dans le local technique.
* Nous allons donc prolonger les 2 câbles s'arrêtant dans le boîtier et tirer 2 nouveaux câbles entre les deux piles: nous aurons donc 6 fils au total.
* 2 Grands câbles de 30m ~ -> Estimation de 26m entre les 2 piles.
* 2 petits câbles de 15m ~ -> Estimation de 13m du boîtier à la pile
* Retirer le câble ethernet qui était tiré entre les 2 piles.
* 7 heures passées au total sur la tâche particulière
[[Fichier:im1.JPG|300px|thumb|left|Fibre passant entre les 2 salles]]
[[Fichier:im2.JPG|300px|thumb|right|Câbles dans le faux plafond]]
[[Fichier:im4.JPG|300px|thumb|left|Guide câbles pour le faux plafond]]
[[Fichier:im5.JPG|300px|thumb|right|Boîtiers contenant les raccords de fibres]]
[[Fichier:im6.JPG|300px|thumb|left|Les fibres en E304 disponibles]]
[[Fichier:im7.JPG|300px|thumb|right|Trou dans le cache laissant passer la fibre]] 

== Travail commun ==

* Installation de la machine virtuelle XEN

<pre>
xen-create-image --hostname=GreenArrow --ip=193.48.57.162 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Modification du fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:
<pre>
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-home -v
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-var -v
</pre>

<pre>
disk = [
'file:/usr/local/xen/domains/GreenArrow/disk.img,xvda2,w',
'file:/usr/local/xen/domains/GreenArrow/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-GreenArrow-home,xvdc,w',
'phy:/dev/virtual/ima5-GreenArrow-var,xvdb,w',
]
</pre>

Commandes de base pour démarrer la VM proprement:
<pre>
ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/GreenArrow.cfg
ssh username@weppes
ssh root@193.48.57.162
</pre>

* Achat du nom de domaine [http://jjlddelamuerto.space] sur Gandi pour 1.19€ TTC

=== Services Internet ===

==== Serveur SSH ====

Sur notre machine virtuelle nous avons configuré le fichier sshd_config (changement de la ligne PubkeyAuthentication) :
<pre>
root@GreenArrow:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

root@GreenArrow:~# service ssh restart
</pre>

Nous avons ensuite réussi à nous connecter en SSH sur notre VM:
<pre>
jjoignau@weppes:~$ ssh root@193.48.57.162
root@193.48.57.162's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 7 10:06:49 2016
root@GreenArrow:~# exit
</pre>

==== Serveur DNS ====

Tout d'abord, nous modifions le fichier '''named.conf.local''' pour créer les zones nécessaires :

<pre>
root@GreenArrow:/etc/bind# vim /etc/bind/named.conf.local
zone "jjlddelamuerto.space" IN {
type master;
file "/etc/bind/db.jjlddelamuerto.space";
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/db.57.48.193.in-addr.arpa";
};
</pre>

Nous créons ensuite les fichiers '''db.jjlddelamuerto.space''' et '''db.57.48.193.in-addr.arpa''' :
<pre>
$TTL 604800
@ IN SOA ns.jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.jjlddelamuerto.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162
ns IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
www IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
@ IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
</pre>
<pre>
$TTL 604800
@ IN SOA jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
57.48.193.in-addr.arpa. IN NS ns.jjlddelamuerto.space.
57.48.193.in-addr.arpa. IN NS ns2.gandi.net.

162 IN PTR jjlddelamuerto.space.
</pre>

Nous modifions ensuite le fichier /etc/resolv.conf afin de passer par notre serveur :
<pre>
root@GreenArrow:/etc/bind# vim /etc/resolv.conf
search jjlddelamuerto.space
nameserver 193.48.57.162
</pre>

Enfin, nous vérifions notre configuration :
<pre>
root@GreenArrow:/etc/bind# host www.jjlddelamuerto.space
www.jjlddelamuerto.space has address 193.48.57.162
www.jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8

root@GreenArrow:/etc/bind# host -tany jjlddelamuerto.space
jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8
jjlddelamuerto.space has address 193.48.57.162
jjlddelamuerto.space has SOA record ns.jjlddelamuerto.space. root.jjlddelamuerto.space. 2016113007 604800 86400 2419200 604800
jjlddelamuerto.space name server ns6.gandi.net.
jjlddelamuerto.space name server ns.jjlddelamuerto.space.
</pre>

==== Sécurisation de site web par certificat ====

Premièrement, sur Gandi nous lançons l'étape d'achat d'un certificat SSL.
Puis, sur la VM nous générons le CSR grâce à cette commande:

<pre>
root@GreenArrow:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout GreenArrow.key -out GreenArrow.csr
Generating a 2048 bit RSA private key

If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:jjlddelamuerto.space
Email Address []:
A challenge password []:
An optional company name []:

root@GreenArrow:/etc/apache2/sites-available/clef# ls
GreenArrow.csr GreenArrow.key

root@GreenArrow:/etc/apache2/sites-available/clef# cat GreenArrow.csr

-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----
</pre>

Nous continuons donc la procédure pour obtenir le certificat, et attendons donc sa mise en place.

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

<pre>
root@GreenArrow:~# apt-get install postfix mailx
</pre>

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

<pre>
root@GreenArrow:/etc/bind# cp certificat.crt /etc/ssl/certs/jjlddelamuerto.space.crt
root@GreenArrow:/etc/bind# cp serveur.key /etc/ssl/private/jjlddelamuerto.space.key
root@GreenArrow:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@GreenArrow:/etc/bind# c_rehash /etc/ssl/certs
</pre>

Enfin, la dernière étape consiste en la modification des fichiers 000-jjlddelamuerto.space-ssl.conf et ports.conf :

<pre>
root@GreenArrow:/etc/apache2/sites-available# cat 000-jjlddelamuerto.space-ssl.conf
<VirtualHost *:443>
ServerName www.jjlddelamuerto.space
ServerAlias jjlddelamuerto.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/jjlddelamuerto.space.crt
SSLCertificateKeyFile /etc/ssl/private/jjlddelamuerto.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@GreenArrow:/etc/apache2# cat ports.conf
Listen 80

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls.c>
Listen 443
</IfModule>
</pre>

Un redémarrage du service apache2 est maintenant nécessaire :

<pre>
root@GreenArrow:/etc/apache2# service apache2 stop
root@GreenArrow:/etc/apache2# service apache2 start
root@GreenArrow:/etc/apache2# service apache2 reload
</pre>

Nous pouvons voir que notre site [https://jjlddelamuerto.space] est maintenant sécurisé, un cadenas vert est bien présent.

==== Sécurisation de serveur DNS par DNSSEC ====

Génération des clefs asymétriques:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE jjlddelamuerto.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE jjlddelamuerto.space
</pre>

On modifie le nom des clefs:
<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# ls
dsset-jjlddelamuerto.space. jjlddelamuerto.space-zsk.key
jjlddelamuerto.space-ksk.key jjlddelamuerto.space-zsk.private
jjlddelamuerto.space-ksk.private
</pre>

Ensuite nous signons les zones:

<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# dnssec-signzone -o jjlddelamuerto.space -k jjlddelamuerto.space-ksk
../db.jjlddelamuerto.space jjlddelamuerto.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.jjlddelamuerto.space.signed
</pre>

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

[[Fichier:jjlddnssec.png]]

=== Tests d'intrusion ===

==== Intrusion par changement d'adresse MAC ====

Tout d'abord nous modifions le fichier /etc/network/interfaces:
<pre>
root@zebrasoma:/home/pifou# vim /etc/network/interfaces
auto wlan5
iface wlan5 inet static
address 172.26.79.21
netmask 255.255.240.0
gateway 172.26.79.254
wireless mode-managed
wireless-essid Wolverine
wireless-key 0123456789
</pre>

Nous vérifions ensuite que nous sommes associés à Wolverine:
<pre>
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11abg ESSID:"Wolverine"
Mode:Managed Frequency:2.462 GHz Access Point: 44:AD:D9:5F:87:00
Bit Rate=54 Mb/s Tx-Power=200 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
Link Quality=50/70 Signal level=-60 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
</pre>

Nous changeons ensuite l'@ MAC:
<pre>
root@zebrasoma:/home/pifou# ip link set wlan5 address 00:1a:56:a4:4b:ff
</pre>

<pre>
root@zebrasoma:/home/pifou# ip a
3: wlan5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:1a:56:a4:4b:ff brd ff:ff:ff:ff:ff:ff
inet 172.26.79.21/20 brd 172.26.79.255 scope global wlan5
valid_lft forever preferred_lft forever
</pre>

Après le changement d'@ MAC, l'association est bien impossible:
<pre>
root@zebrasoma:/home/pifou# ifconfig wlan5 up
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11bgn ESSID:"Wolverine"
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
</pre>

==== Crackage de la clef WEP ====

Nous avons fait le crack de la clé WEP sur cracotte08.
Pour cracker la clef WEP, nous avons tout d'abord utiliser airmon-ng afin de voir le statut des interfaces réseau.
<pre>
root@zebrasoma:/home/pifou# airmon-ng

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
</pre>

On entre ensuite en mode monitoring sur l'interface wlan5 :
<pre>
root@zebrasoma:/home/pifou# airmon-ng start wlan5

Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID Name
1986 avahi-daemon
1987 avahi-daemon

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
(monitor mode enabled on mon1)

</pre>

Pour continuer, nous capturons les paquets transitant afin de collecter les paquets nécessaires au décryptage de la clef WEP. L'option --encrypt wep permet de filtrer uniquement les points d'accès WEP.
<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wep wlan5

CH 5 ][ Elapsed: 0 s ][ 2016-03-31 18:36

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -42 3 0 0 3 54e. WEP WEP Wolverine
04:DA:D2:9C:50:50 -59 2 11 0 2 54e. WEP WEP cracotte01
04:DA:D2:9C:50:56 -59 3 19 0 2 54e. WEP WEP cracotte07
04:DA:D2:9C:50:59 -59 2 0 0 2 54e. WEP WEP cracotte10
04:DA:D2:9C:50:57 -59 2 15 0 2 54e. WEP WEP cracotte08
04:DA:D2:9C:50:52 -58 3 85 42 2 54e. WEP WEP cracotte03
04:DA:D2:9C:50:54 -58 1 20 9 2 54e. WEP WEP cracotte05
04:DA:D2:9C:50:55 -60 1 9 4 2 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -59 2 134 66 2 54e. WEP WEP cracotte02
04:DA:D2:9C:50:53 -61 6 95 47 2 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:50 00:0F:B5:92:23:75 -66 54e-48e 68 10
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -72 36e- 2e 133 19
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -66 54e-36e 89 15
04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -62 54e-48e 23 84
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -66 54e-36e 576 20
</pre>

Nous avons choisi de récuperer la clef WEP de cracotte03 (son BSSID est lié à une station)

<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 2 -w crackWEP wlan5

CH 2 ][ Elapsed: 12 s ][ 2016-03-31 18:42

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:52 -57 35 43 1066 87 2 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -64 36e-48e 1232 1067
</pre>

Enfin, nous lançons le crack de la clef à l'aide de aircrack-ng :
<pre>
root@zebrasoma:/home/pifou# aircrack-ng crackWEP-02.cap
Aircrack-ng 1.2 beta3

[00:00:04] Tested 112801 keys (got 3050 IVs)

KB depth byte(vote)
0 6/ 10 CD(5120) 15(4864) 6D(4864) 8C(4864) A7(4864)
1 46/ 1 E9(4352) 04(4096) 0E(4096) 0F(4096) 16(4096)
2 14/ 42 C8(4864) 10(4608) 11(4608) 1D(4608) 58(4608)
3 19/ 3 CF(4864) 0A(4608) 5E(4608) 8E(4608) 90(4608)
4 2/ 16 08(5632) 89(5376) 96(5376) B4(5376) F7(5376)

Failed. Next try with 5000 IVs.
</pre>

Il est nécessaire d'être proche du point d’accès (sinon le débit est trop faible, ce qui rend l'opération longue), ainsi que de capturer un minimum de 10 000 paquets.

Au final, nous arrivons bien à récupérer la clef WEP :
<pre>

Aircrack-ng 1.2 beta3

[00:04:10] Tested 799 keys (got 42913 IVs)

KB depth byte(vote)
0 0/ 1 EE(56320) B4(51712) 9D(50944) 4E(50688) 28(50432)
1 1/ 2 D9(55552) 3D(50176) 68(49664) 08(49408) 49(49152)
2 1/ 5 A2(53504) 5B(52480) 93(52480) 73(52224) 10(50432)
3 1/ 3 30(53248) 81(51456) 5B(49920) 6E(49920) 1E(49664)
4 9/ 4 9D(50176) 31(49408) 18(49152) 72(49152) E1(49152)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44 ]
Decrypted correctly: 100%
</pre>

==== Cassage de mot de passe WPA-PSK par force brute ====
Nous refaisons les mêmes actions que pour le crackage de clef WEP.
Cette fois nous essayons de cracker la clef WPA sur cracotte03.

<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wpa wlan5
</pre>
<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 13 -w crackWPA wlan5
</pre>

Une fois le handshake récupéré:
<pre>
root@zebrasoma:/home/pifou# aircrack-ng -w dico.txt crackWPA-01.cap
</pre>
Nous avons lancé ceci sur le eeePC qui a une vitesse de traitement 5 fois inférieure à celle d'une zabeth environ (environ 5h de traitement). Puis nous obtenons le résultat suivant:
<pre>
Aircrack-ng 1.2 beta3

[04:32:42] 12399908 keys tested (759.63 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 70 EE 27 96 5B 34 B5 4F 06 A1 F2 B6 A7 16 1E 21
7A 0B BD F4 13 67 5B 4C ED 30 A9 0D 91 E3 F9 7F
88 E6 12 68 9C 77 4B 48 EB 5E 6A 5A DD 1D D9 08
36 40 94 7D B4 05 80 B2 60 FA 84 81 50 CE DC 87

EAPOL HMAC : 83 03 24 AC 39 AB 67 E7 7B C4 40 E8 6B 6D 7D 47

</pre>

=== Réalisations ===
==== Sécurisation des données ====

Nous créons d'abord 3 nouvelles partitions, que nous associons à notre VM en modifiant le fichier GreenArrow.cfg :

<pre>
lvcreate -L 1G -n /dev/virtual/GreenArrow-1 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-2 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-3 -v

'phy:/dev/virtual/GreenArrow-1,xvdd,w',
'phy:/dev/virtual/GreenArrow-2,xvde,w',
'phy:/dev/virtual/GreenArrow-3,xvdf,w',
</pre>

Il faut ensuite installer mdadm :

<pre>
apt-get install mdadm
</pre>

Nous avions une erreur à propos du subsystem. Pour que cela fonctionne, il nous manquait la commande :

<pre>
apt-get install linux-image-3.16.0-4-amd64
</pre>

Après un reboot de la machine, nous créons le volume /dev/md0:

<pre>
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
</pre>

Pour avoir le détail de la configuration actuelle:
<pre>
root@GreenArrow:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Nov 28 12:56:23 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Mon Nov 28 12:56:23 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : GreenArrow:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 0

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf
</pre>

Puis nous sauvons cette dernière afin de conserver md0:
<pre>
root@GreenArrow:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
</pre>

Puis:
<pre>
root@GreenArrow:~# mkfs /dev/md0
root@GreenArrow:~# mkdir /datamd0
root@GreenArrow:/datamd0# mount /dev/md0 /datamd0/
</pre>
Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être surs que la partition soit encore montée après le reboot:
<pre>
/dev/md0 /datamd0
</pre>

Nous créons un fichier texte sur le raid5:
<pre>
root@GreenArrow:/datamd0# vim testraid5.txt
</pre>

Nous mettons en commentaire la 2ème partition dans le fichier de conf, puis redémarrons la machine:
<pre>
root@GreenArrow:/datamd0# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Nov 28 12:56:23 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon Nov 28 13:20:27 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : GreenArrow:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 4

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
2 0 0 2 removed
2 202 80 2 active sync /dev/xvdf
</pre>
On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:
<pre>
root@GreenArrow:~# ls /datamd0/
testraid5.txt
</pre>

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours:
Suppression de la partition xvdf:
<pre>
root@GreenArrow:~# mdadm --set-faulty /dev/md0 /dev/xvdf
</pre>
<pre>
root@GreenArrow:~# mdadm --remove /dev/md0 /dev/xvdf
</pre>
La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>
On remet la partition:
<pre>
root@GreenArrow:~# mdadm --add /dev/md0 /dev/xvdf
</pre>
On peut ensuite constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:
<pre>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===>.................] recovery = 18.2% (191112/1047552) finish=0.4min speed=31852K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 20.0% (210764/1047552) finish=0.4min speed=30109K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 21.8% (229836/1047552) finish=0.4min speed=32833K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 59.6% (626140/1047552) finish=0.2min speed=29816K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 94.3% (989688/1047552) finish=0.0min speed=30124K/sec

unused devices: <none>
root@GreenArrow:~# [ 446.720069] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
</pre>

==== Cryptage de données ====

Tout d'abord, nous vérifions grâce à Gparted que la carte SD fournie comporte une seule partition.
Une fois ce test passé, nous regardons grâce à dmesg où est localisé la carte SD :

<pre>
root@zebrasoma:/# dmesg
[...]
[1126726.403767] mmcblk1: mmc1:59b4 NCard 14.7 GiB
</pre>

Notre carte SD se situe donc sur /dev/mmcblk1.
Nous faisons donc un chiffrage AES avec un hashage SHA256 de la carte SD :

<pre>
root@zebrasoma:/# cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>

Nous devons alors renseigner un mot de passe pour crypter la clef.
Ensuite, nous ouvrons la partition Luks, puis nous formatons la carte :

<pre>
root@zebrasoma:/# cryptsetup luksOpen /dev/sdb1 crypt_sd
root@zebrasoma:/# mkfs.ext4 /dev/mapper/crypt_sd
</pre>

Nous montons la partition, puis créons un fichier sur la carte :
<pre>
root@zebrasoma:/# mount /dev/mapper/crypt_sd /mnt
root@zebrasoma:/# vi /mnt/test.txt #on marque un texte dans le fichier
</pre>

Enfin, nous démontons la carte SD et fermons la partition Luks :
<pre>
root@zebrasoma:/# umount /mnt
root@zebrasoma:/# cryptsetup luksClose crypt_sd
</pre>

Nous essayons ensuite d'accéder à la carte SD. En renseignant un mauvais mot de passe, une erreur apparaît.
Cependant, une fois le bon mot de passe renseigné, tout re-devient possible.

==== Sécurisation Wifi par WPA2-EAP ====
Tout d'abord, nous installons FreeRadius sur notre machine virtuelle. 
Dans le fichier '''users''', nous renseignons le login et le mot de passe pour se connecter à la borne Wifi : 
<pre>
GreenArrow Cleartext-Password:="glopglop"
</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne E306 et E304 : 
<pre>
client E306 {
ipaddr = 10.60.1.2
secret = password
}
client E304 {
ipaddr = 10.60.1.4
secret = password
}
</pre>

Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''', puis nous rentrons en mode configuration : 
<pre>
aaa authentication login eap_greenarrow group radius_greenarrow
radius-server host 193.48.57.162 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_greenarrow
server 193.48.57.162 auth-port 1812 acct-port 1813

dot11 ssid SSID_GREENARROW
vlan 3
authentication open eap eap_greenarrow
authentication network-eap eap_greenarrow
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 3 mode ciphers aes-ccm tkip
ssid SSID_GREENARROW

interface Dot11Radio0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
bridge-group 3 subscriber-loop-control
bridge-group 3 spanning-disabled
bridge-group 3 block-unknown-source
no bridge-group 3 source-learning
no bridge-group 3 unicast-flooding

interface GigabitEthernet0.3
encapsulation dot1Q 3
bridge-group 3
</pre>

Une fois ces modifications effectuées, nous configurons l'interface wlan0 de l'eeePC pour pouvoir se connecter au Wifi à l'aide de '''ifup wlan0''' :

<pre>
auto wlan0
iface wlan0 inet static
address 10.60.3.2
netmask 255.255.255.0
gateway 10.60.3.1
wpa-ssid SSID_GREENARROW
wpa-key-mgmt WPA-EAP
wpa-identity GreenArrow
wpa-password glopglop
</pre>

On lance le serveur FreeRadius via freeradius -X (mode debug).
Sur smartphone, nous arrivons à détecter notre SSID (SSID_GREENARROW). Nous pouvons également ping notre eeePC depuis la machine virtuelle, tout comme nous arrivons à pinger des Vm d'autres groupes depuis notre eeePC. 
<pre>
root@GreenArrow:/etc/freeradius# ping 10.60.3.2
PING 10.60.3.2 (10.60.3.2) 56(84) bytes of data.
64 bytes from 10.60.3.2: icmp_seq=1 ttl=255 time=1.30 ms
64 bytes from 10.60.3.2: icmp_seq=2 ttl=255 time=1.96 ms
</pre>

==== Serveur DCHP ====

Pour cette partie, nous avons d'abord installer le paquet isc-dhcp-server.
Ensuite, nous avons modifier le fichier dhcpd.conf :
<pre>
option domain-name "jjlddelamuerto.space";
option domain-name-servers 193.48.57.162;

subnet 10.60.3.0 netmask 255.255.255.0 {
range 10.60.3.10 10.60.3.40;
option routers 10.60.3.1;
}
</pre>

Nous modifions ensuite isc-dhcp-server pour rajouter l'interface wlan0 :
<pre>
INTERFACES="wlan0"
</pre>

Nous pouvons maintenant nous connecter sur le reseau Wifi via smartphone, le serveur DHCP fonctionne correctement.
[[Fichier:Connexioniphone.JPG|thumb|center|Connexion via smartphone]]

==== Configuration et utilisation du PCBX ====

Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=JulienJoignaux
username=jjoignaux
secret=secret
context=work

[6002]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=LoicDelecroix
username=ldelecro
secret=secret
context=work</pre>
 

Puis nous modifions le fichier extensions.conf
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

[[Fichier:voipjjld.jpg|thumb|center|Appel entre 2 smartphones]]

== Références ==

* Crackage de la clef WEP : [http://wiki.backtrack-fr.net/index.php/Casser_une_cl%C3%A9_wep/wpa_avec_la_suite_Aircrack-ng]
* Cassage de mot de passe WPA-PSK : [http://www.crack-wifi.com/tutoriel-crack-wpa.php]
* Cryptage de données : [https://doc.ubuntu-fr.org/cryptsetup]
* DHCP : [https://doc.ubuntu-fr.org/isc-dhcp-server]
* Asterisk : [http://denisrosenkranz.com/tuto-installer-et-configurer-asterisk-sous-debian-6-et-ubuntu/]

Cahier 2016 groupe n°2

2017-11-17T13:55:37Z

Hdelatte : Annulation des modifications 46349 de Hdelatte (discussion)

== Tâche particulière ==

Câblage de la fibre:
 
Prise de connaissance du sujet de PRA et le choix des tâches particulières. Nous avons également commencer à essayer d'identifier les câbles de fibres déjà existants.
 
Toujours sur la tâche particulière. Identification de tous les câbles déjà tirés. Test de link de chaque câble. Nous avons également commencé à passer les câbles restants.
Tous les câbles nécessaires ont été tirés entre les deux salles, tous les link sont up. Nous avons identifié chaque câble par un scotch de couleur différente. Nous avons également percé la gouttière de la E304 pour laisser passer un raccord de fibre proprement.
 

* Nous avons pu identifier les câbles déjà présents. Il y a donc 2 câbles déjà tirés entre les 2 piles, 2 câbles qui partent de la E306 jusqu'au boîtier ainsi qu'un câble par salle quid descend dans le local technique.
* Nous allons donc prolonger les 2 câbles s'arrêtant dans le boîtier et tirer 2 nouveaux câbles entre les deux piles: nous aurons donc 6 fils au total.
* 2 Grands câbles de 30m ~ -> Estimation de 26m entre les 2 piles.
* 2 petits câbles de 15m ~ -> Estimation de 13m du boîtier à la pile
* Retirer le câble ethernet qui était tiré entre les 2 piles.
* 7 heures passées au total sur la tâche particulière
[[Fichier:im1.JPG|300px|thumb|left|Fibre passant entre les 2 salles]]
[[Fichier:im2.JPG|300px|thumb|right|Câbles dans le faux plafond]]
[[Fichier:im4.JPG|300px|thumb|left|Guide câbles pour le faux plafond]]
[[Fichier:im5.JPG|300px|thumb|right|Boîtiers contenant les raccords de fibres]]
[[Fichier:im6.JPG|300px|thumb|left|Les fibres en E304 disponibles]]
[[Fichier:im7.JPG|300px|thumb|right|Trou dans le cache laissant passer la fibre]] 

== Travail commun ==

* Installation de la machine virtuelle XEN

<pre>
xen-create-image --hostname=GreenArrow --ip=193.48.57.162 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Modification du fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:
<pre>
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-home -v
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-var -v
</pre>

<pre>
disk = [
'file:/usr/local/xen/domains/GreenArrow/disk.img,xvda2,w',
'file:/usr/local/xen/domains/GreenArrow/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-GreenArrow-home,xvdc,w',
'phy:/dev/virtual/ima5-GreenArrow-var,xvdb,w',
]
</pre>

Commandes de base pour démarrer la VM proprement:
<pre>
ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/GreenArrow.cfg
ssh username@weppes
ssh root@193.48.57.162
</pre>

* Achat du nom de domaine [http://jjlddelamuerto.space] sur Gandi pour 1.19€ TTC

=== Services Internet ===

==== Serveur SSH ====

Sur notre machine virtuelle nous avons configuré le fichier sshd_config (changement de la ligne PubkeyAuthentication) :
<pre>
root@GreenArrow:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

root@GreenArrow:~# service ssh restart
</pre>

Nous avons ensuite réussi à nous connecter en SSH sur notre VM:
<pre>
jjoignau@weppes:~$ ssh root@193.48.57.162
root@193.48.57.162's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 7 10:06:49 2016
root@GreenArrow:~# exit
</pre>

==== Serveur DNS ====

Tout d'abord, nous modifions le fichier '''named.conf.local''' pour créer les zones nécessaires :

<pre>
root@GreenArrow:/etc/bind# vim /etc/bind/named.conf.local
zone "jjlddelamuerto.space" IN {
type master;
file "/etc/bind/db.jjlddelamuerto.space";
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/db.57.48.193.in-addr.arpa";
};
</pre>

Nous créons ensuite les fichiers '''db.jjlddelamuerto.space''' et '''db.57.48.193.in-addr.arpa''' :
<pre>
$TTL 604800
@ IN SOA ns.jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.jjlddelamuerto.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162
ns IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
www IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
@ IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
</pre>
<pre>
$TTL 604800
@ IN SOA jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
57.48.193.in-addr.arpa. IN NS ns.jjlddelamuerto.space.
57.48.193.in-addr.arpa. IN NS ns2.gandi.net.

162 IN PTR jjlddelamuerto.space.
</pre>

Nous modifions ensuite le fichier /etc/resolv.conf afin de passer par notre serveur :
<pre>
root@GreenArrow:/etc/bind# vim /etc/resolv.conf
search jjlddelamuerto.space
nameserver 193.48.57.162
</pre>

Enfin, nous vérifions notre configuration :
<pre>
root@GreenArrow:/etc/bind# host www.jjlddelamuerto.space
www.jjlddelamuerto.space has address 193.48.57.162
www.jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8

root@GreenArrow:/etc/bind# host -tany jjlddelamuerto.space
jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8
jjlddelamuerto.space has address 193.48.57.162
jjlddelamuerto.space has SOA record ns.jjlddelamuerto.space. root.jjlddelamuerto.space. 2016113007 604800 86400 2419200 604800
jjlddelamuerto.space name server ns6.gandi.net.
jjlddelamuerto.space name server ns.jjlddelamuerto.space.
</pre>

==== Sécurisation de site web par certificat ====

Premièrement, sur Gandi nous lançons l'étape d'achat d'un certificat SSL.
Puis, sur la VM nous générons le CSR grâce à cette commande:

<pre>
root@GreenArrow:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout GreenArrow.key -out GreenArrow.csr
Generating a 2048 bit RSA private key

If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:jjlddelamuerto.space
Email Address []:
A challenge password []:
An optional company name []:

root@GreenArrow:/etc/apache2/sites-available/clef# ls
GreenArrow.csr GreenArrow.key

root@GreenArrow:/etc/apache2/sites-available/clef# cat GreenArrow.csr

-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----
</pre>

Nous continuons donc la procédure pour obtenir le certificat, et attendons donc sa mise en place.

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

<pre>
root@GreenArrow:~# apt-get install postfix mailx
</pre>

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

<pre>
root@GreenArrow:/etc/bind# cp certificat.crt /etc/ssl/certs/jjlddelamuerto.space.crt
root@GreenArrow:/etc/bind# cp serveur.key /etc/ssl/private/jjlddelamuerto.space.key
root@GreenArrow:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@GreenArrow:/etc/bind# c_rehash /etc/ssl/certs
</pre>

Enfin, la dernière étape consiste en la modification des fichiers 000-jjlddelamuerto.space-ssl.conf et ports.conf :

<pre>
root@GreenArrow:/etc/apache2/sites-available# cat 000-jjlddelamuerto.space-ssl.conf
<VirtualHost *:443>
ServerName www.jjlddelamuerto.space
ServerAlias jjlddelamuerto.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/jjlddelamuerto.space.crt
SSLCertificateKeyFile /etc/ssl/private/jjlddelamuerto.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@GreenArrow:/etc/apache2# cat ports.conf
Listen 80

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls.c>
Listen 443
</IfModule>
</pre>

Un redémarrage du service apache2 est maintenant nécessaire :

<pre>
root@GreenArrow:/etc/apache2# service apache2 stop
root@GreenArrow:/etc/apache2# service apache2 start
root@GreenArrow:/etc/apache2# service apache2 reload
</pre>

Nous pouvons voir que notre site [https://jjlddelamuerto.space] est maintenant sécurisé, un cadenas vert est bien présent.

==== Sécurisation de serveur DNS par DNSSEC ====

Génération des clefs asymétriques:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE jjlddelamuerto.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE jjlddelamuerto.space
</pre>

On modifie le nom des clefs:
<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# ls
dsset-jjlddelamuerto.space. jjlddelamuerto.space-zsk.key
jjlddelamuerto.space-ksk.key jjlddelamuerto.space-zsk.private
jjlddelamuerto.space-ksk.private
</pre>

Ensuite nous signons les zones:

<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# dnssec-signzone -o jjlddelamuerto.space -k jjlddelamuerto.space-ksk
../db.jjlddelamuerto.space jjlddelamuerto.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.jjlddelamuerto.space.signed
</pre>

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

[[Fichier:jjlddnssec.png]]

=== Tests d'intrusion ===

==== Intrusion par changement d'adresse MAC ====

Tout d'abord nous modifions le fichier /etc/network/interfaces:
<pre>
root@zebrasoma:/home/pifou# vim /etc/network/interfaces
auto wlan5
iface wlan5 inet static
address 172.26.79.21
netmask 255.255.240.0
gateway 172.26.79.254
wireless mode-managed
wireless-essid Wolverine
wireless-key 0123456789
</pre>

Nous vérifions ensuite que nous sommes associés à Wolverine:
<pre>
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11abg ESSID:"Wolverine"
Mode:Managed Frequency:2.462 GHz Access Point: 44:AD:D9:5F:87:00
Bit Rate=54 Mb/s Tx-Power=200 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
Link Quality=50/70 Signal level=-60 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
</pre>

Nous changeons ensuite l'@ MAC:
<pre>
root@zebrasoma:/home/pifou# ip link set wlan5 address 00:1a:56:a4:4b:ff
</pre>

<pre>
root@zebrasoma:/home/pifou# ip a
3: wlan5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:1a:56:a4:4b:ff brd ff:ff:ff:ff:ff:ff
inet 172.26.79.21/20 brd 172.26.79.255 scope global wlan5
valid_lft forever preferred_lft forever
</pre>

Après le changement d'@ MAC, l'association est bien impossible:
<pre>
root@zebrasoma:/home/pifou# ifconfig wlan5 up
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11bgn ESSID:"Wolverine"
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
</pre>

==== Crackage de la clef WEP ====

Nous avons fait le crack de la clé WEP sur cracotte08.
Pour cracker la clef WEP, nous avons tout d'abord utiliser airmon-ng afin de voir le statut des interfaces réseau.
<pre>
root@zebrasoma:/home/pifou# airmon-ng

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
</pre>

On entre ensuite en mode monitoring sur l'interface wlan5 :
<pre>
root@zebrasoma:/home/pifou# airmon-ng start wlan5

Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID Name
1986 avahi-daemon
1987 avahi-daemon

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
(monitor mode enabled on mon1)

</pre>

Pour continuer, nous capturons les paquets transitant afin de collecter les paquets nécessaires au décryptage de la clef WEP. L'option --encrypt wep permet de filtrer uniquement les points d'accès WEP.
<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wep wlan5

CH 5 ][ Elapsed: 0 s ][ 2016-03-31 18:36

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -42 3 0 0 3 54e. WEP WEP Wolverine
04:DA:D2:9C:50:50 -59 2 11 0 2 54e. WEP WEP cracotte01
04:DA:D2:9C:50:56 -59 3 19 0 2 54e. WEP WEP cracotte07
04:DA:D2:9C:50:59 -59 2 0 0 2 54e. WEP WEP cracotte10
04:DA:D2:9C:50:57 -59 2 15 0 2 54e. WEP WEP cracotte08
04:DA:D2:9C:50:52 -58 3 85 42 2 54e. WEP WEP cracotte03
04:DA:D2:9C:50:54 -58 1 20 9 2 54e. WEP WEP cracotte05
04:DA:D2:9C:50:55 -60 1 9 4 2 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -59 2 134 66 2 54e. WEP WEP cracotte02
04:DA:D2:9C:50:53 -61 6 95 47 2 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:50 00:0F:B5:92:23:75 -66 54e-48e 68 10
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -72 36e- 2e 133 19
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -66 54e-36e 89 15
04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -62 54e-48e 23 84
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -66 54e-36e 576 20
</pre>

Nous avons choisi de récuperer la clef WEP de cracotte03 (son BSSID est lié à une station)

<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 2 -w crackWEP wlan5

CH 2 ][ Elapsed: 12 s ][ 2016-03-31 18:42

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:52 -57 35 43 1066 87 2 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -64 36e-48e 1232 1067
</pre>

Enfin, nous lançons le crack de la clef à l'aide de aircrack-ng :
<pre>
root@zebrasoma:/home/pifou# aircrack-ng crackWEP-02.cap
Aircrack-ng 1.2 beta3

[00:00:04] Tested 112801 keys (got 3050 IVs)

KB depth byte(vote)
0 6/ 10 CD(5120) 15(4864) 6D(4864) 8C(4864) A7(4864)
1 46/ 1 E9(4352) 04(4096) 0E(4096) 0F(4096) 16(4096)
2 14/ 42 C8(4864) 10(4608) 11(4608) 1D(4608) 58(4608)
3 19/ 3 CF(4864) 0A(4608) 5E(4608) 8E(4608) 90(4608)
4 2/ 16 08(5632) 89(5376) 96(5376) B4(5376) F7(5376)

Failed. Next try with 5000 IVs.
</pre>

Il est nécessaire d'être proche du point d’accès (sinon le débit est trop faible, ce qui rend l'opération longue), ainsi que de capturer un minimum de 10 000 paquets.

Au final, nous arrivons bien à récupérer la clef WEP :
<pre>

Aircrack-ng 1.2 beta3

[00:04:10] Tested 799 keys (got 42913 IVs)

KB depth byte(vote)
0 0/ 1 EE(56320) B4(51712) 9D(50944) 4E(50688) 28(50432)
1 1/ 2 D9(55552) 3D(50176) 68(49664) 08(49408) 49(49152)
2 1/ 5 A2(53504) 5B(52480) 93(52480) 73(52224) 10(50432)
3 1/ 3 30(53248) 81(51456) 5B(49920) 6E(49920) 1E(49664)
4 9/ 4 9D(50176) 31(49408) 18(49152) 72(49152) E1(49152)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44 ]
Decrypted correctly: 100%
</pre>

==== Cassage de mot de passe WPA-PSK par force brute ====
Nous refaisons les mêmes actions que pour le crackage de clef WEP.
Cette fois nous essayons de cracker la clef WPA sur cracotte03.

<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wpa wlan5
</pre>
<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 13 -w crackWPA wlan5
</pre>

Une fois le handshake récupéré:
<pre>
root@zebrasoma:/home/pifou# aircrack-ng -w dico.txt crackWPA-01.cap
</pre>
Nous avons lancé ceci sur le eeePC qui a une vitesse de traitement 5 fois inférieure à celle d'une zabeth environ (environ 5h de traitement). Puis nous obtenons le résultat suivant:
<pre>
Aircrack-ng 1.2 beta3

[04:32:42] 12399908 keys tested (759.63 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 70 EE 27 96 5B 34 B5 4F 06 A1 F2 B6 A7 16 1E 21
7A 0B BD F4 13 67 5B 4C ED 30 A9 0D 91 E3 F9 7F
88 E6 12 68 9C 77 4B 48 EB 5E 6A 5A DD 1D D9 08
36 40 94 7D B4 05 80 B2 60 FA 84 81 50 CE DC 87

EAPOL HMAC : 83 03 24 AC 39 AB 67 E7 7B C4 40 E8 6B 6D 7D 47

</pre>

=== Réalisations ===
==== Sécurisation des données ====

Nous créons d'abord 3 nouvelles partitions, que nous associons à notre VM en modifiant le fichier GreenArrow.cfg :

<pre>
lvcreate -L 1G -n /dev/virtual/GreenArrow-1 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-2 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-3 -v

'phy:/dev/virtual/GreenArrow-1,xvdd,w',
'phy:/dev/virtual/GreenArrow-2,xvde,w',
'phy:/dev/virtual/GreenArrow-3,xvdf,w',
</pre>

Il faut ensuite installer mdadm :

<pre>
apt-get install mdadm
</pre>

Nous créons le volume /dev/md0 qui représente le RAID5 de partitions

<pre>
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
</pre>

Pour avoir le détail de la configuration actuelle:

<pre>
root@GreenArrow:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon oct 13 11:34:23 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Mon oct 13 11:34:23 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : IMA5-BANANE:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 0

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf
</pre>

Puis nous sauvons cette dernière afin de conserver md0:
<pre>
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
</pre>

Puis:
<pre>
mkfs /dev/md0
mkdir /datamd0
mount /dev/md0 /datamd0/
</pre>

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être surs que la partition soit encore montée après le reboot:
<pre>
/dev/md0 /datamd0
</pre>

Nous créons un fichier texte sur le raid5:
<pre>
vim testraid5.txt
</pre>

Nous mettons en commentaire la 2ème partition dans le fichier de conf, puis redémarrons la machine:

<pre>
mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon oct 13 11:34:23 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon oct 13 11:45:01 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : GreenArrow:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 4

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
2 0 0 2 removed
2 202 80 2 active sync /dev/xvdf
</pre>

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

<pre>
ls /datamd0/
testraid5.txt
</pre>

Pour rajouter la partition, on la decommente dans le fichier de configuration et on procede au rajout de cette partition au raid de la facon suivante:

mdadm --add /dev/md0 /dev/xvde

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours:
Suppression de la partition xvdf:
<pre>
root@GreenArrow:~# mdadm --set-faulty /dev/md0 /dev/xvdf
</pre>
<pre>
root@GreenArrow:~# mdadm --remove /dev/md0 /dev/xvdf
</pre>
La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>
On remet la partition:
<pre>
root@GreenArrow:~# mdadm --add /dev/md0 /dev/xvdf
</pre>
On peut ensuite constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:
<pre>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===>.................] recovery = 18.2% (191112/1047552) finish=0.4min speed=31852K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 20.0% (210764/1047552) finish=0.4min speed=30109K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 21.8% (229836/1047552) finish=0.4min speed=32833K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 59.6% (626140/1047552) finish=0.2min speed=29816K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 94.3% (989688/1047552) finish=0.0min speed=30124K/sec

unused devices: <none>
root@GreenArrow:~# [ 446.720069] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
</pre>

==== Cryptage de données ====

Tout d'abord, nous vérifions grâce à Gparted que la carte SD fournie comporte une seule partition.
Une fois ce test passé, nous regardons grâce à dmesg où est localisé la carte SD :

<pre>
root@zebrasoma:/# dmesg
[...]
[1126726.403767] mmcblk1: mmc1:59b4 NCard 14.7 GiB
</pre>

Notre carte SD se situe donc sur /dev/mmcblk1.
Nous faisons donc un chiffrage AES avec un hashage SHA256 de la carte SD :

<pre>
root@zebrasoma:/# cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>

Nous devons alors renseigner un mot de passe pour crypter la clef.
Ensuite, nous ouvrons la partition Luks, puis nous formatons la carte :

<pre>
root@zebrasoma:/# cryptsetup luksOpen /dev/sdb1 crypt_sd
root@zebrasoma:/# mkfs.ext4 /dev/mapper/crypt_sd
</pre>

Nous montons la partition, puis créons un fichier sur la carte :
<pre>
root@zebrasoma:/# mount /dev/mapper/crypt_sd /mnt
root@zebrasoma:/# vi /mnt/test.txt #on marque un texte dans le fichier
</pre>

Enfin, nous démontons la carte SD et fermons la partition Luks :
<pre>
root@zebrasoma:/# umount /mnt
root@zebrasoma:/# cryptsetup luksClose crypt_sd
</pre>

Nous essayons ensuite d'accéder à la carte SD. En renseignant un mauvais mot de passe, une erreur apparaît.
Cependant, une fois le bon mot de passe renseigné, tout re-devient possible.

==== Sécurisation Wifi par WPA2-EAP ====
Tout d'abord, nous installons FreeRadius sur notre machine virtuelle. 
Dans le fichier '''users''', nous renseignons le login et le mot de passe pour se connecter à la borne Wifi : 
<pre>
GreenArrow Cleartext-Password:="glopglop"
</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne E306 et E304 : 
<pre>
client E306 {
ipaddr = 10.60.1.2
secret = password
}
client E304 {
ipaddr = 10.60.1.4
secret = password
}
</pre>

Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''', puis nous rentrons en mode configuration : 
<pre>
aaa authentication login eap_greenarrow group radius_greenarrow
radius-server host 193.48.57.162 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_greenarrow
server 193.48.57.162 auth-port 1812 acct-port 1813

dot11 ssid SSID_GREENARROW
vlan 3
authentication open eap eap_greenarrow
authentication network-eap eap_greenarrow
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 3 mode ciphers aes-ccm tkip
ssid SSID_GREENARROW

interface Dot11Radio0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
bridge-group 3 subscriber-loop-control
bridge-group 3 spanning-disabled
bridge-group 3 block-unknown-source
no bridge-group 3 source-learning
no bridge-group 3 unicast-flooding

interface GigabitEthernet0.3
encapsulation dot1Q 3
bridge-group 3
</pre>

Une fois ces modifications effectuées, nous configurons l'interface wlan0 de l'eeePC pour pouvoir se connecter au Wifi à l'aide de '''ifup wlan0''' :

<pre>
auto wlan0
iface wlan0 inet static
address 10.60.3.2
netmask 255.255.255.0
gateway 10.60.3.1
wpa-ssid SSID_GREENARROW
wpa-key-mgmt WPA-EAP
wpa-identity GreenArrow
wpa-password glopglop
</pre>

On lance le serveur FreeRadius via freeradius -X (mode debug).
Sur smartphone, nous arrivons à détecter notre SSID (SSID_GREENARROW). Nous pouvons également ping notre eeePC depuis la machine virtuelle, tout comme nous arrivons à pinger des Vm d'autres groupes depuis notre eeePC. 
<pre>
root@GreenArrow:/etc/freeradius# ping 10.60.3.2
PING 10.60.3.2 (10.60.3.2) 56(84) bytes of data.
64 bytes from 10.60.3.2: icmp_seq=1 ttl=255 time=1.30 ms
64 bytes from 10.60.3.2: icmp_seq=2 ttl=255 time=1.96 ms
</pre>

==== Serveur DCHP ====

Pour cette partie, nous avons d'abord installer le paquet isc-dhcp-server.
Ensuite, nous avons modifier le fichier dhcpd.conf :
<pre>
option domain-name "jjlddelamuerto.space";
option domain-name-servers 193.48.57.162;

subnet 10.60.3.0 netmask 255.255.255.0 {
range 10.60.3.10 10.60.3.40;
option routers 10.60.3.1;
}
</pre>

Nous modifions ensuite isc-dhcp-server pour rajouter l'interface wlan0 :
<pre>
INTERFACES="wlan0"
</pre>

Nous pouvons maintenant nous connecter sur le reseau Wifi via smartphone, le serveur DHCP fonctionne correctement.
[[Fichier:Connexioniphone.JPG|thumb|center|Connexion via smartphone]]

==== Configuration et utilisation du PCBX ====

Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=JulienJoignaux
username=jjoignaux
secret=secret
context=work

[6002]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=LoicDelecroix
username=ldelecro
secret=secret
context=work</pre>
 

Puis nous modifions le fichier extensions.conf
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

[[Fichier:voipjjld.jpg|thumb|center|Appel entre 2 smartphones]]

== Références ==

* Crackage de la clef WEP : [http://wiki.backtrack-fr.net/index.php/Casser_une_cl%C3%A9_wep/wpa_avec_la_suite_Aircrack-ng]
* Cassage de mot de passe WPA-PSK : [http://www.crack-wifi.com/tutoriel-crack-wpa.php]
* Cryptage de données : [https://doc.ubuntu-fr.org/cryptsetup]
* DHCP : [https://doc.ubuntu-fr.org/isc-dhcp-server]
* Asterisk : [http://denisrosenkranz.com/tuto-installer-et-configurer-asterisk-sous-debian-6-et-ubuntu/]

Cahier 2016 groupe n°2

2017-11-17T13:54:52Z

Hdelatte : /* Sécurisation des données */

== Tâche particulière ==

Câblage de la fibre:
 
Prise de connaissance du sujet de PRA et le choix des tâches particulières. Nous avons également commencer à essayer d'identifier les câbles de fibres déjà existants.
 
Toujours sur la tâche particulière. Identification de tous les câbles déjà tirés. Test de link de chaque câble. Nous avons également commencé à passer les câbles restants.
Tous les câbles nécessaires ont été tirés entre les deux salles, tous les link sont up. Nous avons identifié chaque câble par un scotch de couleur différente. Nous avons également percé la gouttière de la E304 pour laisser passer un raccord de fibre proprement.
 

* Nous avons pu identifier les câbles déjà présents. Il y a donc 2 câbles déjà tirés entre les 2 piles, 2 câbles qui partent de la E306 jusqu'au boîtier ainsi qu'un câble par salle quid descend dans le local technique.
* Nous allons donc prolonger les 2 câbles s'arrêtant dans le boîtier et tirer 2 nouveaux câbles entre les deux piles: nous aurons donc 6 fils au total.
* 2 Grands câbles de 30m ~ -> Estimation de 26m entre les 2 piles.
* 2 petits câbles de 15m ~ -> Estimation de 13m du boîtier à la pile
* Retirer le câble ethernet qui était tiré entre les 2 piles.
* 7 heures passées au total sur la tâche particulière
[[Fichier:im1.JPG|300px|thumb|left|Fibre passant entre les 2 salles]]
[[Fichier:im2.JPG|300px|thumb|right|Câbles dans le faux plafond]]
[[Fichier:im4.JPG|300px|thumb|left|Guide câbles pour le faux plafond]]
[[Fichier:im5.JPG|300px|thumb|right|Boîtiers contenant les raccords de fibres]]
[[Fichier:im6.JPG|300px|thumb|left|Les fibres en E304 disponibles]]
[[Fichier:im7.JPG|300px|thumb|right|Trou dans le cache laissant passer la fibre]] 

== Travail commun ==

* Installation de la machine virtuelle XEN

<pre>
xen-create-image --hostname=GreenArrow --ip=193.48.57.162 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Modification du fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:
<pre>
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-home -v
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-var -v
</pre>

<pre>
disk = [
'file:/usr/local/xen/domains/GreenArrow/disk.img,xvda2,w',
'file:/usr/local/xen/domains/GreenArrow/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-GreenArrow-home,xvdc,w',
'phy:/dev/virtual/ima5-GreenArrow-var,xvdb,w',
]
</pre>

Commandes de base pour démarrer la VM proprement:
<pre>
ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/GreenArrow.cfg
ssh username@weppes
ssh root@193.48.57.162
</pre>

* Achat du nom de domaine [http://jjlddelamuerto.space] sur Gandi pour 1.19€ TTC

=== Services Internet ===

==== Serveur SSH ====

Sur notre machine virtuelle nous avons configuré le fichier sshd_config (changement de la ligne PubkeyAuthentication) :
<pre>
root@GreenArrow:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

root@GreenArrow:~# service ssh restart
</pre>

Nous avons ensuite réussi à nous connecter en SSH sur notre VM:
<pre>
jjoignau@weppes:~$ ssh root@193.48.57.162
root@193.48.57.162's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 7 10:06:49 2016
root@GreenArrow:~# exit
</pre>

==== Serveur DNS ====

Tout d'abord, nous modifions le fichier '''named.conf.local''' pour créer les zones nécessaires :

<pre>
root@GreenArrow:/etc/bind# vim /etc/bind/named.conf.local
zone "jjlddelamuerto.space" IN {
type master;
file "/etc/bind/db.jjlddelamuerto.space";
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/db.57.48.193.in-addr.arpa";
};
</pre>

Nous créons ensuite les fichiers '''db.jjlddelamuerto.space''' et '''db.57.48.193.in-addr.arpa''' :
<pre>
$TTL 604800
@ IN SOA ns.jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.jjlddelamuerto.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162
ns IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
www IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
@ IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
</pre>
<pre>
$TTL 604800
@ IN SOA jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
57.48.193.in-addr.arpa. IN NS ns.jjlddelamuerto.space.
57.48.193.in-addr.arpa. IN NS ns2.gandi.net.

162 IN PTR jjlddelamuerto.space.
</pre>

Nous modifions ensuite le fichier /etc/resolv.conf afin de passer par notre serveur :
<pre>
root@GreenArrow:/etc/bind# vim /etc/resolv.conf
search jjlddelamuerto.space
nameserver 193.48.57.162
</pre>

Enfin, nous vérifions notre configuration :
<pre>
root@GreenArrow:/etc/bind# host www.jjlddelamuerto.space
www.jjlddelamuerto.space has address 193.48.57.162
www.jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8

root@GreenArrow:/etc/bind# host -tany jjlddelamuerto.space
jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8
jjlddelamuerto.space has address 193.48.57.162
jjlddelamuerto.space has SOA record ns.jjlddelamuerto.space. root.jjlddelamuerto.space. 2016113007 604800 86400 2419200 604800
jjlddelamuerto.space name server ns6.gandi.net.
jjlddelamuerto.space name server ns.jjlddelamuerto.space.
</pre>

==== Sécurisation de site web par certificat ====

Premièrement, sur Gandi nous lançons l'étape d'achat d'un certificat SSL.
Puis, sur la VM nous générons le CSR grâce à cette commande:

<pre>
root@GreenArrow:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout GreenArrow.key -out GreenArrow.csr
Generating a 2048 bit RSA private key

If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:jjlddelamuerto.space
Email Address []:
A challenge password []:
An optional company name []:

root@GreenArrow:/etc/apache2/sites-available/clef# ls
GreenArrow.csr GreenArrow.key

root@GreenArrow:/etc/apache2/sites-available/clef# cat GreenArrow.csr

-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----
</pre>

Nous continuons donc la procédure pour obtenir le certificat, et attendons donc sa mise en place.

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

<pre>
root@GreenArrow:~# apt-get install postfix mailx
</pre>

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

<pre>
root@GreenArrow:/etc/bind# cp certificat.crt /etc/ssl/certs/jjlddelamuerto.space.crt
root@GreenArrow:/etc/bind# cp serveur.key /etc/ssl/private/jjlddelamuerto.space.key
root@GreenArrow:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@GreenArrow:/etc/bind# c_rehash /etc/ssl/certs
</pre>

Enfin, la dernière étape consiste en la modification des fichiers 000-jjlddelamuerto.space-ssl.conf et ports.conf :

<pre>
root@GreenArrow:/etc/apache2/sites-available# cat 000-jjlddelamuerto.space-ssl.conf
<VirtualHost *:443>
ServerName www.jjlddelamuerto.space
ServerAlias jjlddelamuerto.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/jjlddelamuerto.space.crt
SSLCertificateKeyFile /etc/ssl/private/jjlddelamuerto.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@GreenArrow:/etc/apache2# cat ports.conf
Listen 80

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls.c>
Listen 443
</IfModule>
</pre>

Un redémarrage du service apache2 est maintenant nécessaire :

<pre>
root@GreenArrow:/etc/apache2# service apache2 stop
root@GreenArrow:/etc/apache2# service apache2 start
root@GreenArrow:/etc/apache2# service apache2 reload
</pre>

Nous pouvons voir que notre site [https://jjlddelamuerto.space] est maintenant sécurisé, un cadenas vert est bien présent.

==== Sécurisation de serveur DNS par DNSSEC ====

Génération des clefs asymétriques:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE jjlddelamuerto.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE jjlddelamuerto.space
</pre>

On modifie le nom des clefs:
<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# ls
dsset-jjlddelamuerto.space. jjlddelamuerto.space-zsk.key
jjlddelamuerto.space-ksk.key jjlddelamuerto.space-zsk.private
jjlddelamuerto.space-ksk.private
</pre>

Ensuite nous signons les zones:

<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# dnssec-signzone -o jjlddelamuerto.space -k jjlddelamuerto.space-ksk
../db.jjlddelamuerto.space jjlddelamuerto.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.jjlddelamuerto.space.signed
</pre>

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

[[Fichier:jjlddnssec.png]]

=== Tests d'intrusion ===

==== Intrusion par changement d'adresse MAC ====

Tout d'abord nous modifions le fichier /etc/network/interfaces:
<pre>
root@zebrasoma:/home/pifou# vim /etc/network/interfaces
auto wlan5
iface wlan5 inet static
address 172.26.79.21
netmask 255.255.240.0
gateway 172.26.79.254
wireless mode-managed
wireless-essid Wolverine
wireless-key 0123456789
</pre>

Nous vérifions ensuite que nous sommes associés à Wolverine:
<pre>
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11abg ESSID:"Wolverine"
Mode:Managed Frequency:2.462 GHz Access Point: 44:AD:D9:5F:87:00
Bit Rate=54 Mb/s Tx-Power=200 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
Link Quality=50/70 Signal level=-60 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
</pre>

Nous changeons ensuite l'@ MAC:
<pre>
root@zebrasoma:/home/pifou# ip link set wlan5 address 00:1a:56:a4:4b:ff
</pre>

<pre>
root@zebrasoma:/home/pifou# ip a
3: wlan5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:1a:56:a4:4b:ff brd ff:ff:ff:ff:ff:ff
inet 172.26.79.21/20 brd 172.26.79.255 scope global wlan5
valid_lft forever preferred_lft forever
</pre>

Après le changement d'@ MAC, l'association est bien impossible:
<pre>
root@zebrasoma:/home/pifou# ifconfig wlan5 up
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11bgn ESSID:"Wolverine"
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
</pre>

==== Crackage de la clef WEP ====

Nous avons fait le crack de la clé WEP sur cracotte08.
Pour cracker la clef WEP, nous avons tout d'abord utiliser airmon-ng afin de voir le statut des interfaces réseau.
<pre>
root@zebrasoma:/home/pifou# airmon-ng

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
</pre>

On entre ensuite en mode monitoring sur l'interface wlan5 :
<pre>
root@zebrasoma:/home/pifou# airmon-ng start wlan5

Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID Name
1986 avahi-daemon
1987 avahi-daemon

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
(monitor mode enabled on mon1)

</pre>

Pour continuer, nous capturons les paquets transitant afin de collecter les paquets nécessaires au décryptage de la clef WEP. L'option --encrypt wep permet de filtrer uniquement les points d'accès WEP.
<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wep wlan5

CH 5 ][ Elapsed: 0 s ][ 2016-03-31 18:36

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -42 3 0 0 3 54e. WEP WEP Wolverine
04:DA:D2:9C:50:50 -59 2 11 0 2 54e. WEP WEP cracotte01
04:DA:D2:9C:50:56 -59 3 19 0 2 54e. WEP WEP cracotte07
04:DA:D2:9C:50:59 -59 2 0 0 2 54e. WEP WEP cracotte10
04:DA:D2:9C:50:57 -59 2 15 0 2 54e. WEP WEP cracotte08
04:DA:D2:9C:50:52 -58 3 85 42 2 54e. WEP WEP cracotte03
04:DA:D2:9C:50:54 -58 1 20 9 2 54e. WEP WEP cracotte05
04:DA:D2:9C:50:55 -60 1 9 4 2 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -59 2 134 66 2 54e. WEP WEP cracotte02
04:DA:D2:9C:50:53 -61 6 95 47 2 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:50 00:0F:B5:92:23:75 -66 54e-48e 68 10
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -72 36e- 2e 133 19
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -66 54e-36e 89 15
04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -62 54e-48e 23 84
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -66 54e-36e 576 20
</pre>

Nous avons choisi de récuperer la clef WEP de cracotte03 (son BSSID est lié à une station)

<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 2 -w crackWEP wlan5

CH 2 ][ Elapsed: 12 s ][ 2016-03-31 18:42

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:52 -57 35 43 1066 87 2 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -64 36e-48e 1232 1067
</pre>

Enfin, nous lançons le crack de la clef à l'aide de aircrack-ng :
<pre>
root@zebrasoma:/home/pifou# aircrack-ng crackWEP-02.cap
Aircrack-ng 1.2 beta3

[00:00:04] Tested 112801 keys (got 3050 IVs)

KB depth byte(vote)
0 6/ 10 CD(5120) 15(4864) 6D(4864) 8C(4864) A7(4864)
1 46/ 1 E9(4352) 04(4096) 0E(4096) 0F(4096) 16(4096)
2 14/ 42 C8(4864) 10(4608) 11(4608) 1D(4608) 58(4608)
3 19/ 3 CF(4864) 0A(4608) 5E(4608) 8E(4608) 90(4608)
4 2/ 16 08(5632) 89(5376) 96(5376) B4(5376) F7(5376)

Failed. Next try with 5000 IVs.
</pre>

Il est nécessaire d'être proche du point d’accès (sinon le débit est trop faible, ce qui rend l'opération longue), ainsi que de capturer un minimum de 10 000 paquets.

Au final, nous arrivons bien à récupérer la clef WEP :
<pre>

Aircrack-ng 1.2 beta3

[00:04:10] Tested 799 keys (got 42913 IVs)

KB depth byte(vote)
0 0/ 1 EE(56320) B4(51712) 9D(50944) 4E(50688) 28(50432)
1 1/ 2 D9(55552) 3D(50176) 68(49664) 08(49408) 49(49152)
2 1/ 5 A2(53504) 5B(52480) 93(52480) 73(52224) 10(50432)
3 1/ 3 30(53248) 81(51456) 5B(49920) 6E(49920) 1E(49664)
4 9/ 4 9D(50176) 31(49408) 18(49152) 72(49152) E1(49152)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44 ]
Decrypted correctly: 100%
</pre>

==== Cassage de mot de passe WPA-PSK par force brute ====
Nous refaisons les mêmes actions que pour le crackage de clef WEP.
Cette fois nous essayons de cracker la clef WPA sur cracotte03.

<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wpa wlan5
</pre>
<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 13 -w crackWPA wlan5
</pre>

Une fois le handshake récupéré:
<pre>
root@zebrasoma:/home/pifou# aircrack-ng -w dico.txt crackWPA-01.cap
</pre>
Nous avons lancé ceci sur le eeePC qui a une vitesse de traitement 5 fois inférieure à celle d'une zabeth environ (environ 5h de traitement). Puis nous obtenons le résultat suivant:
<pre>
Aircrack-ng 1.2 beta3

[04:32:42] 12399908 keys tested (759.63 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 70 EE 27 96 5B 34 B5 4F 06 A1 F2 B6 A7 16 1E 21
7A 0B BD F4 13 67 5B 4C ED 30 A9 0D 91 E3 F9 7F
88 E6 12 68 9C 77 4B 48 EB 5E 6A 5A DD 1D D9 08
36 40 94 7D B4 05 80 B2 60 FA 84 81 50 CE DC 87

EAPOL HMAC : 83 03 24 AC 39 AB 67 E7 7B C4 40 E8 6B 6D 7D 47

</pre>

=== Réalisations ===
==== Sécurisation des données ====

Nous créons d'abord 3 nouvelles partitions, que nous associons à notre VM en modifiant le fichier GreenArrow.cfg :

<pre>
lvcreate -L 1G -n /dev/virtual/GreenArrow-1 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-2 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-3 -v

'phy:/dev/virtual/GreenArrow-1,xvdd,w',
'phy:/dev/virtual/GreenArrow-2,xvde,w',
'phy:/dev/virtual/GreenArrow-3,xvdf,w',
</pre>

Il faut ensuite installer mdadm :

<pre>
apt-get install mdadm
</pre>

Nous créons le volume /dev/md0 qui représente le RAID5 de partitions

<pre>
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
</pre>

Pour avoir le détail de la configuration actuelle:

<pre>
root@GreenArrow:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon oct 13 11:34:23 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Mon oct 13 11:34:23 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : IMA5-BANANE:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 0

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf
</pre>

Puis nous sauvons cette dernière afin de conserver md0:
<pre>
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
</pre>

Puis:
<pre>
mkfs /dev/md0
mkdir /datamd0
mount /dev/md0 /datamd0/
</pre>

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être surs que la partition soit encore montée après le reboot:
<pre>
/dev/md0 /datamd0
</pre>

Nous créons un fichier texte sur le raid5:
<pre>
vim testraid5.txt
</pre>

Nous mettons en commentaire la 2ème partition dans le fichier de conf, puis redémarrons la machine:

<pre>
mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon oct 13 11:34:23 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon oct 13 11:45:01 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : GreenArrow:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 4

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
2 0 0 2 removed
2 202 80 2 active sync /dev/xvdf
</pre>

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

<pre>
ls /datamd0/
testraid5.txt
</pre>

Pour rajouter la partition, on la decommente dans le fichier de configuration et on procede au rajout de cette partition au raid de la facon suivante:

mdadm --add /dev/md0 /dev/xvde

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours:
Suppression de la partition xvdf:
<pre>
root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdf
</pre>
<pre>
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdf
</pre>
La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>
On remet la partition:
<pre>
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdf
</pre>
On peut ensuite constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:
<pre>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===>.................] recovery = 18.2% (191112/1047552) finish=0.4min speed=31852K/sec

unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 20.0% (210764/1047552) finish=0.4min speed=30109K/sec

unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 21.8% (229836/1047552) finish=0.4min speed=32833K/sec

unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 59.6% (626140/1047552) finish=0.2min speed=29816K/sec

unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 94.3% (989688/1047552) finish=0.0min speed=30124K/sec

unused devices: <none>
root@IMA5-BANANE:~# [ 446.720069] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
</pre>

==== Cryptage de données ====

Tout d'abord, nous vérifions grâce à Gparted que la carte SD fournie comporte une seule partition.
Une fois ce test passé, nous regardons grâce à dmesg où est localisé la carte SD :

<pre>
root@zebrasoma:/# dmesg
[...]
[1126726.403767] mmcblk1: mmc1:59b4 NCard 14.7 GiB
</pre>

Notre carte SD se situe donc sur /dev/mmcblk1.
Nous faisons donc un chiffrage AES avec un hashage SHA256 de la carte SD :

<pre>
root@zebrasoma:/# cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>

Nous devons alors renseigner un mot de passe pour crypter la clef.
Ensuite, nous ouvrons la partition Luks, puis nous formatons la carte :

<pre>
root@zebrasoma:/# cryptsetup luksOpen /dev/sdb1 crypt_sd
root@zebrasoma:/# mkfs.ext4 /dev/mapper/crypt_sd
</pre>

Nous montons la partition, puis créons un fichier sur la carte :
<pre>
root@zebrasoma:/# mount /dev/mapper/crypt_sd /mnt
root@zebrasoma:/# vi /mnt/test.txt #on marque un texte dans le fichier
</pre>

Enfin, nous démontons la carte SD et fermons la partition Luks :
<pre>
root@zebrasoma:/# umount /mnt
root@zebrasoma:/# cryptsetup luksClose crypt_sd
</pre>

Nous essayons ensuite d'accéder à la carte SD. En renseignant un mauvais mot de passe, une erreur apparaît.
Cependant, une fois le bon mot de passe renseigné, tout re-devient possible.

==== Sécurisation Wifi par WPA2-EAP ====
Tout d'abord, nous installons FreeRadius sur notre machine virtuelle. 
Dans le fichier '''users''', nous renseignons le login et le mot de passe pour se connecter à la borne Wifi : 
<pre>
GreenArrow Cleartext-Password:="glopglop"
</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne E306 et E304 : 
<pre>
client E306 {
ipaddr = 10.60.1.2
secret = password
}
client E304 {
ipaddr = 10.60.1.4
secret = password
}
</pre>

Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''', puis nous rentrons en mode configuration : 
<pre>
aaa authentication login eap_greenarrow group radius_greenarrow
radius-server host 193.48.57.162 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_greenarrow
server 193.48.57.162 auth-port 1812 acct-port 1813

dot11 ssid SSID_GREENARROW
vlan 3
authentication open eap eap_greenarrow
authentication network-eap eap_greenarrow
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 3 mode ciphers aes-ccm tkip
ssid SSID_GREENARROW

interface Dot11Radio0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
bridge-group 3 subscriber-loop-control
bridge-group 3 spanning-disabled
bridge-group 3 block-unknown-source
no bridge-group 3 source-learning
no bridge-group 3 unicast-flooding

interface GigabitEthernet0.3
encapsulation dot1Q 3
bridge-group 3
</pre>

Une fois ces modifications effectuées, nous configurons l'interface wlan0 de l'eeePC pour pouvoir se connecter au Wifi à l'aide de '''ifup wlan0''' :

<pre>
auto wlan0
iface wlan0 inet static
address 10.60.3.2
netmask 255.255.255.0
gateway 10.60.3.1
wpa-ssid SSID_GREENARROW
wpa-key-mgmt WPA-EAP
wpa-identity GreenArrow
wpa-password glopglop
</pre>

On lance le serveur FreeRadius via freeradius -X (mode debug).
Sur smartphone, nous arrivons à détecter notre SSID (SSID_GREENARROW). Nous pouvons également ping notre eeePC depuis la machine virtuelle, tout comme nous arrivons à pinger des Vm d'autres groupes depuis notre eeePC. 
<pre>
root@GreenArrow:/etc/freeradius# ping 10.60.3.2
PING 10.60.3.2 (10.60.3.2) 56(84) bytes of data.
64 bytes from 10.60.3.2: icmp_seq=1 ttl=255 time=1.30 ms
64 bytes from 10.60.3.2: icmp_seq=2 ttl=255 time=1.96 ms
</pre>

==== Serveur DCHP ====

Pour cette partie, nous avons d'abord installer le paquet isc-dhcp-server.
Ensuite, nous avons modifier le fichier dhcpd.conf :
<pre>
option domain-name "jjlddelamuerto.space";
option domain-name-servers 193.48.57.162;

subnet 10.60.3.0 netmask 255.255.255.0 {
range 10.60.3.10 10.60.3.40;
option routers 10.60.3.1;
}
</pre>

Nous modifions ensuite isc-dhcp-server pour rajouter l'interface wlan0 :
<pre>
INTERFACES="wlan0"
</pre>

Nous pouvons maintenant nous connecter sur le reseau Wifi via smartphone, le serveur DHCP fonctionne correctement.
[[Fichier:Connexioniphone.JPG|thumb|center|Connexion via smartphone]]

==== Configuration et utilisation du PCBX ====

Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=JulienJoignaux
username=jjoignaux
secret=secret
context=work

[6002]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=LoicDelecroix
username=ldelecro
secret=secret
context=work</pre>
 

Puis nous modifions le fichier extensions.conf
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

[[Fichier:voipjjld.jpg|thumb|center|Appel entre 2 smartphones]]

== Références ==

* Crackage de la clef WEP : [http://wiki.backtrack-fr.net/index.php/Casser_une_cl%C3%A9_wep/wpa_avec_la_suite_Aircrack-ng]
* Cassage de mot de passe WPA-PSK : [http://www.crack-wifi.com/tutoriel-crack-wpa.php]
* Cryptage de données : [https://doc.ubuntu-fr.org/cryptsetup]
* DHCP : [https://doc.ubuntu-fr.org/isc-dhcp-server]
* Asterisk : [http://denisrosenkranz.com/tuto-installer-et-configurer-asterisk-sous-debian-6-et-ubuntu/]

Cahier 2016 groupe n°2

2017-11-17T13:52:22Z

Hdelatte : /* Sécurisation des données */

== Tâche particulière ==

Câblage de la fibre:
 
Prise de connaissance du sujet de PRA et le choix des tâches particulières. Nous avons également commencer à essayer d'identifier les câbles de fibres déjà existants.
 
Toujours sur la tâche particulière. Identification de tous les câbles déjà tirés. Test de link de chaque câble. Nous avons également commencé à passer les câbles restants.
Tous les câbles nécessaires ont été tirés entre les deux salles, tous les link sont up. Nous avons identifié chaque câble par un scotch de couleur différente. Nous avons également percé la gouttière de la E304 pour laisser passer un raccord de fibre proprement.
 

* Nous avons pu identifier les câbles déjà présents. Il y a donc 2 câbles déjà tirés entre les 2 piles, 2 câbles qui partent de la E306 jusqu'au boîtier ainsi qu'un câble par salle quid descend dans le local technique.
* Nous allons donc prolonger les 2 câbles s'arrêtant dans le boîtier et tirer 2 nouveaux câbles entre les deux piles: nous aurons donc 6 fils au total.
* 2 Grands câbles de 30m ~ -> Estimation de 26m entre les 2 piles.
* 2 petits câbles de 15m ~ -> Estimation de 13m du boîtier à la pile
* Retirer le câble ethernet qui était tiré entre les 2 piles.
* 7 heures passées au total sur la tâche particulière
[[Fichier:im1.JPG|300px|thumb|left|Fibre passant entre les 2 salles]]
[[Fichier:im2.JPG|300px|thumb|right|Câbles dans le faux plafond]]
[[Fichier:im4.JPG|300px|thumb|left|Guide câbles pour le faux plafond]]
[[Fichier:im5.JPG|300px|thumb|right|Boîtiers contenant les raccords de fibres]]
[[Fichier:im6.JPG|300px|thumb|left|Les fibres en E304 disponibles]]
[[Fichier:im7.JPG|300px|thumb|right|Trou dans le cache laissant passer la fibre]] 

== Travail commun ==

* Installation de la machine virtuelle XEN

<pre>
xen-create-image --hostname=GreenArrow --ip=193.48.57.162 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Modification du fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:
<pre>
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-home -v
lvcreate -L 10G -n /dev/virtual/ima5-GreenArrow-var -v
</pre>

<pre>
disk = [
'file:/usr/local/xen/domains/GreenArrow/disk.img,xvda2,w',
'file:/usr/local/xen/domains/GreenArrow/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-GreenArrow-home,xvdc,w',
'phy:/dev/virtual/ima5-GreenArrow-var,xvdb,w',
]
</pre>

Commandes de base pour démarrer la VM proprement:
<pre>
ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/GreenArrow.cfg
ssh username@weppes
ssh root@193.48.57.162
</pre>

* Achat du nom de domaine [http://jjlddelamuerto.space] sur Gandi pour 1.19€ TTC

=== Services Internet ===

==== Serveur SSH ====

Sur notre machine virtuelle nous avons configuré le fichier sshd_config (changement de la ligne PubkeyAuthentication) :
<pre>
root@GreenArrow:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

root@GreenArrow:~# service ssh restart
</pre>

Nous avons ensuite réussi à nous connecter en SSH sur notre VM:
<pre>
jjoignau@weppes:~$ ssh root@193.48.57.162
root@193.48.57.162's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 7 10:06:49 2016
root@GreenArrow:~# exit
</pre>

==== Serveur DNS ====

Tout d'abord, nous modifions le fichier '''named.conf.local''' pour créer les zones nécessaires :

<pre>
root@GreenArrow:/etc/bind# vim /etc/bind/named.conf.local
zone "jjlddelamuerto.space" IN {
type master;
file "/etc/bind/db.jjlddelamuerto.space";
};

zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/db.57.48.193.in-addr.arpa";
};
</pre>

Nous créons ensuite les fichiers '''db.jjlddelamuerto.space''' et '''db.57.48.193.in-addr.arpa''' :
<pre>
$TTL 604800
@ IN SOA ns.jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.jjlddelamuerto.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162
ns IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
www IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
@ IN AAAA 2001:660:4401:60ba:216:3eff:fe80:efa8
</pre>
<pre>
$TTL 604800
@ IN SOA jjlddelamuerto.space. root.jjlddelamuerto.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
57.48.193.in-addr.arpa. IN NS ns.jjlddelamuerto.space.
57.48.193.in-addr.arpa. IN NS ns2.gandi.net.

162 IN PTR jjlddelamuerto.space.
</pre>

Nous modifions ensuite le fichier /etc/resolv.conf afin de passer par notre serveur :
<pre>
root@GreenArrow:/etc/bind# vim /etc/resolv.conf
search jjlddelamuerto.space
nameserver 193.48.57.162
</pre>

Enfin, nous vérifions notre configuration :
<pre>
root@GreenArrow:/etc/bind# host www.jjlddelamuerto.space
www.jjlddelamuerto.space has address 193.48.57.162
www.jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8

root@GreenArrow:/etc/bind# host -tany jjlddelamuerto.space
jjlddelamuerto.space has IPv6 address 2001:660:4401:60ba:216:3eff:fe80:efa8
jjlddelamuerto.space has address 193.48.57.162
jjlddelamuerto.space has SOA record ns.jjlddelamuerto.space. root.jjlddelamuerto.space. 2016113007 604800 86400 2419200 604800
jjlddelamuerto.space name server ns6.gandi.net.
jjlddelamuerto.space name server ns.jjlddelamuerto.space.
</pre>

==== Sécurisation de site web par certificat ====

Premièrement, sur Gandi nous lançons l'étape d'achat d'un certificat SSL.
Puis, sur la VM nous générons le CSR grâce à cette commande:

<pre>
root@GreenArrow:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout GreenArrow.key -out GreenArrow.csr
Generating a 2048 bit RSA private key

If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:jjlddelamuerto.space
Email Address []:
A challenge password []:
An optional company name []:

root@GreenArrow:/etc/apache2/sites-available/clef# ls
GreenArrow.csr GreenArrow.key

root@GreenArrow:/etc/apache2/sites-available/clef# cat GreenArrow.csr

-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----
</pre>

Nous continuons donc la procédure pour obtenir le certificat, et attendons donc sa mise en place.

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

<pre>
root@GreenArrow:~# apt-get install postfix mailx
</pre>

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

<pre>
root@GreenArrow:/etc/bind# cp certificat.crt /etc/ssl/certs/jjlddelamuerto.space.crt
root@GreenArrow:/etc/bind# cp serveur.key /etc/ssl/private/jjlddelamuerto.space.key
root@GreenArrow:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@GreenArrow:/etc/bind# c_rehash /etc/ssl/certs
</pre>

Enfin, la dernière étape consiste en la modification des fichiers 000-jjlddelamuerto.space-ssl.conf et ports.conf :

<pre>
root@GreenArrow:/etc/apache2/sites-available# cat 000-jjlddelamuerto.space-ssl.conf
<VirtualHost *:443>
ServerName www.jjlddelamuerto.space
ServerAlias jjlddelamuerto.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/jjlddelamuerto.space.crt
SSLCertificateKeyFile /etc/ssl/private/jjlddelamuerto.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@GreenArrow:/etc/apache2# cat ports.conf
Listen 80

<IfModule ssl_module>
Listen 443
</IfModule>

<IfModule mod_gnutls.c>
Listen 443
</IfModule>
</pre>

Un redémarrage du service apache2 est maintenant nécessaire :

<pre>
root@GreenArrow:/etc/apache2# service apache2 stop
root@GreenArrow:/etc/apache2# service apache2 start
root@GreenArrow:/etc/apache2# service apache2 reload
</pre>

Nous pouvons voir que notre site [https://jjlddelamuerto.space] est maintenant sécurisé, un cadenas vert est bien présent.

==== Sécurisation de serveur DNS par DNSSEC ====

Génération des clefs asymétriques:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE jjlddelamuerto.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE jjlddelamuerto.space
</pre>

On modifie le nom des clefs:
<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# ls
dsset-jjlddelamuerto.space. jjlddelamuerto.space-zsk.key
jjlddelamuerto.space-ksk.key jjlddelamuerto.space-zsk.private
jjlddelamuerto.space-ksk.private
</pre>

Ensuite nous signons les zones:

<pre>
root@GreenArrow:/etc/bind/jjlddelamuerto.space.dnssec# dnssec-signzone -o jjlddelamuerto.space -k jjlddelamuerto.space-ksk
../db.jjlddelamuerto.space jjlddelamuerto.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.jjlddelamuerto.space.signed
</pre>

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

[[Fichier:jjlddnssec.png]]

=== Tests d'intrusion ===

==== Intrusion par changement d'adresse MAC ====

Tout d'abord nous modifions le fichier /etc/network/interfaces:
<pre>
root@zebrasoma:/home/pifou# vim /etc/network/interfaces
auto wlan5
iface wlan5 inet static
address 172.26.79.21
netmask 255.255.240.0
gateway 172.26.79.254
wireless mode-managed
wireless-essid Wolverine
wireless-key 0123456789
</pre>

Nous vérifions ensuite que nous sommes associés à Wolverine:
<pre>
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11abg ESSID:"Wolverine"
Mode:Managed Frequency:2.462 GHz Access Point: 44:AD:D9:5F:87:00
Bit Rate=54 Mb/s Tx-Power=200 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
Link Quality=50/70 Signal level=-60 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
</pre>

Nous changeons ensuite l'@ MAC:
<pre>
root@zebrasoma:/home/pifou# ip link set wlan5 address 00:1a:56:a4:4b:ff
</pre>

<pre>
root@zebrasoma:/home/pifou# ip a
3: wlan5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:1a:56:a4:4b:ff brd ff:ff:ff:ff:ff:ff
inet 172.26.79.21/20 brd 172.26.79.255 scope global wlan5
valid_lft forever preferred_lft forever
</pre>

Après le changement d'@ MAC, l'association est bien impossible:
<pre>
root@zebrasoma:/home/pifou# ifconfig wlan5 up
root@zebrasoma:/home/pifou# iwconfig
wlan5 IEEE 802.11bgn ESSID:"Wolverine"
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:0123-4567-89
Power Management:off
</pre>

==== Crackage de la clef WEP ====

Nous avons fait le crack de la clé WEP sur cracotte08.
Pour cracker la clef WEP, nous avons tout d'abord utiliser airmon-ng afin de voir le statut des interfaces réseau.
<pre>
root@zebrasoma:/home/pifou# airmon-ng

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
</pre>

On entre ensuite en mode monitoring sur l'interface wlan5 :
<pre>
root@zebrasoma:/home/pifou# airmon-ng start wlan5

Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID Name
1986 avahi-daemon
1987 avahi-daemon

Interface Chipset Driver

mon0 Ralink RT2870/3070 rt2800usb - [phy1]
wlan0 Broadcom wl - [phy0]
wlan5 Ralink RT2870/3070 rt2800usb - [phy1]
(monitor mode enabled on mon1)

</pre>

Pour continuer, nous capturons les paquets transitant afin de collecter les paquets nécessaires au décryptage de la clef WEP. L'option --encrypt wep permet de filtrer uniquement les points d'accès WEP.
<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wep wlan5

CH 5 ][ Elapsed: 0 s ][ 2016-03-31 18:36

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -42 3 0 0 3 54e. WEP WEP Wolverine
04:DA:D2:9C:50:50 -59 2 11 0 2 54e. WEP WEP cracotte01
04:DA:D2:9C:50:56 -59 3 19 0 2 54e. WEP WEP cracotte07
04:DA:D2:9C:50:59 -59 2 0 0 2 54e. WEP WEP cracotte10
04:DA:D2:9C:50:57 -59 2 15 0 2 54e. WEP WEP cracotte08
04:DA:D2:9C:50:52 -58 3 85 42 2 54e. WEP WEP cracotte03
04:DA:D2:9C:50:54 -58 1 20 9 2 54e. WEP WEP cracotte05
04:DA:D2:9C:50:55 -60 1 9 4 2 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -59 2 134 66 2 54e. WEP WEP cracotte02
04:DA:D2:9C:50:53 -61 6 95 47 2 54e. WEP WEP cracotte04

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:50 00:0F:B5:92:23:75 -66 54e-48e 68 10
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -72 36e- 2e 133 19
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -66 54e-36e 89 15
04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -62 54e-48e 23 84
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -66 54e-36e 576 20
</pre>

Nous avons choisi de récuperer la clef WEP de cracotte03 (son BSSID est lié à une station)

<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 2 -w crackWEP wlan5

CH 2 ][ Elapsed: 12 s ][ 2016-03-31 18:42

BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

04:DA:D2:9C:50:52 -57 35 43 1066 87 2 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -64 36e-48e 1232 1067
</pre>

Enfin, nous lançons le crack de la clef à l'aide de aircrack-ng :
<pre>
root@zebrasoma:/home/pifou# aircrack-ng crackWEP-02.cap
Aircrack-ng 1.2 beta3

[00:00:04] Tested 112801 keys (got 3050 IVs)

KB depth byte(vote)
0 6/ 10 CD(5120) 15(4864) 6D(4864) 8C(4864) A7(4864)
1 46/ 1 E9(4352) 04(4096) 0E(4096) 0F(4096) 16(4096)
2 14/ 42 C8(4864) 10(4608) 11(4608) 1D(4608) 58(4608)
3 19/ 3 CF(4864) 0A(4608) 5E(4608) 8E(4608) 90(4608)
4 2/ 16 08(5632) 89(5376) 96(5376) B4(5376) F7(5376)

Failed. Next try with 5000 IVs.
</pre>

Il est nécessaire d'être proche du point d’accès (sinon le débit est trop faible, ce qui rend l'opération longue), ainsi que de capturer un minimum de 10 000 paquets.

Au final, nous arrivons bien à récupérer la clef WEP :
<pre>

Aircrack-ng 1.2 beta3

[00:04:10] Tested 799 keys (got 42913 IVs)

KB depth byte(vote)
0 0/ 1 EE(56320) B4(51712) 9D(50944) 4E(50688) 28(50432)
1 1/ 2 D9(55552) 3D(50176) 68(49664) 08(49408) 49(49152)
2 1/ 5 A2(53504) 5B(52480) 93(52480) 73(52224) 10(50432)
3 1/ 3 30(53248) 81(51456) 5B(49920) 6E(49920) 1E(49664)
4 9/ 4 9D(50176) 31(49408) 18(49152) 72(49152) E1(49152)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44 ]
Decrypted correctly: 100%
</pre>

==== Cassage de mot de passe WPA-PSK par force brute ====
Nous refaisons les mêmes actions que pour le crackage de clef WEP.
Cette fois nous essayons de cracker la clef WPA sur cracotte03.

<pre>
root@zebrasoma:/home/pifou# airodump-ng --encrypt wpa wlan5
</pre>
<pre>
root@zebrasoma:/home/pifou# airodump-ng --essid cracotte03 --channel 13 -w crackWPA wlan5
</pre>

Une fois le handshake récupéré:
<pre>
root@zebrasoma:/home/pifou# aircrack-ng -w dico.txt crackWPA-01.cap
</pre>
Nous avons lancé ceci sur le eeePC qui a une vitesse de traitement 5 fois inférieure à celle d'une zabeth environ (environ 5h de traitement). Puis nous obtenons le résultat suivant:
<pre>
Aircrack-ng 1.2 beta3

[04:32:42] 12399908 keys tested (759.63 k/s)

KEY FOUND! [ 12399903 ]

Master Key : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87
40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93

Transient Key : 70 EE 27 96 5B 34 B5 4F 06 A1 F2 B6 A7 16 1E 21
7A 0B BD F4 13 67 5B 4C ED 30 A9 0D 91 E3 F9 7F
88 E6 12 68 9C 77 4B 48 EB 5E 6A 5A DD 1D D9 08
36 40 94 7D B4 05 80 B2 60 FA 84 81 50 CE DC 87

EAPOL HMAC : 83 03 24 AC 39 AB 67 E7 7B C4 40 E8 6B 6D 7D 47

</pre>

=== Réalisations ===
==== Sécurisation des données ====

Nous créons d'abord 3 nouvelles partitions, que nous associons à notre VM en modifiant le fichier GreenArrow.cfg :

<pre>
lvcreate -L 1G -n /dev/virtual/GreenArrow-1 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-2 -v
lvcreate -L 1G -n /dev/virtual/GreenArrow-3 -v

'phy:/dev/virtual/GreenArrow-1,xvdd,w',
'phy:/dev/virtual/GreenArrow-2,xvde,w',
'phy:/dev/virtual/GreenArrow-3,xvdf,w',
</pre>

Il faut ensuite installer mdadm :

<pre>
apt-get install mdadm
</pre>

Nous créons le volume /dev/md0 qui représente le RAID5 de partitions

<pre>
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
</pre>

Pour avoir le détail de la configuration actuelle:

<pre>
root@GreenArrow:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon oct 13 11:34:23 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Mon oct 13 11:34:23 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : IMA5-BANANE:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 0

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf
</pre>

Puis nous sauvons cette dernière afin de conserver md0:
<pre>
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
</pre>

Puis:
<pre>
mkfs /dev/md0
mkdir /datamd0
mount /dev/md0 /datamd0/
</pre>

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être surs que la partition soit encore montée après le reboot:
<pre>
/dev/md0 /datamd0
</pre>

Nous créons un fichier texte sur le raid5:
<pre>
vim testraid5.txt
</pre>

Nous mettons en commentaire la 2ème partition dans le fichier de conf, puis redémarrons la machine:

<pre>
mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon oct 13 11:34:23 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Mon oct 13 11:45:01 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : GreenArrow:0 (local to host GreenArrow)
UUID : f70ca72e:e8adc585:ec023dca:21061341
Events : 4

Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
2 0 0 2 removed
2 202 80 2 active sync /dev/xvdf
</pre>

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

<pre>
ls /datamd0/
testraid5.txt
</pre>

Pour rajouter la partition, on la decommente dans le fichier de configuration et on procede au rajout de cette partition au raid de la facon suivante:

mdadm --add /dev/md0 /dev/xvde

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours:
Suppression de la partition xvdf:
<pre>
root@GreenArrow:~# mdadm --set-faulty /dev/md0 /dev/xvdf
</pre>
<pre>
root@GreenArrow:~# mdadm --remove /dev/md0 /dev/xvdf
</pre>
La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>
On remet la partition:
<pre>
root@GreenArrow:~# mdadm --add /dev/md0 /dev/xvdf
</pre>
On peut ensuite constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:
<pre>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===>.................] recovery = 18.2% (191112/1047552) finish=0.4min speed=31852K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 20.0% (210764/1047552) finish=0.4min speed=30109K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[====>................] recovery = 21.8% (229836/1047552) finish=0.4min speed=32833K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 59.6% (626140/1047552) finish=0.2min speed=29816K/sec

unused devices: <none>
root@GreenArrow:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 94.3% (989688/1047552) finish=0.0min speed=30124K/sec

unused devices: <none>
root@GreenArrow:~# [ 446.720069] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdf[3] xvdd[0] xvde[1]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
</pre>

==== Cryptage de données ====

Tout d'abord, nous vérifions grâce à Gparted que la carte SD fournie comporte une seule partition.
Une fois ce test passé, nous regardons grâce à dmesg où est localisé la carte SD :

<pre>
root@zebrasoma:/# dmesg
[...]
[1126726.403767] mmcblk1: mmc1:59b4 NCard 14.7 GiB
</pre>

Notre carte SD se situe donc sur /dev/mmcblk1.
Nous faisons donc un chiffrage AES avec un hashage SHA256 de la carte SD :

<pre>
root@zebrasoma:/# cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>

Nous devons alors renseigner un mot de passe pour crypter la clef.
Ensuite, nous ouvrons la partition Luks, puis nous formatons la carte :

<pre>
root@zebrasoma:/# cryptsetup luksOpen /dev/sdb1 crypt_sd
root@zebrasoma:/# mkfs.ext4 /dev/mapper/crypt_sd
</pre>

Nous montons la partition, puis créons un fichier sur la carte :
<pre>
root@zebrasoma:/# mount /dev/mapper/crypt_sd /mnt
root@zebrasoma:/# vi /mnt/test.txt #on marque un texte dans le fichier
</pre>

Enfin, nous démontons la carte SD et fermons la partition Luks :
<pre>
root@zebrasoma:/# umount /mnt
root@zebrasoma:/# cryptsetup luksClose crypt_sd
</pre>

Nous essayons ensuite d'accéder à la carte SD. En renseignant un mauvais mot de passe, une erreur apparaît.
Cependant, une fois le bon mot de passe renseigné, tout re-devient possible.

==== Sécurisation Wifi par WPA2-EAP ====
Tout d'abord, nous installons FreeRadius sur notre machine virtuelle. 
Dans le fichier '''users''', nous renseignons le login et le mot de passe pour se connecter à la borne Wifi : 
<pre>
GreenArrow Cleartext-Password:="glopglop"
</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne E306 et E304 : 
<pre>
client E306 {
ipaddr = 10.60.1.2
secret = password
}
client E304 {
ipaddr = 10.60.1.4
secret = password
}
</pre>

Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''', puis nous rentrons en mode configuration : 
<pre>
aaa authentication login eap_greenarrow group radius_greenarrow
radius-server host 193.48.57.162 auth-port 1812 acct-port 1813 key glopglop
aaa group server radius radius_greenarrow
server 193.48.57.162 auth-port 1812 acct-port 1813

dot11 ssid SSID_GREENARROW
vlan 3
authentication open eap eap_greenarrow
authentication network-eap eap_greenarrow
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 3 mode ciphers aes-ccm tkip
ssid SSID_GREENARROW

interface Dot11Radio0.3
encapsulation dot1Q 3
no ip route-cache
bridge-group 3
bridge-group 3 subscriber-loop-control
bridge-group 3 spanning-disabled
bridge-group 3 block-unknown-source
no bridge-group 3 source-learning
no bridge-group 3 unicast-flooding

interface GigabitEthernet0.3
encapsulation dot1Q 3
bridge-group 3
</pre>

Une fois ces modifications effectuées, nous configurons l'interface wlan0 de l'eeePC pour pouvoir se connecter au Wifi à l'aide de '''ifup wlan0''' :

<pre>
auto wlan0
iface wlan0 inet static
address 10.60.3.2
netmask 255.255.255.0
gateway 10.60.3.1
wpa-ssid SSID_GREENARROW
wpa-key-mgmt WPA-EAP
wpa-identity GreenArrow
wpa-password glopglop
</pre>

On lance le serveur FreeRadius via freeradius -X (mode debug).
Sur smartphone, nous arrivons à détecter notre SSID (SSID_GREENARROW). Nous pouvons également ping notre eeePC depuis la machine virtuelle, tout comme nous arrivons à pinger des Vm d'autres groupes depuis notre eeePC. 
<pre>
root@GreenArrow:/etc/freeradius# ping 10.60.3.2
PING 10.60.3.2 (10.60.3.2) 56(84) bytes of data.
64 bytes from 10.60.3.2: icmp_seq=1 ttl=255 time=1.30 ms
64 bytes from 10.60.3.2: icmp_seq=2 ttl=255 time=1.96 ms
</pre>

==== Serveur DCHP ====

Pour cette partie, nous avons d'abord installer le paquet isc-dhcp-server.
Ensuite, nous avons modifier le fichier dhcpd.conf :
<pre>
option domain-name "jjlddelamuerto.space";
option domain-name-servers 193.48.57.162;

subnet 10.60.3.0 netmask 255.255.255.0 {
range 10.60.3.10 10.60.3.40;
option routers 10.60.3.1;
}
</pre>

Nous modifions ensuite isc-dhcp-server pour rajouter l'interface wlan0 :
<pre>
INTERFACES="wlan0"
</pre>

Nous pouvons maintenant nous connecter sur le reseau Wifi via smartphone, le serveur DHCP fonctionne correctement.
[[Fichier:Connexioniphone.JPG|thumb|center|Connexion via smartphone]]

==== Configuration et utilisation du PCBX ====

Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=JulienJoignaux
username=jjoignaux
secret=secret
context=work

[6002]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=LoicDelecroix
username=ldelecro
secret=secret
context=work</pre>
 

Puis nous modifions le fichier extensions.conf
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

[[Fichier:voipjjld.jpg|thumb|center|Appel entre 2 smartphones]]

== Références ==

* Crackage de la clef WEP : [http://wiki.backtrack-fr.net/index.php/Casser_une_cl%C3%A9_wep/wpa_avec_la_suite_Aircrack-ng]
* Cassage de mot de passe WPA-PSK : [http://www.crack-wifi.com/tutoriel-crack-wpa.php]
* Cryptage de données : [https://doc.ubuntu-fr.org/cryptsetup]
* DHCP : [https://doc.ubuntu-fr.org/isc-dhcp-server]
* Asterisk : [http://denisrosenkranz.com/tuto-installer-et-configurer-asterisk-sous-debian-6-et-ubuntu/]

Cahier 2017 groupe n°5

2017-11-17T13:42:22Z

Hdelatte : /* Sécurisation des données */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.179
www IN A 193.48.57.179
@ IN A 193.48.57.179

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.179

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

Nous créons trois nouvelles partitions qui vont représenter nos disques.

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

Nous ajoutons ces partitions dans la machine virtuelle via le fichier IMA5-BANANe.conf

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T13:41:42Z

Hdelatte : /* Sécurisation des données */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.179
www IN A 193.48.57.179
@ IN A 193.48.57.179

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.179

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

Nous créons trois nouvelles partitions qui vont représenter nos disques.

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

Nous ajoutons ces partitions dans la machine virtuelle via le fichier IMA5-BANANe.conf

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T13:39:11Z

Hdelatte : /* DNS SEC */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.179
www IN A 193.48.57.179
@ IN A 193.48.57.179

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.179

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T13:38:20Z

Hdelatte : /* Serveur DNS */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.179
www IN A 193.48.57.179
@ IN A 193.48.57.179

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.179

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T13:37:56Z

Hdelatte : /* Serveur DNS */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.179

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T13:35:39Z

Hdelatte : /* Certification SSL */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====
Nous commencons par acheter un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:
root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.162????

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T09:02:23Z

Hdelatte : /* Création d'une machine virtuelle Xen sur Cordouan */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/IMA5-BANANE.cfg
ssh username@weppes
ssh root@193.48.57.179

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====

Premièrement, sur Gandi nous lançons l'étape d'achat d'un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Nous continuons donc la procédure pour obtenir le certificat, et attendons donc sa mise en place.
Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.162????

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====

Cahier 2017 groupe n°5

2017-11-17T09:00:08Z

Hdelatte : /* Création d'une machine virtuelle Xen sur Cordouan */

=='''Présentation générale'''==

===Mise en contexte===

Le projet de Réseau Avancé est composé d'une partie commune et d'une tâche particulière par binôme. Ce projet consiste en la configuration d'une architecture réseau avec différentes parties, en plus du câblage et de la configuration des routeurs et commutateurs.

La partie commune consiste en la création et la mise en réseau d'une machine virtuelle; ainsi que la création d'un site sécurisé avec la configuration du serveur SSH, DNS sécurisé et du certificat SSL. La virtualisation permet de faire fonctionner sur une même machine plusieurs OS isolés ou des logiciels grâce aux machines virtuelles. Au-delà de la réduction des coûts, la virtualisation permet aussi de manipuler et gérer plus facilement des OS. Cependant, on s'oriente de plus en plus vers l'isolation par des conteneurs car ils permettent au sein d'un même OS, d'isoler les ressources matérielles et d'éviter des surcharges.

Notre tâche particulière est donc de réaliser la gestion des conteneurs au sein d'une machine virtuelle configurée en réseau.

===Tâches à effectuer===

* Création d'une machine virtuelle sur le serveur de virtualisation Cordouan
* Mettre la machine virtuelle en réseau
* Configuration des services Internet (Serveur SSH, DNS, DNSSEC, Certificat SSL)
* Crackage de clé Wi-Fi
* Créer les différents conteneurs et configurer leur accès au réseau (tâche particulière)

=='''Travail effectué'''==

====Création d'une machine virtuelle Xen sur Cordouan====

On commence par créer une machine virtuelle Xen sur le serveur de virtualisation cordouan.insecserv.deule.net. On se connecte tout d'abord en SSH sur le serveur cordouan.

1) ssh root@cordouan.insecserv.deule.net
Mot de passe: mot de passe root habituel

On précise:

* le nom de machine virtuelle: IMA5-BANANE
* son adresse IP sur le réseau: 193.48.57.179/28
* le répertoire où créer les disques virtuels: /usr/local/xen
* le miroir Debian: http://debian.polytech-lille.fr/debian
* la distribution: jessie (qui est la distribution stable courante)

2) xen-create-image --hostname=<IMA5-BANANE> --ip 193.48.57.179/28 --dir /usr/local/xen --netmask=255.255.255.240 --gateway=193.48.57.177 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie

On modifie le fichier de configuration de la machine virtuelle pour faire en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte. Installez les paquetages nécessaires pour SSH, le serveur Web apache2 et le serveur DNS bind (voir la partie services).

3) xl create /etc/xen/IMA5-BANANE.cfg
vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-home -v
lvcreate -L 10G -n /dev/virtual/IMA5-BANANE-var -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On modifie le fichier de configuration en faisant en sorte que les répertoires var et home de la machine virtuelle soient sur des partitions LVM de l'hôte:

* la mémoire attribuée: 512 Mo
* l'adresse ip de la MV: 193.48.57.179/28
* bridge: IMA5sc

4) xl list

root@cordouan:~# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1993 8 r----- 52219.3
karmeliett 1 128 1 -b---- 2483.6
duvel 2 512 1 -b---- 4225.6
deus 3 512 1 -b---- 4226.4
trappe 4 512 1 -b---- 4082.4
Rincecochon 6 512 1 -b---- 3788.2
IMA5-Durian 62 512 1 -b---- 3237.7
IMA5-BANANE 84 512 1 -b---- 152.9
IMA5-Papaye 89 512 1 -b---- 35.4
IMA5-Ananas 91 512 1 -b---- 27.0

On vérifie que la MV IMA5-BANANE a bien été créée.

5) xl console IMA5-BANANE

On lance IMA5-BANANE en utilisant le log root et le mot de passe configuré.

Commandes de base pour démarrer la VM proprement:

ssh root@cordouan.insecserv.deule.net
xl create /etc/xen/GreenArrow.cfg
ssh username@weppes
ssh root@193.48.57.162

====Services Internet (SSH, DNS sécurisé et certificat SSL)====

On configure à présent les services Internet après avoir acheté un nom de domaine (https://www.banane.space) sur gandi.net pour créer notre site Web sécurisé.

=====''Serveur SSH''=====

Sur notre machine virtuelle, nous avons configuré le fichier sshd_config (PubkeyAuthentication ) :

root@IMA5-BANANE:~# vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
PermitRootLogin yes

root@IMA5-BANANE:~# service ssh restart

=====''Certification SSL''=====

Premièrement, sur Gandi nous lançons l'étape d'achat d'un certificat SSL. Puis, sur la VM nous générons le CSR grâce à cette commande:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout banane.key -out banane.csr
Generating a 2048 bit RSA private key
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:IMA
Common Name (e.g. server FQDN or YOUR name) []:banane.space
Email Address []:
A challenge password []:
An optional company name []:

root@IMA5-BANANE:/etc/apache2/sites-available/clef# ls banane.csr banane.key
root@IMA5-BANANE:/etc/apache2/sites-available/clef# cat banane.csr
-----BEGIN CERTIFICATE REQUEST-----
<CSR à renseigner sur Gandi lors de l'achat du certificat>
-----END CERTIFICATE REQUEST-----

Nous continuons donc la procédure pour obtenir le certificat, et attendons donc sa mise en place.
Pour recevoir le mail contenant le lien pour activer le certificat, nous installons les packages suivants :

root@IMA5-BANANE:~# apt-get install postfix mailx

Une fois le certificat récupéré, nous les copions tous dans le bon répertoire, puis nous hashons le tout :

root@IMA5-BANANE:/etc/bind# cp certificat.crt /etc/ssl/certs/banane.space.crt
root@IMA5-BANANE:/etc/bind# cp serveur.key /etc/ssl/private/banane.space.key
root@IMA5-BANANE:/etc/bind# cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem
root@IMA5-BANANE:/etc/bind# c_rehash /etc/ssl/certs

Enfin, la dernière étape consiste en la modification des fichiers 000-banane.space-ssl.conf et ports.conf :

root@IMA5-BANANE:/etc/apache2/sites-available# cat 000-banane.space-ssl.conf
<VirtualHost *:443>
ServerName www.banane.space
ServerAlias banane.space
DocumentRoot /var/www/
CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/banane.space.crt
SSLCertificateKeyFile /etc/ssl/private/banane.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

root@IMA5-BANANE:/etc/apache2# cat ports.conf
Listen 80
<IfModule ssl_module>
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>

Un redémarrage du service apache2 est maintenant nécessaire :

root@IMA5-BANANE:/etc/apache2# service apache2 stop
root@IMA5-BANANE:/etc/apache2# service apache2 start
root@IMA5-BANANE:/etc/apache2# service apache2 reload

Nous pouvons voir que notre site est maintenant sécurisé, un cadenas vert est bien présent.

=====''Serveur DNS''=====

On commence par modifier les informations de notre nom de domaine sur le site de Gandi. Ensuite, dans ''"Gérer les Glue Records"'', nous modifions les informations concernant notre nom de domaine.

* nom du serveur: ns.banane.space
* adresse IP: 193.48.57.179
* serveurs de nom:
** DNS1: ns.banane.space
** DNS2: ns6.gandi.net (serveur secondaire de Gandi)

Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :

root@IMA5-BANANE:/etc/bind# vim /etc/bind/named.conf.local
zone "banane.space" IN {
type master;
file "/etc/bind/db.banane.space";
};

On créée ensuite le fichier db.banane.space:

$TTL 604800
@ IN SOA ns.banane.space. root.banane.space. (
2016113007 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.banane.space.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.162
www IN A 193.48.57.162
@ IN A 193.48.57.162

root@IMA5-BANANE:/etc/bind# vim /etc/resolv.conf
search banane.space
nameserver 193.48.57.162????

=====''DNS SEC''=====

Génération des clefs asymétriques:

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE banane.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE banane.space

On modifie le nom des clefs:

/etc/bind/banane.space.dnssec# ls
????

Nous signons ensuite les zones:

dnssec-signzone -o banane.space -k banane.space-ksk
../db.banane.space banane.space-zsk

Pour finir nous ajoutons la clef KSK sur Gandi avec l'algorithme RSA/SHA1.

====Sécurisation des données====

1) vi /etc/xen/IMA5-BANANE.cfg
lvcreate -L 10G -n /dev/virtual/banane-1 -v
lvcreate -L 10G -n /dev/virtual/banane-2 -v
lvcreate -L 10G -n /dev/virtual/banane-3 -v

root@cordouan:~# cat /etc/xen/IMA5-BANANE.cfg
#
# Configuration file for the Xen instance IMA5-BANANE, created
# by xen-tools 4.5 on Mon Sep 11 19:01:21 2017.
#
#
# Kernel + memory size
#
kernel = '/boot/vmlinuz-3.16.0-4-amd64'
extra = 'elevator=noop'
ramdisk = '/boot/initrd.img-3.16.0-4-amd64'
vcpus = '1'
memory = '512'
#
# Disk device(s).
#
root = '/dev/xvda2 ro'
disk = [
'file:/usr/local/xen/domains/IMA5-BANANE/disk.img,xvda2,w',
'file:/usr/local/xen/domains/IMA5-BANANE/swap.img,xvda1,w',
'phy:/dev/virtual/IMA5-BANANE-home,xvdb1,w',
'phy:/dev/virtual/IMA5-BANANE-var,xvdc1,w',
'phy:/dev/virtual/banane-1,xvdd,w',
'phy:/dev/virtual/banane-2,xvde,w',
'phy:/dev/virtual/banane-3,xvdf,w',
#
# Physical volumes
#
#
# Hostname
#
name = 'IMA5-BANANE'
#
# Networking
#
vif = [ 'ip=193.48.57.179/28 ,mac=00:16:3E:56:71:47,bridge=IMA5sc' ]
#
# Behaviour
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

On reconfigure le fichier IMA5-BANANE.cfg en créant 3 nouvelles partitions LVM banane-X de 1 Go associées à notre VM.

2) xl console IMA5-BANANE

On relance la MV IMA5-BANANE.

3) apt-get install mdadm

Nous avons ensuite installé l paquetage mdadm puis rebooté la MV.

4) mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

Nous créons le volume /dev/md0 pour créer un RAID5 logiciel avec les trois partitions obtenues. On sauvegarde ensuite la configuration actelle.
root@IMA5-BANANE:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
root@IMA5-BANANE:~# mkfs /dev/md0
root@IMA5-BANANE:~# mkdir /datamd0
root@IMA5-BANANE:/datamd0# mount /dev/md0 /datamd0/

Ensuite il faut éditer le fichier /etc/fstab en rajoutant la ligne suivante à la fin du fichier afin d'être sûr que la partition soit encore montée après le reboot:
/dev/md0 /datamd0

Nous créons un fichier texte sur le raid5:
root@IMA5-BANANE:/datamd0# vim raid5test.txt

Pour avoir le détail de la configuration actuelle:

5) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Wed Oct 25 17:03:20 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 2
Number Major Minor RaidDevice State
0 202 48 0 active sync /dev/xvdd
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

6) root@IMA5-BANANE:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 25 18:27:13 2017
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed Oct 25 18:51:56 2017
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : IMA5-BANANE:0 (local to host IMA5-BANANE)
UUID : b70ad336:fb198d84:a5909f1c:f4b33229
Events : 12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 202 64 1 active sync /dev/xvde
2 202 80 2 active sync /dev/xvdf

Nous arrêtons la MV, mettons en commentaire la 1ère partition dans le fichier de configuration, puis redémarrons la machine.

On voit bien qu'une partition a été supprimée mais que le fichier créé auparavant est toujours présent:

root@IMA5-BANANE:~# ls /datamd0/
raid5test.txt

Pour le test de réparation, afin de bien voir l'avancement de la reconstruction, nous avons procédé comme dans l'exemple du cours: Suppression de la partition xvdd:

root@IMA5-BANANE:~# mdadm --set-faulty /dev/md0 /dev/xvdd
root@IMA5-BANANE:~# mdadm --remove /dev/md0 /dev/xvdd
La partition est bien supprimée:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]

On remet à présent la partition supprimée:
root@IMA5-BANANE:~# mdadm --add /dev/md0 /dev/xvdd

On essaie ensuite de remonter le RAID5 et on peut constater l'avancement de la reconstruction en lançant la même commande assez régulièrement:

7) root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[===========>.........] recovery = 59.7% (627140/1047552) finish=0.2min speed=28506K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[============>........] recovery = 64.5% (676392/1047552) finish=0.2min speed=29408K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 66.2% (695080/1047552) finish=0.2min speed=28961K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[=============>.......] recovery = 68.1% (714664/1047552) finish=0.1min speed=28586K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
[==================>..] recovery = 94.6% (991996/1047552) finish=0.0min speed=29206K/sec
unused devices: <none>
root@IMA5-BANANE:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvde[1] xvdf[2]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>

====Cryptage des données====

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
cryptsetup luksOpen /dev/sdb1 crypt_sd
mkfs.ext4 /dev/mapper/crypt_sd
mount /dev/mapper/crypt_sd /mnt
vi /mnt/test.txt #on marque un texte dans le fichier
umount /mnt
cryptsetup luksClose crypt_sd

====Mise en réseau de la MV Xen IMA5-BANANE====