DIY Planet : Made in Fr

Ce projet, qui m’aura occupé quelques temps, est parti de trois points :

- Je n’avais pas de thermomètre chez moi, et ma femme et moi n’avons pas tout à fait la même sensibilité à la température, cela permet de donner une valeur objective et d’ajuster en conséquence (soit on met le chauffage, soit l’autre enfile un pull )
- J’avais besoin de tester un circuit de commutation pour tubes Nixie (spoiler : dans le but de réaliser une horloge), mais sur un nombre limité de tube, car en cas d’erreur, c’est très pénible de dessouder le tube et de le ressouder
- J’avais envie de réaliser un montage CMS le plus compact possible, et de tester au passage la mise en oeuvre de CMS taille 0402.

Si si, il y a un composant sur C6. La LED est une 5mm, placée là pour donner l’échelle.

Le montage se divise donc en 4 parties : la mesure de la température, effectuée par un vénérable LM35 (mais le montage permet aussi l’utilisation d’un LM73 plus précis) ; l’élévation de tension pour alimenter les tubes, le contrôle des tubes, et le pilotage de tout ça, réalisé par un Atmega328, version cms évidemment.

Le schéma d’ensemble

La partie mesure de température ne nécessite pas d’explications particulières. A noter simplement que le LM73 fonctionne en I2C, et que dans ce cas, il faut impérativement mettre les résistances de pullup R6 et R7. Dans le cas du lm35, elles ne sont plus nécessaires car ce dernier fonctionne en analogique, la sortie de celui-ci étant à connecter à la broche 4 de l’emplacement du lm73 (A5/SCL sur l’atmega).

La partie élévateur de tension est désormais classique sur mon site, il s’agit de la même que pour mes compteurs geiger, à savoir NE555 + Mosfet + bobine. Un petit condensateur 400v sert à lisser la tension obtenue.

La mise en oeuvre de l’AtMega328 n’a rien de spécifique. Il faut en revanche noter deux connecteurs, un connecteur ISP, et un connecteur permettant de brancher un adaptateur série. Le premier devant servir à charger le bootloader Arduino sur l’Atmega, le second à charger le programme/débugger comme s’il s’agissait d’un simple Arduino. Pour une raison que j’ignore, bien que le bootloader soit correctement chargé, il n’a fonctionné que sur une seule de trois cartes que j’ai assemblé. Après tests, la communication série s’effectue correctement et dans les deux sens, mais impossible de flasher l’atmega par ce biais (si quelqu’un a une idée…). Du coups, la programmation se fait via ISP, et le debug par la connexion série.

La partie la plus intéressante de ce montage est la partie pilotage des tubes nixie. Un des objectifs était de réaliser le montage le plus compact possible, exit donc les drivers type 7441, tout sera fait ici à base de transistors.
Afin de ne pas trop consommer, l’affichage des 2 digits ne se fera pas simultanément, mais l’un après l’autre, de manière très rapide, la persistance rétinienne se chargeant de donner l’impression d’un affichage fixe.
Coté cathode, les transistors sont dans une configuration peu courante : la base est commune à tous les transistors, en permanence à +5v, ce qui permet de n’avoir qu’une seule résistance (mais qui impose de n’utiliser qu’un seul digit à la fois). La commutation se fait en ramenant l’émetteur du transistor voulu à  0v. Dans cette configuration, il faut autant d’entrées/sorties sur le microcontrolleur que de digits, mais en l’occurrence, l’Atmega nous en propose nettement plus que nécessaire dans notre cas.

Le driver coté anode

Coté anode, il aurais été possible également de mettre un simple transistor NPN avec une résistance pour faire le travail. Cependant, la consommation « à vide » aurais été supérieure à la consommation lors de l’affichage sur un tube, ce qui n’est clairement pas le but recherché.
Le montage ci-dessus « coupe » le courant, en limitant les pertes à des valeurs infimes. La résistance R12 et le transistor NPN forment un driver de courant constant, réglé de manière à laisser passer juste le courant nécessaire au déblocage du transistor PNP.

Le thermomètre Nixie assemblé

Le circuit complet tiens sur un PCB de 5x5cm double face. J’aurais probablement pu faire encore plus petit, mais ça me semblais déjà un bon début !

Le circuit vu du dessus

Concernant l’assemblage du PCB, rien de spécial à mentionner, celui-ci étant étonnamment plus facile à assembler que ce qu’il pourrais sembler au premier abord, et ce, malgré le fait que j’ai soudé des résistances 0805 sur des emplacements 0603 (donc un peu plus petits que les résistances). Ayant fait plusieurs essais, j’ai testé différentes techniques de soudure, je vous ferais un petit topo là-dessus dans un prochain article. Globalement, si on omet les 2 composants 0402 (taille qui n’était pas impérative du tout, mais pour faire des tests), ce n’est pas vraiment plus compliqué qu’avec du traversant, au contraire même.  Le circuit intégré demande un petit coups de main, mais ça se fais très bien, et très rapidement. Les 0402, pour le coups, sont assez délicat à placer, leur petite taille faisant qu’ils se collent à la pane du fer à souder par capillarité, et leur taille nécessite de bons yeux en plus d’une bonne loupe (idéalement, une bino)

Enfin, pour finir, le code source, qui n’a rien de très spécifique, il se contente de récupérer la valeur du lm35, et décomposer le résultat obtenu en deux digits, les unité et les dizaines.

thermometre

Deuxième partie : de l’idée à la mise en oeuvre.

Passons donc, comme promis, à la construction de ce capteur de vitesse ET sens de rotation.

D’abord, dessiner le patron. Je choisis de faire 3 largeurs de franges sur 24 degrés selon le dessin suivant (Fig 4).

Fig. 4 : Patron du premier codeur

Les fronts « noirs » seront régulièrement répartis tous les 8° dans le sens trigo, cette répartition régulière pourra être la base de la mesure de vitesse, en se basant sur les fronts montants pour un sens de rotation, descendants pour l’autre sens. La première frange occultante aura 2° de large, la deuxième 4°, et la dernière 6°. Ceci répété 16 fois pour faire le tour. J’aurai donc une roue dentée à 48 créneaux par tour, ce qui suffit bien pour la précision dont j’ai besoin. Le premier prototype sera fait d’une roue dessinée sur l’ordinateur, imprimée sur un film transparent, découpée grâce aux petits ciseaux de couturière piqués à ma charmante épouse, et collée à nouveau sur un bouton de potentiomètre placé sur l’arbre moteur. Résultat nul : imprimante jet d’encre sur film transparent = pas du tout opaque, les variations de signal sont trop faibles. Je l’imprime sur du papier blanc, collé sur film plastique pour rigidifier, puis découpé aux ciseaux : c’est mieux au niveau du signal, mais mes découpes sont imprécises et les différences de largeurs de bandes sont trop irrégulières pour permettre une détection fiable du sens de rotation. C’est en plus très fragile. Néanmoins, le principe est validé : les créneaux obtenus à l’oscillo étant bien identifiables lorsque la fabrication des encoches est correcte (voir photo 5).

Photo 5 : Codeur « papier »

Je construis un modèle STL, en réduisant un peu la résolution pour faciliter la fabrication (10 séries de 3 encoches sur 360° au lieu de 16)  et l’imprime sur une RepRap… mais le plastique est trop translucide et je ne peux pas augmenter l’épaisseur sinon elle ne passera plus dans la fourche !! De plus la précision de la Reprap est trop limite, et les bords pas nets car les fils de PLA (le plastique utilisé) bavent un peu… les durées différentes sont difficilement identifiables (illustration 6).

Illustration 6 : Mauvais signal avec la roue en PLA

Tant pis, je passe à l’imprimante 3D Z-builder (flashage de résine UV par un vidéo projecteur) à laquelle j’ai aussi accès (merci Gi-Nova, et merci Christofer !) et obtiens enfin un modèle suffisamment précis, rigide, opaque… (illustration 7) qui va permettre de mesurer vitesse et sens de rotation de mes moteurs (vitesses variant de -120 à +120 tr/min).

Illustration 7 : Roue en résine photosensible

Et voici la roue codeuse sur le système final en cours d’assemblage… (photo 8).

Photo 8 : Roue codeuse en place

Pour la partie logiciel :

Afin de compter de manière fiable les fronts, j’ai opté pour l’utilisation d’interruptions, une qui compte les fronts montants et enregistre leurs dates, une autre pour les fronts descendants. Sur l’Arduino, le plus simple et fiable que j’ai trouvé est d’utiliser 2 entrées différentes pour cela (et comme entre temps j’ai investi dans un MEGA, cela ne me pose plus de gros soucis ). Le programme principal calcule alors la largeur (durée) des créneaux par différence de dates, conserve toujours les 3 derniers créneaux, et fait les calculs lorsque le créneau détecté est plus grand que les 2 précédents.

Pour être précis, notons ces durées (délai entre front montant et front descendant) dt1, dt2, dt3 dans l’ordre d’apparition. Nous venons de dire que au moment où nous faisons le calcul de vitesse et de sens dt3 est supérieur à dt1 et dt2. Alors si dt1<dt2, le sens de rotation est direct, mais si dt1>dt2, le sens de rotation est indirect. Dans le sens direct, la fréquence des fronts montants est à peu près régulière et permet de calculer assez précisément la vitesse angulaire de la roue codeuse (nombre de fronts montants comptés, ramené au temps passé depuis le dernier calcul). Dans le sens indirect ce sont les fronts descendants qui sont réguliers.

Voili-voila. Si vous avez besoin d’un capteur de vitesse vous donnant le sens de rotation : Do It Yourself !

Phil.

Bonjour à tous. Aujourd’hui, je ne suis là que pour ce petit édito, car j’ai le plaisir d’accueillir mon premier invité sur ce blog, à savoir Philippe, qui va vous présenter un sujet très bien documenté, et qui j’en suis sûr vous sera utile !

Hello, voici mon premier article dans l’esprit « DIY », soyez indulgents svp  ;-)

Merci aussi à Eric de me prêter une petite place dans son blog

Dans le cadre de la fabrication d’un système mécanique à plusieurs arbres (un train épicycloïdal pour être précis), j’avais besoin de mesurer les vitesses de rotation de chacun d’eux… en fait la vitesse ET le sens de rotation. N’ayant pas trouvé ailleurs de système équivalent à celui que j’ai mis au point, je me dis que cela vaut le coup de partager cette idée avec les bricoleurs intéressés.

1. Première partie : du besoin à l’idée.

Parmi les capteurs de vitesse (souvent capteurs de mouvement incrémentaux pour ce type de mesure) on trouve diverses techniques, parmi lesquelles des technologies magnétiques (sur certains compteurs de vitesse pour vélos par exemple) ou des solutions optiques sur lesquelles nous allons nous concentrer dans la suite.

Une solution simple pour construire un capteur de vitesse est d’utiliser une fourche optique (LED d’un côté + photo-transistor de l’autre) dans laquelle on fait passer un disque ajouré. Avec une fourche simple de ce type, connectée sur une entrée numérique d’un microcontrôleur, il est possible de compter un nombre d’impulsions par seconde et donc une vitesse de rotation en fonction du nombre de rainures disposées sur le disque codeur. J’ai donc commencé par effectuer quelques tests sur la base d’un cadran translucide de bouton de potentiomètre sur lequel j’ai collé des adhésifs radialement pour simuler des rainures radiales (photo 1). Une petite fourche et son électronique d’alimentation (récupérée sur un capteur de fin de course de Reprap, merci Pierrot), et me voici à mesurer la vitesse d’un petit moto-réducteur DC en comptant les interruptions sur une carte Arduino UNO. Petit gag (mais ça marche très bien quand même) : j’ai bien placé mon adhésif sur les 10 chiffres noirs du cadran de potentiomètre, mais l’adhésif n’est pas complètement opaque, et on voit donc passer sur l’oscillo les chiffres qui masquent le faisceau lumineux  plus efficacement que le scotch orange !

Photo 1 :

Codeur optique – premier test

Il est aussi possible avec cette technologie de déterminer le sens de rotation… à condition d’ajouter un 2^e photo-transistor judicieusement placé à côté du premier. Le signal optique reçu par le 2^e transistor étant décalé temporellement par rapport au premier, on obtient des signaux en quadrature dont le sens de déphasage permet de déterminer le sens de rotation. Voir l’excellent site de « Rémy Sonelec » pour plus d’explications sur ce type de codeur :

http://www.sonelec-musique.com/electronique_theorie_encodeur_optique.html

Et sachez que la plupart d’entre vous (sauf peut-être les plus jeunes) ont utilisé pendant des heures ce genre de capteur, puisqu’il a équipé la grande majorité des souris à boules pendant des années (Photo 2).

Photo 2 :

Souris a boule : 2 photo-transistors

(source : http://fr.wikiversity.org/wiki/Capteur/Capteur_de_position )

Inconvénient de cette technique à deux transistors : il faut doubler le nombre de photo-transistors (eh oui). En outre, plus il y a de capteurs = plus il y a d’entrées utilisées sur le micro-contrôleur… Or je prévoyais pour mon application de mesurer les vitesses de 3 moteurs, de piloter un afficheur LCD, ainsi que quelques autres éléments consommateurs de ports… incompatible avec l’Arduino UNO L. D’où la recherche d’une solution nécessitant un seul photo-transistor pour avoir la vitesse ET le sens de rotation d’un codeur optique… Comment faire ?? Eh bien appliquer ce que l’on enseigne aux élèves ingénieurs concepteurs de produits innovants : la méthode TRIZ ! Pour ceux qui ne connaissent pas voici un point de départ : http://www.triz40.com

Au-delà des 40 principes et des matrices de contradiction, TRIZ est aussi un état d’esprit, une manière de réfléchir. J’avoue donc que je n’ai pas passé en revue tous les tableaux fournis dans la méthode. Je trouve intéressant d’essayer de vous expliquer le raisonnement…

Ne voulant pas me palucher tous les tableaux et principes de Triz, j’ai donc simplement essayé d’utiliser un principe de générique de la méthode : « regarder le problème autrement, à l’envers, en séparant ou regroupant des éléments, en inversant ou permutant des paramètres… ». Voici en synthèse a posteriori ce que cela peut donner :

Les capteurs à fourche existants (souris, etc.) utilisent la séparation spatiale des récepteurs, qui sont fixes (2 photo-transistors) pour générer une séparation temporelle de 2 signaux. Mais je ne veux pas utiliser 2 récepteurs différents : contradiction. Que pourrait-on inverser ou permuter dans ce schéma, que pourrait-on regarder autrement ? Utiliser une « séparation temporelle » plutôt que spatiale ? Cela voudrait dire quoi ?… 

Ne pas travailler du côté du récepteur, mais du côté de l’émetteur ? Mais l’émetteur, c’est quoi ? La LED qui est émet la lumière ? Non, ce n’est pas elle qui génère le signal proportionnel à la vitesse de rotation : c’est la roue rainurée. à La roue pourrait-elle générer une variation temporelle du signal ? Ca voudrait dire des signaux irréguliers ? Bof, que pourrais-je en déduire ? Ou des signaux réguliers mais de durées différentes ? Et alors ? Poursuivons quand même : peut-être donc si je ne faisais pas des rainures toutes identiques… une large, une étroite,  une large, une étroite ? Les durées de 2 créneaux successifs seraient différentes. On revient à une décomposition spatiale (variation de largeur des rainures) pour générer une séparation temporelle, mais cette fois sur la roue au lieu du transistor. Non cela ne marche pas, j’aurai une alternance de signaux court-long-court-long quel que soit le sens de rotation. Aucun intérêt… ne jamais abandonner J … poursuivons… si 2 largeurs de rainures ne suffisent pas, mettons-en 3 ! Oui… avec une succession de rainures de largeurs 1 ;2 ;3 ;1 ;2 ;3 ;1… qui génère des signaux de 3 durées différentes ordonnées de même, la permutation des trois valeurs deviendra « impaire » lorsque le sens de rotation va changer :  1 ;3 ;2 ;1 ;3 ;2 ;1 ;3 ;… Je crois que c’est gagné !! Il suffira de regarder dans quel ordre passent les créneaux de différentes largeurs.

Concrètement, ceci s’est traduit par quelques nuits de réflexion, et quelques « gribouillis » sur le tableau blanc des enfants…

Premier croquis du codeur à sens

Dans le prochain article… la mise en oeuvre pratique.

10 minutes pour réutiliser un vieux jeans afin de ranger ses outils.