Projektrapport. Kartläggning- och navigationssystem för robotdammsugare. Farhad Atroshi Emil Falge Gustav Fredriksson Johan Svensson Joel Söderström

Transkript

1 Projektrapport Kartläggning- och navigationssystem för robotdammsugare Farhad Atroshi Emil Falge Gustav Fredriksson Johan Svensson Joel Söderström Projektkurs inom elektroteknik och internetteknik HE1029 9hp Handledare: Ibrahim Orhan Uppdragsgivare/examinator: Svante Granqvist Kungliga Tekniska högskolan Skolan för Teknik och hälsa Handen, Sverige

2 2

3 Sammanfattning Robotdammsugare är en allt vanligare produkt som underlättar vardagen för många människor. Enklare robotdammsugare använder sig endast av en tryckknapp i framkant för att upptäckta objekt och är programmerade med simpla algoritmer. Robotdammsugarna blir allt smartare och de mest utvecklade använder avancerade navigationssystem för att dammsuga snabbare och effektivare. Projektet har gått ut på att ta fram en robot som använder ett egendesignat navigationssystem för att kartlägga ett rum med avseende på väggar och möbler. Kartan skickas sedan till en hemsida där den knyts till en specifik profil och presenteras grafiskt för användaren. Nyckelord: Kartläggning, robotdammsugare, webbserver 3

4 4

5 Abstract Robotic vacuum cleaners are an increasingly common product that makes life easier for many people. Less advanced robotic vacuum cleaners use a single switch in the front to detect objects and are programmed with simple algorithms. However, robotic vacuum cleaners are becoming smarter and the most advanced use complex navigation systems to clean faster and more efficiently. The projects aim has been to develop a robot that uses a self designed navigation system to map a room with respect to walls and furniture. The map is then sent to homepage and tied to a specifik profile were the map is presented graphically for the user. Keywords: Mapping, robotic vacuum cleaner, web server 5

6 6

7 Projektdeltagare Figur 1. Projektdeltagarna. Deltagare Deltagarna i projektet se figur 1. Projektdeltagarna från vänster: Gustav Fredriksson Joel Söderström Emil Falge Farhad Atroshi Johan Svensson Uppdelning av arbetsuppgifter Samtliga medlemmar har haft ansvar för insamling och beskrivning av bakgrundsmaterial. Johan har varit projektledare. Johan, Farhad och Joel har programmerat prototypen. Farhad har programmerat algoritmen för roboten som navigerar i rummet. Emil och Gustav har ansvarat för robotens hårdvara. Samtliga personer har skrivit rapporten medans Johan och Joel haft huvudansvaret. Farhad har ansvarat för programmering samt design av hemsidan. Johan har ansvarat för servern. Farhad har varit ansvarig för tre minuters filmen medans Joel ansvarat för en minuts filmen. Samtliga gruppmedlemmar har varit ansvariga för presentationen. Se figur 2 för mer utförlig information över tidsfördelningen. Alla gruppmedlemmar har läst igenom rapporten och godkänner innehållet. Tidsfördelning över projektet uppdelat för vardera projektmedlem Antal: h Ledning Konstruktion Mjukvaran Webbprogrammering & Design Server Analys av Rapportskrivning Film 1 min & Kretsschema hårdvaran 3 min Presentation Johan Farhad Joel Gustav , , ,5 0 69, Emil Figur 2. Arbetsfördelning 7

8 8

9 Förord Detta projekt är en del av kursen Projektkurs inom elektroteknik och internetteknik som ges vid KTH Haninge. Kursen går ut på att ta fram en problembeskrivning, för att sedan realisera en produkt som avhjälper detta. 9

10 10

11 Innehållsförteckning Sammanfattning...3 Abstract...5 Projektdeltagare...7 Uppdelning av arbetsuppgifter...7 Förord Inledning Problemformulering Målsättning Avgränsningar Teori / metodval Arduino Rover 5 chassi Rover 5 motorsköld Wifi sköld Avståndsmätning PALCE22v10-25PC/PI Raspberry pi Hårdvaruteori Kartläggningsteori Tester av Arduino mjukvara Motorsköld med motorer Pulsmätare Tester av hårdvara Wifi SD-kort Metod Blockdiagram Kretsschema Styralgoritm Hårdvara Mjukvara för kartläggning Servern Hemsidan Resultat Diskussion / analys Slutsats...35 Källförteckning...37 Bilagor...39 Bilaga 1. Tester...39 Bilaga 2. Backupscript...42 Bilaga 3. Kretsschema...43 Bilaga 4. Konceptskiss...44 Bilaga 5. Installation av Git...45 Bilaga 6. Programkod...48 Bilaga 7. Programkod

12 Bilaga Bilaga Bilaga Bilaga Bilaga 8. Programkod Installation/konfiguration av Arch Linux Flödesschema hemsidan Flödesschema robot Teoretisk modell för framtagning av reell sträcka

13 1. Inledning Rapporten beskriver framtagandet av en roboten som projektgruppen har utfört. I detta kapitel formuleras problemet, en målsättning tas fram och avgränsningar för projektet anges. 1.1 Problemformulering Varje bostad behöver underhållas. En av dessa uppgifter är dammsugning. Hur ofta detta bör ske - beror på antalet individer som bor i bostaden. Vanligtvis bör det ske mellan en till fyra gånger per vecka. Med arbetslivets krav och det så kallade livspusslet är det lätt hänt att underhållet av bostaden blir lidande. Bostaden blir dammig, smutsig och den allmänna trivseln påverkas negativt. Möjligheten till avkoppling minskar samt att stressen ökar. Robotdammsugaren hjälper hushållet med städningen av bostaden. Hushållsmedlemmarna avlastas och dammsugaren utför sina arbetsuppgifter då ingen är hemma. Intervall och schema planeras åt dammsugaren som den sedan följer. Företagen har noterat att det finns en efterfrågan för denna typ av produkter; exempelvis har företaget Philips en robotdammsugare vars produktnamn är FC9910/01[1]. Den består av ett runt chassi som innehåller utrustning för att suga upp smuts och damm i en behållare. I robotdammsugaren finns dessutom en kamera, ett gyroskåp och infraröda sensorer. För att navigera sig runt i rummet börjar den med att fotografera innertaket med hjälp av kameran, därefter åker den runt i rummet och finner objekt med de infraröda sensorerna. Sedan använder roboten fotografierna samt informationen från sina infraröda sensorer för att beskriva rummet, samt var i rummet den är placerad. Därefter planerar roboten den effektivaste vägen för att dammsuga golvet. Samsung har en liknande produkt som heter NaviBot Silencio[2]. Även den tar en bild av innertaket för att sedan åka i rummet och finna objekt i rummet och slutligen göra en karta över rummet. Dessa produkter har vissa nackdelar. Gränssnittet för att planera robotens rutiner sköts via en fjärrkontroll, oftast med väldigt många knappar som kan vara förvirrande. En liten display med otydliga felkoder ges, vilket man i sin tur får söka upp meddelandet i manualen. Istället för korta beskrivande felkoder och en hantering av roboten med hjälp av en fjärrkontroll är tanken att projektgruppens produkt kommer att ge tydliga åtgärdsanvisningar för att på ett enklare sätt avhjälpa felet som uppstått. 1.2 Målsättning Målet för projektet var att ta fram en robot, för kartläggning av ett rum med, dessa funktioner: Roboten skall kunna kartlägga ett rum med placering vid en av rummets kanter. Den skall kartlägga samt undvika hinder. Erhållen data lagras på SD-minneskort. Roboten skall vara kopplad till en profilbaserad hemsida för inloggning, där varje kund skapar ett eget konto med ett unikt serienummer för roboten. Hemsidan läser in data från SD-kort och ritar upp en karta av rummet. Efter slutförd uppgift återvänder roboten till utgångspunkten. Raspberry Pi agerar server för hemsidan samt för utvecklingsverktyg. Raspberry Pi kör en backup av viktig data var sjätte timme. Roboten skickar lagrad data trådlöst via Wifi till servern som sedan bearbetar datan. 13

14 Tillägg i mån av möjlighet: Roboten skall kunna kartlägga ett rum oberoende av placeringen. Roboten varnar när batteriet börjar bli lågt. Möjlighet att schemalägga städning på hemsidan. Möjlighet att skicka kommandon till roboten via hemsidan, för städning eller åka till en plats i rummet. 1.3 Avgränsningar Roboten kommer att sakna modulen som gör det möjligt att fånga upp damm och smuts från golvet. Den kommer endast att kunna avsöka ett rätvinkligt rum. Roboten kommer att kunna avsöka rektangulära objekt som är parallella med rummets kanter, dessa skall vara minst 10x10cm. Den kommer inte att kunna åka över mattor eller objekt som har låg friktion, då detta medför att roboten kommer ur kurs. Den skall kunna avsöka rum som har maxdimensionen 3x3 meter. Trösklar får högst vara 20mm höga. Sladdar som ligger lösa skall plockas undan innan användning. Roboten skall inte beröras/distraheras under tiden den avsöker rummet. 14

15 2. Teori / metodval Här beskrivs de komponenter och teorier som projektgruppen har diskuterat, både de som användes samt de som avfärdades. 2.1 Arduino Arduino är en mikrodator som programmeras med ett C-liknande programspråk. Den kan avläsa och skicka analoga samt digital signaler, samt skicka PWM (Pulse Width Modular). Den är modulär och det finns många påbyggnadsprodukter såsom Wifi-sköld, motorsköld till enheten, vilket gör att det är lätt att komma igång och börja programmera en Arduino. Det finns även många bibliotek och funktioner som förenklar anslutning med andra hårdvaror som exempelvis motorer eller en LCD-display. Arduino har 14 digitala portar och 6 analoga portar, alla portar kan konfigureras som ingångar respektive utgångar. Den matas med 5 volt antingen via en USB-kabel eller en likströms adapter, alternativt ett 9 volts batteri, se figur 3. Arduinon är baserad på mikrokontrollern Atmega328. Flash minnet är 32 KB stort. Arduinos egna programmiljö och en inbyggd bootloader på Arduino kortet användes för att skriva, kompilera och programmera all kod. Projektet använde en Arduino Uno för att styra robotens motorer och läsa sensorvärden. Flera andra typer av Arduino kort finns att tillgå och därför kommer benämningen Arduino och inte Arduino uno användas i texten där man syftar på Arduinokortet. Arduino har tagits fram i utbildningssyfte och används för att lära studenter eller intresserade att programmera sensorer och displayer. Konceptet är opensource och community baserat, vilket medför att det finns många forum och guider som beskriver hur man kan använda produkten. Det finns även bra information och dokumentation på Arduinos hemsida[18]. Figur 3. Bild på en Arduino uno [3]. 2.2 Rover 5 chassi Rover 5 är ett chassi där fyra motorer inklusive pulsmätare är anslutna. Det är möjligt att använda antingen larvfötter eller däck för driften. Rover 5 produceras av Dagu electronics och är till för studenter och hobbyprojekt. Chassit är byggt i plast med en vissa metalldetaljer som håller ihop konstruktionen. Rover 5 är utrustad med fyra stycken DC-motorer och varje motor är ansluten till varsitt hjul. Två motorer är monterade på vänster sida och de andra två på höger sida. Varje hjulpar är 15

16 anslutet med ett larvband, se figur 4. Motorernernas max varvtal ligger på 8804 varv/minut[4]. En växel ändrar varvtalet till hjulen med ett förhållande på 87:1 (87 varv från motorn, 1 varv på hjulet) vilket medför att roboten blir långsammare men istället får betydligt större vridmoment till hjulen[5]. Vid varje motor finns det dubbla optiska sensorer som läser hur långt hjulen har roterat, sk. pulsmätare. Pulsmätarna läser av en plan skiva med svart och vitt i vartannat fält som roterar med hjulen. Det går att använda en pulsmätarna för enkel precision eller båda för dubbel precision. Pulsmätarna ger vid dubbel precision 1000 pulser som motsvarar tre rotationer på varje hjul[5]. Figur 4. Bild på en Rover 5 [6]. 2.3 Rover 5 motorsköld För styrning av motorerna används motorkortet ROB-11593, se figur 5. Den är framtagen av företaget Dagu för att specifikt användas med ett rover 5 chassi[7]. Det är möjligt att bestämma riktning, hastighet, mäta strömmen över motorerna samt avläsa värden från pulsmätarna via motorkortet. Motorkortet använder två strömkällor. Varav den ena är från ett Arduino kort på 5 Volt som kopplas in på Vcc, vilket driver motorkortet. Samt en spänningskälla mellan 4,5-12 Volt som driver motorerna. Motorkortets utgång tål 4,5 Ampere till varje motor och skadas om det överskrids. För kontroll av riktning skickas antingen en låg eller en hög digital signal till riktningsporten. För kontroll av hastigheten skickas en PWM (pulse width modulation) signal till PWM-porten på motorkortet, den kan anta värdena 0-255, då noll är ingen hastighet och 255 är max. Strömporten på motorkortet mäter strömmen genom varje motor. Pulsmätarna i rover 5 chassit kopplas in på motorkortets pulsmätaringångar, port A resp B. Pulsmätare A och pulsmätare B är förskjutna med 90 grader. Med hjälp en XOR-grind som finns inbyggd mellan dem finns möjligheten att erhålla dubbla mätvärden, vilket ger dubbelt så hög precision.[8] 16

17 Figur 5. Bild på motorkortet ROB-11593[7] 2.4 Wifi sköld Arduinos Wifi-sköld möjliggör kommunikation med internet via ett trådlöst nätverk. Wifi skölden användes tillsammans med ett Arduino kort. Den kopplas in ovanpå Arduinokortet, med andra ord på samma 14 digitala och 6 analoga pinnar. De fyra pinnarna MISO, MOSI, SCK och SS används för att kommunicera seriellt mellan enheterna, se figur 6[14]. MISO pinnen står för master in slave out och skickar data från Wifi skölden till Arduino kortet. MOSI står för master out slave in och skickar data från Arduino kortet till Wifi skölden. SCK står för serial clock och används för att synkronisera signalerna mellan enheterna. SS står för slave select och används för att välja till vilken enhet som datan ska skrivas, i detta fall Wifi eller minneskortet. Wifi skölden stöder krypteringstyperna WEP och WPA2. Wifi skölden användes för att upprätta kommunikation mellan roboten och webservern, primärt för att skicka en beskrivning av ett rum. Figur 6. Arduino Wifi sköld[15]. 2.5 Avståndsmätning Tre ultraljudssensorer av typen HC-SR04[9], se figur 7, användes för mätning av avstånd. Sensorerna har en räckvidd på 2-400cm med en felmarginal på 0,3 cm. Ultraljudssensorerna kopplades in via VCC och GND till Arduino-kortet. Ultraljudssensorn har en sensor som skickar ut ultraljud och en som tar emot signalen. Två pinnar behövs för anslutning, trig och echo, dessa var kopplade till Arduino-kortets portar. Ultraljudssensorn skickar ut åtta ultraljudspulser på trig-pinnen vilket tar tio mikrosekunder. Ultraljudspulserna studsar på objekt och reflekteras sedan tillbaks till mottagarsensorn. Echopinnen detekterar pulserna och får ett tidsbaserat mätvärde som resultat. Detta mätvärde divideras med 58 för att erhålla avståndet i centimeter[9]. Detekterandet av ultrajudspulserna tar mellan 150µs och 25ms beroende på avståndet, och 38ms ifall inget objekt finns inom ultraljudssensorns räckvidd. Speciellt då tester visade att ultraljudssensorerna ibland får felaktiga värden och måste mäta om avståndet(se bilaga 1 Tester av ultraljudssensorer ). 17

18 Andra alternativ för avståndsmätning är IR[10] och laser[11]. Laser är en högprecisionsmetod med lång räckvidd när det gäller avståndsmätning. Laser för avståndsmätning ansågs dock för komplicerat och dyrt för projekts budget och uteslöts därför. IR för avståndsmätning har en hög precision men ansågs ha för kort räckvidd relativt till priset och uteslöts därför. Ultraljudssensorer var prisvärda och har en acceptabel precision samt räckvidd. Figur 7. HC-SR04 [9] 2.6 PALCE22v10-25PC/PI PALCE-kretsen är en mikroprocessor som programmeras med programspråket VHDL. Kretsen programmerades med uppgift att agera avkodare till ultraljudssensorerna. PALCE-kretsen har 24 portar, variabelt mellan 22 stycken ingångar samt 10 utgångar, se figur 8. Valet av denna krets var för att KTH bistod med dessa samt att projektdeltagarna hade erfarenhet av att programmera denna krets. PALCE-kretsen är framtagen av företaget Cypress [12]. Figur 8. PALCE22v10-25PC/PI [13]. 2.7 Raspberry pi Raspberry Pi är en enkortsdator som är i storleksordningen stor som ett kreditkort, enkortsdatorn är en produkt för den som vill lära sig hårdvara och mjukvara[16]. Det finns ett flertal GNU/Linux distributioner som kan installeras på denna, det går även att installera en unixdialekt som är FreeBSD. Ett operativsystem har många fördelar, två av dessa är att man får tillgång till många programmeringsmiljöer, samt att man kan installera tjänster, såsom webserver eller databas-server. Modellen av Raspberry pi som användes var model B, den har 512 MB ram, två USB portar, en 100mb ethernet port, en HDMI-kontakt samt en analog ljudutgång[17], se figur 9. 18

19 Figur 9. Bild av Raspberry pi[17]. 2.8 Hårdvaruteori Det fanns två alternativ för val av chassi, antingen bygger man det själv med hjälp av meccano, vilket är en byggsats som består av metalldelar, likt lego. Eller inhandla en redan färdig produkt med tillhörande motorer och larvband. Det första alternativet fanns möjligheten att justera chassit under projektets gång, exempelvis om roboten skulle färdas snett kunde detta justeras, dock skulle byggandet vara tidskrävande. Det andra alternativet valdes just för att få en hög precision på mätningen av hjulrotationer, vilket skulle ge en hög noggranhet på färden. Att roboten åkte rakt var kritiskt för kartläggningen av rummet. Vardera projektmedlem tog fram en konceptskiss för utseendet av roboten, därefter övervägdes fördelar och nackdelar med varje skiss. Den modell som projektet gick vidare med syns i bilaga 4. Denna skiss låg sedan till grund för prototypen som skulle konstrueras. Konstruktionen utrustades med larvfötter, tre ultraljudssensorer, en Wifi-sköld samt ett motorkort. 2.9 Kartläggningsteori Det togs fram två teorier om tillvägagångssätt för kartläggning av ett rum. Den ena var att roboten åker ut till olika platser i rummet, stannar och låter en svepande avståndmätare mäta avståndet till ett stort antal punkter 360 grader runtom roboten. Roboten åker sedan framåt en bit och upprepar mätningen. Med avancerade algoritmer går det sedan skapa en bild av rummet, baserat på mätvärden till objekten runtomkring roboten. Med den andra metoden åker roboten först runt kanten av rummet för att sedan åka in i rummet och kartlägga objekt där. Det sistnämnda alternativet valdes, detta för att alternativ 1 ansågs allt för svårt att genomföra Tester av Arduino mjukvara En programvara togs fram för att testa ultraljudssensorerna, PALCE kretsen, Wifi skölden och motorskölden med motorerna för att undersöka dess egenskaper. När avkodaren(en VHDL programmerad PALCE krets, se bilaga 12, kopplas in fungerade inte avläsningen av ultraljudssensorerna som förväntat, ultraljudssensorerna returnerar felaktiga värden. Ett testprogram skrevs för att se om avkodaren och Arduinon kommunicerar och fungerar korrekt. Problemet visade sig vara att avkodaren var ansluten på fel portar på Arduinon Motorsköld med motorer För mätning av distansen som roboten färdats användes pulsmätarna, dessa är inbyggda i varje hjul. Det visade att det gav opålitliga mätvärden, att ibland blev det fler och ibland färre. En resistor kopplades in mellan pulsmätaren och Arduinon, samt att jordanslutningen till 19

20 sensorerna kopplades in, dock ingen förändring. Att använda avbrott i programkoden istället för att ständigt avläsa om pulsmätarna förändrats gav förväntat resultat, se bilaga 1. Båda sidorna matades med samma hastighet från motorkortet, detta medförde att roboten färdades något åt höger. Att lätta på de spända banden gav samma resultat. Då Arduinon räknade antalet förändringar från pulsmätarna kunde man med hjälp av dessa få roboten att anpassa farten på respektive sida, det medförde att roboten åkte rakare. Ett test för mätning av spänningen mellan hjulparen på vänster samt högersida visade att skillnaden var ungefär 0.4 volt, se bilaga 1. Dagen efter utfördes samma test igen och resultatet blev då annorlunda. Förhållandet mellan vänster och höger hjulpar hade förändrats vilket resulterade i att förhållandet som tagits fram i programkoden nu även blev tvungen att förändras. Figur 9 och 10 visar förhållandet Pulsmätare Det antogs Arduinon inte hinner att hantera alla avbrott som pulsmätarna genererar när man använder dubbla precisionen, och att det kunde varit det som medfört att roboten åkte märkbart åt höger. Ett test utfördes som gick till så att motorerna startades och roboten körde i en sekund. Därefter nollställdes räknarna och den vänstra pulsmätarens avbrott räknades, mätdata skrevs till konsolen i 120 millisekunder. Räknarna nollställdes, därefter räknades pulsmätaren på den högra sidan, även den kördes i 120 millisekunder. Efter det nollställdes räknarna. Båda pulsmätarna räknades och motorerna kördes i 120 millisekunder. Detta gjordes i två hastigheter, första hastigheten var 50 PWM, som visas i figur 10, den andra hastigheten kördes i 250 PWM, se figur 11. Figur 10. Diagram över pulsmätare(normal noggranhet) med hastigheten 50 PWM. X-axeln anger tiden i sekunder och y-axeln anger antalet pulser ifrån pulsmätarna. 20

21 Figur 11. Diagram över pulsmätare(dubbel noggranhet) med hastigheten 250 PWM.X-axeln anger tiden i sekunder och y-axeln anger antalet pulser ifrån pulsmätarna. Pulsmätare/tid diagrammen visar att det är ett linjärt förhållande mellan vänster och höger sidan. Denna information utnyttjades i styralgoritmen som korrigerar robotens kurs Tester av hårdvara En programkod skrevs för att få roboten att rotera vänster eller höger, se bilaga 1. Med hjälp av värdet från pulsmätarna skulle roboten få en exakt rotation. En 90 graders rotering åt höger resulterade i att pulsmätarnas värden var 583 och felmarginalen blev mindre än fem procent. För en vänstersväng 90 grader visade pulsmätarna ett värde på 275. Om förhållandet mellan gradtal och rotation förändras, medför det att roboten istället svänger mer än 90 grader. Slutsatsen blev att roboten fick svänga mer eller mindre än 90 grader och att roboten sedan fick korrigera svängningen när den fortsatte köra framåt. Ett problem som uppstod under tester var att roboten ibland körde rakt in i väggen innan den svängde, se bilaga 1, Testkörning av kartläggning. Det visade sig att funktionen som läser in pulserna (pulsein) väntar på en signal från ultraljudssensorn i maximalt en sekund. Detta medförde att om samtliga tre sensorerna inte får något värde, så färdades roboten i tre sekunder utan någon kontroll. PulseIn funktionen modiferades till en timeout på 30 millisekunder, den tidsperioden var mer än tillräcklig för att kunna avläsa ett avstånd på tre meter. Dessa filer modiferades med dessa inställningar:./hardware/arduino/cores/robot/arduino.h:unsigned long pulsein(uint8_t pin, uint8_t state, unsigned long timeout = 30000L);./hardware/arduino/cores/arduino/Arduino.h:unsigned long pulsein(uint8_t pin, uint8_t state, unsigned long timeout = 30000L); För att få en roboten att hinna utföra manövrar under färden sattes programmets looptid till 200 millisekunder. Roboten färdades då lagom långt för att hinna korrigera sin kurs samtidigt som samtliga ultraljudssensorer hann avläsas. Det resulterade i att roboten inte väntade länge på en timeout från pulsein funktionen, se bilaga 8. Ett stort problem var att få roboten att färdas rakt längs en linje, se bilaga 1. Vid mätning av pulsmätarna visade det sig att det fanns ett linjärt förhållande mellan vänster och höger 21

22 hjulpar, se figur 10 samt figur 11. Dock förändrades förhållandet så fort att underlagets friktion förändrades eller om något av hjulparets hastighet minskade eller ökades. Som konsekvens av detta blev det svårt att förutsäga vilken hastighet som gav en rak färd framåt. För att balansera motorhastigheterna på motorerna skapades ett program, detta för att få jämn kraft på vänster och höger sida, se bilaga 6. Pulsmätarna används dels för att korrigera så att roboten navigerar sig rakt fram, samt att mäta antalet hjulrotationer som sedan kommer att beräkna sträckan. Trots test av diverse olika justerings algoritmer färdades roboten något åt höger. Man tog ut data från algoritmen ovan för att sedan producera grafer över pulsmätarnas värden och förhållandet mellan motorernas hastigheter. Det togs fram en medelhastighet över respektive sida, vänstersidan var 94 och högersidan var 176. Pulsmätningen repeterades tre gånger, och för vardera gång justerade man hastighetsförhållandet i programkoden. Sammanfattningsvis fick man ett medelvärde på vardera sida, vänster blev 96 och högersidan blev 170. Roboten fortsatte att färdas något åt höger. Ett nytt test gjordes då man ökade samt minskade pulsmätarnas räknarna. Efter tester visade sig att om man minskade den vänstra räknaren efter varje loop minskade problemet med att roboten drog åt höger, se bilaga 7). För att ta reda på den sträcka som roboten färdats byggdes en funktion som beräknar hur långt robote åkt med avseende på rotationer från pulsmätarna samt däckets omkrets. Testerna gick ut på att man anger en distans som roboten ska färdas och därefter används en linjal för att mäta sträckan. I figur 12 och figur 13 kan man utläsa att avståndsmätningarna inte är linjära, vilket medföra stora problem när roboten färdas en exakt sträcka. Ett däck roterades 360 grader för att ta reda på hur många utslag som pulsmätaren känner av, resultatet blev 280 stycken. Då man angivit detta i programkoden istället för databladets angivelse på 333,3 stycken fick man noggrannare distanser. Figur 14 är ett diagram efter att man förändrat funktionen efter de nya värdena. Matas ett värde in, vilket är beskrivet på x-axeln åker man exakt den distansen som är beskriven på y-axeln. 22

23 Figur 12. Mätning av distans för angiven sträcka(x-led) och färdad sträcka (y-led). Figur 13. Mätning av distans för angiven sträcka(x-led) och färdad sträcka (y-led). 23

24 Figur 14. Mätning av distans för angiven sträcka(x-led) och färdad sträcka (y-led) Wifi Wifi skölden placerades ovanpå Arduinon och en exempelkod från Arduinos biblotek laddades in. Den anslöts mot ett WPA2 nätverk och anslutning mot en webserver för att presentera en hemsida lyckades SD-kort SD-kortläsaren är inbyggd i Wifi skölden, en exempelkod programmerade Arduinon. Tester gjordes för att läsa och skriva data till minneskortet, med lyckade resultat. 24

25 3. Metod I detta kapitel beskrivs hur robotens delar byggdes ihop till en helhet och hur komponenterna samverkar. Även slutgiltiga algoritmer och programkoder beskrivs. För att ta del av källkod av programvaran kontakta projektgruppen. 3.1 Blockdiagram Figur 15. Blockdiagram över robotens komponenter med dess flöden. En Arduino Uno med tillhörande komponenter har byggts ihop till en robot som kan navigera runt ett rum längst höger vägg. Roboten sparar information om rummets väggar samt om objekt i rummet. Roboten skickar sedan informationen till hemsidan där användaren ser bilder av rummen. Arduino Uno har anslutits till ett motorkort för styrning av motorer samt inläsning av pulsmätardata. En PALCE krets används för att styra trig-portarna på ultraljudssensorerna, echo portarna är anslutna till Arduinon. Wifi skölden ansluts och skickar data till hemsidan, se figur

26 3.2 Kretsschema Kretsschemat för roboten visas i bilaga 3. Tre ultraljudssensorer anslöts till Arduinokortet. En PALCE-krets med två ingångar kopplade till Arduinon och tre utgångar kopplade till trigpinnarna på ultraljudssensorerna. Wifi-skölden är inkopplad ovanpå Arduino-kortet och dessa delar ansluter samtliga digitala och analoga pinnar. Wifi-skölden nyttjade sex portar och resterande portar var tillgängliga för de andra enheterna. Motorskölden strömförsörjs separat med ett 9 volts batteri, den är sedan ansluten till två motorer och två pulsmätare. Motorskölden är ansluten till Arduinon för styrning av motorer och inläsning av data från pulsmätarna. 3.3 Styralgoritm Då roboten hade problem med att färdas rakt fram så användes högra väggen som stöd. Roboten jämför två avläsningar, om det första avståndet är längre än det andra så svänger roboten något åt vänster för att åka ut ifrån väggen. Är det första avståndet kortare än det andra så svänger roboten något åt höger för att åka in mot väggen, och om avståndet är detsamma åker roboten framåt. Då roboten kommer åka slalom i små svängar färdas den längre än högerkantens längd. Den reella sträckan kommer att skilja sig från den uppmätta sträckan. Vid tester var felmarginalen 12 procent på tre meter, vilket ansågs som en godtagbar felmarginal. När roboten inte kan utläsa en vägg till höger stannar den upp, därefter åker den cirka 30 centimeter framåt, såvida det inte finns en vägg framför. Efter det svänger den till höger för att sedan åka cirka 30 centimeter framåt, sålänge det inte finns ett objekt framför. Därefter avsöks högersidan efter en vägg, och färden framåt längs med högerkanten fortgår. När roboten har åkt runt ett varv och vektorerna i x samt y-led har cancellerat ut varandra hittar den origo och stannar färden, felmarginalen för origo är +-40 centimeter på x och y-led, se bilaga Hårdvara Ovanpå rover 5 chassit skruvades en träplatta fast, på vilken samtliga kretskort och sensorer placerades, se figur 16. Roboten utrustades med tre ultraljudssensorer, en framåt, en till vänster och en till höger. Ultraljudssensorerna kopplades via PALCE-kretsen till Arduino Uno kortet. Wifi skölden kopplades in ovanpå Arduino Uno kortet och användes för att spara data på ett SD-kort samt skicka datan till hemsidan via Wifi. Arduino Uno kortet strömförsörjdes med 5 volt av ett 9 volts batteri via en inbyggd spänningsregulator. Motorerna i rover 5 chassit parallellkopplades till motorkortet så att höger- respektive vänster hjulpar drevs via samma portar. Pulsmätarna kopplades även in till motorkortet. Motorkortet strömförsörjdes separat via ett 9 volts batteri och styrpinnar och styrspänning kopplades till Arduino Uno kortet. Kretsschemat låg till grund för kopplingen av respektive kablar. Samtliga sladdar mellan komponenterna löddes fast och kopplades via ett protoboard kort. Krympslang användes på alla förgreningar samt ändar för att minska risken för att olika sladdar vidrörde varandra och det eliminerade eventuella kortslutningar. Ett chassi med tillhörande tak färdigställdes, detta för att skydda robotens känsliga elektroniska utrustning. 26

27 Figur 16. Prototyp av roboten. 3.5 Mjukvara för kartläggning Det första roboten gör när den sätts ner i ett nytt rum är att rita upp randen av rummet. Detta gör den genom att följa rummets kant längs högervarv. Programmet innehåller en variabel kallad orientation. Denna variabel kan anta värdena 0,1,2 eller 3 beroende på vilken geografisk riktning roboten har. Logiken är samma som i en kompass. Där 0 motsvarar öster, 1 motsvarar norr, 2 motsvarar väster och 3 motsvarar söder sett ifrån ett x-och y-leds perspektiv, se figur 17. Är roboten placerad med vänster sida mot väggen vänder den sig så att den står med högersidan mot väggen. Den kör sedan framåt och kompenserar så att den håller sig på ett avstånd av 20 cm ifrån väggen. När den detekterar nästa vägg svänger den vänster och ändrar variabeln orientation. Ifall att avsåndet till höger överstiger 50 cm tyder detta på att rummet svänger 90 grader åt detta håll, roboten svänger då 90 grader åt höger och kör 40 cm framåt för att ha rummets kant på sin högersida. Den ändrar sedan variabeln orientation och fortsätter rakt fram. Varje gång roboten svänger mäter den antalet förändringar som pulsmätarna har registrerat och kallar på en funktion som beräknar avståndet som roboten har kört. Den skapar sedan en vektor av detta avstånd beroende på vad orientation har för värde. Är tillexempel orientation = 3 har roboten kört nedåt på y-axeln, vektorn kommer då att bli [0,-(kört avstånd),0] där ordningen är [x-led,y-led,objektsid]. Den återställer sedan räknarna som registrerar antalet förändringar och svänger, samt ändrar orientation variabeln beroende på vilket håll den har svängt och vilket värde orientation har. Se bilaga 11 för flödesschemat som tagits fram. 27

28 Figur 17. Princip för variabeln orientation 3.6 Servern Arch linux installerades och konfigurerades på Raspberry pi, se bilaga 9. Servern konfigurerades med en statisk ip-adress, detta för att servern alltid skulle ha samma ip-adress. Därefter skapades en portöppning i brandväggen på port 22 samt port 80 till servern. En konfigurationsändring i sshd_config gjordes att det endast gick att logga in med ssh nycklar, dvs inga lösenord tilläts för inloggning. För att minska attacker mot ssh porten konfigurerades iptables så att en ipadress endast kunde göra fem anslutningar på 60 sekunder. Därefter initierades ett repository och en guide skapades för konfiguration av git klienten, se bilaga 5. I figur 18 visas ett nätverksdiagram över dessa funktioner. Backup av viktig data konfigurerades (se bilaga 2). 28

29 Figur 18. Nätverksdiagram med servern, dess användning samt backup Hemsidan För produktionen av hemsidan gjordes ett flödesschema, se bilaga 10, för att beskriva hur användaren kan interagera med hemsidan, samt hur Arduino kan skicka rumsbeskrivningar. Innan hemsidan skapades togs en skiss fram för innehåll, fontstorlekar, formulärfält, bilder samt typsnitt. En hemsida producerades, där användaren får valet att antingen logga in som befintlig kund eller registrera en ny kund och i samband med det skapa en kundprofil. Om en befintlig kund loggar in med rätt användarnamn samt lösenord omdirigeras denne till profilsidan, om fel användarnamn eller fel lösenord anges kommer ett felmeddelande. Om en ny kundprofil skapas, jämförs användarnamn, epost samt serienyckel med befintliga uppgifter i en databas. Är användaren unik skapas ett konto, men om något som ej är unikt presenteras ett felmeddelande till kunden och som får korrigera sina uppgifter. Efter skapandet av en ny profil omdirigers användaren till profilsida där valet finns att ladda upp egna filer med innehållande kartor som roboten har skapat. Finns det en textfil i kundens hembibliotek läses denna in och en bild produceras utifrån de angivna värdena i filen, se figur

30 Figur 19. en användarprofil på hemsidan 30

31 4. Resultat Alla mål enligt kravspecifikationen uppfylldes. Roboten färdades i rummet och åkte längst med högersidan för att kartlägga rummet, den upptäckte objekt med hjälp av ultraljudssensorn på vänstra sidan, samt att den undvek hinder. Efter slutförd rutt sparar roboten kartan på SD-kortet samt skickar den till servern om Wifi finns. Hemsidan läser in data från filer som innehållet vektorer från Arduinon, dessa ritas med hjälp av PHP, dock är skapandet av bilden väldigt cpu intensiv vilket ledde till att man placerade bildbehandlingen på en annan server. När Arduinon har skickat data över rummet kan en oprocessad bild se ut enligt figur 20. Då det är en viss felmarginal i distansen kommer rummets kanter inte alltid vara ihopsatta. Efter att rummet processats med hjälp av PHP kommer den att presenteras som figur 21. Figur 20. Data hämtad direkt från SD-kortet. Figur 21. Data presenterad till användaren efter att den processats via hemsidan. 31

32 32

33 5. Diskussion / analys Den viktigaste lärdomen som projektmedlemmarna drog är att man inte ska lita på att hårdvaran beter sig optimalt och som förväntat. Som det har nämnts hade gruppen stora problem med att robotens motorer gick olika fort varför roboten drog snett, se bland annat bilaga 1 Justering av sned körning. I projektets början stod som bekant valet mellan att köpa en färdig hårdvara eller konstruera en egen. Med en färdig hårdvara antogs sned körning och dyligt minimeras, vilket skulle ge mer tid till programmeringen. Detta antagande har visat sig vara felaktigt, och möjligheten finns att projektet hade kommit längre ifall man hade valt en annan teori och design för hårdvaran. I efterhand ska det erkännas att tillräckligt mycket tid inte lades ned på faktainsamling och att ta fram en ordentlig teoretisk modell för hårdvaran. Försök att få roboten att åka rakt och justera sin kurs tog mycket tid och energi. Vilket lämnade mindre tid åt det slutgiltiga programmet och kartläggningsalgoritmen. Arbetsstrukturen och sättet att hantera programmeringen var inte heller optimal. En person i taget jobbade med hela programmet istället för att det styckades upp i modulära funktioner så att flera personer kunde programmera samtidigt. Problem med att roboten drog snett och inte mätte kört avstånd korrekt togs inte tag i. Problemen sköts upp och slog sedan tillbaks mot projektet. På grund av dessa problem och tidsbristen drogs kraven på roboten ner, rummets maxdimensioner minskades från 5x5m till 3x3m så att roboten inte behövde köra tvärs igenom rummet. Det ska dock understrykas att problemet löstes, och med mer tid och bättre hårdvara kan roboten fortfarande utvecklas mycket. Framtagna teorier för kartläggning och navigering visade sig vara praktiskt användbara och fungerade bra när de implementerades i programmet. Ett problem som kvarstår uppkom i anslutning till att roboten inte körde rakt. Problemet är att roboten inte mäter det avstånd den har kört korrekt. En förutsättning var att roboten körde rakt så att avståndet den har kört kunde användas för att få väggens längd. I nuläget kör roboten sicksack och avståndet den mäter blir längre än den effektiva sträckan som den har förflyttat sig. Om mer tid hade stått till förfogande var planen att en algoritm för att ta fram den exakta distans skulle programmerats, se bilaga

34 34

35 6. Slutsats Projektgruppen konstruerade en autonom robot som använder väggarna som referens kan kartlägga ett rum med maxdiametern 3x3 m. Roboten skickar via ett trådlöst nätverk informationen till en webbserver där en karta renderas och knyts till en specifik användarprofil. Uppgiften visade sig vara svårare än förväntat och stora problem med den inköpta hårdvarumodulen ledde till förseningar och uppkomsten av ytterligare problem som behövde lösas. Robotens basala funktioner och krav uppfylldes och hela produkten är ett fristående system med hårdvara, navigationssystem och webbserver för processande av data. Pga. den ökade problematiken som beskrivits tidigare kvarstår vissa funktioner som kan läggas till det färdiga robotpaketet. Dessa funktioner är: Kartläggning av rum oberoende av placering Spänningsmätning för batterier Schemaläggning av robotens körning Möjlighet att skicka kommandon ifrån webbserver till roboten I sitt nuvarande program kartlägger roboten rummets mitt medans den kör längs kanten. Detta pga. att robotmodulens motorer hade för låg precision för att roboten ska köra acceptabelt rakt utan korrigeringar. En stor utvecklingsmöjlighet för produkten är att ta fram en robot som även kör igenom rummet och inte korrigerar sig efter kanten. Troligtvis behövs en annan hårdvarumodul med högre precision för att uppnå detta. 35

36 36

37 Källförteckning [1] Phillips Produktsida robotdammsugare FC9910/01 Besökt [2] Samsung Produktsida robotdammsugare NaviBot silencio Besökt [3] Arduino Bild av Arduino Uno Besökt [4] Teco Electric Datablad DC-motorer Besökt [5] Sparkfun Rover 5 infoblad Besökt [6] Lawicel webbshop Bild av Rover 5 r= Besökt [7] Sparkfun Rover 5 motorsköld Besökt [8] Sparkfun Beskrivning av motorsköld %20manual.pdf Besökt [9] Cytron Technologies Användarmanual Ultraljudssensor HC-SR04 Besökt [10] Sharp Datablad IR-sensor GP2Y0A21YK0F Besökt [11] Elfa Produktsida laserdiod LCU98B041A

38 726-27&toc=0&q=laser+avst%C3%A5ndsm%C3%A4tare Besökt [12] Lattice Datablad PALCE22V10 atasheet.pdf Besökt [13] YDXK Bild PALCE22V10 Besökt [14] Arduino Beskrivning av SPI Besökt [15] Arduino Beskrivning av wifi-sköld Besökt [16] Raspberry pi Beskrivning av raspberry pi Besökt [17] Raspberry pi Beskrivning av raspberry pi model B Besökt [18] Arduino Arduinokortet Besökt

39 Bilagor Bilaga 1. Tester Tester av ultraljudssensorer den 14/ En ultraljudssensor riktas ifrån ett rum utåt i en korridor som är längre än 4m(ultraljudssensorns maxräckvidd), avståndet skrivs till en textfil på ett minneskort. Dock visar den på ett avstånd av ca 2m. Utomhusmätningar med avstånd över 4 meter ger konstiga resultat, bland annat negativa tal. När avståndet överstiger 4m, och även när det håller sig inom räckvidden på cm, blir värdena antingen negativa eller 0, möjligtvis pga. Ultraljudsensorerna ger även mätvärden utanför spektrat då objektet de mäter på flyttas mot eller bort ifrån ultrajudssensorn. En ultraljudssensor sattes upp för att mäta avståndet till en burk som stod på en linjal. Ultraljudssensors värde mättes en gång i sekunden och burken flyttades successivt närmare ultraljudssensorn med kortare uppehåll vid 70,60,50 resp. 40 cm, se tabell 1. Linjal(cm) Ultraljudssensor(cm) Tabell 1. Mätvärden, se beskrivning ovan. Första testet med Rover 5 den 14/ En enkel kod skrevs för att testa roboten och låta den åka rakt fram. Problemet som genast uppkom var att motorerna snurrade åt olika håll på varje sida och kämpade mot varandra. För att lösa problemet satte gruppen in en NOT-grind, en krets som inverterar en digital signal. På det viset så kunde arduinon med en ensam port skicka en hög och en låg signal till samma sida på roboten. Det löste problemet och roboten kunde ta sina första rull på golvet. Problem med programmering av arduino den 16/ När kod försöker skrivas till arduinon fås felmeddelandet avrdude: stk500_getsync(): not in sync: resp=0x00. Kod ifrån ett gammalt program, där trig hade pinne 5 och echo pinne 4, går dock att skriva över. I det nya programmet har trig pinne 5 och eho pinne 0. När pinnarna är 39

40 inkopplade så går det varken den nya eller gamla koden att programmeras över. När trig flyttas till pinne 3 och echo till pinne 2 går det att skriva över kod till programmet. Slutsats: Pinne 0 får inte vara inkopplad då kod skrivs till arduinon. Test av pulsmätare den 16/ Testet började med att använda dubbla precisionen med en låg hastighet (PWM på 50). Det gav dåliga resultat och varierade hela tiden. Gruppen provade med att koppla in en resistor mellan arduino:n och motorkortets utgång för de optiska sensorerna, ingen skillnad sen innan. Istället för den dubbla precisionen användes nu enkel precision, lite bättre men inte så pass att det går att använda. Efter det ändrades koden att använda ett avbrott varje gång signalen ändrades, fungerade mycket bättre. Avståndsmätningen gav ungefär samma resultat med olika hastigheter och kördes 300 pulser på enkel precision: hastighet 50=35cm, hastighet 100=37cm, hastighet 255=39cm. Stoppsträckan vart lite längre med snabbare hastighet. Justering av sned körning den 23/ Roboten går snett och motorerna drar ojämnt när motorstyrkortet får samma PWM skriven till sig via en arduino. Larvband och drivhus justeras så gott det går för att få roboten att gå rakare. Roboten går efter detta rakare men drar fortfarande allt för mycket åt höger. I programmet lades en funktion till där arduinon justerar PWM som skickas till motorstyrkortet beroende på hur många pulser vänster resp. höger pulsmätare har registrerat. Har ett hjulpar gått kortare än det andra så ökas PWM på det hjulparet i en halv sekund. Med hjälp av denna kod går roboten betydligt rakare. Felet kan antas ligga i att motorerna inte får samma spänning av motorstyrkortet. Det första antagandet visar sig stämma då spänningen över båda hjulparen mäts vid samma PWM. Spänningsskillnaden är ~0,4 volt. Antalet pulser ifrån pulsmätarna som roboten ska ha mätt innan den slutar att rotera justeras för att komma så nära 90 grader som möjligt. Roboten sätts på ett papper där två linjer har dragets i 90 grader vinkel mot varandra. Diverse olika värden på pulsmätarna testas, till slut kommer gruppen fram till att 583 verkar ge det bästa värdet. Då svänger roboten nästan exakt 90 grader och felmarginalerna är små. Vid ett senare testtillfälle svänger inte roboten längre nästan exakt 90 grader med pulsmätarvärdet 583. Problemet antas ligga i att pulsmätarna är väldigt känsliga och att antalet uppmätta pulser varierar ifrån körning till körning. Ytterligare justeringar av sned körning den 25/ Hela dagen(8h) har lagts på att försöka få roboten att åka så rakt som möjligt. Trots test av diverse olika justeringsalgoritmer så drar roboten alltid lite snett, oftast åt höger. Examinatorn Svante tror att justeringsalgoritmen så bra som det går att få den, och att kvarvarande problem handlar om ojämna ytor, ojämn friktion som ligger utanför justeringsalgoritmens kontroll. Diverse grafer över pulsmätarnas värden och förhållandet mellan motorernas hastigheter har tagits fram, och utifrån det ser koden ut att fungera bra. Justeringar av 90 graders rotationer den 30/ Ett första program för att få roboten att köra runt randen av ett rum har skrivits, utan att roboten sparar vektorer. Det mesta funkar bra förutom att roboten inte svänger 90 grader funktionen för att svänga 90 grader. Konstanten som anger antalet förändringar pulsmätarna ska ha registrerat måste justeras. Detta görs och värdena registreras i en tabell. Underlaget är ett A3 papper och endast en halverad precision används för pulsmätarna, se tabell 2. 40

41 Variabel(impulser) Vänstersväng(grader) 350 ca Tabell 2. Testvärden för pulsmätarkonstant Högersväng(grader) ca Testkörning av kartläggning den 30/ Ett enkelt testrum på ca 2-3 kvadratmeter byggs av liggande bord. Ett första utkast till ett kartritningsprogram användes för att låta roboten köra runt rummets kanter. Roboten kör ibland in i väggen framför. Avståndet framåt måste kollas oftare, eller ha större marginal. Roboten kompenserar även för lite i förhållande till väggen till höger, och försökte hålla för långt avstånd till kanten. Ändringar gjordes så att marginalen till kanten var cm istället för cm. Fördröjningar i kompensationen drogs ned och förhållandet mellan motorhastigheterna ökades istället. Efter ovanstående ändringar kör roboten bättre, men kompensationen är fortfarande undermålig och roboten klarar inte av att följa kanten. Avståndet ändras till 5-15 cm och tiden som roboten vidhåller motorskillnaden ökas med 100 ms. Roboten justerar nu för snävt, en dynamisk funktion som justerar hastighetsförhållandet beroende på hur långt roboten har till kanten antas behövas. En sådan dynamisk funktion skrivs, roboten kompenserar med den dynamiska funktionen bra när den hamnar för långt ut men för svagt när den hamnar för nära väggen. Parametrarna ändras så att roboten har högre PWM skillnad mellan motorerna när den ska kompensera utåt ifrån väggen. Ökade parametrar ger inte önskat resultat. Kartläggning längs rummets rand den 30/ En funktion för att skapa vektorer har gjort, funktionen fungerar bra och vektorerna har testritats på servern. Det största problemet som kvarstår är att roboten har problem med att hålla avståndet till kanten, den beter sig allmänt underligt och svänger upprepade gånger in i kanten. Den komplicerade if/else satsen skrivs om till en switch sats och parametrarna justeras. Kantmarginalen ändras till 8-12 cm. Tiden ökas ifrån 200 till 750ms, roboten drar oberoende av detta in till kanten. I ett test minskas även PWM på vänster motor istället för att bara öka PWM på höger motor. 41

42 Bilaga 2. Backupscript ~]# crontab -l #minute hour dayofmonth month dayofweek * */6 * * * /opt/scripts/mainbackup.sh > /dev/null 2>&1 Filnamn: mainbackup.sh #!/bin/bash #skapa en tmp dir mkdir -p /opt/scripts/backup/tmp/ ######################################### #VARIABLER export DEST=/opt/scripts/backup/tmp/ DATE=$(date +%Y_%m_%d_%H) BACKUPFILE=$DEST/../backup_$DATE.gz DESTHOST=exclude.se@ssh.exclude.se:./backup SCRIPTS=/opt/scripts/backup/ BACKUPFILE=$SCRIPTS/backup_$DATE.gz ######################################### #loopa igenom alla script och kör dem for i in $(ls $SCRIPTS/backup_*.sh) do $i done #packa ned allt till en tar.gz fil och skicka till en backupdestination tar -czf $BACKUPFILE $DEST scp $BACKUPFILE $DESTHOST rm -rf $DEST rm -f $BACKUPFILE Filnamn: backup_git.sh #!/bin/bash SRC=/srv/git/ echo copying from $SRC to $DEST cp -rp $SRC $DEST Filnamn: backup_http.sh #!/bin/bash SRC=/srv/http echo copying from $SRC to $DEST cp -rp $SRC $DEST Filnamn: backup_http.sh #!/bin/bash USERNAME=dummy PASSWORD=dummy echo mysqldumping all databases to $DEST mysqldump --all-databases > $DEST/mysql_backup.sql 42

43 Bilaga 3. Kretsschema Figur: Kretsschema över robotdammsugaren. 43

44 Bilaga 4. Konceptskiss Figur: Konceptskiss av roboten. 44

45 Bilaga 5. Installation av Git Gå in på denna länk: Klicka här: Spara filen: Svara Run: Välj install: Välj Cancel: Stäng sedan programmet. Dubbelklicka på ikonen: 45

46 Skriv: ssh-keygen.exe -t rsa, tryck sedan enter tills att prompten visas igen. Skriv: cd "$env:userprofile\.ssh" Skriv: notepad id_rsa.pub Kopiera innehållet och skicka till mig: Skriv: cd "$env:userprofile\documents\github" Skriv: git clone 46