Simulera beteende av stridsflygplan med hjälp av AI : Simulating behavior of combat aircraft with AI

(1)

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2021 | LIU-IDA/LITH-EX-G--2021/022--SE

Simulera beteende av

stridsﬂyg-plan med hjälp av AI

Simulating behavior of combat aircraft with AI

Daniel Covarrubias Gillin

Gustav Arneving

Joel Alexandersson

Leon Li Persson

Lukas Olsson

Martin Banck

Max Björkander

Handledare : Benjamin Hansson Examinator : Kristian Sandahl

(2)

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten ﬁnns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

©

Daniel Covarrubias Gillin Gustav Arneving Joel Alexandersson Leon Li Persson Lukas Olsson Martin Banck Max Björkander

(3)

Sammanfattning

I denna rapport beskrivs ett kandidatarbete som utfördes på beställning av Saab. Det kunden var intresserad av var att simulera beteende av stridsflygplan med hjälp av AI-tekniker. Projektgruppen använde maskininlärningsalgoritmen Q-inlärning för att försöka uppnå detta. Utöver detta utvecklade gruppen en egen simulator som en miljö för kurvstri-der mellan simulerade stridsflygplan. Projektet utfördes av sju studenter på programmen civilingenjör inom datateknik och civilingenjör inom mjukvaruteknik vid Linköpings uni-versitet.

Resultatet av projektet blev att ett tillfredsställande beteende för det AI-styrda strids-flygplanet ej kunde uppnås, dock kunde ett förbättrat beteende observeras. Mer forskning på området behövs dock för att åstadkomma mer tillfredsställande resultat. Förstärknings-inlärning visar sig vara lovande som metod för att lösa problemet inför framtiden. Diskus-sioner och insikter om vad som kan göras för att vidareutveckla AI:n för en bättre presta-tion hos det simulerade planet dokumenterades.

I slutet av rapporten finns även individuella bidrag skrivna av var och en av medlem-marna i projektgruppen. De ämnena som valdes berörde projektet, antingen som en del av utvecklingsprocessen eller som en del av temat till projektet.

(4)

Projektgruppen tackar handledaren, Benjamin Hansson, för all hjälp under projektets gång och Saab för ett roligt projekt. Gruppen vill även tacka kursledningen i TDDD96 för att få möjligheten att samverka i ett lärorikt projekt.

(5)

Innehåll

Sammanfattning iii Författarens tack iv Innehåll v Figurer viii 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 1.5 Kontext . . . 2 2 Bakgrund 3 2.1 Kunden . . . 3

2.2 Gruppens tidigare erfarenheter . . . 3

3 Teori 5 3.1 Taktiskt beteende . . . 5

3.2 Förstärkningsinlärning . . . 5

3.3 Q-inlärning . . . 6

3.4 Git och GitLab . . . 7

3.5 Python . . . 8 3.6 Testning . . . 9 3.7 Scrum . . . 9 3.8 Parprogrammering . . . 9 4 Metod 10 4.1 Förarbete . . . 10 4.2 Utvecklingsmetod . . . 11

4.3 Metod för att fånga erfarenheter . . . 13

4.4 Process i fokus . . . 13 5 Resultat 15 5.1 Systembeskrivning . . . 15 5.2 Systemanatomi . . . 23 5.3 Process i fokus . . . 23 5.4 Gemensamma erfarenheter . . . 25

5.5 Översikt över individuella bidrag . . . 26

(6)

6.3 Diskussion om metoden . . . 30

6.4 Arbetet i ett vidare sammanhang . . . 31

7 Slutsatser 32 7.1 Slutsatser utifrån frågeställningarna . . . 32

7.2 Uppnåddes syftet? . . . 33

7.3 Viktigaste lärdomar . . . 33

A Effektiviteten av parprogrammering på distans - Daniel Covarrubias Gillin 34 A.1 Introduktion . . . 34 A.2 Bakgrund . . . 35 A.3 Teori . . . 35 A.4 Metod . . . 35 A.5 Resultat . . . 36 A.6 Diskussion . . . 38 A.7 Slutsats . . . 39

B Jämförelse av prestanda för lagring av Q-tabeller - Gustav Arneving 41 B.1 Introduktion . . . 41 B.2 Bakgrund . . . 41 B.3 Teori . . . 42 B.4 Metod . . . 43 B.5 Resultat . . . 45 B.6 Diskussion . . . 46 B.7 Slutsatser . . . 48

C Effektivt ledarskap och koordinering av team på distans - Joel Alexandersson 49 C.1 Introduktion . . . 49 C.2 Teori . . . 49 C.3 Metod . . . 50 C.4 Resultat . . . 50 C.5 Diskussion . . . 51 C.6 Slutsatser . . . 52

D Militär AI – vad kan gå fel? - Leon Li Persson 53 D.1 Introduktion . . . 53 D.2 Bakgrund . . . 53 D.3 Teori . . . 54 D.4 Metod . . . 55 D.5 Resultat . . . 55 D.6 Diskussion . . . 58 D.7 Slutsats . . . 59

E Etisk synvinkel på helt AI-styrda vapen - Lukas Olsson 60 E.1 Introduktion . . . 60 E.2 Teori . . . 60 E.3 Metod . . . 61 E.4 Resultat . . . 61 E.5 Diskussion . . . 65 E.6 Slutsatser . . . 66

(7)

F Adaptiv diskretisering av tillstånd i en Q-inlärningsagent - Martin Banck 68 F.1 Introduktion . . . 68 F.2 Bakgrund . . . 69 F.3 Teori . . . 69 F.4 Metod . . . 70 F.5 Resultat . . . 72 F.6 Diskussion . . . 74 F.7 Slutsatser . . . 76

G En jämförelse mellan Pythonbiblioteken OpenAI Gym och Scikitlearn -Max Björkander 77 G.1 Introduktion . . . 77 G.2 Bakgrund . . . 77 G.3 Teori . . . 78 G.4 Metod . . . 80 G.5 Resultat . . . 80 G.6 Diskussion . . . 83 G.7 Slutsatser . . . 83 Litteratur 84

(8)

3.1 Förstärkningsinlärning. . . 6

5.1 För- och nackdelar med olika simulatorer. . . 16

5.2 Bild på hur simulatorn ser ut. . . 17

5.3 Bild på grafen för beteendet som AI-modellen hade i början. . . 19

5.4 Bild på grafen för beteendet som AI-modellen hade efter de första justeringarna. . 19

5.5 Resultatet av fortsatt träning av den justerade AI-modellen. . . 20

5.6 Distribution av belöningsvärden per 2%-intervall av alla mätvärden (mörkare cir-kel är större andel, svart är 50%). . . 21

5.7 Bild över systemanatomin i början av projektet. . . 24

5.8 Mätvärden för antal commits av varje begäran av sammanslagning. . . 25

5.9 Mätvärden för storlek av varje begäran om sammanslagningar och den tid det tog att granska. . . 26

B.1 Storlekar på de Q-tabeller som används i testerna . . . 44

B.2 Medelvärde av sparningstid för samtliga Q-tabellstorlekar för samtliga prestan-datest . . . 45

B.3 Medelvärde av storlek på disk för samtliga Q-tabellstorlekar för samtliga prestan-datest . . . 45

B.4 Medelvärde av inladdningstid för samtliga Q-tabellstorlekar för samtliga prestan-datest . . . 46

E.1 Resultat från fråga 1: Hur ser du på att jobba inom försvarsindustrin? . . . 62

E.2 Resultat från fråga 2: Idag finns det ingen internationell lag som förbjuder användning av LAWS, Borde det göra det? . . . 62

E.3 Resultat från fråga 3: Om ingen lag emot LAWS kommer, hur lång tid tror du att det skulle ta innan de börjat användas? . . . 63

E.4 Resultat från fråga 4: Inom militären är det någon skillnad på en LAWS som tar ett liv jämfört med en människa? . . . 63

E.5 Resultat från fråga 6 . . . 64

E.6 Resultat från fråga 7 . . . 64

F.1 Utfallet för Q-inlärningsagenten med statisk diskretisering under 121 episoder, efter 3363 episoders träning. . . 73

F.2 Utfallet för Q-inlärningsagenten med adaptiv diskretisering under 121 episoder, efter 3363 episoders träning. . . 73

(9)

1 Introduktion

Det finns i dagsläget ett stort och växande intresse för artificiell intelligens och dess framtida potential att tillämpas inom samtliga sektorer i samhället. Artificiell intelligens, ofta förkor-tat som AI, syftar på intelligens som uppvisas av maskiner, med en bedömningsgrund för intelligens som ofta är baserad utifrån mänsklig intelligens. Inom det militära väsendet är ut-vecklingen av AI högst aktuell, då det är ett område som domineras alltmer av högteknologi. Något som på gott och ont är angeläget på globalt håll är en kapprustning mellan stater för att vara de första att bryta igenom med AI i ett militärt sammanhang.

På beställning av Saab har ett program för att simulera kurvstrider mellan stridsflygplan tagits fram. Med ett fokus på AI har en enklare simulator konstruerats och fungerat som ett koncepttest för att bedöma realiserbarheten i ett självstyrande stridsflygplan. Denna rapport detaljerar implementationen av denna produkt, d.v.s. programmet för simuleringen, samt projektets arbetsflöde och de resultat som har erhållits. Projektet har genomförts av sju stu-denter som läser till civilingenjör i datateknik och civilingenjör i mjukvaruteknik vid Linkö-pings universitet.

1.1 Motivering

Saab är ett företag som bl.a. tillverkar stridsflygplan, där användandet av flygsimulatorer är av relevans i framställningsprocessen av dessa. I nuvarande simulatorer styrs flygplanen i deras stridsscenarion av agenter som är implementerade med beteendeträd, vilket är en im-plementation som gör planens möjliga beteenden begränsade. Saab är därför intresserade av att undersöka om mer komplext beteende kan simuleras för flygplanen med hjälp av mo-derna AI-tekniker. Det som Saab är särskilt intresserade av är simulering av mer avancerat taktiskt beteende, snarare än till exempel mer avancerad teknisk manövrering. Om Saab an-ser att resultaten av detta arbete är intressanta och lovande kan detta arbete användas som grund för vidare arbeten på området.

1.2 Syfte

Syftet med denna rapport är att utforska hur agenter som är designade för att styra ett strids-flygplan i en simulator kan implementeras till att ha ett mer komplext beteende genom att

(10)

an-vända maskininlärningsalgoritmen Q-inlärning. Det har också under projektets gång genom-förts ett kandidatarbete inom programvaruutveckling. Detta har för projektgruppen bistått med att nå målet att samla erfarenheter av att arbeta mot en kund och utveckla kompetenser som är relevanta för en ingenjör.

1.3 Frågeställning

Nedanför presenteras frågeställningarna som besvaras i denna rapport:

1. Kan agenter med komplext, taktiskt beteende implementeras med Q-inlärning så att det skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från det här programvaruprojektet som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

4. Hur kan implementationen av simulatorn användas för att skapa värde för kunden?

1.4 Avgränsningar

För att kunna utforska olika komplexa beteenden av Q-inlärning i en flygsimulator behövde en enkel flygsimulator utvecklas för att kunna träna och utvärdera implementationen av al-goritmen. Det behövdes för att projektgruppen inte kunde använda Saabs egna simulator på grund av den rådande pandemin orsakad av COVID-19. En nackdel med detta är att utveck-landet av simulatorn har tagit tid som kunde ha använts till utforskning och implementation av AI-tekniker utöver Q-inlärning. En fördel är dock att det gav gruppen full kontroll att konfigurera, anpassa, och vidareutveckla AI-agentens simulatormiljö utifrån behov.

1.5 Kontext

Detta projekt har genomförts i kursen TDDD96, Kandidatprojekt i programvaruutveckling, vid Linköpings universitet. I kursen är det krav på att använda och skriva dokument vilket inklu-derar denna rapport, projektplan, systemanatomi, arkitekturdokument, kravspecifikation, kvalitetsplan, testplan, och testrapport. Projektgruppen bestod av sju studenter, tre från ci-vilingenjör inom datateknik och fyra från cici-vilingenjör inom mjukvaruteknik. Projektet har varit tidsbundet till 400 timmar per person, d.v.s. en total tid på 2800 timmar.

(11)

2 Bakgrund

2.1 Kunden

Saab är ett företag som utvecklar högteknologiska lösningar inom säkerhet för olika myndig-heter och länder runt om i världen. De har 17 000 medarbetare, varav 6 000 i Östergötland, och är den största privata arbetsgivaren i landskapet. En av deras produkter är stridsflygplan och de har tillverkat ca 5 000 flygplan sedan 1937. Andra produkter som de har är torpeder, missilsystem, avancerad flygplansstruktur, och helikopterunderhåll [1]. För att kunna förse ens kunder med stridsflygplan och en avancerad flygplansstruktur är det ytterst lämpligt att kunna utbilda nya stridspiloter. Ett sätt att träna piloter är med en flygsimulator. Motstån-daragenter i simulatorn är i nuläget utvecklade med beteendeträd, men Saab är intresserade av möjligheten att förbättra dessa med hjälp av moderna AI-tekniker. Särskilt intressant för kunden är om det är möjligt att åstadkomma mer avancerat taktiskt beteende hos dessa med hjälp av dessa tekniker.

2.2 Gruppens tidigare erfarenheter

I projektgruppen har alla erfarenheter av vissa teoretiska delar av programvaruutveckling såsom agil utveckling, användning av kravspecifikation och de roller som förekommer i pro-gramvaruutveckling samt rollernas ansvar, vilket är väsentligt i propro-gramvaruutvecklings- programvaruutvecklings-projekt som det programvaruutvecklings-projekt som denna rapport är baserad på. Utbildning för detta ges i kursen Programutvecklingsmetodik vid Linköpings universitet.

De som studerar civilingenjör i datateknik i projektgruppen har erfarenhet av större pro-jekt genom kursen Konstruktion med mikrodatorer. Där fick de använda sina teoretiska kun-skaper i ett praktiskt projekt och lära sig hantera dokument som projektplan och kravspeci-fikation, vilket var användbart i projektet. Studenterna i datateknik tar med sig förbättrings-punkten att det är viktigt att ha en bra kommunikation inom gruppen för att samarbetet ska vara effektivt och fungera bra.

De studenter som studerar civilingenjör i mjukvaruteknik har haft kursen Artificiell intel-ligens som ger en översiktlig introduktion till AI samt kursen Artificiell intelintel-ligens - projekt där de har gjort ett projekt med AI. AI är basen i detta kandidatprojekt och det är därmed väldigt praktiskt att kunna det sedan innan för att snabba upp och förbättra arbetet.

(12)

Leon Li Persson i kandidatprojektsgruppen har påbörjat sin mastersprofil inom AI och maskininlärning, vilket också är väldigt användbart och väsentligt i kandidatprojektet, då han kan agera lite som en specialist eftersom han har mest erfarenhet av AI och AI-relaterade områden.

(13)

3 Teori

I detta avsnitt beskrivs begrepp och annan information som behövs för att förstå rapporten.

3.1 Taktiskt beteende

Ett taktiskt beteende definieras här som ett gynnsamt beteende hos en agent som mer lång-siktigt blickar flera steg framåt, utifrån den information och träning som agenten har, med syftet att bättre uppfylla agentens mål jämfört med ett mer kortsiktigt beteende. I kontexten av detta projekt syftar detta på beteende som håller AI-agenten vid liv eller minimerar dess tagna skada och samtidigt leder till att motståndaragenten dör eller maximerar skada som ges på denna. Detta försöker uppnås i detta projekt med hjälp av maskininlärningsalgorit-men Q-inlärning, som leder till ett långsiktigt framblickande uppförande.

3.2 Förstärkningsinlärning

Förstärkningsinlärning är en typ av AI-teknik där en AI-agent lär sig att verka i en okänd mil-jö genom upprepad körning. Inlärningen – som illustreras i figur 3.1 – bygger på att agenten utför en av ett antal möjliga handlingar i ett givet tillstånd, där varje handling har en chans att resultera i ett nytt tillstånd. Därefter får agenten en värdering av det nya tillståndet jämfört med det gamla, och denna värdering används för att omprioritera den utförda handlingen då agenten befinner sig i samma tillstånd i framtiden. Därefter upprepas processen och efter ett antal körningar antas agenten utveckla ett önskat beteende för varje tänkbart tillstånd [2].

3.2.1 Policy

Inom förstärkningsinlärning finns det många algoritmer som alla kallas förstärkningsin-lärning. Två populära förstärkningsinlärningsalgoritmer är Q-inlärning och SARSA (Sta-te–action–reward–state–action), där skillnaden mellan dessa två är vilken policy de använder. Q-inlärning använder sig av en av-policy medan SARSA använder sig av en på-policy. Poli-cyn som en förstärkningsinlärning använder sig av är sättet som algoritmen väljer ut nästa handling. På-policy-algoritmer försöker återanvända sig av samma policy som den redan använder, medan av-policy-algoritmer försöker använda sig av den bästa policyn för det till-stånd den befinner sig i [3].

(14)

Figur 3.1: Förstärkningsinlärning. Hämtad från [4].

3.3 Q-inlärning

Q-inlärning är en förstärkningsinlärningsalgoritm som baseras på att alla tidigare utförda handlingar lagras tillsammans med det tillstånd agenten var i när de utfördes. Dessa tillstånd-handling-par lagras sedan i en så kallad Q-tabell, där de kopplas till ett så kallat Q-värde, vilket är en uppskattning av den förväntade belöningen för att utföra en given handling i ett givet tillstånd. Belöningen för en utförd handling i ett givet tillstånd bestäms av en problemspecifik belöningsfunktion Ra(st´1, st)som beräknar belöningen mellan tillstånd st´1och stför hand-ling a. När en handhand-ling har utförts uppdateras Q-värdet för det givna tillstånd-handhand-ling-paret enligt algoritm 1 [5].

När Q-inlärning implementeras för en miljö med kontinuerliga tillstånd, och agenten an-tas ha ett stokastiskt beteende, blir sannolikheten att agenten befinner sig i exakt samma tillstånd nära noll. Därför behöver tillstånden diskretiseras för att kunna koppla ett tillstånd-handling-par till ett Q-värde [5].

Q-inlärning är en algoritm som förbättrar sig efter varje körning då den utforskar tillstånd och utökar Q-tabellen. Matematiskt är algoritmen baserad på följande ekvation [5].

Låt Q(s0, a0) =0

Q(st, at) =Q(st´1, at´1) +α(Ra(st´1, st) +γmaxa(Q(st, a))´Q(st´1, at´1))

Pseudokoden till Q-inlärning går att se i Algoritm 1 och innehåller ett antal variabler. Indatan till Q-inlärningen kommer vara nuvarande tillstånd s1 _{och där r är belöningen.} Q-inlärningsalgoritmen kommer också använda sig av de beständiga variablerna s och a som är föregående tillstånd och handling och variabeln Q som är den indexerbara Q-tabellen. Pseudokoden innehåller också parametern α, som är inlärningshastigheten som minskar med tiden och leder till att inlärningen konvergerar mot ett beteende, och parametern γ, som är avdragsfaktorn, samt f som är funktionen som väljer vilken nästa handling är.

Pseudokoden för Q-inlärning kommer att fungera genom att först kontrollera att det inte är första körningen. Sedan räknas nästa Q-värde ut och sätts in i Q-tabellen. Efter det kommer det nuvarande tillståndet sättas till det förgående tillståndet och sedan kommer nästa

(15)

hand-3.4. Git och GitLab

ling tas ut. Till sist skickas handlingen tillbaka och agenten utför sedan handlingen ifråga [3].

Algorithm 1Pseudokod för Q-inlärning. Hämtad från [3] functionQ-LEARNING-AGENT (percept) returns an action input: from percept, s’ and r

persistent: Q, s, a 1: ifs is not null then

2: Q[s,a] ÐÝQ[s,a] + α(r + γ maxa1(Q[s’,a’]) - Q[s,a]) 3: end if

4: s, a ÐÝs’, argmax_a1f (Q[s’,a’]) 5: returna

3.3.1 Utforskning och utnyttjande

För att agenten ska kunna finna gynnsamma handlingar för varje tillstånd behöver agenten kunna utforska miljön. Utforskning kan modelleras på flera sätt, men ett vanligt förekom-mande är den så kallade e-giriga metoden, som utgår från att agenten väljer en slumpmässig handling med en given sannolikhet e. Detta innebär att agenten har sannolikhet 1 ´ e att välja den handling som för tillfället ger bäst väntad belöning i det givna tillståndet och på så vis utnyttja vad den vet om miljön till sin fördel [2].

3.3.2 Avdragsfaktor

Avdragsfaktorn (eng. discount factor) beskriver vikten som läggs på framtida belöningar i jäm-förelse med nuvarande belöningar. Ju högre avdragsfaktor desto mer långsiktigt prioriterar den belöningar, och ju lägre faktor desto mer kortsiktigt prioriterar den. En avdragsfaktor av 0 innebär att den endast fokuserar på den nuvarande belöningen och ignorerar framtida belöningar helt [2].

3.3.3 Lärningsgrad

Lärningsgraden (eng. learning rate) avgör procentuellt hur stor andel av ny information som skriver över den gamla informationen för ett Q-värde. En lärningsgrad av 0 gör att agenten ej lär sig något nytt utan håller sig till sitt gamla värde, medan en grad av 1 gör att den bara betraktar den nya informationen och helt ignorerar sitt gamla värde. Allt där emellan anger hur stor andel av det uppdaterade Q-värdet som fås ifrån ny information [6].

3.3.4 Eligibility traces

Det finns mer komplicerade versioner av förstärkninginlärningsalgoritmer som använder sig av så kallade eligibility traces för att lösa problemet med fördröjd belöning. Eligibility traces är ett verktyg för att dela ut temporär belöning. Detta innebär att det inte endast är det senaste tillstånd-handling-paret som uppdateras, utan även de par som utforskades inom kort tidi-gare. Verktyget kommer spara en spårparameter till nyligen besökta tillstånd-handling-par. Denna spårparameter minskar för varje iteration med sönderfallvariabeln λ och bestämmer mängden belöning som det tillstånd-handling-paret sedan erhåller. Detta görs för att försöka hitta mer långsiktiga taktiska beteenden då den belönar fler tillstånd än bara det senaste.

3.4 Git och GitLab

GitLab är ett verktyg som tillhandahåller en server för versionshanteringssystemet Git. Ett versionshanteringssystem är ett program som sparar tidigare versioner av data för framtida

(16)

referens. Git baseras på att utvecklare gör commits, alltså ögonblicksbilder av koden. I framti-den kan utvecklarna gå tillbaka till en given ögonblicksbild för att kunna se hur koframti-den såg ut. Ögonblicksbilder görs på en viss så kallad gren. Grenar är förgreningar av huvudkoden, eller av andra grenar. På dessa grenar kan varje utvecklare arbeta tills de känner sig klara med sina ändringar. När ändringarna är klara gör utvecklaren en integration med en annan gren för att föra in ändringarna där. Git är alltså ett sätt att parallellt kunna utveckla nya funktioner i ett projekt, samt att skapa återställningspunkter där koden är stabil för framtida referens.

Förutom en Git-server har GitLab funktionalitet för att göra arbetsflödet enklare för ut-vecklare. Ett exempel är ärenden (eng. issues), som är aktiviteter som ska göras. Ärenden kan tilldelas en eller flera utvecklare, och även kopplas till en specifik gren. När ändringar inte-greras med huvudkoden blir ett ärende löst. Ett annat exempel är stöd för pipelines, som är processer som körs för varje ögonbicksbild som laddas upp till servern. Dessa processer kan användas för att automatisera repetitiva uppgifter, som testning, formatering, och dokumen-tationsgenerering [7].

Vid användning av Git finns det möjlighet att ha en lokal och en avlägsen kopia av ett projekt. Detta gör att ändringar som görs lokalt kommer att stanna lokalt tills att användaren väljer att integrera in arbetet och uppdatera den avlägsna kopian. Efter det kan andra med-lemmar i Git-förvaret hämta ner ändringarna på sin lokala kopia. Det gör också att andra användare kan arbeta på andra delar av projektet utan att störa varandra och endast integre-ra in kod när den är redo, samt försätta på arbetet utan uppkoppling till internet [8].

3.5 Python

Python är ett programmeringsspråk som ursprungligen utformades som ett alternativ till C och skript i kommandoskal. Språket är även relativt koncist jämfört med lågnivå-språk som C++. Därför är det även ett språk som är bra för nybörjare, där de kan utveckla program relativt enkelt fastän de inte har så mycket erfarenhet. Det stödjer även flera olika program-meringsparadigm, alltså olika sätt att utveckla mjukvara, som till exempel objekt-orientering [9, 10, 11].

3.5.1 Bibliotek

Utöver standardbiblioteket har Python stöd för användning av externa bibliotek för att un-derlätta delning av kod.

Pygame

Pygame är en Python-koppling till C-biblioteket Simple DirectMedia Layer (SDL), som tillhan-dahåller ett gränssnitt mot operativsystemet för grafik- och ljudhantering. Pygame innehåller bland annat funktioner för att skapa och rita ut grafik i fönster, vektormatematik, tidtagning, och hantering av indata från användaren [12, 13].

Pytest och Pytest-Cov

Att testa kod är väsentligt för att veta om koden fungerar som det är tänkt att den ska göra. Pytest är ett sätt att testa kod i Python. Det görs genom att i en funktion skriva programsatsen assert följt av ett villkor som ska bli sant för att testet ska gå igenom, som t.ex. assert road.width > 1. Detta skrivs i vanliga Python-filer med villkoret att filen kallas test i början av filnamnet för att funktionerna däri ska undersökas av Pytest. För att köra testerna kör man relevant Pytest-kommando i kompilatorn, där det även går att skicka med olika parametrar såsom destinationen av filer som den ska testa [14].

Det finns ett plugin till Pytest som användes i detta projekt, kallat Pytest-Cov. Det gör så att det går att se exakt hur mycket som har testats och exakt vilka rader som inte är testade.

(17)

3.6. Testning

På så sätt är det ett användbart verktyg om man har ett krav på hur mycket som ska vara testat, procentuellt eller kvantitativt [15].

3.6 Testning

Testning är ett sätt att verifiera att koden som har skrivits fungerar korrekt. Det finns många sätt att testa mjukvara; ett sätt är uppdelningen av enhetstester, integrationstester, och systemtester [16].

3.6.1 Enhetstester

Enhetstester är till för att kontrollera att de minsta komponenterna i mjukvaran fungerar. Detta brukar vara att funktioner ger rätt värden eller att if-satser ger rätt ut-värde vid indata. För att vara säker på att mjukvaran fungerar som den ska måste då de minsta komponenterna fungera [16].

3.6.2 Integrationstester

Integrationstester är till för att testa större komponenter i ett system. Det finns olika metoder för integrationstestning men detta projekt kommer använda sig av bottom-up-testning. Detta betyder att lågnivå-komponenter testas först och sedan successivt större komponenter [16].

3.6.3 Systemtester

Systemtester är till för att testa systemet i sin helhet och kommer efter integrationstesterna. Här kommer testerna göras som black box testing, vilket betyder att det enda intressanta för testaren är att systemet ger rätt utdata från given indata, oberoende av vad som händer där-emellan [16].

3.7 Scrum

Scrum är en produktutvecklingsmetod vars syfte är att underlätta utvecklingen av stora pro-jekt. Metoden bygger på att ett utvecklingsteam bestående av tre till nio personer utvecklar delar av produkten under bestämda tidsperioder på en till fyra veckor kallade sprints. Vilka delar som ska utvecklas bestäms av den så kallade produktägaren som har ansvar för product backlog, en prioriterad lista av all potentiell funktionalitet produkten kan tänkas innehålla. Vid början av en sprint väljer produktägaren tillsammans med teamet ut vilken funktionali-tet från product backlog som ska utvecklas och skapar en sprint backlog. Denna sprint backlog arbetas sedan successivt igenom till dess att tiden för en viss sprint är slut. När tiden är slut har teamet och produktägaren en sprint demo (eller sprint review) där den funktionalitet som utvecklades gås igenom för att ta emot feedback. Sedan har teamet en sprint retrospective, ett möte där erfarenheter fångas upp för att möjliggöra processförbättringar [17].

3.8 Parprogrammering

Parprogrammering används som en främst agil arbetsmetod där två utvecklare delar arbets-station. Detta gör att bara en av utvecklarna kan skriva kod och den andra ger återkoppling på det som görs. Tanken är att utvecklarna byter plats med varandra så att båda får skriva och ge återkoppling. Nyttan med parprogrammering är att koden kan få en högre kvallitet då den är skriven av två utvecklare; detta då all kod som skrivs granskas i realtid och kan få återkoppling direkt. Parprogrammering har endast nytta om båda utvecklarna är delaktiga, så om en av de som fokuserar på uppgiften ej är närvarande försvinner all nytta [18].

(18)

Projektet utfördes genom att först göra ett förarbete för att ta beslut om relevanta punkter innan utvecklingen av projektet kunde påbörja. Efter det behövde beslut även tas över hur tillvägagångssättet för arbetet skulle se ut, såsom upplägget av utvecklingsprocessen och vil-ka standarder som skulle användas.

4.1 Förarbete

Förarbetet för detta projekt innefattar vilken simulator, programmeringsspråk, och AI-teknik som skulle användas. Alltså fanns det frågor som behövde svaras på innan arbetet kunde börja vilka var:

• Vilken dimension ska simulatorn vara i, 2D eller 3D? Ska en egen simulator utvecklas eller ska en redan existerande användas?

• Vilket programmeringsspråk ska användas? • Vilka AI-tekniker ska användas?

4.1.1 Vilken dimension ska simulatorn vara i, 2D eller 3D? Ska en egen

simulator utvecklas eller ska en redan existerande användas?

Innan en simulator valdes så bestämdes först vilken typ av simulator som skulle användas. Kunden föreslog därför preliminärt 3D-simulatorn DCS World [19], en 3D-simulator där an-vändare kan ställa upp egna scenarion. För att kunna välja simulator gjorde gruppen en över-siktlig sökning av lämpliga alternativ genom att gruppen delade upp sig och utgick ifrån problembeskrivningen nedan:

• Problem: Få en simulator att simulera 2 stridsflygplan som strider mot varandra genom att använda handlingar som “flyg mot fienden”, “flyg från fienden”, “attackera”, “flyg 90 grader mot fienden”, etc., integrerat med förstärkningsinlärning och/eller genetiska algoritmer.

(19)

4.2. Utvecklingsmetod

– Hur väl verkar det gå att förstå den tänkta simulatorn? – Hur väl verkar simulatorn lösa problemen?

– Vilka risker finns vid val av denna simulator? Hur “säkert” är det att välja denna simulator?

• Tänkta simulatorer att utvärdera: – Egen 2D-simulator

– Egen 3D-simulator – DCS World

– Andra färdiga simulatorer

Resultatet av undersökningen blev att det bästa var att använda en 2D-simulator och finns beskriven i detalj under 5.1.2.

4.1.2 Vilket programmeringsspråk ska användas?

Vid valet av programmeringsspråk var det viktigt att det fanns bra möjligheter att integrera AI-teknik i koden. Möjligheter till grafik var även ett krav. Därefter prioriterades språk som var bekanta sedan tidigare. Baserat på dessa punkter valdes Python som programmerings-språk. Det fanns maskininlärningsbibliotek till Python som skulle underlätta implemente-ringen av AI såsom TensorFlow [20] och PyTorch [21]. Det fanns även beprövade grafikbibli-otek såsom Pygame [12]. I slutändan användes dock inget maskininlärningsbibligrafikbibli-otek då det inte ansågs nödvändigt till Q-inlärningen, som istället skrevs för hand från grunden.

4.1.3 Vilka AI-tekniker användes?

Den AI-teknik som användes i projektet var Q-inlärning, vilket var för att Q-inlärning redan användes med viss framgång i tidigare arbete på detta område [22, 23, 24]. Förutom att tekni-ken redan beprövats på området gav det även möjligheten att dra lärdomar från de tidigare arbetena och fortsätta där dessa arbeten slutade. En till anledning till att Q-inlärning använ-des i projektet var att det fanns tidigare erfarenhet av Q-inlärning i projektgruppen, vilket gjorde det lättare att implementera.

4.2 Utvecklingsmetod

För att i projektet veta hur upplägget på arbetsprocessen skulle se ut behövde verktyg och standarder klargöras. Dessa användes sedan genomgående under hela projektets gång.

4.2.1 Arbetsmetod

Arbetsmetoden som användes under utvecklingen av produkten har varit en variant av Sc-rum [17]. Dagliga scSc-rummöten (eng. daily scSc-rums) har hållits vid första mötet varje dag då det funnits ett schemalagt pass där varje medlem gått igenom vad de har gjort, om något pro-blem har uppstått, och vad som ska göras härnäst [25]. Projektgruppen använde scrumsprin-tar (eng. scrum sprints), där varje sprint pågick i en vecka, från fredag till fredag. Därefter hölls en sprintåterblick (eng. scrum retrospective) vid slutet av varje sprint varvid följande frågor gemensamt besvarades [26].

• Vad har fungerat bra? • Vilka lärdomar kan dras? • Vad kan förbättras?

(20)

• Vad ska göras annorlunda nästa sprint?

Till skillnad från konventionell Scrum har ingen produktägare eller scrummästare explicit valts ut, utan alla har agerat som utvecklare.

Projektgruppen hade även handledarmöten varje fredag under projektet, där varje med-lem beskrev vad de hade gjort för handledaren och fått eventuell feedback. Allmänna punkter som gruppen eller handledaren ansåg vara relevanta för framåtskridandet av projektet togs även upp.

Arbetstiderna som gruppen arbetade på är främst från de tillgängliga tider som specifice-rats av kursschemat. Projektgruppen består av studenter från både programmen civilingenjör inom datateknik och civilingenjör inom mjukvaruteknik, så att följa detta kursschema under-lättade processen att hitta arbetstider som passade samtliga gruppmedlemmar. När det var nödvändigt bokades även tider in utöver kursschemat, vilket diskuterades och accepterades på förhand, och har bestått av både hela gruppen men även enstaka medlemmar av gruppen allteftersom projektet har blivit mer uppdelat.

4.2.2 Kodgranskning och kodstandard

När gruppen vill integrera kod från en specifik gren till basgrenen görs en begäran om sam-manslagning. En begäran om sammanslagning (eng. merge request) är att göra en förfrågan att integrera (eng. merge) filer med en annan gren. Innan det görs för en gren (eng. branch) görs en integrering av basgrenen (eng. master) in i grenen där alla sammanslagningskonflik-ter löses. En begäran om sammanslagning ska godkännas av minst två gruppmedlemmar innan det görs en integrering till basgrenen. För att en begäran om sammanslagning ska god-kännas finns några kriterier. Dessa är:

• Det finns docstrings för varje ny klass, metod, och funktion. • Alla tester har gått igenom.

• Testerna har över 70% kodtäckning.

• Koden i grenen ska uppfylla allt som stod i ärenden (eng. issue). • Koden ska vara i standard med stilguiden PEP 8 [27].

Om alla dessa kriterier är uppfyllda kan granskarna godkänna begäran om sammanslag-ning och man uppdaterar därefter basgrenen med den nya koden. Efter det går man vidare till nästa aktivitet och kodgranskningen fortskrider på samma vis.

4.2.3 Miljöer och verktyg

För versionshantering av koden användes GitLab [7]. GitLab Issues användes som en aktivi-tetshanterare för att göra distributionen av programmeringsarbetet mer smidig och effektiv. Gruppmedlemmar kunde då skapa nya aktiviteter, tilldela en aktivitet till sig själv eller nå-gon annan, och markera statusen på aktiviteten (t.ex. som to-do, in-progress eller closed). På så sätt så fås en scrumtavla (eng. scrum board) som arbetas från [28].

För kommunikation inom gruppen användes främst Discord, en plattform för direktmed-delanden i form av text, ljudsamtal, och videosamtal [29]. På grund av pandemin orsakad av COVID-19 inträffade majoriteten av alla möten i form av videosamtal på Discord. Textkanaler på Discord användes även för allmän kommunikation utanför mötestimmarna.

Microsoft Teams användes för att lagra dokument och agerade även som en gemensam re-digeringsplats för dessa, då programmet har stöd för att flera redigerar samma dokument samtidigt [30]. Undantag för detta har varit kandidatrapporten, som har sparats på den

(21)

4.3. Metod för att fånga erfarenheter

molnbaserade LaTeX-editorn Overleaf, och UML-diagram, som har sparats på whiteboard-plattformen Miro [31, 32]. Microsoft Teams användes även för de veckovisa handledarmötena via videosamtal med samtliga i gruppen.

Videochattplattformen Zoom användes för föreläsningar och seminarier som ägde rum under kursens gång tillsammans med andra projektgrupper [33]. Kommunikation med kun-den, Saab, skedde via Zoom och e-mail.

4.2.4 Dokumentation

Dokument som skrivits under projektet är systemanatomi, arkitekturdokument, kravspecifi-kation, kvalitetsplan, projektplan, testplan, och testrapport. Dessa dokument uppdaterades under projektets gång så att de alltid var aktuella. Systemanatomin i figur 5.7 visade hur systemet var uppdelat och vad som ingick i de olika delarna. Arkitekturdokumentet beskrev projektets designbeslut; när det uppstod problem med initiala designbeslut skrevs dokumen-tet om med ett nytt designbeslut för att lösa problemet och ändringen motiverades. Kravspe-cifikationen beskrev alla krav som fanns på systemet. Kvalitetsplanen beskrev projektets kva-litetsmål och vilka processer som användes för att säkerställa att dessa uppfylldes. Projekt-planen beskrev Projekt-planen för projektets genomförande. TestProjekt-planen och testrapporten beskrev vad som skulle testas och hur det skulle testas, samt rapporterade hur väl testplanen efter-följdes under projektet. Tidsrapportering gjordes som en obligatorisk del av kursen där varje gruppmedlem i ett gemensamt dokument skrev ned vad de gjorde under vilka tidsintervall.

4.3 Metod för att fånga erfarenheter

De tillvägagångssätt som användes för att fånga erfarenheter har främst varit sprintåterblic-kar som hållits vid slutet av varje sprint, där det reflekterades kring arbetet under veckans gång, och utifrån det formulerades idéer om vad som kan och ska göras bättre och annorlun-da nästa sprint. På så sätt kunde gruppen ta med sig det som gjordes bra och det som behöv-de förbättras till nästa sprint. Något mer som fångabehöv-de erfarenhet var seminarier där gruppen gjorde presentationer om erfarenheter i projektet. Det gjorde att gruppen blev tvungna att reflektera över projektet och fånga erfarenheter även här.

4.4 Process i fokus

Under projektets arbete så har en viss process av projektet lagt i fokus. En process i fokus är en process i ett projekt som granskas under projektets gång för att kunna förbättra den (t.ex. att göra processen snabbare eller minska fel i processen). Granskningen av processen utförs genom att ta mätvärden av processen varje gång den utförs, sedan analyserar man mätvärdena för att se vad som kan förbättras i processen. Ett annan sätt att granska processen på är att fråga personer som utför liknande arbete om deras åsikter kring hur processen kan förbättras.

4.4.1 Processbeskrivning

Den process i fokus som var vald för detta projekt var granskning av begäran om samman-slagningar. Det bestämdes att det skulle göras en ny gren varje gång ett nytt ärende im-plementeras. När dessa nya grenar sedan sammanslogs med huvudkoden så behövde två gruppmedlemmar granska koden enligt kriterierna beskrivna i 4.2.2 om Kodgranskning och kodstandard.

(22)

4.4.2 Mätvärden

För att förbättra denna process så fanns det sex mätvärden som visade hur processen, begäran om sammanslagning, hade förbättrats under projektets gång. Dessa mätvärden var:

• Tiden det tog från att en begäran om sammanslagning görs tills dess att två medlemmar i gruppen har granskat den. De medlemmar som fick granska begäran om samman-slagning var de medlemmar som inte hade arbetat på den koden. Tiden för granskning gällde bara mellan 8:00 till 17:00 på vardagar (t.ex. om en begäran om sammanslagning laddades upp den 15 april 13:00 och den godkändes av två medlemmar den 16 april 09:00 så tog det 5 timmar att granska den).

• Arbetstiden det tog tills två i gruppen hade granskat dividerat med antal ändrade rader kod i grenen. Syftet med detta mätvärde var att sätta väntetiden för en begäran om sammanslagning i relation till dess storlek.

• Antal begäran om sammanslagningar som blev godkända.

• Antal begäran om sammanslagningar som fick avslag från en gruppmedlem men också ett godkännande från en annan gruppmedlem.

• Antal commits som laddades upp medan begäran om sammanslagningen var aktiv. • Vad medlemmarna i gruppen hade för tankar eller åsikter om hur processen kunde

förbättras eller vad som inte funkade så bra.

Mätvärdena hade samlats till varje sprintåterblick av kvalitetssamordnaren. Informationen som behövdes loggades automatisk i GitLab. Åsikter och tankar om hur processen kunde förbättras samlades in under sprintåterblickarna. Kvalitetssamordnaren ställde de inledande frågorna så att det bildades en diskussion vilket ledde till att gruppen kunde komma fram med förbättringar.

(23)

5 Resultat

5.1 Systembeskrivning

Systemet i projektet som denna rapport beskriver är uppdelad i två moduler. Den första mo-dulen är den egenutvecklade stridsflygplanssimulatorn. Den andra momo-dulen är AI-modellen som kan skapa instanser av AI-agenter. Simulatorn tillhandahåller en miljö för AI-agenten att exekveras, tränas, och utvärderas i, utifrån olika stridsscenarion. Systemet beskrivs i detalj i systemanatomin i figur 5.7. Figuren beskriver projektets initiala systemanatomi, hur syste-met är uppdelat, och vad som ingår i de olika delarna. De två modulerna har utvecklats med objektorienterad programmering som programmeringsparadigm.

5.1.1 Resultat av undersökning av simulatorer

Undersökningen från 4.1.1 resulterade i två alternativa simulatorer: Linux Air Combat [34] – en annan 3D-simulator med öppen källkod – och början på en egen 3D-simulator utvecklad i 3D-motorn Unity [35]. Vidare diskuterades efter undersökningen att utveckla en egen 2D-simulator. Därefter ställdes för- och nackdelar upp med samtliga alternativ, som kan ses i figur 5.1.

I detta projekt användes en 2D-simulator fastän kunden utnyttjade en 3D-simulator, som de i slutändan kunde tänka sig utveckla nya agenter för och använda denna rapport som bas. Kunden ansåg att det var viktigare att agenten kunde lära sig att verka i en given miljö, än att agenten förstod alla moment som ingick i att styra själva flygplanen. Därför ansågs en 2D-simulator mer lämpad som miljö gentemot en 3D-2D-simulator, eftersom en 2D-miljö är lättare att implementera.

De huvudsakliga kraven som simulatorn behövde uppfylla var att den skulle fungera bra i arbetet, t.ex. att simulatorn skulle kunna simulera tid som går snabbare än realtid för att kunna träna AI-agenten på kortare tid. Då utredningen av olika simulatorer inte fann någon simulator som uppfyllde dessa krav var det bästa alternativet att utveckla en egen simulator som uppfyllde kraven. Detta gav stor kontroll över hur den skulle fungera men tog en del tid som istället hade kunnat spenderats på själva AI-utvecklingen.

(24)

Figur 5.1: För- och nackdelar med olika simulatorer.

5.1.2 Flygplanssimulator

Simulatordelen av systemet simulerar i en 2D-miljö en uppsättning stridsflygplan, se figur 5.2, där två stridsflygplan och en missil kan observeras. Stridsflygplanen har en uppsättning egenskaper som koordinater, vinkel, fart, storlek, hälsa, och antal missiler. Flygplanen kan interagera med simulatormiljön och objekt i den genom att accelerera, svänga, och avfyra missiler. Flygplanen har försökts implementeras med ett realistisk fysikaliskt beteende, men en del förenklingar har gjorts. Några exempel på realistiskt fysikaliskt beteende är att max-imalt antal g-krafter begränsas till vad en stridspilot kan tänkas klaras av, det vill säga 5-9g beroende på under hur lång tid piloten utsätts, och att realistiska värden har satts på para-metrar som maximal acceleration och hastighet [36].

Ett flygplan tar skada och förlorar hälsa när det kolliderar med en missil eller ett annat flygplan och om den sammanlagda skadan blir för stor kraschar flygplanet. Simulatorn ska-par en instans av en miljö och i denna skapas dessa flygplan. Parametrarna som definierar en miljö eller ett flygplan kan sättas manuellt eller till att variera slumpmässigt beroende på önskemål. En instans av ett flygplan kan väljas att antingen skapas med manuell styrning, flygplanets handlingar styrs då med tangentbordet, eller med ett deterministiskt beteende som är programmerat att ha målsättning att skjuta ned ett annat flygplan som specificerats som en motståndare. En episod av simulationen avslutas när ett av flygplanen besegrat sin motståndare eller den fördefinierade tidsgränsen för en episod uppnåtts. När en episod av-slutas startas automatiskt en ny episod. Anledningen till detta är att syftet med simulatorn

(25)

5.1. Systembeskrivning

Figur 5.2: Bild på hur simulatorn ser ut.

var att en AI-agent, som är i kontroll av ett flygplan, över många episoder ska kunna lära sig ett beteende som syftar till att besegra fientliga flygplan i simulatormiljön. Systemet kommer alltså fortsätta att skapa nya episoder tills dess att dess exekvering termineras.

Ett grafiskt gränssnitt för simulatorn finns också, implementerat med Pygame, som visu-aliserar flygplanens tillstånd och rörelse och eventuella missiler som har avfyrats från flyg-planen. Grafiken har implementerats utan sprites eller andra element som enbart syftar till att förbättra den visuella upplevelsen. Detta motiveras av att det är AI-modellen som är den intressanta slutprodukten för kunden. Därför är även uppsnabbning av tiden och körning utan grafik implementerade så att det går snabbare att träna AI-modellen än vad det hade gjort annars då fler episoder hinner köras. Simulatorn är i sig bara ett verktyg för att träna de AI-agenter som AI-modellen skapar instanser av och det grafiska gränssnittet är framförallt tänkt att användas för debugging och för att förstå vad som händer i simulatorn, under ut-vecklingsarbetets gång.

Motståndaragenten

Motståndaragenten som implementerades är den agent som styr motståndarplanet som en instans av AI-modellen spelar mot. Denna agent gjordes genom att ha fem olika fall som agenten kan befinna sig i, vilka är:

1. Det finns ingen annan agent eller så är det obestämt vad som ska göras. 2. Motståndaragenten tittar på AI-agenten och AI-agenten tittar åt ett annat håll. 3. Agenterna tittar inte på varandra.

(26)

5. Motståndaragenten tittar mot AI-agenten och håller på att krocka.

I det första fallet svänger agenten runt i cirklar i det hållet som den svängde i senast. Då fall två inträffar accelererar motståndaragenten och avfyrar en missil. I fall tre svänger motståndaragenten mot AI-agenten. När det fjärde fallet inträffar svänger agenten i motsatt riktning till den närmaste vinkeln till AI-agenten. I det femte fallet svänger den också i agen-tens motsatta riktning till närmaste vinkeln till det andra flygplanet. Fallen medför alltså att motståndaragenten alltid gör något när det är viktigt och är aggressiv i sitt beteende då den nästan alltid flyger mot AI-agenten och försöker skjuta ned den.

5.1.3 AI-modell

Systemets andra modul är en AI-modell baserad på Q-inlärning. Från AI-modellen kan en instans av en AI-agent skapas som från många episoder i simulatorn försöker lära sig ett beteende som är fördelaktigt för att besegra fiendeflygplan i simulatormiljön. Eftersom en Q-inlärningsagents Q-tabell är kärnan i agenten och det som definierar dess policy efter träning har kod skrivits som gör det möjligt att spara och ladda agentens Q-tabell till och från en fil. Även den totala belöning en agent får under en episod, definierat av agentens belöningsfunk-tion, sparas så att det är möjligt att se hur belöningen förändras under träningens gång och under ett stort antal episoder. För att göra denna data mer överblickbar och lättare att tolka har även ett program skrivits som visualiserar den totala belöningen för varje episod under en exekvering av programmet.

Beteende

Den första implementationen av Q-inlärningalgoritmen resulterade i övervägande negativ belöning enligt figur 5.3, där belöningen per iteration är utritad på en graf så att det lätt går att se hur det har gått för algoritmen.

Belöningen är definierad som skillnad i skada given och skada tagen för AI-agenten. Vid negativ belöning tog AI-agenten emot mer skada av motståndaragenten än vad den själv tillfogade till motståndaren, och vice versa för positiv belöning. Skalan på y-axeln går från -10 till 10 då en agents hälsa sattes någorlunda godtyckligt till 10; så AI-agenten kan i värsta fall bli beskjuten 10 gånger utan att själv få in en enda träff på motståndaren, och i bästa fall skjuta motståndaren 10 gånger utan att själv ta någon skada.

Det bör noteras att eventuella episoder när -10 ficks som belöning istället skrevs ut som -9 i figur 5.3, då en ny episod påbörjades innan denna belönings hann sparas. Detta uppmärk-sammades och åtgärdes dock för körningar som utfördes därefter.

Projektgruppen spekulerade kring olika orsaker till vad som kunde vara problemet med algoritmen och hur den skulle kunna göras bättre, vilka var:

• Justera belöningsfunktionen för att undvika att planen krockar.

• Förenkla scenariot där flygplanen återupplivas så att AI-modellen får övertaget, alltså att flygplanet som modellen kör mot återupplivas framför AI-modellen.

• Justera längden på iterationer så att de är inte så långa i början men blir sedan längre. • Justera hur ofta AI-modellen ska ta slumpmässiga beslut så att det är fler slumpmässiga

beslut i början som sedan avtar det så att det till slut blir beslut som mestadels följer Q-tabellens policy.

Efter att dessa idéer hade implementerats såg AI-modellens beteende ut som i figur 5.4, vilket såg betydligt bättre ut. Efter att ha tränat ca 200 000 episoder uppnåddes resultatet i figur 5.5. 10 000 perioders glidande medelvärde av belöningen, som finns i figur 5.5, minskade från 0 ner till -4 under de första 10 000 iterationerna, för att sedan öka upp till 6 efter 40 000

(27)

Figur 5.3: Bild på grafen för beteendet som AI-modellen hade i början.

(28)

Figur 5.5: Resultatet av fortsatt träning av den justerade AI-modellen.

iterationer. Därefter pendlade medelvärdet mellan 6 och 1 innan den nådde en topp på 8 för att sedan pendla mellan 5 och -1.

När det blev oavgjort – främst via att agenterna kolliderade med varandra – kunde det dock leda till både negativ eller positiv belöning när det idealt borde ha lett till en belöning av 0. Därför kan inte vinstandel bestämmas explicit, eftersom urskiljande data mellan vinst och oavgjort inte sparats. Däremot kan andel episoder när AI-agenten inte förlorade bestämmas som andel positiva totalbelöningar (inklusive nollvärden) av de uppmätta. Denna andel blev 78, 4 ˘ 0, 005% av alla uppmätta belöningar.

Distribution av belöningsvärden per 2%-intervall av alla mätvärden i figur 5.6 visar att agentens totalbelöning från 0 till 25 000 iterationer var övervägande negativ. Mellan 25 000 och 150 000 episoder varierade det mellan positiva belöningar och noll, förutom kring 80 000 - 90 000 episoder, där även negativa värden förekommer till större del omkringliggande. Mel-lan 150 000 och 170 000 episoder förekom främst negativa belöningar, för att melMel-lan 170 000 och 200 000 pendla mellan främst negativ och positiv fördelning. En intressant observation är att kring 100 000 episoder och mellan 130 000 och 140 000 episoder är distributionen rela-tivt koncentrerad kring 10, då en markant andel belöningar är just 10, och andelar för lägre värden är betydligt mindre än omkringliggande intervall.

5.1.4 Handlingar och analys

Genom att undersöka Q-tabellen i den tränade modellen kan vi hitta vilka handlingar som agenten finner mest gynnsamma i alla möjliga olika tillstånd. Eftersom tillståndsrymden är så pass stor väljer vi ut sju olika tillstånd. Dessa hämtades genom att skapa sju olika unika scenarion som bedömdes som intressanta.

Scenario 1

Här är båda agenterna riktade rakt mot varandra. De är separerade med ett avstånd på 500 meter och de båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra

(29)

Figur 5.6: Distribution av belöningsvärden per 2%-intervall av alla mätvärden (mörkare cirkel är större andel, svart är 50%).

en missil. Detta scenario resulterar i tillståndet 2220000 med följande par av handlingar och belöning avrundat till två decimaler.

Accelerera: 2,28, sakta ner: 1,27, sväng höger: 0,46, sväng vänster: 1,00, avfyra missil: 1,13 och gör ingenting: 19,10.

Här bedömer AI:n att vänta och inte göra någonting är det bästa beslutet. Ingen annan handling är ens i närheten. Det går inte med säkerhet att avgöra vad det beror på. En möjlig-het är att AI:n är nöjd med sin hastigmöjlig-het och vet om att motståndaragenten kommer att väja eftersom den endast tränat mot detta beteende. Därmed kommer den hålla sin kurs om den avgör att en missil förmodligen inte kommer att träffa.

Scenario 2

Här är den tränade agenten riktad rakt mot motståndaragenten. Motståndaragenten är riktad i samma riktning. De är separerade med ett avstånd på 500 meter och de båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra en missil. Detta scenario resulterar i tillståndet 2240000 med följande par av handlingar och belöning avrundat till två decimaler.

Detta är ett tillstånd som är väldigt gynnsamt att befinna sig i eftersom AI:n har ett bra läge att avfyra missiler samtidigt som det inte finns någon risk alls för att själv bli träffad. Här bedömer AI:n att avfyra missiler är det bästa beslutet, vilket är fullt rimligt och väntat. Scenario 3

Här är motståndaragenten riktad rakt mot den tränade agenten. Den tränade agenten är rik-tad i samma riktning. De är separerade med ett avstånd på 500 meter och de båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra en missil. Detta scenario

(30)

re-sulterar i tillståndet 2320000 med följande par av handlingar och belöning avrundat till två decimaler.

Detta är ett tillstånd som är väldigt utmanande att befinna sig i eftersom motståndara-genten har ett bra läge att avfyra missiler samtidigt som det inte finns någon risk alls för att själv bli träffad. Här bedömer AI:n att svänga höger är det bästa beslutet, detta kan antas vara en påbörjad undanmanöver. AI:n bedömer även att sakta ner farten är det sämsta beslutet. Även detta är fullt rimligt då det endast skulle minska avståndet till motståndaragenten och förmodligen försämra situationen.

Scenario 4

I detta scenario är båda agenterna riktade mot samma riktning. De flyger precis parallellt med varandra där motståndaragenten är direkt till höger om den tränade agenten, de befinner sig på ett avstånd av 300 meter ifrån varandra och de båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra en missil. Detta scenario resulterar i tillståndet 1310000 med följande par av handlingar och belöning avrundat till två decimaler.

Här bedömer AI:n att svänga höger är det bästa beslutet. Det kan låta riskabelt då mot-ståndaren befinner sig direkt till höger men AI:n bedömer trots det beslutet som det bästa möjliga. Det är rimligt att högersvängen är högre värderad då en vänstersväng skulle sätta AI:n i ett liknande scenario som beskrivs i Scenario 4. En högersväng tvingar motståndara-genten att väja för att undvika en kollision. Detta förändrar i sin tur hela scenariot.

Scenario 5

I detta scenario är båda agenterna riktade mot samma riktning. Den tränade agenten befinner sig 500 meter rakt framför motståndaragenten men även 300 meter direkt till höger. Detta motsvarar ett avstånd på 583 meter och en vinkel på 31 grader till den tränade agenten från motståndaragenten. De båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra en missil. Detta scenario resulterar i tillståndet 2020000 med följande par av handlingar och belöning avrundat till två decimaler.

Här bedömer AI:n att vänta och inte göra någonting är det bästa beslutet. Syftet kan vara att tvinga motståndaren att svänga för att sedan göra en undanmanöver i motsatt riktning. Detta sätter påfrestningar på motståndaragenten i form av g-krafter. Det kan även vara fallet att diskretiseringen av tillstånd är för grov. Detta kan då ha medfört att tillståndet är tvetydigt vilket leder till att göra ingenting är det bästa beslutet då den tränade AI-agenten väntar och först fattar ett aktivt beslut när den vet mer. AI-agenten bedömer även att avfyra en missil är det sämsta beslutet. Detta kan bero på att detta medför en period på fem sekunder där missiler inte kan avfyras. Eftersom missilen garanterat inte kommer att träffa blir detta då ett mycket dåligt beslut.

Scenario 6

I detta scenario är båda agenterna riktade mot samma riktning. Motståndaragenten befinner sig 500 meter rakt framför den tränade agenten men även 300 meter direkt till höger. Detta motsvarar ett avstånd på 583 meter och en vinkel på 31 grader till motståndaragenten från den tränade agenten. De båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra en missil. Detta scenario resulterar i tillståndet 2300000 med följande par av handlingar och belöning avrundat till två decimaler.

(31)

5.2. Systemanatomi

Här bedömer AI-agenten att det bästa beslutet är att sakta ner. Detta är smart eftersom att det leder till att vinkeln mellan de båda flygplanen minskar. Detta leder i sin tur att scenariot mer liknar vad som beskrivs i Scenario 2. Det sämsta beslutet här är att inte göra någonting. Detta kan bero på att det låter motståndaragenten att väja undan utan att AI-agenten följer efter.

Scenario 7

Här är båda agenterna riktade rakt bort från varandra. De är separerade med ett avstånd på 500 meter och de båda flygplanen har en hastighet på 200 m/s. Båda flygplanen är redo att avfyra en missil. Detta scenario resulterar i tillståndet 2040000 med följande par av handling-ar och belöning avrundat till två decimaler.

I detta scenario bedömer AI-agenten att det bästa beslutet är att accelerera. Förmodligen ser AI-agenten detta scenario som ett bra tillfälle att öka avståndet mellan motståndaragen-ten. Detta ger mer utrymme för mer komplicerade manövrar när planen till slut är riktade mot varandra igen.

5.2 Systemanatomi

En systemanatomi gjordes i början av projektet i programmet Miro och är åskådliggjord i figur 5.7, där allt som involverade AI-modellen och simulatorn var definierade och där det överblickades vad de väsentligen skulle innehålla. Den har genom hela projektet varit re-levant för hur själva grundidén ska se ut och har inte behövts uppdateras under projektets gång. Projektgruppen kom fram till detta genom att diskutera systemanatomin i slutet av projektet för att se om den fortfarande var relevant och hur den annars behövde uppdateras. Gruppen kom då fram till att den inte behövde uppdateras och att alla punkter av anatomin fortfarande var aktuella för den slutliga produkten.

5.3 Process i fokus

Processen om begäran om sammanslagning började vecka 8 och fortsatte ända tills vecka 20. Frekvensen av processen varierade beroende på hur mycket tid som kunde läggas ner på att utveckla AI-modellen och simulatorn.

5.3.1 Förbättringar

De förbättringar av processen som gjordes var:

• Att när en begäran om sammanslagning skickades upp så skulle personen som skickade upp begäran om sammanslagningen skicka ett meddelande till resten av gruppen via Discord för att minska risken att begäran om sammanslagningar glöms bort av grup-pen. Detta implementerades efter vecka 14.

• Att gruppmedlemmarna skulle vara mer uppmärksamma med att se till att koden de skrev följde kriterierna som hade satts upp. Detta implementerades efter vecka 14. • Att gruppmedlemmarna skulle bli bättre på att kommentera mer

kom-plexa/matematiska delar av koden så att det blir enklare att läsa av de delarna av koden. Detta implementerades efter vecka 15.

(32)

Figur 5.7: Bild över systemanatomin i början av projektet.

• Att meddelanden om begäran om sammanslagning som skickas via Discord skickas i sin egen textkanal så att de inte tappas bort bland andra medelanden som hamnar i samma kanal. Detta implementerades efter vecka 16.

• Att begäran om sammanslagningar inte får ta längre än en arbetsdag (9 timmar) att godkännas. Detta implementerades efter vecka 17.

5.3.2 Utveckling av processen

Figur 5.8 visar att under första veckan av processen var det ett högt antal commits i ett antal begäran om sammanslagningar. Dessa höga antal commits uppkom när gruppen höll på att lära sig processen och var inte helt säkra på hur koden skulle vara strukturerad, vilket ledde till flera omskrivningar. Under projektets gång blev gruppen mer bekväm med processen och strukturen av koden. Dessutom implementerades förbättringarna med att bättre följa PEP 8-standarden för att minska mängden commits. Tillsammans ledde det till att antal commits i aktiv begäran om sammanslagningar minskade under de senare veckorna.

I figur 5.9 visas det att den första veckan när processerna utfördes hade granskningstiden minst variation jämfört med granskningstiden för de andra veckorna. Anledningen till detta var att under den veckan utvecklades grunden av simulatorn, vilket gjorde att begäran om sammanslagningar var snabbt granskade så att arbetet kunde fortsätta framåt från en och samma struktur. I de senare veckorna började uppgifter delas ut till de aktiviteter som skulle implementeras i simulatorn och gruppmedlemmarna kunde då arbeta separat från varandra. Detta blandat med att ett antal begäran om sammanslagningar laddades upp under tider när gruppen var upptagen med andra uppgifter i projektet eller med andra kurser ledde till att dessa begäran av sammanslagningar tog mycket lång tid att granskas.

Figur 5.9 visar också att storleken av begäran om sammanslagning hade ingen riktig på-verkan på hur snabbt de granskades. Förbättringar som att skicka ett meddelande till alla gruppmedlemmar via Discord, och att en begäran om sammanslagning inte fick ta längre än 9 timmar att granskas, var tänkt att se till att processen skulle utföras snabbare och undvika

(33)

5.4. Gemensamma erfarenheter

Figur 5.8: Mätvärden för antal commits av varje begäran av sammanslagning.

situationer där granskningen tog över en dag att granskas. Dessa ändringar i processen gav inte några signifikanta förbättringar, då det större problemet med att utföra processen i god tid var att andra uppgifter och kurser tog tid från gruppmedlemmarna att utföra processen, samt att det inte fanns någon koordination om vilka personer som skulle göra granskningen.

5.4 Gemensamma erfarenheter

Alla gruppmedlemmar har fått erfarenhet av att skriva och granska de obligatoriska doku-menten. Erfarenhet har även fåtts av att arbeta med den agila utvecklingsmetoden Scrum, där GitLab har använts för att göra aktiviteter och skriva milstolpar. GitLabs pipelines har använts för automatiserade tester, så det är också något som gruppen har fått erfarenhet av. Något som har märkts är att formuleringen av aktiviteter är viktig så att det blir tydligt för alla vad som ska ingå i en aktivitet. Det har även märkts att för att uppnå en bra effektivi-tet bör gruppmedlemmarna inte tveka att fråga varandra om hjälp inom gruppen. Dessa är erfarenheterna från första fasen av projektet.

Från den andra och sista fasen av projektet har gruppen fått erfarenhet från att jobba mot en riktig kund och kännedom om hur det ska hanteras. En till erfarenhet som fåtts är att job-ba i en större projektgrupp än vad som har gjorts i tidigare projekt. Det har medfört att saker som att få igenom allas vilja har varit svårare, men att få saker gjorda har gått snabbare då alla hjälper till. Arbetet har behövts göras på distans vilket kan ha försvårat arbetsprocessen genom att göra den mer okonventionellt upplagd, dock tar gruppen med sig vissa aspekter som har underlättats såsom borttagning av transport till mötesplatser och möjlighet för flera att koda samtidigt under avlägsen parprogrammering. Sedan har även alla gruppmedlem-mar erhållit erfarenhet om att presentera och opponera, där fyra seminarier har hållits där delar av projektet har visats upp – och kritik till andra gruppers projekt har givits. En stor del av projektet var att utveckla en AI-modell för de simulerade planen via Q-inlärning, vilket samtliga inom gruppen åtminstone har bekantat sig med.

(34)

Figur 5.9: Mätvärden för storlek av varje begäran om sammanslagningar och den tid det tog att granska.

5.5 Översikt över individuella bidrag

Varje gruppmedlem har skrivit ett individuellt bidrag till kandidatrapporten. Dessa beskrivs kort nedan.

Daniel Covarrubias Gillinhar i appendix A skrivit en jämförelse av parprogrammering på distans med parprogrammering på plats. Utredningen fokuserade på att undersöka skillna-derna på upplevelsen och utförandet mellan parprogrammering på distans och på plats. Gustav Arnevinghar i appendix B jämfört prestanda för olika sätt att spara träningsresultat för Q-learning. Ett antal implementationsförslag testades för att avgöra vilket som skulle vara lämpligast för fortsatt användning.

Joel Alexanderssonhar i appendix C skrivit om ledarskap på distans.

Leon Li Persson har i appendix D skrivit om samtida och framtida risker med AI inom ett militärt sammanhang. En litteraturstudie har gjorts för att identifiera dessa risker – och åtgärder som kan tas för att avvärja eller mitigera dessa.

Lukas Olssonhar i appendix E skrivit om de etiska konsekvenserna av användning av Lethal autonomous weapon systems och hur studenter som studerar data- eller mjukvaruteknik tänker kring det. Detta har gjorts med hjälp av en enkät som studenter har fått svara på.

Martin Banckhar i appendix F skrivit om valen och diskretiseringen av states och actions för Q-matrisen i en Q-learning agent och hur detta påverkar agentens inlärning och prestation.

(35)

5.5. Översikt över individuella bidrag

Max Björkanderhar i appendix G skrivit en jämförelse av AI-biblioteken OpenAI Gym och scikit-learn. En utvärdering gjordes av hur de kan användas i studentprojekt och för- och nackdelarna med att använda respektive bibliotek.