Ha már atomreaktor, sztem a 20-40MW kategóriának lenne sokkal nagyobb létjogosultsága űrmeghajtásban. Azután egy-két ilyen babát le is lehetne tenni Mars felszínre.
A cikk nem is tér ki arra, hogy mi lenne a tágulás lényege? Sztem hőleadó felületek. A 1.5MW nem túl sok, ionhajtóműveket biggyeszthetnek rá. Nem igazán látom az emberes marsi utazásban való részvételét.
Valóban nem tudnál repülni sajnos. Már az előző Szojuz generációban (TMA, ahol A - anthropometric) az ISS-re készülve sikerült amerikai kérésre növelni az űrhajósok lehetséges testméretét. Viszont ezzel együtt is 185 centi a felső határ.
Most úgy érzem magam, mint a modern művészetek múzeumában. Amikor ott a tárlatvezető, akkor látom a képen az anyát gyermekével, de amikor vasárnap visszamegyek a családommal, akkor csak kusza vonalakat látok és színpacákat.
Igen. Ők is írják, hogy rögzítési hiba is lehet. Nincs elég visszajelzés, hogy a helyére került-e, kapaszkodik valamennyire félúton is, nem lökődik ki, ha félig van rányomva.
Ha olyan ez a csempe amilyennel én is találkoztam, akkor annyira puha, hogy el is tudnám rágni.
Ez a tulajdonság megkívánja, hogy a lemez villa amire rápattintják sem lehet túl erős, mert közvetlenül csúszik végig a lyukban és nem szánthatja fel. Ha a fém a fémen csúszik, ez a probléma nem áll fenn, és a gyűrű körben támaszt.
Így néz ki a villa, a kis horgocskával.
Ezt a rögzítést nem tartom méltó megoldásnak egy csillaghajó "bőréhez". :-)
hát ez még nagyon nem a x68-os assembly :D ahhoz hogy értsen valamit az ember belőle előtte meg kellene ismerni a pontos architektúrát, utasításkészletet, regisztereket, perifériákat, üzemmódokat, os-t, programokat, verb/noun kódokat, hibakódokat stb stb.. + a komp egyéb komponenseit.. az angol wikipédián ránéztem, de hát kinek van manapság ideje ilyenekbe bele mélyedni ?? :)
Ez durva - az a részletesség, ahogy ismered (riszpekt). Amikor belinkelted a progit, átfutott a fejemen, hogy csak kíváncsiságból belenézek, de nagyon gyorsan revideáltam az álláspontomat e témában. :D
Most leüthetném azt a macsós poént, hogy két ilyen csinos hölggyel összezárva valahogy elviselhetőnek érzem dolgot :) De vagyok annyira repülőember, hogy igazság szerint ha két szőrős kozák paraszt lenne a csajok helyén, akkor is virulna a fejem. Régmúlt vitorlázórepülő koromban egyszer lehetőséget kaptam, hogy a Pik-20D nevű, finn gyártású géppel repüljek. 191 centi magas vagyok, derék finn mérnökök meg valszeg kisebbek, úgyhogy a dekket is csak úgy lehetett rámcsukni, hogy annyira lecsúsztam az ülésben, hogy a műszerfal alsó széle belenyomódott a sípcsontomba, a fejemet meg valami elég idétlen helyzetben behúztam a vállaim közé. Na így repültem végül hat és fél órát, és csak azért szálltam le, mert véget ért a nap. Ezek után nehezen tudom elképzelni, hogy egy rám szabott ülésben, kényelmesen a hátamon fekve ne tudnék pár órát kibírni a startra várva, odafenn, 0g-ben meg valszeg még könnyebb a dolog. Az egyetlen szépséghiba csak az, hogy éppen a magasságom miatt valszeg nem lennék alkalmas a Szojuzra. De ha lehetne, teljesen nyilvánvalóan nem zavarna, hogy nem egy bálteremben ücsörgök, ami miatt jobban aggódnék, az az, hogy a SAS-sal miként fogok megküzdeni.
Teljesen rendben van, ha nem érted. Én már vagy két évtizede nézegetem ezeket az AGC kódokat, és még most is sokszor van, hogy hamarabb megértem a programozók kommentjeiből az adott kódrészlet működését, mint magukból az utasítások bogarászásából. Ráadásul sokszor két-három különböző szintje van a problémának: van a legmagasabb itt az, hogy egyáltalán mit várunk el a TVC-től. Lehet pl. megkövetelni hogy adott irányban tartsa az űrhajót, de olyan is - mint itt - hogy az égetés végére minél pontosabban szeretnénk elérni az előírt (ΔVx, ΔVy, ΔVz) sebességnövekményt, és mindent ennek rendelünk alá. A mérnökök emiatt választották a már említett cross-product steering-et, ez ugyanis elég pontos ΔV vektort eredményez.
A következő szint az a szabályozástechnikai feladat, hogy miként tartsuk a cross-product steering által adott adott szögsebességet a hajtómű megfelelő kitérítésével. Van erre ugye a naív megoldás, amit te is pedzegetsz, hogy az előírt és a tényleges szögsebesség közötti különbséggel arányosan térítjük ki a hajtóművet. Ez látszólag jó is lenne, valóságban azonban egyre erősödő lengésekhez vezetne, pár másodpercnél hosszabb égetéseket így nem lehetne csinálni. A megoldás, amit az SPS TVC-nél használtak, tulképp sztenderd szabályozástechnikai megoldás: egy megfelelően kialakított digitális szűrővel ki lehet kompenzálni a rendszer tehetetlenségeit, késleltetéseit, és a beinduló lengéseket magától csillapítja a rendszer. A konkrét, a linkelt kód által is megvalósított szűrő leírását megnézheted itt: https://www.ibiblio.org/apollo/Documents/R577-section3-rev14.pdf, 93-96. oldal.
Legmélyebb szint meg természetesen az, hogy ezt a digitális szűrőt miként lehet az AGC nem túl acélos hardverén megvalósítani. Az tény, hogy az AGC assembly-je még más processzorok assemblyjével összehasonlítva is elég nyakatekert, ezért nem is akarok belemenni nagyon a részletekbe, csak egy kis izelítő azokkal az elemi feladatokkal kapcsolatban, amiket kérdeztél: - különbség képzés: 156-157. sor, két utasítás, "DCA OMEGAYC" és "DAS ERRBTMP". OMEGAY a cross-product steering által kért legyezőirányú szögsebesség (ellentétes előjellel), ezt DCA parancs betölti az A és L 15-bites regiszterekbe. A DAS parancs meg hozzáadja az A és L regiszterek értékét ERRBTMP nevű memóriahelyen lévő számhoz. Nyilván az ERRBTMP a hibajel, amit azután a digitális szűrő tovább alakít, amíg TVC vezérlőjel lesz belőle.
- feltétel vizsgálat: pl. 537-540. sor. Ez a kódrész módosítja a szűrő paramétereit attól függően, hogy csatlakoztatva van-e a holdkomp, vagy nincs. A kulcs a "CCS A" utasítás, ami - ha A értéke > 0, akkor végrehajtja az utánakövetkező utasítást, ha meg egyenlő nullával, akkor a kettővel utána következőt. Az A regiszterben meg - a megelőző két utasításnak megfelelően - az a flag van, ami megmutatja a LM dokkolt-nem dokkolt állapotát.
- határérték ellenőrzés: 484-503. sor. Itt történik meg a vezérlőjel limitek közé szorítása, a konkrét limit az ACTSAT - actuator saturation, gondolom - memóriahelyen található. Ennek a konkrét értéke bele van égetve a kódba, a 767. sorban: 6 fok, átskálázva valami, a mozgató villanymotorok vezérlése által értelmezhető egész számmá.
szűk de talán nem annyira mint erről a fotóról gondolná az ember, az átjáró kerete miatt még szűkebbnek tűnik mint amilyen, az 'asztal' az ajtó amit meg be lehet csukni a fotó után. és csak startkor/leszálláskor vannak így összeszuszakolva. (ráadásul két nővel könnyebben elviseli az emberfia.) https://youtu.be/24Bz5Ra5RgE?si=r0MR3rlNuS9mCI2g&t=379
Az egész kódot nem értem, úgy ahogy van. Tényleg felfoghatatlan. Egy űrhajó az űrben az egy forgási tehetlenséggel "megáldott" tárgy. Vektoriálással meg lehet adni, hogy mekkora szögsebességgel kezdjen forogni valamilyen irányban, de amikor kezdi megközelíteni az előírt szöghelyzetet, akkor vagy kilőjük az előző vektort egy ugyanolyan ellenkező irányúval, vagy elkezdjük kisebb pif-ek sorozatával csökkenteni a módosító szögsebességet. De ehhez kellene egy határérték bevitel, egy különbségképzés, egy sorozat, egyre kisebb értékekkel, egy összehasonlítás, egy számláló, egy feltétel függvény és még millió apró apró programozási részlet, ami assemblyben nem megkerülhető ( memória kezelés pl.) Semmi ilyen nincsen a kódban. Soha életemben nem programoztam egy sort sem assembly-ben, de azért még azt hittem tudom mit jelent a kódolás általában. Ha tévedek, akkor tévedek - de valami nekem nem megggyőző - ami megint nem oszt nem szoroz semmit valójában.
Gyanítom, hogy nem csak önmagában a rezgés lehetett a probléma, hanem a rögzítés folyamata is. A jelenlegi rendszer ha jól látom nem ad egyértelmű visszajelzést arról, hogy a csempe a helyére került-e, vagy még nem rögzült teljesen.
Van a problémára egy nagyon egyszerű megoldás ami teljesen önzáró, csak a csempe sérülésével lehet leválasztani, nem lehet rosszul a helyére rakni, mert leugrik és talán még egyszerűbb is, mint a jelenlegi.
Egyrészt: nem a tolóerővektor pontatlansága miatt kell trimmelni, hanem a súlypont nagyjából előre tervezhető vándorlása miatt (fogyó anyagok, átkonifgurálódás, stb.). Másrészt: nem csak trimmelésre, de vezérlésre is használták a TVC-t. Ennek az az értelme, hogy égetés közben nem kell használni RCS hajtóanyagot a kívánt irány beállításához, a TVC által biztosított forgatónyomaték meg szinte ingyen van. Utóbbihoz sem kell olyan nagyon gyorsnak lenni a hajtómű mozgatásának, ha ±pár fokra kitéríthető és egy-két másodpercen belül át tud állni a két véghelyzet között, az már elegendő. De hogy egyértelmű legyen, olvasd el az általam linkelt forráskódba írt kommentet a 24. sortól kezdve: # SELF-PERPETUATING T5 TASKS WHICH GENERATE THE COMMAND SIGNALS # FOR THE PITCH AND YAW SPS GIMBAL ACTUATORS DURING TVC (SPS) BURNS, # IN RESPONSE TO BODY-AXIS RATE COMMANDS FROM CROSS-PRODUCT STEERING # (S40.8). IF NO STEERING (IMPULSIVE BURNS) MAINTAINS ATTITUDE-HOLD # ABOUT THE REFERENCE (INITIAL) DIRECTIONS (ZERO RATE COMMANDS).
A T5 az a számítógép egyik beépített, 10 ms-os időzítője, vagyis SPS égetés közben századmásodpercenként fut le ez a rutin és nyúl hozzá a hajtómű mozgatásához. Az inputot kívánt szögsebességek formájában kapja a cross-product steering (vektorszorzat-kormányzás?) nevű algoritmustól. Utóbbi azt csinálja, hogy összehasonlítja az elért sebességnövekmény-vektort az elvárttal, és az irány eltérésének megfelelően tesz javaslatot az űrhajó elforgatására.
Ezt én nem úgy értelmezem, hogy üzem közben nagy szögben, irányítás céljából lehetett a vektort elmozdítani. Hanem úgy, hogy az előre sohasem kiszámítható eredő vektor finombeállítását szolgálta, hogy biztosan a súlypontban legyen a vektor tengelye.
Használták az Apollón is a TVC-t, öt különböző helyen: a Saturn V mindhárom fokozata ilyen volt, de a CSM főhajtóműve, ill. a holdkomp leszállófokozatának a hajtóműve is. Egyetlen kivétel az LM felszálló fokozata, az fix beépítésű hajtóművet használt, bólingatott is rendesen a masina az emelkedés közben. De ezek mellett mind az LM, mind a CSM esetében meg kellett azt oldani, hogy mind dokkolt, mind dokkolatlan égetéseknél stabilan tudja tartani a szerkezetet. De én arra írtam példának az Apollót, hogy már akkor is volt olyan digitális komputer, ami elég gyors volt ahhoz, hogy az űrhajóval kapcsolatos vezérlési feladatokat megoldja. Pl. itt van az Apollo 15-17 CSM számítógépén futó TVC-vezérlőkód: https://github.com/virtualagc/virtualagc/blob/master/Artemis072/TVCDAPS.agc. Amit itt láthatsz, az konkrétan egy többfokozatú digitális szűrő assembly nyelvű implementációja.
"The exhaust nozzle measured 152.82 inches (3.882 m) long and 98.48 inches (2.501 m) wide at the base. It was mounted on two gimbals to keep the thrust vector aligned with the spacecraft's center of mass during SPS firings. The combustion chamber and pressurant tanks were housed in the central tunnel."
Nem emlékszem, hogy az Apollokon lett volna tolóerő vektorizálás. Amolyan kiegészítő fúvókázás volt, fix irányba, fix tolóerővel és a működtetési idővel adták a szükséges irányba a gyorsulást. Már ha jól emlékszem.
Hát nem tudom. Egy bukdácsoló űrhajóban felpörgetni egy lendkereket elég kockázatos. Újabb forgatónyomatékokat fog eredményezni - harmadik irányokba. Már képletezni is nehéz, hát még vezérelni milyen lehet.
Jogos a felvetés, olcsóság szempontjából, de először a Boostert kell elkapni, utána jöhet a Ship.
A SpaceX módszere az, hogy ha tesztelni kell valamit, akkor az menjen az éles módon, ahogy ténylegesen használni fogják..
Ahogy kinéz a dolog, az IFT-4-en még nem fognak szállítmányt vinni pályára (mert a biztonságos visszatérés, a Raptorok pályán való újraindításával, még nem lett kipróbálva), viszont utána már szerintem igen. Tehát azok az indítások már nem nettó veszteségek lesznek. Egyben több dolgot is üzemszerűen tudnak majd párhuzamosan tesztelni, ami gyorsabb fejlesztést jelenthet.
szerintetek ha majd eljutnak az elkapásig, nem kellene megint csak shipet ugráltatni kezdetben egymagában? egyrészt kevesebb motor menne kukába, másrészt kevesebb üzemanyag (kisebb robbanás/kár ha nem sikerül elkapni).. arról nem is beszélve hogy rengeteget fejlődött a ship 2021-óta, és nem láttunk belly flopot azóta se, csak rég a kezdetleges verziókkal.
