Prosjektrapport Eksperter i Team

Instrumentering og styring over Internett

Torbjørn Aase  Andreas Bertheussen  Rune Holmgren  Sigurd Holsen  Jostein Munz

30. april 2014

Sammendrag

Denne rapporten presenterer et verktøy for å visualisere og styre en Dynamixel robotarm basert på målinger av vinkler og kjente konstante parametre. Robotarmens kinematikk er blitt modellert, og inverskinematikken er dokumentert. Brukergrensesnittet for produktet er en arbitrær nettleser som kommuniserer med en server over internett. C++ med rammeverket Qt har blitt brukt i tillegg til javascript og WebGl.

Innhold

3

1 Innledning

Over flere tiår har det blitt utviklet en rekke styresystem til roboter. Mangfoldige millioner kroner har blitt brukt på forskning innen dette feltet, og industrien har kommet langt på dette området. I applikasjoner hvor operatøren ikke kan se den fysiske robotarmen er kamera og målinger av vinklene de vanlige verktøyene for å visualisering. Denne rapporten tar for seg en alternativ visualiseringsmetode hvor en operatør vil se en 3D-modell som kontinuerlig beskriver posisjon og orientasjon til robotarmen. Operatøren har mulighet til å visualisere både faktisk og ønsket posisjon av robotarmen, ved at den ønskede posisjonen vises som en transparent modell, og den faktiske modellen vises som en ikke-gjennomsiktig modell.

2 Problemstilling

Prosjektet har krav om at det er tverrfaglig, involverer styring over internett og at det skal ha stor grad av sammfunnsnytte.

Prosjektet er tverrfaglig ved å kreve kompetanse innenfor både robotikk, hardware, programvare og 3D-grafikk. Styring av robotarmen skjer over internett, og implementeres i JavaScript på klientsiden og C++ på serversiden. Prosjektet vil være aktuelt både i industrielle og akademiske applikasjoner. Det vil være mest aktuellt hvor robotmanipulatorer opererer i ukjente omgivelser hvor et kamera ikke vil gi tilstrekkelig informasjon og det stilles høye krav til presisjon. Eksempel på dette vil være subsea operasjoner eller operasjoner på en satelitt.

3 Problemformulering

Hvordan kan vi fjernstyre en robot over internett, ved bruk av en nettleser?

4 Systembekrivelse

Komponentene som gruppa har til rådighet og som danner utganspunktet for prosjektet, er et servomotorsystem kalt Dynamixel[?], produsert av ROBOTIS. Servomotorene og tilhørende komponenter er vist i blå farge i figur ??, og utgjør roboten". Roboten kan i utgansgpunktet ikke styres direkte fra internett, men kan styres via et serielt bussgrensesnitt, eller med en overgang til USB. I tillegg til robot inngår derfor en server-PC som skal gjøre servomotorene tilgjengelige over internett.

Klienter som ønsker å styre roboten benytter en nettside vist i en nettleser. Denne nettsiden kommuniserer med serveren direkte, og presenterer et grensisnitt der brukeren kan styre og visualisere roboten. I prinsipp kan flere klienter koble seg til systemet samtidig.

Ikke vist i figur ?? er hvordan nettsiden leveres til klienten. Dette kan skje lokalt fra klienten sitt filsystem, fra server-PCen, eller fra en tredje datamaskin som fungerer som en dedikert webserver.

Figur 1: Systemdiagram

4.1 Robotkomponenter

Gruppa har benyttet følgende utstyr:

Figur 2: Dynamixel AX-12+ servomotor, USB2Dynamixel og SMPS2Dynamixel

AX-12+ [?] er en servomotor som kan rotere til en bestemt vinkel mellom 0^{∘}og 300^{∘}, med en oppløsning på 0.29^{∘}(1024 steg). Alternativt kan den settes i hjulmodus uten vinkelbegrensing, men der man kun kan angi rotasjonshastighet.

USB2Dynamixel er en komponent som fungerer som grensesnitt mellom servomotorene og en PC. Denne konverterer signaler mellom den serielle bussen der servoene er koblet sammen, og en virtuell serieport for PC-en.

SMPS2Dynamixel gjør det mulig å bruke en 12V DC nettadapter til å forsyne servoene med strøm.

Komponenter i dynamixelsystemet kobles sammen via et daisy chain. Det vil si at komponentene er koblet sammen på samme buss, der hver enhet har to konnektorer. Én konnektor for koble seg til bussen, og én konnektor for å koble neste enhet til bussen. Dynamixel-bussen består kun av tre ledere; VDD, DATA og GND. På DATA-linjen vil PC og servomotorer utveksle informasjon via TTL level multi-drop UART.

Signaleringen for en UART er vist i figur ??. Når det ikke kommuniseres på bussen, holdes spenningen ved 5V. Under sending, vil først en start bit (0V) sendes, etterfulgt av 8 data bit, og avsluttet med ett stopp-bit (5V). Hensikten med start-bittet er å synkronisere mottaker til senderens sendefrekvens. Hensiktet med et stopp-bit er for å returnere linjen til 5V. TTL refererer til spenningsnivåene 0V og 5V som er brukt. Multi-drop vil si at det er flere mottakere som er koblet på samme buss.

Figur 3: Signalering for en UART

Datamaskinen som styrer systemet sender ut en rekke byte (en pakke) serielt på DATA-linjen. Hver enhet på bussen har en unik ID, og dersom pakken er addressert til enheten sin egen ID, så vil enheten kunne svare. Pakker inneholder instruksjoner for enten lesing eller skriving til minnelokasjoner. Verdien som lagres i hver minnelokasjon har en betydning avhengig av enheten som er koblet til. For AX-12+ for eksempel, kan man skrive til addresse 30 og 31 for å sette ønsket vinkel.

4.2 QT

For å sikre kryssplattform kode, ble QT valgt som C++-rammeverk. Qt er en samling C++- bibliotek som er plattformuavhengig, som vil si at kode som utvikles for Qt-rammeverket krever minimale endringer for å kjøre på en annen platform. De forskjellige bibliotekene fungerer også godt med hverandre, og man får en konsistent kodebase. QT-versjonen som ble brukt er 5.2, men programvaren vår bør også kompilere med senere versjoner.

En annen fordel med å bruke Qt, er at siden det allerede innholder biblioteker for svært mange anvendelser, er det ikke nødvendig å lete etter et eget bibliotek for hver enkelt anvendelse. Qt sine biblioteker er allerede tilgjengelige, og godt dokumentert.

4.2.1 QT og Raspberry Pi

Gruppa hadde i starten et ønske om å kjøre serveren på en Raspberry Pi[?]. Denne platformen har per i dag kunn støtte for Qt versjon 4. For å få koden til å kjøre på Raspberry Pi, må derfor QT5 kompileres til ARM-arkitekturen. Dette viste seg å bli for mye arbeid, så det ble istedet besluttet å kun støtte Windows, Linux og Mac på x86-arkitekturen, som er de platformene som Qt leveres ferdig kompilert til.

4.3 CMake

Store prosjekter med mange kildefiler får ofte en komplisert kompileringsprosess. For å sikre at prosjektet blir bygget på samme måte hver gang, benytter man seg ofte av et byggesystem. Det er per i dag to byggeverktøy som har offisiell støtte for QT: QMake og CMake.

CMake ble valgt siden det er nyere, mer brukt, og mer fleksibelt. Prosjektet genererer flere kjørbare filer, flere testprogrammer og selve serveren. Her var CMake sin løsning mer elegant, og det som var utslagsgivende.

Har denne seksjonen en funksjon, vært lenger?

4.4 Robotdriver

Dynamixel har lagt ut et eksempelbibliotek til Windows og Linux, som gjør det mulig å kople seg opp til roboten og sende pakker. Qt har et bibliotek som skal gjøre dette kryssplattform, kalt QtSerialPort. Utganspunktet var da at biblioteket levert av leverandøren skulle skrives om til Qt ved hjelp av dette. Dette viste seg å være utfordrende, og det ble istedet bestemt at eksempelbiblioteket skulle brukes. CMake gjør det mulig å ha betingelser på plattform, og gjorde det dermed lett å velge mellom plattformversjonene ved kompilering.

4.4.1 Arkitektur

Robotdriveren er lagdelt i fire moduler (se figur ??). Lagdelingen er gjort slik at hver modul kun kommuniserer med laget som ligger rett nedenfor. Dette sikrer en klar fordeling av ansvar, og gjør koden ryddigere.

Figur 4: Lagdeling for serverprogramvaren

Det nederste laget er kalt for DxlHal. Dette er det laget som tar seg av det plattformspesifikke med å sende kommando-pakker over en serieport.

Modulen over dette kalles for Dynamixel. Denne er ikke plattformspesifikk, og er på et høyere abstraksjonsnivå enn DxlHal. Mens DxlHal sender èn og èn pakke, kan Dynamixel sende mer sammensatte pakker.

Det nest øverste laget er kalt DynaChain, der all robot-logikk ligger. Et klassediagram for robotdriveren kan sees i figur ??.

Det øverste laget er nettverkslaget som tar seg av sending og mottaging over internett.

Figur 5: Klassediagram over DynaChain

4.4.2 DynaChain

DynaChain er den modulen som inneholder all robotlogikk. Denne modulen har i hovedsak to oppgaver: Å hente ut, og å endre motorposisjonene.

Den enkleste klassen i hierarkiet er Motor-klassen. Denne klassen innkapsler en enkelt motor. Det som er felles for hver motor er at de har en motor-ID, en maks-vinkel, en minimum-vinkel og et vinkel-avvik. Motor ID-en er den ID-en motoren som sikrer at meldinger kommer frem til rett motor. Som nevnt tidligere, er posisjonen til moteren gitt ved et heltall mellom 0 og 1023. For å gjøre det lettere å tolke disse tallene, ble det bestemt at det skulle brukes grader der 0 grader på alle motorer skulle representere posisjonen vist i figur ??. For å implementere dette trengs derfor et vinkelavvik som gir forskjellen i vinkel mellom posisjon 0 og vinkel 0.

Dette kan betraktes som en slags kalibrering og er avhengig av robotarmen som jobbes med. Det vi regner som 0 grader er gitt av hvordan roboten er modellert for invers kinematikk. De to resterende vinkel-variablene, maks-vinkel og min-vinkel, angir hvilke vinkler som er gyldige.

Figur 6: Posisjon til manipulatorarmen når alle vinkler er satt til 0

For å håndtere en serie med slike motorer, brukes klassen DynaChain. DynaChain inneholder en liste med Motor-objekter, samt metoder for hente ut og styre alle motorer samtidig. Den viktigste metoden her er setAngle(motorid, vinkel), som tar inn motorid og vinkel, og setter motoren til denne posisjonen.

For å hente ut tilstanden til roboten brukes to klasser: DynaChainState og MotorState. Disse klassene er immutable, som vil si at et objekt av disse klassene ikke kan endres etter at objektet først er satt. Dette forsikrer mottageren av et slikt objekt om at objektet aldri har blitt endret.

For å hente ut disse tilstandene brukes metoden getState(), som er implementert for både Motor og DynaChain, og som henholdsvis returnerer et MotorState- og DynaChainStateobjekt. Begge klassene har metoden toJson() for å representere tilstanden som en JSONstreng, slik at den lett kan dekodes av klienten.

4.5 Kinematikk

Robotarmen ble modellert og parametrisert i tråd med Denavit-Hartenberg konvensjonene.

\begin{matrix}Link & a_{i} & α_{i} & d_{i} & θ_{i} \\ 1 & 0 & 90^{∘} & 0.025m & θ_{1}^{∗} \\ 2 & 0.068m & 0 & 0 & θ_{2}^{∗} \\ 3 & 0.1m & 0 & 0 & θ_{3}^{∗} \end{matrix}

Tabell 1: DH table

Følge figur illustrerer kordinatsystemet. x_{0} går langs kjøreretningen til fartøyet som robotarmen er festet på.

Figur 7: Kordinatsystem for robotarmen

Figuren er hentet fra [?, p. 90]. Foroverkinematikken er definert somForklar hva foroverkinematikk er?

x_{e} = cosθ_{1}(d_{2} cosθ_{2} + d_{3} cos(θ_{2} + θ_{3}))
y_{e} = sinθ_{1}(d_{2} cosθ_{2} + d_{3} cos(θ_{2} + θ_{3}))
z_{e} =d_{1} + d_{2} sinθ_{2} + d_{3} sin(θ_{2} + θ_{3})

Hvor x_{e}. y_{e} og z_{e} definerer kordinatene til endepunktet på armen som funksjon av vinklene.

Inverskinematikk beskriver gitt et visst kordinat, hvordan vinklene må settes for at enden av robotarmen skal oppnå den gitte posisjonen. Fra [?, p. 99].

θ_{1} = atan2(y_{c}, x_{c})
θ_{2} = atan2(z_{c} − d_{1}, \sqrt{x_{c}^{2} + y_{c}^{2}}) − atan2(a_{3} sinθ_{3}, a_{2} + a_{3} cosθ_{3})
θ_{3} = atan2(± \sqrt{1 − D^{2}}, D)
D = \frac{x_{c}^{2} + y_{c}^{2} + (z_{c} − d_{1})^{2} − a_{2}^{2} − a_{3}^{2}}{2a_{2}a_{3}}

4.6 Nettverkslag

4.6.1 Valg av transportlag

For å gjøre det mulig å bruke webapplikasjonenen til å styre roboten over internett, må vi velge en egnet teknologi. Styring over internett begrenser oss i praksis til IP-basert (Internet Protocol) kommunikasjon. Fordi vi vil kommunisere fra en webapplikasjon/nettleser, er valgmulighetene videre begrenset. Nettlesere i dag støtter Javascript som gjør det mulig å programmere oppførselen til nettsiden, samt diverse plugins for multimedia og mer avansert programvare.

Forskjellige plugins er tilgjengelige til nettlesere for å kommunisere over nettverket. Så godt som alle nettlesere har Flash installert. Flash støtter både TCP og UDP. Java er også et annet alternativ der man kan benytte både TCP og UDP.

Dersom man ikke ønsker å bruke en nettleser-plugin, finnes to valg som vi diskuterte. Alle disse valgene aksesseres gjennom JavaScript-koden som vi allerede bruker i web-applikasjonen.

HTTP-forespørsler innebærer at klienten må initiere alle overføringer[?]. Denne funksjonaliteten er innebygget i nettlesere sin JavaScript-funksjonalitet, men er mer egnet for å hente data fra en nettside, og ikke en robot. For roboten ønsker vi å kontinuerlig motta siste tilstand fra roboten slik at dette kan vises. Dersom klienten hele tiden må sende HTTPforespørsler (polling), blir dette tungt. Fordelen med HTTP-forespørsler er at trafikken slipper gjennom de aller fleste proxyer og brannmurer, fordi den er lik vanlig nettsidesurfing.

Eksempel på HTTP?

GET /index.html HTTP/1.1 Host: www.example.com

Websockets [?] tilbyr toveis kommunikasjon, og bygger på TCP. Opprettelsen av en websocket likner på en HTTP-forespørsel, men tilkoblingen blir ikke lukket når forespørselen er over. Tilkoblingen fortsetter å være åpen, og klient og server kan utveksle meldinger (frames). Websockets ser ut som HTTP-forespørsler, og kan slippe gjennom brannmurer, men ikke alle proxyer. Websockets er standardisert av IETF, og er støttet av alle de populære nettleserne.

Å bruke HTTP-forespørsler vil innebære å enten tilpasse en eksisterene server, eller skrive vår server fra grunnen av. En slik server vil være mer omfattende enn en Websocket-server. HTTP i seg selv tilfører ikke noe nyttig funksjonalitet utover det å være tilgjengelig overalt, og derfor har vi valgt Websockets.

Opprettelsen av en websocket består av følgende type forespørsel fra klienten:

GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

Deretter følger toveis utveksling av frames, der hvert frame består av en header etterfulgt av data som skal overføres. Innholdet i disse defineres av applikasjonslaget.

4.6.2 Valg av applikasjonslag

For enkelhets skyld har vi valgt å opprette to toveis forbindelser mellom hver klient og serveren. Den ene forbindelsen brukes til styring av roboten, der man kan sende kommandoer og motta responsen på kommandoene (styringsforbindelse). Den andre forbindelsen (tilstandsforbindelse) vil serveren kontinuerlig strømme informasjon om robotarmens tilstand, slik at klientene de kan oppdatere visningen sin. Å gjøre dette i to forskjellige forbindelser gjør implementasjonen enklere, og virker naturlig fordi det er to vidt forskjellige typer trafikk.

Tilstandsforbindelsen har valgt å kun bruke i en retning, fra server til klient. Vi har også valgt å formatere data som JavaScript Object Notation (JSON), ettersom dette er enkelt å dekode i JavaScript på klienten, og er tilgjengelig i Qt-rammeverket.

For styringsforbindelsen ønsker vi å tilby APIet til robot-driveren vår som består av en rekke funksjoner. Vi ønsker at nettverkslaget skal være så tynt som mulig, og tilby dette APIet til klienten (over internett). Da er det naturlig å gjøre det i form av RPC (Remote Procedure Calls).

Det vil si at klienten (i JavaScript) kan kalle setAngle(2.3, 3) for å sette vinkelet på servo med id 3, til 2.3 radianer. Informasjonen om dette kallet (’setAngle’) og dets parametre (3, 2.3) overføres over Websocket, og på mottakersiden tolkes det og utføres på serveren. Eventuell returverdi for prosedyrekallet sendes så tilbake. Det finnes flere RPC-standarder, blant annet JSON-RPC[?] og SOAP[?]. I JSON-RPC og SOAP formateres informasjonen om prosedyrekallet og parametrene som henholdsvis JSON eller XML. JSON er kompakt og godt støttet i både JavaScript og C++, imens SOAP er mer kompleks og dermed vanskeligere å implementere. Av disse grunnene valgte vi JSON-RPC.

Et eksempel på et JSON-RPC-kall og respons for setAngle(2.3, 3) er vist under. --> indikerer data sendt fra klient til server, og <-- er det motsatte.

--> {"jsonrpc": "2.0", "method": "setAngle", "params": [2.3, 3], "id": 1} <-- {"jsonrpc": "2.0", "result": 0, "id": 1}

JSON-RPC støtter også notifications, som er kall uten returverdi. Kallet vil da ikke inkludere et "id"-felt.

4.6.3 Implementasjon av nettverkslag

Fordi robot-driveren var skrevet i C++/Qt, var det naturlig å skrive serveren i noe kompatibelt. Alternativene some vi fant var QtWebsocket (C++/Qt)[?], WebSocket++ (C++/Boost)[?] og libwebsockets (C)[?].

Vi fant ut at QtWebsockets tilbød funksjonaliteten vi ønsket, og kom med mange eksempler - både av servere og klienter. QtWebsocket tilbyr klassene QWsServer og QWsSocket. En QWsServer kan instansieres og bes om å lytte på en gitt IP-adresse og port.

For å implementere JSON-RPC fantes flere muligheter; vi vurderte JsonRpc-Cpp[?], og qjsonrpc[?]. Førstnevnte er minimal og bør være enkel å bruke. Ulempen er at den bruker et tredjepart Json-bibliotek. qjsonrpc er en Qt-basert implementasjon, som baserer seg på QTCPServer og QTCPSocket fra Qt. Det er mer komplekst enn JsonRpc-Cpp, men fordi det er bygget på Qt, er det lettere å integrere med en Qt-applikasjon.

qjsonrpc-biblioteket tilbyr fra før en QJsonRpcTcpServer-klasse. Denne benytter en QTCPServer, og tillater flere TCP-tilkoblinger. For å støtte websockets valgte vi å utvide biblioteket med en ny klasse, QJsonRpcWebsocketServer som benytter QWsServer i stedet for QTCPServer. For å gjøre dette mulig, måtte QWsSocket endres for å oppføre seg mer som en QTCPSocket. Dette innebar å alltid emitte signalet readyRead() når et Websocket-frame er mottatt, og å implementere readData() og writeData() som kan sende og motta Websocket-frames.

JSON-RPC er egnet for styringsforbindelsen

4.6.4 Implementasjon for web-klient

Web-klienten utvikles i JavaScript. Websockets er tilgjengelig gjennom WebSocket()-konstruktoren [?], og dette APIet er implementert i alle de mest brukte nettleserne Internet Explorer, Firefox, Chrome, Safari og Opera[?][?]. Det er derfor ikke nødvendig å skaffe et eget bibliotek for WebSockets.

Vi bygget på denne implementasjonen, og har innkapslet den i en klasse vi kaller Ws. Denne tilbyr mer funksjonalitet for debugging av websockets, som å logge nettverkstrafikken, og skrive informasjon til konsoll når tilstanden til en websocket endrer seg. Denne klassen er til dels basert på eksempelkode inkludert i QtWebsocket.

JSON-RPC-funksjonalitet får vi ved hjelp av et tredjepartsbibliotek kalt jQuery JsonRpcClient[?], som bygger på det populære jQuery-rammeverket.

4.7 Web-applikasjon

Web-applikasjonen tillater en operatør å fjernstyre robotarmen samtidig som han/hun får tilbakemelding om armens posisjon gjennom en 3D-visualisering av leddene i armen. Når operatøren laster nettsiden kobler applikasjonen automatisk til server-applikasjonen som gir kontroll over, og informasjon om robotarmen.

Figur 8: Arkitektur for web-klient.

Web-applikasjonen i seg selv er bygd opp etter en variant av MVC (Model-View-Controller), med filene Robot.js (model), index.html (view) og Core.js (controller). Robot.js blir brukt til å generere to modeller, control_robot og real_robot, som henholdsvis representerer ønsket tilstand og faktisk tilstand på robot-armen. Modellene baserer seg på filen model.json som redegjør for antall ledd og maksimum/minimum vinkel for aktuatorene i armen. Index.html er nettsiden operatøren forholder seg til for å gi kommandoer og få feedback fra roboten. Input og output blir så håndtert av Core.js som er ansvarlig for å holde modellene oppdaterte med informasjon fra operatøren og serveren.

Ved å implementere klienten som en nettjeneste, oppnår vi med en gang en svært høy grad av multiplatformstøtte. De fleste moderne nettlesere på PCer, tablets og mobiltelefoner støtter tjenesten. Dette er en styrke som gjør at det er enklere for bedrifter å adoptere løsningen som et tillegg til allerede eksisterende løsninger.

4.7.1 Fjernstyring av roboten

Figur 9: Det grafiske brukergrensesnittet til web applikasjonen.

Figur ?? viser grensesnittet operatøren forholder seg til ved bruk av systemet. Gjennom kontrollpanelet har operatøren to valg for styring. Manual control tillater manuell styring av hver aktuator i sanntid gjennom bruk av slidere. Set point lar operatøren sette koordinater for ett enkelt punkt. Når operatøren så trykker på Send instructions vil koordinatene bli sendt til serveren og vinkler på aktuatorene regnet ut på server-siden slik at enden på robot-armen treffer punktet. Operatøren har da valget mellom Manual control for responsiv kontroll i sanntid eller Set point for tilfeller hvor det er viktig å nå et nøyaktig punkt.

Til venstre for kontrollpanelet kan operatøren se visualiseringen av robot-armen i 3D. I figuren vises to 3D-modeller av robot-armen. Dette er 3D-representasjoner av de tidligere nevnte real_robot og control_robot. Den solide modellen viser operatøren hvordan robot-armen faktisk er posisjonert, samtidig som den transparente modellen viser hvordan robot-armen bør være posisjonert basert på det input som er gitt. I eksempelet vist i figuren kan da operatøren klart se at noe hindrer den ene aktuatoren i å fullføre den ønskede rotasjonen, feks. en obstruksjon eller en feil ved aktuatoren, og kan da iverksette tiltak. Ved normal drift vil modellene alltid overlappe, siden ønsket posisjon og faktisk posisjon vil være er like.

4.7.2 3D-modeller

Dette prosjektet avhenger i stor grad av at operatøren av roboten får et mest mulig korrekt bilde av utstyret sitt. For å oppnå dette var det viktig å skaffe 3D-modeller som på en realistisk måte representerte den fysiske roboten. Dette ble gjort ved å benytte en MakerBot Digitizer 3Dscanner. Hvert enkelt ledd på roboten ble scannet hver for seg, slik at leddene mellom dem kan manipuleres digitalt i ettertid ved hjelp av Google SketchUp. Ved å finpusse på 3D-modellene fra scanningen for hånd endte vi opp med 3D-modeller som lignet svært mye på den faktiske roboten. Disse modellene ble konvertert fro .obj-format til et JavaScript-basert format som kunne benyttes i webklienten.

Figur 10: Rådataene som de kom fra 3D-scanneren.

Figur 11: Den ferdige modellen slik den framstår i webapplikasjonen.

4.7.3 3D framvisning

Vi valgte som nevnt tidligere å implementere systemet som en nettapplikasjon, og med dette få en høy grad av multiplatform støtte. Dette innebar også at vi ble nødt til å jobbe med 3Dgrafikk i nettleseren. Dette har heldigvis blitt enklere og enklere de siste årene, med HTML5, JavaScript og WebGL. Disse utvidelsene er nå er tilgjengelig i nesten alle nettlesere. For å gjøre utviklingen av løsningen enklere, ble biblioteket THREE.js benyttet. Det gir en økt grad av abstraksjon fra de WebGL-kallene som nettleserne tilbyr, og lar utvikleren benytte mange former for funksjonalitet som normalt sett er vanskelig å implementere selv. Selve 3D framvisningen er et HTML-lerret (canvas) der de to robotmodellene til en hver tid er representert med hver sin 3D-modell.

5 Videre arbeid

3D-grafikk er sentralt i produktet, og de fleste relevante utvidelser av prosjektet fordrer kunnskap på denne fronten. Kjennskap til robot-kinematikk vil også være sentralt for de fleste utvidelser.

Integrasjon av hjul

Robotarmen er festet på en bil med fire servomotorer som hjul, og en naturlig utvidelse vil være å inkludere denne i prosjektet. Hjulene på bilen har sensorer som gjør det mulig å inkludere bilen i 3D modellen. Dette åpner også for styring av bilen igjennom det eksisterende brukergrensesnittet.

Banefølging

Da forover- og inverskinematikk allerede er håndtert legger dette til rette for å generere en bane som en ønsker robotarmen skal følge. Man vil da kunne visualisere denne banen på forhånd med den transparente modellen før en gir kommandoen til roboten.

Dette kan kombineres med Integrasjon av hjul for å følge mer komplekse kurver i rommet.

Visualisering av omgivelser

For å bruke prosjektet i praksis vil en trenge en visuell referanse, og mulighet til å visualisere objektene som roboten skal arbeide på eller med. Visualisering av omgivelsene vil gi en solid referanse for styring i 3D-modellen. For å oppnå dette kan en bruke kamera og sensorer, enten separat eller i kombinasjon. En Kinect eller en LIDAR sensor vil gi 3D-informasjon om omgivelsene som kan overføres til klienten og visualiseres sammen med roboten i 3D-visningen. Dersom man har en presis modell av fartøyets bevegelse vil et kamera kunne med god presisjon kartlegge omgivelsene. Et kamera vil også kunne bidra med farging av omgivelsene, og det vil være et godt supplement til 3D-visualiseringen. Dette vil trolig kreve kunnskap om bildebehanling og 3D-grafikk.

Implementasjon av serveren og driver til portabel datamaskin

Ved å overføre serveren og driveren til en mikrokontroller eller Raspberry Pi kan en oppnå trådløshet av robotarmen. Dette antas å være relativt lite tidkrevende, og det vil være praktisk å kombinere med en mobil robot. Det var et mål for prosjektet å implementere dette på en Raspberry Pi, men det ble forkastet da Qt 5.2 ikke var ferdig kompilert til ARM-plattformen til Raspberry Pi.

Implementere sikrere kommunikasjon

Sikkerhet har ikke vært en prioritet for oss i dette prosjektet, men kan være interessant i senere implementasjoner. I nåværende versjon av systemet er det ingen form for kryptering eller autentisering i kommunikasjonen mellom klient og server. Det vil si at det ville vært uproblematisk for utenforstående å benytte seg av systemet og potensielt misbruke det. For å motvirke dette bør det implementeres kryptering og også funksjonalitet som krever at operatører av systemet må logge seg på, for å sikre at kun de som faktisk skal ha tilgang til systemet får det.

Legge til flere ledd

For en mer sofistikert robot kan en legge til flere ledd. En kan utvide bibloteket for å støtte flere ledd uten å fysisk endre på roboten. Inverskinematikken for flere ledd er dog meget eksponensiell i kompleksitet, og i stedet for å utlede denne selv, bør man forsøke å finne et mer generelt bibliotek.

6 Vedlegg

A Hvordan sette opp serveren

A.1 Bygging av koden

For å bygge koden trengs byggeverktøyet CMake, samt en installasjon av Qt versjon 5. Qt kan lastes ned fra http://qt-project.org/downloads CMake kan lastes ned fra http://cmake.org/. Kiledkoden ligger på https://bitbucket.org/eit2014/server og kan lastes ned med git.

A.1.1 Installasjon av Qt

Under installasjon av Qt, velg standard installasjonsvei. Som kompilator, velg MinGW sin C++- kompilator. Pass på å krysse av for installere av QtCreator.

A.1.2 Installasjon av CMake

Programmet installeres på vanlig måte.

A.1.3 Kompilering

• Åpne QtCreator

• Velg Open Project

• Bla frem til mappen der kildekoden ligger og velg filen CMakeLists.txt og trykk Next • På bygge-plassering velges ønsket lokalisering av de kompilerte filene. Trykk Next.

• Om det ikke er gjort tidligere, må lokalisering av cmake.exe finnes. Denne ligger der CMake er installert

• Trykk Run CMake. På Windows kommer det her noen advarsler, men sålenge byggefilene ble skrevet, er alt OK.

• Prosjektet kan nå kompileres ved å trykke hammeren nederst til venstre.

A.2 Test kommunikasjon med roboten

For å gjøre det enkelt å teste roboten, ble det laget flere små programmer som kjøres uavhengig av konfigurasjon. Det enkleste programmet å teste er wriggle.

Roboten er koplet til datamaskinen gjennom en serieport. På Linux vil den få et device-name som /dev/ttyUSB# der # er et tall fra og med 0. Om ingen andre serieporten er tilkoplet vil dette tallet være 0. På Windows vil den dukke opp i Device Manager som en COM#-input der # er et tall fra og med 3. Om ingen andre serieporter er opptatt, er dette tallet 3.

• Kople til roboten.

• I QtCreator trykk på Projects i venstremenyen.

• Øverst i programmet kan man velge mellom Build og Run. Trykk på Run.

• Under Run configuration, velg wriggle.

• I tekstboksen Arguments, skriv inn 0 for Linux eller 3 for Windows. Dette er det samme nummeret som beskrevet i parafen over.

• For linux kan det hende det må endres rettigheter på robot-input-filen. Gå inn i en terminal og skriv inn “sudo chmod 777 /dev/ttyUSB0”. For å kjøre denne kommandoen trengs passord.

• Trykk på den grønne Run-knappen i nedre venstre hjørne for å starte.

• Følg instruksjonene til programmet. Roboten vil begynne å bevege seg, så pass på at den står slik at ingen blir skadet.

A.3 modellfilen

Modellfilen er en JSON-fil som beskriver hvordan roboten er bygget opp. Denne modellfilen viser hvor de forskjellige servoene er koplet sammen. Hvis det brukes en annen robot enn den som ble brukt i dette prosjektet, må modellfilen konfigureres for den nye roboten. Hvis modellfilen er korrekt, er neste punkt å teste serverprogrammet.

A.4 Starte serveren

• Kople til roboten og test kommunikasjonen som beskrevet i kap. ??.

• Bytt program fra wriggle til server.

• I tekstboksen Arguments, skriv inn samme tall som fungerte under wriggletesten.

• Trykk på den grønne Run-knappen i nedre venstre hjørne for å starte. Serveren burde nå være oppe og gå.

A.5 Finn IP

For å gjøre det mulig for andre å kople seg til serveren, må de vite hvilken IP serveren ligger på. IPen kan blant annet finnes ved å gå inn på http://www.whatsmyip.org/.

B Hvordan sette opp web-siden

• Pakk ut filen web.rar i en mappe som leses av en web-server.

• Finn filen rpcserver.js i mappen src.

• Åpne denne filen med et hvilket som helst tekstredigeringsverktøy (feks. notepad/notisblokk).

• På fjerde linje finner du variabelen ip. Endre verdien på denne variabelen til å samsvare med IP-adressen som tilhører robot-serveren. Lagre endringene og lukk programmet.

• Brukere kan nå styre roboten over internett gjennom nettleseren sin ved å aksessere index.html som du deler på din web-server.