Archives du blog

Timelapse … le retour

Vous le savez ça fait quelques temps que j’expérimente pour réaliser des timelapse. Après cette version de base j’avais réalisé une version plus sympa avec un écran LCD pour contrôler les paramètres.
Il s’avère que lors d’une prise de vue je n’ai pas toujours accès à une source de courant pour alimenter l’Arduino et l’appareil photo.

Or la partie Arduino est améliorable, en effet jusque là j’utilise le kit de base qui prends sa place et consomme du courant (la led d’alimentation par exemple en dépense pour rien). Certains articles parlent d’une consommation de 30mA (en 5V ?).

J’ai donc eu l’idée de remplacer l’arduino par un Attiny 45. Outre la consommation, cela me permettra de faire un circuit plus compact.
Dans mon cahier des charges je veux une consommation faible donc pas de led ou de LCD. Se pose le problème paramétrage du temps entre deux clichés.

Commutateur DIP

Commutateur DIP

J’ai utilisé un commutateur DIP pour le paramétrage. Pour éviter une dépense de courant inutile, je le lis au démarrage et je conserve la valeurs, il faut éteindre et allumer le montage pour changer la valeur
Le commutateur utilisé ayant 4 interrupteurs j’ai 16 combinaisons possibles (ah du binaire !). En associant une valeur d’attente à chacune d’entre elle j’ai plus que ce qu’il me faut pour mon interface. Il est sans doute possible d’utiliser un DIP à 3 interrupteurs pour simplifier le schéma.

4 3 2 1 Valeur (en secondes)
0 0 0 0 1
0 0 0 1 2
0 0 1 0 5
0 0 1 1 10
0 1 0 0 15
0 1 0 1 30
0 1 1 0 45
0 1 1 1 60
1 0 0 0 90
1 0 0 1 120
1 0 1 0 240
1 0 1 1 300
1 1 0 0 450
1 1 0 1 600
1 1 1 0 900
1 1 1 1 1800

Le montage

PCB Timelapse mini

PCB Timelapse mini

Le PCB réalisé est le suivant, il est surement possible de le réduire mais je ne suis pas un expert dans ce domaine, le fichier fritzing est disponible dans le repository projet.

Le Code


int buttons[4] = {1,2,3,4};

unsigned long tableDelais[ 16 ] = { 1000,2000,5000,10000,15000, 30000, 45000,60000,90000,120000,240000, 300000,450000,600000,900000,1800000 };
unsigned long waitingTime = tableDelais[0];

int trigger = 0;
int triggerTime = 200;

void setup()
{
  // make the pushbutton's pin an input:
  for (int i=0; i < 4; i++)
  {
    pinMode( buttons[ i ] , INPUT);
  }
  int index = (digitalRead( buttons[3] ) ? 0 : 8 )
                    + (digitalRead( buttons[2] ) ? 0 : 4 )
                    + (digitalRead( buttons[1] ) ? 0 : 2 )
                    + (digitalRead( buttons[0] ) ? 0 : 1 );

  waitingTime = tableDelais[ index ];
  
  pinMode( trigger , OUTPUT);
  
}

void loop()
{
  digitalWrite( trigger, HIGH);
  delay( triggerTime );  
  digitalWrite( trigger, LOW);
  
  delay( waitingTime  );        // delay in between reads for stability

                    
}

Le chargement se faisant sur un Attiny 45 je vous renvoie sur l’article adéquat pour réaliser cette étape.

Le montage final

Tiny Timelapse

Tiny Timelapse


Par rapport au PCB réalisé ci dessus j’ai rajouté un interrupteur pour l’alimentation.
Mes connecteurs vers l’alim et vers le câble de l’APN sont des plots à vis , je n’ai pas assez de boitier à pile ni de câble pour l’APN pour les souder durablement.

Consommation

Mon premier test de consommation a été encourageant en affichant un débit de 8.5mA sous 5.6V (4 piles AA rechargeables).

J’ai donc lancé un test en situation, il a tourné pendant 6 jours sans s’arrêter. a ce moment là il tournait toujours mais le pack de piles est descendu à 2.29V/

Améliorations

voir s’il est possible d’améliorer la consommation via le code (réduction de la fréquence, …). Une piste à explorer : http://electronics.stackexchange.com/questions/49182/how-can-a-let-my-atmega328-run-for-a-year-on-batteries
Pas d’urgence sur une telle évolution, le facteur limitant ne sera pas sur l’attiny (mais sur l’APN).

EDIT 22/11/2013 : Correction du code, je n’y avais pas fait attention mais un int sur Attiny n’est pas aussi grand que sur Arduino. Du coup les temps > 30s, lorsqu’ils sont convertis en millisecondes dépassent et ne donnent pas le résultat attendu.

Brochages Arduino et Raspberry Pi

Un petit article bookmark pour citer deux liens particulièrement utiles.

[*] Les brochages de l’arduino, des Atmega328 mais aussi des attiny, à garder à portée de main

http://www.semageek.com/pratique-des-diagrammes-de-pinout-pour-arduino-et-atmega/

[*] Un petit PDF à découper et à enficher sur le port GPIO de votre Raspberry Pi, un must have pour ceux qui n’ont pas de Pi Cobbler

http://www.doctormonk.com/2013/02/raspberry-pi-and-breadboard-raspberry.html

Time Lapse avec Arduino

Un Timelapse ? Késako ?

Il s’agit d’un des premiers montages sérieux (comprendre : réellement utile) que j’ai réalisé avec l’arduino.

Il s’agit de piloter mon appareil numérique (un Canon EOS 350D) et lui faire prendre des photos toutes les n secondes ( n étant paramétrable). Les images prises seront mises bout à bout pour faire un film. Pour rappel une seconde de vidéo en contient 25 (plus ou moins selon les formats). Ce qui veut dire que le temps sera comme accéléré (tout dépend du temps entre chaque prise de vue)

Pour vous mettre en appétit je commence par vous donner le résultat :

Concernant la vidéo il s’agit d’un morceau écrit et interprété par Delphine Desrayaud pour l’occasion (encore merci !!).

Principes du montage

Connections de l’appareil

Mon reflex a une connectique jack stéréo 2.5mm qui permet de connecter un déclencheur souple.
Un déclencheur souple réalise le contact entre la masse et une des voix .
Ce contact réalise soit la mise au point soit le déclenchement.

Pour ce qui est du montage ici je ne m’intéresse qu’au shooting, la mise au point est réalisée manuellement.

Montage pilote

L’effet « interrupteur » est réalisé en alimentant un transistor 2N2222 avec l’Arduino. Le courant passe alors entre les deux autres pâtes du transistor.
Le paramétrage du temps entre deux prises de vue est réalisé au gré d’une résistance variable qui sera mesurée par l’arduino. Pour ce faire j’ai pris un slider de chez DFRobot.
J’ai rajouté 3 leds (rouge, jaune et verte) pour savoir où j’en suit du décompte entre deux prises de vues. Je trouvais utile de savoir si l’appareil va bientôt prendre la prise de vue ou non (vert : au début de l’attente, rouge : ne pas toucher shoot imminent).

PCB Timelapse

PCB Timelapse

Une petite boite pour la route ?

J’ai opté pour une petite boite en carton pour emballer ce petit montage

Shield sur l'arduino dans son ravissant écrin en carton

Shield sur l’arduino dans son ravissant écrin en carton

Code arduino

Le code de l’arduino est visible comme d’habitude ici

Montage des images

Une fois les images récupérées il faut en faire un film, après tout c’est le but de la manoeuvre.

Pour ce faire j’ai utilisé ffmpeg pour faire le montage. Mes images se nommant toutes img_XXXX.jpg ( avec XXXX = numéro croissant)

ffmpeg -f image2 -i img_%04d.jpg -vcodec mpeg4 -b 15M timelapse.avi

Goodies

M’amusant avec ImageMagick, j’avais aussi réalisé une vidéo en SD avec un timestamp sur chaque image

i=0
for file in *.JPG
do
  echo $i
  ((i=$i+1))
  newfile=`printf "imgs_%04d.jpg" $i`
  date=`exiftool -createdate $file | cut -c 46-50`
  convert -resize 720 -crop 720x576+0+0 $file -font Bookman-DemiItalic -draw "text 670,20 '$date'" $newfile
done

ffmpeg -f image2 -i imgs_%04d.jpg -vcodec mpeg4 -b 15M timelapse_timestamp.avi

Et pour remercier ceux qui sont allés jusque ici une seconde vidéo ^^

Instabilité de l’Arduino relié au WR703N

Comme je l’ai décris ici a plusieurs reprises, j’utilise un WR703N pour lire la liaison série de l’Arduino.

Cependant le montage s’arrête au bout d’un certain temps sans raison apparente. J’ai d’abord incriminé le matériel et le système, après tout le WR703N est du low cost Made in China ^^ et la version d’OpenWRT est en Bleeding Edge (danger Béta ^^).

L’Arduino me paraissait hors de cause vu qu’une fois branché sur l’USB du Linux il marche pendant des jours.

Il y a quelques jours je suis tombé sur l’article d’Andy Brown qui a eu le même soucis.

Lui a récupéré les données par un autre biais qu’un programme C, une lecture direct par le shell . Son hypothèse étant d’ouvrir à chaque lecture le port. Chez lui ça à l’air de fonctionner. Apres en avoir discuté ensemble je me suis mis en tete de modifier mon programme de lecture pour ré ouvrir le port périodiquement.

Mais hier, j’ai eu une autre idée (vous ne vous y attendiez pas hein ^^), et si le problème ne venait pas du système (un bug sur le driver cdc_acm qui m’aurait fort embetté) ? Hier j’ai donc fait le test en ajoutant une alimentation externe à l’Arduino.

 

Au moment où je vous parle (H+12), ça tourne toujours sans planter …

Est-ce la solution ? L’avenir le dira …

EDIT : J’ai parlé trop vite, en rentrant cet apres-midi j’ai trouvé la bête figée, plus d’accès au port ttyACM1 😦 Dans ces cas là obligé de relancer l’Arduino (électriquement)

 

Capteur de pluie – DIY

J’ai eu l’idée saugrenue de fabriquer un capteur de pluie pour m’envoyer un signal sonore quand il se met à pleuvoir la nuit et que la fenêtre est ouverte.

Le montage

Je suis parti d’une plaque de polystyrène mince et de deux fils de cuivre (une chute de câble multi brin dénudé). Il est tout a fait possible de prendre d’autres matériaux tant qu’ils ne craignent pas l’eau et qu’ils ne sont pas trop flexibles (il faut tendre les fils pour éviter qu’ils fassent contact entre eux). Sur le schéma les fils se chevauchent mais il faut imaginer qu’il passent derrière la carte par des trous percés. Il serait aussi tout a fait possible de faire un PCB mais pas sûr que cela soit rentable si la surface est énorme.

Le but est d’avoir deux fils dénudés qui ne sont pas en contact entre eux. C’est l’eau qui assurera leur contact, fermant ainsi le circuit comme un interrupteur. Reste a voir à l’usage à quelle vitesse l’eau va encrasser/oxyder les fils.

 

Capteur de pluie - DIY

 

Je mesure la résistance entre A et B (cf schéma), au repos il ne dois pas y avoir de contact. A est relié à GND et B à A0, une résistance de 1k Ohm est placée entre A0 et 5V.

 

Le code Arduino

J’ai réalisé un rapide programme d’alerte sur l’Arduino qui utilise mon bus ARV pour la communication. C’est le WR703N qui assure la connexion à distance de la sonde.

Je me contente d’une lecture toutes les 100 millisecondes, ça doit être assez précis dans la majorité des cas.

Pour éviter de noyer le bus sous les messages j’évite d’envoyer un message si la variation entre deux mesures est trop faible, j’estime que le changement ne se fera que brutalement, si la variation en 100ms est de 1 unité (sur 1023 …) c’est uniquement dû à l’incertitude de mesure.

De la même manière je considère que les valeurs qui m’intéressent sont < 1000, au dessus c’est sec , sauf si j’ai besoin de savoir si le capteur a séché … à voir si physiquement l’inclinaison du capteur peut aider à le sécher naturellement.

int sensorPin = A0;    // select the input pin for the potentiometer
int sensorValue = 0;  // variable to store the value coming from the sensor
int oldValue = 0;
int sensorDelay=100;

// Seuil en dessous duquel regarder l'évolution
int seuil = 1000;

void setup() {
  Serial.begin( 115200 );
}

void loop() {
  // read the value from the sensor:
  sensorValue = analogRead(sensorPin); 

  if ( sensorValue < seuil )
  {
    // si la valeur a changé de 1 on n'en tient pas compte, il y a trop de fluctuation sur la ligne pour que ce soit important
    if ( abs(  oldValue - sensorValue ) > 1 )
    {
      Serial.print("D");
      Serial.println(sensorValue);
    }
  }

  delay(sensorDelay);
  oldValue = sensorValue;
}

Paramétrage d’ARV

Pour ceux qui suivent ce carnet de note, j’ai développé un bus de communication en TCP/IP qui peut acheminer des messages lus depuis le port série de  l’arduino pour être traités ailleurs.

Pour le test je trace les informations dans un fichier texte grâce au plugin toFile d’ARV. Il faudra d’ailleurs que je développe un plugin qui peut appeler un programme/lire un son/tweeter/… quand il reçoit un message. Le problème sera de régler la sensibilité pour ne pas envoyer de messages trop fréquemment … Peut être en fixant un seuil et en ne notifiant que ce passage de seuil ?

collector.ini

Le fichier collector.ini permet d’associer à un type de message reçu un plugin qui va traiter celui-ci. La « paramétrabilité » est encore sommaire pour l’instant, mais ça viendra au fil du temps.

Pour l’exemple ci-dessous, l’arvcollector lisant le port série arduino envoie des messages de type « arduinoTP.WarningStation ». Un autre arvcollector déporté (celui ayant le collector.ini renseigné comme703 ci-dessous)  tracera les messages reçus (plugin toFile) en les horodatant (timestamp=TRUE).

[plugins]
arduinoTP.WarningStation=toFile.so

[toFile:arduinoTP.WarningStation]
timestamp=TRUE
fileOut=warning.csv

Lancement des processus

Sur le serveur je lance l’arvserveur et l’arvcollector pour traiter les messages via les plugins

./arvserver
./arvcollector [ip_serveur] PluginMaster

Enfin sur le WR703N je lance un collecteur lisant le port série

./arvcollector [ip_serveur] DropWarner /dev/ttyACM0 arduinoTP.WarningStation

L’instance DropWarner enverra des messages au serveur quand la valeur du capteur descendra en dessous de 1000. Le serveur va relayer à tous les autres collecteurs, dont PluginMaster qui a été configuré pour tracer dans le fichier warning.csv.

Application du capteur

Pour tester en situation j’ai mis le capteur cette nuit sous ma chaudière (qui depuis une semaine à une fuite une ou deux fois pas jour et dont on ne connait pas la provenance ). Cela m’a permis de détecter que la fuite a eu lieu à 2h34 du matin, au moment où tout le monde était assoupi dans la maison … surement la faute des chats.

ArduGate ou le pilotage d’un Arduino en manuel via une interface web

Un rapide petit billet pour vous parler d’un projet que je viens de découvrir : ArduGate.

ArduGate permet de contrôler son arduino à partir d’une page web.

Un programme est à charger sur l’arduino et un agent tourne sur l’ordinateur auquel il est connecté en USB. Une fois ce dernier lancé on a accès au serveur web sur http://127.0.0.1:8880/.

L’écran d’ArduGate

1) Paramétrage du port série à utiliser et du baudrate. A noter que sous Linux le port série est en /dev/ttyACM0 et que les ports énumérés ici sont les /dev/ttySXX. En attendant une correction de la part de l’auteur, j’ai donc fait un lien symbolique entre /dev/ttyS33 (un port inexistant) et /dev/ttyACM0.

sudo ln -s /dev/ttyACM0 /dev/ttyS33

2) Connexion à l’Arduino. L’Arduino doit avoir été préchargé avec le programme de l’ArduGate et bien sûr être connecté à l’ordinateur ^^

Une fois connecté il est possible d’accéder aux entrées/sortie digitales (3) et analogique (4).

Le sens des E/S Digitales est paramétrable dans les boites boites de sélection. Il est aussi possible de choisir de piloter un servo, un switch, une lumière ou un relais .

Je pense que ce programme me sera très utile dans les phases de développement et de test d’un montage électronique. Cependant je me vois mal l’utiliser pour piloter mes créations de façon pérenne, l’interface web étant à paramétrer lors de l’utilisation. Par contre pourquoi ne pas réemployer le protocole de communication entre l’ordinateur et l’arduino pour en faire un protocole universelle, mais cela revient à déplacer l’intelligence de l’Arduino vers l’ordinateur, l’Arduino n’étant plus que l’esclave de ce qu’il reçoit par son port série.

Passer un Arduino en wifi avec un WR703N

Le problème dans un appartement c’est bien souvent de faire passer des câbles et je trouve les shields réseau pour Arduino horriblement couteux. Rien que le shield ethernet coute une trentaine d’euro, et le wifi, si mes souvenirs sont bons est au moins une cinquantaine.

Possédant un WR703N qui allie le wifi et l’ethernet pour un prixé dérisoire, j’avais déjà pris le pari dans les articles précédents de lire les données de l’arduino depuis celui-ci. La connexion était en filaire, j’ai un peu cherché dans différents tutoriels pour activer le  mode client en WPA sur openwrt.

J’ai failli m’arreter sur celui-ci , utilisant wpa_supplicant, mais il n’est pas intégré aux outils de configuration d’OpenWRT ce que je trouvais dommage.

Apres quelques tâtonnements j’ai trouvé la configuration suivante :

  • /etc/config/network
config interface 'wan'
 option ifname 'wlan0'
 option 'proto' 'static'
 option 'ipaddr' '192.168.2.99'
 option 'netmask' '255.255.255.0'
  • /etc/config/wireless
config wifi-iface
 option device 'radio0'
 option mode 'sta'
 option ssid 'ssid de votre réseau Wifi'
 option encryption 'psk'
 option key 'mot de passe du wifi'

Il suffit alors de rebooter ou tout simplement de lancer la commande

wifi up

Reste à le passer en mode dhcp pour coller à la topologie du réseau de la maison, mais l’essentiel est fait.

Actuellement je mesure 0.5W en consommation pour l’Arduino (avec le programmes d’acquisition des températures et de la luminosité) et le WR70N avec Wifi et LAN activé. Je serais curieux de comparer avec un shield wifi, si quelqu’un à l’info …

D’ailleurs je cherche un câble USB « court » A mâle vers B mâle pour alimenter l’arduino depuis le WR703N, le plus court que j’ai fait son mètre et c’est un peu ridicule pour relier deux petites machines qui sont cote a cote. Alors si quelqu’un sait ou s’en procurer des pas cher (ou des connecteurs USB pas cher pour faire un câblage maison …)

EDIT : A lire la procédure de Andy Brown qui part dans le même sens que moi, mais à une autre approche que moi pour la lecture des données venant de l’arduino (je l’avais détaillée ). Comme on dit en perl : tmtowtdi.

Mise en graphique des données

Dans les billets précédents j’ai donc détaillé comment récupérer des température depuis l’Arduino, comment les véhiculer sur le réseau à travers un modèle client/serveur et comment les insérer dans une base de données.

Tout cela est bien beau mais des données non exploitées ne servent à rien.

Deux écrans de consultation me viennent naturellement à l’esprit :

Une consultation de la dernière valeur (un peu comme le ferait un thermomètre accroché au mur), cet écran est trivial donc pas la peine d’en parler.

Graphique de la station météo

Graphique de la station météo

Une visualisation d’un historique, cet historique sera constitué des moyennes sur chaque heure et restitués sur un graphique a deux axes (d’un coté les températures et de l’autre les mesures de lumière).  J’ai utilisé une librairie de chez Google dont la documentation se trouve ici .Je vous encourage a vous balader dans la doc, il y a des fonctionnalités assez intéressante d’autant plus que son utilisation est assez aisée. La génération du graphique que je souhaite rendre est fait coté client par du JavaScript.

En moins d’une heure j’ai donc codé un graphique, ce n’est peut être pas très « sexy » mais les données sont restituées et c’était là mon but.

Comme d’habitude le code est dans mon répository Google Code

Robocarton piloté par Nunchuk

Et non Robocarton n’est pas à la plage, meme s’il aimerait surement. Mais son dermatologue lui a déconseillé, il parrait que l’eau ne lui ferait pas du bien. Donc il est resté à la maison et j’ai pu le faire évoluer. Le but de la manœuvre a été de le faire piloter via un vieux Nunchuk dont le fil était coupé (je vous rassure il existe aussi des adaptateurs pour éviter de le massacrer).

Cela faisait un bout de temps que je tâtonnais mais je m’étais fait avoir par les code couleurs des fils qui ne correspondent à rien de censé (c’est un nunchuk « compatible », pas « officiel »).

Le nunchuk que je possede a ce cablage là :

  • Jaune : 3.3V
  • Rouge : Gnd
  • Bleu : A5 (clk)
  • Blanc : A4 (data)

D’autre part j’avais trouvé une Démo permettant de piloter un arduino à partir du nunchuk, mais la forme ne me plaisait pas (mettre du code dans un .h, j’entends encore certains professeurs hurler ^^).

Alors que j’étais parti pour en faire une librairie je suis tombé sur une implémentation par Gabriel Bianconi  dudit code.

Cette librairie est à déposer comme d’habitude dans le répertoire ~/sketchbook/libraries/.

Le code suivant une fois compilé  et envoyé il est  donc possible de :

  • faire lever/baisser les bras en bougeant le joystick vers le haut/bas
  • faire tourner la tête en bougeant le joystick vers la droite/gauche
  • allumer les leds en appuyant sur le bouton Z

(le code est aussi accessible sur google code)

#include <Servo.h> 
#include <Wire.h>
#include <ArduinoNunchuk.h>
Servo myServoTete;
Servo myServoBrasDroit;
Servo myServoBrasGauche;
#define BAUDRATE 19200
#define SERVO_BRAS_DROIT 7
#define SERVO_BRAS_GAUCHE 5
#define SERVO_TETE 6
#define LED_GAUCHE 9
#define LED_DROITE 8
#define LED_PECTORAL 10
ArduinoNunchuk nunchuk = ArduinoNunchuk();
#define MIN_JOY 0
#define MAX_JOY 255
#define MIN_SERVO 1
#define MAX_SERVO 181
int oldAngleTete = 0;
int oldAngleBrasDroit = 0;
int oldAngleBrasGauche = 0;
int oldStatusBoutonZ = 0;
void setup ()
{
 Serial.begin(BAUDRATE);
 nunchuk.init();
 myServoTete.attach( SERVO_TETE );
 myServoBrasDroit.attach( SERVO_BRAS_DROIT );
 myServoBrasGauche.attach( SERVO_BRAS_GAUCHE );

 pinMode( LED_GAUCHE, OUTPUT);
 pinMode( LED_DROITE, OUTPUT); 
 pinMode( LED_PECTORAL, OUTPUT); 
}
void loop ()
{
 nunchuk.update();
 int angleTete = (int) (( (float) nunchuk.analogX / ( MAX_JOY - MIN_JOY ) ) * ( MAX_SERVO - MIN_SERVO ) + MIN_SERVO);
if ( angleTete != oldAngleTete )
 {
 myServoTete.write( angleTete );
 oldAngleTete = angleTete;
 }

 int angleBrasGauche = (int) (( (float) nunchuk.analogY / ( MAX_JOY - MIN_JOY ) ) * ( MAX_SERVO - MIN_SERVO ) + MIN_SERVO);
 if ( angleBrasGauche != oldAngleBrasGauche )
 {
 myServoBrasGauche.write( angleBrasGauche );
 myServoBrasDroit.write( MAX_SERVO - angleBrasGauche );
 oldAngleBrasGauche = angleBrasGauche;
 }

 int statusBoutonZ = nunchuk.zButton;

 if ( oldStatusBoutonZ != statusBoutonZ )
 {
 digitalWrite( LED_GAUCHE, (statusBoutonZ == 1 ? HIGH : LOW ) );
 digitalWrite( LED_DROITE, (statusBoutonZ == 1 ? HIGH : LOW ) );
 digitalWrite( LED_PECTORAL, (statusBoutonZ == 1 ? HIGH : LOW ) ); 
 oldStatusBoutonZ = statusBoutonZ;
 }
}

Je laisse mon fils vous faire une démo (c’est dire si la robotique c’est un jeu d’enfant 😉 ) :


Robocarton piloté par un nunchuk

Capteur de température et de luminosité pour Arduino

WR703n

Arduino avec 5 sondes de température et deux de luminosité

A partir de code récupéré sur mon-club-elec.fr et la doc officielle de l’Arduino. J’ai réalisé il y a quelques mois un petit montage sur Arduino qui peut mesurer la température provenant de plusieurs capteurs DS18B20, ainsi que la luminosité ambiante à partir de photorésistances.

Pour ce qui est du montage, on utilise des entrées numérique pour les capteurs de température et des entrées analogique pour les photorésistances.  Les DS18B20 (températures) utilisent le protocole OneWire, heureusement la doc Arduino est là avec ses explications (la lib est téléchargeable ici).

Le Montage

Le montage est séparable en deux parties

  • les Sonde Thermo (à gauche)

Les sondes thermo sont toutes connectées sur le même port d’entrée numérique de l’Arduino. Je n’en ai représenté qu’une seule, mais en pratique toutes les sondes sont reliées au même bornier.

  • les photorésistances (à la droite)

Les photorésistances sont des résistances dont la valeur change avec la quantité de lumière reçue. Il existe des formules permettant de calculer la valeur en Lux correspondant, mais je n’ai pas les moyens de faire un étalonnage pour l’instant. La valeur mesurée sera donc relative (sur une échelle allant de 0 à 1023).

La collecte des données

Le code de l’arduino est hérité du travail de Xavier Hinault et se trouve ici. J’ai principalement apporté la gestion de plusieurs sondes Thermo, des photorésistances et mis en forme la trame remontée au PC via le port USB.

Les données en sortie sont écrites sur la sortie série (le classique Serial.println) et récupéré sur l’ordinateur par un programme dont j’ai déjà parlé ici , j’ai nommé log-avr (dont le code source est toujours lisible ici )

Oui je sais, j’écris les articles dans le désordre :p