Tutoriel système domotique Arduino
Tutoriel système domotique Arduino
...
LES SYSTÈMES À BASE D’ARDUINO
PRÉSENTATION DE LA CARTE ARDUINO MEGA2560
- Arduino Méga 2560 est un module basé sur le microcontrôleur ATMEGA2560
- Dispose de 54 broches entrées / sorties numériques (dont 14 peuvent être
- Utilisées comme sorties PWM), 16 entrées analogiques , 4 UART (ports série matériels)
- Une connexion USB
- Une embase d'alimentation
- Un bouton de réinitialisation
- Tension de fonctionnement : 5V
- Tension d'alimentation (recommandé) : 7-12V
- Courant DC par broche E/S : 40 mA
- Mémoire Flash de 256 Ko
- Vitesse de l'horloge de 16 MHz
ADAPTATION DE LA CARTE ARDUINO A LA DOMOTIQUE
- La domotique est l’ensemble des techniques de l’électronique, d’automatisme, de l’informatique et des télécommunications .
- La domotique vise à apporter des solutions techniques pour répondre aux besoins :
– confort (gestion d’énergie)
– optimisation de l’éclairage et du chauffage
– sécurité (alarme)
– communication (commandes à distance, signaux visuels ou sonores, etc.)
… … …
MATÉRIELS ET LOGICIELS UTILISÉS
RÉCEPTION DES CODES INFRAROUGE
- Le contrôle à distance de notre système est possible grâce à l'échange d'informations en provenance d'un émetteur (la télécommande IR) vers un récepteur IR.
- Ce récepteur est une photodiode, qui est capable de transformer le signal lumineux qu'elle reçoit en un signal électrique.
- Ces signaux IR sont modulés à 38 kHz pour éviter les interférences avec la lumière ambiante, La portée est de 8 mètres, en ligne droite sans obstacles.
…
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
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 (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 (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
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 :
(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.).
… …
Ressenti et Impressions
Nous nous sommes investis dans ce projet de plein gré puisque nous étions satisfaits de la décision de notre tuteur, c'est à dire d'orienter le projet vers une réalisation matérielle plutôt que vers une recherche documentaire au sujet de la domotique. Le fait d'imaginer, de concevoir et de fabriquer cette maison nécessitent de la prise d'initiative et beaucoup de réflexion. Nous n’avons jamais été réellement confrontés à ce genre de projet avant. Celui-ci nous a permis d'entrevoir le métier d'ingénieur avec le travail et les démarches qui suivent. Effectivement Didier Donsez nous a proposé son idée et nous étions enjoués et motivé à la réaliser. Cependant, étant donné notre manque d'expérience dans ce type de projet, nous avons eu beaucoup de difficultés pour savoir par où commencer. Même si notre responsable nous a dicté les tâches à effectuer, nous avons passé énormément de temps à trouver les logiciels et les formats des fichiers adéquats à chaque une de nos étapes de production. De plus, il a fallu comprendre et maîtriser les logiciels que nous utilisions puisqu’ils étaient tous nouveaux pour nous.
Certes Monsieur Donsez nous a donné beaucoup d'informations élémentaires, mais nous avons été en quelque sorte « lâchés dans la nature ». Ceci nous a réellement permis de nous prendre en main et d'acquérir une maturité essentielle à la gestion de notre projet. En effet, nous avons presque effectué toutes les démarches seuls, en tant « qu'entreprise » chargée de la fabrication d'un nouveau produit. Nous ne sommes absolument pas mécontents de cette façon de procédé, au contraire, cette expérience s'est avérée très enrichissante car nous avons su nous répartir les tâches en fonction des compétences et préférences de chacun pour maximiser notre efficacité. Cependant, nous avons rencontré beaucoup de difficultés. Il nous a fallu du temps pour récupérer tout le matériel nécessaire, pour comprendre nos erreurs aussi bien au niveau de la programmation, des dessins des plans, ou de l’utilisation des logiciels. Effectivement, il y a beaucoup de subtilités que nous ne connaissions pas et qui nous ont causé des problèmes à plusieurs reprises.
De plus, nous avons dû contacter différentes personnes essentielles à la conception de notre maison. Pour la fabrication de notre maquette, nous avions besoin d'une découpeuse laser et d'une imprimante 3D. Ces types de machines ne sont pas courants, c'est pourquoi Didier Donsez nous a conseillé d'aller au « Fablab » à l'Imag lorsque nous aurons besoin de les utiliser. En revanche, les deux instruments sont tombés en panne, ce qui a considérablement retardé la réalisation de la maison et des meubles qu’elle était censé comporter. Un des dirigeants du « Fablab », Monsieur Maisonnasse nous a envoyé à l’ Inria (Montbonnot) pour utiliser leur découpeuse laser. Nous nous sommes rendu sur le lieu de rendez-vous et avons rencontré Monsieur Pinssant, qui nous a consacré une après-midi pour nous aider à la construction de notre maison. Il nous a expliqué comment fonctionne la découpeuse laser et comment arranger et améliorer nos plans. M. Maisonasse nous a également aidés lors des impressions 3D et surtout en nous donnant son envie à chaque étape que nous entreprenions (lorsqu'il était présent). Ceci a couté beaucoup de temps à ces deux personnes qui n'étaient en soit pas responsable de nous, ni de notre projet.