La nuit porte conseil...
La chose la plus difficile à comprendre dans SGDD, c'est cette histoire de niveaux. En plus, saisie manuelle.
D'un autre côté, la saisie manuelle permet d'influencer les choix de l'Arduino.
Comment optimiser et surtout automatiser ?
Pour optimiser les itinéraires, il faut faire comme en réalité, avec un maître mot :
fluiditéIl faut donc arriver à donner un "poids" aux itinéraires. C'est la phase d'analyse. On ne la fait qu'une fois.
Soit on la fait à part en on inscrit les résultats "en dur" dans la programme d'exploitation, soit on la met dans le setup() et c'est automatique.
1°) Il faut trouver tous les itinéraires.
Combien y en a-t-il ?
Dans ma gare, 9 origines (à gauche) et 12 extrémités (à droite).
Donc 9 x 12 = 108 itinéraires. Deux sens => 216 itinéraires.
Une bonne partie des itinéraires ont 2 solutions à cause des doubles diagonales => 432 est une borne supérieure.
C'est beaucoup pour un humain, mais pas trop pour un Arduino. Et, là dedans, 180 itinéraires utiles.
En "largeur" de la matrice, on a un maxi de 11 (itinéraire voieLibre0 -> voieLibre7)
2°) Il faut donner un poids à chaque aiguille.
A chaque fois qu'une aiguille est utilisée dans un itinéraire, on lui ajoute 1, en faisant le tour de tous les itinéraires.
On a donc un mini de 4 pour une aiguille donnée (aiguille = 2 itinéraires mini, dans les 2 sens) et un maxi de ... on ne sait pas.
Je ne serais pas surpris qu'on atteigne les 25-30.
Un poids de 20 indique que cette aiguille est impliquée dans 0 itinéraires.
3°) En ayant le poids de chaque aiguille, on va pouvoir donner le poids de chaque itinéraire en additionnant.
Et plus un itinéraire est "lourd", plus il bloque d'autres itinéraires et plus il contrarie la fluidité.
Et donc plus il faut le faire tard !
On a ainsi une donnée supplémentaire dans l'objet "itinéraire" : son poids, calculé une fois pour toute dans le setup().
Maintenant, on va élaguer cette liste en ne gardant que les itinéraires de plus faible poids quand il y en a deux pour un même coupe origine-extrémité.
Et c'est là qu'on arrive à "seulement" 180 itinéraires.
Une autre variable des itinéraires est "l'heure" à laquelle il va être demandé, heure qui va servir à savoir quand on va pouvoir le lancer.
Le principe du "time sharing" me paraît la méthode la plus adaptée à notre problème.
C'est une méthode qui sert dans les serveurs. Vieille méthode et donc éprouvée.
Le principe est le suivant :
Plusieurs itinéraires doivent être exécutés en même temps.
Comme on ne peux pas les faire vraiment en même temps, on va leur donner une priorité dynamique.
1°) On note l'heure de la demande.
2°) On note le poids de l'itinéraire. On effectue en priorité les itinéraires courts, ce qui réduit la liste (fluidité toujours)
3°) Au bout d'un "certain temps", on effectue des itinéraires plus lourds, même s'ils bloquent tout (ex : voieLibre0 -> voieLibre7) parce qu'il faut aussi que ces itinéraires soient faits.
Voilà.
Y'a plus qu'à ...
