SDH2015
Ce projet a été réalisé par DECELLE Lucas, DELISE Antoine, GARIN Lucas, MADELON Rémi, ROUX Nicolas, étudiants en PEIP 1ère année à Polytech Grenoble.
Media:RapportMaisonIntelligentePEIP2015.pdf
Introduction
Dans le cadre du DU Polytech, chaque étudiant doit participer à la réalisation d'un projet. Nous avons choisi entre plusieurs thématiques et avons ensuite former des groupes pour chaque thème.
Nous avons entrepri de travailler sur la domotique avec Didier Donsez comme enseignant responsable.
La domotique regroupe les technologies de l’électronique, de l'automatique, de l’informatique et des télécommunications permettant d’améliorer le confort, la sécurité, la communication et la gestion d’énergie d’une maison, d’un lieu public…
Notre tuteur a choisi une approche plutôt pratique autour de ce thème en mettant de côté la ressource documentaire.
En effet, la domotique permet par exemple d’optimiser l’utilisation de l’éclairage, du chauffage afin de réduire notre consommation en énergie. C'est pourquoi Didier Donsez nous a proposé de fabriquer un modèle réduit d'une maison dite « intelligente ».
Cette maquette, à l'échelle d'un Playmobil, permettrait de présenter certaines fonctionnalités de la domotique à travers 3 scénarios : Motion sensor, Free cooling et Fire Alarm. Ces scénarios seront automatisés via des cartes « Arduino » exécutant des programmes informatiques. Didier Donsez nous a proposé de poster la construction de cette maquette sur Internet sous forme de manuel afin que collèges et lycées puissent reproduire cette maison dans le but d'enseigner le langage « Arduino ». Cependant, n'importe quelle personne pourrait également reconstruire notre maquette en achetant le matériel décrit dans le manuel.
Nous nous sommes alors lancés dans ce vaste projet, soit la fabrication de la maison et la programmation de nos scénarios.
Fabrication de la maison
a) Struture principale
La première étape est la plus importante, tout ce qui suivra dépendra de celle-ci. Elle consiste à créer une maison. Pour cela, nous avons dessiné la structure principale, c’est-à-dire les murs extérieurs et le sol. Nous avons alors utilisé le logiciel Makercase dont le lien est ici : http://www.makercase.com/ .
Ce logiciel permet de construire le plan d’un cube ou d’un rectangle dans le but d’être découpé dans un matériau adéquat. Ce logiciel propose 3 façons d’emboiter les murs : Finger, Flat et T-Slot. On utilise le type de fixation « Finger », et de ce fait le cube crée pourra tenir sans colle ni clou.
Le but est de construire une maison adaptée à la taille d’un Playmobil. De ce fait nous avons choisi une dimension de 40cm*40cm avec des murs fait en MBF d’une épaisseur de 3 mm.
Pour une meilleur visualisation et compréhension des différents systèmes présents dans la maison, nous avons effectué une coupe de la maison en ajoutant des traits rouges supplémentaires de biais sur deux murs opposés. Ainsi la hauteur maximum des murs est de 16cm et la hauteur minimum est de 3,5cm. Ensuite, nous avons dessiné une porte d’entrée d’une dimension 8 cm par 3 cm sur un coté perpendiculaire à la coupe.
De plus, nous avons inclue deux fenêtres 5cm par 5cm situées sur le mur du fond, celui qui est le plus grand en hauteur et en largeur après la découpe. Elles sont aussi bien nécessaires pour nos scénarios automatisés que d’un point de vue esthétique.
Nous avons ensuite enregistré les plans en format .svg pour créer la structure de notre maison.
b) Murs intérieurs
Le but de cette étape est de définir la disposition des pièces à l’intérieur de la maison. Ainsi il faut dessiner les plans des murs intérieurs.
Il y a 2 logiciels principaux pour concevoir les plans : Inkscape et Adobe Illustrator. Le premier est gratuit mais n’est pas très pratique pour dessiner des plans précis. Le deuxième est payant mais offre de nombreuses fonctionnalités, et est plus adapté à notre besoin. Par chance, Adobe Illustrator met à disposition une version d’essai pendant 30 jours. De ce fait nous avons établi la configuration intérieure de notre maison sur ce logiciel.
Nous avons décidé de séparer la maison en quatre pièces de même taille, soit 20cm*20cm. Ceci nous a permis de mettre en place, et par la suite de présenter, nos quatres scénarios facilement, de manière précise et distincte. Pour cela, nous avons dessiné deux murs perpendiculaires sur Adobe Illustrator. Comme notre maison est censée être utilisée et reconstruite à nouveau, notamment par des collégiens ou des lycéens dans le but de découvrir le potentiel des cartes arduino, nous avons cherché une façon pratique d’ajouter les murs intérieurs dans notre maison. C’est pourquoi, nous avons équipé nos murs de petites fentes, dessinés via Adobe Illustrator, afin de pouvoir les emboîter en forme de croix. Ceci permet de créer une maison en kit-détachable, on peut enlever les murs intérieurs et détacher les murs extérieurs grâce aux encoches « Finger » afin de mettre le tout dans un sac. Nous avons également inclue 3 portes (8cm*3cm) sur les murs intérieurs pour permettre aux « Playmobils » de circuler de pièces en pièces et d’actionner chacun des scénarios individuellement.
c) Mobiliers
Pour rendre plus réelle notre maison, nous avons décidé d’inclure plusieurs objets du quotidiens, ainsi que du mobilier, propre à une maison. Cette dernière étape de fabrication est majoritairement esthétique mais s'avère utile suivant les scénarios puisque certains d’entre eux nécessite un réveil, un lit, etc.. pour que les scénario s’enclenchent. Nous avons alors récupéré les plans essentiels sur le site http://fablab.ensimag.fr/index.php/PILBI-2013-Team2.
On distingue alors deux types de mobilier, celui en bois, et celui en plastique. Les plans des objets, tel que la table, le bureau etc ... ont été édités sur Adobe Illustrator et peuvent être fabriqué par la découpeuse laser. Les autres plans, comme les WC, le réveil, etc ... ont été réalisés grâce à l’imprimante 3D. Nous avons ajusté la taille des objets grâce aux réglages sur l’imprimante 3D et nous avons lancé leur production.
Si quelqu’un veut ajouter des accessoires à notre maison, on trouve énormément de différents objets sur le site https://www.thingiverse.com . L’imprimante 3D permet de matérialiser les plans disponibles sur « Thingiverse », il suffit de modifier la taille avant la production pour rester à l’échelle d’un playmobil. Nous avons ensuite récupérer le plan de notre maison édité sur Makercase et nous l’avons ouvert sur Adobe Illustrator afin d’ajouter n’importe quelle touche personnelle, texte ou photo. Effectivement, la découpeuse laser a aussi la possibilité de graver.
Voici les plans après personnalisation
II) Automatisation de la maison
a) Motion Sensor
La gestion de la consommation d’énergie est une tendance actuelle, c’est pourquoi nous avons modélisé un premier scénario qui respecte cette tendance à une échelle réduite. Notre dispositif permet d’allumer automatiquement la lumière en cas de présence dans une pièce mais permet aussi d’éteindre celle-ci en l’absence de mouvement pendant 10 min.
Le matériel que nous avons utilisé est le suivant : - Un capteur de mouvement - Une LED (lampe) - Une résistance 220 ohm - Une Carte Arduino
Nous avons schématisé les montages électroniques grâce au logiciel Fritzing ( http://fritzing.org/home/ ). Voici le montage du premier scénario « Motion sensor ».
b) Free Cooling
Ce dispositif permet d’améliorer la gestion d’énergie de la maison. En effet la dépense de chauffage ou de climatisation est une part importante du budget énergétique. Ainsi, afin de réduire ce coût, nous avons créé un dispositif prenant en charge l’ouverture et la fermeture des fenêtres en fonction d’une température réglée par l’utilisateur. Il compare la température intérieur et la température extérieure et décide d’ouvrir ou non la fenêtre.
Nous avons utilisé comme matériel : - Deux capteurs DHT 11 - Une shield LSD avec 4 boutons selectors - Un cerveau moteur - Des piles ou une batterie - Une carte arduino
c) Fire Alarm
La sécurité est devenue un élément primordial dans le choix d’une maison. Et l’une des plus grande crainte d’accident reste l’incendie. Ainsi nous avons associé différents composants afin de créer un détecteur de flamme. Ce détecteur de flamme déclenche une alarme.
Le matériel utilisé est le suivant : - Un détecteur de flammes - Un buzzer - Une carde arduino - Un bouton poussoire
d) Centralisation des commandes : Interface
Nous avons décidé de développer une interface centralisant les différents « module » permettant à la fois de procéder à des ajouts ou des retraits de module ainsi que d’offrir à l’utilisateur (de la maison) une interface afin d’interagir directement et facilement avec les modules.
Pour cela plusieurs étapes ont été nécessaires :
La première, la conception de l’interface niveau hardware, non nécessaire dans le projet initiale seul les sortis Tx Rx et 2 du server ET des arduino était utilisés, Rx serveur était directement branché à toute les sorties Tx des clients et réciproquement et toutes les sorties 2 était reliés.
Le jour de la présentation arrivant nous nous sommes rendu qu’il nous faudrais encore une petite semaine de travail afin de terminer de développer ce protocole de communication et avons décidé de recommencer à « zéros » (pas exactement vrais) et de repartir sur un autre protocole réalisable dans le peu de temps restant. En effet le problème était que lorsqu’une arduino « n’a rien à dire/envoyer » au serveur elle le fait savoir par le maintien d’un niveau haut, provoquant ainsi la perte des informations des signaux des autres systèmes clients. Il aurait fallu modifier le système de communication série au niveau des librairies système ou encore introduire un ordre afin de demander au système de se taire et d’attendre d’être appelés plutôt que de dire qu’elles n’ont rien à dire (comportement natif à l’arduino). Ce premier protocole avait l’avantage de permettre un nombre illimité (théoriquement) de module installer en même temps et d’être léger en pin client. En effet puisque les clients n’ont pas de sorties qui leur sont réservé spécifiquement sur les sorties serveur, le nombre de module n’a donc aucune importance.
La partie plus compliqué de ce premier protocole était la connexion des modules. En effet le système étant designer pour une maison une coupure de courant peut survenir à tout moment, provoquant une reconnexion de tous les systèmes simultanément. La première étape est de réussir à dissocier les clients, tous les clients dispose de la même librairie pas de nom et aucun moyen de le faire savoir au server (tous les clients parleraient en même temps rendant le signale incompréhensible pour le serveur). Nous avons dans premier temps utiliser une librairie de génération d’UN nombre réellement aléatoire (mais pas réellement uniforme) qui ne nécessite pas de connexion série avec un ordinateur, puisque le système natif de génération de nombre est celui du C qui nécessite un nombre généralement un timestamp (qui est plus ou moins aléatoire sur une ordinateur) mais dans notre cas si elle démarre toute en même temps elles auraient toutes le même nombre.
Une fois nommé (le nombre est assez grand pur être supposé unique pour une centaine de module ce qui est déjà énorme) le but est de les dissocier, puisque les clients n’ont pas connexion privilégier elles ne savent pas au début quand parler et le serveur ne connais pas encore leur nom pour les appeler.
Le nouveau protocole est plus simple à implémenter et a pu être terminé à temps mais limite le nombre de module, chaque module nécessite 2 pins qui lui sont réservés, donc le nombre de module dépends du nombre de pin serveur disponible de plus 1 transistor et 2 diode sont nécessaire par module.
Les communications se déroulent par la suite selon le schéma suivant : - Le programme envoi une requête : STC<PPP…> (Size de la requête en bytes, Target de la requête, Command byte qui définit le type de requête, Param nombre de byte indéfini qui sont les paramètres de la requête, sa taille est S-3) - Le serveur la réceptionne sélectionne le module grâce à Target et traduit la requête en : XSC<PPP…> (X est le type de dispositif qui envoi la requête serveur ou module, était utiliser par la première version du deuxième protocole qui présentais un problème d’écho, le serveur recevait ses propres requêtes) - Le client réagit à la requête et si nécessaire renvoi une requête de retour du même type qu’il a reçu avec paramètre - Si la requête est à valeur de retour (ex Refresh qui actualise les valeurs de capteurs sur l’interface) les transmet à l’ordinateur par : STC<PPP…>
De plus la requête connexion est à valeur de retour, le module renvoi un tableau identité :
Le paramètre de la valeur de retour se présente ainsi :
<PTVPTV…> (Paquet size, Type de ‘field’, Value du field en caractère) exemple :81Fermer signifie que le champs fait 8 octet et demande la création d’une action (un bouton qui envoie une requête) nommé Fermer (lors du clique la requête contient le numéro du bouton dépendant de l’ordre de création, le client appel la fonction stocké dans un tableau de fonction) ‘13’ 2Temperature seras un champ d’affichage de la forme “ Temperature : “
Lors de la marche le serveur envoi des « refresh » régulier aux clients afin de mettre à jour les champs d’affichage et lors de l’appuie sur un bouton dans l’interface graphique le programme appel une fonction du client en passant par le serveur. (à noter que si la connexion, la création d’un nouvel onglet par module dans l’interface et la création des fields dans les onglets et l’appel de fonction client grâce aux bouton de l’interface sont fonctionnel. La commande refresh quant à elle présente encore un bug dont nous n’avons pas eu le temps de résoudre avant la date de présentation.).