/rumfart

Mr. GUIDO i Q&A: Måske låser vi rorene ved alvorlig fejl

De danske raketbyggere overvejer at programmere deres styresystem til at låse styrerorene i neutral position, hvis rakettens computer opdager en kritisk fejl. Sådan lyder et af svarene fra elektronikudvikler Flemming Nyboe til læserne. Læs alle svarene her.

Af Thomas Djursing, tirsdag 07. feb 2012 kl. 14:28

To Sapphire-raketter bliver de første amatørraketter i Europa, der skal flyve aktivt styret. Affyringen finder sted i Østersøen i sensommeren eller efteråret, og et team på tre udviklere er i fuld gang med at skabe det styresystem, der skal gøre raketten selvstyrende.

Elektronikudvikler Flemming Nyboe programmerer i øjeblikket på det program, der bliver hjernen i toppen af raketten. Han er også kendt som GUIDO, hvilket er Nasa-speak for personen i Mission Control, der står for styring.

Tirsdag den 7. februar svarede han på spørgsmål fra læserne. Læs svarene nedenfor:

Læs også: Simpelt computerspil træner dansk raket til at finde rette kurs
Læs også: Styreprogram i toppen gør dansk raket selvstyrende
Læs også: Se styrefinner blive udsat for jetstråle på 3000 kelvin
Læs også: Se raketbyggernes styrefinner klare test

Det er ikke længere muligt at stille spørgsmål til Flemming Nyboe

Ikon

Svend Ferdinandsen

Hvad er tidskonstanterne for rorudslag til retnings- og bevægelses-ændring? De må være ret forskellige for de forskellige akser.
Vil i også med accelerometrene beregne rakettens position og eventuelt prøve at holde den indenfor en eller anden kegle?

Flemming Nyboe

Goddag Svend, jeg tillader mig at svare i omvendt rækkefølge:
Baseret på IMU'en beregner vi både position og orientering (6 frihedsgrader i alt). Der bliver to reguleringssløjfer: En ydre, som udfra positions fejlen dikterer ønsket kurs, og en indre, som udfra kurs fejlen dikterer ror udslaget.
Og ja, der bliver forskel på tidskonstanterne: Den inderste sløjfe kommer til at reagere så hurtigt som vi kan få den til med en god stabilitetsmargin; servomotorerne er det langsomste led. Den yderste sløjfe bliver gjort bevidst langsom, for at sikre at den inderste kan følge med.

Ikon

Lars Tørnes Hansen

Det kunne være rart at studere elektronik designet, protokoller og softwaren. Bliver schematics[1], software,og protokoller for kommunikation imellem subsystemer offenligt tilgængeligt? Hvis ja, hvor, hvornår, og under hvilken licens (creative commons?)?

[1]: http://en.wikipedia.org/wiki/Schematic#Electrical_and_electronic_industry

Flemming Nyboe

Hej Lars,
Det korte svar er "måske, men nok ikke foreløbigt". Der er ikke meget software at vise frem endnu, vi har p.t. navigations systemet fra HEAT-1X + en lang to-do list. Jeg starter med at ordne to-do listen, og reviewe med nogle CS kolleger (der er flere erfarne software udviklere). Hvis der så udvikler sig en stolthed over resultatet, kan det godt være vi viser det frem :-) Licensen kunne være CC, men vi har aldrig diskuteret det.
I givet fald vil diagrammet over vores onboard computer følge med, da der er en tæt integration mellem software og hardware.

Ikon

Kim Rasmussen

Hej Flemming,
er der en grund til at du bruger en ældre sag som en ARM7 CPU, når der nu er andre CPU'er som f.eks. ARM's Cortex-M3, der har bedre kode densitet, bedre interrupt responstid og væsentlig bedre DMIPS/MHz?
Eller er det mere den pågældende mikrocontroller med dens periphere enheder, der er baggrunden for dit valg?

Undskyld, det var 2 spørgsmål!

Flemming Nyboe

Hej Kim,
Det er netop en Cortex-M3 vi bruger. ARM7 er noget vrøvl jeg har sagt, fordi jeg ikke kan mit ARM stamtræ. Beklager meget.

Ikon

Mogens Kjær

Har også spurgt i det almindelige debatsystem. Men:

Hvorfor 205 gange/sek

Hvor mange gange giver det mening at regulere rorene i sekundet, givet at de ikke bevæger sig hurtigere end de gør?

Er det derfor sekvensen kører 205 gange i sekundet? Eller er det processoren eller noget af det andet elektronik der afgør det?

Flemming Nyboe

Tallet 205 kommer fra ADIS16367 IMU'en, som mest praktisk kan aflæses 819 gange i sekundet, eller en potens af 2 gange langsommere. 205 Hz giver os tid nok til de beregninger vi skal nå.
Servoernes styrekommandoer sendes kun med 50 Hz, og dertil kommer deres mekaniske respons tid.
Men faktisk er det ikke helt spild at køre reguleringen hurtigere end 50 Hz alligevel. Hvis vi aflæste IMU'en med 51 Hz (819/16), ville bevægelses informationen i hver måling i gennemsnit være 1/102 sek gammel, hvilket medfører en ekstra forsinkelse. Ved i stedet at køre regulerings loopet ved en moderat højere frekvens, opnår vi så at sige at hver servo kommando er baseret på lidt nyere data.

Ikon

Thomas Bowley

Hej Flemming
Mange spørgsmål melder sig efter den gode artikel på ing.dk.
Blandt mange er disse:
Hvad er årsagen til at du ikke har valgt et standard RTOS i stedet for dit eget? (Tænker det ville lette samarbejdet med andre i udviklere i fremtiden hvis det var standard)
Hvilket niveau af redundans er der i alt fra styre servo'er, controller hw og ikke mindst software, i tilfælde af et (hårtørrer)nedbrud?
Er du den eneste der sidder som udvikler på styringen? Tænker at et minimum af 3-4 kodereview'ere ville være smart på et sådan kritisk system.
Og sidst men måske vigtigst af alt - Hvordan dokumenterer du dine valg, din implementering og ikke mindst dine tests? Med andre ord, hvad gør du aktivt for at nedbringe "truck-factoren"?

Tak for et ellers godt arbejde til både dig og alle andre på Refshaleøen.
Det var en spændende aften da jeg en dag i sensommeren inden motortesten besøgte området.

Flemming Nyboe

Hej Thomas,
"styresystem" og "operativsystem" skal faktisk byttes i sætningen i artiklen: Jeg har ikke skrevet noget operativsystem, vi bruger intet, og ved styresystem skal forstås selve den aktive styring.

Nogle systemer er redundante, f.eks. strømforsyning, og andre er ikke, f.eks. onboard computeren. Det kunne naturligvis gøres bedre, selvom nogle delsystemer faktisk vanskeligt kan gøres redundante. Men jagten på den mest sandsynlige fejl starter nok med at koncentrere sig om softwaren.

Guidance arbejdet er mere en team indsats end artiklen giver udtryk for, men indtil videre er det kun mig der sidder med styre softwaren. Du har selvfølgelig ret i at det er uholdbart, men der er flere erfarne software udviklere i CS, så det er der råd for. Personligt dokumenterer jeg mine valg og oplevelser i et tekstdokument.

Og selvtak!

Ikon

Lars Juul

Ikke et spørgsmål om guidance, men jeres termiske beregninger: Hvordan har I estimeret den effekt der bliver afsat på overfladen af jetvanen i "udstødningen"?

Flemming Nyboe

Hej Lars,
Det der er i aller højeste grad et guidance spørgsmål. Vi er svært tilfredse med at Kristoffer, Flemming Rasmussen (og flere andre) har frembragt et rorsystem som klarer en test så upåvirket. Der er professionelle som har prøvet med mindre held, og en af de som har lykkes med det, har advaret os om at netop det termiske er en svær udfording ved at styre med stråleror.

Vi har målt temperaturstigningen i et kobber ror, men ikke estimeret effekten. Men lad os bare: Et kobber ror på ca. 800g steg ca. 240K i temperatur. Det kræver 74kJ, og burnet den dag (22/10) var ca. 20 sek, så det er 3.7kW pr. ror. Dette under antagelse af uniform temperatur i det meget varmeledende kobber, og ignorance overfor den varme som er ledt videre ud i det rustfri stålophæng.

Ikon

Jakob Mønster

Har i tænkt en hvis fejltolerance ind i systemet.
Så det både tjekker op på om data er (antageligt) korrekte, og ved udfald i data / defekt måleudstyr, så i kan korrigere for det?

Flemming Nyboe

Hej Jakob,
Mht. sensorer:

IMU'ens output stoler vi på, dels fordi den fysisk er placeret i samme æske som computeren, og dels fordi vi ikke kan erstatte dens output med noget meningsfyldt. Den performede også godt på HEAT-1X.

Kammertryk sensoren er noget andet. Den sidder udsat og i den modsatte ende af raketten. Den mest sandsynlige fejl er at den bliver afbrudt, enten elektrisk eller mekanisk (f.eks. bliver stoppet til med PUR), og derfor viser for lavt. Dette er kritisk, da det vil resultere i for højt gain i vores regulering, hvilket er opskriften på ustabilitet.
Løsningen er ikke lavet endnu, men en realistisk ide er at validere data udfra et kriterie som f.eks. at vi kun bruger trykmålingen, hvis den viser mindst 70% af værdien fra statisk test på samme tidspunkt. Hvis vi kasserer målingen kan vi skifte til en konservativt aftagende funktion baseret på erfaringer fra statisk test.

Ikon

Karl Kaas Laursen

Hvad er de juridiske konsekvenser af at gøre raketten selvstyrende og i sagens natur dermed skaber et missil? Det er vel ikke nok at spørge SOK om lov til affyring af sådan en tingest fra dansk farvand?

Flemming Nyboe

Vi er ikke bekendt med at styringen skulle medføre særlige restriktioner, udover dem som i forvejen henviser os til ES D 139 området. Det er tydeligt at vore intentioner ikke er i den kategori som regler for missiler er henvendt imod, og man kan da heller ikke beskylde os for hemmelighedskræmmeri.

Ikon

Knud-Erik Christensen

Hvorfor laver man styrbare finner i jetstrålen i stedet for at lave styrbare finner udvendigt??

Flemming Nyboe

Hej Knud,
Begge muligheder har været i betragtning. Den store fordel ved stråleror er, at deres styrekraft kan måles i en statisk test, og forventes at være ca. den samme når vi flyver. Det var det vi gjorde den 30/12, og det er vigtigt for designet af reguleringen at kende sammenhængen mellem rorvinkel og styrekraft. For luft-finner kan sammenhængen ikke måles (uden en supersonisk vindtunnel), og teorien omkring det er ubehagelig, selv i tilnærmet form.

En ulempe ved stråleror er, at det er svært at lave noget der kan tåle varmen. Men den har vi jo besejret nu.

En anden forskel er, at stråleror er stærkest først i burnet, og mister kraften ved burnout, imens finner gradvist bliver mere effektive med farten. Begge dele har sin ret, men en svingtur som den HEAT-1X lavede ville bedst kunne korrigeres med stråleror.

Ikon

Svend Ferdinandsen

Er der noget som kan sætte rorene i neutral ved alvorlig fejl.

Flemming Nyboe

Hej Svend,
Det er ikke afgjort, men det er en mulighed, især hvis onboard computeren selv kan detektere fejlen. Dog kan vi ikke gardere os imod et ror som fejler af elektriske eller mekaniske årsager. Rent sikkerhedsmæssigt er fordelen ved den type fejl, at den højst sandsynligt resulterer i en kortere flyvetur.



  • Seneste nyt
  • Mest læste
  • Topdebat
Populært på Facebook
 

Nyhedsbrev

Tilmeld dig vores nyhedsbrev.