/rumfart

En gang imellem besøger Flemming Nyboe  hangaren på Refshaleøen, men typisk arbejder han på styringsprogrammet derhjemme i de sene aftentimer.
(Foto: Copenhagen Suborbitals)

En gang imellem besøger Flemming Nyboe hangaren på Refshaleøen, men typisk arbejder han på styringsprogrammet derhjemme i de sene aftentimer. (Foto: Copenhagen Suborbitals)

Simpelt computerspil træner dansk raket til at finde rette kurs

I de sene aftentimer skaber elektronikudvikler Flemming Nyboe det computerspil, der skal holde den danske rumraket på rette kurs. Det er en kamp med Newton, motorformler og aerodynamik på den ene side og vindstød, tyngdepunkter og lydmuren på den anden.

Af Thomas Djursing, lørdag 04. feb 2012 kl. 12:00

Elektronikudvikler Flemming Nyboe er for alvor gået i gang med at spille computerspil om aftenen. Men det er hverken 'Battle Field' eller 'Warcraft', men derimod et simuleringsprogram, hvor det gælder om at sende en raket op i luften og få den til at ramme samme sted, som den startede.

Programmet er under udvikling af Flemming Nyboe selv og bliver hele tiden finpudset med det formål at ende som styringsprogram i toppen på to styks Sapphire-raketter med en længde på 4,5 meter, der skal sendes 10 til 12 kilometers op til efteråret.

»Snart begynder jeg at påvirke raketten i programmet med vindstød, hurtigere rotation, ændret kammertryk – ja, måske endda en ødelagt styrefinne. Og så er planen at blive bedre og bedre til at ramme affyringsplatformen. Når raketten bliver ved med at ramme plet hver gang trods alle mulige påvirkninger, så er reguleringsprogrammet klar,« siger Flemming Nyboe alias GUIDO, hvilket er ‘Nasa-speak’ for den person i Mission Control, der står for styring.

Styringsprogrammet er helt afgørende for, at de danske raketbyggere Copenhagen Suborbitals (CS) kan nå deres mål om at skyde en bemandet raket ud i rummet. Sidste års test i Østersøen viste nemlig, at finner på ydersiden ikke holder retningen præcist nok. Derfor laver de nu en selvstyrende raket.

Genbruger system fra rumskib
Testen 3. juni 2011 viste, at raketbyggernes navigationssystem med tilhørende IMU fra Analog Devices og en ARM7-mikroprocessor, der sad i næsen af rumskibet Tycho Brahe, virkede over al forventning. IMU’en, der består af tre accelerometre og tre gyroskoper, gav hele tiden data om rakettens position i luften, og sammen med en tryksensor leverede den data til mikroprocessoren om alt fra kammertryk til hastighed, position og højde.

Og rakettens egne data svarede meget præcist til de data, som teknikere fra radarvirksomheden Weibel fik om bord på Mission Control-skibet Hjortø.

Derfor genbruger CS nu det samlede navigationssystem fra Tycho Brahe i de nye Sapphire-raketter for at give styringsprogrammet data under flyveturen. På baggrund af data ved styringsprogrammet nøjagtig, hvor meget kraft der skal overføres til de fire styrefinner, der er placeret i jetstrålen under raketmotoren.

»Det er ren Newton«
Det afgørende er, at programmet omregner data til brugbare størrelser. En udfordring er for eksempel, at rakettens tyngdepunkt ændrer sig undervejs, når raketten bruger brændstof og bliver lettere. Men styringsprogrammet modtager hele tiden data om rakettens kammertryk, og ved at bruge formler om raketmotorers ydelser sammenholdt med data fra raketbyggernes statiske test kan programmet udregne rakettens vægt og og tyngdepunktet.

»Egentlig er det ren Newton. Det hele handler om at beregne kraft og påvirkning. Og alt sker i den her,« forklarer Flemming Nyboe og peger på en ARM 7-mikroprocessor, der ikke er større end en fingernegl.

Mikroprocessoren kører ikke noget styresystem, som eksempelvis Linux, men udelukkende et operativsystem, som Flemming Nyboe selv har skrevet.

205 gange i sekundet gentager styringsprogrammet samme sekvens, der groft sagt lyder:

Mikroprocessor: Hvor dælen er vi?
Navigation: Ups, vi er xx meter fra optimal position.

Mikroprocessor: Hvilken vej vender raketten?
Navigation: Vi vender XX grader.

Mikroprocessor: Hvor mange kilo har jeg slanket mig?
Tilstandsestimering: Du har tabt dig. Nu vejer du XX.

Mikroprocessor: Hvor er mit tyngdepunkt så nu?
Tilstandsestimering: Det har flyttet sig XX.

Mikroprocessor: Føler mig afkræftet. Hvordan er kammertrykket?
Tilstandsestimering: Kammertryk er XX.

Mikroprocessor til ror: Stille! Hør efter! Bevæg XX ror xx grader.

Mikroprocessor: Hvor dælen er vi?
Navigation: Åhh, ikke igen ... Vi er xx meter fra optimal position.
Osv. ...

Undervejs skal programmet også tage højde for faktorer som, at luften bliver tyndere, og raketten dermed bliver mindre selvstabiliserende. Samtidig ændrer aerodynamikken sig ved lydmuren, og endelig bliver det vigtigere at flyve lodret end at ramme den optimale kurs, når motoren er tæt på at brænde ud.

Men selv om udfordringen lyder enorm, er Flemming Nyboe fortrøstningsfuld. Raketten er nemlig ikke nødt til at ende nøjagtig på affyringsplatformen, men kan ramme hvor som helst i en radius af 14 kilometer fra sit udgangspunkt for at blive inden for det tilladte nedfaldsområde i Østersøen.

»Så længe vi bare lader styrefinnerne rette ganske langsomt op, så gør vi det meget nemmere for os selv. Altså i modsætning til missiler, der skal lave hidsige manøvrer for at spore et fly, der prøver at ryste dem af,« siger Flemming Nyboe.

Kobberfinner køler sig selv
Også i raketværkstedet er en prototype til det mekaniske styresystem allerede klar og er blevet testet. Systemet består af fire styrefinner i massivt kobber, der bliver styret af servoer, der bruges til meget store modelfly. Servoerne klarede en statisk test af Sapphire-raketten, og data fra testen viser, at styrefinnerne leverede et meget tilfredsstillende tryk på de sensorer, som raketten var ophængt i.

Temperaturmålinger af kobberfinnerne ved en tidligere test viste en temperaturstigning til 250 grader celsius på 12 sekunder. Med den hastighed, som temperaturen stiger, vil kobberet nå de kritiske 1050 grader celsius efter 48 sekunder. Og det er faktisk ganske fornuftigt, da Sapphire-raketterne vil få burn-out langt tidligere end 48 sekunder.

Det er værd at bemærke, at kobber har et lavere smeltepunkt end jern, men alligevel er at foretrække.

»Havde man lavet styrefinnerne af jern, så havde de opført sig som en isterning, der bliver angrebet med en flammekaster,« siger Flemming Nyboe.

Men fordi kobber er ekstremt varmeledende, så vil det inderste af den massive styrefinne køle ydersiden, indtil temperaturen af hele blokken når smeltepunktet. Når det sker, vil det hele forsvinde på et kort øjeblik.

På den næste store raket, Heat 2X, vil styrefinnerne blive langt større end på Sapphire, og dermed vil kobberfinnen formentlig klare sig i længere tid, så raketbyggerne er overbevist om, at de har fundet det rigtige materiale, der ikke behøver ekstern køling.

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

Animation af det mekaniske styresystem



04. feb 2012 kl 13:58

raymond johnsen

styrring

fed forklaring af styringen :-D
det er da lige til at forstå..!

hvilke hardware dele består computeren af?


04. feb 2012 kl 17:50

Svend Ferdinandsen

Tilbage til start

Det er ikke helt optimalt at du prøver at komme tilbage til start!
Hvis styringen virker rigtig godt, så smadrer i jo affyringsplatformen. Det vil sikkert være spektakulært, men vel ikke lige det i ønsker.
Kommer til at minde om James Bond, som lige nåede at ændre koordinaterne inden raketten blev affyret.
Afstanden XX burde vel være afstanden til en lodret linie op fra platformen.
Umiddelbart ville jeg primært styre efter at holde raketten lodret, og først sekundært prøve at holde den lodret over platformen.
Kalder man rakettens placering over overfladen for epicenteret?


04. feb 2012 kl 18:01

avatar

Thomas Djursing

Re: Tilbage til start

Jeg skal ydmygst forsøge at svare, selvom jeg ikke er ekspert, men dog har snakket ret indgående med flere af raketbyggerne.

Risiko for at ramme affyringsplatformen: Ja den er der selvfølgelig, men uden at kende den nøjagtige risiko, så er jeg sikker på, at den risiko vil være ekstremt lille, da du skal tænke på, at den slukker motoren omkring 10 kilometer oppe, hvis alt går godt. Og da vil sandsynligheden for at ramme et mål på få meter være ekstrem lille. Og skulle de endelig ramme affyringsplatformen, så må man sige, at de har fået styr på den aktiv styring.


Lodret linie: Det er helt rigtigt, at raketten netop hele tiden styrer efter at nå tilbage til en fiktiv linie lodret over affyringsplatformen. Årsagen til, at man styrer efter denne er, at foruden at flyve opad, så er det afgørende, at raketten kan holdes indenfor det tilladte affyring- og nedslagsområde.

Epicentret: Hmm...tja det kan man vel godt kalde det. Det er i hvert fald centret for affyringsområdet.


04. feb 2012 kl 18:24

Svend Ferdinandsen

Re: Tilbage til start

Epicentret: Hmm...tja det kan man vel godt kalde det. Det er i hvert fald centret for affyringsområdet.

Jeg tænkte egentlig på at ved jordskælv kalder man punktet på jordoverfladen lodret over skælvet for epicenteret, så rakettens lodrette placering over jordens overflade kunne vel også kaldes dens epicenter.
Selvom raketten er (næsten) lodret kan den udmærket have en stor vandret hastighed.


04. feb 2012 kl 18:39

Peter J. Hansen

Jordens rotation

Hvordan regner i subj. ind?


04. feb 2012 kl 19:46

avatar

Peter Madsen

Djursings var / jordens rotation

Djrusing har fuldkommen forstået princippet. Vi har valgt at operere med en cirkulær sikkeredszone ved nogen opsendelser. Fordelen er at ved at forsøge at skyde eksakt lodret for vi den mindst mulige downrange - men faren for at ramme platformen selv er helt teoretisk. Efter burnout kan styre systemet ikke gøre mere, derfor vil afdrift i faldskærmen og alle mulige andre påvirkninger giver sørge for at vi ikke lander på Sputnik.

Raketten roterer med jorden ved liftoff - radius i cirkelen er aftanden til jordens rotations akse - på vore breddegrader må det være en 3 - 4000 km. Ved apogge er den afstad vokset med 12 km, så vores raket kommer altså lidt bagefter - denne effekt flytter nedslaget ved en 12 km tur med et par hundrede meter.

Peter Madsen


04. feb 2012 kl 19:58

avatar

Uffe R. B. Andersen

Styring efter udbrænding?

Motoren brænder kun de første 30 sekunder af turen, så vidt jeg husker, og derefter har kobberfinnerne vel ikke nogen effekt - hvad skal justere kursen på resten af turen?


04. feb 2012 kl 20:02

avatar

Thomas Pedersen

Re: Styring efter udbrænding?

Det korte svar er ingenting. Eller Newton om man vil. Når motoren er brændt ud er der kun vindmostand og tyngdekraft tilbage til at påvirke raketten. I samme splitsekund motoren slukker kan man altså beregne et forholdsvist præcist nedslagspunkt.


04. feb 2012 kl 20:25

Svend Ferdinandsen

Re: Styring efter udbrænding?

hvor det gælder om at sende en raket op i luften og få den til at ramme samme sted, som den startede.

Forudsætningerne er vigtige. Umiddelbart lyder det som om den aktivt skal ramme startpunktet med fuldt blus på motoren. Jeg forstår jo at meningen er, at den skal dale tilbage i faldskærm efter udbrænding, men sådan var det ikke lige beskrevet ved første læsning.

Er det sådan noget der går galt i de store IT-projekter?


04. feb 2012 kl 20:35

Peter J. Hansen

Re: Djursings var / jordens rotation


Raketten roterer med jorden ved liftoff - radius i cirkelen er aftanden til jordens rotations akse - på vore breddegrader må det være en 3 - 4000 km. Ved apogge er den afstad vokset med 12 km, så vores raket kommer altså lidt bagefter - denne effekt flytter nedslaget ved en 12 km tur med et par hundrede meter.

Tak, nu kan jeg se det.

Faktisk må det være lidt mindre, da i ikke skyder vinkelret på rotationsaksen, men i den størrelsesorden betyder det jo ikke så meget.


04. feb 2012 kl 21:19

Mogens Kjær

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?


04. feb 2012 kl 22:27

avatar

Peter Madsen

Infostået...

Så man kan læse teksten som om raketten skal skydes af - flyve op, vende om, men motoren på fuld hug - jagte affyringsplatformen...tja...

Det er svært - at undgå den slags misfortåelser.

Der ligger implicit den antagelse bag artiklen at alle da ved hvordan en V2 raket styrer - at alle da ved noget om regulerings teknik - og at alle da ved hvad Copenhagen Suborbitals arbejder med. Men det gør alle altså absolut ikke.

Det den fare der lurer når journalisten selv kommer til at vide for meget, kan man godt sige. Så stiller han for få dumme spørgsmål for forklarer for få indlysende ting.

V2 raketten - verdens første langtrækkende ballistiske missil styrede på samme måde og ramte rigeligt nøjagtigt efter vores formål. Dens nøjagtighed var ( relativt ) svarende til konventionelt arteilleri - selvom der ikke styredes efter burnout.

Vi skal bare højt op - og samtid holde os inden for et område på 35 x 50 km på vand.

Peter Madsen


04. feb 2012 kl 22:58

Lars Tørnes Hansen

Re: 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?

Adskillige 1000 km/t, er det langsomt? Du skal ikke mange grader forkert fra kursen før du kort tid senere er langt ved siden af.


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

Som ingeniør ud i embedded systems, så er det ret nemt at gætte hvad der sker.

Reguleringsprogrammet kører det der hedder en uendelig løkke, hvor den laver det samme i en uendelighed, så længe der er strøm på mikroprocessoren.

Det starter typisk sådan her:

[code]
void main (void)
{
funktion_der_gør_mikroprocessoren_klar_til_det_vi_skal_bruge_den_til(();
while(1) {
/* reguleringsprogrammet indsættes her */
}
}
[/code]

Det er så sådan at en et krystal bestemmer med hvilken frekvens at mikroprocessorens digitale kredsløb arbejder på.

En maskinkode-instruktion tager et vist antal kloksignaler at udføre og summen af kloksignaler der skal til at køre programmet igennem 1 gang tager så i gennemsnit 1/205 sekunder at udføre.

Derfra har du 205 gange per sekund.


05. feb 2012 kl 04:56

Mikkel Højbak

Re: Hvorfor 205 gange/sek

Det er oftest også lettere at køre på denne måde. I og med at udregningen sker stort set konstant behøver computeren ikke regne ud præcis i hvilken retning styrefinnen skal pege, men blot om den skal drejes til den ene eller den anden side. Eftersom udregningerne kører så hurtigt gør det ikke noget om finnen overskyder lidt - efter 5ms er den på vej den anden retning igen.


05. feb 2012 kl 11:38

Mogens Kjær

Re: Hvorfor 205 gange/sek

Arh. Servoer til modelfly der kan gennembryde lydmuren? Der har været vist en video hvor vi ser rorene blive testet. Og det fremgik også at de blev reguleret hurtigere end de egentlig kunne følge med til. Forstå mig ret. De så ret hurtige ud og blev reguleret helt ud til yderpunkterne, hvilket de forhåbentligt ikke kommer til under flyvning, for så ender det da nemt galt.

Men jeg er med på at de 205 /sek fremkommer ved bare at lade sekvensen drøne derudaf med fuld cpu-hastighed. Det giver fint mening, hvis sensorer og aktuatorer kan følge med til det.

Jeg er også med på at man kan bruge aktuatorernes sendrægtighed aktivt i sin reguleringsprocess.


05. feb 2012 kl 11:44

avatar

Flemming Nyboe

Re: Hvorfor 205 gange/sek

Goodag,

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?

Det sidste. Frekvensen skyldes at IMUen internt måler ca. 819 gange i sekundet, og er indrettet så det er fordelagtigt at udlæse dens data med en frekvens som er en potens af 2 gange lavere. Valget af 205 Hz stammer fra HEAT-1X's navigationssystem, og giver rigelig tid til at genberegne positionen for hver ny måling. Jeg tror der er tid nok til styringen også, og ellers går vi en faktor 2 ned.
Styresignalerne til servoerne opdateres kun 50 gange i sekundet så du har ret, det er ikke for deres skyld.

Vh Flemming


05. feb 2012 kl 11:46

Jørgen Henningsen

Re: Hvorfor 205 gange/sek

Det er oftest også lettere at køre på denne måde. I og med at udregningen sker stort set konstant behøver computeren ikke regne ud præcis i hvilken retning styrefinnen skal pege, men blot om den skal drejes til den ene eller den anden side.

Ja systemet er sikkert ganske kaotisk hvis man ser på sammenhængen mellem motorens resulterende kraft og rorets orientering. Det er sikkert ikke noget man kan regne særligt nøjagtigt på alligevel.
Såvidt jeg kan se er den algoritme, som der lægges ud med udelukkende proportional styring, som er kompenseret for ændringen i kammertryk og rakettens masse/tyngdepunkt. Den form for regulering vil ikke være speciel nøjagtig, men den vil være stabil og robust hvis man ikke presser forstærkning for langt op.
P.S. Jeg har lovet at hilse fra den software ansvarlige på Arianne 5 og sige at i skal passe på med register overflow ;-).


05. feb 2012 kl 13:49

Lars Tørnes Hansen

Re: Hvorfor 205 gange/sek

Jeg har lovet at hilse fra den software ansvarlige på Arianne 5 og sige at i skal passe på med register overflow ;-).

hehe :)

Ja det er ikke sådan når man smider smider et sysem ind i en større raket - uden at teste det til de nye forhold.

Fra

ARIANE 5, Flight 501 Failure, Report by the Inquiry Board
The Chairman of the Board : Prof. J. L. LIONS

som kan findes på http://www.di.unito.it/~damian...html har vi:


m) The inertial reference system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. This realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off.

n) During design of the software of the inertial reference system used for Ariane 4 and Ariane 5, a decision was taken that it was not necessary to protect the inertial system computer from being made inoperative by an excessive value of the variable related to the horizontal velocity, a protection which was provided for several other variables of the alignment software. When taking this design decision, it was not analysed or fully understood which values this particular variable might assume when the alignment software was allowed to operate after lift-off.

o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software.

p) Ariane 5 has a high initial acceleration and a trajectory which leads to a build-up of horizontal velocity which is five times more rapid than for Ariane 4. The higher horizontal velocity of Ariane 5 generated, within the 40-second timeframe, the excessive value which caused the inertial system computers to cease operation.

q) The purpose of the review process, which involves all major partners in the Ariane 5 programme, is to validate design decisions and to obtain flight qualification. In this process, the limitations of the alignment software were not fully analysed and the possible implications of allowing it to continue to function during flight were not realised.

r) The specification of the inertial reference system and the tests performed at equipment level did not specifically include the Ariane 5 trajectory data. Consequently the realignment function was not tested under simulated Ariane 5 flight conditions, and the design error was not discovered.

s) It would have been technically feasible to include almost the entire inertial reference system in the overall system simulations which were performed. For a number of reasons it was decided to use the simulated output of the inertial reference system, not the system itself or its detailed simulation. Had the system been included, the failure could have been detected.

t) Post-flight simulations have been carried out on a computer with software of the inertial reference system and with a simulated environment, including the actual trajectory data from the Ariane 501 flight. These simulations have faithfully reproduced the chain of events leading to the failure of the inertial reference systems.

Jeg synes i øvrigt også at Ada og Spark er spændende programmeringssprog, men som altid, hvis et system ikke testes kan systemet fungere aldeles fremragende - den gør bare ikke lige det man forventede.


05. feb 2012 kl 14:58

avatar

Thorleif Bundgård

Lær af andre

Det er et spændende projekt som jeg følger løbende i disse spalter.
Og software forklaringen ser enkel ud, men.. den rummer kun et korrigerende element, ingen forudsigelser.

Der er en grund til at man andre steder bruger PID i reguleringssløjfer.

Men - hvorfor lærer i ikke mere fra andre og fra historien.?

Der er garanteret ingeniører derude der 'ved' hvordan man programmerer optimale reguleringer - hvor ikke spørge dem.??

Ideen med at gøre alting selv ligner for meget den typisk danske tankegang fra andre store projekter, hvor man også selv ville genopfinde den 'bedste' løsning, og endte med et andenrangsprodukt på dobbelt tid, i stedet for at hente hvad andre har brugt år på.

Så mit råd er - spørg de professionelle IT ingeniører der er derude, og lad dem få lov til at fortælle hvordan de har gjort.

Andet spørgsmål.
Hvorfor studerer i ikke V2 raketten noget mere. Jo, jeg ved den brugte et andet brændstof, og den var ballistisk, men det lykkedes dem altså for mere end 60 år siden at holde balancen på en (forholdsvis) lille raket, og med meget simple kredsløb, at styre deres raket.

Vi skal huske at "hvis vi står på skuldrene af vore forfædre så når vi højere."


05. feb 2012 kl 15:40

Oluf Bagger

Re: Lær af andre



Så mit råd er - spørg de professionelle IT ingeniører der er derude, og lad dem få lov til at fortælle hvordan de har gjort.


Det er lidt urimeligt at sige at Flemming ikke er professionel. Reguleringsteknik er vel beskrevet i litteraturen og jeg er sikker paa Flemming har laest paa lektien.

I oevrigt er der ingen grund til at udvikle og finde den "optimale regulering". En tilstraekkelig regulering er jo netop tilstraekkelig.

Jeg tror artiklen kan vildlede lidt ved at kalde simularingsprogrammet for et computerspil. Det kan forlede laeseren til at tro der ikke er teoretisk fundering bag.



Andet spørgsmål.
Hvorfor studerer i ikke V2 raketten noget mere. Jo, jeg ved den brugte et andet brændstof, og den var ballistisk, men det lykkedes dem altså for mere end 60 år siden at holde balancen på en (forholdsvis) lille raket, og med meget simple kredsløb, at styre deres raket.

Vi skal huske at "hvis vi står på skuldrene af vore forfædre så når vi højere."

V2 er super spaendende, men den regnekraft Von Braun havde til raadighed for 70 aar siden gav ham helt andre randbetingelser end man har idag. V2's kredsloeb var nok simple men de er ikke noedvendigvis nemme, paalidelige eller billige at reproducere.


05. feb 2012 kl 16:18

Lars Tørnes Hansen

Re: Lær af andre

Det er et spændende projekt som jeg følger løbende i disse spalter.
Og software forklaringen ser enkel ud, men.. den rummer kun et korrigerende element, ingen forudsigelser.

Der er en grund til at man andre steder bruger PID i reguleringssløjfer.

Fra http://en.wikipedia.org/wiki/P...ller har vi:

In the absence of knowledge of the underlying process, a PID controller is the best controller.
...
Note that the use of the PID algorithm for control does not guarantee optimal control of the system or system stability.

Nu er det bare sådan at CS en rigtig god ide om hvordan raketmortoren opfører sig fra de mange raketmortor tests.
De kender også den fysiske form på det der flyver, så de kan regne på tyngdepunkt, massetab under drift med mere.


Men - hvorfor lærer i ikke mere fra andre og fra historien.?

Der er garanteret ingeniører derude der 'ved' hvordan man programmerer optimale reguleringer - hvor ikke spørge dem.??

Ideen med at gøre alting selv ligner for meget den typisk danske tankegang fra andre store projekter, hvor man også selv ville genopfinde den 'bedste' løsning, og endte med et andenrangsprodukt på dobbelt tid, i stedet for at hente hvad andre har brugt år på.

Så mit råd er - spørg de professionelle IT ingeniører der er derude, og lad dem få lov til at fortælle hvordan de har gjort.

Jeg synes du undervurderer Flemming her.

Jeg har mødt E-ingeniører der kun laver software nu. De kan deres kram - specielt hvad angår reguleringsteknik.

Måske kender de ikke til mere avancerede datalogi, som de ikke har på deres studie, men det lærer de som alle ingeniører ret hurtigt, hvis de har brug for den information.

Vi ved heller ikke om Flemming rådfører sig med dataloger eller IT ingeniører på sit arbejde, eller blandt tidligere kolleger.
Det er jeg sikker på han gør hvis han har brug for noget viden de har.


Andet spørgsmål.
Hvorfor studerer i ikke V2 raketten noget mere. Jo, jeg ved den brugte et andet brændstof, og den var ballistisk, men det lykkedes dem altså for mere end 60 år siden at holde balancen på en (forholdsvis) lille raket, og med meget simple kredsløb, at styre deres raket.

Vi skal huske at "hvis vi står på skuldrene af vore forfædre så når vi højere."

I dag er mekanik meget dyrt, og software er billigt.

Skal du lave noget om i software skal du bare indlæse den nye firmware, mens man med mekanik skal lave om på konstruktionen.

Derfor bruger man software, der modtager information om omverdenen fra sensorer og påvirker sine omgivelser med aktuatorer.


05. feb 2012 kl 17:43

avatar

Flemming Nyboe

Reguleringsteknik

Goddag,

Jeg kan ikke se at artiklen insinuerer at vi bruger proportionalregulatorer, det er i hvert fald ikke meningen. P.t. er det åbent, da reguleringssystemet ikke er færdigt, men skal optimeres ved hjælp af den bane model artiklen omtaler. To ting er dog givet:
1) Der er frit spil mht. loop filtre, og valget er hverken begrænset til P, PID eller noget andet.
2) Der bliver 2 sløjfer indeni hinanden:
a) En langsom yderst, som udfra positionsfejlen dikterer den ønskede kurs.
b) En hurtigere inderst, som udfra kurs-fejlen (og tilstandsestimaterne) dikterer ror udslaget.
Der findes forskellige teknokratiske designmetoder til reguleringssystemer, såsom LQR eller H-infinity metoden, og de er også blevet brugt på raketter [1]. Ulempen er at den intuitive fornemmelse af løsningen og dens afhængighed af systemet bliver dårligere. Jeg vil derfor hellere forsøge mig med en enklere og håndlavet regulering. Det bliver mindre optimalt, men mere gennemskueligt.

Venligst Flemming,
PS: Ikke et ondt ord om tyskerne, men V2 var nu ikke særligt fejlfri, og jeg kan ikke se det enkle i det her: http://www.v2rocket.com/start/....jpg

[1] http://rsta.royalsocietypublis....pdf


05. feb 2012 kl 18:50

Svend Ferdinandsen

Re: Reguleringsteknik

Selve rakettens bevægelse giver en god integration af rorudslagene, så at lægge en integration i reguleringen også kan give sjove resultater.


05. feb 2012 kl 20:08

avatar

Flemming Nyboe

Re: Reguleringsteknik

Godaften Svend,

Selve rakettens bevægelse giver en god integration af rorudslagene, så at lægge en integration i reguleringen også kan give sjove resultater.

Vinkelaccelerationen er proportional med styrekraften, så faktisk giver raketten ikke en, men to integrationer derfra til vinkel (kurs). Det er således proportionalleddet der kan give sjove resultater, og en ren P regulator i den inderste sløjfe vil altid være ustabil.
Rakettens mekaniske adfærd bliver taget i betragtning, og indgår i den bane model, der omtales som et computerspil.

Venligst Flemming


05. feb 2012 kl 22:43

Jørgen Henningsen

Re: Reguleringsteknik

Selve rakettens bevægelse giver en god integration af rorudslagene, så at lægge en integration i reguleringen også kan give sjove resultater.

Det er formodentligt heller ikke nødvendigt da der ikke er det store krav til præcision.
Det er således proportionalleddet der kan give sjove resultater, og en ren P regulator i den inderste sløjfe vil altid være ustabil.

Ja og dog. En ren P regulator vil som regel kunne gøres stabil. Men det kommer til at koste båndbredde og præcision. Derfor vil man som regel ikke kunne leve med resultatet. Så er det man griber til differential leddet for få tingene op i hastighed.


05. feb 2012 kl 23:21

avatar

Peter Madsen

Jeg studsede også over udtrykket-

"computerspil" men journalistens opgave er at gøre det Flemming vil kalde en banesimulater til noget almindelige mennesker kan forstå -og så kalder han det altså et computerspil. Det er for at være børnevenlig.

Om teori og CS vil jeg sige -

Nogen har kun styr på teorien og tegner ganske imponerende projekter op i 3D programmer.

Hvis man ikke kan udføre et projekt i praksis - så er det næstbedste vel at tegne det i 3D studie max og nyde synet.

Jeg kender f.eks. en australier der har tegnet en 100 tons undervandsbåd ned i sidste detalje. Den bliver sikkert aldrig bygget, for manden er ejendomsmægler, og kan ikke bruge en hammer - men kors hvor han tegner.

Al ære og respekt for den flotte 3D model.

Vi laver også - når det er nødvendingt, 3D modeller i CS. Vi regner os tit helt blå i hovedet - og til aften ligner mit skrivebord et patchwork af tegninger og beregninger på HEAT 2X.

Jeg er typen hvor en god lommerregner og masser af papir er metoden.

Men - vi bygger altså tingene i praksis ude i hangaren. Derfor bliver 3D modellerne lidt sekundære i vores bevidsthed - men det betyder ikke der ikke ret godt styr på teorien.

Hvis det ikke var det - og myterne om "snusfornuft" og øjemål passede - ville vi ganske enkelt ikke lykkes med det vi gør.

På motorsiden hvor jeg arbejder, forudsiger vi ofte motorernes performance inden for få procent. Jeg kan hilse at sige at hybrid forbrænding ikke er udpræget enkelt at modelere matematisk.

Regnedrengene i CS - som b.la. er Flemming Nyboe og Steen Andersen - beregnede HEATs bane ud fra IMU data inden for få procent fra hvad Weibels radarmålinger viste.

Tror, uden at spille alt for smart, at der er nogenlunde styr på det.

Peter Madsen


06. feb 2012 kl 15:33

Ole Dahl

SMS styring

og få donationer ind samtidigt.
:)


06. feb 2012 kl 20:47

Lars Tørnes Hansen

Re: SMS styring

og få donationer ind samtidigt.
:)

Det med SMS styring er vel en joke?

Ok, hvis det ikke var:

Mobiltelefon netværk ser således ud:
[img]
http://upload.wikimedia.org/wi....png
[/img]
Det du ser i midten af hver bi-kube er det der hedder en base station, og det er den din telefon snakker med. Du snakker ikke direkte med en anden mobiltelefon, som i en walkie-talkie, f.eks.

SMS styring er en dårlig ide, fordi:
1) Der er en meget stor tidsforsinkelse (fra sms sendes til den bliver modtaget - mobilselskaber sender den ikke straks ud, men når det passer ind i trafikken af signalering,tale, data, og andre folks sms'er).
2) En base station kan ikke række op til raketten.
3) Hvis signalet endeligt kan række op til raketten, vil der opstå interferens med andre base stationer, der sender på samme frekvens, når raketten kommer højt nok op. Interferens er at et sådan mobiltelefon modul ville kunne "høre" mange base stationer på samme frekvens.


10. feb 2012 kl 00:47

Alexander Eldh

V2 vs Armadillo Aerospace.

Inga kommentarer kring AA (Armadillo Aerospace) som håller på med samma saker som CS ungefär.
Dom har skickat upp sin Stig (jo, döpt efter Top Gears Stig) raket till 50 miles (82 kilometer) se http://www.space.com/14499-pri...html
dessutom har dom en avancerad fallskärmskonstruktion, som tyvärr inte fungerade.
Om pengar fanns så skulle jag föreslå att man köpte in deras styrprogram istället, visst är det bra att göra saker själv, men om det finns färdigt att köpa så är det bättre.
V2 var en chansning och den funkade ibland, det är inte speciellt bra om man vill skjuta upp människor i rymden...


09. mar 2012 kl 22:26

Niels Ole Pedersen

Live test

Regulator-loops kan være svære at dimensionere og simulere, hvilket også fremgår af de mange indlæg.
Har I overvet at lave en live test af styresystemet inden det går løs ved Nexø under offentlighedens bevågenhed ?
Det kan f.eks. gøres ved ophænge raketten lodret i en gimbal i jeres teststand og lave en affyring. Så vil det afsløres om styresystemet han holde raketten lodret. Også under kunstig påvirkning af raketten med ydre kræfter.

Niels Ole


Ny i debatten? Opret en brugerkonto

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

Nyhedsbrev

Tilmeld dig vores nyhedsbrev.