LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: SUPERN le janvier 20, 2016, 03:11:52 pm
-
Salut,
Comme annoncé dans ma présentation, je vais vous exposer la solution que Xavier et moi mettons au point pour piloter 8 aiguillages pour moins cher que les décodeurs du marché, mais aussi avec plus de sécurité et de performance.
Ce décodeur 8 servos est basé sur un shield pour Arduino UNO. Il résulte des essais effectués sur plusieurs types de servos (adaptation du mouvement, utilisation optimale du débattement du servos, limitation des efforts en fin de course, et limitation de la consommation) et après étude des offres commerciales de décodeurs.
Voir les détails sur http://cdmrail.free.fr/ForumCDR/viewtopic.php?f=17&t=2425&hilit=globale
Il résulte des essais qu'il faut couper l'alimentation des servos lorsqu'on ne les fait pas bouger. Il y a donc un circuit de coupure d'alimentation par la masse.
Sur ce shield on trouve aussi l'isolement optique nécessaire à l'Arduino pour lire le DCC et une alimentation complète qui permet de fonctionner:
Soit en autonome: alimentation par le DCC de la voie (à condition d'utiliser des servos qui consomment peu et de bien respecter les règles de montage)
Soit avec une alimentation extérieure 5 volts servos: utile si on a un grand nombre de servos à piloter, donc plusieurs modules à alimenter.
Soit avec deux alimentations extérieures: 5 volts servos + 10 volts Arduino. Cela permet de ne pas gaspiller la puissance DCC destinée aux locomotives.
Ce shield comporte également une mémoire EEPROM / I2C qui nous sert à stocker les paramètres (adresse du décodeur, position min et max de chaque servo individuellement et dernière position logique droit/dévié avant coupure d'alimentation).
Voici le schéma du shield:
A+
Yves
-
Bonsoir,
Projet intéressant. Nous avons également ce type de projet, voir ici : http://forum.locoduino.org/index.php?topic=125.0
J'ai quelques questions :
J'ai moi même sur une carte servomoteurs pilotée par un PIC, mis en œuvre une fonction d'allumage de l'alimentation de chaque servomoteur. Il ne s'agissait de régler un problème de consommation ou de grognement des servomoteurs quand ils forcent en butée, mais de limiter l'appel de courant à l'allumage car les servomoteurs frétillaient à la mise sous tension. Finalement, Guillaume a découvert qu'en tirant le signal de commande à +5V les servomoteurs ne frétillaient plus à l'allumage. Je suis donc revenu est arrière et j'ai redessiné une carte sans pilotage de l'alimentation des servos.
La question est : sachant qu'un micro-servomoteurs consomme environ 20mA (de mémoire il faut que je mesure à nouveau) est-il vraiment intéressant de complexifier le matériel pour cette fonction ?
Concernant la déconnexion du servomoteur quand il est en butée, il suffit d'arrêter de le piloter pour que la position ne soit plus asservie et que le moteur cesse de forcer. Cependant, certains servomoteurs numériques continuent d'asservir la position en l'absence de signal de commande mais ils sont rares.
Pourquoi mettre une EEPROM externe alors que l'Arduino en comporte déjà une ?
Pourquoi faire un shield qui a des contraintes de connecteurs plus complexes alors qu'une carte recevant un Arduino type nano ou pro mini est, me semble-t-il plus adaptée pour réaliser ce type de système ?
-
Bonsoir Jean-Luc,
Merci pour ton intérêt.
Beaucoup de questions, mais je vais essayer d'y répondre le mieux possible:
- La coupure de l'alimentation des servos n'est pas seulement faite pour limiter la consommation globale, ni celle en butée (bien que cela soit ainsi traité) mais pour éviter tout mouvement intempestif des servos lors d'une mise sous tension. En effet, lorsque l'on met en route, j'ai observé que certains servos partaient en butée avant de revenir sur la plage autorisée. Dans le modélisme à l'échelle N, on ne peut pas accepter qu'un servo aille en butée, sinon on a de la casse. J'ai vérifié qu'un délai entre la mise sous tension de la carte micro et des servos résolvait de manière sûre ce problème.
- La consommation d'un micro servo est bien de 20mA, sauf en butée ou lorsqu'il force. J'ai observé couramment 150 à 200 mA. C'est pourquoi j'ai prévu une alimentation extérieure avec un fusible ré-amorçable automatiquement.
- l'arrêt du pilotage ne me semble pas suffisant car il ne répond pas à mon premier point.
- L'EEPROM est utilisée pour pouvoir mémoriser les positions de butée et les positions de chaque servos afin de sécuriser les mises en route et arrêt. J'ai mis une mémoire externe car ce type de mémoire ne supporte que quelques dizaine de milliers d'écriture, ce qui fait que l'on ne jette pas le micro tous les deux ans, seulement un boitier à 1 Euros sur support. Mais chacun son option!
- enfin, le format UNO a été retenu, car le format du shield correspond à celle là (et encore on rentre au chausse pied vu qu'on a des implantations pour une alimentation autonome sur DCC).
Voilà, j'espère avoir compris tes questions et y avoir répondu. Si cela n'est pas clair, je reste à ta disposition.
De ton côté, où en es-tu de ton projet?
A+
Yves
-
Beaucoup de questions, mais je vais essayer d'y répondre le mieux possible:
- La coupure de l'alimentation des servos n'est pas seulement faite pour limiter la consommation globale, ni celle en butée (bien que cela soit ainsi traité) mais pour éviter tout mouvement intempestif des servos lors d'une mise sous tension. En effet, lorsque l'on met en route, j'ai observé que certains servos partaient en butée avant de revenir sur la plage autorisée. Dans le modélisme à l'échelle N, on ne peut pas accepter qu'un servo aille en butée, sinon on a de la casse. J'ai vérifié qu'un délai entre la mise sous tension de la carte micro et des servos résolvait de manière sûre ce problème.
Il semblerait bien que tirer le signal de commande à 5V (via une résistance de 10kΩ par exemple, produise le même effet. Je l'ai testé avec les HK15178 que j'ai acheté pour mes aiguillages (http://www.hobbyking.com/hobbyking/store/__16257__HobbyKing_8482_HK15178_Analog_Servo_1_4kg_0_09sec_10g.html) et le SG90 que je viens de tester a le même comportement. Si vous avez un large échantillon de servos, vous pourriez tester cette configuration. L'avantage est une complexité moindre. J'avais par le passé essayé de tirer ce signal de commande à la masse et là le servo bouge à l'allumage. Ceci couplé à l'arrêt du pilotage remplirait votre cahier des charges je pense.
Je mettrais une diode de protection sur l'alimentation externe, un mauvais branchement est si vite arrivé.
- L'EEPROM est utilisée pour pouvoir mémoriser les positions de butée et les positions de chaque servos afin de sécuriser les mises en route et arrêt. J'ai mis une mémoire externe car ce type de mémoire ne supporte que quelques dizaine de milliers d'écriture, ce qui fait que l'on ne jette pas le micro tous les deux ans, seulement un boitier à 1 Euros sur support. Mais chacun son option!
On trouve des EEPROM externe qui supportent 1 million d'écritures. Par exemple : http://www.tme.eu/fr/Document/70a2a08b621e743c2d24fbd8cde093d0/m24c01-w.pdf
http://www.tme.eu/fr/details/m24c01-wbn6p/memoires-eeprom-de-serie/st-microelectronics/
11 centimes l'exemplaire :-)
Pour ma part, j'explore une autre piste, j'attends le composant. Il s'agit d'un composant à trois broches qui surveille l'alimentation. Quand elle chute en dessous de 4,3V, le composant envoie une interruption au micro qui peut alors procéder à la sauvegarde des positions des servos avant que la tension soit trop basse. De cette manière l'écriture en EEPROM n'est fait que lors de l'extinction et il n'est pas nécessaire de la changer et on peut donc utiliser l'EEPROM interne de l'Arduino.
De ton côté, où en es-tu de ton projet?
La carte est dessinée et par à la fabrication la semaine prochaine. Concernant le montage des servos, nous avons eu la même idée. Sur les miens j'ai également des contacts de fin de course et d'alimentation du cœur. Voir ici : http://modelleisenbahn.triskell.org/spip.php?article35
A+
-
Salut,
Merci pour ton retour d'expérience.
La résistance n'a pas eu d'effet dans mon cas, mais j'ai pu calmer les servos par logiciel avec un setup plus développé.
Donc la solution complète fonctionne (en prototype).
OK pour la diode... je vais la rajouter.
Pour la mémoire, super site, je vais le visiter plus en détail.
Enfin, concernant la mémorisation des positions des servos en cas de coupure de courant, j'ai prévu un monitoring des tensions par les entrées analogiques de l'Arduino. Qu'en penses-tu?
Cordialement,
Yves
-
Bonjour,
Pour la mémoire, super site, je vais le visiter plus en détail.
Je suis un fan de TME. Choix suffisamment large, prix excellents, livraison du jour pour le lendemain si la commande est passée avant 15h pour un tarif raisonnable.
Enfin, concernant la mémorisation des positions des servos en cas de coupure de courant, j'ai prévu un monitoring des tensions par les entrées analogiques de l'Arduino. Qu'en penses-tu?
J'y ai pensé aussi au début mais ça ne fonctionnera pas. En effet, la tension de référence pour la conversion analogique numérique est la tension d'alimentation (ou bien dérivée de la tension d'alimentation). Si la tension d'alimentation chute, la référence chute également. Par conséquent une lecture analogique de la tension d'alimentation renvoie 1023 quelque soit la tension d'alimentation. La chute n'est donc pas détectable de cette manière.
La question qui subsiste est le temps dont on dispose pour sauvegarder les données. Si les servos sont à l'arrêt et en butée, un octet suffit, chaque bit représentant la position, droit ou dévié, de chaque servo. Mais si on veut également gérer le fait qu'un ou plusieurs servos sont en cours de déplacement au moment de la coupure, il faut mémoriser la position, entre 500 et 2500, donc 2000 valeurs possibles, de chaque servo. Il faut 12 bits par servo, soit 12 octets en tout. Il faut également 2 bits de plus par servo pour déterminer si il était à l'arrêt, en mouvement vers l'angle min ou en mouvement vers l'angle max. Donc 2 octets de plus. Dispose-t-on de 14 x 3,3ms = 47ms avant que le programme plante et/ou que l'EEPROM ne soit plus programmable ? Une autre solution est de ne pas sauvegarder les 12 bits par servo mais seulement les 8 bits de poids fort et d'oublier les 4 de poids faible, on peut ajuster ce poids fort si le poids faible est > 7 pour n'avoir qu'une erreur maximum de 3 bits = 8µs en plus ou en moins. Sachant que 8µs représente une erreur d'angle de 8/2000 * 180 = 0,72°, ça me semble tolérable. On économise 4 octets et on tombe à 33ms. On peut également tolérer une erreur plus importante, surtout dans la manœuvre d'un aiguillage, et intégrer les 2 bits d'état dans l'octet qui code la position et l'état d'un servo. On a alors 5 bits d'erreur, soit 32µs maximum et un angle de 2,88° ce qui me semble aussi tolérable, sachant que les angle min et max mémorisée par ailleurs ne seront pas dépassés. On tombe alors à 8 octets et donc 26,4ms de temps d'écriture.
On peut également décider qu'on ne fait bouger qu'un seul servo à la fois. Dans ce cas il y a beaucoup moins de chose à mémoriser : 1 octet pour la position des servos qui sont en butée, 4 bits pour spécifier quel servo est en mouvement (il faut un bit pour dire « aucun n'est en mouvement »), 1 bit pour indiquer dans quel sens il bouge et le reste pour sa position. On est à 3 octets, soit 10ms.
Dans le manuel, il est aussi fait mention de taille de page pour l'EEPROM. Une page fait 4 octets. Visiblement une page peut être écrite d'un seul coup. Dans ce cas, peut être que 3,3ms suffisent pour écrire nos 3 octets. Le bibliothèque EEPROM gère-t-elle l'écriture par page ? Je je sais pas, il y a une étude à faire :)
De combien de temps dispose-t-on ? Le micro tourne à 16MHz et page 316 du manuel, on a une courbe qui définit une zone de fonctionnement sûr en fonction de la tension d'alimentation et de la fréquence. La tension min à 16MHz se situe vers les 4V. Le circuit de surveillance que j'ai vu déclenche à 4,3V mais un diviseur de tension peut le faire déclencher avant, 4,6 ou 4,7 V par exemple.
-
Bonsoir Jean Luc,
En effet je pensais surveiller l'entrée aliments externe et pas le 5 volts dû micro.
Néanmoins je suis intéressé par ton composant de surveillance...
Si tu as une référence ?
Pour la mémorisation, j'ai essayé de ne stocker que les dizaines de micro secondes. Cela se fait sur 1 octet, donc 8 octets.
Au redémarrage on sait si le servo est en mouvement par la différence entre sa position et les butées.
Qu'en penses tu?
A+
Yves
-
Bonsoir Yves
Surveiller l'alimentation externe suppose qu'elle soit fixée à priori et stable. Or souvent on a une plage d'alimentation.
Le composant est le TC54 de microchip. Je ne l'ai trouvé qu'en SOT23 mais ça reste pas trop difficile à souder.
Pour la taille de ce qui est à stocker, l'expérience dira du temps dont on dispose. 8 octets pourraient se stocker en deux écritures. Je ne vois pas cette histoire de pages pour écrire dans l'EEPROM dans la Bibliothèque EEPROM, il faut que je creuse. À suivre donc.
-
Bonjour,
Merci pour tes réponses
Je pense alimenter la carte arduino par du 12 volts, soit externe soit issu du DCC par 7812.
Mon idée est de détecter un passage en dessous de 10 volts, ce qui élimine les parasites et laisse le temps de descente jusqu'à 7 volts pour faire l'enregistrement.
Je vais donc essayer avec un pont diviseur devant le TC54.
A+
Yves
-
Bien vu. Ça laisserait plus de temps pour faire la sauvegarde et ca laisse une marge de bruit confortable.
-
Salut,
Bon cela marche comme je le souhaitais.
Merci pour ton aide.
Voici donc le schéma final
A+ pour le programme Arduino.
Yves
-
Salut,
Voici le circuit imprimé:
A+
Yves
-
Bonjour,
Concernant la détection de perte d'alimentation, le TC54 ne va pas fonctionner pour surveiller la tension à l'entrée du régulateur 5V.
J'ai pensé à ce petit montage avec une zener 6,8V (et tu t'es planté):
(http://www.locoduino.org/pic/detectionAlim.png)
Tant que la tension VIN est supérieure à 6,8V, la diode zener est passante et LOST est tiré à la masse. Lorsque VIN chute en dessous de 6,8V, la zener se bloque et LOST monte à 5V, la diode vers le 5V tire l'excédent (point que je vais vérifier auprès d'un collègue plus fort que moi en électronique). Le montage provoque donc une transition de LOST qui peut être utilisée sur une entrée d'interruption du micro. S'il s'avère que la diode vers le 5V pose un problème, on peut faire ceci (et là je suis sûr que ça fonctionne nickel) :
(http://www.locoduino.org/pic/detectionAlim2.png)
Ça suppose que le pull-up de l'entrée du micro est actif. Cette fois si c'est une transition de l'état haut vers l'état bas.
-
Bonjour Jean-Luc,
Merci pour ta contribution. mais je pense que c'est exactement ce que fait le TC54 en version N, c'est à dire en collecteur ouvert.
Si tu utilises le TC54 normal, le niveau de sortie dépend de l'alimentation 5V du 7805 en effet.
J'ai reçu mes TC54N hier, je les câble aujourd'hui et te donne des nouvelles dans le WE.
Cordialement,
Yves
-
Oui mais le TC54 à une tension maxi de 10V. Ça ne va pas aller avec un VIN de 12V
-
Je n'ai pas beaucoup le temps, en ce moment, mais il me vient une idée : :P
Au lieu d'utiliser un 7812, on devrait utiliser un LM317.
http://www.ti.com/lit/ds/symlink/lm117.pdf (http://www.ti.com/lit/ds/symlink/lm117.pdf)
En fait, par son principe de fonctionnement, il contient une tension de référence à 1,25 V, tension qu'il maintient contre les fluctuations de la tension d'entrée.
Donc, si on met un ampli op (µA741, p.ex) qui a sa broche (-) à la tension de référence à 1,25 V et, pour le (+), une tension issue d'un pont diviseur sur l'entrée (7 k en haut et 1k en bas).
Donc (+)>(-) donc la sortie est à HIGH.
Quand la tension chute, la référence ne bouge pas. Par contre, il arrive un moment où (-)>(+) et l'ampli-op bascule à LOW.
Et bascule proprement, par un flanc bien raide. :D
-
Bonsoir,
En fait j'ai mis un pont diviseur 1k/1.5k devant cela fait une comparaison à 4.3*2.5 = 10.75 volts.
Cela marche sur mon prototype, la chute de tension est bien détectée.
Il me reste à vérifier à la remise sous tension, car cela entre directement sur Int1!
A+
Yves
-
Bonsoir,
En fait j'ai mis un pont diviseur 1k/1.5k devant cela fait une comparaison à 4.3*2.5 = 10.75 volts.
Cela marche sur mon prototype, la chute de tension est bien détectée.
Il me reste à vérifier à la remise sous tension, car cela entre directement sur Int1!
A+
Yves
Tant qu'aucune interruption n'est attachée, les variations sur int1 ne seront pas vue. Pour etre bordé met une tempo de quelques dizaines de millisecondes dans setup. Bien qu'en fait tu aies déjà la tempo du boot loader. A mon avis ça ne pose pas de problème.
Ce qui me chagrine dans le diviseur de tension, c'est l'absence de protection de l'Arduino. Si VIN est trop fort, tu grilles ton entrée
-
J'ai acheté quelques diodes zener et j'en profite pour mettre à jour le schéma. Dans ce que j'avais posté auparavant, j'avais fait une erreur : quand la zener est positionnée en inverse, on a une chute de tension égale à la tension inverse de la zener. La base du transistor est donc à 6,8V tout le temps et à VIN quand elle est en dessous de 6,8V. Donc bien au-dessus de la tension de 0,7V Vbe nécessaire pour le rendre passant. Conclusion, ça ne marche pas, le transistor est tout le temps passant et on ne détecte rien du tout.
Voici le bon schéma :
(http://www.locoduino.org/pic/detectionPerteAlim.png)
Donc quand VIN est > 6,8V + 0,7V (Vbe du transistor) = 7,5V le transistor conduit, LOST est à 0
Quand VIN est entre 7,5 et 6,8V, le transistor est en cours de blocage, les expérimentations montrerons à quelle moment l'IT a lieu.
en dessous, le transistor est bloqué et LOST est à 1.
-
Bonsoir Jean-Luc,
Merci pour ton intérêt pour mon projet. J'ai décidé de changer le principe d'alimentation de mon module. Je me cale sur l'existant:
--un 16v AC pour l'alimentation
--une entrée DCC (JK) pour la commande.
Je fournis le VIN régulé à l'Arduino par un 7812 et je dérive la tension des servos par un 7805.
Je surveille donc la sortie du 7812 et son passage sous 10,5 volt par le pont.
A la mise sous tension, dans le setup je mets un While qui attend que la tension sur ce pont soit supérieur à 4.5 volts. Tout semble OK.
Pensez-vous que cela puisse être intéressant de pouvoir recevoir les commande Locoduino par I2C (sortie bus prévue)?
Voici les nouveaux schéma et pcb.
A+
Yves