-

Transkripcija

1 Organizacija in management informacijskih sistemov RAZVOJ SPLETNEGA UPORABNIŠKEGA VMESNIKA ZA ROBOTA Mentor: izr. prof. dr. Andrej Škraba Somentor: dr. Radovan Stojanović Kandidat: Robert Babčec Kranj, februar 2015

2 ZAHVALA Zahvaljujem se mentorju izr. prof. dr. Andreju Škrabi ter somentorju dr. Radovanu Stojanoviću za strokovno pomoč pri izdelavi diplomskega dela in tehnične napotke pri izvedbi strojne platforme in aplikacije. Zahvaljujem se tudi vsem, ki so me podpirali pri izvedbi naloge.

3 POVZETEK Magistrska naloga obravnava integracijo interneta in robotske platforme, ki jo lahko upravljamo preko grafičnega uporabniškega vmesnika. Robotsko platformo smo zgradili iz standardnih komponent, majhnega računalnika z Linux operacijskim sistemom, DC motorjev, krmilnika za motorje in Arduino mikrokrmilnika, zunanje brezžične kartice in prenosne baterije. Za upravljanje platforme se uporabniki povežejo na spletni uporabniški vmesnik, kjer v realnem času spremljajo, znotraj 3D izrisanega okolja, odzivnost simulacije in gibanja modela. Za delovanje in upravljanje je vzpostavljena ustrezna informacijska arhitektura, ki tehnično omogoča upravljanje in komunikacijo med napravami odjemalcev in robotsko platformo. Aplikacijski del na strežniški strani je realiziran s pomočjo tehnologije node.js. Uporabniški vmesnik se prilagaja napravam uporabnikov, izdelan pa je s spletnimi tehnologijami JavaScript, CSS in HTML5. KLJUČNE BESEDE: - Uporabniški vmesnik - Node.js - Three.js - Arduino - Kiberfizični sistem

4 ABSTRACT Master's thesis deals with the integration of the Internet and robotic platform that can be controlled through a graphical user interface. The robotic platform was built from standard components, minicomputer with a Linux operating system, DC motors, motor shield, Arduino microcontroller, an external wireless card and a portable battery. To control the platform, users connect to the user interface, where they can monitor model movement in different directions within the 3D animated simulation environment in real-time. A suitable information architecture was designed that enables control and communication between client devices and robotic platform. Application runs on the server side with Node.js and compatible modules. User interface is responsive to the user used devices and made with web technologies JavaScript, CSS and HTML5. KEYWORDS: - User interface - Node.js - Three.js - Arduino - Cyber-physical system

5 KAZALO 1 Uvod Predstavitev problema Cilji naloge Predpostavke in omejitve Metode dela Razvojno prototipiranje Pristopi prototipiranja Faze prototipnega razvoja Analiza zahtev Načrtovanje in oblikovanje rešitve Implementiranje oz. izvedba Uporabnikova ocena in predstavitev Testiranje in nadgradnje Sprejemanje rešitve, obratovanje in vzdrževanje Generirani dokumenti Orodja za razvoj Modeliranje in simulacija D modeliranje Simulacija Arhitektura sistema Uporabljene tehnologije aplikacije V8 JavaScript Node.js Socket I/O Johnny-Five Firmata Three.js WebGL Metode asinhronega programiranja Strojna platforma Strežnik Razvojna plošča Plošča krmilnika motorjev Ostala oprema Strežniška aplikacija latenca Uporabniški vmesnik Načrt Kompatibilnost brskalnikov Odzivnost uporabniškega vmesnika Model in simulacija Kodna povezava vmesnika in strojne oprema Rezultati testiranja vmesnika Mobilna robotska platforma Optimizacija velikosti vmesnika Zaključek ocena učinkov optimizacije Pogoji za uvedbo... 58

6 8.3 Možnosti nadaljnjega razvoja Literatura in viri Kazalo slik Kazalo tabel Kratice in akronimi Priloge... 63

7 1 UVOD Današnja družba v dobi hitrih tehnoloških in tehničnih sprememb zahteva hiter razvoj sistemov. Potreba po hitrosti in odprtokodnosti spodbuja povezovanje različnih področij oz. znanstvenih strok ter projektov preko interneta. Z razvojem številnih spletnih platform, ki služijo kot odlagališče razvojne kode, se pojavljajo metodologije, ki omogočajo hiter razvoj in izdelavo prototipov različnih proizvodov oz. izdelkov. Hiter tehnološki razvoj odpira številne možnosti integracije elektronskih komponent v svetovni splet. Koncept pametnih hiš obstaja že nekaj časa, današnja tehnologija pa omogoča povezovanje vseh tehničnih aparatov, ki jih imamo v gospodinjstvih, v svetovni splet, z namenom oddaljenega nadziranja in upravljanja. Področje, ki ga v delu obravnavamo zajema izgradnjo ustreznega uporabniškega vmesnika za robotsko platformo, ki jo lahko upravljamo preko spleta s tehnikami povezovanja različnih odprtokodnih tehnologij. Integracija interneta in robotskih platform oz. strojne opreme se pojavlja v zadnjem času in zahteva nove pristope k oblikovanju uporabniških vmesnikov ter programskih rešitev. Pri tem obravnavamo povezovanje fizičnega sveta prek interneta v smislu kiberfizičnih sistemov, kar omogoča številne nove aplikacije na področju informacijskih sistemov. Ena od možnosti je kontroliranje fizičnega sveta preko svetovnega spleta od kjerkoli na zemeljski obli, le da ima uporabnik omogočen dostop v svetovni splet. V okviru magistrskega dela predstavljamo razvoj in oblikovanje uporabniškega vmesnika, ki bo omogočal hkratno uporabo robotske platforme z več kot enim uporabnikom. Robotska platforma je sestavljena iz standardnih komponent: Mini ARM PC z Linux operacijskim sistemom, DC motorjev, krmilnika za motorje in Arduino mikrokrmilnika. Pri upravljanju platforme bodo uporabniki preko uporabniškega vmesnika interpretirane ukaze spremljali v resničnem času preko simulacije znotraj 3D okolja. V ta namen je vzpostavljena ustrezna informacijska arhitektura, ki omogoča razvoj in komunikacijo med platformami odjemalcev in robotsko platformo. Uporabili smo strežniško tehnologijo, ki omogoča asinhrono komuniciranje z uporabniki. Uporabniki tako lahko podajajo ukaze na različnih mobilnih platformah. Razvita programska rešitev in ugotovitve bodo omogočile nadaljnji razvoj funkcionalnosti uporabe robotske platforme. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 1

8 1.1 PREDSTAVITEV PROBLEMA Namen dela je vzpostavitev arhitekture informacijskega sistema, ki bo omogočila razvoj uporabniškega vmesnika mobilne robotske platforme. Uporabili bomo na trgu dostopno strojno opremo, ki bo v povezani, zgrajeni obliki predstavljala prototipno robotsko platformo. Le-to bo lahko upravljalo več uporabnikov preko spletnega uporabniškega vmesnika. Strojna platforma bo sestavljena iz različnih med seboj povezanih komponent, zato moramo biti pozorni pri integraciji, predvsem v smislu kompatibilnosti komponent, ki vplivajo na stabilno delovanje. Prav tako moramo zagotoviti ustrezno programsko povezovanje v različnih programskih jezikih, ki morajo na koncu neprekinjeno delovati kot stabilna celota. Pravilna kombinacija tehnologij v prototipu nam bo predstavljala stabilno platformo za razvoj vmesnika ter funkcionalnosti. Udeleženci se v procesu nadziranja tehničnih platform poslužujejo številnih naprav, zato je namen dela tudi oblikovati uporabniški vmesnik na način, da se upošteva različne dimenzije prikazovalnikov naprav na strani uporabnika, kar omogoča lažji nadzor in upravljanje robotske platforme. Ob upoštevanju različnih uporabniških dejavnikov pri uporabi bomo izničili tveganje nepredvidenega obnašanja robotske platforme, ki bi lahko potencialno povzročila nestabilno obnašanje ali odpoved posamezne fizične komponente. Poleg uporabniškega vmesnika bo realizirana tudi simulacija robotske platforme, kjer se bo objekt glede na uporabniške ukaze istočasno odzival v digitalnem in fizičnem okolju. Pri tem ne bomo modelirali fizičnih, nepredvidenih ovir. Delovanje simulacije bo omejeno na podprto strojno opremo. Ugotovili bomo zmožnosti 3D aplikacijskega vmesnika ter njegove potenciale pri integraciji digitalnega in fizičnega sveta. Zaradi dostopnosti ter popularnosti bomo uporabljali izključno odprto kodne aplikacijske vmesnike za razvoj aplikacije. Ustvarjena bo strežniška aplikacija, ki bo služila kot komunikacijski most med uporabniškim vmesnikom in strojno opremo. Uporabljene tehnologije bomo uporabili za razvoj aplikacije na strežniški strani, ki omogoča odjemalcem dostop preko različnih brskalnikov. V glavnem delu naloge bomo razvoj in testiranje izvajali s pomočjo modernih brskalnikov, ki omogočajo WebGL podporo. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 2

9 1.2 CILJI NALOGE Temelj uspešne izvedbe naloge je vzpostavitev ustrezne strojne in programske infrastrukture, ki bo kot celota predstavljala delujočo strojno platformo robota. Na podlagi zgrajene platforme bomo razvili grafični uporabniški vmesnik, ki bo uporabnikom omogočal enostavno upravljanje robotske platforme. V zgrajenem prototipnem vmesniku bomo za posamezne naprave, z uporabo modernih tehnik oblikovanja spletnih vsebin, vzpostavili grafično odzivnost ter strukturo, ki je z vidika uporabnika intuitivna za uporabo. Testiranje odzivnosti vmesnika bomo izvedli na različnih napravah z različnimi resolucijami. Prav tako bomo zmerili latenco med uporabniki in strežnikom znotraj istega omrežja. Do uporabniškega vmesnika lahko dostopa več uporabnikov ter podaja ukaze robotski platformi. 1.3 PREDPOSTAVKE IN OMEJITVE Pri izdelavi robotske platforme se lahko pojavijo številne motnje, napake ali odpovedi na nivoju strojne opreme. Pri tem upoštevamo, da se fizične komponente različno odzivajo na dane električne impulze, kar lahko povzroči dodatno časovno in finančno škodo pri diagnostiki za odkrivanje problema. Elektronske komponente se za svoje delovanje napajajo preko USB vhoda. Za stabilno delovanje strojne opreme robotske platforme v mobilni različici moramo zagotoviti stabilizirano 5V napajanje. Mobilna različica robotske platforme bo za svoje delovanje uporabljala zunanjo USB brezžično kartico, zaradi česar bo latenca in komunikacija z odjemalci večja. Pri uporabi vmesnika s pametnimi telefoni oz. tablicami, določeni uporabniki, ne bodo mogli doživeti iste uporabniške izkušnje, ker številni mobilni brskalniki ne podpirajo ustrezne WebGL tehnologije. Določeni brskalniki namiznih in prenosnih računalnikov prav tako ne podpirajo tehnologije, ki omogoča izdelavo simulacije v 3D okolju. Omejitev prikazovanja simuliranega okolja ni vezana le na brskalnik, ampak tudi na strojno opremo naprave, ki prikazuje vmesnik. Vse naprave, ki imajo nezadostno močan grafični procesor, ne bodo mogle ustrezno prikazati simuliranega grafičnega okolja. Zaradi omejene možnosti testiranja z vsemi možnimi napravami, ki so dostopne na trgu, bomo uporabniški vmesnik omejili na pogosto uporabljene dimenzije določenih naprav. V ta namen bo razvit odzivni vmesnik, ki se bo prilagajal dimenzijam naprave. Odzivnost prilagajanja pa ni odvisna le od ločljivosti naprave, ampak tudi od tehnologij, ki jih brskalnik podpira. Z modernimi brskalniki na napravah bo odzivnost ustrezna. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 3

10 1.4 METODE DELA Metodologija razvoja uporabniškega vmesnika je temeljila na pristopu razvojnega prototipiranja. Na podlagi oblikovane ideje smo vpeljali razvojno metodo zaradi njene ustreznosti, ker bo agilen proces dela omogočal hitro uveljavljanje sprememb. Številne analize ter ocene bodo izvedene, ko se zgradijo posamezni moduli aplikacije. Popravki ter zahteve pa bodo takoj za fazo ocenjevanja implementirani. Odzivnost uporabnikov bo upoštevana na podlagi deskriptivnih zahtev, planirane so številne iteracije produkta, kar predstavlja kratko življenjsko dobo posamezne različice produkta. Glede na razpoložljivost komponent je izdelana robotska platforma, ki ima aktivno povezavo s strežnikom, ki je glavni akter pri izvajanju komunikacije. Povezovanja uporabniškega vmesnika ter izvajanje komunikacije s strojno opremo smo razvili z metodo asinhronega programiranja. Uporabili smo le odprtokodne aplikacijske vmesnike za razvoj programske opreme in komunikacije s pomočjo modula socket.io. Pri razvoju uporabniškega vmesnika smo upoštevali standardne uporabniške dimenzije različnih aparatov in temu primerno zgradili ustrezno odzivnost uporabniškega vmesnika. Uporabniški vmesnik je na strani odjemalca zgrajen s pomočjo spletnih tehnologij HTML, CSS in JS. Največ razvoja je potekalo s pomočjo programskega jezika JavaScript. Znotraj vmesnika smo izdelali digitalni model in izvajanje simulacije objekta v realnem času. Pri tem smo uporabili tehnike 3D vizualizacije s knjižnico three.js in simulacije. Upoštevali smo tudi zmožnosti brskalnikov, ki uporabljajo grafično pospeševanje za izvajanje vizualizacije. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 4

11 2 RAZVOJNO PROTOTIPIRANJE Prototipiranje v procesu razvoja programske opreme načeloma ni samostojna razvojna metodologija. Smatrati ga moramo kot pristop k obvladovanju izbranega dela, ki predstavlja odsek večjega sistema, ki se razvija z bolj tradicionalno obliko razvojne metodologije, kot npr.: RAD, inkrementalni razvoj, V-model, spiralni model (Sommerville, 2011). Prototipiranje se opisuje kot tehnika konstruiranja delne implementacije sistema. Uporablja se ga z namenom zmanjševanja tveganja propada celotnega projekta, ker večji del sistema razbijemo na manjše segmente, ki jih tako lahko lažje obvladujemo. Uporabniki so zajeti v celoten razvojni proces, kar pripomore k večji verjetnosti sprejemanja rezultata programske opreme s strani uporabnikov. Skozi proces se sodelujoči uporabniki ter razvijalci podrobneje seznanijo z definiranim problemom ter njegovo rešitvijo. Metodologija razvojnega prototipiranja je postopna in se uporablja z namenom, da v definiranem razvojnem času, znotraj razvojnih faz, postane samostojni sistem ali delna integracija celotnega sistema (Werber, 2011). Proces prototipiranja v osnovi zajema fazo določanja potreb in definiranja problema, nato se premakne na fazo analiziranja in ciklično kroži nazaj do nje preko faz načrtovanja, implementacije in testiranja, kot to prikazuje Slika 1. Razvoj abstraktne specifikacije Izdelava prototipnega sistema NE Uporaba prototipnega sistema Predaja sistema DA Zadovoljivost sistema Slika 1: Faze procesa razvojnega prototipiranja (Sommerville, 1995). Prototipiranje v spletnem okolju označimo kot način raziskovanja in uresničevanja idej, preden v njih vložimo veliko sredstev in časa. Lahko predstavlja minimalno investicijo, ki pripomore k ugotavljanju uporabnosti modulov, ustreznosti oblike uporabniškega vmesnika v začetnem stanju, kar pomeni manjše investicije na daljši rok (Ravi, 2008). Pri pregledovanju potreb moramo dobro opredeliti probleme in cilje, ter proces uporabe, ki ga bo podpirala rešitev, ker se vsako razvojno okolje mora poskusiti Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 5

12 izogniti reševanja napačnih problemov in uvedbe nepotrebnih funkcionalnosti. Razvojni pristop s svojimi lastnostmi je praktičen za določene scenarije. Izbrani pristop je odvisen od narave dela, obsežnosti projekta ter sredstev. Prototipiranje se lahko uporabi za izdelavo celotnega sistema ali le posamezen del. Na podlagi literature, ki je na voljo, bomo navedli prednosti in slabosti, ki jih prototipiranje omogoča. Ključna prednost prototipiranja je zmanjševanje nesposobnosti uporabnikov pri specificiranju lastnih zahtev. Prototip omogoča razvijalcu ali analitiku boljše razumevanje uporabniških potreb in želja. Uporabnik si pri izdelanem prototipu lažje predstavlja končni izdelek ter lastne potrebe. Na podlagi prototipa lahko lažje odpravimo napake v komunikaciji in ugotovimo ali so implementirane zahteve ustrezne (CMS, 2008). Vnaprejšnje ugotavljanje napačnih implementacij skrajša čas razvoja v nadaljevanju in zmanjšuje število potrebnih iteracij procesa razvoja. Hitra implementacija posameznih modulov v obsežnejši sistem je prav tako praktična z vidika razvijalca, ker se lahko osredotoči le na določen del sistema, ki ga najbolj pozna. Vsak razvojni pristop ima tudi svoje slabosti. V procesu prototipiranja je pogosto problematično hitro sprejemanje dodatnih uporabniških želja in upoštevanje vsake uporabnikove ideje. Glede na izdelan model se potrebe lahko hitro spreminjajo. Nepopolna analiza problematike in površno načrtovanje lahko predstavljata slabo podlago za izgradnjo sistema, ker se lahko izdela sistem, ki je na dolgi rok nestabilen in tog za vzdrževanje in implementacijo novosti, ker so bile prej dodane funkcionalnosti površinsko obravnavane. Številne ponovitve procesa razvoja lahko drastično dvignejo stroške in porabljen čas za razvoj (CMS, 2008). Pri pogovarjanju z odgovornimi osebami ali uporabniki moramo razumeti njihove zahteve in pričakovanja. Nerazumevanje lahko privede do napačnih pričakovanj, kjer uporabnik misli, da je sistem zaključen, ker ne pozna arhitekture delovanja sistema. Vedeti moramo, da vsak prototip ne more izpolniti vseh ciljev, zato lahko uporabniki površinsko mislijo, da so njihove želje izpolnjene, vendar ne vidijo dejanske funkcionalnosti prototipa in posledično dobijo drug rezultat ali ne pridobijo prednosti, ki so dejansko pričakovane iz prototipnega razvoja (Sommerville, 2011). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 6

13 2.1 PRISTOPI PROTOTIPIRANJA Prototipni pristopi so se pričeli uveljavljati v začetku 80-tih z razvojem in pojavom bolj zmogljivih programskih orodij. Namen metode, kjer uporabnik lažje oceni, ali delujoča aplikacija ustreza njegovim zahtevam, je vnaprej opredeliti zahteve še preden se zgradi dejansko programsko okolje. Namen je prav tako preseči ugotovljene slabosti tradicionalnega pristopa SDLC (Software development Life Cylce). Uporabnik pri omenjenem pristopu v primerjavi z drugimi oblikami razvoja programske opreme po standardnem življenjskem ciklu razvoja, uporabi in testira aplikacijo hitreje, kar mu omogoča boljše razumevanje potreb kot v primeru, ko vidi oz. preizkusi aplikacijo šele v fazi realizacije oz. uvajanja rešitve, ko so programske spremembe težavne, stroškovno visoke ter prezapletene (Wikipedia, 2014). S prototipom lahko uporabnik eksperimentira, ga oceni, razvijalec ga lahko (večkrat) dopolni, dokler ne ustreza zahtevam uporabnika. Uporabniške želje se hitro spreminjajo, zato so velikokrat planirane številne iteracije produkta, kar predstavlja kratko življenjsko dobo produkta (Pressman, 2009). Razvojna metodologija omogoča, da se razvijalec na podlagi danih zahtev po spremembah, odloči: 1. Ali bo prototip zavrgel (throw away prototype, expendable prototype). V konceptu gre za ustvarjanje modela, ki se bo sčasoma zavrgel kot pa, da postane del končne verzije programske opreme. Bistvo izdelave modela, ki ga zavržemo je to, da lahko z njim bolj natančno opredelimo zahteve uporabnikov. Uporabniško mnenje ter predloge lahko pri naslednji fazi načrtovanja uporabimo pri izgradnji dejanskega sistema. Metoda razvoja je v primerjavi z drugimi metodologijami hitra, ter omogoča ugotavljanje nedoločenih funkcionalnosti v prvotnem načrtu. Metodologija za izgradnjo je glede na svojo naravo včasih neformalna, saj je za uporabniško predstavitev pomemben faktor razvoja sama hitrost. Model postane začetna točka iz katere uporabnik, po navadi ustno, poda svoja pričakovanja in zahteve. Po dosegu zbiranja zahtev in potrebnih informacij model zavržemo. Prednost je hitrost, ki omogoča izgradnjo uporabniškega vmesnika, ki ga uporabnik dejansko vidi in lahko preizkusi, kar mu omogoča boljšo predstavo kako sistem in vmesnik deluje. 2. Ali ga bo izpopolnjeval do končne aplikacije (razvojni prototip - Evolutionary prototype). Evolucijsko prototipiranje je drugačno od vrste prototipiranja, ko model zavržemo. Glavni cilj evolucijskega prototipiranja je izdelava robustnega prototipa, ki ga v nadaljevalnih fazah stalno dopolnjujemo in izpopolnjujemo. Podobno kot pri prejšnjem omogoča, v samem razvoju, dodajanje sprememb, modulov ter nadgradenj, ki niso bile premišljene v fazi specificiranja zahtev in oblikovanja sistema. Izdelava aplikacije s to metodologijo je stalna, ker aplikacija počasi zori in upošteva zunanje dejavnike pri implementaciji sprememb. Evolucijsko prototipiranje omogoča razvijalcem, da se osredotočijo na nadgradnje posameznih modulov sistema, ki jih najbolj poznajo. Izdelani moduli so delujoči deli sistema, zato jih v primerjavi s prejšnjo metodo ne zavržemo. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 7

14 3. Ali bo določene prototipe zavrgel, določene pa izdeloval po principu evolucijskega prototipiranja. Ta način imenujemo inkrementalno prototipiranje, ker dodajamo določene module obstoječemu sistemu, druge pa po ugotovitvi potreb zavržemo in začnemo z izdelovanjem novega modula. Končni izdelek je sestavljen iz ločenih prototipov, ki se v končni fazi projekta združijo in programsko povežejo v eno celoto (Sadabadi in Tabatabei, 2009). Od izbrane vrste prototipiranja je odvisen tudi napor in čas, ki se vloži v razvoj prototipa. Prototipiranje je praktično v fazah analiziranja in oblikovanja vmesnikov. V fazi analiziranja pa uporabniku predstavi vizualno, kako bo sistem oz. njegov del zgledal. Zato je prototipiranje posebej praktično za oblikovanje uporabniških vmesnikov, kjer sta odzivnost vmesnika in uporabniška izkušnja med seboj močno povezana. Slika 2 prikazuje proces prototipiranja, kjer določene dele programske opreme lahko zavržemo. Zapis zahtev Razvoj prototipa Ocenjevanje prototipa Specificiranje sistema Komponente za večkratno uporabo Razvoj prog. opreme Validacija sistema Dostavljena programska oprema Slika 2: Proces»throw away«prototipiranja (Sommerville, 1995). Uporaba prototipov ni vedno primerna. Npr. pri velikih projektih in sistemih, ki jih ne razumemo dobro, sistemih, ki delujejo v realnem času, dogodkovno usmerjenih sistemih in sistemih, kjer se hitro izvajajo spremembe notranjih in zunanjih dejavnikov. Uporaba prototipov je bolj primerna pri uporabniških vmesnikih, kjer so cilji jasni, z rešitvijo, ki si jo uporabniki lažje predstavljajo (CMS, 2008). Tekom načrtovanja moramo vključiti minimalne funkcionalnosti, da je izdelek sposoben preživeti na trgu. Slabost prototipiranja je, da se pri razvoju funkcionalnosti hitro pojavijo nepredvideni stroški in številni razvojni timi ne izvajajo celovitega testiranja (Wilson in drugi, 1992). Prav tako ni priporočljivo za izdelavo sistemov z malo uporabniške interakcije, kot npr. pri zaporedni obdelavi podatkov (angl. batch processing). Težje kalkulacije zahtevajo večji napor in vložen čas, zato v takšnih primerih potencialne pridobitve ne opravičijo vložka in niso smotrne (Sadabadi in Tabatabei, 2009). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 8

15 Metodologija razvojnega prototipiranja se v različnih situacijah in razvoju priporoča v številnih situacijah in primerih. Uporabniki niso dovolj podkovani v procesu, ki ga želijo programsko podpreti, zato ne vedo kaj želijo. Tehnično ali procesno neznanje jim onemogoča definirati ali izražati lastne zahteve. Zaradi hitrih sprememb se spremenijo funkcije poslovanja, kjer uporabniki v procesu dela najbolj poznajo postopke, ki jih je potrebno informatizirati, zato je metodologija razvojnega prototipiranja uporabna pri spremembah poslovnega sistema in njegovega delovanja, podpori in izdelavi uporabniških vmesnikov, vpeljevanju in informatiziranju izboljšav v procesih dela. Ozkoglednost uporabnikov onemogoča optimizacijo delov, zato je prototipiranje dobra metoda prepričevanja za vpeljavo novih rešitev. Časovna zasedenost in finančna sredstva ne morejo podpreti dragih sistemov za reševanje poslovnih procesov, kar pomeni, da je lažje izdelati prototip, ki izboljša proces v obstoječem sistemu. Uporaba razvojnih prototipov je predvsem priporočljiva in učinkovita pri izdelavi sistemov, kjer sodelujoči odločevalci ter uporabniki niso sposobni konkretno definirati, kaj naj bi vse izdelan sistem omogočal. Na podlagi stalnega spreminjanja v povezavi z izdelanim prototipom naredimo povzetek, ocenimo skrbi uporabnikov o funkcionalnostih ter pri načrtovanju in oblikovanju upoštevamo čas, ki ga imamo na voljo za nadaljnji razvoj, hitrost delovanja, natančnost izvedbe glede z načrtovanim prototipom in velikost projekta. V vsaki razvojni fazi mora biti dosledna izdelava dokumentacije naravni del projekta (Oshana in Kraeling, 2013). Na podlagi pogostih zatikanj v praksi lahko prototipiranje glede na cilj delimo v dve kategoriji. Inkrementalno prototipiranje, katerega namen je dostaviti delujoč sistem končnim uporabnikom, kjer razvoj s takšnim ciljem po navadi začnemo s komponentami oz. moduli, ki jih najbolje razumemo. Drugo predstavlja»throw away«prototipiranje, ki je validacija sistemskih zahtev, kjer se proces prototipiranja začne z elementi, ki jih najmanj razumemo (Sommerville, 2011). Napake odkrite v zgodnji fazi razvoja so cenejše in časovno učinkovitejše za odpravo. Odpravljanje napak je časovno zamudno in dražje odpraviti v fazi izdelave, kot če bi bilo to storjeno že v fazi načrtovanja. V najslabšem primeru se lahko zgodi, da v fazi izdelave ugotovimo, da je neko komponento nemogoče izvesti. Tudi oblikovalci ne morejo predvideti težave, ki lahko potencialno nastanejo oz. se ugotovijo pri izvajanju v prihodnosti, ker le-te do faze izvajanja no morejo biti jasno opazne. V takšnih primerih, kjer se ugotovijo nejasnosti, je bolj praktično popraviti načrt (Werber, 2011). Izdelana prototipna rešitev v razvojnih skupinah ne spodbuja veliko sprememb v samem načrtu, več se pojavlja diskusija glede operativnih problemov v izdelanem prototipu (Johansson in Arvola, 2007). Slabosti razvojnega prototipiranja se pojavijo v primerih, ko naročnik ni seznanjen z vsemi zahtevami, ki jih bomo potrebovali v naslednjih fazah. Prav tako je problem, če se zahteve naročnika naknadno spremenijo od faze načrtovanja, kar predstavlja dodatni strošek s ponovno izdelavo ali popravljanjem načrta in daljšanja časa izvedbe (CMS, 2008). Ne glede na vrsto in način prototipiranja se pri hitrem razvoju velikokrat pojavi nedokumentirana koda, degradacija sistema na dolgi rok, zaradi težavnosti izvajanja popravkov in nadgradenj ter zmanjševanje zanesljivosti, varnosti ter hitrosti delovanja (Sommerville, 2011). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 9

16 2.2 FAZE PROTOTIPNEGA RAZVOJA Najbolj splošni življenjski cikel prototipnega razvoja se začne z zasnovo in oblikovanjem zahtev uporabnika, kjer se generira dokument uporabniških zahtev. V osnovi je v tej fazi model prototipiranja bolj svoboden kot na primer V-model, kjer moramo imeti že definirane procese in uporabniške zahteve, vendar pa je priporočljivo, da z dobro definiranimi cilji in idejo zasnujemo sam začetek. Faza se nadaljuje tako, da skoči v cikel oblikovanja oz. načrtovanja arhitekture, tehnologij, izdelavo oz. implementacijo, testiranje in posvetovanje z uporabniki, izvedbo popravkov in oblikovanje nadgradenj, kot to prikazuje Slika 3. Ta predel procesa kroži dokler se uporabnik ne strinja z narejeno rešitvijo, kjer se potem proces premakne naprej na nadaljnji razvoj, testiranje in vzdrževanje. Analiza zahtev Načrtovanje in oblikovanje Prototipiranje Ocena uporabnika Pregled in posodobitve Stranka je zadovoljna Vzdrževanje Testiranje Razvoj Slika 3: Faze metode prototipiranja. Proces prototipnega razvoja lahko strnemo v šest osnovnih faz: Analiza zahtev (angl. Requirements analysis) Načrtovanje in oblikovanje rešitve (angl. Design) Implementiranje oz. izvedba (angl. Prototyping) Uporabnikova ocena in predstavitev (angl. Customer evaluation) Testiranje in nadgradnje Sprejemanje rešitve, obratovanje in vzdrževanje (angl. User acceptance and maintainance) Pri vsakem razvoju je na koncu potrebno razjasniti delovanje končne programske rešitve, ugotoviti primernost uporabniške izkušnje na osnovi preverjanj, po potrebi uvesti spremembe, ki jih zahteva naročnik ter izvesti podrobno testiranje. Število iteracij faz procesa prototipiranja ponavljamo dokler programski produkt ne odgovarja končni, načrtovani verziji, ki je primerna, da postane končni sistem oz. njegov del. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 10

17 2.2.1 Analiza zahtev Pri vsakem projektu razvoja informacijskega sistema, ki je rezultat nekih zahtev, je potrebno formulirati dokument, ki vsebuje uporabniške zahteve in izpolnjuje potrebe poslovnega procesa. Analiza predstavlja proces določanja osnovnih zahtev z želenimi vhodnimi in izhodnimi informacijami. Podrobnosti kot so varnost se po navadi v tej fazi ignorirajo (Sadabadi in Tabatabei, 2009). Rezultat analize je definicija oz. specifikacija zahtev, ki predstavlja začetno točko načrtovanja. Programska arhitektura je prav tako določena v tej fazi Načrtovanje in oblikovanje rešitve Faza načrtovanja zajema aktivnosti od programskih specifikacij do definicij implementiranja in uporabe tehničnih elementov. Postopek oblikovanja ter načrtovanja rešitve lahko poteka v več nivojih in postopno. Rezultat je seznam hierarhične in več nivojske strukture v obliki modulov, podanih v načrtu izvedbe (Werber 2011) Implementiranje oz. izvedba V tej fazi je zajet razvoj programske opreme, ki bo zadostil vsem uporabniškim zahtevam. Pri razvoju uporabniških vmesnikov je v fazi implementacije razvit le osnovni prototip uporabniškega vmesnika (Sadabadi in Tabatabei, 2009). Faza prav tako zajema izdelavo prototipa, ki omogoča končnim uporabnikom konkretno predstavo načrtovane programske opreme, zgrajene iz številnih modulov (Sommerville, 1995) Uporabnikova ocena in predstavitev V tej fazi poteka evaluacija prototipa, kjer si lahko uporabnik ogleda zmogljivosti prototipa in s tem potencial sistema. Proces se znotraj faze odvija od potrditve za nadaljnji razvoj, definiranja potrebe po popravkih, do ponovne implementacije, kar predstavlja krožni proces (Werber, 2011) Testiranje in nadgradnje Dokumentacija, ki zajema dnevnik testiranja se ustvari v tej fazi. Cilj testiranja je preverjanje, da uporabniška rešitev odgovarja funkcionalnim zahtevam ter, da zgradi zaupanje v sistem, da je sposoben izvajati funkcije za katere je bil zgrajen (Sommerville, 2011) Sprejemanje rešitve, obratovanje in vzdrževanje V fazi končne rešitve potrdimo prototip in lahko nadaljujemo z nadaljnjim razvojem celotnega sistema oz. vzdrževanjem rešitve (Werber, 2011). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 11

18 2.3 GENERIRANI DOKUMENTI Posamezna faza, ki se nahaja v procesu prototipnega razvoja, da kot rezultat različne vrste dokumentacije. Spodaj je opisan seznam dokumentov s posameznimi zahtevami, ki omogočajo izvedbo in uporabo modela v praktičnem procesu razvoja programske rešitve (Werber, 2011). Analiza zahtev (angl. Requirements analysis): Dokument z zahtevami uporabnikov in zahtevami sistema o Funkcionalne zahteve, o zmogljivostne zahteve, o oblikovne zahteve, o cilji, o željeni rezultati, o varnostne zahteve, o diagram arhitekture, o uporabljene tehnologije, o splošno organizacijo informacijskega sistema, o itd. Načrtovanje in oblikovanje rešitve (angl. Design): Dokument s programskimi specifikacijami. o Strukture menijev, o podatkovne strukture, o itd. Tehnična dokumentacija. o Diagrami entitet, o podatkovni slovarji. Seznam modulov in njihove karakteristike. Podatkovne tabele. Implementiranje oz. izvedba (angl. Prototyping): Dokument komentarjev, spremljanje različic kode (SVN). Uporabnikova ocena in predstavitev (angl. Customer evaluation): Potrditev oz. zavrnitev, zapisnik komentarjev. Testiranje in nadgradnje. Dnevniki testov, dnevniki popravkov. Sprejemanje rešitve, obratovanje in vzdrževanje (angl. User acceptance and maintainance). Izvedba in zaključena opravila definirana s pogodbo (Sommerville, 2011). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 12

19 2.4 ORODJA ZA RAZVOJ Številna orodja in programi omogočajo razvoj programske opreme, vendar pa se poleg svojih implementiranih funkcionalnosti pričakuje njihova zanesljivost delovanja, sposobnost rednega vzdrževanja in nadgradnje s popravki ter prenosljivost med sistemi (Werber, 2011). Številne tehnike pristopa razvoja omogočajo različne načine izgradnje ter uporabe programskih orodij. Uporabljena orodja na podlagi literature za razvoj prototipov bi morala vsebovati sledeče integrirane komponente, karakteristike in lastnosti kot jih navaja Sommerville (1995): Orodja naj bi imela integriran sistem za prototipiranje interaktivnih sistemov. Uporabljajo naj tehnike objektno orientiranih jezikov. Vsebovati morajo podporne vtičnike z orodji, ki omogočajo izdelavo grafičnih uporabniških vmesnikov. Vsebujejo naj jezik četrte generacije. Omogočati morajo specifičen jezik področja poslovnega sistema, ki je povezan s sistemom za upravljanje podatkovne baze. Dobro je, da imajo integrirana orodja primerov iz prakse. Cenovno morajo biti dostopna tudi za mala in srednje velika podjetja. Podporna orodja naj bi pri hitrem razvoju sistemov visokih kakovosti omogočala tudi Generatorje izrazov in kode (CMS, 2008). Elementi uspešnega prototipiranja so hitrost, iterativnost in uporaba strokovnjakov s področja na katerem prototipiramo (Sadabadi in Tabatabei, 2009). Strokovnjaki s področja za katerega izdelujemo prototip morajo za integracijo svojega razumevanja uporabniških potreb, razumeti okolje v katerem se prototip razvija. V primeru, da je okolje zanje prezahtevno morajo tesno sodelovati z razvijalci in analitiki prototipiranja. Pogosto se uporabljajo generatorji grafičnih okolij, ki omogočajo razvijalcem, da svojim uporabnikom pokažejo kako bo sistem izgledal, čeprav še ni funkcionalen. Oblikovni del je uporabnikom zelo pomemben, ker velikokrat za njih to tudi predstavlja sistem, ki ga bodo uporabljali. Glede na tehniko prototipiranja moramo imeti v mislih, da vsa orodja niso vedno primerna za vse vrste projektov. Vsako orodje ima svoje prednosti in slabosti. Upoštevati moramo krivuljo učenja, če se z orodjem uporabnik prvič srečuje. Za večje projekte, kjer po navadi dela 10 ali več ljudi se lahko zahteve po funkcionalnostih razširijo v primerjavi s prej naštetimi opcijami. Orodje v okoljih, kjer sodeluje večje število sodelujočih razvijalcev mora pri razvojni metodi dodatno nuditi optimalno izkoriščanje strojnih zmogljivosti, hitro dostopanje do podatkovne baze ter možnost revizije sprememb. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 13

20 3 MODELIRANJE IN SIMULACIJA V delu je cilj znotraj uporabniškega vmesnika prikazati simulirano gibanje objekta. Model smo zgradili v odprtokodnem orodju Blender (Blender, 2015). Smisel uporabe modeliranja je enostavna ponazoritev sistema ter njegovo delovanje z namenom boljšega razumevanja. Znotraj dela smo v uporabniškem vmesniku vzpostavili simulacijo gibanja, v kateri uporabniki, tudi v primeru svoje fizične neprisotnosti, dobijo občutek zavedanja kaj se z realnim modelom dogaja, ker v resničnem času gledajo gibanje modela znotraj simulacije. Simulacijo izvajamo z namenom upodabljanja ali predvidevanja nekega vedenja. Računalniško generirani simulacijski modeli so precizni ter omogočajo boljši pregled nad izvedenim procesom. Število iteracij, kalkulacij ter obdelave različnih spremenljivk po številnih modelih se izvedejo hitreje (Debevec in drugi, 2003). Simulacijo bomo izvajali znotraj uporabniškega vmesnika, ki bo del celotnega sistema, ki ga bomo opisali v nadaljevanju. V teoriji je sistem celota predpisov, pravil, ki urejajo določeno področje, sistem vsebuje med seboj povezane elemente. Elementi so najmanjše enote, ki jih ne moremo ali nočemo deliti (Škraba in drugi, 2011). V razvojni fazi smo definirali potrebne spremenljivke, ki so kritične za izvedbo simulacije. Naš element bo predstavljal modeliran objekt robotske platforme. Njegova odzivnost bo temeljila na podlagi uporabniške akcije. Ključne spremenljivke za simulacijo pa so hitrost in rotacija. Pri oblikovanju modela bomo izbrali 3D tehniko modeliranja. Okolje in prostor v katerem se bo gibal model je zgrajeno iz številnih spremenljivk, ki jih bomo v nadaljevanju bolj podrobno razložili. Določeni elementi vizualizacije so predstavljeni v vektorski obliki. V kolikor je bilo možno, smo izvajali iteracije vektorskega risanja, npr. pri izgradnji mreže po kateri se bo objekt premikal. V razvoju lahko uporabimo različna okolja za modeliranje in metodologije, pod pogojem, da se lahko simulacijo zažene. Zagonska okolja omogočajo lažje razumevanje ter omogočajo večjo preglednost pri prepoznavanju težav. Arhitektura, ki omogoča zagonsko okolje lahko pomaga pri identifikaciji pomanjkljivosti sistema v dinamičnih situacijah preden se sistem zgradi, kar omogoča cenejši in hitrejši postopek izdelave (Gianni in drugi, 2014). Relativno mlada znanstvena disciplina modeliranja in simulacije je sistematična študija procesa modeliranja in procesa simulacije, ki opisuje in oblikuje konceptualizacijo. Disciplina zajema študije konceptualizacije, njihovo teorijo, analizo, načrtovanje, ugotavljanje efektivnosti, implementacijo, validacijo, verifikacijo in aplikacijo (Padilla in drugi, 2011). Pri izbiri okolja modeliranja moramo upoštevati, da je sposobno predstavitve problema, ki ga rešujemo. Vsa orodja in jeziki modeliranja omogočajo nedvoumno predstavitev potreb, predvidevanj, omejitev in pridobljenih rešitev na različnih nivojih in scenarijih. V jedru gre za predstavitev modelov s temelji matematike, ki jih z določeno sintakso oz. semantiko lahko izvedemo (Gianni in drugi, 2014). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 14

21 3.1 3D MODELIRANJE Računalniški svet 3D modeliranja tretira modeliranje kot proces ustvarjanja nekega 3D objekta s pomočjo matematičnih pravil. Izdelek imenujemo model, ki ga lahko prikažemo kot 2D sliko preko procesa, ki ga imenujemo rendering ali kot model, ki je lahko animiran znotraj računalniške simulacije. Modeliranje se navezuje na matematično modeliranje fizičnih sistemov in predstavlja umetnost imitiranja in opisovanja narave z matematičnimi enačbami. Glavni cilj modeliranja je izolirati določen del naravnega sveta in razumeti procese, ki ga oblikujejo (Luis in Barrales, 2008). Proces izdelave objekta imenujemo digitalno kiparjenje, katerega rezultat je 3D model, ki uprizarja poljuben objekt. Zgradbo celotnega modela imenujemo mesh. Mesh je vizualna predstavitev, ki je zgrajena iz ploskev, robov in oglišč. Z vsemi elementi modela lahko uporabnik znotraj orodja manipulira. Generiran model v Blenderju smo izvozili s pomočjo Blender 2.65 izvoznega modula. Objekt je sestavljen iz 8550 oglišč, 8480 ploskev in 7122 tridimenzionalnih vektorjev, ki stojijo pravokotno na površini. Za animacijo pa uporablja 20 animacijskih oblik. Ker je model zgrajen z namenom le simuliranja gibanja objekta v realnem času nismo ustvarili grafičnih barvnih elementov in tekstur. Končen izgled znotraj orodja v pogledu žičnega okvirja prikazuje Slika 4. Slika 4: Pogled žičnega okvirja. Koncept izgradnje okolja in modeliranja, ki ga bomo uporabili temelji na API-ju Three.js, ki omogoča objektno orientiran pristop pri izgradnji okolja simulacije. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 15

22 3.2 SIMULACIJA Omenili smo, da moramo pri izdelavi simuliranih okolij najprej izbrati okolje ter definirati ključne spremenljivke za izvajanje le-te. Da lahko izvajamo računalniško simulacijo in začnemo reševati problem je potrebno dobro poznavanje problema (Kljajić in drugi, 2000), pri čemer moramo imeti opredeljen cilj modeliranja in obseg obravnavanega sistema, definirati moramo spremenljivke interakcij modela in okolja ter matematično opredeljene dele z ustreznimi enačbami modela, ki so primerne za izbrani simulacijski jezik (Debevec in drugi, 2003). Pri izgradnji simulacije modela in okolja smo uporabili številne spremenljivke, ki omogočajo izdelavo in prikazovanje objektov. Pri izdelanem modelu so za simulacijo potrebne spremenljivke hitrosti gibanja ter hitrosti rotacije. Izbrano hitrost smo pridobili z metodo eksperimentiranja. Simulacija se v idealnem strojnem okolju izvaja s hitrostjo najmanj 60 sličic na sekundo oz. enoto FPS. V simulacijskem okolju smo vgradili števec, ki kaže čas izvedbe rendiranja za posamezno sličico. V simulaciji znotraj uporabniškega vmesnika je željena čim nižja številka, ki se meri v enotah milisekunda. Gibanje modela ne deluje po principu povratne zanke, ker je vhodna vrednost stanja modela v prostoru neodvisna od povratnih informacij uporabnika. Uporabnik s posamezno akcijo definira vsako stanje posebej. Postopek izvajanja simulacije poteka na način kot ga prikazuje Slika 5. V prvem koraku se izvede inicializacija objektov in okolja, ki omogoča prvotno rendiranje celotne scene. V drugem koraku se začne izvajanje funkcije animacije, ki znotraj svojega sklopa spreminja stanje objekta ter hitrost, ki ju v procesu uporablja za premik objekta. Stanje objekta se spremeni preko vhodne uporabniško sprožene informacije, ki v vizualiziranem svetu spremeni obnašanje objekta. Korak 1. Korak 2. Animacija Inicializacija okolja in objekta Stanje objekta Hitrost Izvajanje simulacije Uporabniško sprožena vhodna informacija Slika 5: Izvajanje simulacije. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 16

23 Teorija sistemov predstavlja interdisciplinarno vedo, ki stremi k razumevanju naravnih in s strani človeška zgrajenih sistemov (Škraba in drugi, 2011). Naš sistem, v katerem bomo izvajali simulacijo, je umeten. Okolje simulacije poteka na tehnologiji WebGL, z njim pa direktno komunicira knjižnica Three.js, ki jo bomo uporabili pri izgradnji okolja simulacije. Simulacijo uporabljamo, ker želimo prikazati odzivnost simuliranega objekta v digitalnem okolju glede na dane informacije. Računalniška simulacija je postala sinonim za simulacijo kot tehniko reševanja problemov. V teoriji se mnogokrat omenja, da je namen simuliranega okolja, analiza odzivov sistema v prihodnjem času ter povečanje razumevanja obravnavanega sistema (Kljajić in drugi, 2000). Znotraj dela obravnavamo simulacijo ter odzivnost v realnem času z namenom boljšega razumevanja problema povezovanja simulacije ter fizičnega objekta ter okolijskih spremenljivk. Vpeljana rešitev je preprosta in v izvedeni fazi ne omogoča upoštevanja drugih fizičnih zunanjih dejavnikov okolja. Za simulatorje robotov sta ključna elementa celotna arhitektura in metodologija nadzora. Za izvedbo je potreben robustni sistemski pristop za fleksibilno in dodelano simulacijsko strategijo. Pri razvoju s poudarkom na modularnosti, skalabilnosti in razširljivosti omogočamo, da simulacija ostane robustna ko izdelujemo robotske sisteme, kjer se določene sistemske specifikacije ne morejo predvideti (Ando in drugi, 2010). Modularnost arhitekturnih elementov simulacijskega okolja omogoča hitrejše modifikacije z namenom doseganja izpolnjevanja simulacijskih potreb kompleksnih robotskih sistemov. V nadaljevanju klasificiramo sistem, ki ga bomo uporabljali pri razvoju ter njegove elemente z medsebojnimi relacijami. Izdelava robotske platforme in simulacije se odvija sočasno. Pri upoštevanju sistema gibanja v realnem svetu tehnično in strojno ne bomo podprli s točnim določanjem pozicije. Določanje pozicije je ključni problem na področju navigiranja mobilnih robotov (Hess in Schilling, 2010). Za izboljšanje in definiranje točne lokacije v zunanjem okolju bi lahko uporabili GPS, vendar se bo testiranje zaradi tehničnih omejitev izvajalo v notranjosti. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 17

24 4 ARHITEKTURA SISTEMA Slika 6 prikazuje splošno sistemsko arhitekturo. Jedro arhitekture predstavlja spletni in aplikacijski strežnik z nameščenim Linux sistemom. Na strežniku imamo priklopljen mikrokrmilnik, na katerega je priklopljen krmilnik za upravljanje DC motorjev s katerimi je tudi povezan. Glavni mikrokrmilnik ima dodatno baterijo za napajanje DC motorjev. Vzpostavili smo dve instanci delujočega sistema, v kateri se en strežnik napaja preko napajalnika za prenosnik, drugi pa preko prenosne baterije z USB izhodom. Linux Spletni in aplikacijski strežnik Mikrokrmilnik z DC motorji in dodatno baterijo Uporabniške naprave s prikazanim vmesnikom, ki so povezane v isto omrežje kot strežnik. Vir energije za napajanje strežnika. Slika 6: Sistemska arhitektura. Desni predel, ki ga prikazuje Slika 6, predstavlja uporabniške naprave, ki so povezane v isto omrežje v katerem teče strežnik. Uporabniki pošljejo zahtevo na strežnik, ki jim posreduje vse potrebne datoteke za zagon aplikacije. Strežnik in uporabniške naprave so povezane v isto brezžično omrežje. Usmerjevalnik je stacionaren in omogoča pošiljanje podatkovnih paketov znotraj lokalnega omrežja. Usmerjevalnik dodeli stacionaren IP naslov strežniku in žično povezanim napravam, medtem ko ostale naprave pridobijo naslov dinamično, ko vzpostavijo povezavo z brezžično točko. Slika 7 prikazuje uporabljene komponente za izdelavo robotske platforme. 1a in 1b predstavljata strežnika z Linux operacijskim sistemom. Ustvarili smo dva sistema. Eden je ustvarjen iz komponent 1a, 2, 3. Drugi je sestavljen iz komponent 1b, 2, 3, 4, 5 in 6. Na 1a ali 1b se povezuje 2 preko USB kabla, ki predstavlja mikrokrmilnik Arduino in krmilnik za upravljanje DC motorjev. 2 je v obeh instancah povezana na 3, ki predstavlja DC motorja. V drugi instanci, kjer je strežnik 1b, vklopimo 4, ki predstavlja baterijo za dodatno napajanje DC motorjev. Strežnik 1b ima na voljo en standarden USB izhod ter dodaten mikro USB vhod. Za lažje povezovanje naprav smo na 1b priklopili 5, ki predstavlja USB 2.0 razdelilnik s štirimi vhodi. 6 predstavlja zunanjo brezžično USB kartico, ki je povezana na 5, da lahko komunicira z 1b strežnikom. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 18

25 5 3 1b 1a Slika 7: Komponente sistema. Programsko arhitekturo sistema, pri kateri smo izhajali iz primera (Škraba in drugi, 2014) prikazuje Slika 8. Na mikrokrmilniku se izvaja Firmata, ki je povezana z node.js sistemom in njegovim modulom Johnny-five, ki uporablja Firmata API. Node.js omogoča komunikacijo med odjemalec-strežnik. Socket.io se izvaja asinhrono, uporabljamo pa ga za izmenjavo ukazov in sporočil. V sklopu odjemalca se izvaja uporabniški vmesnik, ki izrablja WebGl in Three.js za prikaz simuliranega gibanja robotske platforme, samo grafično okolje pa je izdelano v tehnologijah HTML5 in CSS. Brskalnik JavaScript Node.js Three.js WebGl Interni node.js moduli Socekt.io Socekt.io HTML5 in CSS Johnny-five in firmata Firmata WiFi USB Odjemalec Strežnik Arduino Slika 8: Programska arhitektura kiberfizične platforme z nivoji strojne opreme. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 19

26 4.1 UPORABLJENE TEHNOLOGIJE APLIKACIJE Pri izdelavi vmesnika in programskega komunikacijskega mostu smo uporabili številne knjižnice in API-je, ki v veliki večini bazirajo na skriptnem jeziku JavaScript. JavaScript se v glavnini uporablja znotraj brskalnikov in se izvaja na strani odjemalca. Implementacija jezika omogoča razširitev funkcionalnosti in dinamičnosti današnjih spletnih strani. V zadnjih letih pa se, zaradi popularnosti uporabe njegova sintaksa seli tudi na strežniška okolja kot je node.js. Klasificiran je kot prototipno usmerjen in objektno orientiran skriptni jezik. JavaScript je implementacija skriptnega jezika ECMA Script (ECMA, 2015). V delu bo JavaScript služil kot glavni jezik za razvoj komunikacijskega vmesnika, ki bo deloval na strežniški strani robotske platforme. Kombinacija protokolov, knjižnic in aplikacijskih vmesnikov nam omogoča izgradnjo aplikacije na strani strežnika, ki na eni strani direktno komunicira s strojno opremo, medtem ko na drugi streže ustrezne datoteke in skripte odjemalcu, od katerega v resničnem času sprejema ukaze za izvajanje. Na Arduinu smo namestili Firmata protokol, kjer se lahko popravke izvaja v C++ programskemu jeziku znotraj IDE okolja V8 JavaScript V8 je rezultat podjetja Google (Chrome V8, 2012), ki predstavlja odprtokodni JavaScript pogon. V8 je napisan v jeziku C++, uporablja pa se v spletnem brskalniku Google Chrome, ki predstavlja odprtokodni brskalnik prej omenjenega podjetja. V8 se lahko izvaja samostojno ali integrirano v katerikoli aplikaciji, napisani v programskem jeziku C++. V8 ima implementirano ECMAScript-o. ECMAScript je definiran s strani standarda ECMA-262. Standard je trenutno v svoji peti izdaji, popolnoma usklajen s tretjo izdajo mednarodnega standarda ISO/IEC 16262:2011 (ECMAScript, 2011). Peta izdaja deluje na operacijskih sistemih Windows od XP naprej, Mac OS X od 10.5 naprej in Linux operacijskih sistemih, ki uporabljajo IA-32, x64, ali ARM procesorje. V8 JavaScript pogon je oblikovan za hitro izvedbo velikih JavaScript aplikacij. V primerjalnih testih se je V8 izkazal za hitrejši pogon kot Jscript (IE), SpiderMonkey (Firefox) in JavaScriptCore (Safari) (V8 Bechmark, 2013) Node.js Node.js predstavlja pogon na strežniški strani, ki uporablja V8 JavaScript pogon, dogodkovno zanko, nizko-nivojski I/O API in sintakso skriptnega jezika JavaScript. Glavni namen pogona je prejemanje in odgovarjanje na http zahteve s strani odjemalcev. Bistvo pogona je, da so vsi ukazi dogodkovno usmerjeni, ki s pomočjo JS-a omogočajo izdelavo hitrih in nadgradljivih aplikacij in omrežnih ter spletnih storitev (Teixeira, 2013). NPM (Node Package Manager) predstavlja močno ogrodje za urejanje paketov programske opreme, ki deluje kot centralizirano odložišče za različne module, ki jih lahko uporablja Node.js Preko NPM-a smo namestili, testirali in uporabili specifične knjižnice, ki so nam omogočile komunikacijo programske opreme s strojno opremo. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 20

27 4.1.3 Socket I/O Koncept knjižnice socket I/O je dvostranska komunikacija med klienti in strežnikom v resničnem času. Za izvedbo dvostranske komunikacije potrebujemo knjižnico na obeh straneh akterjev, klienta in strežnika. Tako kot node.js gre za dogodkovno usmerjene operacije, ki pri komunikaciji uporablja»websocket«protokol (Socket I/O, 2015) Johnny-Five Johnny-Five je odprtokodna knjižnica, ki temelji na firmata protokolu, IoT in programskemu razvojnemu okolju za robotiko. Sestavljen je iz številnih API-jev, ki omogočajo konsistentno povezavo in robustno povezovanje s številnimi mikrokrmilniki (Johnny-five, 2015) Firmata Firmata je generičen protokol, ki služi za komunikacijo med mikrokrmilniki in programsko opremo na računalniku gostitelja. V samem smislu je generičen, ker omogoča izdelavo strojne programske opreme brez da bi nam bilo potrebno ustvarjati lastne protokole in objekte za programsko okolje, ki ga uporabljamo. Strojna programska oprema vzpostavi protokol za izmenjavo informacij z gostiteljsko programsko opremo, kar predstavlja popoln nadzor strojne opreme preko programske opreme na računalniku gostitelja (Firmata.org, 2015) Three.js Three.js predstavlja fleksibilno in prostorsko nezahtevno JavaScript knjižnico, ki se uporablja za prikaz animiranih 3D grafičnih elementov preko spletnega brskalnika. Pri izvedbi kode uporablja WebGL. Prednost knjižnice je JavaScript sintaksa, kar prihrani čas učenja, vendar je kljub temu potrebno poznati določene grafične koncepte WebGL. Samo moderni brskalniki imajo podporo za WebGL (Three.js, 2015) WebGL WebGl je kratica za angl. Web Graphics Library, ki predstavlja spletno grafično knjižnico, ki deluje kot JavaScript API za rendiranje interaktivnih 3D in 2D vsebin znotraj kompatibilnih brskalnikov. Na OpenGL ES 2.0 temelječ API je brezplačen, odprtokoden projekt, ki se je v zadnjih letih uveljavil s HTML5 canvas elementom. Prednost uporabe je, da deluje brez raznolikih dodatkov. Njegov pogon omogoča brskalniku, da izrablja grafični procesor za kalkulacijo fizike gibanja, prikazovanja in obdelave raznolikih učinkov ter grafičnih elementov (WebGl, 2015) Metode asinhronega programiranja Porast uporabe tehnik asinhronega programiranja je omogočil številne nove platforme, ki omogočajo razvoj hitrejših in bolj interaktivnih vmesnikov. Pri izvajanju aplikacij se asinhrone operacije izvajajo neodvisno v primerjavi z ostalimi procesi, medtem ko sinhrone operacije tečejo zaporedno kot npr. pri skriptnem jeziku PHP. Tehnika programiranja se uporablja za dvig odzivnosti ter hitrejše interakcije med odjemalci in strežniško aplikacijo (Mardan, 2015). Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 21

28 4.2 STROJNA PLATFORMA V prejšnjem poglavju smo opisali smo opisali logični in aplikacijski del dela. V strojni arhitekturi smo uporabili številne konfiguracije strojne opreme na kateri je tekel node.js. Povezava z Arduino krmilnikom in komunikacija z Node.js je v vseh instancah delovala stabilno Strežnik Razvoj strežniške aplikacije je potekal primarno na glavni napravi HP Compaq 6715s z 32 bitnim operacijskim sistemom Ubuntu LTS in procesorjem Mobile AMD Sepron(tm) Zaradi povečanja mobilnosti robotske platforme, smo v nadaljevanju izgradnje robotske platforme, aplikacijski del prenesli na mini računalnik s procesorjem ARM (MK802IIIS, 2015), ki ga prikazuje Slika 9. Slika 9: Mini PC. Naprava se imenuje Rikomagic MK802IIIS, ki vsebuje Rockchip 3066, dvojedrni 1,6Ghz A9 procesor in 1GB DDR3 delovnega pomnilnika. Naprava ima privzeti operacijski sistem Android, zato smo morali popraviti zagonski sektor, da smo omogočili zagon Linux operacijskega sistema. Na mikro SD kartico velikosti 16GB smo namestili distribucijo Picuntu, ki temelji na Ubutnu z jedrom verzije Po uspešnem zagonu naprave in dostopanju do operacijskega sistema smo za razvojne namene uporabili root uporabnika, ker ima najvišji nivo pravic znotraj Linux okolja. Internega brezžičnega čipa nismo mogli usposobiti, ker ne obstajajo gonilniki za uporabljeno Linux distribucijo, zaradi česar smo morali uporabiti zunanjo USB brezžično napravo, da smo vzpostavili povezavo z internetom in omogočili komunikacijo z drugimi napravami znotraj omrežja. Na strežnik smo namestili razvojno okolje, ki ga sestavlja node.js, modul firmata, socket.io, Johnny-five ter Apache strežnik. Naprave nadziramo preko SSH omrežnega protokola. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 22

29 4.2.2 Razvojna plošča Za realizacijo prototipne robotske platforme smo uporabili razvojno ploščo Arduino Uno. Mikrokrmilnik temelji na ATmega328 čipu. Različica Uno R3 vsebuje 14 digitalnih vhodno-izhodnih pinov, med katerimi jih lahko 6 uporabimo kot PWM izhode. PWM predstavlja način pridobivanja analognih rezultatov z digitalnim načinom (Arduino, 2015). V prototipu smo omenjene izhode uporabili za krmiljenje DC motorjev. Verzija R3 prav tako vsebuje 16MHz keramični resonator, konektor za 12V napajanje ter USB konektor, preko katerega bo naprava lahko komunicirala z strežniškim računalnikom. Slika 10 prikazuje elemente razvojne plošče, ki so uporabljeni pri izgradnji platforme ter predstavljajo ključ za logiko delovanja sistema. Reset USB ATmega3 28 Zunanje napajanje Slika 10: Arduino Uno. Obstajajo omejitve, ki jih moramo upoštevati, da ne poškodujemo strojne opreme. Delovna napetost krmilnika je lahko 5V, priporočljiva vhodna napetost pa od 7V do 12V DC. Za varno upravljanje, DC tok na I/O pinu naj ne bi presegel 40mA, medtem ko za DC tok za 3.3V pin naj ne bi presegel 50mA. Pozornost mora biti prav tako na tem, da skupni izhodni tok ni večji od 500 ma. Na spomin mikrokrmilnika lahko naložimo strojno programsko opremo, kar je v našem primeru Firmata, do maksimalne velikosti 32KB, od katerih se 0,5 KB uporablja za zagonski nalagalnik. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 23

30 4.2.3 Plošča krmilnika motorjev Za povezovanje in krmiljenje preko Arduina moramo vzpostaviti povezavo z Arduinom in računalnikom. Pri testiranju smo uporabili dve različni Arduino razvojni ploščici. Arduino Uno in Arduino Duemilanove, ki vsebuje enak ATmega čip. V prvi fazi je najprej potrebno namestiti razvojno delovno okolje Arduino, ki v primarni stopnji omogoča testiranje delovanja ploščice ter njenih pinov. V razvojnem okolju je kritičnega pomena pravilna izbira razvojne ploščice ter z njo povezane povezave, ki poteka preko COM vrat operacijskega sistema Windows 7. Za normalno prepoznavanje delovanja razvojne plošče znotraj IDE moramo namestiti ustrezne gonilnike, ki omogočajo neprekinjeno in stabilno delovanje ter komunikacijo z gostujočim operacijskim sistemom. Po uspešni namestitvi najprej testiramo delovanje ploščic z različnimi elektronskimi komponentami. Na obeh ploščicah je bil Izveden test vseh digitalnih pinov ter pinov 3, 5, 6, 9, 10 in 11, ki omogočajo 8 bitni PWM izhod. Naslednja stopnja zajema priklop in testiranje glavnih elementov mobilnosti dveh DC motorjev. DC motorja, ki smo ju uporabili delujeta na toku od 3 do 12V, povprečno pa dosegata 120 rotacij na minuto pri toku 3V. Vzpostavitev delovanja ploščic je podlaga za testiranje DC motorjev. Uporabljene komponente prikazuje Slika 11. Za test delovanja motorjev smo uporabili LED diodo, ki je indicirala pošiljanje impulza, 1N4001 diodo, upornik 270 Ohm in PN2222 tranzistor. Potrdili smo delovanje obeh motorjev ter nadzorovanje hitrosti preko PWM. Naknadno smo USB napajanje zamenjali še z adapterjem z izhodnim tokom 12V in močjo 800mA. Višja napetost je dvignila hitrost rotacij in delovanja DC motorjev. Slika 11: Testiranje DC motorjev. Po stabilnem delovanju posamično vezanih DC motorjev je potrebno preko Arduina testirati istočasno delovanje obeh. Na način, ki smo ga uporabili za testiranje ne moremo vzpostaviti obeh, ker se naložena programska koda izvaja zaporedno in s tem onemogoča istočasen nadzor. Za rešitev problema nadzora DC motorjev Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 24

31 moramo vpeljati preklopni register, ki je sposoben podajati ukaze istočasno obema motorjema hkrati. Za test in krmiljenje DC motorjev smo uporabili krmilnik proizvajalca Adafruit (SER1 v1.0), ki omogoča istočasno krmiljenje 4 DC motorjev. Krmilnik omogoča istočasno upravljanje 2 DC motorjev v različnih smereh. Plošča služi kot kompatibilna razširitev Arduino plošči. M1 Povezava DC motorja 74hc595n Shift Register M2 Povezava DC motorja Reset Slika 12: Adafruit krmilnik motorjev. Za izvedbo testa smo uporabili poziciji M1 in M2, ki ju prikazuje Slika 12. Srednji konektor izmed 5 prikazanih bi lahko uporabili kot ozemljitev v primeru večjega dovajanja napetosti. Tipka Reset ponovno ponastavi delovanje Arduina in vzpostavi začetno stanje ob vklopu naprave na vir napajanja, ker predstavlja podaljšek tipke z ukazom na sami Arduino plošči. Slika 12 prikazuje pozicijo povezave DC motorjev, preko katerih dobijo motorji regulirano količino toka, ki omogoča obračanje koles v obe smeri. Čip 74HC595n omogoča paralelno pošiljanje ukazov vsem povezanim izhodom. Za lažje pošiljanje ukazov uporablja logična vrata, kar omogoča upravljanje vhodov in izhodov naenkrat. 8 pinski register pri komunikaciji lahko bere le vrednosti 0V in 5V, isto kot pri digitalnih pinih Arduina. Čip se upravlja s tremi povezavami: ura (clock), serijski podatki (serial data) in Register vhodnih vrednosti (Storage register clock). Krmilna plošča za motorje je kompatibilna z Arduinom in se enostavno združi v celoto kot to prikazuje Slika 13. Povezavo z rdečo in črno žico med krmilnikom in motorji bi lahko obrnili, vendar bi potem morali vnesti ustrezne popravke v kodi na strežniški strani. Prvotno testiranje je bilo izvedeno z Adafruit knjižnico za motorje z nazivom AFMotor.h, ki se jo v skripto prikliče preko ukaza #include <AFMotor.h>. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 25

32 Slika 13: Združeni razvojni plošči za krmiljenje. Tabela 1 prikazuje uporabljeno kodo za testiranje delovanja DC motorjev, ki sta povezana z Adafruit ploščo. Void setup() predstavlja inicializacijo, določanje hitrosti ter smeri pa je izvedeno v funkciji void loop(). Tabela 1: Koda za testiranje hkratnega delovanja DC motorjev 1. Knjižnica in inicializacija 2. Funkcija loop() 3. nadaljevanje funkcije loop() #include <AFMotor.h> AF_DCMotor motor(4); void setup() { Serial.begin(9600); // nastavi serijsko knjižnico na 9600 bps Serial.println("Motor test!"); motor.setspeed(255); // vklopi motor motor.run(release); } void loop() { uint8_t i; Serial.print("Test 2 DC motorjev"); Serial.println(); motor.run(forward); motor.setspeed(255); delay(100); Serial.print("tick - Naprej"); Serial.println(); motor.run(forward); for (i=0; i<255; i++) { motor.setspeed(i); delay(10); } for (i=255; i!=0; i--) { motor.setspeed(i); delay(10); } Serial.print("tock - Nazaj"); Serial.println(); motor.run(backward); for (i=50; i<255; i++) { motor.setspeed(i); delay(10); } for (i=255; i!=0; i--) { motor.setspeed(i); delay(10); } Serial.print("tech"); Serial.println(); motor.run(release); //sprosti PWM delay(1000); } Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 26

33 4.2.4 Ostala oprema Končna oblika robotske platforme ima spodaj naštete elemente med seboj povezane z ustreznimi kabli. Nosilno ogrodje moramo čim manj obremeniti, da ne povzročimo preveč trenja med kolesi in podlago po kateri se pelje platforma. Večja teža elementov povzroča tudi težje obračanje motorjev, ker niso dovolj močni. Priklopljen mini PC napaja prenosna baterija. Za MK802IIS mini PC je priporočljiv vhodni tok 2A, pri napetosti 5V. Mini PC naprej napaja USB razdelilnik in priklopljeno brezžično mrežno kartico. DC motorja delujeta na napetosti od 3 do 12V, povprečno pa dosegata 120 rotacij na minuto pri napetosti 3V. Motorja sta priklopljena na Adafruit krmilnik motorjev. 9V baterija, ki jo uporabljamo za dodatno napajanje DC motorjev je priklopljena na vhod Arduina. Prenosna zunanja baterija Anker 2nd Gen Astro3 s kapaciteto 1200mAh z dvema USB izhodoma. Izhodni polnilni tok na enem USB izhodu znaša 2A, druga dva pa imata 1A izhod. Na baterijo imamo priklopljen mini PC. Mobilna različica je bila testirana tudi z GP PowerBank s kapaciteto 10400mAh. Prenosna baterija ima dva USB izhoda, enega z izhodno napetostjo 2,1A in drugega z 1A. USB brezžična mrežna kartica, ki podpira hitrosti komunikacije preko dostopa b/g/n. Omrežna kartica vsebuje Ralink čipovje. Prvotno uporabljena in merjena kartica je bila AlfaNetwork AWUS036NH, v nadaljnji konfiguraciji strojne platforme pa smo uporabili Kasens N8600 z dodano direkcijsko anteno. Brezžična mrežna kartica je priklopljena na USB razdelilnik, ki omogoča komunikacijo z Arduino mikrokrmilnikom. Za povezovanje USB naprav smo uporabili razdelilnik USB 2.0 s štirimi vhodi. Naprava je direktno priklopljena na mini PC. Ogrodje z izrezanimi luknjami za lažjo montažo elementov, ki drži vse komponente nad površino na kateri se premika platforma. Sestavljeno je iz dveh nadstropij. Stabilizirano je na dveh plastičnih, neprožnih kolesih, za stabilizacijo pa ima v ospredju kolešček, ki omogoča drsenje v vse smeri. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 27

34 5 STREŽNIŠKA APLIKACIJA Programska oprema, (»možgani«) aplikacije se nahajajo na Mini PC ARM strežniku z nameščenim operacijskem sistemom Linux. Na njem teče Node.js preko katerega z vsemi privilegiji gostujočega operacijskega sistema poženemo aplikacijo, ki smo jo poimenovali server.js. Strežniška aplikacija temelji na dveh sklopih med seboj povezanih modulov. V samem začetku imamo definirane spremenljivke, ki jih prikazuje Slika 14. Te služijo za relacijo in komunikacijo na strani odjemalec strežnik. Slika 14: Spremenljivke strežniške aplikacije. Modul http je del node.js sistema, s katerim smo ustvarili strežniško stran aplikacije, ki je sposobna z odjemalci komunicirati preko http protokola. Namen modula je tudi strežba html datotek ter drugih datotek kot npr. js, css, txt, jpeg, png, ipd., z veljavnimi MIME vrstami do samega odjemalca. Uporabniki do aplikacije dostopajo preko ustreznega naslova na vratih 8080, številka je arbitrarna, ker bi lahko bila katerakoli sistemsko dovoljena vrednost. Vsak izveden klic na aplikacijo odgovori z dostavo vseh ustreznih datotek, z modulom path, do odjemalca, v kolikor kakšna datoteka ne obstaja na strežniški strani, s pomočjo metode path.exists(), izpisujejo napake o nezmožnosti dobavljivosti datotek do odjemalca. V nadaljevanju imamo asinhrono tehniko komuniciranja, ki jo izvajamo s pomočjo modula socket.io. Po definiranju modula vklopimo možnost pošiljanja in prejemanja paketov. Paketi se začnejo prenašati po vzpostavljeni povezavi s knjižnicama na obeh straneh, potem se v resničnem času izvaja komunikacija med odjemalcem in strežnikom, ki za vsako instanco komunikacije uporablja ločene pakete. Kot omenjeno smo za izvedbo asinhronega načina smo vključili na strani odjemalca ustrezno socket.io knjižnico. Funkcija socket.on() prejema ukaz za izvedbo obračanja koles ter PWM hitrost, prav tako pa opisno odgovarja odjemalcu, kaj se je zgodilo. Z uporabniške strani po vzpostavljeni povezavi prenašamo vrednosti za nadzor robotske platforme na strežniško stran, ki pošlje PWM hitrost in ukaz zagona motorjev mikrokontrolerju. Po prejemu paketa na strežniku, ta odgovori odjemalcu preko funkcije socket.emit(), kaj je strežnik prejel, kar nam omogoča bolj intuitiven način zaznavanja napak ter pregled zapisnika za diagnostiko pri pojavljenih težavah. V drugem sklopu modula na strežniški strani, ki služi za komunikacijo strežnika s krmilnikom, najprej definiramo knjižnico Johnny-five. Johnny-five temelji na Firmata protokolu, kar omogoča komunikacijo z aplikacijo ter Arduino krmilnikom. V nadaljevanju moramo obvezno definirati razvojno ploščico ter ShiftRegister čip kot to prikazuje Slika 15. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 28

35 Slika 15: Spremenljivke aplikacije krmilnika. V funkciji board.on(), aktiviramo povezavo med Arduinom in strežnikom. Ob uspešni povezavi nam sistem vrne sporočilo o inicializirani povezavi kot to prikazuje Slika 16. Slika 16: Uspešna povezava Arduino - strežnik. V primeru nestabilne oz. prekinjene povezave strežnik odgovori v obliki napake, kar prikazuje Slika 17. Slika 17: Neuspešna povezava Arduino - strežnik. Po uspešni povezavi najprej definiramo 4 spremenljivke, ki nam služijo za upravljanje 74hc595n preklopnega registra. Spremenljivke za nadzor preklopnega registra ter pošiljanja ukazov preko Arduina do DC motorjev so MOTORLATCH, MOTORCLCK, MOTORENABLE in MOTORDATA. Nato so definirani Arduino pini za prejemanje PWM signala in definiranja hitrosti. Te spremenljivke so podlaga za definiranje podatkov v funkcijo shiftregister(), ki jo v nadaljevanju izrabljamo v kombinaciji z metodo shiftregister.send(), ki nam omogoča pošiljanje binarnih vrednosti v krmilnik. V našem primeru so binarne vrednosti pretvorjene v decimalne. V nadaljevanju definiramo kot ločeni instanci dva objekta za vsak motor posebej. Motorjem preko aplikacije sporočamo stanje in hitrost delovanja, tako lahko z različnimi kombinacijami ustvarimo različna gibanja motorjev, naprej in nazaj za vsako kolo posebej, istočasni premik obeh koles naprej in nazaj, rotacije v obe smeri ter stanje mirovanja, ki ga bomo imenovali stop. Ob zagonu vsakega motorja sprožimo povratno funkcijo, ki nam v strežniški terminal izpiše s časovnim žigom kateri motor se je zagnal. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 29

36 5.1 LATENCA Za preverjanje dostopnosti strežnika znotraj omrežja smo uporabili ping ukaz. Z ukazom ping smo preverili IP naslov obeh naprav, ki smo jih želeli doseči. Ukaz nam prikaže, če se želena naprava odziva in koliko časa je trajalo, da smo prejeli nazaj odgovor. Prejeti odgovor v rezultatih predstavljamo kot P. V testu se mnogokrat pojavi odgovor, da gostitelj ni dosegljiv, kar predstavlja izgubo paketa, ki jo v tabeli označujemo z I. Odgovor o nedosegljivosti gostitelja predpostavlja, da se pojavljajo motnje v poti do gostitelja in zato nismo prejeli odgovora v privzeti časovni enoti 1 sekunde. Lahko pa tudi pomeni, da je latenca povezave višja od 1 sekunde. Rezultate prikazuje Tabela 2. Znotraj rezultatov je delež izgube predstavljen z oznako % IZG. MIN predstavlja oznako za minimalen čas prejetega odgovora, MAX pa maksimalen čas prejetega odgovora. V izpisih testa se pojavi oznaka RTT (Round trip time), ki predstavlja potreben čas za potovanje paketa od odjemalca do gostitelja in nazaj, ki ga merimo v milisekundah. AVG predstavlja povprečen čas potovanja paketov v milisekundah. Obremenitev omrežja je pri testiranju naprav za vse odjemalce enaka. V centralnem delu se nahaja usmerjevalnik na katerega so istočasno priklopljene vse testirane naprave. Posamezna naprava je izpisovala čas prejemanja paketov le za enega gostitelja naenkrat. En gostitelj je pošiljal odgovore le eni napravi naenkrat. Zaželjena je povprečna hitrost prenosa 5ms. Omejitev (timeout) izvedbe je nastavljen na 1 sekundo. TTL (time to live) znaša 64ms. Velikost ping paketa znaša 32 byte-ov. Število poslanih paketov n= Tabela 2: Rezultat ping testa. Strežnik Stacionarni Tablica Prenosni Mobitel HP Compaq P I P I P I P I AVG % IZG AVG % IZG AVG % IZG AVG % IZG 2 ms 0,8% 22ms 4% 4ms 3,6% 13ms 7,2% MAX MIN MAX MIN MAX MIN MAX MIN 231ms 1ms 636ms 2ms 238ms 1ms 322ms 2ms MK802IIIS P I P I P I P I AVG % IZG AVG % IZG AVG % IZG AVG % IZG 47ms 5,4% 99ms 36,2% 91ms 13,8 95ms 45,6% MAX MIN MAX MIN MAX MIN MAX MIN 3167ms 1ms 1038ms 4ms 4573ms 3ms 1112ms 8ms Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 30

37 Tabela 2 prikazuje rezultate različnih naprav s katerimi smo merili odzivnost dveh različnih strežnikov, Stacionarni in Mobilni, v omrežju, ki ga prikazuje Slika Stacionarni preko brezžične povezave Mobilni preko brezžične povezave Slika 18: Omrežna topologija. Oba strežnika sta bila v omrežje povezana brezžično. V primerjavi odzivanja na poslane pakete ugotavljamo, da je stacionarni strežnik bolj odziven ter ima manjšo latenco v poizkusu z vsemi napravami. Slika 18 prikazuje, da je stacionarni računalnik z naslovom prejemal odgovore v najhitrejšem času. Žična povezava je hitrejša in ima najboljšo odzivnost. Vse naprave so imele boljšo odzivnost ter manjšo latenco s stacionarnim strežnikom, povezanim preko brezžične povezave. Največjo izgubo paketov je imela mobilna naprava z obema testiranima strežnikoma. Strežnik HP Compaq uporablja brezžični Broadcom 4311AG adapter. Na strežniku MK802IIIS je v testiranju uporabljen Alfa Network AWUS036NH brezžični adapter z Ralink RT3070 čipovjem. Na podlagi pridobljenih meritev ugotavljamo, da ima zunanji brezžični adapter na MK802IIS visoke povprečne vrednosti oddajanja in sprejemanja paketov, kar ne predstavlja stabilnega okolja za izvajanje velikih skript ter istočasnega povezovanja številnih odjemalcev na napravo. Naprava velikokrat izgubi povezavo z centralnim usmerjevalnikom. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 31

38 6 UPORABNIŠKI VMESNIK Izdelava grafičnega uporabniškega vmesnika (GUI graphical user interface) omogoča interakcijo uporabnikov in strežniške aplikacije, ki se izvaja na Node.js-u. Uporabniki lahko z direktno manipulacijo grafičnih elementov izvajajo akcije, ki se odzivajo na elemente za simuliranje gibanja robotske platforme ter gibanja v fizičnem svetu. Oblikovanje ter vizualna kompozicija je bila v prvi fazi izvedena z grafičnim programom za oblikovanje. Cilj GUI vmesnika je dvigniti odzivnost ter vzpostaviti strukturo, ki je z vidika uporabnika intuitivna za uporabo. Komponenta za prikaz vmesnika je modern brskalnik, ki omogoča prikazovanje tehnologij HTML5 in CSS3. V glavnem je razvoj potekal v Chrome in Mozilla spletnem brskalniku. V obzir in delna testiranja so bili zajeti tudi Opera, Internet Explorer11 ter drugi, ki temeljijo na Chromium projektu. Doba, kjer na strani odjemalca spletnih vsebin uporaba mobilnih naprav in tabličnih računalnikov postopoma presega uporabo namiznih zaslonov, predstavlja razlog za t.i. fluid design, ki predstavlja oblikovanje in načrt spletne strani, ki je odziven glede na dimenzije in pozicijo naprave, ki jo uporabnik uporablja. Strukturirali smo načrt, ki je odziven glede na napravo, ki jo uporabnik uporablja, ker želimo vzpostaviti grafični vmesnik, ki se samodejno prilagaja s pomočjo vnaprej definiranih pravil. Tehnika odzivanja nam bo v vmesniku omogočila manj kodiranja na dolgi rok, ker bomo previdno izbrali dimenzije, ki v teoriji podpirajo različne ločljivosti. Načrt smo izvedli znotraj programa za grafično oblikovanje Gimp, implementacija pa je potekala s pomočjo programa Notepad++ in njegovih vtičnikov, ki predstavljajo enostavno, lahko razvojno okolje. Razlog za izbiro okolja je enostavna uporaba ter povezava, ki omogoča direktno spreminjanje kode na strežniku preko SFTP protokola. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 32

39 6.1 NAČRT Za izdelavo načrta uporabniškega vmesnika smo uporabili orodje za grafično oblikovanje. Faza oblikovanja načrta služi kor podlaga za ugotavljanje uresničene prvotne vizije. Na podlagi aktivnosti v načrtovanju vizualno opredelimo funkcionalnosti, ki jih zahtevamo od končnega uporabniškega vmesnika. Načrt nam prav tako služi za lažje in bolj natančno oblikovanje programskih potreb pred začetkom implementiranja. Postopek načrtovanja je odkril številne potrebe po dodatnih funkcionalnostih, ki jih bodo končni uporabniki lahko uporabljali. Namen je izdelati vmesnik, ki je znotraj brskalnikov različnih naprav odziven in intuitiven za uporabo. Pred začetkom oblikovanja smo definirali ločljivosti zaslonov za katere smo uporabniški vmesnik zgradili ter izvedli 3D simulacijo odzivnosti in zmožnosti poganjanja rendiranega okolja znotraj najbolj uporabljanih brskalnikov. Začetni temelj za oblikovanje je bila ločljivost 1024x600. S tem smo želeli zajeti večino naprav. Kontrolni gumbi za nadziranje smeri robotske platforme so prikazani v skupnem bloku, sestavljenem iz 9 kvadratov s črno podlago. Pod gumbi se nahaja drsnik za določanje hitrosti gibanja robota, pod njim pa imamo konzolo, ki uporabniku izpisuje prejete komande ter odgovore strežnika. Osnovno postavitev prikazuje Slika 19. Slika 19: Osnutek načrta uporabniškega vmesnika. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 33

40 Slika 20: Osnutek načrta vertikalne postavitve za mobilne naprave. Pri izdelavi načrta za mobilne naprave smo izdelali načrt za vertikalno in horizontalno pozicijo. Pri vertikalni poziciji, kot to prikazuje Slika 20, smo se sklicevali na širino 320px, pri horizontalni pa na 530px. Pri vertikalni poziciji je načrtovan podoben sklop kot pri drugih večjih ločljivostih, medtem ko je drsnik za nadziranje hitrosti ter ostali elementi pri horizontalnem na levi strani zaslona, kot to prikazuje Slika 21. Slika 21: Osnutek načrta horizontalne postavitve za mobilne naprave. V nadaljevanju smo pri implementaciji načrt deloma popravili, nadaljnja izvedba pa je temeljila na podlagi vmesnih deskriptivno pogojenih sprememb s pomočjo metode razvojnega prototipiranja. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 34

41 6.2 KOMPATIBILNOST BRSKALNIKOV Uporabniški vmesnik vsebuje 3D simulacijo gibanja robotske platforme, kar je predstavljalo dejavnik pri izbiri brskalnikov za testiranje kodnih implementacij. Brskalniki, ki privzeto podirajo tehnologije WebGl ter knjižnico Three.js so imeli absolutno prednost v primerjavi z drugimi, ki tega v osnovi ne podpirajo oz. imajo kompleksen proces vklopa grafičnega pospeševanja znotraj svojega pogona Razvoj in testiranje vmesnika se je v večjem delu izvajal znotraj brskalnika Google Chrome. Razlog za izvedbo in testiranje znotraj omenjenega brskalnika je njegova popularnost in doslednost modernih tehnologij ter kompatibilno izvajanje JavaScript knjižnic. Brskalnik je v letu 2014 na globalni ravni uporabljalo več kot 50% uporabnikov, v mesecu avgustu 2014 pa se je njegova uporaba prvič dvignila nad 60% kot to prikazuje Tabela 3. Tabela 3: Uporaba spletnih brskalnikov 2014 (W3Schools, 2015). Drugi razvojni brskalnik je bil Mozilla Firefox, ki je po svetovni uporabi na drugem mestu kot to prikazuje Tabela 3. Firefox ima prav tako kot Chrome vključeno in stabilno WebGl podporo. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 35

42 IE11 privzeto ne podpira izvajanje WebGL tehnologije. Znotraj njegovega pogona se komponento da vklopiti, vendar postopek izvedbe ni uporabniku prijazen, kar predstavlja veliko oviro pri številnih uporabnikih, ki imajo omejeno tehnično znanje. Podjetje Microsoft je zelo pozno, šele v letu 2014, začelo integrirati delovanje tehnologije znotraj svojega brskalnika IE11 (IEBlog, 2014). Opera ne povzroča večjih težav pri izvajanju 3D modela. Njeno delovanje ter izvajanje skript uporabniškega vmesnika je stabilno in poteka brez težav. Kljub dobri odzivnosti ter delovanju, znotraj brskalnika nismo izvedli veliko testov, zaradi nepriljubljenosti uporabe. Drugi brskalniki imajo v večini težave pri izvajanju 3D modela, zato smo implementirali Three.js knjižnico Detector.js, katere namen je zaznava WebGl podpore znotraj brskalnika ter ustrezne strojne opreme, ki je sposobna 3D pospeševanja. Opozorilo napak, ki so se pojavile prikazuje Slika 22. Slika 22: WebGL opozorilo brskalniku. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 36

43 6.3 ODZIVNOST UPORABNIŠKEGA VMESNIKA Izvedba vmesnika je potekala v HTML in CSS jeziku. Odzivnost uporabniškega vmesnika za dvig uporabniške izkušnje je bil v fazi načrtovanja postavljen na podlagi standardnih dimenzij različnih aparatov. Posodobljeno bazo naprav, ki jih uporabniki v večini uporabljajo smo si ogledali na tej spletni strani: Pri načrtovanju izgleda za večje zaslone smo vzeli mejo, da se za vse zaslone, ki so višji ali enaki resolucije 1280x800 oblikuje dinamičen prikaz animiranega predela znotraj brskalnika. Ti aparati predstavljajo klasične namizne zaslone. Tabela 4 prikazuje, da ima 99% obiskovalcev spletnih strani z omenjenimi napravami ločljivost višjo od 1024x768 točk. Tabela 4: Ločljivost zaslonov obiskovalcev po letih (W3Schools, 2015). Na podlagi definiranih dimenzij smo določili tri stopnje oblikovanja. Za mobilne naprave, naprave s srednjim velikim zaslonom ter naprave z visoko resolucijo. Pri implementaciji pravil oblikovanja v CSS jeziku smo za kode najprej definirali meta značko, ki jo prikazuje Slika 23. Slika 23: Meta značka - viewport. poizv. Pred kodiranjem za posamezne naprave smo preverili kompatibilnost značke za zaznavanje vizualnega oz. predstavitvenega polja (angl. Viewport) s posameznimi brskalniki. Zanimala nas je stabilnost prilagajanja glede na velikost zaslonov za posamezne brskalnike znotraj različnih operacijskih sistemov. Glavna brskalnika Chrome in Firefox, ki smo ju uporabili, kot ju prikazuje Tabela 5, podpirata prilagajanje glede dimenzije pogleda za uporabniški vmesnik. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 37

44 Tabela 5: Podpora idealnega viewport-a (Quirksmode, 2015). Naprave, ki jih držimo v roki imajo dve poziciji, pokončno (angl. portrait) in ležečo (angl. landscape). Na podlagi pozicije ter vrnjenih vrednosti, Tabela 5 prikazuje rezultate glede operacijskih sistemov, različic ter podpore. Pri testu se uporablja selektor screen.width in screen.height. Vrednost yes predstavlja, da se idealno razmerje dimenzij predstavitvenega polja odziva v pričakovanju s predvidenimi dimenzijami. Vrednost portrait pomeni, da naprava vedno vrne vrednosti v pokončni poziciji. Vrednost physical vrne dimenzije fizičnega zaslona. Vrednost layput vrne dimenzije vidnega polja. Vrednost both pomeni, da je točkovno razmerje vedno 1, zato ima idealno vidno polje vedno iste dimenzije kot zaslon. Vrednost p+p predstavlja vračanje vrednosti physical in portrait (Quirksmode, 2015). Pri implementaciji za različne dimenzije je bila znotraj CSS uporabljena Sama struktura poizvedbe definira tip naprave (mediatype) ter njene lastnosti kot npr. velikost (media feature). Poizvedba pa prav tako omogoča nastavljanje logičnih pravil z and, not in only. podirajo vsi glavni brskalniki od danih verzij naprej, ki jih prikazuje Tabela 6. Tabela 6: Podpora (W3Schools, 2015). Na podlagi načrta smo implementirali različne scenarije za prilagoditev na različnih zaslonih. Za mobilne različice imamo dva načina prikazovanja, vertikalno in horizontalno. Ukaze za najmanjše možne zaslone, ki imajo maksimalno resolucijsko širino 320px v vertikalnem položaju smo zabeležili znotraj poizvedbe, ki jo prikazuje Slika 24. Slika 24: Ukazi vertikalnega načina najmanjših zaslonov. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 38

45 Za mobilne zaslone v ležečem položaju smo nastavili pravilo, ki velja za vse naprave do širine 600px kot to prikazuje Slika 25. Slika 25: Ukazi ležečega načina najmanjših zaslonov. V nadaljevanju smo zaradi enostavnosti izvedbe implementirali pravilo, ki velja za dimenzije srednje velikih zaslonov. Implementirano pravilo velja za številne manjše zaslone ter starejše tablične računalnike z nizko resolucijo, ki ima minimalno dimenzijo širine vsaj 601px. Ustvarjeno pravilo prikazuje Slika 26. Slika 26: Ukazi za zaslone srednjih dimenzij. Krepka večina tabličnih, namiznih in prenosnih računalnikov ima širino zaslona vsaj 1024px. Za visoko resolucijske zaslone, katerih dimenzije so višje od 1024px širine naprej smo implementirali pravila, ki jih prikazuje Slika 27. Slika 27: Ukazi za zaslone visokih dimenzij. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 39

46 6.4 MODEL IN SIMULACIJA Oblikovan model lahko upravljajo le uporabniki, ki imajo brskalnike z WebGL podporo. V uporabniškem vmesniku se prikaže opozorilo v primeru, da naprava ni sposobna prikazati 3D okolja. V takšnem primeru smo z vidika optimizacije onemogočili ustvarjanje canvas elementa z namenom hitrejše izvedbe ostale kode. V primeru, da brskalnik ne podpira kreacije 3D okolja, ima uporabnik še vedno možnost upravljati z robotsko platformo. Okolje, ki simulira gibanje objekta je v celoti obdelano in ustvarjeno na strani odjemalca. Hitrost izvedbe je sorazmerna z močjo grafične procesorske enote naprave, ki jo uporabnik upravlja. Ko uporabnik prikliče skripto se najprej izvede funkcija zaznavanja sposobnosti izvajanja WebGL okolja naprave. V kolikor ima naprava ustrezne tehnične lastnosti se prične generiranje okolja. Slika 28 prikazuje strnjeno obliko funkcij, ki nam omogočajo generiranje okolja, izvajanje animacij ter uporabniško kontrolo okolja. Za uporabo Three.js API-ja moramo vključiti knjižnico three.min.js. Slika 28: Temeljne funkcije okolja. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 40

47 Prva, začetna funkcija je init() v kateri inicializiramo objekte ter ostale potrebne elemente za kreacijo okolja, ki ga vidimo v vmesniku. Je prva funkcija, ki jo moramo izvesti. Druga temeljna funkcija, ki omogoča izvajanje primerov premika ter odzivanje 3D okolja je animate(). Funkcija za animiranje vsebuje metodo.requestanimationframe(), ki sporoča brskalniku, da želimo izvesti animacijo s tem, da zahtevamo od brskalnika izvedbo iste funkcije. Rutina nam omogoča posodobitev animacije na zaslonu. Posodobitev zgrajenega vizualnega okolja vsakega klica animacije omogoča render(). Funkcija render() generira grafično okolje za posamezno časovno instanco. Znotraj funkcije za animiranje imamo metodo, ki omogoča posodabljanje uporabniškega spreminjanja okolja v časovni enoti za vsako sliko. Funkcija onwindowsresize() omogoča izvedbo oz. popravek dimenzij okna canvasa za vsako spremenjeno dimenzijo okna brskalnika. Funkcija se sproži s pomočjo metode addeventlistener(), ob vsaki definirani spremembi, ki jo imenujemo dogodek. V našem primeru smo nastavili argument, da se funkcija sproži ob dogodku spremembe okna brskalnika. Okolje je sestavljeno iz scene, svetlobe, kamere, objekta, mreže, števcev, kontrole z miško, kartezijskih koordinatnih smernic. Za hitrejše izvajanje animacij na napravah s slabšo grafično strojno opremo smo prvotno načrtovane določene efekte odstranili. Scena nam omogoča vzpostaviti vse elemente za rendiranje. V funkcijo vzpostavitve scene smo ustvarili mrežo, objekt robota, svetlobo, koordinatne smeri. To lahko za objekte naredimo preko scene.add(imeobjekta). Mreža je definirana znotraj funkcije makegrid(). Služi uporabniku za boljšo orientacijo. Definirana je s kodo, ki jo prikazuje Slika 29. Slika 29: Funkcija za ustvarjanje mreže Objekt, ki predstavlja robotsko platformo je oblikovan z odprtokodnim programom za 3D modeliranje. V istem orodju je ustvarjena animacija modela, ki se izvaja ko je sprožena akcija s strani uporabnika. Skupni predmet je izvožen s three.js izvoznim modulom v obliko JSON (angl. Javascirpt object notation) z imenom Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 41

48 Avtomobil_Animacija_Naprej.js. Model s pravili animacije prikličemo v naši inicializacijski funkciji z loadobject(). Slika 30 prikazuje kodo funkcije za ustvarjanje objekta. Slika 30: Funkcija za ustvarjanje objekta. Model vsebuje veliko točk za izris, zato je v vmesniku prostorsko (kb) največji element, zato se tu najdlje nalaga na strani odjemalca. Končni izgled rendiranega okolja prikazuje Slika 31. V desnem zgornjem kotu, Slika 31 vsebuje prikaz realne robotske platforme. Števca hitrosti delovanja preklop s klikom. 3D model z animacijo Realni model Koordinatni sistem Mreža Slika 31: 3D model in okolje. Slika 30 prikazuje dva števca, med katerimi preklapljamo s klikom. Prvi prikazuje enote števila slik na sekundo s kratico FPS. Optimalna hitrost je 60 FPS ali več, vendar je v napravah s slabšim grafičnim pospeševanjem število FPS bistveno nižje, kar bomo videli v nadaljevanju. Enota MS predstavlja število potrebnih milisekund za rendiranje posamezne slike. Zaželeno je, da je številka čim nižja. Števec za FPS in MS pa sta definirana znotraj funkcije loadmeter(). Slika 32 prikazuje funkcijo loadmeter(), ki nam omogoča priklic statistike in lepljenje števcev v okvir znotraj izbranega canvas elementa. Za delovanje smo uporabili knjižnico stats.min.js. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 42

49 V nadaljevanju bomo prikazali testiranje stanja FPS in MS za izbrane naprave. Slika 32: Funkcija za statistiko FPS in MS. Koordinatni sistem je definiran znotraj funkcije makecoordinatearrows(), kjer smo barvno označili koordinate x,y,z z barvami rdeča, zelena in modra. Kodo za izdelavo prikazuje Slika 33. Slika 33: Funkcija ustvarjanja vidnih koordinat. Uporabili smo kamero perspektive, ki smo jo definirali in priklicali v funkciji loadcamera(). Pri vzpostavitvi okolja je kamera pomemben dejavnik, ki omogoča uporabniku dober pregled nad simulacijo, ki se izvaja. Za vzpostavitev ter spreminjanje vrednosti mora upoštevati spremenljivke, ki jih prikazuje Slika 34. near Camera frustum near plane. Pozicija kamere View frustum fov Camera frustum vertical field of view. aspect Camera frustum aspect ratio aspect = x y Črta pogleda uporabnika far Camera frustum far plane. Slika 34: Spremenljivke kamere. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 43

50 Funkcija za nalaganje kamere je zgrajena iz kode, ki jo prikazuje Slika 35. Slika 35: Funkcija za vzpostavitev kamere. Pogled lahko uporabnik znotraj simuliranega okolja spreminja s pomočjo miške oz. prstov na prenosnih napravah. Spremenljivke nadziranja pogleda smo definirali v funkciji loadcontrols() kot to prikazuje Slika 36. Slika 36: Funkcija spreminjanja pogleda okolja. Uporabnikom je omogočena rotacija glede na točko, ki jo aktivira, približevanje in oddaljevanje, premik v levo ali desno z uporabniškega pogleda kot to prikazuje Slika 37. Uporaba funkcionalnosti je omogočena s knjižnico TrackballControls.js. Slika 37: Spreminjanje pozicije pogleda okolja. Po prvih uporabniških testih ugotavljamo, da premikanje pogleda okolja ni najbolj intuitivno za uporabnike, ki veliko igrajo 3D igre. Namen implementacije metode TrackballControls je prikazovanje odzivnosti ter zmožnosti svobodnega manipuliranja okolja glede na kliknjeno točko znotraj koordinatnega sistema. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 44

51 Vizualiziran objekt smo v naslednjem koraku povezali z upravljanjem robotske platforme v fizičnem svetu. Pred integracijo uporabniškega vmesnika smo priklicali animacije objekta ter vzpostavili povezavo z smernimi tipkami, da smo potrdili normalno delovanje. V nadaljevanju smo isto funkcionalnost integrirali z gumbi, ki jih prikazuje Slika 38. Uporabnik s klikom na gumb izvede smer gibanja. Koda za izvedbo zajema 9 scenarijev različnega gibanja. Slika 38: Gumbi za nadzor modeliranega objekta. Animacija za hitrost premikanja uporablja tri glavne spremenljivke kot to prikazuje Slika 39. Spremenljivka delta dobi svojo vrednost preko globalno nastavljene spremenljivke»var clock = new THREE.Clock();«, ki omogoča gibanje objekta na časovno enoto. movedistance za služi za premik razdalje v pikslih po osi Z absolutno glede na objekt. Spremenljivka rotateangle služi za 360 obračanje objekta. Slika 39: Spremenljivke hitrosti premikanja. Po nastavljenih osnovnih parametrih za zagon animacije imamo serijo pogojnih stavkov, ki za posamezno smer definirajo premik smeri objekta po Z osi in sprožijo animacijo. Zaradi prototipne narave uporabniškega vmesnika ter tehnologij imamo omogočeno kontrolo objekta s smernimi tipkami oz. q, w, e, a, s, d. Služi nam za testiranje odzivnosti v primeru diagnostike odpovedi strojne opreme ali zamrzovanja aplikacije na strani uporabnika. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 45

52 6.5 KODNA POVEZAVA VMESNIKA IN STROJNE OPREMA V prejšnjem poglavju smo omenili vzpostavljeno povezavo med gumbi ter premikanjem animiranega modela. V tem poglavju bomo predstavili rešitev povezovanja animacije ter pošiljanja ukaza strežniški aplikaciji z uporabniške strani. Vseh 9 prikazanih gumbov za upravljanje, ki jih prikazuje Slika 37 ima nastavljeno metodo, ki čaka na uporabnikovo akcijo, da se sproži. Akcije gumbov so oblikovane na način kot prikazuje Slika 40. Slika 40: Primer izvedbe ukaza premika. Rešitev ob kliku na gumb definira spremenljivko stevilkaukaza, ki jo vmesnik s pomočjo metode emit() posreduje preko paketa do strežnika. V istem koraku se torej izvede dogodek»ukazarduinu«ob katerem se posreduje podatke s številko ukaza ter nastavljeno PWM hitrost, ki jo uporabniki nastavijo preko html drsnika, ki ga prikazuje Slika 41. Slika 41: Drsnik za nastavljanje hitrosti. Ko uporabnik sproži dogodek in s tem pošlje paket strežniku, ta preveri, da je pravilno vzpostavljena komunikacija med odjemalcem in strežniško aplikacijo, nato aktivira metodo on() kot je prikazuje Slika 42. Slika 42: Metoda socket.on(). Paketni prenos se izvede po vzpostavljeni povezavi in prenese vrednosti stevilkaukaza in pwmprejet do aplikacije na strežniku. Omenjeni vrednosti uporabimo glede na uporabniški sprožen dogodek v seriji pogojnih stavkov, ki posredujejo ukaz krmilniku ter izpišejo izvedeno akcijo v konzoli na strežniški strani. Z asinhrono tehniko se v opisani funkcionalnosti izmenjujejo paketi med strežnikom in odjemalcem. Za prenos informacij uporabljamo websocket, ki predstavlja protokol, ki podpira hkratne komunikacijske kanale, ki tečejo preko TCP povezave. Tehnologijo uporabimo, ker omogoča hiter prenos informacij in sočasno oddajanje in prejemanje le-teh. Protokol omogoča izgradnjo simulacijskega okolja Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 46

53 in uporabniškega vmesnika z visokim nivojem interaktivnosti. Podane informacije z enega odjemalca interpretira strežnik, nato vrne rezultate vsem priklopljenim. Znotraj simulacijskega okolja se gibanje robotske platforme vidi v brskalnikih vseh povezanih odjemalcev. Omenjena serija pogojnih stavkov se izvaja po prejemu povratne informacije s strani odjemalca v omenjeni metodi, ki jo kaže Slika 41. Vzorec pogojnih stavkov prikazuje Slika 43. Slika 43: Vzorec pogojnega stavka na strani strežnika. Znotraj pogojnega stavka prejmemo ukaz, ki ga je določil uporabnik in sprožimo funkcijo gibanja robotske platforme, v fizičnem in simulacijskem okolju, v poljubno smer. Znotraj interpretacije ukaza se izvede metoda emit(), ki istočasno vsem povezanim odjemalcem prikaže zadnjo sproženo akcijo v obliki sporočila. Prav tako jim posreduje številko ukaza za gibanje ter podano uporabniško hitrost, ki se uporablja v simulaciji. Slika 45 prikazuje pogoje za zagon animacije v simulacijskem okolju. V primeru, da uporabnik pošlje katerikoli ukaz za gibanje robotske platforme s PWM hitrostjo 0, bo model miroval. V nasprotnem primeru, kjer je PWM hitrost definirana s številko, imamo nastavljane številne možne alternative gibanja v simulacijskem okolju. Funkcija log(), kot jo prikazuje Slika 44, omogoča vsem odjemalcem izpis informacij sproženega gumba gibanja, ki jih je strežnik prejel. Kot argumenta sprejme sporočilo, ki ga izpiše in številko prejetega ukaza. Pri izpisovanju zadnjih prejetih ukazov je nastavljena omejitev, da je v uporabniškem vmesniku izpis strukturno nemoteč ter praktično umeščen v vizualno podobo vmesnika. Slika 44: Funkcija izpisovanja ukazov na strani odjemalca. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 47

54 Slika 45: Pogoji za zagon animacije. Funkcija animwheell() izvaja klice animacij za določene akcije glede na sprožen gumb. Funkcija se izvaja na uporabniški strani. Znotraj nje beležimo logični vrednosti true in false, ki se v seriji pogojev uporabljata za zagon robotske platforme v simuliranem okolju. V tem predelu se definira hitrost in vektor gibanja, rotacijo in zagon funkcije za predvajanje animiranih koles. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 48

55 6.6 REZULTATI TESTIRANJA VMESNIKA Testiranje je znotraj razvojnega cikla potekalo s številnimi iteracijami, kjer smo merili odzivnost navedenih ukazov ter popravkov v kodi. Pri izvajanju popravkov smo izvajanje testirali na različnih napravah, različnih resolucij. Tehnično in ekonomsko nismo v testiranje mogli zajeti vseh dostopnih naprav na trgu, zato smo v testiranje poskusili zajeti čim več naprav iz različnih časovnih obdobij. Pri mobilnih napravah je izvajanje simulacije in okolja odvisno od strojne opreme naprave, glavna komponenta za gladko izvajanje je procesor, ki v večini primerov pri napravah, ki služijo kot telefoni ima grafično procesno enoto vgrajeno. Starejše naprave kot testirani Google Nexus S z Android sistemom, nima dovolj močnega grafičnega procesorja za prikaz rendiranega okolja. Ker smo v takšnih primerih onemogočili izvajanje simulacije, se kljub temu prikažejo možnosti nadziranja robotske platforme v vertikalni (levi predel) in horizontalni legi (desni predel) naprave kot to prikazuje Slika 46. Slika 46: Rezultat naprave Nexus S. Mlajša naprava v primerjavi z Google Nexus S, ki smo jo testirali je Samsung Galaxy Trend S7680 z Android sistemom in Chrome brskalnikom, ki ima grafični procesor, ki zadostuje minimalnim potrebam za prikaz mreže okolja ter gibanja s pomočjo načina sledilne kroglice, vendar brez animiranega objekta. Ne zmore rendirati animiranega objekta, občasno pa algoritem zaznavanja ustreznosti tehničnih pogojev izpiše, da grafični procesor ni dovolj močan. Rezultat oblikovanega vmesnika je enak kot v prej prikazanem primeru. V manjših resolucijskih napravah smo dodali funkcionalnost premikanja na gumbe z ukazi gibanja. Ikona se nahaja v zgornjem desnem predelu simuliranega okolja. Razlog za uvedbo je onemogočeno premikanje navzdol, ker uporabnik ob pritisku na zaslon nadzoruje simulirano okolje. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 49

56 Testirana naprava: SAMSUNG GT-I8580 Galaxy Core. OS: Android s Chrome brskalnikom , ki ima WebGL podporo. Test je pokazal, da je naprava ustrezna za izvajanje našega simulacijskega okolja. Rezultat vertikalne pozicije naprave prikazuje Slika 47. V levem predelu se nahaja simulacijsko okolje, v desnem predelu slike pa ukazi. Slika 47: Rezultat naprave Galaxy Core - vertikalne pozicije. Naprava se je v testiranju izkazala za stabilno. Ob določenih pogojih je sposobna izvajati simulirano okolje s 60FPS. Povprečni čas izvedbe rendirane slike je 17ms. Slika 48 prikazuje prikaz horizontalne pozicije simuliranega okolja (Levi predel) in ukazov za premikanje (desni predel). Slika 48: Rezultat naprave Galaxy Core - horizontalna pozicija. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 50

57 Naprava SAMSUNG Galaxy tab 3 GT-P5210. OS: Android s Firefox v.34.0 brskalnikom, ki ima WebGL podporo. Naprava omogoča stabilno delovanje simuliranega okolja. Grafični procesor je sposoben prikazovanja maksimalno 35FPS, povprečni čas izvedbe rendirane slike je 56ms. Slika 49 prikazuje rezultat naprave. Slika 49: Rezultat naprave Galaxy Tab. Prenosnik HPCompaq 6715s. Resolucija zaslona 1280x800 (16:10). Ubuntu Linux LTS. Firefox v ter ostale naprave, ki imajo najmanjšo ločljivost 1280x800 izrišejo simulirano grafično okolje in rezultate kot jih prikazuje Slika 50. Slika 50: Rezultat naprav z resolucijo 1280x600 ali več. Znotraj JavaScript kode smo za boljšo odzivnost implementirali, na strani odjemalca, serijo pogojnih stavkov, ki znotraj funkcije onwindowresize() popravlja dimenzije prikazanega html canvas elementa, ki služi za prikazovanje rendiranega okolja. Obnašanje primarno ni bilo predvideno, zato je rešitev začasna in zahteva nadaljnji razvoj. Razlog neidealnega razmerja v prikazovanju se nahaja v argumentu funkcije rendiranja, ki za prikazovanje okolja jemlje argument kot razmerje in ne kot absolutno vrednost. Za nadaljnji razvoj predlagamo drugačno oblikovno strukturo, ki bi za prikazovanje rendiranega okolja jemala idealne vrednosti višine in širine. Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 51

58 7 MOBILNA ROBOTSKA PLATFORMA Na podlagi pridobljenih meritev latence in časa prihoda paketov, ki jih prikazuje Tabela 2 in prvotno načrtovanega sistema ugotavljamo, da je povprečna vrednost odzivnosti ping ukaza krepko nad 5ms optimalno mejo. Izguba paketov zaradi predolgega časa prejemanja povratne informacije s strani strežnika ali napake, pri brezžično povezani tablici znašala 36,2%, pri mobilni napravi pa 45,6%. Visoka izguba onemogoča kvalitetno uporabniško izkušnjo. Številni ukazi, sproženi na strani uporabnika ne dosežejo strežnika, ki uporabniku ne more poslati povratne informacije. Prvotni brezžični adapter Alfa Network AWUS036NH z Ralink RT3070 integriranimi vezji deluje, vendar nima visoke zanesljivosti. Priklopljen mobilni strežnik MK802IIS ključne informacije v procesu prenašanja podatkov izgublja zaradi motenj v komunikaciji. Na picuntu, ki predstavlja distribucijo linuxa smo namestili ustrezen gonilnik za delovanje, zato smo zaradi časovne omejitve priklopili drug brezžični adapter Kasens N8600, ki prav tako vsebuje Ralink RT3070 čipovje. Nanj smo priklopili direkcijsko anteno, z namenom hitrejšega prejemanja in oddajanja informacij do usmerjevalnika. Robotsko platformo prikazuje Slika 51. Slika 51: Mobilna robotska platforma. Hitrost nalaganja je ključnega pomena, zato smo zaradi visoke latence ter komunikacije med odjemalcem in strežnikom zamenjali zunanji brezžični adapter, ki v linux okolju uporablja isti gonilnik za svoje delovanje. Ponovili smo test hitrosti dostopanja paketov, ki jih prikazuje Tabela 7. Tabela 7: Rezultati ping testa s Kasens N8600. Strežnik Stacionarni Tablica Prenosni Mobitel MK802IIIS P I P I P I P I AVG % IZG AVG % IZG AVG % IZG AVG % IZG 82ms 1,0% 83ms 4,2% 70ms 1,9 88ms 9,99% MAX MIN MAX MIN MAX MIN MAX MIN 1046ms 1ms 412ms 3ms 762ms 2ms 417ms 3ms Robert Babčec: Razvoj spletnega uporabniškega vmesnika za robota stran 52