1351
Vos projets / Re : Un Arduino par canton
« le: février 17, 2015, 11:41:16 am »
J'ai fait une vidéo, je vous mets ça en ligne dès que possible.
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
1352
Vos projets / Re : Un Arduino par canton
« le: février 16, 2015, 04:37:06 pm »
Pour l'instant je fais des essais avec un moteur Graupner Speed 500E sans chercher à optimiser quoique ce soit. La seule chose que j'ai faite est de passer la fréquence de la PWM à 31,45kHz (d'après l'oscillo).
Le moteur est donc piloté avec une PWM à 31,45kHz.
Toutes les 10ms, la PWM est coupée et l'Arduino mesure la force contre électromotrice du moteur (FCEM). Quand un moteur tourne, il produit une tension, comme une dynamo de vélo, qui est proportionnelle à la vitesse de rotation. Pour cela, un montage à d'amplificateur opérationnel permet de la mesurer. Ça ramène une valeur entre 0 et 10V entre 0 et 5V et ça fonctionne avec des masses qui ne sont pas exactement les mêmes, elles peuvent différer de plusieurs volts.
L'Arduino effectue 6 mesures car la FCEM est très bruitée et les trie. Les deux extrêmes sont éliminés et une moyenne des 4 centrales est effectuée.
J'ai mis en œuvre un asservissement de vitesse du moteur avec un régulateur PI (j'utilise asservissement plutôt que régulation pour ne pas confondre). PI pour Proportionnel Intégral. La consigne est la FCEM à atteindre. En soustrayant la FCEM mesurée à la consigne, on calcule une erreur. Cette erreur est multipliée par une constante qu'il faut régler : le gain proportionnel. On calcule également la somme des erreurs ce qui donne l'intégrale de l'erreur. Cette intégrale est également multipliée par un gain. La PWM est donc calculée comme suit (ici on divise par l'inverse du gain intégral) :
La PWM est ensuite relancée avec la nouvelle valeur.
Pour l'instant l'électronique est un peu crade. L'ampli op est alimenté directement par la tension qui alimente le MOSFET et elle est très bruitée. Mais ça marche quand même
Le moteur est donc piloté avec une PWM à 31,45kHz.
Toutes les 10ms, la PWM est coupée et l'Arduino mesure la force contre électromotrice du moteur (FCEM). Quand un moteur tourne, il produit une tension, comme une dynamo de vélo, qui est proportionnelle à la vitesse de rotation. Pour cela, un montage à d'amplificateur opérationnel permet de la mesurer. Ça ramène une valeur entre 0 et 10V entre 0 et 5V et ça fonctionne avec des masses qui ne sont pas exactement les mêmes, elles peuvent différer de plusieurs volts.
L'Arduino effectue 6 mesures car la FCEM est très bruitée et les trie. Les deux extrêmes sont éliminés et une moyenne des 4 centrales est effectuée.
J'ai mis en œuvre un asservissement de vitesse du moteur avec un régulateur PI (j'utilise asservissement plutôt que régulation pour ne pas confondre). PI pour Proportionnel Intégral. La consigne est la FCEM à atteindre. En soustrayant la FCEM mesurée à la consigne, on calcule une erreur. Cette erreur est multipliée par une constante qu'il faut régler : le gain proportionnel. On calcule également la somme des erreurs ce qui donne l'intégrale de l'erreur. Cette intégrale est également multipliée par un gain. La PWM est donc calculée comme suit (ici on divise par l'inverse du gain intégral) :
Code: [Sélectionner]
int erreur = consigneVitesse - fcem;
cumulErreur += erreur;
pwm = erreur * gainProportionnel + cumulErreur / inverseGainIntegral;
La PWM est ensuite relancée avec la nouvelle valeur.
Pour l'instant l'électronique est un peu crade. L'ampli op est alimenté directement par la tension qui alimente le MOSFET et elle est très bruitée. Mais ça marche quand même
1353
Composants / Re : Un nouveau composant prometteur : le VL6180
« le: février 16, 2015, 09:43:33 am »
Attention aux capas de découplage. Dans la datasheet, il indiquent bien qu'elles doivent être le plus près possible des broches. Je verrais bien une languette de PCB un peu plus large que le composant avec les capas de découplage au dos et les composants pour l'alim régulée 2,8V sous la table. Comme ceci :
1354
Composants / Re : Un nouveau composant prometteur : le VL6180
« le: février 16, 2015, 09:06:45 am »
Bonjour Dominique.
Très intéressant du fait de la très petite taille. La datasheet chez ST
Pour la distance je lis plutôt une distance utile de 1cm à 15cm et un Max de 20cm
Ça va être coton à souder
J'ai cherché un peu et l'engin n'est pas donné. Vers les 6$ en petites quantité. On le trouve d'ailleurs difficilement, j'ai trouvé le prix chez Digikey
Très intéressant du fait de la très petite taille. La datasheet chez ST
Pour la distance je lis plutôt une distance utile de 1cm à 15cm et un Max de 20cm
Ça va être coton à souder
J'ai cherché un peu et l'engin n'est pas donné. Vers les 6$ en petites quantité. On le trouve d'ailleurs difficilement, j'ai trouvé le prix chez Digikey
1355
Vos projets / Re : Re : Un Arduino par canton
« le: février 14, 2015, 09:36:37 am »Il faudra que tu nous expliques cela le truc différentiel. Un peu cher le mcp comme tu dis. Les autres c'est mieux.
http://fr.m.wikipedia.org/wiki/Signalisation_différentielle
Citer
Une autre question d'ailleurs, les arduinos sont aussi reliés par la masse ?
Oui via l'alimentation. Mais il ne faut pas considérer que les masses sont identiques partout. Un fil long n'est pas une équipotentielle.
Citer
Si on reprend le truc, un arduino lambda uno ou mega ou mini pour le moment démarre le master clock sur la broche 3. Sont reliés ensuite d'autres arduino qui démarre le prog sync, crée un objet selon la biblio avec réception du signal sur la broche 8 et envoie le pwm sur la broche 3 en fonction d'un argument byte.
Chaque arduino mettant l'attribut byte qu'il veut d'où l'indépendance de chaque canton.
Oui c'est ça. Mais les valeurs de PWM appliquées sur chaque canton sont décidées par un Arduino maître qui connaît l'emplacement des trains via une rétro-signalisation.
Citer
Le due n'est pas nécessaire pour le moment, je réfléchis à en prendre un vu son prix pas si différent d'un méga. Ca sera pour mon mini module en HOe.
Le due me semble bien taillé pour jouer le rôle de l'Arduino maître.
1356
Vos projets / Re : Re : Un Arduino par canton
« le: février 13, 2015, 05:13:56 pm »peut-on augmenter au maximum la fréquence des PWM ? Sans cela, je serais dans l'impossibilité de gérer avec cette biblio. Au regard de ce que tu dis, oui mais différentiel ?
Oui. On peut augmenter la fréquence de la PWM au maximum. Le signal de synchro sera à la même fréquence et donc il est préférable de le diffuser en différentiel. Le faire avec un MCP2551 est un peu coûteux. Il existe des drivers différentiels et des récepteurs moins coûteux (UA9638 et UA9637)
Citer
Si je comprends bien un peu le code, c'est que pour les arduinos de base avec un atmega je parle, pas de possibilité encore du due par exemple.
Je pense que tu parles du contrôleur central. Pour l'instant je n'ai pas fait l'émission de la synchro sur un Due mais je pense que ça se fait facilement et je le ferai.
1357
Vos projets / Re : Un Arduino par canton
« le: février 08, 2015, 11:55:30 am »
Bonjour Pierre.
Ok, je vois. Quand je parlais de régulation de vitesse, je parlais de mesurer la FCEM et de piloter la PWM par une loi de commande pour que la FCEM soit égale à une consigne. Dans ce contexte, je pense que réguler la vitesse est difficile car la longueur de fils entre les rails et l'alimentation traction nuit à la mesure de la FCEM.
Ok, je vois. Quand je parlais de régulation de vitesse, je parlais de mesurer la FCEM et de piloter la PWM par une loi de commande pour que la FCEM soit égale à une consigne. Dans ce contexte, je pense que réguler la vitesse est difficile car la longueur de fils entre les rails et l'alimentation traction nuit à la mesure de la FCEM.
1358
Vos projets / Re : Un Arduino par canton
« le: février 06, 2015, 04:47:51 pm »
Bonjour Pierre,
Pourrais-tu expliquer ce que tu fais sur ton réseau ?
Pourrais-tu expliquer ce que tu fais sur ton réseau ?
1359
Bus CAN / Le bus CAN
« le: février 03, 2015, 04:16:53 pm »
Nous avions démarré en interne une discussion sur le bus CAN qui a débouché sur la réalisation d'un module permettant d'expérimenter le bus sur un Arduino. La carte réalisée est visible sur le fil voisin : BreakoutBoard CAN. Ce développement a été entrepris car les shields CAN sont mystérieusement hors de prix (20€ et plus).
Le bus CAN est déjà utilisé dans notre hobby. Il y a tout d'abord le MERG (Model Electronic Railway Group). Organisation anglaise qui a choisi le CAN pour interconnecter les modules qu'elle développe. L'explication est donnée ici : http://www.merg.org.uk/merg_resources/cbus.php
Ensuite il y a Zimo qui a choisi le bus CAN comme bus de rétro signalisation : http://www.zimo.at/web2010/aboutus/highlights_EN.htm
Enfin il y a CAN Digital Bahn : http://www.can-digital-bahn.com/news.php
J'utilise moi même le CAN sur mon réseau (2 bus en fait, l'un à 125kb et l'autre à 700kb+)
Des informations concrètes suivront sur le site éditorial.
Le bus CAN est déjà utilisé dans notre hobby. Il y a tout d'abord le MERG (Model Electronic Railway Group). Organisation anglaise qui a choisi le CAN pour interconnecter les modules qu'elle développe. L'explication est donnée ici : http://www.merg.org.uk/merg_resources/cbus.php
Ensuite il y a Zimo qui a choisi le bus CAN comme bus de rétro signalisation : http://www.zimo.at/web2010/aboutus/highlights_EN.htm
Enfin il y a CAN Digital Bahn : http://www.can-digital-bahn.com/news.php
J'utilise moi même le CAN sur mon réseau (2 bus en fait, l'un à 125kb et l'autre à 700kb+)
Des informations concrètes suivront sur le site éditorial.
1360
Vos projets / Re : Un Arduino par module....ou pas.
« le: février 03, 2015, 02:52:52 pm »
Je ne suis pas spécialement pro-filaire et je pense qu'on est d'accord 
C'est juste que le sans fil a des temps de latence indéterminés qui dépendent de l'encombrement du médium de communication et la bande des 2,4Ghz est particulièrement encombrée (Bluetooth et wifi) et que ces conditions ne seront pas les même chez soi au calme radioélectrique (quoique en appartement...) et sur un salon où un tas de types vont se promener avec le Bluetooth de leur téléphone allumé et où plusieurs réseaux wifi seront déployés.
Tu ne peux pas faire reposer sur ce type de communication certains systèmes de contrôle où tu as besoin de connaître les temps de communication et d'être sûr de leur déterminisme pour assurer le bon fonctionnement du système. Ni sur des systèmes ou tu as besoin de la meilleure fiabilité de transmission possible. Je ne dis pas que c'est le cas du système que veut construire petitrain. Je dis que les solutions ne sont pas uniquement à comparer quantitativement mais également qualitativement. Si le sans fil était aussi bien et universel, les constructeurs automobiles et les avionneurs n'hésiteraient pas une seconde à remplacer les dizaines ou centaines de kg de cuivre des fils par des modules radio. Ils gagneraient en coût et en simplicité de déploiement mais pas en fiabilité (pour ma part je ne monte pas dans un avion ou une voiture où les calculateurs sont interconnectés en sans fil
).
C'est très différent des communications sur un réseau domestique ou entre micros où les latences sont gênantes mais ne mettent pas en danger le système. Où un clic souris qui ne passe pas n'est pas grâve. Dans ces applications, on cherche de la facilité, pas de la fiabilité et de la sûreté de fonctionnement.
En fait je pense que les deux solutions sont complémentaires. Ok pour le sans fil quand le fil est vraiment ennuyeux : manette, capteur à poser sur un module dont on n'est pas l'auteur pour prolonger un automatisme, systèmes non critique. Ok ce sont des petits trains mais pour moi les parties critiques sont les aiguillages (connaître avec de faibles chances de se tromper leur position), la détection (savoir où se trouve le matériel) et la traction (pouvoir arrêter une loco à coup sûr). Ces trois systèmes collaborent pour assurer l'anticollision. Il n'est pas souhaitable que ces systèmes soient en sans fil avec des temps de communication indéterministes.
En ce qui concerne les risques de pannes dues aux fils, il ne faut pas confondre le cas général où des fils sont déployés dans des lieux inappropriés et n'importe comment, humides, etc et le cas où c'est correctement déployé et la plupart des modélistes disposent soigneusement leur câblage. Par ailleurs, avec le CAN, on peut commencer par une séquence de « qui est là » ce qui permettra de connaître le fil ou le nœud en défaut.
Donc je ne suis pas pro-filaire ni pro-wifi, je suis pour utiliser les technologies là où elles font sens. J'ai utilisé le CAN extensivement sans rencontrer le moindre problème et avec des temps de communication parfaitement prédictibles et strictement réguliers. J'ai bricolé avec des nrf24 et je vais en utiliser là où c'est sympa et utile et je vais les soumettre à des tortures pour voir ce qu'on obtient. Donc les deux sont acceptés dans leur domaine de prédilection
C'est juste que le sans fil a des temps de latence indéterminés qui dépendent de l'encombrement du médium de communication et la bande des 2,4Ghz est particulièrement encombrée (Bluetooth et wifi) et que ces conditions ne seront pas les même chez soi au calme radioélectrique (quoique en appartement...) et sur un salon où un tas de types vont se promener avec le Bluetooth de leur téléphone allumé et où plusieurs réseaux wifi seront déployés. Tu ne peux pas faire reposer sur ce type de communication certains systèmes de contrôle où tu as besoin de connaître les temps de communication et d'être sûr de leur déterminisme pour assurer le bon fonctionnement du système. Ni sur des systèmes ou tu as besoin de la meilleure fiabilité de transmission possible. Je ne dis pas que c'est le cas du système que veut construire petitrain. Je dis que les solutions ne sont pas uniquement à comparer quantitativement mais également qualitativement. Si le sans fil était aussi bien et universel, les constructeurs automobiles et les avionneurs n'hésiteraient pas une seconde à remplacer les dizaines ou centaines de kg de cuivre des fils par des modules radio. Ils gagneraient en coût et en simplicité de déploiement mais pas en fiabilité (pour ma part je ne monte pas dans un avion ou une voiture où les calculateurs sont interconnectés en sans fil
).C'est très différent des communications sur un réseau domestique ou entre micros où les latences sont gênantes mais ne mettent pas en danger le système. Où un clic souris qui ne passe pas n'est pas grâve. Dans ces applications, on cherche de la facilité, pas de la fiabilité et de la sûreté de fonctionnement.
En fait je pense que les deux solutions sont complémentaires. Ok pour le sans fil quand le fil est vraiment ennuyeux : manette, capteur à poser sur un module dont on n'est pas l'auteur pour prolonger un automatisme, systèmes non critique. Ok ce sont des petits trains mais pour moi les parties critiques sont les aiguillages (connaître avec de faibles chances de se tromper leur position), la détection (savoir où se trouve le matériel) et la traction (pouvoir arrêter une loco à coup sûr). Ces trois systèmes collaborent pour assurer l'anticollision. Il n'est pas souhaitable que ces systèmes soient en sans fil avec des temps de communication indéterministes.
En ce qui concerne les risques de pannes dues aux fils, il ne faut pas confondre le cas général où des fils sont déployés dans des lieux inappropriés et n'importe comment, humides, etc et le cas où c'est correctement déployé et la plupart des modélistes disposent soigneusement leur câblage. Par ailleurs, avec le CAN, on peut commencer par une séquence de « qui est là » ce qui permettra de connaître le fil ou le nœud en défaut.
Donc je ne suis pas pro-filaire ni pro-wifi, je suis pour utiliser les technologies là où elles font sens. J'ai utilisé le CAN extensivement sans rencontrer le moindre problème et avec des temps de communication parfaitement prédictibles et strictement réguliers. J'ai bricolé avec des nrf24 et je vais en utiliser là où c'est sympa et utile et je vais les soumettre à des tortures pour voir ce qu'on obtient. Donc les deux sont acceptés dans leur domaine de prédilection
1361
Vos projets / Re : Un Arduino par module....ou pas.
« le: février 03, 2015, 05:13:17 am »
Mmmmmh
J'ai des nrf24 sur les cartes de mes radiateurs. Parce que je ne me voyais pas passer des fils dans toute la maison pour les piloter. Sur le réseau c'est différent c'est déjà plein de fils partout et c'est pas un rj11 de plus qui va changer la donne. Par contre pour les poste de conduite je pensais effectivement utiliser des nrf24. Mais je n'en prévois que trois.
Je n'ai pas fait des tests de performance avec les nrf24 mais pourquoi pas, pas seulement le débit mais egalement la latence et sa dispersion. Je me doute déjà du vainqueur pareil pour la fiabilité. Quoiqu'il en soit mes cartes servo, traction et TCO utilisent déjà du CAN, une cinquantaine de nœuds en tout.
Le sans fil oui mais là où il est utile
J'ai des nrf24 sur les cartes de mes radiateurs. Parce que je ne me voyais pas passer des fils dans toute la maison pour les piloter. Sur le réseau c'est différent c'est déjà plein de fils partout et c'est pas un rj11 de plus qui va changer la donne. Par contre pour les poste de conduite je pensais effectivement utiliser des nrf24. Mais je n'en prévois que trois.
Je n'ai pas fait des tests de performance avec les nrf24 mais pourquoi pas, pas seulement le débit mais egalement la latence et sa dispersion. Je me doute déjà du vainqueur
pareil pour la fiabilité. Quoiqu'il en soit mes cartes servo, traction et TCO utilisent déjà du CAN, une cinquantaine de nœuds en tout. Le sans fil oui mais là où il est utile
1362
Vos projets / Re : Un Arduino par module....ou pas.
« le: février 02, 2015, 08:59:07 pm »
Pas de pb avec le sans fil tu y vas un peu fort Hubert. J'aurais plutôt dit l'inverse : le filaire est plus fiable.
La solution des modules sans fil à base de nrf24 est séduisantes. Mais c'est aussi un domaine où tous les emmerdements restent à decouvrir. Le CAN a le mérite d'être largement déployé industriellement.
tu y vas un peu fort Hubert. J'aurais plutôt dit l'inverse : le filaire est plus fiable. La solution des modules sans fil à base de nrf24 est séduisantes. Mais c'est aussi un domaine où tous les emmerdements restent à decouvrir
. Le CAN a le mérite d'être largement déployé industriellement.
1363
Vos projets / Re : Un Arduino par module....ou pas.
« le: février 02, 2015, 05:01:39 pm »
Je penche pour un article structuré
1364
Débuter / Re : problème de driver
« le: février 02, 2015, 01:51:59 pm »
Hubert,
Cette panne ne serait pas liée au fait d'avoir branché un moteur pas-à-pas directement dessus ?
Cette panne ne serait pas liée au fait d'avoir branché un moteur pas-à-pas directement dessus ?
1365
Vos projets / Re : Un Arduino par module....ou pas.
« le: février 02, 2015, 01:36:31 pm »
Autre chose : sur ton schéma, tu diffuses du 5V à partir d'une alim centrale à tous les Arduino. Ce 5V va être bruité car tu vas avoir des longs fils. Ça risque de provoquer des reset intempestifs des Arduino. Il vaut mieux diffuser une tension plus élevée et utiliser une régulation en tension sur l'Arduino.