Contrôle d'une VMC

Vidéo HD

Cahier des charges du projet

Explication du sujet

Nous allons tout d'abord définir plus précisément notre projet suite à un entretien avec nos tuteurs. L'objectif est de réaliser une VMC (Ventilation Mécanique Contrôlée) simple flux dite "intelligente". Le principe de la VMC simple flux est d'extraire l'air de pièces dites "humides" (cuisine, salle de bains et toilettes) ce qui crée une dépression dans la maison. L'air extérieur rentre ensuite par des ouïes placées dans les "pièces à vivre" (chambre, séjour, etc ...) grâce à la dépression créée, ce qui permet d'avoir ainsi une maison ventilée avec un air sain. Elle peut, et c'est notre cas ici, avoir plusieurs vitesses.

Voici un schéma illustrant le principe de la VMC simple flux :

Le but de notre projet est de commander cette VMC à partir de paramètres qui sont :

-les températures intérieure et extérieure

-le pourcentage d'humidité des pièces dites "humides"

-la qualité de l'air dans la maison

-le taux de CO2 dans la maison

-la présence de personnes dans la maison

-l'état du système de chauffage de la maison (ON/OFF)

Nous pourrons donc comparer tous ces paramètres, une fois acquis, à des "scénarios" que nous aurons prédéfinis et qui nous permettront donc d'établir une commande "intelligente" du système d'extraction. La raison d'être principale de ce projet est évidemment d'économiser l'énergie en ne laissant pas tourner la VMC constamment d'une part, et en limitant son utilisation le plus possible lors du chauffage d'une pièce d'autre part.

Travail à réaliser

Après avoir compris le fonctionnement de la VMC et ciblé le travail à faire pour l'améliorer, nous nous sommes mis d'accord sur les solutions techniques à adopter pour mener à bien notre réalisation. Tous les paramètres évoqués précédemment (servant à commander la VMC) seront bien évidemment acquis par des capteurs, ou simulés dans le cas de capteurs trop chers et/ou rares. Ces données seront transmises au microcontrôleur (Arduino avec son ATMEGA328P) et traitées pour établir le signal de commande de la VMC. Ladite VMC sera simulée par un ventilateur à plusieurs vitesses ou bien un moteur si nous ne disposons pas d'une véritable VMC. Nous réaliserons aussi une maquette d'une maison pour pouvoir simuler notre système.

Pour le moment, nous avons réparti les tâches au sein de notre binôme :

-un membre s'occupe de définir l'architecture nécessaire autour du microcontrôleur et de réaliser la carte correspondante

-l'autre s'occupe d'établir l'algorithme de commande à partir des paramètres dont nous avons déjà parlé

-les deux membres établissent la maquette de la maison et la feront ensuite fabriquer (probablement à l'atelier mécanique)

Si nous parvenons à finir toutes ces tâches, nous nous attellerons à la conception d'une carte servant d'interface entre le microcontrôleur et une véritable VMC (en 220V).

Mise à jour 12/02

Nous réaliserons une carte capteurs qui regroupera tous les capteurs nécessaires ainsi qu'un Arduino et son module Xbee pour communiquer les données vers la carte principale (celle qui commande la VMC), dotée elle aussi d'un module Xbee.

Matériel acquis (liste évolutive au cours des séances)

-capteur de température et humidité pour l'intérieur de la maison (DHT11) 05/02

-capteur de température pour l'extérieur de la maison (LM35) 05/02

-boîte rouge SparkFun 10/02

-2 modules Xbee + 2 Arduino Uno + programmateur AVRII 12/02

Travail réalisé

10 Février / 15 Février

Partie commande :

Lors de cette première semaine de projet et concernant la partie commande, il a fallu définir comment nous allions procéder pour mettre en place la commande de la VMC. Nous avions déjà défini le microcontrôleur à utiliser (ATMEGA328P au sein d'un Arduino, Uno pour la phase de développement et Mini pour la phase finale d'implantation). Il ne nous restait donc plus qu'à définir quels capteurs nous devions utiliser et ensuite quel type de commande nous allions mettre en œuvre (méthode de régulation choisie incluant l'élaboration de scénarios possibles quant à la température et les paramètres de l'air dans les pièces humides).

Nous nous sommes d'abord penchés sur l'aspect récupération des données issues des capteurs sur l'Arduino Uno. Les capteurs que nous utilisons sont :

-le DHT11 : capteur de température/humidité disposant de sa propre librairie pour faciliter la récupération des données sur un Arduino.

Il dispose de 3 broches qui sont l'alimentation, la masse et les données que transmet le capteur sous forme de trames.

-le LM35 DZ : capteur de température qui lui a aussi 3 broches, les mêmes que celles du DHT11 sauf que la broche de données délivre une tension analogique (fonction de la température) et non une trame de bits.

En ce qui concerne les capteurs de CO2 et de qualité d'air, le premier est trop cher pour pouvoir en avoir un, il sera donc simulé à l'aide d'un potentiomètre et le second est en fait superficiel pour notre système et ne sera donc pas mis en place pour l'instant.

Nous avons donc réalisé sur "plaque lab" les montages électriques permettant de relier les capteurs à l'Arduino pour l'exploitation des données. Il suffisait de câbler l'alimentation, la masse et de relier les broches de données aux broches de l'Arduino (une broche analogique pour le LM35 DZ et une broche numérique pour le DHT11). Le DHT11 nécessite une résistance de pull-up en plus (voir schéma ci-dessous).

Les montages une fois faits, nous avons décidé d'utiliser l'environnement Arduino IDE ainsi que les librairies Arduino pour le développement. Comme dit, précédemment, le DHT11 dispose de sa propre librairie et nous n'avions donc plus qu'à utiliser les fonctions pour récupérer la température et l'humidité (il faut réveiller le capteur qui répond ensuite avec une trame dans laquelle sont inclus deux octets contenant ces données). Concernant le LM35 DZ, il suffit d'utiliser l'ADC pour convertir la tension analogique en un nombre binaire que l'on remet à l'échelle (en fonction de la sensibilité du capteur, des tensions d'alimentation de l'ADC et du nombre de bits de la conversion) pour récupérer notre température, à l'aide de la fonction analogRead.

Câblage du DHT11

Partie cartes :

Durant ces premières séances, on a essayé d’appréhender le projet et essayer de choisir la technologie à adopter. Pour faire communiquer les différentes parties du système on a décidé d’utiliser le protocole Zigbee*, qui est un protocole peu compliqué et plus facile à mettre en œuvre, sachant qu’il est tout à fait fonctionnel pour notre projet. Pour réaliser la partie émettrice ainsi que la partie réceptrice on a décidé d’implanter un microcontrôleur, le choix s’est fixé sur un Arduino Mini, vu sa petite taille et le fait qu’on est familier avec ce type de microcontrôleurs. Du côté émetteur l’Arduino sera connecté à plusieurs capteurs (Humidité, Température, Présence …) ainsi qu’à un module Xbee qui assurera la transmission des données vers la partie réceptrice, cette partie ne contiendra qu’un Arduino pour commander la VMC et un Xbee qui se chargera de récupérer les données envoyées par les capteurs.

Une fois l’architecture des cartes émettrice et réceptrice définie, on a commencé la réalisation de ces dernières sur le logiciel CadSoft Eagle, qui permet de créer des circuits imprimés. Une des difficultés rencontrées lors de cette étape était de trouver les composants utilisés (DHT11, LM35, Xbee, Arduino Uno …) sous ce logiciel. Mais après quelques recherches approfondies sur internet, on a fini par trouver quelques-uns de ses composants, les autres étant introuvables, on a dû les établir grâce aux données relatives aux dimensions fournies par le constructeur.

Les composants tous récupérés sous CadSoft Eagle, on a commencé le routage de la carte réceptrice, quant à la carte émettrice on l’a entamé sans pour autant la finir, faute de non disponibilité de certains capteurs ce qui rend la liste des capteurs de la carte émettrice ouverte et donc la carte modifiable à tout moment.

Carte réceptrice

Carte émettrice

• ZigBee est un protocole de haut niveau permettant la communication de petites radios, à consommation réduite, basée sur la norme IEEE 802.15.4 pour les réseaux à dimension personnelle (Wireless Personal Area Networks : WPAN).

17 Février / 22 Février + 3 Mars / 8 Mars

Partie commande :

Capteurs

Simulation du capteur de CO2 par un pont diviseur de tension composé d'une résistance et d'un potentiomètre aux bornes duquel on vient prélever la tension. A l'instar du montage constitué du LM35 DZ, ce montage délivre une tension analogique et doit, en conséquence, être branché sur une broche analogique de l'Arduino. La tension sera convertie en un nombre binaire sur 10 bits (de 0 à 1023) qu'il faut remettre à l'échelle avec un coefficient dépendant de la plage du taux de CO2 que l'on voudra simuler (probablement de 200 à 2000 ppm).

Simulation de la VMC commandée par PWM à l'aide d'une LED branchée par l'intermédiaire d'une résistance, sur une broche digitale de l'Arduino. Cette dernière génère un signal PWM. On s'est servi du montage précédent (qui n'avait donc plus rien à voir avec un simulateur de CO2) pour changer la valeur du rapport cyclique de la PWM, qui faisait donc varier l'intensité lumineuse de la LED (qui symbolise la vitesse de la VMC). Voici ci-dessous, les bouts de code qui permettent de récupérer les données issues des capteurs

Logique floue

Nous avons commencé à mettre en place la commande de la VMC en fonction des paramètres recueillis, grâce à tous les montages simulés sur "plaque lab". Le type de commande choisi est la "logique floue" car elle ne nécessite pas de connaître le modèle mathématique du système, ce qui est utile car il nous est impossible de le déterminer. Le principe de la "logique floue" repose sur 3 étapes :

-la fuzzification : qui consiste à créer des fonctions d'appartenance pour chacune des entrées (froid ou chaud pour la température par exemple) et des sorties. Elles sont comprises entre 0 et 1 et dépendent de la grandeur de l'entrée. 2 fonctions d'appartenance consécutives, également, se chevauchent. La différence notable est que ces fonctions ne sont pas tout ou rien (on peut être "un peu froid" ou "moyennement froid", pas seulement "froid" ou "pas froid"). Nos entrées ici sont donc les températures intérieure et extérieure, l'humidité intérieure et le taux de CO2 intérieur.

-l'inférence : qui consiste à créer les règles de commande sous la forme if "entrée1 = ... and entrée2 = ... and ... then sortie = ..."

-la défuzzification : qui consiste à partir des règles d'inférence définies précédemment et des fonctions d'appartenance créées durant la fuzzification, de commander la sortie.

Nous avons fini la fuzzification, c'est-à-dire que nous avons défini pour toutes nos entrées/sorties les fonctions d'appartenance. Nous avons pu créer ces fonctions grâce à des informations tirées d'Internet quant aux seuils acceptables/préférables et dangereux/inadaptés des différents paramètres. Ci-dessous, sont décrits ces seuils et se trouvent les fonctions d'appartenance définies.

Informations sur la qualité de l'air :

taux de C02

-<400 ppm : excellente qualité d'air

-400-600 ppm : qualité moyenne

-600-1000 ppm : taux acceptable

->1000 ppm : mauvaise qualité d'air (danger)

taux d'humidité

-entre 40 et 60 % : bon taux

-<30 % : trop sec (alarme taux trop bas)

->70 % : trop humide (alarme taux trop haut)

température

-19 degrés

MF des E/S

Partie cartes:

L'architecture complète des cartes émettrice et réceptrice a été définie. La liste définitive des capteurs retenus est :

- Un capteur de température (LM35)

- Un capteur d'humidité (DHT11)

- Un capteur de taux de CO2 (Simulé car trop cher)

On a réalisé plusieurs versions des cartes émettrice et réceptrice. Les changements qu'on a du y apporter à chaque fois se résument comme suit :

- Changement de la taille des pastilles en en mettant des plus larges.

- Réduction de la taille des drills (Trop grands dans certains cas).

- Rajout de capacités de découplage entre les pins d'alimentations des composants (Xbee et Arduin) et l'alimentation . Ceci pour évacuer les harmoniques de haute fréquence et augmenter l'immunité électromagnétique du circuit. Ainsi on limite l'influence des perturbations, d'autant plus que leur fréquence est élevée.

- Rajouter un transistor sur la carte émettrice pour augmenter la puissance qui va vers la VMC.

- Relier les pins non-utilisées de l'Arduino à des connecteurs, au cas où on aurait besoin de relier des composants non prévus d'avance.

- On a refait entièrement les 2 cartes, en utilisant le bottom comme plan de masse, ce qui réduit la taille des fils à router et donne un aspect plus esthétique à la carte.

- Rajouter un potentiomètre sur la carte émettrice, pour simuler le capteur de CO2.

Schematic de la carte émettrice

PCB de la carte émettrice

Schematic de la carte réceptrice

PCB de la carte réceptrice

10 Mars / 5 Avril

Partie commande :

Nous avons tout d'abord fini d'établir notre modèle flou concernant la qualité de l'air et son lien avec la vitesse de la VMC. La dernière fois, nous avions fini la première étape qui concernait à fuzzifier les entrées du systèmes (paramètres de qualité de l'air). Nous avons donc continué avec l'inférence et la défuzzification que nous allons exposer dans les paragraphes suivants.

Inférence :

Comme dit la dernière fois, l'inférence est la définition des règles de commande sous forme de if "condition then sortie". Détaillons un peu plus cette structure : en fait on a : if "entrée1 = MFentrée1 and entrée2 = MFentrée2 ..." then "sortie = MFsortie" où MFentrée1 est une fonction d'appartenance (Membership Function) de l'entrée 1 définie au préalable. Il en va de même pour MFentrée2 et MFsortie. Un exemple avec notre système donnerait : if "humidity = humid then sortie = fast".

Voici toutes les règles d'inférence que nous avons définies pour notre système :

-1 If (CO2_rate is bad) then (MCV_speed is fast)

-2 If (CO2_rate is excellent) and (humidity is humid) then (MCV_speed is fast)

-3 If (CO2_rate is excellent) and (humidity is good) and (temperature is hot) and (ext_temperature is not hot) then (MCV_speed is slow)

-4 If (CO2_rate is good) and (humidity is good) and (temperature is hot) and (ext_temperature is not hot) then (MCV_speed is tempered)

-5 If (CO2_rate is good) and (humidity is humid) then (MCV_speed is fast)

-6 If (CO2_rate is acceptable) and (humidity is good) and (temperature is not cold) then (MCV_speed is slow)

-7 If (CO2_rate is acceptable) and (humidity is good) and (temperature is hot) and (ext_temperature is not hot) then (MCV_speed is tempered)

-8 If (CO2_rate is acceptable) and (humidity is humid) then (MCV_speed is fast)

-9 If (CO2_rate is not bad) and (humidity is dry) then (MCV_speed is stop)

-10 If (CO2_rate is excellent) and (humidity is not humid) and (temperature is not hot) then (MCV_speed is stop)

-11 If (CO2_rate is good) and (humidity is not humid) and (temperature is not hot) then (MCV_speed is stop)

-12 If (CO2_rate is excellent) and (humidity is good) and (temperature is hot) and (ext_temperature is hot) then (MCV_speed is stop)

On a donc défini nos règles et à forciori le comportement voulu de notre système. Le problème maintenant est de définir un degré d'appartenance (similaire au concept de MF), à chaque règle que l'on vient de définir car ce ne sont pas des conditions binaires au sein desdites règles. Il faut faire appel aux opérateurs flous pour pallier ce problème, en vue d'une future implantation au sein d'un microcontrôleur. Ici, seuls deux opérateurs nous sont nécessaires quant aux types de règles que l'on a :

-le AND est l'opérateur mathématique min

-le NOT (X) est remplacé par 1 - X

Prenons un exemple concret sur la règle simple suivante : if "temperatureInt is hot and humidity is not humid then VMC = tempered"

où hot, humid et tempered sont les MF respectives de chaque entrée/sortie de la règle d'inférence. La fuzzification nous retourne donc une valeur entre 0 et 1 pour chaque entrée vis-à-vis de sa MF considérée. Admettons ici que l'on ait :

-temperatureInt is hot = 0.5

-humidity is humid = 0.25

On a donc 0.5 AND 1 - 0.75 = 0.5 AND 0.25 = min (0.5,0.25) = 0.25. Le degré d'appartenance de cette règle vaut donc 0.25. Cette méthode est donc appliquée à toutes les règles de notre système et va permettre de défuzzifier le système très simplement comme nous allons le voir dans le paragraphe suivant.

Défuzzification :

La dernière étape est donc la défuzzification. Celle-ci concerne tout simplement à pouvoir appliquer une valeur de consigne à notre système, qui aura été déterminée par le comportement décrit par les règles d'inférence et les MF des E/S, toutes définies et explicitées précédemment.

Il existe plusieurs méthodes de défuzzification qui ont été développées par des chercheurs qui ont planché sur la logique floue. Ici, nous utiliserons une méthode simple et robuste nommée centroid, signifiant en anglais centre de gravité. Cette méthode lie notre sortie, par une relation très simple, aux degrés d'appartenance des règles d'inférence et à l'abscisse du max de la MF de sortie utilisée dans la règle considérée. Ces derniers paramètres seront respectivement notés A et B pour alléger la formule :

- sortie = $(\sum A*B)/(\sum A)$

Prenons encore une fois un exemple concret pour éclaircir cette formule. Admettons que l'on ait deux règles ayant comme degré d'appartenance 0.75 et 0.25. Ces deux scalaires correspondent aux valeurs A dans notre formule. Pour la première règle admettons que la MF de sortie soit fast et pour la seconde slow. Conformément à l'explication précédente et à la MF définie précédemment (voir photo ci-dessus), on a donc B valant 100 % pour la première règle et 20 % pour la deuxième. Si on applique la formule on aura donc la sortie qui vaudra :

sortie = (0.75*100 + 0.25*20) / (0.75 + 0.25) = 80 %

Nous voilà arrivés au terme de l'établissement de notre modèle flou pour la commande de notre système. Il faut maintenant l'implanter au sein d'un microcontrôleur (ici l'Arduino Uno), donc en langage C. C'est l'objet des paragraphes suivants qui va traiter de l'adaptation de tout ce que nous avons expliqué à propos de la commande floue, en langage C.

Ci-dessous se trouve un schéma résumant les 3 étapes, qui constituent un FLC (Fuzzy Logic Controller), que nous avons expliquées.

Structure d'un FLC

Implantation au sein du microcontrôleur :

C'est sans nul doute l'étape la plus intéressante du projet : transformer notre modèle théorique en quelque chose de compréhensible par le microcontrôleur pour commander le vrai système physique. Nous allons procéder de la même manière que précédemment pour expliquer le travail réalisé, c'est-à-dire que l'on va détailler l'implémentation de chacune des 3 parties du FLC (fuzzification, inférence et défuzzification).

Fuzzification

Le travail de récupération des différents paramètres à l'aide des capteurs avait déjà été réalisé donc nous avions déjà les données sous la main pour commencer la fuzzification de chaque entrée. Cette partie est la plus simpliste. En effet, il suffit de retourner l'image des données capteurs pour chacune de leurs MF qui sont triangulaires ou trapézoïdales (donc des fonctions linéaires/constantes). Voici la fonction permettant de retourner l'image d'une donnée capteur pour une MF donnée :

NB : b et c sont confondus dans le cas d'une MF triangulaire

La précédente fonction sert de base pour fuzzifier. Il a fallu généraliser cela à tous nos paramètres et stocker les résultats d'appartenance à chaque MF. Ces derniers sont stockés dans des tableaux de taille "nombre de MF pour le paramètre considéré". De plus, les arguments a,b,c et d de la fonction fuzzify_MF sont stockés dans des tableaux de taille "4*nombre de MF pour le paramètre considéré". Voici le bout de code qui a permis cela (tous les tableaux et les paramètres mesurés par les capteurs sont les paramètres de la fonction) :

Inférence

Cette deuxième partie était intéressante à réaliser car il a fallu s'interroger quant à un moyen de stocker des règles de type if X and Y then Z. Le choix retenu est un tableau d'une structure contenant des tableaux pour chaque paramètre capteur. le tableau de structure contient autant de cases que de règles (i.e chaque case = une règle) et les tableaux des paramètres capteurs contiennent autant de cases que de MF liées au paramètre considéré.

La structure est remplie de la manière suivante : pour chaque case de cette dernière correspond donc une règle. Et chaque case des tableaux internes à la structure vaut 0,1 ou 2 selon que la case, qui correspond à une MF d'un paramètre capteur, fait intervenir cette dernière dans la règle d'inférence (1 ou 2 si la MF intervient en NOT) ou non (0 dans ce cas). Voici la définition en C de tout ce que l'on vient d'expliquer, c'est-à-dire de toutes les règles d'inférence. Ce bout de code sert d'exemple à la compréhension de ce paragraphe et on notera l'initialisation de la structure entière à 0.

La deuxième partie consiste à parcourir cette structure pour en déduire les degrés d'appartenance aux règles d'inférence. En se référant aux explications données précédemment à ce sujet (sur les opérateurs flous dans l'explication de l'inférence), on peut aisément comprendre le bout de code ci-dessous qui stocke dans le champ f de la structure rules le degré d'appartenance de la règle.

Défuzzification

Nous voici dans la dernière partie de l'implantation de l'algoritmhe de notre FLC. Cette partie s'est aussi avérée simple car il a suffi d'appliquer la formule de défuzzification centroid évoquée dans les paragraphes précédents. Le bout de code correspondant se trouve ci-dessous et retourne donc la valeur de sortie à appliquer à notre VMC. Cette dernière n'a plus qu'à être envoyée (à un coefficient près) sur une sortie PWM pour obtenir un signal de commande (à amplifier bien évidemment) de la VMC.

Communication entre la partie capteurs et la partie commande grâce au protocole Zigbee

Nous l'avons vu précédemment, nous avons réalisé en entier la partie commande de la VMC. Cette dernière se compose, pour résumer très rapidement, de la récupération des données capteurs et de l'algorithme de commande floue à partir de celles-ci. Jusqu'à présent, tout avait été fait et testé dans le même programme. Cependant, comme nous l'avons déjà exposé auparavant, deux cartes sont prévues : l'une récupérant les données capteurs et les transmettant à l'autre (via le protocole Zigbee) qui va s'en servir pour l'algorithme de commande. Il a donc fallu splitter notre programme en deux pour le mettre sur deux microcontrôleurs différents (Arduino Uno), programmer deux modules Xbee Series 1 pour la communication et sur le second microcontrôleur recevant les données capteurs, écrire un bout de code permettant de recomposer les chaînes de caractères reçues et en extraire les données utiles.

La programmation des Xbee Series 1 s'avère être une tâche très facile. Il suffit de connecter son Xbee (branché sur un adaptateur USB fourni en salle de projet) sur le PC et d'ouvrir un terminal de communication. Les paramètres de communication choisis sont tout ce qu'il y a de plus standard : 9600 Bauds, pas de contrôle de flux , 8 bits de données. Il suffit ensuite de taper "+++" et attendre la réponse "OK" du Xbee, ce qui permet de rentrer en mode commande, pour commencer la configuration. Ce qu'on configure ici est très simple, c'est un réseau WPAN (Wireless Personal Area Network) composé de deux stations. Les paramètres choisis sont les suivants :

-3000 est l'ID du réseau

-1 est l'adresse du Xbee émetteur dans ce réseau

-2 est l'adresse du Xbee récepteur

Lignes de commande utilisées pour l'émetteur :

-ATID 3000 (ID du réseau)

-ATMY 1 (adresse de l'émetteur)

-ATDH 0 et ATDL 2 (indique l'adresse du récepteur sur 16 bits, les 8 bits de poids fort sont indiqués par ATDH et les 8 faibles par ATDL)

-ATWR (sauvegarde de la configuration)

Lignes de commande utilisées pour le récepteur :

-ATID 3000

-ATMY 2

-ATWR

Cette très simple série de commandes nous permet donc de communiquer. Il faut cependant relier les Xbee à leurs Arduino respectifs pour établir la communication au sens propre du terme. Encore une fois, des adaptateurs sont disponibles à l'école où il suffit de brancher son Xbee. Un connecteur femelle sur cet adaptateur nous permet de relier les 4 broches dont nous avons besoin à l'arduino à savoir :

-Vcc

-Gnd

-Tx

-Rx

Adaptateur USB pour Xbee, identique à l'adaptateur pour relier à l'Arduino sans le connecteur 4 broches :

Xbee

Partie électronique:

Une fois les cartes imprimées, on a commencé le perçage et le soudage des supports tulipes qui accueilleront les composants (Xbee, Arduino …). Perçage et soudage finis, on a fait des essais sur les différentes pins pour vérifier que les liaisons électriques sont bien définies, et qu’il n’y a aucun faux contact entre nos pins.

Les premiers résultats ont été concluants, car il n’y avait pas de faux contacts entre les pins, et qu'il n’y avait qu’une seule pin non raccordée électriquement. Il a donc fallu la dessouder, et refaire une nouvelle soudure.

Une fois qu'on a fini le perçage et la soudure , l'étape qui suivant était de programmer l'Arduino Mini afin de le brancher par la suite sur la carte et essayer le système.

Les cartes (émettrice à droite et réceptrice à gauche)

L’implantation du code sur l’Arduino Mini s'est vouée à l'échec, car l’IDE Arduino refusait de transmettre le code sur nos Arduino et retournait l'erreur : « Programmer is not responding ».Cette erreur est très fréquente sur les forums d'entraide sur internet, mais il n'existe pas de solution qui permet de la résoudre. Malgré donc les différents essais et les différentes modifications des paramètres de programmation sur l’IDE Arduino, nous n'avons pas réussi à téléverser le code sur l’Arduino.

Après avoir consulté Mr.Vantroys, il nous a proposer de passer par un programmateur ISP AVR « mkii », car il se pourrait que l'origine du problème soit la non présence d'un BootLoader sur la nouvelle génération des Arduino Mini.

On a réalisé le raccordement entre le programmateur mkii et l’Arduino en respectant le protocole SPI comme suit (A gauche les sorties du programmateur et à droite les entrées de l’Arduino Mini) :

• GND - GND

• Reset – Reset

• Power – 5V

• SCK – D13

• MISO – D12

• MOSI – D11

Liaison Arduino Mini - Programmateur mkii

Le programmateur mkii

Cependant le voyant du programmateur affichait une lumière rouge. C’est donc après lecture de la documentation du programmateur et quelques sites qui en parlent, qu’on a pu résoudre cette erreur en mettant une résistance de rappel (Pull Up) entre la sortie Reset du programmateur et l’entrée Reset de l’Arduino.

Une fois ce branchement fait, le voyant du programmateur a tourné au vert. Mais malgré cela, on n’a pas réussi à transférer notre programme sur l’Arduino Mini. Cette fois-ci le message d’erreur était un driver manquant. L’installation du driver du programmateur mkii n’a rien résolu que ce soit sur Linux ou bien sur Windows.

Nous avons été contraints par le temps, et on a abandonné la piste de l’Arduino Mini en optant pour un Arduino plus standard et facilement programmable, qui est l’Arduino Uno (Sur lequel on a fait nos tests depuis le départ). On a écarté la possibilité de refaire une autre carte avec cette fois-ci un Arduino autre qu’un Mini ou bien un Atmega328, car le temps que prendrait la conception d’une nouvelle carte, l’impression (Cette étape prenait énormément de temps les dernières semaines vu le grand nombre de cartes qui étaient commandées), le perçage ainsi que le soudage, était très long.

L'implantation de nos codes sur nos 2 Arduinos finie, on a relié Xbee, capteurs, résistances , ... entre eux sur une plaque lab.Afin d'effectuer les tests.

Parce qu’une VMC qui change de vitesse suivant son environnement c’est bien beau, mais ce n’est pas forcément parlant à tout le monde. On a décidé de relier notre système à un écran qui affichera à un intervalle donné, les valeurs du taux de CO2, de la température extérieure, de la température intérieure, du taux d’humidité et de la vitesse de la VMC. Comme ça, un utilisateur lambda de notre système, pourra lire les valeurs des paramètres atmosphériques de l’environnement qui l’entoure. Et voir en temps réel l’évolution de la vitesse de sa VMC.

On a opté pour l’afficheur RGB d’Adafruit qui est facilement programmable,car les constructeurs ont mis en places des libraires en C qui réalisent l'initialisation de l'écran, l'envoie de chaines de caractères, le changement de la résolution ...

L'écran LCD d'Adafruit

Les liaisons avec Arduino sont plutôt simples, et intuitives. On relie donc les 2 composants comme dans le graphique suivant :

Le brochage de l'écran et l'Arduino

Pour afficher une chaîne de caractère donnée sur l'écran, il suffit d'utiliser le code suivant :

#include <Wire.h>
#include <EEPROM.h>
#include <LiquidCrystal.h>
#include <Bounce.h>
#include "DHT.h"
LiquidCrystal lcd(10, 9, 8, 7, 6, 5);
void setup() {
 lcd.begin(16,2);
 lcd.home ();

}
void loop() {
lcd.print("Bonjour !");
}

Les libraires déclarées ci-dessus contiennent des fonction permettant de définir les pins sur les quels sont connectées les entrées de l'écran, qui permettent de définir le contraste de l'écran, et qui permettent d'afficher des messages.

Maquette:

Pour l’esthétique du projet, on a décidé de faire une maquette d’une maison 3 pièces. Chacune des pièces contiendra un environnement donné. Pièce humide, pièce avec un taux de CO2 élevé, pièce avec une température élevée…

Pour ceci on a contacté l’atelier mécanique, un mois avant la date de la soutenance. Il nous fallait dessiner un plan de la maison, avec différentes vues. Les plans ont été transmis à l’atelier mécanique le 31 Mai 2014, et le responsable nous a assuré d’avoir la maquette au maximum 2 semaines après, à savoir le Vendredi 11 Avril. Cependant à cause des surcharges que connaissait l’atelier mécanique, on n’a pas pu avoir notre maquette au temps voulu, et ils ont fixé une nouvelle date de livraison de la maquette, qui est du 14 Avril.

Vue de dessus du plan

Murs avec caractéristiques particulières

Vue en 3D

7 Avril / 12 Avril

Partie commande :

Nous entamons maintenant la dernière partie de la partie programmation qui est l'extraction des données reçues sur la carte qui va commander la VMC. Il faut tout d'abord reconstituer la chaîne de caractères reçue à intervalles réguliers et contenant toutes les données capteurs. Pour ce faire, on y a introduit le caractère 'Z' à la fin, pour pouvoir à la réception détecter la fin de la chaîne. Voici le bout de code qui reconstitue cette chaîne :

Enfin, il faut pouvoir en extraire les données, c'est-à-dire extraire les paramètres de qualités de l'air qui sont des nombres. On commence donc par reconstruire un tableau contenant tous les chiffres de la chaîne. Ensuite, à partir de l'ordre dans lequel sont envoyées les données et de leur format, on peut aisément reformer les données au format numérique et exploitable pour le FLC. Le bout de code éxécutant cela est le suivant :

Les données sont au format suivant (ce qui est déductible du code) :

-température intérieure, température extérieure et humidité : WX.YZ

-taux de CO2 : VWX.YZ où V et W peuvent être égaux à 0 d'où les 3 cas d'extraction.

Partie tests:

Les tests ont été très concluants, car notre ventilateur (simulant la VMC) répondait exactement comme on avait prévu aux changements du climat extérieur qu’on lui infligeait (Chauffage, Augmentation/Réduction du taux de CO2, Changement de l’humidité). Selon ces facteurs, la vitesse de la VMC variant suivant le modèle qu’on a défini auparavant.

A titre d’exemple, une augmentation du taux de CO2 augmentait la vitesse de la VMC pour essayer de rendre l’air moins polluée, le dépassement d’un taux de 1000 PPM faisait tourner la VMC à sa vitesse maximale, car nous considérons qu’à partir de ce seuil l’air devenait extrêmement irrespirable. Ceci va de soit lorsqu'on augmente la température ou l’humidité.

14 Avril

Maquette:

Nous avons reçu la maquette de la maison Lundi 14/04/2014 en fin d'après-midi, mais vu le manque de temps nous n'avons pas pu y installer des résistances chauffantes pour simuler différents environnements pour la vidéo. On a donc agit sur notre seul degré de liberté qui est le taux de C02.

La maquette de la maison

NB : Deux caractères numériques mais inutiles sont présents dans la chaîne, issus du texte "CO2 rate"

Conclusion & Rapport

Conclusion

Ce projet nous a été très bénéfique, car il nous a confronté à la difficulté de définir soi-même un cahier des charges et de trouver par soi les solutions les plus efficaces pour réaliser le projet. De plus, on a pu appliquer la notion de commande floue que nous avons vu au cours de cette année, ainsi que les différentes notions acquises en réseau et en systèmes d’exploitation au cours du premier semestre. De plus il nous a permis d’être autonomes, et d’apprendre à s’organiser et faire un travail d’équipe.

Rapport

Média:VMC.pdf

Matériel récupéré

• 2 arduino UNO
• 1 arduino Mini R5
• 2 puces Xbee
• 1 Shiled Xbee
• 2 adaptateurs Xbee