Konstruktion av x/y-system för kamerabaserad detektering och infångning av bollar.

EXAMENSARBETE I

ELEKTRONIK

15 HP, GRUNDNIVÅ

Konstruktion av x/y-system för kamerabaserad

detektering och infångning av bollar.

16 januari 2011

Författare:

Mikael Engholm (mikael.engholm@motioncontrol.se)

Fredrik Lundh (fredrik.lundh@motioncontrol.se)

Företag:

Motion Control i Västerås AB

Handledare: Christer Gerdtman, Fredrik Modigh

Examinator: Mikael Ekström

Förord

Denna rapport ingår som en del i det arbete som krävs för en högskoleingengörsexamen i mekatronik/elektronik (180 HP) vid Mälardalens Högskola.

Arbetet har utförts på Motion Control i Västerås AB under perioden februari 2010 till januari 2011.

Handledare på högskolan har varit Mikael Ekström vid Akademin för innovation, design och teknik. Hand-ledare på Motion Control har varit Christer Gerdtman och Fredrik Modigh.

Vi vill rikta ett varmt tack till:

Christer Gerdtman, för att han låtit oss genomföra vårt examensarbete på Motion Control och gett oss en n ingång i arbetslivet.

Fredrik Modigh, för tålmodigt tillrättavisande av dokumenteringsfadäser. Medarbetarna, för idéer, synpunkter och allmän hjälp.

Grabbarna i MdH-verkstan (i synnerhet Henrik Lekryd).

Slutligen vill vi åter tacka alla medarbetare på företaget för de många intressanta och ibland absurda dis-kussionerna vid kabordet.

Västerås i januari 2011

En viktig uppgift för alla företag är att sälja sin kompetens. För många företag innebär det bland annat att locka in besökare i ett utställningsbås på de många yrkesmässorna runt om i världen. Med detta som avsikt beslutade sig Motion Contol i Västerås AB att annonsera ut ett examensarbete med inriktningen att utveckla ett publikfång i form av ett stort visionbaserat x/y-system. Besökaren kastar en boll mot x/y-systemet var på den fångar in bollen med visionsystemet till hjälp.

För att lösa uppgiften krävs att de rörliga delarna i det mekaniska systemet hålls så lätta som möjligt. Då maskinen skall kunna fånga in bollar över ett område på 1 x 1 meter på mindre än 0,5 sekunder, uppstår betydande krafter vid en stor rörlig massa.

En inledande marknadsundersökning gjordes för att ta fram alternativ gällande motorer, motordrivare, linjärdon, och visionsystem. Under den efterföljande konstruktionen av maskinen har visionsystemet visat sig svårast att implementera. Dock har alternativa demonstrationslägen tagits fram som möjliggör dess användning utan visionsystem.

Innehåll

1 Bakgrund 1 2 Problem 2 2.1 Mekaniskt system . . . 2 2.1.1 Förutsättningar . . . 2 2.1.2 Matematiken . . . 3 2.1.3 Krav . . . 4 2.2 Visionsystem . . . 4 2.2.1 Inledning . . . 4 2.2.2 Krav . . . 4 2.3 Systemkravspecikation . . . 5 2.3.1 Funktionskrav . . . 5 2.3.2 Gränssnittskrav . . . 5 2.3.3 Driftkrav . . . 6 2.3.4 Kapacitetskrav . . . 6 2.3.5 Konstruktionskrav . . . 6 2.3.6 Dokumentationskrav . . . 6 2.3.7 Kravlista . . . 7 2.3.8 Önskemålslista . . . 7 3 Analys 8 3.1 Funktionsundersökning av drivsystem . . . 8 3.1.1 Inledning . . . 8 3.1.2 Linjära ställdon . . . 8 3.1.3 Motorer . . . 10 3.1.4 Motordrivenheter . . . 11 3.1.5 Förslagsställning . . . 12 3.1.6 Rekommendation . . . 15 3.2 Funktionsundersökning av visionsystem . . . 15 3.2.1 Inledning . . . 15 3.2.2 OpenCV . . . 16 3.2.3 RoboRealm . . . 17 3.2.4 Wiimote Whiteboard . . . 18 3.2.5 GpuCV . . . 19 3.2.6 Sammanfattning . . . 19 3.2.7 Rekommendation . . . 20

3.3 Fördjupad analys av OpenCV med webbkamera . . . 20

3.3.1 Inledning . . . 20 3.3.2 Undersökning . . . 20 3.3.3 Resultat . . . 22 4 Modell 24 4.1 Övergripande design . . . 24 4.2 Mekanisk design . . . 24 4.3 Elektrisk design . . . 24 4.3.1 Signaldistrubution . . . 24 4.3.2 Kraftdistrubution . . . 27 4.4 Mjukvarudesign . . . 27 i

4.4.1 Visionsystem . . . 27 4.4.2 Hårdvarugränssnitt . . . 29 4.4.3 Säkerhetsaspekter . . . 29 4.4.4 Användargränssnitt . . . 29 4.5 Systemtestspecikation . . . 30 4.5.1 Genomförande . . . 30 4.5.2 Systemtester . . . 31 5 Metod 33 5.1 Konstruktionsbeskrivning  mekanik . . . 33 5.1.1 Inledning . . . 33 5.1.2 Översikt . . . 33 5.1.3 Detaljredovisning . . . 33 5.1.4 Monteringsanvisning . . . 39 5.2 Konstruktionsbeskrivning  elektronik . . . 56 5.2.1 Signaldistribution . . . 56 5.2.2 Kraftdistribution . . . 57 5.2.3 Styrskåpets uppbyggnad . . . 58 5.2.4 Elektronik . . . 59 5.2.5 Styrdatorn . . . 67 5.3 Konstruktionsbeskrivning  mjukvara . . . 68 5.3.1 Användargränssnitt . . . 68 5.3.2 Inställningar . . . 71 5.3.3 Positionsberäkningar . . . 71 5.3.4 Seriellt gränssnitt . . . 73 5.3.5 Grakberäkningar . . . 74 5.3.6 Visiongränssnitt . . . 74 5.3.7 Operativsystem . . . 76 5.3.8 Utvecklingsmiljö . . . 76 5.3.9 Övergripande kodstruktur . . . 76 6 Resultat 78 6.1 Teststeg . . . 78 6.2 Protokoll . . . 79 7 Diskussion 80 7.1 Fel och brister . . . 80

7.1.1 Mekanik . . . 80

7.1.2 Elektronik . . . 80

7.1.3 Mjukvara . . . 80

7.2 Förslag till förbättringar . . . 80

7.2.1 Mekanik . . . 80 7.2.2 Elektronik . . . 81 7.2.3 Mjukvara . . . 81 A Denitioner 84 B Mekanik 86 B.1 Remfäste  mothåll . . . 87 B.2 Remfäste  block . . . 88 B.3 Linjärskensfäste . . . 89 B.4 Justeringsblock . . . 90 B.5 Motorfäste . . . 91 B.6 Brythjul . . . 92 B.7 Brythjulsfäste . . . 93

C Elektronik 94

C.1 Kraftschema . . . 95

C.2 Signalschema . . . 96

C.3 PIO . . . 97

Figurer

2.1 Rörelsebeskrivning för linjärdon. . . 2

3.1 Nook Industries EGZ40 . . . 8

3.2 Nook Industries ELZU30 . . . 9

3.3 HepcoMotion PDU2 . . . 9 3.4 Thomson PowerLine WM60Z . . . 9 3.5 ELMORE Light 30 SP1 . . . 10 3.6 PrintedMotorWorks GM16 . . . 10 3.7 JVL MAC800 . . . 10 3.8 Mavilor BLS72 . . . 11 3.9 Geckodrive G340 . . . 11 3.10 Technosoft IDM640 . . . 12 3.11 Infranor CD1-p . . . 12 3.12 Principskiss för förslag 1 - 3. . . 14

3.13 Första CAD-utkast av förslag 4. . . 15

3.14 OpenCV . . . 16

3.15 RoboRealm . . . 17

3.16 Wiimote Whiteboard . . . 18

3.17 GpuCV . . . 19

4.1 Övergripande design . . . 25

4.2 Principbeskrivning av system med lång rem. . . 25

4.3 Stommen till det mekaniska systemet. . . 26

4.4 Signaldistrubution. . . 26

4.5 Kraftdistrubution. . . 27

4.6 Övergripande programupplägg. . . 28

4.7 Flödesschema visionsystem. . . 28

4.8 Huvudfönster. . . 30

5.1 Maskinen utan framsida. . . 34

5.2 Kanya PVS Basis 50. . . 34

5.3 Skiss  Kanya PVS Basis 50. . . 35

5.4 Lineartrace T-Race Monorace 28. . . 35

5.5 Skiss  T-Race Monorace 28. . . 35

5.6 JVL MAC800. . . 36

5.7 16AT5 rem och brythjul. . . 36

5.8 Skåp med kontaktorer och signalelektronik. . . 37

5.9 Standard PC dator (vänster), Skärm och tangentbord(höger). . . 38

5.10 Optisk lägesgivare. . . 38

5.11 Bollfångare. . . 39

5.12 Maskinens framsida av MDF. . . 40

5.13 Datorhylla. . . 40

5.14 Justeringshjul  sprängskiss. . . 41

5.15 Övre främre prol. . . 42

5.16 Nedre främre prol. . . 42

5.17 Nedre bakre prol. . . 43

5.18 Linjärskensfäste  sprängskiss. . . 44

5.19 Remhållare. . . 44 iv

5.20 Övre motorpaket. . . 45

5.21 Nedre motorpaket. . . 46

5.22 Tangentbordshylla  överdel. . . 46

5.23 Överdel med relevanta mått för släde och stoppvinkel. . . 47

5.24 Tangentbordshylla  underdel. . . 47

5.25 Elektronikskåp med tangentbordshylla. . . 48

5.26 Slutmontage av prolsystemets nedre del. . . 49

5.27 Slutmontage  undre bollfång. . . 50

5.28 Slutmontage av elektronikskåp med tangentbordshylla. . . 50

5.29 Slutmontage av övre proler och skärmstativ. . . 51

5.30 Slutmontage av övre motorpacket och skärmstopp. . . 52

5.31 Slutmontage av återstående bollfångsdetaljer och linjärskena med remhållare. . . 52

5.32 Remmens dragning. . . 53

5.33 Remmens infästning. . . 54

5.34 Framsida med beslag. . . 54

5.35 Hela maskinen monterad (utom bollfångstyg). . . 55

5.36 Blockschema för systemet. . . 56

5.37 Blockschema för signaldistribution. . . 56

5.38 Blockschema för kraftdistribution. . . 57

5.39 Placeringsskiss för styrskåpets bakplan. . . 59

5.40 Vänster samt höger sida. . . 60

5.41 Insida av dörr. . . 60 5.42 ULN2003A. . . 61 5.43 Benkonguration ULN2003A. . . 61 5.44 SN75176. . . 62 5.45 Benkonguration SN75176. . . 62 5.47 Benkonguration PIC18F2220. . . 63 5.46 PIC18F2220. . . 63

5.50 Benkonguration och inkoppling MAX232ACSE . . . 64

5.48 CSTCV20M0X53J-R0. . . 64

5.49 MAX232ACSE. . . 64

5.51 Flödesdiagram för koden till SPIO-kortets mikrokontroller. . . 65

5.52 Överblick över programmet. . . 68

5.53 Huvudfönster. . . 69

5.54 Inställningsfönster. . . 69

5.55 Kalibreringsfönster. . . 70

5.56 Muspekardemo. . . 70

5.57 Jämförelse mellan koordinatsystem. . . 71

5.58 Jämförelse konvertering mellan koordinatsystem. . . 72

5.59 Ickekompenserad rörelse. . . 73 5.60 Ljusintensitetsspårning av tennisboll. . . 75 5.61 Spårning av ljusintensitetsförändringar. . . 76 6.1 Systemtestprotokoll. . . 79 B.1 Remfäste  mothåll . . . 87 B.2 Remfäste  block. . . 88 B.3 Linjärskensfäste. . . 89 B.4 Justeringsblock. . . 90 B.5 Motorfäste. . . 91 B.6 Brythjul. . . 92 B.7 Brythjulsfäste. . . 93 C.1 Kraftschema. . . 95 C.2 Signalschema. . . 96 C.3 PIO. . . 97 C.4 SPIO. . . 98

Tabeller

2.1 Data för genomsnittligt rembaserat linjärdon med 1 meters aktionslängd. . . 3

2.2 Enhetsbeteckningar och dess betydelser. . . 3

5.1 Format för data skickad till SPIO-kortet via USART. . . 66

5.2 Format för data skickad från SPIO-kortet via USART. . . 66

5.3 Operationsbeskrivarna som används. . . 74

5.4 Specialbytes som används. . . 74

5.5 Register som används. Byte 2 är inversen av byte 1. . . 74

5.6 Lägen som används för MODE_REG. Byte 2 är inversen av byte 1. . . 75

5.7 MACTALK skrivsekvens. . . 75

5.8 MACTALK lässekvens. . . 75

Kapitel 1

Bakgrund

Då företag ställer ut på mässor kan ett uppseendeväckande element i montern bidra till ökade besökarantal. Då ökar även chansen till er aärsrelationer. Företaget Motion Control i Västerås AB vill därför ta fram ett system för automatisk infångning av bollar som kastas mot det. Systemet skall medge användarinteraktivitet med visionsystem och en större rörlig fångstannordning. Oavsett hur mässbesökaren kastar bollen så skall systemet se till att bollen träar målet. Motion Control vill med demonstratorn visa bredden av företagets kompetens.

Systemet skall designas utifrån krav på snabbhet, robusthet och gränssnitt. Systemet omfattar hårdvara, inbyggd programvara och mjukvara. I uppgiften ingår att deniera vilka krav som skall kunna ställas på systemet, därefter undersöka lämplig hårdvara för mekanik såväl som elektronik. Därefter konstruktion av systemet med framtagning av mjukvara för visionsystem, användargränssnitt, och motorstyrning. Slutligen skall systemet testas och optimeras.

Arbete och dokumentation skall utföras enligt av Motion Control uppsatta direktiv, krav, och önskemål.

Kapitel 2

Problem

2.1 Mekaniskt system

2.1.1 Förutsättningar

Det mekaniska problemet är som följer; en boll som kastas från ett avstånd av ungefär 5 meter skall fångas inom en yta på 1 x 1 meter. Då tanken är att lösa detta med någon form av x/y-system kan det förutsättas att fångstanordningen kommer att starta från ytans mittpunkt. Detta innebär att x/y-systemet måste kunna accelerera 50 cm i x- och y-led samtidigt under den tid det tar för bollen att färdas 5 meter. För att ta fram en rimlig uppskattning för hur lång tid systemet har på sig att färdas denna sträcka genomfördes ett enkelt prov. Några kastare ck kasta en vanlig tennisboll i underhandskast mot ett 1 x 1 meters mål, uppställt fem meter från kastaren på 50 cm höjd. Under detta test framkom en genomsnittlig ykttid på ca: 0,7 sekunder.

För att tillåta för avvikelser i reaktionstid vid tidtagningen och för att ge det slutliga systemet en rimlig marginal, beslöts det att systemet skulle designas med avsikten att bollfångaren skulle kunna nå målytans extrempunkter inom 0,5 sekunder. Att låta systemet accelerera över 50 cm på 0,5 sekunder är dock otillräckligt som begränsande indata för beräkning av de krafter maskinen kommer att utsättas för. Dessa indata tar inte med inbromsning i beräkningen. Under förutsättningen att de motorer som ska driva rörelserna kan retardera lika fort som de kan accelerera en rörelse fås således följande begränsningar; rörelsen skall accelereras 0,25 meter under 0,25 sekunder (och därefter retarderas på samma sätt).

Det enklaste sättet att realisera ett x/y-system är att koppla ihop minst två linjärdon. Dessa är typiskt uppbyggda runt en skruvstång eller en kuggrem. Vid en snabb översikt av marknaden visar det sig att varianterna med skruvstång generellt sett är starkare och mer exakta än de med remdrift. De är dock betydligt dyrare och långsammare. De remdrivna linjärdonen håller däremot ett rimligt pris samtidigt som de ger tillgång till betydande hastighet och acceleration. Upp till 50 m/s och 20 m/s2 _{är inte alls ovanligt. I gur 2.1 syns de}

relevanta delarna med tillhörande storheter. Tabell 2.1 visar relevanta begränsningar och dimensioner för ett rembaserat linjärdon.

Ett traditionellt x/y-system innebär att vikten för den ena axeln och dess tillhörande motor ska föryttas av den andra axelns motorkraft. Därför gjordes även en snabb informell översikt av marknaden för lämpliga elmotorer. Undersökningen visar att de esta lämpliga motorer ligger runt 5 till 10 kg i vikt. Därför kommer följande beräkningar i delkapitel 2.1.2 ta 15 kg som en rimlig begränsning på den massa som ska accelereras.

Figur 2.1: Rörelsebeskrivning för linjärdon. 2

Parameter Värde Max hastighet. 50 m/s Max acceleration. 20 m/s2

Max kraft i rörelseled. 200 N Remhjuls radie. 20 mm Vikt. 5 kg

Tabell 2.1: Data för genomsnittligt rembaserat linjärdon med 1 meters aktionslängd. Storhet Betydelse

s Sträcka mellan initial och slutlig position. u Initial hastighet.

v Slutlig hastighet.

a Den konstanta accelerationen. t Tid från initialt läge till slutligt läge. F Kraft.

τ Vridmoment. m Massa.

r Radie.

Tabell 2.2: Enhetsbeteckningar och dess betydelser.

2.1.2 Matematiken

Ur följande ekvationer tas de krav som behöver ställas på motorer och linjärdon fram. De begänsningar som diskuterats i föregående delkapitel används som indata.

ˆ Massan som ska yttas ska kunna väga upp till 15 kg. ˆ Massan ska kunna föryttas 0,25 meter på 0,25 sekunder. ˆ Linjärdonens kuggremshjul har en radie på 20 mm.

s = ut +1 2at

2 _(2.1)

a = 2 (s − ut)

t2 (2.2)

Om utgångshastigheten sätts till u = 0 i ekvation 2.2 kan följande uttryck förenkla till: a = 2s

t2 (2.3)

Sätts s = 0, 25 och t = 0, 25 i ekvation 2.3 blir accelerationen a = 8 m/s2_{. Accelerationen tillsammans med}

massan 15 kg sätts så in i Newtons andra lag.

F = ma (2.4)

= 15 × 8 = 120N

Den erfoderliga kraften blir 120 N. Vridmomentet är kraften F gånger hävarmens längd r på 20 mm.

τ = F r (2.5)

= 120 × 0, 02 = 2, 4Nm

Således står det klart att en motor kapabel att leverera ett vridmoment på 2,4 Nm är tillräckligt för ända-målet. Vad beträar de linjära ställdonen skall de kunna hantera minst 120 N, men vid undersökning står det

klart att även begränsningar för max hastighet behöver beräknas.

v = at (2.6)

= 8 × 0, 25 = 2m/s

De linjära ställdonen behöver alltså klara en hastighet på minst 2 m/s.

2.1.3 Krav

För en vidare analys av lämliga motorer såväl som linjärdon kommer följande krav ställas. ˆ Motorerna ska kunna generera ett vridmoment på minst 2,4 Nm.

ˆ Linjärdonen ska klara av en hastighet på minst 2 m/s. ˆ Linjärdonen ska klara av en acceleration på minst 8 m/s2_.

ˆ Linjärdonen ska klara av minst 120 N i rörelseled.

2.2 Visionsystem

2.2.1 Inledning

Ett visionsystem är ett system som med något slags bildinfångstenhet och analysmjukvara eller hårdvara, kan användas för maskinstyrning eller automatiserad inspektion. Det kan ske antingen i realtid, eller efter att data samlats in. Bildinfångsenheten kan vara något så enkelt som en linjeskanner med en laser, en videokamera, eller till och med en värmekamera. Det nns mer avancerade industriella alternativ till kameror, med snabba gräns-snitt såsom gigabit-ethernet, men det går även att använda en USB-ansluten webbkamera för konsumentbruk. Allt beror på vad som krävs i robusthet, snabbhet, och kvalitet.

Vissa infångstenheter innehåller inbyggd hårdvara för analys av den data som samlas in. Det kan vara enkla logiska kretsar, mikrokontrollers eller till och med programmerbara FPGA'er. Andra förlitar sig på externa sy-stem, som till exempel en dator. Vissa kameror har viss intelligens för att kunna utföra enklare bildbehandling samt kontrollera kameran i sig. Det kan till exempel röra sig om vitbalans och färgmättnad. Många konsument-kameror, i synnerhet webbkonsument-kameror, saknar möjlighet till inställning av parametrar som dessa. Vissa saknar det helt, andra har automatisk reglering, vilket kan vara problematiskt i ett visionsystem.

Datorbaserade system kräver programvara för den uppgift som skall utföras, och till detta nns självklart möjligheten att programmera något från grunden. Detta är dock tidskrävande och att analysera en större bild i realtid är en krävande uppgift. Många av de operationer som kan vara av intresse att utföra på en bild nns det någon som tänkt på tidigare, varför det kan löna sig att leta reda på en beprövad och optimerad algoritm. Det nns kommersiella programvaror som på ett enkelt sätt låter användaren plocka ihop sin önskade funktionalitet på en nivå där funktion sätts över den faktiska implementationen i kod. Det nns även kodbibliotek som kan användas för att implementera optimerade algoritmer i egen kod. Dessa låter användare bygga en mer specialiserad och optimerad programvara för just deras ändamål. En sådan kan bli bättre optimerad än något som tas fram i en kommersiell programvara, men kräver just mer arbete och kunskap om programmering.

2.2.2 Krav

Systemet för infångning av bollar kräver en snabb behandling av en videoström för att detektera och spåra bollen. Detta talar för att använda en lösning där mycket av behandlingen sker i hårdvara. En annan parameter som har stor vikt är systemets pris. Här har hårdvarubehandling en nackdel, då dessa tenderar att vara markant dyrare är mjukvarubaserade system. Detta beror på att tekniken än så länge är så pass ny att det nns få aktörer på marknaden. För att få upp hastigheten på ett mjukvarubaserat system kan prestandakomponenter användas i den dator som skall sköta behandlingen, vilket är betydligt billigare. En industriell kamera har ofta bättre monteringsmöjligheter än en konsumentkamera. Även optik och bildsensor håller högre prestanda. Vad som dock talar mot använding av en industriell kamera i detta projekt är priset på dessa. Även den billigaste kamerans pris är uppåt 10000 SEK utan optik, som således tillkommer.

Av hänseende till detta kommer analysen inriktas på ett visionsystem med en kamera från konsumentmark-naden i kombination med en standarddator med bättre prestanda. Till programvara för bildbehandling kommer främst öppna, men även billigare betalalternativ att undersökas.

2.3 Systemkravspecikation

Denna specikationen har tagits fram i samförstånd med Motion Control för att uppfylla de krav och önskemål som företaget ställer. Maskinen är avsedd att stå ute i en relativt oskyddad mässmiljö, vilket ställer stora krav på säkerhet.

2.3.1 Funktionskrav

Demonstratorn skall användas på mässor av besökare som ej har kunskap om demonstratorn sedan tidigare. ˆ Krav 1. Demonstratorn skall kunna ta emot bollar som kastas från ett avstånd av maximalt sex, minimalt

tre meter.

Ljusförhållande såväl som graden av radiostörningar kan variera mellan olika lokaler. Enhetens funktion får därför inte variera med olika miljöer.

ˆ Krav 2. Demonstratorn skall fungera lika bra i olika slags belysning. Lysrör, strålkastare, etc.

För att underlätta utvecklingen är det bra om så mycket som möjligt av utrustningen består av färdiga moduler, så att så lite som möjligt behöver nytillverkas i fråga om kretskort.

ˆ Önskemål 1. Inga egenutvecklade kretskort.

2.3.2 Gränssnittskrav

Gränsytekraven redogör för hur systemet skall kommunicera med omgivningen samt i viss mån internt mellan systemkomponenterna.

Mekaniska gränssnitt

Det X/Y-bord som ämnas användas för infångning av bollen, står för det mekaniska gränssnittet mot användaren. ˆ Krav 3. X/Y-bordet måste kunna föryttas mellan två extrempunkter på under en sekund.

Signalgränssnitt

Hit räknas det visionsystem som förser systemet med indata om bollens position, samt kommunikation mellan visionsystemet, värddatorn, och den mekaniska aktuatorn. Kameran måste vara snabb nog för att ge tillräckligt många bilder om bollens position.

ˆ Krav 4. Kameran måste kunna ta minst 30 bilder per sekund.

ˆ Krav 5. Dataöverföringen mellan kamera och värddator måste kunna föra över bilddata motsvarande kamerans upplösning och bildrutehastighet.

Då en bärbar dator avses att användas som värddator, är gränssnitten begränsade. USB är en av få anslutnings-möjligheter som med säkerhet kan nnas på de esta moderna bärbara datorer.

ˆ Önskemål 2. Kommunikation mellan värddator och de mekaniska aktuatorerna sker med fördel via ett USB-gränssnitt och en signalomvandlare passande det protokoll som används.

Programvarugränssnitt

Den programvara som styr demonstratorn från värddatorn.

ˆ Önskemål 3. Programvaran får med fördel visa statistik över kast och annan data.

2.3.3 Driftkrav

Start/Stopp

Demonstratorn är tänkt att fungera som ett dragplåster till montern men är inte huvudsyftet med montern. Därför skall den vara enkel att hantera och inte ta för mycket tid i anspråk av medarbetaren som företräder företaget.

ˆ Krav 6. Demonstratorn måste förses med nödstopp som omedelbart stoppar mekaniska rörelser på X/Y-bordet, samt bryter spänningen till eventuellt utsatta delar. Ett stopp på enheten, samt en kabel på ca. fem meter till medarbetaren.

ˆ Krav 7. Återaktivering efter nödstopp får inte orsaka oförutsedd rörelse.

ˆ Krav 8. Demonstratorn skall vara enkel och snabb att montera och demontera inför, samt efter, utförda mässor. Max fem minuter från beslut att packa ihop till dess att den är färdig att yttas.

Eektförbrukning

Då en mässlokal kan ha olika möjligheter till kraftförsörjning för montrarna, krävs att kraven som demonstratorn ställer på kraftförsörjningen är relativt små.

ˆ Krav 9. Hela demonstratorn inklusive värddatorn skall drivas på 230V 50Hz enfas nätspänning, max 10A.

2.3.4 Kapacitetskrav

Kapacitetskraven specicerar hur mycket demonstratorn skall klara av själv utan inverkan från operatören. ˆ Önskemål 5. Demonstratorn skall med fördel kunna ta emot er än en boll innan de måste återhämtas.

Alternativt automatiskt skicka tillbaka dem.

2.3.5 Konstruktionskrav

Övergripande krav

ˆ Krav 10. Projektet ska följa Motion Controls uppsatta regler och instruktioner för projekt, gällande konstruktion och programmering.

Mjukvara

Programmeringsspråket C är standard hos företaget Motion Control. ˆ Krav 11. Mjukvara skall utvecklas i programmeringsspråket C. Dimensioner

Fångstannordningen skall kunna manövreras över en yta på en kvadratmeter. Av denna orsak blir hela X/Y-bordet något större än detta. Trots den relativt stora dimensionen skall hela demonstratorn vara så enkel som möjligt att förvara och förytta.

ˆ Krav 12. Demonstratorn inklusive transportlåda får inte vara större än att den går igenom en standard-dörr, 200 x 200 x 90 cm.

ˆ Önskemål 6. Kringutrustning får gärna förvaras i X/Y-bordet vid transport och förvaring för att mini-mera utrymmesåtgången.

2.3.6 Dokumentationskrav

Eftersom demonstratorn utvecklas på uppdrag av Motion Control skall deras regler och anvisningar följas i fråga om dokumentationskrav.

ˆ Krav 13. Dokumentation och programkod skall följa de uppsatta regler och anvisningar som nns på Motion Control.

För att underlätta vidareutveckling och förståelse för hur programkoden opererar är det viktigt att den är strukturerad och kommenterad ordentligt så att det går att följa programödet.

ˆ Krav 14. Källkodsler och ändringar i dessa skall vara noggrant kommenterade på svenska enligt Motion Controls standarder.

2.3.7 Kravlista

Nr. Kravbeskrivning

1 Demonstratorn skall kunna ta emot bollar som kastas från ett avstånd av maximalt sex, minimalt tre meter.

2 Demonstratorn skall fungera lika bra i olika slags belysning. Lysrör, strålkastare, etc. 3 X/Y-bordet måste kunna föryttas mellan två extrempunkter på under en sekund. 4 Kameran måste kunna ta minst 30 bilder per sekund.

5 Dataöverföringen mellan kamera och värddator måste kunna föra över bilddata motsvarande kamerans upplösning och bildrutehastighet.

6 Demonstratorn måste förses med nödstopp som omedelbart stoppar mekaniska rörelser på X/Y-bordet, samt bryter spänningen till eventuellt utsatta delar. Ett stopp på enheten, samt en kabel på ca. fem meter till medarbetaren.

7 Återaktivering efter nödstopp får inte orsaka oförutsedd rörelse.

8 Demonstratorn skall vara enkel och snabb att montera och demontera inför, samt efter, utförda mässor. Max fem minuter från beslut att packa ihop, till dess att den är färdig att yttas.

9 Hela demonstratorn inklusive värddatorn skall drivas på 230 V 50 Hz enfas nätspänning, max 10 A. 10 Projektet ska följa Motion Controls uppsatta regler och instruktioner för projekt, gällande

konstruktion och programmering.

11 Mjukvara skall utvecklas i programmeringsspråket C.

12 Demonstratorn inklusive transportlåda får inte vara större än att den går igenom en standarddörr, 200 x 200 x 90 cm.

13 Dokumentation och programkod skall följa de uppsatta regler och anvisningar som nns på Motion Control.

14 Källkodsler och ändringar i dessa skall vara noggrant kommenterade på svenska enligt Motion Controls standarder.

2.3.8 Önskemålslista

Nr. Kravbeskrivning

1 Inga egenutvecklade kretskort.

2 Kommunikation mellan värddator och de mekaniska aktuatorerna sker med fördel via ett USB-gränssnitt och en signalomvandlare passande det protokoll som används.

3 Programvaran får med fördel visa statistik över kast och annan data.

4 Val att visa kamerans vy kan vara en väg till ytterligare intresse av besökare.

5 Demonstratorn skall med fördel kunna ta emot er än en boll innan de måste återhämtas. Alternativt automatiskt skicka tillbaka dem.

6 Kringutrustning får gärna förvaras i X/Y-bordet vid transport och förvaring för att minimera utrymmesåtgången.

Kapitel 3

Analys

Detta kapitel visar vilka produkter som har undersökts för projektet samt ger en rekommendation för vidare modellering.

3.1 Funktionsundersökning av drivsystem

3.1.1 Inledning

Denna del innehåller en undersökning av motorer, linjära ställdon och motordrivenheter lämpliga för ett x/y-system.

Förutsättningar och avgränsningar

Det nns ett stort antal möjliga vägar att gå för att åstadkomma x/y-positionering. Man skulle kunna tänka sig skruvdrivna linjära ställdon eller mer exotiska alternativ, så som seriella eller parallella robotar, men dessa alternativ faller på hastighetsprestanda eller pris. Denna undersökning begränsar sig till remdrivna linjära ställdon. Dessa har era fördelar; lägre pris, högre acceleration och hastighet, och mindre underhåll. De har lägre noggrannhet än skuvdrivna don, men den tänkta applikationen kräver inte högre noggrannhet än positionering inom en millimeter så remdrift är nöjaktigt. Vad beträar motoralternativ så är ej heller stegmotorer med i undersökningen. Dessa lämpar sig ytterligt till noggrann positionering men klarar inte de hastigheter och krafter som slutapplikationen kräver.

3.1.2 Linjära ställdon

Nook Industries EGZ40

Parameter Värde Max kraft i slädens

x-led/y-led 350 N/315 N Max hastighet 2 m/s Max acceleration -Vikt 3,94 kg Mått utan släde (lxbxh) 1225x58x58mm Leveranstid -Pris

-Figur 3.1: Nook Industries EGZ40 8

Nook Industries ELZU30

Parameter Värde Max kraft i slädens

x-led/y-led 180 N/60 N Max hastighet 2 m/s Max acceleration -Vikt 7,6 kg Mått utan släde (lxbxh) 1240x1210x42mm Leveranstid 3 - 4 veckor Pris ca: 42 000 SEK

Figur 3.2: Nook Industries ELZU30

En smidig, färdig lösning som har fördelen av att ha ganska låg rörlig vikt. Systemet bygger på en enda lång rem som genom manipulering av två fasta motorer tillsammans sköter både x- och y-rörelse.

HepcoMotion PDU2

Parameter Värde Max kraft i slädens

x-led/y-led 280 N/500 N Max hastighet 6 m/s Max acceleration -Vikt 3,6 kg Mått utan släde (lxbxh) 1291x60x40mm Leveranstid 4 veckor Pris ca: 6 100 SEK

Figur 3.3: HepcoMotion PDU2 Thomson PowerLine WM60Z

Parameter Värde Max kraft i slädens

x-led/y-led 850 N/1400 N Max hastighet 2,5 m/s Max acceleration 20 m/s2 Vikt 8,8 kg Mått utan släde (lxbxh) 1420x60x65,5mm Leveranstid 3 - 4 veckor Pris 12 706 SEK

ELMORE Light 30 SP1 Parameter Värde Max kraft i slädens

x-led/y-led 250 N/340 N Max hastighet 4 m/s Max acceleration 50 m/s2 Vikt 4,1 kg Mått utan släde (lxbxh) 1287x43x60mm Leveranstid 7 veckor Pris 6 300 SEK

Figur 3.5: ELMORE Light 30 SP1

3.1.3 Motorer

PrintedMotorWorks GM16 Parameter Värde Nominell spänning 80 VDC Nominellt vridmoment 2,25 Nm Nominellt varvtal 3000 RPM Vikt 8 kg Leveranstid 6 - 8 veckor Pris 20 000 SEK Figur 3.6: PrintedMotorWorks GM16

Motorn är av typen pannkaksmotor, även kallad axial-gap motor eller printed rotor motor. Den har en väldigt lätt rotor och accelererar därför väldigt snabbt. Den har stort vridmoment för sin storlek och lägre varvtal än traditionella motor, vilket gör att den lämpar sig väl till positioneringsarbeten. Det går att montera på encoder om det skulle behövas. GM16 är en borstad DC motor.

JVL MAC800

Parameter Värde Nominell spänning 230 VAC Nominellt

vridmoment 2,38 Nm Nominellt varvtal 3000 RPM Vikt 3,5 kg Leveranstid Omedelbart Pris ca: 11 000 SEK Rabatterat pris 6 000 SEK

JVLs MAC serie möjliggör väldigt smidig och enkel rörelsestyrning. Den innehåller förutom motorn, en högupp-löst quadrature encoder och kraftelektronik. Inkoppling av matningsspänning och en signalkabel (t.ex. RS232 eller USB) är allt som behövs för att börja skicka positions- eller hastighetsdata till den.

Mavilor BLS72

Parameter Värde Nominell spänning 230 VAC Nominellt vridmoment 1,76 Nm Nominellt varvtal 3000 RPM Vikt -Leveranstid 7 veckor Pris 7 900 SEK Figur 3.8: Mavilor BLS72

3.1.4 Motordrivenheter

Geckodrive G340 Parameter Värde Matningsspänning 18-80 VDC Drivspänning 18-80 VDC Drivström 20 A Kommunikations-möjligheter Steg/Riktning Styrmöjligheter Endast stegning Sensoringångar Quadrature

encoder Leveranstid 2 veckor Pris ca: 1 100 SEK

Technosoft IDM640 Parameter Värde Matningsspänning 12-80 VDC Drivspänning 12-80 VDC Drivström 8 A

Kommunikations-möjligheter RS232, CAN,Steg/Riktning Styrmöjligheter Vridmoment, Hastighet, Posotion, Stegmotor-emulering Sensoringångar Quadrature encoder, Absolute serial encoder Leveranstid 2 - 3 dagar Pris ca: 6 500 SEK

Figur 3.10: Technosoft IDM640

IDM640 är en välutrustad motordrivenhet. Den kan driva borstlösa DC och AC motorer, borstade DC motorer, stegmotorer, och linjära motorer.

Infranor CD1-p Parameter Värde Matningsspänning 230/400-480 VAC Drivspänning 230/400-480 VAC Drivström 10,5/7,2 A Kommunikations-möjligheter RS232 Styrmöjligheter Hastighet Sensoringångar Encoder Leveranstid 7 veckor Pris 15 900 SEK Figur 3.11: Infranor CD1-p

CD1-p är en motordrivare för AC-motorer. En mindre variant av denna (CD1-a) har använts i annat projekt inom företaget.

3.1.5 Förslagsställning

Förslag 1

ˆ 4 st. PDU2 (ca: 6 100 SEK/st.) ˆ Övrigt  2 st. Linjärgejdrar  2 st. Torsionsaxlar  2 st. Linjärlager  2 st. Växellådor

Pris exklusive 'övrigt' ca: 36 400 SEK.

Förslag 1 har en stor fördel i att motorn innehåller en motordrivenhet såväl som en encoder. Ingen anpassning mellan delarna behövs; inga kablar, ingen montering. Ur hänseendet att komma snabbt mot mål i projektet är det en överlägsen produkt.

Förslag 2

ˆ 2 st. GM16 (ca: 20 000 SEK/st.) ˆ 2 st. IDM640 (ca: 6 500 SEK/st.) ˆ 4 st. PDU2 (ca: 6 100 SEK/st.) ˆ Övrigt  2 st. Linjärgejdrar  2 st. Torsionsaxlar  2 st. Linjärlager  2 st. Växellådor  2 st. Encoders  1 st. Kraftaggregat 80 V 22 A Pris exklusive 'övrigt' ca: 77 400 SEK.

Förslag 2 med motordrivenhet från Technosoft är å andra sidan en väldigt kraftfull lösning. IDM640 är väldigt mångsidig. Den klarar av att driva de esta motortyper och har era intressanta administrationsmöjligheter, som ex. loggning av rörelser för att plocka fram hur mycket ström motorn drar vid en viss acceleration. Nackdelen med förslaget är behovet av extern strömförsörjning då motordrivenheten drivs med 18 - 80 VDC.

Förslag 3

ˆ 2 st. BLS72 (7 900 SEK/st.) ˆ 2 st. CD1-p (15 900 SEK/st.) ˆ 4 st. PDU2 (ca: 6 100 SEK/st.) ˆ Övrigt  2 st. Linjärgejdrar  2 st. Torsionsaxlar  2 st. Linjärlager  2 st. Växellådor  2 st. Encoders

Pris exklusive 'övrigt' ca: 72 000 SEK.

Motorn i förslag 3 drivs med fördel direkt från bentlig nätanslutning. Nackdelen i förslaget ligger i dess be-gränsade kontrollmöjlightet då motordrivenheten endast kan hastighetsstyras. Det innebär att encoder-signalerna måste behandlas på något annat sätt för att möjliggöra postitionskontroll.

Förslag 4

ˆ 2 st. MAC800 (6 000 SEK/st.)

ˆ Övrigt

 3 st. Linjärgejdrar  5 st. Linjärlager

Pris exklusive 'övrigt' ca: 12 000 SEK.

Den säljande punkten för förslag 4 är dess låga pris kopplat till snabb leveranstid. Nackdelen ligger i osäker-heten om huruvida rörelseprincipen kommer att kunna implementeras utan problem.

Principbeskrivning

Förslag 1 - 3 (gur 3.12) bygger på fyra stycken linjärdon monterade i en kvadrat, med två don monterade horisontellt och två don vertikalt. Mellan de horisontella resp. vertikala donen monteras så varsin linjärgejd som kopplas ihop i mitten med hjälp av två linjärlager. Alla tre förslagen bygger på linjärgejdern PDU2 pga. pris och leveranstid.

Figur 3.12: Principskiss för förslag 1 - 3.

Förslag 4 (gur 3.13) innebär egenkonstruktion av x/y-rörelsen i högre utsträckning. En egen variant av principen som ELZU30 bygger på skall då tillverkas. Förslaget bygger på två horisontella resp. en vertikal linjärgejd hopkopplade och aktuerade mha. en lång kuggrem.

Figur 3.13: Första CAD-utkast av förslag 4.

3.1.6 Rekommendation

Undersökningen har i huvudsak inriktat sig på pris- och leverans-betänkligheter på produkter som har tillräcklig funktion. Under förslagsställningen (3.1.5) nns även specicerat övriga detaljer för ett komplett rörelsesystem. Dessa är dock av sån art att det varken nns pris- eller leverans-betänkligheter. Efter företagets önskemål rekommenderas därför förslag 4.

3.2 Funktionsundersökning av visionsystem

3.2.1 Inledning

Denna del innehåller en undersökning av ett urval av de visionsystem och metoder för visuell objektspårning som förekommer på marknaden.

Förutsättningar och begränsningar

Då ett visionsystem är ett relativt krävande system som det dessutom sker mycket utveckling inom, begränsas undersökningen till system som uppdateras relativt ofta, minst årligen, och som då visar att det fortfarande är aktuellt att använda i nya konstruktioner. Dessutom utesluts industriella lösningar som tenderar att ha en hög kostnad, då detta projekt har en låg budget.

3.2.2 OpenCV

Parameter Värde Program eller programmerings-bibliotek Programmerings-bibliotek för C, C++, och Python. Ljusförhållanden och störningskänslighet Beroende på kamera. Hastighet Beroende på kamera och värdsystemets processorhastig-het. Uppdaterad Version 2.0 2009-09-30 Systemkrav PC med Linux,

Windows (2000, XP, Vista), eller Mac OS X Ytterligare komponenter Kamera Dokumentation Från blandade källor Pris Gratis, BSD-licens Figur 3.14: OpenCV

OpenCV är ett programmeringsbibliotek för C, C++, och Python, med funktioner för bildbehandling. Projektet startades av Intel och är fritt att använda kommersiellt. Dessutom uppdateras det ett par gånger per år.

OpenCV stödjer ertalet operativsystem, Linux, Mac OS X, och Windows. Vad gäller Windows är det testat för versionerna 2000, XP, samt Vista. Med nyare versioner är det ej fullt testat varför korrekt funktionalitet ej kan säkerställas.

Avancerade matematiska beräkningar på graska element kan utföras med hjälp av biblioteket. Men bild-behandling är ändå ett tungt arbete, varför prestandan kan påverkas kraftigt beroende på vilken algoritm som används. Vid tester som författaren till detta dokument utfört med en relativt dålig algoritm blev bildfrekvensen 16Hz vid upplösningen 640x480. Potentialen nns i OpenCV, det gäller bara att använda dess resurser på rätt sätt.

Dokumentationen av projektet kan tyckas bristfällig vid en första anblick, men mycket information nns att tillgå på spridda platser online vid sökning på OpenCV.

3.2.3 RoboRealm

Parameter Värde Program eller programmerings-bibliotek Program med API Ljusförhållanden och störningskänslighet Beroende på kamera. Hastighet Beroende på kamera och värdsystemets processorhastig-het. Uppdaterad Version 2.15.2 2010-02-19 Systemkrav PC med Windows (2000, XP, Vista, 7). 2GHz+ processor Ytterligare komponenter Kamera Dokumentation På hemsida Pris 89 USD Figur 3.15: RoboRealm

RoboRealm är ett program med GUI för bildbehandling, antingen från l, eller från videoenhet. Det har ett API för att ge externa program tillgång till funktionalitet och data. Det går även att inkludera plugin-moduler för att utöka funktionaliteten i programmet om så krävs.

Projektet började som open-source, men gick i och med version 2.0 över till betalversion. I och med detta började utvecklarna att samarbeta med Microsoft Robotics. Det pris som anges avser installation av program-varan på en dator. Programprogram-varan kan testas i 30 dagar utan köp. Med licensen kommer möjligheten att köra programmet i dolt läge, t.ex. för integration i andra program. Dessutom ges fria uppdateringar i ett år och fri support via programmets forum på hemsidan.

RoboRealm stödjer endast Windows som operativsystem. Det skall vara kompatibelt med Windows 7 enligt kommentarer i hemsidans forum. Inget om detta nns dock angivet i den dokumentation som nns.

I och med att det är ett program, och med ett graskt gränssnitt, kan parametrar ändras under körtid. Detta kan korta ned tiden för att ta fram en fungerande lösning.

3.2.4 Wiimote Whiteboard

Parameter Värde Program eller programmerings-bibliotek Program Ljusförhållanden och störningskänslighet Använder sig av IR. Hastighet 100Hz Uppdaterad Version 0.3 2008-08-20 Systemkrav PC med Windows 32-bit (XP, Vista) Ytterligare

komponenter Wiimote, Bluetooth-kommunikation med PC Dokumentation På hemsida och

bifogat med programmet. Pris Gratis

Figur 3.16: Wiimote Whiteboard

Wiimote Whiteboard är egentligen tänkt som ett inmatningsdon till en PC, istället för mus. Det utnyttjar den IR-känsliga kamera som en Wiimote innehåller, för att positionsbestämma en källa för IR-ljus. Om denna kamera riktas mot en skärm, eller projektion, kan en penna med IR-ljuskälla användas för navigation. Programmet låter först användaren kalibrera Wiimote-enheten mot skärmen, för att programmet skall veta vart bildytan benner sig och därmed kunna efterlikna användarens rörelser med pekaren.

Då pekarens position på skärmen lätt kan extraheras, kan detta program även användas för att spåra objekt, bara de kan urskiljas från bakgrunden med IR-ljus. Antingen genom att objektet självt sänder ut IR, eller att det reekterar det från en källa vid sidan av.

En fördel med denna metod är att i stort sett all detektering och positionsbestämning är färdig i detta program och fokus kan läggas på styrning av den aktuator som används.

3.2.5 GpuCV

Parameter Värde Program eller programmerings-bibliotek Programmerings-bibliotek för C och C++ Ljusförhållanden och störningskänslighet Beroende på kamera. Hastighet Beroende på kamera och GPU/CPU hastighet Uppdaterad Version 0.4.2 2008-06 Systemkrav Windows XP med Visual Studio (version 6, 2003, 2006, eller 2008) eller Linux. Hårdvarukrav nns under kap. 6.3 Ytterligare komponenter Kamera. Dokumentation På hemsida. Pris Gratis, CeCILL-B -licens . Figur 3.17: GpuCV

GpuCV är en variant på OpenCV. Det har liknade funktionalitet men använder mer av de resurser för beräkning som nns i GPU, och kan därmed utföra vissa typer av beräkningar snabbare. Enligt tester som upphovsmännen publicerat på hemsidan var dessa upp mot tre gånger snabbare än motsvarande hos OpenCV. Dock förutsätter detta ett kompatibelt grakkort.

Det är likt OpenCV ett programmeringsbibliotek för C och C++, med funktioner för bildbehandling. För närvarande stöds Windows och Linux som operativsystem. För Windows är det endast XP som har testats med fullgott resultat.

3.2.6 Sammanfattning

Alla de lösningar som har undersökts är gratis eller har en låg inköpskostnad. De har alla varit uppdaterade relativt frekvent för att säkerställa att det nns en framtid inom dess teknik. De lösningar som undersökts fungerar alla under Windows, främst Windows XP. De som är tänkta att användas vid programmering fungerar även till Linuxbaserade system. Hälften av dem är program som kan ställas in eller modieras för att få till önskad funktion. Den andra hälften utgör programmeringsbibliotek för implementering vid kodande av program. De esta av lösningarna fungerar med era typer av kameror. Detta betyder att de kan användas vid er olika scenarion. Till exempel för behandling av monokroma bilder tagna i mörker med IR-belysning, vanliga bilder i dagsljus, eller kanske med värmekamera. En av lösningarna (Wiimote) använder sig dock uteslutande av IR-ljus, vilket kan vara av fördel om omgivningen gör objekt som skall spåras svårigenkännliga.

Då alla dessa system är PC-baserade kan kostnaden för dedikerad hårdvara sparas in, samtidigt som pro-grammering på en PC-plattform ofta är enklare i hänsyn till testning. Vilken typ av kommunikation som används mellan dator och kameraenhet kan spela roll för hastigheten om det är högupplösta bilder, men mer troligt är det att beräkningarna står för den större tidsrymden.

3.2.7 Rekommendation

Alternativen som behandlas i denna undersökning rekommenderas i fallande skala som följer: ˆ OpenCV

ˆ RoboRealm ˆ Wiimote ˆ GpuCV

Under sektionen 'Fördjupad analys av OpenCV med webbkamera' (3.3) följer en motivering av undersökningens rekommendation av just OpenCV.

3.3 Fördjupad analys av OpenCV med webbkamera

3.3.1 Inledning

Denna del innehåller en produktundersökning av programmeringsbiblioteket OpenCV, för användning till pro-grammering av ett visionsystem. Till detta används en webbkamera av konsumentklass.

Syfte

Syftet med undersökningen är att undersöka hur OpenCV är att arbeta med, samt hur pass sannolikt det är att detta kan komma till nytta vid programmeringen av mässdemonstratorns visionsystem. Till detta används en webbkamera av konsumentklass för att försöka minska projektets kostnader, dvs. en webbkamera med lägre noggrannhet gällande färg, kvalitet, och uppdateringshastighet.

3.3.2 Undersökning

Undersökningen innebar att ett program byggdes för att detektera en tennisboll mot en bakgrund bestående av mestadels olika nyanser av vitt, i den lokal som undersökningen ägde rum i. Genom olika algoritmer maskas den bild som webbkameran tar, för att endast lämna tennisbollen kvar i bilden, så att dess position kan bestämmas. Webbkamera

Specikationerna för den webbkamera som användes vid undersökningen listas nedan. ˆ Emtec W1300SN Snake

ˆ Upp till 1024x768 pixlars upplösning (interpolerad). 640x480 pixlar bildsensor, vilket användes i under-sökningen.

ˆ Uppdateringsfrekvens upp till 30 bildrutor per sekund

Just denna kamera har sämre färgupptagningsförmåga, vilket kan vara en nackdel i fallet med mässdemonstra-torn. Den gulgröna färg som en tennisboll har, uppfattas genom kameran mer som gråblek grön.

Datorns inverkan

De för undersökningen relevanta specikationerna för den dator som användes vid undersökningen listas nedan. ˆ Dell Inspiron I6400

ˆ Intel Centrino Duo T2400 processor på 1.83GHz ˆ 987MHz busshastighet

Då kameran ger en bild på 640x480 pixlar med tre färger om vardera åtta bitars djup, blir det totalt 921'600 byte som skall processas i era steg, 30 gånger per sekund, för att komma upp i kamerans maximala uppdaterings-frekvens. Det innebär ett rent dataöde på 27'648'000 byte per sekund för en enda operation. Detta motsvarar 220 Mbit/s. Det bör dock bäras i åtanke att det är ertalet operationer som behöver utföras innan datorn kan tolka koordinater ur bilden. Till exempel måste systemet fungera i olika ljusförhållanden utan alltför stora om-ställningar. Detta kräver ltrering som klarar mer än bara ett specikt fall, och därmed även är mer krävande än ett specikt lter. Det är mycket information som skall processas på kort tid, varför processorhastighet och busshastigheter bör vara höga för att ej få sådana askhalsar. Man bör således vara försiktig med att välja en kamera med för hög upplösning.

Programmering med OpenCV

Ett program för spårning av en tennisboll skrevs för att testa den erbjudna funktionaliteten. Runt om den kod som sköter bildbehandlingen nns även kod för att hålla koll på uppdateringsfrekvensen, både för stunden samt den maximala samt minimala frekvensen under den senast gångna sekunden. Denna information presenteras i samband med den resulterande videoströmmen för att avgöra systemets reaktionsförmåga och snabbhet mer exakt än genom visuell uppskattning.

Programuppstart Först och främst initieras och allokeras minnesplatser för variabler och bilddata, därefter associeras en fångstenhet för video med programmet. Denna fångstenhet måste kunna detekteras av värdope-rativsystemet för att den skall kunna användas av OpenCV. Fönster öppnas för presentation av bilddata. I undersökningens fall presenteras den ursprungliga bilden, så som den kommer från fångstenheten, samt den bearbetade bilden.

Fångst av bildruta Som första steg i loopen för bildbehandling, skall en ny bildruta läsas in från fångstenhe-ten. Därefter kopieras denna bildruta till en extra minnesplats för att möjliggöra beräkningar utan att påverka ursprungsbilden. Dessutom skapas plats för ytterligare två bildrutor. En av dem för en bild i gråskala av samma dimensioner som ursprungsbilden, samt en för en wire-frame representation av bilden senare.

Färglter Den implementation av färglter som användes var en egenutvecklad variant som inte är speciellt sostikerad. Detta betyder att den mycket väl kan göras snabbare, men information om detta har ej vart funnen i någon dokumentation om OpenCV. Denna lösning kontrollerar pixel för pixel om en vald kanals färg är dominerande, så när som på tio enheter. I detta fall användes grön kanal. Dvs. om det är mer grönt än blått eller rött i en pixel, så lämnas denna pixel orörd. Är det mer rött eller blått än värdet för grönt minus tio, så nollställs alla värden för den pixeln vilket resulterar i svart. Då det är åttabitars färgvärden, blir det ett intervall på 0-255, och gränsen på tio enheter motsvarar därmed ca. 1/25-del av färgskalan.

Färgkonvertering När en viss färg har maskats ut, kan bilden konverteras till gråskala. Detta reducerar mängden data till en tredjedel, då två färgkanaler utelämnas. Även om konverteringen tar på resurserna, sparas resurser in på vidare hantering av bilden efter detta steg, då det är mindre data att ta hand om. Dessutom fungerar inte alla OpenCV's funktioner på bilder med mer än en kanals färgdjup. Ett par av dessa funktioner behöver nämligen användas efter detta steg.

Tröskelvärdeskonvertering För att underlätta igenkänning av objektet ytterligare, görs bilden som var i gråskala om till svartvit. Detta görs i två steg, det första tar bort de pixlar som är mörkare än ett specikt värde. Detta för att maska bort detaljer i bilden som är mörkt gröna, då tennisbollen har en ljusgrön nyans. I det andra steget tas alla kvarvarande pixlar som är ljusare än ett annat värde bort. Detta för att ta bort en del brus som uppkommer i bilden. Kvar nns ett intervall mellan de satta värdena, som nu alla har samma intensitet.

Erodering För att ytterligare ta bort oönskade detaljer ur bilden, läggs ett eroderande lter på. Detta minskar ytan på de fält som nns kvar efter tröskelvärdeskonverteringen. Nu försvinner ytterligare delar av det brus som kan förekomma. Tennisbollen har en storlek som relativt bruset är så pass stor att denna inte påverkas nämnvärt av detta lter.

Kantdetektering När större delen av bruset är borttaget körs en kantdetektering på den återstående bilden. Denna lämnar en wire-frame som märker ut konturerna på de kvarvarande objekten.

Cirkeldetektering När ltrering och omvandling till wire-frame har utförts, kan cirkeldetektering ske. Detta använder en av OpenCV tillhandahållen algoritm som är relativt krävande gentemot de andra stegen i program-met. Hur lång tid detta steg tar, beror på hur många kanter det nns i den bild som används i detekteringen, en viktig anledning till att ta bort så mycket brus som möjligt innan detta steg. Med dålig ltrering gjorde detta steg att den totala uppdateringsfrekvensen sjönk till närmare 0.2 bildrutor per sekund. Det är fem sekunder mellan var bildruta! Detta är alldeles för långsamt för mässdemonstratorn.

Presentation Slutgiltigt presenteras informationen för användaren. De två fönster som tidigare öppnas, upp-dateras nu med data om dels ursprungsbilden, dels bilden av den wire-frame som genererats. Detta för att göra det möjligt att jämföra dem två för att kunna förbättra algoritmerna. Information om bildrutefrekvensen presenteras även, likväl ritas en ring in i originalbilden för att markera positionen för den cirkel som upptäckts.

3.3.3 Resultat

OpenCV kan mycket väl vara en lösning till det visionsystem som behövs till mässdemonstratorn. Det är mångsidigt och kongurerbart genom att du som programmerare väljer parametrar, ordningsföljd, samt även kan konstruera egna funktioner genom den åtkomst som OpenCV ger till bildobjekten. Mycket användbar funktionalitet nns att implementera, även om inte allt av detta utnyttjades till fullo i denna undersökning. Exempel och tips nns att tillgå från personer som delar med sig av sina kunskaper på Internet.

Diskussion

Det står klart att detektering av cirklar eventuellt ej är rätt väg att gå. Med tennisbollen i kamerans synfält, var bilduppdateringsfrekvensen nere på fem bildrutor per sekund, eller lägre. Det kan fungera bättre med någon typ av blob-detektering, vilket dock ej testades under denna undersökning. En sådan detektering nner större områden med samma färgvärde, istället för cirkeldetekteringens geometriska undersökning. En blob-detektering torde vara snabbare och mindre resurskrävande.

Vidare stod det klart att bildbehandlingen är en resurskrävande uppgift. Aktivitetshanteraren på den da-tor som användes vid undersökningen visade på hög utnyttjandegrad av processorns båda kärnor, särskilt då cirkeldetekteringen utförs. För att få uppdateringsfrekvens på 30 bilder per sekund behövs förvisso optimerad kod, men då mässdemonstratorn ej kommer att benna sig i en kontrollerad miljö måste koden klara av de uktuationer som kan uppstå i form av till exempel ljusförhållanden. Detta kan föra med sig en långsammare kod, vilket då kan viktas upp med ett snabbare system att köra koden på.

I viss mån kan miljön kontrolleras, genom att kameran riktas mot en kontrollerad bakgrund, lämpligen den fångstutrustning som används. Dock kvarstår att olika ljusförhållanden kan få den boll som används att framträda i olika nyanser.

Dessutom hade den vid undersökningen använda webbkameran så pass dålig färgåtergivning att ljusare nyanser av färger i vissa fall övergick till en ljusgrå nyans.

Slutsats

Till projektet med mässdemonstratorn kan OpenCV mycket väl användas, programmeringsmässigt nns poten-tialen. Den webbkamera som användes lämnar dock önskemål om bättre färgåtergivning, för att bättre skilja färger åt, över hela färgskalan, och därmed bättre kunna hantera variationer i belysningen. En upplösning runt 640x480 är önskvärt med avseende på hanterbar datamängd.

Den relativt låga uppdateringsfrekvensen som uppnåddes med programmet i undersökningen, kan säkerligen förbättras något med bättre algoritmer. Dock tillkommer det kod runtom för beräkning av motorhastigheter och positionsangivelser för dessa. Dessutom skall data läsas in från utrustningen runt om, i form av ändlägesgivare och nödstoppssignal. Dessa tillägg tar också på systemets prestanda, varför processorhastigheten på den dator som systemet skall köras med bör överstiga de 1,83 GHz som datorn i undersökningen kördes på. Undersök-ningsdatorn hade dubbla kärnor, vilket den slutgiltiga datorn även den borde ha. Även minnesresurserna kan spela roll vid behandling av de datamängder som sker, även operativsystemet skall yta på bra i bakgrunden. Undersökningsmaskinens RAM-minne om 1 GB får således ses som ett minimum.

Rekommendation

Följande komponenter rekommenderas således: ˆ OpenCV

ˆ PC-dator med minikrav:

 2 GHz+ med dubbla kärnor  2 GB+ RAM-minne Addendum

Efter undersökningens avslut framkom ett alternativ till webbkamera i Playstation Eye. Playstation Eye är en kamera specikt framtagen för bildtolkning i Sony's spelkonsoll Playstation 3. Den är kapabel att mata ut 60 bildrutor per sekund vid 640x480 pixlar och 120 bildrutor per sekund vid 320x240 pixlar. Drivrutinerna som är framtagna för anslutning till Windows är freeware vid anslutning av 1 - 2 kameror. Anslutning av era kameror kostar pengar. Drivrutinerna ger tillgång till manuell kontroll av kamerans alla parametrar så som bildstorlek, bildhastighet, skärpa, vitbalans, och slutartid. Detta är funktioner som åternns också i industriella kameror men som tyvärr saknas på de esta konsument-webbkameror.

Kapitel 4

Modell

4.1 Övergripande design

Systemet skall kunna ta emot en boll som kastas mot det. Detektering av bollen sker med hjälp av en kamera monterad framför personen som kastar bollen, riktad mot hårdvaran som skall ta emot bollen.

4.2 Mekanisk design

Systemet bygger på en enda lång sluten rem som drivs av två fasta motorer. Detta till skillnad från ett tradi-tionellt x/y-system där motorerna till axel 1 och 2 arbetar var för sig med sin egen axel, och axel 1 måste ytta vikten av både axel 2 och dess motor. I gur 4.2 syns det hur de två motorerna samarbetar för att åstadkomma rörelse i x- och y-led. När de båda drivna hjulen roterar åt samma håll rör sig nyttolasten i x-led, när de roterar åt varsitt håll rör sig lasten i y-led.

En rotation av det ena hjulet två 'steg', kan likställas med att båda hjulen först roterar ett steg åt samma håll och sedan ett steg åt varsitt håll. Ur detta kan man härleda att lasten rör sig ett steg i x-led och ett steg i y-led om bara det ena hjulet rör sig. Med hjälp av arctan(1 steg/1 steg) fås 45 grader. Det visar sig alltså att det går att konstruera ett koordinatsystem med frikopplade axelrörelser om man lutar det 45 grader mot remmarnas riktning istället för att lägga det parallellt med dem.

Stommen till den mekaniska konstruktionen består till stora delar av aluminiumproler av märket Kanya PVS - Basis 50. Det är ett prolsystem som med hjälp av ett ankarsystem är väldigt lätt och snabbt att montera ihop, med en insexnyckel som enda nödvändiga verktyg. Den rörliga delen av konstruktionen består av tre linjärskenor/vagnar av märket Lineartrace T-Race Monorace 28, ett system bestående av stålskenor och vagnar med hjullager för låg friktion. I gur 4.3 syns det hur det rörliga systemet är monterat i stommen. I guren syns även hur motorerna med sina drivande hjul och de xerade resp. rörliga hjulen är monterade. Motorerna är av typen JVL MAC-800; en trefas motor med inbyggd encoder och kraftelektronik. Observera att guren visar konstruktionen från baksidan för att exponera alla detaljer.

4.3 Elektrisk design

Den elektriska designen delas upp i signal och kraft, för att tydliggöra de olika områdena.

4.3.1 Signaldistrubution

Kommunikation mellan dator och motorer sker via RS232 gränssnitt. Ett separat gränssnitt per motor säkerstäl-ler att adressering ej skall ställa till det för motorernas rörelser. Kameran för visionsystemet ansluts via USB. Övrig kommunikation mellan datorn och systemet sker med parallellporten via ett egenutvecklat I/O kort för givare och kontaktorer.

Större delen av all den kommunikation som förekommer i systemet, sker med 24 V signaler. Positionsgivarna är av Reed-typ och optiska. De har inbyggd elektronik och indikering, och ger ut en positiv signal vid aktivering. Denna signal tas in på åtta av de tio parallella ingångar som PIO-kortet tillhandahåller. Kontaktorernas status kan detekteras via de två kvarvarande ingångarna. Till detta används en normalt öppen hjälpkontakt per kontaktor för att även detektera kabelbrott. I fallet med nödstoppet indikerar detta utlöst nödstopp, varefter systemet stoppas. Ett av nödstoppen placeras på styrskåpet, det andra vid kameran utanför enheten.

Figur 4.1: Övergripande design

F Frirullande hjul (xerad position)

D Drivande hjul - kopplade till varsin motor (xerad position)

R Rörliga hjul - rörliga i förhållande till F och D men xerade i förhållande till varandra X X-axel - den påförda rotationen och den resulterande rörelsen i x-led

Y Y-axel - den påförda rotationen och den resulterande rörelsen i y-led Figur 4.2: Principbeskrivning av system med lång rem.

Figur 4.3: Stommen till det mekaniska systemet.

Figur 4.5: Kraftdistrubution.

En av de utgångar som PIO tillhandahåller, styr kontaktorn för motors-ON, dvs. den kontaktor som kon-trollerar spänningssättningen av motorerna i andra hand efter nödstoppskontaktorn. Datorn kan dock ej styra kontaktorn direkt, utan signalen måste först konrmeras manuellt med hjälp av nollspänningsbrytaren, som en extra säkerhetsåtgärd. Den andra utgången styr den lampa som indikerar att styrdatorn vill aktivera motorerna. På detta vis kan olika signaler ges vid olika tillstånd  ett blinkande ljus då styrdatorn vill aktivera motorerna, samt ett fast sken när de är aktiverade.

Utlöst nödstopp indikeras även med en lampa på styrskåpet. Även styrdatorn kan läsa av och meddela nödstoppens status.

4.3.2 Kraftdistrubution

Systemet matas av 230 V enfas växelspänning. Matningen antas vara avsäkrad för 10 A alternativt 16 A. Internt delas systemet upp i två individuellt avsäkrade delar för att minimera risken att överström till motorerna får den externa avsäkringen att utlösas och därmed släcka ned hela systemet.

Kraftmatningen till motorerna passerar först nödstoppskontaktorn för att säkerställa att kraften till dem kopplas från vid nödstopp. Därefter passerar de motors-on kontaktorn för att det ej skall gå att aktivera moto-rerna utan en tillkopplad styrdator.

Motorernas elektronik matas med en separat 24 V likspänning för att motordata skall bibehållas i intakt form trots spänningsbortfall i 230 V-matningen som följd av nödstopp. Denna 24 V matar även givare och kontaktormanövrering via PIO kortets högnivåsida.

Styrdatorn matas från samma säkring som PSU'n för 24 V, och matar i sin tur kameran via USB, samt lågnivåsidan av PIO kortet med 5 V.

4.4 Mjukvarudesign

Mjukvarudesignen delas upp i visionsystem, hårdvarugränssnitt, och användargränssnitt. Samtlig mjukvara skrivs i språket C, med hjälp av utvecklingsmiljön Microsoft Visual Studio 2008 Professional Edition.

4.4.1 Visionsystem

Visionsystemet består av en USB-ansluten kamera och egenutvecklad programvara på styrdatorn för att tolka videoströmmen från kameran.

Programvaran är utvecklad med hjälp av biblioteket OpenCV, som tillhandahåller optimerade algoritmer för bildbehandling. Då bildbehandling är så pass krävande, kör denna i en separat tråd i systemets huvudprogram. För att visa för besökare att bildbehandling utförs, presenteras videoströmmen med ett extra lager av grak som visar objektspårningen. Detta genom att inkommande data kopieras till en presentationskopia, utöver den som används för behandling.

Figur 4.6: Övergripande programupplägg.

Bollmottagaren och bollen har en känd färg och reexionsförmåga, varför dessa intervall kan maskas ut ur de rådata som läses in från kameran. På detta vis försvinner mycket störmoment från objektdetekteringen, då denna nner större sammanhängande områden med likartad färg.

Därefter konverteras bilden till en svartvit representation, genom tröskelvärdeskonvertering. Tröskelvärden sätts både för en lägre och för en högre gräns, för att endast lämna ett visst intervall.

Detta kan dock ge en del synligt brus, dvs. enstaka bildpunkter som är aktiva med bara inaktiva områden runt omkring. Dessa elimineras genom att ett eroderande lter läggs på. Då bollen är relativt stor, påverkar detta inte bollens igenkänning i större utsträckning.

Efter detta nns bara ett fåtal sammanhängande områden kvar, varför detektering av den största av dessa inom det område som bollmottagaren nns på, ger positionen på bollen. Denna position meddelas till koden för hårdvarugränssnittet, som i sin tur sköter motorstyrningen.

4.4.2 Hårdvarugränssnitt

Hårdvarugränssnittet är kopplingen mellan data i programmet och de fysiska portar till vilka hårdvaran är ansluten. För mässdemonstratorn är detta en parallellport för sensorer och styrning av kontaktorer samt två serieportar för styrning av motorerna. Tangentbord, mus och monitor räknas till användargränssnittet, även om de kan användas för att styra hårdvaran. Kameran hör till visionsystemet.

Styrdatorn kommunicerar med motorerna via MACTALK-protokollet. Tillverkaren erbjuder ett programme-ringsgränssnitt för att underlätta programmeringen mot motorerna, dock fungerar inte detta mot C-kod direkt, utan kräver C++. Dessutom var dokumentation och exempel knapphändiga, varför beslutet togs att utveckla ett eget gränssnitt mot MACTALK-protokollet helt implementerat i C. Detta gränssnitt stödjer skrivning till, och läsning från register i motorn, samt veriering av skrivning.

Motorerna spänningsmatas via en kontaktor som kontrolleras av styrdatorn via PIO-kortet och datorns parallellport. Denna styrning är som en extra säkerhetsåtgärd utformad så att ett eventuellt kabelbrott bryter spänningen till motorerna. Parallellporten styr även den lampa som visuellt meddelar operatören om systemet är tillkopplat, eller behöver bekräftas för att kopplas till. Två ingångar används för att indikera status på kontakto-rerna, samt åtta ingångar för ändlägesgivare. De tio ingångarna läses av genom parallellportens dataledningar samt två statusledningar. Utgångarna styrs via kontrolledningarna.

Då det inte nns någon intelligens på PIO-kortet, måste all data skickas och läsas på bitnivå, dvs. ut-an ut-användut-ande av något dataöverförningsprotokoll. Detta kut-an eventuellt ställa till det på nyare system, som alltmer frångår direkt programmering, utan kräver att allt mer kommunikation skall gå genom fördenierade enhetsdrivrutiner.

4.4.3 Säkerhetsaspekter

Då motorerna är både snabba och kraftfulla, måste de hanteras säkert. Ett ertal åtgärder vidtas för att minimera risken för skada på person eller egendom.

ˆ Vid avslut av programmet stoppas motorerna, både via kommandon till dem, samt genom att bryta spänningen till dem.

ˆ Inställning och kalibrering måste utföras innan programmet kan startas.

ˆ Vid kalibrering måste operatören aktivt observera ändlägesinställningen genom att hålla en kontroll ak-tiverad. Detta för att förhindra att motorerna går för långt, om sensorerna av någon anledning ej skulle fungera.

4.4.4 Användargränssnitt

Huvudprogrammet skrivs som en Win32 applikation, med ett visuellt gränssnitt. Det har fem huvudsakliga vyer: ˆ Huvudfönster

ˆ Inställningar för kommunikation ˆ Kalibrering

ˆ Exekvering, med justering av övriga inställningar ˆ Vision

Figur 4.8: Huvudfönster.

Huvudfönstret ger tillgång till alla de andra vyerna. Stängs detta så termineras programmet. Det ger även grundläggande statusinformation för systemets delar.

I inställningsfönstret görs inställningar för kommunikation med motorerna och PIO-kortet, samt kamerain-ställningar. Inställningar måste ha gjorts och kontrollerats innan kalibrering är tillgängligt.

Kalibrering måste köras innan exekveringen kan startas. I kalibreringen kontrolleras att alla givare är an-slutna som de bör, samt att alla kontakter och signaler fungerar som de skall. Dessutom läses positionsdata för motorerna in, och de föryttas till sina ändlägen för att ställa in ändlägespositionerna. Under denna process måste operatören observera förloppet. Detta säkerställs genom att en kontroll i fönstret måste hållas aktiverad under den tid föryttningen sker. Detta är en säkerhetsåtgärd då en defekt givare kan få motorerna att slita av drivremmen, eller på annat sätt skada systemet, och med viss risk även ge personskada. Kameran ställs även in under detta steg, så att dess koordinatsystem stämmer överrens med det mekaniska systemets.

Då exekveringsfönstret öppnas startar systemet upp för körning. Från detta fönster nns möjlighet att ändra hur systemet skall bete sig, samt om det skall styras manuellt från styrdatorn eller automatiskt via kameran. I viss mån kan även visionsystemet påverkas från detta fönster, t.ex. vilken data som skall presenteras med bilden. Visionsfönstret visar kamerans bild med spårningsdata inskriven.

4.5 Systemtestspecikation

4.5.1 Genomförande

Generella testförutsättningar

Vid utförande av följande kapitels tester skall den testutrustning som nämns till varje testfall användas och den ordning som ställts upp följas. Vid direkta test på kretskort skall testpersonen jordas innan själva testet får påbörjas. Testprocedurerna har anpassats för att kunna innefatta krav av samma eller liknande art.

Testutrustning ˆ Måttband 6 m

ˆ Testprogrammet Program för systemtest

ˆ Diverse ljusförhållanden (glödlampa, ljusrör, naturligt ljus, et.c.) ˆ Extern automatisk snabbsäkring

4.5.2 Systemtester

Testfall 1 - Nödfunktionalitet

Detta test avser testa om uppställda krav på säkerhet uppfylls. För merparten av kontrollerna används avsett testprogram (Program för systemtest) som sätter maskinen i kontrollerad och långsam rörelse.

Teststeg:

ˆ 1. Kontrollera att extern nödstopp (minst 5 m kabel) nns och är kopplad till styrskåpet (Krav 6). ˆ 2. Kontrollera att motorerna stannar vid aktivering av nödstopp; både extern och skåpmonterad (Krav

6).

ˆ 3. Kontrollera att inga oavsedda rörelser sker vid avaktivering av nödstopp (endast motors on via panel såväl som dator skall kunna sätta maskinen i rörelse igen) (Krav 7).

ˆ 4. Kontrollera att motorerna stannar vid aktivering av vardera säkerhetsbrytare.

ˆ 5. Kontrollera att inga oavsedda rörelser sker vid avaktivering av säkerhetsbrytare (endast motors on via panel såväl som dator skall kunna sätta maskinen i rörelse igen).

ˆ 6. Kontrollera att motorerna stannar vid avbrott på kabel för båda nödstopp och alla säkerhetsbrytare. ˆ 7. Kontrollera att inga oavsedda rörelser sker vid återinkoppling av kabel (endast motors on via panel

såväl som dator skall kunna sätta maskinen i rörelse igen). Testfall 2 - Fysisk konstruktion och dimensioner

Detta test skall avser att fastställa att konstruktionen uppfyller givna krav på transporterbarhet och hantering vid i- och ur-drifttagande.

Teststeg:

ˆ 1. Kontrollera att maskinens yttermått uppfyller krav om maximalt yttermått om 200 x 90 x 200 cm (l x b x h) (Krav 12).

ˆ 2. Kontrollera att maskinen uppfyller kravet att en person ska kunna ta maskinen i eller ur drift på 5 minuter (Krav 8). Detta innebär att maskinen ska vara helt färdig för transport före och efter testet. Testfall 3 - Funktionalitet vid automatisk körning

Detta test skall säkerställa att maskinen uppfyller ställda krav gällande huvudfunktionalitet. Testet utförs i sin helhet m.h.a. testprogrammet Program för systemtest.

Teststeg:

ˆ 1. Kontrollera att maskinen kan röra sig mellan två extrempunkter inom 1 sekund (Krav 3).

ˆ 2. Kontrollera att maskinen kan spåra och fånga bollar, kastade med underhandskast, på ett avstånd av 3 till 6 meter (Krav 1).

ˆ 3. Kontrollera att maskinen fungerar vid olika ljusförhållanden, framför allt glödlampa, ljusrör och natur-ligt ljus (Krav 2).

Testfall 4 - Visionsystem

Detta test skall säkerställa att krav gällande visionsystemet är uppfyllt. Teststeg:

ˆ 1. Kontrollera i testprogrammet (Program för systemtest) att kameran levererar minst 30 bilder/sekund (Krav 4 och 5).