16
Shields et Modules / Re : Module WIFI
« le: septembre 24, 2022, 09:59:17 am »
Notre forum semble pollué !!! ou peut-être même utilisé à d'autres fins !
Modérateurs à vos consoles !
Modérateurs à vos consoles !
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.
Pages: 1 [2]
17
Vos projets / Re : Wagon de mesure distance et vitesse
« le: août 13, 2022, 11:37:18 am »
Bonjour,
Pour charger les batteries, j'ai utilisé un stepdown convertisseur qui permet de générer du 9V, car il faut une tension supérieure à 7,2V pour alimenter les batteries montées en série (jusqu'à 8,4V). La résistance de 10 ohm limite le courant de charge.
J'ai utilisé le module suivant https://www.ebay.fr/itm/173252476101 qui a l'avantage proposer une gamme de tensions de sortie fixes sélectionnables par un pont de soudure ainsi qu'une tension ajustable par potentiomètre.
Mais les modules proposés par msport https://www.ebay.fr/itm/403755865933 ou https://www.ebay.fr/itm/403644631964 conviennent également très bien, une fois réglé en 9V de sortie..
Dans tous les cas, il faut derrière un module de régulation de charge fait pour 2 batteries en série afin d'équilibrer les charges des 2 batteries (fournisseurs en France) :
https://www.ebay.fr/itm/334291536926
https://www.ebay.fr/itm/174288736062
Cette tension de 7,2V convient très bien pour alimenter l'Arduino nano dont le régulateur 5V fournira la tension d'alimentation des capteurs et de l'émetteur Bluetooth.
On pourrait également envisager de passer en 3,3V et n'alimenter qu'avec une seule batterie, mais je ne connais pas le comportement des capteurs à effet hall (faits pour fonctionner sous 5V) lorsqu'ils sont alimenté sous 3,3V.
Cordialement
PS: Quel type de wagon avez-vous l'intention d'utiliser ?
Pour charger les batteries, j'ai utilisé un stepdown convertisseur qui permet de générer du 9V, car il faut une tension supérieure à 7,2V pour alimenter les batteries montées en série (jusqu'à 8,4V). La résistance de 10 ohm limite le courant de charge.
J'ai utilisé le module suivant https://www.ebay.fr/itm/173252476101 qui a l'avantage proposer une gamme de tensions de sortie fixes sélectionnables par un pont de soudure ainsi qu'une tension ajustable par potentiomètre.
Mais les modules proposés par msport https://www.ebay.fr/itm/403755865933 ou https://www.ebay.fr/itm/403644631964 conviennent également très bien, une fois réglé en 9V de sortie..
Dans tous les cas, il faut derrière un module de régulation de charge fait pour 2 batteries en série afin d'équilibrer les charges des 2 batteries (fournisseurs en France) :
https://www.ebay.fr/itm/334291536926
https://www.ebay.fr/itm/174288736062
Cette tension de 7,2V convient très bien pour alimenter l'Arduino nano dont le régulateur 5V fournira la tension d'alimentation des capteurs et de l'émetteur Bluetooth.
On pourrait également envisager de passer en 3,3V et n'alimenter qu'avec une seule batterie, mais je ne connais pas le comportement des capteurs à effet hall (faits pour fonctionner sous 5V) lorsqu'ils sont alimenté sous 3,3V.
Cordialement
PS: Quel type de wagon avez-vous l'intention d'utiliser ?
18
Vos projets / Re : Wagon de mesure distance et vitesse
« le: août 10, 2022, 09:15:13 pm »
Bonsoir,
Je viens de refaire un dessin, ci joint, de la position des capteurs. Il s'agit de la coupe longitudinale du wagon, au niveau de l'essieu portant les aimants.
J'ai positionné les fils de sortie des capteurs tels que je les ai implantés dans mon wagon, et surtout une cote angulaire de 135° mécaniques entre les capteurs. L'image est peut-être déformée dans l'article et les 135° mécaniques apparaissent mal.
J'espère que ce dessin est plus explicite.
135° mécaniques entre les capteurs correspond à 270° électrique. Ayant 2 paires de poles, 1 tour électrique ne fait que 180° mécaniques. Pour un tour d'essieu mécanique, chaque capteur voit passer de façon alternée deux poles nord et deux poles sud soit 2 tours électriques. Et donc 135° mécaniques correspondent à 270° électriques ou -90° électriques.
Cet angle de -90° électriques ou 135° mécaniques n'est pas critique au degré près, mais tout écart se traduira par une erreur de mesure plus ou moins "ondulée" sur un tour électrique. Une erreur sur cet angle se traduit par des signaux qui ne sont pas en quadrature. Les deux signaux sont en quadrature quand un signal est au maximum ou au minimum pendant que l'autre passe par zéro.
De même il faut que les aimants passent à la même distance des deux capteurs pour avoir des signaux de même amplitude.
Il est également possible d'utiliser un ESP32 au lieu due l'Arduino, ce qui permettrait, tout en utilisant l'IDE Arduino pour le développement, de disposer d'une liaison WIFI en plus du Bluetooth.
Cordialement
Je viens de refaire un dessin, ci joint, de la position des capteurs. Il s'agit de la coupe longitudinale du wagon, au niveau de l'essieu portant les aimants.
J'ai positionné les fils de sortie des capteurs tels que je les ai implantés dans mon wagon, et surtout une cote angulaire de 135° mécaniques entre les capteurs. L'image est peut-être déformée dans l'article et les 135° mécaniques apparaissent mal.
J'espère que ce dessin est plus explicite.
135° mécaniques entre les capteurs correspond à 270° électrique. Ayant 2 paires de poles, 1 tour électrique ne fait que 180° mécaniques. Pour un tour d'essieu mécanique, chaque capteur voit passer de façon alternée deux poles nord et deux poles sud soit 2 tours électriques. Et donc 135° mécaniques correspondent à 270° électriques ou -90° électriques.
Cet angle de -90° électriques ou 135° mécaniques n'est pas critique au degré près, mais tout écart se traduira par une erreur de mesure plus ou moins "ondulée" sur un tour électrique. Une erreur sur cet angle se traduit par des signaux qui ne sont pas en quadrature. Les deux signaux sont en quadrature quand un signal est au maximum ou au minimum pendant que l'autre passe par zéro.
De même il faut que les aimants passent à la même distance des deux capteurs pour avoir des signaux de même amplitude.
Il est également possible d'utiliser un ESP32 au lieu due l'Arduino, ce qui permettrait, tout en utilisant l'IDE Arduino pour le développement, de disposer d'une liaison WIFI en plus du Bluetooth.
Cordialement
19
Présentez vous ! / Re : Présentation pour les membres du forum
« le: décembre 08, 2021, 02:53:12 am »
Bienvenue Philippe
Je te souhaite beaucoup plaisir à développer des applications à base d'Arduino pour ton réseau.
C'est une tache de longue haleine à laquelle tu t'attaches, mais en y allant progressivement, ce sont des moments très gratifiants, au fur et à mesure des succès des diverses étapes.
Sur ce site tu trouveras toujours quelqu'un pour te conseiller et te mettre sur la bonne voie.
Serge
Je te souhaite beaucoup plaisir à développer des applications à base d'Arduino pour ton réseau.
C'est une tache de longue haleine à laquelle tu t'attaches, mais en y allant progressivement, ce sont des moments très gratifiants, au fur et à mesure des succès des diverses étapes.
Sur ce site tu trouveras toujours quelqu'un pour te conseiller et te mettre sur la bonne voie.
Serge
20
Vos projets / Re : Le futur TCO de mon réseau
« le: janvier 06, 2021, 12:35:37 am »
Bonsoir,
Si c'est la solution de l'Arduino piloté par un smartphone en Bluetooth qui est retenue, l'architecture pourrait être un TCO fait en processing tournant sur le smartphone, pilotant l'Arduino via le lien BT06.
Pour le TCO , Pierre (Pierre59) a développé un système à base de Processing, voir l'article https://www.locoduino.org/spip.php?article222 et suivant.
Pour l'implantation de Processing sur un smartphone Androïd et de la communication en Bluetooth voir la fin de l'article https://www.locoduino.org/spip.php?article259.
Je ne connais pas assez bien App Inventor pour savoir s'il est facile de développer un TCO, mais les graphiques du TCO en Processing par Pierre sont top. L'envoi de commandes et la réception de données via Bluetooth me semble facile.
Une fois la taille de l'écran du smartphone déterminée, la mise au point des graphiques et du programme se fait facilement sur un PC (y compris la communication série). Après, il suffit de transférer le tout sur le smartphone.
Si la taille du réseau est importante, un smartphone peut ne pas suffire et il faut penser à utiliser une tablette.
Ce n'est que mon humble avis, mais c'est la solution que je développerais.
Bonne Année à tous. Que 2021 soit bien meilleure que 2020 tant pour notre santé que pour nos petits trains et nos clubs.
Si c'est la solution de l'Arduino piloté par un smartphone en Bluetooth qui est retenue, l'architecture pourrait être un TCO fait en processing tournant sur le smartphone, pilotant l'Arduino via le lien BT06.
Pour le TCO , Pierre (Pierre59) a développé un système à base de Processing, voir l'article https://www.locoduino.org/spip.php?article222 et suivant.
Pour l'implantation de Processing sur un smartphone Androïd et de la communication en Bluetooth voir la fin de l'article https://www.locoduino.org/spip.php?article259.
Je ne connais pas assez bien App Inventor pour savoir s'il est facile de développer un TCO, mais les graphiques du TCO en Processing par Pierre sont top. L'envoi de commandes et la réception de données via Bluetooth me semble facile.
Une fois la taille de l'écran du smartphone déterminée, la mise au point des graphiques et du programme se fait facilement sur un PC (y compris la communication série). Après, il suffit de transférer le tout sur le smartphone.
Si la taille du réseau est importante, un smartphone peut ne pas suffire et il faut penser à utiliser une tablette.
Ce n'est que mon humble avis, mais c'est la solution que je développerais.
Bonne Année à tous. Que 2021 soit bien meilleure que 2020 tant pour notre santé que pour nos petits trains et nos clubs.
21
Présentez vous ! / Re : automatisation pont tournant jouef
« le: décembre 23, 2020, 03:44:07 pm »
Bonjour,
Cela semble être un beau projet.
Quelques photos est schémas seraient les bienvenus pour nous mettre l'eau à la bouche.
Serge
Cela semble être un beau projet.
Quelques photos est schémas seraient les bienvenus pour nous mettre l'eau à la bouche.
Serge
22
Le logiciel DCC++ / Re : Cohabitation DCCpp et Adafruit sur UNO
« le: avril 25, 2020, 11:55:59 am »
Bonjour,
En essayant de faire appel à de vieux souvenirs de programmeur, il me semble que la réservation dynamique de mémoire peut être pleine de surprises.
La fonction malloc() permet de réserver, lors de l’exécution du programme, de la mémoire par blocs. La mémoire réservée ne peut être que des adresses contiguës pour faciliter la gestion des tableaux et des structures de données par pointeurs.
La fonction de réservation dynamique de mémoire cale l'adresse de début du bloc créé sur un multiple entier de la longueur du bloc à créer. Ainsi un bloc de 512 octets ne commencera que sur une adresse en 0000H ou 0200H ou 0400H ou ....
La réservation de plusieurs blocs de tailles différentes peut amener à un gruyère de mémoire avec de nombreux trous perdus.
J'ai eu ce cas là en utilisant la bibliothèque Adafruit qui réserve, via malloc(), pour le buffer pour l'écran SDD1306, 64 x 128 bits soit 1ko.
Au départ, je créais d'abord le buffer tournant de la liaison série logicielle (SoftwareSerial.h). Un bloc de 128 octets était alors réservé. Ensuite, lorsque je réservais le buffer d'Adafruit , ce dernier était placé à partir de 0400H, ce qui correspond à la borne de 1ko suivante. Compte tenu de la taille mémoire de 2ko, il ne restait plus rien pour les affectations suivantes et le programme plantait lamentablement.
Le problème a été résolu lorsque j'ai changé l'ordre des affectations. Dans la fonction setup(), j'ai commencé par initialiser le buffer d'écran par Mydisplay.begin(SSD1306_SWITCHCAPVCC, 0x3C) suivi plus loin par l'initialisation de la liaison série logicielle BTSerial.begin(9600).
L'ordre des réservations de mémoire est important sur des micros controllers avec peu de mémoire.
Je te propose d'essayer de mettre l'instruction de réservation des buffers de l'écran (ecran.begin()) dans les premières lignes de setup() avant les autres réservations de mémoire telles que DCCpp.begin() et DCCpp.beginMain() ou autres .
Voila mon retour d'expérience sur ce genre de problèmes, si ça peut aider ...
Amitiés
Serge
En essayant de faire appel à de vieux souvenirs de programmeur, il me semble que la réservation dynamique de mémoire peut être pleine de surprises.
La fonction malloc() permet de réserver, lors de l’exécution du programme, de la mémoire par blocs. La mémoire réservée ne peut être que des adresses contiguës pour faciliter la gestion des tableaux et des structures de données par pointeurs.
La fonction de réservation dynamique de mémoire cale l'adresse de début du bloc créé sur un multiple entier de la longueur du bloc à créer. Ainsi un bloc de 512 octets ne commencera que sur une adresse en 0000H ou 0200H ou 0400H ou ....
La réservation de plusieurs blocs de tailles différentes peut amener à un gruyère de mémoire avec de nombreux trous perdus.
J'ai eu ce cas là en utilisant la bibliothèque Adafruit qui réserve, via malloc(), pour le buffer pour l'écran SDD1306, 64 x 128 bits soit 1ko.
Au départ, je créais d'abord le buffer tournant de la liaison série logicielle (SoftwareSerial.h). Un bloc de 128 octets était alors réservé. Ensuite, lorsque je réservais le buffer d'Adafruit , ce dernier était placé à partir de 0400H, ce qui correspond à la borne de 1ko suivante. Compte tenu de la taille mémoire de 2ko, il ne restait plus rien pour les affectations suivantes et le programme plantait lamentablement.
Le problème a été résolu lorsque j'ai changé l'ordre des affectations. Dans la fonction setup(), j'ai commencé par initialiser le buffer d'écran par Mydisplay.begin(SSD1306_SWITCHCAPVCC, 0x3C) suivi plus loin par l'initialisation de la liaison série logicielle BTSerial.begin(9600).
L'ordre des réservations de mémoire est important sur des micros controllers avec peu de mémoire.
Je te propose d'essayer de mettre l'instruction de réservation des buffers de l'écran (ecran.begin()) dans les premières lignes de setup() avant les autres réservations de mémoire telles que DCCpp.begin() et DCCpp.beginMain() ou autres .
Voila mon retour d'expérience sur ce genre de problèmes, si ça peut aider ...
Amitiés
Serge
23
Vos projets / Re : Wagon de mesure distance et vitesse
« le: décembre 13, 2019, 09:33:04 pm »
Bonsoir Denis,
Merci pour ton jugement sur ma présentation qui malheureusement a du être coupée en plusieurs posts la rendant plus difficile à lire.
Pour ce qui est de l'oscillo, je n'ai pas les moyens de me payer une de ces dernières merveilles à écran plat et analyse de protocoles. Il ne s'agit que de la récupération d'un vieux Tektro monochrome, à tube cathodique, mais qui permet de stocker les images sur disquettes 3"1/4. Par contre, j'ai développé sur Excel une macro qui relit un fichier de type HPGL généré par le scope et qui trace les graphes en couleur. Je peux ainsi obtenir les courbes sur PC. Le maillon faible de la chaîne est la disquette car tout repose sur un bon alignement des têtes de lecture tant dans le scope que dans le lecteur (portable en USB) du PC et, malheureusement, tout ça n'est pas trop fiable.
En C j'utilise la fonction atan2(y,x) qui fournit un résultat sur ]-PI,PI].
Pour ce qui est de la précision, j'ai étalonné la mesure sur une voie droite de 1 m de long. Sans toucher aux coefficients théoriques (diamètre des roue), la précision était <1 mm.
Pour ce qui est de la vitesse, l'être humain sous-estime les vitesses pour les petites échelles. Lorsque un train roule à 150km/h à l'échelle HO, l'observateur a l'impression qu'il se traîne, et pense que le wagon surestime les vitesses. Il n'est pas rare de voir un MOYSE rouler à 180 km/h en HO, ce qui déstabilise l’observateur.
Le Bluetooth vers le PC se fait via un port COM spécifique, un peu comme la liaison série IDE Arduino qui passe par l'USB. Les données qui arrivent par ce port sont alors traitées par un programme "Processing" ou par des macros Excel qui tracent les courbes correspondantes.
Bonsoir
Conchito
Merci pour ton jugement sur ma présentation qui malheureusement a du être coupée en plusieurs posts la rendant plus difficile à lire.
Pour ce qui est de l'oscillo, je n'ai pas les moyens de me payer une de ces dernières merveilles à écran plat et analyse de protocoles. Il ne s'agit que de la récupération d'un vieux Tektro monochrome, à tube cathodique, mais qui permet de stocker les images sur disquettes 3"1/4. Par contre, j'ai développé sur Excel une macro qui relit un fichier de type HPGL généré par le scope et qui trace les graphes en couleur. Je peux ainsi obtenir les courbes sur PC. Le maillon faible de la chaîne est la disquette car tout repose sur un bon alignement des têtes de lecture tant dans le scope que dans le lecteur (portable en USB) du PC et, malheureusement, tout ça n'est pas trop fiable.
En C j'utilise la fonction atan2(y,x) qui fournit un résultat sur ]-PI,PI].
Pour ce qui est de la précision, j'ai étalonné la mesure sur une voie droite de 1 m de long. Sans toucher aux coefficients théoriques (diamètre des roue), la précision était <1 mm.
Pour ce qui est de la vitesse, l'être humain sous-estime les vitesses pour les petites échelles. Lorsque un train roule à 150km/h à l'échelle HO, l'observateur a l'impression qu'il se traîne, et pense que le wagon surestime les vitesses. Il n'est pas rare de voir un MOYSE rouler à 180 km/h en HO, ce qui déstabilise l’observateur.
Le Bluetooth vers le PC se fait via un port COM spécifique, un peu comme la liaison série IDE Arduino qui passe par l'USB. Les données qui arrivent par ce port sont alors traitées par un programme "Processing" ou par des macros Excel qui tracent les courbes correspondantes.
Bonsoir
Conchito
24
Vos projets / Re : Wagon de mesure distance et vitesse
« le: décembre 11, 2019, 12:17:31 pm »
Bonjour,
Je suis content que ma réalisation suscite quelques réactions.
Pour répondre à nopxor
pi * diamètre_roue / nbre_top_par_tour, soit pour une roue de 11mm et 4 aimants sur la roue, une résolution de 8,6mm.
En utilisant deux capteurs en quadrature, pour les mêmes paramètres, j'obtiens une précision de l'ordre du mm(erreurs de positionnement des capteurs), mais j'obtiens aussi le signe du déplacement. Je peux ainsi soustraire les mm parcourus en marche arrière, facilitant l'ajustement de la position du wagon pour la mesure de distance exacte entre deux points.
Bien le bonjour
Conchito
Je suis content que ma réalisation suscite quelques réactions.
Pour répondre à nopxor
Citer
C'est un travail important certes, mais il eut été plus simple d'utiliser un seul capteur à effet Hall numérique.Effectivement c'est plus simple de compter les tours de roue, mais la résolution de mesure de distance n'aurait été que de :
Un simple aimant sur la périphérie de la roue de l'essieu comptabilise les tours de roue dont on connaît le diamètre, donc le périmètre et la distance parcourue s'obtient par une simple multiplication.
pi * diamètre_roue / nbre_top_par_tour, soit pour une roue de 11mm et 4 aimants sur la roue, une résolution de 8,6mm.
En utilisant deux capteurs en quadrature, pour les mêmes paramètres, j'obtiens une précision de l'ordre du mm(erreurs de positionnement des capteurs), mais j'obtiens aussi le signe du déplacement. Je peux ainsi soustraire les mm parcourus en marche arrière, facilitant l'ajustement de la position du wagon pour la mesure de distance exacte entre deux points.
Bien le bonjour
Conchito
25
Vos projets / Wagon de mesure distance et vitesse
« le: décembre 09, 2019, 07:50:28 pm »
Je vous propose la réalisation d'un wagon HO de mesure de la vitesse et de la distance parcourue.
Wagon odomètre-tachymètre en Bluetooth
Transformation d’un wagon de marchandises échelle HO pour mesurer, afficher et transmettre la distance parcourue et la vitesse de déplacement du wagon. La réception des données se fait sur une application pour smartphone Androïd développée en processing. Le cœur du système est un Arduino nano et fonctionne aussi bien en analogique qu’en digital.
Cahier des charges :
• Mesure de la position angulaire d’un essieu en utilisant des aimants et des capteurs à effet Hall analogiques.
• Traitement des mesures pour obtenir la distance totale parcourue.
• Dérivation et filtrage de la distance parcourue pour le calcul de la vitesse.
• Mise à l’échelle des mesures.
• Affichage des valeurs calculées sur l’écran du wagon et transmission en Bluetooth.
• Alimentation sur batterie et recharge de la batterie par les rails
• Remise à zéro de la distance parcourue par Bluetooth
• Sélection des unités d’affichage de la position et de la vitesse via Bluetooth.
• Réception et affichage des données par smartphone
La description de cette réalisation a été concrétisée sous la forme d'un article plus complet qui est plus lisible que les posts successifs sur ce fil. Aussi, afin de désencombrer ce fil, je supprime mes posts précédents et je vous invite à consulter https://www.locoduino.org/spip.php?article259
Wagon odomètre-tachymètre en Bluetooth
Transformation d’un wagon de marchandises échelle HO pour mesurer, afficher et transmettre la distance parcourue et la vitesse de déplacement du wagon. La réception des données se fait sur une application pour smartphone Androïd développée en processing. Le cœur du système est un Arduino nano et fonctionne aussi bien en analogique qu’en digital.
Cahier des charges :
• Mesure de la position angulaire d’un essieu en utilisant des aimants et des capteurs à effet Hall analogiques.
• Traitement des mesures pour obtenir la distance totale parcourue.
• Dérivation et filtrage de la distance parcourue pour le calcul de la vitesse.
• Mise à l’échelle des mesures.
• Affichage des valeurs calculées sur l’écran du wagon et transmission en Bluetooth.
• Alimentation sur batterie et recharge de la batterie par les rails
• Remise à zéro de la distance parcourue par Bluetooth
• Sélection des unités d’affichage de la position et de la vitesse via Bluetooth.
• Réception et affichage des données par smartphone
La description de cette réalisation a été concrétisée sous la forme d'un article plus complet qui est plus lisible que les posts successifs sur ce fil. Aussi, afin de désencombrer ce fil, je supprime mes posts précédents et je vous invite à consulter https://www.locoduino.org/spip.php?article259
Pages: 1 [2]