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

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #45 le: août 05, 2018, 10:22:45 am »
Non, le Processing.exe de ton Mac (ce serait pareil avec un PC) a gardé le chemin de la dernière fois que tu as été chercher des data.

Donc, dans la fenêtre où on te demande de choisir le fichier, tout en haut, il est sur une directory "data", mais pas la bonne.
Remonte dans l'arborescence et choisis la bonne directory qui sera dans la V6-32.
Tu dois être dans une version antérieure à la V6-24.

Rassures-toi : une fois ce choix fait, Processing gardera le chemin vers la V6-32.
Mais, la première fois, il faut aller au bon endroit.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #46 le: août 05, 2018, 02:48:10 pm »
C'était bien ça, Processing pointait sur un ancien dossier data ailleurs dans les anciennes versions.

C'est dommage que ton programme ne puisse pas récupérer son propre chemin d'accès pour éviter ça en partant du principe que le dossier data serait au même niveau !

Bon en lançant le programme avec l'un ou l'autre des .tsv dans le dossier date 'circuit_d'essai" ou "TCO____2018_07_30__17_31_34", ça plante encore plus grave avec même pas de barre de menu en bas et une "ConcurrentModificationException", dans l'onglet TCO à la ligne 22 où il y a "        for (Pave pave : tous_paves1) {"

et toujours :

Citer
2018-08-05 14:24:50.094 java[22667:4930413] pid(22667)/euid(502) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
objc[22667]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fffaf02ec90) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x1631a0cd8). One of the two will be used. Which one is undefined.

En ouvrant un circuit vide (annuler au lieu de choisir un .tsv), j'obtiens une exception pour pointeur null dans Mouse ligne 21
"                    pave_feu_noir.feu_noir[cote_feu_noir] = true;"
en tentant de sélectionner un itinéraire sans circuit  :-*
Je sais que c'est débile mais ça ne devrait pas planter !

Donc visiblement tu as fait de gros progrès et je dois pouvoir tester un peu maintenant. Dommage, je m'absente quelques jours. Je reprendrai à mon retour.

Amicalement
Dominique

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #47 le: août 05, 2018, 07:13:19 pm »
Merci Dominique, c'est sympa de bien vouloir tester.

Voyons les bugs (que j'ai malheureusement déjà trouvés aussi ...  :-[) :

1°) Choisir automatiquement la bonne directory.

Dans Processing, pour choisir un fichier, je dois obligatoirement mettre dans le setup() :
selectInput("Selectionnez un fichier pour determiner le repertoire de demarrage : ", "fileSelected");
Cela a un premier défaut :
-> Cela génère une page blanche sans intérêt au départ

On peut alors choir le fichier dans la fenêtre qui apparait.
Deux cas :
-> On est en adressage absolu (il existe getAbsolutePath dans Processing) et c'est mal barré parce qu'il faudra changer V6_32 en V6_33 si on a une nouvelle version.
Donc, très mauvaise idée
-> On est en adressage relatif (sauf que getRelativePath n'existe pas  :-[) et là, je cale. Ce serait bien.
Et c'est Processing qui mémorise la dernière directory, avec le problème que tu soulevais.

2°) "ConcurrentModificationException" (à cet endroit)

Figures-toi que ce n'est pas parce qu'on choisit un mauvais fichier, c'est ... parce qu'on sélectionne trop vite !!!  ??? ??? ???
Ailleurs, j'ai une explication (il y en a plusieurs) et je résous le problème. Mais, à cet endroit, je n'ai pas d'idée.
En quoi la rapidité de sélection peut influer ?
Il faut compter jusqu'à 2 avant de cliquer. C'est débile  :o

3°) En choisissant "annuler" :

Je n'ai jamais eu ça (et ce n'est pas faute de l'avoir fait).
On a ce que tu décrivais dans ton précédent post : un pupitre out petit (à l'échelle 1), au point 0,0. Et un menu. Et évidemment, pas de circuit.
C'est bizarre

Amicalement
Denis

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #48 le: août 09, 2018, 06:01:21 pm »
Je viens de régler le cas 3°) du précédent post : on peut maintenant reculer n'importe où. Il faut quand même s'arrêter avant  ;)
C'était quand même la moindre des choses…

Je profite de ce problème pour expliquer comment je raisonne pour gérer les itinéraires.
Disons que c'est assez original. Assez pour qu'on n'ait pas besoin de bouton d'inversion.

Quand un train se déplace, il va d'un point à un autre.
Cela peut paraitre évident, dit comme ça, mais c'est beaucoup plus profond.
On va donc définir des "points" qui seront les positions possibles des véhicules (loco, wagons et voitures). Cette brillante idée est due à Pierre59, dans le Locodrome.
On calcule les points dans les pavés, puis ces points, de proche en proche, recouvrent tout le réseau, au fur et à mesure qu'on ajoute les pavés pour construire le dessin du réseau.
On remarquera que ces points ont des coordonnées fixes, une fois le réseau défini.

Je n'utilise pas les points de la même manière que Pierre59, mais je ne sais pas si ma méthode est la meilleure. Elle est juste différente.

Je pars du fait qu'un train (au sens large : ce peut être une loco "haut le pied") doit forcément être sur un itinéraire. ;) ;)

Et un itinéraire, c'est aussi au sens large, comme expliqué précédemment : on peut très bien avoir un itinéraire entièrement en pleine voie, sans aucun appareil de voie ("SAV", voir un précédent post). Un train avance sur son itinéraire et "est transféré" sur l'itinéraire suivant. La dernière zone d'un itinéraire devient la première zone du nouvel itinéraire. Et ainsi de suite.

J'utilise une possibilité tout à fait courante à la SNCF : le carré manuel.
Comme un train ne peut pas quitter un itinéraire, on lui mettra un carré manuel à l'extrémité, sauf, évidemment, s'il est chaîné à un itinéraire suivant.
Si on parcoure une boucle fermée, on ne verra jamais apparaitre ce carré manuel.
Si on arrive sur une voie de gare, ce carré sera tout à fait à sa place classique.
Mais c'est une sécurité pour qu'un train ne sorte pas de son itinéraire (si c'est le dernier de la chaîne).

Maintenant qu'un train a son itinéraire, on sait tout sur lui. C'est pour ça que je raisonne comme ça.
On a en effet une échelle d'une incroyable précision : les points.
Pour vous donner une idée, depuis le coin en haut à gauche au coin en bas à droite, il y a plus de 7000 points ! :P
On connait la position de chaque signal et, en particulier celui que voit le conducteur du train.
On connait la position de chaque véhicule, que ce soit la loco, les wagons, …
On en déduit évidemment les zones occupées, celles qui se libèrent.

Et ça résout surtout une question que je me posais depuis 1990 (!) :o

Je raisonne en me disant qu'on a 128 crans de vitesse, de 0 à 127.
Si un train roule au cran 127, je considère qu'il avance de 127 points à chaque fois.
Au cran 100, on avance de 100 points, c'est-à-dire qu'on redessine le train 100 crans plus loin.

Puis je définis une zone de freinage, égale à 10 fois la vitesse du train. Pour l'instant, le facteur 10 sera l'objet d'essais. Si ça se trouve, il faudra 5 ou 20. On verra. Mais, pour l'explication, mettons 10 fois.
Donc, si le train roule au cran 127, il lui faudra une distance de 1270 points pour s'arrêter et 1000 points pour une vitesse au cran 100.
Vous constatez que c'est linéaire, ce qui n'est pas du tout le cas d'une courbe de décélération qui ressemble plutôt à une décharge de condensateur. Mais ça n'est pas grave :



En regardant ce schéma (issu de vraies mesures), on constate qu'il y a trois zones :
1°) La zone de décélération proprement dite
2°) La zone de vitesse constante à la vitesse de ralenti. Ici cran 10
3°) A 100 points du signal, on passe de 10 à 0 et le train s'arrête.
Il a bien mis 1270 points pour s'arrêter.
En fait, la variable d'adaptation, c'est la zone à vitesse ralenti.
On peut avoir une distance de freinage qui varie linéairement avec la vitesse, tout en ayant une courbe de décélération non linéaire.

Et c'est là que ça devient novateur.


On est à 1270 points du signal rouge (SEMAPHORE ou CARRE) et on démarre le freinage. On s'arrêtera pile où on voulait, exactement à 100 points du signal.
Mais à 1270 points du signal, où est-on ?
Prenons un cas classique :



La longueur de la zone comprise entre le signal CARRE et le signal AVERTISSEMENT (en vert sur l'image) est de plus de 2500 points.
Et donc le train va passer à fond (cran 127) au droit du signal d'AVERTISSEMENT, puis, à 1270 points du signal CARRE, il va s'arrêter à 100 points du CARRE.

Mais, dans cet autre cas :



On a un problème : la distance entre le CARRE et l'AVERTISSEMENT est supérieure à 1270 points.
Et on va devoir commencer à s'arrêter sur la zone d'AVERTISSEMENT.

Je ne connais pas beaucoup de gestionnaires de trains qui soient capables de freiner avant d'avoir croisé le signal d'AVERTISSEMENT. En général, tout se passe sur la dernière zone.

J'ai eu cette idée en 1990, mais c'est la première fois que je la réalise. ;D ;D ;D

Pour aller jusqu'au bout de l'explication, à la SNCF, si la zone d'arrêt est trop courte, on emploie le signal rouge clignotant qui, justement, prévient le conducteur qu'il faut commencer à freiner plus tôt que d'habitude.  Et c'est signalé sur sa feuille de route quand il prend son  train en charge.
Je n'ai pas encore géré le signal rouge clignotant. C'est prévu.

Gestion de la marche arrière :

Maintenant que vous avez suivi comment je gère les itinéraires, vous comprenez pourquoi je n'ai pas besoin de bouton de marche arrière : il suffit que je demande un itinéraire dans l'autre sens… et que je me sois arrêté.

"Accessoirement", il faut effacer tout ce qui restait à faire dans l'autre sens…
Et dès que la zone sur laquelle est le train devient la dernière de son itinéraire, le transfert d'itinéraire a lieu automatiquement. C'est "magique".

Voici la vidéo explicative :
Je crée 3 itinéraires chaînés et je décide, à un moment de m'arrêter et de repartir dans l'autre sens.
Je sélectionne un nouvel itinéraire, tout s'efface et c'est parti !

https://www.youtube.com/watch?v=Ylsb8KT9oFI&feature=youtu.be

Le programme qui fait ça est là :
http://www.locoduino.org/IMG/zip/train_tco_v1_6_33.zip

Pierre59

  • Jr. Member
  • **
  • Messages: 91
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #49 le: août 09, 2018, 06:21:02 pm »
Bonjour

Super, je vois que tu avance bien.

Pour obtenir un déplacement plus fluide des trains, j'avance toujours d'un seul point, mais pour respecter la vitesse le délai entre un point et le suivant dépend de la vitesse (0 à 127).

Pour les itinéraires j'essaie de respecter le plus possible ce que fait la SNCF, avec un point de départ et un point d'arrivée, les points de départ sont toujours devant un signal.

Ton système comptant les points avant un signal est assez astucieux pour faire les ralentissements. Mais un gestionnaire gérant des trains réels et non pas des trains virtuels ne peut pas trop utiliser ce système sauf peut être en implantant des balises sur le réseau.

Bon courage

Amitiés

Pierre

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #50 le: août 09, 2018, 06:46:32 pm »
Merci Pierre, tes encouragements me vont droit au cœur  ;D ;D

Je ne suis pas trop pour installer des balises sur le réseau, à priori.
Je pense que les "balises" existent naturellement : le changement de zone.

Le but étant que les déplacements de trains virtuels soient synchrones avec les déplacement réel.
Il reste donc un gros boulot, parce que ça n'est pas gagné ! Ce n'est peut-être même pas possible...

Remarque : Je pense que ce n'est pas au gestionnaire de gérer lui-même les ralentissements. C'est plutôt le boulot de la centrale DCC (à mon avis).
Mais le gestionnaire doit donner le top pour lancer le ralentissement.
Ma gestion de la courbe, c'est un peu "pour le fun".

Citer
Pour les itinéraires j'essaie de respecter le plus possible ce que fait la SNCF, avec un point de départ et un point d'arrivée, les points de départ sont toujours devant un signal.
Moi aussi, c'est forcé. On est en phase.
Quand je dis "n'importe où", c'est pour dire que ça peut aussi être en pleine voie (pas forcément à côté d'un appareil de voie). Mais toujours au pied d'un signal.

Denis

fmd14

  • Newbie
  • *
  • Messages: 14
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #51 le: août 10, 2018, 10:36:48 am »
Bonjour,

Félicitation pour votre travail

je voudrais dessiner un réseau
je ne trouve pas l'éditeur de réseau  dans la avant dernière version

beau travail encore

FMD14
FMD14

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #52 le: août 10, 2018, 11:02:18 am »
Bonjour fmd14,

J'ai bien un éditeur (sinon, je n'aurais pas pu réaliser ce réseau  8)), mais je le trouve beaucoup trop lent.
A la lumière de mon expérience sur le TCO, je me rends compte qu'il doit bénéficier des mêmes accélérations dans le traitement.
Je dois donc le revoir pour l'améliorer... et trouver du temps pour le faire. ;)

Ceci étant, même quand l'éditeur sera amélioré, tu auras certainement remarqué que, pour l'instant, je suis dans les trains virtuels.
Je ne suis pas encore au point pour passer au réel. Mais c'est bien sûr prévu.  ;D

Denis

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #53 le: août 10, 2018, 11:07:52 am »
Pour bien comprendre la démarche de ralenti, je vais exposer quelques cas concrets et bien détailler.

Zone de freinage :




Sur le cas suivant, la zone1 fait 400 points et la zone2 fait 470 points.
La zone de freinage est égale à 10 x vitesse de consigne.

Supposons qu'un train arrive au cran 30. Il va donc mettre 300 points à s'arrêter.
Donc, juste quand il passe de la zone2 à la zone1, il commence à ralentir et s'arrête juste devant le butoir, à 100 points précisément car 300+100 = 400.

Maintenant, le train arrive au cran 77. Il va donc mettre 770 points pour s'arrêter.
Juste quand il passe de la zone3 à la zone2, le feu que voyait le conducteur, qui était à VOIE_LIBRE, passe à AVERTISSEMENT. Le processus s'enclenche et il s'arrête à 100 points du butoir car 770+100 = 400+470.

Enfin, un train arrive à fond, cran 127. Il devrait mettre 1270 points pour s'arrêter.
Mais il ne bénéficie pas de cette distance…
Tout est perdu ? Que nenni !

Observons de plus près la courbe de décélération :



Le train freine vraiment au début, sur 400 points, maintient une vitesse de cran 10 et ralenti jusqu'à l'arrêt sur 200 points.
Le top départ du ralenti final n'est pas donné par la courbe, mais par la position du signal.
En fait, à 300 points du signal, on démarre un ralenti linéaire sur 200 points.
Ce qui fait qu'on s'arrête à 100 points du signal.

Donc, le train arrive au cran 127 à 870 points du signal (zone1+zone2)
400 points plus loin, il est au cran 10. On est à 470 points du signal.
Il reste au cran 10 jusqu'à ce qu'il arrive à 300 points du signal et là, il termine son arrêt sur 200 points.
Il arrive donc à 100 points du signal, dans tous les cas, même si les zones sont courtes.

Ces exemples numériques sont sujets à évolution.
On a toute latitude sur la forme plus ou moins accentuée de la courbe de freinage, la décélération finale en 200 points, le facteur 10 de la zone de freinage, …

Ce que je voulais surtout mettre en exergue, c'est que le freinage ne démarre pas d'un point précis sur le réseau (ILS ou autre).

Et cela correspond vraiment à la réalité :
Le vrai conducteur d'un vrai train peut commencer à ralentir AVANT de passer au droit de l'AVERTISSEMENT, en fonction de sa vitesse à ce moment.
S'il arrive à fond, il ne va pas passer le signal d'AVERTISSEMENT à fond pour freiner à mort avant le CARRE. Il commencera avant, ce qui est beaucoup plus naturel.

Dans la pratique, il faut absolument que la centrale DCC fournisse, via le bus CAN, sa vitesse de consigne au gestionnaire.
Et que, dans l'autre sens, le gestionnaire oblige le train à freiner si la sécurité l'impose, indépendamment d'un ILS ou autre, juste parce qu'il le juge nécessaire.

Je sais : pas gagné !...

Denis

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1246
  • 100% Arduino et N
    • Voir le profil
Re : Re : Modélisation logicielle d'un réseau - le système de Denis
« Réponse #54 le: août 10, 2018, 12:46:42 pm »
Dans la pratique, il faut absolument que la centrale DCC fournisse, via le bus CAN, sa vitesse de consigne au gestionnaire.
Et que, dans l'autre sens, le gestionnaire oblige le train à freiner si la sécurité l'impose, indépendamment d'un ILS ou autre, juste parce qu'il le juge nécessaire.

Bonjour Denis,
Tu as tout à fait raison, c'est ce que j'applique dans mon réseau et qui sera démontré à Orléans le 11 Novembre sur le stand Locoduino.

La centrale que je réalise est entièrement pilotée par le gestionnaire de Pierre59 et elle dispose aussi de ses propres boutons de commande pour piloter 2 trains manuellement ou automatiquement.

Comme tu l'as très bien expliqué :

- La commande manuelle de la centrale remonte, via Can, les paramètres de conduite au gestionnaire qui les renvoie à la centrale sauf si la consigne est restrictive, auquel cas c'est cette consigne qui est transmise.

- Les accélérations et ralentissements sont gérés par la centrale, en fait sous forme de transition douce entre une vitesse de départ et une vitesse d'arrivée.

- Les vitesses 30, 60 et 90 km/h à l'échelle sont étalonnées dans la centrale pour chaque machine, c'est à dire que si le gestionnaire demande une vitesse de 30 (le cran 30 DCC), ce sera le cran DCC correspondant à la vitesse réelle de 30 km/h qui sera utilisé.
Cela implique que la centrale reçoive au moins 2 détecteurs de rétrosignalisation pour une mesure de vitesse. Avec le bus Can c'est facile.

De cette façon cela simplifie pas mal les contraintes sur le gestionnaire.

Dominique