Posts | Comments

Planet Arduino

Archive for the ‘planet’ Category

Space. The final frontier. Unfortunately, the vast majority of us are planet-locked until further notice. If you are dedicated hobbyist astronomer, you probably already have the rough positions of the planets memorized. But what if you want to know them exactly from the comfort of your room and educate yourself at the same time? [Shubham Paul] has gone the extra parsec to build a Real-Time Planet Tracker that calculates their locations using Kepler’s Laws with exacting precision.

An Arduino Mega provides the brains, while 3.5-turn-pan and 180-degree-tilt servos are the brawn. A potentiometer and switch allow for for planet and mode selection, while a GPS module and an optional MPU9250 gyroscope/magnetometer let it know where you are. Finally a laser pointer shows the planet’s location in a closed room. And then there’s code: a lot of code.

The hardware side of things — as [Shubham Paul] clarifies — looks a little unfinished because the focus of the project is the software with the intent to instruct. They have included all the code they wrote for the RTPT, providing a breakdown in each section for those who are looking to build their own.

There is an extra step to auto-align the RTPT to north, otherwise you’ll have to do so manually. But [Shubham Paul] has designed it so that even if you move the tracker about, the RTPT will readjust its calculations in real time. Each part of the project includes a wealth of related information beyond simple instructions to adequately equip any prospective builders.

This hack gets the job done. If it’s looks you’re after, an artistic expression of maker skills and astronomy can be seen in this planetary map that relies on persistence of vision.


Filed under: Arduino Hacks, software hacks

OpenAlarm Node 1.5.0

Format de la carte

Comme je l'évoquais dans un article précédent, Seeedstudio qui produit les pcb, m'a demandé un surplus de 17$ à cause des demi-trous en bordure de la carte, vu le cout total de production des PCB (9$ pour 10), ça fait une belle surprise et de toute façon, je n'étais pas convaincu de l'utilité / praticité de ces demi-trous, j'ai donc résolu le problème en augmentant quelque peu la largeur de la carte qui passe de 16mm à 19mm, rien de bien méchant et surtout un gain appréciable en terme de place disponible sur le PCB.

Améliorations par rapport à la version 1.0.0 :

  • L'ouverture du port USB à été agrandie car ça coinçait un peu sur la première version.
  • Certains composants ont été déplacés pour faciliter le montage
  • Les broches de programmation ont été agrandis (voir plus bas)

Comparatif visuel et à l'échelle entre un Funky v3, un OpenAlarm Node 1.0.0 et un OpenAlarm Node 1.5.0 :
Comparatif Funky v3, OpenAlarm Node 1.0.0 et OpenAlarm Node 1.5.0

Comme vous le voyez, nous sommes un poil plus gros que la version 1.0.0 mais ça reste très petit comme le prouve cette photo :
Un OpenAlarm Node 1.5.0 dans la main

Vue de derrière :
Vue de derrière

Entrées / sorties

Avec la taille gagnée, j'en ai profité pour revoir le mappage des entrées / sorties, maintenant, elles sont placées dans l'ordre de chaque côté de la carte, toutes groupées par fonction.

On trouve dorénavant sur le côté gauche les 3 broches d'alimentations VIN (entrée de 3.3V à 7V), GND, VCC (entrée de 3V à 5V), 4 entrées / sorties génériques ayant chacune une interruption matérielle D0, D1, D2, D3.
Sur le côté droit, on trouve 2 entrées analogiques A0 et A1 et d'autres entrées / sorties génériques D6, D7, D8, D9 et D12 (D8 et D9 ayant également des interruptions matérielles).

Les entrées / sorties d'un OpenAlarm Node 1.5.0

Sur l'ancienne version des OpenAlarm Node et sur les Funky, il n'est pas possible d'utiliser le port physique I2C car la broche PD0 (SCL) est utilisé comme broche d'interruption pour dialoguer avec le module radio.
À cause d'un bug dans la librairie JeeNode de pilotage du module radio, il n'était pas possible d'utiliser une autre broche, le problème étant résolu, j'ai libéré PD0 afin de pouvoir utiliser le port I2C directement, et c'est PB7 (D11) qui est maintenant utilisé pour le dialogue avec le module radio.

Le PCB

Un des principes des OpenAlarm Node est de pouvoir utiliser des cartes filles que l'on vient superposer les unes sur les autres avec le même principe que les shields d'Arduino ou la spécification Hats pour les Raspberry.
Nous avons donc un PCB pour la carte mère et des PCB pour chaque carte fille mais comme évoqué précédemment, un critère important est le cout et faire fabriquer plusieurs PCB, c'est onéreux. La plus petite taille de PCB disponible chez Seeedstudio étant de 5cm x 5cm, il y a de la place perdue (le PCB de la carte mère fait 19mm x 21mm), j'ai donc ajouté 3 cartes filles directement sur le PCB original, il ne reste plus qu'à découper (un coup de cutter et on casse proprement l'époxy).

Pour le prix d'un PCB, on se retrouve avec 4 PCB dont 2 utilisables comme des platines d'essais et une autre intégrant un chargeur de batterie LiPo.
Le PCB de la version 1.5.0 d'OpenAlarm Node

Les cartes filles

Pour ce premier batch d'OpenAlarm Node 1.5.0, j'ai donc inclut directement 2 cartes filles d'essai et 1 autre carte fille d'essai avec un chargeur LiPo à base de Max1555 qui chargera automatiquement la batterie lorsque le Node sera branché sur USB, un voyant permettant de voir si la charge à bien lieu.

Un OpenAlarm Node avec une carte fille proto sur laquelle on aperçoit un capteur infrarouge :
Carte fille Lipo pour OpenAlarm Node

Un OpenAlarm Node avec une carte fille LiPo :
Carte fille proto pour OpenAlarm Node

Programmation

Programmation du bootloader

Comme évoqué plus haut, les contacts de programmation du bootloader étant un peu trop petit sur la première version, ils ont été agrandi afin d'en faciliter l'utilisation.

Pad de programmation d'un OpenAlarm Node 1.5.0

Sur la première version des OpenAlarm Node, je soudais directement des fils sur le port de programmation afin d'envoyer le bootloader, c'était long, source de problèmes mais surtout, franchement pas pratique, j'ai donc fabriqué un outils parfait pour cette tâche :

Que peut-on faire avec une pince à linge en Inox et des pogopins (des pointes de contacts) ?
pince-a-linge-inox.png pogopin.png

On fait une pince de programmation très pratique !
Pince de programmation DIY Pince de programmation DIY

Programmation par USB

Le bootloader n'a besoin d'être programmé qu'une seule fois, par la suite, le programme est chargé directement par USB, comme pour l'ancienne version du PCB, j'utilise un port USB un peu particulier puisque ce dernier est directement sur le PCB, je ne suis pas rentré en détail dessus dans mes derniers articles, voici quelques informations à ce sujet.

Pour commencer, pourquoi ne pas mettre un port physique microUSB ?

  • Ça prend de la place, c'est épais
  • Ce n'est pas forcément plus solide
  • C'est toujours ça de moins à souder
  • Ça coute moins cher
  • Parce qu'on peut le faire !

Pour cela, il faut que votre PCB fasse 0.8mm d'épaisseur au maximum, vous aurez également à limer chaque côté du bord d'insertion sinon, vous aurez de mauvaises surprises...
Limage du connecteur USB avant insertion OpenAlarm Node en cours de programmation usb_1.jpg

Je n'ai pas eu de souci avec ce genre de connecteur, sauf un limage un peu trop léger du PCB, qui, lors de l'insertion à plié les contacts internes du connecteurs de la prise USB et l'a donc rendu inutilisable mais le connecteur PCB n'a absolument rien eu : PCB=1 / USB=0 ;).
Je maltraite pas mal les connecteurs et aucun n'a rompu (alors que sur les Funky v3, j'ai un connecteur standard USB qui s'est arraché) et ne montre de signe de faiblesse donc je pense que c'est une solution parfaitement utilisable...

La suite

Au niveau logiciel, beaucoup énormément d'évolutions aussi bien au niveau code embarqué que Python qui seront l'occasion d'un prochain article qui devrait sortir très prochainement...

Si vous êtes intéressé par OpenAlarm, si vous avez des conseils, si vous voulez participer, venez en discuter sur IRC, canal #madeinfr sur irc.freenode.net, vous pouvez également suivre les évolutions sur Twitter @hugokernel, un forum OpenAlarm est également disponible chez Madeinfr et enfin, tout ceci est sur GitHub / hugokernel / OpenAlarm.

OpenAlarm Node 1.5.0

Format de la carte

Comme je l'évoquais dans un article précédent, Seeedstudio qui produit les pcb, m'a demandé un surplus de 17$ à cause des demi-trous en bordure de la carte, vu le cout total de production des PCB (9$ pour 10), ça fait une belle surprise et de toute façon, je n'étais pas convaincu de l'utilité / praticité de ces demi-trous, j'ai donc résolu le problème en augmentant quelque peu la largeur de la carte qui passe de 16mm à 19mm, rien de bien méchant et surtout un gain appréciable en terme de place disponible sur le PCB.

Améliorations par rapport à la version 1.0.0 :

  • L'ouverture du port USB à été agrandie car ça coinçait un peu sur la première version.
  • Certains composants ont été déplacés pour faciliter le montage
  • Les broches de programmation ont été agrandis (voir plus bas)

Comparatif visuel et à l'échelle entre un Funky v3, un OpenAlarm Node 1.0.0 et un OpenAlarm Node 1.5.0 :
Comparatif Funky v3, OpenAlarm Node 1.0.0 et OpenAlarm Node 1.5.0

Comme vous le voyez, nous sommes un poil plus gros que la version 1.0.0 mais ça reste très petit comme le prouve cette photo :
Un OpenAlarm Node 1.5.0 dans la main

Entrées / sorties

Avec la taille gagnée, j'en ai profité pour revoir le mappage des entrées / sorties, maintenant, elles sont placées dans l'ordre de chaque côté de la carte, toutes groupées par fonction.

On trouve dorénavant sur le côté gauche les 3 broches d'alimentations VIN (entrée de 3.3V à 7V), GND, VCC (entrée de 3V à 5V), 4 entrées / sorties génériques ayant chacune une interruption matérielle D0, D1, D2, D3.
Sur le côté droit, on trouve 2 entrées analogiques A0 et A1 et d'autres entrées / sorties génériques D6, D7, D8, D9 et D12 (D8 et D9 ayant également des interruptions matérielles).

Les entrées / sorties d'un OpenAlarm Node 1.5.0

Sur l'ancienne version des OpenAlarm Node et sur les Funky, il n'est pas possible d'utiliser le port physique I2C car la broche PD0 (SCL) est utilisé comme broche d'interruption pour dialoguer avec le module radio.
À cause d'un bug dans la librairie JeeNode de pilotage du module radio, il n'était pas possible d'utiliser une autre broche, le problème étant résolu, j'ai libéré PD0 afin de pouvoir utiliser le port I2C directement, et c'est PB7 (D11) qui est maintenant utilisé pour le dialogue avec le module radio.

Le PCB

Un des principes des OpenAlarm Node est de pouvoir utiliser des cartes filles que l'on vient superposer les unes sur les autres avec le même principe que les shields d'Arduino ou la spécification Hats pour les Raspberry.
Nous avons donc un PCB pour la carte mère et des PCB pour chaque carte fille mais comme évoqué précédemment, un critère important est le cout et faire fabriquer plusieurs PCB, c'est onéreux. La plus petite taille de PCB disponible chez Seeedstudio étant de 5cm x 5cm, il y a de la place perdue (le PCB de la carte mère fait 19mm x 21mm), j'ai donc ajouté 3 cartes filles directement sur le PCB original, il ne reste plus qu'à découper (un coup de cutter et on casse proprement l'époxy).

Pour le prix d'un PCB, on se retrouve avec 4 PCB dont 2 utilisables comme des platines d'essais et une autre intégrant un chargeur de batterie LiPo.
Le PCB de la version 1.5.0 d'OpenAlarm Node

Les cartes filles

Pour ce premier batch d'OpenAlarm Node 1.5.0, j'ai donc inclut directement 2 cartes filles d'essai et 1 autre carte fille d'essai avec un chargeur LiPo à base de Max1555 qui chargera automatiquement la batterie lorsque le Node sera branché sur USB, un voyant permettant de voir si la charge à bien lieu.

Un OpenAlarm Node avec une carte fille proto sur laquelle on aperçoit un capteur infrarouge :
Carte fille Lipo pour OpenAlarm Node

Un OpenAlarm Node avec une carte fille LiPo :
Carte fille proto pour OpenAlarm Node

Programmation

Programmation du bootloader

Comme évoqué plus haut, les contacts de programmation du bootloader étant un peu trop petit sur la première version, ils ont été agrandi afin d'en faciliter l'utilisation.

Pad de programmation d'un OpenAlarm Node 1.5.0

Sur la première version des OpenAlarm Node, je soudais directement des fils sur le port de programmation afin d'envoyer le bootloader, c'était long, source de problèmes mais surtout, franchement pas pratique, j'ai donc fabriqué un outils parfait pour cette tâche :

Que peut-on faire avec une pince à linge en Inox et des pogopins (des pointes de contacts) ?
pince-a-linge-inox.png pogopin.png

On fait une pince de programmation très pratique !
Pince de programmation DIY Pince de programmation DIY

Programmation par USB

Le bootloader n'a besoin d'être programmé qu'une seule fois, par la suite, le programme est chargé directement par USB, comme pour l'ancienne version du PCB, j'utilise un port USB un peu particulier puisque ce dernier est directement sur le PCB, je ne suis pas rentré en détail dessus dans mes derniers articles, voici quelques informations à ce sujet.

Pour commencer, pourquoi ne pas mettre un port physique microUSB ?

  • Ça prend de la place, c'est épais
  • Ce n'est pas forcément plus solide
  • C'est toujours ça de moins à souder
  • Ça coute moins cher
  • Parce qu'on peut le faire !

Pour cela, il faut que votre PCB fasse 0.8mm d'épaisseur au maximum, vous aurez également à limer chaque côté du bord d'insertion sinon, vous aurez de mauvaises surprises...
Limage du connecteur USB avant insertion OpenAlarm Node en cours de programmation usb_1.jpg

Je n'ai pas eu de souci avec ce genre de connecteur, sauf un limage un peu trop léger du PCB, qui, lors de l'insertion à plié les contacts internes du connecteurs de la prise USB et l'a donc rendu inutilisable mais le connecteur PCB n'a absolument rien eu : PCB=1 / USB=0 ;).
Je maltraite pas mal les connecteurs et aucun n'a rompu (alors que sur les Funky v3, j'ai un connecteur standard USB qui s'est arraché) et ne montre de signe de faiblesse donc je pense que c'est une solution parfaitement utilisable...

La suite

Au niveau logiciel, beaucoup énormément d'évolutions aussi bien au niveau code embarqué que Python qui seront l'occasion d'un prochain article qui devrait sortir très prochainement...

Si vous êtes intéressé par OpenAlarm, si vous avez des conseils, si vous voulez participer, venez en discuter sur IRC, canal #madeinfr sur irc.freenode.net, vous pouvez également suivre les évolutions sur Twitter @hugokernel, un forum OpenAlarm est également disponible chez Madeinfr et enfin, tout ceci est sur GitHub / hugokernel / OpenAlarm.

J’utilise depuis quelques mois une solution domotique qui me donne pleinement satisfaction. Cette solution relativement économique repose sur l’utilisation d’un RaspberryPi avec le logiciel Domoticz ainsi que d’un « modem » radio 433MHz RFXCom

Je ne vais pas détailler l’installation de Domoticz, tout est décrit sur leur site et l’opération reste très simple.

Mes besoins essentiels concernent les consommations de l’habitation ( eau, gaz, électricité ) et les relevés de température et humidité dans certaines pièces. De plus, je pilote quelques lumières ainsi qu’un radiateur de type sèche serviettes. Depuis quelques temps j’ai ajouté des capteurs d’ouverture sur les Vélux et les portes. Je peux ainsi savoir par une notification sur le téléphone si l’on quitte la maison avec un Vélux oublié ouvert…

La solution à base de technologie radio en 433MHz présente quelques avantages:

  • Le prix
  • Le nombre de modules disponibles sur le marché
  • La possibilité de créer facilement ses propres capteurs avec un arduino par exemple

Le gros inconvénient c’est que contrairement au Zwave, il n’y a pas de retour d’état. Pour piloter des éléments « critiques » comme le chauffage, c’est un peu gênant mais on peut y remédier d’une façon assez satisfaisante à l’aide d’un script.

Les modules que j’utilise sont disponibles facilement dans les grandes surfaces de bricolage ou sur internet.

 

Le raspberry équipé d’une carte RFM12Pi en 868MHz pour un usage futur.

RasberryPi
RaspberryPi

 

Le modem RFXCom. On pourrait en créer un avec un arduino pour beaucoup moins cher mais il faut décoder les différents protocoles ce qui m’aurait demandé trop de temps. J’ai donc préféré acheter un module « tout fait » et consacrer plus de temps sur les autres parties.

Module RFXCom
Module RFXCom

 

Des sondes de température Oregon sont disposées aux endroits stratégiques ( Salon, Salle de bain, extérieur, chambres…)

Capteur oregon de température et humidité
Capteur Oregon de température et humidité

 

Le carillon de la porte d’entrée est lui aussi compatible. Il peut donc servir d’alerte sonore si besoin, d’autant qu’il dispose de 3 mélodies utilisables avec des codes différents.

Carillion
Carillon

 

Pour les Vélux, de simples capteurs d’ouverture

Capteur d'ouverture
Capteur d’ouverture

 

Pareil pour la porte du garage

Capteur d'ouverture
Capteur d’ouverture

 

Il y a aussi un capteur de mouvement pour le déclenchement d’un éclairage et d’une notification sur smartphone

Capteur de mouvements
Capteur de mouvements

 

Les lumières sont pilotables par ces petits relais.

Module d'éclairage
Module d’éclairage

J’utilise aussi les modules d’éclairage pour piloter le sèche serviette. Attention, il faut le piloter au travers du fil pilote. Il y a une petite astuce très bien décrite sur le site d’Alexandre.

La consommation électrique est relevée par un OWL180. Une petite pince ampèremétrique branchée sur le compteur transmet la consommation en temps réel.

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Un petit écran déporté affiche la consommation en temps réel

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Pour le gaz, c’est un peu plus compliqué mais aussi plus amusant. Les modules du commerce sont très chers, le DIY vient à la rescousse.

Capteur DIY Gasmonitor
Capteur DIY Gasmonitor

C’est simple, un arduino relève les impulsions générées par le compteur de gaz (un aimant est placé sur la roue du compteur) et les transmet à Domoticz par radio. On peut capter les impulsions d’un compteur de gaz avec un interrupteur reed.

Par la même occasion je relève la température et l’humidité du garage avec un DHT22.

Je vais aussi ajouter la consommation d’eau un peu plus tard.

IMG_20141230_095054_

Et le circuit vraiment très simple

Sélection_023

Le schéma et le code pour programmer l’arduino sont sur Github ici. C’est une première version mais ça marche très bien.

Pour la transmission des informations, j’ai utilisé une librairie permettant de simuler un capteur de type RFXMeter et RFXSensor. Du coup domoticz détecte le capteur tout seul comme un grand. Pour les informations de température et d’humidité, j’ai plutôt utilisé le format Oregon V2 gentiment mis à disposition par Olivier ici. Le nombre d’impulsions comptées est stocké dans l’EEPROM de l’arduino toutes les heures afin de ne pas perdre les informations en cas de coupure de courant.

Un seul arduino peut donc émuler toutes les sondes possibles et imaginables. D’autant qu’il ne faut qu’un arduino et un petit transmetteur 433MHz qui coûte 2-3€ ! Pour les arduino, j’utilise des Mini Pro en 5v ou en 3.3v suivant le type d’alimentation.

 

Après les informations concernant le matériel, voilà un petit tour de ce que ça donne dans Domoticz.

 

Le dashboard
Le dashboard
Les compteurs
Les compteurs
La conso de gaz
La conso de gaz
Les rapports d'électricité avec les coûts
Les rapports d’électricité avec les coûts
La météo
La météo
Des scénarios
Des scénarios

 

Des scripts lua sont aussi possibles pour faire ce qui n’est pas possible avec l’interface web. Ici par exemple, on envoie une notification sur mobile si la porte du garage est restée ouverte. Pratique avec des enfants </p/></p>				</div>

			</div>

				<div class=

J’utilise depuis quelques mois une solution domotique qui me donne pleinement satisfaction. Cette solution relativement économique repose sur l’utilisation d’un RaspberryPi avec le logiciel Domoticz ainsi que d’un « modem » radio 433MHz RFXCom

Je ne vais pas détailler l’installation de Domoticz, tout est décrit sur leur site et l’opération reste très simple.

Mes besoins essentiels concernent les consommations de l’habitation ( eau, gaz, électricité ) et les relevés de température et humidité dans certaines pièces. De plus, je pilote quelques lumières ainsi qu’un radiateur de type sèche serviettes. Depuis quelques temps j’ai ajouté des capteurs d’ouverture sur les Vélux et les portes. Je peux ainsi savoir par une notification sur le téléphone si l’on quitte la maison avec un Vélux oublié ouvert…

La solution à base de technologie radio en 433MHz présente quelques avantages:

  • Le prix
  • Le nombre de modules disponibles sur le marché
  • La possibilité de créer facilement ses propres capteurs avec un arduino par exemple

Le gros inconvénient c’est que contrairement au Zwave, il n’y a pas de retour d’état. Pour piloter des éléments « critiques » comme le chauffage, c’est un peu gênant mais on peut y remédier d’une façon assez satisfaisante à l’aide d’un script.

Les modules que j’utilise sont disponibles facilement dans les grandes surfaces de bricolage ou sur internet.

 

Le raspberry équipé d’une carte RFM12Pi en 868MHz pour un usage futur.

RasberryPi
RaspberryPi

 

Le modem RFXCom. On pourrait en créer un avec un arduino pour beaucoup moins cher mais il faut décoder les différents protocoles ce qui m’aurait demandé trop de temps. J’ai donc préféré acheter un module « tout fait » et consacrer plus de temps sur les autres parties.

Module RFXCom
Module RFXCom

 

Des sondes de température Oregon sont disposées aux endroits stratégiques ( Salon, Salle de bain, extérieur, chambres…)

Capteur oregon de température et humidité
Capteur Oregon de température et humidité

 

Le carillon de la porte d’entrée est lui aussi compatible. Il peut donc servir d’alerte sonore si besoin, d’autant qu’il dispose de 3 mélodies utilisables avec des codes différents.

Carillion
Carillon

 

Pour les Vélux, de simples capteurs d’ouverture

Capteur d'ouverture
Capteur d’ouverture

 

Pareil pour la porte du garage

Capteur d'ouverture
Capteur d’ouverture

 

Il y a aussi un capteur de mouvement pour le déclenchement d’un éclairage et d’une notification sur smartphone

Capteur de mouvements
Capteur de mouvements

 

Les lumières sont pilotables par ces petits relais.

Module d'éclairage
Module d’éclairage

J’utilise aussi les modules d’éclairage pour piloter le sèche serviette. Attention, il faut le piloter au travers du fil pilote. Il y a une petite astuce très bien décrite sur le site d’Alexandre.

La consommation électrique est relevée par un OWL180. Une petite pince ampèremétrique branchée sur le compteur transmet la consommation en temps réel.

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Un petit écran déporté affiche la consommation en temps réel

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Pour le gaz, c’est un peu plus compliqué mais aussi plus amusant. Les modules du commerce sont très chers, le DIY vient à la rescousse.

Capteur DIY Gasmonitor
Capteur DIY Gasmonitor

C’est simple, un arduino relève les impulsions générées par le compteur de gaz (un aimant est placé sur la roue du compteur) et les transmet à Domoticz par radio. On peut capter les impulsions d’un compteur de gaz avec un interrupteur reed.

Par la même occasion je relève la température et l’humidité du garage avec un DHT22.

Je vais aussi ajouter la consommation d’eau un peu plus tard.

IMG_20141230_095054_

Et le circuit vraiment très simple

Sélection_023

Le schéma et le code pour programmer l’arduino sont sur Github ici. C’est une première version mais ça marche très bien.

Pour la transmission des informations, j’ai utilisé une librairie permettant de simuler un capteur de type RFXMeter et RFXSensor. Du coup domoticz détecte le capteur tout seul comme un grand. Pour les informations de température et d’humidité, j’ai plutôt utilisé le format Oregon V2 gentiment mis à disposition par Olivier ici. Le nombre d’impulsions comptées est stocké dans l’EEPROM de l’arduino toutes les heures afin de ne pas perdre les informations en cas de coupure de courant.

Un seul arduino peut donc émuler toutes les sondes possibles et imaginables. D’autant qu’il ne faut qu’un arduino et un petit transmetteur 433MHz qui coûte 2-3€ ! Pour les arduino, j’utilise des Mini Pro en 5v ou en 3.3v suivant le type d’alimentation.

 

Après les informations concernant le matériel, voilà un petit tour de ce que ça donne dans Domoticz.

 

Le dashboard
Le dashboard
Les compteurs
Les compteurs
La conso de gaz
La conso de gaz
Les rapports d'électricité avec les coûts
Les rapports d’électricité avec les coûts
La météo
La météo
Des scénarios
Des scénarios

 

Des scripts lua sont aussi possibles pour faire ce qui n’est pas possible avec l’interface web. Ici par exemple, on envoie une notification sur mobile si la porte du garage est restée ouverte. Pratique avec des enfants </p/></p>				</div>

			</div>

				<div class=

Gen
01

Domotique avec raspberryPi et Domoticz

arduino, compteur de gaz, Do it, domoticz, Domotique, gasmonitor, Hack it, planet, Raspberry Commenti disabilitati su Domotique avec raspberryPi et Domoticz 

J’utilise depuis quelques mois une solution domotique qui me donne pleinement satisfaction. Cette solution relativement économique repose sur l’utilisation d’un RaspberryPi avec le logiciel Domoticz ainsi que d’un « modem » radio 433MHz RFXCom

Je ne vais pas détailler l’installation de Domoticz, tout est décrit sur leur site et l’opération reste très simple.

Mes besoins essentiels concernent les consommations de l’habitation ( eau, gaz, électricité ) et les relevés de température et humidité dans certaines pièces. De plus, je pilote quelques lumières ainsi qu’un radiateur de type sèche serviettes. Depuis quelques temps j’ai ajouté des capteurs d’ouverture sur les Vélux et les portes. Je peux ainsi savoir par une notification sur le téléphone si l’on quitte la maison avec un Vélux oublié ouvert…

La solution à base de technologie radio en 433MHz présente quelques avantages:

  • Le prix
  • Le nombre de modules disponibles sur le marché
  • La possibilité de créer facilement ses propres capteurs avec un arduino par exemple

Le gros inconvénient c’est que contrairement au Zwave, il n’y a pas de retour d’état. Pour piloter des éléments « critiques » comme le chauffage, c’est un peu gênant mais on peut y remédier d’une façon assez satisfaisante à l’aide d’un script.

Les modules que j’utilise sont disponibles facilement dans les grandes surfaces de bricolage ou sur internet.

 

Le raspberry équipé d’une carte RFM12Pi en 868MHz pour un usage futur.

RasberryPi
RaspberryPi

 

Le modem RFXCom. On pourrait en créer un avec un arduino pour beaucoup moins cher mais il faut décoder les différents protocoles ce qui m’aurait demandé trop de temps. J’ai donc préféré acheter un module « tout fait » et consacrer plus de temps sur les autres parties.

Module RFXCom
Module RFXCom

 

Des sondes de température Oregon sont disposées aux endroits stratégiques ( Salon, Salle de bain, extérieur, chambres…)

Capteur oregon de température et humidité
Capteur Oregon de température et humidité

 

Le carillon de la porte d’entrée est lui aussi compatible. Il peut donc servir d’alerte sonore si besoin, d’autant qu’il dispose de 3 mélodies utilisables avec des codes différents.

Carillion
Carillon

 

Pour les Vélux, de simples capteurs d’ouverture

Capteur d'ouverture
Capteur d’ouverture

 

Pareil pour la porte du garage

Capteur d'ouverture
Capteur d’ouverture

 

Il y a aussi un capteur de mouvement pour le déclenchement d’un éclairage et d’une notification sur smartphone

Capteur de mouvements
Capteur de mouvements

 

Les lumières sont pilotables par ces petits relais.

Module d'éclairage
Module d’éclairage

J’utilise aussi les modules d’éclairage pour piloter le sèche serviette. Attention, il faut le piloter au travers du fil pilote. Il y a une petite astuce très bien décrite sur le site d’Alexandre.

La consommation électrique est relevée par un OWL180. Une petite pince ampèremétrique branchée sur le compteur transmet la consommation en temps réel.

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Un petit écran déporté affiche la consommation en temps réel

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Pour le gaz, c’est un peu plus compliqué mais aussi plus amusant. Les modules du commerce sont très chers, le DIY vient à la rescousse.

Capteur DIY Gasmonitor
Capteur DIY Gasmonitor

C’est simple, un arduino relève les impulsions générées par le compteur de gaz (un aimant est placé sur la roue du compteur) et les transmet à Domoticz par radio. On peut capter les impulsions d’un compteur de gaz avec un interrupteur reed.

Par la même occasion je relève la température et l’humidité du garage avec un DHT22.

Je vais aussi ajouter la consommation d’eau un peu plus tard.

IMG_20141230_095054_

Et le circuit vraiment très simple

Sélection_023

Le schéma et le code pour programmer l’arduino sont sur Github ici. C’est une première version mais ça marche très bien.

Pour la transmission des informations, j’ai utilisé une librairie permettant de simuler un capteur de type RFXMeter et RFXSensor. Du coup domoticz détecte le capteur tout seul comme un grand. Pour les informations de température et d’humidité, j’ai plutôt utilisé le format Oregon V2 gentiment mis à disposition par Olivier ici. Le nombre d’impulsions comptées est stocké dans l’EEPROM de l’arduino toutes les heures afin de ne pas perdre les informations en cas de coupure de courant.

Un seul arduino peut donc émuler toutes les sondes possibles et imaginables. D’autant qu’il ne faut qu’un arduino et un petit transmetteur 433MHz qui coûte 2-3€ ! Pour les arduino, j’utilise des Mini Pro en 5v ou en 3.3v suivant le type d’alimentation.

 

Après les informations concernant le matériel, voilà un petit tour de ce que ça donne dans Domoticz.

 

Le dashboard
Le dashboard
Les compteurs
Les compteurs
La conso de gaz
La conso de gaz
Les rapports d'électricité avec les coûts
Les rapports d’électricité avec les coûts
La météo
La météo
Des scénarios
Des scénarios

 

Des scripts lua sont aussi possibles pour faire ce qui n’est pas possible avec l’interface web. Ici par exemple, on envoie une notification sur mobile si la porte du garage est restée ouverte. Pratique avec des enfants :-D

print(‘Porte de garage…’)

t1 = os.time()
s = otherdevices_lastupdate[‘Porte de garage’]
— returns a date time like 2013-07-11 17:23:12

year = string.sub(s, 1, 4)
month = string.sub(s, 6, 7)
day = string.sub(s, 9, 10)
hour = string.sub(s, 12, 13)
minutes = string.sub(s, 15, 16)
seconds = string.sub(s, 18, 19)

commandArray = {}

t2 = os.time{year=year, month=month, day=day, hour=hour, min=minutes, sec=seconds}
difference = (os.difftime (t1, t2))
if (otherdevices[‘Porte de garage’] == ‘Open’ and difference > 300 and difference < 400) then
commandArray[‘SendNotification’]=’La porte de garage est ouverte depuis plus de 5 minutes!’

end

return commandArray

Il y a aussi des applications android / iphone pour piloter le tout avec son mobile.

Voilà un bref aperçu de ce que l’on peut faire. Tout ou presque est possible ! Si vous avez des questions sur cette solution, n’hésitez pas à laisser un commentaire :)

J’utilise depuis quelques mois une solution domotique qui me donne pleinement satisfaction. Cette solution relativement économique repose sur l’utilisation d’un RaspberryPi avec le logiciel Domoticz ainsi que d’un « modem » radio 433MHz RFXCom

Je ne vais pas détailler l’installation de Domoticz, tout est décrit sur leur site et l’opération reste très simple.

Mes besoins essentiels concernent les consommations de l’habitation ( eau, gaz, électricité ) et les relevés de température et humidité dans certaines pièces. De plus, je pilote quelques lumières ainsi qu’un radiateur de type sèche serviettes. Depuis quelques temps j’ai ajouté des capteurs d’ouverture sur les Vélux et les portes. Je peux ainsi savoir par une notification sur le téléphone si l’on quitte la maison avec un Vélux oublié ouvert…

La solution à base de technologie radio en 433MHz présente quelques avantages:

  • Le prix
  • Le nombre de modules disponibles sur le marché
  • La possibilité de créer facilement ses propres capteurs avec un arduino par exemple

Le gros inconvénient c’est que contrairement au Zwave, il n’y a pas de retour d’état. Pour piloter des éléments « critiques » comme le chauffage, c’est un peu gênant mais on peut y remédier d’une façon assez satisfaisante à l’aide d’un script.

Les modules que j’utilise sont disponibles facilement dans les grandes surfaces de bricolage ou sur internet.

 

Le raspberry équipé d’une carte RFM12Pi en 868MHz pour un usage futur.

RasberryPi
RaspberryPi

 

Le modem RFXCom. On pourrait en créer un avec un arduino pour beaucoup moins cher mais il faut décoder les différents protocoles ce qui m’aurait demandé trop de temps. J’ai donc préféré acheter un module « tout fait » et consacrer plus de temps sur les autres parties.

Module RFXCom
Module RFXCom

 

Des sondes de température Oregon sont disposées aux endroits stratégiques ( Salon, Salle de bain, extérieur, chambres…)

Capteur oregon de température et humidité
Capteur Oregon de température et humidité

 

Le carillon de la porte d’entrée est lui aussi compatible. Il peut donc servir d’alerte sonore si besoin, d’autant qu’il dispose de 3 mélodies utilisables avec des codes différents.

Carillion
Carillon

 

Pour les Vélux, de simples capteurs d’ouverture

Capteur d'ouverture
Capteur d’ouverture

 

Pareil pour la porte du garage

Capteur d'ouverture
Capteur d’ouverture

 

Il y a aussi un capteur de mouvement pour le déclenchement d’un éclairage et d’une notification sur smartphone

Capteur de mouvements
Capteur de mouvements

 

Les lumières sont pilotables par ces petits relais.

Module d'éclairage
Module d’éclairage

J’utilise aussi les modules d’éclairage pour piloter le sèche serviette. Attention, il faut le piloter au travers du fil pilote. Il y a une petite astuce très bien décrite sur le site d’Alexandre.

La consommation électrique est relevée par un OWL180. Une petite pince ampèremétrique branchée sur le compteur transmet la consommation en temps réel.

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Un petit écran déporté affiche la consommation en temps réel

Consommation électrique - OWL180
Consommation électrique – OWL180

 

Pour le gaz, c’est un peu plus compliqué mais aussi plus amusant. Les modules du commerce sont très chers, le DIY vient à la rescousse.

Capteur DIY Gasmonitor
Capteur DIY Gasmonitor

C’est simple, un arduino relève les impulsions générées par le compteur de gaz (un aimant est placé sur la roue du compteur) et les transmet à Domoticz par radio. On peut capter les impulsions d’un compteur de gaz avec un interrupteur reed.

Par la même occasion je relève la température et l’humidité du garage avec un DHT22.

Je vais aussi ajouter la consommation d’eau un peu plus tard.

IMG_20141230_095054_

Et le circuit vraiment très simple

Sélection_023

Le schéma et le code pour programmer l’arduino sont sur Github ici. C’est une première version mais ça marche très bien.

Pour la transmission des informations, j’ai utilisé une librairie permettant de simuler un capteur de type RFXMeter et RFXSensor. Du coup domoticz détecte le capteur tout seul comme un grand. Pour les informations de température et d’humidité, j’ai plutôt utilisé le format Oregon V2 gentiment mis à disposition par Olivier ici. Le nombre d’impulsions comptées est stocké dans l’EEPROM de l’arduino toutes les heures afin de ne pas perdre les informations en cas de coupure de courant.

Un seul arduino peut donc émuler toutes les sondes possibles et imaginables. D’autant qu’il ne faut qu’un arduino et un petit transmetteur 433MHz qui coûte 2-3€ ! Pour les arduino, j’utilise des Mini Pro en 5v ou en 3.3v suivant le type d’alimentation.

 

Après les informations concernant le matériel, voilà un petit tour de ce que ça donne dans Domoticz.

 

Le dashboard
Le dashboard
Les compteurs
Les compteurs
La conso de gaz
La conso de gaz
Les rapports d'électricité avec les coûts
Les rapports d’électricité avec les coûts
La météo
La météo
Des scénarios
Des scénarios

 

Des scripts lua sont aussi possibles pour faire ce qui n’est pas possible avec l’interface web. Ici par exemple, on envoie une notification sur mobile si la porte du garage est restée ouverte. Pratique avec des enfants </p>				</div>

			</div>

				<div class=

La dernière fois, je vous ai présenté une méthode essentiellement graphique, permettant une bonne approximation des paramètres PID de votre régulateur. Encore faut-il savoir comment tracer les graphiques, c’est ce que je me propose de vous expliquer dans cet article. Il est bien sûr évident que cette méthode peut être utilisée pour tracer des graphiques à partir de tout type de données, du moment que les données arrivent via un port série.
La première étape va consister à récupérer les données du port série sur un PC. Comme souvent, il existe plusieurs façon de faire, je vous présenterais celle que j’ai utilisé ici : un petit script python.

import serial
import sys

serialport = serial.Serial("/dev/ttyACM0", 9600, timeout=1)
line = []

while True:
    for c in serialport.read():
        line.append(c)
        if c == '\n':
            for s in line:
                f=open('myfile','a')
                sys.stdout.write(s)
                f.write(s)
                f.close
            line = []
            break

serialport.close()

Ce petit script prend les caractères arrivant sur le port série, jusqu’au caractère marquant la fin de ligne, puis écrit la ligne dans un fichier. Ca peut éventuellement suffire pour tracer un graphique… Mais dans ce cas précis, on veut pouvoir également envoyer une consigne au régulateur, la modifier afin de suivre la réaction de ce dernier. Problème : comment envoyer des données sans perturber la lecture des données et ne pas sauter de mesure ?
Là encore, il y a plusieurs méthodes possibles, certaines plus complexes que d’autres. Celle que j’ai choisi permet de garder un programme simple, mais ne fonctionnera que sous linux. Ceux sous un autre système chercheront du côté du multithreading…

import serial
import sys
import select

serialport = serial.Serial("/dev/ttyACM0", 9600, timeout=1)
line = []

while True:
        while sys.stdin in select.select([sys.stdin], [], [], 0)[0]:
          ligne = sys.stdin.readline()
          if ligne:
            print(ligne)
            serialport.write(ligne+'\r\n')
          else: # an empty line means stdin has been closed
            print('eof')
            exit(0)
        else:
            for c in serialport.read():
                    line.append(c)
                    if c == '\n':
                        for s in line:
                                f=open('myfile','a')
                                sys.stdout.write(s)
                                f.write(s)
                                f.close
                                line = []
                    break

serialport.close()

Ah oui, j’ouvre et ferme le fichier a chaque écriture, de manière à pouvoir accéder aux données pendant l’exécution du programme. Ca permet de visualiser l’évolution du graphique en temps réel.
Les données sont envoyées par le microcontrolleur sous la forme . Je n’ai pas de mesure de temps, chaque échantillon étant pris à un intervalle d’une seconde, il suffit de compter les échantillons pour connaître le temps écoulé.

Passons maintenant au graphique lui-même. Pour cela, j’utilise le logiciel Gnuplot, outil très puissant de tracé de courbes dont nous n’utiliseront ici qu’une infime quantité de ses possibilités. Lorsque vous lancez gnuplot en ligne de commande, vous vous retrouvez avec un shell dans lequel vous pourrez lancer vos commandes gnuplot.

plot 'myfile' using 1 smooth bezier title 'temperature', 
'myfile' using 2  with line title 'CO', 
'myfile' using 3 with line title 'Setpoint'
 plot 'myfile' using 1 

Indique que l’on va tracer une courbe correspondant aux données de la première colonne du fichier

smooth bezier

Indique que l’on veut lisser les données. Il n’est pas toujours intéressant de lisser les données, par exemple, ici la colonne 3 correspondant à la consigne n’est pas lissée, ce qui permet de visualiser le moment exact du changement de consigne. Par contre, dans le cas des valeurs mesurées, cela permet de s’affranchir du bruit sur les mesures.

title 'temperature'

Légende de la courbe. Pratique dès qu’il y a plus d’une courbe.

Par défaut, gnuplot va afficher le résultat à l’écran. Pour pouvoir enregistrer le résultat dans un fichier il faut taper les instructions suivantes :

set terminal "png"
set output "monfichier.png"
replot

Nota : avec la commande replot (ou avec le bouton replot de la gui), vous pouvez rafraîchir les données affichées, de manière à visualiser en continu vos données…
Il y a certainement plein d’amélioration possibles à ma méthode, mais je vous la présente car elle a le mérite d’être simple et rapide à mettre en oeuvre, tout en fournissant de bons résultats :)

Ott
17

Régulation PID, faire de jolis graphiques 2/2

arduino, diy, Électronique, expérimentation, General, planet, Programmation, théorie Commenti disabilitati su Régulation PID, faire de jolis graphiques 2/2 

La dernière fois, je vous ai présenté une méthode essentiellement graphique, permettant une bonne approximation des paramètres PID de votre régulateur. Encore faut-il savoir comment tracer les graphiques, c’est ce que je me propose de vous expliquer dans cet article. Il est bien sûr évident que cette méthode peut être utilisée pour tracer des graphiques à partir de tout type de données, du moment que les données arrivent via un port série.
La première étape va consister à récupérer les données du port série sur un PC. Comme souvent, il existe plusieurs façon de faire, je vous présenterais celle que j’ai utilisé ici : un petit script python.

import serial
import sys

serialport = serial.Serial("/dev/ttyACM0", 9600, timeout=1)
line = []

while True:
    for c in serialport.read():
        line.append(c)
        if c == '\n':
            for s in line:
                f=open('myfile','a')
                sys.stdout.write(s)
                f.write(s)
                f.close
            line = []
            break

serialport.close()

Ce petit script prend les caractères arrivant sur le port série, jusqu’au caractère marquant la fin de ligne, puis écrit la ligne dans un fichier. Ca peut éventuellement suffire pour tracer un graphique… Mais dans ce cas précis, on veut pouvoir également envoyer une consigne au régulateur, la modifier afin de suivre la réaction de ce dernier. Problème : comment envoyer des données sans perturber la lecture des données et ne pas sauter de mesure ?
Là encore, il y a plusieurs méthodes possibles, certaines plus complexes que d’autres. Celle que j’ai choisi permet de garder un programme simple, mais ne fonctionnera que sous linux. Ceux sous un autre système chercheront du côté du multithreading…

import serial
import sys
import select

serialport = serial.Serial("/dev/ttyACM0", 9600, timeout=1)
line = []

while True:
        while sys.stdin in select.select([sys.stdin], [], [], 0)[0]:
          ligne = sys.stdin.readline()
          if ligne:
            print(ligne)
            serialport.write(ligne+'\r\n')
          else: # an empty line means stdin has been closed
            print('eof')
            exit(0)
        else:
            for c in serialport.read():
                    line.append(c)
                    if c == '\n':
                        for s in line:
                                f=open('myfile','a')
                                sys.stdout.write(s)
                                f.write(s)
                                f.close
                                line = []
                    break

serialport.close()

Ah oui, j’ouvre et ferme le fichier a chaque écriture, de manière à pouvoir accéder aux données pendant l’exécution du programme. Ca permet de visualiser l’évolution du graphique en temps réel.
Les données sont envoyées par le microcontrolleur sous la forme . Je n’ai pas de mesure de temps, chaque échantillon étant pris à un intervalle d’une seconde, il suffit de compter les échantillons pour connaître le temps écoulé.

Passons maintenant au graphique lui-même. Pour cela, j’utilise le logiciel Gnuplot, outil très puissant de tracé de courbes dont nous n’utiliseront ici qu’une infime quantité de ses possibilités. Lorsque vous lancez gnuplot en ligne de commande, vous vous retrouvez avec un shell dans lequel vous pourrez lancer vos commandes gnuplot.

plot 'myfile' using 1 smooth bezier title 'temperature', 
'myfile' using 2  with line title 'CO', 
'myfile' using 3 with line title 'Setpoint'
 plot 'myfile' using 1 

Indique que l’on va tracer une courbe correspondant aux données de la première colonne du fichier

smooth bezier

Indique que l’on veut lisser les données. Il n’est pas toujours intéressant de lisser les données, par exemple, ici la colonne 3 correspondant à la consigne n’est pas lissée, ce qui permet de visualiser le moment exact du changement de consigne. Par contre, dans le cas des valeurs mesurées, cela permet de s’affranchir du bruit sur les mesures.

title 'temperature'

Légende de la courbe. Pratique dès qu’il y a plus d’une courbe.

Par défaut, gnuplot va afficher le résultat à l’écran. Pour pouvoir enregistrer le résultat dans un fichier il faut taper les instructions suivantes :

set terminal "png"
set output "monfichier.png"
replot

Nota : avec la commande replot (ou avec le bouton replot de la gui), vous pouvez rafraîchir les données affichées, de manière à visualiser en continu vos données…
Il y a certainement plein d’amélioration possibles à ma méthode, mais je vous la présente car elle a le mérite d’être simple et rapide à mettre en oeuvre, tout en fournissant de bons résultats :)

Étant donné que je n’ai pas encore tout le matériel nécessaire pour avancer mes autres projets, j’en profite pour approfondir un peu mes connaissances théoriques et vous en fait donc profiter. Mon projet ici est simple : Réguler une température à l’aide d’un microcontrolleur, mais surtout bien comprendre les tenants et aboutissements des différents réglages et algorithmes. L’objectif ici n’est pas tant d’expliquer ce qu’est un PID, ni comment il fonctionne dans le detail, mais plutôt de donner une méthode permettant d’approximer les coefficients du régulateur.

Je profiterais de cette expérience pour faire 2 articles :
– celui-ci concernant le PID a proprement parler
– Un second article concernant ma méthode pour obtenir des courbes « lives » a partir d’un arduino et d’un PC.

Qu’es-ce qu’un PID

Pour simplifier, on parlera dans la suite de régulation de température, vu que ce sera notre application ici. Mais bien entendu, une régulation peut se faire sur tout type de process (vitesse, débit, etc…)

Lorsqu’on veut réguler la température (d’une pièce par exemple), l’idée la plus simple qui nous vient à l’esprit est de faire une régulation tout-ou-rien : on est en dessous d’un premier seuil, on allume la chauffe, on passe au dessus d’un second seuil on coupe la chauffe. Cette façon de procéder, bien que très simple à implémenter n’est pas exempte de défauts. Par exemple, la température ne sera jamais vraiment constante, même si elle l’est « en moyenne ». Selon le process, on peut arriver à fortement dépasser les consignes (dans un sens ou dans l’autre), en fonction de l’inertie du système, ce qui peut s’avérer nuisible selon ce qu’on veut faire. Enfin, la puissance du chauffage oscillera entre 0 et 100%, ce qui engendre une surconsommation non négligeable.

La régulation PID permet de coller « au plus juste » à la consigne, en évitant les dépassement (en fonction du réglage comme on le verra plus loin), et en n’utilisant que la puissance nécessaire à aller à la consigne et à la maintenir. Concrètement, dans PID, on a P pour Proportionnelle, D pour Dérivée, et I pour Intégrale. Si comme moi vous avez tendance à être un peu allergique aux maths, vous commencez déjà à vous sauver, mais en fait c’est moins compliqué que ça n’en a l’air.

Proportionnelle : c’est ni plus ni moins que la différence entre votre consigne et la valeur actuelle, multiplié par un coefficient de proportionnalité (Que vous définissez, cf la suite). Dans la suite, nous l’écrirons Kc.e(t)

Intégrale : A chaque mesure, vous allez avoir une différence avec la consigne (en plus ou en moins). Prenez cette erreur à chaque pas de temps, multipliez la par un (autre) coefficient de proportionnalité, et additionnez le résultat de tous les pas de temps depuis le début, et vous avez la fameuse composante Intégrale. Dans la suite, l’intégrale sera notée de la façon suivante :

I

 

Dérivée : Son rôle est de « freiner » l’augmentation de puissance calculée en fonction de P et de I, de manière à ne pas dépasser la consigne. C’est une façon de prendre en compte la vitesse d’évolution de notre process. Pour le calculer, vous faites erreur actuelle – erreur précédente, multiplié par un troisième coefficient de proportionnalité

La formule globale de notre régulateur PID peut donc s’écrire de la manière suivante (plus d’explications plus bas):

Formule PID, source ControlGuru

Formule PID, source ControlGuru

 

Description du materiel

Le montage utilisé pour ces essais est très simple : un arduino, un bouton 2 positions, 1 capteur de température (DS18B20), un mosfet (IRF540), une résistance 10Ω 5W, et une alimentation 12V. Le mosfet est piloté par une sortie PWM de l’arduino, et gère le courant (puissance) transitant dans la résistance. Cette dernière chauffe donc plus ou moins en fonction du ratio PWM (la tension change) envoyé par l’arduino. Le bouton 2 positions sert à passer d’une première consigne (valeur PWM 5 sur 255) à une seconde (valeur PWM 30 sur 255) Un petit programme python enregistre les valeurs dans un fichier texte sur le pc (via connection série), et j’utilise GnuPlot pour avoir une jolie courbe et pouvoir lire les valeurs des graphiques plus facilement que directement sur l’image. Par la suite, j’ai ameliore mon script python, de maniere a pouvoir saisir une consigne via le port serie, tout en continuant de logguer.

Montage régulation de température

Montage régulation de température. Attention, utiliser une résistance 5W mini !

Méthode de réglage

Je vous présente une méthode « graphique » directement tirée du site Control Guru, appliquée à mon montage de test. Ce site étant en anglais et très dense en informations, j’ai essayé de résumer les points essentiels ici. J’invite ceux qui voudraient approfondir le sujet à consulter ce site qui est une véritable mine d’information sur la régulation.

Définitions

  • PV : Process Variable, cela correspond à la grandeur mesurée que l’on veut influencer (la température dans cet exemple)
  • CO : Controller Output , la sortie de notre contrôleur en %. (Correspond à l’ouverture de la vanne par exemple)
  • Kp : Gain du process
  • Kc : Gain du contrôleur

Introduction

Une fois modélisé notre boucle de contrôle, nous allons pouvoir en déterminer les trois paramètres principaux par expérimentation, mesure et calcul (et oui…)

Les paramètres à déterminer sont :

  • Kp : la Gain du process, ou, dit autrement, le sens et la grandeur de la variation de la sortie
  • Tp : Constante de temps du process, ou la vitesse de variation quand le process a commencé à répondre
  • θp : (Prononcer Thêta P) Temps mort du process, ou le délai écoulé avant que le process commence à réagir
Boucle de contrôle

Boucle de contrôle

Afin de pouvoir déterminer nos trois paramètres, il va nous falloir mesurer la façon dont réagis notre système. La première étape consiste donc à fixer une première valeur de sortie à notre contrôleur (CO) et attendre que la variable de sortie (PV, ici la température) soit bien stabilisée.

Une fois cette dernière stable, nous allons modifier la valeur de sortie du contrôleur (CO), et mesurer le changement obtenu sur la variable de sortie (PV). On logue bien sûr tout ça dans un fichier, avec les pas de temps, de manière à pouvoir également déterminer le temps mort du process (θp) et la vitesse de variation (Tp).

On se sert ensuite de ces mesures pour tracer un joli graphique, qui nous servira à déterminer nos différentes valeurs.

La formule permettant de déterminer notre premier paramètre Kc, qui est à la base du calcul de nos 3 paramètres (cf. formule) est la suivante :

source : controlguru

source : controlguru

pour déterminer Kc, nous devons donc commencer par déterminer différentes variables intermédiaires.

Calcul de Kp

Kp décrit le sens et de combien va évoluer PV, en fonction d’un changement de consigne (CO) Le cacul de Kp est assez simple : Kp=ΔPV/ΔCO ou en d’autre termes Kp = (différence en PV initial et PV final)/(différence entre consigne initiale et finale)

Sur mon prototype, j’ai modifié la consigne initiale (1,96%) pour une nouvelle consigne à 11.76%, voici la courbe obtenue:

Graphique test du système.

Graphique test du système.

En appliquant la formule ci-dessus, on a donc Kp = (79-40)/(11,76-1,96) = 39/9.8 = 3.98°C/%

Détermination de la constante de temps Tp

Tp représente le « en combien de temps » le système va réagir. En partant du même graphique, on va déterminer quand l’état de sortie vaut 63% de δPV, à partir du moment où le système à déjà commencé à réagir (et pas à partir du moment où on a modifié la consigne. Pour ceux qui se demandent d’où sort les 63%, vous trouverez toutes les explications (attention, maths !) dans ce pdf Fichier:Derive63rule.pdf On regarde donc le nombre de secondes écoulées lorsqu’on arrive à 63% de δPV (ici 39*0.63 + 40 = 64.6°C), et le nombre de secondes écoulées au moment où le système commence à réagir (très rapide ici)

Détermination de la constante de temps TP

Détermination de la constante de temps Tp

On obtiens donc Tp = 172 secondes.

Le cas de θp

θp représente le temps mort avant réaction. Dans une boucle de contrôle, il n’est jamais très bon d’avoir du temps mort, et il sera nécessaire d’avoir cette valeur la plus faible possible. Du fait de mon montage de test, le temps mort est ici très réduit. Ceci s’explique facilement par la position du capteur (sur la résistance), et par le faible volume à chauffer (uniquement la résistance. De manière assez intuitive, on imagine très bien que plus le volume à chauffer sera important, plus le temps mort sera long, pour une même puissance de chauffe.

Si on reprend le graphique ci-dessus, on vois que la consigne a été modifié à T1=195s, et j’ai décider de compter le début de la réaction à T2=198s. On a donc θp = T2 – T1 = 198 – 195 = 3s.

Il est intéressant de noter ici que mon échantillonnage étant d’une seconde, la valeur de θp peut être sensiblement erronée, du fait de sa faible durée dans ce cas.

Application à un modèle PID

Formule PID, source ControlGuru

Formule PID, source ControlGuru

Avec:

  • CO = Sortie du contrôleur (Controller Output)
  • CObias = biais du contrôleur, ou valeur nulle.
  • e(T) = Erreur actuelle, définie par SP – PV
  • SP = consigne (Set Point)
  • PV = valeur actuelle du process (Process Value)
  • Kc = Gain du controlleur, un paramètre de réglage
  • Ti = reset time, un paramètre de réglage
  • Td = derivative time, un paramètre de réglage

Calcul du gain et du reset time

Il faut tout d’abord se demander si notre process accepte un dépassement de consigne ou pas, ainsi que la vitesse à laquelle ce process doit réagir.

  • Si on accepte un dépassement, on peut choisir un réglage agressif, et donc un faible temps de réponse (petit Tc). Dans ce cas, Tc est le plus grand de 0.1Tp ou 0.8θp
  • Modéré, le contrôleur produira peu ou pas de dépassement. Dans ce cas, Tc est le plus grand de 1.Tp ou 8.θP
  • Conservateur, le contrôleur ne produira pas de dépassement, mais ira doucement, Tc sera le plus grand de 10.Tp ou 80.θP

Une fois décidé du comportement de notre contrôleur, et calculé Tc, on peut calculer le gain du contrôleur et le reset time grâce à la formule suivante :

source : controlguru

source : controlguru

Pour mon application, je vais choisir un comportement modéré. Tc sera donc la plus grande valeur de 1.Tp ou 8.θP (1×172 ou 8*3=24). On retiendra donc Tc = 172.

J’obtiens donc Kc = (1/3.98)*(172/(3+172)) = 0.25%/°C et Ti = 172

Je peux maintenant calculer mes deux principaux paramètres P et I :
P = Kc = 0.25
I=Kc/Ti. = 0.25/172 = 0.00145
Reste à déterminer D. la formule permettant de déterminer D est Kc.Td, avec Td = (Tp.θP)/(2Tp+θP) = (172*3)/(344+3) = 1.487. D vaut donc 0.25*1.487=0.372
D = 0.372

Mise en application

Reste maintenant à confronter les calculs à la réalité. Voici le code Arduino que j’ai utilisé pour effectuer mes tests :

#include <OneWire.h>
#include <DallasTemperature.h>

// Data wire is plugged into port 2 on the Arduino
#define ONE_WIRE_BUS 2
// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature. 
DallasTemperature sensors(&oneWire);
DeviceAddress insideThermometer;

unsigned long lastTime;
double Input, Output, Setpoint;
double ITerm, lastInput;
double kp, ki, kd;
int sampleTime = 1000; //1 sec
double outMin, outMax;
String cmd = String("");
double tfirst = 0;

float printTemperature(DeviceAddress deviceAddress)
{
  sensors.getAddress(insideThermometer, 0);
  float tempC = sensors.getTempC(deviceAddress);
  Serial.print(tempC);
  Serial.print(" ");
  Serial.print(Output);
  Serial.print(" ");
  Serial.println(Setpoint);
  return(tempC);
}

void compute()
{
  unsigned long now = millis();
  int timeChange = (now-lastTime);
  if(timeChange>=sampleTime)
    {
      //get the new input value
      Input = getInput();
      //compute all working error variables
      double error = Setpoint - Input;
      ITerm+=(ki * error);
      if(ITerm>outMax) ITerm = outMax;
      else if(ITerm < outMin) ITerm = outMin;
      double dInput = (Input - lastInput);
      
      //compute PID output
      Output = kp * error + ITerm - kd * dInput;
      if(Output > outMax) Output = outMax;
      else if(Output < outMin) Output = outMin;
      
      //remember some variables for next round
      lastInput = Input;
      lastTime = now;
    }
}

void setTunings(double Kp, double Ki, double Kd)
{
  double sampleTimeInSec = ((double)sampleTime)/1000;
  kp = Kp;
  ki = Ki * sampleTimeInSec;
  kd = Kd / sampleTimeInSec;
}

void setSampleTime(int NewSampleTime)
{
  if (NewSampleTime>0)
  {
    double ratio = (double)NewSampleTime / (double)sampleTime;
    
    ki *= ratio;
    kd /= ratio;
    sampleTime = (unsigned long)NewSampleTime;
  }
}

void setOutputLimits(double Min, double Max)
{
  if(Min > Max) return;
  outMin = Min;
  outMax = Max;
  
  if(Output > outMax) Output = outMax;
  else if (Output < outMin) Output = outMin;
  
  if(ITerm>outMax) ITerm = outMax;
  else if(ITerm<outMin) ITerm = outMin;
}

double getInput(void)
{
  sensors.setResolution(insideThermometer, 9);
  sensors.requestTemperatures(); // Send the command to get temperatures
  return printTemperature(insideThermometer);
}

void setup()
{
  Serial.begin(9600);
  pinMode(3, OUTPUT);
  Setpoint = 0; //on fixe 0 de consigne
  double P, I, D;
  P = 0.25;
  I = 0.00145;
  D = 0.372;
  int STime = 1000;
  setTunings(P,I,D);
  setSampleTime(STime);
  setOutputLimits(0, 255);
}

void loop(){
compute();
analogWrite(3,Output);
if (Serial.available() > 0) {
      char SerialInByte;
      SerialInByte = Serial.read();
      
      if(SerialInByte==13){
        Setpoint = cmd.toInt();
        cmd = String("");
      }
      else
      {
        cmd += String(SerialInByte);
      }
  }
}

et voici le résultat :

Test des paramètres PID calculés

Test des paramètres PID calculés

Conclusion :

J’ai utilisé des paramètres « conservateurs » afin d’éviter de dépasser la consigne. On peut voir qu’effectivement la consigne n’est jamais dépassée, au prix d’une montée en charge un peu lente. En partant sur cette bonne base, il est maintenant facile d’affiner si l’on souhaite quelque chose d’un peu plus réactif, il reste de la marge de manœuvre.

Sources :

La régulation étant un vaste domaine, j’ai trouvé beaucoup d’informations pertinentes sur les deux sites suivants. Si vous n’êtes pas anglophobe, et désirez approfondir le sujet, je vous les recommandes chaudement !
ControlGuru
brettbeauregard.com, auteur d’osPID



  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook