LOCODUINO
Parlons Arduino => Modélisation, Architectures logicielles et matérielles => Discussion démarrée par: patrick le décembre 23, 2016, 03:23:45 am
-
Sur la demande de Dominique, je vous présente mon projet en quelques lignes. Je pourrais en parler longuement, mais je veux avant tout vous donner l'idée générale.
En fait, je pourrais résumer mon projet en trois mots: machine à états. Chaque noeud est une machine à états qui reçoit des évènements, réagit en effectuant une action et renvoie un autre message au système. Jusque là, rien de bien sorcier...
Ensuite: le système est répartit entre plusieurs noeuds, ce qui permet de gérer suffisamment de code sans nécessiter l'utilisation d'un ordi ou un logiciel externe. Pour le moment, j'en suis environ à 1500/1600 lignes de code pour chaque arduino. Et c'est là tout l'avantage de ce système: de petites fonctionnalités un peu partout et finalement tout tient dans quelques arduinos.
Le système fonctionne grâce au CanBus configuré à 500kbit/s. Ce qui est rapide (si on fait le calcul, cela représente quasiment 4000 messages à la seconde). J'ai fait des tests à plus basse vitesse et il y a encore de la marge... Disons que je n'ai pas encore rencontré de situation qui nécessite cette vitesse aussi rapide.
Pour les noeuds: comme je l'ai déjà mentionné sur mon blog, le tout s'organise autour de 4 types de noeuds:
- le DCC, gestionnaire de la position des trains et de la topologie du réseau (rails). Il génère aussi les messages DCC.
- le LOCO, il contient le script de la loco. C'est lui qui va demander au système s'il peut aller de tel à tel canton, demander l'état de la signalisation au modules CANTON, etc...
- le CANTON, il a la responsabilité d'un canton (3 zones de détection) et de la signalisation (2 feux complexes)
- enfin, les autres noeuds: aiguillages, animations, etc...
Un exemple de fonctionnement: un train entre sur une zone, le canton le détecte et met à jour la signalisation. Celui-ci envoie l'info d'occupation au DCC qui sauvegarde la position et autorise la poursuite du script si rien ne s'y oppose. Le module train, une fois entré dans un canton, demande l'état de la signalisation et ajuste sa vitesse en fonction... etc...
A chaque fois, il s'agit d'évènement qui entraine une action puis une réaction (nouveau message...). Le secret: bien manager le principe de message/réponse de façon atomique, et ne pas envoyer plein de messages dans tous les sens et espérant que les noeuds pourront gérer le tout en parallèle... Mon premier prototype semblait "plus intelligent" mais je me retrouvais dans des situations de "dead lock" parce que deux messages attendaient deux réponses simultanées et le système perdait les pédales...
A part cela, mon réseau une fois équipé devrait compter une douzaine de cantons, mais pas tous avec signalisation complète. Certaines branches de manoeuvres n'en utilisant pas.
Voilà, difficile d'en dire plus, ou alors ce serait vraiment beaucoup plus...
Si vous avez des questions sur des détails bien précis, je pourrai essayer d'y répondre.
Au plaisir,
Patrick
-
Merci beaucoup Patrick,
Voilà un projet d'ensemble 100% Arduino comme on les aime, qui va en intéresser beaucoup sur Locoduino.
J'ai passé un moment sur ton blog hier soir et l'explication que tu donnes ici est très claire pour moi parce que j'imagine assez bien ce que font les nœuds, d'autant que tu nous décrits quelque chose que tu as réalisé et qui marche (c'est même une 2ème version).
Je t'encouragerais donc à continuer la description sur Locoduino si tu es d'accord.
Mais c'est Noël d'abord et je te souhaite de bonnes fêtes.
Cordialement
Dominique
-
Bonjour Patrick,
Tu dis :Chaque noeud est une machine à états qui reçoit des évènements, réagit en effectuant une action et renvoie un autre message au système qui est répartit entre plusieurs noeuds.
Cela sous-entend que tu n'as pas réalisé une modélisation centralisée de ton réseau comme le décrivent Jean-Luc, Pierre59 et DDEF dans cette partie du Forum.
Je suppose (en me trompant peut-être) que chaque noeud correspond à un canton et, dans ce noeud, la connexion aux noeuds adjacents est décrite quelque part pour permettre de suivre les trains et de gérer localement la signalisation.
Ta solution me semble originale et devrait intéresser un certain nombre de modélistes qui pensent aussi "mettre un Arduino par Canton".
Cordialement
Dominique
-
Salut,
En fait, oui et non... Le système global n'est pas vraiment centralisé, mais il reste que le module DCC est un peu le point central du système. Beaucoup de messages passent par ce module avant d'être re-dispatcher aux autres modules mais sans sauvegarder d'états particuliers... Aussi, il a la connaissance de toute la topologie du réseau. Il permet quasi-exclusivement de sauvegarder la position des locos ou manager les priorités entre les trains... Dans un sens, c'est un point central, mais il ne connait rien de la signalisation.
Les cantons, quant à eux, sont totalement autonomes. Dès qu'un évènement de zone est détecté, il est "broadcasté" à tous les autres modules cantons afin de mettre à jour la signalisation et au module DCC pour le suivi des trains. Bien évidemment, comme tu le mentionnes, chaque canton a connaissance de ses voisins. Cela évite une fois de plus de passer par le module DCC pour gérer la signalisation.
Pour résumer, je dirais qu'un point important est d'éviter de sauvegarder trop d'états, mais au contraire, d'envoyer des requêtes d'infos auprès des autres modules lorsque nécessaire. Cela augmente le trafic CanBus, mais l'ensemble du système est plus autonome et plus robuste face aux bugs (décalage entre réalité du réseau et états des sauvegardes dans les différents modules). Par exemple, un module Canton A sauvegarde les signaux dont il a le contrôle. Si un voisin B veut mettre à jour ses propres signaux, il lance une requête vers A pour lui demander la position d'un signal et récupère la réponse. DCC n'a aucune connaissance de cet échange.
Voilà, j'espère que cela vous éclaire un peu plus ;-)
Au plaisir, et bonnes fêtes!
Patrick
-
Bonjour Patrick,
Tu pourrais mettre ton lien dans ce fil, pour que ce soit facile d'y accéder ?
Par certains côtés, ça me rappelle la CS90 de JC (dans Loco Revue en 1990 ;)), mais en plus moderne.
Une question :
Tu gères avec le DCC. OK. Normal.
Mais serait-il envisageable de gérer avec une alimentation analogique quelconque ?
-
Bonjour Patrick,
Tes explications sont très claires, mais je te pose encore une question :
Si le canton gère la signalisation, mais pas la traction DCC, comment peux-tu imposer à une loco de respecter un R60 ou un RR30, ou un arrêt devant un sémaphore ?
Il faudrait que le canton puisse envoyer un message à la traction mais s'il ne connait pas le N° DCC de la loco, ce sera difficile !
Ou bien je n'ai pas assez de détails, car je pense que tu as dû le prévoir.
Amicalement
Dominique
-
Tu pourrais mettre ton lien dans ce fil, pour que ce soit facile d'y accéder ?
Par certains côtés, ça me rappelle la CS90 de JC (dans Loco Revue en 1990 ;)), mais en plus moderne.
http://jurasecondairen.blogspot.fr (http://jurasecondairen.blogspot.fr)
Ca vaut le coup de tout visiter !
-
Une question :
Tu gères avec le DCC. OK. Normal.
Mais serait-il envisageable de gérer avec une alimentation analogique quelconque ?
L'avantage du DCC dans ce cas-là est de centraliser la gestion des messages DCC dans un seul module. Je m'explique: avec l'analogique, il faut alimenter chaque canton au travers de chaque module canton... Du coup, on augmente le trafic de messages et la logique de communication. Cela s'éloigne du modèle que j'ai développé... Gérer la signalisation est faisable mais la traction, je ne suis pas sûr dans l'état. Bref, il faudrait y réfléchir sérieusement...
-
Si le canton gère la signalisation, mais pas la traction DCC, comment peux-tu imposer à une loco de respecter un R60 ou un RR30, ou un arrêt devant un sémaphore ?
Il faudrait que le canton puisse envoyer un message à la traction mais s'il ne connait pas le N° DCC de la loco, ce sera difficile !
Ou bien je n'ai pas assez de détails, car je pense que tu as dû le prévoir.
Je me rends compte que si je veux tout expliquer, il faudrait que j'écrive un diagramme d'états complet avec plus de 80 à 100 messages différents... Cela me prendrait un temps certain :( Je vais donc répondre aux questions au coup par coup... Désolé... Mais ce n'est pas perdu. J'ai le projet de rédiger un petit site web pour décrire complètement mon projet, mais cela reste encore une idée en l'air... En fait, tout le temps que je mets dans la rédaction ne va pas sur le projet. Des fois, je n'ai pas le courage de le faire et je préfère travailler sur mes Arduino ;)
Ceci étant dit, je retourne à ta question. Une idée du fil de messages (va-et-vient). N'oublie pas que je passe des paramètres dans les messages (par exemple, le loco id ou le zone id...):
- (canton) détection zone & mise à jour de la signalisation & envoi du message au dcc
- (dcc) gestion des positions des locos & envoi d'une requête de vitesse au canton
- (canton) envoi de la directive de vitesse à la loco
- (loco) en fonction de son script et de la signalisation, déduit la vitesse voulue & envoi de la directive au dcc
- (dcc) message DCC
Dans cet exemple, on peut voir que de nombreux messages sont impliqués dans cette résolution (le double en réalité). Et cela se multiplie très rapidement, d'où la grandeur du diagramme d'états... Chaque module a un diagramme d'environ une douzaine d'états, avec plusieurs états ré-entrant... Pour chaque message, il faut aussi considérer sa réponse (ou ACK) ce qui double quasiment le nombre. Etc...
J'espère que cela t'éclairera un peu plus.
Patrick
-
On a tous le même problème de gérer la rédaction "d'articles" et la programmation ;D
J'ai lu la quasi totalité de ton blog, qui mérite effectivement le détour...
Il y a de très bonnes choses, c'est sûr.
En fait, avec un Arduino par canton, c'est un peu comme si tu avais un objet C++ par canton, sauf que, là, l'objet, tu peux le tenir dans la main ! ;)
Je note avec bonheur qu'il n'y a finalement que peu de fils sous le plateau, puisque tous les liens sont dans le CAN.
La gestion de la signalisation est finalement totalement indépendante du DCC.
Au travers des messages que tu cites :
- (canton) détection zone & mise à jour de la signalisation & envoi du message au dcc
- (dcc) gestion des positions des locos & envoi d'une requête de vitesse au canton
- (canton) envoi de la directive de vitesse à la loco
- (loco) en fonction de son script et de la signalisation, déduit la vitesse voulue & envoi de la directive au dcc
- (dcc) message DCC
je remarque un certain mix entre la centralisation et la décentralisation.
Et je pense que, suivant la façon dont on voit les choses, on pourrait changer la programmation en augmentant la décentralisation.
1°) Le décodeur de la loco est du commerce (surtout en N, comme pas mal d'entre nous)
2°) On construit une centrale DCC dont le but est de générer un signal DCC à l'attention des locos, uniquement.
Deux actions possibles sur cette vitesse :
- le conducteur donne une vitesse de consigne (j'aimerais bien rouler à 100 km/h)
- le réseau lui envoie un ordre prioritaire (non, ici, tu ne dois pas dépasser le 30 km/h)
En fait, la centrale DCC n'a aucune raison de savoir où est le train. 8)
Et ce, d'autant plus qu'on va gérer les aiguilles, la signalisation, ... hors DCC, via le CAN.
3°) La gestion de l'occupation, de la signalisation, de la position des aiguilles n'a que faire de l'id DCC du train qu'elle gère.
Le seul qui doive connaitre l'id DCC du train, c'est l'Arduino qui a ce train sur le canton qu'il gère. 8)
C'est juste pour qu'il puisse dire à la centrale : mets le train n°3 à 30 km/h.
Et aussi, pour refiler ce n° DCC de train à l'Arduino qui gère le canton suivant.
Plus je réfléchis, moins je trouve d'arguments à la centralisation des informations.
Je suis presque certain qu'on peut tout décentraliser si on met un Arduino par canton.
A creuser. :-*
-
Il faut préciser que j'ai rassemblé le noeud DCC et la centrale DCC dans le même module. Mais on pourrait totalement mettre de côté la messagerie DCC/booster et utiliser une centrale comme le Zephyr que je possède. Ainsi, le module "central" serait un pont vers Loconet.
En fait, la centrale DCC n'a aucune raison de savoir où est le train. 8)
Hmmm... Pas tout à fait. Il te faut un point central pour résoudre les conflits et gérer les trajets (aiguillages)... Par exemple, deux locos demandent l'accès au même canton. Il faut pouvoir gérer les réservations sans propager de nouveaux messages CAN et que la commande reste "atomique". Si tu propages une nouvelle série de messages pour résoudre le conflit (demander où se trouve telle loco sur le réseau) tu risques de laisser passer l'évènement et de te retrouver dans une situation "en retard", les deux locos se retrouvant sur le même canton! etc... Ce n'est peut-être pas très clair, mais si tu essaies de faire le design de cette situation sur le papier, tu arriveras probablement à la même conclusion. En tout cas, tu as raison, cela mérite une petite réflexion...
Aussi, ça peut paraître étonnant, mais on pourrait supprimer totalement le booster central DCC, et mettre un mini booster sur chaque canton (transistor plus petit puisque seul une loco est alimentée). Et là, le seul équipement se résume aux modules cantons pour gérer les messages DCC! On diminue ainsi le trafic Can. C'est la suite de mon projet... Mais je veux d'abord finir et valider la première phase courante. Cela ne supprime pas non plus les noeuds Loco et potentiellement le noeud de résolution de conflits.
J'ai encore pas mal d'idées dans ma boite ;)
Patrick
-
Ah, je viens de te relire... Tu dis "centrale"... mais j'ai compris "noeud central"... Ok, tu as raison, la centrale pourrait être supprimée comme mentionné à la fin de mon précédent message...
-
Oui, j'ai bien mis "centrale DCC". C'est sûr.
Mais tu n'étais pas loin : je réfléchis à supprimer aussi le nœud central ::)
Autre idée, très importante pour moi : je propage le n° DCC de canton en canton, avec un canton d'avance.
Dit autrement, un canton peut être occupé "par une source", sans train dedans. Pour être précis "pas encore dedans".
Et, si tu gères comme ça, tu peux anticiper le cas de deux trains allant en sens contraire, y compris la gestion des signaux.
Autre chose :
Pourquoi veux-tu savoir où est la loco ayant le code DCC n°3 ?
Pas pour la signalisation, pas pour l'occupation des voies, pas pour gérer les itinéraires. Toutes ces questions sont globales :
Ex : Sémaphore si le canton suivant est occupé, ... par n'importe quel train.
On ne pourra peut être pas se passer complètement d'un peu de centralisation. Mais ça vaut le coup d'y réfléchir. :P
-
Autre idée, très importante pour moi : je propage le n° DCC de canton en canton, avec un canton d'avance.
Dit autrement, un canton peut être occupé "par une source", sans train dedans. Pour être précis "pas encore dedans".
Et, si tu gères comme ça, tu peux anticiper le cas de deux trains allant en sens contraire, y compris la gestion des signaux.
C'est ce que je fais dans le module central: un canton peut être libre, occupé ou réservé. A y réfléchir, c'est vrai que je pourrais pousser cette logique dans le canton et ne rien laisser dans le module central. Il faudrait que j'approfondisse l'idée.
Autre chose :
Pourquoi veux-tu savoir où est la loco ayant le code DCC n°3 ?
Pas pour la signalisation, pas pour l'occupation des voies, pas pour gérer les itinéraires. Toutes ces questions sont globales :
Ex : Sémaphore si le canton suivant est occupé, ... par n'importe quel train.
Hmmm... c'est surtout pour gérer les conflits. Mais en développant un peu plus loin l'idée précédente, il est probable de pouvoir supprimer cette info. Par élimination, elle ne doit plus être utile... Encore une fois, à approfondir...
Patrick
-
Je ne suis pas dépositaire de LA solution. Loin de là. Je ne sais pas où ça mène vraiment.
Mais ton système m'a fait réfléchir tout haut.
Bonne soirée.
-
Cela fait 7 années que Patrick travaille sur son réseau : son expérience est considérable !
Je n'ai pas autant d'expérience, loin s'en faut, mais la découpe différente des éléments de mon réseau, reliés en bus CAN permet aussi une vraie économie de messages.
J'ai prévu de le décrire, mais, Patrick a raison, si j'écris je ne programme pas et vice versa !
On en trouve des bouts sur Locoduino, plus sur mon site que je trouve maintenant trop moche (à refaire, donc encore écrire ...)
Mais cette discussion est interessante et enrichit bien ce sujet de l'Architecture.
Merci à tous.
-
Tu as raison.
Il faut laisser à Patrick le temps de développer sa solution. 7 ans d'expérience, c'est rare.
Et, en plus, sa solution fonctionne.
Encore plus rare !! ;D ;D
-
Disons que cela fait un certain temps que je m'amuse avec des Arduino, mais cela fait un peu plus d'un an que je travaille sur mon projet... Je ne me souviens plus trop du point de départ... 😊
-
J'ai bien réfléchi : on ne peut pas se passer d'une certaine centralisation, ne serait-ce que pour gérer les aiguilles et les itinéraires.
On ne peut pas, en effet, imaginer un Arduino par aiguille !! (surtout pour ma gare :D).
Bonne année !
-
Bonjour,
La première vidéo avec la signalisation fonctionnelle est arrivée. Encore une fois, la qualité laisse à désirer, mais vous comprendrez facilement de quoi il s'agit... http://jurasecondairen.blogspot.ca/2017/01/signalisation-automatique-la-premiere.html (http://jurasecondairen.blogspot.ca/2017/01/signalisation-automatique-la-premiere.html)
Au plaisir,
Patrick
-
Bonjour Patrick,
Déjà, ça marche ! Un bon point (on se croirait à l'école ;) )
La vidéo est claire à ce sujet. On devrait d'ailleurs s'en inspirer pour des articles.
Évidemment, on attend que tous les cantons soient équipés !! ;D
Le réseau est assez simple, mais donner tous les feux, y compris RR et autres, liés à la position des trains et des aiguilles, c'est déjà un bel exploit que pas mal de gens aimeraient pouvoir faire. J'ai bon espoir.
Bon courage !
Denis
-
Déjà, ça marche ! Un bon point (on se croirait à l'école ;) )
Je le prends ;)
Évidemment, on attend que tous les cantons soient équipés !! ;D
J'y travaille... mais c'est assez long d'installer tout le câblage! ;)
Patrick
-
Voilà un projet très intéressant, bravo et surtout prend ton temps pour que ca marche du premier coup.
Le découpage fonctionnel autour du bus CAN est très sain, mais je ne comprends pas encore tres bien l'architecture globale.
Mais la qualité de réalisation des circuits ne laisse pas de doute sur une vision claire et complète de Patrick.
Bon courage
Dominique
-
Vous vouliez un tour complet? Et bien maintenant vous l'avez... ;)
http://jurasecondairen.blogspot.ca/2017/01/signalisation-automatique-un-tour.html (http://jurasecondairen.blogspot.ca/2017/01/signalisation-automatique-un-tour.html)
-
Dominique a raison : pas "d'affolage" !
Juste une question : pourquoi, au démarrage, on est à R et RR pour une aiguille qui donne voie directe ?
Après, tout est bon. OK.
Denis
-
Juste une question : pourquoi, au démarrage, on est à R et RR pour une aiguille qui donne voie directe ?
Deux points ici:
- d'une part, il s'agit d'un reliquat d'un test précédent où je voulais valider que R et RR fonctionnaient bien dès le départ
- d'autre part, les moteurs ne sont pas encore câblés dans cette nouvelle version mais la logique persiste. Donc, je dois malgré tout actionner les aiguillages même si les rails ne bougent pas.
Voilà...
Patrick
-
Bonjour
J'ai regardé tes réalisations => c'est top, mais hélas j'ai cherché des plans et programmes, mais rien trouvé
Peut-être mal cherché
Cordialement
Marcel
-
Bonjour Marcel, bonjour à tous,
J'ai regardé tes réalisations => c'est top
Merci beaucoup. Heureux de voir qu'il y a de l'intérêt!
mais hélas j'ai cherché des plans et programmes, mais rien trouvé
C'est une vaste problématique... Je prends quelques minutes pour répondre...
Autant je lève mon chapeau devant tout le travail accompli par l'équipe de Locoduino car la volonté d'être pédagogue est bien présente, autant, dans mon cas, je suis très frileux à l'idée de faire la même chose. Cela demande énormément de travail et de temps. Il ne suffit pas d'écrire des articles, il faut aussi que le code soit bien présenté, clair, "bug free" autant que possible. De plus, il faut supporter les utilisateurs qui pourraient avoir des problèmes avec celui-ci, etc... Mon boulot me demande déjà beaucoup d'investissement personnel et je préfère consacrer le peu qu'il me reste à avancer sur mon projet...
Mais bon, je ne dis pas que les choses ne changeront jamais, bien au contraire... Mais pour l'instant, je peux difficilement en faire plus.
J'espère ne décevoir personne.
Au plaisir,
Patrick
-
Bonjour Patrick,
Ne sois pas déçu, on sait ce que c'est de développer...
Au début, ça à l'air de marcher et puis, zut, là, ça ne fait pas ce qu'il faut ! :(
Et puis on répare et ça foire ailleurs >:(
Et puis, un jour, allelouia !
Il faut que ça reste un loisir.
Et, (mais c'est tout à fait personnel) : si c'est toi qui débogue, ça m'arrange ... ;D ;D ;D
-
Bonjour,
Je pense que Patrick, comme beaucoup d'entre nous, préfère montrer une partie de son projet quand il marche, et pas trop tôt, une fois qu'il est sûr des choix pour sa solution.