EL1901, Examensarbete, 15 hp
UTVECKLING AV
SIMULERINGSMODELL OCH
AUTOMATISERAD
NEDSTÄLLNINGSFUNKTION
FÖR EN FRONTLASTARE
DEVELOPMENT OF A
SIMULATION MODEL AND
AN AUTOMATED PUT DOWN
CONTROL FUNCTION FOR A
FRONT END LOADER
högskoleingenjörsprogrammet inom elektronik och datorteknik 180 hp vid Umeå universitet. Jag vill säga stort tack till min handledare på Ålö David Wiberg för all den vägledning och hjälp han gett mig genom hela arbetet. Jag vill även tacka min institutionshandledare Ville Jalka-nen för insiktsfull och utförlig feedback under rapportskrivandet. Tack också till Juan Sagarduy på MathWorks för värdefulla råd och uppmuntran gällande Simulinkmodellen. Slutligen vill jag tacka alla i gruppen Control Systems på Ålö för det vänliga bemötandet och en både lärorik och rolig tid!
Umeå, juni 2019 Leon Amkoff
framåt inom det moderna lantbruket. I sin utveckling av nya styr- och reglerfunktioner för frontlastare behövde Ålö AB en pålitlig och effektiv plantmodell av deras frontlastare Quicke Q5M. Plantmodellen skulle inkludera det tillhörande mekaniska och hydrauliska systemet och kunna rendera simulering och 3D-animering i realtid. En automatisk nedställningsfunktion för material skulle också utvecklas för att automatisera den vanligt förekommande sysslan att ställa ned material från en upphöjd position.
En plantmodell för Quicke Q5M med ett lastkännande hydraulsystem utvecklades i MAT-LAB Simulink med Simscape Multibody och Simscape Fluids. Prestandan av den simulerade plantmodellen utvärderades. Plantmodellen visade grundläggande överensstämmelse när den jämfördes med sensordata från en frontlastare i verkligheten.
En reglerfunktion för automatisk nedställning av material utvecklades i Simulink. En algo-ritm för att detektera kollision med mark konstruerades genom att analysera sensordata från en frontlastare i verkligheten som ställt ned material på marken. För att detektera materia-lets kontakt med mark utfördes hastighets- och accelerationsestimeringar på sensordata från vinkelgivare och trycksensorer. Vid kontakt med mark avslutades nedställningsrörelsen automa-tiskt. Prestandan och noggrannheten av reglersystemet under olika scenarion analyserades och diskuterades.
Trots att simuleringar av plantmodellen och den föreslagna nedställningsfunktionen såg re-alistiska ut var det svårt att kvantifiera överensstämmelsen mellan plantmodell och frontlastare då inga utförligare fysiska tester hanns med. Framtida utveckling av plantmodell och nedställ-ningsfunktion rekommenderas därför att börja med ett implementeringstest av reglerfunktionen i en traktor i verkligheten. Det skulle ge ett mått på hur pass bra plantmodellen representerar frontlastaren samt möjliggöra utvärdering och vidare justering av reglerfunktionens parametrar i en verklig fysisk miljö.
technological advances forward. In developing new automatic control functions for front end loader applications, Ålö AB needed a reliable and effective plant model of their front end loader Quicke Q5M. The plant model should include the associated mechanical and hydraulic system and be capable of rendering simulation and 3D animation in real time. An automated put down control function would also be of benefit for farming operators, speeding up the commonly performed farming task of putting down material from an elevated position.
A plant model for the Quicke Q5M with a Load Sensing hydraulic system was developed in MATLAB Simulink with Simscape Multibody and Simscape Fluids. The performance of the simulated plant model was evaluated. The plant model showed some consistent results when compared to sensor data logs from a real-world front end loader.
An automatic put down control function for material was also developed and tested in Simulink. A collision detection algorithm was constructed by analyzing sensor data logs from a real-world tractor putting down material on the ground. Velocity and acceleration estimations were made from angular position and pressure sensors to detect the contact between material and ground. The control function automatically stopped the lowering movement when contact was detected. The performance and accuracy of the control system under different scenarios were analyzed and discussed.
Although the simulations of the plant model and proposed control function seemed realistic, the consistency of the plant model was hard to quantify since there was no time left for any thourough physical tests. It is recommended that future development of both the plant model and control system begin with an implementation test of the control system in a real-world tractor. This would help determine how accurately the plant model represents the front end loader. It would also allow evaluation and further tuning of the control function in a real physical environment.
1.1 Bakgrund och problembeskrivning . . . 1 1.2 Frågeställningar . . . 1 1.3 Syfte . . . 1 1.4 Mål . . . 1 1.5 Kravspecifikation . . . 2 1.6 Avgränsningar . . . 2 1.7 Tidigare arbeten . . . 2 1.8 Ordlista . . . 4 2 Teori 5 2.1 Modellering med differentialekvationer . . . 5
2.1.1 Numerisk lösning av differentialekvationer . . . 5
2.1.2 Styva differentialekvationer . . . 5 2.1.3 Newtons metod . . . 5 2.1.4 Trapetsmetoden . . . 6 2.2 Lösning i Simulink . . . 6 2.2.1 ODE45 . . . 6 2.2.2 ODE15s . . . 7 2.2.3 ODE23t . . . 7 2.2.4 Nollgenomgångar . . . 7 2.2.5 Solver resets . . . 7
2.2.6 Newton iteration exception . . . 7
2.2.7 Error control exception . . . 7
2.2.8 Run/Sim tidskvot . . . 7
2.3 Mekanik . . . 8
2.3.1 Referensram . . . 8
2.3.2 Tröghetsmoment . . . 8
2.3.3 Vinkelhastighet och varvtal . . . 8
2.4 Hydraulik . . . 9 2.4.1 Deplacementpump . . . 9 2.4.2 Hydraulolja . . . 9 2.4.3 Hydraulventil . . . 9 2.4.4 Hydraulcylinder . . . 10 2.4.5 Lastkännande system (LS) . . . 10 2.5 Signalbehandling . . . 11 2.5.1 Brus . . . 11 2.5.2 En ideal differentiator . . . 11 2.6 Reglerteknik . . . 12 2.6.1 PID-regulator . . . 12 2.7 Mjukvaror . . . 13 2.7.1 Simscape Multibody . . . 13 2.7.2 Simscape Fluids . . . 13 3 Metod 14 3.1 Inhämtning av information . . . 14
3.2 Motivering till val av Simulink och modellbaserad simulering . . . 14
3.3 Design guidelines . . . 14
3.4 Utveckling av mekanisk modell . . . 15
3.5.4 Sammankoppling av mekanisk och hydraulisk modell . . . 19
3.6 Val av solver i MATLAB . . . 20
3.7 Verktyg för felsökning och optimering av exekveringstid . . . 20
3.8 Automatiserad mjuk nedställning av material . . . 20
3.8.1 Kontakt med underlag . . . 20
3.8.2 Detektering av kollision . . . 21
3.8.3 Jämförelse med Ålös loggar från traktor i verkligheten . . . 23
3.8.4 Detekteringsalgoritm . . . 23
3.8.5 Hastighetsestimering . . . 24
3.8.6 Signalbehandling . . . 24
3.8.7 Reglering . . . 25
3.8.8 Kombinering av kontinuerlig och diskret solver . . . 25
4 Resultat 27 4.1 Signalbehandling . . . 28 4.2 Lösning i Simulink . . . 30 4.3 Simuleringsmodell . . . 31 4.4 Automatisk nedställning . . . 34 5 Diskussion 39 5.1 Utvärdering av metoder och resultat . . . 39
5.1.1 Mekanisk modell . . . 39
5.1.2 Hydraulisk modell . . . 39
5.1.3 Lösning i Simulink . . . 39
5.1.4 Reglerfunktion . . . 40
5.2 Felkällor och begränsningar . . . 41
5.3 Framtida förbättringsarbete . . . 41
6 Slutsats 43
A LS-reglering av pump med Simscape komponentblock 47
B Komplett plantmodell 48
C Mekanisk modell 49
1
Inledning
1.1 Bakgrund och problembeskrivning
En frontlastare är en hydraulisk lyftanordning som monteras framtill på traktorer och används inom bland annat lantbruk. På frontlastare kan redskap så som till exempel skopor, pallgafflar eller balgripar fästas. I sin styrsystemverksamhet så har Ålö ett behov av en tillförlitlig och effek-tiv simuleringsmodell av sina frontlastare, inkluderande även traktorns hydrauliska kraftkälla. Sedan tidigare har företaget en grundmodell för en annan version av frontlastare med annan hydraulik, men där simulering inte varit möjlig i realtid. Utvecklingen av nya funktioner till Ålös frontlastare hade kunnat effektiviseras om testning via simulering i realtid varit möjlig.
I takt med att antalet människor på jorden blir fler och efterfrågan på grödor växer, blir samtidigt antalet lantbruk och lantbrukare färre. Istället så har själva storleken på lantbruken ökat. Som en följd av detta är en ökad effektivisering av lantbruk nödvändig [1]. Om vanligt förekommande arbetssysslor kan automatiseras effektivt och noggrant så kan produktiviteten öka, samtidigt som operatörens arbete blir mindre ansträngande [2].
En svensk pilotstudie har undersökt hur lantbrukare upplever användandet av avancerade och automatiska lantbrukssystem [2]. Studien visade att det fanns fördelar med dessa så som ökad effektivitet och noggrannhet, men också nackdelar så som större svårighet att lösa tekniska problem när dessa uppstod. Lantbrukarna själva ansåg att avancerad lantbruksteknologi var gynnsam, men att det också fanns utmaningar. Andra källor bekräftade trenden och behovet av ökad automation inom lantbruksindustrin för att kunna öka produktionen [3]. En vanlig arbetsuppgift för frontlastare är att från ett upphöjt läge ställa ned material - antingen staplat på annat material eller direkt ned på marken. Detta kräver noggrannhet, precision och fokus av operatören.
1.2 Frågeställningar
Följande frågeställningar för projektet togs fram i dialog med Ålö:
1. Hur kan frontlastaren modelleras och simuleras både effektivt och verklighetstroget? 2. Är det möjligt att erhålla simulering av modellen i realtid?
3. Är det möjligt att utveckla en effektiv och stabil reglerteknisk styrsystemfunktion för automatiserad nedställning av material med hjälp av den framtagna simuleringsmodellen? 1.3 Syfte
Syftet med arbetet är att utveckla en simuleringsmodell som kan användas till att effektivisera utvecklingen av nya styrsystemfunktioner för Ålös frontlastare. Syftet är också att utveckla en automatisk nedställningsfunktion som kan öka produktiviteten för lantbrukare.
1.4 Mål
1. Med utgångspunkt i ett redan genomfört grundarbete utveckla en komplett plantmodell av Ålös frontlastare Q5M. Modellen ska inkludera relevant mekanik och hydraulik samt omvärldsfaktorer.
2. Med hjälp av simuleringsmodellen utveckla en reglerteknisk styrsystemfunktion för auto-matiserad mjuk nedställning av material i MATLAB Simulink
3. Implementera och demonstrera funktionen i ett komplett styrsystem i en traktor i verklig-heten.
1.5 Kravspecifikation
En kravspecifikation togs fram i dialog med Ålö och Institutionen för tillämpad fysik och elekt-ronik vid Umeå universitet, se tabell 1.
Tabell 1 – Kravspecifikation
Krav nr Kravbeskrivning Prioritet
1 Med en tidigare modell av frontlastare som utgångspunkt utveckla en komplett plantmodell i MATLAB Simulink för Ålös frontlastare Quicke Q5M med tillhörande hydraulik och mekanik.
1
2 Utveckla en reglerteknisk styrsystemfunktion för automatiserad mjuk nedställning av material i MATLAB Simulink.
1 3 Simuleringsmodell, inklusive reglerfunktion, ska kunna hantera nya
indata med periodtid 10 ms på Ålös datorer.
2 4 Maximal exekveringstid för reglerloopen tillåts vara 1 ms på Ålös
styrsystem.
2 5 Reglerfunktionen ska vara stabil, ingen ryckighet ska upplevas vid
test.
3 6 All utveckling i Simulink ska följa Ålös interna regelverk ”Simulink
Design Guideline”.
3 7 Implementation och demonstration av reglerfunktionen i ett komplett
styrsystem i en traktor i verkligheten.
3 8 Dokumentation i form av examensrapport på svenska. 1
1.6 Avgränsningar
Formell utvärdering av prestanda eller uppmätning av korrelation mot verkligheten vid ett even-tuellt test i traktor i verkligheten kommer endast att utföras om det finns tid över.
Plantmodellen ska endast utvecklas efter frontlastaren Quicke Q5M med en given specifikation för hydraulik (”Ålö LS-valve”) och mekanik. Eventuella nödvändiga justeringar av modellen för att kunna simulera liknande men andra modeller av frontlastare än Quicke Q5M eller andra hydraulsystem ingår inte i ramen för examensarbetet.
1.7 Tidigare arbeten
Arbetet inleddes med en litteraturöversikt där fysisk modellering och reglering av lantbruksma-skiner studerades. Tidigare akademiska arbeten på Ålö har visat några möjliga modellerings-antaganden så som att hydraulventilers läckage kan försummas samt att öppningsarean i en hydraulventil kan antas vara proportionell mot styrsignalen [4]. Andra antaganden så som att hydrauloljans fjädring i ett hydraulsystem ibland också kan försummas beskrivs av Ingvast, H [5]. Gällande reglerfunktioner så föreslog Cristofori, D. en adaptiv reglermetod för att reglera olika hydrauliska mobila maskiner där störningar i form av vibrationer och diskontinuerliga rörelser var ett problem [6]. Metoden utnyttjade hydrauliska tryckgivare för återkoppling, en optimeringsal-goritm och gain scheduling. Metoden kunde implementeras med olika typer av regulatorer men skribenterna valde en PID-regulator för enkelhetens skull i sitt arbete. Metoden var tillämpbar för många olika typer av hydrauliska maskiner, inklusive LS-system, då den adaptiva regler-metoden identifierade mekaniken och reglerparametrarna själv. Andra publicerade artiklar där reglersystem för lantbruksfordon och traktorer utvecklats använde ofta PID-regulatorer i olika
Vid arbetets början fanns det en plantmodell i Simulink av en annan frontlastare tillgänglig att studera. Mekaniken och hydrauliken var i ett annat utförande, men inspiration och vägledning för tillvägagångssätt kunde ändå tas för delar av den övergripande plantdesignen. En komplett CAD-modell med materialinformation för Quicke Q5M fanns tillgänglig i CAD-mjukvaran Solid Edge ST8.
1.8 Ordlista
1. Frontlastare - Lyftanordning på en traktor
2. ECU - Electronic Control Unit, inbyggt styrsystem på ett fordon 3. LS - Load Sense, ett återkopplat lastkännande hydraulsystem
4. MVU - Main-Valve-Unit, en enhet bestående av två eller fler hydraulventiler 5. PID - En vanligt förekommande typ av regulator
6. STL - Ett filformat som beskriver tredimensionella ytor med hjälp av trianglar 7. Solver - Algoritm som används för att lösa differentialekvationer i MATLAB
2
Teori
2.1 Modellering med differentialekvationer 2.1.1 Numerisk lösning av differentialekvationer
Många differentialekvationer är svåra eller omöjliga att lösa analytiskt. I dessa fall kan det vara lämpligt att lösa differentialekvationerna numeriskt istället [9]. Numerisk lösning av differen-tialekvationer går ut på att genom olika lösningsmetoder diskretisera problemet och approxi-mera lösningen för varje tidssteg. Lösningarna kan beräknas explicit eller implicit. Exempel på vanliga numeriska lösningsmetoder av ordinära differentialekvationer är Eulers metod, Runge-Kuttametoden och Trapetsmetoden. Vid numerisk lösning kan storleken på tidsstegen antingen sättas statiskt eller variabelt. Ett variabelt tidssteg innebär att algoritmen anpassar varje tids-stegs storlek beroende på hur systemet vid varje tidpunkt förändras. Om systemet förändras snabbt tas små steg och om systemet förändras långsamt kan större steg tas. På detta vis kan viktiga förändringar i systemet fångas med små steg samtidigt som den totala exekveringstiden kan hållas låg eftersom systemet eventuellt kan ta större steg genom andra delar av lösningen. 2.1.2 Styva differentialekvationer
En differentialekvation med begynnelsevillkor kallas ”styv” (eng. stiff) om den vid numerisk lös-ning under något eller några intervall kräver alltför små tidssteg sett till dess släthet jämfört med den exakta lösningen under det intervallet [9]. En explicit lösning kan därför kräva väldigt många steg i ett styvt område för att uppnå toleranskrav. Styva differentialekvationer blir alltså i praktiken ett kapacitetsproblem, där den numeriska lösningsmetoden måste väljas så att lös-ningen inte tar för lång tid. En lösning på det problemet är att lösa systemet implicit istället [10]. Vissa implicita metoder kan ta mycket stora steg i styva områden utan att tappa i noggrannhet, vilket kan motivera den högre beräkningstiden som krävs för att lösa de olinjära ekvationerna som metoderna kräver [11].
2.1.3 Newtons metod
Newtons metod är en iterativ matematisk algoritm för att numeriskt beräkna rötter till ekva-tioner av typen f (x, y) = 0. Metoden kan användas för att hitta lösningar på system av m ekvationer i m variabler. I fallet där m = 2 kan successiva approximeringar av rötterna till ekvationssystemet
(
f (x, y) = 0 g(x, y) = 0
beräknas med hjälp av en initial gissning av rot (x0, y0) och Jacobianen, ∂(f, g)
∂(x, y)|(x0, y0). Algoritmen ges enligt (1) och (2), [12],
xn+1 = xn− f f2 g g2 f1 f2 g1 g2 |(xn, yn), (1) yn+1 = yn− f1 f g1 g f1 f2 g g |(xn, yn). (2)
Antalet iterationer kan exempelvis väljas så att algoritmen beräknar nya approximeringar så länge någon av olikheterna |f (xn, yn)| > δ och |g(xn, yn)| > δ uppfylls, där δ är något önskat tröskelvärde för noggrannhet.
2.1.4 Trapetsmetoden
För att lösa en första ordningens differentialekvation av typen y0= f (t, y), y(t0) = y0 från t = n till t = n + 1 kan ekvationen först integreras vilket ger
y(tn+1) − y(tn) = Z tn+1
tn
f (t, y(t))dt En bestämd integral kan enligt trapetsregeln [12] approximeras enligt
Z b a
g(t)dt ≈ (b − a)g(a) + g(b) 2
Om integralen från den integrerade differentialekvationen approximeras med trapetsregeln har vi att Z tn+1 tn f (t, y(t))dt ≈ (tn+1− tn) f (tn, y(tn)) + f (tn+1, y(tn+1)) 2 Låt h = tn+1− tn
och använd att yn≈ y(tn) och yn+1≈ y(tn+1) så kan en formel för att lösa en ordinär differen-tialekvation med trapetsregeln skrivas som
y(tn+1) = y(tn) + h
f (tn, yn) + f (tn+1, y(tn+1))
2 (3)
Metoden att lösa differentialekvationer iterativt via (3) kallas för trapetsmetoden [13]. Det går att se metoden som att den linjäriserar y vid tnmed en lutning som är medelvärdet av y0(tn) och y0(tn+1). Eftersom y(tn+1) står på båda sidor av ekvationen kan ekvationen inte lösas explicit utan endast implicit.
2.2 Lösning i Simulink
I Simulink finns det ett antal program kallade ”solvers” som löser system av ordinära diffe-rentialekvationer genom olika algoritmer. Gemensamt för nästan alla solvers är att de endast löser system av första ordningens ordinära differentialekvationer, vilket innebär att de skriver om eventuella högre ordningens differentialekvationer i system av första ordningens differentia-lekvationer. Solvers kan antingen lösa system i diskret eller kontinuerlig tid. Vid val av solver måste flera faktorer så som önskad exekveringstid, stabilitet och robusthet tas i beaktning. Oli-ka solvers är dessutom lämpade för oliOli-ka typer av system. Till exempel så är implicita solvers bättre lämpade att lösa styva system än vad explicita solvers är [14]. Vid modellering av fysiska komponentblock i Simulink blir systemet alltid implicit.
2.2.2 ODE15s
ODE15s är den solver som MathWorks rekommenderar att först testa om systemet verkar vara styvt [10]. Solvern är implicit med variabelt tidssteg och använder en multistegmetod, vilket innebär att data från fler steg än endast det senaste används för att beräkna nästa steg. Genom att göra mer arbete varje steg kan också större steg tas, vilket i styva områden kan ge snabbare lösning än vad en explicit solver kunnat.
2.2.3 ODE23t
ODE23t är en implicit solver designad för att lösa måttligt styva system av differentialekvationer. Solvern använder trapetsmetoden för att lösa differentialekvationer. Eftersom ekvationerna löses implicit och blir olinjära så linjäriseras först systemet och därefter används Newtons metod för att hitta lösningar till ekvationerna [15].
2.2.4 Nollgenomgångar
En nollgenomgång (eng. zero crossing) innebär att en matematisk funktion byter tecken genom att passera genom ett nollställe. En solver som använder variabelt tidssteg kommer att ta myc-ket små steg nära ett systems eventuella diskontinuiteter. Detta kan leda till många upprepade nollgenomgångar och ta mycket lång tid att lösa [16]. I Simulink går det att ställa in om Si-mulink ska detektera nollgenomgångar och om nollgenomgångar ska hanteras med en adaptiv algoritm där itereringen avslutas efter ett max antal detekterade nollgenomgångar. Att detekte-ra nollgenomgångarna har ett pris av ökad beräkningstid men kan potentiellt minska den totala beräkningstiden.
2.2.5 Solver resets
Under lösning kan solvern behöva resetas för att kunna gå vidare. En reset kan till exempel uppstå vid en nollgenomgång eller om en diskret signal driver ett kontinuerligt block [17]. Vissa block kan också konfigurerats att göra en reset av solvern för att modellera något fysikaliskt fenomen. En reset av solvern har ett pris av ökad beräkningstid.
2.2.6 Newton iteration exception
När en solver som använder Newtons metod inte lyckas konvergera inom den givna feltoleransen efter ett visst antal itereringar orsakas ett ”Newton iteration exception” i Simulink [17]. Det är endast implicita solvers som kan orsaka detta undantag.
2.2.7 Error control exception
Ett ”error control exception” orsakas när den lösning som solvern når är utanför den bestämda feltoleransen [17].
2.2.8 Run/Sim tidskvot
”Run/Sim” tidskvot är ett mått på hur lång tid solvern behövt arbeta för att beräkna lösningen, ”Run”, jämfört med hur lång själva simuleringstiden i normal uppspelningshastighet, ”Sim”, varit. En låg tidskvot eftersträvas och om hela simuleringen i snitt lösts i realtid är kvoten mindre än 1.
2.3 Mekanik 2.3.1 Referensram
Positionen av materiella system (kroppar), beskrivs inom mekaniken med hjälp av koordinat-system [18]. En referensram är ett koordinatsystemen som fixerats och orienterats på något bestämt sätt och används för att beskriva kroppars lägen och rörelser.
2.3.2 Tröghetsmoment
En stel kropps tröghetsmomentet I är ett mått på hur stort vridmoment kroppen måste utsättas för, för att en viss ändring av rotationshastighet per tidsenhet runt en fix axel ska uppnås [18]. För en kropp som består av i delmassor m med avstånd a till axeln λ ges tröghetsmomentet av
Iλ = i=n X
i=1 mia2i
Om λ är någon av axlarna i koordinatsystemet, exempelvis λ = x, ges tröghetsmomentet av
Ix = i=n X
i=1
mi(yi2+ z2i)
Om massan är kontinuerligt fördelad ges tröghetsmomentet av Ix=
Z
(yi2+ zi2)dm
Tröghetsmomentet för en kropp i tre dimensioner kan arrangeras i tröghetstensorn, som definieras enligt (4). I = Ixx Ixy Ixz Iyx Iyy Iyz Izx Izy Izz (4)
där Iij är tröghetsmomentet runt i-axeln när kroppen roterar runt j-axeln. Elementen Iii kallas för tröghetsmoment, medan elementen Iij, i 6= j kallas för tröghetsprodukter [19].
2.3.3 Vinkelhastighet och varvtal
Varv per minut eller varvtal, (eng. Revolutions Per Minute) definieras som antal varv en kropp gör runt en fix axel per minut, där ett varv är 2π radianer. Det innebär att
1 rpm = 2π 60 rad/s vilket ger att vinkelhastigheten ω ges av
ω = 2π
2.4 Hydraulik
Hydraulsystem är ett samlingsbegrepp för system där strömmande trycksatta fluider i vätskeform används för att överföra mekanisk energi från en el- eller förbränningsmotor till hydraulcylindrar eller hydraulmotorer [20]. I ett hydraulsystem ingår bland annat motor, pump, tank, slang, ventil och hydraulisk aktuator [5]. Hydraulsystem kan ha mycket hög verkningsgrad och hög precision. Ett exempel på ett hydraulsystem visas i Fig 1.
Figur 1 – Exempel på ett enkelt hydraulsystem med de viktigaste komponenterna för att styra en hydraulcylinder. I bilden styrs hydraulcylindern nedåt [21].
2.4.1 Deplacementpump
En deplacementpump är en pump som stänger in en viss volym vätska och forslar den från ingång till utgång [20]. Pumpens deplacementet är ett mått på hur stor volym som för varje arbetscykel förträngs . Så länge pumpen förses med tillräckligt stor drivkraft och att hållfastheten är tillräckligt hög så kommer en deplacementpump alltid att förtränga samma volym vätska, oavsett mottryck.
2.4.2 Hydraulolja
Hydrauloljan är det trycksatta medie som kraftöverföringen i ett hydraulsystem sker via. Hyd-rauloljan tjänar även som ett smörjmedel, rostskydd och transporterar bort föroreningar och vär-me till reningsfilter och kylare [5]. När hydraulsystem modelleras är det beroende på modellens krav ibland möjligt att försumma hydrauloljans kompressibilitet. Hydrauloljan är kompressibel, men den fjädring i systemet som kompressibiliteten orsakar är oftast mycket liten i jämförelse med andra komponenter. Exempelvis orsakar hydraulslangar ungefär 10 gånger mer fjädring än vad själva hydrauloljan gör [5].
2.4.3 Hydraulventil
En hydraulventil är en enhet som kan styra tryck, flöde och riktning i ett hydraulsystem. En viktig typ av hydraulventil är riktningsventilen. Riktningsventilen finns i många utföranden men grundfunktionen är att styra oljeflödet i olika riktningar genom omkopplingar i ventilen. Styrning
av riktningsventilen kan göras antingen manuellt via en spak, mekaniskt, elektriskt, hydrauliskt eller pneumatiskt [20].
2.4.4 Hydraulcylinder
En hydraulcylinder används vid hydraulisk kraftöverföring som en motor. En hydraulcylinder består av två kammare som separeras av en kolv och utför en linjär rörelse. Rörelse uppnås genom att hydraulolja släpps på genom en hydraulventil och trycksätter en av kammarnas sidor. Beroende på om hydraulcylindern kan styras i båda eller endast ena riktningen kallas den för antingen dubbelverkande eller enkelverkande [20].
2.4.5 Lastkännande system (LS)
Ett lastkännande hydraulsystem (eng. ”Load Sense”, även kallat LS-system) är ett system som möjliggör att hålla ett konstant tryck över den volymströmstyrande riktningsventilen - oavsett hur lasten varierar [5]. Detta medför att ett visst utstyrt slag från operatören kommer att ge samma rörelse av aktuatorn, oavsett lastens tyngd. Genom återkoppling av flöde kan pumpen regleras så att trycket innan riktningsventilen alltid ligger på en viss önskad tryckskillnad ∆P över lasttrycket. ∆P är typiskt kring 20 bar. Om flera aktuatorer används anpassas det totala flödet efter den aktuator med högst behov. Detta förutsätter att pumpens kapacitet och den mekaniska hållfastheten i lastaren klarar av lasten. Det finns olika metoder att realisera LS-system. En vanlig metod är att använda en riktningsventil med en LS-utgång som ger ett tryck proportionellt mot den aktuator med för tillfället högst last. LS-signalen återförs till pumpen vars styrsystem justerar pumpflödet. Ett typexempel på en mekatroniskt styrd LS-ventil visas i Fig 2.
Figur 2 – Exempel på en mekatroniskt styrd ventil i LS-utförande [22]. LS-signal från den ventil med högst lasttryck återkopplas till en regulator som styr en pump med variabelt deplacement.
2.5 Signalbehandling 2.5.1 Brus
Störningar av olika slag uppstår i alla verkliga elektriska system [23]. Störningar genererade i det egna elektriska systemets komponenter kallas för brus. Störningar kan också komma från andra elektriska system eller från elnätet. Brus kan definieras som en slumpmässigt varierande spänning [23]. Brus som är spritt över hela frekvensspektrat och har en normalfördelad amplitud kallas för vitt brus. Vitt brus genereras i elektriska system genom värmen alstrad på grund av laddningar-nas rörelser i kretsens ledningar. Detta vita brus kallas för Johnsonbrus. Eftersom bruset varierar slumpmässigt kan brusspänningen inte bestämmas exakt för någon viss tidpunkt. Däremot kan effektivvärdet, det vill säga det kvadratiska medelvärdet, beräknas för Johnsonbruset enligt
ujohn= √
4πkRT B (6)
där k är Boltzmanns konstant, R är ledningens resistans, T är temperaturen i Kelvin och B är systemets brusbandbredd [24]. Av sambandet i (6) kan man utläsa att bandbredden, inim-pedansen och temperaturen i ett elektriskt mätsystem ska hållas så låga som möjligt för att generera lägsta möjliga brus.
2.5.2 En ideal differentiator
För ett linjärt tidsinvariant system är överföringsfunktionen G(s) för en ideal differentiator G(s) = s [25]. Detta innebär att G(jω) = jω. Amplitudförstärkningen för G(jω) kommer att variera beroende på vinkelfrekvensen ω enligt amplitudfunktionen A(ω) = |G(jω)| [26]. Amplitudfunktionen för en ideal differentiator blir därmed
A(ω) = |G(jω)| = |ω| (7)
Med andra ord beskriver (7) att amplitudförstärkningen ökar linjärt med (den positiva) vinkelfrekvensen, se Fig 3.
Figur 3 – Amplitudfunktion för en ideal differentiator. Amplituden ökar linjärt med frekvensen. Endast positiva vinkelfrekvenser är avbildade.
Eftersom brus innehåller mycket högra frekvenser kommer en brusig signal som deriveras att få bruset kraftigt förstärkt. Om det är mycket brus i en signal kan deriveringen göra bruset oproportionellt stort sett till signalen och i värsta fall överrösta signalen helt [25]. Deriveras signalen ytterligare gånger blir bruset ännu kraftigare.
2.6 Reglerteknik
Reglerteknik är ett tvärvetenskapligt teknikämne och kan beskrivas som läran om automatiska system och särskilt återkopplade automatiska system [26]. Målet med reglerteknik är oftast att utveckla system för att automatiskt övervaka en eller flera storheter och reglera dessa så att de befinner sig så nära som möjligt något önskat värde. Det önskade värdet kallas börvärde. I ett återkopplat reglersystem mäts utsignalen från den reglerade processen med givare och återförs till regulatorn som då kan justera styrsignalen. Regulatorn är ofta en mikrokontroller som kör en och samma algoritm i en oändlig loop. Typiskt läser regulatorn in data från analoga givare via AD-omvandlare, beräknar en ny styrsignal och ställer sedan ut den till styrdonet via DA-omvandlare. Ett blockschema för ett reglersystem visas i Fig 4.
Figur 4 – Blockschema för ett reglersystem.
2.6.1 PID-regulator
En vanligt förekommande regulator i industrin är PID-regulatorn [26]. Namnet PID kommer från att regulatorn innehåller en proportionell, en deriverande och en integrerande del. Algoritmen för en PID-regulator kan beskrivas enligt (8)
u(t) = Kpe(t) + KI Z
e(t)dt + KD de(t)
dt (8)
där u(t) är styrsignalen, e(t) är felet (skillnaden mellan börvärde och ärvärde) och KP, KI och KDär konstanter som styr hur stort bidrag de respektive termerna ska ge [27]. Den proportionella delen ger ett bidrag till styrsignalen som är proportionerligt mot felet e(t). Den proportionella delen ger oftast upphov till ett kvarvarande statiskt fel. Det statiska kvarvarande felet elimineras genom att låta den integrerande delen integrera över felet e(t). För stort värde på KI kan leda till oscillationer på styrsignalen. Den deriverande delen deriverar e(t) och kan på så vis förutse vad det förväntade framtida felet kommer vara KD sekunder fram. Detta kan beskrivas som att regulatorn tittar framåt i tiden och ser var processen är på väg. Genom att göra det kan justeringar av styrsignaler göras i förväg och på så vis förbättra snabbhet, stabilitet och dämpa oscillationer. I praktiken kan den deriverande delen försämra stabiliteten eftersom en mer eller mindre brusig givarsignal måste deriveras. Den deriverande delen av PID-regulatorn kan därför behöva utelämnas om signalen är brusig [28].
2.7 Mjukvaror
MATLAB Simulink med tilläggen i Simscape möjliggör modellbaserad utveckling av simule-ringsmodeller. Genom att använda komponentblock kan utvecklingen göras modulär och effek-tiv. Simscape delas in i olika fysiska domäner, till exempel 3D mekanisk ramdomän, mekanisk translationsdomän och hydraulisk domän. I Simulink kan modeller i olika fysiska domäner enkelt kopplas samman för att beskriva sammansatta komplexa system.
2.7.1 Simscape Multibody
Simscape Multibody möjliggör modellering av mekaniska system med komponentblock [29]. I Simscape Multibody sammankopplas delkroppar i systemet antingen via stela transformer av referensramar, där både translation och rotation är möjligt att specificera, eller via olika typer av rörliga leder kallade ”joints”. En referensram i Multibody beskriver position och basvektorer i ett koordinatsystem. En global referensram i vila kallad ”World Frame” måste alltid finnas med i modellen och det är relativt denna som alla delkroppar är definierade. En joint i Multibody kan beskriva linjär rörelse längs med en axel (”prismatic joint”), rotationsrörelse runt en fix axel (”revolute joint”) eller en kombination av dessa (exempelvis ”cylindrical joint”) längs en given koordinataxel, se Fig 5. I varje joint kan begynnelsevärden, styrning och mätning av fysikaliska storheter ställas in. Modeller i Multibody kan också 3D-animeras.
(a) En revolute joint [30]. (b) En prismatic joint [31]. Figur 5 – Två olika typer av joints som kan användas för att koppla samman kroppar. 2.7.2 Simscape Fluids
Simscape Fluids möjliggör modellering av hydrauliska system med komponentblock [32]. Sims-cape Fluids inkluderar ett bibliotek med färdiga modeller av bland annat pumpar, ventiler, slangar och hydraulcylindrar. Komponenter så som tryck- och flödesgivare finns också tillgäng-liga.
3
Metod
3.1 Inhämtning av information
För att söka publik information i form av vetenskapliga artiklar användes Umeå universitets-biblioteks söktjänst. Läroböcker som används inom de olika teknikområdenas universitetskurser lånades också på Umeå universitetsbibliotek. Intern dokumentation på Ålö så som Ålös interna designregler i MATLAB Simulink för modellering och datablad för mekanik och hydraulik har också studerats. Hydraulschema för LS-ventil tillhandahölls av Ålö. Två rådgivningsmöten med en kontaktperson på MathWorks genomfördes. På mötena diskuterades metoder och strategier för modellering av mekanik och hydraulik, solvers, exekveringstid och utveckling av reglersy-stem i MATLAB. MathWorks egna hjälpsidor konsulterades också frekvent under utvecklingen av både plantmodell och reglerfunktion.
3.2 Motivering till val av Simulink och modellbaserad simulering
Ålö hade ställt krav på att mjukvaran MATLAB Simulink med tilläggen Simscape Fluids och Simscape Multibody skulle användas för utveckling av plantmodell och reglerfunktion. Det fanns andra liknande mjukvaror men just MATLAB Simulink ansågs ha ett antal fördelar jämfört med de andra. Det vanligaste alternativet till MATLAB på marknaden är GNU Octave [33]. Octave har vissa grafiska funktioner men saknar motsvarigheten till tillägsfunktionaliteten MATLABs Simulink erbjuder. Ett annat alternativ till MATLAB är Scilab [34]. Scilab är gratis och har en motsvarighet till Simulink vid namn Xcos. Xcos utvecklades specifikt för simulering av reglersy-stem och har stöd för både mekaniska och hydrauliska delar. Xcos hade därför kunnat vara ett möjligt alternativ till Simulink för denna uppgift.
Simulink är enkelt att använda, tillförlitligt, väl dokumenterat och har ett stort utbud av inbyggda komponenter med färdiga fysikaliska parametrar. Befintliga mekaniska CAD-modeller kan importeras och animeras i 3D. Modellen kan också användas för Hardware-in-the-loop-simulering (HIL). Den tidigare grundmodellen var designad i Simulink vilket gjorde att vissa designidéer kunde återanvändas. Dessutom gjordes mycket av den övriga funktionsutvecklingen på Ålö i MATLAB Simulink vilket gör framtida integrering mellan delsystem enklare. Samman-taget gjorde detta att Simulink föredrogs över Xcos i detta projekt.
På en högre systemnivå fanns en vilja att använda just modellbaserad simulering på det sätt som verktyg likt Simulink möjliggör, till skillnad från metoder med black box modellering. Anledningen till detta var att det ansågs finnas ett stort värde i att kunna se, förstå och ha möjlighet att vid behov förändra modeller. Förhoppningen var att en effektiv och smart de-sign skulle kunna undvika de problem med långsamma simuleringar som kan uppstå med just modellbaserad simulering.
3.3 Design guidelines
Interna designregler från Ålö följdes vid utvecklingen i Simulink. Dessa regler hade stor likhet med Matworks egna designregler för utveckling i Simulink, men med vissa undantag. Utöver dessa regler bestämdes det även i början av arbetet att de komponenter som skulle användas upprepade tillfällen skulle modelleras i ett Simulink library. De egna komponentblocken försågs med masker där nödvändiga parametrar kunde anges för varje instans av komponenten. På så vis kunde komponentblock enkelt återanvändas. Ett initieringsscript skapades också i MATLAB för att initiera de nödvändiga variablerna för plantmodell och reglerfunktion.
3.4 Utveckling av mekanisk modell
En färdig CAD-modell av frontlastaren Q5M fanns tillgänglig i Solid Edge ST8 vid arbetets början, se Fig 6. Cylindrarna var dubbelverkande hydraulcylindrar. Cylindrarna närmast in-fästningarna kallades ”Lift” och cylindrarna som vinklade redskapshållaren längst ned kallades ”Tilt”.
Figur 6 – CAD-modell av Ålös frontlastare Quicke Q5M.
Frontlastaren betraktades som ett dynamiskt system, beståendes av ett antal stela homo-gena delkroppar sammanlänkade via rörliga leder och stela transformer. Varje väsentlig stel delkropps 3D-geometri av frontlastaren exporterades från Solid Edge ST8 i STL-format. Vissa mekaniska delar exporterades ej, så som exempelvis skruvar och slangar, men dessa delars massor inkluderades istället i de stela kroppar de satt fästa vid. Eftersom Simulink modellerar system med punktmassor förändrade detta inte resultatet av simuleringen, utan resulterade endast i en enklare grafisk representation av frontlastaren.
Delsystemens fysiska parametrar inspekterades i Solid Edge. Tröghetsmomenten var angivna i tröghetstensorform, relativt en global referensram. För varje delkropp noterades massa, mass-centrum, tröghetsmoment, tröghetsprodukter och koordinater för ledaxlar till andra delkroppar. STL-filerna importerades därefter till Simulink som solider. Med hjälp av den noterade fysika-liska datan kunde soliderna modelleras med samma fysikafysika-liska egenskaper som de hade i Solid
Edge ST8, se Fig 7.
Figur 7 – Redskapshållare modellerad som solid i Simscape Multibody med fysikaliska tröghets-parametrar från Solid Edge ST8.
Varje solid och dess tillhörande transformer fick utgöra ett eget subsystem. Genom referens-ramstransformer kunde kontaktpunkter för sammankoppling av dessa subsystem definieras, se Fig 8.
Figur 8 – Transformer definierade kontaktpunkter med angränsande solider. På vänster sida är in-kommande kontaktpunkter med tilt-cylindrar och lastararm, på höger sida utgående kontaktpunkt med redskapet.
De rörliga lederna mellan soliderna modellerades med revolute- och prismatic joints, se Fig 9.
Figur 9 – Solider sammankopplade via stela transformer och joints. I figuren ser man att ”Tool carrier” kan rotera via två revolute joints mot lastararmen ”Loader arm”. Kontakten mot redskapet är modellerat med en stel transform.
3.5 Utveckling av hydraulisk modell 3.5.1 Hydrauliska cylindrar
Med hjälp av Simscape Fluids modellerades det hydrauliska systemet enligt dokumentation och hydraulschema tillhandahållet av Ålö. Både hydraulcylindrar och LS-ventiler förekom upprepade gånger och därför utvecklades modulära komponentblock för dessa komponenter, se Fig 10. Komponentblocken sparades i ett eget bibliotek.
Figur 10 – Det hydrauliska cylinderblocket. Dessa block utgjorde gränssnittet mellan den hyd-rauliska och den mekaniska domänen, vilket färgerna gult respektive grönt illustrerar.
I plantmodellen användes hydraulcylinderblocket för att modellera både höger och vänster hydraulcylinder i subsystem för både lift och tilt , se Fig 11. Värden för kolvdiameter, gavel-diameter, slaglängd, initialposition, initialtryck i kammare samt koefficienter för styvhet och dämpning i cylinderns ändlägen lades in som justerbara variabler i blockets mask. Initialtryck i kammare valdes experimentellt genom att notera vilka trycknivåer kammarna stabiliserade sig vid i början av simulering.
Figur 11 – Hydraulcylinderblocken i subsystemet för liftcylindrarna. Specifika parametrar angavs som inparametrar. Ett likadant subsystem skapades för tiltcylindrarna.
3.5.2 LS-ventiler
LS-ventilerna modellerades med variabla öppningsareor för varje möjlig flödesriktning i ventilen efter ett internt hydraulschema från Ålö, se Fig 12.
Figur 12 – LS-ventil.
Öppningsareorna reglerades genom styrsignalens signal-area öppningsvektor som angivits som inparameter i masken till komponenten. För varje öppningsarea angavs en unik vektor
(Pump till A). LS-funktionen i ventilen fungerade på så vis att en variabel öppningsarea (A-LS eller B-LS) öppnades maximalt så fort den motsvarande variabla öppningsarean (P-A eller P-B) öppnades. Beroende på om det var P-A (Pump till A-sida) eller P-B (Pump till B-sida) blev det en lika hög trycknivå vid skyttelventilen till höger som den trycknivå lasten orsakade. En strypning till tank agerade ”pulldown”, vilket medförde att tryckfallet blev väldefinierat, något som LS-regulatorblocket (ej i figur) inte kunde åstadkomma.
Ventilerna placerades i ett block för MVU, se Fig 13. Unika signal-area öppningsvektorer angavs för varje ventil. Även här användes en skyttelventil för att välja det största lasttrycket som LS-signal ut till LS-regulatorblocket. En backventil användes för att undvika att baktryck i den alternativa vägen till tank i ”Tbackup” uppstod.
Figur 13 – Subsystemet för MVU’n innehöll modulära LS-ventiler för Lift och Tilt.
3.5.3 Lastkännande hydraulpump med PI-regulator
Vid modellering av hydraulpumpen beräknades först parametrar så som deplacement utifrån givna nominella flöden och varvtal. Hydraulpumpens lastkännande funktion var inte möjlig att modellera med de block som fanns tillgängliga i Simscape Fluids. Därför skrevs ett eget Simscape komponentblock för en tryckstyrande LS-regulator. Komponentblocket agerade som en flödesreglerande variabel shunt från pump till tank. Shuntens strypning reglerades med en PI-regulator. Komponentblocket beskrevs utifrån ett antal ekvivalenser och själva blocket blev i praktiken ett ekvationssystem. Med LS-signalen från LS-ventilen som insignal sattes börvärdet till LS + ∆P . För att öka pumptrycket ökades strypningen och för att sänka pumptrycket sänktes strypningen.. Regulatoralgoritmen inkluderade en övre och undre begränsning av styrsignalen samt skydd mot integratoruppvridning.
PI-regulatorns parametrar valdes genom att först endast aktivera och ställa in proportionell verkan. Testning utfördes tillsammans med resten av plantmodellen under kombinationer av lyftning, sänkning och tiltning. Den proportionella parametern valdes så att den kunde justera shuntens strypning såpass mycket att hela det nominella flödet kunde shuntas vid maxtryck. Därefter lades en integrerande verkan till för att eliminera fel som annars kvarstod. Olika värden testades fram och valdes så att den integrerande delen svarade snabbt och utan översläng. 3.5.4 Sammankoppling av mekanisk och hydraulisk modell
Det mekaniska och det hydrauliska systemet kopplades samman så att det hydrauliska systemet kunde applicera kraft på det mekaniska systemets joints via hydraulcylindrarna. Rörelsehastig-het från det mekaniska systemets joints återkopplades i sin tur till det hydrauliska systemets
hydraulcylindrar. Sammankopplingen skedde mellan de hydraulcylinderblock och de prismatic joints som motsvarade respektive hydraulcylinder i den mekaniska modellen.
3.6 Val av solver i MATLAB
Eftersom plantmodellen endast skulle köras på Ålös datorer behövde inte någon C-kod för plant-modellen genereras. Endast när C-kod ska genereras finns krav i Simulink på att solvern måste använda diskret solver med statiskt tidssteg. Systemets egenskaper analyserades med Solver Profiler och olika lösningsmetoder testades och jämfördes. Jämförelserna utfördes vid olika tole-ransnivåer. Både adaptiv och icke adaptiv algoritm för behandling av nollgenomgångar testades och jämfördes sett till exekveringstid och fel.
3.7 Verktyg för felsökning och optimering av exekveringstid
Optimering och felsökning av modellen gjordes till stor del med det inbyggda verktyget Simulink Solver Profiler. Solver profiler visar bland annat en graf över alla lösningssteg för systemet, där steglängd samt eventuella undantag från lösningskrav solvern varit tvungen att göra illustreras. Dessa undantag benämns ”solver exceptions”. Olika typer av exceptions så som nollgenomgångar, solver resets och Newton iteration exceptions plottas med olika färger samt går att filtrera efter komponentblock. Med Solver Profiler blir det det enklare att identifiera vad som orsakar problem vid specifika tidpunkter i simuleringen, se exempel i Fig. 14.
Figur 14 – Exempel där simuleringen kraschat efter t=15s. Med Simulink Solver Profiler kunde felorsaken identifieras genom att filtrera ut vilket block som gav upphov till ett solver exception precis innan kraschen (den röda pricken precis vid t=15s).
3.8 Automatiserad mjuk nedställning av material
Funktionen för automatiserad nedställning skulle låta operatören i hytten manuellt påbörja nedställning av material och när materialet tog i underlaget så skulle styrfunktionen automatiskt avsluta nedställningen. Operatören skulle alltså inte själv behöva avgöra när materialet nått marken eller underlaget.
3.8.1 Kontakt med underlag
Testmaterial och kontakt med ett underlag i form av mark modellerades i Simscape. Transla-tionsrörelsen mellan material och mark utgjordes av en cartesian joint och ett hard stop med en
Figur 15 – Kontakt mellan redskap och mark modellerades med en cartesian joint och ett fjäder-dämpar system.
En Cartesian joint är en led beståendes av tre ortogonala prismatic joints och möjliggör därmed obegränsad translation i tre dimensioner. Ett hard stop definierar en övre och en undre gräns för den translaterande rörelsen. Gränserna utgjordes av var sin fjäder och dämpare. Ef-tersom en kollision av material med marken både i teorin och i Ålös testkörningar inte varit helt stum ansågs en fjäder och en dämpare kunna modellera detta fenomen. För att hitta rimliga fjäder- och dämparkonstanter prövades olika värden i simuleringen och jämfördes med tryck och positionsdata från Ålös testkörningar tills de såg ut att stämma överens med varandra. Gräns-snittet mellan den mekaniska ramdomänen och den mekaniska translationsdomänen utgjordes av en omvandling mellan kraft och translationrörelse enligt Fig 16.
Figur 16 – Gränssnittet mellan ramdomän och translationsdomän.
3.8.2 Detektering av kollision
De tillgängliga sensorerna på frontlastaren undersöktes. Det satt en trycksensor på vardera sida av liftcylindrarna. Den övre sidan kallades A och den nedre sidan kallades B. Vid infästningarna för både lift och tilt satt det vinkelgivare. Joystickens kommandon fanns också tillgängliga att läsa av. Eftersom rörelsen ned mot mark skulle kunna ske med både varierande last och kom-mando från operatör ansågs det rimligt att använda data från flera sensorer samtidigt för att få så korrekt detektering som möjligt. En ökning av tryck i liftcylinder skulle till exempel kunna innebära att materialet tagit i marken och att nedsänkningen därför borde avslutas, men lika väl endast att operatören givit kommando om en snabbare nedstyrning. Om data från flera olika typer av sensorer användes skulle det gå att undvika sådana felaktiga utslag. I fallet i exemplet
så skulle en hastighetsestimering av vinkelgivaren på liftsidan kunna visa att anledningen till att trycket ökat mest troligt endast berodde på att hastigheten nedåt ökat - inte att materialet tagit i marken.
Sedan tidigare fanns det loggfiler tillgängliga där Ålö hade testat att ställa ned material på marken med frontlastare på en riktig traktor. Sensordata från vinkelgivare och tryckgivare på lift fanns med i dessa loggfiler. Loggar fanns från frontlastare både med och utan lastdämp-ningsfunktion. För att få en bättre bild av hur sensorerna reagerade vid kollision analyserades och plottades data från loggarna, se Fig 17 för tryckdata och vinkeldata från en av de flera körningarna.
Figur 17 – Data från liftcylindrarnas tryckgivare och liftsidans vinkelgivare vid Ålös testkörning ned i marken av verklig frontlastare med material. Ingen traktorfjädring eller lastdämpning var aktiverad på lastaren. Den första pilen visar hur kontakt med mark först märktes på tryckgivaren i och med att trycket på A-sidan sjönk kraftigt och snabbt. Vid den andra pilen har kommando för nedsänkning avslutats och vid den tredje pilen påbörjas lyft. Vid den fjärde pilen har trycket vid A-sidan snabbt spikat upp till strax över normalnivå.
Datat visade att snabba tryckförändringar uppstod vid första markkontakt men att vinkelgi-vardatat relativt obehindrat fortsatte nedåt en bit innan sänkkommandot avslutades. Kollisionen var alltså inte stum utan det fanns en dämpande effekt. En mindre fjädrande effekt kunde också noteras. Eftersom det uppstod så snabba förändringar av både tryck och vinkelposition under
3.8.3 Jämförelse med Ålös loggar från traktor i verkligheten
Ålös loggar från där en traktor i verkligheten ställt ned material på marken jämfördes med hur plantmodellen svarade på att styras ned i marken. Simuleringen konstruerades så att den skulle efterlikna testerna i riktig traktor så mycket som möjligt. Differenstryck över hydraulcylindrarna och vinkelpositioner jämfördes.
3.8.4 Detekteringsalgoritm
Genom att både studera Ålös loggar och eget simuleringsdata från när plantmodellen på olika vis styrde ned material i marken utvecklades en detekteringsalgoritm. Vid kollision med marken uppstod det i båda fall alltid en vinkelretardation, det vill säga
˙
ω < 0 (9)
Utöver det uppstod en av två saker. Låt Pinit vara initialtrycket över liftcylindern då regler-funktionen aktiveras för nedställning av material. Vid kollision så spikade då antingen tryckför-ändringshastigheten negativt proportionerligt till initialtrycket och uppfyllde
˙
P ≤ αPinit (10)
där α valdes genom att jämföra loggar från simuleringar med olika sätt att ställa ned material. Olikheten uppfylldes om lastaren styrts ned med någorlunda konstant styrsignal. Om styrsigna-len varit ryckig kunde det uppstå situationer där ˙P inte gav lika stort utslag. I de fallen kunde en kollision ändå detekteras genom att titta på hur mycket trycket över liftcylindern minskat sedan påbörjad nedställning enligt
P ≤ βPinit (11)
där β också valdes genom att jämföra simuleringar. För att kunna detektera kollision med underlag i båda fall konstruerades två sammansatta villkor som båda kunde ge detektionsutslag. Båda villkoren kombinerade den vinkelolikhet i (9) som alltid uppstod med var sin tryckolikhet i (10) och (11). Villkoret som innehöll (10) kompletterades med att även inkludera en mindre tryckolikhet för att undvika falska utslag enligt (12).
P ≤ γPinit, γ > β (12)
Utöver att dessa villkor skulle uppfyllas så krävdes det att en aktiveringsflagga för funktionen var satt hög samt att joystickens nuvarande kommando var att sänka liftsidan för att algoritmen skulle ge utslag. Algoritmen för kollisionsdetektering implementerades enligt Fig 18.
Figur 18 – Algoritm för detektering av kollision.
3.8.5 Hastighetsestimering
Om förändringshastigheten av liftcylinderns differenstryck och vinkelacceleration skulle kunna användas för detektering av kollision skulle de behöva estimeras på något sätt. Ett Simulinkblock för hastighetsestimering fanns tillgängligt sedan tidigare arbeten på Ålö. Blocket tog en diskret signal in och gav ut ett uppskattat värde av dess förändringshastighet. Blocket hade bland annat en filterkoefficient som kunde justeras för att balansera störningsdämpning och fördröjning. Flera instanser av blocket kunde seriekopplas och på så vis kunde även en uppskattad acceleration erhållas. Blocket var utvecklat med diskreta block. Ett subsystem där samtliga estimeringar utfördes konstruerades, se Fig 19.
Figur 19 – Subsystem för estimering av förändringshastighet av differenstryck samt vinkelacce-leration.
3.8.6 Signalbehandling
Vid utvecklingens början undersöktes storleken på bruset från givarna i Ålös loggar. Storleken på bruset ansågs betydelsefullt eftersom estimeringsblocket skulle derivera signalen. Om någon
nalerna var därför relativt brusfria. Det fanns dock mer brus i givarsignalerna jämfört med de ideala tryck- och vinkelsignaler som plantmodellen genererade. I simuleringsmodellen adderades därför vitt brus som bandbegränsats till givarsignalerna. Under simuleringar undersöktes det hur mycket brus som kunde tolereras samt hur estimeringsalgoritmens filterkoefficient kunde ställas in för att dämpa bruset samtidigt som ett tillräckligt snabbt resultat gavs.
3.8.7 Reglering
När en kollision detekterades kopplades joystickens styrsignal förbi och en snabb rampfunktion tog vid från den nivå joysticksignalen var på. Styrsignalen rampades ned till att ge stillastående kommando. Olika hastigheter på rampfunktionen testades för att erhålla snabb respons utan att allt för tvärt stänga ventilerna då detta orsakade oscillationer i trycknivåerna. Subsystemet för detektion och reglering visas i Fig 20.
Figur 20 – Subsystem för detektering av kollision och reglering.
Regleringen av styrsignal vid detekterad kollision visas i Fig 21.
Figur 21 – Styrsignalen rampades ned vid detekterad kollision.
3.8.8 Kombinering av kontinuerlig och diskret solver
För att den utvecklade reglerfunktionen skulle kunna användas för implementering i traktorns ECU var det ett krav att C-kodsgenerering i Simulink var möjligt. Funktionsalgoritmen skulle därför behöva använda en diskret solver, samtidigt som plantmodellen inte kunde simuleras med annat än kontinuerlig variabel solver. Detta löstes genom att låta reglerloopen med plantmodel-len ligga i ett huvudprojekt och i detta projekt endast inkludera modellreferenser till separata projekt med reglerfunktionens beståndsdelar. I de separata projekten kunde diskret solver använ-das. Genom att separera systemen på detta vis kunde plantmodellen simuleras med kontinuerlig solver med variabelt steg och reglerfunktionen simuleras med diskret solver.
Reglerblockets diskreta styrsignal till den kontinuerliga plantmodellen omvandlades från diskret till kontinuerlig tid med S-function blocket ”d2c”. Blocket konverterar en diskret signal med dis-kontinuiteter till kontinuerlig tid genom att approximera den diskreta signalen med en styckvis linjär interpolerad kurva.
4
Resultat
I tabell 2 visas de krav som ställdes i början av arbetet och om de uppfyllts eller inte. Tabell 2 – Resultat av kravspecifikation.
Krav nr Kravbeskrivning Prioritet Uppfyllt
1 Med en tidigare modell av frontlastare som utgångspunkt utveckla en komplett plantmodell i MATLAB Simulink för Ålös frontlastare Quicke Q5M med tillhörande hyd-raulik och mekanik
1 Ja
2 Utveckla en reglerteknisk styrsystemfunktion för auto-matiserad mjuk nedställning av material i MATLAB Si-mulink
1 Ja
3 Simuleringsmodell, inklusive reglerfunktion, ska kunna hantera nya indata med periodtid 10 ms på Ålös datorer
2 Ja
4 Maximal exekveringstid för reglerloopen tillåts vara 1 ms på Ålös styrsystem.
2 Nej
5 Reglerfunktionen ska vara stabil, ingen ryckighet ska upplevas vid test
3 Ja
6 All utveckling i Simulink ska följa Ålös interna regelverk ”Simulink Design Guideline”
3 Ja
7 Implementation och demonstration av reglerfunktionen i ett komplett styrsystem i en traktor i verkligheten
3 Nej
8 Dokumentation i form av examensrapport på svenska 1 Ja Krav 1 och 2 uppfylldes eftersom både en simuleringsmodell och en reglerfunktion utveckla-des. Krav 3 uppfylldes eftersom simuleringsmodellen, inklusive reglerfunktionen, kunde animeras i realtid på Ålös datorer. Krav 4 kunde aldrig utvärderas eftersom test i traktor inte hanns med. Krav 5 uppfylldes i och med att reglerfunktionen i simuleringen betedde sig mjukt. Reglerfunk-tionen testades dock inte i traktor i verkligheten. Krav 6 är uppfyllt eftersom designreglerna följdes. Krav 7 uppfylldes inte eftersom det inte fanns tid till att testa reglerfunktionen i traktor i verkligheten. Krav 8 uppfylldes i och med att en examensrapport på svenska skrevs.
4.1 Signalbehandling
Ett exempel på hur estimeringarna hanterade ett medelstort vitt brus adderat till vinkelgivarens utsignal, något större än det som noterats i Ålös loggar, visas i Fig 22.
Figur 22 – Jämförelse i simulering mellan sann hastighet, estimerad hastighet och estimerad acceleration givet vinkelposition. I graferna till höger har ett vitt brus med medeleffekt adderats till det första estimeringsblockets insignal. Brusets förstärks för varje derivering.
En jämförelse mellan den diskreta styrsignalen i reglerloopen ofiltrerad, filtrerad med diskret lågpassfilter med brytfrekvens 100 Hz, filtrerad med kontinuerlig överföringsfunktion motsva-rande lågpassfilter med brytfrekvens 100 Hz, samt omvandlad med d2c-blocket visas i tabell 3. Relativ feltolerans var inställd på 0.1 %. Ur tabellen utläses att d2c gav lägst Run/Sim tidskvot, antal steg, solver resets, Newton iteration exceptions samtidigt som högst medelvärde stegstor-lek, max stegstorlek användning och näst lägst antal error exceptions. Eftersom simuleringarna gjordes med implicita solvers vars princip bygger på att utföra mer arbete varje steg än andra metoder är det viktigt att de i utbyte istället kan ta större steg. Höga värden för stegstorlek och max stegstorlek användning är därför önskvärt. Antalet solver resets, Newton itereration exceptions och error control exceptions önskas minimeras.
Tabell 3 – Jämförelse av simuleringsstatistik för olika behandlingar av den diskreta styrsignalen mellan kontrollblock och plantmodell.
Behandling styrsignal Ingen LP kontinuerlig LP diskret d2c
Run/Sim tidskvot 2.83 1.66 1.46 1.01
Antal steg 11217 6368 6368 5441
Medelvärde stegstorlek (ms) 2.67 4.71 4.71 5.51
Max stegstorlek (ms) 10 10 10 10
Max stegstorlek användning (%) 20.10 36.29 43.68 45.56
Antal solver resets 996 733 733 105
Antal Newton iteration exceptions 2518 1424 1424 1271
4.2 Lösning i Simulink
En implicit solver med variabelt tidsteg var tvunget att användas för att plantmodellen skulle kunna lösas korrekt. ODE23t erhöll snabbast simuleringstid vid jämförelse med den andra till-gängliga implicita solvern ODE15s, se tabell 4 och tabell 5. När den relativa feltoleransen ökas kan solvern ta större steg vilket ger ett högre medelvärde på stegstorlek. Det resulterar i färre steg, större stegstorlek, större användning av max stegstorlek och en lägre Run/Sim tidskvot.
Tabell 4 – Jämförelse mellan solvers där en nedställning av material simulerats under 30 sekunder med 1% relativ feltolerans.
Solver ODE23t (1%) ODE15s (1%)
Run/Sim tidskvot 0.86 0.99
Antal steg 4491 7596
Medelvärde stegstorlek (ms) 6.68 3.95
Max stegstorlek (ms) 10 10
Max stegstorlek användning (%) 61.70 0
Tabell 5 – Jämförelse mellan solvers där en nedställning av material simulerats under 30 sekunder med 0.1% relativ feltolerans.
Solver ODE23t (0.1%) ODE15s (0.1%)
Run/Sim tidskvot 1.01 1.09
Antal steg 5441 8886
Medelvärde stegstorlek (ms) 5.51 3.38
Max stegstorlek (ms) 10 10
Max stegstorlek användning (%) 45.56 0.12
Jämförelser där ODE23t med och utan adaptiv algoritm för nollgenomgångar testats visas i tabell 6 och 7. Den adaptiva algoritmen gav lägre Run/Sim tidskvot i båda fall och valdes att användas för plantmodell och reglerfunktion.
Tabell 6 – Jämförelse mellan adaptiv och icke adaptiv algoritm för nollgenomgångar där ned-ställning av material simulerats under 30 sekunder med 1% relativ feltolerans.
Algoritm nollgenomgång Adaptiv (1%) Icke adaptiv (1%)
Run/Sim tidskvot 0.86 0.95
Antal steg 4491 4534
Medelvärde stegstorlek (ms) 6.68 6.62
Max stegstorlek (ms) 10 10
Max stegstorlek användning (%) 61.70 61.14
Tabell 7 – Jämförelse mellan adaptiv och icke adaptiv algoritm för nollgenomgångar där ned-ställning av material simulerats under 30 sekunder med 0.1% relativ feltolerans.
Algoritm nollgenomgång Adaptiv (0.1%) Icke adaptiv (0.1%)
Run/Sim tidskvot 1.01 1.11
Antal steg 5441 5427
Medelvärde stegstorlek (ms) 5.51 5.53
4.3 Simuleringsmodell
Plantmodellen renderad i 3D visas i Fig 23.
Figur 23 – Plantmodellen renderad i 3D.
En bildsekvens från en 3D-simulering av plantmodellen med redskap påkopplat visas i Fig 24
Simulering av pumptryck, LS-signal och avvikelse från ∆P , där ∆P = 20, visas i Fig 25. Komponentkod för LS-shuntens komponentblock återfinns i Appendix A.
Figur 25 – LS-regulatorn styr pumptrycket till att eftersträva en trycknivå motsvarande LS-signal + ∆P , där ∆P = 20 bar.
Frontlastaren simulerades där den utförde fullt utslag på både lift och tilt i båda riktningar över en simuleringstid på 30 sekunder. Simuleringsstatistik för solver med 1 % och 0.1 % relativ feltolerans visas i Fig 26. Båda toleransnivåer gav en korrekt lösning av plantmodellen. Figuren visar att mindre steg tas vid t=0 oavsett relativ feltolerans, vilket resulterar i en simulering som där inte klarar att simuleras i realtid. Tabell 8 visar tillhörande simuleringsstatistik för Fig 26. Även om Run/Sim tidskvoten är över 1 för relativ feltolerans 0.1 % så var animeringen, efter insvängningsförloppet som i början höjer kvoten, ändå i realtid.
(a) Stegstorlek för relativ tolerans 1%. (b) Stegstorlek för relativ tolerans 0.1%. Figur 26 – Stegstorlek för simulering av frontlastaren med 1% och 0.1% relativ feltolerans.
Tabell 8 – Simuleringsstatistik plantmodell. Relativ feltolerans (%) 1 0.1
Run/Sim tidskvot 0.98 1.10
Antal steg 4169 6121
Medelvärde stegstorlek (ms) 7.20 4.90
En schematisk bild av hela plantmodellen i Simulink återfinns i Appendix B och hela den mekaniska modellen i Appendix C.
4.4 Automatisk nedställning
Frontlastaren med redskap, material och mark renderad i 3D visas i Fig 27.
Figur 27 – Frontlastaren med redskap, material och mark att ställa ned materialet på.
En bildsekvens från simulering där frontlastaren ställde ned material på mark visas i Fig 28
Figur 28 – Bildsekvens där frontlastaren ställde ned material och automatiskt stannade vid kontakt med marken.
Plantmodellen simulerades där den lyfte upp och sedan ställde ned 500 kg material automa-tiskt med hjälp av reglerfunktionen över en simuleringstid på 30 sekunder. Simuleringsstatistik för solver med 1 % och 0.1 % relativ feltolerans visas i Fig 29 och tabell 9. Eftersom den dis-kreta lösaren uppdateras var 10:e ms är också max stegstorlek 10 ms. Den variabla lösaren för plantmodellen tar ofta mindre steg än 10 ms, vilket går att utläsa av att användningen av max stegstorlek ökar vid högre feltolerans. Eftersom plantmodellen användes i reglerloopen höjs
(a) Stegstorlek för relativ tolerans 1 %. (b) Stegstorlek för relativ tolerans 0.1 %. Figur 29 – Stegstorlek för simulering av frontlastaren med reglerfunktion för automatisk ned-ställning med 1% och 0.1% relativ feltolerans.
Tabell 9 – Simuleringsstatistik för frontlastaren med reglerfunktion för automatisk nedställning med 1% och 0.1% relativ feltolerans.
Relativ feltolerans (%) 1 0.1
Run/Sim tidskvot 0.86 1.01
Antal steg 4491 5441
Medelvärde stegstorlek (ms) 6.68 5.51
Max stegstorlek (ms) 10 10
Max stegstorlek användning (%) 61.70 45.56
En jämförelse mellan icke reglerad och reglerad nedställning av material visas i Fig 30. Vid icke reglerad nedställning hålls styrsignalen konstant trots att materialtet tagit i marken vilket gör att differenstrycket P över liftcylindrarna går ned till negativt maxtryck och saturerar. I den reglerade nedställningen rampas styrsignalen ned till 0 vilket avslutar nedställningskommandot och P stabiliserar sig istället på en positiv normal nivå så som önskat. I båda figurer visas utöver trycket P även de två andra mätvärden från frontlastarens sensorer som algoritmen använder för att detektera kollision med underlag, ˙P och ˙ω. Vid kollisionen går trycket P ned till en mycket lägre nivå än tidigare och eftersom det går snabbt så visar ˙P en kraftig negativ spik. Vinkelgivarna visar också på en retardation eftersom ˙ω är negativ.
Figur 30 – Nyckelvariabler från två simuleringar där frontlastaren med 500 kg material styrts ned i marken, med och utan automatisk nedställningsfunktion aktiverad.
ned material med massa 0 kg, 100 kg, 500 kg och 1000 kg visas i Fig 31. I figuren visas det när en kollision detekteras och att kollisionsflaggan då sätts till 1. Z pos (lastens höjden över mark) ska då vara 0, vilket den är i alla fall förutom i grafen med 0 kg last. Vid nedställning av material under 75 kg gav detektionsalgoritmen i simuleringarna av plantmodellen mellan 2-23 mm för tidigt utslag. Desto lättare materialet var desto högre upp gavs det felaktiga utslaget. Vid detektion rampas styrsignalen ned till 0 och differenstrycket P över liftcylindrarna stabiliserar sig på en normal positiv trycknivå. Vid 100 kg last eller mindre tar denna stabilisering längre tid eftersom oscillationer i trycknivån uppstår, vilket visas i grafen med 0 kg last.
Figur 31 – Nyckelvariabler för reglerfunktionen när plantmodellen automatiskt ställt ned material med massa 0 kg, 100 kg, 500 kg och 1000 kg.
Nyckelvariabler för reglerfunktionen när den simulerade plantmodellen automatiskt ställt ned material med hög fart och med hög lastvikt visas i Fig 32. I båda fall visas det att kollision detekteras korrekt då Z pos = 0 och att P stabiliserar sig som önskat på en normal, positiv trycknivå.
Figur 32 – Nyckelvariabler för reglerfunktionen när plantmodellen automatiskt ställt ned material snabbt med massa 500 kg och medelsnabbt med massa 2000 kg.
Nyckelvariabler för estimerings- och detektionsalgoritmen applicerad på Ålös loggar från ned-ställning med riktig traktor visas i Fig 33. Algoritmen testades på loggar där material ställdes ned med både medelhög och långsam fart. Kollisioner vid medelhög fart detekterades korrekt eftersom kollisionsflaggan höjdes när P nått en låg nivå samtidigt som en negativ förändrings-hastighet ˙P och retardation i ˙w observerades. Vid låg fart detekterades inte någon kollision.
Figur 33 – Nyckelvariabler för estimerings- och detektionsalgoritmen applicerad på Ålös nedställ-ningsloggar från riktig traktor.
Algoritmen testades även mot loggar från nedställning med riktig traktor där en frontlas-tare med lastdämpning använts, se Fig 34. I dessa tester kunde inte någon kollision med mark detekteras vilket i figuren visas genom att kollisionsflaggan aldrig sätts till 1.
Figur 34 – Nyckelvariabler för estimerings- och detektionsalgoritmen applicerad på Ålös nedställ-ningsloggar från riktig traktor. Frontlastaren hade aktiverad lastdämpning.
5
Diskussion
5.1 Utvärdering av metoder och resultat
Genom att skapa och sedan återanvända komponentblock från ett eget Simscape library kun-de kun-det säkerställas att alla komponenter som skulle vara ikun-dentiska faktiskt också var kun-det. Det kunde annars lätt hända att någon liten ändring gjordes i ett av flera större block och sedan glömdes bort. En sådan bugg hade kunnat vara både svårupptäckt och tidsödande. Det hände också under utvecklingens gång att ändringar behövde göras på redan modellerade subsystem. Om ändringen endast behövde göras en gång i ett komponentblock i biblioteket gjorde det utvecklingen snabbare.
5.1.1 Mekanisk modell
Skruvar, slangar och vissa andra mindre icke rörliga delar valdes att inte exporteras från Solid Edge till Simulink. Anledningen till att de inte togs med var att dessa låg i separata assemblys och i så fall hade varit tvungna att modelleras som separata solider i Simscape. Detta hade gjort modellen mer tungkörd och inte tillfört något till frontlastarens beteende. Utvecklingen hade också tagit längre tid. Att den grafiska framställningen blev lite enklare ansågs därför vara en kompromiss värd att göra.
Quicke Q5M är i verkligheten konstruerad med ett mekaniskt tiltstopp som beror av liftvinkel och parallellföringsstag. Ingen mekanisk begränsning implementerades i simuleringsmodellen, all begränsning skedde i hydrauliken. Detta är en begränsning i plantmodellens överensstämmelse med verkligheten.
5.1.2 Hydraulisk modell
Eftersom flödesdynamik är såpass komplext kan en stor hydraulisk modell lätt bli tung att simu-lera. Det var därför viktigt vid hydraulmodelleringen att vara extra vaksam på vad som kunde försummas och inte. Hydraulslangar valdes att inkluderas eftersom det var viktigt att kunna mäta och utnyttja tryckskillnader i modellen vid funktionsutveckling. Däremot valdes den enk-laste modellen av slang, det resistiva röret, för att hålla komplexiteten nere. Det resistiva röret tog inte hänsyn till oljans kompressibilitet eller tröghet. Det gav en stor vinst i simuleringstid att välja enkla resistiva rör som slangmodell istället för den komplexa hydraulslangsmodellen som tar oljans kompressibilitet och tröghet i beaktning. Eftersom oljan ger upphov till så mycket mindre fjädring än vad övriga delar i systemet gör så borde det vara där förenklingar kan göras till liten kostnad av överensstämmelse med verkligheten. Båda slangmodellerna testades men ingen direkt visuell skillnad kunde urskiljas i rörelse eller trycknivåer. Trots det så skulle ett jämförelsetest med riktig traktor ändå behöva göras för att undersöka hur väl plantmodellen faktiskt beskriver systemet.
LS-pumpen valdes att regleras med endast PI-reglering. Eftersom regulatorn både följde bör-värdet och gav snabbt svar fanns det ingen anledning till att lägga till någon deriverande verkan, se Fig 25. Det fanns ingen specifik LS-styrning av pump som skulle efterliknas så beslutet föll på den metod som fungerade bäst i simuleringen.
5.1.3 Lösning i Simulink
ODE23t valdes som solver eftersom den gav bäst simuleringstid av plantmodellen samtidigt som lösningen blev korrekt, se tabell 4 och tabell 5. För detektions- och styrblocken i reglerfunktionen kunde inte någon annan solver än en diskret solver med statiska tidssteg väljas eftersom det är
