P3 Capteurs enfuis pour vieillissement du béton : Différence entre versions
(→Interface de récupération des données) |
(→Rapport) |
||
| Ligne 336 : | Ligne 336 : | ||
===Rapport=== | ===Rapport=== | ||
| + | |||
| + | [[Fichier:RAPPORT_PROJETP3_GIOVA.pdf|Rapport de Projet]] | ||
| + | |||
| + | ===Fichiers de programmation=== | ||
| + | |||
| + | [[Fichier:Projet_P3_Prog.zip|Livrables de programmation]] | ||
Version actuelle datée du 20 juin 2017 à 10:34
- Etudiant : Florian Giovannangeli
- Encadrants : Alexandre Boé / Thomas Vantroys
Cahier des charges
Présentation générale du Projet
Contexte
Les ouvrages d'art sont généralement réalisés avec du béton. Le processus de maturation du béton est un ensemble de réactions chimiques qui dépendent de nombreux paramètres. Pour être suffisamment robuste, le béton doit sécher dans de bonnes conditions (température et humidité notamment). Le suivi du séchage par la mesure de paramètres comme l'humidité et la température à l'intérieur du béton est donc important afin de pouvoir anticiper et corriger les éventuels problèmes. Concevoir un capteur qui mesurerait ces paramètres tout au long de la vie du bâtiment serait donc une bonne solution.
Objectif
L'objectif de ce projet est de confectionner un prototype de capteur capable de mesurer et transmettre les caractéristiques à l'intérieur du béton au cours de sa maturation et de son séchage.
Description
Ce projet propose donc de concevoir et réaliser un système permettant de mesurer différents paramètres physiques (notamment température et humidité) et de les transmettre à une station de base. Différentes parties sont attendues :
- conception du capteur à base de composants du commerce et sur des standards éprouvés,
- conception d'une interface de récupération des données issues des capteurs,
- tests en situation réelle (coulage de béton avec insertion d'un capteur).
Durant la première phase de séchage, les conditions sont importantes pour garantir la qualité du béton. Pendant les 30 premiers jours après le coulage, les caractéristiques (température, humidité et vibration) seront donc mesurées et transmises toutes les heures. Par la suite, durant la maturation du béton, les données seront récupérées à hauteur de une mesure par jour jusqu'au 100ème jour de maturation. Après ces 100 jours, les données pourront être transmises tous les mois afin de contrôler d'éventuels problèmes post-maturation.
Ce capteur devra être capable d'émettre pendant 5 à 10 ans.
Contraintes
Capteur
Afin que le système de capteur puisse être inséré dans le béton et puisse réaliser les fonctions souhaitées, il est nécessaire qu'il soit :
- capable de transmettre régulièrement des données à travers le béton
- économe en énergie ; de façon à tenir plusieurs années
- de petite taille ; pour éviter une fragilisation de la structure en béton
- étanche ; pour éviter toute dégradation des composants
- rentable ; car il aura une unique utilisation
Interface
Pour être capable de suivre et analyser les caractéristiques mesurées, l'interface de récupération devra :
- être capable de recevoir en permanence les données envoyées par le(s) capteur(s)
- transmettre ces informations au PC pour le traitement et stockage
Schéma
L'idée générale de fonctionnement du capteur enfouis et de l'interface de récupération des données est la suivante :
Choix du matériel
Pour réaliser ce projet, il faudra avoir 2 modules : le module "capteur enfouis" et le module de récupération de données.
Afin de répondre aux fonctionnalités et aux contraintes définies précédemment, les composants nécessaires pour la conception de ces modules sont les suivants :
- 2 Feather M0 LoRa 433MHz
- 1 capteur(s) température et humidité
- 1 capteur micro vibration
- 1 batterie
Les cartes Feather M0 LoRa possèdent déjà les autres composants nécessaires, à savoir les micro-contrôleurs, les HTR (Horloges Temps Réel), les connecteurs USB/Série et alimentation. Du côté du module enfouis, il suffira donc de réaliser une carte avec les capteurs qui pourra se plugger sur la carte Feather M0 et qui sera contrôlée par le micro-contrôleur de cette dernière. On pourra ainsi mesurer les caractéristiques environnementales et les transmettre via le protocole LoRa. Du côté du module de récupération de données, une connexion directe avec le PC via USB permettra de récupérer les données et les transmettre au PC.
Autres :
- Boîtier étanche (à réaliser)
- Filtre anti-humidité (à voir)
Avancée du projet
Planning prévisionnel
| Semaine 1 (13/03) | Choix du sujet et études préliminaires |
|---|---|
| Semaine 2 (20/03) | Réunions avec les encadrants de projet et autres enseignants afin de définir les objectifs
Définition objectifs et cahier des charges / Recherches préliminaires |
| Semaine 3 (27/03) | Choix des composants / Réalisation du schématique / Etudes communication LoRa |
| Semaine 4 (03/04) | Réalisation du PCB / Tests communication LoRa et programmation |
| Semaine 5 (10/04) | Réalisation PCB / Tests émission/réception entre modules LoRa |
| Semaine 6 (17/04) | Réalisation PCB / Etudes des capteurs et du fonctionnement |
| Semaine 7 (24/04) | Correction PCB / Installation des librairies et programmes |
| Semaine 8 (01/05) | Demande d'impression carte / Programmation des capteurs |
| Semaine 9 (08/05) | Impression de la carte / Programmation des capteurs |
| Semaine 10 (15/05) | Impression de la carte / Réalisation de la trame de données |
| Semaine 11 (22/05) | Réception carte et composants / Réalisation de la trame de données |
| Semaine 12 (29/05) | Câblage première carte / Tests / Corrections PCB |
| Semaine 13 (05/06) | Câblage deuxième carte / Programmation générale et tests |
| Semaine 14 (12/06) | Corrections éventuelles / Tests réels / Réalisation rapport-vidéo |
Etudes préliminaires
Alimentation :
L'une des caractéristiques importantes du système souhaité est sa longévité. Même si son utilisation sera intermittente et de courte durée, le capteur doit pouvoir émettre des données pour une durée de 5 à 10 ans, et cela sans ravitaillement possible de l'extérieur. De plus, pour éviter une fragilité de la structure en béton ou pour des zones éventuellement étroites, il serait préférable d'utiliser une alimentation de petite taille. L'utilisation de piles aurait pu être intéressante pour la taille, mais la durée de vie risque d'être insuffisante. Dans un premier temps, j'utiliserai donc une batterie. Des études et des modifications pourront éventuellement être faites en fonction de la consommation des composants du capteur. Concernant le module de récupération de données, le problème ne se pose pas car il sera en permanence connecté au PC.
Communication :
La méthode de communication qui apparaît dans le cahier des charges et qui semble la plus pratique est la communication radio RF. Deux choix s'offrent alors : soit la réalisation d'une carte électronique "maison" avec les composants de notre choix (micro-contrôleur + émetteur/récepteur etc...), soit l'acquisition d'une carte déjà réalisée de type LoRa avec les fonctions souhaitées, puis connectée à une carte de mesure. Dans un premier temps, nous choisirons la deuxième option pour effectuer les tests. En effet, la carte 'Feather M0 LoRa' qui sera utilisée possède un module de communication RFM98 permettant l'envoi de données entre plusieurs cartes LoRa.
Micro-contrôleur :
Les fonctions de commande de notre système et les composants associés seront peu nombreux, de plus une fois mesurées, les données seront directement envoyées à l'interface et non stockées dans l'appareil. Un micro-contrôleur avec peu d'entrées/sorties et de mémoire flash peut donc faire l'affaire. Les modules 'Feather M0 LoRa' que j'utilise possèdent déjà un micro-contrôleur 'ATSAMD21G18 ARM' qui possède suffisamment de fonctionnalités pour permettre la commande des capteurs et le traitement des données. De plus il possède différents modes de fonctionnement (normal, veille...) pouvant être contrôlé par l'Horloge Temps Réel (HTR ou RTC) présente sur la carte et permettant une basse consommation en énergie. Il possède également un USART qui servira à programmer le micro-contrôleur, puis rapatrier les données vers le PC.
Boîtier :
La difficulté du boîtier qui contiendra le système est que celui-ci doit être étanche autour de la carte afin de protéger les composants électroniques du béton et notamment de l'eau lors de son coulage, mais il doit également laisser aux capteurs la possibilité de mesurer l'humidité et la température. Deux solutions sont à étudier : soit un boîtier laissant ressortir uniquement des capteurs supportant un certain degré d'humidité, mais sa réalisation devra donc être très précise selon les composants choisis, soit un filtre fin capable de laisser suffisamment passer l'humidité pour la mesurer sans risquer d'abîmer les autres composants.
Partie informatique
Premiers essais de communication
Pour les premiers essais de communication RF, il a été décidé d'utiliser 2 cartes 'Feather M0 LoRa 433MHz'. Ces cartes seront connectées d'une part à un PC pour le module de récupération de données, et de l'autre au module capteur qu'il va falloir réaliser.
Dans un premier temps, après étude de la Datasheet et autres informations trouvées sur les cartes Feather, j'ai pu réaliser une communication simple entre mes 2 modules. Il a d'abord fallu câbler des "antennes radio" sous forme de fil en suivant les spécifications données pour avoir une fréquence de 433MHz (fil de 16.5 cm). Ensuite, chaque module a été connecté à un PC, l'un servant de récepteur et l'autre d'émetteur. Après les différentes configurations et initialisations des micro-contrôleurs et des radios, le code de l'émetteur effectue une boucle qui envoie toutes les secondes un message de type "Hello World #" en incrémentant un numéro à chaque envoi. Il transmet également les informations sur la trame (longueur, FED...). Du côté du récepteur, le code effectue lui aussi une boucle qui vérifie en permanence si une trame avec les spécifications requises est reçue. Si c'est le cas, elle est affichée, puis le récepteur envoie une réponse à l'émetteur pour confirmer la réception. J'ai ensuite effectué ces mêmes tests en débranchant l'émetteur (puisque par la suite il sera enfouis et fonctionnera sans liaison série), alimenté par une batterie, pour tester son bon fonctionnement en autonome et sa portée.
NB: Pour réaliser cette opération, j'ai utilisé l'IDE Arduino conseillé dans la Datasheet. J'ai donc installé l'IDE sur deux PC, ainsi que les différents packages nécessaires à la programmation et l'utilisation des modules Feather.
.
Programmation des capteurs
Après avoir étudié attentivement les Datasheet des deux capteurs HTU21D (température/humidité) et FXLS8471Q (accéléromètre), j'ai effectué plusieurs recherches afin de mieux assimiler les différentes applications des capteurs avec des Arduino. J'ai pu ensuite télécharger des librairies correspondant à ces capteurs qui sont :
- SparkFun_HTU21D_Breakout_Arduino_Library-master
- SparkFunHTU21D.cpp
- SparkFunHTU21D.h
- FXLS8471Q-master
- FXLS8471Q.ccp
- FXLS8471Q.h
La librairie de l'accéléromètre FXLS8471Q était cependant codée pour une connexion SPI, or mes deux capteurs sont en I2C, je n'ai donc pas pu l'utiliser. Je m'en suis tout de même servi, ainsi qu'avec d'autres exemples trouvés et surtout à l'aide la Datasheet, pour réécrire ma propre librairie permettant cette fois une configuration et une utilisation des fonctions en I2C. Ces programmes contiennent la déclaration et la configuration de tous les registres, variables et fonctions permettant de faire fonctionner les capteurs. J'ai donc pu ensuite sélectionner les fonctions souhaitées et les intégrer à mon programme d'Emission dans l'IDE Arduino.
Réalisation de la trame de données
Suite à ces premiers tests, je me suis lancé sur la définition d'une nouvelle trame de données plus complète et une modification du programme afin de pouvoir transmettre par la suite les caractéristiques mesurées par les capteurs.
J'ai rencontré de nombreuses difficultés sur cette partie au niveau des différents types et donc des conversions de variables. En effet, les premiers essais effectués envoyaient seulement une trame de caractères déjà définie, sans conversion. Niveau récepteur également une simple réception dans une chaîne de caractère et l'affichage série suffisait. Or pour la suite les données reçues par les capteurs sont de types différents : réels (float) pour l'humidité et la température, et entiers signés 16 bits (int16_t) pour l'accéléromètre.
Dans un premier temps j'ai tenté de convertir les réels du capteur par des chaînes de caractères simples (String) que j'intégrais ensuite dans le paquet à transmettre, idem à l'inverse pour la réception. Cette solution fonctionnait mais convertissait donc chaque chiffre et même la virgule des entiers en un (char) et donc en un octet. Cela rendait la trame trop longue, risquant de surcharger la fréquence radio et de perdre des données.
Pour une meilleure optimisation, j'ai donc fait des recherches sur les conversions, les "cast" et les différentes méthodes pouvant fonctionner. La solution trouvée est d'utiliser des pointeurs de type (unsigned char*) sur l'adresse des variables, puis d'effectuer des 'memcpy' (copie mémoire) à partir des pointeurs vers le tableau paquet. Cette méthode permet d'insérer tous les bits de chaque variable les uns à la suite des autres dans la trame. Du côté récepteur, il suffit d'effectuer la même chose en inverser, c'est à dire de copier chaque bit un à un dans les variables associées. On retrouve alors les valeurs, quelque soit leur type, avec une trame plus courte.
Programmation de la RTC
L'envoie des caractéristiques récupérées par les capteurs a été défini dans le cahier des charges en fonction du temps écoulé après coulage du béton. Pour ce faire, il faut donc que le programme du module enfoui puisse connaître la durée écoulée en temps réel et adapte ainsi sa fréquence d'envoi. Il nous faut alors utiliser la 'RTC' (Real Time Clock ou Horloge Temps Réel) présente sur le 'Feather M0' pour contrôler cela.
J'ai alors défini 3 cas distincts :
- Début -> 30 jours = Emission toutes les heures
- 30 jours -> 100 jours = Emission tous les jours (à 8h00)
- 100 jours -> Fin = Emission tous les mois (le 1er de chaque mois à 8h00)
Pour ce faire, j'ai utilisé la librairie RTCZero.h. Cette librairie contient de nombreuses fonctions pour démarrer la RTC, régler l'heure et la date, régler une alarme et surtout mettre le module en mode veille (standby). Une fois l'heure et la date de mise en route du module réglée, le programme effectue une boucle avec l'envoi des données puis, en fonction du cas dans lequel on se trouve, règle une alarme pour le prochain réveil par interruption et met le module en mode veille. Ainsi on économise la batterie pendant le temps d'attente, et le module ne se réveille qu'une fois le moment voulu pour envoyer les données et se remettre en veille.
Interface de récupération des données
Du côté récepteur, le cahier des charges stipulait la mise en place d'une interface de récupération des données. Lors de mes premiers tests, les données reçues n'apparaissaient que dans l'interface série de l'IDE Arduino, mais ces données ne sont pas conservées lors de la fermeture de l'IDE. J'ai donc fait des recherches pour trouver le moyen de récupérer ces données.
L'une des solutions consiste à utiliser un logiciel de lecture de port série proposant une option d'enregistrement des informations reçues. J'ai pour cela utilisé le logiciel PuTTY qui enregistre tout ce qu'il reçoit du port série dans un fichier texte de type .log. Cette solution fonctionne correctement et permet de garder une trace des données, mais celles-ci sont difficilement exploitables par la suite. Une autre solution est de réaliser un programme en Python qui réceptionne les infos du port série, et les enregistre sur un fichier de type .csv, exploitable ensuite par une tableur par exemple. Mes connaissances en Python étant limitées, j'ai dû faire plusieurs recherches à ce sujet et j'ai réalisé des tests qui m'ont donné quelques résultats. Or cette option était selon moi trop compliquée pour pas grand chose.
La dernière et meilleure solution est d'utiliser une macro Excel ou LibreOffice qui se connecte au port Série et qui, à l'aide d'une typographie bien définie, enregistre directement les données reçues dans un tableur. J'ai ainsi pu trouver une macro appelée OpenDaqCalc sur LibreOffice permettant de faire cela. J'ai dû modifier la macro ainsi que mon code de réception afin d'afficher les valeurs souhaitées et de les exploiter avec des graphiques.
.
Partie électronique
La carte électronique contenant les capteurs de température, humidité et vibration doit pouvoir se brancher directement sur la carte Feather M0. Pour cela, je suis parti sur une carte reprenant les emplacements exacts des connecteurs 16 et 12 branches du Feather et de placer les capteurs au milieu.
Après plusieurs versions de schématiques et PCB, plusieurs modifications ont été apportées, notamment au niveau du capteur de température/humidité SHT11 qui a été remplacé par le HTU21D. Ce changement est dû à son prix plus abordables et à son âge plus récent lui fournissant une meilleure fiabilité. Cependant, ce nouveau capteur ne se trouvait pas dans la bibliothèque 'Fritzing', et aucune version n'était disponible sur le Web. J'ai donc dû réaliser ce composant en respectant les consignes établies par le créateur de composant 'Fritzing'. Trois fichiers SVG sur 'Inkscape' ont été réalisés pour : la vue Breadboard, la vue schématique et l'empreinte PCB.
Une première carte a ensuite été tirée. Dans un premier temps je n'ai câblé que le capteur HTU21D de façon à tester cette partie du circuit. J'ai ensuite réalisé des tests avec mon programme : le module fonctionne. Testé dans différentes conditions de température et humidité, les données semblent être cohérentes et sont bien transmises à l'émetteur.
Avec cette première carte j'ai pu repérer plusieurs erreurs que j'avais commises. Notamment au niveau du capteur HTU21D que j'avais branché sur des sorties SPI (SCK / DATA) et non I2C (SCL / SDA) du module Feather. J'avais donc dû gratter les pistes et mettre des fils pour les premiers tests. Il a donc été nécessaire de revoir entièrement le PCB et de replacer les composants de façon à permettre les connexions des 2 capteurs à SCL et SDA. J'en ai profité pour corriger quelques imperfections sur la carte, et j'ai donc pu commander une seconde carte.
Le schématique et le PCB finaux de la carte des capteurs sont consultables dans les livrables plus bas.
NB1 : Les connecteurs reprennent les pin in/out de la carte Feather à titre informatif, mais ne sont pas tous utilisés.
NB2 : La carte étant simple face, les vias seront connectés par des fils sous la carte.
. Une fois la deuxième carte reçue, j'ai pu câbler l'ensemble de mes composants. Pour ce faire, j'ai pu utiliser, avec l'aide de M.Flamen, l'assemblage au four avec de la pâte à braser. Nous avons cependant eu quelques problèmes avec l'accéléromètre qui est petit et a des pattes très rapprochées. Certaines des pattes ont été soudées entre elles et nous avons donc dû régler ces soucis manuellement avec une soufflerie à air chaud pour retirer le composant et le ressouder correctement. J'ai pu ensuite tester ma nouvelle carte qui fonctionne correctement, fournissant des valeurs de température, humidité et sensibilité XYZ cohérentes et correspondant à mes attentes.
Livrables
Détails composants
Schématiques et PCB
Rapport
Fichier:RAPPORT PROJETP3 GIOVA.pdf
