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.
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.
Sauf que... dans la famille ESP32 certains sont plus costauds que d'autres... et les miens sont trop larges pour les cartes d'extension ! (d'un pas "dupont", 2.5mm, argh...)
Les ESP32 je ferai autrement par contre les shield (il y en a deux) je ne m'en servirai jamais mais je n'aime pas jeter. Aux dernière nouvelles, ils seraient prévus pour des ESP Vroom (?).
Si quelqu'un en à l'usage, je les cède pour rien, juste le prix du timbre pour l'expédition.
Asservissement de vitesse pour les nuls... saison 2
Résumé de la saison 1 : c'est fou, la FCEM ça se capte avec juste un bout de fil, deux résistances et un code minimaliste ! Et encore... la saison 2 démontrera que le code peut être encore plus simpliste. Voire carrément remplacé par un circuit RC ? Ce qui donnerait corps à la remarque de Msport :
Citer
Les 15kmh, oui, mais c'est du DCC et les décodeurs comportent une compensation de charge qui est manifestement basée sur la mesure de la FCEM ...
Alors SAISON 2 : Un code élaboré pourra-il produire EN SITUATION un véritable asservissement, plus "intelligent" que de la compensation de charge ?
En résumé : un peu oui et beaucoup non (en attendant la saison 3 !!)
Du côté du non : Il y a deux conditions à une régulation réellement opérante : une mesure fiable de la grandeur et des corrections très fréquentes.
Première condition : l'horreur. Avec deux principaux problèmes : - un bruit de fond relativement important, cad l'impossibilité de mesurer une "erreur" (entre demande et constat) plus faible que le bruit de fond moyen - ET les transitoires aux frontières électriques, cad lorsque la motrice est à cheval (mais il faut aussi raisonner "train", car la motrice une fois passée tout wagon générera du bruit de fond en maintenant la section sous tension ...)
Seconde condition : confiés à un nano qui a d'autres choses à faire, 100 cycles de mesures à la seconde ne sont pas loin du maximum possible. Malheureusement, 10millisecondes, du point de vue d'une boucle d'asservissement, c'est une éternité.
Autant du fait de la première que de la deuxième condition, pas la peine de penser à une correction "dérivée"... il faudra donc faire avec une proportionnelle fantasque (capable d'un freinage brutal immédiatement après un grand coup de +) et une intégrale vite chatouilleuse.
Le but est tout de même de tirer le maximum de ces FCEM, puisqu'il est possible de mesurer "quelque chose" !
Améliorer la mesure ? On a deux approches possibles :
un filtrage logiciel "élaboré" sur les mesures elles-mêmes. Dans cette approche, mes expériences n'ont pas donné mieux que ce que propose Jean-Luc : la moyenne des quatre valeurs médianes dans un groupe de six.
aucun filtrage : on prend tout de qui arrive, sans précaution préalable, sans même de délai de coupure du courant traction avant mesure, mais on prend le maximum de mesures possible. Et on compte sur l'effet statistique.
Après moult essais, je n'ai pas su faire de différence sensible entre les deux approches (ce qui conforte à nouveau l'hypothèse de la compensation de charge DCC par rétroaction FCEM)
Peaufiner le code ? C'est ce qui peut faire la différence avec une compensation aveugle. Mais les contraintes inhérentes à la mesure sont toujours là, le code ne peut que tenter de différencier des situations pour apporter à chacune la réponse la plus appropriée. La complexification est presque sans limite. Mais deux exemples, deux situations très perturbées :
un train est détecté sur deux, ou plus, sections électriques : au milieu des mesures qui arrivent, lesquelles relèvent-elles d'un bruit de fond "wagons" ? Sachant qu'au démarrage, une motrice est tout d'abord vue comme du bruit de fond...
La correction proportionnelle devant être appliquée avec beaucoup de modération, comment régler la correction intégrale ? Si le convoi en marche lente "accroche" un point dur et s'arrête... l'intégrale doit très vite réagir mais si en réponse (tardive) le train "bondit", elle ne doit pas le stopper aussitôt mais le ralentir en délicatesse... les coefficients ne seront donc pas les mêmes.
Du côté du oui : Dans ces conditions, il y a un réel plus par rapport à une conduite par la PWM: une régularité d'horloge, la quasi certitude de ne plus avoir de train définitivement bloqué sur un point délicat, une vitesse identique loco à vide ou en traction, des accélérations et ralentissements sous contrôle ...mais un ralenti "au pas"... heu pas vraiment. Ou peut-être s'en approcher avec des conditions "labo" : une motrice très courte avec un max de roues au contact, lente car fortement démultipliée (donc grosse FCEM même à vitesse faible), une seule zone électrique, pas d'aiguilles, des grands rayons... là oui, et/ou avec en plus le renfort d'une électronique assez futée pour doper le signal mais pas le bruit de fond (la phase 3 !) ça doit pouvoir être plutôt sympa!
Alors voilà pour l'instant ce que ça donne chez moi. Avec trois "crans" : 15%, 11%, 8%. Sur ce dernier, on voit nettement, surtout si on tremble en même temps que l'image, que la régulation flirte avec la capacité à distinguer le signal du bruit de fond... résultat : 25kmh et pas moyen en l'état de faire mieux...
... en attendant la phase 3 ! Mais là, gros problème. Car si un code c'est, pour moi, un peu comme les sous-titre anglais d'un film : je comprends plus ou moins et quand c'est mon tour d'écrire, en insistant je finis par me faire comprendre. Mais un schéma électronique... ce coup, c'est un film avec des sous-titre en russe ! Quelqu'un aurait-il le temps et la gentillesse de me "traduire" ce schéma proposé par Jean-Luc ? Nécessaire et suffisant sauf erreur (de ma part !). J'ai approvisionné les ampli OP, révisé les différents types de montage (sans reconnaître celui-du schéma...), me manquera plus que l'impression de ne pas faire n'importe quoi !
Un énorme merci par avance au volontaire (pourvu que !)
Dans la laborieuse mise au point de mon asservissement de vitesse et pour m'éviter un téléversement chaque fois que je bouge un paramètre, j'aimerais utiliser la librairie CommandInterpreter et juste adapter les moniteur.cpp moniteur.h de votre code AlimentationTraction. Or lorsque je charge ce dernier, autant les "strings" sont acceptés sans souci, autant je n'arrive pas à passer un "int". J'ai essayé des tas de syntaxe, dont la plus évidente (par exemple : gi 20)... rien à faire. La lecture de la valeur est OK, les messages d'instruction OK, mais la modif de la valeur... non. La solution est bien sûr dans la librairie elle-même... mais le code est hélas trop abscons pour mon niveau ! Pouvez vous me dire ce qu'il faut écrire ?
Le post de Trimarco est l'occasion de rapporter une expérience très positive concernant l'I2C.
Il s'agissait comme envisagé plus haut de lire des détecteurs, donc à priori en grand nombre et (donc) au travers d'un multiplexage. Moyennant une organisation par zones de proximité, pour des distances de fil raisonnables (jusque 60cm dans ma configuration), le tout marche PARFAITEMENT. Tant côté bus I2C que capteurs (décidément idéaux) : jamais de fausse détection (sauf main qui traîne malencontreusement mais du point de vue du détecteur ça n'est pas une fausse détection...), le besoin néanmoins d'un filtrage logiciel sur les détections faibles, ce qui n'est pas un inconvénient car c'est fort utile : la latence qui en résulte à la retombée de la détection se traduit par une distance de dégagement avant, par exemple, la libération d'un canton quitté. Un traitement logiciel juste un peu évolué permet même que cette distance soit indépendante de la vitesse du convoi ; pour cela le gestionnaire doit rétro-signaler régulièrement au détecteur la vitesse de "l'objet" détecté. Ainsi, lorsque c'est un attelage qui est au surplomb, condition de détection la plus défavorable, une vitesse très faible entraînant une latence importante l'attelage reste détecté. (une précision : les capteurs communiquent avec le multiplexeur et ce dernier à un arduino "satellite" par I2C / la communication satellites-gestionnaire est assurée par bus CAN)
Chaque système a ses limites (voir notamment si ceci serait transposable au HO car les "trous" entre wagons sont plus conséquents qu'en N...) mais dans mon cas je n'ai plus aucun problème. Et la satisfaction de toujours voir les feux changer lorsqu'un canton vient de se libérer, de façon constante quelque soit la vitesse, le sens traction ou refoulement.
La nécessité des résistances de tirage... en effet mais on ne risque pas de l'oublier car sans, on obtient une lecture "random". De ci de là, j'avais lu qu'il fallait mettre des 10kOhms... ça marche tout aussi bien qu'avec des 4,7 qui "tirent" pourtant plus fort bien sûr.
Seconde expérience positive : l'affichage par le gestionnaire sur écrans OLEDs, avec une seule adresse et donc également au travers d'un multiplexeur. Mais là les distances sont encore plus courtes. En tous cas, aucun souci !
Mais je revenais pour une correction. Car après avoir mieux regardé la vidéo, et jusqu'à la fin (avec la ligne droite), ça fait pas plus que +/- du 5kmh !!! Eh bé !
C'est magnifique ! Et je devine que ni 5 ni 10 wagons derrière ne changeraient le résultat. Pas possible sans un asservissement n'est ce pas ? Merci pour vos deux réponses, je me demandais où placer la barre.
Mais si je calcule : 15kmh, à l'échelle ça fait 2.5 cm seconde. Or si tes coupons sont comme il semble des coupons de 10cm, ça correspond au +/- 4 secondes par coupon ?
Car les 15kmh je pense que ça sera possible (sans pont de diode qui bouffe la plage de basses vitesse, ça c'est confirmé) mais moins que 15kmh... je suis à peu près certain que je ne pourrai pas : en dessous plus rien ne sort du moteur, sinon par bouffées entre deux hoquets (je parle toujours d'un mode "mesure" sans bouclage d'asservissement).
Et cette vidéo, c'est à quelle fréquence de PWM car j'ai - vraiment - de plus en plus besoin de comprendre. En effet, après ce n'ième rappel sur les "bonnes ondes" et un peu penaud d'avoir tant insisté sur mes 40Hz, je me suis vu reparti à refaire quelques essais "à la base", avec une PWM native de MEGA2560 (la 5 pour tout dire). Et si je suis incapable de refaire la théorie, je peux au moins rapporter les faits :
- aux paramètres par défaut : constat immédiat d'un retard à l'allumage rédhibitoire, assorti évidemment de l'impossibilité de "vrais" ralentis. Par exemple : là où je paramètre les PWM de "décollage" sur 50, en moyenne (selon la loco... puis variable selon son humeur, ce qu'elle tire, si elle démarre en courbe ou non, la direction du vent etc), c'est vers PMW 100 qu'elle se décidait à démarrer ("bondir" serait plus exact), feux prés-allumés pendant les longues secondes de la montée des crans de la programmation habituelle pour un démarrage progressif. Et je parle d'ampoules bulbe, pas de LEDs, ce qui donne idée du courant de court-circuit. Si ça ça ne fait pas chauffer le néodyme !!
- Alors qu'en ajoutant juste : TCCR3B = TCCR3B & B11111000 | B00000101; pour une PWM à 30Hz, je reviens immédiatement à la souplesse de mes 40Hz maison.
Le cran 1 du DCC me laisse dont admiratif et rêveur. Mais le DCC c'est comme un univers parallèle pour moi. Sauf que dans ce cas je ne doute pas (vraiment) que ça existe, alors j'ai deux questions pour Dominique :
- cran 1 (sur 128), cad correspondant à une PWM de 2 ?? (sur 255 donc). Avec un moteur supraconducteur sur paliers fluides ?? En tous cas avec une mécanique top forme sinon c'est pas possible !! (et sans rien à tracter ? car j'ai lu et je veux bien le croire qu'on ne peut pas embarquer l'asservissement dans une loco DCC mais c'est peut-être faux)
- et donc cran1 : véritable cran1 ou est-ce le cran 1 après un talon ? (l'équivalent de ma PWM de décollage)
Du coup le sujet m'a intéressé. Et m'intéressera peut-être quand je me demanderai ce qui reste à régler ! Mais sur du N ça risque d'être un peu décevant non ? Comme mon wagon témoin qui maintenant est allumé en marche arrière... style clignotant. Mais les deux côtés en même temps. Car quand je lis lis condensateur et supercondensateur, on est forcément au moins dans du HO ?
Très content, ça se présente très bien. D'abord, moteur bloqué ça fait bien FCEM zéro. C'était facile à vérifier puisqu'il pouvait y avoir un petit doute.
Mais surtout : le pont de diode est coulant. Sur un essai très basique certes, une seule loco, uniquement de la mesure (pas de rétro-action), FCEM prise directement sur un pont, la fourchette de valeurs est plus favorable qu'espéré : +/-500 (sur 1023) à 200kmh vitesse vraie rapportée à l'échelle, +/- 20, assez constant, à 15kmh, ce qui laisse une bonne latitude de régulation. L'allure footing (soutenu!) doit être possible, faut-il qu'à basse vitesse la régulation ne pompe pas.
L'alternative avec deux lectures analogiques, je testerai sérieusement ; je suis bien d'accord que
Citer
C'est sans doute mieux
En attendant, 15kmh ça me semble déjà un ralenti impressionnant ? Est-ce au dessus de ce qui est couramment obtenu ?
Grosse campagne d'essais en perspective pour optimiser tout ça. Et d'abord, chic, du tricotage au plafond, entre deux tréteaux de 75cm.
Pour ce qui est de modelleisenbahn, je connais... quasiment depuis que je suis venu au monde (le monde arduino !) et les "quelques dizaines de kHz" c'était précisément une citation ! (Apparemment mes aimants ne sont pas néodyme !)
Et concernant ces relais qui ne devraient pas trop stresser, je ne dirai pas le contraire mais la question n'est pas celle là... c'est celle de MON stress !
pour répondre à msport : vitesse moteur 0 => FCEM=0, oui, mais vitesse 0 MOTEUR BLOQUE et FCEM=0... je n'ai pas fait attention et je ne me souviens pas ; je ferai le test car j'ai l'impression que si ça n'est pas le cas ça invaliderait toute autre mesure, c'est bien ça ?
et à Jean-Luc : Le pont de diode est une évolution en cours d'essais ; précédemment OUT1 était lu sur A0 et OUT sur A1 (un "if" dans le code lisant la bonne pin, fonction de la (*)polarisation). Petit inconvénient, il faut 2x plus de fils et pins mais gros avantage : aucun seuil. (*) Le pont H vient du choix de départ de n'employer aucun relai... mauvais vécu professionnel
Le pont de résistances : faute de compétences pour mettre en œuvre ton principe, je peux au moins les recalibrer si nécessaire pour diminuer le puissance consommée. Les essais in-vivo vont me renseigner.
Citer
Je ne comprends pas le choix d'une fréquence de 40Hz
mais moi pas vraiment ! elle provient historiquement de l'idée de tester un pca9685 et ses 16 PWM pour régler par la bande le problème du non synchronisme des timers Arduino. Or ces modules produisent des PWM 60Hz... et ça a parfaitement fonctionné, je n'ai pas été chercher plus loin. Jusqu'à, sans refaire toute l'histoire, que je découvre qu'à 40Hz les locos "respiraient" mieux, meilleurs ralentis, plus rapides à PWM égale. Peu importe, 60Hz ou 40Hz la question est la même : comment est-il possible que ça fonctionne alors que "quelques dizaines de kHz" sont recommandées... ()
Bonjour, Merci pour vos réponses ! C'est très stimulant, par les questions que ça ouvre et parce que je ne suis donc pas engagé dans une impasse. Elles pointent aussi le fait que tout est dans tout ! Et c'est vrai qu'il y a loin entre des essais avec une loco sur banc (d'autant que dans mon cas, c'est indécent j'en rougis, banc veut dire loco sur le toit roues en l'air avec deux pins Dupont qui les lui chatouillent) et une loco au pas sur ses rails.
Point par point, je me permets de nouvelles questions/remarques sur vos observations.
Citer
MSPORT - Reste à vérifier qu'en fonction de la fréquence PWM adoptée, la rapidité de la conversion A/D (...) Mais j'imagine que cela a été pris en compte.
Eh bien non ! et j'avoue même car c'est grave que ça ne m'avait même pas effleuré ! Mais juste pour ceux qui n'auraient pas acheté ma précédente aventure, co-éditée avec Trimarco, je précise que j'ai refilé au CPU le soin de fabriquer sur mesure mes PWM (nativement synchrones donc... on partait d'un sujet sur ce problème) et à la fréquence très étonnante de 40Hz, optimum vérifié et revérifié. Cad 10 à 20 fois plus faibles que les PWM hardware... elles même encore au moins 10 fois trop faible par rapport à ce qui est universellement préconisé (il y a la un grand mystère que j'aimerais beaucoup qu'on m'aide à lever... il n'est pas possible qu'on parle de la même chose !) Donc, partant d'essais OK faits avec des PWM à 490Hz, je ne redoute pas la transposition sur des ponts travaillant à priori sous 40Hz.
Citer
MSPORT - Un petit test à faire : un moteur bloqué (pas trop longtemps, je n'assume aucune responsabilité)
Le moteur avait déjà survécu au jeu du foulard, je ne chercherai donc pas de tiers responsable. Le but était de tester le coef de l'intégrale mais je crois que vous pensiez à autre chose ?
Citer
Jean-Luc - La grosse différence, au sens physique, est que dans le schéma que j'utilise la FCEM ne produit presque pas de courant (résistance de 100kΩ) et la tension reste aussi stable que possible pendant les mesures
Oui, gros souci. Ce qui est à redouter dans les résultats de l'expérimentation en réel, c'est une différence, à l'arrivée (des signaux tension reçus) suivant les sections électriques du fait de... contacts plus ou moins francs, incidence des longueurs de fils, différence de potentiel entre masses, parasitages etc... et pour en effacer le plus possible j'avais visé un courant relativement élevé (mauvais raisonnement?). Mais je peux facilement si vous le conseillez modifier le pont diviseur pour abaisser le courant sans modifier le ratio diviseur, cad la tension récupérée ? (Pensez vous que pour le meilleur compromis pour la justesse des mesure soit de faire les relevés aux points d'alimentation rails ou plutôt sur les bornes des boosters ?)
Citer
Jean-Luc - Ici elle dissipe dans 1,22 kΩ. Et donc cette charge va contribuer à ralentir la loco pendant la mesure. Je ne sais pas si ça peut poser un problème
Je ne crois pas, parce qu'on parle de 400 micro-secondes et 4% du temps total ce qui rend déjà le ralentissement imperceptible et que si on parle de la marche "visible", sous 12V mes locos (N) vont toutes tellement trop vite qu'elles subissent un paramètre de bridage PWM individualisé. Il y en a donc sous le pied. Elles supporteraient d'ailleurs aussi d'être alimentées sous un peu plus que 12V, je ne pense donc pas qu'il puisse y avoir un problème.
Citer
Jean-Luc - La seconde différence est que lorsque la FCEM est inférieure au seuil de la diode, elle devient nulle du point de vue de la mesure. J'ai peur que le système ne soit pas capable de faire un ralenti très bas
Alors ça c'est ennuyeux ! d'autant que ça n'est pas une mais deux diodes que le courant de FCEM doit vaincre successivement n'est ce pas ? Pour le ralenti au pas, ou même "petit footing" qui m'aurait bien convenu, j'ai peur que ça soit cuit et que les essais le confirment. Mais il y a une parade car le pont de diode est facultatif, il a pour intérêt essentiel de n'avoir plus besoin que d'une pin quelque soit le sens de marche. La décision sera facile à prendre. D'autant qu'un réseau c'est, quoi?, au minimum 20 sections électriques et qu'il faudra de toutes façons multiplexer les entrées. (à moins que ça ne soit une nouvelle source de perturbation de la mesure ? à priori je ne pense pas)
Citer
Jean-Luc - Pour protéger l'entrée analogique, tu peux mettre une diode schottky entre A0 et 5V de manière à ce que si la tension sur A0 dépasse 5V + seuil, ça part dans l'alimentation au lieu de casser l'entrée A0
Ne pouvant être complètement rassuré sur le fait que ça n'arrive pas, c'est donc ce que je vais faire, je découvre, merci pour le conseil.
deux ans (déjà!) de découverte et initiation et me voilà devant une difficulté redoutée : l'asservissement de la vitesse. Pourtant indispensable car la conduite par la PWM c'est vraiment pas ça pour des ralentis ou des arrêts maîtrisés, trop de paramètres bougent, décidément impossibles à encoder en dur.
Le vrai problème, pour moi, c'est d'être sérieusement/gravement crasse pour tout ce qui touche à l'électronique/la théorie des moteurs, respectivement. Impossible malgré du temps passé dessus de comprendre les schémas proposés par Jean-Luc dans le fil "un arduino par canton" ; j'ai renoncé à m'y frotter. J'aurais donc bien besoin d'un coup de main pour aboutir, quand-même, alors voilà où j'en suis.
A partir de cette page http://www.train35.fr/commande_moteur.html et par tâtonnements j'ai pu arriver à ce montage, qui à l'air de marcher bien qu'on dise que "ce qui est trop simple ne peux pas marcher" (et ce qui est trop compliqué ne marche jamais) voilà le schéma :
LA question est : est-ce que c'est viable ?? ensuite il y a d'autres question de détails, mais importants, est-ce que par exemple le Nano est protégé contre des risques imprévus ? Le calage un peu au pif du pont diviseur permet de ne pas dépasser 2.5V sur l'entrée analogique ce qui laisse une bonne plage de valeurs pour les calculs de correction mais est-ce que une zener par exemple ? ou un optocoupleur ?
Il est possible que l'expérience intéresse d'autres que moi ? je joins deux sketchs, le premier qui permet de tester la FCEM mesurée en fonction de la PWM appliquée à la motrice, le second qui à l'inverse conduit celle-ci par une consigne de FCEM et ajuste la PWM en conséquence. (précision : je dois à Jean-Luc les variables de temps et la logique de filtrage des valeurs mesurées, merci à lui car c'est beaucoup de temps de gagné et surtout quelque chose que sans oscillo je n'aurais probablement pas pu déterminer)
Je me languis de vos conseils, avant de me lancer à passer de la paillasse à la planche ! bien cordialement, merci par avance
... ouf pas de sortie grillée ! (sur ma Teensy3.5 dont les pins RX/TX alternatifs sont brochés au recto, ce qui est heureux !) j'avais ce matin déjà une réponse de Pierre Molinaro, dont cette version courte : Réponse courte : il faut que la patte STBY du MCP2562 soit à 0, sinon, par défaut, une résistance de tirage interne au MCP2562 la met au niveau haut, qui est le mode standby.
En cherchant les occurrences "teensy" sur le forum, je m'aperçois qu'elles sont très peu nombreuses et presque chaque fois très furtives, sans fil réellement dédié. Je vais réfléchir s'il y a matière à en créer un, par exemple une fois que j'aurai bien en main la librairie CAN Teensy citée ici par Jean-Luc mais comme on est très loin du sujet originel c'est une info qui ne profitera pas comme elle pourrait. Façon de compléter par des aspects pratiques l'article du site sur ces cartes Teensy.
(et vivement l'opus 3 des articles ACAN !) Merci pour ces interventions cordialement
Voir les contributions
car j'ai - vraiment - de plus en plus besoin de comprendre. 
!
