Auteur Sujet: Modélisation logicielle d'un réseau - le système de Denis  (Lu 768 fois)

DDEFF

  • Sr. Member
  • ****
  • Messages: 303
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #15 le: octobre 22, 2016, 11:22:18 am »
Suite à quelques questions qui m'ont été posées (en off), je précise un peu plus ma démarche.
J'ai, en cours de développement toujours, deux programmes complémentaires.
Je vous ai présenté le deuxième dans le précédent post et, en PJ, vous trouverez le premier. Je sais, c'est un peu bizarre ... :)

Le premier programme est un éditeur de TCO.

Le but étant que quelqu'un qui n'est pas forcément féru de C++ (Arduino), de Java (Processing) puisse dessiner son réseau et avoir un vrai TCO.
On a à sa disposition une palette contenant tous les symboles nécessaires (on pourrait en ajouter, d'ailleurs) et, par drag & drop, on les mets où on veut, on les oriente, on les copie, on les déplace par lots, ... Bref, on dessine petit à petit son réseau.

Je me suis très fortement inspiré du Locodrome de Pierre (=Pierre59), qui est une formidable boîte à outils concernant les objets, des briques, qu'on peut adapter à ses goûts et ses besoins.

Les briques qui permettent de dessiner une Ferrari peuvent aussi servir à dessiner un tracteur :
Ils ont tous les deux quatre roues. Je prends les roues de la Ferrari, je change la taille et j'ai des petites roues à l'avant et des grandes à l'arrière !

Ce programme a été développé sous Windows, avec une vraie souris à molette, ce qui est extrêmement pratique à l'usage.

Pour la fonction zoom, on a le choix entre mettre la souris au dessus de la partie à zoomer et tourner la molette dans un sens ou dans l'autre.
Si on n'a pas de souris, on fait + ou -, toujours en ayant mis la souris sur la partie qu'on veut zoomer.

Sur un portable, avec un touchpad, c'est effectivement moins pratique, mais possible.

On peut évidemment sauver ce qu'on a fait (ouf ! ;)) simplement en appuyant sur "S".

Cela génère trois fichiers texte :
--> Un fichier qui décrit chaque cube, avec toutes ses caractéristiques
--> Un fichier qui décrit les cantons (donne la liste des cubes qui le composent) et qui donne l'élément suivant et précédent
--> Un fichier qui décrit les aiguilles (donne la liste des cubes qui le composent) et qui donne les éléments qui y sont rattachés
J'appelle "élément" un canton ou une aiguille.
"Aiguille" au sens (très) large : aiguille, TJD, croisement, triple...

Quand on a fini de dessiner son TCO, ces 3 fichiers seront à transférer de la directory "data" du TCO à la directory "data" des commandes.
Comme vous le remarquerez, le nom des fichiers suit une logique stricte : quand on sauve, le nom du fichier contient la date, l'heure (minutes et secondes).
C'est comme ça qu'on les relie ensemble.
Il est d'ailleurs quasi obligatoire de trier la directory data en fonction de la colonne date. Comme ça, les 3 fichiers sont ensemble.

Le deuxième programme sert à commander les trains

Il y a toujours une palette, mais elle contient des éléments de commande des trains.
L'autre palette a disparu, on ne peut plus bouger les cubes ni modifier le tracé.
Mais, alors qu'on ne pouvait pas changer la position des aiguilles, là, on pourra (pas encore fait).

Je pense que je ne ferais pas directement la commande des aiguilles, mais celle des itinéraires, en utilisant une méthode différente du Locodrome :
Premier clic sur un train, deuxième clic sur sa destination. Et c'est le programme qui se débrouillera pour savoir comment y aller.

Là, le programme de Jean-Luc sera bien utile, même si, pour l'instant, il n'a pas cette fonction.

En tous cas, je ne veux pas avoir à dresser moi-même la liste de tous les itinéraires possibles.

La nouvelle palette contient à l'ouverture 14 manettes. C'est beaucoup trop.
Allez ligne 57 et mettez "8" au lieu de "28". Vous n'aurez plus que 4 manettes, ce qui est déjà pas mal.

Et là, vous apprécierez (je l'espère) de pouvoir déplacer la manette où vous voulez et surtout de zoomer dessus.
Vous verrez la qualité des fonctions de dessin vectoriel de Processing : ça reste net à grande échelle. Vous pourrez voir les ombres sous le curseur, etc...

Avenir :

Malheureusement, je me rends compte en développant le deuxième programme qu'il a une influence sur le premier. D'où le fait que ferai l'article sur le premier quand je saurais qu'il n'évoluera plus.

Ce que je voudrais développer aussi, c'est que le point qui symbolise une loco dans le Locodrome avance exactement en phase avec le vrai train.
J'entends par là qu'on puisse en déduire la vitesse réelle du train à tout moment. J'ai des pistes, mais il faut se lancer.

Processing existe aussi pour Android (et pas trop pour Iphone). On peut donc envisager une manette déportée sur un mobile.
J'attends l'article de bobyAndCo pour voir comment l'intégrer  ;D ;D

Vous noterez également que les fonctions DCC sont distinctes du reste. En virant une colonne sur deux, on peut envisager une commande analogique. A voir.
En fait, c'est aussi un labo. C'est quand même agréable de faire ce qu'on veut...

« Modifié: novembre 12, 2016, 04:15:47 pm par DDEFF »

DDEFF

  • Sr. Member
  • ****
  • Messages: 303
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #16 le: novembre 12, 2016, 02:18:52 pm »
Je propose aujourd'hui de faire le point sur ce que je veux faire, à terme, et ce qui fonctionne déjà.

Étant donné le prix des logiciels du commerce, n'ayant peur de rien, j'ai cherché à en faire un moi-même, à ma sauce.
Je dis tout de suite que, sans un site comme Locoduino, je n'y serais jamais arrivé. Imaginez qu'en 2014, je ne connaissais pas le langage C…

Quatre ordinateurs

Le premier, c'est celui du salon (ou du bureau, comme vous voulez) et vous devez installer dessus la dernière version de Java et du logiciel Processing.
Avec Processing, mon premier logiciel en Processing : TCO.

Processing ?

Pour faire simple, un Arduino sait exécuter une tâche quand vous appuyez sur un bouton poussoir, allumer une LED, …
Mais il est très pauvre en entrées sorties avec un écran.

Processing sait, par contre, gérer quasiment tout ce que vous voulez faire sur un écran (faire tourner des figures en 3D, dessiner en 2D, …) mais il ne sait pas allumer une LED !

En fait, ces deux là sont faits pour s'entendre, via le bus série.

Donc, sur votre ordinateur (PC, Mac ou Linux) vous allez créer votre TCO en jouant avec des petits cubes. Vous pourrez les déplacer, les copier-coller ou couper-coller.
Tout ça avec une palette qui contient, à l'origine, tous les types de figures (ligne droite, courbe, aiguilles, croisements, TJD, TJS et triples)

J'ai voulu une interface sobre, épurée, avec le moins de texte possible.
En plus, je cherche à dessiner un réseau complet (c'est absolument indispensable ici, vous verrez pourquoi), une représentation assez proche de la réalité, y compris des longueurs à l'échelle.

On peut évidemment sauver le résultat et cela génère 4 fichiers textes :

Block___2016_11_10__08_04_55.tsv
C_panel_2016_11_10__08_04_55.tsv
Turnout_2016_11_10__08_04_55.tsv
Specifs.h

Les trois premiers sont liés par une date-heure commune (à la seconde près) et sont destines au deuxième ordinateur.
Le quatrième est destiné au troisième ordinateur.

Quand votre TCO est complètement dessiné, vous n'avez plus besoin du premier ordinateur. Après tout, on ne change pas de réseau tous les jours…



Le deuxième ordinateur

Ce n'est plus un vrai ordinateur, mais un couple PCDuino3 - écran.
Et quand je dis écran, c'est un grand écran (27", au moins) et il est attaché au mur, comme les vrais TCO.
Et si je pouvais, il ferait toute la longueur du mur, comme les vrais TCO.
Je pense qu'on peut même recycler une ancienne TV à écran plat.

PCDuino3 ?

Pour 70 €, vous allez avoir un micro ordinateur qui fonctionne en Linux. L'écran se branche en HDMI.
Et comme Processing fonctionne aussi en Linux, vous installerez mon deuxième logiciel : Commandes.

Il faut copier les 3 fichiers en .tsv avec et vous retrouverez votre joli dessin de TCO, mais plus la palette qui servait à le dessiner.



A la place, un boîtier de commandes qu'on peut déplacer et dimensionner pour conduire de 1 à n trains. Commande uniquement à la souris.
Cette partie est en cours de développement.

A court terme, je souhaite doter le programme de Jean-Luc d'entrées sorties plus conviviales en le gérant depuis Processing. Et intégrer le programme de Pierre (= Pierre59), celui qui gère le célèbre Locodrome.

Par rapport aux solutions du commerce, j'insiste sur trois points :

1°) Maintenant que j'ai dessiné le TCO, je ne décrirai plus le réseau une nouvelle fois. Il faudra que ça se débrouille pour toutes les fonctions.

On vient de voir que le programme de Jean-Luc pouvait être intégré (http://forum.locoduino.org/index.php?topic=167.45) et que donc, automatiquement, tous les itinéraires possibles sont calculés. C'est même tellement rapide qu'on n'a pas besoin de les sauvegarder : ils sont calculés à la demande, en quelques millisecondes.

Je ne veux pas non plus décrire des trajets : ce sera au programme de les trouver, en fonction de paramètres à définir.

2°) J'affiche sur chaque commande le signal que "voit" le conducteur de la loco.
Sous une forme agréable et conforme à la réalité SNCF, pas un simple voyant.

3°) Par ailleurs, je veux voir les trains se déplacer.
J'entends par "se déplacer" un mouvement continu. Pas un bond brutal de canton en canton.
Un mouvement coulé qui suit de belles courbes, sur des cantons pas forcément rectilignes, horizontaux ou verticaux.

C'est même cette fonction qui doit me permettre d'avoir sur la commande la vitesse réelle du train.
Quel plaisir de voir la vitesse réelle se rapprocher progressivement de la vitesse de consigne !

Certes, ça suppose que les paramètres DCC soient bien ajustés, via une phase de tests. A mon avis assez longue.

Donc, un point va se déplacer, accélérer, ralentir, en fonction de la vitesse réelle du train. C'est pour cette raison que le tracé du TCO doit correspondre au vrai tracé du train.
A chaque signal de changement de canton, d'aiguille, cela donnera un top qui resynchronisera le point par rapport au point sur l'écran. Plus les paramètres DCC seront précis, plus le dessin du TCO sera proche de la réalité, plus ce sera facile de resynchroniser.

Une fois qu'on est synchrone, tout est possible :
1°) Plus besoin de couper les rails pour les zones d'arrêt
2°) On peut déclencher une action (sifflet, par exemple) a un point précis du réseau, sans ILS ou autre.

Le troisième ordinateur

Cette fois-ci, c'est un Arduino DUE, gestionnaire du réseau.
Il est relié au PCDuino3 par un câble USB série (au moins pour les essais).
Il reçoit du PCDuino3 les ordres (choix d'itinéraires, vitesse, …) et lui envoie le résultat (occupation des cantons, couleur des signaux, …)

C'est là que vous utilisez le fichier "Specifs.h" généré par TCO, au début.

La partie description du réseau existe (le programme de Jean-Luc), mais il reste beaucoup à faire.
En particulier répondre à la question très complexe : parmi tous les itinéraires calculés, quel est le meilleur ?

C'est là aussi qu'il me faut intégrer la partie signaux de Pierre. J'ai bon espoir.

Et, évidemment, le DUE est relié au réseau via un bus CAN.

Je ne veux pas voir de fils sous le réseau.
Uniquement des câbles Ethernet avec des RJ11/RJ45 qui vont de modules en modules.

Jean-Luc a réalisé le premier d'entre eux : le module 8 aiguilles.

On fera évidemment un module cantons.

Les possibilités du bus CAN sont énormes et permettront à la fois de gérer la mise en place des aiguilles, mais de gérer aussi toute la rétro-signalisation.

Les bibliothèques de Thierry permettront une gestion simplifiée de tous ces échanges.

Le quatrième ordinateur

C'est la centrale DCC, avec un Arduino MEGA.

Logiciel DCC++ dont Dominique vous a déjà parlé sur le Forum et dans des articles.

Relié bien sûr au gestionnaire. A définir.
Je penche pour un lien vers le DUE par le bus série et relier le DUE au PCDuino par un bus CAN.
Le deuxième bus CAN du DUE vers le réseau.

En fait, la seule information qui va être véhiculée sera du DUE vers le MEGA, c'est la vitesse maxi de consigne.
Exemple : "Je veux que le train 1 aille au maximum à 30 km/h".

Cela suppose que cette centrale DCC puisse commander plusieurs trains. A suivre.

Comme vous le voyez, c'est extrêmement ambitieux, mais faisable.
Et qu'on peut agglomérer les réalisations des uns et des autres en un ensemble complet.

C'est très motivant.
N'hésitez pas à vous exprimer, à donner vote avis.
« Modifié: novembre 13, 2016, 10:23:35 am par DDEFF »

DDEFF

  • Sr. Member
  • ****
  • Messages: 303
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #17 le: novembre 19, 2016, 08:59:45 am »
Je commence à voir un peu de lumière dans le programme de Jean-Luc (voir le fil sur ce programme).
Par ailleurs, concernant Processing, je vois le cheminement pour intégrer le Locodrome de Pierre.

Au passage, je vais faire figurer les retraits de Pierre (un blanc entre 2 cantons, pour les séparer) en l'automatisant de manière simple :
Il faut ajouter un retrait entre 2 cubes voisins s'ils n'ont pas le même label ! :D

Au début, je ne voulais pas faire figurer de signaux.
Ceux de Pierre sont sobres et je vais les ajouter, avec un détail supplémentaire :
Signal un feu quand on est en pleine voie et 2 feux quand on peut avoir le carré ou les ralentissements, rappels, etc...

A suivre  :P

DDEFF

  • Sr. Member
  • ****
  • Messages: 303
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #18 le: décembre 06, 2016, 04:42:23 pm »
Juste une remarque :

Comme je viens de mettre un nouveau Post sur le fil de Jean-Luc, je vais devoir adapter mon programme TCO pour que les enum{...} soient dans le bon ordre.
Comme ça, ça me repose un peu .... ;D

DDEFF

  • Sr. Member
  • ****
  • Messages: 303
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #19 le: janvier 11, 2017, 02:22:11 pm »
Bonjour,

Je viens de terminer mes deux courbes de 90°, l'une droite et l'autre orientée à 45°.
Ces deux courbes sont extensibles.

Pourquoi avoir recommencé, puisque ça marchait déjà avant ?

C'est simple : après avoir correspondu avec Pierre (=Pierre59), il m'a expliqué qu'il avait changé de courbes de Bezier.
Il utilise maintenant des courbes dites cubiques au lieu de courbes quadratiques.

Dans les courbes quadratiques, on n'a qu'un point attracteur et donc assez peu de possibilité de manœuvre.
Disons que si on veut faire un joli cercle, on s'en approche avec une sorte de parabole.

Dans les courbes cubiques, on a deux points attracteurs, avec 2 vecteurs associés.
Et là, si on veut approximer un cercle, on est presque à la perfection.

Voilà ce que ça donne en vrai :



A gauche, une courbe quadratique et à droite une courbe cubique.

Si on observe bien, la courbe quadratique souffre de deux défauts :
1°) elle est trop "pointue" pour simuler un cercle
2°) si vous regardez vraiment bien, vous verrez que l'épaisseur du trait varie et qu'elle est plus fine au milieu.

Mais pourquoi vouloir approximer un cercle ?

C'est vrai qu'on nous a expliqué depuis longtemps que la courbe idéale pour les trains était justement la parabole.
C'est toujours vrai, pour les vrais rails. Pour les trains réels et aussi pour les nôtres.

Mais là, on est sur un TCO qui ne représente qu'approximativement notre réseau. Ce n'est donc pas un réel problème d'approximer une parabole par un cercle pour un TCO.

Et surtout, si on veut faire rouler des trains sur le TCO, c'est beaucoup plus simple à programmer !!
D'où le réel intérêt de ce changement de type de courbes.

Sinon, le train du TCO va rouler à côté des rails !!  ;D ;D

Il me reste à faire la même chose pour les 1/8è de cercle, eux aussi extensibles.  :-*



« Modifié: janvier 11, 2017, 03:12:18 pm par DDEFF »

DDEFF

  • Sr. Member
  • ****
  • Messages: 303
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #20 le: janvier 14, 2017, 05:17:16 pm »
"Les mathématiques, c'est l'art de raisonner juste sur une figure fausse"… disait mon prof de maths en 4ème.

Une fois n'est pas coutume, je vais vous donner un petit aperçu des choses qu'on doit résoudre pour faire un TCO élégant. Je vous rassure, je n'irai pas ici plus loin que des maths niveau 5ème.

On a vu dans le post précédent qu'on allait maintenant utiliser des courbes de Bezier cubiques pour avoir de jolis cercles. On pourra ainsi voir nos petits trains rouler exactement au milieu du tracé du TCO.
Pour le 1/4è de cercle, c'était "assez" facile puisque le centre du cercle était bien dans le coin.
Pour le 1/8è de cercle, ça n'est plus vrai et il va falloir chercher les coordonnées.

J'ai fait ce joli dessin avec le logiciel gratuit que mes enfants utilisaient au collège : Geogebra.
Je vous conseille de le télécharger (https://www.geogebra.org/download), de façon à pouvoir zoomer sur certains points, ça peut être instructif.



J'appellerai "e" le côté du carré. il est fixé à le 9 dans le locodrome, mais je voulais calculer pour n'importe quelle valeur. Il est à 10 chez moi.

J'appellerai "t" l'épaisseur du tracé, fixé à 3 dans le locodrome et à 2 chez moi.

J'appellerai "d" la valeur t/2/racine(2) qui sert dans les calculs. Elle vaut 1 dans le locodrome.
J'ai compris alors pourquoi Pierre (=Pierre59) avait utilisé 9 et 3 !! De toute beauté.

J'appellerai "z" le facteur de zoom. Dans le dessin, il est à 1 (on reste dans 1 carré).

On a au départ 6 points qui sont :

X1 de coordonnées (0 , -e/2+t/2) : 0 en x et pour y, on descend d'1/2 côté et on remonte d'1/2 épaisseur
X2 de coordonnées (e-d,  -d). Voilà l'usage du "d".
X3 de coordonnées (0,  -e/2) : on descend d'1/2 côté.
X4 de coordonnées (e,  0)
X5 de coordonnées (0, -e/2-t/2): on descend d'1/2 côté et on descend d'1/2 épaisseur.
X6 de coordonnées (e+d,  -d)

On notera que la difficulté vient du fait que les corde1, corde2 et corde3 (voir figure) ne sont PAS parallèles. Ils sont en éventail.

Au début, j'avais dessiné sur un cahier, à main levée, et j'ai cherché à trouver un centre commun à corde1 et corde3, en me disant que je me débrouillerai bien pour trouver un cercle qui soit à peu près centré après pour le suivi des trains.

J'ai donc raisonné en me disant que le centre du cercle qui passait par X1 et X2 était sur la médiatrice de corde1.
De même, le centre du cercle passant par X5 et X6 serait sur la médiatrice de corde3.
Et, évidemment, comme ces deux médiatrices se coupent, ce point d'intersection est le centre commun pour les deux cercles.
Et, ( oh surprise ! ) : ce point commun est aussi le centre du cercle qui passe par X3 et X4 !!
Je vous assure que ça n'a rien d'évident. Pas du tout.
Mais ça nous arrange vraiment parce qu'on n'approxime rien : le calcul est exact.

Autre trouvaille, qui n'avait rien d'évident non plus, c'est que les 3 angles au centre de chaque arc font exactement 45° !!
Si vous regardez bien le dessin, les trois triangles (gauche1, corde1, droite1), (gauche2, corde2, droite2) et (gauche3, corde3, droite3) sont semblables, décalés chacun les uns des autres, mais avec un point commun et des angles identiques. Et ça, j'achète !!

Par contre, les coordonnées du centre des cercles sont complexes.

On n'est plus simplement "dans un coin", comme avec des 1/4 de cercles.

Et il n'est pas question de déplacer artificiellement le centre C1 sur le point Coin1 parce que vous allez voir que quand on veut zoomer pour agrandir la courbe, le centre s'éloigne de plus en plus des coins ou de points simples.

En fait, pour les courbes de Bezier, on n'a pas besoin de calculer les coordonnées du centre. Il faut calculer les coordonnées des deux points "attracteurs" de chaque courbe approximant le 1/8è de cercle.
Et comme on est exactement à 45° d'angle au centre, on trouve sur internet le nombre "magique" correspondant, à savoir "m" = 0.265206.

Vous comprendrez maintenant pourquoi j'étais content de m'apercevoir que chaque angle faisait exactement 45°. Un calcul (infernal, d'ailleurs) en moins. Et une précision de 1/1 000 000 !!

Mais pour calculer les coordonnées de P1 (côté X1) et P2 (côté X2), on passera par les coordonnées du centre des cercles.


Les voilà :  C1(e*K1,  e/4+e*K)

Avec K1 = (5*racine(2)-7)/(8*racine(2)-12) = -0.103553
Avec K = racine(2)/2 = 0.707107
Vous pourrez faire le calcul avec e = 9 et confirmer les données de la figure pour C1.
Et moi, je peux faire le calcul pour e = 10.

Vous remarquez une chose étrange : les coordonnées du centre des cercles ne dépendent pas de l'épaisseur des bandes sur le TCO, uniquement du côté du carré !

En ayant C1 et X1, on calcule la pente de la droite qui passe par les deux points, ce qui donne la pente de la droite passant par X1 et P1. Et, avec le nombre magique, on a les coordonnées de P1.

Pente de la perpendiculaire a1 = -e*K1/(e/4+e*K+(e-t)/2)

Donne P1( e*m/racine(1+a1),  a1*[e*m/racine(1+a1)]-(e-t)/2)

Pour e = 9 et t = 3, P1(2.296489, -2.815714)
Pour P2, symétrique de P1 par rapport à la médiatrice, même genre de calcul, avec X2 et C1.
Je ne vais pas vous infliger le calcul pour les autres points.

Vous aurez remarqué que les formules ne sont pas évidentes, sans être vraiment atroces. Finalement, le raisonnement, lui, est assez simple et c'est pour ça que je voulais vous le présenter.

Mais ça n'est pas fini. Passons aux zooms.


Normalement, en bougeant la molette, on agrandit la courbe.
Mais le résultat ne va pas :



On a bien les 45°, les cercles concentriques, mais il y a un angle inacceptable entre la droite et le cercle. On ne peut pas zoomer de cette façon.

Je propose plutôt ça, mais je dois encore faire les calculs.








« Modifié: janvier 14, 2017, 05:19:33 pm par DDEFF »