LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: MBP le décembre 22, 2022, 03:08:58 pm
-
Bonjour Dominique,
Je n'arrivai pas à déverser le programme dans mon Arduino car je n'avais pas chargé correctement la bibliothèque de l'afficheur TM1637. Mais ça y est, j'ai trouvé la bonne manip dans l'article de Loco-Revue 858 sur le sujet.
Maintenant je vais connecter les composants et voir ce que ça donne, je vous dirai.
Mon idée serait de faire un mesureur de vitesse "portatif" dans un petit boitier sur pile que je poserai le long de la voie. Je l'adapterai au HO et à la longueur entre capteur d'environ 20 cm.
-
Bonjour Mr MBP ?
J'ai fabriqué celui-ci, qui fonctionne toujours
https://dcc-arduino.weebly.com/scale-speedometer.html
-
Bonjour,
C'est le même principe que celui de l'article, mais bien plus professionnel, bravo Marcel !
Une précision : dans mon réseau j'utilise 2 détecteurs d'occupation consécutifs pour faire des mesures de vitesse.
Avec un seul logiciel dans le gestionnaire, je peux mesurer les vitesses un peu partout sur le réseau et étalonner les vitesses de mes locos.
-
Bonjour,
Me revoilà avec mes problèmes de débutant !
J'ai chargé le programme sur l'Arduino Uno que j'avais déjà utilisée et ça marche !
Mais quand je veux le charger sur l'Ardunino Pro Mini via l'adaptateur USB, ça bloque avec un message d'erreur qui dit :
avrude:ser_open(): can't open device "\\.COM3" : le fichier spécifié est introuvable.
Quelle bêtise ai-je pu faire ? L'Arduino Pro Mini semble connecté car la led rouge s'allume.
(http://)
-
pour compléter voici une photo du Pro Mini avec l'adaptateur USB.
-
A première vue les connexions coté adaptateur USB ne correspondent pas à celles du Pro-mini !!!
il faudrait :
Arduino <-> adaptateur
Rx <-> Tx
Tx <-> RX
Gnd <-> GND
5V <-> 5V
DTR <-> DTR
exemple à adapter à vos composants :
https://www.b4x.com/android/forum/attachments/conexao-ftdi-arduino-pro-mini-jpg.53557/ (https://www.b4x.com/android/forum/attachments/conexao-ftdi-arduino-pro-mini-jpg.53557/)
-
Effectivement, le connecteur broche à broche (de la photo) n'est pas utilisable puisque les sorties ne sont pas au même endroit que les entrées (voir appellation des broches).
La véritable question est aussi : comment quelqu'un qui se classe en "débutant" peut avoir été amené à utiliser une carte Pro-mini plutôt réservée à ceux qui ont déjà de l'expérience ? Serait-ce le mot PRO qui attire les novices ? Ou bien est-ce que notre site ne les a pas assez alertés sur ce sujet ? En plus, cette carte a été retirée par Arduino !!!
Première solution : refaire le câblage entre les deux cartes en respectant les appellations des broches (comme dit Dominique). Si la carte Pro-mini n'a pas été endommagée, cela devrait fonctionner.
-
J'avoue que j'ai bêtement branché les 2 modules face à face sans plus réfléchir...
En corrigeant le branchement comme indiqué par Dominique, j'ai le même message d'erreur, que j'ai aussi si je ne branche rien du tout sur la prise USB de l'ordinateur. J'ai peut-être bien détruit l'Arduino ou le module USB, ou les 2 ! Je n'ai plus qu'à repasser une commande et recommencer...
Pourquoi avoir utilisé une Pro Mini étant très débutant ? Parce que c'est la carte utilisée dans le montage présenté par Dominique, et elle me plaisait bien par son petit volume vu ce que je veux faire. Mais comme dit plus haut, j'ai d'abord fait fonctionner le programme sur une Arduino Uno, et ça marchait.
Si la Pro Mini n'est plus d'actualité, auriez-vous un autre type de carte à me conseiller, aussi de toutes petites dimensions ?
Et merci de votre aide. :)
-
Si la Pro Mini n'est plus d'actualité, auriez-vous un autre type de carte à me conseiller, aussi de toutes petites dimensions ?
Et merci de votre aide. :)
Un Arduino Nano qui est identique au Pro-mini mais avec sa propre interface USB.
-
...
Pourquoi avoir utilisé une Pro Mini étant très débutant ? Parce que c'est la carte utilisée dans le montage présenté par Dominique, et elle me plaisait bien par son petit volume vu ce que je veux faire. Mais comme dit plus haut, j'ai d'abord fait fonctionner le programme sur une Arduino Uno, et ça marchait.
Si la Pro Mini n'est plus d'actualité, auriez-vous un autre type de carte à me conseiller, aussi de toutes petites dimensions ?
Nous avons donc une part de responsabilité ! Beaucoup d'articles que j'écris sont pour les débutants, donc je ne vais jamais les inciter à utiliser une carte (moins chère certes) mais qui nécessite du matériel supplémentaire et des connaissances pour la mettre en oeuvre. La carte Nano est plus simple à utiliser que la carte Pro-Mini car elle a l'interface USB incluse. Donc, c'est la même chose que la carte Uno en taille plus réduite, et à prix légèrement moins cher. Il faut aussi se rappeler qu'une carte Pro-Mini et une interface USB revient au même prix (sinon plus) qu'une carte Nano.
Avant de déduire que la carte Pro est flinguée, il faut essayer de faire quelques tests et essayer de programmer Blink avec cette carte. Si cela fonctionne, c'est que la carte est opérationnelle. Mais à condition aussi que l'IDE ait été bien réglé. Essayez et dites-nous ce que vous obtenez (ou observez). Pour vous aider, il nous faudra un maximum de détails sur la façon dont vous opérez pour programmer Blink sur la carte. ;)
-
Avec blink, j'ai le même problème, voir photo du message d'erreur.
J'ai testé blink sur l'Arduino Uno et ça marche. Je précise que j'ai sélectionné dans Outils Type de carte la bonne carte à chaque fois (Uno ou Pro Mini)
Quand je branche la Pro Mini j'ai sur l'USB une led rouge fixe, et sur la Pro Mini une led rouge fixe au centre et une led rouge clignotante (mais pas aux fréquences aléatoire du blink) à l'extrémité.
Je crois que la Nano sera une bonne solution !
Ce n'est pas vous les responsables, c'est bien moi ! J'ai soudé la Pro Mini et l'USB broche à broche sans me poser de questions, d'autant que les 2 étaient vendues ensembles dans le même sachet, j'ai pensé qu'ils étaient faits l'un pour l'autre ! Il y a au moins un point commun avec l'électronique analogique, les erreurs de câblage peuvent être mortelles ;D
-
Désolé pour cette déconvenue.
De mon coté j'ai re-testé un couple Pro-mini + adaptateur utilisé pour faire un proto de satellite V1 (avec bus Can) et ça marche toujours.
Donc c'est le modèle soit de Pro-mini, soit d'adaptateur qui n'est pas le même que les miens (Ah ces chinois !!!), soit le votre a prix un coup et ne fonctionne plus.
A noter que mon adaptateur est reglé sur 3,3V mais ca fonctionne aussi avec un pro-mini en 5V.
Et je reconnais que le pro-mini de l'article 173 n'est pas identique à ceux que j'utilise ici. Donc il faut toujours vérifier et adapter si necessaire.
Mais celui de l'article 173 doit fonctionner car les articles sont toujours testés avant d'être publiés.
-
...
Ce n'est pas vous les responsables, c'est bien moi ! J'ai soudé la Pro Mini et l'USB broche à broche sans me poser de questions, d'autant que les 2 étaient vendues ensembles dans le même sachet, j'ai pensé qu'ils étaient faits l'un pour l'autre ! Il y a au moins un point commun avec l'électronique analogique, les erreurs de câblage peuvent être mortelles ;D
Etant tous les deux administrateurs du site, nous venons d'échanger Dominique (auteur de l'article) et moi à ce sujet. La figure de câblage et les explications partent du principe que les broches sont dans le même ordre entre Arduino et interface USB. Comme en plus c'est le cas chez Dominique, il ne pouvait pas se douter que ça puisse parfois être autrement. Comme par exemple pour l'interface montrée en photo dans l'article. Une mise à jour s'impose pour donner plus d'explications et prévenir le lecteur que les broches doivent être reliées selon les noms et pas selon l'ordre dans lequel elles se présentent.
Nous faisons le maximum pour que les montages de nos articles soient reproductibles par les lecteurs. Parfois, des choses peuvent nous échapper (un circuit différent par exemple) et nous nous en rendons compte par les retours des lecteurs. Dans ce cas, nous adaptons ou corrigeons nos articles.
Du coup, nous allons faire le maximum pour vous aider à vous en sortir. On y réfléchit et on revient vers vous. ;)
-
Pourriez-vous dans un premier temps refaire une photo montrant comment vous branchez l'interface USB et l'Arduino ? (même genre que celle que vous avez postée plus haut).
Ensuite, lancez l'IDE et reliez la carte, puis faites une photo du menu Outils montrant le port COM utilisé (comme la photo ci-dessous).
Cela nous permettra de comprendre certaines choses.
-
En examinant les pro-mini que j'ai chez moi, je vois qu'il y a une broche marquée "DTR" à une extrémité, contrairement à l'image de mon article. Elle correspond à la broche DTR de l'adaptateur et tout va bien dans ce cas.
C'est ceux que l'on trouve couramment sur Ebay, mais c'est plus cher maintenant qu'à l'époque de l'article !
-
Bonjour,
Je crois que la nuit porte conseil car ce matin, ça va mieux.
Je vous joins les photos du câblage et la copie d'écran port.
Quand je verse le programme dans la Mini pro, cette fois je n'ai plus de message d'erreur, d'abord avec le blink puis avec le compteur de vitesse.
Je viens de connecter les détecteurs et l'afficheur, et ça marche !
La led centrale du Pro Mini reste allumée, pas gênant ça me fera un voyant.
-
Salut MBP,
Donc si j'ai bien compris, tu as réussi à téléverser le programme Blink (éventuellement en modifiant les fréquences d'allumage pour être certain qu'on n'est pas sur un Blink résiduel) et tu as réussi aussi à téléverser le programme de mesure de vitesse. Donc maintenant, ça marche complètement ?
Voilà un joyeux Noël en perspective !
-
C'est bien ça :)
Mes mauvaises connexions initiales n'auront pas été destructrices.
Joyeux Noël aussi !
-
Bravo 🎊 et Bon Noël 🎅
-
Cela fait plaisir quand on arrive à aider quelqu'un à faire fonctionner son montage !
Ce qu'il faut en retenir : avant de jeter une carte qu'on pense foutue, il faut faire quelques tests et un des meilleurs est d'essayer de la programmer avec Blink qu'on a au préalable modifié avec son rythme de clignotement. Si la LED de la carte clignote avec le rythme voulu, c'est bon signe...
Dans le cas présent, le mauvais montage n'a pas eu de conséquences (OUF) mais si la carte avait été une 3,3V, il aurait été destructeur de mettre sur une de ses broches du 5V.
Là, c'est la trêve des confiseurs, mais promis, juré : on va modifier l'article pour bien spécifier le branchement à faire entre Arduino et interface USB. N'est-ce pas Dominique ? ;)
-
Là, c'est la trêve des confiseurs, mais promis, juré : on va modifier l'article pour bien spécifier le branchement à faire entre Arduino et interface USB. N'est-ce pas Dominique ? ;)
C'est fait ;D ;D
https://www.locoduino.org/spip.php?article173 (https://www.locoduino.org/spip.php?article173)
-
Bonjour,
C'est encore moi avec mes questions !
j'ai modifié le calcul de vitesse pour le HO (3132/1000 au lieu de 576/100) et j'ai ajusté la distance à l'écartement des capteurs de 203 mm. (valeur qui s'affiche au branchement du circuit)
ça fonctionne bien et ça me renvoie la vitesse conforme mais seulement pour des vitesses lentes. Pour des vitesses élevées, il affiche des valeurs basses et fausses. Le problème apparait pour des vitesses supérieures à 60 km/h environ soit un temps de passage entre les 2 capteurs inférieur à 1 seconde (en gros).
Dans tous les cas, on a le maintien de l'affichage pendant 5 secondes.
J'ai lu le programme mais je ne comprends pas. Faut-il une durée minimale pour un cycle de calcul ?
Je sèche...
-
Comme indiqué dans l’article, vous pouvez changer les types des variables en unsigned long (au lieu de Int) et utiliser microseconds() plutôt que millis().
La méthode de calcul vous est donnée à titre indicatif, il y en a sûrement une meilleures mieux adaptée à votre montage. C’est un bon terrain d’expérience avec Arduino. J’espère que vous publierez les résultats.
Bonne année 2023 à vous et vos proches.
-
D'accord je vais creuser tout ça.
Et oui bien sûr, je reviendrai vous présenter le résultat.
Bonne année aussi !
-
Bonjour,
Cette fois c'est bon ! Je suis passé en unsigned long au lieu de int et en micros au lieu de millis. la vitesse devient des microns par microsecondes au lieu des millimètres par millisecondes et ça donne de bonnes valeurs même à grande vitesse.
J'ai pu construire mon compteur portatif à placer en bord de voie sur un réseau. Voir les photos.
Merci pour votre aide. Tout ça me donne envie de continuer.
Je vais analyser le programme car je n'ai pas tout compris et même si ça marche j'aime bien comprendre !
-
Et bien Bravo 🍾🎉
Cette réalisation doit pouvoir intéresser du monde. Nous sommes toujours récompensés du temps passé sur nos articles quand un modéliste réussit son projet.
Amicalement
Dominique
-
Bonjour,
Cette fois c'est bon ! Je suis passé en unsigned long au lieu de int et en micros au lieu de millis.
Cela fonctionne et c'est super. Voici quelques explications si vous voulez comprendre.
La fonction millis() renvoie une valeur de type unsigned long c'est à dire 4 octets. Une valeur en int n'utilise que deux octets. Si vous mettez dans deux octets quelque chose qui en contient 4, il peut y avoir une perte d'information. C'est pourquoi quand on utilise la fonction millis(), il faut toujours prévoir de mettre le résultat dans une variable de type unsigned long.
Je pense qu'utiliser micros() à la place de millis() n'est pas ce qui a résolu le problème. Réessayez avec millis() maintenant que vous savez comment stocker le résultat et cela devrait fonctionner (à condition aussi d'appliquer la bonne formule de calcul de vitesse). La fonction micros() retourne également un unsigned long.
millis() retourne à zéro après 50 jours et micros() retourne à zéro après 70 minutes. Donc, si vous utilisez votre compteur de vitesse avec micros(), les résultats seront faux si la mesure a lieu 70 minutes après la mise en route du système (une séance de jeu peut durer plus d'une heure).
-
D’après la photo du projet, la distance entre les 2 capteurs est petite, donc le nombre de millisecondes entre les passages devant les capteurs est aussi petit ce qui peut induire un manque de précisions dans les calculs.
De mémoire, le programme d’origine utilise des unsigned long pour les mesures du temps et des unsigned int pour les calculs intermédiaires. C’est là que les imprécisions peuvent donner des mauvais résultats et surtout des valeurs ambiguës (hors des plages de mesure souhaitées).
-
Je viens effectivement de regarder ton programme et c'est vrai que tu manipules à la fois des unsigned long et des unsigned int dans tes calculs.
Sur certains cas particuliers, il doit se passer des choses bizarres.
-
Des choses bizarres ou des cas non prévus ?
Si T est un unsigned long et D un unsigned int, alors D=T retournera T modulo 65536.
Pour éviter les choses bizarres, il faut bien connaître les ordres de grandeur manipulés et tester les calculs sur un jeu d’essais comme dans l’informatique de grand papa 👨.
A l’époque de la rédaction de cet article j’ai du faire un petit programme du genre « calculette » pour tester mon jeu d’essai.
C’est une des façons de faire et il y en a pour tous les goûts. J’ai voulu éviter l’utilisation des float (je ne sais plus pourquoi) d’où les changements d’échelle avec ce facteur 100.
En parcourant Locoduino, le lecteur patient et assidu trouvera les bonnes pratiques qui lui conviennent.
Notre ami MBP a la curiosité qui va bien pour comprendre ce projet et qui profitera aux projets suivants plus ambitieux. Merci encore de partager ce succès, ce qui est en général assez rare, ce en quoi nous le remercions ;D
-
Un programme peut fonctionner dans 99,99 % des cas. Et puis un jour, tu tombes sur le 0,01 % qui reste et le résultat est erroné. Mais la première chose à laquelle tu penseras est que le microcontrôleur a dû capter un parasite. En fait non, c'est simplement une singularité due à des conversions qui se font mal. Ce n'est pas grave dans notre domaine : au tour suivant, la mesure redeviendra correcte car on repart dans le 99,99 % des cas. En aéronautique ou spatial, ce pourrait être une catastrophe. C'est pourquoi les programmeurs doivent avant tout déterminer les types de variables à utiliser et éviter de les mélanger dans des calculs pour éviter les problèmes. Je m'amusais bien quand je faisais un goto direct pôle nord sur A310 : le FMS plantait ! Mais ce point est une singularité ! Heureusement, avant d'arriver dans un cockpit, un logiciel est testé pendant des milliers d'heures.
Cela n'enlève rien à ton montage qui fonctionne.
-
Bonsoir,
Merci à vous, je suis content d'être ici car je ne m'en serais pas sorti tout seul.
Au départ j'avais fait un petit tableau Excel pour avoir la bonne valeur de vitesse selon le temps de passage. C'est comme ça que j'avais vu le problème d'affichage bizarre à grande vitesse.
J'ai rétabli les millis d'origine au lieu des micros et bien sûr j'ai rétabli ma distance entre capteurs de 203 mm et non plus de 203000 microns.
J'ai laissé les unsigned long (ligne 37 à 42 du programme).
Et ça marche toujours, il renvoie les bonnes valeurs quelle que soit la vitesse.
J'ai aussi testé la version micros après plus de 70 minutes (largement), je ne vois rien de bizarre. Le problème se poserait peut-être si le chrono revient à zéro pendant une détection ?
Ce qu'il faut bien comprendre c'est que pour un pur ignorant en langage informatique, c'est ardu. Avec le blink ou les feux routiers, j'avais réussi à comprendre chaque ligne du programme mais ici j'en suis loin, même si ce programme est classé facile. Mais je ne désespère pas :)
-
Merci à vous, je suis content d'être ici car je ne m'en serais pas sorti tout seul.
...
J'ai aussi testé la version micros après plus de 70 minutes (largement), je ne vois rien de bizarre. Le problème se poserait peut-être si le chrono revient à zéro pendant une détection ?
...
1- Si mais cela aurait pris plus de temps. L'avantage d'un forum, c'est qu'on peut poser une question à des gens qui sont un jour passés par le même problème.
2- C'est exactement cela.
Plus on avance en Arduino, plus les choses peuvent paraître difficiles. D'un autre côté, on a plus d'expérience pour chercher et trouver où se situe la solution d'un problème. Avec ce montage, vous avez appris qu'il faut (dans la mesure du possible) adapter le type de variable à ce que renvoie une fonction (ex avec millis()). Je suis certain que vous y serez plus vigilant maintenant.
Pour progresser, je vous conseille la lecture de ces deux articles de Jean-Luc :
https://www.locoduino.org/spip.php?article11
https://www.locoduino.org/spip.php?article102
Et dans votre progression, sachez prendre votre temps. Bon développement.
-
...
J'ai rétabli les millis d'origine au lieu des micros et bien sûr j'ai rétabli ma distance entre capteurs de 203 mm et non plus de 203000 microns.
J'ai laissé les unsigned long (ligne 37 à 42 du programme).
Et ça marche toujours, il renvoie les bonnes valeurs quelle que soit la vitesse.
...
Avec le blink ou les feux routiers, j'avais réussi à comprendre chaque ligne du programme mais ici j'en suis loin, même si ce programme est classé facile. Mais je ne désespère pas :)
1- Il n'y avait pas de raison que cela ne marche pas.
2- Effectivement, au vu de votre retour, je pense que l'article est plutôt pour confirmés (deux étoiles). Je laisse à son auteur le choix de le modifier en ce sens s'il partage cette opinion.
Il n'est pas toujours facile de dire si un article est d'un niveau débutant ou confirmé. L'espace de conversation à la suite d'un article est justement là pour que les lecteurs s'expriment et disent quelles difficultés ils ont rencontré. Et cela nous donnerait un retour sur ce que nous produisons.