Transcript Projektrapport

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
13640 Handen, Sverige
http://www.kth.se/sth
2
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
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
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
230
35
10
20
10
40
15
80
0
5
15
Farhad
257
0
5
135
67
0
30
5
12
0
3
Joel
188
4
40
90
0
0
20
30
4
0
5
Gustav
189
0
68,5
15
0
0
13,5
51
0
25
14
187,5
0
69,5
15
0
0
14
47
0
25
15
Emil
Figur 2. Arbetsfördelning
7
8
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
Innehållsförteckning
Sammanfattning....................................................................................3
Abstract................................................................................................5
Projektdeltagare.....................................................................................7
Uppdelning av arbetsuppgifter...............................................................7
Förord..................................................................................................9
1. Inledning.........................................................................................13
1.1 Problemformulering......................................................................13
1.2 Målsättning.................................................................................13
1.3 Avgränsningar.............................................................................14
2. Teori / metodval...............................................................................15
2.1 Arduino......................................................................................15
2.2 Rover 5 chassi.............................................................................15
2.3 Rover 5 motorsköld......................................................................16
2.4 Wifi sköld....................................................................................17
2.5 Avståndsmätning.........................................................................17
2.6 PALCE22v10-25PC/PI....................................................................18
2.7 Raspberry pi................................................................................18
2.8 Hårdvaruteori..............................................................................19
2.9 Kartläggningsteori........................................................................19
2.10 Tester av Arduino mjukvara ......................................................19
2.10.1 Motorsköld med motorer.......................................................19
2.10.2 Pulsmätare..........................................................................20
2.11 Tester av hårdvara......................................................................21
2.11.1 Wifi....................................................................................24
2.11.2 SD-kort...............................................................................24
3. Metod..............................................................................................25
3.1 Blockdiagram..............................................................................25
3.2 Kretsschema...............................................................................26
3.3 Styralgoritm................................................................................26
3.4 Hårdvara....................................................................................26
3.5 Mjukvara för kartläggning..............................................................27
3.6 Servern......................................................................................28
3.6.1 Hemsidan.............................................................................29
4. Resultat...........................................................................................31
5. Diskussion / analys...........................................................................33
6. 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.........................................................................50
11
Bilaga
Bilaga
Bilaga
Bilaga
Bilaga
8. Programkod.........................................................................53
9. Installation/konfiguration av Arch Linux...................................57
10. Flödesschema hemsidan......................................................59
11. Flödesschema robot............................................................60
12. Teoretisk modell för framtagning av reell sträcka.....................61
12
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
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
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
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
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
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
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.
2.10 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.
2.10.1 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
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.
2.10.2 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
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.
2.11 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
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
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
Figur 14. Mätning av distans för angiven sträcka(x-led) och färdad sträcka (y-led).
2.11.1 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.
2.11.2 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
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 15.
25
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 11.
3.4 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
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
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
Figur 18. Nätverksdiagram med servern, dess användning samt backup.
3.6.1 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
19.
29
Figur 19. en användarprofil på hemsidan
30
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
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 12
.
33
34
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
Källförteckning
[1] Phillips
Produktsida robotdammsugare FC9910/01
http://www.philips.se/c/dammsugare/robotdammsugare-fc9910_01/prd/sv/
Besökt 2014-05-15.
[2] Samsung
Produktsida robotdammsugare NaviBot silencio
http://www.samsung.com/my/consumer/home-appliances/vacuumcleaner/robotic/VCR8895L4A/XME
Besökt 2014-05-15.
[3] Arduino
Bild av Arduino Uno
http://arduino.cc/en/Main/arduinoBoardUno
Besökt 2014-05-15.
[4] Teco Electric
Datablad DC-motorer
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Robotics/RP6%20motor%20TFK280SC21138-45.pdf
Besökt 2014-05-15
[5] Sparkfun
Rover 5 infoblad
https://www.sparkfun.com/datasheets/Robotics/Rover%205%20Introduction.pdf
Besökt 2014-05-15
[6] Lawicel webbshop
Bild av Rover 5
http://www.lawicel-shop.se/shop/assets/prod_images/pROB-10336l.jpg?
r=34212.67247666674
Besökt 2014-05-15
[7] Sparkfun
Rover 5 motorsköld
https://www.sparkfun.com/products/11593
Besökt 2014-05-15 .
[8] Sparkfun
Beskrivning av motorsköld
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Robotics/4%20Channel%20instruction
%20manual.pdf
Besökt 2014-05-15
[9] Cytron Technologies
Användarmanual Ultraljudssensor HC-SR04
https://docs.google.com/document/d/1Y-yZnNhMYy7rwhAgyL_pfa39RsBx2qR4vP8saG73rE/edit
Besökt 2014-05-15
[10] Sharp
Datablad IR-sensor GP2Y0A21YK0F
http://www.pololu.com/file/download/gp2y0a21yk0f.pdf?file_id=0J85
Besökt 2014-05-15
[11] Elfa
Produktsida laserdiod LCU98B041A https://www.elfa.se/elfa3~se_sv/elfa/init.do?item=75-
37
726-27&toc=0&q=laser+avst%C3%A5ndsm%C3%A4tare
Besökt 2014-05-015
[12] Lattice
Datablad PALCE22V10
http://www.latticesemi.com/~/media/Documents/DataSheets/PAL/PALCE22V10PALCE22V10ZD
ataSheet.PDF
Besökt 2014-05-15
[13] YDXK§
Bild PALCE22V10
http://www.ydxk-ic.com/uploadfiles/image/201010712493676372.jpg
Besökt 2014-05-15.
[14] Arduino
Beskrivning av SPI
http://arduino.cc/en/Reference/SPI
Besökt 2014-05-15
[15] Arduino
Beskrivning av wifi-sköld
http://arduino.cc/en/Main/ArduinoEthernetShield
Besökt 2014-05-15
[16] Raspberry pi
Beskrivning av raspberry pi
http://www.raspberrypi.org/help/what-is-a-raspberry-pi/
Besökt 2014-05-15
[17] Raspberry pi
Beskrivning av raspberry pi model B
http://www.raspberrypi.org/product/model-b/
Besökt 2014-05-15
[18] Arduino
Arduinokortet
http://arduino.cc
Besökt 2014-05-15
38
Bilagor
Bilaga 1. Tester
Tester av ultraljudssensorer den 14/4-2014
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å 2-400 cm, blir
värdena antingen negativa eller ”0”, möjligtvis pga. Ultraljudsensorerna ger även mätvärden
utanför 2-400 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)
70
70
70
69
67
60
60
60
60
61
50
50
49
50
50
40
42
40
40
Tabell 1. Mätvärden, se beskrivning ovan.
Första testet med Rover 5 den 14/4-2014
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/4-2014
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
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/4-2014
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/4-2014
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/4-2014
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/4-2014
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
Variabel(impulser)
Vänstersväng(grader)
350
ca 130
300
100
280
90
270
89
275
89
275
90
Tabell 2. Testvärden för pulsmätarkonstant
Högersväng(grader)
ca 115
109
94
89
91
90
Testkörning av kartläggning den 30/4-2014
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 10-13 cm istället
för 20-25 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/4-2014
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
Bilaga 2. Backupscript
[root@webpi ~]# 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
[email protected]:./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
Bilaga 3. Kretsschema
Figur: Kretsschema över robotdammsugaren.
43
Bilaga 4. Konceptskiss
Figur: Konceptskiss av roboten.
44
Bilaga 5. Installation av Git
Gå in på denna länk:
https://windows.github.com/
Klicka här:
Spara filen:
Svara Run:
Välj install:
Välj Cancel:
Stäng sedan programmet.
Dubbelklicka på ikonen:
45
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: [email protected]
Skriv: “cd "$env:userprofile\Documents\github" ”
Skriv: ”git clone [email protected]:/srv/git/robot ”
46
Klart!
Skriv: ”exit”
Öppna:
Klicka: Tools->Options
Tryck på : Scan for repositories
Kolla så att robot är markerad:
Klicka på Add:
Tryck Update:
Nu finns robot tillagd:
47
Bilaga 6. Programkod
//Programvara för att ta ut förhållanden mellan vänster och höger larvfötter
/* av PROJEKTGRUPP 15 */
/* DEFINES */
#define RIGHT 0
#define LEFT 1
#define FORWARD 1
#define BACKWARD 0
#define TRUE 1
#define FALSE 0
//array for motorer första är PWM, andra är direction
int arrayMotorLeft[] = {9,A2};
int arrayMotorRight[] = {5,A3};
//räknar variabel för encoders
long counterL = 0;
long counterR = 0;
void setup()
{
pinMode(arrayMotorLeft[0], OUTPUT); //Sätter alla portar för motorstyrning
pinMode(arrayMotorRight[0], OUTPUT);
pinMode(arrayMotorLeft[1], OUTPUT);
pinMode(arrayMotorRight[1], OUTPUT);
attachInterrupt(0,countLeft,CHANGE); //använd interrupts för vänster encoder
attachInterrupt(1,countRight,CHANGE); //använd interrupts för höger encoder
Serial.begin(9600); //fixa debugging
}
void loop()
{
//ändra förhållandet mellan däcken
if(counterL > counterR){
speedL--;
speedR++;
}else if(counterL < counterR){
speedL++;
speedR++;
}
analogWrite(arrayMotorLeft[0],speedL);
analogWrite(arrayMotorRight[0], speedR);
}
Serial.print(counterL);
Serial.print(",");
Serial.print(speedL);
Serial.print(",");
Serial.print(counterR);
Serial.print(",");
Serial.println(speedR);
void countLeft(){
48
counterL++;
}
void countRight(){
counterR++;
}
void m_motor(int pinPower,int power, int pinDir , int dir){
digitalWrite(pinDir, dir);
analogWrite(pinPower,power);
}
49
Bilaga 7. Programkod
//Programvara för att åka framåt
/* av PROJEKTGRUPP 15 */
/* DEFINES */
#define RIGHT 0
#define LEFT 1
#define FORWARD 1
#define BACKWARD 0
#define TRUE 1
#define FALSE 0
//#define speedLeft 76 //orignal värden från statistik
//#define speedRight 180 //orignal värden från statistik
#define speedLeft 96 //tunade inställningar
#define speedRight 170 //tunade inställningar
#define MCHANGE 5 //hur många procent ska förändras åt gången
//array for motorer första är PWM, andra är direction
int arrayMotorLeft[] = {9,A2};
int arrayMotorRight[] = {5,A3};
//räknar variabel för encoders
long counterL = 0;
long counterR = 0;
//
int once = 1; //starta mjukt
int multiplyLeft = 100; //multiplikatorn för vänster
int multiplyRight = 100; //multiplikatorn för höger
void setup()
{
pinMode(arrayMotorLeft[0], OUTPUT); //Sätter alla portar för motorstyrning
pinMode(arrayMotorRight[0], OUTPUT);
pinMode(arrayMotorLeft[1], OUTPUT);
pinMode(arrayMotorRight[1], OUTPUT);
attachInterrupt(0,countLeft,CHANGE); //använd interrupts för vänster encoder
attachInterrupt(1,countRight,CHANGE); //använd interrupts för höger encoder
}
Serial.begin(9600); //fixa debugging
void loop()
{
//starta mjukt
if(once){
once = 0;
m_motor(arrayMotorLeft[0], (speedLeft * 0.20) ,arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight * 0.20),arrayMotorRight[1],FORWARD);
delay(100);
m_motor(arrayMotorLeft[0], (speedLeft * 0.60) ,arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight * 0.60) ,arrayMotorRight[1],FORWARD);
delay(100);
m_motor(arrayMotorLeft[0], (speedLeft * 1) ,arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight * 1) ,arrayMotorRight[1],FORWARD);
50
}
//ändra förhållandet mellan däcken
if(counterL > counterR){
multiplyLeft -= MCHANGE;
multiplyRight += MCHANGE;
}else if(counterL < counterR){
multiplyLeft += MCHANGE;
multiplyRight -= MCHANGE;
}
//om hastigheten blir mindre än 55, åtgärda
if(((multiplyLeft/100.0)*speedLeft) < 55){multiplyLeft += MCHANGE;}
if(((multiplyRight/100.0)*speedRight) < 55){multiplyRight += MCHANGE;}
//om hastigheten blir över 220, åtgärda.
if(((multiplyLeft/100.0)*speedLeft) > 220){multiplyLeft -= MCHANGE;}
if(((multiplyRight/100.0)*speedRight) > 220){multiplyRight -= MCHANGE;}
m_motor(arrayMotorLeft[0], (speedLeft *
(multiplyLeft/100.0)),arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight *
(multiplyRight/100.0)),arrayMotorRight[1],FORWARD);
Serial.print(counterL);
Serial.print(",");
Serial.print(speedLeft * (multiplyLeft/100.0));
Serial.print(",");
Serial.print(counterR);
Serial.print(",");
Serial.println(speedRight * (multiplyRight/100.0));
//vänta 200ms innan loopen roterar
delay(200);
counterL -= 1; //en fullösning för att få förhållandet mellan larvfötterna att fungera
}
void rotate(int *motorleft, int *motorright, int mDirection, int degree){
//dettach timer1 innan svängning!
long oneDegree = (RATVINKEL/90.0);
switch(mDirection){
case LEFT:
m_motor(arrayMotorLeft[0], (speedLeft*1.2),motorleft[1],BACKWARD);
m_motor(arrayMotorRight[0], (speedRight*1.2),motorright[1],FORWARD);
break;
case RIGHT:
m_motor(arrayMotorLeft[0], (speedLeft*1.2),motorleft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight*1.2),motorright[1],BACKWARD);
break;
}
while((counterR < (oneDegree * degree)) || (counterL < (oneDegree * degree))){
delay(1);
}
m_motor(arrayMotorLeft[0], 0,motorleft[1],FORWARD);
m_motor(arrayMotorRight[0], 0,motorright[1],FORWARD);
}
void countLeft(){
51
counterL++;
}
void countRight(){
counterR++;
}
void m_motor(int pinPower,int power, int pinDir , int dir){
digitalWrite(pinDir, dir);
analogWrite(pinPower,power);
}
52
Bilaga 8. Programkod
//Programvara för att åka framåt samt hantera ultraljudssenorerna
/* av PROJEKTGRUPP 15 */
/* DEFINES */
#define RIGHT 0
#define LEFT 1
#define FORWARD 1
#define BACKWARD 0
#define TRUE 1
#define FALSE 0
#define RATVINKEL 450 // 195 pulser ger en rät vinkel, 390 med dubbla enc
//#define speedLeft 76 //orignal värden från statistik
//#define speedRight 180 //orignal värden från statistik
#define speedLeft 96 //tunade inställningar
#define speedRight 170 //tunade inställningar
#define MCHANGE 5 //hur många procent ska förändras åt gången
#define DELAYMS 200
#define LASTSENSOR 3
/*MOTORER*/
//array for motorer första är PWM, andra är direction
int arrayMotorLeft[] = {9,A2};
int arrayMotorRight[] = {5,A3};
//räknar variabel för encoders
long counterL = 0;
long counterR = 0;
//
int once = 1; //starta mjukt
int multiplyLeft = 100; //multiplikatorn för vänster
int multiplyRight = 100; //multiplikatorn för höger
/* ///////////////// */
/*SENSORER*/
int pinPALCE[] = {A4,A5}; //Y0, Y1
//encSensors[0] = vänster,encSensors[1] = mitten,encSensors[2] = höger
int pinEcho[] = {10,11,8};
int encSensors[4][2] = {
{1,0},
{0,1},
{1,1},
{0,0}
};
//array med UL-data
int newULdata[] = {0,0,0};
int oldULdata[] = {0,0,0};
/* ///////////////// */
void setup()
{
/*motorer*/
pinMode(arrayMotorLeft[0], OUTPUT); //Sätter alla portar för motorstyrning
53
pinMode(arrayMotorRight[0], OUTPUT);
pinMode(arrayMotorLeft[1], OUTPUT);
pinMode(arrayMotorRight[1], OUTPUT);
attachInterrupt(0,countLeft,CHANGE); //använd interrupts för vänster encoder
attachInterrupt(1,countRight,CHANGE); //använd interrupts för höger encoder
/*UL sensorer*/
pinMode(pinEcho[0], INPUT);//echo
pinMode(pinEcho[1], INPUT);//echo
pinMode(pinEcho[2], INPUT);//echo
pinMode(pinPALCE[0], OUTPUT); //trig
pinMode(pinPALCE[1], OUTPUT); //trig
selectSensor(encSensors[4]); //Ingen sensor vald
/**/
Serial.begin(9600); //fixa debugging
}
//fixa variabeln
void loop()
{
int delayULsensor = 0; //ska alltid vara noll
//starta mjukt
if(once){
once = 0;
m_motor(arrayMotorLeft[0], (speedLeft * 0.20) ,arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight * 0.20),arrayMotorRight[1],FORWARD);
delay(100);
m_motor(arrayMotorLeft[0], (speedLeft * 0.60) ,arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight * 0.60) ,arrayMotorRight[1],FORWARD);
delay(100);
m_motor(arrayMotorLeft[0], (speedLeft * 1) ,arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight * 1) ,arrayMotorRight[1],FORWARD);
}
//ändra förhållandet mellan däcken
if(counterL > counterR){
multiplyLeft -= MCHANGE;
multiplyRight += MCHANGE;
}else if(counterL < counterR){
multiplyLeft += MCHANGE;
multiplyRight -= MCHANGE;
}
//om hastigheten blir mindre än 55, åtgärda
if(((multiplyLeft/100.0)*speedLeft) < 55){multiplyLeft += MCHANGE;}
if(((multiplyRight/100.0)*speedRight) < 55){multiplyRight += MCHANGE;}
//om hastigheten blir över 220, åtgärda.
if(((multiplyLeft/100.0)*speedLeft) > 220){multiplyLeft -= MCHANGE;}
if(((multiplyRight/100.0)*speedRight) > 220){multiplyRight -= MCHANGE;}
m_motor(arrayMotorLeft[0], (speedLeft *
(multiplyLeft/100.0)),arrayMotorLeft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight *
(multiplyRight/100.0)),arrayMotorRight[1],FORWARD);
//kolla sensorerna, ta reda på hur lång tid det tog.
delayULsensor = millis();
54
getULdistance(newULdata);
delayULsensor = millis() - delayULsensor;
Serial.print("delay is: ");
Serial.println(delayULsensor);
Serial.print("DISTANS VANSTER: ");
Serial.print(newULdata[0]);
Serial.println(" cm till handen");
Serial.print("DISTANS MITTEN: ");
Serial.print(newULdata[1]);
Serial.println(" cm till handen");
Serial.print("DISTANS HOGER: ");
Serial.print(newULdata[2]);
Serial.println(" cm till handen");
/*
Serial.print(counterL);
Serial.print(",");
Serial.print(speedLeft * (multiplyLeft/100.0));
Serial.print(",");
Serial.print(counterR);
Serial.print(",");
Serial.println(speedRight * (multiplyRight/100.0));
*/
//vänta 200ms innan loopen roterar
delay(DELAYMS - delayULsensor);
counterL -= 1; //en fullösning för att få förhållandet mellan larvfötterna att fungera
}
/*MOTOR FUNKTIONER*/
void rotate(int *motorleft, int *motorright, int mDirection, int degree){
//dettach timer1 innan svängning!
long oneDegree = (RATVINKEL/90.0);
switch(mDirection){
case LEFT:
m_motor(arrayMotorLeft[0], (speedLeft*1.2),motorleft[1],BACKWARD);
m_motor(arrayMotorRight[0], (speedRight*1.2),motorright[1],FORWARD);
break;
case RIGHT:
m_motor(arrayMotorLeft[0], (speedLeft*1.2),motorleft[1],FORWARD);
m_motor(arrayMotorRight[0], (speedRight*1.2),motorright[1],BACKWARD);
break;
}
while((counterR < (oneDegree * degree)) || (counterL < (oneDegree * degree))){
delay(1);
}
m_motor(arrayMotorLeft[0], 0,motorleft[1],FORWARD);
m_motor(arrayMotorRight[0], 0,motorright[1],FORWARD);
}
/*// / /// /// //// ////*/
void countLeft(){
counterL++;
}
void countRight(){
counterR++;
}
55
void m_motor(int pinPower,int power, int pinDir , int dir){
digitalWrite(pinDir, dir);
analogWrite(pinPower,power);
}
/*SENSOR FUNKTIONER*/
void getULdistance(int *newData){
int distance_raw = 0;
int distance_cm = 0;
int i;
/*räkna igenom UL sensorerna och gör en array av dem
och denna skrivs över med nya värden*/
for(i=0;i < LASTSENSOR; i++){
selectSensor(encSensors[i]);
delayMicroseconds(10);
selectSensor(encSensors[LASTSENSOR]);
distance_raw = pulseIn(pinEcho[i], HIGH);
distance_cm = (distance_raw/58);//Formel för att få avståndet i cm
if(distance_cm < 0 || distance_cm > 300){distance_cm = 0;}
newData[i] = distance_cm; //arrayen som var ett argument skrivs nu över.
}
}
void selectSensor(int pins[]){
digitalWrite(pinPALCE[0], pins[0]);//= y0
digitalWrite(pinPALCE[1], pins[1]);//= y1
}
//Mäter kört avstånd
float get_distance(float counterA){
float distance = 0;
float wheel_r = 3;
float wheel_round = 1000/3;
if(counterA > 0){
distance = (counterA / wheel_round) * (wheel_r * 2 * PI);
}
return distance;
}
/*// / /// /// //// ////*/
56
Bilaga 9. Installation/konfiguration av Arch Linux
Nedladdning av operativsystem hämtades från denna adress:
http://archlinuxarm.org/platforms/armv6/raspberry-pi
Därefter packades zip filen upp med kommandot: unzip ArchLinuxARM-rpi-latest.zip
SD-minneskortet anslöts till PC:n, med hjälp av dmesg kan man fånga de senaste händelserna
från kärnan, det räcker med de tjugo senaste för att ta reda på vilken enhetsbeteckning
minneskortet fick:
[root@laptop ~]# dmesg | tail -20
[ 175.261485] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[ 175.261610] scsi6 : usb-storage 1-1.1:1.0
[ 175.261758] usbcore: registered new interface driver usb-storage
[ 176.264024] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0
[ 176.501088] sd 6:0:0:0: [sdb] 15544320 512-byte logical blocks: (7.95 GB/7.41 GiB)
[ 176.502484] sd 6:0:0:0: [sdb] Write Protect is off
[ 176.502490] sd 6:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[ 176.503877] sd 6:0:0:0: [sdb] No Caching mode page found
[ 176.503884] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 176.508893] sd 6:0:0:0: [sdb] No Caching mode page found
[ 176.508900] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 176.511140] sdb: sdb1 sdb2
sdb är diskenheten som är minneskortet.
För att sedan kopiera över Arch Linux till minneskortet körs detta kommando:
dd bs=1M if=ArchLinuxARM-2014.03-rpi.img of=/dev/sdb
ta sedan ur minneskortet för att sätta i det i datorn igen, detta för att ladda om
partitionstabellen, därefter kan man verifiera att koperingen har gått bra med kommandot:
[root@webpi ~]# fdisk -lu
Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000c3563
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 2048 186367 92160 c W95 FAT32 (LBA)
/dev/mmcblk0p2 186368 31291391 15552512 5 Extended
/dev/mmcblk0p5 188416 31289343 15550464 83 Linux
Anledningen till att det är olika storlekar på minneskorten är att den första som installerades
Arch Linux på hade korrupta datablock.
Därefter användes verktyget gparted för att utöka de två partitionerna, detta för att ge Linux
Operativsystemet större diskarea.
Därefter togs minneskortet ut ur den bärbara datorn och placerades i Raspberry Pi. Servern
startades och det första kommando som utfördes efter installation var:
pacman -Syu #detta kommando utför en systemuppdatering.
Efter det kommandot startades servern om med kommandot: systemctl reboot
57
Konfiguration av Raspberry Pi
En statisk ipadress konfigurerades till servern, detta för att garantera att servern har samma
ipadress även vid omstart samt att man nu kan göra port-forwarding från routern till servern.
Ändra hostname på servern: echo webpi > /etc/hostname
/etc/netctl/eth0 har konfigurationen för IP.
[root@webpi ~]# cat /etc/netctl/eth0
Description='A basic static ethernet connection'
Interface=eth0
Connection=ethernet
IP=static
AutoWired=Yes
Address=('<ipaddress>/24')
Gateway='<gateway>'
DNS=('<dns>')
<ipaddress>,<gateway> samt <dns>, byts ut till inställningar som passar nätet som den är
ansluten till.
Installera ddclient:
pacman -S ddclient #installera ddclient
systemctl enable ddclient.service #se till att servicen startas automatiskt vid omstart
editera /etc/ddclient/ddclient.conf efter behov, i detta fall används dyndns som tjänst för att få
en dynamisk uppdatering av dns-record. Servern står hos en ISP och routern har ett
dynamiskt ipnummer, om detta skulle förändras kommer ddclient att ansluta till dyndns och
ändra ipadressen på det A-record som den är knuten till.
systemctl start ddclient.service #startar tjänsten
pacman -S apache #installera apache
pacman -S php-gd #installera GD bibliotek till php
pacman -S php-apache #installera php till apache
pacman -S git #installera GIT
pacman -S mariadb #installera mariadb (MySQL)
systemctl enable httpd.service #starta automatiskt tjänsten apache vid omstart
systemctl enable mysqld.service #starta automatiskt mariadb vid omstart
Konfigurera Apache gjordes efter denna guide:
https://wiki.archlinux.org/index.php/LAMP
Konfigurera GIT gjordes efter denna guide:
http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server
58
Bilaga 10. Flödesschema hemsidan
Figur: Flödesschema av hemsidan.
59
Bilaga 11. Flödesschema robot
Figur: Flödesschema över algoritmen för roboten.
60
Bilaga 12. Teoretisk modell för framtagning av reell sträcka
61