Version du 18 mars 2020 à 15:24 (voir la source) Grouille (discussion | contributions) (→‎Confinement) ← Modification précédente		Version du 18 mars 2020 à 15:24 (voir la source) Lahouass (discussion | contributions) (→‎Equipe 1) Modification suivante →
Ligne 1 202 :		Ligne 1 202 :
	|-		|-
	|		|
−	Faire de même avec la Nucleo M4 ?	+	Faire de même avec la Nucleo M4
	|		|
−	<font color='orange'>À voir</font>	+	<font color='orange'>En pause (PBs techniques)</font>
		+
		+	|-
		+	|
		+	Depuis la Raspberry, modification du script python d'envoi des données au serveur pour distinguer automatiquement l'adresse IP et obtenir le numéro du capteur
		+
		+	|
		+	<font color='green'>Fait</font>
		+
		+	|-
		+	|
		+	Ajustement des codes capteur et Température de façon à ce qu'ils utilisent tout les deux une fonction généraliste de retour de données
		+
		+	|
		+	<font color='green'>Fait</font>
		+
		+	|-
		+	|
		+	Mise en place d'un unique makefile généraliste pouvant uploader le bon code selon le type capteur (makefile déjà en place, quelques ajouts manquants sont en cours)
		+	|
		+	<font color='Orange'>En cours</font>
		+
		+	|-
		+
	|}		|}

---

Version du 18 mars 2020 à 15:24

Présentation générale

Administration système, déploiement et surveillances de logiciels dans un réseau de capteurs

Description

Dans le cadre de recherches dans le domaine des réseaux de capteurs et des objets connectés, notre projet consiste à développer une solution de maintenance et de reconfiguration à distance d'un ensemble de nœuds déployés dans un environnement réel. Afin de faciliter la vie de ces chercheurs sur le test de leurs hypothèses, ils pourront facilement et rapidement déployer leurs créations sur tout les nœuds souhaités grâce à un système de sélection ou au téléchargement du nouveau code sur tous les nœuds du réseau.

Objectifs

L'objectif principal de notre projet est de créer une interface permettant de tester des programmes ou logiciels en les déployant sur le vaste réseau de capteurs. Nous devons rendre accessible chaque nœud indépendamment des autres, tout en permettant un lien entre tous, afin d'envoyer le contenu vers tout ou une partie des nœuds disponibles.

Enfin, nous allons permettre la mise à jour et l'adaptation du chemin d'envoi des données des nœuds, entre eux, et avec l'application de gestion.

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent

Notre concurrent principal reste le FIT(Future Internet Testing Falicity)/IoT-Lab. Il s'agit d'un laboratoire dont les recherches se portent sur les différents domaines scientifiques tel que les adresses de communications sans fils, des réseaux de capteurs, des protocoles de routages basse consommation et applications embarquées. Ce laboratoire dispose de plus de 1500 de nœuds de capteurs sans fils propagés à travers les six sites différents en France qui sont : Inria Grenoble (640), Inria Lille (293), Inria Saclay (264), ICube Strasbourg (400), Institut Mines-Télécom Paris (160) and CITI Lab Lyon (29). Chaque site dispose de capacités matérielles et de nœuds différentes, mais tous les sites sont interconnectés et disponibles via le même portail Web,

Analyse du second concurrent

Il y aussi une autre équipe au sein du laboratoire de recherches en informatique(LRI) qui est en train de faire un projet sur les capteurs de réseaux. Les questions abordées par l’équipe concernent les réseaux ad hoc sans fil et mobiles, les réseaux de capteurs et les réseaux fixes, et concernent la qualité de service, la sécurité, le contrôle d’admission, la réservation de ressources, le calcul des limites déterministes et la consommation d’énergie. L'analyse de la performance est donnée à la fois théoriquement, pour déterminer les limites, et par simulation, pour enrichir l'analyse et inclure un support pour un environnement dynamique.

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

De nombreux chercheurs et développeurs créent de nouveaux codes adaptés à l'utilisation d'un réseau de capteurs. Ces codes doivent être facilement déployés sur le réseau afin de pouvoir y réaliser des essais rapides. Cela permet de corriger rapidement les erreurs liées à leur mauvais fonctionnement.

Supposons que notre réseau est réparti sur une très grande surface. Le chercheur voulant tester son code doit l'envoyer à partir de son ordinateur sur le réseau. Notre projet va lui permettre de rester assis dans son bureau et de ne pas devoir charger le code sur chaque nœud de capteurs un par un.

A travers notre projet, nous voulons rendre possible ces exports rapides de données. Il nous faudra utiliser un routeur qui permettra la liaison entre chaque nœud et un serveur de données. Dans chacun de ses nœuds, on trouve plusieurs nœuds de mesures comportant chacun un microcontrôleur associé à des capteurs.

Pour pouvoir envoyer ses codes sur le réseau, le chercheur dispose d'une interface web graphique connectée au même serveur que les nœuds de collecte et le routeur. Cette interface permettra la sélection de tout ou d'une partie du réseau sur laquelle il doit effectuer les modifications. Ceci se fera à l'aide des microcontrôleurs du réseau et de Raspberry Pi gérant chaque nœud. Une fois la zone d'export choisie, il pourra envoyer ses codes et les mettre à jour en quelques clics. Le code sera envoyé sur le serveur et distribué par le routeur sur les nœuds sélectionnés. Les différents nœuds feront un retour sur la réception à travers le serveur via le routeur, et le chercheur pourra ainsi tester rapidement sa réalisation.

Dans le cas où le chercheur veut tester l'envoi de données par radio par exemple, il pourra placer un grand nombre de nœuds communiquant en filaire avec le routeur et par radio entre eux. Les nœuds seront capables de transmettre l'information au suivant et de choisir un autre chemin (contourner un nœud par exemple) en cas de perturbations (présence de réseau Wi-Fi à proximité, etc...), pour envoyer l'information. Ces nœuds seront capables de communiquer avec le serveur pour indiquer la bonne réception des données, les résultats obtenus ou éventuellement le mauvais fonctionnement d'un ou plusieurs capteurs.

Bibliographie et webographie

Site Web

Protocole XMLHttpRequest

https://openclassrooms.com/fr/courses/1085676-upload-de-fichiers-par-formulaire

Banana PI

DataSheet

https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf

OpenWRT

https://openwrt.org/

Wiki

http://wiki.banana-pi.org/Banana_Pi_BPI-R1

Raspberry PI

Pin Raspberry

https://pi4j.com/1.2/pins/model-3b-plus-rev1.html

Configuration

https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018

Clignotement d’une LED

https://www.framboise314.fr/la-saga-blink-un-raspberry-pour-faire-clignoter-une-led/
http://nagashur.com/blog/2013/01/01/controler-une-led-depuis-les-ports-gpio-du-raspberry-pi/

Installation Raspbian

https://raspbian-france.fr/installer-raspbian-premier-demarrage-configuration/

Préparation du projet

Cahier des charges du groupe

Nous allons devoir répondre à plusieurs problématiques.

• Tout d'abord nous devons créer un site web dynamique permettant l'envoi des données au serveur et finalement, aux nœuds de capteurs sélectionnés. Pour cela, nous allons devoir implémenter un système d'envoi de fichiers vers un routeur. Le routeur (Banana Pi) va filtrer les informations reçues, et donner un accès internet aux différents nœuds représentés par des Raspberry Pi et des microcontrôleurs.

• Ensuite, il faudra que les Raspberry récupèrent les fichiers C sur le serveur et les envoient correctement aux différents capteurs de leur nœud et puissent récupérer les informations à retourner. Pour se faire, on utilise l'utilitaire Python Ansible, permettant la gestion et la configuration des nœuds de capteurs. Celui-ci va récupérer les fichiers C et les distribuer sur les différents capteurs affectés. Le retour d'information se fera par le chemin inverse jusqu'au serveur web sous forme de fichiers contenant les données issues des capteurs.

Cahier des charges des équipes

Equipe 1 : Ziyad HOUSSAINI (S6), Loris AHOUASSOU (S7, S8)

• Dans notre équipe, il faudra configurer le routeur afin de pouvoir assurer la communication entre les Rasberry Pi qui seront configurées par l'équipe 2 et le serveur web qui sera mise en place par l'équipe 3.
• Pour se faire, on va utiliser une Banana pi sur laquelle sera installé OpenWRT.
• Le routeur servira également de point d'accès internet pour les différentes Raspberry.
• Il devra scruter le serveur web et récupérer les fichiers qui s'y trouvent avant de les envoyer sur les bonnes Raspberry à l'aide de scripts Shell.

Equipe 2 : Eymeric CAPRONNIER, Thomas MERTZ (S8)

• Une fois que le routeur aura envoyé les fichiers aux Raspberry demandées, et donc en fonction des capteurs qui s'y trouvent, celles-ci pourront commencer leur traitement.
• Les Raspberry vont commencer par compiler les codes reçus, puis vont les envoyer sur les microcontrôleurs représentant les capteurs.
• Les microcontrôleurs devront pouvoir être reconfigurer directement à partir de la Raspberry. Ils vont exécuter les codes reçus.
• Ils vont ensuite générer des fichiers résultat qui seront envoyés sur le serveur.

Equipe 3 : Guillaume ROUILLÉ

• Dans un premier temps, notre équipe devra réaliser une interface web utilisateur permettant la connexion au serveur de données. Pour se faire, on va utiliser les langages HTML et CSS pour la forme du site, et les langages PhP et SQL pour lier le site à la base de données. Un complément en langage Java Script permettra de rendre le site dynamique.

• Ensuite, il faudra créer un système de sélection des capteurs sur lesquels envoyer le ou les fichiers. Il faudra faire correspondre chaque capteur des différents nœuds avec un type prédéfini et créer une page de sélection sur le site.

• Puis, nous devrons envoyer les fichiers sur le serveur, où ils seront récupérés par le routeur pour être traiter. Il faudra créer une page permettant la mise en ligne de fichiers. Cette page affichera la progression de l'envoi et sera capable de valider la bonne réception des données.

• Enfin, une dernière partie du site permettra l'affichage des résultats reçus depuis les capteurs.

Choix techniques : matériel et logiciel

Equipe 1

• Une Banana Pi ;
• Une image (OS) de type Debian ou OpenWrt afin de pouvoir utiliser la carte ;
• Un carte SD sur laquelle on va charger l'image ;
• Un cable HDMI afin de pouvoir visualiser l'interface.

Equipe 2

• Une Raspberry Pi et son alimentation ;
• Un câble Ethernet ;
• 4 diodes et résistances ;
• Un câble HMDI/VGA ;
• Un clavier et une souris afin d'utiliser la Raspberry (interface graphique) ;
• Ansible pour faciliter le déploiement des fichiers C sur les nœuds.

Equipe 3

• Une base de données PostgreSQL pour le stockage des données ;
• Un interpréteur PhP et un serveur web (Apache) ;
• Un site moderne basé sur les Frameworks CSS Bootstrap et Vue.js.

Liste des tâches à effectuer

Equipe 1

Déploiement d'un routeur à base de Banana Pi R1. Ce routeur permettra l'accès internet aux différentes Raspberry Pi et il filtrera les accès. Déploiement de OpenWRT sur ce routeur.

• Documentation sur le fonctionnement du routeur Banana Pi ;
• Documentation sur le fonctionnement de OpenWRT ;
• Déploiement de OpenWRT sur le routeur et configuration ;
• Création d'un point d'accès internet sur la carte routeur ;
• Récupération des fichiers sur le serveur web ;
• Envoi des fichiers sur les bonnes Raspberry.

Equipe 2

Déploiement des logiciels sur les Raspberry Pi avec la création de différents scripts pour faciliter ce déploiement, en utilisant notamment Ansible.

• Documentation sur le fonctionnement des Raspberry pi ;
• Documentation sur Ansible ;
• Configuration de la Raspberry PI 3 ;
• Création du script afin de vérifier que le capteur sélectionné par le serveur se trouve bien dans la liste de capteur connecté à la Raspberry ;
• Création du script afin d'envoyer le code reçu aux différents capteurs ;
• Configuration à distance du microcontrôleur, peut importe son type ;
• Création du script permettant de créer le fichier résultat afin d'envoyer les données issus des capteurs.

Equipe 3

Déploiement d'un serveur permettant de récupérer les différentes données issues des capteurs (création d'une base de données et d'un site web dynamique pour l'affichage).

• Documentation sur les Frameworks Web Bootstrap.css et Vue.js ;
• Documentation sur PhP et Apache ;
• Création d'une interface web utilisateur ;
• Création d'une base de données relationnelle pour gérer les nœuds ;
• Envoi du fichier C sur le serveur ;
• Envoi du numéro et type des capteurs sélectionnés sur le serveur ;
• Envoi du numéro de la demande sur le serveur.

Calendrier prévisionnel

Equipe 1

Dates	Objectifs
05/02	Analyse des concurrents ; Scénario d'usage.
19/02	Cahier des charges ; Répartition du travail entre équipes.
05/03	Recherche sur Internet sur quel type de carte on pourra utiliser pour configurer le routeur, qui sera un point d'accès wifi pour le noeud de collecte qui sera la Rasberry Pi.
19/03	Recherche de la datasheet du routeur Banana PI-R1, afin de pouvoir comprendre les configurations de la carte et aussi les branchements.
02/04	Trouver l'open source me permettant de visuliser l'interface de la BPI-R1, et en l'occurrence l'OS OpenWrt.
16/04	Faire fonctionner la carte et comprendre les fonctionnalités qu'offrent l'OpenWrt.
30/04	Configurer la carte en tant que point d'accès wi-fi en utilisant cette fois l'OS Debian car la semaine dernière l'image OpenWrt ne fonctionnait pas.
07/05	Résoudre le problème de la carte car elle ne fonctionnait pas et demander à mes tuteurs la raison pour laquelle elle ne marche pas.
14/05	Mettre une nouvelle image (Armbian) et rattraper le retard pour le configurer en tant que point d'accès wi-fi pour la rasberry pi.
28/05	Faire en sorte que la BPI-R1 arrive à jouer le rôle de point d'accès wifi pour que la Rasberry PI puisse se connecter au serveur via internet.
14/11	Reprendre la configuration de la Banana Pi à zéro ; Faire de cette carte un point d'accès Wi-Fi.
01/04	Faire de la carte un routeur.

Equipe 2

Dates	Objectifs
05/02	Analyse des concurrents ; Scénario d'usage.
19/02	Cahier des charges ; Répartition du travail entre équipes.
05/03	Documentation sur les différents outils : Raspberry et Ansible.
19/03	Documentation sur l'allumage d'une LED et création des premiers scripts d'allumage de LED.
02/04	Installation de Raspbian sur la Raspberry PI 3 et début de configuration de la Raspberry PI 3.
16/04	Configuration de la Raspberry PI 3.
30/04	Installation de la bibliotèque wiringPI permettant le lancement du script écrit en C permettant l'allumage des différentes LED.
14/05	Installation d'un premier cablage de LED afin de tester le script d'allumage des LED.
28/05	Récupération du fichier C et XML envoyé sur le site ; Création des commandes de récupération de ces fichiers ; Création du script permettant de lire le fichier XML envoyé par le serveur qui indique le nom et le numéro du capteur sélectionné.
04/06	Permettre une récupération rapide des fichiers à partir du serveur ; Permettre une scrutation régulière du serveur sur la Raspberry ; Permettre l'exécution unique du programme ; Création du script permettant le lancement automatique des différents scripts créés lorsque le serveur effectue une demande.
14/11	Réinstaller une image sur la Raspberry Pi sans interface graphique ; Permettre l'accès à internet sur la Raspberry.
21/11	Permettre la connexion entre la Raspberry Pi et un Arduino Atmega328p.
20/12	Permettre l'exécution de code sur l'ATMega328p.

Equipe 3

Dates	Objectifs
05/02	Analyse des concurrents ; Scénario d'usage.
19/02	Cahier des charges ; Répartition du travail entre équipes.
05/03	Création de la base de données associée au projet ; Documentation Php et lancement du site web.
19/03	Création du système de connexion du site.
02/04	Mise en forme correcte du site : page de connexion, d'inscription et d'accueil.
16/04	Création de l'interface de sélection du capteur.
30/04	Documentation sur la création d'un fichier XML à partir d'un site web ; Création du fichier XML permettant de regrouper les informations concernant le capteur choisi.
14/05	Création de la section de sélection du fichier à envoyer sur le serveur (fichier C) ; Documentation sur le protocole XMLHttpRequest qui permet l'envoi du fichier sur le serveur ; Envoi du fichier C sur le serveur.
28/05	Récupération du fichier C et XML envoyé sur le site ; Création des commandes de récupération de ces fichiers.
04/06	Permettre une récupération rapide des fichiers à partir du serveur ; Permettre une scrutation régulière du serveur sur la Raspberry ; Permettre l'exécution unique du programme.
01/04	Créer la table pour le retour d'informations dans la base de données ; Créer un page d'affichage des données de cette nouvelle table.

Réalisation du Projet

Projet S6

Semaine 4 - 05/03

Pour l'équipe 1 :

Première recherche sur la carte Banana PI, à l'aide de la datasheet, dont le lien est ci-dessous.
L'utilisation de la datasheet va nous permettre de voir l'intégralité des données de la carte BPI-R1
c'est à dire les branchements, le courant d'alimentaion et les composants.
https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf

---

Pour l'équipe 2 :

Documentation sur l'utilisation d'Ansible et sur les Raspberry Pi

Afin d'installer Ansible, deux lignes de commande ont dû être lancé dans le terminal d'un pc en E306 ( car l'installation d'ansible n'était pas possible dans les autres salles) :

apt install ansible

Connexion internet sur la Raspberry :

Partie Raspberry

export https_proxy=https://proxy.polytech-lille.fr:3128
export http_proxy=http://proxy.polytech-lille.fr:3128

OU :

export https_proxy=https://proxy.plil.fr:3128
export http_proxy=http://proxy.plil.fr:3128

Puis, dans /etc/resolv.conf

nameserver 193.48.57.48

Ensuite dans /etc/network/interfaces :

auto eth0
iface eth0 inet static
   address 172.26.145.111
   netmask 255.255.255.0
   gateway 172.26.145.254

Enfin :

ipdown eth0
ifup eth0

Sur le pc :

iptables -F
iptables -tnat -F
iptables -PFORWARD ACCEPT

L'utilisation d'ansible se fera ensuite de la manière suivante : Ecriture d'un fichier .yml contenant les différentes tâches à effectuer sur un serveur (réseau de capteur) spécifique puis le lancement s'effectuera ensuite en lanceant la commande ansible suivi du nom du serveur sur lequel on souhaite travailler.

Concernant la Raspberry PI 3, la Raspberry PI 3 est un ordinateur miniature que l'on peut brancher à un écran et un clavier afin de l'utiliser comme un ordinateur normal. Le stockage des données s'effectue sur une carte SD ce qui permet à la Raspberry d'être très petite (l'utilisation d'un disque dur interne augmenterait grandement sa taille)

---

Pour l'équipe 3 :

Première recherche sur la création du site web. Recherche des ressources PhP, HTML, CSS nécessaires (Bootstrap).
J'ai laissé de côté la partie JavaScript et Vue.js car elles ne sont pas utiles pour commencer le site.

Création de la base de données projetCapteurs sur Houplin et des fonctions de connexion du site à celle-ci.
La base contient 3 tables :

• capteurs : numéro du capteur | nom du capteur | Raspberry à laquelle le capteur est relié | type de capteur
• membres : numéro du membre | nom | prénom | mot de passe | identifiant de connexion
• verif : numéro de la demande

La table capteurs stocke les informations concernant les capteurs et permettra la sélection au moment de l'envoi du fichier C.
La table membres répertorie les informations concernant les membres et permettra la connexion sur le site web.
La table verif contient le numéro de la demande.

---

Semaine 5 - 19/03

Pour l'équipe 1 :

Après avoir effectué des recherches sur la carte BPI R1, cette séance va me permettre de faire des recherches sur l'image qui va me permettre de faire visualiser l'interface de la BPI R1.
D'après le cahier de charge imposé, il faut mettre l'image OpenWrt.
Open Wrt est une distribution GNU/Linux minimaliste pour matériel embarqué. Après avoir fait des recherches, on a finalement retrouvé le site qui a l'image OpenWrt.
La première que je devais faire était d'installer un fichier OpenWrt dans une carte SD, et ce fichier servait à faire fonctionner la banana pi.
Voici le lien qui nous a permis de trouver l'image:

https://openwrt.org/toh/view/toh_fwdownload?dataflt%5B0%5D=supported%20current%20rel_%3D18.06.2.

Voici une image du site d'openwrt :

---

Pour l'équipe 2 :

Au cours de cette séance, je me suis documenté sur l'allumage d'une LED. Cela m'a amené à créer un organigramme afin de réaliser le code plus simplement par la suite.

Le câblage s'effectuera de façon très simple en connectant une LED puis une résistance à chaque sortie GPIO en fonction du nombre de capteurs souhaités par Raspberry (nous utilisons des LED pour cette année pour simuler et voir que le code envoyé par le serveur est bien traité et reçu par les LED s'allumant lorsque le capteur associé a été sélectionné).

Puis je me suis intéressé au code afin d'allumer la LED 500ms puis de l'éteindre 500ms grâce à une boucle while qui est toujours active tant que le programme tourne (control C par l'utilisateur pour stopper le programme). Pour se faire, il faut mettre le PIN connecté à la LED en mode sortie (OUTPUT) car sans cela la LED ne s'allume pas.

Ce code nécessite l'installation de la bibliothèque WiringPi qui permet d'allumer et d’éteindre la LED. Nous verrons l'installation de cette bibliothèque une fois les configurations faites sur la Raspberry effectuées et une fois connecté à la Raspberry.

---

Pour l'équipe 3 :

Début de la création du site : mise en place d'un système de connexion basique et d'un minimum de design pour rendre clair le site.
Je me suis limité à des fonctions de connexion et déconnexion sans modifier le reste des pages en fonction de l'état de connexion, et sans créer de variables de session.
Pour cela, j'ai utilisé des fonctions Php telles que pg_connect et pg_close, fonctions liées à une base de données PostgreSQL.

• Création d'un formulaire de connexion ;
• Création d'un formulaire d'inscription ;
• Création des scripts Php de lancement de ces formulaires.

---

Semaine 6 - 02/04

Pour l'équipe 1 :

Après avoir trouvé l'image permettant de visualiser l'interface BPI-R1, de la faire marcher et de le configurer en tant que routeur de wifi pour qu'il puisse emettre pour le noeud de collecte qui est la Rasberry PI. La première étape est d'abord d'installer l'OpenWrt dans une carte SD et cette carte SD sera mis sur le port SD de la Banana PI R1. Voici les commandes qui m'ont permis de mettre l'image OpenWrt dans la carte SD :

• Il faut d'abord se connecter à su sur le terminal
• Mettre l'image avec la commande ci dessous :

dd if=OpenWrtimage.img of=/dev/sdb

Avec OpenWrtimage.img le nom du fichier télécharger. Après avoir branchéle port HDMI de la carte avec l'entrée VGA du moniteur on pouvait voir l'interface mais on arrivait pas écrire. Donc après avoir appeler mes tuteurs, ils m'avaient dit que la semaine prochaine, ils allaient mettre le système Debian, car il y aurait des problèmes avec le système OpenWrt.

---

Pour l'équipe 2 :

Tout d'abord, il faut télécharger Raspbian sur la carte SD de la Raspberry Pi 3. Pour cela, j'ai sélectionné le fichier contenant Raspbian avec des interfaces graphiques (voir photo ci-dessous) sur le site internet :

https://www.raspberrypi.org/downloads/raspbian/

Une fois l'archive zippée de la distribution récupérée vous pouvez l'installer sur la carte SD après l'avoir décompressée en utilisant la commande dd :

dd if=2019-04-08-raspbian-stretch-full.img of=/dev/sdb

Puis une fois tout ceci téléchargé, j'ai commencé à effectuer mes premiers pas sur la Raspberry. Une fois le clavier, la souris, l'écran et la carte SD branché et connecté à la Raspberry, j'ai pu connecter l'alimentation de la Raspberry. Le premier démarrage fut un peu long, car lors de celui-ci, la raspberry a installé le système Raspbian. Lors de ce premier démarrage, des premières configurations ont été effectué qui ont été très simplifié car étant sur une version de Raspbian avec une interface graphique. Ces quelques réglages consistaient principalement à régler la langue, l'heure, la connexion internet et le nouveau mot de passe. L'identifiant et le mot de passe ont été laissé comme initialement.

le login par défaut est « pi », et le password est « raspberry »

---

Pour l'équipe 3 :

Adaptation du système de connexion avec création de variables de session. Ces variables permettent de maintenir une connexion ouverte en changeant de page et à structurer les pages afin qu'elles affichent les bonnes choses.
En effet, un individu connecté ne verra pas la page de connexion par exemple.
Amélioration du système de compte avec la mise en place du hachage des mots de passe.
Amélioration du design du site, avec la création d'une barre de menu et l'utilisation de Bootstrap.

---

Semaine 7 - 16/04

Pour l'équipe 1 :

Dans cette séance de projet, je vois que mon cahier de charge doit être changer. En effet, vu que la séance dernière, avec l'OpenWrt
qu'il y avait un problème de visualation de l'interface. Au final, j'ai reçu par mes tuteurs une carte SD, contenant cette fois
l'image Debian. Et cette fois ci, on voit bien l'interface. Maintenant le but est de pouvoir configurer la banana PI en routeur Wifi
afin que la Rasberry PI reçoit la wifi de ce dernier. Et aussi dans cette séance, j'ai pu voir des tutoriels, afin de pouvoir comprendre le mécanisme de fonctionnement et de
programmation.

---

Pour l'équipe 2 : Durant cette séance, plusieurs autres configurations ont été effectuées. Pour accéder à la fenêtre de configuration, il a fallu rentrer la commande :

sudo raspi-config

Maintenant que notre système Raspbian est un peu plus sécurisé, nous allons nous assurer que le SSH est bien activé afin que nous puissions prendre le contrôle de la Raspberry à distance. Pour cela, il faut sélectionner le huitième choix, « Advanced Options ». Cette fois, après validation nous arrivons sur un autre menu ou nous allons choisir la quatrième ligne, « SSH ». Puis « Enable », et enfin « Valider ». Le système lance quelques commandes puis nous ré-affiche une fenêtre nous indiquant le succès de l’opération.

---

Pour l'équipe 3 :

Création de la page de sélection des capteurs sous forme d'un formulaire Php. La sélection n'est pas au point mais l'affichage est correct.
Je laisse toujours de côté la partie dynamique, en essayant de rendre possible la sélection multiple pour l'envoi du formulaire.
Cette page contiendra aussi une partie de chargement du fichier à envoyer (unique pour le moment).

---

Semaine 8 - 30/04

Pour l'équipe 1 :

Dans la dernière séance, j'ai pas pu totalement assimiler l'ensemble du fonctionnement permettant de configurer
la BPI-R1 en tant que routeur de wifi. Donc toute cette séance s'est consacrés à la recherche des fonctionnalités de la carte.
Et aussi, j'ai pu énormément m'aider du site du bureau d'étude d'IMA (Robot Prédateur et Proie) de l'an dernier, surtout avec
la partie Rasberry Pi que j'ai remarqué qu'au final les fonctionnalités de la Banana PI est à peu près identique que celle de la Rasberry.
Voici le lien qui m'a principalement aidé à mieux comprendre et trouver les fonctionnalités du Debian :
https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019

---

Pour l'équipe 2 :

Une fois la Raspberry configuré, il a fallu installer la bibliothèque wiringPi. Pour se faire :

On installe GIT:

sudo apt-get install git-core

On met a jour le PI:

sudo apt-get update
sudo apt-get upgrade

On récupère la dernière version de WiringPi:

git clone git://git.drogon.net/wiringPi

On se place dans le bon répertoire:

cd wiringPi

On lance la compilation:

./build

Puis le lancement du code créé pour l'allumage des LED s'effectue de la manière suivante:

gcc blink.c -o blink -lwiringPi
./blink

Le fichier blink étant notre fichier contenant le script permettant l'allumage d'une led toute les 0.5s.

---

Pour l'équipe 3 :

Modification de la page principale (sélection d'un capteur possible). Possibilité de joindre un seul fichier C.
Un fichier XML est créé avec le numéro du capteur sélectionné. Ce fichier sera transmis avec le fichier C.
Documentation sur le protocole XMLHttpRequest : XMLHttpRequest

Le fichier XML contient le code suivant :

<?xml version='1.0' encoding='ISO-8859-1'?>

<sensor>nom_num</sensor>

---

Semaine 9 - 14/05

Pour l'équipe 1 : Dans cette séance, je peux enfin commencer à configurer la BPI-R1 en point d'accès Wifi. Après avoir branché au moniteur la carte
je remarque qu'il n'y a aucune visualisation sur le moniteur. Et c'est là où je commence à me perdre. En effet, n'ayant aucune idée de pourquoi
on ne voit plus l'interface, j'ai décidé de rechercher les causes de ce problème, en supposant que la carte a été court-circuiter.
Donc cette séance n'a été que la recherche de ce problème et surtout pouvoir le résoudre. N'ayant aucune idée après plusieurs séances de recherche, j'ai décidé de voir mes tuteurs afin de pouvoir
résoudre ce problème car je suis vraiment en retard par rapport à mon objectif fixé qui était
de configurer la BPI-R1 en routeur wifi pour qu'elle puisse donner les informations à la Rasberrie -PI.
Après plusieurs essaies, c'est à dire changer le courant d'Alimentation, mettre de nouveau l'image Debian
au final, mes tuteurs m'ont conseillé de changer l'image et d'en mettre un nouveau mais aussi il faut que
que cette image soit récente afin de ne pas avoir de problème au niveau du noyau de la carte.

---

Pour l'équipe 2 :

Installation d'un premier câblage pour réaliser l'allumage d'une des 4 LED en fonction de la LED sélectionné. Il a fallu trouver grâce à différent test le bon schéma de pin de notre Raspberry car il en existait beaucoup de différent sur le numéro du pin à entrer pour allumer la led correspondante à ce numéro.

---

Pour l'équipe 3 :

Création du script permettant l'upload d'un fichier C sur le serveur.

Le script va d'abord vérifier que le fichier à uploader vérifie les conditions (pas d'erreur, taille inférieure à la taille maximale, bonne extension).
Ensuite, on normalise le nom du fichier qui s'appellera maintenant 'binaire', et on récupère son extension.
A l'aide de la fonction move_uploaded_file, on délace le fichier de son répertoire temporaire vers le répertoire upload présent sur le serveur.

Il faut maintenant un script pour récupérer les fichiers C et XML sur la Raspberry Pi.

La partie 3 étant terminée pour le résultat attendu au S6, les équipes 2 et 3 fusionnent pour terminer la création des scripts.

---

Semaine 10 - 28/05

Pour l'équipe 1 : Le problème est enfin résolu mais il faut vite rattraper le retard, donc aujourd'hui, on a consacré cette séance dans l'utilisation de l'Armbian.

---

Pour l'équipe 2 & 3 :

Création d'un script blink.c permettant la récupération du nom du capteur et de son numéro stockés dans le fichier XML.
Création du script de récupération du fichier XML et du fichier C à partir du serveur.

Pour télécharger le fichier C et le fichier XML stockés sur le serveur, on utilise la commande wget dans un script nommé script.sh :

Pour exécuter un script automatique : Règle Cron

Voici le script de téléchargement automatique des fichiers toutes les minutes :

Il s'agit d'une crontab qui s’exécute toutes les minutes.
Cette crontab va lancer le script de téléchargement à chaque exécution, permettant ainsi de garder le fichier C à jour.

---

Semaine 11 - 04/06

Pour l'équipe 1 :

Donc suite au problème qui ont eu lieu ces dernières séances, et après avoir reçu des conseils de
mes tuteurs, j'ai fait une nouvelle des recherches sur l'image la plus récente qui va me permettre
de faire marcher ma carte et visualiser l'interface de l'OS. Après avoir fait un tour sur le site (lien ci dessous)
http://wiki.banana-pi.org/Banana_Pi_BPI-R1
qui propose différentes images et ne sachant vraiment lequel choisir, j'ai choisi de mettre un Armbian 2016 et
et avec la même commande me permettant de copier sur carte SD que l'OpenWrt afin de le mettre sur la carte
. Au final, cela marche, et je me connecte avec "root" qui a pour mot de passe "1234". Après s'être connecter
on obtient cette interface.
Sachant que je suis énormément en retard par rapport aux deux autres équipes, surtout celui de la
qui a presque terminé sa partie, mon objectif est finalement à ce que ma banana PI marche seulement
en tant que routeur Wifi. Et donc en partant de l'OS Armbian et que le principe de la programmation est à
peu près similaire que celle de la Rasberrie PI. Donc je me suis servi du même raisonnement que celui de ce lien :
https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019#Connexion_s.C3.A9rie

La première chose était d'abord d'installer le packtage Hostapd, car c'est ce packtage qui contient tous les
fichiers me permettant d'activer le routeur Wifi :

apt-get install hostapd

Ensuite afin de pouvoir mofidier le fichier de configuration de hostapd qui se trouve dans le répertoire /usr/share/doc/hostapd/examples/ et le coller dans le répertoire /etc/hostapd :

 cp /usr/share/doc/hostapd/examples/hostapd.conf.gz /etc/hostapd
 gunzip /etc/hostapd/hostapd.conf.gz

Et finalement avec l'éditeur de texte nano, on peut modfier le fichier /etc/hostapd/hostapd.confles mots-clefs suivants :

• ssid, indiquez le nom de réseau WiFi ;
• country_code, mettez le code de la France FR ;
• channel
• wpa, activez l'option (mettre à 1) ;
• wpa_passphrase, configurer un mot de passe pour notre réseau (au moins 8 caractères) ;
• wpa_key_mgmt, à configurer à la valeur WPA-PSK.

Enfin il faut definir le chemin du fichier de configuration à l'aide du fichier /etc/default/hostapd :

DAEMON_CONF=/etc/hostapd/hostapd.conf

On relance le service avec la commande  :

service hostapd restart

Au final, on arrive à faire apparaître le nom du reseau de la banana sans fil

Mais le problème, c'est que si on tape le même mot de Passe sur le smartphone, ça nous renvoie erreur d'authentification
au lieu de l'erreur détection IP. Au final, on va de nouveau changé l'OS et de recommencer toute la procédure. Donc le problème du routeur sera résolu l'année prochaine.

---

Pour l'équipe 2 & 3 :

Nous avons créer le script de récupération de tous les fichiers nécessaires, à savoir :

• Le fichier binaire.c ;
• Le fichier sensor.xml ;
• le fichier demande.txt dont l'utilité sera expliqué ci-dessous.

Ce script permet aussi la compilation du fichier C et le lancement des exécutables du programme.

La crontab n'étant pas fonctionnelle sur la Raspberry, nous avons choisi un autre moyen pour permettre la répétition du script.
Nous avons crée le script ci-dessous, qui boucle toutes les 15 secondes (possibilité de modifier le temps).

Pour que le code ne s'exécute que lorsqu'on envoie un nouveau fichier sur le serveur, et pas toutes les 15 secondes, on reçoit le fichier demande.txt.
Ce fichier contient le numéro de la demande (stocké dans la base de données).
En récupérant le numéro et en le comparant à la dernière version reçue (stockée dans un autre fichier texte), on peut savoir si une nouvelle demande est réalisée.
Si ce n'est pas le cas, le programme ne lance pas l'exécutable du fichier binaire.c.
Ces différentes étapes se font dans le fichier blink.c.

Il est possible de se demander pourquoi nous avons 2 exécutables, et pas un seul reçu directement du serveur. Voici les différentes raisons :

• L'exécutable blink nous permet de gérer l'exécution ou non de binaire.
• En supposant le projet plus avancé, il est préférable de séparer la partie récupération du capteur et le programme en lui même, car différents capteurs pourraient ne pas utiliser le même code et pourraient être placés sur différentes Raspberry.

---

Documents Rendus

• Gitlab : Git IMA3 P10
• Site web  : Site
• Rapport : media: Rapport_IMA3_P10.pdf

Projet S7

Objectifs

Pour l'équipe 1 :

• Remplacement de Ziyad Houssaini par Loris Ahouassou.
• Notre équipe s'occupe de la partie routeur, qui doit être reprise au début.
• Les objectifs sont de fournir un accès internet aux Raspberrys, et de permettre l'envoi des fichiers de données aux bonnes Raspberry.

---

Pour l'équipe 2 :

• Maintenant que nous avons réussi à scruter le serveur pour y récupérer les fichiers, et que l'allumage des LEDs est fonctionnel, il faut qu'on configure les Raspberry pour qu'elles fournissent un retour au serveur.
• Parallèlement à ça, nous devons permettre la reconfiguration de plusieurs types de microcontrôleurs (Cortex M0 ou M4, Atmega328p) à partir de la Raspberry. Ainsi, peut importe le capteurs (situés sur n'importe quel type de microcontrôleurs), il sera utilisable sans besoin de le reprogrammer directement.

---

Pour l'équipe 3 :

• Lors du S6, notre équipe à réaliser une interface Web statique permettant à l'utilisateur de dialoguer avec un serveur et une Raspberry Pi. Il faut maintenant le rendre dynamique en ajoutant un Framework Java Script (Vue.JS) et créer un nouveau système permettant l'affichage des données reçues.
• Parallèlement, il faut créer une nouvelle table dans laquelle seront entrées les données reçues des capteurs. Le routeur devra donc réaliser du pré-traitement afin d'entrer les valeurs reçues dans la base.

---

Documentation

Pour l'équipe 1 :

• Banana Pi

http://hardware-libre.fr/2015/01/bpi-r1-open-router-first-look/

---

Pour l'équipe 2 :

• Passage en mode DFU

https://www.arduino.cc/en/Hacking/DFUProgramming8U2

• Flasher un Arduino sans programmer

https://welldoneblog.fedevel.com/2015/04/13/how-to-flash-arduino-bootloader-without-a-programmer/

• Datasheets

https://produktinfo.conrad.com/datenblaetter/175000-199999/191789-an-01-fr-plat_uno.pdf
https://www.farnell.com/datasheets/1682209.pdf
https://www.mouser.com/pdfdocs/Gravitech_ATMEGA328_datasheet.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/DDI0432C_cortex_m0_r0p0_trm.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/DDI0439B_cortex_m4_r0p0_trm.pdf

• Connexion entre RPI & Atmega328p

http://hardware-libre.fr/2014/04/rapberry-pi-atmega-bridge-presentaion/
http://hardware-libre.fr/2014/04/raspberry-pi-atmega-bridge-branchements/
http://hardware-libre.fr/2014/04/raspberry-pi-atmega-bridge-installation/
https://www.instructables.com/id/Connect-Your-Raspberry-Pi-and-Arduino-Uno/
https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/overview

• Arduino UNO & Raspberry Pi SPI

http://ozzmaker.com/program-avr-using-raspberry-pi-gpio/
https://davecturner.github.io/2019/02/23/programming-avr-microcontrollers.html

---

Pour l'équipe 3 :

• Vue.js

https://fr.vuejs.org/v2/guide/index.html

• JavaScript

https://openclassrooms.com/fr/courses/2984401-apprenez-a-coder-avec-javascript

---

Réalisation

Pour l'équipe 1 :

Cette partie a été mise en suspend car elle n'est pas indispensable au fonctionnement du projet.

---

Pour l'équipe 2 :

Ce semestre, nous avions pour objectif de faire communiquer la Raspberry Pi avec l'Arduino UNO en ICSP.
Nous devons utiliser l'Arduino UNO comme support pour les différents capteurs. Ainsi, la Raspberry n'aura qu'un rôle intermédiaire de compilation.
Il faut donc que l'on connecte ensemble ces deux cartes. Nous avons choisi de ne pas passer pas les ports USB, car dans le cas contraire, notre projet est assez simplifié. Nous avons choisi de passer par les pins SPI pour connecter l'ensemble. Ainsi, nous avons effectué quelques manipulations, expliquées ci-dessous.

• Installation de avrdude

apt-get install avrdude
avrdude -v (pour vérifier l'installation)

• Configuration de avrdude

cp /etc/avrdude.conf ~/avrdude_gpio.conf
nano ~/avrdude_gpio.conf

Nous avons cherché cette partie du code :

#programmer
#  id    = "linuxgpio";
#  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
#  type  = "linuxgpio";
#  reset = ?;
#  sck   = ?;
#  mosi  = ?;
#  miso  = ?;
#;

Pour la changer en :

programmer
  id    = "pi_3";
  desc  = "Use the Linux sysfs interface to bitbang GPIO lines";
  type  = "linuxgpio";
  reset = 4;
  sck   = 11;
  mosi  = 10;
  miso  = 9;
;

• Test de connexion

avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v

Nous avons néanmoins rencontré un problème concernant les pins. La Raspberry n'arrivait pas à exporter certains pins :

• Erreur rencontrée

can't export GPIO 10, already exported/busy?

La même erreur survenait pour d'autres pins.

Après quelques recherches, nous avons trouvé comment régler ces problèmes.

• Nous avons visualisé donc les GPIOs non exportés à l'aide de la commande suivante

gpio exports

Cela nous a permis d'exporter manuellement les GPIOs concernés.

• Pour exporter manuellement les GPIOs dont nous avions besoin :

echo 4 > /sys/class/gpio/unexport
echo 10 > /sys/class/gpio/unexport
echo 11 > /sys/class/gpio/unexport

Suite à cela, la Raspberry pi était désormais capable de se connecter à l'atmega328p.

• Création d'un programme test à l'aide de l'IDE Arduino

Nous avons utilisé un programme exemple disponible dans l'IDE. Nous avons activé la compilation dans les préférences et compiler le programme blink qui fait clignoter une led (GPIO 13). Ensuite, nous avons uploadé le fichier .hex créé sur l'Arduino UNO.

avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v -U flash:w:/tmp/build4952970404801881316.tmp/Blink.cpp.hex:i

• Résultats

Média:Avrdude.txt On observe bien clignoter la led branchée sur le GPIO 13, ce qui veut dire que l'upload a fonctionné.

Il nous faut maintenant compilé notre fichier C pour pour obtenir le fichier .hex.
Pour cela nous allons créer un Makefile.

• Problèmes rencontrés

Nous avons tenté de compiler notre code avec le Makefile d'Arduino. La compilation s'effectue sans problème mais lorsque le code est uploadé sur la carte, la LED s'allume et ne clignote pas comme elle devrait le faire.
Nous avons essayé de faire un Makefile en partant de celui utilisé en tutorat de Système.
Après modification, nous n'arrivons pas à compiler car le compilateur n'arrive pas à accéder à la librairie wiringPi.
En effet, nous avons réfléchi à notre Makefile en considérant le code prévu pour la Raspberry Pi. Cependant, le code était destiné à l'ATMega328p, d'où l'erreur lors de la compilation.

• Résolution des problèmes

Nous nous sommes rendu compte que la librairie wiringPi n'était pas utile et surtout pas utilisable sur l'ATMega328p.
En la remplaçant par les librairies avr/io et util/delay, le projet compile sans erreur et s'execute correctement sur l'ATMega328p.

---

Pour l'équipe 3 :

Cette partie sera traitée au S8.

L'objectif sera de créer une nouvelle table sans la base de données, permettant de récupérer les données venant des capteurs (des Raspberrys).
Il faudra également modifier le site afin d'ajouter une page permettant l'affichage de ces données.

---

Documents Rendus

• Pré-Rapport : media: Rapport_P10_S7.pdf

Projet S8

Objectifs

Suite à la soutenance de projet en fin de S7, nous avons de nouveaux objectifs :

Objectif
Rendre automatique la création du fichier .hex grâce à un Makefile ; Permettre l'upload à partir du Makefile.
Adapter la procédure au Cortex M4 ; Permettre la distinction entre ATMega328p et Cortex M4.
Envoyer un code permettant d'utiliser les capteurs que nous avons commandé ; Récupérer les valeurs de retour pour les envoyer sur le serveur.
Déployer le réseau sur environ 50 Raspberry Pi à l'aide d'Ansible.
Ajouter au site web une page permettant l'affichage des données venant des capteurs ; Créer un programme permettant le versement des données venant des capteurs sur le serveur.
Si le temps nous le permet, utiliser la Banana Pi comme point d'accès internet.

Documentation

• Connexion SPI

https://www.arduino.cc/en/reference/SPI
https://zestedesavoir.com/forums/sujet/2574/communication-via-rx-et-tx/

• TX/RX à partir de GPIO

https://github.com/adrianomarto/soft_uart
https://oscarliang.com/raspberry-pi-and-arduino-connected-serial-gpio/

• Communication SSH

https://geekeries.org/2016/10/transferts-scp-sans-mot-de-passe/?cn-reloaded=1

• Script PhP

http://www.manuelphp.com/php/function.ssh2-connect.php
https://www.developpez.net/forums/d702424/bases-donnees/mysql/debuter/remplir-base-fichier-texte/
https://www.php.net/manual/fr/function.scandir.php
https://www.php.net/manual/fr/function.array-diff.php

• Script Python

https://www.quennec.fr/trucs-astuces/langages/python/python-modifier-la-valeur-dune-balise-dun-xml-en-fonction-de-la-valeur-de-son-attribut
http://dridk.me/python-requests.html

Répartition du travail par équipe

• Equipe 1 - Loris Ahouassou

Intégrer les capteurs aux cartes et permettre le retour de données.

Script pour placer les données du port série dans fichier avant l'envoi au serveur

• Equipe 2 - Eymeric Capronnier - Thomas Mertz

Travailler sur le déploiement du réseau avec Ansible.

• Equipe 3 - Guillaume Rouillé

Réaliser le Makefile pour automatiser l'upload du code envoyer depuis le site web ;

Effectuer les modifications au niveau du serveur et du site web ;

Permettre l'envoi des données provenant des capteurs des Raspberry Pi au serveur.

Réalisation

Equipe 1

Ici, il s'agira d'utiliser les capteurs afin d'obtenir des données "concrètes" à renvoyer à la RaspberryPi.
Il s'agira également, avant envoi au serveur (cf Équipe 3), de récupérer les données sur le port série de la Raspberry afin de les stocker dans les fichiers adéquats.

Objectif	État
Tester l'envoi de données sans capteurs avec la liaison USB	Fait
Tester l'envoi de données sans capteurs avec la liaison série UART TX/RX	Annulée
Intégrer le capteur de température et envoi des résultats au port série via USB	Fait
Intégrer le capteur ultrasons et envoi des résultats au port série via USB	Fait
Depuis la Raspberry, script de stockage des résultats dans fichier XML	Fait
Faire de même avec la Nucleo M4	En pause (PBs techniques)
Depuis la Raspberry, modification du script python d'envoi des données au serveur pour distinguer automatiquement l'adresse IP et obtenir le numéro du capteur	Fait
Ajustement des codes capteur et Température de façon à ce qu'ils utilisent tout les deux une fonction généraliste de retour de données	Fait
Mise en place d'un unique makefile généraliste pouvant uploader le bon code selon le type capteur (makefile déjà en place, quelques ajouts manquants sont en cours)	En cours

Semaine 1

• Retour des données

Dans un premier temps, nous devons chercher à récupérer les données issues des capteurs pour les transmettre à la RaspberryPi.
Dans un second temps, nous allons gérer la transmission des données de la RaspberryPi vers le serveur.

Pour le premier volet, nous allons commencer par réaliser un test (sans capteurs) et récupérer un caractère envoyé par l'Arduino UNO vers la Raspberry Pi en liaison série.

Pour se faire, plusieurs moyens s'offrent éventuellement à nous : l'utilisation du bus SPI ou de la liaison série par l'intermédiaire de l'USB (ou USART TX-RX). Nous avons opté pour cette dernière solution plus simple à mettre en place.

Notre premier test a été réalisé avec la liaison USB. Ainsi, nous avons flashé l'Arduino UNO avec un code (arduinoToRpi.c) permettant d'envoyer un caractère sur la liaison série et qui pourra être vu par la RaspberryPi.

Ce code est inspiré de celui utilisé dans le tutorat système du S7.

Pour lire ce qui se trouve sur la liaison série, nous avions plusieurs solutions.

• La première était d'installer minicom sur la Raspberry, mais après plusieurs tentatives d'installation (car le réseau était plutôt défavorable à ce moment là), nous avons changé d'idée.
  
• Deuxièmement, nous nous sommes penchés sur l'utilisation d'un script python minimaliste à l'aide du module "Pyserial", qui n'a pas fonctionné. Nous pensons que le problème n'est pas tant lié au code en lui-même, qui nous semble correct, mais en la configuration de la RaspberryPi.

#!/usr/bin/env python
import serial
ser = serial.Serial('/dev/ttyACM0', 9600, timeout=1)
while 1:
  print(ser.readline())

• La troisième tentative fonctionnait. Nous avons récupéré un code C permettant de lire le port que nous souhaitions. Le caractère envoyé par l'Arduino a bien été récupéré.

Nous avons donc réussi à faire communiquer la Raspberry Pi et l'Atmega328P dans les deux sens.

Maintenant, l'objectif est de permettre le retour Atmega328P-->RaspberryPi non pas par USB mais en utilisant l'USART (via les broches Tx-Rx).

---

Semaine 2

La séance suivante, nous avons réglé le problème empêchant le script python de s'exécuter correctement. En effet, son exécution supposait un contrôle du port serie par l'intermédiaire du terminal, mais il fallait l'autoriser au préalable.

1- Démarrer l'utilitaire de configuration système de la Raspberry:

sudo raspi-config

2- Ouvrir les options d'interface serie
3- Choisir "oui" pour accepter le contrôle via le terminal

Nous avons ensuite mis à jour la Raspberry Pi avec la commande apt update Cette mise à jour a permis le téléchargement et l'installation de minicom. Il nous est donc plus facile de visualiser le contenu arrivant sur le port série.
Nous avons remarqué que la Raspberry Pi ne possédait qu'un unique UART. Ainsi, si nous voulons exécuter des scripts dans le terminal qui utilise le port série, nous ne pouvons pas en même temps récupérer les données via l'UART.
Pour résoudre cette difficulté, nous avons choisi de travailler avec un "soft uart". Celui-ci devrait nous permettre d'utiliser d'autre GPIOs de la Raspberry en tant que port série (TX, RX).

Nous avons donc utilisé un module créé par Adriano Marto, nous permettant de réaliser cette opération :

https://github.com/adrianomarto/soft_uart

Après le téléchargement, nous avons tenté de faire un "make" comme demandé. Cependant, il semblerait que la version du packet raspberrypi-kernel-headers que nous avons installé précedemment ne corresponde pas au noyau de notre Raspberry.
Le problème est que ce sont des téléchargements automatiques donc nous ne pouvons pas choisir la version.
La version du noyau étant inférieure à celle du packet, nous avons essayé la commande apt upgrade. Après la mise à jour, il semblerait que nous disposions déjà de la dernière version du noyau.

---

Semaine 3

Au démarrage de la Raspberry, nous avons lancé par hasard la commande uname -r. Nous avons été surpris de voir que la version du noyau correspondait maintenant à celle du packet raspberrypi-kernel-headers.
Nous avons donc tenté l'installation du soft uart, avec succès. Il nous fallait maintenant envoyer des données depuis l'Arduino UNO pour les récupérer via TX/RX.
Nous avons réalisé un diviseur de tension pour faire correspondre la tension des pins de l'Arduino UNO (5V) et de la Raspberry (3.3V).
Une fois les branchements fait, nous avons créé grâce à l'IDE Arduino un code utilisant la bibliothèque Serial.h. Ce code devait simplement envoyé un caractère sur la liaison TX/RX.

Là, nous avons rencontré un problème : nous ne reçevions aucune donnée. Nous avons donc décidé de passer par les pins RX/TX de la Raspberry et de laisser de côté le soft uart.
Le problème persistant toujours, nous avons donc décidé ce mettre provisoirement de côté la partie communication par RX/TX pour avancer sur le reste, car la communication par liaison USB série fonctionne correctement.

En étant connecté par liaison USB, l'objectif consistait maintenant à connecter les capteurs et ainsi transférer de vraies données à la Raspberry. Pour se faire, il nous fallait donc écrire les codes utiles pour tester ces capteurs en utilisant le langage C avec la librairie avr.

• Test du capteur de température ST039:
  

Il est basé sur le LM35 et délivre un signal analogique variant entre 0 et 5V selon la température mesurée. La température résultante quant à elle se situe sur la plage 0-100°c avec une précision de 0.5°c.

1-Branchement :
Ci-dessous, le branchement avec une carte Arduino uno.

2 - Code :
Nous disposons déjà des fonctions d'envoi de caractères sur le port série. La principale difficulté de ce code résidait dans l'utilisation du convertisseur analogique-numérique afin de lire sur l'entrée analogique voulue.
Pour cela, nous avons créé une fonction (équivalente à AnalogRead() de L'IDE arduino) nous retournant le résultat numérique de la conversion.

int analogReadNew(uint_8 pin){
   //Selection de la fréquence du prescaler
   ADCSRA |= (1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0);
   //Définition de la référence de tension
   ADMUX |= (1<<REFS0)|(1<<ADLAR);
   //Sélection de l'entrée analogique selon le pin
   ADMUX = (ADMUX&0xf0)|pin;
   //Activation de l'ADC 
   ADCSRA |= (1<<ADEN);
   //Lancement de la conversion
   ADCSRA |= (1<<ADSC);
   //On attend la fin de la conversion
   while(bit_is_set(ADCSRA, ADSC));
   //Résultat
   return ADCH;
 }

Ensuite, il nous fallait normaliser ce résultat afin d'avoir la température en degrés.

 reading=analogReadNew(0);
 temperature = reading * 1.9607843;
 //1.960743 = (5.0/1023.0)*100*4

La température était ensuite envoyée sur le port série pour être visible depuis la RaspberryPi.

3 - Résultat

Semaine 4

Cette quatrième semaine a servi à tester le capteur de distance et à intégrer les données recueillis par la Raspberry dans un fichier.

• Test du capteur à ultrasons HC-SR04 :
  

Ce capteur ultrason utilise le principe de fonctionnement d'un capteur laser mais se base sur des ondes sonores (inaudibles pour l'homme) à la place d'un faisceau lumineux. Il est beaucoup moins cher qu'un capteur laser, toutefois il reste imprécis. On note néanmoins que ses mesures restent insensibles à la luminosité ambiante et à l'opacité de la surface en face.
Le HC-SR04 fonctionne avec une tension d'alimentation de 5V, un angle de mesure d'environ 15° et permet (sur le papier) d'obtenir des mesures de distance variant de 2cm à 4m avec une précision de 3mm (en pratique, ce n'est pas si précis que cela).

1 - Principe de fonctionnement :

En utilisant la vitesse du son, les étapes d'une prise de mesure sont les suivantes :

- Une impulsion HIGH de 10µs est envoyée sur la broche TRIGGER du capteur.

- Ensuite une série de 8 impulsions ultrasoniques est envoyée par le capteur

- Puis, dans l'air, les ultrasons se propagent pour toucher un obstacle et font le chemin retour vers le capteur.

- Enfin, le capteur capte l'écho et achève la prise de mesure.

Précisons que le signal présent sur le pin ECHO du capteur reste à HIGH durant les deux dernières étapes, permettant ainsi de connaître la durée de l'aller-retour des ultrasons et donc de déterminer la distance.

2 - Branchement :

3 - Code :

Le code consiste à réaliser les étapes décrites ci-dessus et à transférer le résultat sur le port série. La seule difficulté ici réside dans la mise en place de l'acquisition du temps d'aller-retour. Pour cela, nous utiliserons un timer et nous procéderons par interruption (INT0) sur un changement logique.

 //Trigger = PIND0 et ECHO = PIND2
 DDRD = 0b11111011;
 _delay_ms(50);
 //Selection INT0
 EIMSK |= (1<<INT0);
 //Interruption sur changement logique
 EICRA = 0x01;
 sei();

Nous mettons en place le trigger :

 //TRIGGER HIGH
   PORTD |= 1<<PIND0;
   //Durée de l'impulsion TRIGGER
   _delay_us(10);
   //TRIGGER LOW
   PORTD &= ~(1<<PIND0);

À chaque interruption, nous mesurons la durée :

 ISR(INT0_vect){
   //i=1 indique l'écho HIGH
   if(i == 1)
   {
     //On arrête le timer
     TCCR1B = 0;
     //On stocke la valeur précédente du timer (l'aller-retour)
     pulse = TCNT1;
     //On reset la valeur de TCNT1 et de i à Zero
     TCNT1 = 0;
     i = 0;
   }
   
   //i=0 indique l'écho à LOW
   if(i==0)
   {
     //On set le bit CS10 à HIGH, debut du timer qui compte
     TCCR1B |= (1<<CS10);
     i = 1; 
   }
  }

La durée mesurée est ensuite normalisée et on effectue le calcul pour obtenir la distance (ici, en cm) qui sera ensuite envoyée sur le port serie.

 //On calcule la distance en cm : pulse/(58/2/10)  (en cm)
   count_a = pulse/1160.0;

La distance est ensuite envoyée sur le port serie pour être disponible sur la RaspberryPi.

4 - Résultat :

Tout fonctionne correctement, ci-dessous un capture du résultat:

• Coté Raspberry : Préparation des résultats pour envoi au serveur

Ici, les résultats sont disponibles uniquement sur le port serie. Ce que nous voulons, c'est les stocker dans un fichier qui sera ensuite exportable vers le serveur. Pour cela, nous nous sommes entendus sur le format XML. En effet, comme il a été mentionné plus bas par l'équipe 3, nous devons avoir un fichier de cette forme :

 <capteur>
     <parametre name="ip_address">172.26.145.X</parametre>
     <parametre name="numero">Y</parametre>
     <parametre name="name">Nom</parametre>
     <parametre name="data">AB.C</parametre>
 </capteur>

Pour cela nous avons réalisé un script Python en usant du module serial et du module lxml pour créer des fichiers XML.

Installation du module lxml

 pip3 Install lxml

Le programme récupère la donnée sur le port série et la met à sa place préétablie dans un fichier xml de base existant.

 import serial
 from lxml import etree
 capteur = etree.parse("111-1.xml")
 ser = serial.Serial("/dev/ttyACM0", 9600, timeout = 1)
 
 value = ser.readline()
 while(value in ['\r', ]): 
      value = ser.readline()
 value = float(value)
 for parametre in capteur.getroot().getchildren():
      if "name" in parametre.attrib and parametre.attrib["name"] == "data":
          parametre.text = str(value)
 with open("111-1.xml", 'w') as myFile:
      capteur.write("111-1.xml")
 myFile.close()

Nous avons testé ce script et c'est fonctionnel. Nous sommes désormais capables de renvoyer les données issues des capteurs jusqu'au serveur.

Semaine 5

• Retour des données par requête POST

Le retour des données étant effectif, cette cinquième semaine a été l'occasion de faire une petite démonstration à nos encadrants concernant l'aller (flash) et le retour des données.

Il en est ressorti une suggestion quant à la partie de l'équipe 1 :

- Au lieu d'utiliser un système de fichier au format XML, il nous a été suggéré d'utiliser une simple requête POST dans notre script python pour envoyer nos données. (cf Équipe 3 pour plus de détails).

• Différenciation des capteurs

Pour notre retour de données, nous voulons diversifier nos cas de tests. En effet, nous aimerions avoir :

Cas 1 : un capteur de température ou de distance relié à une carte
Cas 2 : deux capteurs différents reliés à une même carte
Cas 3 : deux capteurs identiques reliés à une même carte

Il faut donc que nous soyons capables d'identifier clairement nos capteurs afin de pas confondre les données remontées.

[voir la méthode].

De cette façon, il nous sera plus facile d'identifier nos capteurs (en particulier dans les Cas 2 et 3). Le script python se chargera de découper la chaîne reçue pour extraire chacun des paramètres et ainsi faire la requête POST par la suite.

---

Equipe 2

Liste des choses à installer de base sur les Raspberry Pi :

- Connexion ethernet : interface eth0 dans /etc/network/interfaces (address : 172.26.145.X, netmask : 255.255.255.0, gateway : 172.26.145.254), DNS dans /etc/resolv.conf (name-server : 193.48.57.48), ifup eth0 ;
- Le script load.sh qui devra être modifié pour prendre en compte Ansible (plus de wget par exemple, et différenciation des Arduino et Nucléo) ;
- Le script script.sh ;
- Le dossier "Build" avec surtout le Makefile ;
- Les scripts de réception des données via liaison série et d'envoi par requête POST (Rpi_to_server.py) ;
- La commande : 'pip3 install lxml' ;
- La commande : 'import requests'.

Semaine 1

Recherches concernant Ansible

Interet d'utiliser Ansible par rapport à d'autres logiciel : Il fonctionne en python (Chef et Puppet utilisent ruby) Si nous voulons utiliser Python 3 (car python 2 n'est plus maintenu depuis le premier janvier) il nous faut Ansible 2.5 ou supérieur.

On pourrait utiliser "python-virtualenv" pour faciliter la compatibilité de nos scripts entre les versions de nos logiciel ou utiliser docker

Il n'est pas nécessaire d'installer Ansible sur chaque noeud (dans notre cas les raspberry pi) seulement sur un serveur qui sera notre "node manager" (Ce dernier devant etre un système UNIX). Les noeud devrons juste permettre le ssh. Le reste pourra etre installé grace à Ansible.

le node manager doit pouvoir connaitre les addresses IP de ses nodes. (dns ou fichier /ect/hosts) Utilisation de clé ssh pour sécuriser la communication (ex : ssh-keygen -t ecdsa)

---

Semaine 2

Ce qu'il faut definir pour aller plus loin :

- Comment récupère-t-on la liste des adresses des nodes à paramétrer
- Quels sont les logiciels à installer ainsi que les paramétrages à effectuer pour notre application.
- Ansible doit il également déployer les codes sur les raspberry pi, si c'est le cas, peut il etre appelé automatiquement par le serveur web ?

Les commandes ansibles pourront être exécuté par script bash (faut-il séparer le setup des cartes et l'update de code ?)

On peut copier le code sur chaque machine (ou groupe de machine) en utilisant le module "copy" d'ansible.

Ansible peut également exécuter des scripts shell sur les machines distantes : module "shell".

Il serait utile d'utiliser le module "docker_container" pour permettre un versioning facile et supprimer les problèmes de compatibilité.

Ensuite il semblerait qu'Ansible puisse réagir à des événements grâce à l'utilisation de "wait_for". Dans notre cas, cela serait utile pour envoyer les codes au raspberry pi lorsqu'on le souhaite.

Dans mon idée actuelle :

• Ansible met en place les raspberry pi pour qu'ils soient pret à exécuter du code
• Ansible envoi le code sur les raspberry pi (Quand un utilisateur le demande).
• Les raspberry pi renvoyent leurs données directement au serveur principale.

---

Semaine 3

Premiers pas avec Ansible :

• Installation de la dernière version d'Ansible à l'aide de pip :

pip3 install ansible

Il faut donc avoir python 3.5+ installé, posibilité de choisir la version d'ansible (pip3 install ansible==2.9.4)

On peut vérifier si l'installation est correcte avec la commande :

ansible --version

Pour communiquer avec nos noeuds on va les renseigner dans le fichier /etc/hosts. Exemple dans notre cas on ajoute les lignes:

172.26.145.112  rasp1
172.26.145.113  rasp2

Il faut enfin créer un fichier inventaire.ini pour référencer nos noeud, il est pour le moment très simple :

rasp1
rasp2

La seule chose qu'il y a à faire sur le raspberry pi est d'activer le ssh, de regler son adresse ip et de lui donner une connexion internet.

• Première commande Ansible. Un simple ping permet de voir si on arrive bien a communiquer avec notre noeud :

ansible -i inventaire.ini -m ping rasp1 --user pi --ask-pass

-i inventaire.ini : chemin vers le fichier d'inventaire

-m ping rasp1 : action à effectuer sur la cible

--user pi : choix de l'utilisateur qui se connecte

--ask-pass : demande du mot de passe ssh

On peut commencer à parametrer nos nodes. On utilisera pour le moment des lignes de commandes et pas des fichier playbooks.

• Installation de python3 :

ansible -i inventaire.ini -m raw -a "sudo apt-get install python3 -y" rasp1 --user pi --ask-pass

• Installation de WiringPi :

ansible -i inventaire.ini -m raw -a "sudo apt-get install wiringpi -y" rasp1 --user pi --ask-pass

-m raw : pour envoyer une ligne de commande à lancer sur la cible

-y dans le apt-get : permet de valider la demande d'utilisation d'espace sur le disque

Autre possibilité pour la connexion :

On utilise sudo car l'utilisateur pi peut avoir les droits administrateur. On pourrait également se faire cette commande en demandant une élévation de privilèges :

ansible -i inventaire.ini -m raw -a "apt-get install python3 -y" rasp2 --user pi --ask-pass --become --ask-become-pass

On pourrait enfin se connecter directement en utilisateur root, mais cela demanderait plus de préparation sur le raspberry pi :

-Editer le fichier: sudo nano /etc/ssh/sshd_config
-Trouver la ligne: PermitRootLogin without-password
-Editer: PermitRootLogin yes (enlever le # de commentaire)
-Fermer et sauvegarde le fichier
-restart du service sshd: /etc/init.d/ssh restart
-Mettre un mot de passe root: sudo passwd root

• L'idée maintenant serait de supprimer la demande de mot de passe en utilisant le système des clé de sécurité ssh.

Pour créer une clé ssh de type rsa 2048 bits :

ssh-keygen

On n'indiquera pas de passphrase pour permettre un reboot automatique du serveur ansible.

On va ensuite envoyé notre clé publique sur nos noeuds :

ansible -i inventaire.ini -m authorized_key -a 'user=pi state=present key="{{ lookup("file", "/home/pifou/.ssh/id_rsa.pub") }}"' --user pi --ask-pass --become --ask-become-pass all

user=pi correspond à l'utilisateur auquel on donne notre clé

/home/pifou/.ssh/id_rsa.pub correspond au chemin où la clé à été enregistré

all que l'on envoie à toutes les noeuds du fichier inventaire.ini

Maintenant on n'a plus besoin d'utiliser l'option --ask-pass.

---

Semaine 4

Un des but de cette semaine est de créer le fichier d'inventaires de nos nodes Ansible. Cependant nous voulons le rendre dynamique : le fichier contiendrait uniquement la liste des nodes à mettre à jour.

Une idée pourrait être que le site web, lors d'une demande de modification des noeuds, envoi le fichier d'inventaire par scp en utilisant par exemple la commande php : "ssh2_scp_send"

L'idée serait sur le serveur Ansible, de vérifier si le fichier inventaire.ini à bien été déposé. On utilisera un playbook contenant :

---
- name: Wait until the file /home/pifou/inventaire.ini
  hosts: 127.0.0.1
  tasks:
    - wait_for:
       path: /home/pifou/inventaire.ini

Ansible va attendre d'avoir le fichier inventaire.ini avant de continuer son exécution.

On pourra ensuite appeller nos playbook de paramètrage. Exemple avec un simple ping :

---
- name: Ping
  hosts: all
  remote_user: pi
  tasks:(sûrement un ou plusieurs codes C)
    - ping:

Pour le lancement du code on pourra utiliser un script bash :

#!/bin/bash
trap exit SIGINT
while [ 1 ]
do
ansible-playbook playbooktest.yml
ansible-playbook taskPing.yml -i inventaire.ini
rm inventaire.ini
done

---

Semaine 5

Cette semaine nous allons essayer d'avancer sur les playbook pour l'installations de tous les composants sur nos noeuds Ansible.

On voudrait que le fichier inventaire.ini nous donne les informations sur les choses à installer : cela devrait surtout dépendre de si on à une raspberry pi ou autre chose.

Dans l'idée le fichier devrait contenir des groupes tel que [arduino] ou [nucleo] et contenant les ip des machines qu'il faut mettre à jour.

On veut donc que les playbook aient s'exécute suivant le groupe (le type) de machine.

Résultat :

Plusieurs roles ont été créé : arduino_Setup/nucleo_Setup/arduino/nucleo

Les deux premiers serviront pour préparer les cartes arduino pour pouvoir utiliser des arduino ou des nucleo.

Les deux suivant sont les roles de production : ils copieront les fichiers, lanceront la compilation pour les scripts d'execution.

Un premier playbook de mise en place pour les arduino à été commencé. Il permet de mettre en place le proxy, installe python3, minicom, wiringpi, avrdude.

---
- name: Copy file for proxy setup
  copy:
    src: ../files/proxy.conf
    dest: /etc/apt/apt.conf.d/proxy.conf
    owner: root
    group: root
    mode: '0644'

- name: "verif install python3"
  apt:
    name: python3
    state: present

- name: "verif install minicom"
  apt:(sûrement un ou plusieurs codes C)
    name: minicom
    state: present

- name: "verif install wiringpi"
  apt:
    name: wiringpi
    state: present

- name: "verif install avrdude"
  apt:
    name: avrdude
    state: present

---

Semaine 6

La totalité des logiciels et packages à installer sur le raspberry pi ont été ajoutés sur le playbook d'installation (un fichier yaml séparer pour mieux se retrouver dans le code ) : python3, pip3, wiringpi,avrdude, lxml pkg, requests pkg, pyserial pkg.

Il sera très facile d'ajouter un nouveau paquet si nécessaire.

Pour la partie installation il faut encore transferer les fichiers sur les raspberry pi (makefile ...)

Le role de fonctionnement en "production" à été ajouté. Il aura pour but de transferer le fichier binaire à compiler et de lancer le script bash de fonctionnement. Avec le fonctionnement conditionnel on peut également avoir plusieurs capteurs qui travaillent en même temps.

Pour l'instant le fichier est récupèrer sur le site web. Cela pourrait changer si nécessaire (utilisation de la fonction "copy").

---
- name: "envoyer du fichier binaire.c"
  get_url:
    url:  http://serveur-etu.polytech-lille.fr/~grouille/PROJET/upload/binaire.c
    dest: /home/pi/capteur{{capteur}}/binaire.c
    mode: '0644'

Enfin le fichier inventaire.ini a prit sa forme "définitive". On retrouvera ainsi les adresses IP des raspberry pi à mettre à jour (setup ou prod) avec l'information du capteur.

[Arduino_init]
172.26.145.112 capteur=1
172.26.145.113 capteur=2

[Arduino]
172.26.145.112 capteur=1

Pour l'instant nous n'arrivons pas à utiliser correctement ansible pour le lancement de nos scripts bash. Cela vient du fait qu'ils contiennent des boucles infini et que Ansible attend la fin de l'exécution.

---

Semaine 7

Nous arrivons à bien envoyer les fichiers sur les raspberry pi. Pour chaque capteur on va donc créer un dossier qui contiendra tous les fichiers de code et de lancement. Pour le moment on récupère également le fichier zip sur le serveur.

- name: "Creation des dossiers pour le capteur"
  file:
    path: /home/pi/capteur{{capteur}}
    state: directory

- name: "Download and unzip files"
  unarchive:
     src: http://serveur-etu.polytech-lille.fr/~grouille/PROJET/fichiersRPI/fichiersRPI.zip
     dest: /home/pi/capteur{{capteur}}
     remote_src: yes 

Nous avons enfin réussi à lancer correctement les fichiers bash avec ansible. Le problème était la boucle infini et également que le processus s'arretait lorsque ansible quittait.

Du coté ansible l'appel est assez classique :

---
- name: Lancer le fichier bash
  hosts: all
  remote_user: pi
  become: yes
  tasks:
     - shell: /home/pi/capteur3/lancer.sh

La modification importante est la création du fichier lancer.sh qui va lui appeler le script en mode nohup ( et kill le processus s'il existait déjà) :

#!/bin/sh

kill $(cat /var/run/script.pid)
base=`dirname $0`
nohup $base/script.sh &

Pour récupérer le pid de script.sh il faut ajouter en haut dans ce script la ligne :

echo $$ > /var/run/script.pid

---

Semaine 8

Avec l'arrivée du Coronavirus nous avons besoin de migrer notre projet sur un autre serveur. Il est disponible au 172.26.189.200 avec nos fichiers dans /var/www/html/P10.

Les fichiers seront mis à jour en utilisant notre repository git.

Un problème qu'il nous reste à régler est l'automatisation du transfert des clé ssh du serveur vers les cartes raspberry. Actuellement ce processus n'est pas automatique.

---

Equipe 3

Objectif	Etat
Créer une page web dynamique (rafraîchissement des données)	Fait
Créer des fichiers "de retour" vides sur le serveur pour chaque capteur	Fait
Créer un Makefile pour automatiser l'envoi jusqu'au microcontrôleur.	Fait
Créer un script permettant la compilation et l'upload des fichiers grâce au Makefile	Fait
Permettre l'ajout d'un capteur sur le site	Fait
Créer un script PhP permettant d'entrer les données présentes dans les fichiers dans la base de données (lié au dynamisme de la page)	Fait
Modifier le script shell pour lui permettre d'envoyer les fichiers de données des capteurs en ssh sur le serveur	Fait
Mettre sous forme de fichier .ini les données relatives à l'identification des Raspberry Pi et des capteurs sélectionnés sur le site	Fait
Faire un requête POST depuis les Raspberry pour envoyer les données sur le serveur.	Fait
Modifier le site et la base de données pour créer un historique des valeurs des capteurs.	Fait
Rendre accessibles depuis le site les données historiques des capteurs, et créer un système de filtre.	Fait
Permettre la sélection de plusieurs capteurs de même type depuis le site.	Fait
Migrer le site sur le nouveau serveur 172.26.189.200.	Fait
Lancer Ansible depuis le site.	A faire

Semaine 1

• Makefile et script shell

Nous avons créé un Makefile à l'aide du cours de PSR.
De ce fait, il nous suffit maintenant de faire un make upload pour envoyer le code sur l'Arduino UNO.
Le script load.sh a été légèrement modifié pour que le programme fonctionne correctement :

#!/bin/sh
wget -N -P ./ http://houplin.studserv.deule.net/~grouille/PROJET/upload/binaire.c
wget -N -P ./ http://houplin.studserv.deule.net/~grouille/PROJET/upload/sensor.xml
wget -N -P ./ http://houplin.studserv.deule.net/~grouille/PROJET/upload/demande.txt
gcc -o program program.c -lwiringPi
./program
cp binaire.c Build/main.c
cd Build
make clean
make upload

Maintenant, tout est automatisé de l'envoi du fichier à partir du site web jusqu'à l'exécution du programme sur l'ATMega328p.

---

Semaine 2

• Modification du site Web

L'objectif de cette partie est de mettre à jour le site pour qu'il puisse afficher les données reçues par les capteurs.
Pour se connecte à la base de données depuis un terminal, il est maintenant nécessaire d'entrer la commande : psql -h serveur-etu.polytech-lille.fr -U grouille projetCapteurs avec le mot de passe postgres.
Depuis un navigateur Web : https://pgsql.polytech-lille.fr/
Dans un premier temps, il faut ajouter une nouvelle table dont le contenu reste à déterminer en fonction de ce que retourne les Raspberry comme données.

Nous avons décidé de choisir d'utiliser 3 Raspberry Pin, sur lesquelles se trouvent respectivement :

- Un Arduino UNO avec un capteur de température et un capteur de distance ;
- Un Arduino UNO avec un capteur de température ;
- Un Nucléo M4 avec un capteur de distance.

Pour repérer les capteurs depuis le site, au travers des Raspberry, elles sont maintenant liées à leur adresse IP et chaque capteur a un numéro sur la Raspberry.
Il serait intéressant de permettre l'ajout d'une Raspberry depuis le site, en permettant l'ajout de celle-ci dans la liste ainsi que des capteurs qui lui seraient liés.

• Envoi des données sur le serveur

La première idée que nous avons eu est de passer par une connexion ssh entre la Raspberry envoyant les données et le serveur.
Les données seraient ainsi toujours stockées au même endroit sur le serveur et l'envoi serait conditionné d'une simple connexion internet, de la même manière que pour la réception du code.
Il reste à voir avec l'équipe 2 comment Ansible gère le dépoiement des codes et le retour de données.

La deuxième idée est de créer un script PhP directement sur les Raspberry (déployé par Ansible).
Ce script permettrait la connexion au serveur et mettrait automatiquement la base de données à jour.
Plusieurs questions se posent alors :

- Peut-on exécuter un script PhP directement dans le shell ?
- Peut-on utiliser un code HTML pour l'exécuter dans le cas contraire ?
- Serait-il plus propre d'envoyer les données au serveur en ssh et de les traiter par un script qui s'y trouve ?

Le plus intéressant et pratique serait la dernière option. Une connexion ssh entre chaque Raspberry Pi et le serveur s'établierait à chaque fois qu'une valeur de capteur est mise à jour.
Ainsi, lorsqu'on se trouve sur la page de site où se trouvent les valeurs affichées, il faudrait trouver un moyen dynamique de rafraîchir les données pour que les dernières arrivées soient prises en compte.

---

Semaine 3

• Script d'envoi de données par SSH

Pour envoyer les données par SSH, nous allons utilisé le protocole SCP.
Pour se faire, nous devons configurer pour chaque raspberry une connexion SSH via des clés RSA, afin de ne pas devoir entrer manuellement un mot de passe.
Nous avons suivi ce tutoriel : https://geekeries.org/2016/10/transferts-scp-sans-mot-de-passe/?cn-reloaded=1&cn-reloaded=1. Il faudra que cette opération soit effectuée sur chaque Raspberry via Ansible.

Nous allons copier les données vers le serveur. Ces données seront sous forme de fichier XML ayant un nom précis : ip-capteur.xml, de manière à pouvoir avoir plusieurs fichiers de données.
Le fichier XML sera de la forme :

<?xml version='1.0' encoding='UTF-8'?>
<capteur>
    <parametre name="ip_address">172.26.145.X</parametre>
    <parametre name="numero">Y</parametre>
    <parametre name="data">AB.C</parametre>
    <parametre name="date">Date</parametre>
</capteur>

Les données y seront entrées par un script Python.

La commande SCP est la suivante :

SCP /home/pi/Desktop/ip-capteur.xml grouille@houplin.studserv.deule.net:/home/peipa1/grouille/public_html/PROJET/data/

Pour que la copie par SCP fonctionne, il faut retirer tout les 'echo' dans le bashrc sur le serveur.

• Nouvelle manière de mettre à jour la base de données

Il nous a été proposé d'utiliser une requête POST pour mettre à jour la base de données, à la place du système décrit précédemment.
Nous avons donc modifier le script Python de l'équipe 1 pour y intégrer cette requête :

params = {"ip_address":"172.26.145.111", "numero":"2", "data": data, "date": Date}
r = requests.post("http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php", data = params)

Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données de la même manière que update_values().
De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.
Les requêtes SQL d'update s'executeront tour à tour grâce au système de verrous.

Semaine 4

---

• Script PhP/SQL permettant la mise à jour de la base de données

Pour permettre la modification de la base de données et l'affichage de celles-ci sur le site, il nous faut 2 fichiers PhP supplémentaires et une fonction.
Le premier (data.php) sert "seulement" à vérifier que l'utilisateur est bien connecté au site, et à importer le fichiers PhP contenant les fonctions utiles.
Il permet également le rafraichissement de la page toutes les 10 secondes (balise meta).

Le second fichier (values.php) contient deux choses :

- Un tableau fabriqué à partir de requêtes SQL permettant l'affichage des données ;
- L'appel à la fonction de mise à jour.

Explications de la fonction de mise à jour : updates_values()

Cette fonction est stockée dans le fichier accesBase.php, qui est importé dans la page data.php.
Tout d'abord, cette fonction récupère et ouvre tous les fichiers XML sur le serveur à l'aide de la fonction simplexml_load_file().
Ensuite, on récupère les valeurs de chaque attribut pour les stocker dans des variables.
Enfin, on effectue une requête SQL update de ce type : UPDATE capteurs SET value='$data' WHERE raspberry='$ip_address' and numero='$numero' and nom='$name' pour effectuer la mise à jour.

L'appel successif à la fonction de mise à jour puis de récupération des données dans la base permettra le maintient à jour du site.

• Nouvelle manière de mettre à jour la base de données

Il nous a été proposé d'utiliser une requête POST pour mettre à jour la base de données, à la place du système décrit précédemment.
Nous avons donc modifier le script Python de l'équipe 1 pour y intégrer cette requête :

params = {"ip_address":"172.26.145.111", "numero":"2", "name":"Solaris", "data": data}
r = requests.post("http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php", data = params)

Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données de la même manière que update_values().
De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.
Les requêtes SQL d'update s'executeront tour à tour grâce au système de verrous.

---

Semaine 5

• Historique des capteurs

Nous avons créé un système d'historique qui enregistre la date et l'heure de chaque relevé dans une nouvelle table.
Nous allons créer un système de recherche et rendre accessible ces données à partir du site.

En arrivant sur la page de recherche, plusieurs possibilités :

- Sélectionner un capteur spécifique ;
- Sélectionner un type de capteur ;
- Sélectionner une adresse IP ;
- Sélectionner un intervalle de dates ;
- Sélectionne un nombre maximum de résultats.

Il est possible de combiner tous ces critères pour affiner les recherches.
On obtient un tableau contenant les informations utiles des capteurs.

• Ajout d'un capteur depuis le site

Nous avons créé une page permettant d'ajouter un capteur à la liste des présents.
La requête est fonctionnelle et gère les doublons dans la table.
Il reste à utiliser Ansible dans cette partie pour ajouter les fichiers de base sur une Raspberry si elle n'existait pas avant.

---

Semaine 6

• Migration sur un autre serveur

Lien du site : http://projet-p10.plil.fr/
Lien du site à jour avec le git : http://projet-p10.plil.fr/IMA3_P10/site
Fichiers raspberry : http://projet-p10.plil.fr/fichiersRPI

Pour continuer d'utiliser la base de données liée à notre projet, nous avons choisi d'installer PostgreSQL sur le nouveau serveur et d'y recopier l'ancienne base de données.
Elle est maintenant accessible depuis le serveur 172.26.189.200 avec la commande : psql -h localhost -U grouille projetCapteurs et le mot de passe postgres.

Par ailleurs, nous avons ajouté dans la table capteurs le numéro de version du capteur (en lien avec la connectique utilisée) :
- 0 : le capteur est branché en USB sur un Arduino UNO ;
- 1 : le capteur est branché en SPI sur un Arduino UNO ;
- 2 : le capteur est branché en USB sur une Nucléo M4 (optionnel pour le moment).

• Création du fichier .ini à partir du serveur

Pour l'utilisation d'Ansible, il nous faut créer un fichier inventaire.ini lorsque l'on crée un nouveau capteur et lorsque l'on veut envoyer du code sur un ensemble de capteurs.
Pour cela, on a défini des balises :
- [Arduino], [Arduino_spi] et [Nucleo] pour l'envoi de code ;
- [Arduino_init], [Arduino_spi_init] et [Nucleo_init] pour la création de capteurs.

Nous avons différencier 3 versions de capteurs selon la carte sur laquelle ils sont branchés et selon la connectique utilisée entre la carte et la raspberry. Ces versions sont stockées dans la base de données sous forme numérique (0, 1 ou 2) et vont permettre le choix du bon mode de transfert du code sur les cartes (choix du bon Makefile ou choix de version dans un même Makefile, à déterminer par l'équipe 1).

Admettons que l'on veuille envoyer un code sur le capteur 2 connecté en SPI à la raspberry d'adresse 172.26.145.111.
Le fichier inventaire.ini ressemblerait à ça :

[Arduino_spi]
172.26.145.111 capteur=2-1

De cette manière, on pourra récupérer facilement le numéro du capteur et sa version sur la raspberry pour le traitement des données.

---

Confinement

Durant ces semaines de confinement, nous voulions continuer de travailler sur le projet.
Nous avons connecté 2 raspberry (172.26.145.111 et 172.26.145.113) sur le réseau de l'école avec les capteurs qui leur sont liés.
De plus, nous avons mis en place un dépot git sur le serveur qui nous permet de travailler chez nous et de mettre à jour nos données avec un simple git pull.

• Lancement d'Ansible depuis le site

---

Récapitulatif au début du confinement : media: Recapitulatif_p10_debut_confinement.pdf

Documents Rendus

• Gitlab : Git P10
• Site web  : Site (id: admin; pwd: admin)
• Rapport : media: Rapport_final_P10_2019_2020.pdf