Modélisation logicielle d'un réseau - le système de Jean-Luc

[Jack56]

Bonjour Jean-Luc

Sujet très intéressant, après avoir décortiqué le SGDD de Denis (merci Denis) et avant de me décider sur la méthode que je vais utiliser pour gérer mon réseau (encore virtuel  ) je vais essayé de comprendre ta méthode qui me plait bien au premier survol. Maintenant il faut approfondir et je me pose quelques petites questions.

Sur tes schémas de présentation tu parles du "sens normal" et dans ton code tu définis dans voie.h

Code: [Sélectionner]

enum { DIRECTION_AVANT = 0, DIRECTION_ARRIERE = 1, AUCUNE_DIRECTION = 2 };
puis dans voie.cpp

Code: [Sélectionner]

void afficheSens(byte sens)
{
  switch (sens) {
    case DIRECTION_AVANT:   Serial.print("AV"); break;
    case DIRECTION_ARRIERE: Serial.print("AR"); break;
    case AUCUNE_DIRECTION:  Serial.print("*");  break;
  }
}

C'est quoi exactement le "Sens normal" y-a-t-il une relation avec les "DIRECTION" par exemple sens normal = DIRECTION_AVANT, ou bien pour faire un // avec le SGDD de Denis sens normal = sens HORAIRE ?

D'autre part est-ce que la définition du canton est la même que celle de Denis à savoir : une zone STOP, une Zone pleine voie, une zone STOP ?

J'aurai sûrement d'autres questions par la suite (j'ai aperçu des pointeurs dans ton code  ), car je n'en suis qu'au début de l'analyse de ton code. Mais pour le moment cette question de "sens" m'interpelle.

Merci d'avance pour ta réponse.
 

[Jean-Luc]

Bonjour Jack

Ce n'est pas tout à fait équivalent.  Ce que je définis comme le sens normal c'est le parcours d'une voie dans la même direction que sa direction de connexion.  Ainsi dans la gare de Denis, l'aiguillage Aiguille1 est connecté en DIRECTION_AVANT, le sens normal pour cet aiguillage est donc DIRECTION_AVANT. L'aiguillage Aiguille3 est connecté en DIRECTION_ARRIERE, le sens normal est donc DIRECTION_ARRIERE.

Pour l'instant je n'ai pas encore de notion de canton mais ça va venir. C'est un peu différent en analogique et en numérique. En analogique un canton = une alimentation indépendante, la détection de présence peut être unique ou multiple. En numérique un canton = une détection de présence.

[DDEFF]

C'est vrai que sur la façon de raisonner, il y a quelques subtilités dans la description du réseau :
Mes cantons sont tous décris dans le sens horaire (cw = Clockwise).
Par contre, les aiguilles sont toutes orientées de la pointe vers le talon.

Le raisonnement de Jean-Luc est très légèrement différent, comme il l'a indiqué dans son précédent post.

Le principal est de définir une règle et de s'y tenir strictement.

Mais la grosse différence entre ma façon de raisonner et celle de Jean-Luc tient au fait que sa méthode cherche tous les itinéraires possibles (sans reculer, quand même  ) et c'est même élargi à tout le réseau (moi, je reste en gare...).
Évidemment, le type de programmation est, lui aussi, très différent car il exploite à fond la programmation objets, héritage et pointeurs.

A ce propos, j'ai une question :

Certains itinéraires bouclés peuvent ne pas être trouvés quand un itinéraire possible est inclus. Ça n'est pas très grave.  J'ai l'idée d'une variante pour les inclure tous mais je me pose la question de l'intérêt.

Pas compris...

[Jean-Luc]

Voici un exemple.

On cherche les chemins de A à B. quand on arrive sur la TJD0, les chemins que l'on va trouver dépendent de l'ordre d'exploration.

Si on commence du côté de la flèche rouge, on trouve la cible et la TJD mémorise un chemin partiel (B). Quand on explore côté flèche bleue, on retombe sur la TJD et on découvre le chemin partiel. Il est donc recopié et le chemin via la boucle est ajouté. On termine avec deux chemins, le direct (flèche rouge) et le bouclé (flèche bleue).

Si on commence côté flèche bleue, on retombe sur la TJD sans chemin partiel et on ne retourne pas de chemin. On explore côté flèche rouge et on trouve la cible. On termine avec un seul chemin.

[DDEFF]

L'une des joies de l'informatique, c'est qu'on se rend compte que, nous, on raisonne de manière analogique (dans le sens pas complètement logique).
L'ordinateur raisonne, lui, de manière particulièrement logique, jusqu'à l'absurde dans ce cas.

La bonne nouvelle, c'est que le bon itinéraire est trouvé dans les deux cas, avec du rab pour l'une des solutions.

On a même de la "chance" qu'il ne fasse pas deux fois le tour 
Non, ça n'est pas possible avec les marquages.

J'avais dit en rigolant "sans reculer, quand même", mais plus j'y réfléchis, plus je me demande si l'Arduino, en cherchant toutes les possibilités, ne va pas utiliser une boucle de retournement pour trouver un itinéraire "en reculant".

Exemple :
Il nous parait à tous évident qu'on ne peux pas aller de la VoieGarage8 à la VoieGarage9.
Mais si en cherchant, il trouve qu'en sortant VoieLibre5 on suit les rails jusqu'à revenir VoieLibre6, il va trouver que c'est possible !!

Parce qu'en fait, quand j'avais dit que VoieLibre6 <-> VoieLibre5 est une boucle de retournement, je ne pensais qu'au cas où on revenait vraiment sur ses pas.
Et, là, ça n'est pas le cas.

D'ailleurs quelque chose m'a choqué quand tu as fait ta deuxième version :
Dans la première, tu trouvais 18 itinéraires impossibles.
Moi qui compte les deux sens, j'en trouve 36. Donc on est d'accord.

Et dans ta deuxième version, tu noteras qu'il ne trouve plus que 14 impossibilités.
Il a dû trouver des machins comme ça.

[Jean-Luc]

L'une des joies de l'informatique, c'est qu'on se rend compte que, nous, on raisonne de manière analogique (dans le sens pas complètement logique).
L'ordinateur raisonne, lui, de manière particulièrement logique, jusqu'à l'absurde dans ce cas.

Je voie plutôt ça comme une force 

La bonne nouvelle, c'est que le bon itinéraire est trouvé dans les deux cas, avec du rab pour l'une des solutions.

On a même de la "chance" qu'il ne fasse pas deux fois le tour 

Mais tous ces itinéraires sont valables, celui avec 1 tour, celui avec 2 tours, ... ceux avec N tours. Le seul qui n'est pas valable est celui avec une infinité de tours 

Non, ça n'est pas possible avec les marquages.

Eh oui car sans marquage, comme c'est un algorithme breadth-first (en profondeur d'abord), on commencerait par chercher si par hasard, celui avec une infinité de tours ne conviendrait pas 

En pratique, il faudra couper des itinéraires. En effet, si on veut des itinéraires pour manœuvrer en gare, il ne s'agit pas de permettre ceux qui quittent la gare. Par exemple sur mon réseau j'ai un pont tournant et une gare terminus (le dépôt est à côté de la gare). Je voudrais automatiser la remise en tête de la locomotive via le pont tournant. Comme j'ai également des boucles de retournement, plusieurs itinéraires possibles sortent de la zone dépôt/gare pour aller se balader.

Avec le marquage, c'est facile d'interdire des voies, il suffit de les marquer comme déjà vues avant de lancer l'algorithme. Ça servira à enlever de la recherche les voies des cantons occupés et les voies menant à des parties non désirées.

[Jack56]

Bonjour Jean-Luc

Je suis en train de décortiquer ton code, afin de bien comprendre. 

Je me pose une question par rapport à la fonction tousLesCheminsVers(). Dans l'objet "TraverseeJonctionDouble" tu as déclaré cette fonction comme protected alors que pour tous les autres objets "Voie" elle est déclarée en public. Y-a-t-il une raison particulière ?
Comme cette fonction (pour le moment) n'est appelée que par les objets "voie" en interne elle devrait peut-être être déclarée comme protected par tous les objets "Voie" ?

Dans le même ordre d'idée la fonction connecteDeVoie() qui n'est appelée (toujours pour le moment) que par les objets "Voie" pourrait (devrait ?) être déclarée comme protected ?

Clairement cela ne change rien pour le fonctionnement du code dans son état actuel, mais quand je me pose une question j'aime bien aller au bout, cela m'aide à progresser en C++ qui n'est pas mon langage de prédilection.

[Jean-Luc]

Bonjour Jack

Non, il n'y a pas de raison particulière. Je pense qu'à terme tousLesCheminsVers sera protected et appelée via une interface publique dans Voie (c'est déjà le cas avec cheminVers). C'est en développement, tout les petits tas de poussière ne sont pas nettoyés

[DDEFF]

Grand nouveauté sur Locoduino : un programme qui écrit … un programme Arduino !

Dès le début, j'ai bien aimé ce programme de Jean-Luc.
D'abord, il s'intéressait à une gare que je connaissais bien : la mienne …


Ensuite, comme expliqué, ce programme trouve tous les itinéraires, sans autre préalable que de décrire le réseau dans le .ino.
C'est-à-dire qu'il cherche tout seul tous les itinéraires possibles : on n'a pas besoin de les décrire un par un. Tant mieux, il y en a 241 ! 

Cependant, cette description du grill de la gare, bien que d'une grande logique, n'est pas aussi simple qu'on le penserait de prime abord.

Aussi, je me suis dit que j'allais la faire écrire par l'ordi, sans intervenir directement.

Je commence par du très simple : mettre tout ce qui concerne le réseau dans le même onglet.

Donc, je crée un onglet "Specifs" (sans accent).
Je mets dedans :
enum { … }
La création des objets (voies, aiguilles, TJD, …)
La table des sources
La table des destinations
Le void afficheNomVoie { … }
Jusque là, ce sont de simples copier-coller. On démarre cool.
Je mets tout au début du .ino un #include "Specifs.h" pour que l'Arduino s'y retrouve.

Pour les connexions des voie, cette fois dans le setup(), il faut créer un void()
Je crée donc void export_setup() { … } dans Specifs, que j'appelle depuis le setup().
Un dernier copier coller des connexions de voies et c'est fini.

Une vérification pour voir qu'on n'a rien oublié ni raté une ligne et le programme fonctionne comme avant. C'était bien la peine…

Mais, avez-vous remarqué que pour créer l'onglet dans l'IDE de l'Arduino, il ne vous a pas demandé le nom de l'onglet, mais le nom du fichier correspondant. Et c'est là qu'est la première astuce : tout ce que je dois créer, c'est un simple fichier texte : Specifs.h !

Si je veux changer de réseau, j'ai juste à changer de Specifs.h. C'est dur de faire plus simple.

Reste un "détail" : générer ce fichier…

C'est là que j'utilise mon programme de TCO en Processing.

En deux mots :

1°) Je dessine mon réseau, en positionnant des petits cubes.


2°) Je regroupe les cubes en cantons en leur affectant un numéro (de 101 à 255) et je numérote de la même façon les aiguilles  (de 1 à 100). J'utilise la touche CTRL et la touche M (pour "memorize").


3°) Une petite analyse, pour voir s'il reste des erreurs (cubes isolés, …) et mise en forme des cantons.
Un simple appui sur A (pour "analysis"). Corrections des erreurs trouvées.

4°) Je sélectionne les voies entrantes de la gare, avec CTRL et quand je les ai toutes, j'appuie sur I (pour "in")

5°) Je sélectionne les voies sortantes de la gare, avec CTRL et quand je les ai toutes, j'appuie sur O (pour "out")

6°) J'appuie sur R (pour "Route", faux ami pour itinéraire).

Et c'est fini.
J'ai, non seulement un TCO sur mesure à l'écran, mais aussi un fichier Specifs.h !
L'affichage du TCO serait presque accessoire (alors que c'est quand même l'essentiel)…

Maintenant, je copie ce fichier Specifs.h pour remplacer celui existant dans la directory du programme Arduino. Et ça marche.

Quelques précisions :

1°) Le programme de Jean-Luc utilise des "voies libres", c'est-à-dire des voies qui sont bien reliées côté gare et "en l'air" vers l'extérieur.
Je n'ai pas retenu cette notion qui n'existe pas dans la réalité, mais dont je comprends parfaitement l'utilité dans ce programme, dans son état actuel.
Les curieux auront remarqué que j'ai donc mis des voies de garage à chaque entrée sortie. Pas très réaliste non plus…
C'est donc un point à creuser dans l'avenir.

2°) J'ai donc un peu modifié le programme de Jean-Luc en retirant les tests de debug au départ (qui font allusion aux voies libres). Mais qui ne sont pas nécessaires au fonctionnement.

3°) Evidemment, j'ai essayé avec le réseau de Dominique que j'utilise dans mes articles.
Le fichier Specifs.h est bien créé, mais il ne fonctionne pas avec l'Arduino.
Est-ce parce qu'il est bouclé ?? Je ne sais pas.

4°) J'ai aussi changé le mot "aiguillage" que j'ai remplacé par "aiguille" (on n'est pas pinailleur pour rien  ). Je vais essayer d'ajouter les TJS et les triples, mais c'est plus sournois qu'il y paraît.

Et maintenant ?

"Que vais-je faire ?", disait Becaud.
Moi, rien.
Mais j'aimerais bien que Jean-Luc puisse trouver un peu de temps libre pour continuer son magnifique programme.

Parce qu'en l'état actuel, il trouve en un temps record tous les itinéraires d'une gare (et, j'en suis sûr, d'un réseau complet). Mais d'un point A à un point B, il en trouve "trop". Lequel choisir ?

Donc, à suivre.

En PJ : mon TCO en Processing, version 3.8 et le fichier de Jean-Luc avec les quelques modifs décrites et qui marche avec mon Specifs.h

[DDEFF]

Finalement, j'ai continué 

Parce que le réseau de Dominique ne marchait pas et que ça n'était pas dû au programme de Jean-Luc, mais au mien ... 
J'ai donc retroussé mes manches et j'ai revu l'onglet Analysis qui a connu une simplification drastique.
Maintenant, c'est beaucoup plus simple, plus facile à comprendre et plus carré.
J'ai revu l'onglet routes et, là, seulement quelques bricoles.
C'est quand même sympa, la récursivité... 

Et maintenant, les deux fonctionnent parfaitement 

J'ai volontairement retiré les // devant la trace de l'onglet debug => c'est plus long. Soyez patients : ça s'arrête bien à la fin dans la fenêtre du moniteur.
Vous pourrez toujours remettre les //, bien sûr.

Ce qui veut dire, entre autres, que le programme de Jean-Luc fonctionne avec un réseau bouclé.

A suivre 

[Dominique]

Bravo Denis,

Heureusement que tu peux faire les questions et les réponses, en ce qui concerne mon réseau, car je ne peux pas faire tourner Processing à cause de la version de Java que je ne peux (et veux) pas mettre à jour.

Alors tu peux me dire combien d'itinéraires sont possibles sur mon réseau ?

Amicalement
Dominique

[DDEFF]

Il en trouve 26 et 2 impossibles.
Mais je n'ai pas compris lesquels ... 

Je m'explique :

1°) je te fournis le plan de ton réseau avec ma numérotation (celle du programme TCO et de SGDD).

2°) Je te fournis aussi le programme Arduino de Jean-Luc, avec la version ton réseau.
Celui-là, tu peux le téléverser sur un Arduino DUE et voir ce qu'il donne.

L'onglet Specifs.h est la description, "comme Jean-Luc" cette fois, de ton réseau.

Pour t'aider je te joins aussi le fichier tansform.txt qui est la traduction numérotation DD -> numérotation JLB.
(numérotation DD = 1000+numérotation DD du plan pour que tout soit bien aligné)
Ce fichier ne sert à rien d'autre qu'à nous aider, pauvres humains 
Il est quand même généré par l'ordi, sans intervention humaine.

En retirant les // pour voir les tâches, tu verras comment travaille le programme de Jean-Luc.
Et tu comprendras ma réponse du début 

[DDEFF]

Trouvé les 25 :



Ce qui correspond à ce que je lui ai demandé :
Origine     : VOIE_GARAGE_1, VOIE_GARAGE_5 et VOIE_GARAGE_6
Extrémité : VOIE_GARAGE_0, VOIE_GARAGE_2, VOIE_GARAGE_3 et VOIE_GARAGE_4

Et les deux impossibilités sont donc : VOIE_GARAGE_5 vers VOIE_GARAGE_0 ou VOIE_GARAGE_1, ainsi que VOIE_GARAGE_6 vers VOIE_GARAGE_0 ou VOIE_GARAGE_1

On peut demander individuellement ce qu'on veut (un peu plus haut dans le programme).
Ex VOIE_21 -> VOIE_20
Il trouve les 4 solutions :
Via la VOIE_2, la VOIE_3, la VOIE_4 ou la VOIE_5, prenant le périphérique intérieur ou le périphérique extérieur 

Je savais que ce programme était génial ! Bravo Jean-Luc !

Pour transformer les numéros de voie DD -> nom des voies JLB, utiliser le fichier Transform.txt (post précédent).
Je conseille d'imprimer le plan avec mes numéros et d'écrire dessus les noms de Jean-Luc.
Comme ça, c'est plus facile à suivre.

Moyennant quelques modifs simples, je vais l'adapter au port série et lui faire échanger avec mon programme de commandes, cette fois.
Je lui demanderai sur le TCO par où je démarre (CTRL, clic souris sur le canton puis I (= in) et où je veux aller (CTRL, clic souris sur le canton puis O (= out))
Et il me sortira la liste des itinéraires.

Reste une question à la quelle on ne sait pas répondre : lequel choisir ?
"A que" on est bien embêtés  , d'autant que cette réponse doit être dynamique, en fonction des itinéraires demandés et des présences des autres trains...

A suivre 

[DDEFF]

Je prends un autre exemple :
Faire un circuit 107, 110, 112, 114, 115, 117, 124, 131.
On indique à la ligne 115 ce qu'on veut :

Code: [Sélectionner]

  testItineraire(VOIE_4, VOIE_23);(en suivant bien ce que le fichier Transform.txt a dit)

Réponse dans la fenêtre du moniteur :

Code: [Sélectionner]

Gestionnaire reseau
Nombre de voies : 50
**** Test des ensembles ****
VOIE_4
    AIGUILLE_10
        VOIE_23
================
*vide*
================

Ajout de VOIE_23
================
VOIE_23
================

Ajout de AIGUILLE_10
================
VOIE_23 AIGUILLE_10
================

Ajout de VOIE_4

Qui se lit comme suit :

VOIE_4
AIGUILLE_10 = AIGUILLE_1 (les numéros d'aiguille sont multipliés par 10. Je ne sais pas quelle est la raison)
VOIE_23.

Puis la construction :

Ajout de VOIE_23
Ajout de AIGUILLE_10
Ajout de VOIE_4

C'est dans le sens DIRECTION AVANT.

Pour l'autre sens, il faut aller modifier la ligne 31 en DIRECTION_ARRIERE.
Et téléverser.

Ce qui donne dans le moniteur série, en vous faisant grêce du début :

Code: [Sélectionner]

================
VOIE_7 VOIE_9 VOIE_11 VOIE_12 VOIE_14 VOIE_19 VOIE_23 AIGUILLE_40 AIGUILLE_50 AIGUILLE_70 AIGUILLE_80 AIGUILLE_90 AIGUILLE_150 AIGUILLE_160
VOIE_7 VOIE_9 VOIE_11 VOIE_12 VOIE_14 VOIE_20 VOIE_23 AIGUILLE_40 AIGUILLE_50 AIGUILLE_70 AIGUILLE_80 AIGUILLE_90 AIGUILLE_150 AIGUILLE_160 TJD_0 TJD_1
VOIE_7 VOIE_9 VOIE_11 VOIE_12 VOIE_14 VOIE_17 VOIE_23 AIGUILLE_40 AIGUILLE_50 AIGUILLE_60 AIGUILLE_100 AIGUILLE_110 AIGUILLE_150
VOIE_7 VOIE_9 VOIE_11 VOIE_12 VOIE_14 VOIE_18 VOIE_23 AIGUILLE_40 AIGUILLE_50 AIGUILLE_60 AIGUILLE_110 AIGUILLE_150
================

Ajout de VOIE_4

Il y a cette fois 4 façons d'aller de la VOIE_4 à la VOIE_23.
On peut passer par la VOIE_17, la VOIE_18, la VOIE_19 et la VOIE_20
N'oubliez pas, les numéros d'aiguilles sont multipliés par 10...

Ce que je retiens, c'est que ce magnifique programme résout de façon entièrement automatique la problématique d'aller d'un point A à un point B, sur absolument n'importe quel réseau.

Il donne toutes les solutions.

S'agissant d'un cœur de programme, la partie intelligente si vous voulez, la partie communication avec l'extérieur, aussi bien en entrée qu'en sortie n'a pas été développée. Mais, justement, chacun peut développer la sienne.

J'ai apporté ma pierre en simplifiant l'entrée des données, elle aussi automatisée. On a juste à "jouer aux cubes"... 

Je vais m'attacher maintenant à communiquer avec ce programme Arduino via le bus série et mon programme "Commande.pde" écrit en Processing.

La suite sur mon post http://forum.locoduino.org/index.php?topic=211.0 
 

[DDEFF]

"Houston ?
We have a problem"...

J'ai progressé dans ma compréhension du fonctionnement du programme de Jean-Luc.
Je pense même que j'ai trouvé comment choisir le meilleur itinéraire parmi ceux trouvés.
Mais je bloque sur la façon de programmer cette fonction.

Le point aujourd'hui :

Il y a 93 éléments dans ma gare :

- 37 voies normales (ou de liaisons).
- 10 "voies libres", selon la dénomination de Jean-Luc, qui sont vouées, à terme, à devenir des voies normales.
       Mais qui, en l'état actuel du programme, sont nécessaires car elles évitent d'avoir à décrire le reste du réseau.
- 11 voies de garage
- 15 aiguilles
- 17 TJD
- 3 croisements

Comme on donne en clair les éléments au départ (maintenant dans Specifs.h), le programme n'a aucun mal à les dénombrer.
Il crée une matrice uniligne pour marquer ces éléments.
Au départ, un peu trop grande (il ne sait pas combien d'éléments il va trouver), puis retaillée au bon format, à savoir 24 octets ici.

(Au passage : Excellente idée, à réutiliser sans modération).

En effet, à 2 bits par élément, il faut au moins 93*2 bits, soit un peu moins de 24 octets.
Les bits d'ordre pair marquent le fait qu'on utilise un élément en y mettant un 1.
Les bits d'ordre impair marquent le sens dans lequel on parcoure l'élément.

Si vous voulez voir ça, il faut ajouter dans l'onglet Debug :
#define TRACE2

Comme cette matrice est triée dans l'ordre donné plus haut (voies, voies libres, voies de garage, aiguilles, TJD, croisements), il s'ensuit que quand on donne la liste des éléments formant l'itinéraire, cette liste est triée de cette façon.

Mais il manque d'autres notions si on veut utiliser mon idée.

Un bon schéma valant plus qu'un discours, je (re)prends l'exemple de ma gare.



Je veux aller de la voieLibre0 vers la voieGarage6 sur ce schéma.
L'Arduino me trouve quand même pas moins de 12 (!!) façons de réaliser cet itinéraire.

Code: [Sélectionner]

################
De VOIE_LIBRE_0 a VOIE_GARAGE_6
================
VOIE_LIBRE_0 VOIE_0 VOIE_3 VOIE_21 VOIE_30 VOIE_34 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_10 AIGUILLE_14 TJD_0 TJD_8 TJD_12 TJD_14 CROISEMENT_2
VOIE_LIBRE_0 VOIE_0 VOIE_3 VOIE_21 VOIE_29 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_14 TJD_0 TJD_8 TJD_12 TJD_14 TJD_16 CROISEMENT_2
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_6 VOIE_12 VOIE_26 VOIE_30 VOIE_34 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_10 AIGUILLE_14 TJD_0 TJD_1 TJD_2 TJD_11 TJD_14
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_6 VOIE_12 VOIE_26 VOIE_29 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_14 TJD_0 TJD_1 TJD_2 TJD_11 TJD_14 TJD_16
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_18 VOIE_25 VOIE_28 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_8 AIGUILLE_14 TJD_0 TJD_1 TJD_2 TJD_4 TJD_6 TJD_10 TJD_16 CROISEMENT_0
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_19 VOIE_28 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_8 AIGUILLE_14 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_16
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_20 VOIE_26 VOIE_29 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_14 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_11 TJD_14 TJD_16
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_20 VOIE_26 VOIE_30 VOIE_34 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_10 AIGUILLE_14 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_11 TJD_14
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_8 VOIE_29 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_14 TJD_0 TJD_1 TJD_12 TJD_14 TJD_16 CROISEMENT_2
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_8 VOIE_30 VOIE_34 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_10 AIGUILLE_14 TJD_0 TJD_1 TJD_12 TJD_14 CROISEMENT_2
VOIE_LIBRE_0 VOIE_1 VOIE_21 VOIE_29 VOIE_33 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_14 TJD_8 TJD_12 TJD_14 TJD_16 CROISEMENT_2
VOIE_LIBRE_0 VOIE_1 VOIE_21 VOIE_30 VOIE_34 VOIE_GARAGE_6 AIGUILLE_0 AIGUILLE_10 AIGUILLE_14 TJD_8 TJD_12 TJD_14 CROISEMENT_2
================
J'affirme que l'itinéraire suivant, venant de la gauche, est le meilleur :
VoieLibre0 -> Aiguille0 (droite) -> Voie1 -> TJD8 (tout droit) -> Voie21 -> Croisement2 -> TJD13 (droite) -> Voie30 -> Aiguille10 (gauche) -> Voie34 -> Aiguille14 (talon) -> VoieGarage6.

Et pourquoi est-ce le meilleur ?
Parce qu'il réserve le maximum de place aux autres itinéraires. Il améliore donc grandement la fluidité des déplacements.

Donc, le raisonnement est le suivant :

Quand on vient de la gauche, il faut tourner le plus rapidement possible à droite (pour dégager la première diagonale) et ainsi de suite.
Evidemment, quand on vient de la droite, il faut tourner le plus rapidement possible à gauche.

Ce qui suppose d'amener ces deux notions dans le programme de Jean-Luc :
- sortie d'un élément multiple (aiguille, TJD, croisement) par la gauche ou la droite
- ordre dans lequel les éléments sont abordés par le train

Il y a en effet dans mon raisonnement une notion d'ordre. Il ne suffit pas de compter le nombre de fois où on tourne à droite, par exemple. Il faut aussi savoir si c'est au début, ou pas, de l'itinéraire.
Tourner à droite est d'autant plus efficace qu'on le fait tôt.

Donc, j'ai modifié les dessins du début de ce fil, pour tenir compte de la gauche et de la droite.

Voici mes nouveaux schémas (moins beaux, OK) 



On remarque que, maintenant, je distingue les aiguilles gauches des aiguilles droites.
Dans le programme, on garde aussi Droit et Dévié pour tenir compte des longueurs des branches.

J'ai donc une nouvelle version de TCO qui génère le nouveau fichier Specif.h et, bien sûr, la nouvelle version de Gestionnaire_JLB_DD.ino.

Par exemple, de la voie de garage 0 (dans ma notation) à la voie de garage 16 (dans ma notation), ça donne :

Code: [Sélectionner]

###################################################
De VOIE_GARAGE_0 a VOIE_GARAGE_16
================
VOIE_0 VOIE_3 VOIE_21 VOIE_30 VOIE_34 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_2 AIGUILLE_D_70 AIGUILLE_G_00 AIGUILLE_G_40 TJD_0 TJD_8 TJD_12 TJD_14
VOIE_0 VOIE_3 VOIE_21 VOIE_29 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_2 AIGUILLE_D_70 AIGUILLE_G_00 TJD_0 TJD_8 TJD_12 TJD_14 TJD_16
VOIE_0 VOIE_2 VOIE_6 VOIE_12 VOIE_26 VOIE_30 VOIE_34 VOIE_GARAGE_0 VOIE_GARAGE_16 AIGUILLE_D_70 AIGUILLE_G_00 AIGUILLE_G_40 TJD_0 TJD_1 TJD_2 TJD_11 TJD_14
VOIE_0 VOIE_2 VOIE_6 VOIE_12 VOIE_26 VOIE_29 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 AIGUILLE_D_70 AIGUILLE_G_00 TJD_0 TJD_1 TJD_2 TJD_11 TJD_14 TJD_16
VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_18 VOIE_25 VOIE_28 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_0 AIGUILLE_D_40 AIGUILLE_D_70 AIGUILLE_G_00 TJD_0 TJD_1 TJD_2 TJD_4 TJD_6 TJD_10 TJD_16
VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_19 VOIE_28 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 AIGUILLE_D_40 AIGUILLE_D_70 AIGUILLE_G_00 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_16
VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_20 VOIE_26 VOIE_29 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 AIGUILLE_D_70 AIGUILLE_G_00 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_11 TJD_14 TJD_16
VOIE_0 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_20 VOIE_26 VOIE_30 VOIE_34 VOIE_GARAGE_0 VOIE_GARAGE_16 AIGUILLE_D_70 AIGUILLE_G_00 AIGUILLE_G_40 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_11 TJD_14
VOIE_0 VOIE_2 VOIE_8 VOIE_29 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_2 AIGUILLE_D_70 AIGUILLE_G_00 TJD_0 TJD_1 TJD_12 TJD_14 TJD_16
VOIE_0 VOIE_2 VOIE_8 VOIE_30 VOIE_34 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_2 AIGUILLE_D_70 AIGUILLE_G_00 AIGUILLE_G_40 TJD_0 TJD_1 TJD_12 TJD_14
VOIE_1 VOIE_21 VOIE_29 VOIE_33 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_2 AIGUILLE_D_70 AIGUILLE_G_00 TJD_8 TJD_12 TJD_14 TJD_16
VOIE_1 VOIE_21 VOIE_30 VOIE_34 VOIE_GARAGE_0 VOIE_GARAGE_16 CROISEMENT_2 AIGUILLE_D_70 AIGUILLE_G_00 AIGUILLE_G_40 TJD_8 TJD_12 TJD_14
================
Information importante :

Le choix d'un itinéraire ne peut pas être fixe, à partir d'une liste qu'on donnerait dès le départ.
Dans le cas précédent, on a trouvé qu'il fallait passer par la voie 1. Et décrit l'itinéraire qui passe par là.

Supposons qu'on ait perdu un wagon justement voie 1. Si le choix de l'itinéraire est fixé, il faudra attendre d'avoir dégagé le wagon de la voie 1 pour pouvoir faire l'itinéraire de la voie de garage 0 à la voie de garage 16.

Si l'allocation d'itinéraire est dynamique, le programme va passer par la voie 3 et le tour est joué.

Il s'ensuit que la définition des itinéraires va devoir tenir compte des occupations de zones…

Et voilà

Je suis donc dans une situation où j'ai une idée très précise de ce qu'il faudrait faire … sans savoir le faire !

"Houston ?
We have a problem"…