ModelleisenbahN

Test des LED RGB WS2812B

Jean-Luc — 2013-12-09T20:53:06Z

J'ai reçu 10 exemplaires de ces LED la semaine dernière. J'avais préparé un circuit imprimé pour faire des essais. Le circuit représente une aiguille sur le TCO et les LED sont implantées à raison de 4 pour 3cm en X (soit un pas de 7,5mm) et 4 pour 2cm en Y (soit un pas de 5mm). De cette manière les LED tombent sur les intersections du cadre tactile.

J'ai tiré le circuit imprimé hier et soudé les LED.

Cet élément va venir prendre place dans le prototype de TCO que je suis en train de construire.

Je viens de tester avec la bibliothèque NeoPixel d'Adafruit et ça crache très fort. Un petit film pour se rendre compte :

Le programme de test d'Adafruit est assez démonstratif avec un bel effet sapin de Noël. Je ferai quelque chose de plus sobre bien entendu.

Témoins de positions : la mise en œuvre

Jean-Luc — 2013-12-03T19:28:33Z

Nous avons vu la technique du Charlieplexing dans « Témoins de positions : le Charlieplexing », nous allons maintenant l'appliquer à un système à 5 broches de pilotage et 16 LED puis l'intégrer dans notre application.

Charlieplexing des 16 LED témoins [1]

Le schéma pour allumer 16 LED est le suivant.

Charlieplexing avec 5 broches et 16 LED

On peut noter que le schéma est incomplet. En effet, avec 5 broches, il est possible de piloter 20 LED. Ici les couples de broches 0-3 et 1-4 sont manquants et nous n'allons donc pas les placer dans notre table d'état des broches.

Voici donc la table d'état des broches pour chaque LED

	broche 0	broche 1	broche 2	broche 3	broche 4
D0	0	1	Z	Z	Z
D1	1	0	Z	Z	Z
D2	Z	0	1	Z	Z
D3	Z	1	0	Z	Z
D4	Z	Z	0	1	Z
D5	Z	Z	1	0	Z
D6	Z	Z	Z	0	1
D7	Z	Z	Z	1	0
D8	0	Z	1	Z	Z
D9	1	Z	0	Z	Z
D10	Z	Z	0	Z	1
D11	Z	Z	1	Z	0
D12	Z	0	Z	1	Z
D13	Z	1	Z	0	Z
D14	0	Z	Z	Z	1
D15	1	Z	Z	Z	0

Nous allons donc construire cette table en C comme nous l'avons fait pour la Charlieplexing avec 3 broches de commande.

const byte etatSortiePourLED[16][5] = { { OUT0, OUT1, INZ, INZ, INZ }, /* D0 */ { OUT1, OUT0, INZ, INZ, INZ }, /* D1 */ { INZ, OUT0, OUT1, INZ, INZ }, /* D2 */ { INZ, OUT1, OUT0, INZ, INZ }, /* D3 */ { INZ, INZ, OUT0, OUT1, INZ }, /* D4 */ { INZ, INZ, OUT1, OUT0, INZ }, /* D5 */ { INZ, INZ, INZ, OUT0, OUT1 }, /* D6 */ { INZ, INZ, INZ, OUT1, OUT0 }, /* D7 */ { OUT0, INZ, OUT1, INZ, INZ }, /* D8 */ { OUT1, INZ, OUT0, INZ, INZ }, /* D9 */ { INZ, INZ, OUT0, INZ, OUT1 }, /* D10 */ { INZ, INZ, OUT1, INZ, OUT0 }, /* D11 */ { INZ, OUT0, INZ, OUT1, INZ }, /* D12 */ { INZ, OUT1, INZ, OUT0, INZ }, /* D13 */ { OUT0, INZ, INZ, INZ, OUT1 }, /* D14 */ { OUT1, INZ, INZ, INZ, OUT0 } /* D15 */ };

La fonction programmeBroche(...) reste la même par contre la fonction gereLED(...) doit être modifiée puisque l'on passe de 3 à 5 broches de commande.

void gereLED(int num) { if (etatLED[num] == ALLUME) { programmeBroche(8,etatSortiePourLED[num][0]); programmeBroche(9,etatSortiePourLED[num][1]); programmeBroche(10,etatSortiePourLED[num][2]); programmeBroche(11,etatSortiePourLED[num][3]); programmeBroche(12,etatSortiePourLED[num][4]); } else { programmeBroche(8,INZ); programmeBroche(9,INZ); programmeBroche(10,INZ); programmeBroche(11,INZ); programmeBroche(12,INZ); } }

Et le tableau etatLED doit être agrandi pour contenir 16 éléments.

Intégration dans l'application

Pour intégrer l'allumage des témoins dans l'application il faut tout d'abord insérer l'appel à gereLED() dans loop(). Nous faisons face à un premier problème. Pour que les servomoteurs pivotent suffisamment lentement, l'attente est de 5ms. Cela conduit à un balayage des 16 LED en 80ms ce qui est trop lent pour que la persistance rétinienne opère. Il faudrait balayer au moins 4 fois plus souvent. Par conséquent, le délai dans loop() va être réduit à 1ms et la gestion des poussoirs et des servomoteurs sera appelée toutes les 5 fois alors que la gestion des LED sera appelée toutes les fois. Nous allons donc ajouter un compteur compteurGestionServos initialisé à 0. Comme ceci.

void loop() { compteurGestionServos++; if (compteurGestionServos == 5) { compteurGestionServos = 0; ... /* code de gestion des servos et des poussoir à l'identique */ ... } gereLED(numLED); numLED++; if (numLED == 16) numLED = 0; delay(1); }

Il suffit ensuite de changer l'état des LED en ALLUME ou ETEINT dans le tableau etatLED en fonction des événements. Deux fonctions membre de la classe DescripteurServo sont concernées : evenementServo(...) où on va éteindre la LED de la position que l'on quitte et gereServo() où on va allumer la LED de la position que l'on atteint. Dans le tableau etatLED, les LED sont alternativement rouges et vertes et par conséquent la paire de LED correspondant à un servomoteur est à la position numéro de servo × 2 (angle minimum) et numéro de servo × 2 + 1 (angle maximum).

void evenementServo() { cptArret = -1; switch (etatServo) { case SERVO_A_ANGLE_MIN: etatLED[numServo * 2] = ETEINT; objetServo.attach(pin); case SERVO_EN_MOUVEMENT_VERS_ANGLE_MIN: vitesse = 1; etatServo = SERVO_EN_MOUVEMENT_VERS_ANGLE_MAX; break; case SERVO_A_ANGLE_MAX: etatLED[numServo * 2 + 1] = ETEINT; objetServo.attach(pin); case SERVO_EN_MOUVEMENT_VERS_ANGLE_MAX: vitesse = -1; etatServo = SERVO_EN_MOUVEMENT_VERS_ANGLE_MIN; break; } }

Dans la fonction membre gereServo(), la partie qui s'occupe du passage de la vitesse à 0 quand les angles minimum ou maximum sont atteint est modifiée comme suit :

if (! reglageEnCours || etatServo == SERVO_EN_MOUVEMENT_VERS_ANGLE_MIN || etatServo == SERVO_EN_MOUVEMENT_VERS_ANGLE_MAX) { if (angle > angleMax) { angle = angleMax; arreteServo(); etatServo = SERVO_A_ANGLE_MAX; etatLED[numServo * 2 + 1] = ALLUME; } else if (angle < angleMin) { angle = angleMin; arreteServo(); etatServo = SERVO_A_ANGLE_MIN; etatLED[numServo * 2] = ALLUME; } }

Il ne faut pas oublier d'allumer la LED correspondant à l'angle minimum dans la fonction membre connecte(...)

/* allume la LED correspondante */ etatLED[numServo * 2] = ALLUME;

Nous sommes parvenus au bout de ce développement. Voici le sketch de l'application complète à télécharger.

Sketch de l'application complète

mis à jour en version 1.1. La position des servos est désormais mémorisée dans l'EEPROM.

Dessin du montage complet

Attention : le montage montre les 8 servomoteurs alimentés par l'Arduino. Ce n'est pas possible en pratique et il est nécessaire d'avoir une alimentation 5V séparée pour les servomoteurs

Dessin du montage complet à télécharger en PDF

Attention : le montage montre les 8 servomoteurs alimentés par l'Arduino. Ce n'est pas possible en pratique et il est nécessaire d'avoir une alimentation 5V séparée pour les servomoteurs

Ainsi qu'une vidéo de démonstration.

Démonstration de l'application complète et terminée

[1] On peut noter que plus le nombre de LED est important, plus le temps d'allumage sur un cycle de balayage devient faible. En pratique, la luminosité n'est pas beaucoup plus faible avec 16 LED. Pour un plus grand nombre de LED, il peut être nécessaire de diminuer la valeur des résistances sans toutefois dépasser les capacités des entrées/sorties du micro-contrôleur

Témoins de positions : le Charlieplexing

Jean-Luc — 2013-12-02T21:08:29Z

La dernière fonction à mettre en œuvre est la gestion des témoins de position. 16 LED sont nécessaires et il nous reste 6 broches. La broche numérique 13 ayant déjà une LED soudée sur la carte de l'Arduino n'est pas très commode à utiliser. Il nous reste donc en réalité 5 broches.

Comment faire ?

Il existe une technique connue sous le nom de Charliplexing [1] qui permet de multiplexer des LED sur des entrées/sorties numériques. Examinons tout d'abord le cas de deux LED connectées à 2 broches avec 2 résistances de 150Ω.

Charlieplexing avec 2 broches

dont l'intérêt est plus que discutable.

Si la broche 0 est en sortie à 5V et la broche 1 en sortie à 0V, la LED rouge est allumée. Si la broche 0 est en sortie à 0V et la broche 1 en sortie à 5V, la LED verte est allumée. Toute autre configuration, une des broches ou les deux en entrée ou les deux en sortie au même potentiel, éteint les deux LED.

Ça ne nous avance pas beaucoup me direz vous.

Rajoutons donc une broche 2 et une résistance et ajoutons une paire de LED entre la broche 2 et la broche 1 mais aussi entre la broche 2 et la broche 0, soit 6 LED au total.

Charlieplexing avec 3 broches

Pour allumer la LED D5 par exemple, il faut mettre la broche 0 en sortie à 5V, la broche 2 en sortie à 0V et pour que ni D1, ni D3 ne s'allument, mettre la broche 1 en entrée (donc en haute impédance). On peut remarquer que D1 et D3 sont également alimentées mais comme elle sont en série, elles présentent une tension de seuil 2 fois supérieure [2] et le courant empruntera le chemin de plus faible tension de seuil.

Pour la suite on va noter le fait de mettre une sortie à 5V : 1, à 0V, 0 et en entrée : Z.

La table correspondant à l'allumage de chaque LED est la suivante.

	broche 0	broche 1	broche 2
D0	0	1	Z
D1	1	0	Z
D2	Z	0	1
D3	Z	1	0
D4	0	Z	1
D5	1	Z	0

De manière générale, avec N broches, on peut piloter N × N-1 LED. Avec nos 5 broches disponible, on pourra donc piloter 5 × 4 = 20 LED.

Programme de démonstration

Évidemment, seule une LED peut être allumée à un instant. C'est donc l'Arduino qui va s'occuper de balayer les LED et, pour chacune les allumer ou non à une vitesse suffisamment grande pour que l'œil ait l'impression que l'allumage de chaque LED est permanent grâce à la persistance rétinienne. Avant de nous lancer dans l'allumage de 16 LED, voyons comment fonctionne le programme pour 3 broches et 6 LED. Dans un premier temps, nous allons balayer et allumer les 6 LED pour juger de l'effet rendu.

Il faut tout d'abord transposer le table d'états en C dont les lignes correspondront aux LED et les colonnes aux sortie. Les états eux même sont définis par un enum, une manière de donner un nom symbolique à une constante numérique :

enum { OUT0, OUT1, INZ }; const byte etatSortiePourLED[6][3] = { { OUT0, OUT1, INZ }, /* D0 */ { OUT1, OUT0, INZ }, /* D1 */ { INZ, OUT0, OUT1 }, /* D2 */ { INZ, OUT1, OUT0 }, /* D3 */ { OUT0, INZ, OUT1 }, /* D4 */ { OUT1, INZ, OUT0 } /* D5 */ };

OUT0 signifie que le broche est en sortie et à 0, OUT1 qu'elle est en sortie et à 1 et INZ en entrée et à haute impédance, c'est à dire sans résistance de pull-up.

Ajoutons une fonction pour programmer une broche en fonction de ce code :

void programmeBroche(int numBroche, byte etat) { switch (etat) { case OUT0: digitalWrite(numBroche,LOW); pinMode(numBroche,OUTPUT); break; case OUT1: digitalWrite(numBroche,HIGH); pinMode(numBroche,OUTPUT); break; case INZ: pinMode(numBroche,INPUT); digitalWrite(numBroche,LOW); /* pas de pullup */ break; } }

Pour que l'on puisse tour à tour allumer une LED ou non, il nous faut un tableau qui, pour chaque LED, va indiquer son état, ALLUME ou ETEINT. De nouveau nous allons utiliser un enum.

enum { ALLUME, ETEINT }; byte etatLED[6] = { ETEINT, ETEINT, ETEINT, ETEINT, ETEINT, ETEINT };

Enfin, il nous faut une fonction qui, pour un numéro de LED, va chercher son état et, si elle elle allumée, appelle, pour chaque broche, programmeBroche avec les états de broche correspondant à l'allumage de cet LED. Si elle est éteinte, toutes les sorties sont mises dans l'état INZ.

void gereLED(int num) { if (etatLED[num] == ALLUME) { programmeBroche(10,etatSortiePourLED[num][0]); programmeBroche(11,etatSortiePourLED[num][1]); programmeBroche(12,etatSortiePourLED[num][2]); } else { programmeBroche(10,INZ); programmeBroche(11,INZ); programmeBroche(12,INZ); } }

Il suffit ensuite dans loop() de balayer les LED, de 0 à 5, en donnant leur état avec une période de 2ms.

int numLED = 0; void loop() { gereLED(numLed); numLED++; if (numLED > 5) numLED = 0; delay(2); }

Par dessus on superpose une séquence d'allumage comme, par exemple, un chenillard.

int numLED = 0; int LEDAllumee = 0; int compteur1s = 0; void setup() { /* Au début la LED 0 est allumée */ etatLED[LEDAllumee] = ALLUME; } void loop() { compteur1s++; if (compteur1s == 500) { /* Au bout de 1s, on allume la LED suivante */ compteur1s = 0; /* Éteint la LED qui était allumée */ etatLED[LEDAllumee] = ETEINT; /* Passe à la LED suivante */ LEDAllumee++; if (LEDAllumee > 5) LEDAllumee = 0; /* Allume la nouvelle LED */ etatLED[LEDAllumee] = ALLUME; } gereLED(numLed); numLED++; if (numLED > 5) numLED = 0; delay(2); }

Voici le programme de chenillard en Charlieplexing sur 3 broches et 6 LED.

Sketch du chenillard en Charlieplexing

Ainsi que la vidéo de démonstration

Démonstration du sketch de chenillard

[1] Le Charlieplexing est une technique proposée en 1995 par Charlie Allen, voir l'article sur Wikipedia

[2] La tension de seuil dépend de la couleur de la LED mais même en mettant en série 2 LED rouge dont la tension de seuil est la plus faible, 1,6V, 2 × 1,6V = 3,2 V reste supérieure à la tension de seuil des LED violettes, 3,1V

Reflexions ergonomiques sur le TCO

Jean-Luc — 2013-12-01T16:27:36Z

L'ergonomie du TCO me tourne dans la tête depuis quelques semaine et il est temps de fixer les réflexions sur le papier, enfin sur le web.

Les boutons tactiles

Comme expliqué dans « Quelques réflexions », le TCO est constitué d'un cadre tactile de 240 points sensibles disposés selon un maillage de 3cm en X et de 2cm en Y [1]. Tous les points sensibles ne sont pas employés. Ceux qui le sont doivent être matérialisés par une LED.

Un point important avec le tactile est que l'utilisateur doit avoir un retour immédiat de ses actions puisqu'il n'a aucun retour mécanique. Le fait de toucher une zone sensible doit produire un changement visuel.

Imaginons que la zone sensible et la LED qui la matérialise corresponde à la manœuvre d'une aiguille.

L'aiguille au repos est symbolisée par une lumière verte permanente ;
L'aiguille en mouvement est symbolisée par une lumière jaune clignotante ;
Le fait de toucher la zone sensible éclaire en jaune permanent ;
Le fait de retirer le doigt de la zone sensible provoque le mouvement de l'aiguille.

Le mouvement en lui même prend peu de temps mais le contrôleur central peut différer le mouvement de l'aiguille parce qu'une rame, conduite en automatique ou par un autre opérateur la préempte. Dans ce cas faut-il l'indiquer ? par une lumière verte clignotante par exemple ?

Le même principe s'applique pour les boutons des autres dispositifs : dételeurs, coupure d'alimentation, etc, avec évidemment des couleurs différentes selon le dispositif. Mais il y aura aussi des boutons semblables pour les fonctions. Par exemple envoyer une rame en gare cachée pourrait se faire en touchant le canton où se trouve la rame pour la sélectionner puis en touchant un bouton symbolisant la gare cachée.

Les boutons correspondantes aux appareils de voie : aiguilles et dételeurs, seront situés sur le dessin de la voie elle même. Ceux correspondant aux :

coupures d'alimentation ;
sélection de rame ;
position du pont tournant.

seront déportés comme représenté ci dessous avec les boutons des aiguilles en vert et ceux des coupures d'alimentation en jaune.

Annuler une commande

Supposons que l'utilisateur touche un zone sensible par erreur. Que faire pour annuler la commande ? Trois pistes seront explorées.

Disposer d'un zone sensible d'annulation mais l'utilisateur doit avoir ses deux mains libres ;
Ne valider la commande qu'après un appui dépassant une certaine durée. Un appui bref est donc annulé ;
Annuler la commande si l'appui dépasse une certaine durée. Un appui bref est donc validé.

Difficile de dire laquelle des deux dernières solutions est la meilleure. Il faudra expérimenter. L'avantage est qu'il suffit de changer le logiciel pour opter pour l'une ou l'autre des solutions.

La visualisation des itinéraires enclenchés

La visualisation des itinéraires est plus délicate. En effet, le minimum syndical consiste à placer une paire de LED à la fourche de chaque aiguille. Comme ceci.

Toutefois l'oeil aura du mal à voir un itinéraire si deux aiguilles sont distantes. Une alternative consiste à mettre des LED tout le long des voies et de les éclairer selon l'itinéraire enclenché.

Ces LED témoins font double emploi avec les LED de rétro-éclairage et il est tentant de fusionner les deux. C'est une voie que je compte explorer.

Il existe des LED RGB adressables individuellement que Pierre m'avait signalées en août dernier, les WS2812 et WS2812B. Je reviendrai sur le fonctionnement de ces composants prochainement.

L'idée est donc de disposer à intervalle régulier en position de rétro-éclairage des LED RGB dont la teinte serait adaptée à l'information communiquée avec par exemple :

Bouton, couleur adaptée au type et à l'état du bouton
Voie non alimentée, blanc peu lumineux
Canton libre ne faisant pas partie d'un itinéraire, blanc
Canton libre faisant partie d'un itinéraire, vert-jaune
Canton occupé ne faisant pas partie d'un itinéraire, violet
Canton occupé faisant partie d'un itinéraire, bleu

Les boutons ayant des couleurs saturées et les voies et cantons des couleurs peu saturées.

Difficile de juger de l'effet rendu sans essayer mais le système semble séduisant. L'un des avantages évident est de pouvoir régler l'éclairage et la couleur après-coup alors que l'utilisation de LED bicolores fixes oblige à décider de l'aspect à priori.

Un peu plus de 400 LED RGB seraient nécessaires pour mon TCO. À 60mA de consommation unitaire, les mettre toutes au blanc à l'intensité maximum nécessiterait 24A. Mais comme elles sont très lumineuses, il ne sera pas nécessaire de les illuminer au maximum et il est très probable que la consommation effective soit de moins d'un quart de la consommation maximum. Un fois encore, il faut faire des essais pour juger de l'intensité lumineuse nécessaire.

[1] Suite à une adaptation technique, la géométrie du TCO a changé entretemps. On a maintenant 20 points en X et 12 en Y