Embed Size (px)
Citation preview
Zagreb, lipanj 2010.
SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
ZAVRŠNI RAD br. 78
SIMULATOR PLOVILA TEMELJEN NA
MOOS-U
Tonči Milat
ii
iii
Zahvale
Dragom kolegi i prijatelju Draženu Popoviću, za pomoć pri otklanjanju grešaka i analizi koda.
Mojoj djevojci, roditeljima i ostalim prijateljima, za beskonačno strpljenje, podršku i ljubav
koju su mi pružili.
iv
Abstract
In this thesis a program used for mathematical modelling and simulation of various
underwater vehicles on remote machines is described. First, common types of these vehicles
are introduced. A generic six degrees of freedom model of their behaviour is developed.
Afterwards, a mission oriented operating suite known as MOOS, which serves as a cross
platform middle ware for robotics research, is introduced.
Using C++ programming language and various embedded functions of this platform,
mentioned model is implemeted in form of object-oriented computer code, enabling tests of
different control algorithms.
Different vehicle and enviroment configurations were used to explore possiblities of
the simulator, including parallel running of several different simulations simoultaneously.
Lastly, using an embedded logging feature of the MOOS platform, results of those
simulations were presented in MATLAB, after being parsed with an appropriate Python
script.
v
Sažetak
U ovom diplomskom radu opisan je program za modeliranje i simulaciju različitih bespilotnih
podvodnih plovila. Ponajprije, predstavljene su najpoznatije kategorije takvih plovila.
Razvijen je generički matematički model sa 6 stupnjeva slobode kojim se opisuje njihovo
ponašanje u vodi. Nakon toga predstavljen je obavljanju misija namijenjen operacijski softver
poznatiji kao MOOS, koji uobičajeno služi kao meĎuplatforma za razna robotska istraživanja.
Koristeći se C++ programskim jezikom i različitim ugraĎenim funkcijama platforme,
spomenuti je matematički model implementiran u obliku objektno orijentiranog računalnog
koda, kojim se omogućuje testiranje raznolikih upravljačkih algoritama za pojedine ronilice.
Različite su konfiguracije plovila i okoline korištene kako bi se ispitale mogućnosti
razvijenog simulatora, što je uključivalo i izvoĎenje više paralelnih simulacija istovremeno.
Konačno, koristeći se ugraĎenom aplikacijom za bilježenje rezultata simulacija u
MOOS-u, ishodi su pojedinih pokusa grafički prikazani u MATLAB-u, nakon što su
prethodno bili parsirani prikladnom skriptom za to napisanom u Pythonu..
vi
Sadržaj
Uvod ........................................................................................................................................... 1
1. Podvodna plovila ................................................................................................................ 3
1.1. Plovila upravljana na daljinu (ROV-ovi) ................................................................... 5
1.2. Autonomna podvodna plovila (AUV-ovi) ................................................................. 9
2. Matematički model ronilice ............................................................................................. 12
2.1. Modeliranje ponašanja krutog tijela u vodi .............................................................. 12
2.2. Modeliranje propulzije ............................................................................................. 19
3. Realizacija simulatora na MOOS platformi ..................................................................... 24
3.1. Povijest i karakteristike MOOS-a ............................................................................ 24
3.2. Struktura razvijene programske podrške .................................................................. 30
3.2.1. Realizacija matričnih operacija ........................................................................ 33
3.2.2. Realizacija opisa ponašanja krutog tijela u vodi .............................................. 35
3.2.3. Realizacija modela propulzije ronilice ............................................................. 42
3.2.4. Blokovi za odabir odredišta i upravljačke algoritme ....................................... 44
4. Testiranje rada simulatora ................................................................................................ 45
4.1. Metode bilježenja rezultata simulacije u MOOS-u .................................................. 45
4.2. Odabir parametara simulacije ................................................................................... 48
4.3. Grafički prikaz rezultata ........................................................................................... 51
4.4. Paralelno izvršavanje više simulacija ....................................................................... 55
Zaključak .................................................................................................................................. 57
Ključni pojmovi: ...................................................................................................................... 58
Literatura .................................................................................................................................. 59
vii
Popis slika
1-0-1 Podjela podvodnih plovila..................................................................................4
1-0-2-ronilica VideoRay Pro II s pripadajućom opremom.......................................7
1-0-3: Uobičajen izgled autonomnog podvodnog plovila.........................................10
2-1-1:Veza mobilnog i fiksnog koordinatnog sustava...........................................12
2-2-1:Najčešći raspored potisnika u pogonskom sustavu ROV-a........................19
2-2-2:Raspored potisnika ROV-a zaduženih za korizontalno gibanje................20
2-2-3:Potisnici ronilice VideoRay Pro II.................................................................21
2-2-4:Konfiguracija hidrodinamičkih aktuatora AUV-a......................................23
3-1-1:Topologija MOOS-a........................................................................................25
3-2-1:Shema daljinskog upravljanja plovilom........................................................30
3-2-2-Općenita blokovska shema simulatora..........................................................30
3-2-3: Opis programske strukture simulatora........................................................31
3-2-4:Programska struktura simulatora u zvjezdolikoj topologiji.......................32
3-2-2-1: Princip rada MOOS aplikacije..................................................................36
0-3-1:AUV s početnom brzinom u x i z-smjeru (izranjanje).................................51
0-3-2:MiniROV sa različitim početnim brzinama pojedinih motora...................51
0-3-3:Rov Ronilica opće klase okreće se dok izranja.............................................51
0-3-4:MiniROV reguliran u klizećem načinu upravljanja....................................52
0-3-5:Podešavanje usmjerenja ronilice od (1,0,0) prema (2,-1,0).........................53
0-3-6:Moment oko z-osi stvoren u prethodnom manevru.....................................53
0-3-7: Rotacijska brzina ronilice tokom gornjeg manevra...................................53
0-3-8: Prijeđena udaljenost ronilice tokom reguliranog gibanja unaprijed........54
0-3-9: Brzina koju je ronilica postigla tkom reguliranog gibanja unaprijed......54
viii
0-3-10: Regulirani zaron ronilice na 10 metara dubine........................................54
0-3-11:Opterećenje aktuatora pri zaronu zbog lošeg upravljačkog algoritma...54
4-3-12:Provođenje paralelnih simulacija................................................................56
ix
Popis tablica
1-Karakteristike ronilice VideoRay Pro II..................................................................7
2-Oznake korištene za podvodna plovila....................................................................13
2-Sadržaj MOOS poruke.............................................................................................27
x
Popis korištenih kratica
ROV-plovilo upravljano na daljinu (Remote Operated Vehicle)
AUV-autonomno podvodno plovilo (Autonomous Underwater Vehicle)
MOOS-softver namijenjen obavljanju misija (Mission Oriented Operating Suite)
API-meĎuprogramsko komunikacijsko sučelje (Application programming interface)
DOF-stupnjevi slobode (degrees of freedom)
1
Uvod
Posljednjih pola stoljeća, rijetka su područja znanstvenog istraživanja koja se mogu
pohvaliti sličnom brzinom napretka kao što je to slučaj s robotikom. Donedavno, na spomen
robota prosječni bi se pojedinac mogao prisjetiti tek jedne njihove značajne primjene:
proizvodnih linija u tvornicama, gdje su se višezglobni roboti koristili za, primjerice,
sastavljanje automobilskih djelova, razvrstavanje različitih proizvoda ili obavljanje
jednostavnih zadataka poput bojanja ili zavarivanja.
MeĎutim, odnedavno je potpuno nova kategorija robota započela s do tada neviĎenim
napretkom: mobilni roboti. U navedenom razdoblju, oni su od nekolicine pojedinačnih
proizvoda korištenih u specifičnim vojnim ili znanstvenim primjenama dosegli razinu gotovo
svakodnevne upotrebe.
U spomenutu kategoriju mobilnih robota pripadaju i različita bespilotna podvodna
plovila, koja se sve češće koriste u istraživanjima teško dostupnih podmorskih lokacija,
obavljanju redovitog nadzora podvodnih postrojenja i/ili struktura, kao i u drugim misijama
različitog stupnja složenosti gdje bi uobičajeni ronilački timovi bili preskupi, odnosno gdje bi
ih bilo preriskantno koristiti.
Svim tim primjenama zajednička je jedna karakteristika, koja bespilotne ronilice, kao i
sve druge mobilne robote, izdvaja od robota prethodne generacije: oni ne rade u poznatom i
nepromjenjivom okolišu u kojem se od njih očekuje da obavljaju uvijek iste, jednostavne
zadatke. Upravo suprotno, oni često rade na potpuno nepoznatom terenu, gdje se zadaci koje
moraju obaviti mogu promijeniti u trenu, ali, što je daleko važnije, jamstvo da će sve biti
obavljeno uspješno bitno je manje nego u kontroliranom okruženju kao što je tvornica.
Unatoč strelovitom napretku, cijena pojedinog autonomnog plovila i dalje je visoka, pa bi
rizik od njegovog oštećenja ili gubitka trebao biti sveden na minimum. Upravo je to razlog za
razvoj simulatora takvih plovila, pomoću kojih se različiti upravljački algoritmi, konfiguracije
propulzora ili pak uvjeti okoline u kojima će se ronilica zateći mogli ispitati pouzdano i brzo,
bez da se sama ronilica (i po potrebi skupa oprema koju bi u stvarnom svijetu takoĎer bili
primorani koristiti) dovodi u ikakvu opasnost.
2
Dodatno, simulacija na računalu pruža nam mogućnost da korištenjem prikladne
programske potpore potrebna ispitivanja vršimo iz po volji udaljene lokacije, pri čemu
isključive preduvjete za uspješno testiranje predstavljaju pristup internetskoj vezi te kvalitetno
razvijen model koji bi obuhvatio sve bitne karakteristike, kako plovila kojim želimo
upravljati, tako i okoline u kojoj to upravljanje želimo vršiti (pritom ne mislimo samo na
fizičko okruženje plovila već i, primjerice, komunikacijsko kašnjenje izmeĎu njega i
operatera).
Cilj je ovog diplomskog rada bio razvoj upravo jednog takvog modela, koji bi
predstavljao simulator plovila temeljen na MOOS-u, tj. na platformi zasnovanoj na C++
programskom jeziku koja se često koristi za istraživanja u području robotike.
Pogodnosti korištenja MOOS-a uključuju, meĎu ostalim, upravo mogućnost daljinskog
povezivanja s razvijenim modelom, što znači da jednom stvoreni program možemo koristiti s
bilo kojeg računala s pristupom internetu. Štoviše, arhitektura MOOS-a omogućuje, kao što
će biti pokazano, paralelan pristup željenom modelu od strane nekoliko klijenata, koji isti
osnovni program mogu koristiti u različite svrhe, u rasponu od testiranja jedne te iste ronilice
u različitim uvjetima, pa do slanja potpuno novih konfiguracija i njihova predispitivanja, čak i
prije nego što je stvarna, fizička verzija pripadajućeg plovila uopće i proizvedena.
Na taj način, razvoj novih autonomnih plovila i njihovih simulatora mogu se uzajamno
potpomagati. Takav paralelni razvoj dovodi ne samo do sve realnijih i preciznijih simulatora,
nego i do sve učinkovitijih i kvalitetnijih plovila.
U nastavku ovog rada bit će opisan sam matematički model koji je na MOOS platformi
realiziran. Mogućnosti samog modela bit će ilustrirane slikama napravljenima u programskom
paketu MATLAB™, a koje su dobivene na temelju rezultata različitih simulacija prikupljenih
pomoću odgovarajućih funkcija za bilježenje istih, integriranih u samoj programskoj
platformi.
Tamo gdje je to bilo nužno, djelovi koda su izdvojeni i dodatno pojašnjeni dok se u svojoj
cjelovitoj inačici mogu pronaći na disku priloženom uz ovaj rad.
Kao što je naglašeno, glavna je namjena ovdje opisanog simulatora mogućnost ispitivanja
različitih upravljačkih algoritama za pojedina podvodna plovila. Jednom kada se pojedini
algoritam pokaže učinkovitim u virtulanom okruženju, može se pristupiti njegovom korištenju
u stvarnom svijetu. Stečena saznanja mogu se potom koristiti za preinaku parametara modela i
na taj način iterativno usavršavati kako samu simulaciju , tako i plovilo kojem je namijenjena.
3
1. Podvodna plovila
Povijest ljudskih aktivnosti pod vodom započinje i prije nego što su ikakva tehnička
dostignuća omugućila današnje opsežne i dugotrajne misije. Lovci na koralje i bisere od
najdavnijih su se vremena služili ronjenjem na dah pri bavljenju svojim zanimanjima.
MeĎutim, dubine koje su čak i najsposobniji pojedinci mogli doseći na ovaj način bile
su ograničene jednostavnom činjenicom: ograničenim kapacitetom ljudskih pluća. Prve
metode kojima bi se čovjekov boravak pod vodom mogao produžiti pojavile su se tokom
razdoblja antičke Grčke, i redom su to bila različita zvonolika pomagala koja su omogućavala
,,roniocu'' već zalihu zraka.
Značajnije korištenje ovakvih naprava nastavilo se u renesansi, pa sve do kasnog 18.
stoljeća i razvoja prvih podmornica. Uslijedio je i razvoj ronilačkih odijela, regulatora i boca s
kisikom. No, istovremeno je uočena i pojava kesonske bolesti, izazvane dekompresijom pri
zaronima na veću dubinu.
Spomenuti je problem dodatno potpomogao kasniji razvoj bespilotnih ronilica, budući da
se njihovim korištenjem moglo uštedjeti na kompliciranim postupcima izranjanja i tretmana
posada pojedinih podvodnih plovila nakon povratka na površinu (dekompresijske komore).
Unatoč tome, sve donedavno, tj. do postizanja značajnijeg napretka u području robotike
posljednjih desetljeća, većina je podvodnih plovila zahtijevala barem jednog člana posade, a
mnogo češće i puno veći broj.
Prve ronilice bez posade pojavile su se tek sredinom prošlog stoljeća, točnije 1948. kada
je Auguste Piccard poslao svoj batiskaf, FNRS-2, na nekoliko uzastopnih zarona.
U meĎuvremenu, razvoj je podmorskih plovila bio motiviran dvama ciljevima: vojnim i
istraživačkim. Tako su u drugom svjetskom ratu podmornice odigrale značajnu ulogu u
pomorskim obračunima na Atlantiku i Pacifiku, dok su se 60-ih godina Jacques Piccard i Don
Walsh batiskafom Trieste spustili na dno Marijanske brazde, najdublju poznatu točku u
Tihom oceanu.
S daljnjim tehnološkim otkrićima napokon se došlo i do toga da bespilotne ronilice u
velikom broju različitih zadataka mogu učinkovito zamijeniti bilo ronioce, bilo podmornice.
4
U skladu sa svim gore navedenim, podvodna se plovila u današnje vrijeme mogu
podijeliti u dvije značajne kategorije: ona koje su zadržale ljudsku posadu, tj. podmornice, te
različite bespilotne ronilice koje se mogu podijeliti u nekoliko dodatnih kategorija, kao što je
prikazano na Slici 1-1:
Slika 1-1 Podjela podvodnih plovila
Ovaj će se završni rad baviti potonjom kategorijom, plovilima bez ljudske posade
(ronilicama), i to sa dvije značajne kategorije istih: AUV-ovima1, autonomnim podvodnim
vozilima, te ROV-ovima2, plovilima upravljanima na daljinu. U sljedećem potpoglavlju bit će
izložene bitne karakteristike i razvoj obje navedene podvrste, a potom će se u nastavku rada
pristupiti opisivanju izrade matematičkog modela ovih dvaju ronilica, te načinu na koji je isti
realiziran na MOOS platformi.
1 eng. Autonomus Underwater Vehicles
2 eng. Remotelly Operated (Underwater) Vehicles
5
1.1. Plovila upravljana na daljinu (ROV-ovi)
Plovila upravljana na daljinu (u daljnjem tekstu ROV-ovi) podvodni su mobilni roboti
koji se koriste pri obavljanju širokog spektra zadataka pod vodom, kao što su istraživanje i
dokumentiranje, operacije spašavanja, pregledavanja podvodnih postrojenja, postavljanja
podvodnih kablova i mnoge druge.
Konvencionalni ROV-ovi uobičajeno se sastoje od velikog plutajućeg dijela na vrhu
aluminijskog kućišta, kako bi im se osigurao potrebni uzgon. K tome, za njihovo plutanje
često se koristi sintaktička pjena. Donji dio nalik je na sanjke i na njega se može priključiti
velik broj senzora različite namjene. Smještanjem lakših komonenti bliže vrhu, a onih težih na
dno osigurava se razmjerno velik razmak izmeĎu središta mase i središta uzgona. Ovakav
raspored jamči stabilnost i povećava robusnost ronilice pri obavljanju njene misije.
Kako bi se spriječila korozija zbog izloženosti morskoj vodi, električni su kablovi
unutar ronilice najčešće položeni unutar uljem ispunjenih cijevi, dok su potisnici usmjereni
smjeru svih koordinatnih osi kako bi se omogućila puna upravljivost.
Gore navedene konstrukcijske karakteristike odnose se ponajprije na radnu klasu
ROV-ova, dok oni manji mogu u različitom stupnju odstupati od navednih svojstava.
Ono što je zajedničko svim ROV-ovima je da zadržavaju vezu s površinskim plovilom
u obliku kabela koji ne samo da osigurava opskrbu ronilice električnom energijom, već služi i
za razmjenu podataka izmeĎu ronilice i operatera, bili to videozapisi koje ronilica snima,
vrijednosti koje mjere njeni senzori ili naredbe koje joj operater šalje.
ROV-ovi su u početku razvijani u vojne svrhe, a daljnja ulaganja u njih bila su
prvenstveno posljedica kontinuiranog rasta kada su u pitanju ulaganja u dubokooceanska
istraživanja ležišta nafte i plina. Sredinom 80-ih godina prošlog stoljeća došlo je do
privremenog zastoja u tehnološkom napretku uzrokovanog padom cijena nafte i globalnom
recesijom. MeĎutim, od tog vremena do danas razvoj se ponovno ubrzao i omogućio prodor
ROV-ova na nova područja primjene, kao što su oceanografija, ribarstvo i sigurnosne
operacije.
ROV-ovi su slobodno upravljivi od strane operatera (uzevši u obzir komunikacijsko
kašnjenje), ali su često unaprijed programirani da se kreću odreĎenom putanjom ili nadgledaju
odreĎeno područje. Uz potisnike koji im omogućuju navigaciju i pozicioniranje, uobičajeno
su opremljeni kamerama, hidrofonima (podvodnim mikrofonima) koji operateru omogućuju
6
da vidi i ( u nekim slučajevima) čuje što se dogaĎa s ronilicom, kao i mnoštvom raznolikih
senzora, koji ovisno o klasi ROV-a i njegovom zadatku mogu varirati, a najčešće uključuju
sonare, te senzore dubine i temperature.
Kao što je već istaknuto, ROV-ovi se dijele u nekoliko klasa. Najveće ronilice ovog
tipa pripadaju u uvodu poglavlja spomenutoj radnoj klasi, i upravljanje njima najčešće
zahtijeva veći broj operatera. ,,Posada'' takve ronilice u pravilu se sastoji od nadglednika,
pilota (operatera), te u nekim slučajevima kopilota. Općenito, upravljanje ovom klasom
ronilice zahtijeva od savakog od njih pozamašno iskustvo kao i poznavanje elektronike,
mehanike i hidraulike. Radna klasa najčešće se složene zadatke kao što su kopanje i polaganje
kablova na velikim dubinama, podvodni popravci ili izbavljanje većih objekata s morskog
dna. Zbog njihove velike mase, ove se ronilice u vodu obično polažu i iz nje podižu pomoću
prikladnih dizalica. Ova klasa nužan je i neizostavan alat za mnogobrojne inače teško
obavljive podvodne zadatke
Durug klasu čini ,,istraživačka'' ili ,,opća'' klasa. Iako veličinom manja od prethodne, u
stanju je obaviti mnoge podvodne zadaće, posebno one u kojima bi radna klasa zbog svoje
veličine imala problema s manevriranjem, ili jednostavno predstavljala prevelik trošak resursa
i ljudstva. Stoga se opća klasa često upotrebljava za pregledavanje cjevovoda, brodova, lučkih
pristaništa, arheološka istraživanja ili akcije potrage i spašavanja na moru. Većinom je za
upravljanje ovom klasom dovoljan tek par iskusnih operatera, što poslove može učiniti
lakšima i jefitinijima.
Konačno, treću klasu Mini/Micro ROV-ovi: kao što im i ime ukazuje, riječ je o
najmanjoj klasi, kako veličinom tako i težinom (do 3 kilograma za Micro, odnosno do 15 kg
za Mini ROV-ove). To znači da pojedinačni operater može čitav ROV-sustav ponijeti sa
sobom na manjem plovilu, i potom obavljati zadaće samostalno bez ikakvih problema. Ovo je
pogodno za mnoge primjene, a pristupačna cijena ovakvih operacija znači da ova kategorija
predstavlja izvrsnu alternativu ronilačkim posadama.
7
Upravo jedana takva ronilica bit će simulirana i u ovom završnom radu, konkretno
VideoRay Pro II, prikazana na donjoj slici:
Slika 1-2-ronilica VideoRay Pro II s pripadajućom opremom
Njene su karakteristike navedene u sljedećoj tablici:
Tabela 1-Karakteristike ronilice VideoRay Pro II
TEHNIČKE KARAKTERISTIKE
Operabilna dubina 0 – 150 m
Brzina 0-2 čvora
Dimenzije: 355 mm (duljina)
228 mm (širina)
215 mm (visina)
Težina 4 kg
Kućište Anodizirani 6061 T6 aluminij
Operabilni temperaturni raspon 0-40 º C
Napajanje 110-220 V, 50-60 Hz
POGONSKI MOTORI
Horizontalni 1 na lijevoj i 1 na desnoj strani plovila
Vertikalni 1 posred plovila
8
Vrijedi izdvojiti da VideoRay uobičajeno raspolaže sa jednom kamerom – onom
prednjom s rasponom zakreta od 170°, no opcionalno se može dodati još jedna, usmjerena
prema natrag, i opremljena vlastitim izvorima svjetlosti. Prednja kamera ima nekoliko
različitih dodatnih podesivih parametara, kao što su osjetljivost na svjetlo i rezolucija.
TakoĎer, ronilica posjeduje visok stupanj modularnosti što znači da je na nju moguće
dodati raznoliku i mnogobrojnu dodatnu opremu. U uobičajenu opremu ronilice spadaju još i
kompas i dubinski senzor, a tim se standardnim ureĎajima mogu još dodati i sonar, kao i drugi
senzori (primjerice temperaturni, ili pak detektori saliniteta). Težine oko 4 kilograma,
uobičajeno je da ovakva ronilica može obavljati misije do dubine od 150 metara (500 stopa).
Način na koji se gore navedeni parametri ronilice predaju simulatoru bit će objašnjen u
narednim poglavljima. Kako bi se simulacijom dobili što točniji rezultati, potrebno je dakako
uvažiti i utjecaj sve dodatne opreme na njih (posebno u obzir treba uzeti masu, središte
uzgona ronilice, moguću promjenu dimenzija i dr.)
Uz nju, simulacija će biti vršena i za jednu od ronilica opće klase, mase 145
kilograma. Ovime će se ukazati na mogućnosti simulatora da se koristi ne samo za provjeru
izvedbe već postojeće ronilice, nego i za predviĎanje ponašanja podvodnog plovila kojeg
možda tek želimo nabaviti, ali se ponajprije želimo uvjeriti da će se takvo ulaganje isplatiti te
će taj, drugačiji ROV biti u stanju obaviti pred njega postavljene zadaće.
Konačno, uz ROV-ove, dio će simulacija biti posvećen autonomnim podvodnim
plovilima, odnosno AUV-ovima, čiji će razvoj, povijest, primjena, kao i karakteristike i bitne
razlike u odnosu na prije opisanu kategoriju vozila upravljanih na daljinu, biti prikazani u
sljedećem potpoglavlju. Nakon što se ukaže na sličnosti, iduće će poglavlje biti posvećeno
kinematičkom i dinamičkom opisu ponašanja krutog tijela u vodi, dok će se propulzija, s
obzirom na bitne razlike koje mogu postojati meĎu navednim plovilima, analizirati u
zasebnom potpoglavlju.
Potom će, nakon što se ukratko upoznamo s platformom na kojoj je simulator razvijen,
biti prikazana realizacija tih dijelova matematičkih modela ronilica na samoj platformi.
9
1.2. Autonomna podvodna plovila (AUV-ovi)
Autonomna podvodna plovila (AUV-ovi) su robotski ureĎaji koji se površinom vode
ili ispod nje kreću uz pomoć potisnika upravljanih i usmjerenih pomoću računala, i to u sve tri
dimenzije. Ovakav način kontrole u većini zamislivih uvjeta omogućuje ronilici da precizno
prati predprogramiranu trajektoriju gdje god i kad god se to od nje traži. Kao i kod ROV-ova,
obraĎenih u prethodnom poglavlju, i AUV-ovi su najčešće opremljeni mnogobrojnim
dodatnim senzorima koji im pružaju mogućnost obavljanja mjerenja dok se kreću oceanom,
pri čemu korak uzorkovanja kojim se mjerenje vrši može biti ovisan bilo o vremenskom, bilo
o prostornom pomaku.
Senzorskim podatcima prikupljenima na ovaj način obično se automatski pridružuje
geoprostorna i vremenska referenca, i najčešće su sami podatci visoke kvalitete. Korištenje
većeg broja plovila može se upotrijebiti za povećavanje učinkovitosti ovakvih misija,
jednostavnije vremensko ili prostorno uzorkovanje, a samim time i način da se po prvi put
ispita ponašanje golemih vodenih masa u većim razmjerima.
Najveća razlika AUV-ova u odnosu na ROV-ove je stupanj slobode koji mogu postići
u kretanju pod vodom: oni nemaju nikakve fizičke veze sa svojim operaterom.
Povijesno, razvoj AUV-a potaknut je ponajprije otkrićem torpeda[8]: dizajn, izgradnja
i demonstracija istog pripisuju se Robertu Whiteheadu, 1866. u Rijeci. Pogonjen
komprimiranim zrakom, ovaj je ureĎaj mogao dostići brzinu od 3 metra u sekundi i imao
domet od sedam stotina metara. Ukoliko se zanemari činjenica da je na vrhu nosio eksplozivni
naboj, mogli bismo ga smatrati prvim autonomnim podvodnim plovilom.
Dakako, današnji AUV-ovi nemaju za cilj udariti u neki predmet pod vodom, već,
upravo suprotno, izbjeći prepreke pri svom kretanju kroz ocean. Stoga se prvim pravim
plovilom ovog tipa može smatrati SPURV I, kojim se moglo akustički upravljati s površine, a
vrhunac je razvoja doživio tokom 70-ih godina prošlog stoljeća. Nakon kraćeg zastoja, interes
za AUV-ove ponovno je probuĎen oko 1990, dok su se na ulasku u treće tisućljeće pojavile i
prve komercijalne primjene za AUV-ove, konkretno nadzor dubokomorskih postrojenja.
Uobičajeno se pretpostavlja da će AUV operirati u području slobdnog oceana, gdje ne
postoji značajan broj prepreka koje bi ga spriječile da dovrši misiju: ovo omogućuje da se
sama putanja AUV-a odredi unaprijed pripremljenom računalnom skriptom.
10
Tipičan izgled modernog autonomnog podvodnog plovila prikazan je na sljedećoj slici
(Slika 1-3 ):
Slika 1-3: Uobičajen izgled autonomnog podvodnog plovila
Na njoj je AUV prikazan u stanju u kojem će najčešće biti tokom obavljanja misije: u
pokretu. No, to ne znači da on ne može poslužiti i kao plutajuća ,,platforma'', s time da se u
ovakav način rada ronilica može dovesti bilo programiranjem gašenja potisnika pri dosezanju
željene dubine (ili, primjerice, podvodnog sloja vode odreĎene gustoće), bilo ostavljanjem
potisnika u aktivnom stanju, pri čemu se održava položaj u neposrednoj blizini željene
lokacije. TakoĎer, AUV-ovi mogu biti programirani da plove konstantnom brzinom ili
održavaju konstantnu dubinu dok istražuju podmorje, ili pak da se mijenjanjem neke od tih
varijabli kreću izlomljenom putanjom koja bi pružila uvid u različite horizontalne ili
vertikalne slojeve vode. Konačno, AUV-ovi se mogu poslužiti svojim akustičkim ili optičkim
senzorima za nadzor samog morskog dna.
Sve gore navedeno ukazuje na činjenicu da je je razvijanje kvalitetnih upravljačkih
algoritama za AUV-ove važan, ali i zahtjevan zadatak. Upravo stoga razvoj prikladnih
simulatora kojim bi se opisalo ponašanje ove podvrste plovila u vodi ima potencijal za
mnogobrojne primjene.
U samu metodologiju upravljanja AUV-ovima u ovom se radu neće ulaziti. MeĎutim,
vrijedi istaknuti da stupanj autonomnosti koji će ronilici biti pružen predstavlja zanimljiv
optimizacijski problem: naime, potpuna autonomnost korisniku ne pruža nikakvu povratnu
informaciju o tome u kojoj je fazi misije ronilica niti kakvo je njezino stanje, a isto tako ne
pruža ni mogućnost upravljanja ili preusmjeravanja vozila tijekom same misije, ukaže li se za
11
tim potreba. S druge strane, ovakav pristup daje korisniku slobodu da se bavi drugim
zadatcima, na taj način uvelike smanjujući operativne troškove, dok god se misija obavi
uspješno i na vrijeme. Za pojedine zadatke, potpuna je autonomnost jedini izbor; ukoliko se
obavlja rutinska misija, veći stupanj autonomnosti se preferira-upravo za takve primjene
razvoj simulatora imat će najveću isplativost.
Dvosmjerni akustički ureĎaji, radio-frekvencije ili oblici komuniciranja zasnovani na
satelitskim vezama, pak, nude mogućnost da se prati i upravlja AUV-om iz bilo kojeg kutka
svijeta. Ova činjenica predstavlja najveću prednost poluautonomnih operacija nad potpuno
autonomnim.
Dodatno treba uzeti u obzir da prednost u pokretljivosti stečena činjenicom da ne
postoji kabel koji bi ograničavao kretanje ronilice dolazi i sa jednim značajnim nedostatkom:
ograničenjem trajanja misije na 8-50 sati, ovisno o tipu AUV-a. TakoĎer, činjenica da je izvor
energije za pokretanje na samom AUV-u, a propulzija nije jedini njegov dio kojem je ta
energija potrebna, znači da unatoč tome što AUV-ovi mogu postići brzinu do 2.5 metara u
sekundi, 1.5 metara u sekundi najčešće predstavlja optimalan izbor kada je u pitanju
obavljanje misije-pri toj brzini, zahtjevi na energiju od strane potisnika predstavljaju trećinu
ukupnog opterećenja.
Ovakvi zahtjevi mogu biti uzeti u obzir pri izradi odgovarajućih algoritama za
upravljanje, ili se može uvesti fizičko ograničenje maksimalne brzine koju stvaraju potisnici:
u ovom drugom slučaju, pri simulaciji se ovaj zahtjev može integrirati u dio simulatora koji
opisuje propulziju podvodnog plovila. Kao što će biti pokazano, ovaj dio simulatora napisan
je dovoljno generički da programiranje ovakvih, dodatnih, zahtjeva na model propulzora ne
predstavlja programeru nikakav problem.
Vrijedi istaknuti da dio koji opisuje propulziju nije preporučljivo iskodirati u obliku
koji doslovno opisuje pojedinu konfiguraciju, jer bi to značilo da svaka nova konfiguracija
koju želimo dodati znači mijenjanje i proširivanje izvornog koda, za razliku od dijela koji
opisuje dinamička i kinetička svojstva, a koji ovisi samo o parametrima ronilice, zadržavajući
istu matematičku formu.
Taj jedinstveni matematički model kojim se opisuje ponašanje ronilice (i, općenitije,
bilo kojeg krutog tijela u vodi) bit će stoga opisan u sljedećem poglavlju, dok će model
propulzije biti predstavljen sa nekoliko tipičnih primjera, ali za razliku od dinamike i
kinematike neće biti doslovno preslikan u simulator pomoću programskog jezika C++.
12
2. Matematički model ronilice
2.1. Modeliranje ponašanja krutog tijela u vodi
Pri upravljanju podvodnim vozilima najveći problem predstavljaju poremećaji te
nelinearnost i spregnutost samog sustava. Nerijetko se dinamika podvodnog vozila mijenja iz
misije u misiju, budući da potreba za različitim senzorima utječe na masu samog plovila i
njezinu prostornu raspodjelu. Stoga se kao nužnost nameće razvoj identifikacijskih algoritama
koji brzo mogu pružiti vjeran model sustava i na taj način omogućiti projektiranje regulatora.
Izrada matematičkog modela ronilice bitna je za projektiranje preciznog autopilota, AUV
(ROV) simulatora ili za predikciju ponašanja i performansi ronilice. MeĎutim, modeliranje i
kontrola podvodnih vozila je izuzetno je složen zadatak. Iako je dinamika podvodnih vozila
najčešće poznata, istovremeno je i neprikladna za većinu praktičnih primjena i ostvarivanje
jednostavnog upravljanja ROV-om. Razlog tome je izrazita hidrodinamička i inercijalna
nelinearnost, primjerice zbog postojanja podvodnih struja koje uvelike narušavaju željeno
gibanje ronilice.
Da bi se dobio što vjerniji prikaz ponašanja jednog tako složenog sustava, nužno je u
matematički model uključiti tri bitne komponente: nelinearnu karakteristiku upravljačkog
ureĎaja (u našem slučaju potisnika) te kinematiku i dinamiku same ronilice. Kako bi se
omogućilo povezivanje ta tri dijela, nužno je za ronilicu definirati dva različita koordinatna
sustava, mobilni koordinatni sustav koji se odnosi na samu ronilicu te fiksni koordinatni
sustav u odnosu na kojega se opisuje kretanje ronilice. Veza izmeĎu ta dva pojma prikazana
je slikom 2-1.
Slika 2-1-1:Veza mobilnog i fiksnog koordinatnog sustava
13
Kao što se vidi na gornjoj slici, za odreĎivanje pozicije i orijentacije krutog tijela potrebno
nam je 6 nezavisnih osi pa se stoga u modeliranju plovnih i podvodnih objekata raspravlja o 6
stupnjeva slobode.3Ti su stupnjevi slobode navedeni u donjoj tablici (Tabela 2), pri čemu se prve
tri koordinate i njihove derivacije odnose na translacijsko, a druge tri koordinate s pripadajućim
derivacijama na rotacijsko gibanje.
Tabela 2-Oznake korištene za podvodna plovila
Stupanj slobode Naziv Oznaka za sile i
momente
Oznaka za
linearne i kutne
brzine
Pozicije i
Eulerovi kutevi
1 Pomicanje u smjeru x-osi
(približavanje4) X u x
2 Pomicanje u smjeru y-osi
(pomicanje5) Y v y
3 Pomicanje u smjeru z-osi
(zaranjanje6) Z w z
4 Rotacija oko x-osi
(valjanje7) K p
5 Rotacija oko y-osi
(poniranje8) M q
6 Rotacija oko z-osi
(zaošijanje9) N r
3 eng. DOF-degrees of freedom
4 eng. surge
5 eng. sway
6 eng. heave
7 eng. roll
8 eng. pitch
9 eng. yaw
14
U daljnjoj analizi koristit će se sljedeći skraćeni zapis (indeks B odnosi se na mobilni
koordinatni sustav10, a indeks E na fiksni koordinatni sustav11):
1
TBv u v w.............................................................vektor linearnih brzina
2
TBv p q r.................................................................vektor kutnih brzina
TBv u v w p q r
......................vektor linearnih i kutnih brzina
1
TE x y z ........................................................................vektor pozicija
2
TE .........................................................................vektor kutova
TE x y z
...............................vektor pozicija i kutova
TE X Y Z K M N
.................................vektor sila i momenata
10 eng. body- fixed frame
11 eng. Earth-fixed frame
15
Vezu izmeĎu brzina u vlastitom koordinatnom sustavu tijela koje se giba (mobilnom
koordinatnom sustavu) te derivacija pozicije i kutova u koordinatnom sustavu vezanom za
referentnu točku (fiksnom koordinatnom sustavu) dat će nam kinematički model ronilice: uz
zadane brzine u mobilnom sustavu i početna stanja u fiksnom sustavu on glasi[1]:
( )J v (2-1-1)
Pritom jednadžba (2-1-1) u proširenom obliku glasi
1 2 3 31 1
3 3 2 22 2
( ) 0( )
0 ( )
EE B
E E Bx
EE B
x
J vJ v
J v
(2-1-2)
Komponente 1 2( )EJ i 2 2( )EJ u (2-1-2) pritom su:
1 2
cos cos sin cos cos sin sin sin sin cos cos sin
( ) sin cos cos cos sin sin sin cos sin sin sin cos
sin cos sin cos cos
EJ
(2-1-3)
te
2 2
1 sin tan cos tan
( ) 0 cos sin
sin cos0
cos cos
EJ
(2-1-4)
Iz jednadžbe (2-1-4) jasno se uočava da će za kut poniranja od 90° dva elementa matrice
biti nedefinirana. Dijeljenje s nulom koje se u ovom slučaju dogaĎa može kod različitih
zračnih i podvodnih vozila dovesti do pojave singularnosti.
Kad je riječ o dinamičkom modelu gibanja, odmah treba istaknuti da je on spregnut i
nelinearan, što je dijelom uzrokovano dinamikom tijela same ronilice, a dijelom
hidrodinamičkim utjecajima. U najopćenitijem obliku, nelinearne se dinamičke jednadžbe
gibanja mogu izraziti sljedećom jednadžbom:
( ) ( ) ( ) EMv C v v D v v g (2-1-5)
16
U jednadžbi s prethodne stranice navedene veličine su redom:
M- matrica inercije (uključujući dodanu masu)
C(ν) - matrica Coriolisovih i centripetalnih utjecaja (uključujući dodanu masu)
D(ν) - hidrodinamička matrica prigušenja
g(η) - vektor gravitacijskih sila i momenata
τ - vektor sila i momenata koji se javljaju kao rezultat propulzije plovila
E - vektor sila i momenata koje djeluju na plovilo uslijed vanjskih poremećaja
Matrice M i C(v) uobičajeno se razlučuju na dvije komponente:
RB AM M M (2-1-6)
( ) ( ) ( )RB AC v C v C v (2-1-7)
Razlog uvoĎenja ovih komponenti je analiza dinamike gibanja krutog tijela uz dodatno
uzimanje u obzir efekta dodane mase.
Kao što je navedeno u [2], uz definiciju vektora Gr kao vektora kojim se izražava za
centar gravitacije krutog tijela prema jednadžbi (2-1-8) , matrice inercije I prema jednadžbi
(2-1-9) te simetričnog matričnog operatora S prema jednadžbi (2-1-10), matrice iz jednadžbe
(2-1-5) definiraju se redom jednadžbama od (2-1-11) do (2-1-17) kao što slijedi:
B
g
B
g g
g
x
r y
z
(2-1-8)
0 0 0, 0
X XY XZ
T
YX Y YZ
ZX ZY Z
I I I
I I I I I I
I I I
(2-1-9)
17
0
0
0
a c b
S b c a
c b a
(2-1-10)
3 3
0
0 0 0
0 0 0
0 0 0( )
0( )
0
0
G G
G G
BG Gx G
RB BG G X XY XZG
G G YX y YZ
G G ZX ZY Z
m mz my
m mz mx
m my mxmI mS rM
mz my I I ImS r I
mz mx I I I
my mx I I I
(2-1-11)
1
11 12 3 3 1 2
21 22 1 2 1 0 2
0 ( ) ( ( )( )
( ) ( ( ) ( ( ) ( )
B B B
B x G
RB B B B B B B
G G
A A mS v mS S v rC v
A A mS v mS S v r mS S v r S I v
(2-1-12)
0 0 0 ( ) ( ) ( )
0 0 0 ( ) ( ) ( )
0 0 0 ( ) ( ) ( )
( ) ( ) ( ) 0
( ) ( ) ( ) 0
( ) ( ) ( )
G G G G
G G G G
G G G G
RB
G G G G ZZ YY
G G G G ZZ XX
G G G G
m y q z r m x p w m x r v
m x q w m z r x p m y r u
m x r v m z q u m x p y qC
m y q z r m y p w m z p v I q I p
m x q w m z r x p m z q u I q I p
m x r v m y r u m x p y q I
0YY XXq I p
(2-1-13)
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
u
v
w
A
p
q
r
X
Y
ZM
K
M
N
(2-1-14)
Elementi matrice AM odnose se na inducirane sile i momente proporcionalne ubrzanju
tijela.
18
3 3 11 1 12 2
11 1 21 2 21 1 22 2
0 0 0 0
0 0 0 0
0 0 0 00 ( )( )
0 0( ) ( )
0 0
0 0
w v
w u
B Bv uB x
A B B B Bw v r q
w u r p
v u q p
Z w Y v
Z w X u
Y v X uS M v M vC v
Z w Y v N r M qS M v M v S M v M v
Z w X u N r K p
Y v X u M q K
(2-1-15)
AC predstavlja matricu hidrodinamičkih Coriolisovih i centripetalnih utjecaja.
| |
| |
| |
| |
| |
| |
| | 0 0 0 0 0
0 | | 0 0 0 0
0 0 | | 0 0 0( )
0 0 0 | | 0 0
0 0 0 0 | | 0
0 0 0 0 0 | |
u u u
v v v
w w wB
p p p
q q q
r r r
X X u
Y Y v
Z Z wD v
K K p
M M q
N N r
(2-1-16)
( )BD v predstavlja hidrodinamičku matricu prigušenja (16) koja uzima u obzir efekte kao što su
potencijalno prigušenje, površinsko trenje, prigušenje uslijed valova, prigušenje uslijed potiska vodenog
vira i drugo.
( )sin( )
( ) cos( )sin )
( )cos( )cos( )( )
cos( )cos( ) cos( )sin( )
sin( ) cos( )cos( )
cos( )sin( ) sin( )
B B
B B
B B
W B
W B
W Bg
y B z B
z B x B
x B y B
(2-1-17)
Konačno, matrica ( )g predstavlja hidrostatičke sile gdje parametar W predstavlja težinu tijela
ronilice12
, a parametar B silu uzgona13
.
12 eng. weight
13 eng. buoyancy
19
2.2. Modeliranje propulzije
Za razliku od prehodnog potpoglavlja, koje je opisalo ponašanje zajedničko svim
podvodnim objektima pod utjecajem sila i momenata, u ovom se opisuje način na koji se tim
objektima upravlja, a koji može biti veoma raznolik, i stoga ga se ne može opisati
jednistvenim matematičkim modelom kojeg bi se dalo pretočiti u programski kod.
TakoĎer, kao što će biti prikazano, razvijeni simulator parametar uzgona (B) u
konfiguracijskoj datoteci prima kao konstantan, što znači da njime nije pokriven slučaj kada
se upravljanje vrši pomičnim balastom unutar ronilice. Ukoliko bi se željela dodati ova
funkcionalnost, bilo bi potrebno taj parametar izdvojiti iz konfiguracijske datoteke kojoj
simulator pristupa pri spajanju klijenta na server, i umjesto toga ga učiniti dodatnim
upravljačkim parametrom. Više o izgledu konfiguracijske datoteke bit će rečeno u
poglavljima koja se bave samom realizacijom simulatora.
Za sada, bit će istaknuti osnovni načini na koje se za dvije klase podvodnih plovila od
interesa, ROV-ove i AUV-ove, ostvaruje kretanje sa 6 stupnjeva slobode.
Započet ćemo s klasom koja je u ovom trenutku nešto zastupljenija, plovilima
upravljanima na daljinu.
Za konvencionalne ROV-ove osnovni je oblik kretanja onaj u horizontalnoj ravnini, s
nužnim promjenama koje zahtjeva zaron[7]. Za vrijeme takvog, jednostavnog kretanja kutevi
valjanja i zaošijanja najčešće su zanemarivi. Stoga se na ukupni pomak ronilice u prostoru
najčešće gleda kao na superpoziciju dvaju pomaka: u horizontalnoj i vertikalnoj ravnini.
Ovakvo nam razmatranje omogućuje da pogonski sustav ronilice razdijelimo u dva
neovisna dijela, pri čemu je svaki od njih zadužen za jedan od dva gore navedena pomaka.
Sljedeća slika (Slika 2-2-1) prikazuje najopćenitiji raspored potisnika kojim se takva
podjela ostvaruje:
Slika 2-2-1-Najčešći raspored potisnika u pogonskom sustavu ROV-a
20
Prvi dio u tom rasporedu čini jedan ili više potisnika koji generiraju silu u smjeru
vertikalne osi. Pritom potisak iz jednog propelera (ili suma potisaka iz više njih) moraju biti
jednaki traženoj sili potrebnoj za zaron/izron.
Drugi dio osigurava približavanje, pomicanje i zaošijanje, i obično ga čine 4 potisnika
rasporeĎena oko glavnih osi simetrije ronilice na način prikazan na slici 2-2-2:
Slika 2-2-2:Raspored potisnika ROV-a zaduženih za korizontalno gibanje
Sile koje djeluju u smjeru uzdužne i poprečne osi ronilice te moment koji se javlja oko
njene vertikalne osi kombinacija su potisaka proizvedenih od gornja 4 propelera. Veza izmeĎu
navednih sila i momenata te potisaka od strane pojedinih propelera složena je funkcija koja
ovisi o brzini plovila, gustoći vode, poprečnom presjeku plovila, promjeru propelera i
njegovom broju okretaja. U praktičnim primjenama, vektor u kojem se nalaze sile i momenti
koji djeluju u horizontalnoj ravnini može se opisati kao funkcija vektora pojedinih potisaka na
sljedeći način:
( )T Pf (2-2-1),
pri čemu je 1 2 3
T ,
1 -sila u smjeru uzdužne osi
2 -sila u smjeru poprečne osi
3 -moment oko vertikalne osi
21
Matrica T pritom je matrica konfiguracije potisnika, f vektor potisaka, a P dijagonalna
matrica dostupnosti potisnika (0 za nedostupne i 1 za dostupne).
Matrica T sljedećeg je oblika:
1 2
1 2
1 1 2 2
cos cos ... cos
sin sin ... sin
sin( ) sin( ) ... sin( )
n
n
n n
T
d d d
(2-2-2),
a u skladu sa slikom 2-2-2, i predstavlja kut izmeĎu smjera pojedinog potisnika i uzdužne
osi, id njegovu udaljenost od centra gravitacije ronilice, a i razliku izmeĎu kuta koji smjer
potisnika zatvara s uzdužnom osi i kuta izmeĎu uzdužne osi i spojnice centara gravitacije
ronilice i potisnika.
Nakon što je razmotren najopćenitiji mogući slučaj konfiguracije potisnika za ovaj tip
ronilice, prikazan će biti specifičan raspored koji se odnosi na VideoRay Pro II: njen je
pogonski sustav prikazan na donjoj slici:
Slika 2-2-3:Potisnici ronilice VideoRay Pro II
Kao što se vidi, ova ronilica Micro klase posjeduje jedan vertikalni potisnik koji stvara
potisak v , te samo 2 horizontalna potisnika s fiksnom orijentacijom. Indeksi s i P odnose
se pritom na potiske koje stvaraju desni i lijevi propeler. To znači da se sile i momenti koji
nastaju korištenjem ovakvog pogona mogu pojednostavljeno zapisati pomoću sljedećih
jednadžbi:
Z
N
x
100
0
011
RR
V
P
S
(2-2-3)
22
Ovakav, matrični zapis nastalih sila i momenata jedan je od načina na koji se oni mogu
opisati, ali iako će se u ostatku simulatora uvelike koristiti matrični operatori, u samom dijelu
koji opisuje propulziju može se izabrati proizvoljan način obavljanja proračuna, zahvaljujući
generički napisanom kodu. Bitno je samo da su po obavljenom proračunu svih 6 potrebnih
sila i momenata koji čine vektor jednoznačno odreĎeni, kako bi se njegove vrijednosti
mogle proslijediti sljedećem bloku.
Kompletiranje opisa propulzije ROV-a obavit ćemo uspostavom veze izmeĎu pojedinih
upravljačkih vrijednosti koje potisnici dobivaju i potiska koji u skladu s time generiraju.
Opis ponašanja potisnika može biti veoma složen, ali srećom pri malim brzinama kretanja
ronilice možemo se poslužiti sljedećim modelom, kojeg nazivamo afinim:
1 | |b n n (2-2-4)
U gornjem izrazu 1b je pozitivna konstanta, a n brzina okretanja propelera. Ovaj je izraz
pojednostavljenje složenijeg bilinearnog modela opisanog donjom jednadžbom:
1 2| | | |b n n b n u (2-2-5),
kojeg nazivamo bilinearnim, a koji u obzir dodatnim članom uzima i unaprijednu brzinu. Za
male brzine zanemarenje tog člana je opravdano.
Dodatno treba naglasiti da pri ovakvom opisu nije uzet u obzir značajan moment
valjanja oko x-osi koji nastaje kao posljedica činjenice da se propeleri oba horizontalna
potisnika okreću u istom smjeru.
Isto vrijedi i za ronilice tipa AUV sa 2 potisnika, a složenost njihovog modela dodatno
podiže postojanje kormila, te višestrukih upravljačkih površina. Stoga se za modeliranje ovih
plovila pribjeglo odreĎenim pojednostavljenjima, a aproksimacije koje su pri tom provedene
su, meĎu ostalima, da je umnožak dvaju pertubacija zanemariv, da je vrijednost kosinusa kuta
bliskog nuli jednaka 1, te da je vrijednost sinusa kuta bliskog nuli jednaka iznosu tog kuta u
radijanima. U konačnim izrazima, zadržana je jednaka struktura bloka koji opisuje ponašanje
tijela u vodi, ali su pojedini koeficijenti prilagoĎeni kako bi opisali i utjecaj ovih dodatnih
faktora. Detaljnije će njihove vrijednosti biti iznesene u poglavlju koje se odnosi na testiranje
rada simulatora, no zajednička im je karakteristika da se odnose na male promjene otklona
kormila, elevatora ili bočnih upravljačkih ploha, za koje je njihov utjecaj na spomenute
koeficijente linearan.
23
U primjeru koji će biti realiziran kasnije u simulatoru pretpostavilo se sljedeći
raspored aktuatora na toj ronilici:
Postojanje upravljačke površine na obje strane plovila: kako bi se povećala
fleksibilnost modela pretpostavljeno je da te upravljačke površine mogu
djelovati u dva različita načina rada: prvom u kojem su otkloni na njima
jednaki, pa se upravljačke površine meĎusobno potpomažu, te u drugom,
diferencijalnom. Stoga je bilo potrebno definirati zasebne kutove otklona za
svaku od tih ploha, redom dl i dr , pri čemu se uzelo da pozitivna vrijednost
tih kutova uzrokuje stvaranje momenta (u ovom slučaju oko y-osi) u
negativnom smjeru. Ovakva konvencija zadržane je i za niže opisane kutove.
Elevator na stražnjem kraju, čija je osnovna svrha upravljanje poniranjem
AUV-a. Kut odmaka te plohe označen je sa e .
2 kormila koji mu omogućuju upravljanje zaošijanjem. Za njih je
pretpostavljeno da im je kut odmaka uvijek jednak, i taj se taj zajednički kut
označava sa r .
Puni upravljački vektor stoga se može zapisati kao T
h dl dr e r .
Donja slika predstavlja raspored navedenih aktuatora na ronilici:
Slika 2-2-4:Konfiguracija hidrodinamičkih aktuatora AUV-a
24
3. Realizacija simulatora na MOOS platformi
Treće poglavlje predstavlja središnji dio ovog diplomskog rada, i u njemu je izloženo na
koji je način MOOS platforma upotrijebljena za razvoj simulatora podvodnih plovila.
Prikazana je realizacija matematičkog modela u programskom jeziku C++ napisana uz pomoć
[5] i [6], obrazložene karakteristike same platforme, programa koji će se njome koristiti, kao i
dodatnog programskog koda (matrix.h) koji je upotrijebljen kako bi se olakšala realizacija već
spomenutog modela. Detaljnija objašnjenja vezana uz svojstva pojedinih dijelova simulatora
dana su u pripadajućim potpoglavljima, a rezultati testiranja kompletnog simulatora za
pojedine ronilice u narednom poglavlju.
3.1. Povijest i karakteristike MOOS-a
MOOS, tj. ,,softver namijenjen obavljanju misija''14
, platforma je razvijena u
programskom jeziku C++ zamišljena kao posrednik pri istraživanjima iz područja robotike.
Njezino je podrijetlo vezano uz misije koje se odnose na more i podmorje, i stoga ona sadrži
pojedine aplikacije koje se i danas koriste u zadaćama vezanima uz taj medij. MeĎutim, njena
primjena danas je daleko šira, a pojedini njeni dijeni slojevi, posebno oni okupljeni pod
nazivom ,,Essential MOOS'', mogu se zbog svoje općenitosti koristiti u širokom spektru
aktivnosti (upravljanje procesima, bilježenje rezultata). Na čitav MOOS zapravo se može
gledati kao na niz slojeva, od kojih onaj najvažniji, ,,Core MOOS'', predstavlja
komunikacijski sloj, odnosno vrlo robusnu mrežno orijentiranu komunikacijsku arhitekturu
koja se sastoji od 2 bibliotečne datoteke15
te mrežnog čvora pod nazivom MOOSDB koji
pojedinim aplikacijama omogućuje jednostavnu razmjenu podataka.
Dodatni slojevi omogućuju uključivanje naprednijih funkcija u MOOS, kao što su
povezivanje simulacije u MATLAB-u s nizom procesa koji se odvijaju na MOOS-u, vizualno
pronalaženje nepravilnosti u skupini procesa koji meĎusobno komuniciraju, ili pak ponovni
prikaz do tog trenutka izračunatih podataka.
14 eng. Mission Oriented Operating Suite
15 eng. library
25
Kao što je vidljivo iz gornjeg opisa njegovog komunikacijskog sloja, MOOS ima
zvjezdoliku topologiju, prikazanu na sljedećoj slici (Slika 3-1-1):
Slika 3-1-1:Topologija MOOS-a
Na njoj je vidljivo da svaka aplikacija u MOOS okruženju (klijent) ima jedinstvenu vezu sa
MOOS bazom podataka (MOOSDB) koja predstavlja jezgru čitave platforme. Ona služi kao
server i sva se komunikacija odvija isključivo njenim posredovanjem. Ovakva topologija
posjeduje sljedeće karakteristike:
ne postoji izravna komunikacija izmeĎu pojedinih klijenata16
klijent je uvijek taj koji mora poslati zahtjev za komunikacijom
svaki klijent ima jedinstveno ime
pojedini klijenti u najopćenitijem slučaju ne posjeduju informaciju o tome je li
i koliko drugih klijenata spojeno na server
čitava mreža može biti (a najčešće i jest) distribuirana preko većeg broja
različitih računala koja mogu, ali i ne moraju raditi na istom operacijskom
sustavu, dok god je njihov vlastiti operacijski sustav (Windows, Linux)
podržan od strane MOOS-a
16 eng. Peer-to-Peer communication
26
Najočitiji nedostatak ovakvog ureĎenja mrežne komunikacije je moguća pojava
simptoma ,,uskog grla'' na samom serveru, bez obzira koliko je njegov programski kod dobro
napisan. MeĎutim, kao što će biti pokazano, prednosti uvelike nadmašuju nedostatke.
Ponajprije, struktura mreže zadržava jednostavnost bez obzira na broj klijenata koji su
trenutno spojeni na server. Sam server posjeduje potpunu informaciju o broju trenutno
uspostavljenih veza s različitim klijentima, i može odrediti prioritet kojim im treba
proslijeĎivati tražene podatke. Rad s pojedinim klijentima odvija se neovisno od drugih putem
pripadajuće meĎuveze. Time se osigurava da klijent s loše napisanim kodom ne može izravno
utjecati na druge klijente u mreži.
Nadalje, MOOS podržava istovremeni rad više različitih zajednica klijenata17
, tj. grupa
klijenata vezanih, primjerice, zajedničkim procesom. Ovo će se svojstvo u velikoj mjeri
koristiti i u ovom radu. Kao posljedica ove činjenice, svaka poruka koja se šalje od pojedinog
klijenta prema središenjem čvoru sadrži i ime zajednice kojoj taj klijent pripada. Više o
ovome bit će rečeno u poglavlju o paralelnom izvršavanju više simulacija. Za sada, naglasimo
da je osnovna paradigma koje se valja držati pri spajanju zajednice klijenata na server glasi:
,,jedinstven zadatak-jedinstvena konfiguracijska datoteka'' i svi će procesi koji su dio iste
zajednice klijenata sve potrebne parametre i /ili potprograme preuzeti iz te datoteke, što će
biti naznačeno i u njoj samoj, najčešće imenom same zajednice u obliku
Community=<Name>
u njenom zaglavlju.
Preostaje još opisati kakav je format poruka koje server izmijenjuje s klijentima, i
kako do navedene razmjene dolazi. MeĎuprogramsko sučelje komunikacijskog sloja u
MOOS-u18
omogućuje prijenos podataka izmeĎu MOOSDB-a i klijenta, no značenje je tih
podataka odreĎeno ulogom koju klijent ima. Pritom odmah mora biti naglašeno da je oblik
poslanih podataka za MOOS aplikacije ograničen: oni mogu biti isključivo znakovni nizovi19
ili brojčane vrijednosti u zapisu dvostruke preciznosti20
.
17 eng. communities
18 eng. API, ,,Application programming interface''
19 eng. string
20 eng. double
27
Tim podatcima se potom pridružuju dodatne varijable koje opisuju njihova svojstva kao što je
prikazano sljedećom tablicom:
Tabela 3-Sadržaj MOOS poruke
Ime varijable Značenje
Name Naziv poslanog podatka
String Val Podatak je tipa ,,znakovni niz''
Double Val Podatak je brojčana vrijednost u zapisu dvostruke preciznosti
Source Ime klijenta koji je podatak poslao serveru
Time Trenutak u kojem je podatak zapisan
Data Type Tip podatka (STRING ili DOUBLE)
Message Type Tip poruke (najčešće NOTIFICATION)
Source Community Naziv zajednice kojoj proces pripada
Sve navedeno potom se pakira u jedinstvenu poruku klase ,,MOOS poruka'' (oznaka
CMOOSMsg). Iako slanje poruka u binarnom obliku smanjuje njen broj bitova, treba uzeti u
obzir sljedeće: binarne su datoteke bez prethodne konverzije prosječnom korisniku potpuno
nerazumljive, a s druge strane činjenica da se komunikacija odvija posredstvom TCP/IP
protokola znači da ušteda memorije nije toliko značajna kako bi se moglo činiti na prvi
pogled. Stoga je korištenje znakovnih nizova opravdano (veličina poslanog paketa gotovo je
neovisna o veličini samog poslanog podatka). Vrijedi meĎutim istaknuti da ponovno
dobivanje brojčanih vrijednosti iz takve poruke zahtijeva njeno parsiranje, što kod binarnih
podataka ne bi bio slučaj. Prednosti ovakvog formata su, pak, sljedeće:
Znakovni nizovi korisniku su razumljivi
Svi su podaci istog tipa
Zabilježene vrijednosti su čitljive i može ih se lako komprimirati
Ponovni prikaz tih vrijednosti svodi se na čitanje primljenih znakovnih nizova
iz datoteke i njihovog opetovanog slanja na MOOSDB
28
Kao što je već spomenuto, svaki klijent posjeduje vlastitu vezu sa serverom. Ta se
veza ostvaruje od strane klijenta stvaranjem instance klase CMOOSCommClient, a koja se
nalazi u jednoj od dvije središnje bibliotečne datoteke, MOOSLIB. Za samu klasu vrijedi da
su svi složeni dijelovi komunikacije i vremenski trenutci kad se isti odvijaju zapravo privatne
varijable nevidljive vanjskoj aplikaciji, kojoj je pružen tek ograničen broj metoda kojima
korištenjem ove klase može napraviti nešto od sljedećeg:
Objaviti podatke: izdati obavijest (NOTIFY) o specifičnim (imenovanim)
podatcima
Pretplatiti se (REGISTER) na obavijesti o specifičnim podatcima
Prikupljati (FETCH) vrijednosti podataka na koje je pretplaćena
Najuobičajeniji primjer okolnosti u kojima bi se aplikacija služila prvom od navedenih
metoda je kada se u njoj izračuna vrijednost koja je potrebna nekoj drugoj aplikaciji.
Pozivanjem metode Notify u svojoj lokalnoj instanci objekta CMOOSClient može se odaslati
tražena vrijednost specificiranjem njenog iznosa, imena podatka na kojeg se ta vrijednost
odnosi, te vremenskog trenutka u kojem je ta vrijednost valjana. Sama metoda potom će od
navedenog upisivanjem u pripadajuća polja stvoriti odgovarajuću MOOS poruku. Sam čin
objavljivanja vrijednosti treba pritom biti shvaćen kao obavijest o stanju pripadajuće
podatkovne varijable: iako se njen iznos možda uopće nije promijenio, promijenilo se vrijeme
u kojem smo o tom iznosu obaviješteni. Pojedine poruke koje klijent objavljuje ne
proslijeĎuju se na server odmah: učestalost kojom klijent uspostavlja kontakt sa serverom
odreĎena je vrijedošću unutar pripadajuće komunikacijske datoteke pod nazivom
,,CommTick'', čiji je iznos obično podešen izmeĎu 10 i 50 Hz. Sve poruke koje se trebaju
odaslati u intervalu izmeĎu dvije uspostave kontakta formiraju jedinstvenu ,,super-
poruku''/paket pod imenom CMOOSPkt. Kad do kontakta doĎe i server primi sve potrebne
vrijednosti, tok podataka mijenja smjer i server sada prvotnoj aplikaciji šalje njoj potrebne
podatke. U slučaju da u trenutku uspostave kontakta paket ne sadrži niti jednu MOOS poruku,
ili ukoliko u meĎuvremenu na strani klijenta nije došlo ni do kakvog dogaĎaja, šalje se NULL
poruka. Na taj način uvijek se održava simetrija izmeĎu broja poslanih i primljenih paketa.
Kao što je naglašeno, po primitku obavijesti o podatcima koje aplikacija mora poslati
na stranu servera, on joj uzvraća slanjem podataka koji su toj aplikaciji potrebni za rad. To o
kojim je podacima riječ odreĎeno je drugom metodom unutar objekta CMOOSClient,
metodom Register.
29
Korištenje ove metode pretpostavlja da, iako aplikacija nije upoznata sa dogaĎajima
koji se odvijaju na nekom drugom klijentu niti sa njihovim ukupnim brojem, ima pristup
imenima podatkovnih varijabli koje taj klijent objavljuje putem prethodno opisane metode, a
koje su joj potrebne za rad. Drugim riječima, od autora se pojedine MOOS aplikacije
namijenjene specifičnoj svrsi očekuje da napravi popis podataka koje njegova aplikacija
objavljuje. Nakon toga, neka druga aplikacija može izraziti svoju potrebu za pristupom
vrijednostima tih varijabli na način da se pretplati odnosno registrira na njih gore navedenom
matodom. U toj metodi navodi se ime podatkovne varijable čije promjene želimo pratiti, kao i
učestalost kojom o tim promjenama želimo biti obaviješteni.
Konačno, metoda Fetch u skladu s tablicom 3 za pripadajuću aplikaciju osvježava listu
odgovarajućih MOOS poruka u kojoj se navodi što se promijenilo, koji je klijent uzrokovao
promjenu, u kojem trenutku i na kojem tipu podataka. Zbog razloga opisanih na prethodnoj
strani, pojedini poziv ove metode može dovesti do istovremenog zaprimanja većeg broja
obavijesti vezanih uz pojedinu imenovanu varijablu. Značenje ovakvog ishoda poziva metode
je intuitivno jasno: došlo je do većeg broja promjena vrijednosti željenog podatka od
posljednjeg kontakta klijent-server.
Ova se tvrdnja može i poopćiti: na MOOSDB-u kao središtu čitavog sustava i čvoru
kroz koji se obavlja sva komunikacija unutar njega, nije zabilježena samo vrijednost varijabli
od interesa nakon posljednjeg osvježavanja njihovih vrijednosti: upravo suprotno, MOOSDB
u sebi, na zahtjev stvoren Notify metodom od strane pojedinih priključenih klijenata, bilježi
čitavu povijest promjena tih varijabli od trenutka njihovog posljednjeg slanja pa do novog
zahtjeva za istim. Stoga klijent po dobivanju pristupa serveru ne prima samo posljednje
vrijednosti traženih varijabli , nego i sve promjene koje su se s njima zbivale u meĎuvremenu.
Ukoliko u tom vremenskom razdoblju niti jedan klijent nije poslao novu obavijest na
server, nakon što aplikacija pristupi serveru zahtijevajući pristup vrijednostima pojedinih
varijabli, na njemu neće biti nikakvih novih obavijesti za tu aplikaciju. Jedina iznimka od
ovog pravila je trenutak u kojem se aplikacija prvi put pretplaćuje na pojedinu varijablu: u
ovom slučaju uzvraćena obavijst neće sadržavati NULL znakovni niz, već vrijednost tražene
varijable zajedno sa vremenskim odsječkom u kojoj je njena vrijednost posljednji put
postavljena.
30
3.2. Struktura razvijene programske podrške
Upoznavši se sa osnovnim svojstvima MOOS platforme i njezinih slojeva, u ovom se
potpoglavlju razmatra način na koji je ta struktura upotrijebljena za realizaciju simulatora
podvodnih plovila. U tu svrhu, razmatra se tipična shema daljinskog upravljanja takvim
plovilom, prikazana na donjoj slici:
Slika 3-2-1:Shema daljinskog upravljanja plovilom
Cilj ovog rada je preslikati danu strukturu na MOOS platformu, pri čemu bi plovilo
bilo zamijenjeno vjerodostojnim modelom koji opisuje njegovo ponašanje. Model će stoga na
blokovskoj razini pokazivati sličnu organizacijsku hijerarhiju, uz naglasak na činjenicu da on
sam po sebi neće predstavljati pojedino plovilo, već će mu se karakteristike istog pridijeliti
slanjem odgovarajućih parametara. Ta se osnovna ideja da grafički predočiti sljedećom
blokovskom strukturom (Slika 3-2-2):
Slika 3-2-2-Općenita blokovska shema simulatora
31
Stvarna realizacija te blokovske strukture uključuje i podjelu središnjeg bloka na dio
koji opisuje propulziju i dio koji opisuje ponašanje same ronilice u vodi; blok kojim se
opisuje upravljanje ronilicom razlaže se, pak, na dio za odabir njenog odredišta i dio u kojem
se unošenjem odgovarajućeg upravljačkog algoritma postiže dolazak ronilice u tu točku.
Konačno, prikaz dobivenih rezultata sastoji se od bilježenja vrijednosti potrebnih varijabli te
potom iscrtavanja njihovih promjena u vremenu u MATLAB-u. Sve navedeno prikazano je
na sljedećoj shemi (Slika 3-2-3):
Slika 3-2-3: Opis programske strukture simulatora
Završni korak u preinaci sheme predstavlja opis načina na koji pojedini blokovi
predaju jedni drugima podatke: iako bi se iz gornjeg prikaza moglo pomisliti da odgovarajući
blokovi jedni drugima potrebne vrijednosti varijabli predaju izravno, kao što je objašnjeno u
prethodnom poglavlju, to zbog topologije MOOS-a nije slučaj. U stvarnosti, svaki od blokova
,,Odabir odredišta'', ,,Algoritam upravljanja'', ,,Opis propulzije'' i ,,Ponašanje tijela u vodi''
predstavlja zasebnog klijenta unutar iste zajednice na MOOS-u. Svaki od njih podatke koje bi
trebao proslijediti nekom drugom klijentu šalje na MOOSDB, tj. na server, gdje im pristupa
onaj klijent kojem su isti namijenjeni. Općenito je način na koji pojedini klijent šalje te
podatke i pretplaćuje se na praćenje drugih objašnjen u uvodnom dijelu trećeg poglavlja, dok
će se specifični programski kod kojim se ta komunikacija ostvaruje objasniti za svakog
zasebno u narednim potpoglavljima. Kao što će biti pokazano, upravo se na prenošenje
vrijednosti meĎu pojedinim klijentima odnosi najveći dio samog koda.
32
U zvjezdolikoj topologiji kakvu posjeduje naša platforma, prethodna shema stoga
izgleda ovako (Slika 3-2-4):
Slika 3-2-4: Programska struktura simulatora u zvjezdolikoj topologiji
Na njoj je središnji server označen ljubičastom bojom, klijenti žutom, a dijelovi koda
namijenjeni konfiguriranju zelenom bojom. Vidljivo je da se sva razmjena podataka obavlja
preko MOOSDB-a, kao i da svaki od klijenata objavljuje putem metode Notify barem neku od
varijabli, dok svi osim klijenta preko kojeg zadajemo odredište moraju i osluškivati stanje na
serveru kako bi primili i povratnu informaciju. Može se učiniti neintuitivnim da taj klijent ne
prima informaciju o stanju ronilice, ali budući da se on zajedno s upravljačkim algoritmom
nalazi na istom računalu, praćenjem stanja varijabli u tom dijelu programa možemo na
konzoli u odgovarajućem trenutku zadati novo odredište. U tu svrhu, ovaj dio aplikacije radi u
,,prekidnom'' načinu rada, tj. uvijek aktivno čeka želimo li unijeti nove koordinate na koje
ronilicu želimo poslati. Potrebno je još samo uočiti razliku izmeĎu varijabli koje se pojedinim
klijentima šalju svakom mogućom prilikom i onih koje će im biti po potrebi proslijeĎene
samo po prvom spajanju na server: u ovu drugu kategoriju spadaju dakako parametri iz
konfiguracijske datoteke, koji mogu biti potrebni bilo kojem od klijenata, kao i funkcija za
opis propulzije simulirane ronilice, koja se po spajanju na server proslijeĎuje odgovarajućem
pojedinačnom bloku.
33
3.2.1. Realizacija matričnih operacija
Prvi klijent od četiriju koliko ih postoji u konačnoj verziji programa, a čije će
ponašanje biti izloženo, jest onaj u kojem ćemo programski opisati ponašanje krutog tijela u
vodi. Matematički model na kojem se ovaj blok zasniva dan je u drugom poglavlju, i u njemu
se za opis veze izmeĎu mobilnog i fiksnog koordinatnog sustava koristimo Eulerovim
kutevima. Iako je ovakva reprezentacija položaja ronilice intuitivna, za odreĎene će
vrijednosti tih kuteva doći do pojave singulariteta, i proračun se neće moći obaviti (najočitiji
su primjeri oni u kojima se u odreĎenim matricama javljaju elementi u obliku razlomaka čiji
je nazivnik cos(x), što za, primjerice, iznos odgovarajućeg kuta od 2
dovodi do dijeljenja s
nulom).
Za specifične je primjene, kao što su primjerice modeli geostacionarnih satelita,
postojanje ovakvih singularnosti neprihvatljivo. U tom slučaju uvodi se novi pristup, koji
umjesto sa dotadašnja tri parametra (Eulerovi kutevi) radi sa 4: ovi se novi parametri nazivaju
kvaternionima.
No, kako se u ovom radu bavimo s modeliranjem ponašaja podvodnih plovila, dodatan
je trud koji bi zahtijevalo uvoĎenje ovih parametara nepotreban: za većinu se ronilica može
pronaći takva putanja za koju se singularitet nikad neće javiti: primjerice, AUV nikad neće
operirati pod kutom poniranja ili valjanja od 090 .
To znači da je opisivanje ponašanja ronilice putem matrica koje su dobivene pomoću
Eulerovih kuteva opravdano. No, to nas dovodi do sljedećeg problema: programski jezik C++
u kojem je ovaj rad napisan ne uključuje meĎu svojim operatorima i one matrične. Iz
jednadžbi je (2-1-1) do (2-1-17) vidljivo da su opracije koje će nam biti potrebne zbrajanje,
oduzimanje, množenje i invertiranje matrica. Stoga se nužnim pokazalo uključivanje javno
dostupne bibliotečne datoteke matrix.h, u kojoj su potrebne radnje podržane. Uz nju, potrebno
je bilo napisati i nekoliko dodatnih funkcija kojima su se obavile operacije stvaranja skew-
simetrične matrice, vektorskog umnoška, unošenja elemenata u matricu iz pripadajućeg polja
podataka u dvostrukoj preciznosti, te, konačno, stvaranje matrica čiji su elementi druge
matrice. Za posljednji navedeni zadatak realizirano je samo stvaranje matrica čiji su elementi
više matrica jednakih dimenzija, s obzirom da samo na takve primjene i nailazimo u već
spomenutim jednadžbama iz drugog poglavlja.
34
Pripadajući programski odsječci su sljedeći:
Popunjavanje matrice elementima polja:
void fill(matrix<double>& m1,double f[ ]){
for(int i = 0; i < (int)m1.RowNo(); i++)
{ for(int j = 0; j < (int)m1.ColNo();j++)
{m1(i, j) = f[i*m1.ColNo()+j];}}}
Popunjavanje matrice drugim matricama:
void insert(matrix<double>& M, int row_mat_indx, int col_mat_indx,
matrix<double> m){
int row_start_indx = row_mat_indx*m.RowNo();
int col_start_indx = col_mat_indx*m.ColNo();
for(int i = row_start_indx; i < row_start_indx + (int)m.RowNo(); i++)
{for(int j = col_start_indx; j < col_start_indx + (int)m.ColNo();j++)
{M(i,j) = m(i-row_start_indx, j-col_start_indx);}}}
void fill(matrix<double>& M, matrix<double> mf[]){
int inner_rown, inner_coln;
inner_rown = mf[0].RowNo();
inner_coln = mf[0].ColNo();
int row_mat_n = M.RowNo() / inner_rown;
int col_mat_n = M.ColNo() / inner_coln;
for(int i = 0; i < row_mat_n; i++){
for(int j = 0; j < col_mat_n; j++){
insert(M, i, j, mf[i*col_mat_n + j]);}}}
Stvaranje skew-simetrične matrice:
void skewsymm(matrix<double>& V, matrix<double> v){
double f[ ] ={0,-v(2,0),v(1,0),v(2,0),0,-v(0,0),-v(1,0),v(0,0),0};
fill(V, f);}
Računanje vektorskog umnoška:
void cross(matrix<double>& v, matrix<double> v1, matrix<double> v2){
double a,b,c,d,e,f;
a = v1(0,0); b = v1(1,0); c = v1(2,0);
d = v2(0,0); e = v2(1,0); f = v2(2,0);
v(0,0) = (b*f - c*e);
v(1,0) = (c*d - a*f);
v(2,0) = (a*e - b*d);}
Konačno, navest ćemo operatore koje smo preuzeli iz matrix.h, bez detaljnijeg objašnjavanja
ovog dijela koda:
+ : zbrajanje dvaju matrica
- : oduzimanje dvaju matrica
* : množenje dvaju matrica
! : inverzija matrice
35
3.2.2. Realizacija opisa ponašanja krutog tijela u vodi
Koristeći se gore navedenim operatorima i funkcijama, traženi je matematički model
isprogramiran u C++-u. Cilj je ovog bloka bio na temelju sila i momenata koji djeluju na
ronilicu i stanja u kojem se ona prethodno nalazila izračunati novo stanje u kojem će se ona
zateći. Stanje je ronilice pritom smo definirali kao strukturu sa 12 elemenata koji
predstavljaju redom translacijske i rotacijske brzine same ronilice kao i globalne koordinate
na kojima se ona nalazi, kao što je prikazano sljedećim isječkom:
typedef struct _state{
double u;
double v;
double w;
double p;
double q;
double r;
double x;
double y;
double z;
double phi;
double theta;
double psi;
} state;
Stanje ronilice je, zajedno sa svim primljenim parametrima, svrstano u privatne
članove pripadajuće klase. Ostatak njenog zaglavlja je sljedeći:
class CRov : public CMOOSApp
{
public:
CRov();
virtual ~CRov();
protected:
bool OnNewMail(MOOSMSG_LIST &NewMail);
bool Iterate();
bool OnConnectToServer();
bool OnStartUp();
void DoRegistrations();
bool OnPropulsion(CMOOSMsg& msg);
private:...
}
Ukratko će biti objašnjena uloga članova navednih u gornjem isječku, a potom će se u
skladu s time navesti dijelovi koda pojedinih članova bitni za zadatke koje svaki od njih mora
obavljati. Kako je ovakva struktura zaglavlja reprezentativna za svakog od klijenata u MOOS
zajednici, u daljnjim se poglavljima (osim isticanja razlika u odnosu na gornji zapis) uloga
pojedinih članova neće posebno isticati.
36
Svaka se aplikacija napravljena za MOOS platformu (a time i svaki od naših klijenata)
u osnovi gradi na isti način: stvaranjem nove klase izvedene iz CMOOSApp, stvaranjem
instance te klase u main() funkciji, te po potrebi preopterećivanjem sljedećih virtualnih
funkcija:
:: Iterate – funkcije pomoću koje će se vršiti glavna obrada
::OnNewMail – funkcije koja se poziva kada klijentu pristignu novi podaci
::OnConnectToServer – funkcije koja se poziva kada se uspostavi kontakt sa MOOSDB
::OnStartUp – funkcije koja se poziva pri prvom pokretanju aplikacije
Općenito je stoga rad bilo koje MOOS aplikacije opisan sljedećom slikom (3-2-2-1):
Slika 3-2-2-1: Princip rada MOOS aplikacije
Kao što je vidljivo, preopterećivanjem se spomenutih funkcija postiže da pojedina
aplikacija obavlja ono što od nje želimo. Prva od njih koja će biti objašnjena je funkcija
::Iterate(). Riječ je o funkciji koja se periodički poziva i kojom se orkestrira izvršavanje
zadataka povjerenih pojedinom klijentu. Učestalost tih poziva odreĎena je metodom
SetAppFreq() ili, češće, definiranjem vrijednosti parametra AppTick u konfiguracijskoj
datoteci. Taj parametar predstavlja maksimalnu frekvenciju kojom se aplikacija može
pozivati. Iako ulazak u beskonačnu petlju u ovom dijelu koda čekanjem na podatke neće
nužno uzrokovati pogrešku pri izvoĎenju programa, takav je postupak u neskladu s dobrom
programerskom praksom, pa se osim postavljanja potrebne vrijednosti AppTick-a spomenuta
funkcija najčešće ostavlja nedirnutom:
bool CRov::Iterate()
{return true;}
37
Iduća je funkcija ::OnNewMail() i pomoću nje će se zapravo vršiti proračun potrebnog
stanja. Ona se aktivira kada i ako neki proces na serveru objavi podatke za koje je naša
aplikacija zainteresirana (način na koji se to odreĎuje bit će iznesen u opisu sljedeće funkcije).
Nova ,,pošta'' pristiže u obliku std::list<MOOSMsg> koji predstavlja listu CMOOSMsg
objekata. Programiranjem se može postići da se kroz tu listu opetovano prolazi, pregledavaući
tko je poslao podatke, na što se odnose, koliko su stari, jesu li u formatu znakovnog niza ili
numeričke vrijednosti, te potom takve podatke primiti i/ili obraditi u skaldu sa zahtjevima
programa.
U našem slučaju, funkcija OnNewMail() unutar bloka koji opisuje ponašanje krutog
tijela u vodi ima sljedeći oblik:
bool CRov::OnNewMail(MOOSMSG_LIST &NewMail)
{
MOOSMSG_LIST::iterator iterMSG;
for(iterMSG = NewMail.begin(); iterMSG != NewMail.end(); iterMSG++){
CMOOSMsg & rMsg = *iterMSG;
if(MOOSStrCmp(rMsg.GetKey(),"Propulsion"))
{this->OnPropulsion(rMsg);
}
}
return true;
}
Njime se zapravo izražava da se pri pojavi novog podatka na serveru provjeri odnosi li
se taj podatak na vrijednosti proslijeĎene od bloka koji opisuje sile i momente koje stvara
pogon ronilice, i u slučaju da je odgovor na to pitanje potvrdan poziva se funkcija koja nad
tim vrijednostima obavlja odgovarajući proračun.
Funkcija OnPropulsion() zapravo je realizacija jednadžbi opisanih u 2. poglavlju u
programskom jeziku C++, čiji bi potpuni prikaz zauzeo previše prostora. Za specifične detalje
može se proučiti programski kod na disku priloženom uz ovaj rad. Ovdje će redom biti
navedeni samo reprezentativni primjeri pojedinih koraka u proračunu:
Nakon primitka novih vrijednosti sila i momenata koje djeluju na ronilicu, ponajprije
se stvore vektori translacijskih i rotacijskih brzina te Eulerovih kutova analogno donjem
isječku:
matrix<double> v1_G(3,1);
double f1[ ] = {this->_state.u, this->_state.v, this->_state.w};
fill(v1_G, f1); // stvaranje vektora translacijskih brzina
38
Slijedi uvoĎenje varijabli koje predstavljaju vrijednosti trigonometrijskih funkcija
pojedinih kutova potrebnih za stvaranje matrica iz jednadžbi (2-1-3) i (2-1-4) kao što je:
c1 = cos(this->_state.phi);
Nakon što se izgeneriraju matrice koje povezuju mobilni i fiksni koordinatni sustav (u
primjeru matrica J2), te vektori koji opisuje središte uzgona, odnosno mase ronilice, kao i
matrica inercije (preuzimanjem potrebnih parametara iz konfiguracijske matrice), primjenom
skewsymm funkcije nad za to potrebnim vektorima, izračunaju se matrice Coriolisovih i
centripetalnih sila, a odmah potom i onih matrica koje se odnose na utjecaj mase ronilice
(uključujući dodanu masu), linearnog i kvadratnog prigušenja, gravitacije i dr.
matrix<double> J2(3,3);
double f5[] = {1, (s1*t2), (c1*t2),
0, c1, -s1,
0, (s1/c2), (c1/c2)};
fill(J2, f5);
Proračun se nastavlja ekvivalentno ranije danom izvodu, s preuzimanjem iznosa sila i
momenata i njihovim pohranjivanjem u vektor Tau na donji način:
matrix<double> tau(6,1);
double dblTau;
string strPropulsion = msg.GetString();
MOOSValFromString (dblTau , strPropulsion, "tau1", false);
tau(0,0) = dblTau;
MOOSValFromString (dblTau , strPropulsion, "tau2", false);
tau(1,0) = dblTau;
MOOSValFromString (dblTau , strPropulsion, "tau3", false);
tau(2,0) = dblTau;
MOOSValFromString (dblTau , strPropulsion, "tau4", false);
tau(3,0) = dblTau;
MOOSValFromString (dblTau , strPropulsion, "tau5", false);
tau(4,0) = dblTau;
MOOSValFromString (dblTau , strPropulsion, "tau6", false);
tau(5,0) = dblTau;
Sa stvaranjem tog vektora, a nakon što su obavljene sve prethodne matrične operacije,
napokon se može proračunati derivacija varijabli stanja u našem modelu, i to najprije
derivacije translacijskih i rotacijskih brzina (nudot je vektor-stupac sa 6 elemenata):
nudot = -invM*C*nu - invM*(D*nu + d1 + d2) - invM*g + invM*tau;
//nu je vektor brzina pronilice, nudot vektor njihovih derivacija
a potom, služeći se i funkcijom za popunjavanje matrica drugim matricama kao u donjem
primjeru, konačno i vektor derivacija položaja ronilice eta_E_dot:
39
matrix<double> pom1(6,6), pom2(6,1), zero(3,3);
matrix<double> mf5[] = {J1, zero, zero, J2};
fill(pom1, mf5);
matrix<double> mf6[] = {v1_G, v2_G};
fill(pom2, mf6);
matrix<double> eta_E_dot(6,1);
eta_E_dot = pom1 * pom2;
U realizaciji ovog koda u MATLAB-u potom bi se pozvala neka od metoda kojom se iz
prethodnog stanja pojedinih varijabli i njihovih derivacija dobija nova vrijednost (primjerice,
ODE 45), no u ovdje se ta vrijednost računa na najjednostavniji mogući način, preko linearne
aproksimacije:
( ) ¨ ( ) * '( )f a t f a t f a .
Korak integracije (u programskom kodu označen sa Step) odabran je tako da trenutak u
kojem se proračuna novo stanje odgovara vremenu koje je proteklo dok se proračun obavljao,
što znači da je inverzan vrijednosti parametra AppTick. Testiranja provedena u sljedećem
poglavlju pokazala su da je ova vrijednost (0.1, tj. 1/10 Hz) zadovoljavajuća. Konačan se
proračun novih vrijednosti varijabli stanja tako može opisati kao:
this->_state.u += nudot(0,0)*dblStep;
this->_state.v += nudot(1,0)*dblStep;
this->_state.w += nudot(2,0)*dblStep;
this->_state.p += nudot(3,0)*dblStep;
this->_state.q += nudot(4,0)*dblStep;
this->_state.r += nudot(5,0)*dblStep;
this->_state.x += eta_E_dot(0,0)*dblStep;
this->_state.y += eta_E_dot(1,0)*dblStep;
this->_state.z += eta_E_dot(2,0)*dblStep;
this->_state.phi += eta_E_dot(3,0)*dblStep;
this->_state.theta += eta_E_dot(4,0)*dblStep;
this->_state.psi += eta_E_dot(5,0)*dblStep;
Te će se vrijednosti varijabli stanja potom poslati na MOOSDB gdje će ih po potrebi
preuzeti drugi klijenti (aplikacija za proračun upravljačkog algoritma, a po potrebi i blok za
opis propulzije, ukoliko primjerice želimo uvesti ovisnost sile koje stvaraju potisnici o
unaprijednoj brzini ronilice). Taj posljednji korak, objavljivanje novih vrijednosti relevantnih
varijabli na server, obavlja se već uvelike spominjanom metodom Notify kao što je prikazano
u na sljedećoj stranici navedenom odsječku koda:
40
string strState;
strState =
MOOSFormat("u=%f,v=%f,w=%f,p=%f,q=%f,r=%f,x=%f,y=%f,z=%f,phi=%f,theta=
%f,psi=%f",
this->_state.u,
this->_state.v,
this->_state.w,
this->_state.p,
this->_state.q,
this->_state.r,
this->_state.x,
this->_state.y,
this->_state.z,
this->_state.phi,
this->_state.theta,
this->_state.psi);
this->m_Comms.Notify("State", strState, MOOSTime());
No, još nije objašnjeno u kojem je trenutku funkcija OnPropulsion dobila sve parametre
potrebne za obavljanje gore opisanog proračuna, kao i na koji način je osigurala primanje
vektora Tau (ili, analogno, kako će aplikacija/klijent zadužena za upravljački algoritam
preuzeti vrijednosti varijabli stanja potrebne za njen proračun, a koje smo ovime upravo
poslali na server). Za tu i slične zadaće obično se služimo preopterećivanjem posljednje dvije
virtualne funkcije unutar CMOOSApp-a navedene na početku ovog potpoglavlja,
::OnConnectToServer() i ::OnStartUp().
Prva od njih razlikuje se od do sada analiziranih virtualnih funkcija ponajviše po tome
što je ne pozivamo izravno iz CMOOSApp::Run() već to radi posebna dretva unutar objekta
zaduženog za komuniciranje. Ovo je ujedno i najpogodnije mjesto u kojem se pozivanjem
metode Register može reći serveru za koje smo MOOS poruke zainteresirani. Svoj
komplement ima u funkciji ::OnDisconnectFromServe()r, no kako je poziv iste obično znak
da je nešto pošlo po krivu dalje od točke u kojoj se to da popraviti, ukoliko ne želimo započeti
ni sa kakvim posebnim postupkom u slučaju prestanka komunikacije, instancu iste ne
moramo imati u našoj aplikaciji.
Funkcija ::OnStartUp je, pak, za razliku od funkcije spajanja na server, uvijek
pokrenuta od strane CMOOSApp::Run(), ali samo jednom, i to upravo prije nego što
aplikacija uĎe u ciklus izmijenjivanja poziva ::Iterate funkcije. U tom jednom koraku, obično
se provodi inicijalizacija, što znači da je ovo mjesto gdje se programeri najčešće služe
funkcionalnošću pruženom od člana m_Mission.Reader kako bi pročitali konfiguracijske
parametre.
41
Na prvi pogled može se učiniti da i ::OnStartUp() i ::OnCOnnectToServer imaju posve
različite uloge-jedna da odredi koje će varijable primati u daljnjem toku izvoĎenja programa,
a druga da primi nepromjenjive parametre uz pomoć kojih će te proračune obaviti. Istina je,
meĎutim, nešto drugačija: preporučljivo je izvršenje pretplate na varijable koje se žele primiti
od servera izvršiti u obje ove funkcije (metodom DoRegistrations))-na kraju funkcije
::OnStartup() i negdje unutar funkcije ::OnConnectToServer(). Zašto je tome tako?
Parsiranjem konfiguracijske datoteke koja se zaprimi tokom pokretanja prve od ovih
dvaju funkcija može se otkriti da se nužno mora pratiti sadržaj neke od poruka poslanih na
server. No, s druge strane, spajanje na server je asinkrono zbog topologije platforme, i ovisi o
tome što se dogaĎa s ostatkom mreže. Stoga se spajanje na server neočekivano može dogoditi
prije poziva za pokretanjem aplikacije ( i time prije inicijaliziranja ovog dijela koda), pa stoga
i u ovom slučaju klijent mora biti spreman registrirati se unaprijed na sve potrebne varijable.
Pripadajući kod stoga u bloku za simuliranje ponašanja ronilice ima sljedeći opći oblik:
bool CRov::OnConnectToServer()
{ this->DoRegistrations();
return true;}
Ekvivalentna se linija u skladu s do sada navedenim nalazi i u ::OnStartUp() dijelu, ali
prije toga se obavlja čitanje svih potrebnih parametara iz konfiguracijske datoteke. Kodom je
osigurana nemogućnost obavljanja simulacije ukoliko bilo koji od parametara nedostaje.
Pritom se zasebno provjerava svaki pojedini parametar kao što je vidljivo u donjem isječku:
double dblx0;
if(!this->m_MissionReader.GetConfigurationParam("x0", dblx0))
{MOOSTrace("CRov::OnStartUp(): Conf x0 missing\n");}
//nije poslana x-koordinata početnog položaja ronilice:
//simulacija ne može započeti
Preuzeti se parametri potom proslijeĎuju odgovarajućoj strukturi:
this->_state.x = dblx0;
//samo pri prvom pozivu!!
Tek nakon učitavanja svih parametara se, ukoliko to nije već obavljeno prethodnom
funkcijom, pozove napokon i funkcija DoRegistrations, koja dakako za ovaj blok ima oblik :
void CRov::DoRegistrations(){
this->m_Comms.Register("Propulsion", 0);
return;
}
42
3.2.3. Realizacija modela propulzije ronilice
Klijent koji šalje vrijednosti na koje se aplikacija opisana u prethodnom poglavlju
pretplaćuje je blok s opisom propulzije ronilice. Njegova je svrha, kao što će se pokazati u
daljnjem tekstu i primjerima, zapravo nešto šira od toga što bi se na prvi pogled očekivalo,
tj.da samo proslijedi rezultantne sile i momente nastale korištenjem propelera ronilice u dio
koji opisuje njezinu kinematiku i hidrodinamiku. Iako je u osnovnoj inačici programa imao
upravo tu namjenu, naknadno je ronilica klase AUV modelirana na način da su se rezultati
djelovanja njezinih hidrodinamičkih aktuatora (tj. bočnih upravljačkih ploha, kormila i
elevatora) trebali proslijediti prethodno opisanom klijentu u obliku linearnih promjena
odreĎenih parametara ( te su promjene izražene kao dodatni koeficijenti specifični za svaku
upravljačku plohu). MeĎutim, to je značilo da se ili trebalo dodatno proširiti već pozamašnu
konfiguracijsku datoteku, ili smanjiti njenu općenitost time da se neki od parametara u
pojedinim slučajevima proglase promjenjivima, ili iznova napisati komunikaciju izmeĎu
pojedinih klijenata. Ovaj je posljednji postupak mogao dovesti i do neočekivanih problema u
izvoĎenju simulacije kao posljedica zvjezdolike topologije platforme: ukolko bi se naime
komunikacija podesila tako da za opis ponašanja tijela u vodi osim na iznose potrebnih sila i
momenata čekamo i na vrijednosti upravljačkih veličina, moglo bi se dogoditi da zbog
asinkronog karaktera komunikacije klijenti Control i Ronilica (što su nazivi aplikacija
zaduženih za upravljački algoritam, odnosno hidrodinamiku/kinematiku) zatvore petlju u
kojoj naizmjence jedan drugome šalju vrijednosti, izostavljajući pritom blok Propulsion u
potpunosti (prisjetimo se da je struktura prikazana slikom 3-2-3 samo idejna, dok slika 3-2-4
prikazuje realnu situaciju u kojoj klijent zapravo nije svijestan u kojem će redoslijedu podatci
koje pošalje na server biti proslijeĎeni drugim klijentima, pa čak ni koliko ih ukupno na te
podatke čeka). Izbjegavanje ovoga zahtijevalo bi ugraĎivanje dodatne logike u dio za prijem
poruka kojim bi se odredilo kada se proračun u bloku vrši, mijenjaje CommTicka pojedinih
blokova (što je neprihvatljivo budući da se ta varijabla koristi za simuliranje realne
komunikacije operatera s ronilicom), ili pak kombiniranje blokova za pogon i ponašanje tijela
u vodi, čime bi se izgubila početna željena struktura simulatora.
Stoga se za modeliranje AUV-a, kao što će biti pokazano, pribjeglo kompromisu, u
kojem blok Propulsion služi kao posrednik za prenošenje vrijednosti otklona pojedinih
upravljačkih kuteva izmeĎu blokova Control i Ronilica. Osnovni izgled konfiguracijske
datoteke time je zadržan, ali su pri simuliranju AUV-a u klijentu Ronilica dodane nove
jednadžbe za preinaku vrijednosti pojedinih parametara. Kako se ovime donekle gubi na
43
općenitosti tog bloka, taj dio koda je u konačnoj verziji izostavljen. TakoĎer, klijent je
Propulsion vraćen u oblik koji umjesto proizvoljno velikog broja parametara (ovisno o broju
hidrodinamičkih aktuatora) ponovno šalje njih točno 6.
Kad je riječ o samoj strukturi tog bloka, njegovo je zaglavlje očekivano analogno
onom bloka Ronilica kojeg smo već opisali. Najznačajniju promjenu predstavlja sljedeći
privatni član ovog bloka:
FUNC_PTR_Propulsion _fptrPropulsion;
Objasnimo o čemu se radi: za razliku od bloka Ronilica koji će uvijek obavljati
potpuno jednake operacije nad potpuno jednakim skupom argumenata (iako se njihove
vrijednosti mogu mijenjati), blok Propulsion prije inicijalizacije ovog člana ne zna čak ni broj
podataka na koje se pretplaćuje: isti predstavljaju upravljačke veličine za pojedine aktuatore
na ronilice, čiji broj varira od plovila do plovila. TakoĎer, omogućeno je da se broj tih
aktuatora promijeni čak i za vrijeme same simulacije, mijenjajući iznova suštinsku strukturu
ove aplikacije. Sve to ukazuje da, kako bi se zadržao širok spektar primjenjivosti ovog
simulatora, kod koji će ovdje biti napisan ne smije biti fiksan, već imati dovoljnu fleksibilnost
da se prilagodi različitim zahtjevima korisnika.
Njegovo se konfiguriranje stoga ne svodi na puko preuzimanje parametara, već i na
primanje koda/jednadžbi koji će se tim parametrima služiti. U općenitom slučaju taj poziv
izgleda ovako:
CPropulsion::CPropulsion(FUNC_PTR_Propulsion fptrPropulsion)
{ this->_fptrPropulsion = fptrPropulsion;}
CPropulsion::~CPropulsion()
{}
bool CPropulsion::OnControl(CMOOSMsg& msg){
msg.Trace(); //print msg in details
int dblControlCount;
string strControl = msg.GetString();
this->_ctrlPrev.clear();
MOOSValFromString (dblControlCount , strControl, "ControlCount",
false);
char buff[10];
for(int i=1; i <= (int)dblControlCount; i++){
sprintf(buff, "control%d", i);
double dblControl;
MOOSValFromString (dblControl , strControl, buff, false);
_ctrlPrev.push_back(dblControl);
Nakon što primi potreban opis propulzije i vrijednosti nužnih varijabli, i ovaj će klijent na
uobičajen način objaviti rezultantne sile i momente : korištenjem metode Notify.
44
3.2.4. Blokovi za odabir odredišta i upravljačke algoritme
Sa do sada objašnjena dva bloka obavljeno je programiranje općenitog simulatora
podvodnih plovila na MOOS platformi. Korisniku koji se njime želio služiti preostaje da
preda odgovarajuće parametre i konfiguraciju pogona tim blokovima, te da potom proizvoljno
odabran algoritam za upravljanje unese u za to namijenjenog dodatnog klijenta, koji je nazvan
Control. Taj je klijent isprogramiran kao generički blok koji se prijavljuje na podatke o stanju
ronilice te o odredištu na koje je želimo poslati, što znači da se pretpostavlja da će primarna
zadaća ovog simulatora biti testiranje algoritama u kojima se vrši praćenje odreĎene putanje
ili pak prolazak kroz veći broj kontrolnih točaka (neovisno o odabranoj putanji). Klijent
zadužen za zadavanje odredišta, kao što je ranije spomenuto, nema se potrebu prijavljivati niti
na jednu MOOS poruku, budući da će se ovaj blok redovito nalaziti na strani korisnika (sam
simulator kao što će se pokazati može biti na po volji dalekom računalu), te stoga sam
korisnik može:
Pratiti vrijednosti koje o stanju ronilice osluškuje njegov kontrolni algoritam; poslužiti se
integriranom aplikacijom uMS (koja inače služi za otklajanje grešaka iz programa) da njome
zadaje vrijednosti pojedinih upravljačkih varijabli izravno na server i prati rezultate takve
intervencije; preoblikovati blok DestCtrl (zadavanje odredišta) da u pravilnim vremenskim
razmacima čita nove odredišne koordinate iz unaprijed pripremljene datoteke (u ovom bi se
slučaju pretpostavljalo da ronilica neće naići na zapreke koje bi je spriječile u prolasku kroz
sve zadane točke) i dr.
Jedna od intrigantnijih mogućnosti koje pruža MOOS platforma je da se korištenjem
ugraĎenog terminala pod nazivom iRemote zadaju direktno naredbe u MOOS zajednicu, bez
obzira je li riječ o simulaciji ili smo spojeni na stvarno plovilo. Kako to može predstavljati i
sigurnosni problem (napuštanje terminala bi teoretski značilo da se stvarnom plovilu do
unedogled šalje posljednja upisana naredba, bez obzira na njezin smisao) od operatera se u
ovom slučaju traži da u odreĎenim vremenskim periodima pritiskanjem tipki označi da je još
uvijek prisutan. Kako bi to za testiranje našeg simulatora predstavljalo nepotrebnu smetnju,
blok za zadavanje odredišta realiziran je kao jednostavna funkcija koja radi u prekidnom
načinu rada, tj. spremno očekuje da korisnik zada nove koordinate, a tek onda kad su sve tri
zaprimljene proslijedi ih bloku za kontrolu i vraća se u stanje čekanja.
Time se omogućilo da se testiranje pojedinih kretanja ronilice u vodi obavlja po volji
željenom brzinom.
45
4. Testiranje rada simulatora
Nakon što je u prethodnom poglavlju opisan razvoj i izgled programske podrške koja je
tema ovog diplomskog rada, u ovom će poglavlju biti prikazana njezina primjena za
simulaciju različitih podvodnih plovila. U tu svrhu, upoznat ćemo se s pLoggerom, dijelom
MOOS arhitekture zaduženom za bilježenje svih aktivnosti tokom pojedinog provoĎenja
simulacije. Potom će biti objašnjeno kako se preinakama u konfiguracijskoj datoteci može
obaviti simulacija različith plovila kao i različitih okolnosti u kojima se ta plovila mogu
zateći, nakon čega će se rezultati dobiveni logiranjem pojedinih aktivnosti prebaciti u
programski paket MATLAB i biti grafički prikazani. Konačno, bit će pokazano kako se
MOOS arhitektura može koristiti za provoĎenje više istovremenih simulacija, te će rezultati
takvog, paralelnog izvršavanja programskog koda na platformi takoĎer biti prikazani na već
opisan način.
4.1. Metode bilježenja rezultata simulacije u MOOS-u
Kao što je već naglašeno, kako bismo mogli proučavati rezultate pojedine simulacije
nužno je posjedovati način na koji se ti isti rezultati mogu sačuvati u računalnoj memoriji i
kasnije po potrebi reproducirati, te upotrijebiti u daljnjoj analizi. Tu funkcionalnost na MOOS
platformi osigurava proces pod nazivom pLogger. Njegova je isključiva zadaća bilježenje
aktivnosti koje se dogaĎaju za vrijeme rada proizvoljnog broja klijenata u jednoj MOOS
zajednici. Kada su u pitanju postsimulacijska analiza, prikupljanje podataka i ponovljivost
rezultata pojedine simulacije, ovakav je alat nenadomjestiv.
Konfiguriranje je samog pLoggera trivijalno i sastoji se od višekratnog pisanja linija
programskog koda sljedećeg oblika:
Log=varname@period [NOSYNC] [MONITOR]
U gornjem zapisu varname predstavlja naziv bilo koje MOOS varijable korištene u trenutnoj
simulaciji, a period minimalan interval izmeĎu dvaju unosa vrijednosti te varijable u log koji
će biti pohranjeni. NOSYNC, pak, predstavlja opcionalnu zastavicu čije postavljanje
signalizira da se pohranjena varijabla ne pohranjuje tokom snimanja sinkronih logova.
46
Konačno, MONITOR predstavlja opcionalnu zastavicu zaduženu za praćenje
učestalosti kojom se vrijednost spomenute varijable bilježi: ukoliko vrijednost varijable nije
zabilježena barem jednom u posljednjih 10 sekundi, ta zastavica uzrokuje da varijabla
MOOS_DEBUG unutar pLoggera istom da naredbu da o nepostojanju tražene aktivnosti izda
obavijest.
Ukoliko se program koristi procesom iRemote, spomenutom u potpoglavlju o
blokovima za odabir odredišta i upravljačke algoritme, postavljenost će ove zastavice dovesti
do ispisivanja upozoravajuće poruke na ekranu, što miože biti korisno kod složenijih sustava
u kojem odsustvo bilježenja neke varijable obično znači fatalnu grešku u procesu koji tu
varijablu računa.
Preporučljivo je pLogger aplikaciju pohraniti u vlastiti direktorij, a pri postavljanju
staze do memorijske lokacije u kojoj se taj dirketorij nalazi možemo se poslužiti relativnim
adresiranjem. Štoviše, čak i ako nikakva staza nije unaprijed navedena, pLogger će potrebne
rezultate pohraniti u lokaciju s generičkim imenom.
Bez korištenja pAntlera, pLogger je nužno pokrenuti kao i svaku drugu MOOS
aplikaciju. Ovaj je korak bitan ukoliko ne želimo na kraju čitave misije primjetiti da zapravo
niti jedan podatak nije pohranjen.
Ti podaci pohranjeni u odabranom direktoriju pripadaju dvama različitm tipovima, a u
ovisnosti o simulaciji koju vršimo kao i o načinu na koji smo odlučili slati podatke s pojedinih
klijenata prema serveru ti će nam tipovi biti manje ili više korisni, pa to hoćemo li se i kako
služiti svakim od njih odlučujemo konfiguriranjem samog pLoggera.
Oba su tipa podataka u formatu ASCII teksta, koji se može po potrebi komprimirati,
no držeći i dalje na umu da je njihova uporabljivost važnija od memorijskog prostora koji
zauzmu. Prvo od dva tipa su sinkroni logovi, koji stvaraju tablicu s podacima u kojoj svakoj
liniji odgovara jedan vremenski interval. Vrijeme je izmeĎu tih intervala (kao i to želimo li
uopće snimati sinkroni log) opisano je sljedećom naredbom:
SyncLog = true/false @ period
Ukoliko izmeĎu uzastopnih koraka ne doĎe do promjene praćene varijable njena se
vrijednost upisuje kao NaN. Zbog načina na koji se generiraju, sinkroni blogovi ne bilježe
nužno sve što se dogaĎa; umjesto toga, oni simulaciju uzorkuju. S druge strane, asinkrono je
bilježenje podataka temeljito: njihov im mehanizam rada omogućuje da zabilježe svaku
47
promjenu koja se dogodi na serveru. Iako, kao što ćemo vidjeti, obrada znakovnih nizova (
format u kojem se MOOS poruke šalju na server) zahtjeva dodatan trud, činjenica da nakon
obavljanja simulacije možemo ubrzati ili usporiti vrmeenske intervale mĎu poslanim
podacima, kao i obraditi svaki dogaĎaj koji se zbio predstavlja golemu prednost.
Aktiviranje asinkronog bloga postiže se naredbom
AsyncLog = true
u konfiguracijskoj datoteci pLoggera. pLogger kojim smo se koristili pri bilježenju rezultata
simulacija u ovom diplomskom radu sljedećeg je oblika:
tell all processes where the DB is (default is localhost:9000)
ServerPort = 9000
Serverhost = localhost
ProcessConfig = pLogger
{
AppTick = 10.0
CommsTick = 10.0
File = RovLog
PATH = .
SyncLog = true @ 0.2
AsyncLog = true
WildCardLogging = false
FileTimeStamp = false
Log = Propulsion @ 0
Log = State @ 0
Log = Control @ 0
// Log = Var @ 0
}
Dakako, pri provoĎenju paralelnog simuliranja treba pripaziti da se varijabla ServerPort
prilagodi. Iako su zbog već integrirane aplikacije za pokretanje cijele zajednice klijenata kao i
više zajednica paralelno, pAntlera, ovakvi zahvati nad pojedinim dijelovima koda minimalni,
ipak na njih treba obratiti pozornost inače može doći do grešaka na pojedinim klijentima.
Iako zbog zvjezdolike strukture nema izravnog utjecaja takvog klijenta na druge, posredno
svejedno može doći i do otkazivanja rada čitave platforme. Nužno je u ovom opisu razlikovati
istinsko paralelno izvoĎenje (u kojem više različitih zajednica pristupa istom serveru, ali s
različitim imenima ( čak i ako se radi o jednakim procesima!)) od najobičnijeg naizmjeničnog
sudjelovanja više klijenata u radu jedne te iste simulacije, makar se u obje situacije služimo
istom aplikacijom.
48
4.2. Odabir parametara simulacije
Nakon što je opisano na koji će se način rezultati pohraniti, može se napokon
pokrenuti i nekoliko simulacija u kojima će se preispitati osnovne mogućnosti programa. Već
je naglašeno da izvoĎenje programa neće biti moguće bez da se zajednici koja će u simulaciji
sudjelovati preda odgovarajuća konfiguracijska datoteka. U ovisnosti o složenosti procesa koji
se simulira, te datoteke mogu doseći velik broj elemenata. Priložena je, primjerice, datoteka
za obavljanje misije21
MiniROV, koja se odnosi na ronilicu VideoRay PRO II. Parametri su
preuzeti iz [3]:
ProcessConfig = ROV
AppTick= 10
CommsTick = 10
//@tm parameters
u0 = 0
v0 = 0
w0 = 0
p0 = 0
q0 = 0
r0 = 0
x0 = 1
y0 = 0
z0 = 0
phi0 = 0
theta0 = 0
psi0 = 0
Ix = 2.28e-2 //25
Iy = 2.39e-2 //50
Iz = 2.53e-2 //50
Ixy = 0
Iyz = 0
Ixz = 0
m = 50
xG = 0
yG = 0
zG = 0
xB = 0
yB = 0
zB = -0.1
Xu = 2.3
Yv = 8.01
Zw = 5.81
Kp = 0.0009
Mq = 0.0012
Nr = 0.0048
Xuu = 8.28
Yvv = 23.69
Zww = 20.52
Kpp = 0.0048
Mqq = 0.0069
21 eng. mission file
49
Nrr = 0.0089
Xud = 1.94
Yvd = 6.05
Zwd = 3.95
Kpd = 3.26e-2
Mqd = 1.75e-2
Nrd = 3.21e-2
kL = 0.0005
kD = 0.0005
kY = 0.0015
kl = -0.0001
km = -0.0002
kn = 0.001
Clp = -0.1
Clr = -0.1
Cmq = -2
Cma = -1
rho = 1.025
A = 0.135
l = 0.36
h = 0.23
W = 500
B = 500}
Kao što je vidljivo, broj parametara je nezanemariv, pa se vidi da je programski odsječak u
kojem se u slučaju pogrešno predana konfiguracijske datoteke simulacija odmah prekida bio
itekako nužan.
Drugi dio konfiguracije ronilice kojeg se očekuje od korisnika je funkcija opisa
pogona ronilice. Ponovno je prvi primjer MiniROV, za kojeg ista (u ovom slučaju u modelu s
različitom snagom potisnika prema naprijed i nazad) glasi:
void MiniROV_Propulsion(vector<double>& vdblControls, state& sState,
vector<double>& vdblPropulsions){
double speed_le, speed_ri, speed_vert;
speed_le = vdblControls[0];
speed_ri = vdblControls[1];
speed_vert = vdblControls[2];
double thrust_le, thrust_ri, thrust_vert;
if(speed_le > 0){thrust_le = Cthf*abs(speed_le)*speed_le;}
else{thrust_le = Cthb*abs(speed_le)*speed_le;}
if(speed_ri > 0){thrust_ri = Cthf*abs(speed_ri)*speed_ri;}
else{thrust_ri = Cthb*abs(speed_ri)*speed_ri;}
if(speed_vert > 0){thrust_vert = Ctvf*abs(speed_vert)*speed_vert; }
else{thrust_vert = Ctvb*abs(speed_vert)*speed_vert; }
Dakako, nedefinirani parametri se predaju preko pripadajuće misijske (konfiguracijske)
datoteke.
Parametri za ronilicu Rov opće klase sa 4 horizontalna potisnika u križnom rasporedu
predani su na potpuno ekvivalentan način, a zahvaljujući činjenici da je klijent Propulsion
dovoljno općenit, to da sada imamo 5 varijabli koje mu predajemo umjesto 3 ne predstavlja
50
nikakav problem. Nešto je drugačija situacija sa AUV-om, za kojeg se blok Ronilica morao
bitno mijenjati kako bi se omogućilo, primjerice, opisivanje sljedeće jednakosti:
rdl eD DBasic D dl D dr D eC C C C C
(4-2-1)
Iako su prema [2] konfiguracijski parametri za specifični AUV predani u
odgovarajućoj datoteci na isti način kao i do sada, činjenica da prilagoĎene vrijednosti nekih
od tih parametara ovise o varijablama na koje Ronilica nije izravno pretplaćena (a želeći i
dalje zadržati strukturu koda koja bi nam omogućila jednostavan opis propulzije) napravljen
je kompromis po kojem su svi upravljački signali poput onih prisutnih u (4-2-1) preneseni na
način da je blok Propulsion umjesto jednog za ovaj dio simulacije objavljivao 2 skupa
podataka, dotadašnji vektor Tau (pretvoren u znakovni niz, naravno), te novi vektor
upravljačkih signala kojeg je jednsotavno proslijedio od bloka Control do bloka Ronilica.
Osim u svrhu te pojedinačne simulacije, ova metoda nije zadržana jer bi u ovisnosti o broju
aktuatora ronilice blok Propulsion uvijek slao različit broj vrijednosti sljdećem klijentu, što
nam nikako nije odgovaralo. Prva grupa simulacija provedena je bez posebne regulacije
pojedinih varijabli stanja, dakle bilo proizvoljnim slanjem vrijednosti na potisnike ronilice,
bilo gašenjem motora i provjeravanjem što se sa ronilicom dogaĎa ukoliko već ima neku
početnu brzinu. Te su simulacije, kao i one napravljene uz korištenje raznolikih funkcija u
aplikaciji Control, potom nacrtane u MATLAB-u, a da bi to bilo moguće morali smo iz
logova dobijenih praćenjem tih simulacija izdvojiti potrebne numeričke vrijednosti sljedećom
skriptom:
import sys
flog = open(sys.argv[1])
flog_lines = flog.readlines()
var = sys.argv[2]
var_key = sys.argv[3]
for line in flog_lines:if(line[0] == "%"):#print(line)continue
line_split = line.split()
time = line_split[0]
var_name = line_split[1]
var_source = line_split[2]
var_val = line_split[3]
if(var_name == var):var_val_split = var_val.split(",")
for kv in var_val_split:kv_split = kv.split("=")
if(kv_split[0] == var_key):
print(time + "\t" + kv_split[1])
51
4.3. Grafički prikaz rezultata
Sljedeće slike prikazuju ponašanje triju različitih ronilica bez upotrebe ikakvih
kontrolnih algoritama:
Slika 4-3-1:AUV s početnom brzinom u x i z-smjeru (izranjanje)
Slika 4-3-2:MiniROV sa različitim početnim brzinama pojedinih motora
Slika 4-3-3:Rov Ronilica opće klase okreće se dok izranja
52
Nakon toga implementirani su raznoliki upravljački algoritmi, kao u donjem primjeru:
void LjapunovCourse(
double course, double psistate, double rstate,
double &speed_le, double &speed_ri)
{
double V = -2*rstate*(Iz+Nrd+Nrr*abs(rstate))+Nr*rstate;
double K = abs(V) + 0.01;
double s = (rstate + -2*course);
double Fs;
if(s > 0.02) Fs = 1;
else if(s < -0.02) Fs = -1;
else Fs = s/0.02;
double N = V - 0.5*s - K*Fs;
if(N > 0){
speed_ri = sqrt(N/(2*R*Cthb));
speed_le = -speed_ri;
}else{
speed_ri = -sqrt(-N/(2*R*Cthb));
speed_le = -speed_ri;
}
}
a niže su dani reprezentativni primjeri regulacije pojedinih veličina:
Slika 4-3-4:MiniROV reguliran u klizećem načinu upravljanja( prema [3])
Ovaj je manevar dobiven upravljačkim algoritmom tokom kojeg ronilica, jednom kad
dosegne pravac po kojem se treba kretati, istog više ne napušta.
53
Slika 4-3-5:Podešavanje usmjerenja ronilice od (1,0,0) prema (2,-1,0)
Slika 4-3-6:Moment oko z-osi stvoren u prethodnom manevru
Slika 4-3-7: Rotacijska brzina ronilice tokom gornjeg manevra
U ovom primjeru ronilica je voĎena od točke do točke na način da prvo podesi kurs, potom
pričeka smirivanje, pokuša prijeći zadanu udaljenost u horizontalnoj ravnini, te se nakon toga
podigne vertikalno uvis. Gornje tri slike predstavljaju prvu fazu manevra.
54
Sljedeće dvije slike predstavljaju pokušaj regulacije pomicanja ronilice za 10 metara
unaprijed:
Slika 4-3-8: Prijeđena udaljenost ronilice tokom reguliranog gibanja unaprijed
Slika 4-3-9: Brzina koju je ronilica postigla tkom reguliranog gibanja unaprijed
Za kraj, pokazat ćemo i primjer lošeg algoritma čije se mane može uočiti korištenjem
razvijenog simulatora: riječ je o zaronu ronilice na na fisknu dubinu, a iako se na prvi pogled
ponašanje ronilice čini zadovoljavajućim, kao što se vidi na slici 4 -3-10,
Slika 4-3-10: Regulirani zaron ronilice na 10 metara dubine
graf nam iznosa brzine vertikalnog motora ukazuje na opterećenje koje aktuator trpi:
Slika 4-3-11:Opterećenje aktuatora pri zaronu zbog lošeg upravljačkog algoritma
55
4.4. Paralelno izvršavanje više simulacija
Sve su gornje simulacije izvedene pojedinačno, i to uz pomalo zahtjevno zasebno
povezivanje svakog pojedinog klijenta (Propulsion, Ronilica, Control i DestCtrl) na server. Za
simulacije sa većim brojem pojedinačnih aplikacija koje u njima sudjeluju, takav pristup
očigledno nije optimalan. Na sreću, MOOS platforma ne samo da nudi način da sve
potprograme potrebne za simulaciju pokrenemo odjednom, nego nam pomoću odgovarajućeg
procesa, pAntlera, nudi priliku da istovremeno pokrenemo više takvih zajednica.
Tipično njezino zaglavlje izgleda ovako:
//tell all processes where the DB is (default is localhost:9000)
ServerPort = 9000
Serverhost = localhost
ProcessConfig=ANTLER
{
Run = MOOSDB @ NewConsole = true
Run = DestCtrl @ NewConsole = true,path = ../DESTCTRL/
Run = Control @ NewConsole = true,path = ../CONTROL/
Run = Propulsion @ NewConsole = true,path = ../PROPULSION/
Run = Rov @ NewConsole = true,path = ../RONILICA/
Run = pLogger @ NewConsole = true
// Run = procname [ @ LaunchConfiguration ] [� MOOSName ]
}
ProcessConfig = Rov
....
ProcessConfig = DestCtrl
{
...
}
ProcessConfig = Control
{
...
}
ProcessConfig = Propulsion
{
...
}
ProcessConfig = pLogger
{ AppTick = 10.0
CommsTick = 10.0
File = RovLog
PATH = .
SyncLog = true @ 0.2
AsyncLog = true
WildCardLogging = false
FileTimeStamp = false
Log = Propulsion @ 0
Log = State @ 0
Log = Control @ 0}
// Log = Var @ 0}
56
U njemu uočavamo da za svakog klijenta koji je podreĎen ovom pAntleru on
posjeduje odgovarajuće podatke za njegovu konfiguraciju. Ograničenja kad je u pitanju
korištenje raznih klijenata unutar iste zajednice za neki posao gotovo da ni nema: ne samo da
ne moraju biti na istom računalu, oni čak ne moraju imati niti jednake operacijske sustave.
Pokretanje svih klijenata koji su članovi neke zajednice svodi se na jednostavan poziv
oblika:
pAntler Mission.moos
pri čemu je Mission.moos pripadajuća zajednička misijska datoteka. Naredbe kao što je ova:
Run = pLogger @ NewConsole = true
Označavaju da se pojedini klijent otvori na novoj konzoli. Vizualne karakteristike tih konzola
mogu se ugaĎati nizom dodatnih mogućnosti u čije detalje nećemo ulaziti. Iako u normalnim
okolnostima pAntler očekuje da se pojedini klijent prijavi pod svojim vlastitim imenom, to se
svojstvo može izmijeniti. Ova karakteristika je povoljna, budući da nam omogućava da
pokrenemo više inistanci istog procesa, samo pod drugim imenom. Jedini detalj kod kojeg
moramo biti izrazito oprezni je da takvi procesi moraju imati dvije različite konfiguracijske
datoteke sa tim, novim imenima navedenih klijenata u misijskoj datoteci. Nakon toga,
pokretanje višestrukih simulacija sa po volji odabrane lokacije ne predstavlja nikakav
problem, kao što pokazuje donja slika:
Slika 4-3-12:Provođenje paralelnih simulacija
Zbog potpunosti, navedimo još samo da MOOS platforma podržava i meĎusobnu interakciju
ovako stvorenih paralelnih simulacija, putem aplikacije pMOOSBridge.
57
Zaključak
U ovom diplomskom radu stvoren je općenit simulator podvodnih plovila napisan u
programskom jeziku C++. Najvećim dijelom njegova je struktura potpuno generička, što
omogućava da se na njemu stvore reprezentativni modeli po volji odabranih ronilica. To se
posebno odnosi na dio kojim se modelira propulzija, a na kojeg nisu postavljeni gotovi
nikakvi uvjeti. Programski kod implementiran je na MOOS platformi, čije smo svojstvo da se
na njoj može povezati više različitih aplikacija tokom obavljanja istog zadatka iskoristili za
izvoĎenje paralelnih simulacija različitih plovila, mijenjajući pritom (virtualno) i računalo s
kojeg se tim simulacijama pristupa.
Osim što je provjereno ponašanje pojedinih plovila bez prisustva ikakvih regulacijsih
djelovanja, u klijenta namijenjenog izvoĎenju upravljačkog algoritma unijeli smo nekoliko
različith metoda regulacije varijabli stanja.
Te su simulacije pokazale da je, uz parametre koji odgovaraju stvarnim vrijednostima
plovila koje testiramo, povratna informacija koju dobivamo korisna. Ona se ipak ne može
uzeti kao apsolutno mjerilo vrijednosti pojedinih algoritama, budući da je preciznost
ponašanja modela podložna pogreškama u vrijednosti varijabli koje se programskoj podršci
predaju putem odgovarajućih konfiguracijskih datoteka, bilo da je do tih pogrešaka došlo
ljudskom pogreškom ili pak iz nedovoljnog poznavanja same ronilice koju modeliramo. U
potonjem slučaju, simulator se može koristiti kao značajna pomoć pri iterativnom
pronalaženju sve boljih i boljih estimacija pojedinih parametara koje bi u stvarnim
okolnostima bilo teško mjeriti.
U konačnici, programska podrška razvijena u ovom diplomskom radu predstavlja
jedinstvenu cjelinu, ali jednako tako posjeduje potrebnu modularnost koja joj omogućuje da
se u budućnosti spaja na naknadno stvorene programe prilagoĎene MOOS platformi, a koji bi
njezinu funkcionalnost mogli iskoristiti u složenijim simulacijama.
58
Ključni pojmovi:
Simulator podvodnih plovila, MOOS meĎuprogramska platforma, autonomna podvodna
plovila, daljinski upravljana plovila
59
Literatura
[1] FOSSEN, THOR I: “Guidance and Control of Ocean Vehicles“, John Wiley and Sons,
New York, 1994
[2] BUSCH, REGARDT; “Modelling and Simulation of Underwater Autonomous Vehicle“,
Department of Electrical Engineering,University of Stellebosch, Stelebosch 2009.
[3] WANG, WEI: ‘’Autonomous Control of a Differential Thrust Micro ROV’’, University of
Waterloo, Waterloo, 2006.
[4] MOOS Main documentation,
http://www.robots.ox.ac.uk/~mobile/MOOS/wiki/pmwiki.php/Main/Documentation ,
10.4.2010.
[5] ECKEL, BRUCE i ALLISON, CHUCK : ‘’Thinking in C++, vol. 2:Practical Programming’’,
Paerson Prentice Hall, 2004.
[6] STROUSTRUP, BJARNE: ‘’The C++ Programming Language’’, AT&T Labs, Murray Hill,
New Jersey, 1997.
[7] DOBREF, VASILE i TARABUTA, OCTAVIAN: ‘’Thrust optimization of an underwater
vehicles propulsion system’’, Mircea Cel Batran Naval Academy, Constanta, 2007.
[8] BLINDBERG, D. RICHARD: ''The Development of Autonomous Underwater Vehicles
(AUV); A Brief Summary'', Autonomous Undersea Systems Institute, Lee New
Hampshire, 2000.
.
![LEHUQHWLþNDVLJXUQRVWXKUYDWVNLPPHGLMLPD ...darhiv.ffzg.unizg.hr/id/eprint/11187/1/SVAN HLACA DIPL_SH...UD]OLþLWLKPUHåD te je temeljen na osnovi Interneta, otvorenoj arhitekturi,](https://img.pdfslide.tips/doc/110x75/5e5f902897cdc00eac7fc2ef/lehuqhwlndvljxuqrvwxkuydwvnlpphglmlpd-hlaca-diplsh-udollwlkpuhd.jpg)
