Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

[bobyAndCo]

@Laurent,

Comme je te l'ai déjà dit, toutes ces interrogations et cogitations sont intéressante mais ne doivent pas être traitées ici. Le but de ce fil est de présenter le concept et surtout sa mise en œuvre "simple" pour un public peu ou pas expérimenté.

Il est certains que ce concept poussé plus avant doit permettre des choses assez puissantes mais c'est vraiment un autre sujet (un autre fil pourquoi pas ?). Et comme je te le disais également, je dois rester concentré sur celui-ci pour faire fonctionner cette première étape à coup sûr avant d'aller plus loin.

Christophe

[laurentr]

Pas de soucis

Peux tu nous parler des capteurs ponctuels que tu utilises ( ref, type, mise en œuvre)? ( et comme tu les as testé les écueils desquels il faut se prémunir...)

Ltr

[bobyAndCo]

Pas de soucis

Peux tu nous parler des capteurs ponctuels que tu utilises ( ref, type, mise en œuvre)? ( et comme tu les as testé les écueils desquels il faut se prémunir...)

Ltr

Les capteurs ponctuels à infra rouge que j’ai retenus.

Comme beaucoup sans doute, j’ai essayé plein de choses. Les capteurs à effets Hall ont eu longtemps ma préférence, ils sont discrets, économiques et très fiables. Leur principal inconvénient est qu’il faut fixer un aimant sous la loco et parfois cela pose des problèmes. Et puis, certains finissent par se décrocher provoquant parfois des dégâts.

J’ai découvert les TCRT5000 (seuls) il y a déjà un petit moment, je les ai testés dans différentes configurations. Ca fonctionnait bien mais c’était très délicats de trouver le bon réglage.

Et puis j’ai testé des modules chinois tout assemblés qui me coutaient moins cher que le seul TCRT5000, très simples à régler avec la résistance variable et surtout très fiables.



Voici un exemple sur Ali à 1,07€ : https://fr.aliexpress.com/item/32703689686.html

J’en suis vraiment très content et je n’ai depuis plus aucun problème. Ceux-ci fonctionnent à une fréquence (38 Khz je crois) qui les rend vraiment insensibles aux éclairages extérieurs communs (lumière du jour, ampoules...).

Je recommande de placer à l’avant de la locomotive un petit papier blanc autocollant qui accélère considérablement la vitesse de détection.

[bobyAndCo]

Présentation du programme.

Pour découvrir le programme commençons par un rapide survol global.

Voici la liste des différents fichiers dans lesquels sont réparties les différentes parties du programme.

Le cœur du programme est contenu dans les fichiers Node.h et Node.cpp. J’ai choisi Node (nœud en français) car le satellite autonome est avant tout un nœud dans une chaine, un ensemble d’autres satellites avec lesquels il échange et collabore.

Node est un peu le « cœur de satellite ». Les membres de la classe Node représentent "en logiciel" les objets physique du canton. Ce même fichier contient une autre classe NodePeriph qui elle "symbolise" de manière épurée les satellites "voisins". L'instance de la classe Node initialise huit instances de la classe NodePeriph, nombre maximal de satellites "voisins" possible dans cette version.

Les fichiers Aig, Loco, Sensor, Signal sont les éléments logiciels qui figurent ces objets physiques et les méthodes, les actions de ces objets physiques.

Railcom est à rapprocher de ces fichiers en ce sens qu’il apporte des informations sur l’éventuelle présence d’une locomotive sur le canton en nous précisant l’adresse de cette locomotive.

Settings contient tout ce qui est nécessaire au paramétrage du satellite. C’est par l’intermédiaire des fonctions contenues dans ce fichier que l’on lit ou que l'on sauvegarde le fichier json où sont regroupées les données de paramétrage.

Discovery contient tous les éléments logiciels qui permettent le processus de découverte présenté précédemment. Discovery est activé par défaut au premier lancement de la carte satellite. Une fois la configuration globale réalisée, on doit désactiver le mode Discovery pour activer GestionReseau qui maintenant restera activé en permanence jusqu’à ce que l’on active à nouveau Discovery pour une extension par exemple.

GestionReseau contient toutes les fonctions qui vont analyser tous les messages CAN reçus par le satellite. Je rappelle que chaque satellite envoie toutes les 100 milli secondes environ les principales données le concernant : présence d’une locomotive et adresse de cette locomotive, position de ses aiguille, cantons à partir desquels il est possible d’accéder.

Nous verrons plus tard en détail comment chaque satellite traite les données reçues des autres pour adapter son propre comportement.

Enfin, le fichier main.cpp qui correspond au fichier « .ino » sous l’IDE Arduino. C’est le premier fichier appelé au lancement du microcontrôleur. On y trouve principalement les instances des objets logiciels et aussi l’activation des méthodes de ces différents objets logiciels.

Je ne m’attarderai pas sur les fichiers Wifi, WebHandler, Config et même Can qui ne sont que des programmes « utilitaires » permettant le fonctionnement de l’ensemble.

Voilà pour la présentation globale des fichiers du programme. Nous verrons dans les postes suivants le fonctionnement détaillé des principaux d’entre eux.

[dmskd]

Bonjour,

J’ai découvert les TCRT5000 (seuls) il y a déjà un petit moment, je les ai testés dans différentes configurations. Ca fonctionnait bien mais c’était très délicats de trouver le bon réglage.

Et puis j’ai testé des modules chinois tout assemblés qui me coutaient moins cher que le seul TCRT5000, très simples à régler avec la résistance variable et surtout très fiables.

Comment installes-tu ces capteurs ? Sous la voie ? Sous la plateforme ?
Tu es en HO ?

Je ne suis pas le seul intéressé mais il y a beaucoup de timides

On n'est pas timides, mais c'est du haut niveau !

[bobyAndCo]

On n'est pas timides, mais c'est du haut niveau !

Merci de plonger dans le bain ! Non ce n'est pas du haut niveau. C'est nouveau, assez différents dans les concepts des approches "classiques" mais facile à appréhender. Posez toutes les questions que vous voulez, aucune n'est idiote et mettra en avant un manque de précision de mon côté que je m'empresserai de corriger pour les autres. Donc tu vois, en plus tu feras une BA.

Comment installes-tu ces capteurs ? Sous la voie ? Sous la plateforme ?
Tu es en HO ?

Oui je suis en HO, mon plateau fait 6mm d'épaisseur, je positionne sous le plateau.

Question suivante   

[Dominique]

En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.
Connectés à un satellite V1 ils envoient les messages Can (seulement quelques pins dans les satellites autonomes).

https://forum.locoduino.org/index.php?topic=290.msg12026#msg12026

[bobyAndCo]

@dmskd N'hésite pas à présenter ton réseau (ou ton projet). Où tu en es dans la construction. Si tu es intéressé par ce principe et j'essayerais de te donner les meilleurs renseignements.

Eventuellement aussi d'autres conseils comme pour le câblage pour éviter des erreurs.

Christophe

[bobyAndCo]

En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.
Connectés à un satellite V1 ils envoient les messages Can (seulement quelques pins dans les satellites autonomes).

https://forum.locoduino.org/index.php?topic=290.msg12026#msg12026

Merci Dominique pour cette info.

Il faudra aussi qu'un jour on fasse un corpus des meilleurs solutions. Je n'hésite pas à avancer meilleures car nous les avons testées éprouvées alors autant en faire profiter d'autres plutôt que de les laisser galérer 

[laurentr]

Avec Locoduino on apprend tous les jours. 

Il faut être curieux et rigoureux. Parfois cela demande du temps avant de s'approprier des concepts, des syntaxes mais c est point de passage.
Locoduino essaye d être le plus didactique possible sur de nombreux sujets. ( et y contribuera encore longtemps!)

Pour te rassurer Dominique (@dmskd) , je ne suis pas toujours "confort" avec toutes les rubriques. J'y vais donc par étapes.( J explore aussi beaucoup c est vrai!)

Comme le propose Christophe ici point besoin de connaitre tous les détails puisque le premier niveau de compréhension et d identifier le fonctionnement global du satellite autonome et d'en faire le rapprochement avec son réseau ferroviaire. ( et ses besoins)

La mise en place de ce projet se veut rapide, répétitive en étant très innovante.

Pour rassurer, Christophe qui utilise comme moi PlateformIO comme IDE ( interface soft comme l'IDE ARDUINO) produit un fichier main.cpp.

Sous IDE ARDUINO il faut le renommer en main.ino

Cela sera le seul "truc" compliqué à faire pour être sous cet IDE et utiliser les fichiers fournis.

Laurent

[dmskd]

En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.

Sur mon réseau (N) j'utilise des capteurs équivalents (ITR9909) mais pour les positionner au raz des traverses, ça oblige à en couper 2.
Dans les parties cachées (il n'y en a que là) ce n'est pas gênant, mais ailleurs ce serait quand même un peu voyant.

@bobyAndCo
Pour la programmation et les cartes électroniques, je me débrouille.
Le haut niveau est pour moi le suivi des trains sur le réseau par le gestionnaire.
Mon petit réseau actuel est exploité entièrement en manuel (à partir d'une tablette), à part quelques sécurités dans la gare cachée.
Mais le futur réseau est beaucoup plus ambitieux, et je n'échapperai pas à me triturer le cerveau pour comprendre comment gérer la circulation des trains.
Ce qui m'inquiète c'est la multiplication des cartes électroniques : cartes RailCom, cartes pour décoder les messages Railcom, cartes de détection de présence... Quand il y a beaucoup de cantons, ça fait beaucoup de cartes.

Tu veux des questions, en voici une.
Je comprends que la détection RailCom génère un signal relativement faible. Je suppose que les cartes doivent être proches de la voie.

[laurentr]

Bonsoir Christophe

Je commence a mieux comprendre/identifier certains de mécanismes sous jacents que tu as mis en œuvre et que tu nous détailleras très bientôt.

J ai bien vu que l utilisation de capteur optique dans leur rôle de postions en capteur ponctuel représente un net avantage de mis en ouvre simple et léger

Je pense que je proposerai et vous présenterai bientôt un redesign du circuit de détection RC incluant également les éléments traitants ces capteurs ponctuels tels que nous les a présenté Dominique ( source G BUNZA). Ceci facilitera fortement la mise en place de la solution satellites autonomes.

J ai une question d'ordre fonctionnel:

Dans le réseau de démo sur la TJS:
Si nous avons un train en mouvement sur C5 vers A1 qui est déviée alors le bloc agira et lorsque la loco se présentera dans C5 sur le capteur ponctuel d entrée, le ralentissement va s'opérer jusqu' à l arrivée sur le capteur de "sortie" proche de A1 ou s arrêtera le convoi (machine en tête ou en queue)

Toutefois que se passe t il si un engin est détecté sur la TJS alors que
le train n'est pas encore dans C5: ici le train sur la TJS ( et surement en mouvement entre  C2 ou C0) sera détecté par le capteur RAILCOM de C5, ne va t on pas alors arrêter le mauvais convoi? ( puisque c est l adresse de ce train qui va être associée au canton C5 car FIFO? ( First IN dans le satellite)
le train est dans C5: on a alors un imbroglio pour la lecture de l adresse RAILCOM car 2 engins ne peuvent emmètre en  même temps ( tout cela est peut être très théorique mais me semble être des combinaisons plausibles d'enchainements de différents mouvements).
J ose en déduire qu' il faut donc en principe que le train dans C5 s'identifie avant qu'une possible détection émettant sur la TJS ne vienne placer son adresse dans le satellite.
ou bien que la solution peut reposer sur une détection de présence seule (par conso de courant)  et non railcom sur une aiguille en pointe?

Peut être as tu d autres mécanismes que tu dévoileras très bientôt aussi lorsque tu vas aborder le fonctionnement des briques du programme.

Une autre question plus d ordre implémentation à propos de la frequence d émission des messages que tu as mis sur 100 millis sec. ( 0.1 secondes)
Cette frequence parait très rapide de prime abord et on pourrait penser que 1/4 de seconde ( par exemple donc 0.25 secondes)  semblerait suffisant. Aussi pourquoi aller "aussi vite" dans l envoi des trames toutes les 100millis sec? N'émet t'on pas que ce qui as changé?

Je réserve (déjà) d autres questions pour le traitement en enfilade des aiguilles pour la suite...

Ltr

[laurentr]

Bonsoir Dominique

Je vais essayer de t apporter aussi quelques retour d'info sur les sujets que tu soulèves ( retours d expériences en la matière)

Tu soulignes que le nombre de cartes augmentent et que leur localisation a de l'importance dont celle liée à la détection RAILCOM du fait des faibles tensions présentes dans le processus d émission.

Un bit 0 ou un 1 Railcom dure 4us ( 4 micro secondes). Il repose sur le déstockage de l énergie emmagasinée précédemment au CUTOUT pour opérer.

La norme a codifié cela ( RCN210 et RCN 217) et encodé les messages par soucis de sécurisation des contenus ( encodage 4-8).

Il est envident que plus un signal et propre et mieux il est traité sinon il n'est pas jugé conforme et est donc ignoré. ( donc préférer des distances courtes et non parasitées reste toujours préférables mais on est pas à qq dizaines de cm prêt ici) ( c est moins le cas par exemple avec des servos plus sensibles au parasitage)

Les satellites autonomes reposent sur une mise en place distribuée (c est à dire proche des zones à équiper) comme l étaient les satellites V1 de LOCODUINO.

Le PCB présenté par Christophe regroupe le "cœur" et se voit complété d' un circuit dédié pour la détection ( je devrais dire de circuits pour les détections).
L'approche segmentée présente plusieurs avantages:
répartition par blocs fonctionnels
réparation/substitution en cas de panne de façon simplifiée
optimisation des placements

Je l ai annoncé dans mon post précèdent je proposerai un new design pour la carte gérant les détections.

On peut surement envisager d autres formes de PCB mais cela reste un redesign initial du travail de Christophe.
Je veux bien y contribuer fortement puisque je suis plus à l'aise avec le design des PCB que le C++! 

Personnellement je vois plutôt une implémentation du bus I2C pour la gestion des signaux que des 95HC... mais c est la une affaire de gouts
Cet usage pourrait être étendu aux commandes pour les servos ou des relais de commutation des pointes de cœur voir à des retours d info de capteurs externes via ce canal...
Les possibilités ne manquent pas et j ai déjà eu l occasion d en discuter avec Christophe qui rappelons le encore propose une solution novatrice et déjà éprouvée.
Le nombre d I/O sur l ESP 32 et leur utilisation rend l'utilisation du bus I2C comme une alternative à leur extension de façon simple.

Pour ma part j aime bien la SX1509 très polyvalente mais un PCA9685 offre aussi son lot de possibilités!

pour le SX1509: https://learn.sparkfun.com/tutorials/sx1509-io-expander-breakout-hookup-guide/all
ex PCA9685: https://www.aranacorp.com/fr/utilisation-dun-module-pca9685-avec-arduino/



Vivement la suite!

Ltr

[bobyAndCo]

Je comprends que la détection RailCom génère un signal relativement faible. Je suppose que les cartes doivent être proches de la voie.

@Dominique. Laurent répond bien à ta question. Moins on a de câbles sur le réseau et mieux c'est. Moins on a de longueur pour chaque câble et mieux. C'est l'un des énormes avantages des satellites où toute la rétrosignalisation et les commandes sont véhiculées dans un bus (CAN) très peu sensible aux interférences et qui plus est, dans le cas des satellites autonomes transitent dans du câble RJ45 torsadé et blindé.

[bobyAndCo]

Je l ai annoncé dans mon post précèdent je proposerai un new design pour la carte gérant les détections.

Personnellement je vois plutôt une implémentation du bus I2C pour la gestion des signaux que des 95HC... mais c est la une affaire de gouts
Cet usage pourrait être étendu aux commandes pour les servos ou des relais de commutation des pointes de cœur voir à des retours d info de capteurs externes via ce canal...
Les possibilités ne manquent pas et j ai déjà eu l occasion d en discuter avec Christophe qui rappelons le encore propose une solution novatrice et déjà éprouvée.
Le nombre d I/O sur l ESP 32 et leur utilisation rend l'utilisation du bus I2C comme une alternative à leur extension de façon simple.

Bonjour Laurent,

Tout d'abord, merci de t'impliquer comme tu le fais dans ce projet. Effectivement, les domaines où nous sommes respéctivement le plus à l'aise sont complémentaires et ça peut contribuer beaucoup à faire avancer ce projet.

Pour la mesure de courant sur chaque satellite ce serait un énorme plus de pouvoir intégrer un ACS-712 (ou autre). Je rappelle que c'est toi qui avait déjà émis l'idée il y a quelques temps. Si l'on avance dans cette direction, il faut aussi mettre Railcom sur la même carte ? Cela fait un peu de monde, mais malheureusement (et ça répond aussi à Dominique) c'est nécessaire. Nous souhaitons des solutions toujours plus performantes qui rendent les solutions complexes. On n'a pas tous ces problèmes quand on pilote à vue et a la mano !

Pour l'I2C, pourquoi pas. J'ai mis des 74HC595 pour la simplification. Sur les signaux, il faudra aussi une capacité de "décoder" l'I2C. Simplicité ? Cout ?