KST Nabukodonosor

Des fusées, des avions, et d'autres! Partagez vos modèles ici. Pour plus de personnalisation, de partage et d'aspect communautaire, n'hésitez pas à utiliser notre outil hangar !
Avatar de l’utilisateur
Dakitess
Messages : 6954
Inscription : 25 janvier 2013, 02:17
Localisation : Ile de France
Contact :

Re: KST Nabukodonosor

Message par Dakitess » 06 février 2014, 10:33

Elington a écrit :
Dakitess a écrit :Étonnant pour cette histoire de pitch. Est ce que ça signifie pas qu'il faudrait retarder le gravity turn ? Avoir une courbe logarithmique qui monte beaucoup avant "d'horizontaliser" ?
C'est un profil correspondant à ce vaisseau et cette altitude d'orbite bien particuliers, l'optimiseur ne donne pas ça par défaut.

D'une manière générale il n'y a pas de trajectoire imposée (forme de courbe, gravity turn) l'algorithme optimise le plan de vol de façon libre. Il gère 8 variables, 4 d'angle et 4 temporelles qui définissent les points caractéristiques du profil. Entre ces points les commandes sont interpolées linéairement.
C'est là que doit se situer la légère perte d'efficacité et le pitch final à maintenir : dans la linéarité qui va faire prendre un raccourci dans la courbe à chaque étape et va directement impacter la trajectoire. Y'a qu'à voir, avec des engins si je commence mon gravity turn progressif vers 15000 ça passera jamais alors qu'à 16500 avec la vitesse verticale acquise en quelques secondes de plus, je serai pile dans les temps pour être le nez dans le prograde en permanence. Un rien fait tout changer.

Du coup, est-ce que ton logiciel utilise la linéarisation comme base de calcul ? Je veux dire, les données de vol sont elles établies sur une courbe vraie ou sur une approximation à 4 points ? Ou est-ce que c'est 4 point ne sont qu'ensuite secondaire, pour donner des instants clés à suivre par l'utilisateur ? Tu pourrais extrapoler en degré 2 ou ajouter un point tu penses ou ça alourdirait la simulation ?

Avatar de l’utilisateur
Elington
Messages : 143
Inscription : 02 janvier 2014, 10:43
Contact :

Re: KST Nabukodonosor

Message par Elington » 06 février 2014, 12:18

Dakitess a écrit :Du coup, est-ce que ton logiciel utilise la linéarisation comme base de calcul ? Je veux dire, les données de vol sont elles établies sur une courbe vraie ou sur une approximation à 4 points ? Ou est-ce que c'est 4 point ne sont qu'ensuite secondaire, pour donner des instants clés à suivre par l'utilisateur ? Tu pourrais extrapoler en degré 2 ou ajouter un point tu penses ou ça alourdirait la simulation ?
Alors que tout le monde note que ça n'est pas moi qui part sur les maths! :lol:

A. Chaque trajectoire est calculée par intégration du système d'équations différentielles du mouvement en prenant en compte gravité, poussée, trainée et les variations de masse du vaisseau (carburant consommé et séquence de staging). La méthode d'intégration est un Runge-Kutta d'ordre 4 avec un pas de 0.5s + des points forcés par les réservoirs quand il sont vides.

Au long de cette trajectoire l'axe de poussée est déterminé par les angles de heading et pitch (reconstruction du référentiel du vaisseau à chaque point de calcul), avec effectivement une interpolation linéaire entre les différents points de référence du plan de vol. Si je devais interpoler avec un ordre supérieur cela serait vraisemblablement en spline cubique, mais:
1 - les pertes sont négligeables: 5° d'erreur = 0.4%
2 - c'est un humain qui est aux manettes, et donc va lui dire qu'entre les points il doit appliquer "une interpolation d'ordre 2" et tu vas voir ce qu'il te répond! :D Faudrait-il un pilote auto? Je préfère le "hands-on", c'est plus marrant ;) ... et en pratique avec un peu d'attention ça fonctionne très bien.


B. L'optimiseur lui même se situe une couche au-dessus et vient manipuler les variables du plan de vol (temps et angles) puis recalcule de nouvelles trajectoires pour vérifier le résultat de ses modifs, le "résultat" étant le périapse de l'orbite finale atteinte. Pourquoi le périapse? Parce qu'il est toujours défini quelle que soit l'excentricité et que le maximiser dans le cas des ellipses conduit naturellement à une orbite circulaire, donc on fait d'une pierre deux coups: maximiser le périapse = chercher l'orbite circulaire de plus haute altitude.

Sachant qu'il y a 8 variables pour définir le plan de vol et qu'on veut donc maximiser le périapse, il s'agit donc là d'un problème de, je cite "optimisation non-linéaire en dimension 8 sans contraintes", qui est résolu à l'aide d'un algorithme de "Fletcher et Reeves (gradient conjugué)" qui en gros consiste à parcourir "l'hyper-surface" définie par la fonction PeD = f(plan de vol) en se guidant à l'aide du gradient (le vecteur de dimension 8 des dérivées partielles du periapse en fonction des variables du plan de vol) et qui donne la ligne de plus grande pente.

Le problème est que l'hyper-surface est très "cabossée" avec de nombreux maximums locaux (= trajectoires sous-optimales) et j'ai donc ajouté une pondération du periapse par le DeltaV de circularisation pour trouver des trajectoires plus efficaces (= Pe le plus élevé avec le DV de circularisation le plus faible). La pondération est elle-même modifiée au cours du déroulement de l'algo d'optimisation pour d'abord sortir des régions de basse efficacité puis dans un second temps circulariser la trajectoire une fois dans une zone correcte. Il y a aussi un curseur qui permet de changer la "force" de la pondération certains designs étant plus "rétifs" que d'autres.

Maintenant cet algo donne t-il LA trajectoire idéale? Je ne sais pas. Je suis électronicien, pas astrodynamicien et je n'ai pas les connaissances mathématiques nécessaires pour répondre: je me suis déjà bien "amusé" à implémenter la mécanique elle-même à vrai dire! :lol:
Sinon je n'ai jamais eu de retour à ce sujet et pour ma part il m'a toujours donné des profils performants, et toujours bien meilleurs que ce que j'aurais fait à l'estime dans le jeu.

Je peux donner plus de détails évidemment, de toute façon il n'y a plus personnes qui lit ce topic :)

Avatar de l’utilisateur
DrDam
Messages : 1183
Inscription : 10 décembre 2013, 15:30
Localisation : Sur le vaisseau spatial baptisé " Terre "
Contact :

Re: KST Nabukodonosor

Message par DrDam » 06 février 2014, 12:30

Bon, j'ai décroché au niveau du
La méthode d'intégration est un Runge-Kutta d'ordre 4
et repis au niveau du
cet algo donne t-il LA trajectoire idéale?
Donc sinon pour répondre à ta question :
entre ce que tu as annoncé sur ton tanker et ce que reproduit en réalité ( avec un plan de vol issu de la méthode Larache), j'ai un résultat assez proche ...

en gros je stabilise l'orbite à 150km avec le dernier réservoir-moteur à moitié vide
Tout ce qui a été crée par l'Homme devrait être patrimoine de l'humanité. Vous êtes perdu ?, là ce sera trop loin. Suivez moi : @DrDam8584

Avatar de l’utilisateur
Dakitess
Messages : 6954
Inscription : 25 janvier 2013, 02:17
Localisation : Ile de France
Contact :

Re: KST Nabukodonosor

Message par Dakitess » 06 février 2014, 12:42

Je pense au contraire que ça en intéressera certain :p Donc tu utilises les hyper-surfaces... Tu procèdes couches par couches pour éliminer les maximums locaux de crêtes et rechercher les seules véritables caractéristiques ? Ca me rappelle des souvenirs de maths tout ça, avec les zones d'équilibre instables, stable, superstable, et maximale xD Même principe avec l'analogie d'une surface à plusieurs dimension représentant des reliefs...

Niveau procédure ça aurait tendance également à me faire penser aux méthodes d'optimisation multidisciplinaire comme ModeFrontier, capable de gérer un workflow ouvrant et utilisant des macros de nombreux logiciels, et cherchant à optimiser les sorties. Dès l'instant que les objectifs sont multiplies, il y a matière à optimiser, c'est ton cas, avec des sous-objectifs permettant de servir un super-objectif : l'efficacité énergétique de l'ascension. L'avantage de cette solution logicielle c'est qu'elle va générer à partir des points de simulations physiques, des "surfaces de réponse", à savoir une nouvelle presque infinité de point virtuels qui vont cette fois constituer une plage continue et non discrète pour affiner les valeurs. Le résultat final est une estimation des paramètres physiques à respecter pour suivre les valeurs théoriques crées... M'enfin ça remonte un peu ^^

En tout cas y'a pas à dire, ça semble être un boulot formidable, ton logiciel... Je ne m'y suis pas encore penché je l'avoue, mais je l'ai téléchargé et son interface très pro et "véritable" (dans le sens ou ça fait que ça fait pour de bon, scientifiquement) me plait énormément.

sam21
Messages : 789
Inscription : 02 octobre 2013, 16:42
Localisation : finis les vacances, de retour sur Kerbin
Contact :

Re: KST Nabukodonosor

Message par sam21 » 06 février 2014, 14:32

J'ai mal à la tête ^^.

Avatar de l’utilisateur
Elington
Messages : 143
Inscription : 02 janvier 2014, 10:43
Contact :

Re: KST Nabukodonosor

Message par Elington » 06 février 2014, 14:33

Dakitess a écrit :Je pense au contraire que ça en intéressera certain :p Donc tu utilises les hyper-surfaces... Tu procèdes couches par couches pour éliminer les maximums locaux de crêtes et rechercher les seules véritables caractéristiques ? Ca me rappelle des souvenirs de maths tout ça, avec les zones d'équilibre instables, stable, superstable, et maximale xD Même principe avec l'analogie d'une surface à plusieurs dimension représentant des reliefs...
Oui c'est ça, mais j'ai plutôt essayé d'aplanir la surface. L'algo de recherche par gradient correspond à chercher à gravir une montagne par temps de brouillard: tu ne vois que la pente à proximité immédiate et tu te rappelles d'où tu viens. Reconnaitre des crêtes et sous-structures locales demande plus de puissance de calcul car il faut aussi aller évaluer la fonction dans des zones éloignées, comme avec un grid-search. Dans ce cas tu calcules systématiquement sur les combinaisons générées par des grilles de valeurs définies pour chaque variable. Mais si on veut évaluer toutes les variables sur 10 points chacune, on obtient ici ... 10^8 = 100 millions de calculs de trajectoires. Un i5 ça turbine et ils sont 4 dans la machine mais quand même... Et encore c'est avec 10 points seulement donc assez grossier.
Voilà la doc du komputron à propos de dette modification de la fonction à optimiser (en rouge problème avec le PeD = f(plan de vol) pur, en bleu étape de recherche des régions optimales grâce à la modification de la surface, en vert retour à une configuration amenant à circulariser une "bonne" trajectoire):

Image
Dakitess a écrit :Niveau procédure ça aurait tendance également à me faire penser aux méthodes d'optimisation multidisciplinaire comme ModeFrontier, capable de gérer un workflow ouvrant et utilisant des macros de nombreux logiciels, et cherchant à optimiser les sorties. Dès l'instant que les objectifs sont multiplies, il y a matière à optimiser, c'est ton cas, avec des sous-objectifs permettant de servir un super-objectif : l'efficacité énergétique de l'ascension. L'avantage de cette solution logicielle c'est qu'elle va générer à partir des points de simulations physiques, des "surfaces de réponse", à savoir une nouvelle presque infinité de point virtuels qui vont cette fois constituer une plage continue et non discrète pour affiner les valeurs. Le résultat final est une estimation des paramètres physiques à respecter pour suivre les valeurs théoriques crées... M'enfin ça remonte un peu ^^
Ça n'est pas aussi complexe mais il y a clairement un risque de "plat de nouilles" inutilisable si les différentes couches ne sont pas suffisamment encapsulées. Il est clair que dans cette situation un langage pur objet comme C# limite la casse mais il faut faire attention. En tout cas dans mon cas qui ne suis pas programmeur pro habitué à gérer ce genre de choses - le komputron fait 26,000 lignes effectives quand même.
Dakitess a écrit :Je ne m'y suis pas encore penché je l'avoue
Merci pour le retour mais tu sais il y a certainement beaucoup plus d'intérêt pour moi à bosser dessus que pour toi à essayer de rentrer dedans! Il répond à ma propre logique et à mes objectifs et ce avec une interface qui s'est construite au fur et à mesure donc pas forcément très ergonomique...
Les softs c'est comme les gamins, les siens on en est toujours content :lol:

Avatar de l’utilisateur
Dakitess
Messages : 6954
Inscription : 25 janvier 2013, 02:17
Localisation : Ile de France
Contact :

Re: KST Nabukodonosor

Message par Dakitess » 06 février 2014, 14:57

Je crois au contraire que c'est un outils qui plairait à de nombreux joueurs, très poussé semble-t-il, qui vient renforcer cet aspect simulation-préparation cher à KSP. Ca l'était encore plus sur Orbiter apparemment, mais beaucoup de Kerbonautes recherchent cette dimension de réalisme et cette compréhension physique qui nécessite de se pencher sur des outils d'optimisation.

Mais effectivement, la prise en main est quelque chose qui peut rebuter l'utilisateur lambda. C'est plutôt propre et classieux, mais en matière d'ergonomie, tu l'as construits à ta manière et sur de longues années, c'est logique qu'il ressemble à cela. Faut juste mettre les mains dedans et voir les tutos quoi ! Quand j'aurai débuté mon stage et que j'aurai fini mon grand tour, j'essaierai certainement :D

Avatar de l’utilisateur
Elington
Messages : 143
Inscription : 02 janvier 2014, 10:43
Contact :

Re: KST Nabukodonosor

Message par Elington » 06 février 2014, 14:59

sam21 a écrit :J'ai mal à la tête ^^.
Ben oui c'est le problème... C'est pas pour en mettre plein la vue cette discussion. Mais de nos jours c'est comme s'il fallait toujours masquer la complexité des choses!? N’empêche que quand tu zoomes "naturellement" avec deux doigts sur ton smartphone, ça n'a rien de "naturel" du tout et derrière le bordel recalcule en temps réel tout l'affichage et la position des éléments d'interface. Après on s'étonne qu'il y ait une journée d'autonomie et qu'il faille un quad-core. Non la complexité technique est bien toujours là et ce de plus en plus. Et à mon humble avis il est très dangereux de nier et masquer ce fait.

C'est aussi ce qui fait de KSP un ovni d'ailleurs, les anglo-saxons utilisent le terme "Rocket-Science" pour se moquer des maths et des sciences en général, et là tous les joueurs font allègrement de la "rocket science" avec le sourire et parlent de "DeltaV" et de "TWR" au p'tit dèj! :D C'est pas pour rien que la NASA veut emboiter le pas: KSP a fait plus pour eux en deux ans que tous les millions de dollars de frais de comm qu'ils ont vaporisés en 40! :lol:

Avatar de l’utilisateur
Dakitess
Messages : 6954
Inscription : 25 janvier 2013, 02:17
Localisation : Ile de France
Contact :

Re: KST Nabukodonosor

Message par Dakitess » 06 février 2014, 15:04

Hé ouais ! KSP est un formidable moteur d'émergence de la connaissance communautaire (putain de phrase). Un peu comme tous les Serious-Game, mais tous ,n'y parviennent pas aussi bien. Perso je me régale toujours autant de répondre aux questions qui ont déjà été posé, de rédiger 2-3 tutos un peu différent, d'en apprendre davantage en mécanique orbitale, etc. Avec KSP, ça passe très bien, et beaucoup d'idées émergent d'elles mêmes, à l'échelle de l'individu ou du collectif, concernant le jeu ou la réalité, c'est productif :)

Avatar de l’utilisateur
DrDam
Messages : 1183
Inscription : 10 décembre 2013, 15:30
Localisation : Sur le vaisseau spatial baptisé " Terre "
Contact :

Re: KST Nabukodonosor

Message par DrDam » 06 février 2014, 15:06

sam21 a écrit :J'ai mal à la tête ^^.
on est deux !
Tout ce qui a été crée par l'Homme devrait être patrimoine de l'humanité. Vous êtes perdu ?, là ce sera trop loin. Suivez moi : @DrDam8584

Répondre

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit