IMA3/IMA4 2018/2020 P10
Sommaire
- 1 Présentation générale
- 2 Analyse du projet
- 3 Préparation du projet
- 4 Réalisation du Projet
Présentation générale
Administration système, déploiement et surveillances de logiciels dans un réseau de capteurs
Description
Dans le cadre de recherches dans le domaine des réseaux de capteurs et des objets connectés, notre projet consiste à développer une solution de maintenance et de reconfiguration à distance d'un ensemble de nœuds déployés dans un environnement réel. Afin de faciliter la vie de ces chercheurs sur le test de leurs hypothèses, ils pourront facilement et rapidement déployer leurs créations sur tout les nœuds souhaités grâce à un système de sélection ou au téléchargement du nouveau code sur tous les nœuds du réseau.
Objectifs
L'objectif principal de notre projet est de créer une interface permettant de tester des programmes ou logiciels en les déployant sur le vaste réseau de capteurs. Nous devons rendre accessible chaque nœud indépendamment des autres, tout en permettant un lien entre tous, afin d'envoyer le contenu vers tout ou une partie des nœuds disponibles.
Enfin, nous allons permettre la mise à jour et l'adaptation du chemin d'envoi des données des nœuds, entre eux, et avec l'application de gestion.
Analyse du projet
Positionnement par rapport à l'existant
Analyse du premier concurrent
Notre concurrent principal reste le FIT(Future Internet Testing Falicity)/IoT-Lab. Il s'agit d'un laboratoire dont les recherches se portent sur les différents domaines scientifiques tel que les adresses de communications sans fils, des réseaux de capteurs, des protocoles de routages basse consommation et applications embarquées. Ce laboratoire dispose de plus de 1500 de nœuds de capteurs sans fils propagés à travers les six sites différents en France qui sont : Inria Grenoble (640), Inria Lille (293), Inria Saclay (264), ICube Strasbourg (400), Institut Mines-Télécom Paris (160) and CITI Lab Lyon (29). Chaque site dispose de capacités matérielles et de nœuds différentes, mais tous les sites sont interconnectés et disponibles via le même portail Web,
Analyse du second concurrent
Il y aussi une autre équipe au sein du laboratoire de recherches en informatique(LRI) qui est en train de faire un projet sur les capteurs de réseaux. Les questions abordées par l’équipe concernent les réseaux ad hoc sans fil et mobiles, les réseaux de capteurs et les réseaux fixes, et concernent la qualité de service, la sécurité, le contrôle d’admission, la réservation de ressources, le calcul des limites déterministes et la consommation d’énergie. L'analyse de la performance est donnée à la fois théoriquement, pour déterminer les limites, et par simulation, pour enrichir l'analyse et inclure un support pour un environnement dynamique.
Scénario d'usage du produit ou du concept envisagé
De nombreux chercheurs et développeurs créent de nouveaux codes adaptés à l'utilisation d'un réseau de capteurs. Ces codes doivent être facilement déployés sur le réseau afin de pouvoir y réaliser des essais rapides. Cela permet de corriger rapidement les erreurs liées à leur mauvais fonctionnement.
Supposons que notre réseau est réparti sur une très grande surface. Le chercheur voulant tester son code doit l'envoyer à partir de son ordinateur sur le réseau. Notre projet va lui permettre de rester assis dans son bureau et de ne pas devoir charger le code sur chaque nœud de capteurs un par un.
A travers notre projet, nous voulons rendre possible ces exports rapides de données. Il nous faudra utiliser un routeur qui permettra la liaison entre chaque nœud et un serveur de données. Dans chacun de ses nœuds, on trouve plusieurs nœuds de mesures comportant chacun un microcontrôleur associé à des capteurs.
Pour pouvoir envoyer ses codes sur le réseau, le chercheur dispose d'une interface web graphique connectée au même serveur que les nœuds de collecte et le routeur. Cette interface permettra la sélection de tout ou d'une partie du réseau sur laquelle il doit effectuer les modifications. Ceci se fera à l'aide des microcontrôleurs du réseau et de Raspberry Pi gérant chaque nœud. Une fois la zone d'export choisie, il pourra envoyer ses codes et les mettre à jour en quelques clics. Le code sera envoyé sur le serveur et distribué par le routeur sur les nœuds sélectionnés. Les différents nœuds feront un retour sur la réception à travers le serveur via le routeur, et le chercheur pourra ainsi tester rapidement sa réalisation.
Dans le cas où le chercheur veut tester l'envoi de données par radio par exemple, il pourra placer un grand nombre de nœuds communiquant en filaire avec le routeur et par radio entre eux. Les nœuds seront capables de transmettre l'information au suivant et de choisir un autre chemin (contourner un nœud par exemple) en cas de perturbations (présence de réseau Wi-Fi à proximité, etc...), pour envoyer l'information. Ces nœuds seront capables de communiquer avec le serveur pour indiquer la bonne réception des données, les résultats obtenus ou éventuellement le mauvais fonctionnement d'un ou plusieurs capteurs.
Bibliographie et webographie
S6
Equipe 1
- OpenWRT
Equipe 2
- Pin Raspberry
- Clignotement d’une LED
- Installation Raspbian
Equipe 3
- Protocole XMLHttpRequest
S7
Equipe 1
Equipe 2
- Passage en mode DFU
- Flasher un Arduino sans programmer
- Datasheets
- https://produktinfo.conrad.com/datenblaetter/175000-199999/191789-an-01-fr-plat_uno.pdf
- https://www.farnell.com/datasheets/1682209.pdf
- https://www.mouser.com/pdfdocs/Gravitech_ATMEGA328_datasheet.pdf
- http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf
- http://ww1.microchip.com/downloads/en/DeviceDoc/doc7799.pdf
- http://infocenter.arm.com/help/topic/com.arm.doc.ddi0432c/DDI0432C_cortex_m0_r0p0_trm.pdf
- http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/DDI0439B_cortex_m4_r0p0_trm.pdf
- Connexion entre RPI & Atmega328p
- http://hardware-libre.fr/2014/04/rapberry-pi-atmega-bridge-presentaion/
- http://hardware-libre.fr/2014/04/raspberry-pi-atmega-bridge-branchements/
- http://hardware-libre.fr/2014/04/raspberry-pi-atmega-bridge-installation/
- https://www.instructables.com/id/Connect-Your-Raspberry-Pi-and-Arduino-Uno/
- https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/overview
- Arduino UNO & Raspberry Pi SPI
S8
Equipe 1
- Connexion SPI
- TX/RX à partir de GPIO
- Script Python
Equipe 2
Equipe 3
- Script PhP
- http://www.manuelphp.com/php/function.ssh2-connect.php
- https://www.developpez.net/forums/d702424/bases-donnees/mysql/debuter/remplir-base-fichier-texte/
- https://www.php.net/manual/fr/function.scandir.php
- https://www.php.net/manual/fr/function.array-diff.php
- https://www.php.net/manual/fr/function.shell-exec.php
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
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
- 3x Raspberry Pi ;
- 5x Arduino UNO ;
- 1x Nucleo-F401RE ;
- 4x Câble RJ45 ;
- 6x Câble USB type A mâle - type B mâle ;
- 6x Câble électrique femelle - femelle ;
- 3x Capteurs de distance HC-SR04: https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm ;
- 2x Capteurs de température LM35 : https://www.gotronic.fr/art-module-capteur-de-t-lm35-st039-26113.htm#complte_desc ;
- 18x Câble électrique mâle - mâle.
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 ;
- Ajout d'une table de groupes ;
- Mise à jour des tables contenant les capteurs et les raspberrys.
- Envoi du fichier de configuration (.ini) sur le serveur ;
- Permettre aux administrateurs d'ajouter et de supprimer des comptes ;
- Permettre le lancement d'Ansible via le site.
Calendrier prévisionnel
Equipe 1
| Dates | Objectifs |
|---|---|
|
05/02/19 |
|
|
19/02/19 |
|
|
05/03/19 |
|
|
19/03/19 |
|
|
02/04/19 |
|
|
16/04/19 |
|
|
30/04/19 |
|
|
07/05/19 |
|
|
14/05/19 |
|
|
28/05/19 |
|
|
14/11/19 |
|
|
29/01/20 |
|
|
12/02/20 |
|
|
19/02/20 |
|
|
04/03/20 |
|
|
25/03/20 |
|
|
08/04/20 |
|
Equipe 2
| Dates | Objectifs |
|---|---|
|
05/02/19 |
|
|
19/02/19 |
|
|
05/03/19 |
|
|
19/03/19 |
|
|
02/04/19 |
|
|
16/04/19 |
|
|
30/04/19 |
|
|
14/05/19 |
|
|
28/05/19 |
|
|
04/06/19 |
|
|
14/11/19 |
|
|
21/11/19 |
|
|
20/12/19 |
|
|
08/04/20 |
|
Equipe 3
| Dates | Objectifs |
|---|---|
|
05/02/19 |
|
|
19/02/19 |
|
|
05/03/19 |
|
|
19/03/19 |
|
|
02/04/19 |
|
|
16/04/19 |
|
|
30/04/19 |
|
|
14/05/19 |
|
|
28/05/19 |
|
|
04/06/19 |
|
|
01/04/19 |
|
|
29/01/20 |
|
|
05/02/20 |
|
|
12/02/20 |
|
|
19/02/20 |
|
|
04/03/20 |
|
|
18/03/20 |
|
|
25/03/20 |
|
|
08/04/20 |
|
Réalisation du Projet
Projet S6
Semaine 4 - 05/03
Pour l'équipe 1 :
Première recherche sur la carte Banana PI, à l'aide de la datasheet, dont le lien est ci-dessous.
L'utilisation de la datasheet va nous permettre de voir l'intégralité des données de la carte BPI-R1
c'est à dire les branchements, le courant d'alimentaion et les composants.
https://www.electronicsdatasheets.com/datasheet/BPI-R1.pdf
Pour l'équipe 2 :
Documentation sur l'utilisation d'Ansible et sur les Raspberry Pi
Afin d'installer Ansible, deux lignes de commande ont dû être lancé dans le terminal d'un pc en E306 ( car l'installation d'ansible n'était pas possible dans les autres salles) :
apt install ansible
Connexion internet sur la Raspberry :
Partie Raspberry
export https_proxy=https://proxy.polytech-lille.fr:3128 export http_proxy=http://proxy.polytech-lille.fr:3128
OU :
export https_proxy=https://proxy.plil.fr:3128 export http_proxy=http://proxy.plil.fr:3128
Puis, dans /etc/resolv.conf
nameserver 193.48.57.48
Ensuite dans /etc/network/interfaces :
auto eth0 iface eth0 inet static address 172.26.145.111 netmask 255.255.255.0 gateway 172.26.145.254
Enfin :
ipdown eth0 ifup eth0
Sur le pc :
iptables -F iptables -tnat -F iptables -PFORWARD ACCEPT
L'utilisation d'ansible se fera ensuite de la manière suivante : Ecriture d'un fichier .yml contenant les différentes tâches à effectuer sur un serveur (réseau de capteur) spécifique puis le lancement s'effectuera ensuite en lanceant la commande ansible suivi du nom du serveur sur lequel on souhaite travailler.
Concernant la Raspberry PI 3, la Raspberry PI 3 est un ordinateur miniature que l'on peut brancher à un écran et un clavier afin de l'utiliser comme un ordinateur normal. Le stockage des données s'effectue sur une carte SD ce qui permet à la Raspberry d'être très petite (l'utilisation d'un disque dur interne augmenterait grandement sa taille)
Pour l'équipe 3 :
Première recherche sur la création du site web. Recherche des ressources PhP, HTML, CSS nécessaires (Bootstrap).
J'ai laissé de côté la partie JavaScript et Vue.js car elles ne sont pas utiles pour commencer le site.
Création de la base de données projetCapteurs sur Houplin et des fonctions de connexion du site à celle-ci.
La base contient 3 tables :
- capteurs : numéro du capteur | nom du capteur | Raspberry à laquelle le capteur est relié | type de capteur
- membres : numéro du membre | nom | prénom | mot de passe | identifiant de connexion
- verif : numéro de la demande
La table capteurs stocke les informations concernant les capteurs et permettra la sélection au moment de l'envoi du fichier C.
La table membres répertorie les informations concernant les membres et permettra la connexion sur le site web.
La table verif contient le numéro de la demande.
Semaine 5 - 19/03
Pour l'équipe 1 :
Après avoir effectué des recherches sur la carte BPI R1, cette séance va me permettre de faire des recherches sur l'image qui va me permettre de faire visualiser l'interface de la BPI R1.
D'après le cahier de charge imposé, il faut mettre l'image OpenWrt.
Open Wrt est une distribution GNU/Linux minimaliste pour matériel embarqué. Après avoir fait des recherches, on a finalement retrouvé le site qui a l'image OpenWrt.
La première que je devais faire était d'installer un fichier OpenWrt dans une carte SD, et ce fichier servait à faire fonctionner la banana pi.
Voici le lien qui nous a permis de trouver l'image:
https://openwrt.org/toh/view/toh_fwdownload?dataflt%5B0%5D=supported%20current%20rel_%3D18.06.2.
Voici une image du site d'openwrt :
Pour l'équipe 2 :
Au cours de cette séance, je me suis documenté sur l'allumage d'une LED. Cela m'a amené à créer un organigramme afin de réaliser le code plus simplement par la suite.
Le câblage s'effectuera de façon très simple en connectant une LED puis une résistance à chaque sortie GPIO en fonction du nombre de capteurs souhaités par Raspberry (nous utilisons des LED pour cette année pour simuler et voir que le code envoyé par le serveur est bien traité et reçu par les LED s'allumant lorsque le capteur associé a été sélectionné).
Puis je me suis intéressé au code afin d'allumer la LED 500ms puis de l'éteindre 500ms grâce à une boucle while qui est toujours active tant que le programme tourne (control C par l'utilisateur pour stopper le programme). Pour se faire, il faut mettre le PIN connecté à la LED en mode sortie (OUTPUT) car sans cela la LED ne s'allume pas.
Ce code nécessite l'installation de la bibliothèque WiringPi qui permet d'allumer et d’éteindre la LED. Nous verrons l'installation de cette bibliothèque une fois les configurations faites sur la Raspberry effectuées et une fois connecté à la Raspberry.
Pour l'équipe 3 :
Début de la création du site : mise en place d'un système de connexion basique et d'un minimum de design pour rendre clair le site.
Je me suis limité à des fonctions de connexion et déconnexion sans modifier le reste des pages en fonction de l'état de connexion, et sans créer de variables de session.
Pour cela, j'ai utilisé des fonctions Php telles que pg_connect et pg_close, fonctions liées à une base de données PostgreSQL.
- Création d'un formulaire de connexion ;
- Création d'un formulaire d'inscription ;
- Création des scripts Php de lancement de ces formulaires.
Semaine 6 - 02/04
Pour l'équipe 1 :
Après avoir trouvé l'image permettant de visualiser l'interface BPI-R1, de la faire marcher et de le configurer en tant que routeur de wifi pour qu'il puisse emettre pour le noeud de collecte qui est la Rasberry PI. La première étape est d'abord d'installer l'OpenWrt dans une carte SD et cette carte SD sera mis sur le port SD de la Banana PI R1. Voici les commandes qui m'ont permis de mettre l'image OpenWrt dans la carte SD :
- Il faut d'abord se connecter à su sur le terminal
- Mettre l'image avec la commande ci dessous :
dd if=OpenWrtimage.img of=/dev/sdb
Avec OpenWrtimage.img le nom du fichier télécharger. Après avoir branchéle port HDMI de la carte avec l'entrée VGA du moniteur on pouvait voir l'interface mais on arrivait pas écrire. Donc après avoir appeler mes tuteurs, ils m'avaient dit que la semaine prochaine, ils allaient mettre le système Debian, car il y aurait des problèmes avec le système OpenWrt.
Pour l'équipe 2 :
Tout d'abord, il faut télécharger Raspbian sur la carte SD de la Raspberry Pi 3. Pour cela, j'ai sélectionné le fichier contenant Raspbian avec des interfaces graphiques (voir photo ci-dessous) sur le site internet :
https://www.raspberrypi.org/downloads/raspbian/
Une fois l'archive zippée de la distribution récupérée vous pouvez l'installer sur la carte SD après l'avoir décompressée en utilisant la commande dd :
dd if=2019-04-08-raspbian-stretch-full.img of=/dev/sdb
Puis une fois tout ceci téléchargé, j'ai commencé à effectuer mes premiers pas sur la Raspberry. Une fois le clavier, la souris, l'écran et la carte SD branché et connecté à la Raspberry, j'ai pu connecter l'alimentation de la Raspberry. Le premier démarrage fut un peu long, car lors de celui-ci, la raspberry a installé le système Raspbian. Lors de ce premier démarrage, des premières configurations ont été effectué qui ont été très simplifié car étant sur une version de Raspbian avec une interface graphique. Ces quelques réglages consistaient principalement à régler la langue, l'heure, la connexion internet et le nouveau mot de passe. L'identifiant et le mot de passe ont été laissé comme initialement.
le login par défaut est « pi », et le password est « raspberry »
Pour l'équipe 3 :
Adaptation du système de connexion avec création de variables de session. Ces variables permettent de maintenir une connexion ouverte en changeant de page et à structurer les pages afin qu'elles affichent les bonnes choses.
En effet, un individu connecté ne verra pas la page de connexion par exemple.
Amélioration du système de compte avec la mise en place du hachage des mots de passe.
Amélioration du design du site, avec la création d'une barre de menu et l'utilisation de Bootstrap.
Semaine 7 - 16/04
Pour l'équipe 1 :
Dans cette séance de projet, je vois que mon cahier de charge doit être changer. En effet, vu que la séance dernière, avec l'OpenWrt
qu'il y avait un problème de visualation de l'interface. Au final, j'ai reçu par mes tuteurs une carte SD, contenant cette fois
l'image Debian. Et cette fois ci, on voit bien l'interface. Maintenant le but est de pouvoir configurer la banana PI en routeur Wifi
afin que la Rasberry PI reçoit la wifi de ce dernier.
Et aussi dans cette séance, j'ai pu voir des tutoriels, afin de pouvoir comprendre le mécanisme de fonctionnement et de
programmation.
Pour l'équipe 2 : Durant cette séance, plusieurs autres configurations ont été effectuées. Pour accéder à la fenêtre de configuration, il a fallu rentrer la commande :
sudo raspi-config
Maintenant que notre système Raspbian est un peu plus sécurisé, nous allons nous assurer que le SSH est bien activé afin que nous puissions prendre le contrôle de la Raspberry à distance. Pour cela, il faut sélectionner le huitième choix, « Advanced Options ». Cette fois, après validation nous arrivons sur un autre menu ou nous allons choisir la quatrième ligne, « SSH ». Puis « Enable », et enfin « Valider ». Le système lance quelques commandes puis nous ré-affiche une fenêtre nous indiquant le succès de l’opération.
Pour l'équipe 3 :
Création de la page de sélection des capteurs sous forme d'un formulaire Php. La sélection n'est pas au point mais l'affichage est correct.
Je laisse toujours de côté la partie dynamique, en essayant de rendre possible la sélection multiple pour l'envoi du formulaire.
Cette page contiendra aussi une partie de chargement du fichier à envoyer (unique pour le moment).
Semaine 8 - 30/04
Pour l'équipe 1 :
Dans la dernière séance, j'ai pas pu totalement assimiler l'ensemble du fonctionnement permettant de configurer
la BPI-R1 en tant que routeur de wifi. Donc toute cette séance s'est consacrés à la recherche des fonctionnalités de la carte.
Et aussi, j'ai pu énormément m'aider du site du bureau d'étude d'IMA (Robot Prédateur et Proie) de l'an dernier, surtout avec
la partie Rasberry Pi que j'ai remarqué qu'au final les fonctionnalités de la Banana PI est à peu près identique que celle de la Rasberry.
Voici le lien qui m'a principalement aidé à mieux comprendre et trouver les fonctionnalités du Debian :
https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019
Pour l'équipe 2 :
Une fois la Raspberry configuré, il a fallu installer la bibliothèque wiringPi. Pour se faire :
On installe GIT:
sudo apt-get install git-core
On met a jour le PI:
sudo apt-get update sudo apt-get upgrade
On récupère la dernière version de WiringPi:
git clone git://git.drogon.net/wiringPi
On se place dans le bon répertoire:
cd wiringPi
On lance la compilation:
./build
Puis le lancement du code créé pour l'allumage des LED s'effectue de la manière suivante:
gcc blink.c -o blink -lwiringPi ./blink
Le fichier blink étant notre fichier contenant le script permettant l'allumage d'une led toute les 0.5s.
Pour l'équipe 3 :
Modification de la page principale (sélection d'un capteur possible). Possibilité de joindre un seul fichier C.
Un fichier XML est créé avec le numéro du capteur sélectionné. Ce fichier sera transmis avec le fichier C.
Documentation sur le protocole XMLHttpRequest : XMLHttpRequest
Le fichier XML contient le code suivant :
<?xml version='1.0' encoding='ISO-8859-1'?>
<sensor>nom_num</sensor>
Semaine 9 - 14/05
Pour l'équipe 1 :
Dans cette séance, je peux enfin commencer à configurer la BPI-R1 en point d'accès Wifi. Après avoir branché au moniteur la carte
je remarque qu'il n'y a aucune visualisation sur le moniteur. Et c'est là où je commence à me perdre. En effet, n'ayant aucune idée de pourquoi
on ne voit plus l'interface, j'ai décidé de rechercher les causes de ce problème, en supposant que la carte a été court-circuiter.
Donc cette séance n'a été que la recherche de ce problème et surtout pouvoir le résoudre.
N'ayant aucune idée après plusieurs séances de recherche, j'ai décidé de voir mes tuteurs afin de pouvoir
résoudre ce problème car je suis vraiment en retard par rapport à mon objectif fixé qui était
de configurer la BPI-R1 en routeur wifi pour qu'elle puisse donner les informations à la Rasberrie -PI.
Après plusieurs essaies, c'est à dire changer le courant d'Alimentation, mettre de nouveau l'image Debian
au final, mes tuteurs m'ont conseillé de changer l'image et d'en mettre un nouveau mais aussi il faut que
que cette image soit récente afin de ne pas avoir de problème au niveau du noyau de la carte.
Pour l'équipe 2 :
Installation d'un premier câblage pour réaliser l'allumage d'une des 4 LED en fonction de la LED sélectionné. Il a fallu trouver grâce à différent test le bon schéma de pin de notre Raspberry car il en existait beaucoup de différent sur le numéro du pin à entrer pour allumer la led correspondante à ce numéro.
Pour l'équipe 3 :
Création du script permettant l'upload d'un fichier C sur le serveur.
Le script va d'abord vérifier que le fichier à uploader vérifie les conditions (pas d'erreur, taille inférieure à la taille maximale, bonne extension).
Ensuite, on normalise le nom du fichier qui s'appellera maintenant 'binaire', et on récupère son extension.
A l'aide de la fonction move_uploaded_file, on délace le fichier de son répertoire temporaire vers le répertoire upload présent sur le serveur.
Il faut maintenant un script pour récupérer les fichiers C et XML sur la Raspberry Pi.
La partie 3 étant terminée pour le résultat attendu au S6, les équipes 2 et 3 fusionnent pour terminer la création des scripts.
Semaine 10 - 28/05
Pour l'équipe 1 : Le problème est enfin résolu mais il faut vite rattraper le retard, donc aujourd'hui, on a consacré cette séance dans l'utilisation de l'Armbian.
Pour l'équipe 2 & 3 :
Création d'un script blink.c permettant la récupération du nom du capteur et de son numéro stockés dans le fichier XML.
Création du script de récupération du fichier XML et du fichier C à partir du serveur.
Pour télécharger le fichier C et le fichier XML stockés sur le serveur, on utilise la commande wget dans un script nommé script.sh :
Pour exécuter un script automatique : Règle Cron
Voici le script de téléchargement automatique des fichiers toutes les minutes :
Il s'agit d'une crontab qui s’exécute toutes les minutes.
Cette crontab va lancer le script de téléchargement à chaque exécution, permettant ainsi de garder le fichier C à jour.
Semaine 11 - 04/06
Pour l'équipe 1 :
Donc suite au problème qui ont eu lieu ces dernières séances, et après avoir reçu des conseils de
mes tuteurs, j'ai fait une nouvelle des recherches sur l'image la plus récente qui va me permettre
de faire marcher ma carte et visualiser l'interface de l'OS. Après avoir fait un tour sur le site (lien ci dessous)
http://wiki.banana-pi.org/Banana_Pi_BPI-R1
qui propose différentes images et ne sachant vraiment lequel choisir, j'ai choisi de mettre un Armbian 2016 et
et avec la même commande me permettant de copier sur carte SD que l'OpenWrt afin de le mettre sur la carte
.
Au final, cela marche, et je me connecte avec "root" qui a pour mot de passe "1234". Après s'être connecter
on obtient cette interface.
Sachant que je suis énormément en retard par rapport aux deux autres équipes, surtout celui de la
qui a presque terminé sa partie, mon objectif est finalement à ce que ma banana PI marche seulement
en tant que routeur Wifi. Et donc en partant de l'OS Armbian et que le principe de la programmation est à
peu près similaire que celle de la Rasberrie PI. Donc je me suis servi du même raisonnement que celui de ce lien :
https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019#Connexion_s.C3.A9rie
La première chose était d'abord d'installer le packtage Hostapd, car c'est ce packtage qui contient tous les
fichiers me permettant d'activer le routeur Wifi :
apt-get install hostapd
Ensuite afin de pouvoir mofidier le fichier de configuration de hostapd qui se trouve dans le répertoire /usr/share/doc/hostapd/examples/ et le coller dans le répertoire /etc/hostapd :
cp /usr/share/doc/hostapd/examples/hostapd.conf.gz /etc/hostapd gunzip /etc/hostapd/hostapd.conf.gz
Et finalement avec l'éditeur de texte nano, on peut modfier le fichier /etc/hostapd/hostapd.confles mots-clefs suivants :
-
ssid, indiquez le nom de réseau WiFi ; -
country_code, mettez le code de la FranceFR; -
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 valeurWPA-PSK.
Enfin il faut definir le chemin du fichier de configuration à l'aide du fichier /etc/default/hostapd :
DAEMON_CONF=/etc/hostapd/hostapd.conf
On relance le service avec la commande :
service hostapd restart
Au final, on arrive à faire apparaître le nom du reseau de la banana sans fil
Mais le problème, c'est que si on tape le même mot de Passe sur le smartphone, ça nous renvoie erreur d'authentification
au lieu de l'erreur détection IP. Au final, on va de nouveau changé l'OS et de recommencer toute la procédure. Donc le problème du routeur sera résolu l'année prochaine.
Pour l'équipe 2 & 3 :
Nous avons créer le script de récupération de tous les fichiers nécessaires, à savoir :
- Le fichier binaire.c ;
- Le fichier sensor.xml ;
- le fichier demande.txt dont l'utilité sera expliqué ci-dessous.
Ce script permet aussi la compilation du fichier C et le lancement des exécutables du programme.
La crontab n'étant pas fonctionnelle sur la Raspberry, nous avons choisi un autre moyen pour permettre la répétition du script.
Nous avons crée le script ci-dessous, qui boucle toutes les 15 secondes (possibilité de modifier le temps).
Pour que le code ne s'exécute que lorsqu'on envoie un nouveau fichier sur le serveur, et pas toutes les 15 secondes, on reçoit le fichier demande.txt.
Ce fichier contient le numéro de la demande (stocké dans la base de données).
En récupérant le numéro et en le comparant à la dernière version reçue (stockée dans un autre fichier texte), on peut savoir si une nouvelle demande est réalisée.
Si ce n'est pas le cas, le programme ne lance pas l'exécutable du fichier binaire.c.
Ces différentes étapes se font dans le fichier blink.c.
Il est possible de se demander pourquoi nous avons 2 exécutables, et pas un seul reçu directement du serveur. Voici les différentes raisons :
- L'exécutable blink nous permet de gérer l'exécution ou non de binaire.
- En supposant le projet plus avancé, il est préférable de séparer la partie récupération du capteur et le programme en lui même, car différents capteurs pourraient ne pas utiliser le même code et pourraient être placés sur différentes Raspberry.
Documents Rendus
- Gitlab : Git IMA3 P10
- Site web : Site
- Rapport : media: Rapport_IMA3_P10.pdf
Projet S7
Objectifs
Pour l'équipe 1 :
- Remplacement de Ziyad Houssaini par Loris Ahouassou.
- Notre équipe s'occupe de la partie routeur, qui doit être reprise au début.
- Les objectifs sont de fournir un accès internet aux Raspberrys, et de permettre l'envoi des fichiers de données aux bonnes Raspberry.
Pour l'équipe 2 :
- Maintenant que nous avons réussi à scruter le serveur pour y récupérer les fichiers, et que l'allumage des LEDs est fonctionnel, il faut qu'on configure les Raspberry pour qu'elles fournissent un retour au serveur.
- Parallèlement à ça, nous devons permettre la reconfiguration de plusieurs types de microcontrôleurs (Cortex M0 ou M4, Atmega328p) à partir de la Raspberry. Ainsi, peut importe le capteurs (situés sur n'importe quel type de microcontrôleurs), il sera utilisable sans besoin de le reprogrammer directement.
Pour l'équipe 3 :
- Lors du S6, notre équipe à réaliser une interface Web statique permettant à l'utilisateur de dialoguer avec un serveur et une Raspberry Pi. Il faut maintenant le rendre dynamique en ajoutant un Framework Java Script (Vue.JS) et créer un nouveau système permettant l'affichage des données reçues.
- Parallèlement, il faut créer une nouvelle table dans laquelle seront entrées les données reçues des capteurs. Le routeur devra donc réaliser du pré-traitement afin d'entrer les valeurs reçues dans la base.
Réalisation
Pour l'équipe 1 :
Cette partie a été mise en suspend car elle n'est pas indispensable au fonctionnement du projet.
Pour l'équipe 2 :
Ce semestre, nous avions pour objectif de faire communiquer la Raspberry Pi avec l'Arduino UNO en ICSP.
Nous devons utiliser l'Arduino UNO comme support pour les différents capteurs. Ainsi, la Raspberry n'aura qu'un rôle intermédiaire de compilation.
Il faut donc que l'on connecte ensemble ces deux cartes. Nous avons choisi de ne pas passer pas les ports USB, car dans le cas contraire, notre projet est assez simplifié. Nous avons choisi de passer par les pins SPI pour connecter l'ensemble.
Ainsi, nous avons effectué quelques manipulations, expliquées ci-dessous.
- Installation de avrdude
apt-get install avrdude avrdude -v (pour vérifier l'installation)
- Configuration de avrdude
cp /etc/avrdude.conf ~/avrdude_gpio.conf nano ~/avrdude_gpio.conf
Nous avons cherché cette partie du code :
#programmer # id = "linuxgpio"; # desc = "Use the Linux sysfs interface to bitbang GPIO lines"; # type = "linuxgpio"; # reset = ?; # sck = ?; # mosi = ?; # miso = ?; #;
Pour la changer en :
programmer id = "pi_3"; desc = "Use the Linux sysfs interface to bitbang GPIO lines"; type = "linuxgpio"; reset = 4; sck = 11; mosi = 10; miso = 9; ;
- Test de connexion
avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v
Nous avons néanmoins rencontré un problème concernant les pins. La Raspberry n'arrivait pas à exporter certains pins :
- Erreur rencontrée
can't export GPIO 10, already exported/busy?
La même erreur survenait pour d'autres pins.
Après quelques recherches, nous avons trouvé comment régler ces problèmes.
- Nous avons visualisé donc les GPIOs non exportés à l'aide de la commande suivante
gpio exports
Cela nous a permis d'exporter manuellement les GPIOs concernés.
- Pour exporter manuellement les GPIOs dont nous avions besoin :
echo 4 > /sys/class/gpio/unexport echo 10 > /sys/class/gpio/unexport echo 11 > /sys/class/gpio/unexport
Suite à cela, la Raspberry pi était désormais capable de se connecter à l'atmega328p.
- Création d'un programme test à l'aide de l'IDE Arduino
Nous avons utilisé un programme exemple disponible dans l'IDE. Nous avons activé la compilation dans les préférences et compiler le programme blink qui fait clignoter une led (GPIO 13). Ensuite, nous avons uploadé le fichier .hex créé sur l'Arduino UNO.
avrdude -p atmega328p -C ~/avrdude_gpio.conf -c pi_3 -v -U flash:w:/tmp/build4952970404801881316.tmp/Blink.cpp.hex:i
- Résultats
Média:Avrdude.txt On observe bien clignoter la led branchée sur le GPIO 13, ce qui veut dire que l'upload a fonctionné.
Il nous faut maintenant compilé notre fichier C pour pour obtenir le fichier .hex.
Pour cela nous allons créer un Makefile.
- Problèmes rencontrés
Nous avons tenté de compiler notre code avec le Makefile d'Arduino. La compilation s'effectue sans problème mais lorsque le code est uploadé sur la carte, la LED s'allume et ne clignote pas comme elle devrait le faire.
Nous avons essayé de faire un Makefile en partant de celui utilisé en tutorat de Système.
Après modification, nous n'arrivons pas à compiler car le compilateur n'arrive pas à accéder à la librairie wiringPi.
En effet, nous avons réfléchi à notre Makefile en considérant le code prévu pour la Raspberry Pi. Cependant, le code était destiné à l'ATMega328p, d'où l'erreur lors de la compilation.
- Résolution des problèmes
Nous nous sommes rendu compte que la librairie wiringPi n'était pas utile et surtout pas utilisable sur l'ATMega328p.
En la remplaçant par les librairies avr/io et util/delay, le projet compile sans erreur et s'execute correctement sur l'ATMega328p.
Pour l'équipe 3 :
Cette partie sera traitée au S8.
L'objectif sera de créer une nouvelle table sans la base de données, permettant de récupérer les données venant des capteurs (des Raspberrys).
Il faudra également modifier le site afin d'ajouter une page permettant l'affichage de ces données.
Documents Rendus
- Pré-Rapport : media: Rapport_P10_S7.pdf
Projet S8
Objectifs
Suite à la soutenance de projet en fin de S7, nous avons de nouveaux objectifs :
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 ;
- Permettre aux administrateurs de créer et supprimer des comptes.
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 |
Terminé |
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 faits, 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 recevions 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é de mettre provisoirement de côté la partie communication par RX/TX pour avancer sur le reste, car la communication par liaison USB série fonctionne correctement.
En étant connecté par liaison USB, l'objectif consistait maintenant à connecter les capteurs et ainsi transférer de vraies données à la Raspberry.
Pour se faire, il nous fallait donc écrire les codes utiles pour tester ces capteurs en utilisant le langage C avec la librairie avr.
- Test du capteur de température ST039:
Il est basé sur le LM35 et délivre un signal analogique variant entre 0 et 5V selon la température mesurée. La température résultante quant à elle se situe sur la plage 0-100°c avec une précision de 0.5°c.
- Branchement :
Ci-dessous, le branchement avec une carte Arduino uno.
- 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
Semaine 4
Cette quatrième semaine a servi à tester le capteur de distance et à intégrer les données recueillis par la Raspberry dans un fichier.
- Test du capteur à ultrasons HC-SR04 :
Ce capteur ultrason utilise le principe de fonctionnement d'un capteur laser mais se base sur des ondes sonores (inaudibles pour l'homme) à la place d'un faisceau lumineux. Il est beaucoup moins cher qu'un capteur laser, toutefois il reste imprécis. On note néanmoins que ses mesures restent insensibles à la luminosité ambiante et à l'opacité de la surface en face.
Le HC-SR04 fonctionne avec une tension d'alimentation de 5V, un angle de mesure d'environ 15° et permet (sur le papier) d'obtenir des mesures de distance variant de 2cm à 4m avec une précision de 3mm (en pratique, ce n'est pas si précis que cela).
- 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.
- 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:
- 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 commande. (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és à 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).
Le script était parfaitement fonctionnel.
Semaine 8 | Confinement
Durant cette semaine, comme l'a expliqué l'Equipe 3, nous avons branché 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).
Confinement (Suite)
Durant cette semaine, il a été question de tester les fonctionnalités développées par cette équipe en l'interconnectant avec celles des autres équipes. Nous avons effectué une démonstration en live sur Discord en présence de M. Vantroys. La démonstration a été concluante, et nous avons tenu compte des remarques données afin d'optimiser notre travail.
- Fixer précisément des capteurs à des Ports USB de la Raspberry
Prenons le scénario suivant : Lorsque nous avons plusieurs périphériques (ici ce sont les capteurs via les microcontrôleurs) connectés aux différents ports USB de notre Raspberry. Supposons qu'il y ait un redémarrage de la Raspberry ou simplement un débranchement suivi d'un branchement de nos périphériques, là, nous ne pourrons pas déterminer quels ports USB (ttyACMX) leurs seront attribués à nouveau.
Ainsi, un capteur précédemment branché sur ttyACM0 pourrait se voir attribuer le port ttyACM1 et donc les remontées de données poseraient de sérieux problème à notre système. Nous devions donc trouver un moyen de lier un capteur (plus exactement un microcontrôleur) à un port USB bien déterminé, afin qu'aucun redémarrage ni re-branchement ne puisse lui en attribuer un autre.
Pour se faire, voici comment procéder :
- Déterminer les périphériques branchés
Le but ici est de déterminer quel périphérique a été lié à quel port USB. La meilleure façon c'est de débrancher les périphériques et de les rebrancher un par un. Dans un cadre de test, nous avons travailler avec l'une des Raspberry branchées en salle projet (172.26.145.113 sur laquelle il est connecté un Arduino avec un capteur).
dmesg | grep ttyACM
Sur le résultat de cette commande, nous allons noter quelques informations utiles pour la suite. La première chose à noter ce sont les chiffres juste après "cdc_acm" (1-1.5) et la deuxième consiste à retenir le numéro de port attribué (ici ttyACM0).
Nous devons aussi penser à donner un nom qui nous permettra de reconnaître notre périphérique à chaque fois qu'il sera connecté : ici je lui donnerai le nom "ttyACM_ARDUINO_TEMP" car un capteur de température y est lié.
- Recherche d'attributs
Afin de reconnaître plus tard de façon unique notre périphérique, il nous faudra nous servir d'attributs spécifiques permettant d'identifier ce périphérique parmi tant d'autres. Cela peut être l'identifiant du fournisseur ou le numéro de série.
udevadm info --name=/dev/ttyACM0 --attribute-walk
Il faut retrouver les chiffres notés précédemment "1-1.5". Nous avons choisi de baser notre identification uniquement sur les attributs Serial, idVendor et idProduct (bien évidemment il est possible d'en rajouter plus). Nous notons les noms et les valeurs des attributs pour les utiliser par la suite.
- Création du fichier de règles de noms de ports
Ici nous allons faire la liaison entre le périphérique et le port USB. Pour se faire, il nous faut créer un fichier qui encapsulera les règles nécessaires pour l'attribution d'un port spécifique à notre périphérique en fonction des attributs.
sudo nano /etc/udev/rules.d/usb-serial.rules
- Chargement des nouvelles règles
Pour rendre effectif les règles
sudo udevadm trigger
- Vérification des nouveaux noms de ports
ls -l /dev/ttyACM*
Ainsi nous pouvons voir le nouveau nom apparaître à la place du nom classiquement attribué "/dev/ttyACMX". Ce nom peut désormais être utiliser dans nos scripts pour désigner ce périphérique, et cela même après un redémarrage. De cette manière la gestion des ports USB peut donc être beaucoup plus stabilisée désormais.
- Script generique de fixation des périphériques aux ports
Pour terminer, nous avons devéloppé un script générique qui pourra être déployer depuis ansible sur les Raspberry Pi. Ainsi, au lieu de le faire manuellement pour chacun des périphériques, il suffira de la lancer depuis ansible pour que le script puisse écrire lui même les fichiers de règles selon le périphérique correspondant.
Vous pourrez voir le détail du code dans le git (fichier port.sh).
Récupération du code d'identification du périphérique
data=$(dmesg | grep ttyACM | cut -f 7 -d " " | cut -f 1 -d : ) code=$(echo $data | cut -f 1 -d " ")
On détermine quel numéro de port lui attribuer (Ex: capteur1-1 -> port 0)
port=$(pwd | cut -c 17) let port-- dev="/dev/ttyACM" name="$dev$port"
Récupération des attributs
commande=$(udevadm info --name=$name --attribute-walk | egrep "idVendor|idProduct|serial") idProduct=$(echo $commande | cut -f 1 -d " ") idVendor=$(echo $commande | cut -f 2 -d " ") serial=$(echo $commande | cut -f 3 -d " ")
Attribution d'un nouveau nom de port (ttyPRX à la place ttyACMX)
newdev="ttyPR" newname="$newdev$port"
Écriture des règles
rule="SUBSYSTEM==\"tty\", $serial, $idVendor, $idProduct, SYMLINK+=\"$newname\"" echo $rule >> /etc/udev/rules.d/usb-serial.rules udevadm trigger
Nous avons donc testé notre script depuis Ansible sur une Raspberry Pi à laquelle est fixé un capteur (via une carte Arduino) mais également sur une Raspberry Pi avec deux périphériques (deux capteurs sur deux Arduino). Les tests sont concluants.
Equipe 2
Semaine 1
Recherches concernant Ansible
Interet d'utiliser Ansible par rapport à d'autres logiciels : 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 logiciels ou utiliser docker
Il n'est pas nécessaire d'installer Ansible sur chaque nœud (dans notre cas les raspberry pi) seulement sur un serveur qui sera notre "node manager" (Ce dernier devant etre un système UNIX). Les noeuds devront juste permettre le ssh. Le reste pourra etre installé grace à Ansible.
le node manager doit pouvoir connaître les adresses 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 définir 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ée 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 renvoient leurs données directement au serveur principal.
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é, possibilité 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 nœuds 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 nœuds, 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 régler 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 nœud :
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 à paramétrer nos nodes. On utilisera pour le moment des lignes de commandes et pas des fichiers 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 utiliser 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 nœuds du fichier inventaire.ini
Maintenant on n'a plus besoin d'utiliser l'option --ask-pass.
Semaine 4
Un des buts 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 nœuds, 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 appeler nos playbook de paramétrage. Exemple avec un simple ping :
---
- name: Ping
hosts: all
remote_user: pi
tasks:
- 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 playbooks pour l’installation de tous les composants sur nos nœuds Ansible.
On voudrait que le fichier inventaire.ini nous donne les informations sur les choses à installer : cela devrait surtout dépendre de ce qui est connecté à la raspberry pi (Arduino ou autre).
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 playbooks s'exécutent suivant le groupe (le type) de machine.
Résultat :
Plusieurs rôles 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 rôles de production : ils copieront les fichiers, lanceront la compilation pour les scripts d’exécution.
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éparé 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 transférer les fichiers sur les raspberry pi (makefile ...)
Le rôle de fonctionnement en "production" à été ajouté. Il aura pour but de transférer 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éré 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’arrêtait lorsque ansible quittait le nœud.
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.
- Les différents fichiers envoyé sur 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.
- Ajout des fichiers et logiciels à installer sur les cartes lors de la première mise en place. (avr-dude/avr-gcc/avr-libc et fichier de config pour les GPIO)
- Un problème qu'il nous reste à régler est l'automatisation du transfert des clés 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.)
- Début de la rédaction du rapport et corrections de quelques erreurs présent du côté de Ansible.
Utilisation de Cron afin d'automatiser le lancement du fichier Rpi_to_server.py
Nous nous sommes intéressés à Cron afin d’améliorer un peu plus notre projet. L’objectif de l’utilisation de Cron est d’automatiser le lancement du fichier Rpi_to_server, initialement lancé grâce à une boucle infinie.
Tout d’abord, Cron est un programme qui permet aux utilisateurs d'exécuter automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiée à l'avance, ou selon un cycle prédéfini.
Il a fallu dans un premier temps se renseigner sur l’utilisation de Cron. Dans la table appelée Crontab, chaque ligne correspond à une tâche à exécuter et doit respecter cette notation : mm hh jj MMM JJJ tâche
- mm représente les minutes (de 0 à 59)
- hh représente l'heure (de 0 à 23)
- jj représente le numéro du jour du mois (de 1 à 31)
- MMM représente l'abréviation du nom du mois (jan, feb, ...) ou bien le numéro du mois (de 1 à 12)
- JJJ représente l'abréviation du nom du jour ou bien le numéro du jour dans la semaine
Pour chaque valeur numérique (mm, hh, jj, MMM, JJJ) les notations possibles sont :
- * : à chaque unité (0, 1, 2, 3, 4…)
- 5,8 : aux unités 5 et 8
- 2-5 : aux unités de 2 à 5 (2, 3, 4, 5)
- */3 : toutes les 3 unités (0, 3, 6, 9…)
- 10-20/3 : toutes les 3 unités, entre la dixième et la vingtième (10, 13, 16, 19)
Exemple :
0 0 13 1 5 tâche
La tâche sera exécutée le 13 janvier et tous les vendredis.
Il a fallu tout d’abord tester l’utilisation de la Crontab. Pour cela, nous avons créé un script très simple composé seulement d’un echo afin d’afficher "Bonjour". Puis nous avons modifié la Crontab à l’aide de la commande crontab -e. Nous avons donc ajouté une tâche à celle-ci et nous avons redirigé la sortie du script vers un fichier sauvegarde.txt afin de s’assurer de son bon fonctionnement.
Tâche ajoutée :
* * * * * /home/eymeric/test.sh >> /home/eymeric/sauvegarde.txt
Une fois les premiers pas sur Crontab effectués, il nous a fallu trouver un moyen de lancer celle-ci sans passer par la commande crontab -e. Nous avons donc utilisé dans un premier temps la commande
crontab <<<"* * * * * /home/pi/capteur1-0/python.sh /home/pi/capteur1-0"
Cette commande se lançant dans un script shell et permettant de mettre à jour la Crontab. Le lancement du fichier Rpi_to_server.py se faisait de manière automatique comme souhaité initialement et le serveur recevait les données du capteur tous les intervalles de temps définis.
Un seul problème restait en suspens qui était : comment ajouter ou supprimer une ligne de la Crontab lors de l’ajout ou la suppression d’un capteur par le serveur car cette commande supprimait le contenu de la Crontab puis écrivait dans celle-ci.
Suppression d’une ligne :
crontab -l | grep -v $pwd | crontab -
Ajout d’une ligne :
(crontab -l ; echo "*/$tps * * * * $pwd/python.sh $pwd") | crontab -
Cette nouvelle option de suppression de ligne nous permettant d’ajouter une nouvelle option pour les chercheurs sur le serveur permettant de supprimer un capteur qui avait été lancé préalablement. Cela permet au chercheur d’arrêter le script une fois que celui-ci n’en a plus besoin.
L’utilisation de la Crontab nous a permis d’automatiser le lancement du fichier Rpi_to_server.py et ainsi de contourner l’ancienne utilisation d’une boucle infinie dans le script shell lancé par Ansible. L’ajout de deux lignes de commandes dans le fichier shell, une permettant la suppression et l’autre permettant l’ajout d’une tâche dans la Crontab, a permis le fonctionnement de plusieurs capteurs en simultané mais aussi la suppression d’un capteur sans impacter le retour des valeurs d’un autre capteur actif.
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). |
Obsolète |
|
Modifier le script shell pour lui permettre d'envoyer les fichiers de données des capteurs en ssh sur le serveur. |
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. |
Fait |
|
Permettre l'ajout et la suppression de comptes depuis les comptes administrateurs. |
Fait |
|
Remonter les erreurs aux utilisateurs. |
Fait |
|
Permettre l'arrêt d'un capteur. |
Fait |
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 connecter à 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 Pi, 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 était 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éploiement des codes et le retour de données.
La deuxième idée est de créer un script PhP directement sur les Raspberry (déployé par Ansible).
Ce script permettrait la connexion au serveur et mettrait automatiquement la base de données à jour.
Plusieurs questions se posent alors :
- Peut-on exécuter un script PhP directement dans le shell ?
- Peut-on utiliser un code HTML pour l'exécuter dans le cas contraire ?
- Serait-il plus propre d'envoyer les données au serveur en ssh et de les traiter par un script qui s'y trouve ?
Le plus intéressant et pratique serait la dernière option. Une connexion ssh entre chaque Raspberry Pi et le serveur s’établirait à 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 - Obsolète
Pour envoyer les données par SSH, nous allons utiliser 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 tous 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 modifié 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 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'exécuteront 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 celle-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 fichier PhP contenant les fonctions utiles.
Il permet également le rafraîchissement 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 update_bdd().
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 modifié le script Python de l'équipe 1 pour y intégrer cette requête :
params = {"ip_address":"172.26.145.111", "numero":"2", "name":"Solaris", "data": data}
r = requests.post("http://serveur-etu.polytech-lille.fr/~grouille/PROJET/requests.php", data = params)
Cette requête permet l'envoi des données sur le serveur. Un script PhP (requests.php) récupère les données et utilise la fonction update_bdd(), qui met à jour la base de données de la même manière que update_values().
De cette manière, chaque Raspberry est indépendante et peut envoyer des données lorsqu'elle le souhaite.
Les requêtes SQL d'update s'executeront tour à tour grâce au système de verrous.
Semaine 5
Historique des capteurs
Nous avons créé un système d'historique qui enregistre la date et l'heure de chaque relevé dans une nouvelle table.
Nous allons créer un système de recherche et rendre accessible ces données à partir du site.
En arrivant sur la page de recherche, plusieurs possibilités :
- Sélectionner un capteur spécifique ;
- Sélectionner un type de capteur ;
- Sélectionner une adresse IP ;
- Sélectionner un intervalle de dates ;
- Sélectionne un nombre maximum de résultats.
Il est possible de combiner tous ces critères pour affiner les recherches.
On obtient un tableau contenant les informations utiles des capteurs.
Ajout d'un capteur depuis le site
Nous avons créé une page permettant d'ajouter un capteur à la liste des présents.
La requête est fonctionnelle et gère les doublons dans la table.
Il reste à utiliser Ansible dans cette partie pour ajouter les fichiers de base sur une Raspberry si elle n'existait pas avant.
Semaine 6
Migration sur un autre serveur
Lien du site : http://projet-p10.plil.fr/IMA3_P10/site
Fichiers raspberry : http://projet-p10.plil.fr/IMA3_P10/site/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érencié 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épôt 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.
L'équipe 2 a 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-data 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ée : 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.
Création et suppression de comptes depuis les comptes administrateurs
Nous avons commencé par créer une table groupes dans laquelle on trouve le noms des groupes (Administrateur et Membre) et un id qui leur est relatif. La table membres a été modifiée pour ajouter à chaque membre un groupe.
Nous avons créé une fonction permettant de savoir à quel groupe un membre appartient. De ce fait, on pourra permettre à un utilisateur d'accéder ou non à certaines pages du site.
Ensuite, nous avons créé un ensemble de pages contenant des formulaires pour permettre aux comptes administrateurs d'ajouter et de supprimer des comptes.
Remonter les erreurs aux utilisateurs
Les erreurs lors de la connexion, de la création ou de la suppression d'un compte sont maintenant remontées à l'utilisateur.
Page permettant la visualisation du réseau complet
Nous avons commencé une page permettant une visualisation graphique mais le rendu n'est pas terrible.
Nous allons sûrement nous rabattre sur une page un peu moins "graphique" mais plus lisible.
La page d'accueil où se trouvait un simple logo a été remplacée par la page de visualisation du réseau.
Suppression de Raspberry et de capteurs
De la même manière que pour les comptes, nous voulions que les utilisateurs puissent ajouter et supprimer des Raspberry et des capteurs.
Nous avons donc ajouter cette possibilité.
Protocole d'ajout manuel d'un Raspberry Pi
Lors de l'ajout d'un Raspberry Pi depuis le site, l'utilisateur dispose maintenant du protocole pour l'ajouter manuellement au réseau, avec les différentes commandes utiles.
Lancement d'Ansible
Pour permettre l'arrêt d'un capteur, l'envoi du temps de boucle de la règle Cron associée à un capteur ou encore la suppression du dossier d'un capteur, nous avons modifié le code PHP pour lancer Ansible avec les fichiers inventaire.ini correspondant.
Par ailleurs, nous avons modifié la page values.php pour y intégrer un formulaire d'arrêt des capteurs.
Récupération du résultat d'exécution d'Ansible
Pour permettre un maximum de débug et davantage de fiabilité lors de l'envoi des codes, nous avons voulu remonter les erreurs d'Ansible.
Pour se faire, nous avons tout simplement utilisé la fonction exec() dans sa globalité en lui donnant 2 autres paramètres :
- Un tableau dans lequel sera stocké les valeurs de retours ;
- Un entier qui contiendra le statut de l'exécution (égal à 0 si l'exécution se passe correctement).
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 sans 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.
- 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.
Confinement - Semaine 2
- Equipe 1 : Raspberry, Arduino, Capteurs
- Les Raspberry communiquent parfaitement avec le site via des requêtes POST ;
- Les codes sont modifiés et prêts (code température et code distance) ;
- Un Makefile générique est opérationnel (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 ;
- Éviter l'attente active des capteurs (boucle infinie) ;
- Début du rapport final.
- Equipe 2 : Ansible
- Ansible est opérationnel 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 ;
- Éviter 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.
- Remarques sur chat.plil.fr
- Démonstration ok.
Confinement - Semaine 4 à 6
- Equipe 1 : Raspberry, Arduino, Capteurs
- Un capteur correspond à un port USB unique du Raspberry Pi ;
- Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
- Diaporama de soutenance en cours ;
- Partie du rapport final terminée.
- Equipe 2 : Ansible
- Cron est fonctionnel ;
- Envoi du fichier temps.txt à la création d'un capteur ;
- Le script script.sh lance maintenant Cron ;
- Suppression du dossier des capteurs via Ansible ;
- Lancement du script d'arrêt de Cron via Ansible ;
- Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
- Diaporama de soutenance en cours ;
- Rapport final en cours.
- Equipe 3 : Site Web
- L'ensemble du réseau de capteurs est visualisable sur la page d'accueil;
- Les erreurs sont remontées à l'utilisateur ;
- Les administrateurs peuvent créer et supprimer des comptes ;
- Un utilisateur peut arrêter un capteur ;
- La suppression d'un capteur entraîne la suppression du dossier sur le Raspberry Pi via Ansible ;
- Les résultats d'exécution d'Ansible sont remontés à l'utilisateur ;
- Les fautes d'orthographe et de grammaire sur le wiki corrigées ;
- Partie du diaporama de soutenance terminée ;
- Partie du rapport final terminée.
- Remarques sur discussion
- Corriger les coquilles.
Confinement - Semaine 7
- Equipe 1 : Raspberry, Arduino, Capteurs
- Diaporama de soutenance terminé ;
- Partie du rapport final terminée.
- Equipe 2 : Ansible
- Diaporama de soutenance en cours ;
- Rapport final en cours.
- Equipe 3 : Site Web
- Partie du diaporama de soutenance terminée ;
- Partie du rapport final terminée.
Confinement - Semaine 8
Projet terminé.
Documents Rendus
- Gitlab : Git P10
- Site web : Site
- Rapport : media: Rapport_final_P10_2019_2020.pdf
- Diaporama : media: Diapo_final_P10_2019_2020.pdf
