Reprise du message précédent :
c'est vrai qu'avec l'image d'illustration plus haut, j'aurais pu m'en douter mais j'ai maté ca en blind vingt minutes après en avoir découvert l'existence par le post sur ce topic

SN8 a passé les tests cryo (en deux fois, petite fuite près des emplacements moteurs le premier jour, réparée le lendemain). Ils vont pouvoir continuer l'assemblage.

Petite question pour ceux qui maîtrisent les calculs

Sur NSF ca spécule beaucoup sur des premiers étages de Super Heavy modifiés pour servir de réservoir de stockage en orbite, ou de tracteur vers Mars histoire que le Starship arrive réservoir plein sur place et plus rapidement...

Mais un réservoir "Super Heavy" chargé à bloque (~3500t) en orbite basse genre 400-700km, il consommerait combien de carburant pour se maintenir en orbite chaque année? (bon ca parle aussi de rabaisser l'orbite pour se charger en carburant avant de remonter, mais soit, supposons qu'il reste en orbite basse constamment)

Pour se maintenir en orbite pas grand chose. Par contre faudra m'expliquer comment on envoie l'équivalent en carburant d'un premier étage en orbite. La massée annoncée est bien au delà des capacités du lanceur.  

En faisant le plein mon bon monsieur  
 
Pour remplir le réservoir, et bien faudra quelques dizaines de vols.
 
C'est ce qui est déjà prévu pour le Starship pour l'envoyer sur Mars de toute façon. (Il y aura une version "Tanker" du Starship, Musk l'a déjà annoncé)
Donc cette histoire de réservoir de stockage de carburant en orbite, ca ferait gagner du temps en effet.
 

Un Super Heavy est capable de se mettre en orbite ?

Non, apparemment leur idée c'est de mettre le réservoir d'un Super Heavy sur un Super Heavy.  
 
Mais bon à mon avis même à vide rien qu'avec les dimensions et l'aéro ça ne tient pas la route. Il est déjà prévu un Starship cargo pour faire le job.  
 

et un super heavy sur 3 super heavy ?

Trop KSP

Il me semble avoir lu que oui, la Super Heavy serait en principe SSTO si tu lui enlèves le Starship (80t), ca lui laisserait même du rab en carburant.

1h30 d'interview du patron de glavcosmos
 
https://youtu.be/6X-r4teUWa4
 
Non, je n'ai pas écouté

Au delà de 500km les frottements deviennent vraiment très faibles, on ne perd pas grand chose. Ça dépend de la forme du satallite mais à cette altitude tu peux garder en tête une 20aine d'années avant que ça ne retombe dans l'atmosphère.
Ce n'est pas pour rien qu'on a mis Hubble au max des capacités de la navette à savoir 600km.

J'ai lu Glucosmos
C'est un super nom d'ailleurs vite un Glucosmos Aerospace, le privé totalement glucose

 
C'ést du cyrillique à la base, qui sait comment ça se prononce ... Depuis que j'ai appris que le "T" majuscule a pour minuscule "m" , plus rien ne m'étonne
Et bien sûr j'ai aucune idée du comment le T et le m se prononcent...

 
Ce n'est pas directement mon métier mais question contrôle de vol, je ne crois pas que sur des lanceurs / missiles on se permette beaucoup le code autogénéré par Matlab... Ne parlons même pas de faire revenir des atterrisseurs sur un centre spatial.
 
Effectivement il y a pas mal de maths assez avancés (du point de vue des ingés) derrière la conception et le développement des algos, eux même très très fortement dépendant de la physique et du hardware (perfos de l'informatique embarqué, perfos des capteurs, perfos des actionneurs de pilotage, besoin de forte réactivité en vol endo-atmosphérique, prise en compte de la méca : modes souples, ballotement pour les étages à ergols liquides...) . Ça conduit à embaucher des ingés au profil assez spécialisé pour ces métiers.  
Par contre oui, dans l'industrie spatiale en France, on est clairement pas sur des armées. De manière générale, sur un programme comme Ariane 6, il n'y a pas d'armée dans aucun domaine. Les équipes sont assez restreintes quand on s'intéresse à chaque sujet du développement du lanceur, c'est déjà du luxe quand on peut être 2 à travailler sur le même sujet. Et les équipes sont aussi trés jeunes contrairement à ce que beaucoup semble penser sur ce topic.
 

 
Si c'est la cas.

 
Ok, ma vision c'était plutot celle de la conception et developpement des algos avec matlab, mais ensuite on recode tout dans le programme embarqué en ada.  
Du coup avec du code autogeneré on s'en sort bien en terme de verif/validation derrière ? J'avais l'impression que ca devait pas mal complexifier l'affaire.

Ada est toujours utilisé pour la prog en temps réel ?
Mazette j'ai pas touché ça depuis le siècle dernier.

 
Mmh, du coup j'ai tout vu.
 
Il dit précisément que le 1er étage est à mach 10 et que du coup il qualifie "d'impossible" le fait de le faire revenir à la base.
 
Mais du coup comment ils ont fait pour les side-boosters de la heavy et les mission CRS ?    
 
Ya des boostback burn, alors pourquoi il dit que c'est impossible ?

 
oui, je crois que ça a toujours été avec boostback burn pour les sides booster. J'ai pas regardé mais il dit que c'est impossible dans quel cas, pour le central ?
 
Aussi, il est possible qu'ils finissent de cramer leur carburant utile plus tôt que dans une mission non heavy (par rapport au booster central) et donc se détache moins haut/vite. Le booster central de la heavy par contre c'est sur il faut bien bien freiner sinon il prend cher (fini plus haut/vite/loin), et pas assez de carburant pour un boostback...

il leur faudrait des bases dans d'autres continents pour les poser

https://youtu.be/0-Te-enCEE4?t=283
 
Là, jusqu'à 5:20  

Cet homme a vraiment le charisme d'une huître à l'oral ^^'
 
Il est tellement pas clair dans ses explications, quand tu connais pas déjà je pense que c'est juste imbitable

 
bah il parle du stage centrale (et pas des sides booster) à la séparation avec le deuxième étage la (pour mach 10 en vitesse latérale). D'ou l'impossibilité de faire un boostback pour revenir en arrière, trop de distance/vitesse accumulée, donc juste freiner la rentrée, et poser sur barge.

 
Oui ça va c'est surtout l'intégration et la qualif ù il y'a du taf, mais les TU sont pas en reste non plus , bref le code auto généré n'épargne pas les efforts dans ces 2 activités mais ça permet au moins de simuler le tout rapidement et de faire certains choix.

 
jusqu'à il y'a quelques années , oui, d'ailleurs j'en ai pratiqué que là, mais je trouve ça franchement pas mal, je pige pas qu'il n'y ai pas plus de tempe réel embarqué qui penchent vers ADA / GNAT, mais faut dire que la main d'oeuvre est super rare.
En gros un bon en C / C++ pas trop goret n'aura aucun mal à très bien s'en sortir.

 
https://twitter.com/thesheetztweetz [...] 80064?s=21

La qualification du logiciel de vol Ariane 5, autour de 2010, c'était une armée d'une vingtaine de personnes, oui. Qualification, c'est sans compter l'équipe de dev/validation, ou l'équipe développant les outils de support à la qualification. Mais c'est parce qu'il y avait plusieurs obsolescences d'équipements à requalifier, en plus des vols réguliers. Trois ans plus tard l'équipe avait bien réduit.

Ariane 5 c'était de l'ADA au moins jusqu'à l'ordinateur de bord version B si je me souviens bien. Je ne me rappelle plus si le portage vers l'ordinateur version C a utilisé du langage C à la place.
Mais même vision que toi ; de ce que j'ai vu, on ne fait pas tourner du code autogénéré par matlab sur un lent processeur de satellite type leon2. Au minimum on l'optimise manuellement.

Me suis fermement emmerdé devant The Right Stuff (la série Disney).

Petit pétard du dimanche à 17hr ?

Space X  a "innové" aussi dans la prog, j'avais lu un article qui disait qu'il préféraient  plusieurs personne qui maitrise un langage simple que quelques spécialiste, ça permet de hardtester tout, d'autant plus que nb de bibliothèque libre existent en C / C++ et qu'ils n'ont qu'a écrire des tests du coup.
 
mais la où je pense qu'ils ont des burnes : avoir mis du java dans l'interface homme machine du Dragon .. jamais je n'aurais pris cette décision

What?
C'est du Java?    
 
Euh ils ont donné une raison particulière pour ce choix???

Je sais pas si ils en ont donner une, mais si qq'une trouve un article la dessus je  serais ravi de le lire

j'ai peut etre mal compris , je trouve une autre info ici :
 
https://www.tesmanian.com/blogs/tes [...] cex-reddit
 
 
SpaceX engineers shared the programming languages they code in are: “C & C++ for flight software, HTML, JavaScript & CSS for displays and python for testing,” adding that they “use HTML, JavaScript & CSS. We use Web Components heavily.”
 
ça me rassure un peu : pas de cette saloperie de Java dans l'espace !

Ca ne me rassure pas davantage (html/javascript)
 
 
J'aurais plutôt pensé à du Qt pour ce genre d'usage.

Déjà si il y'a du C / C++ derrière, c'est mieux que n'importe quel  code en Java.

Putain clairement et ce n'est pas souhaitable que dans le spatial d'ailleurs.

Le truc qui rend fou :  
 
"Crew Dragon displays are running Chromium and JS [JavaScript] and we do use a reactive library that we developed in house"
 
 
Mais heureusement :
 
"Chromium in this context is used as a UI [User Interface] rendering engine only. The Flight Software interaction layer with the displays and the fault-tolerant is well defined and resides outside the displays boundary. That said, we follow the same development process for all vehicle code regardless of the technology stack. We cross-train our developers to write vehicle code in C++ and to carry the same mentality toward writing reliable software. We take reliability & performance very seriously, and just like other vehicle software, we test extensively under different conditions to understand all failure modes. We have alerts & procedures in place to act on those failures in case we encounter them. All of that added to hundreds of hours of sims [simulations] that we run on flight hardware to train the crew.”

Si il y avait du Java dans la capsule Dragon, je suis sur qu'on aurait l'info pendant la mise a jour java