Resumé. Dette kan være med til at minimere spildtid i forsøg med robotter, som kører autonomt uden overvågning.

Resumé Denne rapport er skrevet i forbindelse med udarbejdelse af projektet på Institut for Automation ved Danmarks Tekniske Universitet. Internetbaseret interface eller web-enabling betyder, at en robot gøres tilgængelig over Internettet. Til dette projekt er der blevet anvendt en af Instituttets standard robotter en Small Mobile Robot. Robotten er blevet web-enablet ved at udvikle en Java applikation, som kan styre robotten ud fra nogle koordinater, der genereres af en bruger. Koordinaterne sendes, når vedkommende klikker på et billede fra robottens webkamera, vist på en dertil konstrueret hjemmeside. Desuden er der lavet en applikation, som er i stand til at sende en SMS via en serviceudbyder, så som email2sms.dk. Dette gør det muligt for administratoren af en robot at blive kontaktet i tilfælde af, at vedkommendes robot har fået problemer. Dette kan være med til at minimere spildtid i forsøg med robotter, som kører autonomt uden overvågning.

Abstract This report has been written as part of the project Internet based interface for mobile robots at the Automation Institute at The Technical University of Denmark. Internet based interface also known as web enabling means that a robot has been made accessible through the Internet. This project has been developed using a standard robot from the institute, a Small Mobile Robot. The robot has been web enabled by developing a Java application, which controls the robot using coordinates generated by the user. The coordinates are sent when the user clicks the image from the robot s web-camera, which is shown on a website made for that purpose. Another application has also been developed. This has the purpose of sending a SMS to the robot administrator, using the service of a service provider such as email2sms.dk. This makes it possible for the administrator to discover a problem, without being near the robot. This can minimize time wasted during projects with autonomous robots.

1 Indhold Resumé...1 Abstract...1 1 Indhold...1 2 Indledning...5 2.1 Problemstilling...6 2.1.1 Afgrænsning...6 2.2 Information til læseren...7 3 Teknologier...8 3.1 Robotter...8 3.2 SMR...9 3.3 PHP... 11 3.4 JAVA... 13 3.5 C/C++... 14 3.6 SOAP... 15 3.7 Web Services... 16 3.8 EMAIL2SMS... 16 3.9 Javamail... 17 3.10 Palantir... 18 4 Analyse... 20 4.1 Use case modellering... 20 4.1.1 Use cases... 20 4.1.2 Aktører... 22 4.1.3 Use case diagram... 22 4.2 Scenarier... 23 4.2.1 Scenarie 1:... 23 4.2.2 Scenarie 2:... 23 4.3 Kravspecifikation... 23 4.3.1 Del 1... 23 4.3.2 Del 2... 24 4.4 Mulige løsninger... 24 5 Udviklingsprocessen... 26 5.1 SOAP... 26 5.2 PHP... 27 5.3 Java... 28 5.4 WebenableSMR... 29 5.4.1 Main... 29 1

5.4.2 Init... 29 5.4.3 RobotCOM... 30 5.4.4 WebCOM... 31 5.4.5 RobotDrive... 31 5.4.6 CameraDistance... 36 5.4.7 Log... 36 5.4.8 RobotInfo og Auxiliary... 37 5.4.9 LogNAlert... 37 5.5 Alerter... 38 5.5.1 Main... 39 5.5.2 AuxFunc... 39 5.5.3 LogNAlert... 40 5.6 Hjemmeside... 41 5.7 Test... 42 5.7.1 WebenableSMR... 42 5.7.2 Alerter... 46 5.7.3 Webbrowser... 46 5.8 Resultater... 48 6 Diskussion... 51 6.1 Mangler... 51 6.2 Hvad har jeg lært... 52 6.3 Udviklingsmuligheder... 53 7 Konklusion... 56 8 Litteratur... 57 9 Bilag... 60 9.1 Bilag 1 Intel specs... 60 9.2 Bilag 2 mobitech info... 61 9.3 Bilag 3 XML fil... 62 9.4 Bilag 4 Manual... 63 9.4.1 Palantir... 63 9.4.2 SMRDEMO... 63 9.4.3 WebenableSMR... 63 9.4.4 Alerter... 63 9.4.5 Kalibrering af webkamera... 64 9.5 Bilag 5 Kildekode... 65 9.5.1 Main... 65 9.5.2 Init... 68 9.5.3 RobotCOM... 70 2

9.5.4 WebCOM... 73 9.5.5 RobotDrive... 76 9.5.6 CameraDistance... 80 9.5.7 Log... 82 9.5.8 Auxiliary... 84 9.5.9 RobotInfo... 86 9.5.10 LogNAlert... 87 9.5.11 AuxFunc... 90 9.5.12 Main Alerter... 97 9.5.13 Project.php... 99 9.5.14 ClickAndDrive.php... 100 3

4

2 Indledning Dette speciale er udarbejdet som afslutning på et langt Civilingeniørstudie på DTU. Det forventes, at læseren har nogen erfaring med forskellige matematiske og softwaremæssige begreber. Formålet med dette projekt er, at lave et velfungerende interface til styring af en Small Mobile Robot 1 via Internettet. Endvidere skal der udvikles en logfunktion til en SMR, som har mulighed for at alarmere brugerne af SMR en via en SMS i tilfælde af, at der er problemer med SMR en. Formålet med et Internetbaseret interface eller webenablingen 2 af SMR en er, at robotten kan anvendes til demonstration af, hvad man kan give sig i kast med på Institut for Automation 3. Det således tanken, at nysgerrige besøgende på IAU s hjemmeside kan køre rundt med en SMR via Internettet. Måden det fungerer på er, at der på SMR en er monteret et webkamera, som hele tiden transmitterer et billede til en hjemmeside. Brugeren kan så se dette billede ved at klikke ind på siden. Hvis brugeren ønsker at styre SMR en rundt, kan vedkommende trykke på det viste billede, hvorefter ro- 1 Herefter kaldet en SMR 2 Andet ord for styring via Internettet 3 Herefter IAU 5

botten vil bevæge sig hen til det pågældende markerede punkt. Log-delen af projektet er udtænkt med det formål, at man i test af robotter ofte lader disse passe sig selv i f.eks. en weekend. Hvis robotten får problemer i løbet af denne periode, er det en fordel, at den har mulighed for at kontakte sin ejer og fortælle denne, at der er problemer. Det er tanken, at robotten skal sende en alarm SMS til vedkommende, samt en e-mail med relevant log data. Ejeren kan herefter tage stilling til problemet, hvorefter han kan hjælpe robotten på rette vej igen, eventuelt via et webinterface. 2.1 Problemstilling Der ønskes implementeret en løsning til web-enabling af en smr-robot. Endvidere ønskes der implementeret et system til at advisere den ansvarlige, via SMS og e-mail, hvis en robot kommer i problemer. 2.1.1 Afgrænsning Denne problemstilling er meget bred, og det skal præciseres, at der primært vil bliver arbejdet på at få styring af robotten via en webbrowser implementeret. Design af hjemmesiden vil ikke blive prioriteret ret højt i dette projekt. Der skal altså ikke forventes meget af den grafiske præsentation på hjemmesiden. 6

2.2 Information til læseren Det forudsættes at læsere af denne rapport har en forståelse for civilingeniørmæssige værktøjer, som er på niveau med forfatterens, samt er rimeligt fortrolige med begreber som UML og desuden har et rimeligt kendskab til forskellige programmeringssprog, i særdeleshed Java. Rapporten er skrevet på dansk, men der kan forekomme engelske termer, som det ikke har været belejligt at oversætte. 7

3 Teknologier I det følgende afsnit vil nogle af de teknologier, som har været i betragtning til dette projekt, blive beskrevet. Det er ikke dem alle, der er blevet anvendt i den endelige løsning, men der vil siden hen blive gjort rede for hvorfor/hvorfor ikke de er blevet valgt. Da dette projekt blev påbegyndt, var min erfaring indenfor webenabling meget begrænset. Derfor var den indledende opgave at undersøge, hvorfor og hvorledes. Til dette er søgemaskinen Google et yderst effektivt værktøj, som hurtigt kan lede en på rette spor. 3.1 Robotter Robotter er et begreb, som dækker over en meget stor mængde af elektroniske enheder. En definition på en robot kan være: an electro-mechanical device that can perform autonomous or preprogrammed tasks. 4 Fælles for robotter er, at de er i stand til at bevæge sig på den ene eller anden måde, samt at de kan udføre en fysisk opgave. Man kan opdele robotter i mange kategorier. Nogle robotter udfører opgaver autonomt vha. deres programmerede kun- 4 http://en.wikipedia.org/wiki/robot 8

stige intelligens, hvorimod andre robotter styres af mennesker ved brug af joysticks og lignende. Oprindeligt blev robotter produceret for at udføre et stykke arbejde for mennesker, men efterhånden bliver de også produceret som underholdning. Et eksempel herpå er robothunden AIBO, som er udviklet af Sony. Figur 1 - AIBO fra Sony AIBO er ikke i stand til at lave et stykke arbejde efter vore begreber, men man kan træne den til at lave kunster ligesom en rigtig hund. Udviklingen inden for robotindustrien fortsætter med fuld fart. I en knap så fjern fremtid bliver det højst sandsynligt normen, at hver husstand har en eller flere robotter som hjælper til med at passe hus. Allerede nu findes der flere modeller af selvkørende plæneklippere og støvsugere, som kan ordne have og gulve, uden at vi mennesker skal bruge tid og energi på det. 3.2 SMR Først og fremmest er det oplagt at forklare lidt om det hardware som er mål for projektet. Målet er, at programmet skal afvikles på en Small Mobile Robot (SMR). En SMR er en lille firkantet robot med mål på cirka 28 * 28 * 30 cm. Den drives frem ved hjælp af to motorer, som er koblet til hver 9

sit baghjul. Foran sidder to svingbare hjul monteret. Dette design gør, at SMR en har nemt ved at dreje omkring sit eget rotationspunkt, og kan gøre det med ganske lille svingradius. Figur 2 Rotationspunktet på en SMR set fra oven SMR en kører med en kompakt linux installation, som afvikles fra en flashdisk. Dette betyder, at der er mange af de samme features tilgængelige som på en almindelig pc. Robotten er i stand til at afvikle C og Java programmer. SMR en styres fra programmet SMRDEMO, som forstår og eksekverer kommandoer skrevet i sproget SMRCL. Der er forskellige muligheder for at anvende SMRDEMO: blandt andet kan det køres som en server der modtager kommandoer via en socket. Et eksempel på en kommando i SMRCL er: fwd 2.0 @v 1.0 @a 1.0. Denne kommando beder robotten om at køre 2 meter frem, med hastigheden 1 m/s og accelerationen 1 m/(s*s). Endvidere er der en intern log funktion, som gør det muligt at monitorere værdierne af de forskellige sensorer. For et fuldt overblik over mulighederne med SMRCL kan jeg henvise til dokumentationen heraf, som findes på følgende adresse: http://www.iau.dtu.dk/ag/setups/miniagv/smrcl.pdf Den robot, som er anvendt til dette projekt, er en af de robotter som er blevet opdateret med lidt nyere hardware. 10

Den er udstyret med en Via C3 1,2 GHz processor og har en batterilevetid på ca. 2,5 time 5. Dette kunne godt være bedre, da formålet med dette projekt er at køre rundt med robotten uden strøm tilsluttet, men da IAU er i besiddelse af en del SMR er, vil der som oftest være mulighed for at sætte et fuldt opladt batteri i SMR en. Batterilevetiden vil dog efterhånden blive et mindre vigtigt emne, da der hele tiden kommer nye og bedre batterier, samt at processorerne bliver mere og mere energi besparende. Intel s nye Core SOLO ultra low voltage anvender kun ca. 5,5 watt 6, hvilket er ca. halvdelen 7 af den energi, den nuværende bruger. VIA, som har produceret den processor, der sidder i SMR erne nu, er også kommet med en nyere model. Deres Ultra Low Voltage model C7 skulle ifølge dem selv være førende i ydelse-prwatt operationer, og denne model kan fås med et energiforbrug helt ned til 3,5 watt 8 3.3 PHP For at få en interaktion med brugeren er det nødvendigt med noget kode til at opfange brugerens klik på skærmen. 5 Teleoperation af Mobile Robotter M. Løvgreen og A. Beck s. 17 6 Se bilag 1 7 Teleoperation af Mobile Robotter M. Løvgreen og A. Beck s. 17 8 http://www.via.com.tw/en/products/processors/c7-m_ulv/ 11

Der var ikke de store valgmuligheder i dette tilfælde, da det er nødvendigt, at handlingen sker på server-side for at få adgang til IAU s interne netværk. Da denne server allerede anvender PHP, blev dette også sproget til at skrive hjemmesiden i. PHP er et meget alsidigt sprog, som har et væld af indbyggede funktioner, men det har også sine ulemper. For eksempel er det muligt at gemme værdier af forskellig type i den samme variabel, hvilket kan gøre det svært at lave fejlsøgning i koden. Da PHP, som oprindeligt var en forkortelse for Personal Home Page Tools, men nu står for PHP: Hypertext Preprocessor 9, er udviklet som et open-source projekt, tiltaler det mange brugere, og har derfor vundet indpas på servermarkedet som konkurrent til Microsofts IIS. Et serversidesprog, fungerer ved, at brugeren kan komme med noget input eller en forespørgsel, hvorefter der dynamisk genereres en Webside med indhold derefter. Dette gør det praktisk til visning af indhold fra databaser, da man let kan generere visningen ud fra brugerens valg. 9 http://en.wikipedia.org/wiki/php 12

3.4 JAVA Java er et objekt orienteret programmeringssprog. Det blev udviklet af SUN Microsystems i starten af 90 erne og ligger rimelig tæt op ad C og C++ i syntaksen. Et objekt orienteret sprog lader brugeren programmere sin applikation i små dele, kaldet klasser. Man kan forstille sig, at det er lidt ligesom at samle en cykel. Klasserne er i dette tilfælde de elementer, som cyklen består af, dvs. stel, hjul, styr, pedaler, kæde osv. Når man samler alle delene, får man en velfungerende cykel. Det samme gælder i JAVA, hvor klasserne hver for sig giver en vis funktionalitet, men samlet giver de et velfungerende program. Fordelen ved denne form for programmering er, at man kun behøver at lave tingene én gang, men at man kan anvende klasserne igen og igen. Java har også fordel af at være platforms-uafhængigt: alt der er nødvendigt for at køre et program er Javas runtime environment (JRE), som findes til stort set alle platforme. Med JRE installeret på en maskine kan Java applikationer køres, selvom de er skrevet på en helt anden platform. Java er et meget alsidigt sprog, med rigtig mange færdige klasser. Det er derfor vældig praktisk at skrive kode i Java, hvis man ikke ønsker at opfinde hjulet igen. 13

3.5 C/C++ C og C++ er et alternativ til at skrive programmet i Java. C++ er også et objekt orienteret programmeringssprog og har fordel af at være hurtigere til at eksekvere programmer end Java. C++ er dog også et mere komplekst sprog, hvor man har mulighed for at adressere steder i hukommelsen vha. pointere. C++ blev udviklet af Bjarne Stroustrup i 1983 som en udvidelse til C. Oprindeligt blev det kaldt for C med klasser, da det netop var det udvidelsen gik på 10. C++ er ligesom Java et meget alsidigt sprog, og man kan stort set lave de samme ting i C++ og Java, men C++ er som oftest mere effektivt i sin kørsel, hvilket er prisen Java må betale for at være lidt mindre komplekst. Der er fordele og ulemper ved begge sprog, og der er mange, som har ideer om, hvorfor det ene er bedre end det andet, men jeg har valgt at bruge Java, da det er det sprog, jeg har mest erfaring i at anvende. 10 http://en.wikipedia.org/wiki/c%2b%2b 14

3.6 SOAP I begyndelsen af dette projekt havde jeg kun en meget begrænset ide om, hvad webenabling egentlig er. Det tager dog ikke lang tid, før Google leder en i retningen af værktøjet SOAP. Dette værktøj er en simple XML-protokol, som kan bruges til at sende information over Internettet via HTTP. Der er rigtig mange fordele forbundet ved dette, da de fleste netværk har åben adgang på HTTP porten (port 80). Dette gør, at man slipper for bøvl med eventuelle firewalls og deslige. Hvad er det, der gør SOAP så smart? SOAP står for Simple Object Access Protocol. Det er en protokol, som tillader, at applikationer kan kommunikere med hinanden via http. Det vil sige, at SOAP kan gå ind og løse nogle af de samme opgaver som DCOM 11 og CORBA 12, men på en mere simpel måde. Da DCOM og CORBA kommunikerer ved hjælp af Remote Procedure Calls, opstår der ofte problemer med hensyn til sikkerhed, idet denne form for trafik ofte blokeres af firewalls. Denne forhindring er ikke noget problem for SOAP, da den anvender HTTP, som allerede understøttes af alle webservere og browsere. Endvidere gør SOAP det muligt at kommunikere mellem applikationer skrevet i forskelli- 11 http://en.wikipedia.org/wiki/distributed_component_object_model 12 http://en.wikipedia.org/wiki/corba 15

ge sprog, og som bliver afviklet på forskellige operativ systemer. 13 3.7 Web Services En anden ting, som man hurtigt støder på, når man søger efter information om webenabling, er web services. Ideen med web services er at gøre allerede eksisterende applikationer til web applikationer, det vil sige, at man laver dem tilgængelige via Internettet. Web services er tiltænkt at blive indlemmet i eksisterende applikationer, hvorved de ved hjælp SOAP, UDDI og WSDL kan publiceres til andre brugere. Endnu er web services et forholdsvist simpelt værktøj, men når SOAP protokollen bliver udvidet med bedre sikkerhed og routing features, vil det blive mere alsidigt og brugbart. 14 3.8 EMAIL2SMS Dette er en service, som de fleste store mobil selskaber tilbyder. Den gør det muligt at få videresendt en e-mail til en mobiltelefon, som SMS. Dette er en service, som er interes- 13 http://www.w3schools.com/soap/soap_intro.asp 14 http://www.w3schools.com/webservices/ws_intro.asp 16

sant, da det er betydeligt enklere at programmere en funktion til afsendelse af en e-mail, end det er at programmere en funktion til afsendelse af en SMS. Da begge dele koster lidt at få afsendt, var det ikke oppe til den store overvejelse, hvilken en af disse der skulle anvendes. Det fungerer således, at man opretter et abonnement hos en af udbyderne, TDC, Sonofon eller Mobitech. I Mobitech s tilfælde skal man så komponere en e-mail med en modtager i formatet: mobilnummer. abonnementsnavn @email2sms.dk. Herefter modtager man den som en almindelig SMS. En SMS er defineret som 160 tegn, og ønsker man at skrive en længere besked, bliver der afregnet derefter. 15 3.9 Javamail Til at kreere e-mails i Java er det nødvendigt, at man henter en udvidelse til Java2SE, som hedder Javamail. Denne udvidelse indeholder alle de nødvendige biblioteker til understøttelse af e-mails. For at få indblik i mulighederne med Javamail henvises der til følgende: 15 For mere info: http://www.mobitech.dk/mobile_email2sms.html ; http://erhverv.tdc.dk/artikel.php?dogtag=tdc_e_tel_se_ir_sms eller http://www.sonofon.dk/erhverv/produkter/sms_services/email2sms/index.shtml 17

http://java.sun.com/products/javamail/javadocs/index.html 3.10 Palantir Webkameraet er en meget essentiel del af dette projekt. Valget af Palantir som webcamserver er baseret på andre undersøgelser af dette, fortaget af bl.a Anders Bech og Mikkel Løvgreen. Da der findes et utal af forskellige webcamservere til linux (WebMedia, UGrabCam, cqcam og mange flere) 16, har jeg prioriteret således, at i stedet for at lave en tidskrævende undersøgelse selv, har jeg valgt at følge anbefalingerne fra tidligere projekter. De peger på Palantir som det bedste valg med den begrundelse, at programmet anvender færrest ressourcer samt er nemt at anvende - og fleksibelt 17. Specielt vigtigt for valget er ressourceforbruget, da det på SMR en er vigtigt ikke at bruge for mange ressourcer, da det ellers kommer til at gå ud over ydelsen af programmet. Palantir er meget nemt at anvende. Selve koden hentes fra http://www.fastpath.it/products/palantir/index.php. Her findes desuden en glimrende dokumentation af programmet. Palantir skal startes som superuser, og selve konfigurationen af Palantir sker ved at tilpasse filen Palantir.conf. I den- 16 http://myhome.hanafos.com/~soonjp/wcam.html 17 Teleoperation af Mobile Robotter M. Løvgreen og A. Beck s. 60 18

ne fil kan man sætte frameraten, kompressionsniveauet, billedstørrelse, samt mange andre variable. I dette projekt er anvendt en framerate på 5 fps, en kompression på 90 og en outputstørrelse på 640x480 pixels. 19

4 Analyse I dette afsnit vil jeg forsøge at analysere opgaven. Denne analyse skal være med til at kaste lys på de vigtigste problemer og vil ende ud i en endelig kravspecifikation. I det følgende vil jeg opstille nogle use cases for, hvilken idé projektet har til formål at opfylde. 4.1 Use case modellering Denne form for modellering anvendes til at beskrive funktionaliteten af et system. Der vises et struktureret syn på systemet. I dette underafsnit vil jeg derfor beskrive nogle use cases samt beskrive, hvilke aktører der vil anvende systemet. Dernæst vil jeg opstille et use case diagram. 4.1.1 Use cases Der er ikke så mange muligheder med hensyn til use cases, men følgende vil være den primære: Kørsel med robotten: 1. En bruger surfer ind på hjemmesiden 2. Siden viser instruktionerne til brugeren 3. Brugeren klikker på billedet, hvorved koordinaterne for klikket sendes til robotten. 4. Robotten kører til det punkt, der er klikket på. Skarp drejning: 1. En bruger surfer ind på hjemmesiden 2. Siden viser instruktionerne til brugeren 3. Brugeren klikker på scrolldown-menuen og vælger aktion, og derefter klikkes på billedet, hvorved koordina- 20

terne for klikket samt aktionsnummeret sendes til robotten. 4. Robotten ignorerer koordinaterne og udfører kun den valgte aktion. Klik på billedet imens robotten kører: 1. Robotten er i gang med at udføre en tidligere kommando 2. Brugeren klikker på billedet, imens robotten stadig kører 3. Brugeren får en fejlmeddelelse på skærmen og robotten fortsætter den forrige instruktion Robotten kører tilbage automatisk: 1. Brugeren har forladt siden efter endt kørsel 2. Robotten venter på nyt input 3. Efter et bestemt stykke tid skifter robotten til tilbagekørselsprogrammet 4. Robotten kører tilbage, indtil den når start. Kørsel med robotten: Forud defineret problem opstår 1. Brugeren kører med robotten 2. Under kørslen foretages fejltjek på forud definerede problemer (evt. for lav batterispænding). 3. Robotten finder, at en af disse fejl er opstået, og kalder alarmeringsprogrammet. 4. Robotten afventer hjælp. 21

4.1.2 Aktører Nedenstående beskrives de aktører, som har indflydelse på programmet. Dette vil primært være menneskelige aktører, men kan også være computere. Dette system har kun én udefrakommende aktør, hvilket er brugeren. Derudover fungerer robotten selv som aktør, når der køres tilbage. I det tilfælde at alarmeringsdelen bliver aktiveret, er det igen robotten selv, der fungerer som aktør 4.1.3 Use case diagram Ovenstående resulterer i et følgende use case diagram. Figur 3 Use Case Diagram 22

4.2 Scenarier I det følgende vil jeg opstille nogle scenarier som idéer på hvorledes man kunne tænke sig, at programmet kunne anvendes. 4.2.1 Scenarie 1: En nysgerrig studerende klikker sig ind på IAU s hjemmeside for at få et større indblik i, hvad det egentligt er, der foregår hos IAU. Han får klikket sig hen til punktet web-enabling og vælger punktet, kør med en af IAU s robotter. Han får nu åbnet et nyt vindue, hvori han kan se billeder fra robottens webkamera. Han følger nu instruktionerne på siden og kører rundt med robotten ved at klikke på billedet. 4.2.2 Scenarie 2: En robot er programmeret til at køre igennem Dyrehaven. Efter at have kørt et par timer opstår et problem, så den er ude af stand til at køre videre. Programmet opdager, at noget er galt, og det udløser en alarm, som sender en SMS til brugeren om at der er opstået et problem, samt en e-mail indeholdende et XML dokument med de seneste sensordata. Brugeren bliver opmærksom på problemet og kan, ud fra de opsamlede data, få en ide om, hvad problemet er, og kan derefter forsøge at løse det eller køre ud og reparere robotten. 4.3 Kravspecifikation Der er opstillet følgende krav til projektet. 4.3.1 Del 1 Det skal være muligt at styre robotten via en internetbrowser. 23

Robotten skal kunne dreje til højre og venstre. Web-kameraet skal opdatere, imens robotten kører. Robotten skal kunne detektere motorfejl. Robotten skal kunne køre tilbage til start ved hjælp af logning af modtagne koordinater. 4.3.2 Del 2 Det skal være muligt at kontakte brugeren via SMS i tilfælde af alarm Det skal være muligt at sende logdata til brugeren via email i tilfælde af alarm Der skal kunne føres log af op til 8 variable Det skal kunne integreres i eksisterende systemer 4.4 Mulige løsninger Problemstillingen kunne løses på flere forskellige måder. Nedenstående vil jeg liste nogle af de idéer som blev overvejet i brainstormingen. Konvertering af eksisterende program til en webservice. Programmere webside til håndtering af hele styringen. Lave en webservice fra begyndelsen. Java applikation som kan afvikles direkte på robotten. 24

FOR 1 Har et velfungerende program at bygge videre på. 2 Har det hele samlet på web serveren, ingen problemer med sikkerhed 3 Får kun nødvendige funktioner med i programmet. Mere overblik. 4 Stærkeste i dette sprog. Let at arbejde med. Platformsuafhængigt. Mange færdige klasser. IMOD Kræver programmering på meget højt niveau. Måske for ambitiøst hold op imod min programmeringserfaring. Begrænsninger i sproget. Er ikke sikker på, at det kan køre problemfrit Manglende erfaring Ydelse i forhold til C/C++ Ellers ingen nævneværdige. 25

5 Udviklingsprocessen I dette afsnit vil jeg beskrive, hvorledes udviklingsprocessen af dette projekt er foregået. Som nævnt tidligere havde jeg intet kendskab til webenabling før dette projekt, men den første idé var at bygge videre på midtvejsprojektet af Anders Bech og Mikkel Løvgreen og prøve at få dette konverteret til noget brugbart. 5.1 SOAP Den indledende litteratursøgning gav meget hurtigt et fingerpeg om, at løsningen på problemet var at anvende SOAP sammen med webservices. Måden, hvorpå SOAP og webservices fungerer, er ikke så svær at forstå, men at finde det rette værktøj til denne opgave var ikke så let endda. Da koden i midtvejsprojektet er skrevet i C/C++, var det naturligt at finde et SOAP værktøj til C/C++. Der findes en række forskellige SOAP værktøjer til C, men jeg valgte at fokusere på gsoap 18. Eftersom mine undervisningstimer indenfor programmering primært har været i Java, var det lidt af en udfordring. 18 http://www.cs.fsu.edu/~engelen/soap.html 26

Efter at have læst et utal af vejledninger og eksempler på brugen af gsoap var der ikke sket de store fremskridt. For det første fordi jeg ikke helt kunne gennemskue brugen af gsoap, og for det andet, drejede alle artiklerne sig om, hvorledes man kreerede en webservice fra bunden af. Mit problem var, at jeg havde et færdigt produkt, som skulle konverteres til en webservice. Det eneste, jeg kunne finde i min søgen på information, om konverteringen af allerede eksisterende software, var, at man kunne betale sig fra det hos diverse firmaer, hvilket ikke var til den store hjælp. Derfor måtte jeg, efter en del overvejelser, vælge at løse dette problem på en helt anden måde. 5.2 PHP Efterfølgende overvejede jeg, om man kunne lave projektet udelukkende ved hjælp af PHP. Jeg havde fundet ud af, at det kun var en lille del af Anders og Mikkels projekt, som jeg egentlig havde brug for. De havde nemlig udviklet en funktion i deres program til at håndtere styringen af en SMR ved hjælp af museklik på et billede fra et påmonteret webkamera. Jeg havde en idé om, at det måtte kunne lade sig gøre at konvertere denne del af programmet til PHP, da PHP ikke er så langt fra C/C++. Dette var i sig selv ikke helt forkert tænkt, og implementering af Click and Drive funktionen var da også mulig, men ikke brugbar, da andre problemer hurtigt viste sig. En anden fordel ved PHP er, at det er et server-side sprog, og derfor ville der ikke være nogle sikkerhedsmæssige problemer forbundet med anvendelse, da det hele ville foregå på IAU s servere. Denne fordel viste sig dog også at være en ulempe, da load tiderne på web-siden hurtigt blev fuldkommen uanvendelige. Det viste sig, at problemet lå i for- 27

bindelsen til SMR en. Siden kunne ikke loade færdig, så længe PHP koden stadig havde en åben tcp forbindelse til SMR en. På grund af den måde SMRDEMO fungerer på, var det desværre ikke muligt at åbne og lukke denne forbindelse efter behag, da lukning af denne resulterer i, at SMRDEMO lukker ned og skal genstartes via en kommandopromt. Efter at have fortaget endnu en fejldisposition var det ved at være sidste udkald for at få lavet noget brugbart. Derfor valgte jeg at gå i gang med at udvikle projektet i Java. 5.3 Java Da det nu var klart, at projektet skulle udvikles i Java, var det nødvendigt at få formuleret en klar kravspecifikation. Det kan være en hjælp at bruge UML til dette. Det første skridt i processen var derfor, at udføre de trin som findes beskrevet i ovenstående afsnit. Selve udviklingen foregår som en iterativ proces, da det ikke er muligt at komme på alle de rigtige idéer alene i planlægningsprocessen. Da kravspecifikationen var på plads, indledtes selv kodningen. Selvom Java er det sprog, hvor jeg har størst erfaring, er det stadig begrænset, hvor fortrolig man bliver med et sprog ved at bruge det til 3 projekter. Heldigvis er Java rimeligt intuitivt at bruge, og derfor var mit største problem da også, at koden hurtigt blev lidt rodet. En hurtig opdeling af funktionerne i relevante klasser fik dog sat skik på koden igen. Selve koden er bygget op omkring en while-løkke, der kører indtil programmet stoppes manuelt. Det er lavet som et command-line program, og der er derfor ingen grafisk brugerflade som sådan. 28

I det følgende vil jeg kort beskrive klasserne i programmet. 5.4 WebenableSMR Dette er programmet, som står for styringen af robotten. Det fungerer således, at programmet venter på en forbindelse fra hjemmesiden, hvorfra brugerinput bliver sendt. Dette input bliver så behandlet af programmet, som sender en kørselskommando til SMR en, hvorefter programmet vender tilbage til lyttetilstanden. Programmet er opbygget af 9 klasser til eget brug samt en klasse, som bruges til at forbinde til alarm-programmet. 5.4.1 Main Dette er hovedklassen i programmet. Heri initialiseres alle de nødvendige klasser. Endvidere er det herfra, programmet kører rundt i de forskellige tilstande i programmet. Reelt er der kun to tilstande. Den første hvor der lyttes efter indkomne koordinater, og den anden hvor koordinaterne bliver behandlet. 5.4.2 Init Formålet med denne klasse er, at alle værdierne fra web- Enable.conf -filen bliver hentet ind i programmet. Det er her programmet modtager information omkring kaliberering, højde på webkameraet samt mange andre vigtige konstanter. Uden denne information er det ikke muligt for programmet at fungere korrekt. Derfor er det meget vigtigt, at denne konfigurationsfil bliver kopieret ind i samme bibliotek som programmet, inden det køres. Indholdet af konfigurationsfilen ser ud som vist herunder: ######################################################################### #Her kan indtastes ipadressen paa den robot der oenskes kontakt til. # #Syntax: SMR_ID@'ipadresse' # ######################################################################### SMR_ID@smr5.iau.dtu.dk 29