Department of Science and Technology Institutionen för teknik och naturvetenskap
Linköping University Linköpings universitet
LiU-ITN-TEK-G--15/074--SE
Styrsystem för automatiserad
industri tillämpad med LEGO
Mindstorms
Kristofer Jaxne
LiU-ITN-TEK-G--15/074--SE
Styrsystem för automatiserad
industri tillämpad med LEGO
Mindstorms
Examensarbete utfört i Elektroteknik
vid Tekniska högskolan vid
Linköpings universitet
Kristofer Jaxne
Handledare Ole Pedersen
Examinator Kjell Karlsson
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
Linköpings universitet, Campus Norrköping Institutionen för teknik och naturvetenskap (ITN) 2015
Examensarbete
Styrsystem för automatiserad
industri tillämpad med LEGO
®
Mindstorms
®
Kristofer Jaxne Elektronikdesign
Abstract
The purpose of this report is to present a bachelor thesis in electric engineering. The work have aimed to create a model of an automated industry in a small scale. The model
should be simple to use for visualization of how automated industries operate and how control system is designed.
To realize a well created realistic model first a study of real cases in the industry was made and also methods for optimization. Because of the need for simplicity the control system was designed from scratch to have full control over functionality.
A model was built using LEGO® Mindstorms® as a mechanical base and two robots
where programmed in C# to handle a small order flow. The order flow was controlled from a web based GUI and the communication was handled in a database.
Sammanfattning
Syftet med denna rapport är att redovisa ett examensarbete på kandidatnivå inom
elektronik. Arbetet har syftat till att skapa en modell av en automatiserad industri i en liten skala. Modellen skulle vara enkel att använda för att visualisera hur automatisering
fungerar i praktiken och hur ett styrsystem byggs.
För att få ett bra genomförande och en verklighetstrogen modell studerades exempel från industrin och metoder för att optimera. Eftersom enkelhet var viktigt byggdes
styrsystemet från grunden för att få full kontroll över systemet.
En modell byggdes med LEGO® Mindstorms® som mekanisk grund och två robotar
programmerades i C# att hantera ett orderflöde. Orderflödet styrdes från ett webbaserat användargränssnitt och kommunikationen hanterades genom en databas.
Innehållsförteckning
1. Introduktion
1
1.1 Bakgrund 1 1.2 Syfte 1 1.2.1 Huvudmål 1 1.2.2 Delmål 1 1.3 Frågeställning 2 1.4 Metod 21.4.1 Modell av automatiserad processindustri 2
1.4.2 Hårdvara 3 1.4.3 Mjukvara 3 1.4.4 Utvecklingsmiljö 3 1.4.5 Processoptimering 4 1.5 Avgränsningar 4
2. Teoretisk utgångspunkt
5
2.1 Automatiserade produktionssystem 5 2.2 Lean 52.3 Hårdvaruplattformen LEGO® Mindstorms® 6
2.3.1 Introduktion till LEGO® Mindstorms® 7
2.3.2 Mindstorms® EV3 tekniska specifikationer 8
2.4 Mjukvaruutveckling 8
2.4.1 Objektorienterad programmering i C# 8
2.4.2 Serverscript med PHP 9
2.4.3 Databashantering med MySQL 9
2.4.4 Webblayout med HTML, CSS och Javascript 9
2.5 Kommunikationsgränssnitt 9 2.5.1 Bluetooth 10 2.5.2 TCP/IP 10
3. Utvecklingsarbete
11
3.1 Övergripande systembeskrivning 11 3.1.1 Delsystem 12 3.2 Hårdvarudesign 13 3.2.1 Mekanisk uppbyggnad 133.2.2 Sensorlayout 15 3.3 Mjukvaruutveckling robotsystem 16 3.3.1 Utvecklingsmiljö 16 3.3.2 Monobrick firmware 16 3.3.3 Mjukvarudesign 17 3.3.4 Robotkommunikation 18
3.3.5 Styrsystem och övervakning 19
3.3.6 BIST 19
3.4 GUI-design 19
3.4.1 Webbgränssnitt 20
3.4.2 Databaslayout 20
3.5 Beräkningsfunktioner för AI och optimering 23
3.5.1 Struktur för AI-utveckling 23
3.5.2 Beräkningsfunktioner för optimering 24
4. Implementation och test
26
4.1 Sammansättning av delsystem 26
4.2 Testning 26
4.2.1 Testscenarion 26
4.2.2 Datainsamling 28
4.3 Granskning av expansionsmöjligheter 28
5. Resultat och analys
30
5.1 Resultat 30 5.2 Analys 31
6. Avslutande diskussion
33
6.1 Diskussion 33 6.2 Slutsatser 34 6.3 Framtida arbete 34Referenser
35
Bilaga 1. Källkod robot 37
Bilaga 2. Beskrivning av använda MonoBrick-funktioner 65
Bilaga 3. Källkod för robotarnas databaskommunikation 66
Figurförteckning
Figur 1. LEGO® Mindstorms® EV3 Education hårdvaruplattform 7
Figur 2. Grundläggande skiss över systemets mekaniska uppbyggnad 11 Figur 3. Flödesschema för tänkt arbetsprocess vid ny arbetsorder 12
Figur 4. Roboten RoboTransport 14
Figur 5. Roboten RoboArm 15
Figur 6. GUI i medelstor och liten skärmstorlek 21
Figur 7. Informationsflöden 21
Figur 8. Tabellöversikt och databasrelationer 22
Tabellförteckning
Tabell 1. Teknisk specifikation för LEGO® Mindstorms® EV3 8
Sammanställning över förkortningar
AI Artificiell intelligens
BIST Built in self test
CSS Cascading Style Sheets, stilmall FIFO First in, first out
GUI Graphical user interface, grafiskt användargränssnitt
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
PHP PHP: Hypertext Preprocessor
1. Introduktion
1.1 Bakgrund
I dagens högteknologiska samhälle används automatiserade system mer och mer som hjälpmedel i det dagliga livet på många olika områden. Inom industrin är det oerhört viktigt med autonoma system för repetitiva uppgifter om en effektivitet och
konkurrenskraft skall erhållas. Många arbetsuppgifter i industrin kan vara påfrestande för den mänskliga kroppen och kan med fördel utföras av automatiserade robotsystem. Personal är en dyr utgift medan automatiserade system endast är dyra i inköp, men billigare i drift. Att låta robotar utföra repetitiva uppgifter är dessutom mer humant då det är väldigt slitande på människor.
Men hur upprättas ett sådant system från grunden? Går det att göra en modell av ett sådant system som lätt kan åskådliggöras på ett så enkelt sätt att det kan användas i utbildningsmiljö och samtidigt vara utbyggbart nog att möjliggöra användande även i större skala?
1.2 Syfte
Examensarbetet syftar till att granska möjligheterna att skapa en modell av en automatiserad industri på enkelt vis för att studera styrsystem för automatisering i produktionsmiljö.
Detta projekt syftar till framtagande av ett autonomt robotsystem för en modell av en enklare industrimiljö. Systemet ska vara enkelt nog att kunna åskådliggöras på en industrimodell byggd av LEGO® byggelement men samtidigt avancerat nog att kunna
byggas ut för användande i större skala med flera robotiserade delsystem. Systemet måste därmed utvecklas med ett modernt industritänk som möjliggör optimering och anpassning efter Lean för att kunna ge realism. Genom att skapa en genomtänkt
standardisering för kommunikation mellan delsystem möjliggörs en utbyggnad som kan användas för att sätta upp exempelmiljöer för flertalet tillämpningar. Det kan tänkas vara tillämpningar så som att i utbildningsmiljö experimentera med att bygga modeller av miniindustrier för att praktisera flödesoptimering eller på lägre utbildningsnivå bygga modeller av industrier för att väcka intresse för styrsystem. Det kan även tänkas användas av industriföretag som med en enkel modell vill visa hur till exempel databassystem för lagerhantering eller systemövervakning kan implementeras i robotsystem utan att behöva använda en dyr och utrymmeskrävande fabrik.
1.2.1 Huvudmål
Det huvudsakliga målet som skall uppnås är att skapa en modell av ett industriflöde med ett fullt fungerande styrsystem. Systemet måste vara avancerat nog för att efterlikna realistiska system till den grad att det skulle kunna användas som styrsystem i en riktig fabrik med enklare modifieringar. Kommunikationsgränssnittet som används måste även konstrueras på ett sådant vis att det kan definieras en standard som är användbar för expandering av systemet.
1.2.2 Delmål
Huvudmålet för projektet kan delas upp i ett antal delmål för att enklare visualisera projektets genomförande.
• Konstruera fungerande delsystem bestående av hårdvara och mjukvara. • Upprätta kommunikation och integration mellan delsystemen.
• Skapa ett GUI för kontroll av de sammansatta systemet och för inhämtning av status från de automatiserade robotarna.
• Utveckla beräkningsfunktioner för optimering av systemet.
• Utforma en kommunikationsstandard som möjliggör expansion på ett ändamålsenligt sätt för att uppnå huvudmålet.
1.3 Frågeställning
För att kunna genomföra projektet behöver en förståelse för automatisering av industrier bildas. Hur en automatisering planeras och optimeras är viktiga begrepp för ett lyckat resultat. Möjligheterna till att tillämpa Lean i liten skala kommer även granskas.
För robotarnas rörelsemönster i det automatiserade systemet skapas fler frågor som måste besvaras. Huruvida ett omvandlat koordinatsystem för varje robots rörelser är lämpligt och möjligt att tillämpa måste tas i beaktning. Exemplet med en robotarm bestående av flera leder (3.2.1) kommer vara det fall där detta blir mest aktuellt.
Nästa punkt som väcker frågeställningar är hur en bra kommunikation mellan delsystem i ett automatiserat större system upprättas. Dels så måste en bra lösning för
kommunikation mellan robotarna utformas, men även ett sätt att kommunicera med styrsystem. Det måste dessutom vara driftsäkert och pålitligt.
Slutligen så är artificiell intelligens, AI, ett område som kommer att beröras. Men hur man går till väga för att skapa ett tillförlitligt AI är inte självklart. Vilken problematik som måste tas hänsyn till kommer att undersökas.
1.4 Metod
Detta avsnitt beskriver hur projektet kommer att lösas i praktiken. En uppdelning har gjorts för att åskådliggöra hur olika områden kommer att behandlas för att förtydliga vilket tillvägagångssätt som kommer att användas.
1.4.1 Modell av automatiserad processindustri
För att möjliggöra systemutvecklingen behövs en modell av en automatiserad industri med robotar. Modellen måste vara enkel för att inte uppta för stort fokus i projektet så det finns mer utrymme för styrsystemet. Modellen kommer att byggas med LEGO® Technic
byggelement och processorenheter från LEGO® Mindstorms®. Genom processorenhetens
anslutningsmöjligheter går det att upprätta kommunikation genom bland annat Bluetooth och TCP/IP. Detta kommer att användas för att utveckla kommunikationssystem för kontakt mellan olika delar i automatiseringen och med ett styrsystem.
Systemet kommer att bestå av följande tre delar; mekaniska motoriserade funktioner, programmerbar styrning av mekaniken och ett centralt system för styrning och
övervakning. Mekaniken, och den programmebara styrningen, kommer i sin tur att delas upp i mindre delsystem som hanterar olika uppgifter. Varje delsystem måste kunna utföra sin uppgift på ett optimerat tillvägagångssätt och läsa in sensorvärden från omgivningen för att säkerställa att delsystemet uppträder som förväntat. Delsystemen måste även kunna kommunicera med varandra och tillsammans beräkna hur de tillsammans löser den tilldelade uppgiften på bästa vis utan komplikationer. Detta ställer höga krav på den
1.4.2 Hårdvara
Genom att använda LEGO® Technic byggelement för de mekaniska delarna av systemet
så förenklas arbetsprocessen. Med ett stort utbud färdiga byggelement för mekanik så blir konstruktionsarbetet mindre tidskrävande så att fokus kan ligga på
systemutvecklingen. Det går då även enkelt att använda processorenheter av typen LEGO® Mindstorms® EV3. Produktserien från Mindstorms® innehåller även ett tillräckligt
stort utbud av motorer och sensorer för att motsvara alla uppställda krav på hårdvara. EV3 är den tredje generationens processorenhet i serien Mindstorms® från LEGO
Gruppen. Processorenheten EV3 är utvecklad med open source (öppen källkod) och möjliggör därmed avancerad utveckling där användaren själv kan anpassa
komplexitetsnivån. I detta projekt kommer den interna programvaran bytas ut mot en externt utvecklad firmware som möjliggör objektorienterad utveckling på en mer
djupgående nivå med mer kontroll över systemet än med den medföljande programvaran. Processorenheten EV3 har även goda möjligheter för externa anslutningar via Bluetooth och TCP/IP.
1.4.3 Mjukvara
Mjukvaruutvecklingen delas upp i två delar eftersom det blir två avskilda system för olika ändamål. Först och främst så måste processorenheterna för hårdvaran programmeras med sina styrsystem, och sedan tillkommer användargränssnittet som även fungerar som kontrollsystem för det sammansatta systemet som helhet.
Processormjukvara
Tack vare att processorenheten EV3 är utvecklad med open source möjliggörs mer avancerad utveckling. I detta projekt kommer den interna programvaran bytas ut mot en externt utvecklad firmware som möjliggör objektorienterad utveckling på en mer
djupgående nivå med mer kontroll över systemet än med den medföljande programvaran. Varje processor kommer att programmeras med styrsystem för den ansluta mekaniken, och även med kommunikationslösningar enheter emellan och med styrsystem.
Kommunikationsgränssnitt som används blir Bluetooth för kommunikation processorer sinsemellan, och TCP/IP för kommunikation med styrsystem.
Det är här som stor del av projektets fokus kommer att ligga, både för att det är en väldigt vital del, och även för att projektets nivå styrs mycket av funktionaliteten på
processormjukvaran.
Användargränssnitt och styrsystem
För användargränssnittet kommer ett enkelt webbaserat GUI, Graphical User Interface, att skapas för en mobilitet som behövs för att uppnå ett industriellt och framtidssäkert tänk. Genom att använda ett webbaserat system kan styrning och övervakning ske via flera typer av enheter så som datorer, surfplattor och smartphones. Dessutom kan
övervakning och styrning då ske ifrån flera enheter samtidigt parallellt. Då processorerna kommunicerar med styrsystemet via TCP/IP så är en internetbaserad databas för styrning och lagring en väl vald lösning för att ha enkel åtkomst till GUI från olika enheter.
1.4.4 Utvecklingsmiljö
Eftersom delsystemens olika mjukvara är baserad på skilda tekniker så kommer flera olika utvecklingsmiljöer att tillämpas. Processormjukvara och styrsystemet med GUI blir två åtskilda lösningar som utvecklas separat, men databasen anpassas för att fungera ihop med de båda delsystemen.
Processormjukvaran kommer att utvecklas med objektorienterad programmering i C# för att få ett kraftfullt språk som med rätt firmware i processorenheterna blir hårdvarunära. Genom att välja så hårdvarunära programmering som möjligt så blir kontrollen över systemets funktionalitet stor, och mjukvaran kan optimeras till stor grad.
Användargränssnittet och övervakningssystemet, som blir webbaserat, måste
programmeras med ett scriptspråk som körs direkt på webbservern. I detta fall är PHP ett lämpligt språk då det är standard på många webbservrar och dessutom är kraftfullt nog för en sådan här tillämpning. Gränssnittet ut mot användaren blir självklart utvecklat med HTML, CSS och JavaScript eftersom det blir ett webbaserat gränssnitt.
När det gäller databasen så måste åtkomst möjliggöras både från processorerna och från styrsystemet. Detta löses i princip automatiskt genom att integrera databasen i
webbservern för styrsystemet. För webbservrar konfigurerade för PHP så är
standardlösningen att använda databaser i MySQL, så detta blir en bra lösning även här.
1.4.5 Processoptimering
Något som är viktigt när det handlar om automatiserade system i en industriell miljö är effektivitet. Oftast är det kostnadseffektiviteten som är det avgörande vid införskaffandet av ett automatiserat system. För att få en god realism bör även detta projekts modell optimeras för en god effektivitet. Lämplig optimering i detta projekt är effektivisering av styrsystem och kommunikation som kommer att vara en viktig del. Det kommer även att granskas vilka möjligheter det blir att optimera styrningen av mekaniska funktioner med hjälp av konverterade koordinatsystem för ledade robotarmar.
1.5 Avgränsningar
Projektets huvudsakliga fokus kommer att ligga på programmeringen, dels styrsystemets mjukvara, och även mjukvara för styrenheterna till delsystemen. Eftersom projektet kommer använda sig av en modell baserad på LEGO® Mindstorms® byggelement och
processorenheter medför det i sig begränsningar i form av möjliga anslutningar per processorenhet för styrning av motorik och sensoravläsning. Denna begränsning skapar en utmaning men i detta fall bidrar det till att avgränsa omfattningen med datainsamling under drift för att förenkla systemet.
Då den mekaniska modellen förenklas och begränsas på detta vis och med projektets fokus, så kommer ingen mekanisk optimering att tas i någon större beaktning.
Utöver processorenheternas begränsningar så kommer projektet avgränsas med att endast omfatta ett fåtal enheter, uppskattningsvis två till tre stycken, då det räcker för att erhålla en lämplig komplexitetsnivå.
Systemet kommer slutligen avgränsas med att ingen större hänsyn till datasäkerhet kommer att behandlas. Projektet kommer att förutsätta att anslutningar är skyddade från intrång och avlyssning på en lägre system- och utrustningsnivå.
2. Teoretisk utgångspunkt
2.1 Automatiserade produktionssystem
I dagens samhälle eftersträvas hög effektivitet inom industrin, både för att få en ökad vinst, och även för att effektivisering kan minska resursslöseri och vara en god gärning för vår miljö och natur. Ett viktigt begrepp för effektivisering är automatisering vilket är en viktig del i den industriella utvecklingen nu. Med automatisering går det att få en bättre kontroll över en industris processer då även informationsinsamling kan automatiseras för att åstadkomma en god optimering av industrin.
Sedan industrialiseringens början har samhällsnyttan varit väldigt stor. Om man ser till de största OECD-länderna så framgår det tydligt att industrialiseringen lett till att
produktivitet och sysselsättning tillsammans med BNP stigit framgångsrikt [1]. Industrialiseringen som idag pågått i över ett sekel har kommit långt och det som är aktuellt i dagsläget är automatisering med uppkopplade maskiner. Det talas om Industri
4.0, den fjärde industriella revolutionen. Begreppet är myntat i Tyskland, där det satsas
hundratals miljarder årligen för att bli världsledande på området [2]. Med den aktuella industriella revolutionen Industri 4.0 så gäller det för industriföretag att hänga med i den tekniska utvecklingen. Framtidens producerande maskiner blir ständigt uppkopplade och anses vara det man vardagligen kallar smarta. Varje produkt i produktkedjan kan bära med sig information om vart den ska och hur den ska processas för att fabriken själv ska kunna organisera ett optimerat flöde. Detta ger högre flexibilitet med bland annat kortare omställningstider och färre fel. Ju smartare mjukvara i robotarna och maskinerna som utgör industrin, desto bättre effektivisering kan göras.
Ytterligare en viktig punkt i ett modernt automatiserat system är tillgängligheten. Styrning och administration måste även det vara flexibelt om effektiviseringen ska nå en hög standard. För en god flexibilitet måste det gå att nå systemet var än operatör och administratör är. Ett internetbaserat styrsystem som går att nå från webbläsaren på en uppkopplad dator eller surfplatta är att rekommendera. Större tillgänglighet än så är svår att uppnå i dagsläget. Ett bra exempel är pappersbruket Swedpapper i Gävle där hela bruket kan styras från en surfplatta var den än är i världen så länge den har
internetuppkoppling [3]. Det går att följa produktionen likväl som det går att administrera flödet eller lägga arbetsordrar, utan att vara på plats i fabriken. En bra förebild för en modern automatiserad industri.
2.2 Lean
LEAN är ett industriellt arbetssätt för processeffektivisering utvecklat av japanska Toyota Motor Corporation. Toyota Production System, TPS, har utvecklats i över hundra år för att bli det som idag kallas LEAN [4]. Redan år 1896 lanserade Sakichi Toyoda en
automatiserad vävstol som revolutionerade textilindustrin. Vävstolen hade en unik
funktion som gjorde att produktionen automatiskt stoppades om tråden gick av. På så vis kunde felsökning snabbt ske för att hitta orsaken till stoppet och för att minska framtida risker för samma problem. Denna arbetsmetod var en del av grunden för att sätta upp en framgångsrik bilindustri för Toyota som efter andra världskrigets slut hade stora behov av återuppbyggnad. Kiichiro Toyoda, som grundade Toyota Motor Corporation 1937, såg då till sin far Sakichis filosofi från textilindustrin som kunde översättas till ”automation with a
identifiera problem. Detta blev tillsammans med tankesättet i-rätt-tid de viktigaste grundstenarna i basen för Toyotas produktion.
I-rätt-tid fokuserar på att allt material ska anlända till produktionsenheten i rätt tid för att
skapa ett konstant flöde genom produktionen. Med ett sådant flöde minskas de interna lagren och på så vis erhålles även en lägre kapitalbindning. Toyota lade stort fokus på flödeseffektivisering.
Toyotas interna produktionsfilosofi, som kallades Toyota Production System eller TPS, utvecklades vidare inom Toyota i närmare hundra år innan det började spridas världen över. Det var under slutet av 1980-talet som omvärlden började intressera sig mer för Toyotas koncept [4]. Lean har efter detta fått stor spridning, framförallt inom
produktionsindustrin, men även inom sjukvården [5].
Tanken med Lean är att fokus hela tiden ska ligga på rätt delar. Kunden står i centrum och det är kundens önskemål som ska uppfyllas. Vad kunden vill ha och när kunden vill få en leverans är viktigt att ta med i beaktning när det gäller Lean. Samtidigt som det
ekonomiskt optimeras genom att produktion endast sker på beställning, för att minimera slöseri och kapitalbindning. För att kunna genomföra detta behövs god kommunikation genom hela processflödet samtidigt som flödet måste vara tydligt visuellt för alla
inblandande. Jeffrey Liker, som är professor inom industriell ekonomi, har i sin bok The
Toyota Way listat några principer som är karakteristiska för Lean production [6]. Några av
dessa, vilka är relevanta för detta projekt, är listade nedan. - Kontinuerliga processflöden för att identifiera problem. - Producera enbart till order för att undvika överproduktion. - Utjämnad arbetsbelastning.
- Låt processer stoppas för att reda ut problem direkt.
- Använd visuell styrning för att tydliggöra processer och problem som uppstår. - Använd pålitlig beprövad teknik som passar processer och medarbetare. Utöver dessa principer finns även några begrepp som fokuserar på vad som skall undvikas för att minska slöseri.
- Överproduktion - Tillverka enbart efter behov. - Väntan - Undvik kostsam tid utan aktivitet. - Lager - Undvik att lagra mer än nödvändigt.
- Omarbete - Gör rätt från början eftersom omarbete är kostsamt. - Överarbete - Gör inte mer än kunden önskar.
- Transporter - Undvik onödiga transporter.
I Lean är det stort fokus på att undvika slöseri och aktiviteter som inte ökar värdet på produkten ses som onödigt slöseri. Genom att undvika onödigt arbete och kostsamma moment effektiviseras flödet och processerna optimeras.
2.3 Hårdvaruplattformen LEGO
®Mindstorms
®Den modell som används i detta projekt kommer i hårdvaran att helt baseras på LEGO®
byggelement och den mekaniska styrningen kommer ur produktserien LEGO®
Mindstorms®. Detta avsnitt kommer därför att ge en introduktion till plattformen och
berätta lite om utvecklingen till den produkt det är idag. Detta för att ge en god översikt över plattformen och därmed en med ingående förståelse för projektet.
2.3.1 Introduktion till LEGO® Mindstorms®
Leksaksföretaget LEGO har som världens femte största leksakstillverkare länge varit marknadsledande när det gäller framförallt byggklossar av plast [7]. De har ständigt utvecklat sitt sortiment med nya koncept och med ny teknologi. Under lång tid har LEGO även tillverkat produkter som riktar sig till utbildningssektorn. 1989 släpptes LEGO® Dacta
[7] som främst riktar sig till tekniklektioner på högstadienivå. Konceptet visade sig fungera så LEGO fortsatte arbetet med de lite mer tekniskt avancerade produkterna för att förse lärosäten med bra och lärorika hjälpmedel. När sedan LEGO® Mindstorms® Robotic
Invention System 1.0 lanserades 1998 så gjordes det då med två inriktningar. Det skulle inte längre bara rikta sig till skolor och utbildning, utan även till konsumentmarknaden. Det blev en eftertraktad produkt som intresserade så väl barn som skolor och även ingenjörer [8].
Under de svåra åren med en förändring i leksaksmarknaden under millennieskiftet märkte LEGO hur de vuxna användarna hackade deras Robotkit. Eftersom över hälften av alla användare av Mindstorms är vuxna så fanns det många med avancerade tekniska kunskaper. De insåg hur de kunde ha stor användning av att lyssna till användarna och erbjöd produkter i utbyte mot idéer. [9] Utvecklingen gjorde stora framsteg och var en av viktiga faktorer till att LEGO åter kunde stärka sitt varumärke igen. Med de nya idéerna utvecklades andra generationens Mindstorms, NTX, som blev en ännu större succé när det släpptes 2006. Utvecklingen ledde vidare med den nu aktuella tredje generationen, EV3, som lanserades sommaren 2013, se figur 1. För att bemöta önskemålen från användarna ännu mer så valde LEGO att göra EV3 med öppen källkod, Open Source. Med de förutsättningarna kan Mindstorms användas i ännu fler områden och med mer avancerade utföranden, vilket detta projekt kommer att visa.
Figur 1. LEGO® Mindstorms® EV3 Education, motorer och sensorer inkopplade i processorenheten.
Valet av plattform till Mindstorms medför många möjligheter med dess tekniska höjd de har uppnått. Plattformen har flitigt använts även inom högre utbildningar för att enkelt visualisera viktiga principer inom teknisk utveckling. Undersökningar har visat att inlärningen kan öka som ett resultat av användandet av Mindstorms som plattform för kurser inom högre tekniska utbildningar [10]. Mindstorms är kraftfullt nog att användas till såväl signalbehandling i kurser inriktade på signaler och system [11] som i utbildningar i artificiell intelligens [12].
2.3.2 Mindstorms® EV3 tekniska specifikationer
Detta avsnitt beskriver de tekniska specifikationerna för LEGO® Mindstorms® EV3. Detta
för att ge en god uppfattning om hårdvaruplattformen som används. Relevant information listas nedan i tabell 1 med data hämtad från EV3 Användarmanual [13].
Tabell 1. Teknisk specifikation för LEGO® Mindstorms® EV3.
Processor Texas Instruments Sitara AM1808 Procesorkärna ARM9
Processorhastighet 300 MHz Arbetsminne, RAM 64 MB Lagringsminne, Flash 16 MB
Plats för utökat minne micro SDHC, max 32 GB
Display Monokrom LCD 178 x 128 pixlar Sensoringångar 4
Motorutgångar 4 Inbyggda knappar 6
Externa anslutningar USB 2.0 device, USB 1.1 Host, Bluetooth v 2.1, WiFi (via USB-dongle)
Operativsystem LINUX
Kraftförsörjning 6 AA-batterier eller 10 V LEGO laddbart batteri
2.4 Mjukvaruutveckling
I ett automatiserat system är mjukvaran en väldigt vital del som utgör grunden för hur pass intelligent systemet kan anses vara. För att realisera detta projekt behöver stort fokus ligga på mjukvaruutveckling. Flera mjukvaror i olika delar av systemet måste interagera ihop för att slutresultatet ska bli det önskade. Eftersom det är flera delsystem som skiljer sig stort med olika uppgifter och funktionalitet så delas mjukvaruutvecklingen in i flera delar.
2.4.1 Objektorienterad programmering i C#
Viktigast av alla delsystem är robotarnas mjukvara. Robotarna kan ju utvecklas att styras utan externt styrsystem, men styrsystemet kan inte utföra några praktiska uppgifter utan robotarna. Mjukvaran i robotarna utvecklas i objektorienterad C#. Objektorienterad programmering blir tydligare strukturerat för projekt av denna storlek då fokus ligger på funktioner i koden och databehandling snarare än bakomliggande processer. C# som programmeringsspråk kommer att användas dels för att det är ett kraftfullt språk och även till stor del då det finns bra stöd för styrning av plattformen Mindstorms tack vare
2.4.2 Serverscript med PHP
Nästa del i detta projekt är gränssnittet mot användaren, som i detta fall kommer att bli webbaserat. För webbaserade gränssnitt behövs dynamiska hemsidor som genereras av av serverbaserade script så att innehållet kan anpassas efter status på systemet och för möjligheter att mata in information. Ett av de numera största serverbaserade
scriptspråken är PHP. PHP står idag för PHP Hypertext Processor, där PHP ursprungligen var en förkortning av Personal Home Page. Att PHP har blivit ett av de största
serverbaserade språken beror dels på att det är lätt att lära sig, men till stor del på att det är väldigt snabbt och stabilt [14]. I PHP finns dessutom mycket stöd för
databashantering, och det är lika kraftfullt som alternativa scriptspråk. PHP Blir därför ett bra val att använda till utvecklingsprojekt likt detta.
2.4.3 Databashantering med MySQL
För att kunna utveckla ett webbaserat gränssnitt för systemet kommer databashantering bli en del som krävs som en del bakom funktionaliteten för gränssnittet. En mycket populär databasprodukt som används mycket ihop med scriptspråket PHP är MySQL. PHP har i sitt databasstöd många inbyggda funktioner just för sammankoppling med MySQL, och eftersom de båda är fria open source-program så blir det ett givet val [14]. Databashanteringen i MySQL är dock inte den enklaste om inte externa verktyg används. Men även för detta finns det open source-alternativ som lämpar sig att använda.
PhpMyAdmin är ett sådant alternativ. Med detta verktyg kan databaser och dess innehåll enkelt administreras och editeras [15].
2.4.4 Webblayout med HTML, CSS och Javascript
När de första hemsidorna utvecklades i början på 90-talet så var redan då HTML, Hyper
Text Makeup Language, en vedertagen standard för utformning och layout [16]. Sedan
dess har språket utvecklats vidare och är idag inne på femte generationen med HTML5. Tillsammans med HTML används nästan alltid CSS, Cascading Style Sheets, för att styra layouten mer detaljerat och strukturerat.
HTML och CSS beskriver bara utseendet på hemsidorna och hur innehållet ska presenteras, men för mer funktionallitet för att skapa funktioner som aktiveras av användaren utan att ladda om en ny hemsida varje gång så behövs även Javascript. Javascript körs, till skillnad från PHP, direkt i webbläsaren och därmed kan aktiviteter utföras utan att hela sidan laddas om för att generera en ny serverförfrågan. För att få ut mer av detta används scriptbiblioteken jQuery och Ajax. Dessa bibliotek innehåller färdiga strukturer för att till exempel göra anrop till servern för att uppdatera enbart en liten del av sidan och mycket mer.
Denna rapport lägger ingen större vikt vid designregler för skapandet av GUI då detta inte är av högsta relevans för systemets funktionalitet. Men slutresultatet av detta visas längre fram och källkod kommer att presenteras som en bilaga.
2.5 Kommunikationsgränssnitt
Ett av det allra viktigaste fokusområdena för detta projekt är kommunikationen mellan de ingående delsystemen. Detta är en av de mest vitala delarna och systemet kommer inte att fungera om denna del inte lyckas. Kommunikationen mellan systemets delsystem kan delas in i två delar. Först så måste kommunikation mellan styrsystem och med
kommunicera med varandra. De två kommunikationsvägarna kommer att bygga på olika olika standarder för att optimeras på bästa vis.
2.5.1 Bluetooth
Bluetooth kommer att användas för kommunikationen mellan processorenheterna. Enheterna kommer att kommunicera med små datamängder för att fördela uppgifter och för att utföra enklare förfrågningar sinsemellan, så tillförlitlighet är viktigare än
datakapacitet i överföringarna. Eftersom processorenheterna kommer att placeras med korta avstånd, och dessutom har inbyggt stöd för Bluetooth, så passar denna lösning bäst för kommunikation enheterna sinsemellan. För att kunna tillämpa systemet i en större skala så skulle detta kunna bytas ut mot en standard med längre räckvidd, till exempel ZigBee. I denna mindre skala som används i projektet så är räckvidden på Bluetooth tillräcklig. Det är inte heller några större datamängder som behöver skickas mellan processorenheterna, så Bluetooth är ett bra val även i den aspekten. Dessutom finns stöd för Bluetooth inbyggt i processorenheten som kommer att användas.
2.5.2 TCP/IP
När det kommer till kommunikation mellan processorenheterna och med styrsystemet så behövs en teknik med längre räckvidd. Tekniken behöver även kunna använda olika typer av anslutningar om det ska optimeras så att styrsystemets GUI även det kan använda samma gränssnitt, och då måste tekniken stödja fler parallella anslutningar samtidigt. Med dessa villkor så lämpar sig TCP/IP bäst som kommunikationsgränssnitt. TCP/IP har många fördelar i och med att det är en väl etablerad teknik. Tekniken möjliggör olika typer av anslutningar, som tillexempel både kabelanslutning och trådlös anslutning genom lokalt närverk. Eftersom det är denna teknik som används för internet [17] så har den stöd för anslutningar långa distanser genom internets befintliga infrastruktur, och
http-protokollet möjliggör att gränssnittet används för GUI i form av webbsidor från en
ansluten server. HTTP, Hyper Text Transfer Protocol, är det protokoll som normalt används när en hemsida efterfrågas från en server [17], så att skicka kommunikation via detta protokoll blir ett naturligt val.
3. Utvecklingsarbete
3.1 Övergripande systembeskrivning
Den automatiserade industri som åskådliggörs i denna rapport har starka kopplingar till verkliga industriella robotsystem. För att inte skapa ett allt för komplext system så tillämpas ett mindre exempel för befintliga industrier både agerar som ett delsystem i större automatiserade industrier, eller som ett självständigt system för lagerhantering. Det system som utvecklas för att testa projektets teori är ett system för lagerhantering där robotar plockar delar ur ett lager och skickar ut dessa packeterade efter beskrivning från ett ordersystem. Exempel på tillämpningar på sådana system är automatiserade
lagersystem där systemet packar kundorder från lager och skickar ut till godshantering som sedan skickar till kund, eller i ett större system där till exempel delar till en senare process plockas med automatik. Detta möjliggör expansion av systemet samtidigt som det åskådliggör teorin tydligt även som det är.
Systemet består av flera delar som tillsammans skapar modellen av den automatiserade industrin. Kunden i detta fall är en processoperatör eller orderhandläggare som först placerar en order i ett orderhanteringssystem. När ordern är lagd i systemet hanteras den med automatik av de delsystem som ingår och de robotar som utför de praktiska
uppgifterna. Slutligen levereras ordern till plats där kund kan hämta ut sin önskade materiell paketerat enligt önskemål.
Figur 2. Grundläggande skiss över systemets mekaniska ubbyggnad.
För att kunna fungera på detta vis behövs flera delar. Först och främst så behövs ett orderhanteringssystem där inkomna ordrar hanteras. Systemet behöver ett gränssnitt mot användaren och en databas för lagring. Nästa del är hantering av hur arbetet ska fördelas, vad som skall göras när och hur det skall utföras. Slutligen behövs även robotiserade
delen som utför arbetet. Genom att flytta hanteringen av arbetsfördelning och prioritering in i robotarna själva som en form av artificiell intelligens, AI, decentraliseras systemet och det blir mer flexibelt. Det blir då delsystemen som tillsammans bygger upp ett system för hur orderhantering sker. AI i robotarna läser direkt ifrån databasen med ordrar för att se vad som skall göras, och utför sedan detta efter hur prioritering är inlagt i deras AI. AI för robotarna blir mer komplex, men det behövs färre styrsystem om all styrning av systemet sker genom samma databas som orderhanteringen. Flexibiliteten blir stor när ett
gränssnitt för ett enda system hanterar all styrning av systemet. Det går då att göra precis som pappersbruket Swedpapper i Gävle [3], det blir möjligt att styra systemet från en surfplatta utan att fysiskt befinna sig nära den automatiserade industrin.
Med dessa krav kan systemet delas in i följande delar: - GUI för orderhanteirng och systemstyrning
- Databas för informationslagring och kommunikation - Robotar för utförande av ordrar
Figur 3. Flödesschema för tänkt arbetsprocess vid ny arbetsorder. 3.1.1 Delsystem
De ovan definierade delsystemen beskrivs här på en övergripande nivå.
GUI
Gränssnittet mot användaren, GUI: Graphical User Interface, blir den del där hela systemet kontrolleras och administreras. Det kan då inte vara något generellt orderhanteringssystem utan det måste vara anpassat för att även kunna hantera systemstyrningen. Genom att låta olika användare ha olika behörighetsnivåer och vara indelade i olika grupper så blir detta tillämpbart även i ett verkligt fall. Gränssnittet
behöver en del för hantering av ordrar. Nya ordrar ska enkelt kunna läggas in i systemet, och för befintliga ska det vara möjligt att ändra inställningar eller visa status. Den andra delen av gränssnittet blir styrningen till det automatiserade systemet. Även om robotarna själva jobbar på utefter sitt eget AI så måste systemet kunna styras centralt. Robotarna behöver instruktioner om när de ska starta sitt arbete och om de ska avsluta arbetet. Stopp av systemet vid problem måste kunna skickas både från gränssnittet och
robotarna måste kunna informera gränssnittet om de stannar på grund av problem med deras drift. Denna del ska även visa aktuell status för systemet så det är lätt att få en övergripande bild över arbetets gång. För den bästa flexibiliteten utformas GUI som ett webbaserat system så tillgängligheten blir stor och kraven på anslutande enheter hålls öppet för stor flexibilitet.
Databas
Informationen som hanteras i GUI måste lagras på något vis och mest flexibelt är en webbaserad databas. Tillgängligheten blir stor och med ett webbaserat GUI är det mer eller mindre ett krav med webbaserad databas för att de ska arbeta ihop. Databasen måste först och främst lagra all information om ordrar i systemet, och alla produkter som hanteras. Men även lagring av kommunikation som går mellan styrsystemets del i GUI och robotarna. Den typ av kommunikation som hanteras mellan GUI och robotar är data för att starta och stoppa systemet, felmeddelanden från robotar som genererar
information i GUI och status från robotarna. Utöver detta så läser även robotarna in data för hantering av ordrar.
Robotar
För den tänka tillämpningen används två robotar som tillsammans hanterar arbetet genom att paketera ordrarnas materiell och skicka dem till mottagaren. Robotarna läser ut arbetsinstruktioner ur databasen och arbetar tillsammans för att slutföra sin uppgift. Robotarna utrustas på olika vis mekaniskt för att hantera olika delmoment, men de måste kommunicera med varandra för att uppgiften ska kunna slutföras. Båda robotarna bör ha kommunikation med databasen, men om de kommunicerar med varandra via annat gränssnitt så som bluetooth så är det inget krav.
Den ena roboten hanterar de lådor som materiell till ordrana packas i. Lådorna hämtas ur ett lager och placeras fram för att lastas. Lastade lådor transporteras sedan till
leveransutgångarna. Den andra roboten är utformad som en arm som packar lådorna när den får information om att en låda finns att packa. Den hämtar då materiell ur ett annat lager och packar önskat antal till lådan innan den meddelar att lådan är klar för leverans.
3.2 Hårdvarudesign
Med en redan vald hårdvaruplattform blir det denna som sätter begränsningarna för systemet som helhet. Men plattformen har inga större begränsningar mer än tillgängliga mekaniska lösningar. Då all mekanik som används är LEGO byggelement blir
begränsningen i form av tillgängligheten av passande delar i utbudet från LEGO. Men eftersom tillgängligheten för motorer och sensorer är god så blir begränsningarna inget problem.
3.2.1 Mekanisk uppbyggnad
Som ovan nämnts baseras de mekaniska lösningarna enbart på byggelement från LEGO, främst produktgrupperna Mindstorms och Technic. Båda robotarna får varsin
processorenhet för att enkelt kunna jobba självständigt utan fysisk kontakt.
Processorenheten, EV3, är den dit motorer och sensorer ansluts. Vardera processorenhet kan maximalt samtidigt ansluta fyra motorer och fyra sensorer. Den har även en usb-ingång nätverkskort för trådlöst nätverk ansluts (Wifi-dongle). Nedan beskrivs vardera robot mer ingående.
RoboTransport
Denna robot är den robot som transporterar lådor till paketering och leverans. Roboten är konstruerad som ett fordon som placeras på en räls som går längs med de platser den besöker. Rälsen går i ena änden från lagret med lådor, till andra änden där
paketeringsplats är och passerar där emellan leveranspositionerna. Roboten använder en motor för drift längs rälsen. Robotens centrala funktion att hämta och lämna lådor görs från ett transportband med krokar för att ta tag i lådorna. Detta transportband är i sin tur monterat på en lyftanordning för att kunna förflytta transportbandet i höjdled. Även bägge dessa delar drivs med en motor vardera. Slutligen sitter även en motor undertill som används för att ansluta till transportbanden för utleverans. På så vis kan roboten styra aktuellt transportband för utleverans samtidigt som den levererar ut en låda. Detta medför att dessa transportband inte behöver fysisk anslutning till roboten när de inte används och det sparar även in anslutningar för motorer då enbart en motor används oavsett antalet leveransband.
Figur 4. RoboTransport. RoboArm
Detta är den robot som är utformad som en arm för att plocka delar ur lager och paketera. Även denna robot sitter monterad på en räls för transport mellan dess olika positioner. Rälsen här är av en typ där roboten hakas fast för att få stabilitet även när armen är i dess yttersta läge. Detta ger ökad stabilitet även om roboten i sig har god balanserad konstruktion. Processorenheten sitter som en motvikt när roboten sträcker ut sig för att hämta delar, men hastiga rörelser blir ändå ostabila.
Armen som går längs rälsen har två leder, även kallat frihetsgrader. Längst ut på roboten sitter en gripklo som används för att plocka upp de delar som finns i lager. Lagret i sin tur är byggt på sådant vis att delar per automatik matas fram av tyngdkraften när en del plockats så samma typ av del ständigt finns tillgängligt när det finns i lager. Vardera led på roboten styrs med varsin motor och även gripklo och förflyttning längs rälsen drivs med varsin motor. Robotens förflyttning i sidled går mellan platsen för paketering och lagret som ligger i två rader längsmed rälsen.
Figur 5. RoboArm. 3.2.2 Sensorlayout
LEGO Mindstorms har trots begränsningarna i utbudet av sensorer ett utbud stort nog för de flesta tillämpningarna. Det går även att bygga egna sensorer då de kommunicerar med I2C och eftersom kommunikationsstandarden de använder är öppen i och med att det är
open source. För detta projekt används fyra olika typer av sensorer, de är listade nedan med viktiga egenskaper [13].
Color sensor
Sensorn kan arbeta på tre olika vis. De olika sätten är att läsa av färg, mäta reflekterat ljus, och mäta intensiteten på omgivande ljus. I alla fall i detta projekt används
färgavläsning för att läsa av färgmarkeringar. Samplingstakten är 1 kHz.
Touch sensor
Trycksensor som har två lägen. Sensorn är intryckt, eller sensorn är inte intryckt. Fungerar som en mikrobrytare.
Gyro sensor
Gyrosensorn är en digital sensor som mäter rotation längs en axel. Sensorn mäter rotation per sekund med maximalt 440°/s. Sensorn kan även hålla reda på aktuell vinkel angivet i grader.
Ultrasonic sensor
Ultraljudssensor för mätning av avstånd till framförvarande objekt. Sensorn skickar ut ett högfrekvent ljud och mäter tiden tills ett eko hörs. Mätningar mellan 3 till 255 cm är möjligt, med en noggrannhet på +/- 1 cm.
Tillämpade sensorer
De ovan listade sensorerna är de typer som används för de aktuella robotarna.
RoboTransport är den robot som använder flest sensorer, den utnyttjar alla fyra
anslutningar på processorenheten. Första sensorn är en color sensor som läser av
dess position. Ytterligare en color sensor används för att läsa av en färgmarkering längs transportbandet för att veta positionen på krokarna som greppar lådor. Den tredje
sensorn är en touch sensor som trycks in när lyftanordningen når sin övre position för att använda det som en utgångspunkt i dess positionering. Slutligen har den en ultrasonic sensor som används för att mäta avstånd i lagret för lådor för att läsa ut om det står någon låda i lagret eller ej.
RoboArm använder bara tre sensorer, men den använder stegräknaren i motorn som
driver gripklon för detektering om dess läge istället. Första inkopplade sensorn är även här en color sensor som läser av positionering längs rälsen. Nästa sensor är en touch sensor som läser av när den första leden på armen står i upprätt läge för att använda som en utgångspunkt i positioneringen. Till sist sitter det en gyro sensor på den yttre leden av armen för att läsa av dess vinkel.
3.3 Mjukvaruutveckling robotsystem
Robotsystemets mjukvara är den mest komplexa delen i projektet. Det är denna del som avgör hur smart systemet blir genom komplexiteten på dess AI. Detta avsnitt beskriver utvecklingen av olika delar av robotarnas programvara, och förutsättningarna för utvecklingen.
3.3.1 Utvecklingsmiljö
Den medföljande utvecklingsmiljön för LEGO Mindstorms EV3 är ett enkelt program baserad på LabVIEW [18]. Programmet är designat att vara enkelt även för skolelever och barn att sätta sig in i, samtidigt som det har möjlighet för avancerad utveckling.
Programmet bygger helt på att block med olika funktionalitet ansluts i ett visuellt schema. Detta blir dock väldigt invecklat för större projekt som detta, men eftersom EV3 är baserat på open source så finns det goda möjligheter för mer avancerad utveckling. Ett sätt för mer avancerad utveckling är att låta roboten läsa in en firmware som stödjer något traditionellt textbaserat programmeringsspråk.
I detta projekt används en firmware vid namn Monobrick (3.3.2). Denna firmware har en uppsättning metoder för hantering av motorer och sensorer skapat i C# för att möjliggöra objektorienterad C#- programmering. Med stöd från denna firmware blir utvecklingen möjlig att ta till en mycket mer avancerad nivå än det ursprungliga programmet och eftersom denna firmware innehåller många färdiga metoder för hantering av motorer och sensorer så förenklas arbetet.
Koden som skrivs i C# behöver sedan kompileras till exekverbara filer innan robotarna kan tolka instruktionerna där i. För detta används ett open source .Net framework kallat Mono [19]. Programmeringen och kompileringen sker i programmet Xamarin studio [20].
3.3.2 Monobrick firmware
MonoBrick EV3 firmware är ett firmware substitut för Mindstorms EV3. Denna firmware möjliggör utveckling och debuggning för EV3-processorenheten i .Net-kompatibla
programmeringsspråk, däribland C# [21]. Eftersom denna firmware kan lagras på ett SD-kort är det enkelt att installera parallellt med den ursprungliga firmware i EV3-enheten. Processorenheten startar automatiskt upp från denna firmware istället så länge den finns lagrad på ett inkopplat SD-kort. Med denna firmware kan program programmeras och kompileras i valfri .Net-kompatibel miljö.
MonoBrick firmware är baserad på leJOS firmware som används för att kunna programmera Mindstorms-robotar med programmeringsspråket Java [22].
3.3.3 Mjukvarudesign
Robotarnas mjukvara är ett stort programmeringsjobb så god översiktlighet är ett måste. Då passar objektorienterad programmering bäst vilket dessutom tillämpas redan då metoder från MonoBrick firmware används. För att underlätta utvecklingen skapas ett enda program som med en enkel justering anpassas beroende på vilken robot som det installeras i. De robotspecifika metoderna hanteras av att varje typ av robot får en egen class. Sedan skapas under main olika robot-objekt beroende på vilken robot koden skall köras på. Eftersom mycket funktionalitet delas mellan robotarna är det bättre att utveckla ett program där så mycket som möjligt kan delas för att slippa skriva om samma saker flera gånger.
Struktur över klasser
Main, det huvudsakliga programmet. Här ifrån anropas underliggande program
allteftersom något skall utföras. I denna fil startas de parallella trådarna där aktiviteter körs. Först skapas ett robot-objekt beroende på vilken robot koden skall köras på. Därefter körs robotens initiering och när den är slutförd startas tråden för robotens
aktiviteter och tråden för övervakning av roboten. Dessa trådar går sedan till programmet får instruktioner om avslut, eller stoppknapp på robot trycks.
Robot, basklass för robotobjekt. Denna klass innehåller grundläggande funktionalitet som
används av alla robotar.
RoboTransport & RoboArm är subklasser till klassen Robot. Dessa klasser ärver dess
egenskaper och får tillägg beroende på hur den typen av robot ska agera. Här i ligger de robotspecifika metoderna.
GlobalConst är en klass för lagring av konstanter som används globalt genom alla klasser.
Genom att samla dessa blir det tydligare vilka värden som används och det går enklare att modifiera vid behov.
Linux är klassen för att hantera kommunikation med det lokala operativsystemet på
processorenheten. För att kunna skicka kommandon som inställningar av tid och för att skriva till lokala filer.
DBconnector är klassen som hanterar kommunikation med databasen. För att läsa och
skriva information används metoder i denna klass.
Mindre objekt
Även mindre klasser används för mindre objekt, men dessa ligger inbakat i de ovan definierade klasserna och initieras inte globalt på samma vis. Vid inläsning av ordrar ur databasen skapas ett objekt med alla ordrar för att lätt ha dessa samlade. Detta objekt innehåller i sin tur ett mindre objekt för varje order där dessa objekt innehåller information om antal produkter i ordern bland annat. Även varje motor och sensor är ett objekt som skapas när ett robot-objekt skapas initialt.
Variabel- och metodhantering
Eftersom projektet blir omfattande så blir det resurskrävande. Men för att enkelt
möjliggöra expansion måste ett tänk i optimering vara med i ett tidigt skede. Något som är viktigt att lägga vikt vid är minneshanteringen. Varje variabel som initieras tar
minnesutrymme, och processorenheten har ett fast begränsat utrymme att använda. Därför är det lämpligt att välja datatyp för varje variabel beroende på dess funktion. Till exempel är det ineffektiv minneshantering att använda datatypen int som är 32 bitar för en variabel som endast är i intervallet -100 - +100 så som motorhastighet. En sådan variabel är lämpar sig bättre som sbyte vilket bara upptar 8 bitar [23]. Även i klasser och metoder är detta tänk viktigt.
Även om minneshantering kan bli resurskrävande så är många värden återkommande genom koden. Dessa värden sparas i en egen klass (se ovan) för att tillgängliggöras genom alla objekt och metoder. Detta tar mer minnesutrymme då alla variabler sparas i minnet vare sig de används eller ej, men det blir mer översiktligt vilket värde som används var. Skapade metoder i klasserna finns att se i bilaga 1 där källkoden visas. Alla metoder har kommentarer med dess funktionalitet. För förklaring till användandet av metoder och funktionalitet från MonoBrick se bilaga 2.
Huvudaktiviteten, metoden Run()
När ett robot-objekt initierats så tillgängliggörs metoden Run(). Detta är robotens huvudmetod där alla aktiviteter för att lösa robotens uppgift återfinns. Run anropas genom en while-loop för att efter varje steg kontrollera så inget felmeddelande skapats. I denna metod anropas sedan alla underliggande metoder för robotens funktioner för att lösa robotens uppgift. I metoden läses eventuella felmeddelanden ut från anropade underliggande metoder för att hålla kontroll på att allt går som det är tänkt. Denna metod har även funktionalitet för att själv besluta vad som skall utföras i den, genom dess AI.
3.3.4 Robotkommunikation
Som tidigare nämnt är det väldigt önskvärt med kommunikation direkt mellan robotarna eftersom de tillsammans ska lösa uppgifterna de tilldelas. I processorenheterna finns det inbyggt stöd för bluetooth så detta är ett bra val för denna kommunikation då enheterna kommer befinna sig nära varandra. Information som robotarna då skickar mellan varandra blir normalt när de slutfört en uppgift som den andra roboten är beroende av, till exempel när en låda är packad och redo för leverans. Informationen finns redan att läsa i
databasen genom orderstatus, men det går snabbare för robotarna att kommunicera direkt. Dessutom medför detta att inte alla robotar behöver ha tillgång till internet och databasen vilket kräver externt nätverkskort. Om någon robot saknar access till databas så kan även den informationen som läses ut ifrån databasen skickas direkt mellan
robotarna genom att någon robot med internetaccess läser väsentlig information. På så kan systemet även fungera vid dålig internetuppkoppling då arbetsinstruktioner kan läsas in till robotarna vid färre tillfällen och informationen delas robotar mer emellan.
Ett bluetooth-meddelande robotarna emellan måste innehålla mycket mer än bara meddelandet. För att få god kontroll på kommunikationen behöver robotarna veta att informationen kommer fram. Detta kan göras genom att numrera meddelandena och för varje nytt meddelande övar indexeringen, om meddelandenummer som läses inte stämmer med indexeringen så har något missats så meddelande får skickas om. En så kallad step sequencer räknar varje meddelande och kontrollerar så de kommer i rätt ordning. Indexeringen behöver inte öka i all oändlighet utan det räcker med en byte data, som vid värde 0xFF återgår till 0x00 vid nästa ökning.
Ett meddelande skulle kunna innehålla följande information: - Startbitar
- Indexeringsnummer - Typ av meddelande - Meddelandets längd
- Meddelandet, upptar så stor datamängd som definierat innan - Stoppbitar
Roboten som mottagit meddelandet svarar sedan med ett medelande uppbyggt : - Startbitar
- Indexeringsnummer (samma nummer som mottaget meddelande) - Status (Kunde meddelandet mottagas som förväntat)
- Stoppbitar
Om ett meddelande inte kommer fram som det ska kan det enkelt skickas om ett par gånger innan försöken avbryts. Detta sätt att kommunicera ger god kontroll över att all information kommer fram som den ska.
3.3.5 Styrsystem och övervakning
Övervakningen sker som nämnt ovan i en parallell tråd som körs konstant i bakgrunden till robotens huvudfunktionalitet. Den parallella tråden går i en loop som anropar metoder som anger status med jämna mellanrum. Det blir denna del som hanterar start och stop av huvudfunktionerna. När det är angivet att systemet skall starta i databasen ser denna tråd detta och aktiverar huvudtråden, och på samma sätt hanteras ett stopp.
Övervakningstråden måste därför göra kontroller ofta nog att tiden mellan dessa ses som okej väntan från ett stopp-kommando i GUI tills att systemet stannar.
Övervakningen läser även av minnesanvändning och processoranvändning för att hålla koll på robotens belastning. Batterikapacitet läses även av här för att kunna varna så snart batterierna måste bytas ut. Varje gång informationen uppdateras i databasen så anges även tid för uppdateringen så kan systemet se om senaste uppdatering anses vara för gammal så ses roboten som bortkopplad och systemet varnar.
3.3.6 BIST
BIST, eller Built In Self Test som det står för, är precis vad det låter som. Inbyggda tester i systemet som enkelt kan anropas för att kontrollera status för de funktioner som testet går igenom. BIST:er är mycket användbart för större system där man under drift eller under utvecklingsarbetet vill kunna kontrollera vad olika funktioner har för funktionellt tillstånd. Ju mer övervakning av systemet och dess status som önskas, desto mer utveckling av olika BIST:er görs.
För detta projekt sker mycket av övervakningen löpande under drift så inget större arbete läggs på någon särskild BIST-utveckling. Men en del av programmet som kan ses som en BIST är metoden för initiering. Under initieringen så kontrolleras olika funktioner på
roboten innan den är redo för drift. Bland annat så kontrolleras anslutning till internet och till styrsystem. Det sker även kontroll att roboten kan läsa ut var den befinner sig, och att sensorerna svarar som de ska. Initieringen är dessutom gjord på sådant vis att den kan anropas när som helst under drift för att återgå till startläget och kontrollera att allt är i sin ordning.
3.4 GUI-design
För att systemet väl ska efterlikna ett större automatiserat industriflöde så måste
användargränssnittet, GUI, vara förenklat. Om gränssnittet går för djupt in med styrning på detaljnivå så förloras vitsen med automatisering. Gränssnittet måste därför styra på en övergripande nivå där styrsystemet får instruktioner som skall utföras, där sedan
styrsystemet automatiskt låter rätt del i systemet styras beroende på uppgift att utföra. Eftersom webbutvecklingen inte är projektets avgörande del läggs mindre vikt vid detta avsnitt, fokus här blir på de delar som styr det automatiserade systemet.
3.4.1 Webbgränssnitt
För att få ett flexibelt och tillgängligt GUI så väljs ett webbaserat gränssnitt ut mot användaren. Detta medför att användaren kan styra systemet från många olika enheter, och att gränssnittet får stor flexibilitet. Webbgränssnittet blir precis som det låter enbart ett gränssnitt mot användaren. Styrsystemet baseras till större del på informationsflödena i databasen där varje del i systemet själv läser och skriver data, det blir alltså ingen
direktkontakt mellan GUI och det automatiserade systemet. På detta vis blir GUIt en enkel del sett ur utvecklingssynpunkt, det blir en förhållandevis enkel hemsida som skapas. Grunden blir väldigt enkel, men möjligheterna för med komplex design finns för att göra ett mer tilltalande GUI och för att få fram en bättre användarvänlighet.
Grundarbete
Grunden till hela gränssnittet utvecklas med HTML och CSS för designen och med PHP för anslutningen till databasen. Egentligen skulle detta räcka, men för en förbättrad
användarvänlighet så används även andra utvecklingsmetoder. Mer om detta längre fram. Till en början byggs GUI:t enkelt upp för att kunna visa data från databasen och för att kunna mata in mer data, tillika ge instruktioner för styrsystemet. PHP-kod används för att upprätta en anslutning till databasen när data läses och skrivs. I PHP-koden används sedan SQL-frågor för att hantera urval av data och all styrning av databasen.
Utökad användarvänlighet
För att få en utökad användarvänlighet används Javascript för de mer avancerade funktionerna i GUI:t. Biblioteken jQuery och Ajax som är baserade på Javascript
inkluderas för denna utvidgning. Ajax är en grupp funktioner i jQuery-biblioteket. Genom dessa funktioner möjliggörs uppdatering av delar på webbsidan utan att ladda om hela sidan. Detta används för att uppdatera visning av systemstatus och för att läsa ut eventuella felkoder från robotarna. Det är detta som gör att systemet blir uppkopplat ”live”. jQuery hanterar funktioner för att byta ut informationen ur vissa delar på hemsidan, medan Ajax hanterar anropen till databasen. Anropen till databasen sker med PHP-filer, men det är Ajax-funktionerna som aktiverar dessa filer och mottager data från dessa. Med hjälp av detta system visas felmeddelanden direkt de uppstår, istället för att vänta först tills att användaren laddar om sidan och genererar ett nytt databasanrop. På samma sätt hanteras funktioner för start och stopp av systemet.
Responsiv design
Eftersom målet med projektet är att systemet ska bli flexibelt så behövs ett GUI som kan användas från flera olika medier med olika skärmupplösning och inmatningsmetoder. Systemet måste kunna styras från både större medier så som datorer, men även från mindre så som surfplattor, och även mobiltelefoner. Ett givet val när det är ett
webbgränssnitt som ska anpassas så är att använda responsiv design.
Responsiv design innebär att designen byggs på sådant vis att layouten anpassas olika beroende på skärmstorlek. För detta GUI anpassas sidan på sådant vis att om en liten skärm som en mobiltelefon ansluter så är sidan begränsad för att inte bli för invecklad. Men om en surfplatta ansluter till sidan är bara innehållet mer anpassat för att fylla ut skärmen bättre mot om en dator med fullstor skärm ansluter.
3.4.2 Databaslayout
Med ett webbgränssnitt till styrsystemet så blir databaslayouten en oerhört viktig del så som nämnt innan. Hela styrsystemet blir beroende av databasen där allt ifrån instruktioner till loggar lagras. Databasen måste innehålla all dynamisk data som styrsystemet hanterar.
Figur 6. GUI för medelstor (surfplatta) till vänster, och liten skärm (mobiltelefon) till höger.
Då MySQL används i detta projekt så utvecklas databasen med SQL och det finns gott om hjälpmedel för layoutarbetet. Ett verktyg som är mycket användbart är PhpMyAdmin, som nämnts innan. Med detta verktyg blir det lätt att arbete i databasen under hela projektets gång. PhpMyAdmin är mycket användbart vid så väl utvecklingsarbetet som för underhåll då det är mycket enkelt att både skapa och modifiera tabeller, men även att hantera data som lagras i databasen.
Utveckling av databasen
Första steget i utvecklingsarbetet av databasen är att gå igenom vilka informationsflöden som styrsystemet bygger på. Varje flöde med data som skickas mellan gränssnittet och styrsystemet måste mellanlagras i databasen, dels för att gränssnittet inte har någon egen kontakt med robotarna, men även för lagring av information för uppföljning och felsökning.
Tabeller
Databasen byggs upp enligt figur 8.
Figur 8. Tabellöversikt och databasrelationer.
Tabellerna används enligt nedan:
- tblUser: Lista med alla användare och inloggningsuppgifter. - tblProduct: Lista med alla produkter och saldon.
- tblOrder: Alla ordrar lagras här och dess status.
- tblOrderItem: Lagrar vilka produkter och antal som ingår i varje order. - tblRoboStatus: Information om aktuell status för anslutna robotar. - tblSystem: Hanterar meddelanden från styrsystemet i GUI till robotar.
- tblEventLog: Listar meddelanden om händelser och fel både från GUI och robotar.
Robotanslutning till databas
Robotarna ansluter till databasen för att läsa och skriva information med jämna
mellanrum. Dessa anslutningar hanteras av ett eget webbsystem av enklare modell. Att låta robotarna ansluta direkt till databasen och skicka SQL-förfrågningar blir både osäkert och låst med hårdkodade lösningar. Att låta robotarna ansluta till en hemsida där data skrivs ut och läses in blir mer flexibelt och säkert. På så vis behöver inte databasens kontouppgifter lagras i robotens kod. De enkla hemsidorna gör anrop till databasen och allt detta hanteras lokalt på webbservern, sedan visas utdata som textsträngar som roboten mottager. Textsträngarna formateras enligt en standard kallad JSON. Denna standard kan hanteras både på webbsidor med PHP och i C#-koden på robotarna. Flexibiliteten blir då att roboten har enbart en hårdkodad adress till denna sida inlagt, medan databasen kan struktureras om och även byggas om helt så länge sidorna presenterar samma data till robotarna som ursprungligen.
