Archives de Catégorie: Arduino

Migration des repository du blog

Jusqu’à présent le code que j’ai pu vous présenter était hébergé chez google code. Or Google a décidé de fermer ce service.

J’ai donc décidé de migrer les repository mes-projets-arduino et mes-projets-raspberry vers gitlab. gitlab a l’avantage de permettre de créer des projets privés dans sa formule gratuite.

Pour ce faire j’ai suivi les grandes lignes de ce tutoriel.

Dans les grandes lignes j’ai rééxtrait mes projets depuis google code avec git-svn

git svn clone https://mes-projets-raspberry.googlecode.com/svn/trunk mes-projets-raspberry

j’ai vérifié que rien n’était oublié par rapport à mon répertoire local (normalement pas nécessaire, mais bon …). Pour ça j’ai utilisé l’excellent « meld ».

enfin j’ai fait un push des sources

git remote add origin git@gitlab.com:steftech/mes-projets-raspberry.git
git push -u origin master

Mes sources sont accessibles maintenant via :
https://gitlab.com/steftech/mes-projets-raspberry
https://gitlab.com/steftech/mes-projets-arduino

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.

Utilisation des Attiny

J’ai creusé du coté des Attiny pour avoir les même fonctionnalité que l’Arduino mais en moins cher.

J’ai retenu pour le moment l’Attiny 45 et le 85. Ces deux microcontroleurs ne disposent que de 8 pattes ce qui en fait un excellent moyen de diminuer la taille de ses montages. J’ai réussi à trouver sur ebay des Attiny 85 avec leurs sockets à moins de 2€ pièce (frais de port compris), par rapport à un arduino c’est déjà ça de gagné ! A noter qu’ils existent en plusieurs type de « casing », j’ai opté pour les ATTINY85-20PU.

Par contre ces petites machines sont limitées, j’ai bloqué sur l’Attiny 45 et sa limite de 4Ko de flash. En tentant de compiler un exemple simple utilisant RC-switch ( librairie de communication RF en 433 MHz) je n’ai pas réussi à descendre en dessous des 4Ko.

De plus les Attiny de la série X5 n’ont que 5 broches utilisables. Si votre projet en utilise plus vous pouvez regarder du coté des Attiny 44 et 84 ont plus de broches (mais pas plus de mémoire) ou directement des Atmgea328.

Bref, pour utiliser l’Attiny il suffit de suivre le tutoriel suivant :http://www.semageek.com/tuto-programmation-des-attiny45-avec-un-arduino/

Ce tutoriel est simple à suivre, un petit montage à faire, un programme à charger sur l’Arduino, quelques paramétrage de l’IDE de l’Arduino, le bootloader à charger sur l’Attiny et c’est parti.

EDIT du 3 juin : Et voici une version « propre » que j’ai réalisée à partir d’un Protoshield achetée sur Ebay. Le plus long a été de dessouder les connecteurs du dessus 😉

Programmateur Attiny

Programmateur Attiny

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

Ajout d’un Ecran LCD sur ma Timelapse-Machine

J’avais détaillé il y a quelques mois comment réaliser un timelapse avec Arduino . J’ai depuis fait évoluer le montage pour utiliser un écran LCD et un bouton pour gérer les temps d’attente entre chaque prise de vue.

Dans la précédente approche j’utilisais un potentiomètre pour régler le temps entre chaque prise de vue. Or cette méthode se révèle à l’usage peu pratique. Le potentio n’est pas très sensible, une pichenette le fait passer de 1 à deux minutes entre chaque prises, et il surtout est facile de faire une fausse manip et le dérégler.
J’ai donc choisi une autre méthode en définissant des plages pré programmée. La liste que j’ai retenu est la suivante (temps en secondes) : 5, 10, 30, 60 (1 min), 120 (2 min), 300 (5 min), 600 (10 min), 1800 (30 min). Cette liste est « en dur » dans le code, mais ce n’est pas bien difficile de la faire évoluer (chez soi, certes, quand on fait des prises de vue à l’extérieur c’est mort 😉 )
Chaque pression sur le bouton modifie le timer de l’arduino vers la valeur suivante dans cette liste.

Pour pouvoir visualiser le temps sélectionné j’ai utilisé un petit LCD trouvé sur ebay à 2-3€ pièce : le HD44780.

Timelapse LCD en boite

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

Le montage n’est pas bien différent du précédent, j’ai juste câblé l’écran et un bouton

Le bouton est entre le pin 2 et les 5V

Le LCD :

VSS GND
VD 5V
V0 4.7k Ohm => GND
RS pin 12
RW GND
E pin 11
D0 non connecté
D1 non connecté
D2 non connecté
D3 non connecté
D4 pin 7
D5 pin 6
D6 pin 5
D7 pin 4
A 150 Ohm => +5V
K GND

J’ai utilisé une résistance fixe de 150 Ohms pour relier l’Anode (A) au +5V, cela joue sur le contraste de l’écran. Ce choix peut être différent chez vous. Vous pouvez aussi utiliser un potentiomètre pour le rendre réglable.

Le code est disponible sous mon repository Arduino et comme d’habitude vous pouvez le reprendre à votre sauce.

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 – Part 2

Comme je l’avais dis dans mon précédent billet, j’ai des soucis de stabilité de lecture du port serie depuis le WR703N.

J’ai donc modifié le programme de lecture pour faire une fermeture puis une réouverture du port série, le problème se reproduit donc ce n’est pas la solution.

En complément j’ai modifié mon code Arduino pour allumer une led pendant la mesure, la led reste donc allumée quelques secondes avant de s’éteindre pendant la phase d’attente. J’ai bien constaté que pendant le figeage des lecture la led s’allumait et s’éteignait. L’Arduino n’est donc pas figé.

Le problème semble donc se situer au niveau du module cdc_acm ou du programme C. Sachant que le meme programme se déroule sans encombre sur mon PC Linux, je privilégie un pb module ou une spécificité à apporter à l’initialisation du port série. 

Pour le moment je n’ai pas d’idée comment avancer … si un lecteur en a … je prends

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.

Transformation de mouvement … en carton

Bielle Manivelle ... en carton

Bielle Manivelle … en carton

Après avoir réalisé un robot « en carton », j’ai fait un petit montage pour mon fils afin d’illustrer la transformation d’un mouvement de rotation (un servomoteur) en un mouvement linéaire de translation.

Pour ce faire j’ai réalisé une Bielle-manivelle en carton.

Un disque en carton est  accroché sur un servo moteur. (droite de la photo)

Sur ce disque en carton est accroché avec une attache parisienne (un bout de fil électrique rigide ou un trombone fait l’affaire aussi) une tige.

Cette tige propage le mouvement à la pièce qui doit adopter le mouvement de translation (sur la gauche).

J’ai branché le servo moteur en lieu et place d’un de ceux de robocarton. La commande se fait avec le nunchuk. Cela m’a permit de réaliser la vidéo suivante


Bielle Manivelle en action

C’est simple et avec un peu de chance mon fils s’en souviendra dans quelques années ^^