close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Mediehuset Ingeniøren og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Mediehuset Ingeniøren kan findes markedsføring fra samarbejdspartnere.
rumfart på den anden måde cs banner bloghoved

At designe en rumraket - Trin 3/3

Så kære læsere, nu går det løs!

Vi er nemlig nået til sidste del af vores lille føljeton om systemdesignet af Spica raketten, der udgør en af hjørnestenene i CS' minimalistiske system til bemandet rumfart. Dog mangler vi stadig at berøre et helt centralt emne, nemlig udviklingsplanen. Med det teoretiske grundarbejde på plads ved vi nu, hvor vi skal hen design- og performancemæssigt, men hvilke elementer rummer rejsen mod målet egentlig, og hvilke tekniske milepæle og udfordringer ligger der på vejen? Det kommer til at tage mange indlæg fra mange grene af CS at give et bare nogenlunde fyldestgørende svar på de spørgsmål, og forvent derfor talrige indlæg i fremtiden om konkrete tekniske problemstillinger. Men lad os i første omgang prøve at betragte missionens delelementer og udestående opgaver i det lidt større perspektiv. Derefter kan vi med det forkromede overblik i behold dykke ned i detaljen i resten af denne og kommende blogs.

Vi starter med et af de helt centrale værktøjer i systemingeniørens rygsæk, nemlig den såkaldte Work Breakdown Structure eller WBS. WBS'en har til formål at splitte et komplekst projekt op i mere eller mindre selvstændige delelementer, således at der kan identificeres individuelle undersystemer og dertilhørende arbejdspakker. På den måde kan vi danne os et overblik over opgaven som helhed, og få uddelegeret konkrete opgaver med konkrete mål til de enkelte grupper i CS. Professor David Akin har en lidt anden udlægning af WBS'ens formål, som også rummer et gran af sandhed: 'It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.'

Ja... 'Its funny 'cause its true' som Homer Simpson ville have udtryk sig...

Hvis vi tager vort udgangspunkt i den generelle dimensionering af Spica fra sidst, så kan vi helt konkret bruge WBS-metoden til at splitte missionen og det komplekse system op i en lang række delelementer der falder i to segmenter: Flight-segmentet, som rummer alle aspekter af det, der skal flyve, og Ground-segmentet, der indeholder alt, hvad vi behøver af supportudstyr og systemer på jorden. Eksempler på de første niveauer af de dertilhørende WBS'er kan ses herunder.

Illustration: CS

Figur 1: Eksempel på Flight segmentets Work Breakdown Structure niveau 1 til 3. (figur: CS)

Figur 2: Eksempel på Ground segmentets Work Breakdown Structure niveau 1 til 3. (figur: CS)

Derudover kunne vi også sagtens forme en tilsvarende WBS for alt, hvad der har at gøre med tilpasning af CS' faciliteter på Refshaleøen med henblik på at kunne producere og teste Spica og hendes undersystemer. Herunder indgår eksempelvis arbejdet med at redesigne og refitte teststanden, etablere infrastruktur og værktøjer til at præcisionssamle og håndtere fuldskala boosterelementer, tanke og kapsler i Ø955, faciliteter til at samle og teste avionics, osv. osv.

Ok, vi behøver ikke at gå længere ned i detailniveau med WBS'erne i denne omgang, så risikerer jeg også bare at afstedkomme anfald af kollektiv læsermigræne, men for eksemplets skyld så lad os prøve at løbe lidt af opgavelisten for launch pad'en (aka MLP Sputnik) igennem, så I kan se hvordan WBS'en niveau 3 lader sig udkrystallisere i konkrete underopgaver (svarende til WBS'ens niveau 4 og 5). På Sputnik skal der bl.a. ske følgende:

Figur 3: MLP Sputnik i sin nuværende konfiguration. (Foto: Thomas Pedersen)

  • Forøgelse af lastkapacitet til at kunne håndtere/servicere et 4.000 kg bemandet raketfartøj.
  • Redesign af launch rail/servicetårn, som tillader stacking, adgang til rakettens accesspaneler samt sikker kapselservicering og astronaut-ingress og -egress.
  • Design og implementation af et hold-down system, der sikrer at raketten først forlader pad'en når nominel thrust er opnået.
  • Etablering af fuel/oxidizer tankning- og detankningsfacilitet ombord.
  • Etablering af sikkerhedssystemer, gasovervågning, water deluge system etc.
  • Design og implementation af et remote quick-release system til rakettens tank- og tryksætningssektion.

Ovenstående er at betragte som et uddrag af de væsentlige udeståender for at omdanne Sputnik til en funktionel launch pad for Spica i sin endelige form. Der er tale om en mængde omfangsrige delopgaver, udover den løbende drift og vedligeholdelse af fartøjet.

Mange af de andre elementer i såvel Flight- som Groundsegmentet indeholder opgaver af tilsvarende eller endnu større omfang og varetages ihærdigt og systematisk af undergrupperne i CS. At blive klar til Spica kommer således til at kræve en betragtelig og fokuseret indsats over en bred front i CS i de kommende måneder, samtidig med at foreningens økonomi også skal kunne følge med aktiviteterne. Men vi er ved godt mod og går på opgaven med glæde og krum hals!

Realistisk set betyder det også, at vi ikke forventer at have den første flyveklare Spica på rampen før 2016-flyvesæsonen, og det er bydende nødvendigt, at vi er realistiske her. Ellers spilder vi alles tid og, måske endnu vigtigere, CSSernes tillid og støtte.

Det betyder imidlertid ikke, at vi har i sinde at ligge på den lade side i flyvesæson 2015, som jo reelt står for døren om ganske få måneder, tværtimod! Denne sæson skal nemlig udnyttes til at tage nogle teknologiske kvantespring og få testet Spicas nøgleteknologier.

Omend vi nok kunne nå at konstruere en enkelt, fuldskala Spicamotor og få gennemført en enkelt hot-fire test på den inden flyvesæson 2015, så er det ikke en farbar vej for CS. Vi har været der med HEAT-2X, og vi skal ikke ned ad den sti igen. At kombinere prototypemotorer med fuldskala testflights er ganske enkelt ikke en farbar strategi på amatørniveau, når det handler om at skabe det niveau af designmæssig pålidelighed, robusthed og reproducerbarhed, der skal til for overhovedet at kunne overveje bemandet flyvning.

I det hele taget kan testen af HEAT-2X tages som lidt af et skræmmeeksempel i denne kontekst. Den statiske afprøvning af 2X var på alle måder en meget dyr test. Ikke kun pga. testens udfald, som reelt kostede raketten livet, og ej heller alene med tanke på de tabte kroner og øre i hardware og drivmidler, men måske mest af alt operationelt. Reelt set kostede den test alle CS' produktive hænder i godt 3 måneder. Tre måneder hvor al hardwareproduktion uden direkte kobling til 2X måtte sættes på hold for at frigive alle gode kræfter til at klargøre og eksekvere testen. For en organisation som CS er det en ekstremt ineffektiv og serialiseret måde at arbejde på. Et af hovedformålene med systemdesignøvelsen har derfor også været at sikre et tilstrækkeligt modent systemdesign, der tillader os at arbejde parallelt på opgaverne. Kun på den måde vil vi kunne formå at udnytte styrken og bredden i foreningen og derved komme ud over stepperne.

Så hvordan planlægger vi konkret at udnytte sæsonen 2015? Svaret på det spørgsmål er tæt knyttet til Motorgruppens udviklingsplan, så lad os kaste et blik på den først og så vende tilbage til spørgsmålet til sidst.

Motorudvikling

I det lille hjørne af CS, der kaldes Motorgruppen, beskæftiger vi os i sagens natur med udvikling af raketmotorer og de dertilhørende undersystemer, der indgår i Spica-boosteren. I det følgende vil vi kigge nærmere på udviklingsplanen for motorsegmentet og resultaterne af det analyse- og designarbejde, der har pågået på den front over de sidste par måneder.

I kontekst af Spica er det Motorgruppens ansvar at forestå udviklingen af den raketmotor, som skal bringe vores kapsel 100 km lodret opad. Intet mindre.

Motorgruppen har i den forbindelse to meget tunge åg, der skal løftes. De hedder reproducerbarhed og pålidelighed. Det kan ikke understreges nok. Vi skal ikke kun levere den nødvendige performance. Vi skal levere den samme performance HVER gang, og det med en pålidelighed høj nok til ultimativt at kunne vove den ultimative drengestreg: At sætte et menneske ovenpå vores arbejde i 90 nervepirrende sekunder.

Qua det indledende dimensioneringsarbejde foretaget på Spica (jævnfør forrige indlæg) ved vi, at vores mål kan nås med rimelig margin for en 100-kN, Dynamic Pressure Regulation (DPR) dreven LOX/ethanol/H2O, bi-prop-motor, såfremt der kan realiseres en Isp-effektivitet på minimum 80%. Derudover giver Spicas dimensioner også nogle ydre geometriske og vægtmæssige randbetingelser for denne motor, som tilsvarende er bestemmende for motorens endelige udformning.

Andre nok så vigtige randbetingelser for Motorgruppens arbejde har været centreret om at identificere motorteknologier, der ville være egnede til Spica, og som vi i CS kan producere godt nok. For de teknologier, vi vil kunne beherske i CS' regi, har raketmotoren som sådan ikke ændret sig voldsomt i de sidste 40-50 år. Der, hvor udviklingen virkelig har ændret vore muligheder, er på fronter såsom automatisering, instrumentering, reguleringsteknik og ikke mindst CAD/CAM, 3D-printing og CNC-fabrikationsteknikker. Det agter vi naturligvis at udnytte til vores fordel fremover!

Raketmotorudvikling er dog et af de områder, hvor Moder Natur ikke typisk udviser særlige hensyn, uanset om vi påberåber os amatørstatus nok så mange gange. Industrielt har man derfor nogle helt klare kriterier for at kunne kvalificere en raketmotor til operationel status. Designet skal have kørt uden modifikation (men dog gerne på separate motorer) ikke mindre end 10 fulde driftscyklusser uden fejl, med nominel performance. Tilsvarende skal en motor af samme design gennemløbe et fuldt kontinuert burn på minimum 2 gange varigheden af et nominelt burn. Sidst men ikke mindst skal en testmotor gennemgå en margin-test, hvor man presser designet på såvel kammertryk, flowrate og oxidizer/fuel blandingsforhold samt evnen til at overvinde induceret instabilitet. Først herefter kan man begynde at tale om et kvalificeret og pålideligt design.

Det er formentlig næppe hverken realistisk eller ønskværdigt for CS at operere med dette kvalifikationsniveau, men omvendt kan vi heller ikke længere nøjes med happy-go-lucky metoden, hvor vi med én fornuftig test under bæltet klapper hinanden på skulderen og siger, at nu er vi klar til at flyve. Dertil er raketteknikken for lunefuld, og dertil er sandsynligheden for uerkendte fejl for stor.

I amatørregí er der reelt nok kun én vej frem, når det handler om at minimere designtekniske risici og øge pålideligheden, og det er test, test og atter test. Det skal vi blive bedre til i CS, men først og fremmest skal vi udnytte vores nyfundne viden om systemdesignet til at splitte tests op på delkomponentniveau, således at vi fjerner afhængigheder, simplificerer og arbejder parallelt på flere processer.

I motorsammenhæng kunne et repræsentativt eksempel på denne tankegang knytte sig til engine controlleren. Denne elektronikenhed står for opstart, nedlukning og styring af motoren gennem alle burnets faser. Test og udvikling af denne enhed og ikke mindst dens software, kan i princippet pågå uafhængigt af hvilken motorstørrelse, der arbejdes med, hvis man kan formå at standardisere sensorkonfigurationen og fødesystemet omkring motoren.

Et andet eksempel kunne være det DPR-tryksætningssystem, vi introducerede i forrige indlæg i denne føljeton. Reguleringsalgoritmen, de operationelle modes, fejlscenarier, sensorapparatet og kontrolhardwaren bag et DPR-system er tilsvarende uafhængige af motorens størrelse.

I de første uger af Motorgruppens arbejde blev det hurtigt klart, at vi har et enormt behov for en testmotor i mindre skala for at undgå 2X-faldgruben fremover. En meget væsentlig del af motorarbejdet (reelt alle operationelle principper, der ikke skalerer med motorens størrelse) kan faktisk udvikles, testes og kvalificeres med grundige, omfattende margintests på en langt mindre motorplatform end Spicas massive 100-kN motor. Forskellene er til at tage og føle på: For 1.000 kr drivmidler frem for 50.000 kr, én weekends arbejde for en test versus 2 måneder, 5-6 mands test crew frem for 30 mand, test flere gange om måneden frem for 2-3 gange om året. Med det perspektiv har konceptet ikke været svært at sælge internt i CS.

Motorgruppen har derfor splittet hovedopgaven op i to sideordnede processer. Det første spor, som sigter mod at udvikle en "lille", modulær bi-prop testmotor kaldet BPM-5 (Bi-Propellant Motor 5 kN), og det andet spor, som sigter mod udviklingen af den større 100-kN flightmotor med arbejdsbetegnelsen BPM-100 (ja, vi er ikke så opfindsomme...) til Spica.

Figur 4: Copenhagen Suborbitals' BPM-5 testmotor. (CAD: Thomas Madsen, rendering: Niels Foldager)

BPM-5

BPM-5 er på godt og ondt tænkt som en testmotor med alt, hvad det indebærer af kompromiser og muligheder. Den benytter samme brændstofkombination og fødesystemtopologi som BPM-100, men er i modsætning til den store motor optimeret til kørsel på jorden og muligheden for at påtrykke betydelige variationer i driftsparametrene. Målsætningen med BPM-5 er helt klar: Det handler om tekniske lærepenge og om at få udviklet så meget som muligt af systemet bag raketmotoren, inden vi går til det i testsammenhæng langt mere omkostnings- og ressourcetunge BPM-100 format. At det så også betyder, at vi motormæssigt kan tage et teknologisk kvantespring fremad, samtidigt med at foreningen får økonomisk luft til at rykke på alle de andre områder af WBS'erne, er jo yderligere et lag glasur på lagkagen.

BPM-5-konceptet lader os foretage kritiske dele af den for Spica nødvendige teknologiudvikling med en brøkdel af de ressourcer, det ville kræve at lave den samme udvikling på fuldskala flightmotor-designet. Vigtigere endnu betyder det også, at når tiden så kommer til BPM-100 i 2015, da vil vi have et fuldt karakteriseret og velkendt system bag motoren således, at vi kan koncentrere os om udviklingen af denne med tiltro til, at motorens supportsystemer ikke bidrager med uerkendte fejlkilder. BMP-5 gør det reelt muligt at dele udviklingsopgaven med Spicas 100-kN flightmotor op i to underopgaver af omtrent lige stor kompleksitet, frem for én massiv opgave med ekstremt mange variable. Det er i virkeligheden bare sund ingeniørfornuft, og den måde hvorpå vi kan få mest 'Bang' for vores 'Bucks'... 'Path of least resistance'.

Figur 5: BPM-5 snittegning med sensorer. (CAD: Thomas Madsen, rendering: Thomas Pedersen)

Idet vi ønsker muligheden for at køre relativt langstrakte testserier med BPM-5 ved forskellige blandingsforhold af LOX og fuel, har vi valgt at implementere motoren som fuldt regenerativt kølet med mixture ratio bias køling i injektoren. Sammenlignet med et ablativt brændkammer og dyse giver denne løsning større fleksibilitet og mindre turn-around-tid imellem tests.

Nøglen til at opnå effektiv, stabil og pålidelig performance i enhver raketmotor ligger i injektordesignet. På BPM-5 har vi ønsket at realisere et design, der tillader os at variere så mange parametre som muligt; herunder også fysiske parametre såsom kammerlængden eller injektorgeometrien, men det skal kunne gøres med et minimum af ændringer på konfigurationen af selve test-setuppet. Til den ende gør vi brug af et såkaldt monolitisk injektordesign, som basalt set betyder, at hele injektoren udgøres af én blok aluminium, der CNC fræses, bores og drejes til en meget præcis geometri. Denne design- og udviklingsmetode var meget populær for mindre motorer i 50'erne og 60'erne, men kendt for at være omkostningstung på den tid, da fabrikationstolerancer og de geometriske dimensioner er ret små. Dette er et punkt, hvor vi virkelig nyder godt af de mere moderne fabrikationsmetoder, og den monolitiske injektor er i dag et oplagt CNC-emne.

Figur 6: BPM-5's monolitiske injektor set fra kammersiden. (Tegning: Thomas Madsen)

Selve injektordesignet vender vi tilbage til i en kommende blog, hvor vi også vil runde de flowtests, der lige pt. pågår med henblik på at fastslå præcist hvor godt, vi kan bore et hul. Ja ja ja, jeg ved godt det lyder trivielt, men lige her bliver et simpelt hul rent faktisk til benhård rocket science. For en injektor, som den vi taler om her, med ca. 250 huller i ø0,8 mm og ø0,9 mm er tolerancer, grater og ensartethed voldsomt afgørende, og vi har valgt at gøre vores hjemmearbejde grundigt. Men som sagt: mere om det i et kommende indlæg.

Et andet naturligt spørgsmål her ville være, hvorfor vi dog har valgt lige 5 kN som det nominelle thrustniveau? Som med alt andet omkring BPM-5 har det sin begrundelse. Årsagen er, at vi i den skala kan holde brændkammeret relativt kompakt samt injektorens diameter lille, hvilket bevirker at følsomheden overfor lavfrekvent, akustisk instabilitet falder. Det er en god ting fordi, omend andre typer instabilitet sagtens stadig kan forekomme, så er de akustiske modes de sværeste af diagnosticere, de sværeste at afhjælpe og ofte de mest ødelæggende. Altså bør vi med BPM-5 kunne komme i mål uden brug af injektorbaffles og alle de udfordringer, de medfører. Præcis denne udfordring vil vi dog skulle takle i den fysisk større BPM-100, men vi kan så i det mindste imødese den vel vidende, at systemet bag motoren er veludviklet og gennemtestet.

En anden teknisk detalje, som billederne af BPM-5 ovenfor illustrerer, ligger i selve udformningen af brændkammeret. I vil bemærke, at kammeret er tegnet glat og uden sammenføjninger på indersiden. Ingen skarpe kanter, ingen svejsninger el.lign. Fordelen ved den udformning er en voldsom forøgelse af effektiviteten i vores mixture ratio bias køling og langt mindre friktionstab og lokal varmeoverførsel end CS' tidligere motordesigns. Disse forbedringer har dog en omkostning rent konstruktionsteknisk, idet formen er væsentligt mere kompliceret at fabrikere nøjagtigt. Eller, skulle jeg rettere sige, det troede vi i hvert fald, indtil CSer Jørgen Skyt henledte vores opmærksomhed på en fabrikationsmetode kaldet metal spinning.

For os uindviede i metalformningens ædle kunst var det en øjenåbner og en af de gode dage, hvor man går fra arbejdet beriget med ny viden. Herligt! Efter at have undersøgt processen nærmere viser det sig, at det er muligt at opnå rigtig gode fabrikationstolerancer med metoden, og at vi endda i Danmark har firmaer med ekspertviden på området. Bedst af alt, så har et af disse firmaer, Olsen Metaltrykkeri A/S i Rødovre, indvilliget i at bistå vores projekt.

På denne måde er det altså nu muligt for CS at lave brændkammerets indervæg i BPM-5 som en forniklet stålstruktur i ét kontinuert stykke med alle de fordele det giver os. Tak Jørgen og tak Olsen Metaltrykkeri A/S. Det her bliver stort!

Figur 7: Nominelle driftsspecifikationer for BPM-5 ved en fuel-sammensætning på 75% ethanol og 25% H2O. (CAD: Thomas Madsen, rendering: Thomas Pedersen)

For læsere interesserede i at kigge yderligere på BPM-5's indre har Niels Foldager begået en rigtig flot pdf-baseret 3D-rendering, som kan roteres og nærstuderes. Den kan hentes her (Venstre mus: rotation, højre mus: zoom). Tilsvarende har Thomas Pedersen lagt en model af BPM-5 på Sketchfab som bestemt også er et besøg værd.

Opmærksomme læsere har måske bemærket, at der i baseline-dimensioneringen af Spica fra forrige blogindlæg ikke var inkluderet de 5-8 % thrusttab, man normalt ville se for et jet-vane guidancesystem. Spica har designmargin til at rumme den ekstra brændstofmængde, der ville skulle bruges for at udligne et sådan thrusttab, men vi har af flere årsager gjort os overvejelser om at droppe jet-vane konceptet til fordel for en gimbalbaseret løsning, hvor vi altså styrer raketten ved at dreje selve motoren. Udviklingsteknisk er dette spring ikke så stort, som det måtte lyde, især fordi guidancesoftwaren og sensorsystemet forbliver stort set uændret. Dog skal Spica i en gimbalkonfiguration have et separat system til roll-kontrol. Den store gevinst ved denne ændring er imidlertid, at vi går fra et guidancesystem, som ikke fuldstændigt kan testes og karakteriseres på jorden, til noget der er helt og aldeles deterministisk. Her kan vi altså bytte en udviklingsrisiko, der ellers ville ligge ret sent i processen, til noget, vi kan tage fat på nu og her. Men kun fordi vi har BPM-5.

Figur 8: 1/2", 68-Bar og kryogenkompatibel, fleksibel fødeslange til LOX. (Foto: CS)

For at bruge BPM-5 til gimbalforsøg er det imidlertid nødvendigt at designe test-setuppet til også at kunne håndtere denne applikation. Det betyder, at motoren skal kunne bevæges under drift, samtidigt med at vi stadig skal være i stand til at måle den producerede trykkraft og alle de andre parametre, vi overvåger før, under og efter test. Ergo skal alle forbindelser til motoren være fleksible. For størstedelen af forbindelserne er det en trivialitet, men lige for LOX-fødningen er vi nødt til at benytte en type trykslange, som vist ovenfor, der kan bevare både fleksibilitet og strukturel integritet ved kryogene temperaturer. Disse er dog kommercielt tilgængelige for en overkommelig pris. Det viste eksemplar, brugt til at evaluere og teste på, er erhvervet formedelst 145 kr.

Arbejdet med dimensionering, beregning, design, og tegning af BPM-5 har nu nået sin afsluttende fase, og de første tegninger er allerede sendt til produktion. Vi forventer at motorens enkeltdele vil indfinde sig i CS' faciliteter løbende over den næste måneds tid, og hvis alt går som planlagt, vil vi have den første BPM-5 samlet medio december. Alt i alt vil der blive fabrikeret dele til 4 stk. BPM-5 motorer i første produktionsrunde. For os, der godt kan lide hårde pakker til jul, er det her vist omtrent så hårdt, som det kan blive...

Når vi så har BPM-5 i hånden, hvad skal der så ske, og hvordan relaterer det sig til flyvesæsonen 2015? Jo, lad os hive testplanerne op af skuffen og kigge på det.

BPM-5 Testplan

BPM-5 vil gennemgå et ret omfattende testprogram, der knytter sig til såvel selve motoren som systemet omkring den. Hvis vi starter listen der, hvor den samlede motor første gang optræder i test-setuppet, og fortsætter i kronologisk rækkefølge, så kommer det foreløbigt til at se nogenlunde sådan her ud:

  1. Engine controller dry-run/sensor checkout
  2. System pressurization testing
  3. Cold-flow testing
  4. Blow-down hot fire short run
  5. Blow-down hot fire long run (thermal equilibrium)
  6. DPR hot fire short run
  7. DPR hot fire pressurization medium test (He versus N2)
  8. DPR hot fire long run
  9. Flight configuration hot fire
  10. Gimbal hot fire
  11. Parameter variation hot fire study
  12. Swirl injection study

Bemærk at hvert punkt på denne liste godt kan indeholde mere end én test afhængigt af formålet og udfaldet af foregående tests. For at illustrere, hvordan vi med det samme test-setup kan understøtte så mange typer af tests, er det nødvendigt at kaste et nærmere blik på nedenstående diagram over systemet bag BPM-5. Heraf er det også muligt at få en fornemmelse af hvordan DPR-konceptet fungerer i praksis.

Figur 9: BPM-5 test setup (Illustration: Thomas Pedersen og Jonas B. Bjarnø)

Den første udgave af selve test-setuppet er en kompakt størrelse bestående af en række elementer, herunder 2 brændstoftanke med en kapacitet på hver især godt 30 L. Disse kobles til motoren igennem et sæt hovedventiler (V1 og V2) og fleksible tilledninger. Motoren er ophængt således, at trykkraften måles direkte (via LC3 lastcellen), og fysisk er motor og tankmoduler separeret af en sprængvæg. På tanksiden indgår desuden en højtrykstank og et sæt reguleringsventiler (PR1 og PR2), der sammen med en passende mængde velplacerede tryksensorer og ventiler udgør hjertet af DPR-systemet. Som sådan er test-setuppet ret lig hvordan man normalt ville implementere en testbænk til karakterisering af en ny raketmotor, men i CS-kontekst er instrumenteringsniveauet nok lidt over, hvad vi har set tidligere.

DPR-systemet benytter en 200 Bar tryktank med enten helium eller nitrogen (testforløb nr. 7 vil afgøre vores muligheder på det punkt), samt de to reguleringsventiler til at justere tanktrykket i både fuel- og LOX-tankene baseret på trykmålinger fra P1, P2 og P3/P4. Det er netop ved at foretage denne trykjustering i realtid, at vi vil være i stand til at generere en optimeret thrustprofil for vores motorer, men i og med, at der reguleres direkte fra 200 Bar til ~23 Bar tanktryk, er tolerancerne små, og reguleringen skal være 'tight'. Her er vi dog i gode hænder hos Flemming Nyboe, der har påtaget sig den reguleringstekniske opgave.

Det giver også sig selv, at DPR-systemet kan gå helt i hegnet, indtil vi får det indkørt, hvilket naturligt betyder, at sprængpladerne på de to tanke (BD1 og BD2) er dimensioneret til at kunne ventilere det maksimale flow fra DPR-systemet. Således kan en overtryksætning af tanken med strukturel fejl til følge ikke ske på den baggrund.

Man vil også bemærke, at der på fuel-siden er introduceret en purge-gren fra DPR-systemet igennem Purge1-ventilen og CV3-kontraventilen til motoren. Denne purgefunktion benyttes efter endt test til at blæse motorens kølekappe og tilledning ren for fuel. Dette er nødvendigt for at undgå, at fuel stagnerer i kølekappen og opvarmes af den stadig varme motorstruktur til det punkt, hvor ethanoldampe begynder at sive ud af motoren. I den situation kan man meget nemt nå et punkt, hvor ret store mængder let-antændelig gas ophober sig i brændkammer, injektor og kølekappe, hvilket historisk set har resulteret i nogle af rumfartens mere interessante post-test failures til fare for både test crew og hardware. CS har også tidligere haft en uheldig 'event' på dette felt, så denne gang er der ingen undskyldning for ikke at gøre det efter bogen, og addere purge funktionen til setuppet.

I den sidste del af testforløbet er der allokeret testtid til et variationsstudie, hvor vi kan presse BPM-5 i forskellige retninger i et forsøg på at afdække designmæssige svagheder og muligheder for at optimere systemet. Et eksempel på sådan en parametervariation kunne være at ændre på forholdet af ethanol og H2O i vores fuel. Teorien siger, at vi med 25 % vandindhold ved et O/F forhold på 1,3 ligger lidt vel på den konservative side, og at vi vil kunne vinde måske op til 5 % højere Isp ved at tweake lidt. En sådan ændring har naturligvis ikke stor betydning for BPM-5, andet end at det koster på køleeffektiviteten, men det har lidt mere vidtrækkende perspektiver for BPM-100. Så det skal naturligvis efterprøves!

Figur 10: Teoretisk effekt af variationer i ethanol/H2O blandingsforhold. Værsgo Benny ;-) (Figur: CS)

Det er i øvrigt vores klare forventning, at vi undervejs i processen vil formå at eliminere nogle BPM-5'ere. Ellers tester vi ganske enkelt ikke grundigt nok. Forvent derfor alle fejltyper fra misfires til screech-instabilitet, hard-starts, CATOer, chuffing osv. Sådanne events er en naturlig del af raketmotorudviklingsprocessen; især når man arbejder på eksperimentel basis. Det handler blot om altid at forvente, at det kan ske, og planlægge derefter.

Men hvad så mht. flyvesæson 2015? Ja, bemærk her, at der i BPM-5 testprogrammet er indsat et punkt, der hedder 'Flight configuration hot fire'. Dette er en test, der specifikt skal bruges til at afprøve BPM-5 i DPR-mode mod en flightprofil, for hvem ville da bruge al den her energi på at designe og bygge en raketmotor uden at flyve den?!?! Ikke vi i hvert fald! Selvfølgelig skal BPM-5 også flyves, og det skal den i 2015!

På motorsiden opererer vi pt. med en plan, der går på at omkonfigurere de samme elementer, som indgår i det viste test-setup til en bi-prop testraket, der vil flyve i sommeren 2015. Mange flere detaljer herom vil følge i kommende blogs, men oplægget er et fartøj med lidt større dimensioner end Sapphire, som tilsvarende vil flyve til noget større højde.

Samtidig må vi også erkende, at der er aspekter af raketteknikken, som CS historisk ikke har haft megen succes med. Et af disse punkter er recovery af, ja, i virkelighed størstedelen af, hvad der er blevet fløjet. Med tanke på hvor kritisk et element recovery er for vores mission (jvf. tidligere betragtninger herom), er det vitalt, at vi udnytter ALLE tænkelige muligheder for at teste og modne vores nøgleteknologier til formålet. At teste faldskærmssystemet og ballutteknologien i forhold til operation i lavt tryk og høj hastighed, bliver derfor et af hovedformålene med sommerens flyvning i 2015.

Husk i øvrigt lige det lidt større perspektiv her: CS' flyvning i sommeren 2015 vil blive vores første med et bi-prop system; Danmarkshistoriens kun andet forsøg herpå (DSC har jo fløjet en bi-prop tilbage i 2007), og det første danske forsøg med bi-prop-teknologi og aktiv styring. Dette er ikke trivielt, og CS skal først til at lære den operationelle side af bi-props til søs. Sommerens test bliver således en kritisk milepæl i forhold til CS' teknologiudvikling hen imod 2016, hvor vi vender tilbage til ESD139 med et 4 ton tungt bæst af en raket: Spica-1.

På den lidt længere bane kan vi altså nu kridte hovedelementerne i CS' tidsplan for flight-segmentet op som følger, naturligvis under forudsætning af, at foreningens økonomi slår til:

  • Vinterhalvår 2014-2015: BPM-5 udviklings- og testprogram, samt udvikling af 2015 testraketten.
  • Forår/sommer 2015: Udvikling af BPM-100 og prototype kapsel.
  • Sommer 2015: Opsendelse af BPM-5 testraket med ballut/faldskærmsforsøg.
  • Efterår/vinter/forår 2015-2016: BPM-100 testprogram og udvikling af Spica-1/prototype kapsel.
  • Sommer 2016: Opsendelse af Spica-1 med prototype kapsel til reentry eksperiment.
  • Sommer 2017: Opsendelse af Spica-2 med flight grade kapsel nr. 1

Så, kære læsere, der er nok at glæde sig til! Først gælder det dog BPM-5, og ihh hvor det dog kribler i fingrene for at komme i gang med at samle og teste... Bare det snart var jul!

Jonas B. Bjarnø
er seniorforsker indenfor rumfartsteknologi og raketudvikler. Han er et af flere medlemmer af Copenhagen Suborbitals, der skriver på denne blog.

Hvornår begynder I at opgraderer Sputnik?
Efter jeres eget testprogram skal det foregå samtidig med at I udvikler og tester Spica-1 eller under udvikling af BPM-100.
Hvor meget skal der ændres på Sputnik?

  • 5
  • 0

Kunne det tænkes at man kunne nået en lille affyring hen mod Nytår

Og i øvrigt tak for en god blok.

Kommer til at tænke på de gange vi var nogen drenge som byggede med Lego, og ved at organisere os og byggeprocessen, kunne vi nå igennem store projekter med "svævebane forbundet togstrækninger samt kraner til fordeling af gods"

  • 3
  • 0