Självständigt arbete i informationsteknologi 14 juni 2020
CrossDump: En GPS-applikation för Linux-baserade displayer till moderna industrifordon
Anton Bergåker Carl Enlund
Astrid Nord Olsson
Arvid Sandin
Institutionen för informationsteknologi
Besöksadress:
ITC, Polacksbacken Lägerhyddsvägen 2
Postadress:
Box 337 751 05 Uppsala
Hemsida:
https://www.it.uu.se
Abstract
CrossDump: En GPS-applikation för Linux- baserade displayer till moderna industrifordon
Anton Bergåker Carl Enlund
Astrid Nord Olsson Arvid Sandin
CrossDump is a GPS application developed for modern industrial vehi- cles, specifically those in municipal solid waste collection. The appli- cation is developed for CrossControl AB, a company selling computers and electronics for heavy machinery and industrial trucks. CrossDump will be used to demonstrate the potential of CrossControl’s display com- puters. In contrast to GPS applications like Google Maps, CrossDump is tailor-made for CrossControl’s displays, mounted on the dashboard by the driver in a vehicle. The system helps garbage truck drivers nav- igate safely and efficiently between waste collection sites and supplies location-specific information relevant to the driver’s work tasks. Cross- Dump is built to minimize the driving distance, which contributes to a more sustainable environment. To show the full capacity of Cross- Control’s hardware the application has been designed specifically with performance in mind.
Extern handledare: Anders Svedberg och Alexander Wingård, CrossControl AB Handledare: Mats Daniels, Anne Peters, Björn Victor, Tina Vrieler
Examinator: Björn Victor
Sammanfattning
CrossDump är en GPS-applikation utvecklad för moderna industrifordon, specifikt de
inom kommunal avfallshantering. Applikationen är skapad åt CrossControl AB, ett fö-
retag som säljer datorer och elektronik till industriella fordon och maskiner. CrossDump
kan demonstrera potentialen hos CrossControls displaydatorer. Till skillnad från GPS-
applikationer som Google Maps, är CrossDump skräddarsydd för CrossControls dis-
player, som kan monteras framme vid föraren i ett fordon. Applikationen hjälper sop-
bilsförare att navigera tryggt och effektivt mellan sopplatser och visar platsbaserad in-
formation om vilka uppgifter föraren ska utföra. CrossDump är byggd för att minimera
förarens körsträcka för att bidra till en mer hållbar miljö. För att utveckla ett system som
visar hårdvarans förmåga har applikationen designats specifikt med prestanda i åtanke.
Innehåll
1 Inledning 1
2 Bakgrund 2
2.1 System för satellitnavigering . . . . 2
2.2 GPS:ens användning . . . . 3
2.3 CrossControl . . . . 4
3 Syfte, mål, och motivation 5 3.1 Syfte . . . . 5
3.2 Mål . . . . 5
3.3 Motivation . . . . 6
3.4 Etiska aspekter . . . . 7
3.5 Avgränsningar . . . . 7
4 Relaterat arbete 7 4.1 Mjukvara . . . . 8
4.2 Fullständiga GPS-system . . . . 8
5 Metod 9 5.1 Pekskärmsdisplayen CCpilot VS . . . . 9
5.2 Applikationsramverket Qt . . . . 11
5.3 Kartor och navigering . . . . 12
6 Systemstruktur 12
7 Krav och utvärderingsmetoder 14
7.1 Krav på applikationens prestanda . . . . 14
7.2 Krav på offline-stöd . . . . 15
7.3 Krav på användargränssnittets estetik . . . . 15
8 Implementation 16 8.1 Karta och navigeringsläge . . . . 16
8.2 Turn-by-turn-navigering . . . . 18
8.3 Rutter och ruttoptimering . . . . 18
8.4 Indelning av sopplatser i zoner . . . . 19
8.5 Offline-läge . . . . 21
9 Utvärderingsresultat 22 9.1 Utvärdering av applikationens prestanda . . . . 22
9.2 Utvärdering av offline-stöd . . . . 23
9.3 Utvärdering av användargränssnittets estetik . . . . 23
10 Resultat 23 11 Diskussion 24 11.1 Användbarhet . . . . 24
11.2 Kartor och navigering . . . . 25
11.3 Systemstruktur . . . . 26
12 Slutsatser 27
13 Framtida arbete 27
1 Inledning
1 Inledning
CrossControl AB är ett företag som säljer datorer med inbyggd display som kan installe- ras i industriella fordon och maskiner. Datorerna, framöver benämnt displayer, används inom en mängd olika industrier [6], allt från lantbruk till skogs- och gruvindustrin. I nuläget saknar CrossControl applikationer på displayerna som använder sig av kartor och GPS-navigering. CrossControl vill därför utveckla en applikation som kan använ- das för att demonstrera möjliga tillämpningar av dessa tekniker. Navigeringslösningen i applikationen ska kunna användas i framtida eller integreras med existerande system som deras kunder använder. Genom att erbjuda nya funktioner på sina displayer, i det här fallet navigering, kan CrossControls displayer bli användbara för fler kunder.
Det finns olika typer av navigeringsfunktioner som behövs i en navigeringsapplikation.
Det behövs en karta och körinstruktioner som kan visa var användaren befinner sig och var användaren ska åka. Vi har utvecklat och implementerat en fungerande navi- geringsapplikation som kan köras på CrossControls displayer. CrossControls verktyg och utvecklingsmiljöer har använts för att skapa och testa applikationen så att den kan integreras med CrossControls displayer.
Resultatet av vårt projekt CrossDump (Figur 1) är en färdig implementation av en sådan navigeringsapplikation. Applikationen är specifikt gjord för att hjälpa sopbilsförare att navigera mellan sina sopplatser. Applikationen guidar föraren genom en rutt som täcker arbetspassets alla sopplatser, med hjälp av en karta, körinstruktioner och en checklista.
Rutten som applikationen rekommenderar till föraren är optimerad för att minimera den totala körsträckan. En kortare körsträcka minskar utsläpp och tid i trafiken, vilket bidrar till ett mer hållbart samhälle.
Projektets främsta bidrag är att CrossControl har en mer konkret startpunkt när de vill ut- veckla projekt som använder liknande lösningstekniker för kartor och navigering. Cross- Dump visar hur det är möjligt att utveckla ett navigeringssystem för CrossControls dis- player som går att använda i olika industrifordon. Genom projektet har en fungerande kart- och navigeringslösning identifierats till displayerna. Med vidare utveckling och användartester kan denna lösning användas av ett avfallshanteringsföretag. Lösningen innehåller olika funktionalitet som kan vara användbara inom olika branscher, inte bara för sopbilar då navigering mellan flera punkter är vanligt.
Tillkännagivande Tack till Anders Svedberg och Alexander Wingård på CrossCon-
trol, som har varit till stor hjälp genom hela projektets gång, både med handledning och
kontinuerlig feedback.
2 Bakgrund
Figur 1 Vår applikation CrossDump körandes på CrossControls display.
2 Bakgrund
Det här avsnittet går igenom de olika områden som projektet angränsar. GPS-enheter och deras användning är angränsanden områden till projektet och beskrivs från ett histo- riskt perspektiv. Projektets uppdragsgivare och externa intressent CrossControl beskrivs även övergripande.
2.1 System för satellitnavigering
Idag är det nästan otänkbart att inte omedelbart kunna se sin egen position eller få väg-
beskrivning vart man än vill åka. Detta är till stor del tack vare USA:s försvarsmakt,
som 1983 lovade att göra sitt system för satellitnavigering, Global Positioning System
2 Bakgrund
peiska unionen har senare skjutit upp egna navigeringssatelliter som är oberoende av GPS, med benämningarna GLONASS, Beidou respektive Galileo. Navigeringssystem är tillsammans med GPS fyra exempel på det som kallas Global Navigation Satellite System (GNSS) [8]. Trots att nästan alla moderna enheter använder sig av flera olika GNSS [9] kallas systemen fortfarande GPS i folkmun. Uttrycket GPS används även här i texten framöver.
De GPS-satelliter som finns i jordens omloppsbana skickar hela tiden ut information om exakt var de befinner sig och vilken tidpunkt de skickade signalen. En mottagare kan med en enkel antenn plocka upp dessa signaler från en mängd satelliter och sen räkna ut sin egen position [8] med hjälp av triangulering.
Positioneringens noggrannhet har bara ökat i kvalitet med åren. Vid millennieskiftet ha- de GPS en noggrannhet på 20 meter, medan den idag kan ha en noggrannhet på närmare 0,72 meter vid optimala förhållanden [45], vilket är mer än tillräckligt för vanliga navi- geringsbehov. Före år 2000 fanns det dock avsiktliga begränsningar på noggrannheten av positionering för icke-militärt bruk [44]. Den begränsningen har senare släppts och allmänheten har nu tillgång till samma noggrannhet som militären [44].
2.2 GPS:ens användning
GPS-mottagare är ofta inkopplade till mindre, bärbara datorenheter. Datorerna kan ha kartor med vägar redan nedladdade eller tillgängliga online. Tillsammans med sin nuva- rande position kan datorerna på ett smidigt sätt visa körvägar och den närmaste omgiv- ningen på kartan. Under 00-talet var det vanligt att bilåkare köpte en specifik enhet just för detta ändamål som kunde monteras i bilen [29]. Exempel på sådana GPS-enheter är de som är utvecklats av Garmin [10] och TomTom [40].
I takt med att smartphones blev vanligare och mer kapabla, med inbyggd GPS och snab- ba processorer, blev dedikerade GPS-enheter utdaterade. Eftersom smartphones ofta har inbyggd internetuppkoppling finns det alltid nyuppdaterade kartor och vägbeskrivningar som hämtats från snabba servrar via internet. Dedikerade GPS-enheters brist på internet samt tillgången på smartphones har lett till att enheterna säljs i en mindre skala idag [29].
Idag finns det fortfarande ett behov och intresse för GPS och kartor utan internetåtkomst, eftersom fordon kan sakna internetuppkoppling på grund av olika omständigheter. Det kan till exempel vara för att det kostar för mycket att installera en mottagare för internet, eller för att fordonen kör i områden där det inte finns ordentlig mottagning.
I tunga fordon, såsom traktorer, sopbilar eller skogsmaskiner, är det vanligt att datorn
inte har lika modern och kraftfull hårdvara jämfört med mobiltelefoner och desktop-
datorer. På grund av den krävande miljön fordonsdatorerna ligger i måste enheterna
2 Bakgrund
istället prioritera tålighet och livslängd. Både datorer i tunga fordon och i bilindustrin prioriterar tålighet. Förutom tålighet kan datorerna i tunga fordon även ha krav på att deras applikationer ska fungera tillsammans med andra system i fordonen, till exempel olika styrsystem. Karta, navigering och positionering är prestandakrävande processer i en applikation, vilket kan kräva att applikationen är särskilt optimerad för att köra snabbt på datorerna i tunga fordon.
För en vanlig bilförare kan det räcka med en GPS-applikation som enbart hjälper föraren att navigera mellan två olika platser. Andra förare kan ha behov av flera andra funktioner inbyggda i GPS-applikationen. Om applikationen hade utvecklats för en taxichaufförer kan till exempel hen också behöva ha en taxameter tillgänglig, medan en bussförare hellre ser information om hur mycket före eller efter tidtabellen bussen är. Därför är det intressant att kombinera kartor och navigering med andra typer av funktioner i en större fullständig applikation.
2.3 CrossControl
CrossControl är ett företag som tillverkar fordonsdatorer med inbyggda skärmar (be- nämnt displayer i rapporten), kommunikationsenheter och mjukvara som används i in- dustriella fordon och maskiner. Deras skärmar klarar de krav som ställs på fordons- datorer, exempelvis tålighet för vibrationer, höga temperaturer och fukt [2]. Många av deras kunder köper displayer med ett operativsystem och skapar egna applikationer till displayerna. CrossControl vill nu ha en applikation, CrossDump, som de kan använda till displayerna för att demonstrera kart- och navigeringsfunktioner till sina kunder. I nuläget finns det ingen sådan tjänst tillgänglig som kan köras på deras enheter.
Applikationen ska specifikt köra på CrossControls pekskärmsdisplay CCpilot VS [3]
(Figur 2). Enheten har en processor med ARM-arkitektur, en processorarkitektur främst framtagen för att vara energisnål [30]. Den har även 2 GB RAM och 4GB lagring i form av en SSD. CCpilot VS kommer förinstallerad med Linux-distributionen Lubuntu [18].
Lubuntu utgör en del av CrossControls utvecklingsplattform LinX [5] och går även att
installera i en virtuell maskin på en dator för att få tillgång till CrossControls olika
utvecklingsverktyg. I installationen finns bland annat en utvecklingsmiljö för ramverket
Qt [31], som CrossControl använder för att utveckla många av sina applikationer till
displayerna. Displayerna är konstruerade för att hålla länge, med robust design som
kan tåla externa skador och tuffare miljöer. Displayerna är även lätta att installera hos
föraren i olika typer av fordon.
3 Syfte, mål, och motivation
3 Syfte, mål, och motivation
Det här avsnittet diskuterar syftet med CrossDump, vilka mål projektet är tänkt att upp- fylla, och bakomliggande motivation till projektet. Etiska aspekter kring hur projektets resultat kan användas i praktiken diskuteras även kort, följt av vilken funktionalitet som projektet valts att avgränsas till.
3.1 Syfte
Syftet med CrossDump är att göra det lättare för sopbilsförare att navigera mellan platser där sopor ska hämtas. Med hjälp av ett tydligt användargränssnitt kan applikationen göra det lätt att se vilka olika platser föraren ska åka till, så att föraren inte behöver memorera sin rutt. Genom att ge föraren en så kort körsträcka som möjligt mellan de olika platserna, ska applikationen även hjälpa föraren att minska sopbilens utsläpp i trafiken. Föraren kan enkelt se information i applikationen och anpassa sig till de olika rutterna som finns att välja bland. Detta ska göra arbetet enklare både för nya och erfarna sopbilsförare, vilket bidrar till att skapa en tryggare och mer effektiv arbetsmiljö.
Samtidigt som CrossControl vill skapa en användbar produkt vill de använda projek- tet som ett medel för att visa hur kapabla deras displayer är. Projektet blir ett exempel på hur deras kunder kan använda displayerna för karta och navigering inom olika in- dustrier. Syftet med projektet är därför även att hitta en fungerande lösning för kart- och navigeringstekniker till displayerna. På så sätt har CrossControl ett beslutsunderlag när de väljer mellan tekniska lösningar i framtida projekt som använder karta och navi- gering. De behöver då inte upprepa samma undersökning om vilka tekniska lösningar som fungerar bäst. Eftersom CrossControl vill kunna använda koden från CrossDump till liknande projekt, och CrossControl jobbar i Qt är det viktigt att Qt används för att implementera applikationen.
3.2 Mål
Målet med projektet är att leverera en navigeringsapplikation som stödjer CrossCon-
trols displayer. Applikationen ska hjälpa förare att på ett enkelt sätt lägga upp rutter och
navigera mellan de olika platserna i rutten. Applikationen ska ha ett tydligt och minima-
listiskt användargränssnitt för att användaren lätt ska kunna lära sig hur applikationens
olika funktioner används. Systemet fokuserar i första hand på att vara användbar för en
sopbilsförare för att klara av sina arbetsuppgifter, men det ska enkelt gå att anpassa sy-
stemet för andra industrier och branscher och deras arbetsuppgifter. För att fungera på
3 Syfte, mål, och motivation
displayerna behöver applikationen utvecklas med hjälp av CrossControls utvecklings- miljöer och verktyg.
Projektet ska undersöka och utvärdera olika tekniska lösningar för att ge användbar dokumentation till CrossControl om hur de kan utveckla liknande navigeringsappli- kationer. Detta inkluderar att testa och dokumentera olika lösningar för kartbibliotek, simulera användning av applikationen under olika omständigheter, till exempel nedsatt internetuppkoppling, och slutligen integrera systemet med CrossControls display. En sopbil ska inte förväntas ha ständig internetuppkoppling, så vi ska undersöka möjlig- heterna för ett offline-läge och hur det kan påverka funktionaliteten i applikationen. Det är också viktigt att applikationen är optimerad för att klara av att köras med den begrän- sade prestanda som displayerna har.
3.3 Motivation
CrossControl har inga existerande system som visar kartor med navigering på sina dis- player. För att fylla denna lucka har projektet en viktig roll i att utforska olika lösnings- tekniker och vilka som fungerar bäst på displayerna. Applikationen ger CrossControl både ett verkligt exempel på hur karta och navigering kan användas, men även vilka tekniker som kan användas för att implementera dessa. Eftersom det inte är så tydligt vad som ska ingå i en demonstration av en kartapplikation, så har CrossControl föresla- git att vi utvecklar en applikation som kan användas inom sophantering. Vi ska leverera ett system som en sopbilsförare ska kunna använda sig av med CrossControls display installerad i fordonet. Applikationen ska erbjuda föraren navigering mellan sopplatserna och möjlighet att markera vilka sopplatser som är tömda.
CrossDump ska bidra till ett mer hållbart samhälle genom att hjälpa föraren att minime-
ra körsträckan på vägen och därmed minska utsläppen. Genom att ge föraren funktioner
för att lätt se över sina arbetsuppgifter, ska CrossDump även bidra till en tryggare och
mer effektiv arbetsmiljö. Förenta Nationernas utvecklingsprogram (UNDP) har tagit
fram olika hållbarhetsmål med syfte att bidra till ett mer hållbart samhälle och även
minska fattigdom och ojämlikheter i världen [41]. CrossDump är tänkt att främja håll-
barhetsmålet 11: Hållbar städer och samhällen [42], där ett av delmålen är att “Minska
städers miljöpåverkan”. Applikationen är även tänkt att främja hållbarhetsmålet 9: Håll-
bar industri, innovationer och infrastruktur [43], där ett av delmålen är att “Uppgradera
all industri och infrastruktur för ökad hållbarhet”. CrossDump bidrar till dessa hållbar-
hetsmål genom att minimera utsläpp från körning och hjälpa sopbilsföraren att enklare
utföra sina arbetsuppgifter.
4 Relaterat arbete
3.4 Etiska aspekter
Enligt svensk lag är det otillåtet att använda elektronisk utrustning i trafiken om det påverkar körningen på ett trafikfarligt sätt [26]. För att hjälpa föraren fokusera på sin körning är det viktigt att applikationen fungerar som ett hjälpmedel och inte distraherar föraren. Det är svårt att mäta vad som räknas som “distraherande” i en applikation.
Under utvecklingen försöker vi se till att applikationen inte ska vara distraherande, till exempel genom att använda stora knappar för användaren och inte visa onödigt mycket information på en gång. På så sätt kan föraren snabbt uppfatta vad som står på displayen utan att släppa fokus från körandet.
3.5 Avgränsningar
En användarvy för att lägga in och redigera sopplatser och rutter implementeras inte i projektet. En sådan vy kunde ha körts på en desktop-dator där en arbetsledare skapade rutter och zoner med mus och tangentbord, vilket hade varit användbar för en kund som skulle använda systemet i sina sopbilar. Vyn hade inte haft mycket att göra projektet resursmässigt och hade tagit oproportionerligt mycket tid att implementera jämfört med lösningar för karta och navigering.
Systemet har även avgränsats specifikt till sopbilar, men det finns många fordon som sy- stemet skulle kunna användas till. Till exempel har både postleverans och godstransport ett liknande upplägg på sina arbetsuppgifter, eftersom båda fallen innefattar att utfö- ra uppgifter på specifika platser. Applikationen skulle då kunna anpassas för att hjälpa förarna beroende på vad som krävs mer specifikt. CrossDumps funktioner ska vara till- räckligt generella för att man ska kunna återanvända större delar av implementationen för andra industrier än sophantering. Det är därför rimligt att avgränsa projektet enbart för användning i sopbilar.
4 Relaterat arbete
Det här avsnittet går igenom vilka relaterade navigeringssystem som finns till Cross-
Dump. För det första finns system som består helt av mjukvara, ofta en applikation
som användaren kan installera på sin smartphone eller visa direkt i en webbläsare. Det
finns även system som säljs som en fullständig produkt bestående både av mjukvara
och hårdvara. Vissa system fokuserar helt på att lösa navigeringsproblem, medan andra
integrerar andra typer av funktioner tillsammans med en navigeringslösning.
4 Relaterat arbete
4.1 Mjukvara
Nordsense [25] är ett företag som erbjuder kommuner olika licenserade tjänster till de- ras sophantering, vilket inkluderar navigering, och positionering av sopplatser. Mjukva- ran för fordonen kräver en extern enhet med Android eller iOS, och kan inte köras på CrossControls displayer. Systemet är annars likt CrossDump, med samma syfte.
Google Maps [11] är världens kanske mest använda navigeringsapplikation, vilket gör den till ett naturligt första alternativ att överväga som en navigeringsslösning. Applika- tionen är rik på funktionalitet och går att använda i många situationer för att lösa olika navigeringsproblem. Google Maps finns tillgänglig både som fullständig applikation, via webbläsare och smartphone, eller som en fristående karta som går att integrera i andra applikationer. Ett krav i projektet var att det ska använda applikationsramverket Qt. Google Maps saknar officiellt stöd för Qt, vilket innebär att Google Maps inte kan användas för att implementera kartor i projektet.
MapTrip FollowMe [16] är en ytterligare tjänst lik CrossDump som låter användaren skapa rutter bestående av upphämtningsplatser. De erbjuder både färdig mjukvara och utvecklingsverktyg som låter användaren bygga sina egna program. De har stöd för de vanligaste operativsystemen, men har inget stöd för Qt.
4.2 Fullständiga GPS-system
Det finns de enheter med enda syfte att användas till navigering, som Garmin [10] och TomToms [40] navigeringsenheter. Navigeringsenheterna kommer med förinstallerad mjukvara som enbart har stöd för att visa vägbeskrivningar och navigeringsinformation.
I ett system som kräver ytterligare funktioner där navigeringen till exempel kopplas till en sopbilsförares arbetsuppgifter, skulle det vara svårt att använda navigeringsenheterna, på grund av deras begränsade funktionalitet.
En annan lösning på navigeringsproblemet är att ta bort människan helt och hållet. Själv- körande fordon är en teknik som länge har ansetts ligga bara några år fram i tiden [24].
Tekniken skulle helt kunna eliminera behovet av en kart- och navigeringsapplikation,
eller åtminstone en visuell sådan. Sopbilar är lämpliga kandidater för debut av autono-
ma fordon i större skala, eftersom de har repetitiva arbetsuppgifter och inte interage-
rar med människor på samma sätt som till exempel en buss gör. Avfallshantering- och
återvinningsföretaget Renova utför tester i det området, men enligt dem kommer det
dröja innan de manuella sopbilarna fasas ut [28].
5 Metod
5 Metod
Det här avsnittet beskriver vilka tekniker och verktyg som används för att utveckla pro- jektet. Projektet utnyttjar både mjukvara och integrerar med existerande hårdvara för att skapa en fungerande lösning. Bland mjukvaran ingår ramverk och bibliotek för att rita upp saker på skärmen och göra att en användare kan interagera med applikationen.
Kartor och navigering är även en central del i projektet och där har flera olika lösnings- metoder testas.
5.1 Pekskärmsdisplayen CCpilot VS
Figur 2 CrossControls pekskärmsdisplay CCpilot VS.
CrossDump körs på CrossControls display CCpilot VS [3], vilket är en liten dator med en inbyggd 12-tums pekskärm. För att stödja utveckling till displayen har den uttag för USB och Ethernet, vilket gör det möjligt att ansluta den till de datorer som applikationen utvecklas på. Applikationen kan utvecklas på de flesta datorer och operativsystem, så länge de har tillräckligt hög prestanda och tillräckligt med lagringsutrymme. När en utvecklingsdator är ansluten till en display kan man kompilera en applikation, ladda upp den till displayen och sedan testköra den. En GPS-mottagare kan kopplas till displayen, vilket gör det möjligt att hämta platsinformation om fordonet där displayen används.
CCpilot VS använder sig av en processor med ARM-arkitektur[3], en processorarki-
tektur som designats främst för att vara energisnål. ARM-processorer är ovanliga i de
5 Metod
datorer som applikationen utvecklas i, så applikationen behöver kompileras separat med olika inställningar för respektive processor. Förutom processorn finns vissa andra skill- nader i displayens hårdvara som kompilatorn behöver ställas in efter när applikationen ska kompileras till displayen.
Displayen har 2 gigabyte primärminne (RAM-minne) och 4 gigabyte sekundärminne.
Med det tillgängliga utrymmet är det möjligt att lagra all data som behövs för att köra en normal applikation på displayen. Eftersom displayen främst är tänkt att köra en enda applikation under sin användning, kan större delen av lagringsutrymmet allokeras för denna applikation.
På displayen körs operativsystemet och Linux-distributionen Lubuntu [18], som är en del av CrossControls utvecklingsplattform LinX [5]. Applikationen utvecklas och testas i Lubuntu med olika program som är förinstallerade för att användas för utveckling till displayerna. Lubuntu gör det flexibelt att integrera applikationen med displayen, då operativsystemet kan köras både i en virtuell maskin och på verklig hårdvara. På så sätt ser applikationen likadan ut när den körs i de olika miljöerna, utan att förändringar behöver göras i applikationen. En större skillnad mellan displayen och de datorer som applikationen utvecklas på är att datorerna ofta saknar pekskärm som man kan trycka på. För att kunna interagera med applikationen utan pekskärm är det möjligt att använda mus och tangentbord för de flesta funktioner. Musen är begränsad för de funktioner där man behöver interagera med flera fingrar samtidigt på pekskärmen, så i dessa fall behöver applikationen testas på den riktiga displayen.
Det är även möjligt att köra andra operativsystem än Lubuntu på displayen. Detta kan vara nödvändigt då applikationer behöver köra i en speciell miljö för att fungera or- dentligt, till exempel för att vara kompatibel med andra program som körs på displayen.
CrossControl menar att Lubuntu är ett bra val för displayerna eftersom det har bra pre- standa och har testats under en längre tid, vilket gör operativsystemet snabbt att instal- lera och börja använda.
VirtualBox [46] är ett program som används för att köra Lubuntu i en virtuell maskin
och därmed simulera den miljö som finns på en riktig display. CrossDump installeras
även på en riktig display för att testa hur den fungerar under verkliga omständighe-
ter. Displayens hårdvara är inte identisk med den virtuella maskinen som applikationen
utvecklas på. För att få liknande resultat i en virtuell maskin som på verklig hårdva-
ra är det viktigt att applikationen utvecklas med särskilda inställningar i den virtuella
maskinen som liknar hårdvaran, till exempel motsvarande minnestillgångar och proces-
sorkraft. Annars kan det leda till oväntade prestandafel och att minnet tar slut medan
programmet körs.
5 Metod
5.2 Applikationsramverket Qt
Qt [31] är ett ramverk för att skapa plattformsoberoende applikationer med grafiska gränssnitt. Qt används genom hela projektet och gör det möjligt att utveckla en appli- kation som kan köra i miljöer med låg prestanda [32], till exempel låg processorkraft och minnestillgång. Utvecklingsmiljön Qt Creator
1gör det möjligt att utveckla, testa och köra applikationer på en och samma plats. CrossDump har främst utvecklats i Qt Creator körandes på en virtuell maskin med operativsystemet Lubuntu.
Ett vanligt alternativ till Qt är GUI-ramverket GTK [13], med sin jämförbara prestan- da, men Qt har fördelar som gör det till ett bättre val. Medan GTK i grunden endast är gjort för att skapa grafiska användargränssnitt, så har Qt inbyggt stöd för många oli- ka funktioner som behövs för att skapa en fullständig applikation. Qt har till exempel inbyggda funktioner för att ansluta applikationen till internet och rita upp kartor för an- vändaren [38], vilket GTK saknar officiellt stöd för. Både Qt och GTK kan användas på Windows, macOS, och Linux, men Qt har även stöd för Android och iOS [39] [12]. Tack vare Qt:s plattformskompatibilitet är det alltså möjligt att köra samma Qt-applikation på CrossControls displayer som på en surfplatta eller telefon som kör Android eller iOS.
Plattformskompatibiliteten är fördelaktigt om applikationen i framtiden skulle vidareut- vecklas till en bredare målgrupp än de som använder CrossControls displayer.
För att skapa applikationens frontend, den del av programmet som användaren intera- gerar med, används Qt Modeling Language (QML)
2, Qt:s egna markup-språk. QML används för att visa och ändra utseende på saker i gränssnittet, likt språken HTML [22]
och CSS [21] som används för att skapa frontend för webbsidor. Med QML kan man till exempel ändra plats och storlek för text och bilder, eller dela upp gränssnittet i olika av- snitt. Det är även möjligt att skapa interaktiva delar i applikationen med hjälp av QML, till exempel att ett knapptryck får något att hända i programmet. För att göra applikatio- nen interaktiv använder QML sig av skriptspråket JavaScript [23], vilket också används på webbsidor tillsammans med HTML och CSS. JavaScript-kod används på alla ställen i QML där koden behöver vara dynamisk, till exempel om färgen på en knapp ska bero på om knappen är nedtryckt eller inte, eller att ett knapptryck stänger ner applikationen.
Applikationens backend, den del av programmet som hanterar data och inte syns för an- vändaren, är skriven i C++ [1]. Backend ligger direkt i applikationen och kommunicerar direkt med frontend utan någon fördröjning. I Qt finns det stöd även för programsprå- ket Python [27] för att skriva backend[33], men C++ valdes eftersom det kör snabbare än Python. Program skrivna i C++ kompileras till maskinkod, vilket gör att de kräver mindre minne och prestanda. Python kräver att en interpretator körs i bakgrunden av
1
https://doc.qt.io/qtcreator/index.html
2
https://doc.qt.io/qt-5/qmlapplications.html
6 Systemstruktur
programmet, vilket innebär att applikationen använder mer minne och prestanda än vad den annars behöver [15].
5.3 Kartor och navigering
För att hämta och rendera en karta i applikationen finns det ett antal tillägg till Qt som kan användas. På begäran av CrossControl undersöker vi och jämför tre av Qt-tilläggen:
OpenStreetMap
3, Mapbox
4och Mapbox GL
5(Mapbox och Mapbox GL är två oli- ka implementationer av Mapbox). Några skillnader mellan tilläggen är hur de hanterar offline-kartor, 3D-funktioner och kartutseende, men de har alla god dokumentation för hur de används i Qt. Mapbox GL är den enda av dem som är hårdvaruaccelererad [14], vilket innebär att det bland annat utnyttjar en dators grafikkort till en högre grad för att utföra vissa beräkningar. Detta har en prestandafördel på CrossControls displayer, eftersom applikationen lätt kan bli begränsad eller långsam om den enbart utnyttjar pro- cessorns prestanda.
Applikationen presenterar körinstruktioner för användaren genom turn-by-turn-navigering.
Det innebär att bara information om nästa manöver visas på skärmen, till exempel att föraren ska svänga vänster om 100 meter. Ett alternativ till turn-by-turn-navigering är att visa alla körinstruktioner på en gång, men detta kan bli svårare för föraren att följa.
Det kan lätt bli överväldigande för en sopbilsförare att ha väldigt många små uppgifter framför sig, i det här fallet sopplatser. Vi har därför valt att gruppera sopplatser som ligger på samma gata eller område i zoner. Zonerna hjälper föraren att fokusera ett mer begränsat antal uppgifter åt gången. För att veta om en användare befinner sig inom en zon används geostaket, vilket innebär att applikationen kan använda GPS-mottagaren för att avgöra om användaren befinner sig inom ett specifikt geografiskt område eller inte.
6 Systemstruktur
Det här avsnittet beskriver hur applikationen är uppbyggd och vilka designval som har gjorts. De interna delarna kommunicerar med varandra, och vid behov kommunicerar de med externa tjänster via internet.
3
https://doc.qt.io/qt-5/location-plugin-osm.html
4
https://doc.qt.io/qt-5/location-plugin-mapboxgl.html
6 Systemstruktur
CrossDump är i grunden en grafisk applikation som använder GUI-ramverket Qt. Ap- plikationen består av en frontend och en backend som använder sig av en model/view- arkitektur [35] för att kommunicera mellan varandra. Model motsvarar applikationens backend och innebär är delarna av applikationen som hanterar och bearbetar data. Det inkluderar hantering av navigering och uppdelning av zoner. View motsvarar applika- tionens frontend och innebär delarna av applikationen som presenterar information för användaren. Detta inkluderar att rita upp själva kartan, visa körinstruktioner och visa annan typ av information som användaren kan interagera med. Se Figur 3 för syste- mets dataflöde. Systemet körs på pekskärmsdisplayen CCpilot VS som användare kan interagera med och få navigeringsinformation ifrån.
GPS Lokal
databas
Backend Frontend Användare
Nästa destination Navigering Sopplatser
Offline- karta
Välja rutt Markera klar zon
Karta och vägbeskrivning Position
Open Street Map Qt-
tillägg
Mapbox Vägbeskrivning
Position och destination
Internet Qt-ramverket
Mapbox Qt- tillägg
Position
Kartbilder Internet Open
Street Map
Figur 3 Dataflöde för CrossDump. Pilarna beskriver vilken data som skickas och i vil- ken riktning den skickas mellan de olika delarna av applikationen. I bilden representerar backend och frontend de delar av applikationen som CrossDump implementerar, och bå- da delarna kör tillsammans med Qt på displayen. Qt kommunicerar både med backend och frontend, och här skickas data både till och från ramverket. De streckade linjerna från Qt-tilläggen symboliserar att data skickas via internet.
Frontend är skriven i Qt Markup Language (QML). Eftersom QML är ett markup-språk
används det främst för att beskriva applikationens visuella utseende, vilka egenskaper
och hur element ligger på skärmen. QML har ett antal färdiga byggblock, så kalla-
de tillägg, som kan användas för att skapa applikationen. Karttjänsten Mapbox har ett
sådant tillägg i QML, som gör det möjligt att använda Mapbox olika funktioner i appli-
kationen. I CrossDump används Mapbox för att rita upp kartan på skärmen.
7 Krav och utvärderingsmetoder
Backend är skriven i C++ och behandlar all data i applikationen för att sedan presentera den i frontend. Navigering och uppdelning av zoner ligger i backend. Positionsdata kan hämtas från displayens inkopplade GPS-mottagare eller, för utvecklingssyften, simule- rad med data från en lokal fil. Vägbeskrivningen hämtas via internet av OpenStreetMap som har ett tillägg i QML likt Mapbox. Vägbeskrivning och körinstruktioner hämtas genom Qt:s egna API, som i sin tur kommunicerar med OpenStreetMaps servrar.
Frontend och backend kommunicerar med varandra i realtid för att hantera navigerings- information. Qt har stöd för att läsa C++-data i QML vilket används för att kommunicera mellan backend och frontend. Förutom att läsa data från C++ och kan QML anropa för- bestämda funktioner i C++, till exempel för att starta navigeringsläget i applikationen.
För att signalera att data och funktioner i C++-koden ska vara tillgänglig för QML, im- plementerar alla C++-klasser klassen QObject [37] som finns i Qt. Information om att en användare markerat sopplatserna i en zon som klara skickas från frontend till backend, och sedan visas nästa destination på kartan. För att hämta GPS-koordinater används en extern GPS-mottagare som kopplas in i displayen via USB.
Information om alla sopplatser finns inbyggd i applikationen och går inte att ändra på från användarens håll. Kartor för Uppsala är i förtid hämtade från Mapbox, och är spa- rade i en databas på displayens hårddisk. När applikationen saknar internetuppkoppling används databasen för att hämta bilder till kartan, istället för att detta görs genom inter- net.
7 Krav och utvärderingsmetoder
Det här avsnittet beskriver hur CrossDump ska utvärderas och vilka krav som ställs för att implementationen ska anses tillräckligt bra för projektets mål. Det ställs krav på att applikationen ska köra snabbt, fungera utan internetuppkoppling och att användargräns- snittet ser tilltalande ut.
7.1 Krav på applikationens prestanda
Den verkliga hårdvaran i CrossControls displayer ställer högre krav på prestanda än den
virtuella maskinen som applikationen utvecklas i. Displayens svagare processor behöver
mindre krävande mjukvara för att uppnå tillräckligt hög uppdateringsfrekvens. Proces-
sorn i CrossControls displayer har en klockhastighet på 1 GHz [3], vilket är svagare
7 Krav och utvärderingsmetoder
frekvens på minst 30 bilder per sekund (frames per second, FPS), men helst 60. En bildfrekvens under 30 kan ge ett “hackigt” intryck för användaren. Med en högre bild- frekvens kan användare uppleva applikationen som snabbare och lättare att använda.
Displayen som applikationen kör på (CCpilot VS) har en uppdateringsfrekvens på 60 Hz, vilket sätter en målsättning för hur fort applikationen borde uppdateras. Optimalt är att alltid uppnå minst 60 FPS, eftersom applikationen då alltid svarar så snabbt som hårdvaran tillåter. Prestandan utvärderas med hjälp av en FPS-räknare som körs tillsam- mans med applikationens frontend under normal användning. Genom att FPS-räknaren körs i frontend är det möjligt att räkna hur många gånger det grafiska gränssnittet har uppdaterats på en sekund och därmed avgöra om applikationen kör tillräckligt snabbt.
7.2 Krav på offline-stöd
Applikationen ska fungera offline utan att användaren förlorar tillgång till viktiga navi- geringsfunktioner. Kartbilder måste laddas ner i förväg på displayen, eftersom de inte går att hämta senare utan internetuppkoppling. Vägbeskrivningar med körinstruktioner måste även antingen finnas nedladdade på displayen, eller kunna räknas ut utan internet.
Det är tänkt att displayen kan ha internetuppkoppling innan en resa har påbörjats, men därefter ska applikationen kunna fungera utan konstant uppkoppling. När displayen har internetuppkoppling ska det vara möjligt att uppdatera kartan som finns nedladdad, till exempel med kartbilder för nya områden. Med internetuppkoppling ska applikationen även kunna ladda ner vägbeskrivningar och körinstruktioner för de rutter som finns in- stallerade. Ett antagande som görs är att det finns internetuppkopping vid återvinnings- centralen där sopbilen är parkerad, för att applikationen ska kunna uppdatera informa- tion som ska kunna användas offline. Offline-läget kan testas genom att stänga av inter- netanslutningen på datorn och enbart använda displayens inkopplade GPS-mottagare.
7.3 Krav på användargränssnittets estetik
Eftersom applikationen är tänkt att användas i demonstrationssyfte för CrossControls
kunder, är det viktigt att den har ett tilltalande utseende som ger ett professionellt och
modernt intryck. I CrossControls interna grafiska profil [4] beskrivs hur färger, bilder
och layout används för att skapa en sammanhängande bild av företagets produkter. Den
grafiska profilen beskriver bland annat hur CrossControl ska presenteras med en ren
design som kommunicerar en “industriell känsla”. Applikationen ska ha ett utseende
som följer den grafiska profilen för att skapa enhetlighet när applikationen visas upp för
kunder. Estetik utvärderas genom att låta CrossControl bedöma designen.
8 Implementation
Figur 4 Produktbild på CCpilot VS från CrossControls hemsida. Gränssnittet på bilden visar ett exempel på hur CrossControls grafiska profil kan följas.
8 Implementation
Det här avsnittet går igenom hur applikationen är implementerad. Detta inkluderar ap- plikationens karta, navigeringsläge, rutter, ruttoptimering, zonindelning, turn-by-turn- navigering och offline-läge.
8.1 Karta och navigeringsläge
När applikationen starts möts användaren av interaktiv karta. Kartan styrs med svep- rörelser för att flytta runt till andra delar av kartan eller zooma in och ut. Därefter kan kartan åter centreras på den nuvarande positionen med knappen “My location” i väns- termenyn.
Kartan är implementerad med Qt Location
6, ett API i Qt med olika navigeringsfunktio-
ner och stöd för att rita upp interaktiva kartor. Qt Location är inte bunden till en specifik
karttjänst, utan går att använda med många olika tjänster som Qt stödjer [36]. Exempel
på tjänster som kan användas är Mapbox och OpenStreetMap. Qt Location ger tillgång
till en liknande uppsättning funktioner oberoende av vilken av tjänsterna som väljs. Det
innebär för att exempelvis starta en navigering mellan två punkter kan samma funktion
8 Implementation
Figur 5 Navigering i CrossDump med karta och körinstruktioner som visas för använ- daren. I övre vänstra hörnet visas nästa manöver och i nedre högra hörnet visas nästa destination. Användarens position markeras med en blå pil på kartan. Mapbox GL gör att byggnaderna på kartan kan ritas upp i 3D.
i Qt Location användas och Qt ser i bakgrunden till att de anropas på rätt sätt för varje tjänst. Utöver de basfunktioner som finns i Qt Location, har varje karttjänst även stöd för egna funktioner och tjänster. Ett exempel är Mapbox som har särskild funktionalitet för att designa egna kartstilar genom Mapbox Studio [20]. Varje kartstil beskriver vilka färger kartan ska ritas upp med och om den ska visas med till exempel satellitbilder eller 3D-byggnader. Kartstilen designas med Mapbox Studio för att ge kartan ett specifikt ut- seende. Den sparade kartstilen kan sedan användas i programmet genom att i Qt hänvisa till den.
Navigeringsläget (Figur 5) är applikationens centrala del och används den största delen av tiden när applikationen körs. I navigeringsläget visas kartan med information om vilka sopplatser som ska besökas härnäst. Navigeringsläget startas genom att välja en av ett flertal förbestämda rutter och sedan klicka “Start”.
Kartan och navigering är frikopplade från andra delar av programmet, som zonindel-
ning, så de kan lätt återanvändas om man vill anpassa applikationen till andra industrier.
8 Implementation
8.2 Turn-by-turn-navigering
I navigeringsläget ska en kommande körmanöver visas i god tid på skärmen, till exempel att användaren ska sväng höger om 500 meter. Körinstruktioner hämtas via Qt:s API från OpenStreetMaps servrar. För att visa hur långt det är kvar till nästa manöver krävs ett sätt att veta hur långt på en sträcka föraren har färdats.
Figur 6 En del av en körsträcka med dess punkter och linjer markerade i röd. Fordonet är markerad som en blå cirkel. Linjen som överlappar fordonet markerad i orange.
En körsträcka från en zon till är implementerad med en serie av punkter som ligger ut- med gatorna. Varje punkt tillsammans med punkten före skapar en linje, tillsammans bildar dessa linjer hela körsträckan (Figur 6). För att räkna ut vilken av dessa linjer for- donet är på representeras fordonet internt som en cirkel på kartan. Om cirkeln och linjen skär varandra betyder det att fordonet är på sin vägsträcka, och då går det att räkna ut hur långt av färden som föraren har åkt. En för stor cirkel skulle kunna missa om föraren avviker från den planerade vägen, medan en för liten cirkel kanske inte ser att föraren är på vägen om hen kör i en annan fil än vägbeskrivningen. Som en kompromiss sätts där- för fordonet till att vara en cirkel med radien 20 meter. Navigeringen behöver även veta avståndet i meter till nästa manöver. Avståndet beräknas genom att summera avståndet för alla linjer mellan förarens nuvarande plats och positionen för nästa manöver.
8.3 Rutter och ruttoptimering
Applikationen använder sig av rutter för att beskriva vilka zoner som ska besökas och
8 Implementation
under menyn “Routes” i applikationen. I menyn visas varje rutts namn och vilka zoner rutten innehåller. När föraren väljer en rutt startas navigering mellan förarens nuvarande position och den första destinationen i rutten.
Navigering hanteras i backend med hjälp av Qt Location. När navigeringen startas skic- kas en förfrågan till Qt Location att hämta körinstruktioner mellan nuvarande plats och första destinationen. Qt Location hämtar ner instruktioner med tjänsten OpenStreetMaps över internet. Instruktionerna innehåller en lista koordinater och vilka svängar som be- höver skes vid dem. Koordinaterna bildar tillsammans körsträckan. Ifall något går fel med hämtningen så försöker applikationen på nytt efter några sekunder. Informationen blir tillgänglig i frontend och kan presenteras för föraren som körinstruktioner.
När föraren kommer innanför zonens gränser öppnas en ny meny som visar hur många sopplatser som finns i området (Figur 5). Efter att föraren har besökt alla sopplatser i en zon kan föraren markera zonen som avklarad och sedan fortsätta med sin färd.
Ifall det finns fler zoner i rutten så påbörjas vägbeskrivning till nästa zon automatiskt, fram till att alla zoner är avklarade. Vägbeskrivningen hämtas från internet, och kräver därför uppkoppling. Om inget internet finns går det fortfararande se var föraren behöver köra. Det är även möjligt att inspektera den nuvarande rutten genom att öppna menyn
“Routes” igen under navigeringens gång. Här går det nu även att avbryta rutten som påbörjats. När alla zoner är markerade som avklarade så återgår applikationen till start- läget där en ny rutt kan väljas.
Rutter i applikationen är automatiskt optimerade för att ge kortast möjliga körväg för föraren. Djupet-först-sökning används för att hitta den ordning av zoner som ger en mi- nimal körsträcka. Algoritmen innebär att alla möjliga kombinationer av rutter testas för att se vilken som ger den kortaste körsträckan (Figur 7). Algoritmen är implementerad genom att generera en lista av avstånden mellan alla par av zoner i en rutt och sedan re- kursivt skapa nya rutter där alla möjliga ordningar av zoner testas. Den zonordning som resulterar i kortast körsträcka väljs ut och presenteras för användaren i applikationen.
8.4 Indelning av sopplatser i zoner
Sopplatserna är grupperade i ett antal zoner som är manuellt inprogrammerade (“hård- kodade”) direkt i C++-koden. Sopplatserna kan grupperas efter vilken gatan de ligger på eller som en del av ett större område. Varje zon har ett tilldelat namn som används för att identifiera zonen i applikationen. Navigering i applikationen sker i huvudsak mellan zoner, snarare än sopplatser, och förarna får mer frihet i hur de ska köra väl inne i zonen.
Vid navigering till en zon används endast en punkt i den som destination: medelvärdet
av alla koordinater för sopplatserna i zonen. Det kan potentiellt bli en längre körstrecka
8 Implementation
A
B
C
Förare
1 1 1
A
B
C
Förare
2
1
2
A
B
C
Förare
3
2
1 Rutt 1
Total sträcka: 3
Rutt 2 Total sträcka: 5
Rutt 3 Total sträcka: 6
Figur 7 Tre exempel på rutter för samma uppsättning zoner, A B och C. Siffrorna på pilarna säger hur lång tid det tar att köra sträckan mellan varje par av zoner. Vi ser tydligt att rutt 1 har kortast körsträcka eftersom den tar den kortaste vägen mellan alla zoner.
Både rutt 2 och 3 leder till en onödigt lång väg och därmed en sannolikt längre tid i trafiken.
för köraren om den körningen inne i zonen resulterar i att föraren hamnar längre bort el- ler närmare nästa zon när den nuvarande zonen är avklarad. Applikationen tar i nuläget inte hänsyn till hur föraren kör inuti zonen.
Geostaket är ett sätt att avgöra om någonting befinner sig inom ett område definierat av
en geometrisk figur. Varje zon använder ett geostaket som en yttre gräns. När föraren är
inuti zonen visas positionen för varje enskild soptunna i zonen på kartan. Det kommer
även upp en meny som visar antalet soptunnor i zonen för att göra det lättare att räkna
så föraren inte missar några soptunnor. Geostaketet är implementerat som en polygon,
som omsluter alla sopplatser i en zon. Polygonen är manuellt förinlagd eftersom det var
lättast att implementera och en algoritm skulle ha problem att se hur en zon såg ut på
bara dess sopplatser.
8 Implementation
Figur 8 När föraren befinner sig inom en zon (grått område) syns sopplatserna på kartan.
8.5 Offline-läge
För att applikationen ska fungera offline krävs det att information sparas lokalt på dis- playen. I grunden är kartan uppbyggd av en mängd olika bilder, så kallade map tiles, som representerar en specifik del av kartan på en specifik zoomnivå. Mapbox-tilläget använder en lokal databas för att spara tidigare hämtade tiles så de inte behöver hämtas på nytt. Den lokala databasen kan fyllas i förväg genom att generera de områden man önskar använda offline med ett verktyg från Mapbox som kan köras på utvecklingsdato- rerna. Map tiles laddas från databasen och visas på skärmen beroende på vilket område kartan visar och hur inzoomad kartan är på området. Skulle användaren försöka visa ett område utanför det nedladdade området behöver nya map tiles hämtas från internet.
Om applikationen inte har tillgång till internet använder systemet endast de nedladdade
bilderna för att rita upp kartan. Om körinstruktioner hämtades när applikationen hade
internetuppkoppling, så kan navigering ändå fortsätta till nästa destination utan inter-
netuppkoppling. I offline-läget skapas dock inte längre nya vägbeskrivningar mellan de
olika destinationerna. Däremot visas resterande destinationer fortfarande på kartan, så
att föraren kan navigera manuellt utan vägbeskrivning istället.
9 Utvärderingsresultat
9 Utvärderingsresultat
Det här avsnittet visar resultat från utvärderingen av CrossDump. Utvärdering har gjorts av applikationens prestanda, dess offline-stöd och dess utseende.
9.1 Utvärdering av applikationens prestanda
Figur 9 Resultat från prestandatest av de olika kartorna.
I ett jämförande test mellan kartrenderarna Mapbox GL, Mapbox och OpenStreetMap
ser man att prestandan skiljer sig (Figur 9). Figuren visar en procentsats för hur ofta
applikationen uppnår ett visst antal bilder per sekund (FPS) vid användning av de oli-
ka kartorna. I bilden syns det att Mapbox GL ger mycket mindre stabil upplevelse än
OpenStreetMap och vanliga Mapbox. Med Mapbox GL klarar inte applikationen av att
hålla 30 FPS, medan Mapbox och OpenStreetMap är över det och ibland till och med
närmare 60 FPS. Det leder till att användarupplevelsen i applikationen uppfattas som
mer “hackig” med Mapbox GL än de andra två kartrenderarna. Applikationen visade
ingen skillnad i FPS med eller utan 3D-byggnader eller mellan olika kartstilar i Map-
box GL. En teori är att den lägre prestandan hos Mapbox GL beror på att displayen inte
fullt utnyttjar hårdvaruaccelerationen som kartan stödjer.
10 Resultat
9.2 Utvärdering av offline-stöd
En karta över Uppsala finns förgenererad i applikationens lokala databas och går att visa när displayen saknar internetuppkoppling. Den nedladdade kartan går att använda pre- cis som om displayen hade internet, men om användaren flyttar kartan utanför Uppsala kan inte nya map tiles visas utan internet. Vägbeskrivning med körinstruktioner behöver laddas ner via internet vid varje zon för att kunna visas för användaren. Om displayen tappar internetuppkoppling men redan har laddat ner vägbeskrivningen när applikatio- nen var påslagen, är det möjligt att navigera till nästa destination fullständigt offline. I nuläget saknas dock stöd för att ladda ner vägbeskrivningen helt i förväg och använda den vid ett senare tillfälle, till exempel efter att displayen startats om. För en sopbil som inte har internetuppkoppling under körning har CrossDump möjlighet att ändå kunna visa upp kartan för föraren. Det går fortfarande att få information om sopplatser i zoner- na och markera en zon som färdig utan internetuppkoppling. Applikationen klarar av en tillfällig förlust av uppkoppling, men inte en hel körning utan internet. Det går inte att köra helt utan internet eftersom vägbeskrivning till nästa zon hämtas först när föraren är klar med nuvarande zon, men övrig tid behöver applikationen inte vara online.
9.3 Utvärdering av användargränssnittets estetik
CrossControl är nöjda med utseendet på CrossDump och applikationens design följer företagets interna grafiska profil. Den enligt CrossControl bra designen gör applikatio- nen lämplig att använda för att marknadsföra deras displayer och hur de kan användas för olika ändamål. CrossControl var särskilt nöjda med kartans utseende och att det fanns möjlighet att visa den med tredimensionella byggnader.
10 Resultat
Projektet levererar en fungerande navigeringsapplikation som stödjer CrossControls dis- player. Applikationen hjälper en användare att välja en rutt och navigera mellan olika platser i rutten. CrossDumps användargränssnitt är enkelt och presenterar navigerings- information för användaren så att användaren vet hur den ska åka. Applikationen visar en karta och kan ge vägbeskrivning för ett antal förbestämda rutter som användaren kan välja mellan. Alla sopplatser visas för föraren antingen som ett område markerat på kartan eller med enskilda ikoner när föraren närmar sig området med sopplatserna.
Applikationen har stöd för att visa upp en karta med vägar och tredimensionella bygg-
nader. Det fullständiga systemet med display och applikation har ännu inte testats av en
11 Diskussion
verklig sopbilsförare i en sopbil.
Projektet ger användbar dokumentation till CrossControl
7om vilka tekniska lösningar för kartfunktioner vi har använt och hur. Olika tjänster har undersökts för att till exempel visa vilka kartor som fungerar bäst och varför. Dokumentationen har syftet att underlät- ta för CrossControl ifall de utvecklar navigeringssystem på sina displayer i framtiden.
Slutligen har applikationen kunnat integreras med en display för att säkerställa att ap- plikationen fungerar på riktig hårdvara, med de hårdvarubegränsningar som följer.
Applikationen är specifikt anpassad för sopbilsförare, men givet hur koden är skriven ska den utan större ändringar gå att anpassa till andra industrier. På så sätt kan appli- kation hjälpa fler typer av förare med sina arbetsuppgifter och att minska sina utsläpp.
Arbetsuppgifter för sopförare är väldigt lika de som görs i transportindustrin, eftersom förarna i båda fallen behöver åka mellan platser och utföra olika uppgifter. Förare i transportindustrin kan därför ha nytta av applikationens många funktioner. Till exempel kan en lastbilsförare ha nytta av att ta sig mellan flera punkter med en optimerad färdväg och med körinstruktioner däremellan.
11 Diskussion
Det här avsnittet diskuterar resultatet av projektet. Applikationens användbarhet dis- kuteras kort och hur användbarheten kan testas med verkliga användare. Kartor och navigering var en central del av projektet och utgjorde en stor del av utvecklingstiden.
Det var oklart hur till exempel offline-kartor skulle implementeras och hur implementa- tionen berodde på valet av karttjänst. Att utveckla en applikation i Qt krävde också att det undersöktes hur applikationens systemstruktur skulle designas och hur backend och frontend skulle kommunicera med varandra.
11.1 Användbarhet
I nuläget har vi inte testat om CrossDump faktiskt gör det lättare för en sopbilsförare att navigera mellan platser där sopor ska hämtas. Ett fortsatt arbete skulle, utöver vidare utveckling, även kräva användartester och samtal med verkliga sopbilsförare.
7
https://github.com/AntonBergaker/crossdump/blob/master/DOCS.md
11 Diskussion
11.2 Kartor och navigering
Offline-läget i applikationen behövde testas med många olika lösningar innan det ansågs färdigt, på grund av bristande dokumentation om hur offline-kartor implementeras i Qt-applikationer. CrossControl prioriterade offline-läge under projektet, eftersom det gör det möjligt att använda displayen under fler omständigheter. Vi lyckades inte spara kartor offline med vare sig Mapbox eller OpenStreetMap, utan bara med Mapbox GL.
Mapbox GL hade tydlig dokumentation om hur offline-kartor kunde implementeras, till skillnad från Mapbox och OpenStreetMap som hade ofullständig dokumentation kring detta. Mapbox och OpenStreetMap ledde till olika tekniska problem som var svåra att lösa utan tydlig dokumentation. Till exempel var det otydligt var alla map tiles skulle placeras för att kunna användas av applikationen offline. Vi var tvungna att utveckla ett speciellt verktyg som laddade ner kartbilder och placerade dem i en filstruktur som följde ett särskilt format. Trots detta lyckades applikationen inte visa kartor offline utan att antingen krascha eller visa en blank karta.
Förutom att visa kartan offline har applikationen delvis stöd för att visa vägbeskrivning- ar offline, men det kräver att vägbeskrivningar redan har hämtats när det fanns tillgång till internet. Det finns ingen möjlighet att ändra vägbeskrivning mitt under körning, även om displayen har internetuppkoppling, så om föraren avviker från den föreslagna kör- sträckan kommer applikationen inte att beräkna om rutten. Det är ändå möjligt att få viss hjälp med att navigera utan internet, eftersom applikationen fortfarande visar de olika destinationerna på kartan. Karttjänsterna saknar möjlighet att beräkna vägbeskrivning helt på displayen, utan beskrivningarna måste alltid hämtas från karttjänsternas servrar via internet.
Eftersom CrossControl gav offline-läge högre prioritet än prestanda valdes Mapbox GL i slutändan. Mapbox GL ledde till sämre prestanda men hade bättre stöd för att installera offline-kartor på displayen. En orsak till det skulle kunna vara att displayen som stan- dard inte använder hårdvaruacceleration. MapBox GL använder också vektoruppritning istället för färdigrenderade bilder, vilket ställer högre krav på processorn ifall hårdvaru- acceleration inte finns tillgängligt. I diskussion med CrossControl bestämde vi oss för att inte lägga så mycket tid på prestandaproblemen i MapBox GL, men vi tror att det är möjligt att förbättra implementationen. Det finns dokumentation om ökad prestanda i Mapbox GL [19] och med mer arbetsinsatser på optimering bör Mapbox GL kunna leverera en lika snabb lösning som vanliga Mapbox eller OpenStreetMap. Mapbox GL har också fler funktioner som till exempel 3D-grafik och olika typer av kartstilar, vilket hjälper att förhöja användarupplevelsen.
I nuläget är geostaket ett manuellt inlagt område, men det skulle även vara möjligt för
applikationen att automatiskt räkna ut geostaketen. Ett förslag på hur det ska gå till är
11 Diskussion
att räkna ut och använda de yttre sopplatserna som hörnen i en polygon. Ett alternativ på hur man automatiskt kan räkna ut geostaketen är att använda en cirkel med genomsnitts- värdet för alla sopplatsers koordinater som sin mittpunkt. Radien på cirkeln skulle då bero på avståndet till den sopplats som befinner sig längst bort. En risk med att beräkna geostaketet med en cirkel och radie är att zoner som ligger nära varandra kanske skulle visas med överlappande områden på kartan.
De förbestämda rutterna måste programmeras in manuellt direkt i C++-koden som koor- dinater, vilket gör rutterna svåra att ändra för användaren. För att göra rutterna lättare att ändra skulle de kunna läsas in från en fil med ett format som till exempel JSON [7]. Då hade det varit lättare för en arbetsledare att ändra koordinater, eller att låta arbetsledaren placera zoner direkt på kartan med ett annat program. Det är omöjligt för en arbetsle- dare att förutspå alla trafiksituationer som kan uppstå. Därför är det också rimligt att ge föraren möjligheten att planera egna rutter direkt i applikationen.
11.3 Systemstruktur
Under projektet var det flera tillfällen där kod behövde översättas manuellt från QML och JavaScript i frontend till C++ i backend. C++-kod måste vara mer strikt skriven och ta hänsyn till minneshantering, men ger mycket bättre prestanda. Denna kodöversätt- ningen tog ofta mycket längre tid än väntat. Till exempel för att göra C++-kod tillgäng- lig i QML krävs det att koden är utformad på ett specifikt sätt. QML är event-baserat, vilket innebär att C++-kod alltid måste meddela när värden på delade variabler har änd- rats. För att C++ ska meddela om de ändrade variablerna använder Qt olika makron, färdiga bitar kod som klistras in automatiskt av C++-kompilatorn. Hur varje makro är implementerad är dolt för utvecklaren, så det kan vara svårt att veta om de har använts på rätt sätt.
Ett återkommande problem under utvecklingen var att skicka data i form av listor mel- lan backend och frontend. Qt:s dokumentation om hur man skickar en lista från C++
till QML var svår att tyda, vilket gjorde det svårt att snabbt få en fungerande lösning.
Lösningen krävde en stor bit kod som behövde upprepas för varje enskild lista som be- hövde vara synlig i frontend. Det innebar dessutom att ändringar i listorna krävde många ändringar i denna kod vilket gjorde små ändringar svårare.
Det skulle vara möjligt att ändra från OpenStreetMap till Mapbox i navigeringen som
ligger i backend. OpenStreetMap valdes då det var lättare att implementera i början av
projektet, men nu när vi vet mer om Mapbox ser vi att det skulle gå att använda även i
backend. Denna ändring valdes att inte utföras eftersom inte fanns någon direkt fördel
13 Framtida arbete
12 Slutsatser
CrossDump är specifikt gjord för att guida sopbilsförare genom en optimerad rutt som täcker arbetspassets alla sopplatser, med hjälp av karta och navigation. En kortare kör- sträcka minskar utsläpp och tid i trafiken. Applikationen visar hur det är möjligt att utveckla ett navigeringssystem för CrossControls displayer som går att använda i mo- derna industrifordon.
Projektet har identifierat en fungerande kart- och navigeringslösning till displayerna och kan med vidare utveckling användas av ett avfallshanteringsföretag. Vi har även under- sökt hur man bäst implementerar kartfunktionalitet i ramverket Qt. Främsta bidraget i projektet är att när CrossControl eller någon annan aktör själva vill genomföra något liknande, så finns det en startpunkt. CrossDump visar också hur det är möjligt att ut- veckla ett navigeringssystem för CrossControls displayer. Applikationen innehåller oli- ka funktionalitet som kan vara användbara inom andra branscher, inte bara för sopbilar då navigering mellan flera punkter är vanligt.
Hela projektet finns som öppen källkod på GitHub
8. Förutom programkod finns det dokumentation om hur applikationen kan användas, till exempel instruktioner för hur offline-kartor kan genereras och användas.
13 Framtida arbete
Det här avsnittet går igenom förslag på hur projektet kan vidareutvecklas. Det innefattar det som kan uppdateras i den nuvarande implementationen, saker som kan läggas till, och mer omfattande förändringar av det nuvarande systemet.
Den viktigaste framtida utvecklingen i applikationen är optimera prestandan av Mapbox GL som används för att rita upp kartan på skärmen. Mapbox GL presterar sämre än andra karttjänster som går att använda i Qt, men den valdes ändå på grund av andra tekniska fördelar. För att optimera applikationen så att den når högre prestanda med Mapbox GL, behöver främst prestanda för kartans rendering undersökas. Prestandan kan potentiellt förbättras genom att ändra hur kartbilder genereras.
En kritisk förbättring för att göra offline-läge mer användbart är att kunna visa vägbe- skrivningen utan internetuppkoppling. I nuläget kräver displayen internetuppkoppling vid varje zon för att uppdatera vägbeskrivningarna, men det finns redan möjlighet för själva kartan att visas offline. En möjlig lösning för att visa vägbeskrivning offline är att
8
