Animering av flervariabla reglersystem med Matlab och Java · 2012. 10. 22. · Dentredje,ochisärklass st örsta, biten har varit att skapa egna ani-meringar och använda dem

Animering av flervariabla reglersystem

med Matlab och Java

Examensarbete utfört i Reglerteknikvid Tekniska Högskolan i Linköping

av

Magnus Andersson

Reg nr: LiTH-ISY-EX-3145

Animering av flervariabla reglersystemmed Matlab och Java

Examensarbete utfört i Reglerteknikvid Tekniska Högskolan i Linköping

av

Magnus Andersson

Reg nr: LiTH-ISY-EX-3145

Handledare: Mikael Norrlöf

Examinator: Svante Gunnarsson

Linköping, 10 januari 2001.

Sammanfattning i

Sammanfattning

Rapporten behandlar hur datoranimeringar kan användas i undervisningenav flervariabel reglerteknik. Huvudsyftet har varit att utveckla animeringarför kurserna TSRT35 Reglerteori Y och TSRT38 Reglerteori I. Tv̊a anime-ringar har skrivits – en i Matlab och en som ett frist̊aende Java-programsom använder API:t Java 3D. B̊ada tv̊a har använts i undervisningen hösten2000, och deras för- och nackdelar utvärderas.

För att f̊a en vidare överblick har en förteckning över liknande projekttagits fram, med kommentarer om hur de använts i undervisningen ochvilka tekniska lösningar som valts. Dessutom inneh̊aller rapporten en utförligdiskussion om vilka programspr̊ak och API som är lämpliga att använda föratt animera system som simuleras i Matlab och Simulink.

Nyckelord: Matlab, Simulink, Java, Java 3D, API, datorgrafik, animering,flervariabla reglersystem, undervisning.

Abstract

This report discusses how computer animations may be used for teachingof multivariable control. The main purpose has been developing animationsfor the courses TSRT35 Control Theory Y and TSRT38 Control Theory I.Two animations have been written – one using Matlab and the other usingJava and Java 3D API. Both have been used in the teaching fall 2000, andtheir effects have been evaluated.

To get a more comprehensive overview similar projects are listed, toget-her with comments on how they were used in teaching, and which techni-cal solutions that have been chosen. Also, the report contains a discussionof which programming languages and API that are suitable for animatingsystems simulated by Matlab and Simulink.

Key Words: Matlab, Simulink, Java, Java 3D, API, computer graphics,animation, multivariable control systems, teaching.

ii Inneh̊all

Inneh̊all

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Mål och problemformulering . . . . . . . . . . . . . . . . . . . 21.3 Rapportöversikt . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Utblick 42.1 Förteckning över animeringar . . . . . . . . . . . . . . . . . . 5

3 Programspr̊ak och verktyg 83.1 Tekniska lösningar . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Möjliga verktyg . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Möjliga verktyg för animering i Matlab/Simulink . . . . . . . 10

3.4.1 S-funktioner . . . . . . . . . . . . . . . . . . . . . . . . 103.4.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4.3 Java 3D . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.5 Möjligheter i Matlab 6.0 R12 . . . . . . . . . . . . . . . . . . 133.6 Val av programspr̊ak . . . . . . . . . . . . . . . . . . . . . . . 13

4 Animering i Matlab 144.1 Bakgrund och fr̊ageställningar . . . . . . . . . . . . . . . . . . 144.2 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Systemekvationer . . . . . . . . . . . . . . . . . . . . . 144.2.2 Linjärisering . . . . . . . . . . . . . . . . . . . . . . . 164.2.3 Reglertekniska aspekter . . . . . . . . . . . . . . . . . 17

4.3 Användning i undervisningen . . . . . . . . . . . . . . . . . . 184.4 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1 Matlabs programspr̊ak . . . . . . . . . . . . . . . . . . 214.4.2 Filförteckning . . . . . . . . . . . . . . . . . . . . . . . 224.4.3 Simulinkmodell . . . . . . . . . . . . . . . . . . . . . . 224.4.4 Animeringsfönstret . . . . . . . . . . . . . . . . . . . . 234.4.5 Grafiskt gränssnitt för inställning av parametrar . . . 234.4.6 Animering . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.7 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Diskussion och slutsatser . . . . . . . . . . . . . . . . . . . . . 284.5.1 Undervisning . . . . . . . . . . . . . . . . . . . . . . . 284.5.2 Programmering . . . . . . . . . . . . . . . . . . . . . . 29

Inneh̊all iii

5 Animering med Java 3D 305.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . 305.2 Användning i undervisningen . . . . . . . . . . . . . . . . . . 325.3 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.1 Java 3D . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.2 Animeringens uppbyggnad . . . . . . . . . . . . . . . . 345.3.3 Filförteckning . . . . . . . . . . . . . . . . . . . . . . . 365.3.4 Animering . . . . . . . . . . . . . . . . . . . . . . . . . 375.3.5 Datafiler . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3.6 Animeringsfönstret . . . . . . . . . . . . . . . . . . . . 385.3.7 Användning i undervisningen . . . . . . . . . . . . . . 395.3.8 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4 Diskussion och slutsatser . . . . . . . . . . . . . . . . . . . . . 415.4.1 Undervisning . . . . . . . . . . . . . . . . . . . . . . . 415.4.2 Programmering och utvecklingstid . . . . . . . . . . . 42

6 Diskussion och slutsatser 44

Referenser 46

Bilaga A: Dokumentation över vattentankanimeringen 48A.1 Grafik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A.1.1 Val av grafikfunktioner . . . . . . . . . . . . . . . . . . 48A.1.2 Hur grafiken ritas . . . . . . . . . . . . . . . . . . . . . 49

A.2 Globala variabler . . . . . . . . . . . . . . . . . . . . . . . . . 49A.3 S-funktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.4 Parameterfönstret . . . . . . . . . . . . . . . . . . . . . . . . 51A.5 Animering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Bilaga B: Dokumentation över flygplansanimeringen 56B.1 Java 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56B.2 Animering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59B.3 Översikt av programfilerna . . . . . . . . . . . . . . . . . . . 59B.4 Klassen Flight.java . . . . . . . . . . . . . . . . . . . . . . . . 60

B.4.1 Funktionen createSceneGraph . . . . . . . . . . . . . . 61B.4.2 Flygplan . . . . . . . . . . . . . . . . . . . . . . . . . . 63B.4.3 Motorflammor . . . . . . . . . . . . . . . . . . . . . . 64B.4.4 Dimma och ljus . . . . . . . . . . . . . . . . . . . . . . 65B.4.5 Mark, himmel och horisont . . . . . . . . . . . . . . . 65B.4.6 Stödlinjer . . . . . . . . . . . . . . . . . . . . . . . . . 66

iv Figurer

B.4.7 Funktionen disableFog . . . . . . . . . . . . . . . . . . 67B.4.8 Funktionen angToQuat . . . . . . . . . . . . . . . . . 67B.4.9 Funktionen loadData . . . . . . . . . . . . . . . . . . . 67B.4.10 Funktionen createMenus . . . . . . . . . . . . . . . . . 68B.4.11 Funktionen main . . . . . . . . . . . . . . . . . . . . . 68

B.5 Klassen Listener . . . . . . . . . . . . . . . . . . . . . . . . . 68B.6 Klasserna Ground, Sky och Horizon . . . . . . . . . . . . . . 69

Bilaga C: Programkod för vattentankanimeringen 70C.1 tanks.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70C.2 background.m . . . . . . . . . . . . . . . . . . . . . . . . . . . 83C.3 parameters.m . . . . . . . . . . . . . . . . . . . . . . . . . . . 84C.4 guifcn.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91C.5 tankequib.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Bilaga D: Programkod för flygplansanimeringen 94D.1 Flight.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94D.2 Listener.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 112D.3 Ground.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112D.4 Sky.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113D.5 Horizon.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113D.6 anim.m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figurer

2.1 Virtual Control lab inneh̊aller tre system som är animeradei 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 S-funktioner läggs in som vanliga block i Simulink och derasegenskaper bestäms av programmeraren. . . . . . . . . . . . . 11

3.3 För animeringar skrivna i Java är det lämpligast att spara alldata p̊a textfiler fr̊an Matlab, och sedan exekvera ett separatJava-program. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.4 Skiss över tanksystemet. Tv̊a pumpar förser tankarna medvatten. V̊ara utsignaler är vattenniv̊aerna h1 och h2. Medventilernas inställningar kan ett nollställe flyttas till högerhalvplan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5 Simulink-filen watertanks.mdl. Det inringade blocket är v̊arS-funktion som skapar animeringen. . . . . . . . . . . . . . . 23

4.6 Animeringsfönstret för vattentankanimeringen. Insignalerna,d v s spänningen över pumparna, plottas i fönstrets nedre del. 24

Tabeller v

4.7 Parameterfönstret för vattentankmodellen. De gr̊amarkeradefälten inneh̊aller systemkonstanter som inte kan ändras. . . . 25

4.8 Dataflödet i vattentankanimeringen. När användaren ändrarvärdena i parameterfönstret sätts dessa variabler i Matlabsworkspace. När simuleringen startas i Simulink startar ävenanimeringen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.9 Vinklar för beräkning av flygplanets rörelse, för ett skrovfastsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.10 I datorlaborationen används endast roll- och girvinklar. Ani-meringen kan dock användas även för fullständiga manövrar.α- och β är vinklarna mellan flygkropp och hastighetsvektor.Roll-, gir- och tippvinklar är däremot definierade utifr̊an detglobala koordinatsystemet, d v s gentemot en fix rak kurs. . . 33

5.11 Animeringens uppbyggnad. Förutom mark- och himmelplanlöper runt flygplanet en cylinder som visar horisonten. . . . . 35

5.12 Animeringsfönstret för flygplansanimeringen är indelat i trerutor, som visar var sin vy. Streckade hjälplinjer visar planetsrotationsvinklar. . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.13 Dataflödet för flyganimeringen. Matlab-funktionen anim ska-par alla datafiler och startar sedan animeringen med ett ter-minalkommando. . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.14 Fyra begreppsvärldar. Med matematiska modeller och simu-leringar kan vi efterlikna det verkliga systemet, och med ani-meringar f̊ar vi en bild av hur det beter sig. . . . . . . . . . . 44

B.1 Objektträd. Den vänstra grenen inneh̊aller v̊ara fysiska ob-jekt, medan den högra bestämmer kamerans egenskaper. An-talet grenar och deras inneh̊all kan variera. . . . . . . . . . . 57

B.2 I samma ögonblick som grenen med de fysiska objekten sättssamman med det övriga trädet startar animeringen. Dessförinnankompilerar vi grenen för att den ska g̊a snabbare att exekvera. 59

Tabeller

4.1 Systemkoefficienter . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Mätvärden för systemkoefficienter. . . . . . . . . . . . . . . . 165.3 Exempel p̊a datafil. Överst st̊ar samplingstiden, därunder an-

tal sampel och sist listas alla värden. . . . . . . . . . . . . . . 38

vi Tabeller

A.1 Funktioner som kan användas i en S-funktion skriven somm-fil. Namnen är de standardmässiga, och beskrivningen tarupp de vanligaste uppgifterna. I animeringen använder vi en-bart flaggorna 0, 2 och 9. . . . . . . . . . . . . . . . . . . . . 50

1 Inledning 1

1 Inledning

1.1 Bakgrund

Datoranimeringar av system och algoritmer har börjat spela en allt viktigareroll b̊ade i den akademiska världen och i industrin. Matematiska modelleroch grafer ger i princip all information man behöver, men en animeringgör informationen betydligt mer översk̊adlig och lättsmält. Framför allt ärdetta viktigt i undervisnings- och presentationssammanhang. Den snabbautvecklingen av datorprestanda och den svällande mjukvarufloran har dess-utom gjort det möjligt att förh̊allandevis snabbt och smärtfritt producerafunktionella animeringar med höga grafiska och pedagogiska kvaliteter.

Denna rapport är skriven som en del av ett examensarbete för civilin-genjörsprogrammet för Teknisk fysik och elektroteknik vid Linköpings uni-versitet. Arbetet har utförts internt vid Institutionen för Systemteknik förämnesomr̊adet Reglertekniks räkning. För att tillgodogöra sig inneh̊allet börman vara bekant med grundläggande flervariabel reglerteknik och besittaallmänna programmerarkunskaper. Rapporten inneh̊aller dock inga störretekniska utsvävningar, s̊a även den som saknar dessa förkunskaper bör kun-na f̊a ett hyfsat utbyte vid genomläsning.

Syftet med arbetet har varit att utröna vilka möjligheter det finns attskapa animeringar av reglertekniska system, och hur dessa bäst kan användasi institutionens undervisning. I princip kan arbetet delas upp i tre separatadelar. Den första har best̊att av att söka efter information om liknande pro-jekt där animeringar använts i undervisningssyfte. Kommersiella program-paket har jag bortsett ifr̊an, även om dessa har haft undervisningsmässigakvaliteter. De fr̊agor som jag mest inriktat mig p̊a är vilka tekniska lösningarsom valts, hur animeringarna använts i undervisningen och vilka erfarenhe-ter som dragits fr̊an detta.

Den andra arbetsbiten har handlat om att utröna vilka programspr̊akoch verktyg som är lämpliga för de aktuella uppgifterna. Framför allt harkrav ställts p̊a att programmen ska vara plattformsoberoende och koppladetill Matlab.

Den tredje, och i särklass största, biten har varit att skapa egna ani-meringar och använda dem i undervisningen. När animeringarna blivit kla-ra har de stoppats in i reglerteknikkurserna som datoruppgifter och labo-rationer, vilket har gett en återkoppling som varit mycket värdefull vidutvärdering.

2 1 Inledning

1.2 Mål och problemformulering

Den grundläggande problemställningen bakom arbetet var hur datoranime-ringar skulle kunna förbättra undervisningen i kurserna TSRT35 ReglerteoriY och TSRT38 Reglerteori I, som behandlar flervariabel och ickelinjär regler-teknik. Risken med matematiska modeller och teoretiska resonemang är attstudenterna kan tappa verklighetsanknytningen och bli förvillade av detmatematiska symbolspr̊aket. Eftersom studenterna bara kommer i kontaktmed verkliga system under ett f̊atal laborationstillfällen under sin studietid,kan datoranimeringar bidra mycket till att visa vad som egentligen sker ochp̊a ett rättframt sätt demonstrera system- och regulatoregenskaper. Att sehur systemet verkligen uppför sig är ofta mer givande, och om inte annatroligare, än att dra slutsatser fr̊an framräknade värden och grafer, även omde sistnämnda först̊as fortfarande är oersättliga hjälpmedel.

När arbetet med att skapa animeringar började hade vi en rad problemoch aspekter vi ville utröna, och de kan sammanfattas med följande fr̊agor:

• Vilka programspr̊ak och verktyg är bäst lämpade att använda?

• Vilka förkunskaper krävs och hur l̊ang tid tar det att lära sig dessaom de saknas?

• Vilka hinder lägger datorprestanda?

• Hur komplexa animeringar kan skapas med rimlig nedlagd arbetsbörda,l̊at säga n̊agra veckors heltidsarbete?

• Hur kan animeringarna användas i undervisningen?

• Vilka system är lämpligast att animera fr̊an undervisningssynpunkt?

• Hur mycket av den kod som skrivs kan återanvändas för att snabbtkunna skapa en annan animering?

Dessutom hade vi en del krav och förbeh̊all p̊a hur vi ville att anime-ringarna skulle utformas:

• Animeringen ska kopplas till Matlab och kunna startas fr̊an Matlabskommandofönster eller via Simulink.

• Filerna ska vara plattformsoberoende och kunna flyttas mellan olikadatorsystem i största möjliga mån.

1.3 Rapportöversikt 3

Anledningen till att filerna skulle vara plattformsoberoende var att detökar användningsomr̊adena betydligt. Institutionens datorsalar best̊ar avUnix-maskiner medan merparten av studenterna har PC som hemdatorer.Om filerna är flyttbara kan de användas b̊ade som laborationsuppgifter idatorsalarna, som hemuppgifter eller för självstudier.

Syftet med animeringarna har i första hand varit att göra dem funktio-nella och lättanvända. Grafiska och tekniska effekter har kommit i andrahand. Tjusig grafik är först̊as ett plus, men inte om det sker till priset avl̊angsammare program eller markant ökning av tiden för utvecklingsarbetet.Eftersom animeringarna kommer köras upprepade g̊anger är ett snabbt pro-gram med rudimentär grafik betydligt mer användbart än ett l̊angsamt medmer finpolerad yta, s̊avida det inte g̊ar ut över först̊aelsen eller tydligheten.

1.3 Rapportöversikt

Det nästföljande kapitlet, kapitel 2, sammanfattar och listar de anime-ringsprojekt jag funnit p̊a institutioner för reglerteknik runt om i världen.

Kapitel 3 behandlar animering och dess användning i ett mer allmäntperspektiv. Jag g̊ar igenom vilka programspr̊ak och verktyg som är möjligaatt använda för att skapa effektiva animeringar. Därefter konfronterar jagdem med de krav som är listade ovan, och kan därmed skära ned antaletmöjligheter till tre. Jag väljer tv̊a av dessa – filer skrivna direkt i Matlabsprogramspr̊ak respektive i Java.

I kapitel 4 g̊ar jag igenom den animering som skrivits i Matlab. Jagbeskriver reglersystemet, hur animeringen implementerats samt utvärderarde erfarenheter vi dragit och den respons vi f̊att fr̊an de studenter somanvänt den.

Kapitel 5 behandlar p̊a samma sätt den andra animeringen, som skri-vits i Java.

Kapitel 6 inneh̊aller allmänna slutsatser och diskussioner och avrundarprojektdelen av rapporten.

Bilaga A och B inneh̊aller en mer detaljerad beskrivning av program-koden till de bägge animeringarna. Själva koden finns bifogad i bilaga Coch D. De här delarna är i första hand till för den som vill skriva liknandeanimeringar eller sätta sig in i hur koden är uppbyggd. Den som inte ärlika intresserad kan lugnt hoppa över hela appendix utan att det inverkarnegativt p̊a först̊aelsen av de övriga avsnitten.

– – –

4 2 Utblick

2 Utblick

För att kunna f̊a en vidare överblick p̊a vilka möjligheter animeringar kanspela i reglerteknisk undervisning har jag undersökt vilka liknande projektsom bedrivits p̊a reglerteknikinstitutioner världen över. Jag kontaktade in-stitutionerna via e-post och lät dem helt sonika berätta vilka erfarenheter dehade av att använda animeringar i undervisningen. En komplett förteckningöver rundfr̊agningens resultat följer i kapitel 2.1.

Allmänt kan sägas att majoriteten av de animeringar som hittades varJava-applets av enklare typ som kunde köras direkt i webbläsaren. De be-skrev tv̊adimensionella system. Ofta gick det att ändra parametrar i ettseparat fönster och sedan betrakta förändringarna i animeringen. Använd-ningsomr̊adet var vanligtvis ämnat för självstudier. I vissa fall var anime-ringarna knutna till lektioner eller föreläsningar, och belyste viktiga delar avdet material som lektionen eller föreläsningen berörde. Studenterna kundep̊a egen hand g̊a in p̊a webbsidan och experimentera.

I n̊agra fall l̊ag animeringarna p̊a en mer rudimentär niv̊a. Undervi-sarna hade ingen dokumentation eller inga programfiler av större vikt attvisa upp för oss, utan använde animeringarna sporadiskt vid genomg̊angaroch lektioner. Utvecklingen var inte avslutad utan programmen förbättradeskontinuerligt parallellt med undervisningen. Dessa projekt finns inte listadei förteckningen.

N̊agra projekt var väldigt väl utbyggda och integrerade i undervisning-en. Ett framst̊aende exempel utgör Virtual Control lab som utvecklats vidRuhr-Universität i Tyskland. Där har mer eller mindre en hel laborations-sal modellerats i 3D och lagts ut p̊a nätet, se fig 2.1. Tre olika system kanundersökas och laboreras virtuellt.

Vid Arizona State University i USA har tv̊a tredimensionella animering-ar skapats. De är skrivna i Visual C++ och använder Direct3D för rendering.Modellerna simuleras i Simulink.

I ett fall har resultatet blivit en kommersiell programvara med nam-net SysQuake, som visar utsignalernas beroende av polernas placeringar.Polerna och nollställena kan flyttas omkring p̊a skärmen och plottade ut-signaler förändras ögonblickligen vid sidan om. Det här är visserligen inteen renodlad systemanimering av den typen jag eftersökte, men har flera ge-mensamma element med s̊adana program. SysQuake finns i en nedbantadversion som är gratis att ladda hem.

2.1 Förteckning över animeringar 5

Figur 2.1. Virtual Control lab inneh̊aller tre system som är animerade i 3D.

2.1 Förteckning över animeringar

• Department of Automation, Technical University of Den-mark, Danmark

I Internetkursen 50390 Fuzzy Control används ett Matlab-programsom simulerar och animerar en tv̊adimensionell pendel. Pendeln best̊arav en kupad trissa som kan flyttas i sidled. Målet är att placera en kulasom rullar p̊a trissan p̊a dess mittpunkt. Programmet är skrivet somm-filer och laddas hem av studenterna. Det finns även en webbaseraddemonstration.

Kurssida för 50390 Fuzzy Control: fuzzy.iau.dtu.dk/fuzcon.html

Programfiler för nedladdning: fuzzy.iau.dtu.dk/tedlib.nsf/List

Webbaserad demonstration: fuzzy.iau.dtu.dk/demos.html

• Laboratoire D’Automatique de Grenoble, FrankrikeEn Java-applet för ett system med en balanserade kula p̊a en balk.Ska regleras med diverse olika regulatorer, vars parametrar kan ställasin i fönstret.

6 2 Utblick

www-hadoc.ensieg.inpg.fr/hadoc/ateliers/billeSurRail/CasBilleDroite.htm#simulation

• Department of Electrical and Computer Engineering, Uni-versity of Newcastle, Australien

P̊a hemsidan till en lärobok i reglerteknik som skrivits av institutionenfinns åtta interaktiva exempel, skrivna som Java-applets. De är tänktaatt användas i samband med att boken används i reglerteknik-kurser.

csd.newcastle.edu.au/control

• SysQuake är ett interaktivt program i vilket man bland annat kanflytta poler med musen och omedelbart f̊a systemets Nyquistkurvaoch stegsvar plottade. Skrevs ursprungligen i samband med en dok-torsavhandling, men är numera en kommersiell produkt. Finns i enbantad version, SysQuake LE (Light Edition) som till skillnad motfullversionen är kostnadsfri.

www.calerga.com

• School of Electrical and Computer Engineering, Georgia In-stitute of Technology, USA

En lärobok i grundläggande reglerteknik har skrivit och p̊a dess hem-sida finns ett flertal små Java-applets som illustrerar moment i boken.P̊a en av författarnas hemsida finns även en intressant genomg̊ang avhur Internet kan användas i reglerteknik-undervisningen.

users.ece.gatech.edu:80/~bonnie

• Institute for Systems Research, University of Maryland, USAEtt flertal professorer arbetar med att integrera animeringar med un-dervisning. Har bland annat resulterat i SimPLE – ett verktyg skriveti Pascal för att utveckla simulatorer för undervisning. En anställd harutvecklat tv̊a enkla animeringar av ett ugnssystem.

Information om undervisningsprojekten: www.isr.umd.edu/CELS

Ugnsanimering: www.enme.umd.edu/ice lab/lab/stoves.html

• Johns Hopkins University, Baltimore and Wahington, USAJava-baserade animeringar. Används i huvudsak av studenterna försjälvstudier, men ibland även som obligatoriska hemuppgifter eller förpresentationer vid föreläsningar och lektioner. Animeringarna användsäven vid flera andra universitet.

2.1 Förteckning över animeringar 7

www.jhu.edu/~signals

• Elektrische Steuerung und Regelung, Ruhr-Universität, Bo-chum, Tyskland

Har byggt upp tre virtuella laborationssalar under benämningen Vir-tual Control lab (VClab). Det första systemet är en kula som balan-serar p̊a en balk, det andra tre sammankopplade vattentankar ochdet sista en gyropendel. För att kunna köra animeringarna krävs attman laddar hem ett separat programpaket, som best̊ar av en serieJava-applets och plugin-filer till Matlab. Dessutom krävs att man harMatlab, Simulink och plugin-programmet SGI Cosmo Player, för attvisa VRML-filer, installerade p̊a datorn. P̊a webbplatsen finns ävenen del genomg̊angar av grundläggande reglerteknik tillsammans medinteraktiva exempel i form av Java-applets.

Det finns en nyare och uppdaterad version av VClab, med namnetDynaMit, som inneh̊aller fler system. Den finns dessvärre inte i engelsköversättning.

www.esr.ruhr-uni-bochum.de

• Department of Electrical Engineering, Arizona State Univer-sity, Tempe, USA

Tv̊a avancerade animeringar har utvecklats. Den ena beskriver en heli-kopter och den andra den andra en annorlunda modell av en inverteradpendel, där själva pendeln balanserar p̊a en vagga som kan lutas förstabilisera pendelrörelsen. Bägge animeringarna är skrivna i VisualC++ och använder API:t Direct3D, vilket gör att de enbart fungerarp̊a PC-datorer. De är kopplade till Simulink och en mängd grafiskagränssnitt ing̊ar i paketen, för att visa variabler, plotta kurvor ochställa in diverse parametrar.

Inverterade pendel-animeringen finns beskriven i C Rios m fl (1999) [6].

• Automatic Control Laboratory, Swiss Federal Institute of Te-chnology, Zürich, Schweiz.

I en rad Internet-kurser ing̊ar ett flertal små animeringar skrivna iMatlab.

www.aut.ee.ethz.ch/edu

– – –

8 3 Programspr̊ak och verktyg

3 Programspr̊ak och verktyg

Rörliga bilder uppträder i nästan alla möjliga sammanhang där det finnsen dator inblandad – alltifr̊an enkla webbannonser p̊a Internet till dator-spel som ställer datorns prestanda p̊a sin yttersta rand. Det finns dessutomen viktig skillnad mellan webbannonsen och datorspelet förutom grafikenskomplexitet. Annonsen, liksom merparten av alla animeringar som visas p̊anätet och p̊a film, är förrenderad. Den är sparad som en bildfil som spe-las upp när man besöker webbsidan där den ligger. I ett tredimensionelltdatorspel beräknas däremot grafikens utseende i samma ögonblick som denvisas p̊a skärmen. Det möjliggör interaktivitet – att själv kunna styra spel-figuren och ändra synvinkel. Förrenderade bilder kan skapas i kommersiellagrafikprogram och duger till presentationer och i uppvisningssyfte. Om ani-meringen ska fylla n̊agon funktion i studiesammanhang krävs dock att denär interaktiv, och d̊a måste vi skriva egna program. Valet av verktyg ärdärmed begränsat till val av programspr̊ak och grafikbibliotek.

3.1 Tekniska lösningar

Vid utvecklingen av grafiktunga applikationer är det i första hand prestan-da som sätter gränserna. För tio år sedan var Assembler det dominerandespr̊aket för grafisk utveckling. Efter hand som datorerna blivit snabbarehar kravet p̊a att f̊a ut maximal prestanda minskat n̊agot, och numera ärC++ det i särklass populäraste programspr̊aket för professionell utvecklingav s̊aväl grafiska som övriga program.

De animeringar som jag ville skapa ställde emellertid inga höga kravp̊a grafiken. För enkla tv̊adimensionella animeringar duger i princip vilketvanligt förekommande programspr̊ak som helst. Prestanda blir viktigare vidtredimensionell animering, men även här finns det ett flertal olika alternativatt välja mellan.

3.2 Möjliga verktyg

Principiellt ligger det en konflikt mellan snabbhet och utvecklingstid. ”Snab-ba” spr̊ak ligger vanligtvis p̊a l̊ag niv̊a spr̊akmässigt sätt. Ett uppenbart ex-empel är Assembler som bara ligger snäppet över vanlig maskinkod. Ävenhögniv̊aspr̊ak som C++ kan räknas in i den här klassen eftersom stödet förgrafik och grafiska komponenter är ganska basalt. Utvecklingsverktyg somVisual C++ inneh̊aller visserligen färdiga klasser med grafiska komponenter,men i allmänhet ing̊ar dessa inte i spr̊aket.

3.2 Möjliga verktyg 9

”L̊angsamma” spr̊ak, som exempelvis Visual Basic och Java, är å sin si-da betydligt enklare att använda för programmeraren. Fönster, knappar ochövriga grafiska komponenter är fördefinierade i ursprungsversionerna. Pro-grammen behöver inte byggas upp fr̊an grunden. Mindre kod behöver skri-vas vilket minskar tiden för utvecklingsarbetet. Dessutom är det i allmänhetenklare att göra ändringar i koden i efterhand, om funktioner behöver läggastill eller tas bort.

Förutom valet av programspr̊ak är det även viktigt att välja grafikbib-liotek, eller API för att använda en mer korrekt benämning. I ett API finnsdefinitioner av klasser och funktioner för de vanligaste grafiska metoder-na, till exempel för att rita geometrier och kopiera bilder. De kan anropasoch användas av programmeraren. Tv̊adimensionella API:n är vanligtvis in-byggda i operativsystemet. För tredimensionella API:n är valet desto merovisst. Det finns ingen dominerande standard som allmänt kan sägas varamest lämpad. De vanligaste är listade här tillsammans med respektive för-och nackdelar:

• OpenGL. Har störst utbredning och finns för i princip alla platt-formar. Är inbyggd i Windows sedan den andra versionen av Win-dows 95 (Windows 95 OSR2). Kan användas av alla programspr̊ak.Stöder h̊ardvaruacceleration, vilket finns för de flesta moderna grafik-kort. Flyttbarheten mellan plattformar är utmärkt.

• Direct3D. Ing̊ar som en del av DirectX. Kan bara användas p̊a PC-datorer, men av alla programspr̊ak. H̊ardvarustöd finns. Är tillsam-mans med OpenGL det dominerande API:t för framför allt spel.

• Glide. Mycket enkelt att använda för programmeraren. Kan baraanvändas tillsammans med grafikkrestar av typen 3Dfx. Var helt do-minerande i spelbranschen 1997-1998, men har numera (hösten 2000)försvunnit nästan helt.

• Java 3D. Ett tilläggspaket till Java. Medioker prestanda. Plattform-soberoende, kan köras p̊a alla datorer där Java 3D är installerat.Använder h̊ardvarustöd för OpenGL och Direct3D. Högniv̊a-API ochrelativt enkelt att använda.

De angivelser av prestanda som st̊ar upptagna gäller mjukvaruexekve-ring. Med 3D-grafikkort höjs prestanda betänkligt, men det varierar kraftigtberoende p̊a vilket kort som används.


3.3 Krav

När vi valde programspr̊ak och API var det i huvudsak tv̊a kriterier som l̊agtill grund för besluten. För det första ville vi att programmen skulle varaplattformsoberoende, i största möjliga mån, s̊a att de kan köras b̊ade p̊astudenternas hemdatorer och i universitets datorsalar. D̊a blir det flexiblareatt formulera uppgifter, och lättare att passa in animeringarna där de passarbäst i undervisningen. Antingen kan de användas som laborationsuppgifter,i samband med datorlektioner eller för självstudier. Demonstrationer vidföreläsningar är ett annat tänkbart användningsomr̊ade.

För det andra skulle animeringarna vara kopplade till Matlab och Simu-link, s̊a att de kan startas direkt fr̊an Matlabs kommandofönster eller ännuhellre i samband med att en simulering startas i Simulink.

3.4 Möjliga verktyg för animering i Matlab/Simulink

Det g̊ar att starta program direkt fr̊an Matlab med hjälp av ett vanligt ter-minalkommando. Men om vi vill integrera programmet med Matlab har viendast tre alternativ att välja mellan – att skriva programmen helt i Matlabseget programspr̊ak eller i C och knyta dem till Simulink via S-funktioner,eller att anropa färdiga Java-klasser. Vi g̊ar igenom dessa alternativ nedan.

3.4.1 S-funktioner

I Simulink finns ett särkilt block som kallas S-funktioner. Deras funktionerkan detaljstyras av programmeraren. Den kopplas in som ett vanligt blocki Simulinkmodellen och kan ha b̊ade in- och utsignaler. När simuleringenstartas anropar Simulink programfilen vid varje uppdateringstillfälle, vilketgör det möjligt att visa en animering under simuleringens g̊ang. S-funktionerbeskrivs närmare i detalj i bilaga A.

Tv̊a sorters filer kan ligga till grund för en S-funktion. Den ena variantenär filer skrivna direkt i Matlabs eget programspr̊ak, s̊a kallade m-filer. Denandra möjligheten är filer skrivna i C, vilka kallas för C-MEX-filer. Denförstnämnda möjligheten har fördelen att filerna kan köras p̊a alla datorerdär Matlab är installerat. C-filer behöver däremot kompileras om för varjeplattform. Om de använder systemberoende bibliotek, för att exempelvisvisa grafik, måste de även skrivas om helt, vilket gör att de inte är flyttbara.Fördelen med C-filer är de exekverar betydligt snabbare än m-filer eftersomde kompileras och inte tolkas. Hur m-filer och C-MEX-filer ska utformasför att kunna styra en S-funktion beskrivs i detalj i manualen ”Writing S-

3.4 Möjliga verktyg för animering i Matlab/Simulink 11

functions” [7]. Den finns även att ladda hem i pdf-format fr̊an MathWorkswebbplats [13].

Figur 3.2. S-funktioner läggs in som vanliga block i Simulink och deras egenskaperbestäms av programmeraren.

3.4.2 Java

En tredje möjlighet är att skriva program i Java. I Matlab version 5.3 R11infördes ett experimentellt Java-gränssnitt, som till̊ater exekvering av Ja-va 1.1-kod direkt i Matlab. Matlab version 6.0 och senare har fullständigtstöd för Java-kod, men eftersom universitetet använde sig av den äldre ver-sionen när arbetet utfördes fick jag nöja mig med den experimentella, ochtämligen bristfälliga, implementeringen. Stödet fungerar endast under ope-rativsystemen Microsoft Windows och Sun Solaris. Koden kan skrivas i Mat-labs kommandofönster eller i m-filer, som p̊a vanligt sätt. Den kan bakas intillsammans med vanlig Matlab-kod. Syntaxen är dock inte identisk med hurden skrivs i vanliga Java-program. De flesta funktionsanrop och definitionerskrivs annorlunda. Bland annat kan man aldrig deklarera variabler. Typenska aldrig anges explicit vid en definition. Det finns inget kommando sommotsvarar import i Java, som gör att programmet kan hitta fördefinieradeklasser. Därför måste hela sökvägen skrivas ut när en klass ska användas.Dessutom är det möjligt att blanda Matlab-syntax med Java-syntax, vilketkan upplevas vara väldigt förvirrande. Om man exempelvis vill ange en ti-telsträng för ett fönster kan man skriva det p̊a Java-vis

frame = java.awt.Frame;

frame.setTitle(’Ett fönster’);

eller med Matlabs syntax

frame = java.awt.Frame;

setTitle(frame, ’Ett fönster’);


Alla textsträngar ska vara omgärdade av apostrofer, i stället för cita-tionstecken som brukligt är i Java. Mer information om hur Java fungerari Matlab 5.3 R11 f̊ar man om man skriver help java i Matlabs komman-dofönster.

Den största bristen är dock att man inte kan definiera egna funktioneroch klasser direkt i Matlab. Därför blir det i princip meningslöst att läggain Java-kod i m-filer. De program som man kan skapa enbart med hjälp avstandardklasserna och helt utan egna funktioner är i princip oanvändbara.Det g̊ar att skriva och kompilera egna Java-klasser och anropa dessa fr̊anm-filer. För att detta ska fungera krävs emellertid att sökvägen till den ka-talog där klasserna finns anges i en fil med namnet classpath.txt, somligger i Matlabs rotkatalog. P̊a en vanlig persondator är detta inget pro-blem eftersom filen enkelt kan redigeras. P̊a ett nätverk liknande det vidISY ligger dock filen centralt i Matlab-installationen, och studenterna sak-nar skrivrättighet till den. Därför blir användandet av kombinerad Matlab-och Java-kod komplicerat.

Den smidigaste lösningen är att skriva program i ”ren” Java-kod ochkompilera dessa. Programmet kan sedan startas direkt fr̊an en m-fil genomatt exekvera ett vanligt terminalkommando, vilket åstadkoms genom attmarkera detta med ett utropstecken före kommandot. Därmed tappar viegentligen kopplingen till Matlab. Programmet kommer att exekveras heltseparat fr̊an Matlab och Simulink, men kan allts̊a startas i samband medatt en simulering börjar. Användaren kommer inte att märka n̊agon skill-nad mot om koden skulle vara inbakad i m-filer. Däremot är det inte möjligtatt dela variabler eller använda gemensamma parametrar vid funktionsan-rop. Därför måste all gemensam data överföras till datafiler innan Java-programmet kan använda dessa.

3.4.3 Java 3D

Eftersom Matlab kan starta Java-program g̊ar det även att använda API:tJava 3D, när detta är installerat p̊a det aktuella systemet. Java 3D inneh̊alleren mängd klasser för att enkelt kunna lägga till tredimensionella objektoch animera dem. Det är förh̊allandevis enkelt att lära och använda förprogrammeraren. Därför är det ett mycket intressant alternativ till C-MEX-filer när det gäller tredimensionell programmering.

3.5 Möjligheter i Matlab 6.0 R12 13

Matlab/Simulink

Java-program

java Animation

save load

Figur 3.3. För animeringar skrivna i Java är det lämpligast att spara all data p̊atextfiler fr̊an Matlab, och sedan exekvera ett separat Java-program.

3.5 Möjligheter i Matlab 6.0 R12

I Matlab 6.0 R12, som lanserades under hösten 2000, är stödet för Java-kod rejält utökat. Dessutom finns möjligheten att skriva MEX-filer, medfunktioner som kan anropas av Matlab, i Fortran. Konsultera [10] för merinformation. Eftersom vi endast hade tillg̊ang till Matlab 5.3 R11, s̊a vardessa möjligheter inte aktuella.

3.6 Val av programspr̊ak

Eftersom vi ville knyta animeringarna till Matlab beslutade vi att skri-va all kod direkt i Matlab, i den mån det var möjligt. För mer krävandetillämpningar, vilket i första hand avs̊ag tredimensionella animeringar, släpp-te vi kravet p̊a integration med Matlab, och valde Java 3D eftersom det ärplattformsoberoende. Det sistnämnda var skälet till att vi strök möjlighetenatt skriva program som C-MEX-filer, eftersom dessa inte kan användas p̊aalla plattformar utan att skrivas och kompileras om.

– – –

14 4 Animering i Matlab

4 Animering i Matlab

4.1 Bakgrund och fr̊ageställningar

Jag började med att undersöka vilka möjligheter som fanns att skapa ani-meringar med Matlabs eget programspr̊ak. Det g̊ar att skapa förh̊allandevisavancerad grafik med Matlab, men det stora fr̊agetecknet var huruvida pre-standa skulle mäkta med komplexa animeringar. Därför var ribban när detgällde grafiska finesser l̊agt lagd. Jag inriktade mig p̊a en modell som visser-ligen skulle kunna animeras i tre dimensioner p̊a ett effektfullt sätt, men därtv̊a dimensioner änd̊a var fullt tillräckliga för att visa systemets uppförande,i fall prestanda skulle lägga hinder i vägen.

4.2 Systembeskrivning

Till grund för animeringen ligger ett tanksystem best̊aende av fyra vat-tentankar. Figur 4.4 visar en schematisk skiss över systemet. Tankarna ärupphängda i ett rektangulärt mönster, där tv̊a tankar hänger över de bäggeundre. Tv̊a pumpar förser tankarna med vatten. Den vänstra pumpen ärkopplad till tank 1 och 4, den högra till tank 2 och 3. Med en ventil g̊ardet att ställa in hur stor andel av vattnet som ska flöda till vardera tank. Ibotten av varje tank finns ett cirkulärt h̊al, genom vilket vattnet rinner nedtill tanken under eller till uppsamlingskärlet längst ned.

Systemet härstammar fr̊an en laborationsprocess som utvecklats vidTekniska Högskolan i Lund [5]. Processen är relativt l̊angsam och är därförlämplig att animera eftersom hastigheten d̊a kan ändras. Dessutom har sy-stemet flera intressanta reglertekniska egenskaper, som gör att den passarbra i undervisningssammanhang.

4.2.1 Systemekvationer

Insignalerna till systemet är de elektriska spänningarna över pumparna. Ut-signalerna är vattenniv̊aerna i de nedre tankarna. Allts̊a har vi tv̊a insignaleroch tv̊a utsignaler.

L̊at vi beteckna insignalerna och vattenniv̊aerna hi beteckna v̊ara fyratillst̊and. Tankarnas proportioner och övriga systemkoefficienter st̊ar i tabell4.1 respektive 4.2. Systemet kan d̊a, enligt [4], beskrivas p̊a tillst̊andsform

4.2 Systembeskrivning 15

h 3

h 1y 1v1

h 4

h 2y 2 v2

Figur 4.4. Skiss över tanksystemet. Tv̊a pumpar förser tankarna med vatten.V̊ara utsignaler är vattenniv̊aerna h1 och h2. Med ventilernas inställningar kan ettnollställe flyttas till höger halvplan.

Ai – bottenarea för tank i ai – utloppsarea för tank ikc – omvandlingskonstant för niv̊agivare g – gravitationskonstantki – förstärkningar i pumpar γi – ventilinställningar

Tabell 4.1. Systemkoefficienter

av

ḣ1 = −a1A1

√2gh1 +

a3A1

√2gh3 +

γ1k1A1

v1 (4.1)

ḣ2 = −a2A2

√2gh2 +

a4A2

√2gh4 +

γ2k2A2

v2 (4.2)

ḣ3 = −a3A3

√2gh3 +

(1− γ2)k2A3

v2 (4.3)

ḣ4 = −a4A4

√2gh4 +

(1− γ1)k1A4

v1 (4.4)

y =[kc 0 0 00 kc 0 0

]h (4.5)

Värt att notera är att botten- och utloppsareorna inte är desamma för allatankar. De vänstra är mindre och har större utloppsh̊al än de till höger.


A1, A3 [cm2] 28A2, A3 [cm2] 32a1, a3 [cm2] 0.071a2, a4 [cm2] 0.057k1 [cm3/Vs] 3.33k2 [cm3/Vs] 3.35kc [V/cm] 1.0g [cm/s2] 981

Tabell 4.2. Mätvärden för systemkoefficienter.

4.2.2 Linjärisering

För varje inställning av systemets parametrar kan vi i allmänhet linjäriseramodellen kring jämviktspunkten. Resultatet kommer att vara giltigt förmindre höjdförändringar kring dessa värden. Vi sätter systemparametrar-na till fixa värden och väljer därefter niv̊aer i tv̊a av tankarna, vilka skamotsvara jämvikt. Vattenniv̊aerna i de övriga tankarna och storlekarnap̊a insignalerna som ska ge upphov till denna jämviktspunkt kan sedanberäknas. Vi väljer tillst̊and xi som avvikelsen mellan jämviktsniv̊a ochaktuell niv̊a, xi = hi − h0i . Insignalerna ui blir p̊a samma sätt avvikelsenfr̊an de signaler som ger upphov till jämvikt, ui = vi − v0i . En linjäriseradtillst̊andsrepresentation ges d̊a av

ẋ =

− 1T1 0

A3A1T3

00 − 1T2 0

A4A2T4

0 0 − 1T3 00 0 0 − 1T4

x+−γ1k1A1 0

0 γ2k2A20 (1−γ2)k2A3

(1−γ1)k1

A4 0

u (4.6)y =

[kc 0 0 00 kc 0 0

]x (4.7)

där konstanterna Ti är

Ti =Aiai

√2h0ig, i = 1, ... , 4.

Motsvarande överföringsmatris ges av uttrycket G(s) = C(sI −A)−1B+Doch blir

G(s) =

[γ1c1

1+sT1

(1−γ2)c1(1+sT3)(1+sT1)

(1−γ1)c2(1+sT4)(1+sT2)

γ2c21+sT2

](4.8)


där c1 = T1k1kc/A1 och c2 = T2k2kc/A2.Eftersom tv̊a vattenniv̊aer beräknas utifr̊an hur övriga systemet väljs,

krävs att dessa niv̊aer hamnar inom tankarnas fysiska gränser för att enlinjärisering ska vara möjlig att finna. Ogenomtänkta val kan leda till attniv̊aerna blir lägre än noll eller högre än tankarnas höjd. Höjden beror na-turligtvis p̊a tankarnas proportioner och utformning. I animeringen är detmaximala niv̊avärdet satt till 240 cm (vilket dessvärre ger upphov till orim-liga tankproportioner, jag återkommer till detta problem i kapitel 4.4.7.)

4.2.3 Reglertekniska aspekter

Systemet har ett flertal intressanta egenskaper, med vars hjälp det g̊ar attutföra en mängd givande experiment. En kanske n̊agot förv̊anande egenskapär att systemets nollställen f̊ar drastiskt förändrade positioner beroende p̊ahur ventilerna är inställda. I fall bägge ventiler har stora värden, vilket in-nebär att merparten av det vatten som pumpas upp flödar till tank 1 respek-tive tank 2, kommer bägge nollställena befinna sig till vänster om imaginäraaxeln i s-planet. Om summan av ventilernas värden däremot understigervärdet 1, kommer ett nollställe att flytta sig över till det högra halvpla-net, vilket ger upphov till ett icke-minfassystem med markant försämraderegleregenskaper.

Om vi utg̊ar fr̊an den linjäriserade överföringsmatrisen G(s) i (4.8), gessystemets nollställen av matrisens determinant

detG(s) =c1c2

γ1γ2∏4i=1(1 + sTi)

((1 + sT3)(1 + sT4)− (1−γ1)(1−γ2)γ1γ2

).

Undersöker vi uttrycket närmare finner vi att systemet har tv̊a unika ochbegränsade nollställen för varje ventilinställning, där γ1, γ2 ∈ [0, 1]. L̊atoss införa parametern η = (1 − γ1)(1 − γ2)/γ1γ2, vilken kan anta värdeni intervallet η ∈ [0,∞[. För små η kommer nollställena att hamna närapunkterna −1/T3 respektive −1/T4. När η →∞ kommer ena nollstället attflytta sig längs reella axeln mot −∞, medan det andra p̊a samma sätt flyttarsig mot +∞. För η = 1 kommer ett nollställe att vara placerat i origo, ochdet motsvarar överg̊angsvärdet γ1 + γ2 = 1. S̊aledes erh̊aller vi ett icke-minfassystem för 0 < γ1 + γ2 < 1 medan vi f̊ar ett trevligare minfassystemför 1 < γ1 + γ2 < 2.

Förutom nollställenas positioner kan det dessutom vara intressant attundersöka vilka utsignaler som p̊averkas mest av systemets icke-minfas-uppförande. Därför betraktar vi nollställenas riktningar genom att beräkna


vilka utsignalsvektorer som nollställer systemet, det vill säga vilka vekto-rer ψ ∈ R2 som gör att ψTG(z) = 0, där z betecknar det nollställe viundersöker. Om ψ blir parallell med en enhetsvektor kommer systemetsuppförande bara att sl̊a igenom p̊a en av utsignalerna. Ett nollställe i högerhalvplan behöver allts̊a inte ha lika stor genomslagskraft i ett flervariabeltsystem som i ett skalärt. Blir vektorns bägge element nollskilda kommerdäremot icke-minfasbeteendet vara synbart p̊a b̊ada utsignalerna.

Med den linjäriserade överföringsfunktionen G(s) f̊ar vi[ψ1ψ2

]T [ γ1c11+zT1

(1−γ2)c1(1+zT3)(1+zT1)

(1−γ1)c2(1+zT4)(1+zT2)

(1−γ2)c21+zT2

]=[00

]TAv ekvationen följer att ψ1, ψ2 6= 0. Vi kan allts̊a aldrig erh̊alla en skaladenhetsvektor, oavsett vilka koefficienter vi väljer. Om vi löser ekvationenåterst̊ar efter förenkling

ψ1ψ2

= −1− γ1γ1

c2(1 + zT1)c1(1 + zT4)(1 + zT2)

.

Fr̊an denna ekvation g̊ar det att dra slutsatsen att l̊aga värden p̊a γ1 germest utslag p̊a den första utsignalen. P̊a motsvarande sätt syns l̊aga värdenp̊a γ2 mest p̊a den andra utsignalen. Om vi har ett icke-minfassystem gerallts̊a det relativa storleksförh̊allandet mellan γ1 och γ2 en vink om vilkenutsignal som är mest utsatt för icke-minfasbeteendet.

Fler systemegenskaper och närmare beskrivningar finns i [4].

4.3 Användning i undervisningen

Vattentankanimeringen har använts i datorlektioner i kurserna TSRT35Reglerteori Y samt TSRT38 Reglerteori I under hösten 2000. Filerna har le-gat centralt i Matlabs rotbibliotek och gjorts tillgängliga för studenterna närde aktiverat kurserna i ISY:s datorsalar. Dessutom har de varit tillgängligaför nedladdning fr̊an kurshemsidorna.

De bägge kurserna har n̊agot olika inneh̊all. Y-kursen är mer omfat-tande och inneh̊aller fler moment än I-kursen. Därför har den förstnämndaäven inneh̊allit fler lektioner och fler uppgifter. Lektionshandledningen tillY-kursen inneh̊aller, förutom en beskrivning av systemet och en kort ge-nomg̊ang av användbara Matlab-kommandon, sammanlagt tolv uppgifterfördelade p̊a fyra lektionstillfällen:

• Lektion 1. Fyra uppgifter arbetas igenom. Syftet är i huvudsakatt lära känna systemet och studera vilka egenskaper det har. Först

4.3 Användning i undervisningen 19

ändras arbetspunkten genom att ändra insignalernas amplitud. Detlinjäriserade systemets poler och nollställen jämförs.

I den andra uppgiften h̊alls arbetspunkten konstant medan ventiler-nas inställningar varieras. Som nämndes i kapitel 4.2.3 hamnar ettnollställe i höger halvplan när γ1 + γ2 < 1. Studenterna jämför poler,nollställen och singulära värden i de olika fallen.

Därefter undersöks effekterna av insignalvektorns riktning. Den linjär-iserade överföringsfunktionen G(s) (4.8) beräknas för en viss arbets-punkt och ventilinställning. Insignalsvektorn väljs utifr̊an egenvärdenaoch egenvektorerna till G(0), det vill säga för ω = 0.

Slutligen verifieras att man faktiskt kan f̊a en stabil utsignal trotsatt man lägger p̊a en exponentiellt växande insignal. Om vi antaratt den linjäriserade överföringsfunktionen G(s) har ett nollställe i z,kan vi hitta en vektor u0 s̊a att G(z)u0 = 0. Om vi väljer insignalenu(t) = u0ezt blir

y(t) = G(z)u0 + transienter = 0 + transienter.

För ett minfassystem, som har alla nollställen i vänster halvplan, kom-mer u(t) att vara exponentiellt avtagande. Men för ett icke-minfassys-tem kan vi allts̊a f̊a en exponentiellt växande insignal som änd̊a f̊ar ut-signalen att bli noll. Eftersom systemet i praktiken är olinjärt stämmerdock inte detta resultat helt.

• Lektion 2 handlar om observatörer och korskopplingar. Vattenniv̊a-erna i de undre tankarna är v̊ara utsignaler, och vi vill skatta niv̊aernai de övre tankarna med en observatör. P̊a vanligt vis använder vi v̊artillst̊andsmodell och återkopplar beräkningsfelet:

d

dtx̂ = Ax̂+Bu+K(y − Cx̂)

där x̂, u och y betecknar avvikelsen fr̊an jämviktsniv̊aerna.

I den första uppgiften prövar vi att välja återkopplingskonstanten Kmanuellt genom att t ex placera observatörens egenvärden, vilka gesav egenvärdena till A − KC. I den följande uppgiften använder vi istället ett kalmanfilter för att beräkna ett optimalt K, som minimerarfelens kovariansmatris. För att utvärdera prestanda lägger vi p̊a b̊adesystem- och insignalsbrus.


Som tredje uppgift undersöker vi hur h̊art insignalerna är koppla-de med utsignalerna genom att beräkna RGA. Vi prövar olika ven-tilinställningar. En insignal kopplas ihop med en utsignal och varjekrets regleras med var sin PID-regulator.

• I lektion 3 ska en regulator tas fram genom minimering av kvadratiskakriterier. I den första uppgiften antar vi att alla vattenniv̊aer kanmätas. Därmed kan vi använda en ren tillst̊ands̊aterkoppling, som f̊arformen

u = L(x)− L0(r − y)

där u, x och y är avvikelsen fr̊an jämvikt. L är s̊aledes återkopplingenför tillst̊anden, medan L0 är framkopplingen för referenssignalen. Vivill bestämma

min∫eT (t)Q1e(t) + uT (t)Q2u(t) dt.

där Q1 och Q2 är v̊ara straffmatriser och reglerfelet e = y−r. Storlekenp̊a Q1 avgör hur snabbt reglerfelet avtar, och Q2 sätter gränser förinsignalernas amplituder.

I den andra uppgiften antar vi att endast de undre tankniv̊aerna mäts,och att de övre måste skattas med en observatör. Återkopplingsmat-riserna L och L0 beräknas som tidigare med linjärkvadratisk teori.Observatörs̊aterkopplingen K bestäms med kalmanfilter.

• Lektion 4 behandlar ett urartat fall. Vi väljer ventilinställningenγ1 = γ2 = 0, vilket medför att allt vatten flödar till de övre tankarna.Som utsignaler väljs vattenniv̊aerna i de vänstra tankarna, h1 och h3.Därmed f̊ar vi ett envariabelt system som bara beror p̊a u2.

Uppgifterna g̊ar ut p̊a att jämföra exakt linjärisering med vanlig linjäråterkoppling. Som krav ställer vi att polerna för det slutna systemetska hamna i −0.01 och −0.015, samt att den statiska förstärkningenmellan referenssignal och niv̊an i tank 1 blir 1.

För kursen TSRT38 Reglerteori I har uppgifterna ett n̊agot annorlundainneh̊all. Lektion 2 och 4 har tagits bort och i stället ersatts med tv̊a andrauppgifter, som syftar till att statiskt frikoppla systemet genom att multi-plicera med en konstant matris, samt att reglera tankarna med en diagonalregulator. Som avslutning ska man undersöka effekten av bägge delarna –en diagonal regulator för ett statiskt frikopplat system.

4.4 Implementering 21

4.4 Implementering

4.4.1 Matlabs programspr̊ak

Det vanligaste sättet att använda Matlab är att skriva kommandon direkt iprogrammets kommandofönster. De evalueras d̊a direkt och resultatet dykerupp p̊a raden nedanför. För att underlätta arbetet finns det även möjlighetatt definiera funktioner och skriva listor med kommandon i separata textfi-ler, och sedan anropa dessa fr̊an kommandofönstret. Dessa filer ska namngesmed ändelsen m, och kommer fortsättningsvis att kallas för m-filer.

En m-fil som definierar funktioner f̊ar i allmänhet enbart best̊a av en endafunktionsdefinition och inga övriga kommandon. Namnet p̊a filen ska varadetsamma som funktionsnamnet. När filen sparats kan funktionen användasdirekt i Matlabs kommandofönster, eller i övriga m-filer. De variabler somskapas i funktionen är lokala och därmed o̊atkomliga fr̊an workspace. Dockfinns möjligheten att deklarera globala variabler som kan användas gemen-samt av flera funktioner.

En m-fil som inneh̊aller listor med kommandon f̊ar inte inneh̊alla n̊agrafunktionsdefinitioner alls. När filens namn skrivs i kommandofönstret kom-mer filen att exekveras rad för rad. I Matlab finns de vanligaste program-strukturerna, som exempelvis villkorliga hopp och programloopar, vilket gördet möjligt att bygga upp filen som ett vanligt program.

Matlab inneh̊aller färdiga klasser för grafiska komponenter. Dessutomfinns verktyg med vilka man kan rita upp fönster med knappar, textrutor ochrullister med mera utan att behöva koda en rad själv. För att fönstret sedanska fungera och de grafiska komponenterna f̊a n̊agra funktioner krävs attman skriver lyssnarfunktioner, som anropas när användaren interagerar medfönstret. Mer information om hur man utvecklar grafiska användargränssnittfinns i manualen ”Creating Graphical User Interfaces” [9].

Den grafik man kommer i kontakt med i Matlab är vanligtvis att plottafunktioner, och alla dessa dyker upp i figurfönster med skalade axlar. Menförutom funktioner för att plotta tv̊a- och tredimensionella grafer av olikaslag finns även ett antal andra grafikfunktioner. Axlarna g̊ar att ta bort fr̊anfönstret s̊a att vi f̊ar en ren yta. Linjer kan ritas och ytor fyllas med färgmed enkla funktioner. Dessutom g̊ar det att definiera tredimensionella po-lygonmodeller och visualisera dessa med olika ljussättningar. Vanliga bilderi diverse olika filformat kan även läsas in, manipuleras och visas i fönstret.Men trots dessa funktioner är Matlab inte lämpligt för grafisk programme-ring. Anledningen är enkel – prestanda är alldeles för d̊alig i jämförelse medvanliga programspr̊ak, vilket bland annat beror p̊a att Matlab använder sig


av tolkning i stället för att kompilera programmen.De grafiska funktionerna i Matlab finns närmare beskrivna i ”Using Mat-

lab Graphics” [8].

4.4.2 Filförteckning

Programmet best̊ar av tv̊a separata delar – en som skapar själva anime-ringen och en som sköter det grafiska gränssnittet. De här delarna är iprincip oberoende av varandra. Animeringen kan köras utan att det grafis-ka gränssnittet aktiverats. Det förutsätts enbart att de variabler som ing̊ari Simulink-modellen finns definierade i Matlabs workspace. Det enda detgrafiska gränssnittet utför är att definiera alla variabler som behövs för si-muleringen och animeringen globalt, samt de som behövs vid det fortsattaberäkningsarbetet. Dessutom erbjuder det ett enkelt och översk̊adligt sättatt ändra dessa värden.

De filer som ing̊ar i animeringspaketet är

• watertanks.mdl. Simulink-modellen som beskriver tanksystemet.

• tanks.m. Programfil som skapar animeringen. Är uppbyggd enligtprinciperna för en S-funktion och anropas av Simulink i enlighet meddet S-funktionsblock som ing̊ar i Simulink-modellen.

• background.m. Definierar bakgrundgeometrierna, vilket inkluderarall grafik utom texter och vattenniv̊aer.

• parameters.m. Visar det grafiska gränssnittet, vilket best̊ar av ettfönster inneh̊allande alla systemkoefficienter och textrutor, tryckknap-par och rullister för att ändra dessa.

• guifcn.m. Funktionsfil som anropas när n̊agot värde ändras i para-meterfönstret. Fungerar som en lyssnare.

• tankequib.m. Beräknar jämviktsniv̊aerna för tankarna, givet niv̊a-erna i de övre tankarna. Med motsvarande amplitud p̊a insignalenundviker vi insvängningsförloppet.

4.4.3 Simulinkmodell

En ickelinjär modell skapades i Simulink och gavs namnet watertanks.mdl.Öppnar vi filen hittar vi ett modellblock med tv̊a insignaler, pumpspänning-arna, och fyra utsignaler, vattenniv̊aerna. Se figur 4.5. G̊ar vi ner en niv̊a


Figur 4.5. Simulink-filen watertanks.mdl. Det inringade blocket är v̊ar S-funktionsom skapar animeringen.

och tittar närmare p̊a modellblocket finner vi ännu ett modellblock kopplattill en S-funktion. S-funktionen har sex insignaler – samtliga insignaler ochvattenniv̊aer. Det nya modellblocket inneh̊aller en implementering av denickelinjära modellen. I integratorblocken har jag infört mättnadsvärden somgör att tankarnas vattenniv̊aer inte kan bli lägre än 0 eller högre än 240,vilket motsvarar tankarnas höjd.

4.4.4 Animeringsfönstret

Figur 4.6 visar en bild p̊a animeringsfönstret. Vattenniv̊aerna är utritade itankarna tillsammans med aktuella siffervärden. Fr̊an kranarna och tankar-nas utmynningsh̊al är vattenflöden utritade. En tjockare linje tyder p̊a ettkraftigt flöde medan en smalare tyder p̊a ett mindre. I närheten av venti-lerna finns procenttal som anger vattenfördelningen till varje kran. Längstned p̊a fönstret finns tv̊a grafer, som plottar insignalerna.

4.4.5 Grafiskt gränssnitt för inställning av parametrar

Parameterfönstret inneh̊aller de parametrar som används i animeringen. Devattenniv̊aer i de övre tankarna kring vilka vi vill linjärisera sätts med para-


Figur 4.6. Animeringsfönstret för vattentankanimeringen. Insignalerna, d v sspänningen över pumparna, plottas i fönstrets nedre del.

metrarna h3 och h4. De gr̊amarkerade fälten visar systemkoefficienter sominte bör ändras, vilket omfattar tankarnas dimensioner och systemkonstan-ter. g1 och g2 motsvarar ventilernas inställningar γ1 och γ2. De kan antavärden mellan 0 och 1. Animation speed anger hur ofta animeringen skauppdateras, men den ändrar inte den hastighet med vilken animeringen ritasut p̊a skärmen, vilket man kan förledas att tro.

För att ändringar ska ge verkan krävs att knappen Apply trycks in. Vid


Figur 4.7. Parameterfönstret för vattentankmodellen. De gr̊amarkerade fälten in-neh̊aller systemkonstanter som inte kan ändras.

varje ändring, samt när fönstret öppnas, trillar det dessutom ut matriser fördet linjäriserade systemet. De har namnen A, B, C och D, och är åtkomligafr̊an Matlabs workspace. Även de övriga systemvariablerna är åtkomligadärifr̊an, men jag rekommenderar att man aldrig ändrar dem direkt fr̊anMatlabs kommandofönster utan alltid g̊ar vägen via parameterfönstret, närs̊a är möjligt. Förändringarna kommer annars inte att synas i fönstret, vilketlätt kan ge upphov till förvirring.

4.4.6 Animering

När vi startar simuleringen i Simulink kommer koden som styr S-funktionenatt exekveras vid varje uppdateringstillfälle. En flagga talar om i vilket till-st̊and systemet befinner sig vid varje anrop. Första g̊angen koden exekve-ras sker ett initieringsförlopp som definierar diverse globala variabler sombehövs senare, sätter antalet in- och utsignaler till S-funktionen samt öppnaranimeringsfönstret.

Vid varje sampelsteg i fortsättningen kommer i princip samma sak attuträttas. Första steget är att radera hela animeringsfönstret och rita bak-grundsgrafiken p̊a nytt, vilket inkluderar allt förutom vattenniv̊aer och text-strängar. Därefter fylls tankarna med vatten, vilkas niv̊aer ges av S-funktion-ens insignaler, och det vatten som flödar fr̊an kranarna och genom tankarnasbottenh̊al ritas ut. Niv̊aerna skrivs även ut med siffror i vardera tanks ned-re högra hörn, och den aktuella ventilinställningen skrivs ut i procentform


Figur 4.8. Dataflödet i vattentankanimeringen. När användaren ändrar värdenai parameterfönstret sätts dessa variabler i Matlabs workspace. När simuleringenstartas i Simulink startar även animeringen.

intill kranarna. Slutligen uppdateras graferna över pumpspänningarna medytterligare ett steg. Programmets uppbyggnad och kod beskrivs närmare idetalj i bilaga A.

Animeringshastigheten g̊ar att ändra i parameterfönstret via en rullistoch anger vid vilka tidstillfällen fönstret ska uppdateras. När den antar sittlägsta värde, som är 1 även om värdet inte är synligt i parameterfönstret,ritas fönstret om vid varje sampeltidpunkt. Det högsta värdet är 1 000och ger endast en uppdatering vart tusende sampel. Detta medför att ani-meringen g̊ar snabbare i rent systemmässigt hänseende, eftersom inte allasampelvärden ritas ut p̊a skärmen. Däremot är det viktigt att komma ih̊agatt själva animeringen inte g̊ar snabbare. Grafiken ritas alltid i samma takt.

När animeringshastigheten ändras kommer även tidsskalan för insignals-graferna att skalas om s̊a att ett uppdateringssteg motsvarar en bildpunktp̊a skärmen. Om hastigheten ändras under animeringens g̊ang kommer dockdenna omskalning att äga rum först när tiden passerar grafernas bortregräns. D̊a flyttas graferna ett halvt intervall åt vänster och d̊a äger ävenskalningen rum.

Animeringen använder sig av OpenGL för att rita grafiken. I Windows


är OpenGL inbyggt i operativsystemet sedan Windows 95 OSR2. OpenGLföljer med Matlab, och används i de fall det saknas p̊a systemet.

4.4.7 Problem

Eftersom animeringen är skriven i Matlabs eget programspr̊ak borde det g̊aatt köra programmet p̊a alla datorer där Matlab är installerat. Dock finnsvissa skillnader mellan hur OpenGL uppför sig med den implementeringsom inkluderas i Matlab och den som till exempel finns inbyggd i Windows,vilket gör att programmet uppför sig olika p̊a en PC jämfört med i Unix. Fördet första blir alla färger markant blekare i Unix. Allvarligare är dock att endel grafik kastas om och ritas ut i olika ordning. När animeringen anpassatsför PC, ritas kantlinjerna ut innan geometrin fylls med färg, vilket ledertill att linjer försvinner och att delar av grafiken skymmer andra bitar. Omanimeringen anpassas för Unix uppst̊ar p̊a motsvarande sätt samma problemnär filen körs p̊a en PC. Det här g̊ar att komma runt om man i stället förOpenGL använder Matlabs vanliga grafikfunktioner. Priset vi f̊ar betala äratt animeringen blir l̊angsammare. Mer om detta följer i bilaga A.

De proportioner som tankarna ser ut att ha p̊a skärmen stämmer intealls överens med de verkliga värdena. Bottenareorna är runt 30 cm2 stora,medan höjden är helt orimliga 240 cm. Vi tog ingen notis om höjden till enbörjan utan lät den motsvara antalet bildpunkter p̊a skärmen. Lektionsupp-gifterna hade arbetats fram med den här inställningen och därför ans̊ag viinte det vara lönt att ändra den i efterhand. Det är först̊as en enkel sak attändra tankhöjden – det enda som behöver göras är att skala vattenniv̊aernai animeringen och ändra mättnadsgränserna för integratorerna i modellen.

Det är möjligt att ändra systemvariabler under animeringens exekvering.Det bör dock aldrig göras. Enda undantaget utgör animeringshastigheten,som kan ändras när som helst utan att systemet p̊averkas. Alla variablersom används av systemet är globala, och åtkomliga b̊ade fr̊an Matlabs kom-mandofönster och av Simulink. Simulink läser dock endast in variablernaen g̊ang och det sker när simuleringen startar. Om värdena ändras kommerdetta inte att p̊averka simuleringen, men däremot kommer förändringarnaatt sl̊a igenom i animeringen. Flödena fr̊an kranar och tankar, och grafernaöver insignalerna kommer att ändras. Men vattenniv̊aerna, som baseras p̊asystemets tillst̊and och tas fr̊an Simulink, bygger p̊a de gamla värdena.

P̊a vissa datorer är det problem med programmets stabilitet. När ani-meringsfönstrets storlek förändras, eller om det flyttas p̊a skärmen, kan detleda till det föga önskvärda resultatet segmentation fault, varvid Matlabomedelbart avslutas. Det här problemet beror dock med största sannolikhet


inte p̊a programfilerna, utan har sitt ursprung i programfel i vissa versionerav Matlab.

Varje g̊ang ny grafik ritas i animeringsfönstret blir fönstret aktiveratoch lägger sig därmed över de andra p̊a skärmen. P̊a en mindre bildskärmkan det leda till att animeringen skymmer andra fönster som därmed blirsv̊ara att komma åt. Bland annat kan det bli problem med att komma åtstoppalternativet i Simulink för att avbryta simuleringen.

4.5 Diskussion och slutsatser

4.5.1 Undervisning

Animeringen med vattentankarna har använts i tre datorlektioner i kurser-na TSRT35 Reglerteori Y och TSRT38 Reglerteori I under hösten. V̊araslutsatser fr̊an undervisningen är att

• Animeringen ökar först̊aelsen för hur systemet beter sig, och ger entydlig bild över hur de olika tankarna och kranarna är sammankopp-lade.

• Grafiken är enkel och grovhuggen, men fyller änd̊a sin uppgift p̊a etttillfredsställande sätt.

• Animeringen är ganska l̊angsam. Som tidsmedveten student vill mangärna att allt ska g̊a s̊a fort som möjligt och därför har i princip alladragit upp animeringshastigheten till sitt maximala värde.

• Eftersom animeringen är l̊angsam kan det vara lämpligt kunna kopplabort den och enbart använda sig av simuleringen. Det g̊ar betydligtsnabbare och dessutom är animeringen inte lika nödvändig när stu-denten väl f̊att en klar bild över hur det fungerar. En smidig lösningkan t ex vara att lägga till en knapp i det grafiska gränssnittet medvilken man kan växla mellan animering och ren simulering.

• Animeringen gör uppgifterna lite roligare, vilket inte ska undervärderas.

• Systemet som ligger till grund för animeringen kan användas till enrad givande uppgifter, och kan i princip användas för att belysa nästanalla moment som ing̊ar i reglerteori-kurserna.

Över lag har animeringen varit ett uppskattat inslag i undervisningen.Grafiken är l̊angt ifr̊an tekniskt fulländad, men det spelar mindre roll ef-tersom tydligheten är betydligt viktigare.

4.5 Diskussion och slutsatser 29

4.5.2 Programmering

Att skriva grafiska program i Matlab är enkelt, om vi relaterar till vanligaprogramspr̊ak som Java eller C++. Ett grafiskt användargränssnitt snickrarman ihop p̊a n̊agra minuter med de verktyg som finns för detta. Däremotkan det bli problem om man vill göra ändringar i efterhand. Med verktygenkan man rita ut grafiska komponenter p̊a ett färdigt fönster, linjera dessaoch skriva korta lyssnarfunktioner som anropas när användaren interagerarmed komponenterna. Om man vill lägga till mer avancerade funktioner f̊arman däremot göra det för hand, och därmed har man bränt sina möjligheteratt använda verktygen i fortsättningen. Gör man en ändring till med dessakommer all kod man har skrivit själv att raderas.

Om vi g̊ar över till själva animeringen s̊a är även den enkel att skriva.Animeringen knyts till Simulink via S-funktioner och grundstommen fördenna best̊ar enbart av ett tiotal rader kod. Animeringen best̊ar i grundenenbart av ett figurfönster. För att rita grafiken behövs endast tv̊a funktioner,som ritar linjer och fyller ytor.

All information man behöver hittar man i princip i Matlabs manua-ler [7-10] som överlag är lättlästa och pedagogiska. De problem man stöterp̊a best̊ar till stor del av hur man sätter olika parametrar till program-mets objekt. P̊a MathWorks webbplats [13] finns en mycket användbarhjälpfunktion med vilken man kan söka efter funktions- och klassnamn ochf̊a listat alla parametrar etc som ing̊ar i dessa.

Matlab är l̊angt ifr̊an n̊agot optimalt utvecklingsverktyg. Den version jaganvände, 5.3.1.29215a (R11.1), var inte helt stabil vilket medförde att pro-grammet behövde startas om med jämna mellanrum. Den största nackdelenär emellertid dess mediokra prestanda. Grafiken i vattentanksanimeringenär mycket enkel, men mer komplex än s̊a bör inte animeringar vara för att deska g̊a att köra med tillfredsställande hastighet p̊a en ordinär persondator.Tredimensionella objekt är över huvud taget inte att tänka p̊a. Vi är allts̊abegränsade till enkla tv̊adimensionella animeringar, och därmed begränsasäven v̊ara val av system till s̊adana som kan presenteras p̊a ett tydligt sättmed denna enkla grafik.

– – –

30 5 Animering med Java 3D

5 Animering med Java 3D

Som ett exempel p̊a hur en tredimensionell animering kunde te sig valde viatt göra en animering av ett flygplan i Java 3D. I kursen TSRT35 Regler-teori Y ing̊ar sedan 1996 en datorlaboration som g̊ar ut p̊a att konstrueraen regulator för ett plan av typen JAS 39 Gripen. Regulatorn bestäms ge-nom H∞-optimering eller minimering av kvadratiska kriterier. Prestandautvärderas genom att betrakta plottade kurvor för känslighetsfunktioner.Laborationen fyller utan tvekan sin funktion, men en animering som visarhur planet uppför sig i luften skulle ge en bättre koppling till vilket systemsom man arbetar med. Animeringen tillför kanske inte s̊a mycket för opti-meringsarbetet, eftersom prestandaskillnader är allt för små för att kunnauttydas i en animering. Däremot kan studenterna f̊a vetskap om grova fel iregulatorstrukturen p̊a ett omedelbart sätt.

Modellen som ligger till grund för flygplanet är kraftigt förenklad. Mo-dellen är linjär och enbart tillämpbar inom vissa parameterintervall. Deninneh̊aller endast information om roll- och girvinkel, vilket medför att flyg-planet rör sig i ett horisontellt plan. Tippvinkel och hastighetens belopp ochriktning saknas.

Jag hade som mål att skapa en animering som först och främst uppfyllerde kriterier som gör att den kan användas i datorlaborationen. Men jag villeocks̊a utöka animeringen s̊a att den kunde användas för mer avancerademodeller, där alla viktiga variabler – som tippvinkel och hastighet – ingick.En doktorand vid ämnesomr̊adet arbetade med utveckling av reglersystemför flygplan och hade som önskemål att kunna använda animeringen i sittarbete.

5.1 Systembeskrivning

En tillst̊andsrepresentation för den modell som används i laborationen ärtill viss del beskriven i Glad & Ljung (1997) [11] p̊a sidan 46. Modellen harsju tillst̊and. Tv̊a av dessa best̊ar av de roll- och girvinklar vi använder ianimeringen. Rollvinkeln mäts som vinkeln mellan ett tänkt horisontalplanoch planet, se fig 5.9. En rotation motsols, när planet betraktas bakifr̊an,ger en ökning av rollvinkeln. Girvinkeln, eller kursvinkeln som den benämnsi boken, avser vinkeln mellan en fix kurslinje och den linje som pekar längsflygplanskroppen.


φ

ψvy

Figur 5.9. Vinklar för beräkning av flygplanets rörelse, för ett skrovfast system.

Vi väljer tillst̊and enligt

x1 = vy = hastigheten tvärs flygkroppen,x2 = p = rollvinkelhastigheten,x3 = r = girvinkelhastigheten,x4 = φ = rollvinkeln,x5 = ψ = girvinkeln,x6 = δa = skevroderutslaget,x7 = δr = sidoroderutslaget.

Insignalerna sätts till de kommenderade roderutslagen,

u1 = δcmda , u2 = δcmdr .

Viktigt att notera är att dessa vinklar inte överensstämmer med de verkligaroderutslagen, vilket beror p̊a dynamik i roderservona.

Med dessa tillst̊andsvariabler och insignaler kan en linjär tillst̊andsmodellställas upp. Siffrorna baseras p̊a ett flygfall med hastigheten Mach 0.6,höjden 500 meter och anfallsvinkeln 0.04 radianer.

ẋ = Ax+Buy = Cx+Du


där

A =

−0.292 8.13 −201 9.77 0 −12.5 17.1−0.152 −2.54 0.561 −0.0004 0 107 7.68

0 1 0.0401 0 0 0 00 0 1 0 0 0 00 0 0 0 0 −20 00 0 0 0 0 0 −20

(5.9)

B =

0 −2.15−31.7 0.0274

0 1.480 00 020 00 20

(5.10)

C =[0 0 0 1 0 0 00 0 0 0 1 0 0

](5.11)

D =[0 00 0

](5.12)

Denna linjärisering är enbart giltig för flygmanövrar där vinkeln mel-lan hastighetens riktning och flygplanskroppen är försumbar. Hastigheteni tvärsled, vy, ing̊ar visserligen i modellen, men vi tar inte hänsyn till dessvärde i animeringen utan förutsätter att flygplanet alltid rör sig i sammariktning som kroppen pekar åt.

5.2 Användning i undervisningen

Laborationen, i vilken modellen används, g̊ar ut p̊a att fram en regulatorsom uppfyller följande kriterier:

• Insignalerna, de kommenderade rodervinklarna, f̊ar under ett stegsvarinte överstiga beloppet 25 grader.

• Störningar med frekvenser under 0.001 rad/s p̊a utg̊angen ska dämpasminst 40 dB. Inga störningar f̊ar förstärkas mer än 6 dB.

• För frekvenser över 100 rad/s ska designen klara av modellfel p̊a enfaktor 104 utan att bli instabil.

• Stigtiden ska vara ca 1 s i rolled, och 10 s i girled.

5.2 Användning i undervisningen 33

Figur 5.10. I datorlaborationen används endast roll- och girvinklar. Animeringenkan dock användas även för fullständiga manövrar. α- och β är vinklarna mellanflygkropp och hastighetsvektor. Roll-, gir- och tippvinklar är däremot definieradeutifr̊an det globala koordinatsystemet, d v s gentemot en fix rak kurs.

I TSRT35 Reglerteori Y använder studenterna H∞-optimering alter-nativt en metod med namnet Glover-McFarlane för att uppn̊a målen. IReglerteori I används i stället linjärkvadratisk teori. Man har inte tillg̊angtil n̊agon Simulink-modell, utan utför allt arbete med de Matlab-funktionersom ing̊ar i Control System Toolbox.

Animeringen är skriven i Java 3D och i princip frist̊aende fr̊an Matlab.Den kan startas samtidigt som Simulink, men är enbart beroende av attdet finns textfiler inneh̊allande alla mätvärden som behövs för de olika va-riablerna för att kunna visa en animering. Det finns inga krav p̊a hur dessafiler skapats eller vilken modell som ligger till grund för resultatet. Det endasom krävs är att filerna är skrivna i rätt format, vilket beskrivs närmare ikapitel 5.3.5.

Detta medför att programmets användningsomr̊ade är väldigt flexibelt.Det ska som nämnts i första hand användas för den befintliga laboration soming̊ar i kursen TSRT35 Reglerteori Y, men kan användas för att visa vilkenflygplansmanöver som helst, vid laborationer, lektioner eller presentationer.Det flygplan som visas i animeringen är en amerikansk F16, men även denkan bytas ut mot en annan 3D-modell p̊a ett enkelt sätt om det plan somska visas skiljer sig kraftigt.


5.3 Implementering

5.3.1 Java 3D

Java 3D är ett tillägg till Java, som behöver vara installerat p̊a systemetb̊ade om man vill utveckla program själv eller enbart köra befintliga pro-gram. Java 3D är i likhet med Java gratis att ladda hem, och kan hit-tas p̊a Suns officiella Java-sida p̊a adressen www.sun.com/desktop/java3d.För att programmen ska kunna startas krävs naturligtvis även en Java-installation. Den senaste versionen heter Java 2 Platform, Standard Edition,v 1.2 (J2SE). Den kan endast användas för att köra befintliga program. Enmer komplett installation för utveckling är Java 2 SDK, Standard Edition, v1.2 (J2SDK). Filer för nedladdning och mer information finns p̊a webbsidanjava.sun.com/products.

Java är ett helt igenom objektorienterat spr̊ak och följaktligen best̊ar Ja-va 3D av fördefinierade klasser, förpackade i tv̊a packages – javax.media.j3d och javax.vecmath. Den förstnämnda inneh̊aller ett hundratal klas-ser för att bygga ett tredimensionellt program, medan den sistnämnda in-neh̊aller matematiska strukturer som beskriver vektorer, rotationer etc. Var-je komponent som ing̊ar i animeringen, eller visualiseringen eftersom rörelseinte behöver ing̊a, är uppbyggt av var sitt klassobjekt. En geometri är s̊aledesdefinierad av en separat klass, dess position i rymden av en annan och blick-punkten fr̊an vilken landskapet betraktas av en tredje. Dessa objekt byggeri sin tur upp en trädstruktur, vilken beskriver hur föremålen är placerade iförh̊allande till varandra, hur de rör sig etc. Ett dokument som g̊ar igenomgrunderna i Java 3D är Bouvier (1999) [1], som dock inte tar upp alla delarsom ing̊ar i Java 3D utan mer är sedd som en kom-ig̊ang-hjälp för nybörjare.Den täcker änd̊a alla viktiga bitar som krävs för att skapa en animering. Enmer fyllig specifikation, b̊ade i ordets bildliga och bokstavliga bemärkelser,är ”The Java 3D API Specification” [3]. Den är emellertid över 650 sidorl̊ang och relativt tungläst. Alla klasser som ing̊ar i Java 3D finns beskrivnai ett html-bibliotek [4]. En kortare beskrivning av Java 3D finns i bilaga Bi denna rapport.

5.3.2 Animeringens uppbyggnad

Eftersom animeringen i främsta hand ska användas för rörelser i horison-talplanet valdes den enklaste lösningen för att åstadkomma detta. System-modellen har ingen höjdangivelse och därför kan vi anta att planet befinnersig p̊a en fix höjd. Vi slipper de problem som dyker upp när planet dykernärmare marken och vid misslyckade regleringar passerar markplanet. Vi-


dare kan vi representera himlen med ett matematiskt plan klädd med entextur. Flygplanet kan inte stiga och därmed undviker vi problem där planetpasserar molnbankarna.

Det mest rättframma upplägget är att l̊ata planet röra sig i en fix ochstillast̊aende omgivning. Om vi vill ha en bakgrundsvy måste kameran i s̊afall följa tätt efter planet och ha samma rörelsemönster. En enklare lösningär helt enkelt att l̊ata b̊ade flygplan och kamera vara fixa, och att i ställetröra omgivningen. Kameran kommer därmed vara helt stillast̊aende. Flyg-planet kommer att rotera när det rollar och girar, men i övrigt vara fixtplacerat i origo. Marken och himlen kommer däremot att animeras med detmotsatta rörelseschemat som hade gällt för flygplanet.

Figur 5.11. Animeringens uppbyggnad. Förutom mark- och himmelplan löperrunt flygplanet en cylinder som visar horisonten.

Animeringens uppbyggnad visas i figur 5.11. Flygplanet omges i verti-kal riktning av ett markplan och ett himmelplan. B̊ada kläs med texturerföreställande gräs respektive molnbankar. Det ger ett mer verklighetstro-get utseende än att bara använda konstanta färger. Dessutom är det ennödvändighet för att vi ska uppleva att planet för sig framåt i omgivningen.Hade b̊ade himmel och mark varit enfärgade, och inga terrängobjekt funnitsutplacerade som vi kunnat orientera oss efter, skulle vi uppleva att planetstod still.

I animeringen använder vi oss av tre vyer samtidigt. En visar flygplanetbakifr̊an och följer med när det svänger. Den andra visar planet uppifr̊an.Den har samma tänkta translation som planet (eftersom det egentligen ärmarken som rör sig) och därför är planet alltid placerat i bildens mitt.Däremot roterar inte kameran när planet svänger, vilket medför att vi tyd-ligt kan se planets manövrar. Den tredje vyn visar planet fr̊an sidan. Ävenden translaterar med flygplanet, men roterar inte när det stiger respektivedyker, vilket änd̊a inte är aktuellt i det här exemplet.

I Java 3D g̊ar det att ange det maximala avst̊andet fr̊an kameran för attobjektet ska visas i bild. De delar som finns bortom detta avst̊and syns inte.


I v̊art exempel innebär detta att marken och himlen kommer att ersättasmed en abrupt kant vid detta avst̊and, om vi inte gör det oändligt l̊angt vil-ket naturligtvis är en omöjlighet. Bortom kanten kommer bakgrundfärgenatt visas. För att f̊a en naturligare horisont stoppade jag in en cylinder somomgärdar flygplanet. Cylindern roterar åt det motsatta h̊allet när planetsvänger. Den kläddes med en bild föreställande en bl̊a himmel och en grönmark som möts i en ljus horisontlinje. Betraktaren upptäcker det här ”fus-ket” enkelt eftersom det upplevs vara en vertikal vägg uppställd i periferin.För att dölja de markerade kanter som uppst̊ar mellan horisontcylindernoch marken respektive himlen införde jag en vit dimma i animeringen. Dengör linjerna mer diffusa och sv̊arare att upptäcka.

5.3.3 Filförteckning

En textfil inneh̊allande Java-kod har ändelsen java. För att filerna ska kun-na exekveras måste de kompileras. För övriga programspr̊ak skapar kompile-ringen i regel en färdig programfil som best̊ar av maskinkod. P̊a PC-datorerär ändelsen exe för körbara program. I Unix existerar ingen standardise-rad ändelse. Vid kompilering av Java-kod blir dock resultatet en fil medändelsen class, som inneh̊aller s̊a kallad Javabyte-kod, som tolkas av sinJava-installation när den exekveras. De filer som genereras när java-filernakompileras blir identiska, oberoende av p̊a vilket system detta görs. Därmedkan de köras p̊a alla system där Java är installerat.

I listan följer de kompilerade class-filer som ing̊ar i programmet. Förvardera class-fil finns allts̊a en motsvarande java-fil med källkod. Pro-grammet finns även i en utökad variant där variabelvärden listas i realtidoch hastighetsvektorn ritas ut. I den versionen har dessutom programfilenFlight delats upp i ett flertal mindre klasser, vilket ger en bättre överblick.Jag kommer dock bara att g̊a igenom den enklare versionen som användsp̊a datorlaborationen.

• Flight.class. Själva programfilen som skapar animeringen.

• Ground.class. Den geometri som markplanet best̊ar av.

• Sky.class. Geometri för himmelplanet.

• Horizon.class. Cylinder som visar horisonten.

• Ground.jpg. Textur som appliceras p̊a markplanet.

• Sky.jpg. Textur för himlen.


• Horizon.jpg. Textur för horisontcylindern.

• F16.3DS. 3D-modell för flygplanet. Den är gjord i 3D Studio Maxoch best̊ar av 521 polygoner. Kan bytas ut mot en annan modellfil,som ocks̊a är av formatet 3DS (3D Studio). Filnamnet måste dockbibeh̊allas. De flesta 3D-modelleringsprogram kan exportera till 3DS-format.

• Load3DS.class,Load3DS$Surface.class,Load3DS$Face.class. Läser in 3D-modellfilen F16.3DS och impor-terar den till animeringen. Dessa filer är vanligtvis freeware för icke-kommersiella ändamål och har hämtats hem fr̊an Internet [4].

• Flames.jpg. Bild p̊a eldsflammor som appliceras p̊a en kon som före-ställer l̊agorna som sl̊ar ut fr̊an motorn.

5.3.4 Animering

I Java 3D g̊ar det en tydlig skiljelinje mellan rörelser som genereras in-teraktivt av användaren, genom att denne flyttar musen eller trycker p̊atangenter, och förutbestämda tidsberoende rörelser. I detta program är en-dast det sistnämnda aktuellt. Programmet läser in data fr̊an textfiler sominneh̊aller samplingstid och en lista med samtliga variabelvärden. Därefteranpassas flygplanets och markens rörelser till dessa värden.

Animeringen sker alltid i realtid. Uppdateringsfrekvensen för grafikenberor p̊a datorns prestanda, men själva animeringshastigheten är alltid kon-stant, oavsett vilken processor och vilket grafikkort som sitter i datorn.

5.3.5 Datafiler

I datorlaborationen som ing̊ar i Reglerteori-kurserna skapas datafilerna medhjälp av ett Matlab-script, som förklaras i kapitel 5.3.7. Datafilerna kan dockskapas p̊a andra sätt och sedan användas i animeringen, om programmetstartas manuellt. Det enda som krävs är att filerna är skrivna i rätt format.Tabell 5.3 visar ett exempel p̊a en giltig fil. Överst i filen ska samplingstidenst̊a, angiven i sekunder. Alla värden måste vara samplade med ekvidistantatidsavst̊and. Därunder ska antal mätvärden st̊a. Sedan följer en lista medsamtliga värden.

Alla värden måste vara skrivna i decimalform, s̊avida de inte är heltal.Inläsningsfunktionen klarar inte av exponenter. Vidare är det viktigt att alla


Roll.dat0.11010.130.450.9821.14...

Tabell 5.3. Exempel p̊a datafil. Överst st̊ar samplingstiden, därunder antal sampeloch sist listas alla värden.

tal st̊ar p̊a var sin rad och inte är avskilda enbart med mellanslag eller andraskiljetecken. Programmet läser in en hel textrad i taget och omvandlar dendärefter till ett tal.

5.3.6 Animeringsfönstret

Figur 5.12. Animeringsfönstret för flygplansanimeri

Documents

Animering av flervariabla reglersystem med Matlab och Java · 2012. 10. 22. · Dentredje,ochisärklass st örsta, biten har varit att skapa egna ani-meringar och använda dem