Trodde først det var spam: – Jeg har en satellitt. Vil du kjøre Doom på den?

Er du mer enn middels aktiv på Internett, er det gode muligheter for at du har snublet over Ólafur Waage tidligere. Han er islendingen som lager små snurrige videoklipp, ofte om livet i Norge og Norden.

Men nå har han kjørt Doom på en måte ingen har gjort før ham: På en satellitt.

Nærmere bestemt på ESAs OPS-SAT.

Doom i rommet

– Hvordan fikk du den idéen?

– Egentlig var det ikke min idé. Du kan si det hele begynte med Jason Turners Youtube-kanal C++ Weekly.

I en av hans lengre videoer forsøkte han å gjøre Doom-kildekoden om fra C til C++ i sanntid. Kildekoden er åpen, så folk er fri til å leke med den.

Men etter den 10-12 timer lange videoen, gjorde ikke Turner noe mer med prosjektet utover å legge det hele ut på sin Github.

Noen år senere bestemte Patricia Aas seg for å se mer på Turners prosjekt.

Det fanget Ólafurs oppmerksomhet. Den gang var han kollega med Aas.

Ikke ekte tilfeldighet

– Jeg er en ivrig gamer, så da jeg så at hun drev med Doom-greier, ble jeg nysgjerrig. Jeg ba henne vise meg hva hun hadde gjort, og hun kompilerte det. Det gikk fint, men hun hadde ikke faktisk spilt spillet.

Det insisterte Ólafur på at hun måtte gjøre, så de satte det opp og spilte det sammen. Men de fant en bug - noe som ikke hadde gått helt som det skulle. På den automatiske demoen i begynnelsen av spillet gikk ikke spillpersonen i korridorene som den skulle, men rett i veggen.

– Dette var interessant, fordi Doom er deterministisk. Demofilene inneholder kun en liste over «input», det vil si ting som «gå fremover så og så langt», «klikk musen på bilde nummer 640», og så videre.

Det er med andre ord ingen reell tilfeldighet og variasjon i demoen: Når «inputen» er den samme, vil også resultatet bli identisk for hver gang.

«Tilfeldigheten» i Doom består av en tabell med 256 tall som spillet henter verdier fra ved behov, ofte mange ganger i sekundet. Når hele tabellen er «brukt opp», begynner spillet på nytt i samme tabell.

– Så med mindre spilleren introduserer tilfeldighet i spillet - for eksempel ved små variasjoner i bevegelse eller museklikk - vil resultatet bli det samme, sier Waage.

– Med andre ord er det spilleren selv som er spillets generator av tilfeldighet.

Doom som feiltesting

Og nettopp dette utnyttes til å teste de ulike versjonene som lages av det eldgamle spillet. Kjører man demoen og det skjer noe som skiller seg fra normalen, vet man at det er noe galt i koden.

Man trenger ikke spille spillet selv heller - det tar for lang tid. Ved å slå av begrensningene som gjør spillet spillbart for mennesker, kunne Ólafur kjøre gjennom spillets demosekvens på brøkdelen av et sekund.

– Denne formen for bugtesting ga meg en idé for et foredrag for en konferanse, om å få datamaskiner til å spille spill for oss for å finne feil.

Ólafur publiserte prosjektet sitt på Github, samt en liten video på Instagram.

Trodde det var spam

Han tenkte ikke mer på det hele, før han fikk en henvendelse fra en vilt fremmed.

– Jeg har en satellitt. Vil du kjøre Doom på den?

Ólafur visste ikke helt hva han skulle tro.

– Jeg tenkte, hvem er dette? Hvilken spam er dette, ikke sant? Jeg sjekket kontoen hans, og den virket OK. Jeg googlet navnet hans og fant masse publikasjoner og foredrag. Så greit, fortell meg mer.

Henvendelsen kom fra Georges Labrèche hos ESA, og han hadde faktisk en satellitt. Nærmere bestemt OPS-SAT, en såkalt «cubesat» som ble skutt opp i 2019 og er ESAs første satellitt av nettopp denne typen.

Den er ikke store saken - vitale mål er 10 x 10 x 30 cm og omkring 7 kg - men den er utstyrt med to ARM-baserte SOCer («System on a Chip»). Det gjør at den har omtrent ti ganger så mye prosessorkraft som en vanlig ESA-satellitt.

«Has never flown, will never fly»

Hensikten med OPS-SAT er å eksperimentere med nye løsninger generelt, og dermed bidra til å få bukt med en holdning innen satellittkontroll som kalles «Has never flown, will never fly».

Kort oppsummert kan dette kalles romfartens egen versjon av Janteloven.

SOCene på OPS-SAT kjører en versjon av Ubuntu, og med visse begrensninger kan man laste opp og kjøre veldig mye rart, så lenge man holder seg til biblioteker og så videre som OPS-SAT allerede har.

– Labrèche har for eksempel gjort en del arbeid innen kunstig intelligens på OPS-SAT, og har en lang rekke av «førsteganger» på den.

Sensitivt nok?

– Men hvorfor kjøre et 30 år gammelt spill i rommet?

– Det vi ønsket å se på var om dette var en metode som var sensitiv nok til å fange opp feil, som for eksempel såkalte «bit flips» i satellittens systemer.

En «bit flip» er tilfeller der en partikkel treffer akkurat slik på en brikke, at en binær verdi endres. En 0 blir til 1, eller omvendt. Som oftest blir slikt fanget opp av feilrettingsrutiner i systemene, men i rommet er ting mye mer utsatt for stråling, og dermed er faren for slike feil tilsvarende høyere.

– Vi forsøkte mange forskjellige løsninger for å se om dette var en rutine som kunne brukes. Blant annet utvidet vi tabellen fra 256 «tilfeldige» verdier til 64.000 verdier - alle null. Dermed ville ingenting skje med mindre en feil endret en tabellverdi til noe annet enn null, noe vi da ville se i hvordan demoen kjørte.

Man kan selvsagt ikke spille et spill «live» på en satellitt, så derfor måtte man nøye seg med å gjennomkjøre demosekvensen og se på loggfilene etterpå, noe Ólafur forklarer i videoen sin.

Teknikken hadde imidlertid noen begrensninger. For eksempel kan man bare finne bugs som resulterer i forskjeller i den ferdige loggfilen etter at sekvensen har kjørt. Små forskjeller som ikke vises i loggen, vil ikke bli fanget opp.

– Konklusjonen ble dermed til slutt at dette ikke var en teknikk som var sensitiv nok, selv om det fungerte bedre enn standardoppsettet.

Bilde

En loggfil er ikke akkurat kult å se på. Skulle man fenge oppmerksomheten til folk, måtte man ha noe visuelt å vise fram.

Et skjermbilde fra spillet kunne funke, men hvordan ser man forskjell på et skjermbilde fra Doom på en satellitt, og et tilsvarende skjermbilde fra hvor som helst ellers?

– Idéen var at OPS-SAT har et kamera om bord, så hvorfor ikke ta et bilde av jordkloden og så sette det inn i stedet for himmelen i et skjermbilde fra spillet?

Det bød på sine egne problemer.

Man måtte benytte en programvarebasert rendrer og finne riktig øyeblikk til å ta et bilde, siden OPS-SATs kamera ikke alltid pekte mot bakken.

Deretter ble satellittens KI-løsning benyttet til å redusere fotoenes fargepalett til 256 farger. Disse fargene matchet imidlertid spillets palett heller dårlig, så ved hjelp av noen innovative teknikker fikk man justert palettene slik at begge deler så bra ut.

Dommedag

– For hver gang vi sikter kameraet mot bakken, mister OPS-SAT også litt høyde. Den har ikke mulighet til å justere sin bane heller, så for hver gang vi kjørte Doom, kom den et lite hakk nærmere sin egen dommedag.

ESA har forsøkt flere ulike metoder for å få OPS-SAT i en høyere bane, for eksempel gjennom å «surfe» seg oppover på den øvre atmosfæren ved hjelp av oscillerende bevegelser.

Men til ingen nytte. OPS-SAT vil før eller senere møte sin egen «doom».

Men før det skjer, vil ESA skyte opp nye satellitter med samme formål som OPS-SAT har hatt. Og kanskje kommer noen til å kjøre Doom på dem også.

Video

På denne videoen forteller Waage mer om OPS-SAT-prosjektet og hvordan de fikk Doom til å kjøre på den: