54
-
Irasidus #14 "Nem is arról, hogy egy tartályt felemeljenek rakétahajtóművel. A tesztelés oka a leszállás előtti manőverek és maga a leszállás kipróbálása volt. "
Tehát manőverezek egy biciklivel, hogy később egy kamiont tudjak vezetni? Nem érzed az abszurditást? Se a tömege, se a hajtóműve, de igazából semelyik alkatrésze, de még a formája sem ugyanaz. Ez nem leszállási próba, ez direkt marketing, hasolísd össze a grasshopperrel (amit hibással hoppernek hívtam, de nem vetted észre). Nem hiszed? Akkor ezt a levelet olvasd el, amit most tett közzé Musk: link
"Sajnos úgy tűnik, hogy a Raptor hajtóművek gyártási krízise sokkal rosszabb, mint amilyennek néhány hete tűnt. Ahogy beleástuk magunkat a problémába a vezetés távozása után, a helyzet sokkal súlyosabb, mint ahogy azt korábban jelentették. Nem lehet ezt szebben kifejezni. Ha nem tudunk elég megbízható Raptor hajtóművet gyártani, az azt jelenti, hogy nem tudunk elég Starship-et indítani, és vele együtt elég második generációs (V2) Starlink műholdat (a Falcon-9 kapacitása nem elég erre) sem. Az első generációs Starlink műholdak pénzügyileg gyenge lábon állnak, de a V2 már erős lesz. Ezen kívül felpörgetjük a Starlink-terminálok gyártását évi többmillióra, ami hatalmas pénzbe fog kerülni, de ha fel tudjuk bocsátani a V2 műholdakat, akkor ki tudja szolgálni a keresletet. Ha nem, akkor ezek a terminálok használhatatlanok lesznek. Mindebből az következik, hogy megvan annak az esélye, hogy valódi csődkockázattal nézünk szembe, ha jövőre nem tudunk legalább kéthetente egy Starship-et indítani."
Szerintem itt a vitát be is fejezhetjük.
Utoljára szerkesztette: Irasidus, 2021.12.01. 13:15:30 -
kvp #13 "Egész pontosan csak a szoftver fejszerésben használják iterative development-et."
Nem csak ott. Hardvernel is. Neha meg eletkritikus hardvernel is (orvosi muszer). Sot gyakran a meg a sorozatgyartas soran is optimalizaljak a koltsegeket, neha behozva egy-ket uj hibat. Anno elso multis munkahelyemen el is hangzott, hogy ha 100 betegbol csak 1 hal meg szoftver vagy hardver hiba miatt, az jo arany. En nem tartottam annyira jonak, de ha egy nagy amerikai ceg megengedheti ezt maganak, akkor ez a realitas.
Egyebkent beagyazott mernokkent teljesen normalis, hogy neha at kell tervezni egy-egy hardvert, ezert vannak a prototipusok, hogy megtalaljuk azokat a hibakat amiket a tervezes soran nem lehetett kikuszobolni. Legyen az a felhasznalt egyik komponens ismeretben hibaja (ezekbol szuletnek aztan a hardveres erratak, amiket probalnak kesobbi reviziokban javitani), amiket attervezessel tobbnyire meg lehet kerulni ha nem akkor komponenst kell cserelni vagy legyen a szoftver eltero viselkedese a fizikai kornyezetben a tervezett/szimulalt kornyezethez kepest. Neha egy szoftveres problemat a hardver attervezesevel a legegyszerubb kijavitani. Ezt csinaltak egyebkent az Apollo kuldetesek soran is. (a 11-es es 12-es kozott atterveztek az AGC hardveret a 11-es leszallasanal elojott tervezesi hiba reszben kijavitasara, reszben megkerulesere, meg szerencse, hogy az egyetlen civil tesztmernok ment vele)
Meg autoknal is ezert vannak a prototipusok, hogy lehessen hibazni, lehetoleg meg a szeriagyartas elott. De ugyanez igaz egy uditos dobozra is, csak ott valamivel kisebb a hibalehetoseg. Magyarorszagon is epultek proba lakotelepek, hazankent eltero megoldasokkal es az igy nyert tapasztalatokbol keszultek a kesobbi szeriagyartott hazak. Ez mind az iterativ fejlesztesi modell alkalmazasa a gyakorlatban.
"Milyen elvet követhetne még egy rakéta, és milyen más formája lehetne?"
Az R7 a Korolev kereszttel egy eltero elv, a kinai hordozok is azt kovetik. (az uj kinai uralomas fellovesenel a videon is jol latszik, hogy nagyon szep Korolev keresztet dobtak a booster-ek) Aztan ott van az N1 raketajuk, aminek mar a formaja sem volt jo, de a nem onhordo, gomb alaku uzemanyagtartalyok sem jo megoldasok. Aztan ott van a falcon heavy es az ariane 5 barkacs megoldasa, amikor tobb kisebb raketat kotoznek ossze, ami messze nem idealis. Es akkor az ursiklok barkacs megoldasairol meg nem is beszeltunk. Szoval a letisztult forma nem jellemzo minden raketara, de fel lehet ismerni a V2 - Atlas - Saturn - Falcon 1 - Falcon 9 - Starship vonalban az idealisnak tekintheto megoldas hasznalatat. Persze van akinek mas jon be, pl. a Korolev fele parhuzamos 4 booster-es, 1.5 stage-es megoldas konnyebbe teszi a staging-et, de cserebe nem idealis a rendszer hatekonysaga es a raketa legellenallasa a booster levalasztas elott. Persze az ursiklo fele oldalra odakotozott repulo teglahoz kepest fenyevekkel jobb. Szoval nem, a raketamernokok szamara sem trivialis az idealis forma.
A Spacex a crew dragon-nal es az uj cargo dragon-oknal felhasznal egy regi (gorog) geometriai szabalyt, ami javitja a hatekonysagot es csokkenti a terhelest max q-nal, de az amerikai konkurensek kozzul se a starliner, se az artemis kapszula tervezoi nem ismertek fel. (a sojuz pedig burkolattal indul, ott nem szamit) A blue origin sem jott ra, de ok legalabb megprobalnak mindent lemasolni, tehat lehet veletlenul ezt is sikerul majd. Nem irom le micsoda, de a lenyeg a kapszula formajaban van. (a spacex is hallgat rola, meg szabadalmat sem adtak be ra)
"Egy rakétamérnök mélyreható ismeretekkel rendelkezik, amihez képest visszalépés lenne a "trial and error" módszer,"
Ezt reszben test driven development-nek hivjak, ami az iterativ tervezes egyik modernebb valtozata. Hardveres kornyezetben igy jutunk el a deszka modelltol (a szo szerint deszkara szogelt alkatreszektol) a kesz termekig. Ezert van az, hogy pl. a Boeing-al szemben a Spacex minden alrendszert letesztel meg indulas elott, eloszor kulon-kulon, aztan integralva. Viszont eles repulesi tesztet csak repules kozben lehet vegezni. Az osszes tervezoasztalon "tesztelt", bizottsagok altal tervezett jarmu tele van tervezesi hibakkal, amiket ki lehetett volna kuszobolni ha mertek volna ujratervezni amikor egy hiba elojott. Pl. az ursiklo elso utjanal kijott a hovedo csempek lehetseges serulese, de csak a feher festek elhagyasaval es az inditasi homerseklet es paratartalom limitalasaval probaltak tenni ellene, de nem terveztek ujra az egesz jarmuvet, mert tul keso volt mar a hagyomanyos vizeses modell szerinti fejlesztes soran. A Spacex mer hibazni, es utanna mer teljesen ujratervezni valamit ha nem felel meg az elvarasoknak. Az evolucio is pontosan igy mukodik, neha erdemes tanulni belole. -
llax #12 A tervezést én sem értettem másként, itt annak a tesztelés előtti szakaszára (időtartamára) gondoltam. Tervezni elsősorban a meglévő tudás és tapasztalatok felhasználásával lehet. Itt jönnek képbe az (űr)ipar drága anyagai és módszerei, tapasztalat leginkább azokkal van (az F9 esetén is ezeket alkalmazták). Viszonylag kevés kísérletezéssel és kiszámítható idő alatt csak az előbbiek használatával tudnak haladni (erre használtam a "biztosra menve" kifejezést). A SpaceX a drága anyagok és költséges gyártási eljárások alkalmazását próbálja minden korábbinál jobban visszafogni a Starship esetén. Az űriparban ez egy új megközelítés.
Egy konkrét eszköz megtervezése érett elképzelések, jól meghatározott célok után történik. A Starship esetén egyszerre zajlik az útkeresés és a fejlesztés. Emiatt minden képlékeny és az is marad még sokáig.
Az eddigi repülések nem a hajtómű teszteléséről szóltak (azt McGregorban végzik, erre alkalmas körülmények között). Nem is arról, hogy egy tartályt felemeljenek rakétahajtóművel. A tesztelés oka a leszállás előtti manőverek és maga a leszállás kipróbálása volt. SN6-ig csak függőleges leszállás, SN8-tól halmozottan jelentek meg korábban senki által ki nem próbált megoldások (maguk a manőverek, az aero elemek, a kettős üzemanyagrendszer). Ezen megoldások életképességét igazolni kellett ahhoz, hogy tovább lehessen tervezni velük. (Itt jön képbe az 50-es évek: Megbízható szimuláció ahhoz van, amivel több-kevesebb gyakorlati tapasztalatok is vannak. Anno szimuláció sem volt, most az SpX egyes elképzeléseihez nem volt.)
Ezt nem késznek tekinthető, hanem még fejlesztés alatt álló hajtóművekkel végezték, de még így sem mindig (csak) azok okozták a problémát. Emiatt több nekifutás is kellet, mire sikerült a tervezett módon leszállni vele.
Voltak érdekes húzásaik (tesztelések kihagyása), az Mk1 esetén még az átlag fórumozó is látta, hogy 1:1 makettnek is durva, nemhogy repülést tervezni vele (vagy akár nyomáspróbának alávetni). Várhatóan az orbitális teszteknél és majd a leszállások megkísérlésénél is lesznek még ilyenek (részbeni újratervezésekkel, irányváltásokkal együtt).
-
Irasidus #11 "ps: A klassikus V2-es raketak alkohol+viz/folyekony oxigen hajtasa is szenhidrogen alapu volt. Igazabol az osszes szenhidrogen hajtasu raketa ugyanazt az elvet koveti es idealis formajuk sem valtozott sokat, csak a meretuk es technologiai fejlettseguk nott."
Hát igen, ilyen az amikor az egyszeri ember rájön az aerodinamika csodás világára, és, hogy mit jelent a rakéta-elv. Milyen elvet követhetne még egy rakéta, és milyen más formája lehetne? De tényleg, amikor ilyeneket írsz...
Utoljára szerkesztette: Irasidus, 2021.11.30. 21:30:37 -
Irasidus #10 Egész pontosan csak a szoftver fejszerésben használják iterative development-et. SPOILER! Kattints ide a szöveg elolvasásához!Minden területnek meg van a maga eljárási rendje, nem átjárhatóak, így nem húzhatod rá a programozási modelleket más területekre, mert a egészen más elvárások, módszerek, és engedélyek, vannak különböző iparágakban, és fejlesztési területen. Az ötvenes években a tudásuk legjavát beleadták, most meg tudatosan rossz, vagy bevizsgálatlan rendszereket építenek egybe. Egy rakétamérnök mélyreható ismeretekkel rendelkezik, amihez képest visszalépés lenne a "trial and error" módszer, az meg mínusz lépés lenne, ha direkt selejtes, bevizsgálatlan, elellenőrizetlen eszközökkel tesztelnek, mint ahogy látjuk is példát.Másrészt ez egy olyan szoftverfejlesztési megközelítés, amely egy nagy alkalmazás fejlesztési folyamatát kisebb részekre bontja. Mindegyik rész, az úgynevezett „iteráció”, a teljes fejlesztési folyamatot reprezentálja, és külön tervezési, fejlesztési és tesztelési lépéseket tartalmaz. A vízesés modelltől eltérően az iteratív folyamat egyesével ad hozzá funkciókat, így minden iteráció végén működő terméket biztosít, és ciklusról ciklusra növeli a funkcionalitást, ellenben nagyon rugalmatlan.SPOILER! Kattints ide a szöveg elolvasásához!(azaz "megnézik jó-e" - hm, érdekes, hogy kizárólag programozási kifejezésben tudsz gondolkodni)
Utoljára szerkesztette: Irasidus, 2021.11.30. 21:21:31 -
kvp #9 Ezt hivjak iterativ fejlesztesnek. A szoftveres teruleten is nepszeru, csinalunk valamit amirol azt gondoljuk, hogy a legjobb, megnezzuk hogy jo-e. Ha nem, akkor modositunk rajta, hogy jobb legyen, megint megnezzuk. Egyebkent az evolucio is hasonlo elven mukodik, mindig a legjobb megoldas megy tovabb a kovetkezo generaciora.
Nem a legolcsobb elv, de a leggyorsabban tud mukodo eredmenyt hozni. Valoban ilyen volt az 1950-es evek raketatudomanya. A rozsdamentes femtartaly is a regi Atlas raketaktol jon. Egyebkent a formaterv is. Vicces plusz info, hogy az Atlas-ok hajtomuveitol szarmaztak a Saturn raketak hajtomuvei. Gyakorlatilag a Spacex az Atlas - Saturn sorozatot folytatja a Starship-pel. Az Atlas-ok ugyanugy adtak a korai ballisztikus raketakat es kesobb a Mercury es Gemini hordozoit, ahogy a szovjeteknel az R7-es (Semyorka) adta a kesobbi Vostok, Sojuz es Progress hordozojat. Masik parhuzam, hogy ahogy az Atlas sorozat utan epitettek egy nagyobb jarmuvet, a Saturn-okat, ugy a Falcon 9 utan is keszul a nagyobb Falcon, a BFR azaz a Starship. Gyakorlatilag ez egy oriasira nott Atlas raketa. (ami ala vegre teljesen befernek a hajtomuvek is) Az uzemanyag sem veletlen lett RP1/LOX a Falcon-okon, es LNG/LOX a Starship-eknel. Ha a szenhidrogen alapu hajtas az 1950-es evekben jo volt az amerikaiaknak es a szovjeteknek, akkor jo lesz meg a kovetkezo par evtizedben is.
ps: A klassikus V2-es raketak alkohol+viz/folyekony oxigen hajtasa is szenhidrogen alapu volt. Igazabol az osszes szenhidrogen hajtasu raketa ugyanazt az elvet koveti es idealis formajuk sem valtozott sokat, csak a meretuk es technologiai fejlettseguk nott. Egyebkent a V2-esek prototipusai kozott volt 3 fajta aminek volt ket canard szarnya is az orr reszen, de a ballisztikus visszateres miatt (csak be kell csapodnia) vegul elhagytak oket. A Starship-nel viszont nagyon jol jonnek. -
Irasidus #8 A tervezés nem azt jelenti, hogy "biztosra megyünk", hanem bármilyen ötlet megvalósításának az egyetlen, valóban működő, komplex rendszerbe foglalt eljárási rendje. A tervezés nem egyenlő a drága anyagokkal, vagy kompromisszumokkal, mivel a tervezés nem ellentéte az innovációnak, és nem egy elavult módszer, hanem az egyetlen lehetséges út. Amit eddig csináltak az nem egy új tervezést nélkülöző módszer, hanem tervezés, és az irány teljes hiánya! Az általad említett prototípus, és a jelenlegi (erős jóindulattal) tesztpéldány(ok) között óriási különbség van. Viszont amiért ezt nem lehet tesztnek hívni az az, hogy hiányzik a tesztelés oka, módszere, és mikéntje, gyakorlatilag minden. Egy hajtóművet - akármilyen hajtóanyagú - tesztpadon tesztelünk, és nem egy rozsdás konzervdobozon, ugyanígy tartályokat nyomáspárbank vetjük alá - azaz teszteljük - mielőtt egy komplexebb rendszerbe foglaljuk, és folytathatnám napestig... Nézd, ha nem érted mivel foglakozik egy mérnök, és milyen szakkifejezéseket használ nem baj, de legalább ne gyárts szalmabáb érveket, és ne bullshitelj. Minden eszköz adott a teszteléshez, az eddigi tűzijáték semmilyen innovatív eljárási rendet nem tartalmazott (vagy ha igen, nevezed meg), és semmilyen újat nem adtak a tesztelési eljárásokhoz! Az ötvenes évekhez hasonlítani a SpaceX lehetőségeit, és azzal érvelni, mennyivel jobb volt, úgy rakétát tervezni... meg kifejezetten bullshit, elég megnézni mi lett a vége.
Utoljára szerkesztette: Irasidus, 2021.11.30. 17:47:56 -
llax #7 Nagyobb részben egyet tudok érteni.
De van 1-2 dolog, amit nagyon másképp csinálnak mint a többi cég. A módszereik egy része inkább az 50-es évek 2. felének felel meg.
Lehet valamit évekig tervezni, majd a biztosra menve nagyon drága anyagok használatával és egyes paraméterekben súlyos kompromisszumokkal (vagy durva túlméretezéssel) megvalósítani. Ekkor a késztermék is olyan lesz, mint a többi.
Vagy elkezdhetnek olyan anyagokat és megoldásokat használni, amikkel nincs több évtizedes tapasztalat a területen. Ilyen a metánhajtás, ilyen a full flow hajtómű, ilyen a rozsdamentes acél (majdnem) ballontank konstrukció (hővédelemmel ellátása). Tapasztalatok hiányában épkézláb szimuláció sem lehet ezekre (majd lesz). Így a paraméterek is képlékenyek.
(A Hopper szintén Raptor-t használt, csak ott nem kellett újragyújtani. Annyira nem volt kész a technológia, hogy a többedik Raptor példánnyal tudták csak reptetni, a többi a rövidebb teszteket se bírta ki.) -
Irasidus #6 Ez nem prototípus, ez látvány és marketing eddig, és nem valódi fejlesztés. Különböző állami intézmények pénzeire menntek rá ezzel a fejlesztésnek álcázott tüzijátékkal. A kérdés, hogy most, hogy NASAtól fog kapni egy kis pénzt, az mire elég.
1.) szenzorok sincsenek mindenhol, így a hiba okát sem tudnák, de biztos ez a nagyon tuti módszer...
2.) Általában 3 Raptor hajtőműből 1-2 gyári hibás. +2.1.) nem indult leszálláskor. Magyarul a hajtómű sincs kész.
3.) Bármilyen eszközt először tervezőasztalon kell megtervezni, nem trial and error módban, egy COPV tartály esetében ez kifejezetten ostobaság. A tervezést nem tudod kiváltani próbálgatással. Az egész egy mérnöki bullshit.
4.) A Hopper esetében egy kész technológiát reptettek (hajtómű, tartály), ja és volt forrás és dokumentáció, itt csak hájp van.
5.) Az első típusoknál a legkritikusabb részek esetében láthatólag hiányoznak az illesztőgyűrűk, kizárólag hegesztve voltak a tartályok, ami borítékolhatóan nem bírta nyomást, és szét is vette a nyomás. A fizikát nem lehet becsapni.
5.) Miféle fejlesztés az, ahol évente változik a tömeg, méret, hajtómű száma, típusa, de a tesztpéldány semmiben nem követte? Mit teszteltek, mert még a tömeget sem...
6.) A tervezést nem hagyhatod el, de szólj ha tudsz valami tervről.
7.) Igazából van még, csak itt untam meg...
Utoljára szerkesztette: Irasidus, 2021.11.30. 14:57:31 -
llax #5 Ilyen a fejlesztési stratégiájuk. Akkor is elindítják, ha előre tudják, hogy pl. 60% az esély a teljes sikerre. A kísérleti járműveiknél a tűzijáték gyakorlatilag a fejlesztés része. Ezért is épül párhuzamosan több prototípus, a következő példányon igyekeznek az előző hibáit kiküszöbölni. -
#4
"a Starship végre nem robbant fel a repülés előtt vagy annak során"
Mondjuk ez tényleg üdvözlendő a jövendőbeli utasok számára. -
kvp #3 A cikkben meg a 2+3 szanyu jarmu van, a valosagban ebbol mar csak 2+2 maradt, de azok legalabb mind allithatoak. Egyebkent a Falcon 9 booster-ek altal hasznalt hover slam otlete tenyleg a Flash Gordon-bol van, ott is ugy szallnak le a raketaval, hogy pont a foldeteres pillanataban kell elerni a 0 gyorsulast.
A formarol csak annyit tudok mondani, hogy ha megezzuk a klasszikus von Braun fele V2-est, akkor az is kb. ez a forma es belso elrendezes, csak kisebb meretben. Minden mas megoldas (lasd Falcon Heavy, Ariane 5) csak kompromisszum, hogy gyengebb raketakbol valami nagyobbat legozzanak ossze.
https://en.wikipedia.org/wiki/V-2_rocket#/media/File:Aggregat4-Schnitt-engl.jpg
https://www.humanmars.net/2021/01/cutaway-schematic-of-spacex-starship.html
Igazabol ha kemiai raketat epit valaki es a 0-rol tervezi, akkor nagyon mas format nem erdemes hasznalni. -
ProgServ #2 Ezt az uuurhajot mar lattam valahol. Aaaaa megvan. A video vegen... :D
https://www.youtube.com/watch?v=hYTYqs-ytSk -
asgh #1 Az indításnak első sorban bürokratikus és nem műszaki feltételei vannak. A kilövés már akár idén októberben is megtörténhetett volna, csak az FAA hivatalos jóváhagyására várnak.
A SpaceX a Boca Chicca területre csak Falcon 9 és Falcon Heavy indításra kapott engedélyt, így azt ki kell terjeszteni a Starshipre. Az engedélyeztetés már húzódik egy ideje, jelenleg túl vannak a nyilvános meghallgatásokon, most az FAA-nek kell döntenie, hogy teljes környezeti vizsgálatot indít-e (ami akár évekig is eltarthat) vagy zöld utat ad a projectnek.
Azaz a januári kilövés a legoptimistább forgatókönyv, még az is lehet (bár szerencsére nem túl valószínű), hogy az egész projectet át kell telepíteni Floridába.
Utoljára szerkesztette: asgh, 2021.11.29. 11:08:08