IMA3/IMA4 2018/2020 P10

De Wiki de Projets IMA
Révision datée du 8 avril 2020 à 15:18 par Tmertz (discussion | contributions) (→‎Equipe 2)

Sommaire


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

Logo du Laboratoire
Logo du LRI

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é

Schéma Complet

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

S6

Equipe 1

Equipe 2

Equipe 3

S7

Equipe 1

Equipe 2

S8

Equipe 1

Equipe 2

Equipe 3

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 requêtes envoyant les informations mises à jour au serveur.

Cahier des charges des équipes

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

S6

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

S8

  • Créer des scripts permettant d'automatiser la compilation et le lancement les codes reçus depuis le serveur ;
  • Créer les codes pour les différents capteurs disponibles ;
  • Créer un script permettant l'envoi des données au serveur.

Equipe 2 : Eymeric CAPRONNIER, Loris AHOUASSOU (S7), Guillaume ROUILLÉ (S7), Thomas MERTZ (S8)

S6, S7

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

S8

  • Configurer Ansible pour envoyer les données du serveur vers les Raspberrys.

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 ;
  • 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 ce qui est mis en œuvre par l'équipe 2. Il faudra créer une page permettant la mise en ligne de fichiers. Cette page affichera 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 sous plusieurs formes.

Choix techniques : matériel et logiciel

Banana PI R1
Raspberry PI 3

Equipe 1

S6

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

S7, S8

Equipe 2

  • 1x Raspberry Pi ;
  • 1x câble Ethernet ;
  • 4x diodes et résistances (S6);
  • 1x câble HMDI/VGA ;
  • 1x clavier et une souris afin d'utiliser la Raspberry (interface graphique).

Equipe 3

  • Une base de données PostgreSQL pour le stockage des données ;
  • Un interpréteur PhP et un serveur web (Apache).

Liste des tâches à effectuer

Equipe 1

S6

  • Déploiement d'un routeur à base de Banana Pi R1 permettant l'accès à internet aux différentes Raspberry Pi ;
    • 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.

S8

  • Scripts permettant d'automatiser la compilation et le lancement les codes reçus depuis le serveur ;
    • Création d'un Makefile ;
    • Création d'un script de lancement global.
  • Codes pour les différents capteurs disponibles ;
    • Créer un code pour chaque capteur (température, distance) ;
    • Créer une lib contenant une fonction permettant le retour de données via liaison série.
  • Script permettant l'envoi des données au serveur.
    • Créer un script Python permettant la récupération des données sur le port série et l'envoi au serveur par requête POST.

Equipe 2

S6, S7

  • Récupération des fichiers sur le serveur ;
    • Créer un script pour récupérer les fichiers sur le serveur ;
  • Compilation et lancement du code.
    • Créer un Makefile ;
    • Créer un script pour lancer le Makefile de manière automatique.

S8

  • Déploiement des logiciels sur les Raspberry Pi grâce à Ansible.
    • Configuration de la Raspberry PI 3 pour qu'elle soit accessible sur le réseau (adresse IP, routeur, DNS) ;
    • Création du script afin d'envoyer le code reçu aux différents capteurs ;
    • Configuration à distance du microcontrôleur, peut importe son type.

Equipe 3

S6

  • Déploiement du serveur Web ;
    • Création d'une base de données PostgreSQL ;
    • Création d'un site web ;
    • Création d'une interface web utilisateur ;
    • Création d'une page d'envoi des fichiers vers le serveur.
  • Envoi des fichiers sur le serveur ;
    • Créer un script d'envoi du fichier choisit par l'utilisateur 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 ;

S8

  • Ajout de différentes pages ;
    • Page permettant la visualisation de l'historique des données des capteurs ;
    • Page permettant l'affichage de graphes fabriqués à l'aide des données des capteurs ;
    • Pages permettant l'ajout de raspberrys et de capteurs ;
    • Page permettant la visualisation du réseau global.
  • Modification de la base de données ;
    • Ajout d'une table d'historique ;
    • Mise à jour des tables contenant les capteurs et les raspberrys.
  • Envoi du fichier de configuration (.ini) sur le serveur ;
  • Permettre le lancement d'Ansible via le site.

Calendrier prévisionnel

Equipe 1

Dates Objectifs

05/02/19

  • Analyse des concurrents ;
  • Scénario d'usage.

19/02/19

  • Cahier des charges ;
  • Répartition du travail entre équipes.

05/03/19

  • 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/19

  • Recherche de la datasheet du routeur Banana PI-R1, afin de pouvoir comprendre les configurations de la carte et aussi les branchements.

02/04/19

  • Trouver l'open source me permettant de visuliser l'interface de la BPI-R1, et en l'occurrence l'OS OpenWrt.

16/04/19

  • Faire fonctionner la carte et comprendre les fonctionnalités qu'offrent l'OpenWrt.

30/04/19

  • 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/19

  • 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/19

  • 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/19

  • 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/19

  • Reprendre la configuration de la Banana Pi à zéro ;
  • Faire de cette carte un point d'accès Wi-Fi.

29/01/20

  • Faire communiquer l'Arduino UNO et la Raspberry Pi dans les 2 sens.

12/02/20

  • Créer le code pour le capteur de température et visualisation des données sur le port série avec minicom.

19/02/20

  • Créer le code pour le capteur de distance et visualisation des données sur le port série avec minicom.

04/03/20

  • Créer le script Python permettant le retour de données vers le serveur.

25/03/20

  • Créer le Makefile générique.

08/04/20

  • Intégrer la Nucléo dans le projet.

Equipe 2

Dates Objectifs

05/02/19

  • Analyse des concurrents ;
  • Scénario d'usage.

19/02/19

  • Cahier des charges ;
  • Répartition du travail entre équipes.

05/03/19

  • Documentation sur les différents outils : Raspberry et Ansible.

19/03/19

  • Documentation sur l'allumage d'une LED et création des premiers scripts d'allumage de LED.

02/04/19

  • Installation de Raspbian sur la Raspberry PI 3 et début de configuration de la Raspberry PI 3.

16/04/19

  • Configuration de la Raspberry PI 3.

30/04/19

  • Installation de la bibliotèque wiringPI permettant le lancement du script écrit en C permettant l'allumage des différentes LED.

14/05/19

  • Installation d'un premier cablage de LED afin de tester le script d'allumage des LED.

28/05/19

  • 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/19

  • 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/19

  • Réinstaller une image sur la Raspberry Pi sans interface graphique ;
  • Permettre l'accès à internet sur la Raspberry.

21/11/19

  • Permettre la connexion entre la Raspberry Pi et un Arduino Atmega328p.

20/12/19

  • Permettre l'exécution de code sur l'ATMega328p.

08/04/20

  • Rendre Ansible fonctionnel.

Equipe 3

Dates Objectifs

05/02/19

  • Analyse des concurrents ;
  • Scénario d'usage.

19/02/19

  • Cahier des charges ;
  • Répartition du travail entre équipes.

05/03/19

  • Création de la base de données associée au projet ;
  • Documentation Php et lancement du site web.

19/03/19

  • Création du système de connexion du site.

02/04/19

  • Mise en forme correcte du site : page de connexion, d'inscription et d'accueil.

16/04/19

  • Création de l'interface de sélection du capteur.

30/04/19

  • 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/19

  • 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/19

  • 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/19

  • 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/19

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

29/01/20

  • Mise à jour de la table capteurs ;
  • Mise à jour de la page de sélection des capteurs.

05/02/20

  • Créer la page permettant de récupérer les données des capteurs par requête POST ;
  • Créer la fonction de mise à jour de la base de données.

12/02/20

  • Créer la table qui contiendra l'historique de valeurs ces capteurs ;
  • Créer les pages de recherche dans cet historique ;
  • Modifier la fonction de mise à jour de la base de données pour intégrer l'historique.

19/02/20

  • Création des pages permettant l'ajout d'une raspberry ou d'un capteur ;
  • Création des fonctions associées.

04/03/20

  • Créer le fichier inventaire.ini utile à l'équipe 2 à partir du site à l'ajout d'un capteur ou l'envoi d'un code ;
  • Migration du site et de la base données sur un nouveau serveur sur plil.fr.

18/03/20

  • Créer les pages permettant l'affichage des graphes de valeurs des capteurs ;
  • Création des fonctions associées.

25/03/20

  • Permettre le lancement d'Ansible depuis le site.

08/04/20

  • Créer une page permettant la visualisation graphique de l'ensemble du réseau de capteurs et des caractéristiques de chaque nœud.

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 :

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.

Organigramme

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é).

Cablage LED

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.

Script C LED

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

Branchement de la carte Banana PI

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/
Fichier 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.


Page d'accueil en mode non connecté
Barre de menu en mode connecté


Semaine 7 - 16/04

Exemple.png

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

Choix des capteurs et envoi du fichier


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>
Choix des capteurs et envoi du fichier
Script de remplissage du fichier XML


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.

Différent PIN de sortie de notre Raspberry Pi 3


Script d'envoi du fichier C sur le serveur

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 :

Script de téléchargement des fichiers

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

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

Crontab d'exécution périodique du script

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 :

Interface Armbian
Différentes configuration de la BPI R1

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

Configuration du routeur

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

Nom visible sur le smartphone


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.

Script de récupération et lancement 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).

Script d'exécution périodique de load.sh

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

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.


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.

Connexion SPI Raspberry Pi - Arduino UNO
  • 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



Projet S8

Objectifs

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

Equipe 1

  • Faire communiquer l'Arduino UNO et la Raspberry Pi dans les 2 sens ;
  • Créer le code pour le capteur de température et visualisation des données sur le port série avec minicom ;
  • Créer le code pour le capteur de distance et visualisation des données sur le port série avec minicom ;
  • Créer le script Python permettant le retour de données vers le serveur ;
  • Créer le Makefile générique ;
  • Intégrer la Nucléo dans le projet.

Equipe 2

  • Rendre Ansible fonctionel.

Equipe 3

  • Créer la page permettant de récupérer les données des capteurs par requête POST ;
  • Créer la fonction de mise à jour de la base de données.
  • Créer la table qui contiendra l'historique de valeurs ces capteurs ;
  • Créer les pages de recherche dans cet historique ;
  • Modifier la fonction de mise à jour de la base de données pour intégrer l'historique.
  • Création des pages permettant l'ajout d'une raspberry ou d'un capteur ;
  • Création des fonctions associées.
  • Créer le fichier inventaire.ini utile à l'équipe 2 à partir du site à l'ajout d'un capteur ou l'envoi d'un code ;
  • Migration du site et de la base données sur un nouveau serveur sur plil.fr.
  • Créer les pages permettant l'affichage des graphes de valeurs des capteurs ;
  • Création des fonctions associées.
  • Permettre le lancement d'Ansible depuis le site.
  • Créer une page permettant la visualisation graphique de l'ensemble du réseau de capteurs et des caractéristiques de chaque nœud.

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, Obsolète

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, Obsolète

Faire de même avec la Nucleo M4

Suspendue (qqs 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 de capteur (makefile déjà en place, quelques ajouts manquants sont en cours)

En cours de finalisation

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.

  • Démarrer l'utilitaire de configuration système de la Raspberry:
sudo raspi-config
  • Ouvrir les options d'interface serie
  • 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:
Iduino ST039 (LM35)

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.

  • Branchement :

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

Branchement


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

  • Résultat
Résultats du test



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 :
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).

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

Fonctionnement


  • Branchement :
Branchement


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

  • Résultat :

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

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.

Semaine 6

Durant cette semaine, le travail consistait à trouver un moyen d'utiliser la carte nucleo, étant donné que nous n'en avons jamais manipulé.

Après s'être documenté, il est apparut qu'il y avait plusieurs solutions pour l'utiliser : Via des Environnements dédiés (tels que Mbed compiler en ligne et d'autres environnements Offline).
Seulement, la solution intéressante pour nous résiderait dans l'utilisation d'un outil pour compiler en ligne de commandes. (tout comme avec les arduino). Pour se faire nous avons donc trouvé l'outil dédié, créé par ARM-MBED, à savoir mbed-cli qui comme (avr-gcc) permet la compilation et l'upload sur des architectures ARM (avec arm-gcc).

[Rajouter les portions codes pour les étapes d'installation de l'outil]


Un premier test d'upload de code pour faire clignoter une led a été concluant.

  • Problème

Suite à ce premier test, la carte, un fois connectée en USB, se déconnectait au bout de quelques secondes (testé sur mon pc tournant sous ubuntu 18.04). Donc impossible de re-upload à nouveau des codes.

Semaine 7

Pour cette semaine, l'objectif était de trouver une solution pour la Nucleo, et sinon mettre cette étape en attente pour avancer sur d'autres tâches.

N'ayant pas pu palier au problème de déconnexion sur mon pc personnel, Nous nous sommes dirigés directement sur la Raspberry pour Effectuer les mêmes étapes. Le problème lié à la déconnexion n'en était plus un.
Cependant Nous avons rencontré quelques problèmes au début lié à la connexion, mais nous avons par la suite pu installer les composantes nécessaires. Toutefois, d'autres problèmes sont survenus, probablement liés à des dépendances de librairies incomplètes et de problèmes de versions, suite à quoi, nous avons décidé de mettre cette partie en attente, car pas strictement indispensable pour un test complet (en effet, nous pourrions d'abord nous servir d'une autre carte Arduino en remplacement).

  • Coté Raspberry (optimisation du script)

Dans cette partie, il s'agissait d'optimiser le code du script python d'envoi des données au serveur afin qu'il puisse identifier automatiquement l'adresse IP de la Raspberry et aussi identifier directement le numéro du capteur concerné (et non pas les renseignées manuellement en DUR comme nous l'avons fait lors de notre test initial).
Pour plus de précisions sur le système d'identification du numéro du capteur (voir Equipe 3, Semaine 5 et 6).

[mettre les portions de codes appliquées].

Le script était parfaitement fonctionnel.

Semaine 8 | Confinement

Durant cette semaine, comme l'a expliqué l'Equipe 3, nous avons branchés des Raspberry avec quelques capteurs en salle de projet.

Nous (Equipe 1 et 3) avons repensé quelques détails de notre circuit de travail de manière à mieux se connecter avec l'Equipe 2 (Ansible), vous pourrez voir l'Equipe 3 (Semaine 5-6) pour des détails sur le système d'identification des capteurs.


  • Raspberry : Création d'un makefile générique

L'idée est d'automatiser l'attribution (upload) d'un code au capteur adéquat. Pour cela nous avons mis en place la base du fichier makefile qui est fonctionnelle.
Pour que cette partie soit complète il nous reste à rajouter les directives nécessaires en fonction du numéro du capteur (qui est une variable extérieure au makefile, vu que ce dernier est générique) et lancer l'upload adéquat.

Nous avons donc modifié le makefile (disponible sur le Git) afin qu'il lance un Upload spécifique en fonction du numéro du capteur et de la méthode d'upload (via USB ou via SPI pour des cartes Arduino).
Nous avons volontairement omis de gérer la carte Nucléo dans le Makefile pour le moment. Nous allons donc passer en phase de test (avec les autres équipes).


Equipe 2

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


Confinement

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. Après discution avec M.Redon et M. Vantroy ce ne serait finalement pas nécessaire de réaliser cette tache.

Les différents fichiers envoyé sr les Rpi étaient tout d'abord téléchargé sur le site. Puisque nous travaillons en local ce n'est plus nécessaire, les téléchargements ont été remplacé par de simple copier/coller.

Début de la rédaction du rapport et corrections de quelques erreurs présent du côté de Ansible.


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 - Obsolète

Modifier le script shell pour lui permettre d'envoyer les fichiers de données des capteurs en ssh sur le serveur

Fait - Obsolète

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.

Fait

Créer un graphe pour chaque capteur en fonction des X dernières valeurs.

Fait

Ajouter une page plus "graphique" sur le site permettant l'affichage des différents noeuds de capteurs et de leurs caractéristiques.

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 (voir le git).

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 :

  1. Peut-on exécuter un script PhP directement dans le shell ?
  2. Peut-on utiliser un code HTML pour l'exécuter dans le cas contraire ?
  3. 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

Table history

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

De plus, nous considérons qu'au premier ajout de capteur sur une raspberry, il faudra faire des installations sur celle-ci (appelées "setup" par l'équipe 2). De ce fait, si le setup a déjà été effectué sur une raspberry, la variable setup sera égale à 0. Elle vaudra 1 dans le cas contraire et permettra le setup.

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 setup=0

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.
On saura également si la Raspberry sur laquelle est le capteur est déjà prête à recevoir les codes.


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

La commande à lancer est du type :
ansible-playbook /path/to/the/file/MainTask.yml -i /path/to/the/file/inventaire.ini

La fonction PhP exec(String $cmd) devrait nous permettre de la lancer depuis le site aux endroits appropriés :

  • A la création d'un nouveau capteur ;
  • A l'envoi d'un code sur un ensemble de capteurs.

Pour que le serveur puisse lancer Ansible, et pour qu'Ansible ait accès à la clé ssh de root, nous allons utiliser la commande super.
Nous avons créé un script bash dans lequel se trouve la commande : ansible-playbook ../Ansible/MainTask.yml -i upload/inventaire.ini.

Nous devons lancer ce script en tant que root. Pour cela, après avoir installé super, nous avons configurer le fichier /etc/super.tab pour qu'il permette à l'utilisateur www-date de lancer le script en tant que root.
Pour se faire, nous avons ajouté cette ligne à la fin du fichier : 

cmd.sh /var/www/html/P10/IMA3_P10/site/cmd.sh www-data uid=root .*

De ce fait, au niveau du site, une seule ligne a été ajouté : exec("super cmd.sh");

Nous pouvons maintenant lancer Ansible depuis le site, au moment de la création d'un capteur et au moment de l'upload d'un fichier.

Prise en compte des remarques

Le compte d'identifiant admin et de mot de passe admin a été supprimé.
Il n'est plus possible de s'inscrire seul sur le site.

Mise en place des graphes

Notre équipe a travaillé sur la mise en place de graphes modélisant l'historique de données des capteurs.
Nous avons choisi de proposer un formulaire permettant de saisir :

  • Le capteur souhaité ;
  • Un intervalle de dates si besoin ;
  • Un nombre de valeurs à afficher.

Les valeurs affichées sont les valeurs les plus récentes. Si l'utilisateur veut afficher 100 valeurs entre 2 dates et qu'entre ces dates, il y a 150 valeurs, ce sont les 100 dernières qui seront affichées.
Le graphe étant statique, si un grand nombre de points est affiché (>100), nous aurons probablement des chevauchements dans l'affichage. Nous avons tout de même choisi de ne pas limiter le nombre de valeurs pour afficher une tendance.
Cependant, au dessus de 25 points, les valeurs n’apparaîtront pas sur chaque point mais il faudra les lire sur l'axe des ordonnées.
De la même manière, si le nombre de valeurs pour ce capteur dans l'historique est nul, le graphe ne sera pas affiché et vous serez redirigés sur le formulaire.

Pour la réalisation des graphes, nous avons choisi d'utiliser la librairie PHP JpGraphe dédiée à la représentation graphique. JpGraphe fournit des images qu'il reste à inclure dans le code HTML ou PHP. La construction de cette image se fait à partir d'un code PHP. Dans notre cas, nous devons renseigner les paramètres du formulaire dans ce code pour qu'il les prenne en compte. Pour se faire, on récupère les données du formulaire POST sur une nouvelle page (graphique.php). Cette page envoie par REQUEST les données à la page graphe.php qui retourne une image à l'aide d'un code que nous avons écrit à l'aide des fonctions de la librairie.


Avancement du projet pendant le confinement

Le détail de l'avancement de chaque équipe est disponible dans la section 4.3.4.

Confinement - Semaine 1

Nous avons pris la liberté de brancher au réseau de l'école 2 Raspberry et les capteurs qui vont avec. Nous avons emprunté dans une boîte des tutorat Système un Arduino UNO car nous n'en avions pas assez pour en avoir chez nous dans le cas d'une coupure à Polytech.
Nous avons également tout le matériel nécessaire chez nous et accès au serveur depuis chez nous.

Nous considérons que nos raspberry ont une pré-configuration avant leur installation (faite par nos soins).
Elle inclut la modification du DNS et de l'adresse IP de la raspberry pour être accessible depuis le site et Ansible.

  • Equipe 1 : Raspberry, Arduino, Capteurs
    • Les Raspberry communiquent parfaitement avec le site par wget et requete POST ;
    • Les codes sont modifiés et prêts (code température et code distance) ;
    • Un Makefile générique est en cours de finition ;
    • Le Makefile choisira d'abord quel commande d'upload il va effectuer (en fonction du numéro de version) puis spécifiera le port dans la commande avrdude ;
    • La carte Nucléo M4 est en suspend tant que le reste n'est pas fonctionnel.
  • Equipe 2 : Ansible
    • Gestion au niveau des Arduino (Nucléo laissée de côté) ;
    • L'installation des logiciels et bibliothèques nécessaire au fonctionnement des codes est ok ;
    • La transmission des fichiers et le lancement du script fonctionne ;
    • Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
    • Il faudrait récupérer le code envoyé depuis le site dans le télécharger (car Ansible est aussi sur le serveur).
  • Equipe 3 : Site Web
    • Site 95% terminé par rapport à ce qui a été demandé ;
    • Reste le lancement des scripts Ansible depuis le site.
  • Remarques sur chat.plil.fr
    • Mot de passe admin par défaut pour le site internet. Favoriser le mot de passe root habituel à la place ou un mot de passe plus compliqué afin de limiter les risques.
    • Ajouter la possibilité sur le site de visualiser pour chaque capteur, un graphe de l'évolution temporelle des valeurs renvoyées.


Confinement - Semaine 2
  • Equipe 1 : Raspberry, Arduino, Capteurs
    • Les Raspberry communiquent parfaitement avec le site via des requetes POST ;
    • Les codes sont modifiés et prêts (code température et code distance) ;
    • Un Makefile générique est opérationel (mais ne gère pas encore la Nucléo) ;
    • La carte Nucléo M4 est en suspend tant que le reste n'est pas fonctionnel ;
    • Il faut utiliser cron pour lancer le processus d'envoi des données des capteurs de températures toutes les 5 minutes et toutes les 5 secondes pour les capteurs de distance ;
    • Eviter l'attente active des capteurs (boucle infinie) ;
    • Début du rapport final.
  • Equipe 2 : Ansible
    • Ansible est opérationel pour gérer les Arduino ;
    • L'installation des logiciels et bibliothèques nécessaires au fonctionnement des codes est fonctionnelle ;
    • La transmission des fichiers et le lancement du script fonctionne ;
    • Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
    • Il faut récupérer le code envoyé depuis le site sans le télécharger (car Ansible est aussi sur le serveur) ;
    • Début du rapport final.
  • Equipe 3 : Site Web
    • Site 98% terminé par rapport à ce qui a été demandé ;
    • Il faut ajouter une page permettant la visualisation graphique de l'ensemble du réseau.
  • Remarques sur chat.plil.fr
    • Ajouter une page permettant la visualisation graphique de l'ensemble du réseau de capteurs ;
    • Correction de la syntaxe wiki ;
    • Début du rapport final.


Confinement - Semaine 3
  • Equipe 1 : Raspberry, Arduino, Capteurs
    • Il faut utiliser cron pour lancer le processus d'envoi des données des capteurs de températures toutes les 5 minutes et toutes les 5 secondes pour les capteurs de distance ;
    • Eviter l'attente active des capteurs (boucle infinie) ;
    • Faire correspondre un capteur à un port USB physique de chaque raspberry ;
    • Début du rapport final.
  • Equipe 2 : Ansible
    • Il faut gérer l'envoi automatique des clé ssh aux raspberry pour qu'Ansible puisse fonctionner de manière 100% autonome ;
    • Les fichiers envoyés depuis le site sont récupérés directement par Ansible via leur chemin ;
    • Début du rapport final.
  • Equipe 3 : Site Web
    • Il faut ajouter une page permettant la visualisation graphique de l'ensemble du réseau ;
    • Il faut remonter les erreurs à l'utilisateur ;
    • Il faut permettre aux administrateurs de créer et supprimer des comptes ;
    • Il faudrait donner la possibilité à un utilisateur de supprimer une raspberry ou un capteur.
  • Remarques sur chat.plil.fr
    • Démonstration ok.


Documents Rendus

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA3/IMA4_2018/2020_P10&oldid=83593 »