Parlons Navette Spatiale avec SSU 4.2

[Papyref]

Tu t'en sors pous l'instant Papyref?

Aujourd'hui je n'ai pas travaillé sur SSU car j'ai termine la mise à jour de mon addon PAD24_UR500 pour diffusion incessante
Demain je m'y remets. Je pense que ton tutoriel sera très utile ! 

[Gingin]

Je pense que ton tutoriel sera très utile ! 

#Pression   

[Papyref]

 Pas pression mais  et merci d'avance 

[Papyref]

Demande d'aide !

J'ai réussi à comprendre quelle est la procédure pour entrer le deltaV et le TIG requis pour un changement d'orbite mais aprés avoir fait ça l'allumage ne se fait pas au TIG. Pourquoi ?
Cette navette est diabolique !!! 
De même comment peut on reprendre le controle des moteurs principaux en manuel ?
Il est certain que les américains n'ont pas donné dans la facilité d'exploitation ! Il faudrait tout refaire avec des écrans tactiles et des commandes vocales 

[Gingin]

J'ai réussi à comprendre quelle est la procédure pour entrer le deltaV et le TIG requis pour un changement d'orbite mais aprés avoir fait ça l'allumage ne se fait pas au TIG. Pourquoi ?

Hello Papyref, tu pourrais me fournir un screen ?
Dans quelle mode es tu ?( OMS1/2/ Orbit manoeuver)
Peut etre une erreur dans le TIG .

La syntaxe correct est   item10 + jour+ heure+minute+ seconde  EXE     

Un exemple, je suis en mode 105 (OPS1, ascent, phase 5 qui est la poussée OMS 2, d'ou le 105 en haut à gauche de l'écran)



TIG : 01heures 04mn 00 secondes Item 10+0+1+4+0 EXE

Ensuite je rentre une vitesse sur l'axe X du repère LVLH:  Item19 +128 EXE   (128 ft/sec)
Je charge la solution avc l'item LOAD:  Item 22 EXE
On voit les paramètres apparaitre à droite de l'écran ( VTOT, TGO, l'attitude inertielle de l'orbiter dans BURN ATT pour la poussée, et la décomposition du vecteur vitesse à ajouter dans le repère fixe de la navette  VGO X,Y,Z)

Je lance le timer: Item 23 EXE

Le timer apparait en haut à droite en dessus du Mission Elapse Time. 36mn15 dans notre cas.

Enfin, on positionne la navette dans la bonne attitude de poussée.
Item 27 EXE
En dessous de MNVR apparait TTG( Time to Go), temps nécessaire à la manoeuvre.

Et puis on attend la poussée, 15 sec avant le burn un EXEC jaune apparait en haut à droite de l'écran, il faut presser EXE pour confirmer le burn, c'est peut etre ca que tu as manqué.

De même comment peut on reprendre le controle des moteurs principaux en manuel ?

Pas de controle direct pour moteurs orbitaux, tout se fait par l'interface des GPC.

Il est certain que les américains n'ont pas donné dans la facilité d'exploitation ! Il faudrait tout refaire avec des écrans tactiles et des commandes vocales 

C'est clair 
Technologie des 80's

[Papyref]

Merci Gingin,
J'ai effectivement oublie les commandes d'exécution pour le load et le Timer. Je vais refaire l'essai !

[Gingin]

Nickel, j'ai fini à peu près le plan du tuto, je vais m'atteler à l'écriture entre 2 ricards au soleil 

Tu te sors de quoi pour le DeltaV? IMFD ou un calcul direct avec l'équation de la force vive?

[Papyref]

 

Tu te sors de quoi pour le DeltaV? IMFD ou un calcul direct avec l'équation de la force vive?

Pour l'instant calcul direct

[Gingin]

Tu te sors de quoi pour le DeltaV? IMFD ou un calcul direct avec l'équation de la force vive?

Pour l'instant calcul direct

Yes, je fais pareil. Ca marche bien
Et vu qu'une fois la vitesse rentrée on a une estimation du nouveau périgée/apogée, on peut affiner.

[Carcharodon]

Tu te sors de quoi pour le DeltaV? IMFD ou un calcul direct avec l'équation de la force vive?

vous avez déjà utilisé Burn Time Calculator ?
http://www.orbithangar.com/searchid.php?ID=6413
c'est un outil que je trouve indispensable pour quasiment tout les vols.

Sinon, j'ai fini mes tutos XR2 terre/lune et inverse, donc je vais installer le SSU ce WE.

[Gingin]

Il me semble que Burn Calculator seul ne permet d'avoir que le Dv pour circulariser l'orbite?

[Carcharodon]

nan, il permet de calculer toutes les poussées avec tout les moteurs disponibles (retro / hoover / main).
Il permet aussi (comme je le fais dans le tuto terre/lune) d'obtenir avec grande précision les distances qu'il faut pour s'arrêter a partir de la vitesse en cours, avec les moteurs selectionnés.
Il ne permet pas d'obtenir le vecteur de poussée (la direction) mais tout ce qui concerne le calcul Dv, il est fait pour ça.
La circularisation automatique n'est qu'une petite fonction supplémentaire, bien pratique.
Cependant elle n'est utilisable que pour des petites valeurs, car il ne donne pas de vecteur.
Or, les grosses poussées de circularisation ne se font pas dans l'axe prograde mais selon un vecteur unique : le prograde est un vecteur evolutif qui suit la courbure de l'astre autour duquel on est en orbite, ce n'est pas une droite.

edit : ... et c'est pour ça que BTC n'est pas indiqué pour réaliser des circularisations qui demandent plus du 1/4 de la vitesse orbitale finale en impulsion.
Donc il n'est pas indiqué, par exemple, pour circulariser une orbite basse terrestre en arrivée directe de mars ou de la lune.
Le module "orbit insert" de IMFD est bien plus précis et fiable pour ça.
Mais lorsqu'il n'y a que quelques secondes de burn pour circulariser, il fait très bien le taff : très facile, très rapide.

reedit : il est de plus conçu pour bosser en tandem avec transX... que je n'utilises plus depuis des années, je l'ai remplacé par IMFD.

la ou il est très pratique aussi, c'est pour s'arrêter a un rdv spatial (par exemple avec l'ISS).
il suffit de programmer le Dv et le Dt, de pointer le nez sur le "V-", puis de l'engager et de le laisser faire.
très précis, et ça facilite vraiment la tâche.

[Gingin]

D'accord.

Par exemple, on a une orbite de 200 par 300 km
Je vais faire une poussée à l'apogée A1 300km et créer un nouvel apogée A2 400 km.
Il permet de calculer le Dv?
En gros la différence entre la vitesse qu'aurait la navette au point A dans la nouvelle orbite cherchée et entre la vitesse actuelle de la navette au point de poussée A?

Ca pourrait etre pratique de connaitre l'intensité, vu que la direction est connue: axe X du repère LVLH au point de poussée, équivalent à une poussée pro/rétro grade quand on pousse à un apogée/périgée, ou sur des orbites très faiblement elliptiques ( ce qui couvre la très vaste majoritée des opérations de la navette).


Ce qui simplifie les interactions avec l'ordi de bord d'avoir à effectuer une poussée uni axial, on a pas tout ksc derriere :D



Edit: je viens de voir ton édit :D
En fait, il faut le coupler pour qu'il sorte des DV? Sinon, il sort que le temps de la poussée en lui rentrant une DV connue?

[Carcharodon]

Le module Dv de IMFD est plus indiqué pour faire ce que tu demandes, car il permet d'avoir un outil de visualisation predictif : en fonction du Dv que tu injectes a Dt (que tu choisis), tu peux voir exactement combien de Dv il faut injecter a ce moment là pour réhausser ton orbite a telle altitude.

edit : je viens de voir ton edit qui a vu mon edit.
lol

juste pour rajouter : le module Dv d'IMFD est très simple d'utilisation pour faire cde que tu demandes,, je viens d'essayer avec un truc un orbite.
en fait je n'ai jamais eu besoin d'utiliser cette fonction Dv d'IMFD car ce MFD est bourré de fonctions spécifiques toujour plus performants que le module Dv pour faire les opérations spatiales.
SAUF justement, pour rehausser une orbite de tant de km a tel moment.
La il est royal.

[Carcharodon]

En fait, il faut le coupler pour qu'il sorte des DV? Sinon, il sort que le temps de la poussée en lui rentrant une DV connue?

pas forcément besoin de le coupler non.
un exemple de l'arrivée sur la lune en PDI : il te permet tout seul de savoir exactement quand mettre a feu avec tes retros, combien ça va durer en temps, et quelle distance tu va parcourir pendant le burn.
Avec une précision absolue.
Ce qui mâche considérablement la tâche.
et si t'es même vraiment fan des totomatismes, tu le programmes longtemps a l'avance afin qu'il fasse le tout en totale indépendance au moment voulu, au lieu de le lancer en manuel au bon moment qu'il t'aura indiqué.
Ce MFD est un incontournable a mon sens... comme le MFD orbit ou map.
Ça doit faire partie de la panoplie car il y a toujours un moment dans le vol ou il est utile et pratique.

[Gingin]

Ok nickel.

Oui pour SSU, ca pourrait etre sympa.
Calculer des DV simples pour changements d'orbites, et des Target intercept pour ISS ( après on peaufine avec les ordis de bords)
Je regarderai ca alors, merci pour les infos.

Le truc avec SSU, c'est que les automatismes ne marcheront pas (tant mieux au final, ce n'est pas l'esprit de l'add on). Il faut passer absolument par les ordis de bord de la navette.
D'ou l'interet de ce que tu me dis sur IMFD, d'avoir une DV à rentrer et savoir sur quel axe pousser dans les ordis de la navette.

[Carcharodon]

Le truc avec SSU, c'est que les automatismes ne marcheront pas (tant mieux au final, ce n'est pas l'esprit de l'add on).

tout a fait d'accord sur ce point

Il faut passer absolument par les ordis de bord de la navette.

pareil d'accord

D'ou l'interet de ce que tu me dis sur IMFD, d'avoir une DV à rentrer et savoir sur quel axe pousser dans les ordis de la navette.

ha : le problème est donc de trouver le vecteur de poussée ?
il doit forcément y avoir une méthode dans la procédure du shuttle ?
personnellement, je compte bien n'utiliser QUE l'instrumentation et les procédures du shuttle pour les manœuvres.
Donc pas de BTC ni de IMFD  en mode Dv.
SAUF si les informations en question doivent venir de capcom.
A ce moment là, il est justifié d'utiliser des outils annexes pour simuler les calculs fournis par capcom.
mais je compte bien respecter a la lettre les procédures du shuttle, sans "cheat".

j'installe tout ça ce WE et je commence l'introspection dès le début de semaine.
chouette, y a plein de boulot 

[Gingin]

A ce moment là, il est justifié d'utiliser des outils annexes pour simuler les calculs de capcom.
mais je compte bien respecter a la lettre les procédures du shuttle, sans "cheat".

C'est tout a fait l'esprit et la force de cet add on.
Aucun automatismes externes, passer absolument par l'ordi de bord.
Et pouvoir simuler au travers de IMFD ou BaseSYNC pour la déorbitation les 50 mecs qui travaillent à KSC pour fournir la solution de poussée à la navette en orbite qui l'upload via les systèmes de comms, c'est l'esprit

En gros, toutes les solutions de tirs sont uploadés depuis KSC dans la navette. SAUF les phases finales de rendez vous, ou un programme spécial de la navette fait les calculs de la rencontre finale avec ISS, couplé à un radar de rendez vous et Star tracker pour avoir des infos de positions/vitesses relatives par rapport à la target ( Equations de Lambert/ simulé à 80%, ca marche très bien) Le but est d'arrivée 600 feet en dessous de ISS avant d'entamer la phase finale de Docking.Bref, je m'éloigne du sujet

Après, les directions restent simples . Toujours le repère LVLH du post d'avant.
Tu veux changer périgée/apogée de l'orbite, poussée pro/rétrograde axe X.
Tu veux changer le plan, poussée anti normal/normal axe Y. (Très couteux, changement de 1° coutera quasiment tout le fuel à bord, envrion 1000ft/s de réserve)
Tu veux rapprocher l'apogée/périgée de ton point de poussée, poussée radial axe Z

On faisant les calculs à la main ou avec un tableur excel/programme C++ (équation force vive pour le Dv https://fr.wikipedia.org/wiki/%C3%89quation_de_la_force_vive), c'est très précis ( de l'ordre du Nm pour arriver à l'orbite que tu veux)
Tu as moyen avec les ordis de la navette de voir en plus quel sera l'apogée/périgée que tu auras après la poussée, tu peux donc affiner la vitesse en conséquence.
IMFD a l'air parfait pour le mode DV à ajouter ( qui doit etre une poussée prograde, y a meme moyen d'avoir la direction X, Y , X avec le mode Appolo qui donne les composantes du vecteur poussée il me semble)

Ce que je vais tester plus sérieusement prochainement, c'est les rendez vous. La, c'est un peu plus touchy, mais au combien gratifiant.

C'est vrai que ce module reflete bien l'aérospatiale réelle, ou ce qui parait simple à travers un mfd générique est en fait compliqué à mettre en place dans un "vaisseau réel" (et demande des dizaines de mecs au sol pour vérifier,controler le vecteur d'état du vaisseau, etre sur de la position réelle, etc)

[Carcharodon]

C'est vrai que ce module reflete bien l'aérospatiale réelle, ou ce qui parait simple à travers un mfd générique est en fait compliqué à mettre en place dans un "vaisseau réel" (et demande des dizaines de mecs au sol pour vérifier,controler le vecteur d'état du vaisseau, etre sur de la position réelle, etc)

Certes, cependant, beaucoup de ces exigences sont à mettre au passé.
En particulier a cause de l'évolution drastique des moyens informatiques.

Apollo a intégré le premier ordinateur compact de l'histoire.
Avant Apollo, il fallait une pièce entière de maison pour faire tenir un ordinateur tel que celui qu'ils ont embarqué : l'AGC
Son cycle était de 85 kHz, sa mémoire morte de 72 Ko et vive de 4 Ko.
le tout pour une masse absolument remarquable pour l'époque (Apollo a fait naitre le concept d'ordinateur portable) de 32 kg.
Mais la première calculette bas de gamme actuelle est des millions de fois plus puissante que ça !

Pour le Shuttle, le GPC AP-101B date de 1972 pour sa conception, pesait lui aussi 30 kg et n'avait des performances que de 1 Mips (millions d'instructions par seconde), avec une mémoire de 512 Ko.
Il y en avait 5 a bord, 4 utilisés pendant les phases critiques du vol et un pour les "surveiller".
https://fr.wikipedia.org/wiki/Navette_spatiale_am%C3%A9ricaine#L.27informatique_embarqu.C3.A9e

Bref, tout ceci pour dire que les moyens de l'époque, même du shuttle, étaient vraiment très limités comparé a la puissance informatique dont on dispose aujourd'hui.
Non seulement ça mais aussi l'intégration de données (provenant de différents capteurs inboard et au sol), ça a considérablement progressé même depuis simplement les navettes spatiales.
Avec l'informatique moderne, les procédures du Shuttle seraient vraiment très différentes et beaucoup plus autonomes qu'à l'époque.

Mais voilà, à l'époque ce n'était pas le cas, alors moi, comme toi, j'ai envie d'utiliser l'engin dans son jus. 
Parce que c'est bien sympa le XR2, bon engin immersif avec beaucoup de capacités, il permet d'apprendre plein de choses sur les opérations spatiales... mais c'est bien trop facile, en plus d'être totalement irréaliste (au niveau de l'Isp magique des motorisation en particulier)

[Carcharodon]

Tu veux changer le plan, poussée anti normal/normal axe Y. (Très couteux, changement de 1° coutera quasiment tout le fuel à bord, envrion 1000ft/s de réserve)

ha oui, ça a éviter absolument le changement d'inclinaison !
c'est pour cette raison que la mise en orbite doit être remarquablement précise en terme de synchronisation d'inclinaison avec la cible (genre ISS) dès la mise en orbite, et j’attends de voir ce dont va être capable le addon sur ce point, car tout ça est en full automatique (le profil de tir) a partir du décollage jusqu’à mise en orbite définitive.

Avec le shuttle de base d'orbiter, ça demande un timing de tir hyper précis ainsi que la connaissance de l'inclinaison de tir à 0.1° près.
Le nouveau PA intégré dans O16 est cependant super cool pour ça.

Tu as moyen avec les ordis de la navette de voir en plus quel sera l'apogée/périgée que tu auras après la poussée, tu peux donc affiner la vitesse en conséquence.

Ha ba voilà, pas besoin du module Dv alors !

Tu peux compter sur moi pour aider a développer des procédures sans "cheat" pour toutes ces opérations de Shuttle.
Même si ça prend du temps, c'est a notre portée.
Et puis ça donne matière a se faire plaisir sur Orbiter, vu que je commençais a m'ennuyer avec le XR2 ou les delta glider a qui j'ai fait faire quasiment tout depuis une dizaine d'années.

Le NASSP m’intéresse beaucoup aussi, mais je préfère commencer par le SSU.

[Gingin]

Certes, cependant, beaucoup de ces exigences sont à mettre au passé.
En particulier a cause de l'évolution drastique des moyens informatiques.

Oui, c'est clair. J'aurai du mettre l'aérospatiale des années 90

Il y en avait 5 a bord, 4 utilisés pendant les phases critiques du vol et un pour les "surveiller".

Les gars savaient y faire niveau redondance ahah. Le 5ème, le BFC (Back up Flight System) avait meme un software concu par une autre boite que celui 4 premiers pour pallier à un glitch commun qui pouvait arriver dans les 4 GPC primaires, c'est fou.

j’attends de voir ce dont va être capable le addon sur ce point, car tout ça est en full automatique (le profil de tir) a partir du décollage jusqu’à mise en orbite définitive.

Ca marche bien. Les scénarios sont précis dans les fenetres de tir, on arrive à environ Rinc=0,50°
On peut modifier dans les fichiers scénarios le cap de tir pour affiner, et prendre en manuel le roulis/yaw en montée pour vraiment se rapprocher de 0.

Ha ba voilà, pas besoin du module Dv alors !

Dans l'absolu tu as raison. Mais ca évite de bcp tatonner et d'avoir déjà une Dv solide à rentrer, et ensuite on ajuste à quelques ft/s pour la précision

Même si ça prend du temps, c'est a notre portée.

Carrément. Un peu de patience et de lecture et ca le fait

Nassp me tente carrément aussi. Ca a l'air encore plus complexe!!

[Carcharodon]

Ca marche bien. Les scénarios sont précis dans les fenetres de tir, on arrive à environ Rinc=0,50°

arghh c'est déjà énorme ça, ça représente 50% du Dv disponible pour les opérations orbitales.
Je dois t'avouer que dépasser 0.2° de Rinc ça va me foutre des boutons.
mais y a moyen : optimisation de la fenêtre de tir (quelques dizaines de secondes maxi) et de l'inclinaison de tir a 0.1° près.
j'y arrivais avec le shuttle de base (toujours moins de 0.2°), en travaillant ces fenetres de tir et cette inclinaison, il n'y a pas raison qu'on y arrive pas avec SSU.
On fournira des scenarios suffisamment précis pour ça.

Oui, c'est clair. J'aurai du mettre l'aérospatiale des années 90

des années 70 même !
l'informatique du shuttle datait de cette époque là.
je crois savoir qu'elle a été remise un peu a niveau effectivement vers les années 90, mais rien de bien folichon.

Dans l'absolu tu as raison. Mais ca évite de bcp tatonner et d'avoir déjà une Dv solide à rentrer, et ensuite on ajuste à quelques ft/s pour la précision

de toute façon, on va faire en sorte de ne calculer avec des trucs modernes que les infos qui devaient venir de capcom et pas autre chose.
Et ça va le faire sans aucun doute.

[Gingin]

de toute façon, on va faire en sorte de ne calculer avec des trucs modernes que les infos qui devaient venir de capcom et pas autre chose.
Et ça va le faire sans aucun doute.

Yes, c'est ce que j'ai fait jusqu'à présent et ca marche super bien.
Pour le Rinc, oui, y a moyen d'arriver à un très bon résultat, et d'ajuster comme tu dis la fenetre de tir au dixième de degrés dans le scénario. En général, les missions pour ISS ou rendez vous de satellites sont très précises dans les fenetres inclinaisons dans les scénarios.
Je vais retester tout ca en rentrant sur Paris Lundi prochain.

Je me demandais si vous aviez un groupe skype ou teamspeak/discord sur le forum?

[Carcharodon]

il n'y a pas de channel vocal a ma connaissance, mais c'est vrai que ça serait très utile.
j'utilise teamspeak depuis des années pour plein de trucs, je pense que c'est le meilleur produit pour ça.
On va voir a créer ça.


... ça va finir par des cours online en vocal

"mais bordel, je te dis d'appuyer sur le switch master arm !!" 

looool 

[Gingin]

Teamspeak c'est super cool oui.

On pourrait créer gratuitement un discord pour le forum.
Ca pourrait vraiment cool d'échanger et expliquer en vocal.