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

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #15 le: mars 09, 2016, 12:14:20 pm »
A part ça, la compil ne marche pas...  :(

Message :
Arduino : 1.6.7 (Windows 10), Carte : "Arduino Due (Programming Port)"
GrapheReseauDDEFF:23: error: conflicting declaration 'SerialEmulation Serial'
 SerialEmulation Serial;
                 ^
In file included from C:\Users\PARENTS1\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.6\cores\arduino/Arduino.h:189:0,
                 from sketch\GrapheReseauDDEFF.ino.cpp:1:

C:\Users\PARENTS1\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.6\variants\arduino_due_x/variant.h:245:18: error: 'Serial' has a previous declaration as 'UARTClass Serial'

 extern UARTClass Serial;
                  ^
exit status 1
conflicting declaration 'SerialEmulation Serial'

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1250
  • 100% Arduino et N
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #16 le: mars 09, 2016, 12:30:34 pm »
Ça compile bien sur un Mega !

Pour le Due, je l'ai vu aussi. C'est probablement parce que ce n'est plus un AVR, mais un Sam, non ?
La classe Serial est différente.

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #17 le: mars 09, 2016, 01:21:16 pm »
Et ça marche sur un UNO (je n'ai pas de MEGA). Tu dois avoir raison.

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1199
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #18 le: mars 09, 2016, 01:37:36 pm »
Effectivement, mon émulation pour Mac (et Unix en général, ça compilera sous Linux et sans doute sous Windows) casse la compilation pour un Arduino à base d'ARM

Voici une version à jour qui compile sur Due. Hier soir j'ai également commencé à travailler sur les itinéraires et les ensembles d'itinéraires. il y a donc de nouvelles classes qui ne sont pas utilisées pour le moment. Le sketch actuel fait la même chose que celui que j'ai déjà posté.

J'ai également commencé à mettre le code en plusieurs fichiers de manière à ne laisser dans le sketch que ce qui est propre au réseau.

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #19 le: mars 09, 2016, 02:57:52 pm »
Si je voulais être caustique, je dirais qu'il fait la même chose que l'ancien : il n'affiche toujours rien ... :D :D
Mais il compile sur DUE, effectivement, et sur un UNO.
J'ai dû oublier quelque chose  ???

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1199
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #20 le: mars 09, 2016, 03:09:34 pm »
Tu as connecté le DUE via le programming port ?

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #21 le: mars 09, 2016, 04:45:10 pm »
Arduino DUE connecté en USB sur le programming port, comme je l'ai toujours fait...
Je suis en version 1.6.7
La compil se passe bien, le téléversement aussi.
Dans "outils", je suis sur programmateur : "arduinoISP".
Voir copie écran jointe.

Et quand je clique sur la loupe à droite (moniteur série), il ne se passe rien.

Tu as mis le DEBUG en Debug.h.
J'ai essayé de mettre #include "debug.h" dans GrapheReseau, mais le compilateur me parle mal  :)



Arduino : 1.6.7 (Windows 10), Carte : "Arduino Due (Programming Port)"

In file included from R:\Documents publics\_Trains\Locoduino\Jean-Luc\GrapheReseau\GrapheReseau\GrapheReseau.ino:3:0:

Debug.h:6: error: default argument given for parameter 2 of 'void afficheNomVoie(byte, bool)' [-fpermissive]

 extern void afficheNomVoie(byte id, bool aLaLigne = false);
                                                          ^
In file included from sketch\Voie.h:7:0,

                 from R:\Documents publics\_Trains\Locoduino\Jean-Luc\GrapheReseau\GrapheReseau\GrapheReseau.ino:1:

Debug.h:6: error: after previous specification in 'void afficheNomVoie(byte, bool)' [-fpermissive]

 extern void afficheNomVoie(byte id, bool aLaLigne = false);
             ^
exit status 1
default argument given for parameter 2 of 'void afficheNomVoie(byte, bool)' [-fpermissive]
« Modifié: mars 09, 2016, 04:51:58 pm par DDEFF »

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1199
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #22 le: mars 09, 2016, 07:08:47 pm »
Encore mon histoire d'émulation qui joue des tours. Du coup j'ai tout viré. L'archive mise à jour est à télécharger ci-dessous.

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #23 le: mars 10, 2016, 08:58:50 am »
PEBCAK...
Maintenant, fonctionnement parfait.
Merci Jean-Luc

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #24 le: mars 11, 2016, 09:39:22 am »
La nuit porte conseil...  :P
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'à ...  ;D ;D

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1199
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #25 le: mars 11, 2016, 10:03:41 am »
Oui mais moi je ne veux pas faire cette phase d'analyse à la main. En fait je ne veux pas faire d'analyse du tout.

1) c'est fastidieux
2) tu peux te tromper (c'est même une garantie si c'est gros)

Comment sais tu que tu as trouvé tous les itinéraires de ton réseau ? 432 est faux il y en a plus car tu as plusieurs chemins intermédiaires entre les doubles diagonales. Par exemple, entre VoieLibre0 et VoieGarage7, tu as 5 itinéraires si mon compte est bon.

108 est également faux car tu ne peux pas aller de VoieLibre0 à VoieLibre9 sans changer de sens.

Enfin il n'y a pas que les extrémités qui nous intéressent. Il faut également construire les itinéraires permettant d'amener à une voie en particulier, à quai par exemple, qui n'est pas une voie extrême.
« Modifié: mars 11, 2016, 10:13:56 am par Jean-Luc »

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #26 le: mars 11, 2016, 10:29:12 am »
Citer
Comment sais tu que tu as trouvé tous les itinéraires de ton réseau ? 432 est faux il y en a plus car tu as plusieurs chemins intermédiaires entre les doubles diagonales. Par exemple, entre VoieLibre0 et VoieGarage7, tu as 5 itinéraires si mon compte est bon.
Tu as raison : c'est plus que 432, car tu as effectivement tu as des fois plus de 2 itinéraires pour 2 extrémités données.
Donc, le nombre d'itinéraires possibles est plus élevé.

Citer
108 est également faux car tu ne peux pas aller de VoieLibre0 à VoieLibre9 sans changer de sens.
108, c'était un maximum.
En fait, il y a 36 couples origine-extémité qui sont carrément impossibles.

Je veux bien ne pas faire d'analyse (surtout à la main, ce que je n'ai jamais fait), mais il faut quand même prioriser des choses, avoir des critères ?

DDEFF

  • Sr. Member
  • ****
  • Messages: 445
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #27 le: mars 11, 2016, 01:49:46 pm »
C'est quand même un sacré site que LOCODUINO : on en est quand même à la troisième (!!) possibilité de modéliser un réseau... ;D
Pour un seul site, c'est bien une preuve de vitalité !
Comme ils disent dans la pub : le plus dur, c'est de choisir...

Thierry

  • Global Moderator
  • Sr. Member
  • *****
  • Messages: 400
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #28 le: mars 11, 2016, 02:23:17 pm »
Blouge. C'est bien, blouge...

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1199
    • Voir le profil
Re : Modélisation logicielle d'un réseau - le système de Jean-Luc
« Réponse #29 le: mars 11, 2016, 03:44:27 pm »
J'ai avancé hier soir.

J'ai ajouté la méthode tousLesCheminsVers aux voies. Il s'utilise comme creeCheminVers mais prend un argument supplémentaire : un ensemble d'itinéraires. Au retour cet ensemble contient tous les itinéraires possible pour aller de A à B.

Un itinéraire est un ensemble de voies (du point de vue ensembliste, c'est à dire qu'il n'y a pas d'ordre). Côté implémentation, un Itinéraire est un vecteur de bits implémenté sous la forme d'un tableau de N octets ou N est le nombre de voies / 8 + 1 quand la division ne tombe pas juste. Quand le bit de rang identifiant de la voie est à 1, la voie est présente dans l'itinéraire et absente sinon. Cela permet une représentation compacte d'une part et des opérations efficaces. Par exemple, des itinéraires sont compatibles si l'intersection des ensembles de voies qui les représente est vide. Il suffit de faire un & pour le savoir.

J'ai donc l'objet Itineraire et EnsembleItineraires.

Exemple:

  EnsembleItineraires iti3;
  voieLibre6.tousLesCheminsVers(VOIE_GARAGE_4, DIRECTION_AVANT, iti3);
  iti3.print();

crée un ensemble d'itinéraires iti3 qui est pour l'instant vide puis le remplit et enfin l'affiche. Il n'y a qu'un seul itinéraire possible entre voieLibre6 et voieGarage4. L'affichage est :

VOIE_LIBRE_6 VOIE_10 VOIE_20 VOIE_31 VOIE_GARAGE_4 AIGUILLE_3 AIGUILLE_4 AIGUILLE_11 TJD_3 TJD_7 TJD_11 TJD_15 CROISEMENT_0 CROISEMENT_2

  EnsembleItineraires iti4;
  voieLibre0.tousLesCheminsVers(VOIE_GARAGE_7, DIRECTION_AVANT, iti4);
  iti4.print();

produit :

VOIE_LIBRE_0 VOIE_0 VOIE_3 VOIE_21 VOIE_29 VOIE_GARAGE_7 AIGUILLE_0 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_29 VOIE_GARAGE_7 AIGUILLE_0 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_GARAGE_7 AIGUILLE_0 AIGUILLE_8 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_GARAGE_7 AIGUILLE_0 AIGUILLE_8 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_GARAGE_7 AIGUILLE_0 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_11 TJD_14 TJD_16
VOIE_LIBRE_0 VOIE_0 VOIE_2 VOIE_8 VOIE_29 VOIE_GARAGE_7 AIGUILLE_0 TJD_0 TJD_1 TJD_12 TJD_14 TJD_16 CROISEMENT_2
VOIE_LIBRE_0 VOIE_1 VOIE_21 VOIE_29 VOIE_GARAGE_7 AIGUILLE_0 TJD_8 TJD_12 TJD_14 TJD_16 CROISEMENT_2

7 itinéraires possibles

et enfin :

  EnsembleItineraires iti5;
  voieLibre1.tousLesCheminsVers(VOIE_GARAGE_2, DIRECTION_AVANT, iti5);
  iti5.print();

produit :

VOIE_LIBRE_1 VOIE_2 VOIE_8 VOIE_27 VOIE_32 VOIE_GARAGE_2 AIGUILLE_12 TJD_0 TJD_1 TJD_12 TJD_15
VOIE_LIBRE_1 VOIE_2 VOIE_6 VOIE_11 VOIE_16 VOIE_20 VOIE_32 VOIE_GARAGE_2 AIGUILLE_12 TJD_0 TJD_1 TJD_2 TJD_4 TJD_7 TJD_11 TJD_15 CROISEMENT_2
VOIE_LIBRE_1 VOIE_2 VOIE_6 VOIE_12 VOIE_32 VOIE_GARAGE_2 AIGUILLE_12 TJD_0 TJD_1 TJD_2 TJD_11 TJD_15 CROISEMENT_2
VOIE_LIBRE_1 VOIE_3 VOIE_21 VOIE_27 VOIE_32 VOIE_GARAGE_2 AIGUILLE_12 TJD_0 TJD_8 TJD_12 TJD_15
VOIE_LIBRE_1 VOIE_3 VOIE_22 VOIE_GARAGE_2 AIGUILLE_12 TJD_0 TJD_8

5 itinéraires possibles

J'ai laissé la trace de recherche dans le programme pour voir le cheminement.

Ça ne tourne plus sur le Uno par manque de SRAM (le tas vient télescoper la pile)

J'ai mis le code sur le dépôt git : https://git.framasoft.org/locoduino.org/GestionnaireReseau/tree/master

Téléchargement direct : https://git.framasoft.org/locoduino.org/GestionnaireReseau/repository/archive.zip?ref=master

Vous pouvez vous amuser avec.

La suite : étant donné N ensembles d'itinéraires former si possible des itinéraires compatibles.
« Modifié: mars 11, 2016, 04:49:44 pm par Jean-Luc »