Le tableau de commande de Mars Bleu

[antoo]

C'est top que tu partages tout ça! Avec notre simu Apollo, on avance tranquillement, on vous mettra des infos avant l'été .
A+

[nulentout]

Elles sont belles tes cartes électroniques, visiblement tu aimes le travail bien fait. 
La réussite sera forcément la conclusion de ton entreprise avec la satisfaction qui va avec ...

[Mars Bleu]

@Antoo: simu Apollo? J'ai hâte de voir. Ça doit être bien pointu, ça.
Ce qui m'intéressera particulièrement de voir, ce sont les commandes qui n'ont pas
de raccourci clavier.
@ Nulentout: merci! Et, oui, j'essaie de faire de mon mieux, en utilisant
mon expérience professionnelle passée. Quelque chose de bien organisé
est clair et dépannable. Je devrais y arriver, même si, parfois, je galère un
peu. (En ce moment, je bute toujours sur mes roues codeuses...)

[antoo]

Ce qui m'intéressera particulièrement de voir, ce sont les commandes qui n'ont pas
de raccourci clavier.

C'est en effet le plus gro défi... et je me réjouis de vous dire que ça le fait . On vous partagera tout ça quand on aura trouvé de quoi imprimer un EMS en ABS. Il est question de faire un mod, qui prend cela en charge. N'hésite pas à demander si tu veux plus d'infos .

A+

[Mars Bleu]

 

[Mars Bleu]

Voici la suite de mes élucubrations, avec le.....
                                        SIXIÈME CHALLENGE: construire les cartes SIPO

Tout comme les modules PISO, il y a un gros travail de soudure, de vérification des continuités électriques, de vérification d'absence de court-circuit, du sens de montage des circuits intégrés, du bon fonctionnement en général. Pour l'instant j'ai monté trois modules SIPO, ce qui me donne la possibilité de piloter 8x12x3=288 sorties.
Pour le premier module, j'ai soudé les 96 résistances de 330Ω sur la plaque ne supportant pas les registres SIPO.




L'expérience montre que ça multiplie les connecteurs, et donc complication et temps passés: à éviter. Je recommande donc de mettre les résistances en série avec les leds directement sur la carte où se trouvent les leds.
Voilà le module SIPO simplifié:



Je mets la petite plaque ci-dessous au cul de la led, en faisant attention au sens de branchement. Pas brancher en direct les leds à la sortie des 74HC595 sinon, led fichue, mais ça vous le savez déjà.



Pour la mise au point, j'ai bien sûr, commencé avec une seule série de 12 registres 74HC595, puis avec deux, et enfin avec les trois séries de 12 registres.
Avec deux séries de registres, j'ai commencé à avoir des problèmes de transmission de DATA à travers l'ensemble des 74HC595. J'ai équipé l'ensemble des 74HC595 de capas de découplage de 1μF entre Vcc et GND, mais je n'ai pas obtenu d'amélioration. En fait, la solution venait par l'agencement des câbles CLK et LATCH: je faisais passer de module en module les fils CLK et LATCH, alors qu'il fallait à chaque fois partir de la carte de support de la UNO. Cette modification de câblage effectuée, il n'y a plus eu de problème dans mes registres SIPO.

La fonction de remplissage des registres a été montrée plus haut. Si on doit rajouter des registres, parce que 288 sorties ne sont pas suffisantes, il faut juste changer la valeur de NumberSIPOreg à la déclaration des variables, afin de l'ajuster au nombre de 74HC595.

Je vous laisse profiter de tout ça. La suite, ça va être de voir comment on initialise tout ça en soft. Amateurs de C, préparez vous!!

[antoo]

Quel travail de pro! Bravo !

[jacquesmomo]

Bravo pour le "rangement" des fils et connecteur ! comme le dis antoo : travail de pro...

[Mars Bleu]

Merci, les gars, ça fait toujours plaisir de lire de tels posts.
Maintenant, faut voir la table où je monte tout ça, c'est assez
fouillis (c'est le principe entropique!  ).

[Mars Bleu]

                          Et voici la suite de mes élucubrations!

J'ai donc obtenu un système à 144 entrées et 288 sorties. On va pouvoir aborder la programmation de l'initialisation du cockpit en ce qui concerne les auxiliaires fonctionnant avec l'APU. Sur le Xr2, c'est :

   -Gear                            -Airbrakes
   -Radiator                       -Hatch
   -Retrodoors                   -Hoverdoors
   -Scramdoors                  -Baydoors
   -Innerdoor                     -Chamber (ici, pas de raccourci clavier)
   -Outerdoor                    -Nosecone
             Et enfin, l'APU.



Au total 11 auxiliaires dont il faut connaître l'état, et la position. Chamber est un cas particulier, car on n'a pas de raccourci clavier pour la gestion de ce paramètre. APU aussi, car il commande tout le reste, et on ne tient pas compte du temps d'un éventuel démarrage ou arrêt à l'initialisation. (Constatation faite sur le terrain)

L'idée étant d'avoir un code aussi compact que possible, le mieux a été de stocker les états des auxiliaires dans des unsigned int codés sur deux octets, soit 16 bits. En donnant un poids à chaque marqueur d'auxiliaire, on part du MSB pour l'APU, et on descend en poids. Treize bits vont être nécessaires, et on va avoir trois bits disponibles (les trois LSB)

Plusieurs variables vont être nécessaires, car on doit savoir si chaque auxiliaire est à l'arrêt/fermé, en cours de démarrage/ouverture, démarré/ouvert, ou en cours d'arrêt/fermeture, soit quatre possibilités. Or dans les scn, on a:

                                   Valeur scn          Valeur scn en binaire       Transit_status      Switch_status

Arrêté/Fermé                        0                              00                          0                        0
Démarrage/Ouverture           3                              11                          1                         1
Démarré/Ouvert                   1                              01                          0                         1
Arrêt/Fermeture                   2                              10                          1                         0

On voit qu'on peut tirer de ce petit tableau deux valeurs: Transit_status qui va caractériser le mouvement et Switch_status qui va caractériser un ordre: ouvert/déployé ou fermé/replié. On élabore  Transit_status et Switch_status en fonction du poids donné à chaque auxiliaire. Par exemple, pour l'APU en marche, c'est le MSB de Switch_status qui sera positionné à 1.

Toujours pour la compacité du sketch Arduino, j'ai choisi de mesurer une durée avant fermeture complète. La position d'un auxiliaire va être comptée en millisecondes avant la fermeture complète, et c'est la valeur transmise par le script Lua à partir d'une règle de trois tenant compte de la valeur comprise entre 0 et 1 trouvée dans le scn, et de la durée de transit total refPosition[ ] en millisecondes de l'auxiliaire considéré (par exemple, 6.7 secondes, soit 6700 ms pour Gear => valeur fournie par la doc du Xr2).
La durée de transit la plus longue est celle du radiateur, qui est de 32 secondes, soit 32000 ms, ce qui est inférieur à la valeur max de 65535 (les 16 bits d'un unsigned int à 1)

La séquence d'initialisation doit attendre un flux d'octets en provenance du script Lua. Ce flux doit bien sûr être élaboré selon un protocole bien précis. Dans ce but, le script Lua envoie au port USB les éléments du tableau des positions d'auxiliaires, plus les deux derniers éléments contenant respectivement Transit_status et Switch_status. Du côté Arduino, les données arrivent dans le buffer d'entrée (24+2+2=28 octets), et sont chargées dans un tableau Position[3 à 14], plus les valeurs Transit_status, et Switch_status.

Les 28 (ou plus) octets sont envoyés par le script Lua (ce sont les fonctions "widdernix"=>voir le#31).

La carte Arduino réceptionne ces données, et connaît donc la position et l'état des auxiliaires.

C'est tout pour aujourd'hui: bonne digestion!!! Et pas de  , ni de  et encore moins de  dans le fond!

                          Si vous avez des questions, je suis là pour vous renseigner avec plaisir.

Dans un prochain post, j'expliquerai comment le sketch Arduino traite les données réceptionnées, afin de synchroniser le cockpit avec le scénario chargé.

[antoo]

Cool !

[jacquesmomo]

hébédisdonc....

[Mars Bleu]

Merci les gars pour votre présence. Ça me soutient et m'encourage pour
expliquer le déroulé de la conception de mes montages.

[antoo]

Avec plaisir l'ami. On attend la suite avec impatience !

[Gingin]

Wow, très solide aussi de ce coté là . 
Tes explications sont intéressantes, je n'y connais pas grand chose dans ce milieu, et ca me pousse à aller m'informer un peu plus sur tous ca.

Chapeau en tout cas. Est ce déjà opérationnel en partie?

[Mars Bleu]

@Gingin: Oui, oui. Tout ce que je décris est fonctionnel. Les auxiliaires fonctionnant avec la
marche de l'APU, le gimbal des moteurs, le COG (center of gravity) sont gérés. Le contrôle d'attitude
de l'engin également(RCS LIN et ROT, Undock); c'est bien pratique pour les appontages en orbite.
Pour l'instant, je travaille sur le contrôle des pilotes auto. Ça n'avance pas très vite, car je fais
des modifs en permanence, afin de m'adapter aux caprices de l'électronique. Mais ça avance...

J'ai aussi à faire les plans à partir du site  https://easyeda.com/
pour m'y retrouver plus tard pour dépannage ou modif.

Plus voir avec un fablab pour me faire des faces avant rétroéclairées qui soient un peu jolies.

Et pour montrer le fonctionnel, éditer quelques vidéos. Programme chargé!

[Gingin]

Super 

Tu as des photos des faces rétro éclairées?

[Mars Bleu]

Désolé de te décevoir, mais pour l'instant, je n'ai pas de faces rétroéclairés. 
C'est encore à l'état de projet, sous forme de dessin vectoriel.
Je suis en mode provisoire, avec des bouts de contreplaqué percés pour y installer 
les divers switches et autres boutons-poussoirs.

      De patience, preuve tu dois faire! 

[jacquesmomo]

de patience preuve nous ferons... ^{impatient moi je suis de voir...}
 

[Mars Bleu]

Pour les impatients
Ça fait quelque chose comme ça:



Quelques explications:
Le rectangle situé sous "APU fuel" sera découpé, afin de laisser voir quatre afficheurs 7 segments
donnant la quantité d'APU fuel restante en pourcentage du plein.

Les cercles "mismatch" sont des leds rouges de discordance allumées en cas de différence entre l'état
logique de tel ou tel auxiliaire, et la position du switch correspondant. En cas de discordance, manœuvrer
le switch l'alignera sur l'état logique de l'auxiliaire considéré. Le but étant qu'à l'initialisation, on éteigne
toutes les discordances par la manœuvre des switches discordants.

La rangée de cercles située immédiatement en dessous est de couleur jaune, tandis que la suivante
sera verte, indiquant la position "rentrée atmosphérique": tout est vert, tout est clair.

Enfin, la rangée de cercles inférieure correspond au passage des switches de commande.

Je n'ai pas de calendrier précis pour la confection d'un tel synoptique... C'est qu'il y a énormément à faire par
ailleurs, surtout dans la confection du câblage des cartes.

[antoo]

Ulta stylé ! En gros tu nous fais un XR2 complet quoi !
T'as plus qu'à chercher une vieille carlingue de A-6E americain (chasseur 2 places un peu comme le xr2 ...) .

A+

[Mars Bleu]

Ouais, mais mon épouse y trouverait à redire
Déjà qu'elle rouspète gentiment quand elle s'approche
de ma table atelier...
Mais c'est vrai que ça serait bien. Il y aurait moyen de prendre un passager, et on aurait
des belles tenues de vol! ( Spacesuit-casque-gants pour les décollages et rentrées; combi bleu
NASA pour la croisière)

[Mars Bleu]

  Dans le #59, j'élucubrais que dans un prochain post, j'expliquerai comment le sketch Arduino traite les données réceptionnées, afin de synchroniser le cockpit avec le scénario chargé.
Cela consiste à la....

                                                        Gestion des leds des auxiliaires APU



Un auxiliaire APU en mouvement doit être caractérisé par le clignotement de sa led associée: verte pour repli/fermeture, jaune pour déploiement/ouverture. Afin d'éviter de coûteuses et compliquées lignes de commandes dans le sketch, j'ai choisi d'utiliser le 1hz dont j'ai déjà parlé. Ce 1hz élaboré à partir d'un 555 est connecté à une entrée de la UNO, et va être exploité dans le sketch par une fonction booléenne ET.

Dans Orbiter, les switches ne sont pas concrets. A l'initialisation du simpit, les vrais switches peuvent se retrouver en discordance par rapport à l'état logique (issu du scn) du vaisseau. J'ai choisi de monter des leds rouges clignotantes qui vont être activées en cas de XOR entre l'état des switches, et celui du vaisseau dans Orbiter. Ces leds sont aussi activées en cas de manœuvre switch alors que l'APU est arrêté.

Si une discordance apparaît, la manœuvre du switch associé fait disparaître cette discordance: on aligne le cockpit sur l'état du vaisseau issu du scn Orbiter.

En résumé, à chaque switch va être associé un groupe de trois leds: verte (replié/repli), jaune (déployé, déploiement), et rouge (discordance).
                  Les leds vertes sont associées à PISOreg[0]
                  Les leds jaunes sont associées à PISOreg[1]
                  Les leds rouges sont associées à PISOreg[2]


Plutôt que de traiter chaque switch séparément, j'ai préféré traiter l'ensemble des données unsigned int avec des bitwise. Cela permet d'éviter tout un tas de if...else if , et de faire un code compact. Après bien des essais et mises au point pour tenir compte de toutes les possibilités, j'ai obtenu:

    Mismatch_status=(PISOreg[0]^Switch_status);//élaboration des discordances entre l'état logique et physique du simpit
    APU_mismatch=(Transit_status&(65535*(Position_APU==0)));//élaboration des discordances liées à un mvt de switch alors que APU indisponible
    SIPOreg[0]=((~Switch_status&~Transit_status)|(Transit_status&Onehz))&(~Switch_status);// Gestion des leds vertes
    SIPOreg[1]=((Switch_status&~Transit_status)|(Transit_status&~Onehz))&(Switch_status);//   Gestion des leds jaunes
    SIPOreg[2]=Mismatch_status|APU_mismatch;// Gestion des leds rouges
    survey_Position();// envoi à la gestion des fin de course des auxiliaires APU     




Nota:   & correspond à l'opérateur booléen AND
           |  correspond à l'opérateur booléen OR
          ~ correspond à l'opérateur booléen NOT
          ^ correspond à l'opérateur booléen XOR


Pour produire ces petites équations logiques, il a fallu que je revoie mes notions sur les tableaux de Karnaugh, de lointains souvenirs…

Ces quelques lignes de codes placées dans un boucle d'initialisation permettent aux valeurs Switch_status et Transit_status envoyées par le script Lua et reçues par le sketch Arduino  de commander dans un premier temps l'allumage des 3x13=39 leds du panneau auxiliaires APU.


Nous verrons plus tard comment tenir compte de l’écoulement du temps afin faire rendre compte au panel de la variation de l'état des auxiliaires APU.

[Mars Bleu]

Il est grand temps de vous expliquer comment je m'y suis pris pour tenir compte de l'écoulement du temps dans le mouvement des auxiliaires animés par l'APU.

En effet, il se peut que le scénario comprenne des mouvements d'auxiliaires en cours. Il faut donc mettre à jour les états des leds pour tenir compte de l'évolution de la situation. C'est la raison d'être de la fonction survey_Position();

Cette fonction va, entre autres, comparer bit à bit l'état de Switch_status et Transit_status, afin de déterminer si l'auxiliaire associé est en fermeture/fermé ou en ouverture/ouvert. Selon le cas, on va incrémenter ou décrémenter la valeur Position[ ] jusqu'à ce qu'on arrive à une valeur de "fin de course", égale à zéro ou bien à refPosition[ ].


for (byte rank=3;rank<15;rank++)                   // Nota:la marche de l'APU devra aussi être liée au niveau de carburant APU
    {
      if ((bitRead(Switch_status,rank)==1)&(bitRead(Transit_status,rank)==1))
      {                //  si auxiliaire en ouverture
       Position[rank]=Position[rank]+((millis()-mem_time)*(APUrunning*(bitRead(interswitch_control, rank))));//incrémentation: on est en ouverture, à la condition que APU soit en fonction
        if (Position[rank]>(refPosition[rank]-50))//si dépassement position(à 50 ms près),...
        {
          Position[rank]=refPosition[rank];// ...recalage à la valeur max
          bitClear(Transit_status,rank);//marque la fin du mouvement. 
        }//endif
      }//endif
      if ((bitRead(Switch_status,rank)==0)&(bitRead(Transit_status,rank)==1))
      {                //si auxiliaire en fermeture
        Position[rank]=Position[rank]-((millis()-mem_time)*(APUrunning*(bitRead(interswitch_control, rank))));//décrémentation: on est en fermeture, à la condition que APU soit en fonction
        if (Position[rank]<50)// on est à 5/100° de seconde de la fermeture; c'est pour éviter de passer <0 car on est en "unsigned int"
        {
          Position[rank]=0;//si dépassement position, recalage à la valeur min, c a d zéro
          bitClear(Transit_status,rank);//marque la fin du mouvement.
        }//endif
      }//endif      
    }//"next rank, on passe au mouvement de l'auxiliaire suivant"


Pour rappel, le tableau Position[] contient une valeur numérique unsigned int étant une distance temporelle en ms de la position fin de course basse de l'auxiliaire APU désigné par rank.
Le tableau refPosition[] contient les valeurs en ms de durée de transit total entre fin de course basse et fin de course haute de chaque auxiliaire. Ce tableau est essentiel pour connaître le moment où un auxiliaire est complètement ouvert ou déployé. Pour l'état rétracté ou fermé complètement c'est la même valeur pour tout le monde: zéro. Pas la peine de faire un tableau pour ça.

La valeur(millis()-mem_time) mesure l'intervalle de temps écoulé entre deux passages dans la boucle.

Vous aurez aussi remarqué la valeur interswitch_control. Elle sert à autoriser ou inhiber en dernier ressort un mouvement. En effet, nous savons que si le Xr2 est posé au sol sur son train d’atterrissage, on ne peut pas le replier. De même, si nosecone fermé, pas d'ouverture possible de outerdoor. D'où interswitch_control.

Une fois tous ces calculs faits, on envoie le contenu de SIPOreg[0 à 2] dans les registres par la fonction déjà évoquée, updateRegister(SIPOreg);  c'est une mise à jour des registres à décalage de sortie: on rafraîchit l'affichage de toutes les leds APU.
Tout ceci n'est qu'un début, qui ne s'est pas mis au point tout à fait facilement. Mais un des principaux obstacles qu'était la synchronisation du cockpit avec le fichier scn a été surmonté. J'ai essayé toutes les configurations de départ possibles, y compris celles les plus improbables, et je n'ai pas réussi à prendre en défaut mes algorithmes pour l'instant.

Mais on n'est pas encore au bout de nos peines: il faut encore pouvoir envoyer un raccourci clavier (ou non) à chaque mouvement de switch. Ça a l'air simple comme ça, mais c'est plus compliqué qu'il n'y paraît.

  Bonne lecture, en attendant la suite!!

[antoo]

Intéressant!

A+