Computerbaseret offsidedetektering i fodbold - En undersøgelse af realtidskrav og definering af algoritmer

Transkript

1 Speciale Teknisk Informationsteknologi / Distribuerede Realtidssystemer Computerbaseret offsidedetektering i fodbold - En undersøgelse af realtidskrav og definering af algoritmer af Gert Vestergaard Larsen Søren Thestrup Hansen 13. december 2004 Gert V. Larsen Søren T. Hansen Finn O. Hansen Studerende Studerende Vejleder

2 Resume Dette speciale undersøger, hvorvidt det er muligt, med et computerbaseret system, at kunne detektere offside i fodbold indenfor 1 sekund. For at kunne udvikle et system til dette formål, er det nødvendigt med et positioneringssystem, som i realtid kan levere præcise informationer om positionerne for bolden og spillerne under en fodboldkamp. Vi har derfor lavet en analyse af, hvor præcist et positioneringssystem skal være for at kunne detektere offside og en efterfølgende undersøgelse af, om der findes eksisterende positioneringssystemer, der tilbyder den fornødne præcision. Denne undersøgelse har vist, at det tyske positioneringssystem Cairos kan levere den præcision, som vores analyse påpeger er nødvendig. Vi har i dette speciale indledningsvis studeret reglen omkring offside i fodbold, og på baggrund af dette udviklet en algoritme til offsidedetektering. Denne algoritme har vi implementeret i en prototype, DommerStøtteSystem (DSS), der kan detektere offside på baggrund af positioneringsdata. Som input til DSS har vi udviklet en prototype til simulering af Cairos positioneringssystem. Denne består af en ScenarioGenerator (SG) og en ScenarioSender (SS) til opsætning og afspilning af fodboldscenarier. For at kunne teste DSS har vi endvidere udviklet en teststub, Visualizer (VIS), til visualisering af boldens og spillernes bevægelser, samt indikation af offside. Specialet viser, at det er muligt at udvikle et computerbaseret system, som inden for 1 sekund kan detektere en offsidesituation, og viderebringe en information herom til en linjedommer. Side 1

3 Abstract Title: Computerized offside detection in soccer An analysis of real time requirements and the defining of algorithms This thesis investigates whether or not it is possible by using a computerized system to detect offside in soccer within 1 second. To be able to develop a system for this purpose a positioning system is needed, which can deliver accurate information about the ball and the players in real time during a soccer match. Because of this we have made an analysis to find out the needed precision for a positioning system to be able to detect offside. Furthermore we have investigated if a positioning system exists, that is able to deliver the needed accuracy. This investigation has shown, that the German positioning system Cairos has the accuracy, that our analysis has concluded is necessary. We have in this thesis initially been studying the rule of offside in soccer and in light of this developed an algorithm for detecting offside. This algorithm has been implemented in a prototype, DommerStøtteSystem (DSS), which can detect offside by analyzing incoming positioning data. As input for the DSS, we have developed a prototype that can simulate the Cairos positioning system. This consists of a ScenarioGenerator (SG) and a ScenarioSender (SS) to generate and play soccer scenarios. In order to test the DSS, we have developed a test program, Visualizer (VIS), to visualize the movement of the ball and players and also to indicate an offside. This thesis shows that it is possible to develop a computerized system, which is able to detect an offside within one second and transmit this information to the assistant referee. Side 2

4 Indholdsfortegnelse 1. Indledning Problemformulering Metode og værktøjer Relateret arbejde Læsevejledning Forudsætninger Introduktion til offside Offside historie Offside nu Passiv vs. Aktiv offside Undersøgelse af eksisterende positioneringssystemer Beskrivelse af videobaserede systemer til positionsbestemmelse Brug af et enkelt videokamera Brug af flere videokameraer Nøjagtighed Beskrivelse af radiosenderbaserede systemer positionsbestemmelse GPS LPM HorseTrack Cairos Delkonklusion Algoritme til offsidedetektering Definitioner Positioneringsdata Afleveringsøjeblikket Hvem afleverer? Fri af forsvarsspilleren Indflydelse på spillet Algoritmer Sortering Offsidedetektering Valg af metode Anerkendelser Realtidskrav Samlet tidsforbrug Samplingsfrekvens Spillerbevægelse Boldens bevægelse Afleveringsøjeblikket Synkronisering Valg af samplingsfrekvens Udvikling af prototyper Systemoversigt...42 Side 3

5 6.2. Systemovervejelser Programmeringssprog Kommunikationsprotokoller Hardware ScenarioGenerator (SG) ScenarioSender (SS) Visualizer (VIS) DommerStøtteSystem (DSS) Design og implementering Persistering Trådprioriteter Kommunikation med interessenter Test og Verifikation Pakker pr. sekund Fremgangsmåde Resultat Evaluering/Verificering Afleveringsdetektion Fremgangsmåde Resultat Evaluering/Verificering ScenarioSender Test af DSS med forskellige scenarier Onside På linje Én spiller offside To spillere offside Test af scenario hvor en spiller er onside i afleveringsøjeblikket Test af scenario hvor spillere er på linje i afleveringsøjeblikket Test af scenario hvor én spiller er offside i afleveringsøjeblikket Test af scenario hvor to spillere er offside i afleveringsøjeblikket Testkonklusion Fremtidigt arbejde Konklusion Litteraturliste Appendiks Ordliste Overhead Detaljeret sekvensdiagram for DSS Mulig fejlkendelse Testsystem Mails INMOVE Cairos...87 Side 4

6 1. Indledning Fodboldverdenen er i dag en milliardindustri [ UEFA Champions League, 2004], [Grant, 2004], hvor kampe ofte afgøres med et enkelt mål. Dette enkelte mål kan i sidste ende afgøre, om et givent fodboldhold vinder mesterskabet, rykker ned i en lavere division eller går videre i en turnering, hvilket kan have store økonomiske konsekvenser for det enkelte hold. Under fodboldkampe bliver der i dag ofte lavet fejlkendelser i offsidesituationer, hvor fejlkendelsen direkte er skyld i, at der bliver scoret et mål, eller netop ikke bliver scoret. Grunden til at der laves fejlkendelser er, at beslutningerne tages af menneskelige dommere og linjedommere, og at det er svært, pga. øjets begrænsninger, at afgøre disse situationer, når både bold og spillere er i bevægelse [ Offside rule, 2000], [ Scientist say, 1998]. Figur 1 viser en klassisk situation, der ofte fører til en fejlkendelse, idet angriberen, som bolden afleveres til, få øjeblikke efter billedet er taget ser ud til at være offside. Figur 1: Situation der ofte fører til fejlkendelse. (Kilde: Der er blevet eksperimenteret med muligheden for, at dommeren kunne anvende videoreplays, som det f.eks. er kendt fra amerikansk fodbold, hvis han var i tvivl om en situation. Denne metode kræver dog, at spillet stoppes i op til flere minutter, mens dommeren ser et replay af situationen. Da det internationale fodboldforbund FIFA ikke ønsker disse lange afbrydelser i spillet, er det derfor nødvendigt med et system, der fungerer i realtid, hvis dommeren skal have støtte af teknologiske hjælpemidler. Teknologien bag et sådant system vil med stor sandsynlighed kunne anvendes i andre sportsgrene, hvor man kan drage fordel af computerens præcision til, at afgøre vanskelige situationer med. Vi vil i dette speciale forsøge at komme med en løsning på offsideproblematikken, ved at undersøge om det er muligt at udvikle et system, som kan hjælpe linjedommeren med at afgøre om en spiller er offside eller onside i afleveringsøjeblikket. Da en offsidekendelse i sidste ende altid afhænger af en menneskelig vurdering, er det ikke vores intention at lave et system, der skal erstatte dommeren eller linjedommeren. Systemet skal kun bruges som en støtte til linjedommeren og dermed lette hans job, samt nedsætte antallet af fejlkendelser. Udover at have stor betydning for den enkelte klub, vil en reducering af Side 5

7 antallet af fejlkendelser også øge fair play elementet i fodbold, som FIFA lægger stor vægt på. For at kunne drage nytte af et sådant system under en fodboldkamp er det nødvendigt, at det arbejder i realtid. Dermed menes, at en situation skal kunne opdages og rapporteres i samme øjeblik som den sker 1. I specialet antager vi, at den fornødne hardware og software til at bestemme positionerne på bolden og spillerne i realtid allerede eksisterer. Positionsbestemmelse er et stort område som i sig selv kan være emne for et helt speciale, og da vores fokus ligger et andet sted vil vi ikke gå i dybden med teknologien bag dette. Kort beskrevet lyder offsidereglen i fodbold som følger: En spiller er i offside-position, hvis han er nærmere modspillernes mållinje end både bolden og næstsidste modspiller i det øjeblik bolden afleveres til ham Denne regel, samt alle de øvrige fodboldregler er beskrevet i [Fodboldloven, 2004] Problemformulering Vores speciale kan beskrives vha. følgende hovedspørgsmål: Er det muligt at udvikle et computerbaseret offsidesystem, der kan detektere offside indenfor 1 sek.? Derudover rejser der sig følgende underspørgsmål: - Er det muligt at beskrive offsidereglen så præcist, at man kan udvikle en algoritme, der kan dømme offside? - Hvilke realtidskrav stilles der til hastigheden af hhv. positioneringssystemet og beregningsprogrammet for at dette er muligt? Er det muligt med eksisterende positioneringssystemer? 1 Vi har i dette speciale sat en tidsgrænse på 1 sekund. Dvs. at der max må gå et sekund fra situationen opstår til linjedommeren får besked fra systemet. Side 6

8 1.2. Metode og værktøjer For at løse de ovenstående spørgsmål vil vi designe og implementere en prototype, der muliggør detektering af offside ud fra de positioner på bold og spillere, der modtages fra et simuleret positioneringssystem. Andre former for input af data kunne være positioneringsdata man selv genererede, eller positioneringsdata, der var gemt på et persistent medie. Prototypen vil indeholde forskellige algoritmer, der beskriver offsidereglen, og ud fra de modtagne positioneringsdata beregner, om en evt. offsidesituation er til stede. Hvis en offsidesituation detekteres, skal dette kommunikeres ud til evt. interessenter, som f.eks. dommeren og linjedommerne. Denne prototype kaldes for DommerStøtteSystem (DSS). For at kunne lave et DSS kræves det, at man har et pålideligt og nøjagtigt positioneringssystem til at monitorere fodboldens og spillernes position på banen. I dette speciale antages det, at et sådan system findes, og at det har de nødvendige specifikationer. Dvs. vores undersøgelse baserer sig ikke på at beskrive teknologien bag positioneringen af bolden eller den enkelte spillers placering på banen. Undersøgelsen vil tage udgangspunkt i eksisterende positioneringssystemer som f.eks. [Cairos], [LPM] eller [Trakus], og specifikationerne derfra bruges som udgangspunkt for de positioneringsdata vi selv genererer. For at undersøge korrektheden af offsidealgoritmerne vil vi designe og implementere en prototype, der simulerer et positioneringssystem. I prototypen vil det være muligt at opsætte scenarier til input i vores DSS, der i givet fald skal kunne detektere en evt. offside. Denne prototype kaldes for ScenarioGenerator (SG). SG prototypen har som sagt til opgave at producere bold- og spillerkoordinater. Dette gøres ved at vi manuelt indtaster et scenario, via en grafisk brugergrænseflade. For at kunne afspille de generede data i realtid vil vi udvikle en prototype kaldet ScenarioSender (SS). Denne prototype skal sørge for at sende positioneringsdata kontinuerligt til DSS med en fast frekvens. Til at visualisere de positioneringsdata vi modtager fra SS, vil vi udvikle en teststub til at vise boldens og spillernes position. Denne teststub virker også som teststub for DSS, idet den kan modtage og vise evt. offsidekendelser. Denne teststub kaldes for Visualizer (VIS). Det samlede system kan anskues som på Figur 2. Side 7

9 ScenarioGenerator (SG) Live feed ScenarioSender (SS) Scenario fil Gemt kampdata Data Data Data DommerStøtteSystem (DSS) Kendelse Kendelse Visualizer (VIS) Linjedommer / dommer Figur 2: Overordnet systemoversigt. Udviklingen af prototyperne vil foregå i C# for SG og VIS vedkommende, da C# udmærker sig ved at være nemt at udvikle grafiske applikationer i. DSS og SS vil pga. de større performancekrav bliver udviklet i C++, da man i C++ har større mulighed for at opnå en bedre performance end med C#. Ydermere vil DSS og SS køre på realtidsoperativsystemet On Time RTOS-32 [On Time] for at opnå bedre styring med ressourcerne på computeren, end det er tilfældet med f.eks. Windows XP. Side 8

10 1.3. Relateret arbejde Der findes pt. forskellige forskningsprojekter, der forsøger at detektere offside ud fra videobilleder af en fodboldkamp. F.eks. [Redmond, 2004] og [Maruzsi, 2003]. Ingen af disse er dog færdige, og mange ser ud til aldrig at blive det. Et andet, mere seriøst bud, på et offsidedetekteringssystem er [Cairos], der i starten af deres udviklingsfase ville implementere offsidedetektering i deres positioneringssystem. Da Cairos bygger på radiotransmission i stedet for videobilleder, er samplingsfrekvensen og dermed opløsningen på koordinaterne større. Cairos har dog meddelt os [ , 18/8-2004], at de pt. har skrinlagt offsidedetektering i deres system, idet de ikke mener det er muligt pga. offsidereglens vage formulering. Der findes også andre former for offsidedetekteringssystemer end dem der baserer sig på koordinater af bold og spillere (enten via sensorer eller billeder). F.eks. har Javier Garrigues patenteret et system [Garrigues, 2001], der kræver at dommeren aktiverer en knap hver gang bolden afleveres og at linjedommeren holder en knap på sit flag inde, hvis en spiller står offside. Hvis begge knapper er aktiveret på samme tid, konkluderes det at spilleren er offside. DCM Sistemes [ har implementeret en prototype af dette system, som har været testet under en kamp. Dette system har den ulempe, at det kræver at dommeren konstant skal være opmærksom på, hvornår bolden afleveres og huske at aktivere knappen samtidig med, at han skal følge med i spillet. Udover disse forsøg med offsidedetektering, arbejdes der også med, at overvåge andre dele af fodboldsspillet. F.eks. prøver man i [GoalRef] på at overvåge målet og afgøre om bolden er inde eller ej. Nøjagtigheden skal her være meget høj (mindre end 1 cm.), for at man kan anvende systemet i international fodbold. Ved Hummel arbejdes der med at udvikle intelligent tøj (kaldet I-Wear) [I-Wear], der kan give oplysninger om spillernes fysiske tilstand, og derudover også angive deres position. Et sådant system ville kunne bruges som input til vores DSS, hvis nøjagtighed og samplingsfrekvens imødekommer realtidskravene Læsevejledning Opgaven er opbygget på følgende måde: Kapitel 2 - Introduktion til offside Her gennemgås og forklares offsidereglen. Heri både begreberne aktiv og passiv offside. Kapitel 3 - Undersøgelse af eksisterende positioneringssystemer Her gives der et overblik over eksisterende positioneringssystemer og deres fordele og ulemper. Vi evaluerer dem for at afgøre hvilket system, der ville egne sig bedst som positioneringssystem til vores formål. Side 9

11 Kapitel 4 - Algoritme til offsidedetektering Her definerer vi først en række begreber i vores speciale, der bruges til at afgøre en offsidesituation. Derudover analyseres nogle offside- og onsidescenarier fra fodbold, for at komme frem til de algoritmer, der skal kunne detektere offside. Kapitel 5 - Realtidskrav Her undersøges realtidskravene til de enkelte dele i det samlede system, for at vi kan detektere en offsidesituation indenfor den tidsramme vi har sat. Kapitel 6 - Udvikling af prototyper Her præsenteres designet af prototyperne og de punkter der har betydning for performance belyses. Kapitel 7 - Test og Verifikation I dette kapitel testes DSS med input fra SS. Ligeledes testes centrale dele af DSS individuelt. Resultatet analyseres og evalueres og korrektheden af kendelserne undersøges. Kapitel 8 - Fremtidigt arbejde Her kommer vi med bud på, hvad der evt. mangler i vores system, og hvordan det kan implementeres. Derudover ser vi også på forbedringer til den eksisterende kode og design. Kapitel 9 - Konklusion Her konkluderes på de resultater vi er kommet frem til Forudsætninger Det forudsættes ikke, at læseren har kendskab til fodbold eller offsidereglen i særdeleshed. Det vil dog helt klart være en fordel, hvis dette er tilfældet. I så fald kan afsnit 2 springes over. Det forudsættes derimod, at læseren har kendskab til almen programmering og systemarkitektur indenfor programmering. Side 10

12 2. Introduktion til offside For at kunne forstå baggrunden for specialet er det nødvendigt at have en god indsigt i offsidereglen, som er den vi vil detektere vha. et computersystem. Reglen nedstammer fra rugby, og har til hensigt at undgå, at en angriber står ved modstanderens mål og fisker, dvs. venter på at bolden bliver spillet over forsvaret og ned til ham så han er alene med målmanden (eller målområdet i rugby) Offside historie De første eksempler på offsidereglen stammer tilbage fra , hvor forskellige fodboldklubber i England lavede deres egne regler for spillet. Da de forskellige klubber havde deres eget regelsæt gav det problemer når klubberne skulle mødes, og derfor dannede man i 1863 The Football Association (FA), og her enedes man om et fælles sæt regler for fodbolden og dermed også offside. I 1867 ændrede man i offsidereglen, da man adopterede offsidereglen fra Cambridge [Castiglione, 2002]. På dette tidspunkt sagde reglen, at angriberen ikke må være foran de bagerste 3 modspillere, idet bolden afleveres til ham. I 1925 ændredes dette til de 2 bagerste modspillere, og dermed til den regel vi kender i dag. Der blev dog foretaget en lille rettelse i 1990, hvor det blev tilladt for angriberne, at være på linje med den næstsidste modspiller, hvor det før var blevet regnet som værende en offsideposition Offside nu Offsidereglen, som den eksisterer i dag, kan beskrives på følgende måde [Fodboldloven, 11, 2004]: En spiller er i offside-position, hvis han er nærmere 2 modspillernes mållinje end både bolden og næstsidste modspiller i det øjeblik bolden afleveres. Det er en strafbar offside, hvis spilleren opnår en fordel af sin position, generer en modspiller eller har indvirkning på spillet. Det er dommerens skøn at afgøre om dette er tilfældet. Spilleren er ikke offside, hvis han er på egen banehalvdel i afleveringsøjeblikket, eller boldens modtages direkte fra målspark, indkast eller hjørnespark. 2 Definitionen af nærmere er, at angriberen skal være fri af den næstsidste modspiller med en overvejende del af kroppen [GRAF]. Det er så op til den enkelte linjedommer at bedømme hvornår det er tilfældet. Side 11

13 For at illustrere offsidereglen kan de to figurer, Figur 3 og Figur 4 gives som eksempel på to simple tilfælde af henholdsvis onside og offside. Det er her vigtigt at bemærke, at det er angriberens position i afleveringsøjeblikket, der er afgørende og ikke hans position, idet han modtager bolden. Figurerne illustrerer også det faktum, at målmanden skal tælles med som forsvarsspiller, og i langt de fleste tilfælde er han den ene af de to sidste forsvarsspillere. Den gule linje på figurerne markerer den næstsidste forsvarsspiller. Figur 3: Onsidesituation. Figur 4: Offsidesituation Passiv vs. Aktiv offside Selvom en spiller står i en offside position, er det ikke nødvendigvis en strafbar offsideposition. Som nævnt i reglerne [Fodboldloven, 11, 2004] er det kun en strafbar offside i det tilfælde, hvor spilleren enten opnår en fordel af sin position, generer en modspiller eller har indvirkning på spillet. Hvis spilleren står offside i det øjeblik, hvor der afleveres til ham, er der ingen tvivl om, at han opnår en fordel af sin position, og dermed er i en strafbar offsideposition. Det bliver straks sværere at afgøre, såfremt spilleren står i offsideposition, men ikke er ham der bliver afleveret til. I det tilfælde er det op til linjedommeren at afgøre om spilleren har indvirkning på spillet, eller om han f.eks. generer en modspiller. Hvis linjedommeren skønner at dette ikke er tilfældet, er spilleren passiv offside, og spillet fortsætter derfor uden at der dømmes offside. Havde spilleren derimod f.eks. blokeret målmandens udsyn, mens der blev skudt på mål, havde han været aktiv offside, og linje- Side 12

14 dommeren vil så dømme ham offside. Man bruger normalt ikke udtrykket aktiv offside da det blot refereres til som offside. Figur 5 og Figur 6 viser to eksempler på henholdsvis passiv og aktiv offside. Det er ikke muligt at give en entydig forklaring på, hvornår en spiller har indvirkning på spillet eller ej, og dermed er enten aktiv eller passiv offside, da det er et dommerskøn, og derfor altid vil være afhængigt af den enkelte linjedommer. Figur 5: Passiv offside. Figur 6: Aktiv offside. Da det ikke umiddelbart er muligt ud fra koordinaterne på spillerne, at kunne afgøre om en spiller har indflydelse på spillet, vil vi kun koncentrere os om at detektere, om en spiller står i offsideposition eller ej. Om det er en strafbar offside, vil vi ikke give noget bud på, men lade være op til linjedommeren at afgøre. Side 13

15 3. Undersøgelse af eksisterende positioneringssystemer I dette afsnit beskrives, hvilke typer positioneringssystemer der til dato findes og om disse systemer har en stor nok præcision til, at kunne bruges som input til vores DSSprototype. Der findes i dag to forskellige teknologier til at kunne positionsbestemme bolden og spillerne på en fodboldbane. Den ene teknologi benytter sig af live videooptagelser af fodboldbanen fra en eller flere vinkler, og den anden teknologi af radiosendere, som er påmonteret bolden og spillerne. Den store forskel på disse to teknologier er at den videobaserede teknologi er passiv i den forstand, at bolden og spillerne ikke skal have påhæftet noget elektronisk udstyr for, at systemet kan detektere dem og bestemme deres position. Det eneste der kræves er, at de to hold på banen har forskellige farver spillertrøjer på. Den radiobaserede teknologi derimod, er en aktiv teknologi, idet bolden og alle spillerne har påmonteret en eller flere radiosendere, som udsender et unikt radiosignal Beskrivelse af videobaserede systemer til positionsbestemmelse Der er forsket meget i at udvikle positioneringssystemer til brug i sportsgrene, som vha. videooptagelser kan beregne en spillers eller bolds position. Disse systemer udmærker sig ved, jfr. ovenstående, at være passive systemer. Dette betyder, at der ikke skal påmonteres noget udstyr på spillerne, som evt. kunne være forstyrrende for deres bevægelsesfrihed. Ligeledes skal der heller ikke ændres på bolden Brug af et enkelt videokamera En simpel prototype på et videobaseret system til lokalisering af bolden og spillerne, med hovedvægt på offsidedetektering, er udviklet af [Yichie & Schley, 2003]. Deres system består af et enkelt videokamera, som er stationært placeret på sidelinien (Figur 7). De konkluderer, at der med et enkelt kamera opstår mange situationer i spillet, hvor spillerne set fra kameraets synspunkt dækker for hinanden eller bolden. Dette gør det til tidspunkter umuligt at se, hvem der har bolden, og dermed også hvornår bolden bliver afleveret. Som en mulig forbedring af systemet foreslår de brug af flere kameraer for at minimere de blinde vinkler. Side 14

16 Figur 7: Lokalisering af bold og spillere ved brug af et kamera. (Kilde: [Yichie et al., 2003]) Brug af flere videokameraer Firmaet INMOVE [INMOVE] har udviklet et system, der anvender 8 stationære placerede kameraer, som tilsammen dækker hele fodboldbanens areal (Figur 8). INMOVE-systemet er et kommercielt produkt, som er udviklet til at kunne sende de data, som det beregner under en kamp videre til mobile enheder (Figur 9). Dette gør at fodboldinteresserede, som ikke befinder sig på det stadion, hvor kampen spilles, kan følge med på deres PDA 3 eller mobiltelefon. Inden kampstart kalibreres systemet ved at hvert kamera tager et billede, som gemmes som referencebillede. Hvert kamera er placeret således at der i dets synsfelt er synlige kridtstreger fra banen. Disse streger indgår i kalibreringen af kameraerne. Når kampen er i gang bestemmes boldens og de enkelte spilleres position ved at fratrække kalibreringsbilledet fra det aktuelle billede. Dette bevirker, at man får et billede, som kun består af bolden og de evt. spillere, som i det givne øjeblik er i det enkelte kameras synsfelt. Dette filtrede billede køres så igennem en billedgenkendelsesalgoritme, som beregner objekternes position på banen. Denne teknologi har dog flere ulemper, da opløsningen på videobillederne er forholdsvis lille, og opdateringshastigheden er begrænset til 25 billeder i sekundet for PAL 4 og 30 billeder i sekundet for NTSC 5 med standard videokameraer. Følgende angiver en liste over ulemper ved brug af videoteknologien, som blandt andet også [Yichie et al., 2003] og [INMOVE] kommer ind på: 3 PDA (Personal Digital Assistant): Computer i lommeformat. 4 Phase Alternation by Line (PAL) er den europæiske videostandard som består af 25 billeder/sek. 5 National Television System Committee (NTSC) er den amerikanske videostandard, som består af 30 billeder/sek. Side 15

17 1. Der kan opstå situationer, hvor det ikke er muligt at se bolden, da den bliver gemt imellem flere spillere. Da offside dømmes ud fra afleveringstidspunktet af bolden, er dette et stort minus. 2. Spillernes skygger kan påvirke billedgenkendelsesalgoritmen, så den beregner en forkert position. 3. Dårligt vejr med nedsat sigtbarhed kan også påvirke systemet, da de optagne billeder vil kunne blive sløret. 4. Med standard videokameraer vil en bold som bevæger sig med maksimal hastighed 6 bevæge sig 1,66 m fra billede til billede ved PAL og 1,39 m ved NTSC. Ligeledes vil en spiller som bevæger sig med maksimal hastighed, bevæge sig 0,44 m fra billede til billede ved PAL og 0,37 m ved NTSC. Figur 8: 8 kameraer sikrer at hele banens areal bliver overvåget. (Kilde: 6 Baggrund for beregningerne af boldens og spillernes maksimale hastighed er beskrevet i afsnit og Side 16

18 Figur 9: Live animation på PDA af data fra INMOVE. (Kilde: Nøjagtighed Orwell skriver [ , 22/ ] at det nuværende INMOVE-system har en fejlmargen på +/- 30 cm ved spillerpositionering. Derudover har selve kalibreringen af videokameraerne en fejlmargen på hele +/- 1 m. Dette vil dog i nærmeste fremtid blive reduceret til en forventet fejlmargen på +/- 10 cm, idet man skifter fra at bruge kridtstregerne på banen til kalibrering (midterlinje, målfelt, sidelinjer etc.), og til at kalibrere ved hjælp af målestokke, hvilket giver flere fikspunkter på banen. Endvidere skriver Orwell at INMOVE på nuværende tidspunkt ikke er egnet til offsidedetektering, da INMOVE kun er i stand til at detektere ca. 75 % af de afleveringer som forekommer i løbet af en kamp. I [Xu, Orwell & Jones, 2004] fastlægges det også, at målet med INMOVE ikke er, at kunne positionerer den enkelte spiller, men derimod at kunne lokalisere samtlige spillere på banen og kunne skelne imellem, hvilket hold de hører til Beskrivelse af radiosenderbaserede systemer positionsbestemmelse I de seneste år er der sket en stor udvikling indenfor radiobaserede identifikationssystemer (RFID 7 ). Dette har medført, at det er blevet muligt at fremstille meget små radiosendere, som kan bruges til at påmontere f.eks. en vare i et supermarked, i stedet for den lidt gammeldags stregkode. Denne teknologi er også blevet indført i sportsverdenen til positionering i diverse sportsgrene. Der er pt. tre virksomheder som er førende indenfor udviklingen af radiobaserede systemer, der anvendes i sportsindustrien [ABATEC], [Orad], [Cairos]. 7 Radio Frequency Identification (RFID): For nærmere forklaring se Side 17

19 GPS Den første radiobaserede teknologi man tænker på i forbindelse med positionsbestemmelse er nok Global Positioning System (GPS). GPS er dog ikke velegnet til positionsbestemmelse i fodbold. Dette skyldes for det første at præcisionen, hvormed det bedste GPS-udstyr kan bestemme et objekts position er på +/- 40 cm. Den væsentlige grund til at det ikke er velegnet er dog, at man med GPS skal have Line-of-sight. Dvs. at man skal have frit udsyn imellem GPS-modtagerne og GPS-satellitterne. Dette vil være et problem på de fleste fodboldstadions, da disse som regel har høje tribuner som skygger. Endvidere er flere nyere stadions overdækkede, hvilket helt udelukker GPS LPM Det østrigske firma ABATEC [ABATEC] har udviklet systemet Local Position Measurement (LPM), som benytter sig af radarteknologi til 3D-positionering. LPM-Systemet (Figur 11) består af følgende enheder til opbygning af en celle 8 : 1. En transceiver, hvis synsfelt dækker hele det område, hvor objekterne som skal monitoreres er indenfor strategisk placerede receivere 9 omkring det monitorerede område. 3. Et antal transpondere 10 (Figur 10) på alle objekterne som skal monitoreres. 4. En computer til behandling af data. 5. Optiske kabler til forbindelse af tranceiveren, receiverne og computeren i en HUB for at opnå den hurtigst mulige udveksling af data. Systemet fungerer ved, at transceiveren udsender et ping-signal. Når transponderne på de objekter som monitoreres modtager dette signal, svarer de ved at udsende et replysignal, som indeholder et unikt ID for den enkelte transponder (objekt). Disse signaler modtages så igen af receiverne og transceiveren og sendes til computeren til behandling. På baggrund af den tidsforskel, hvormed de enkelte receivere modtager et svarsignal, kan en position bestemmes. ABATEC oplyser [ABATEC], at man med deres system kan beregne et objekts position op til 1000 gange i sekundet, med en nøjagtighed på +/- 5 cm. Det er muligt at monitorere op til 30 objekter indenfor en enkelt celle. Endvidere er det muligt at forbinde flere celler, så man f.eks. kan dække en racerbane i motorsport. Transponderen (Figur 10) har på nuværende tidspunkt en vægt på 61 gram (inkl. batteri) og en størrelse på 97 x 57 x 17 mm, men der forskes stadigvæk i at minimere dette. Figur 10: LPM-transponder (Kilde: ) 8 En celle betegner hele systemet med transceiveren, receiverne og transponderne. Den maksimale afstand imellem transceiveren og transponderne er 500 m. 9 Se Appendiks 11.1 for nærmere forklaring. 10 Se Appendiks 11.1 for nærmere forklaring. Side 18

20 LPM-Systemet er for nyligt blevet testet [ABATEC] med stor succes i en hollandsk isarena, hvor professionelle speedskatere 11 under træning blev monitoreret med LPM. De monitorerede data, som bestod af skaternes position, hastighed, acceleration og puls, blev vist live på en storskærm, samt efterfølgende i replay for de involverede skatere. Testen viste, at LPM kunne blive et behjælpeligt værktøj til optimering af den enkelte skaters træning, da han ville kunne optræne sin ideallinje på isen ved at studere de monitorerede data. Figur 11: Systemoversigt hvor LPM tænkes anvendt i amerikansk football. (Kilde: ) HorseTrack Et andet system som benytter sig af en tilsvarende teknologi er HorseTrack [Orad]. Dette system benyttes til monitorering af heste på en væddeløbsbane i Hong Kong. Selve systemet minder meget om LPM, men kan dog kun bestemme objekters positioner 30 gange i sekundet, hvilket ifølge [Orad] giver deres system en nøjagtighed på +/- 20 cm. Til gengæld er transponderne dog mindre, da de i dette system vejer 18 gram og fylder 65 x 37 x 4 mm. Figur 12: Systemoversigt af HorseTrack. (Kilde: Figur 13: HorseTrack Transponder. (Kilde: 11 Speedskating er en sportsgren, hvor det gælder om hurtigst muligt, at skøjte et antal runder på en cirkulær isbane. Se for nærmere forklaring. Side 19

21 Cairos Det tyske firma Cairos A/G [Cairos] er i et samarbejde med Fraunhofer-Instituttet [IIS] ved at udvikle systemet Cairos til 3D-positionering af bold og spillere i fodbold. Cairossystemet vil når det er færdigudviklet blive et godt redskab til fodboldtrænere, da de i realtid vil kunne følge med i spillernes løbemønstre på banen. F.eks. vil det være muligt at se, om en spiller i løbet af kampen bliver træt, idet hans tophastighed bliver mindre (eller fordi han står meget stille på banen). Endvidere giver det også træneren mulighed for efterfølgende, at analysere kampen til mindste detalje og udvikle enkelte spilleres løbemønstre. Cairos-systemet giver også mulighed for, ligesom INMOVE, at sende live-data ud til mobile enheder under kampen. Disse kunne være data som f.eks. boldbesiddelse, skud på mål og hårdeste skud. Et andet og noget mere kommercielt marked som Cairossystemet åbner op for, er væddemål baseret på kampen. Ifølge Cairos A/G vil dette give de klubber, som installerer Cairos-systemet en ny indtjeningskilde med et stort potentiale. Cairos-systemet minder både om LPM og HorseTrack, dog med den forskel, at der i dette system benyttes envejskommunikation ved brug af transmittere 12 på de objekter som skal monitoreres, i stedet for transpondere. Dette gør, at tag et 13 som fodboldspillerne skal bære er så lille, at det kan være i en benskinne (Figur 14). Ved at benytte sig af envejskommunikation opnår man også den fordel, at levetiden for tag et bliver længere, da strømforbruget bliver væsentligt nedsat. Dette skyldes, at transmitterne ikke har et modtagerkredsløb, som er et strømkrævende kredsløb. Figur 14: Cairos transmitter-tag (Kilde: promo.wmv fra Cairos-systemet består af et antal receivere, som er placeret tæt ved sidelinjerne på banen, og et antal receivere som er placeret højst muligt oppe på stadionet. Disse receivere er forbundet til en computer via optiske fiberkabler. Receiverne modtager signalerne fra de transmittere, som er påmonteret bolden og spillerne. På baggrund af den tidsforskel, hvormed de enkelte receivere modtager den enkelte transmitters signal, kan en 3Dposition bestemmes. 12 Se Appendiks 11.1 for nærmere forklaring. 13 Tag er et begreb som dækker over de forskellige typer sendere man påmonterer det objekt man vil monitorere. Side 20

22 Cairos-systemet kan ifølge [Holzer & Braun, 2004] beregne positionen for et objekt op til 2000 gange i sekundet. Dette giver en nøjagtighed på +/- 3 cm for et objekt, som bevæger sig med en hastighed omkring 150 km/t (maksimal hastighed for bold). Braun skriver [ , 14/ ] at nøjagtigheden på +/- 3 cm af positioneringen af bolden og spillerne, i teorien muliggør brugen af Cairos-systemet til offsidedetektering. I praksis er det dog i det nuværende system ikke muligt, da Cairos A/G har valgt at placere transmitterne i spillernes benskinner. Da en offsidesituation bedømmes ud fra overkroppens placering på en spiller, ville det kræve, at overkroppen også blev påmonteret en transmitter for at kunne detektere offside. Cairos A/G er i øjeblikket ved at teste en prototype af systemet, som er installeret på Nürnberger Frankenstadion i Nürnberg - Tyskland. Det er Cairos mål, at deres system vil blive installeret på samtlige stadions i Tyskland i forbindelse med VM i fodbold 2006 [Cairos]. Figur 15: Systemoversigt af Cairos. (Kilde: Delkonklusion På baggrund af vores undersøgelse af eksisterende positioneringssystemer, har vi konkluderet, at videobaserede systemer ikke er velegnede til vores formål med at kunne detektere offside. Dette beror på, at videobaserede systemer er for upræcise, idet de for det første ikke kan beregne mere end 30 positioner i sekundet, og for det andet beregner disse positioner med en stor fejlmargen (+/- 30 cm ). Vores undersøgelse har derimod vist at radiobaserede systemer er yderst velegnede, da denne teknologi giver en stor præcision på de beregnede positioner (+/- 3 cm med Cairos-systemet). Med denne teknologi undgår man også problemet som optræder i video- Side 21

23 systemerne, hvor spillere kan dække for bolden og andre spillere, så deres positioner ikke kan beregnes. Den umiddelbare ulempe ved den radiobaserede teknologi, hvor de monitorerede objekter skal bære et tag, har med Cairos system vist sig ikke at være noget problem, idet tag ets størrelse er minimalt. Et problem der dog kan opstå ved brug af radiobaserede systemer er, at et tags batteri kan løbe tør for strøm under en kamp, eller tag et kan risikere at gå i stykker. Cairos A/G siger dog, at deres tags er meget robuste, idet de kan klare en tur i vaskemaskinen, sammen med benskinnerne, uden at tage skade. Deres tags har også strøm nok til, at det kan sende i op til 4 timer, så en fodboldkamp på minutters varighed (inkl. pauser) er ikke noget problem, hvis dets batteri er fuldt opladt inden start. Da Cairos er det system, som har den største præcision i beregning af positioner, har vi valgt at bruge dette systems specifikationer som input til vores offsidesystem. Side 22

24 4. Algoritme til offsidedetektering Som nævnt i introduktionen til offside, så er det op til linjedommeren at afgøre, om en angriber befinder sig foran den næstsidste forsvarsspiller i afleveringsøjeblikket, og om han i givet fald har indflydelse på spillet i afleveringsøjeblikket. Da det er en menneskelig og individuel afgørelse, er dette umuligt at implementere i en ren digitaliseret version af offsidereglen. Derfor er det nødvendigt at definere, hvordan vi vil afgøre, om der er offside ud fra de oplysninger, vi får fra positioneringssystemet Definitioner De ting som vi skal have fastlagt en definition for er følgende: Hvilke data modtages der fra positioneringssystemet? Hvornår er afleveringsøjeblikket? Hvem afleverer bolden? Hvornår er en angriber foran næstsidste forsvarsspiller? Har angriberen 14 indflydelse på spillet? Positioneringsdata For overhovedet at kunne detektere offside vha. et computersystem, er det nødvendigt at have viden om bolden og spillernes position på ethvert givent tidspunkt. Da det at bestemme bolden og spillernes position er et omfattende job i sig selv, har vi valgt at antage, at der eksisterer et positioneringssystem, der er i stand til dette. For at have en ide om, hvilke data det er muligt at få fra et positioneringssystem, har vi undersøgt eksisterende systemer og evalueret disse med henblik på hvilke, der evt. kunne bruges som input til vores system. En detaljeret gennemgang af de eksisterende positioneringssystemer blev gennemgået i afsnit 3. Da de eksisterende systemer enten stadig er på udviklingsstadiet eller er blevet til et kommercielt firma, har det ikke været muligt at skaffe et eksempel på hvilke data, der bliver sendt fra et eksisterende positioneringssystem. Derfor har vi valgt selv at specificere hvilke data vi forventer at modtage fra et positioneringssystem. Vi har på baggrund af analysen af de forskellige eksisterende positioneringssystemer, baseret vores positioneringsdata på specifikationerne for Cairos A/G [Cairos], der er et positioneringssystem udviklet specifikt til fodbold. I deres system er opdateringshastigheden for bolden 2000 gange i sekundet, mens den er 750 gange for spillerne. Koordinaterne på både bold og spillere angives i tre dimensioner,og præcision opgives til værende +/- 3 centimeter. Med udgangspunkt i Cairos positioneringssystem har vi defineret, at det positioneringssystem vi simulerer, har de i Tabel 1 angivede specifikationer. En detaljeret baggrund for valg af opdateringshastighed kan ses i kapitel 5.2 Samplingsfrekvens 14 Angriberen bruges om den eller de spillere, der er i risiko for at stå offside. Side 23

25 Opløsning [cm] Opdateringshastighed [Hz] Dimension Præcision [cm] Bold D (x,y) +/- 3 Spiller D (x,y) +/- 3 Tabel 1: Specifikation for vores antagede positioneringssystem. Det antages at data er pålidelig, dvs. at positionen er korrekt hver gang og at vi derved ikke kan ske at modtage positioner f.eks. 50 meter fra den egentlige position i en enkelt sample. I modsætning til Cairos tre dimensioner, har vi valgt kun at anvende to dimensioner. Årsagen hertil er, at tilføjelse af z-komposanten i SG-prototypen ville gøre den væsentlig mere kompleks og dermed for tidskrævende at programmere. Da vi samtidig ikke anvender z-koordinatet i DSS-prototypen, har vi altså valgt at se bort fra den tredje dimension i vores simulerede positioneringssystem. For at øge nøjagtigheden og også være kompatibel med eksisterende positioneringssystemer, er dette en ting, som vil være påkrævet i en videreudvikling af systemet. Da vi som nævnt ikke har kunnet få et eksempel på positioneringsdata fra et eksisterende system, har vi selv måtte definere det ud fra gæt på, hvordan data bliver præsenteret. Vi har i første omgang skullet vælge imellem, om der bliver sendt data-pakker for hvert enkelt objekt på banen, eller om alle samplinger fra samme øjeblik (med samme timestamp) sendes i en samlet pakke. Hvis alle samplinger sendes videre fra positioneringssystemet enkeltvis, vil dette kreere et massivt overhead pga. den lille datamængde der sendes. Ved at samle alle samplinger i en pakke med samme timestamp mindskes dette overhead, og udnyttelsen af netværket forbedres. Med dette som grundlag, har vi defineret pakkeformatet fra positioneringssystemet til at have et udseende som på Figur 16. Pakken indeholder ét fælles timestamp plus ID og koordinater for 23 objekter. Rækkefølgen af objekterne har ingen betydning. Figur 16: Pakkeformat for positioneringsdata. Vi har defineret størrelsen af de forskellige informationer ud fra følgende antagelser: TimeStamp Ved en samplingsfrekvens på 2000 Hz, som Cairos har i deres system mht. bolden, kommer der er i løbet af en kamp på 90 minutter = samples. Hvis hver sample udstyres med et unikt timestamp, behøves der i princippet kun afsættes 3 bytes (ca. 16 millioner). Vi har dog afsat 4 bytes for at have ekstra timestamps i tilfælde af f.eks. forlænget spilletid eller andre uforudsete hændelser, der kan forlænge en kamp. Side 24

26 ID Antallet af objekter der skal håndteres består af to hold med hver 11 spillere plus udskiftere (op til 11 i venskabskampe) samt et antal bolde byte giver mulighed for op til 256 unikke objekter, hvilket vi regner for rigeligt. X- og Y-koordinat Koordinaterne har vi valgt som beskrivende banens reelle mål i centimeter. Da en bane maksimalt kan være op til 95 m x 120 m. [Fodboldloven 1, 2004] kræver det altså mulighed for koordinatangivelser op til ( cm). Ved at afsætte 2 bytes, har vi op til ca , hvilket giver en fremtidig mulighed for en højere opløsning som f.eks. 0,5 cm. Dette ville i så fald give koordinatangivelser op til (1 enhed = 0,5 cm). Figur 17 viser hvordan vi tolker koordinaterne i forhold til banen 16. X-koordinatet beskriver, hvor objektet befinder sig i længden af banen, mens y-koordinatet beskriver hvor i bredden det befinder sig. En anden mulighed kunne være at koordinatet var et relativt tal, der i så fald krævede en form for omregning afhængig af banens mål, for at muliggøre udregning af position, hastighed og acceleration. Figur 17: Tolkningen af koordinaterne i forhold til banen 15 Der ligger ekstra bolde rundt omkring banen for at kunne sætte spillet hurtig i gang igen. 16 Grunden til at y-koordinatet er positiv nedad, er implementationsspecifik (se afsnit 6.3) Side 25

27 Ud fra definition af pakkeformatet vil en pakke indeholde 119 bytes data for 22 spillere og en bold. Hvis hvert objekt blev sendt enkeltvis, ville den pakke indeholde 9 bytes, da timestampet skal sendes med hvert objekt. Ved at sende alle positioneringsdata i én pakke med et fælles timestamp, spares der 88 bytes ( bytes) alene i udeladelsen af individuelle timestamps. Antager vi at data sendes med UDP vil overhead for pakkerne med 9 bytes data være 85,0 %, mens det for den samlede pakke på 119 byte vil være på 26,1 % 17. Altså et væsentlig mindre overhead for den samlede pakke. En ting der er nødvendig at tage højde for ved koordinaterne, er det faktum, at vi modtager koordinater for et punkt, mens bold og spillere har en vis fysisk udformning i den virkelige verden. Vi har altså brug for at vide, hvilket punkt på kroppen/bolden vi får koordinatet på. For boldens vedkommende antager vi at det koordinat vi modtager, er for boldens centrum. For spillerne antager vi, at det koordinat vi modtager, er koordinatet på spillerens bryst. Ved kun ét koordinat, er det ikke muligt at afgøre, hvilken vej spilleren vender. Dette kan give en unøjagtighed når angriber og forsvarer står meget tæt, set ud fra x-koordinatets synspunkt. Figur 18 viser et eksempel, hvor to spillere står tæt set ud fra x-koordinatet. Vores tolkning vil her fejlagtig antage, at den blå spiller er længst mod højre, da koordinaterne på sensorerne indikerer dette. Som det kan ses på figuren er det reelt den hvide spiller, der er længst til højre i virkelighedens verden. Figur 18: Forkert tolkning af position når spillere står tæt (mht. x-koordinatet). Vi har defineret vores positioneringssystem til kun at levere koordinater på bold og spillere, og ikke andre informationer. I det positioneringssystem Cairos A/G har udviklet, angiver de, at de bl.a. også har information om hastighed og acceleration for bold og spillere. Da vi ikke har nogen viden om nøjagtigheden af disse, har vi valgt selv at udregne hastighed og acceleration på baggrund af de koordinater vi modtager. I og med at Cairos-systemet har disse ekstra informationer ud over selve koordinatet, er det muligt, at de også er i stand til at afgøre, hvornår bolden bliver afleveret og af hvem. I så fald kan det simplificere de udregninger, der er nødvendige i DSS for at afgøre, om der er offside eller ej, idet mange af informationerne er tilgængelige fra positioneringssystemet. Vi kan dog ikke forvente at alle positioneringssystemer stiller disse informationer til rådighed, og hvis de gør, kan der være forskel i den måde de f.eks. definerer afleveringsøjeblikket på. Ved selv at udregne afleveringsøjeblikket og hvem der afleverer bolden, er vi sikre på, at få netop det øjeblik som vores algoritmer er baseret på. 17 Udregningen for dette kan ses i Appendiks Side 26

28 Afleveringsøjeblikket For at kunne afgøre om en spiller er offside eller ej, er det nødvendigt at vide, hvornår bolden bliver afleveret og derfor har vi altså behov for at definere, hvornår afleveringsøjeblikket er. Reglerne giver ikke noget entydigt svar herpå, og derfor har vi valgt at definere afleveringsøjeblikket som det øjeblik, hvor bolden slipper foden. Dvs. det øjeblik hvor der ikke længere er fysisk kontakt mellem bold og støvle. Definitionen er baseret på ordlyden af offsidereglen i Laws of The Game [LOTG 11, 2004]. Her står der, at det er i det øjeblik bolden er rørt eller spillet af en medspiller, at man kan stå i en offside-position. Vi tolker her rørt, som værende hvis bolden rammer en medspiller og ryger videre (en utilsigtet aflevering), mens at spille tolkes som en alm. aflevering hvor spilleren sparker til bolden. Figur 19: Tre øjeblikke i løbet af et spark - det midterste er det vi har defineret som afleveringsøjeblikket, hvor bolden netop har sluppet støvlen. (Kilde: [Sports]) Hvem afleverer? Når man sidder og ser en fodboldkamp enten på stadion eller i fjernsynet, er det normalt ikke noget problem, at se hvem der afleverer bolden. I vores tilfælde har vi dog kun positioneringsdata til at afgøre dette med, og derfor er vi nødt til at beregne os frem til, hvem der har afleveret bolden. Vi har valgt at se på hvilken spiller, der er tættest på bolden i afleveringsøjeblikket, og antager at det er ham der har afleveret bolden. Selve udregningen af hvem, der er tættest på bolden, er en simpel to-dimensional afstandsudregning baseret på de modtagne (X,Y) koordinater. Ovennævnte antagelse kan i visse tilfælde give det forkerte resultat, hvis to spillere står meget tæt på hinanden idet bolden afleveres. Da det modtagne koordinatet på spilleren angiver koordinatet af hans bryst, vil det se ud som om forsvarsspilleren afleverede bolden, hvis en angriber tacklede bolden væk fra ham med en glidende tackling. Dette er pga. at angriberens bryst vil befinde sig længere fra bolden end forsvarerens bryst, og derved vil udregningen fejlagtigt komme til det resultat, at forsvareren er tættest på bolden. Figur 20 viser en illustration af problemet. Side 27

29 Figur 20: Eksempel på fejlagtig detektion af hvem der afleverer bolden. En måde hvorpå dette muligvis kunne forbedres, er ved at sammenligne boldens nuværende retning i forhold til spillernes retning. Man kunne alternativt ændre placeringen sensoren på kroppen, så det er spillernes fødder man får koordinatet på. Disse tilføjelser ville dog også have usikkerheder, f.eks. kan en spiller lave en aflevering med hælen modsat hans egen bevægelsesretning, eller bolden kan blive afleveret med et hovedstød Fri af forsvarsspilleren I offsidereglen står der, at angriberen skal være nærmere baglinjen end den næstsidste forsvarsspiller samt bolden for at være i en offsideposition. Vi har altså behov for at fastsætte, hvornår nærmere helt præcist er. Lovudvalget i Dansk Boldspils Union (DBU) har defineret nærmere som værende Når den overvejende del af kroppen har passeret modspillerens krop / bolden [GRAF, 2004] Da vi ud fra koordinatet ikke kan se spillerens udformning, har vi ikke samme mulighed som en dommer for at afgøre, om en angriber har passeret en forsvarer med en overvejende del af kroppen. Vi definerer derfor en angriber til at være nærmere mållinjen end den næstsidste forsvarsspiller, ved at se på de to spilleres x-koordinater, og afgøre hvilken spiller, der er tættest på mållinjen. Denne definition kunne gøres mere nøjagtig, hvis vi f.eks. også, via en anden sensor, modtog koordinatet for spillerens ryg, da man i så fald kunne danne et billede af hans fysiske udformning, samt indikation om, hvilken vej han vender. Derved vil man kunne undgå den fejl der kan opstå, når to spillere står tæt set ud fra x-koordinatet, som vist på Figur Indflydelse på spillet Vi vælger i første omgang ikke at afgøre om en spiller er passiv eller aktiv offside, da dette efter vores mening kræver et menneskeligt syn på sagen. Vi vælger derfor kun at afgøre, om en spiller står i en offsideposition i afleveringsøjeblikket, og lader det så være op til linjedommeren, at afgøre om det er en strafbar offsideposition. Det ville dog være muligt at komme med et plausibelt gæt, hvis man regnede ud, om der var nogle medspillere i den retning, som bolden blev afleveret. Dette vil dog ikke kunne bruges som et endegyldigt bevis på om vedkommende, som afleveringen har retning imod, deltager aktiv i spillet. Han kunne f.eks. være ved at binde sine snørebånd, og dermed udenfor indflydelse på spillet. Side 28

30 4.2. Algoritmer For at kunne definere algoritme, der kan detektere offside ud fra koordinaterne på bold og spillere, er det nødvendigt at kigge lidt nærmere på selve offsidereglen. Umiddelbart er den første indskydelse at fremgangsmåden for at detektere en offside, må være den samme som i virkeligheden, hvor man observerer hvornår bolden bliver afleveret, og derefter kigger på, om der står en spiller i offsideposition i det øjeblik. Det kan dog vise sig at dette ikke er den mest effektive metode, når problemet flyttes over på en computer, hvor vi skal være opmærksomme på, at processeringstiden skal nedbringes bringes under ét sekund, samt at vi kun har koordinaterne at gå ud fra Sortering For at kunne afgøre om en spiller er offside eller ej, er det nødvendigt at have en eller anden form for billede af spillernes nuværende indbyrdes position. Dette kan f.eks. gøres ved at sortere spillerne ud fra deres x-koordinat, da vi dermed har spillernes placering i forhold til mållinjen. Spilleren længst til venstre på banen vil da have plads 0, mens spilleren længst til højre på banen vil have plads n-1 for et array med n spillere. Til at udføre denne sortering har vi valgt at kigge på 2 forskellige sorteringsalgoritmer med hver sin styrke. Bubble Sort Bubble Sort er en sekventiel algoritme, der sorterer et array ved at sammenligne en værdi med den næste og bytte om på dem, hvis den første er den største. På denne måde bobler de største værdier op igennem arrayet, mens de mindste synker til bunden. Den har i værste fald en kompleksitet på O(n²) [Lamont, 2004]for et array af størrelsen n. Til gengæld vil den i tilfælde hvor data er præsorteret blot kræve et enkelt gennemløb af arrayet for at konstatere at data er sorteret, hvilket svarer til n sammenligninger. Quick Sort I modsætning til Bubble Sort er Quick Sort en rekursiv algoritme. Den fungerer ud fra Divide and Conquer princippet og har en gennemsnitlig kompleksitet på O(n log n) [Lamont, 2004] for et array af størrelsen n. Dette er dog også tilfældet selvom data er præsorteret, hvormed man derfor ikke opnår markant bedre performance i det tilfælde. Alt afhængig af hvordan man vælger at dele sit array, kan man faktisk risikere en kompleksitet på O(n2) for allerede sorteret data. Det betyder at den ikke egner sig til sorteringer på præsorterede data, men derimod er bedst til usorteret data. For at finde den bedst egnede sorteringsalgoritme, har vi testet de to algoritmer på henholdsvis et array af størrelsen 22 (alle spillere i et array) og to arrays af størrelsen 11 (hvert hold i sit array). Alle arrays blev fyldt med usorteret data og derefter sorteret to gange. Første sortering giver et billede af performance ved usorteret data og anden sortering giver et billede af performance ved præsorteret data. Testen blev udført på en Dell OptiPlex GX1 og gav følgende resultater (gennemsnit af 10 gennemløb usorteret data er genereret tilfældigt): Side 29

31 1 array af 22 spillere [usorteret] 1 array af 22 spillere [præsorteret] 2 arrays af 11 spillere [usorteret] 2 arrays af 11 spillere [præsorteret] Bubble Sort 981 μs 36 μs 468 μs 41 μs Quick Sort 363 μs 313 μs 271 μs 212 μs Tabel 2: Test af sorteringsalgoritmer. Testen af de to sorteringsalgoritmer viser, at for usorterede arrays er Quick Sort som ventet hurtigt, mens det for de sorterede arrays vedkommende klart er Bubble Sort, der er den hurtigste. Bubble Sort er faktisk op til 10 gange hurtigere i testen med et sorteret array på 22 spillere. Ud fra ovennævnte test kan det konkluderes, at efter den første sortering vil det være hurtigst at benytte sig af Bubble Sort hvis man skulle sortere data hver gang, der er modtaget nye data. Da data ankommer hvert millisekund, er det kun i et fåtal af det samlede antal samples, at spillere får en ny indbyrdes placering. Dette er pga. af den korte distance en spiller kan nå at tilbagelægge på 1 millisekund. Spillerne vil kontinuerligt få nye koordinater, men dette afstedkommer som oftest ikke ændringer i den indbyrdes placering af spillerne Offsidedetektering Idet vi anvender en computer til at beregne, om der er opstået en offside situation har vi flere muligheder til at detektere en offside end en linjedommer har i virkeligheden. Vi kan, i modsætning til linjedommeren, gemme et nøjagtigt billede af spillernes placering i afleveringsøjeblikket og bruge det, idet en angriber modtager bolden. Umiddelbart er der tre tilgangsvinkler til offsidedetekteringen. To af metoderne afgør om der er offside i det øjeblik bolden afleveres, mens den tredje venter med at afgøre om der er offside til bolden havner hos en spiller. I og med at man venter med at afgøre om der er offside indtil en spiller har modtaget bolden, er det her nødvendigt med et billede af spillernes indbyrdes position i det øjeblik bolden blev afleveret. Vi vil i det efterfølgende sammenligne de tre metoder og finde frem til hvilken metode, der egner sig bedst med hensyn til at detektere offside og samtidig have en høj performance. Først aflevering, så spillerposition Denne metode er den som anvendes af linjedommerne under en fodboldkamp. Metoden baserer sig på at vi monitorerer bolden og holder øje med, hvornår den bliver afleveret. I tilfælde af at beregningen viser at bolden er blevet afleveret, er næste skridt at kigge på spillernes indbyrdes position for at detektere en evt. offside. For at kunne danne sig et billede af dette, er en eller anden form for sortering af spillerne nødvendig. I løbet af en fodboldkamp, kan der gå langt tid (flere tusinde samples) imellem afleveringerne og dermed langt tid imellem, at det er nødvendigt at sammenligne spillernes indbyrdes position. Derfor er det ikke nødvendigt, kontinuerligt at have sorteret spillerne på baggrund af deres position. Hvis ikke spillernes indbyrdes position sorteres hver gang der modtages nye koordinater, kan der dog være op til flere spillere, der har skiftet indbyrdes position næste gang der detekteres en aflevering. Ved at sammenligne disse betragtninger med testen af sorteringsalgoritmerne kan det konkluderes at tidsforbruget i Side 30

32 dette tilfælde øges ved en Bubble Sort, mens tidsforbruget ved en Quick Sort, er stort set uændret. Hvis vi derimod sørger for at kontinuerlig have et opdateret billede af spillernes position, vil det helt klart være en fordel at benytte sig af Bubble Sort pga. dennes lave tidsforbrug ved præsorterede data. Først spillerposition, så aflevering Denne metode minder meget om den første metode, men i stedet for at monitorer bolden, vælger vi at overvåge spillernes position, for at detektere om en eller flere spillere fra et af holdene skulle befinde sig i en offsideposition. Hvis en eller flere spillere befinder sig i en offsideposition, monitoreres bolden for at holde øje med om den bliver afleveret. Hvis en aflevering så detekteres er der opstået en offsidesituation, men vel og mærke kun hvis spilleren, der afleverer bolden, er fra samme hold som den eller de spillere, der står offside. Da en spiller sagtens kan befinde sig i en offsideposition i mange sekunder, bliver dette til mange samples, hvor både bold og spillere skal monitoreres, i modsætning til den første metode, hvor det kun krævede én udregning af spillernes position hvis der var detekteret en aflevering. Denne metode kræver at vi hele tiden har et billede af spillernes indbyrdes position og ud fra betragtningerne omkring kontinuerlig sortering vil det helt klart være hurtigst at benytte sig af Bubble Sort, da spillerne ikke skifter indbyrdes position særlig tit (set i forhold til det samlede antal samples). Disse to første metoder afgiver deres offsidekendelse i afleveringsøjeblikket, hvilket både kan være en fordel og en ulempe. Det er en fordel at kendelsen afgives med det samme idet at linjedommeren hurtigt bliver opmærksom på at der er en mulig offsidesituation. Ligeledes går der mindst mulig tid fra afleveringsøjeblik til indikationen omkring en offside, hvilket øger muligheden for at holde os under 1 sekund i responstid. Ulempen opstår hvis bolden f.eks. aldrig når frem til angriberen fordi en forsvarer kommer imellem og stjæler bolden. Angriberen vil i så fald ikke have indflydelse på spillet og derfor ikke være strafbar offside. Da algoritmen afgiver sin indikation på offside i afleveringsøjeblikket, vil den i dette tilfælde altid indikere en offsidesituation, selvom der reelt set er en passiv offside. Bolden modtages, var spilleren offside i afleveringsøjeblikket? Den sidste metode monitorerer hvornår en spiller modtager bolden og kigger så tilbage på spillernes indbyrdes position i det øjeblik bolden blev afleveret. I det tilfælde hvor spilleren der modtager bolden var i offsideposition i afleveringsøjeblikket, er der offside, hvis spilleren der sidst havde bolden var en fra samme hold. I modsætning til de to foregående metoder, afgøres det her ikke i afleveringsøjeblikket om der er offside, men først når spilleren modtager bolden. Metoden kræver, at man mens bolden er hos en spiller, monitorerer bolden for at se, om den bliver afleveret. Detekteres en aflevering gemmes positioneringsdata for samtlige spillere og der holdes så øje med bolden for at detektere hvornår den er modtaget af en spiller. Når bolden modtages sammenlignes spillernes indbyrdes position for at detektere en evt. offsidesituation. Da der ligesom ved den første metode kan gå lang tid mellem afleveringerne kan vi antage at spillernes indbyrdes positioner som oftest har ændret sig fra gang til gang, hvorved anvendelse af Quick Sort vil være mest effektiv. Side 31

33 Fordelen ved denne metode er at der kan skelnes imellem aktiv og passiv offside idet andre spillere end ham der modtager bolden ikke bedømmes som værende offside af algoritmen. Her er det så op til linjedommeren at vurdere, om andre spillere end boldmodtageren har indflydelse på spillet og dermed er offside. En anden fordel er, at der ikke dømmes offside hvis en aflevering aldrig når frem til den tiltænkte spiller selv om han skulle befinde sig i en offsideposition. Et problem er at det kan være vanskelligt at afgøre hvornår bolden er hos en spiller, og det derved er ham, der sidst har haft den. Hvis man definerede kontrol over bolden som en imaginær cirkel, som omkranser spilleren, kan man fejlagtigt komme til at tro at en spiller har haft bolden, hvis den passerer tæt nok forbi ham. I vores system, der kun anvender to dimensioner, er det specielt et problem hvis bolden passerer hen over en spiller (f.eks. en lang høj aflevering), da bolden her vil se ud, som om den har samme position som spilleren. Da vi har som mål, at afgøre om en spiller er offside eller ej, inden for et sekund efter at bolden er afleveret, kan denne algoritme i nogle tilfælde overskride deadline, hvis bolden har lang vej til modtageren Valg af metode Pga. vanskelligheden ved at afgøre om en spiller har modtaget bolden eller ej, har vi i første omgang valgt at se bort fra denne metode. Ligeledes risikerer vi at overskride vores eget krav til offsidedetektering inden for 1 sekund efter bolden er afleveret. I valget mellem de to første metoder har vi kigget på hvilken metode vi mener, har den mindste køretid, da begge metoder har samme evne til at detektere en offsidesituation. Selvom det umiddelbart virker til at det mest optimale (pga. Bubble Sort s lave køretid på præsorterede data) ville være at overvåge spillernes indbyrdes position for at holde øje med evt. offsidepositioner, har vi valgt at monitorere bolden for at detektere en evt. aflevering. Hvis monitoreringen af bolden viser at den er blevet afleveret, kræver det kun en sortering af spillerne for at kunne afgøre, om der er offside eller ej. Hvis man derimod holder øje med spillerne og detekterer, at en eller flere befinder sig i en offsideposition, kræver det at man samtidig monitorerer bolden i hele det tidsrum hvor spillerne er i offsideposition. Dette kan strække sig over flere tusinde samples, hvis blot spilleren står offside i nogle sekunder. Den bedste metode til at detektere offside med, ville i bedste fald være, at have en kombination af forskellige algoritmer. Derved ville de kunne supplere hinanden og hver især opdage situationer, som en anden metode ikke havde opdaget eller fejlbedømt. Udfordringen ved sådan en konstellation, er at afgøre, hvornår de hver især har præcedens. Side 32

34 4.3. Anerkendelser Vi har i vores algoritmer, og i prototypen som helhed, en række ting som vi ikke tager højde for eller helt ignorerer. Vi monitorerer f.eks. ikke dommerens position, da han som sådan er at regne for en knold på banen, set ud fra reglerne [Fodboldloven 9, 2004]. Ved en videreudvikling af algoritmen skal han tages med, da man stadig kan blive offside, hvis bolden rammer dommeren under en aflevering. Alt afhængig af algoritmen, kan det være nødvendigt, at detektere at det er dommeren, som bolden har ramt, og at det derfor ingen betydning har. Yderligere ting som vi ikke har medtaget i vores algoritmer i prototypen, er stop i spillet som indkast, målspark, frispark osv. Det er ikke muligt at være offside på hverken indkast eller målspark, men dette skelner vores algoritme ikke imellem. Mulighederne for at løse dette problem, er enten at detektere spilstop i algoritmen, hvilket kan være meget vanskeligt, eller at lade algoritmen indikere en offside og så lade det være op til linjedommeren at ignorere indikationen. Side 33

35 5. Realtidskrav Da vi har som mål at kunne detektere en offsidesituation, indenfor 1 sekund efter afleveringsøjeblikket, er vi nødt til at opstille visse realtidskrav til de enkelte delsystemer i det samlede system. Der stilles samtidig også krav til præcisionen, for at kunne detektere en offsidesituation med tilfredsstillende nøjagtighed Samlet tidsforbrug Tiden fra en spiller afleverer bolden og til linjedommeren får besked om en evt. offside, kan deles op i følgende sekvenser: Figur 21: Samlet tidsforbrug fra spiller/bold-sensor til linjedommer. Figur 21 viser, hvilke ting der går tid med fra positionsenheden på spilleren/bolden sender sin information til positioneringssystemet, til dommeren eller linjedommeren modtager besked om en evt. offside. Hvis man antager, at banen har maksimumsstørrelsen (90 x 120 m), er den maksimale afstand et signal skal bevæge sig 150 m (spiller/bold og modtager står i hvert sit hjørne af banen). Derudover vil en modtager med stor sandsynlighed befinde sig et stykke uden for banen, så den reelle worst case afstand er nærmere 200 m. Udbredelsestiden i luften fra positioneringssensoren til positioneringssystemet bliver derved i worst case: s 200 m s = t v t = t = = 66,67 µ s v 8 m 3 10 s 8 m Hastigheden er sat til lysets hastighed i vakuum ( 3 10 ) s Side 34

36 Udover selve udbredelsestiden, går der også tid med selve dataoverførslen, og denne tid er afhængig af, hvilken teknologi der anvendes til transmissionen. En sensor sender dog ikke data med sin position, men derimod blot sit ID. Ud fra hvornår denne data modtages af de forskellige modtagere rundt omkring, udregnes positionen så af positioneringssystemet (se afsnit 3.2.4). Det kan derfor antages, at den mængde data der sendes fra sensoren til positioneringssystemet er minimal, og at transmissionstiden er i samme størrelsesorden som udbredelsestiden. Sammenlignet med den tid på 1 sekund vi har som maksimum i vores system, er den samlede transmissionstid så lille, er det er rimeligt at se bort fra den. Transmissionstiden fra positioneringssystemet til DSS afhænger af, hvilket medie der anvendes. Mediet kan i princippet være alt fra et nulmodemkabel til lyslederkabel, men pga. den mængde data der sendes, kræves der en forholdsvis høj bitrate (ved 119 bytes og 1000 samples i sekundet sendes der 952 kbit/s). Hvis man antager, at der bruges en alm. 100 Mbit Ethernet forbindelse, vil overførslen af en pakke med 119 bytes data fra positioneringssystemet til DSS, tage ca. 13 μs. Hvis positioneringssystemet 18 og DSS er opstillet fysisk tæt på hinanden, kan udbredelsestiden i kablerne antages at være under 1 mikrosekund. Ligesom ved transmissionstiden af data fra sensoren til positioneringssystemet, er den samlede transmissionstid af data fra positioneringssystemet til DSS altså så lille i forhold til 1 sekund, at det er rimeligt at se bort fra den. Fra DSS og ud til dommeren/linjedommeren foregår transmissionen også trådløst, og udbredelsestiden kan derfor sammenlignes med udbredelsestiden fra sensor til positioneringssystemet. Da de eneste data, der sendes til linjedommeren er en indikation i tilfælde af offside, er denne, ligesom ved sensoren, så lille at transmissionstiden er i mikrosekundområdet. Transmissionstiden fra DSS til linjedommeren er altså også så lille, at man kan se bort fra den. Processeringstiden i positioneringssystemet bliver i vores situation et estimat, da vi ikke har viden omkring den interne virkemåde af dette delsystem. Hvis vi antager, at det er i stand til at fungere ved en samplingsfrekvens på 1000 Hz 19, er det rimeligt at antage, at den maksimale processeringstid er 1 millisekund for at systemet kan følge med. Altså også en tid betydeligt mindre end 1 sekund. Ud fra ovenstående antagelser er det altså rimeligt at antage, at vi har 1 sekund til udregningen i DSS. 18 Her tænkes på den enhed der står for videresendelsen af data til DSS. 19 [Cairos] har f.eks. en samplingsfrekvens på 2000 Hz i boldens tilfælde og 750 Hz for spillerne Side 35

37 5.2. Samplingsfrekvens Samplingsfrekvensen i positioneringssystemet angiver hvor mangle samples i sekundet DSS har at regne på, og dermed har det indirekte indflydelse på, hvor hurtigt det kan komme med en kendelse. Samplingsfrekvensen har også betydning for, hvor præcist vi kan detektere ting som hastighed og acceleration. Ligeledes har det betydning for, hvor nøjagtig kendelser kan blive, da en lav samplingsfrekvens betyder at bold og spiller kan nå at bevæge sig meget mellem to samples. Dette kan resultere i, at en spiller der i afleveringsøjeblikket reelt set er onside, bliver set som offside, fordi han når at bevæge sig foran den næstsidste forsvarsspiller mellem to samples. For at finde frem til realtidskravene til positioneringssystemet, har vi valgt at regne baglæns på to centrale ting, hvorpå samplingshastigheden har betydning. Hvor meget bevæger spilleren sig mellem hver sample? Hvor meget bevæger bolden sig mellem hver sample? Spillerbevægelse Som sagt kan det have stor betydning for en kendelse, hvor langt en spiller bevæger sig mellem to samples. Vi har her regnet på den tilbagelagte distance mellem to samples ved forskellige samplingshastigheder og forskellige spillerhastigheder. Samplingshastighed [Hz] Tilbagelagt distance [cm] (ved 40 km/t) 5 222,22 111, ,04 18, ,44 2, ,22 1, ,11 0, ,89 0, ,56 0,28 Tabel 3: Tilbagelagt distance ved forskellige samplingshastigheder for spillerne. Tilbagelagt distance [cm] (ved 20 km/t) Vi har valgt, at se på den tilbagelagte hastighed ved to forskellige hastigheder. De 40 km/t er den højeste hastighed, hvormed en spiller antages at kunne løbe, og svarer til at spilleren tilbagelægger 100 m. på 9 sekunder. Da dette er absolut worst case 20, vælger vi også at se på den tilbagelagte distance ved en hastighed på 20 km/t. I en fodboldkamp har angriberen som oftest netop startet sit løb, idet han passerer næstsidste forsvarsspiller, og vil derfor endnu ikke have opnået sin maksimumhastighed. Som det kan ses i Tabel 3 kan spilleren nå at flytte sig forholdsvis meget ved lave samplingshastigheder ( < 30). Det betyder, at der kan opstå problemer med at detektere, om en spiller er onside eller offside i afleveringsøjeblikket. TV-billeder optages normalt 20 Verdensrekorden for 100 m. i år 2004 er på 9,78 s, sat af Tim Montgomery i Paris I 100 m. løb opnår løberne max. hastigheder på ca. 42,5 km/t (11,8 m/s) her skal man dog tage højde for at de løber på et hårdt underlag. Side 36

38 med 25 eller 30 samples i sekundet, og de vil derfor være ensbetydende med stor usikkerhed, hvis de skulle bruges til detektering af offside. Ved højere samplingshastigheder ( > 500) er den tilbagelagte distance nede på et niveau, hvor den kan sammenlignes med usikkerhederne på positioneringssystemet (Cairos som pt. er det mest præcise, har +/- 3 centimeters nøjagtighed). Samtidig er det svært at afgøre, om en angriber går fra at være onside til at være offside, idet han bevæger sig 2 centimeter. Udover at angriberen bevæger sig, skal vi også tage højde for, at forsvarsspilleren kan bevæge sig fremad i samme øjeblik. Det betyder, at den relative hastighedsforskel mellem de to spillere, er summen af deres individuelle fart. Dermed kan worst case scenariet resultere i en dobbelt så lang tilbagelagt afstand de to spillere imellem. Ud fra disse betragtninger har vi konkluderet, at samplingshastigheden for spillerne skal være minimum 500 Hz, for at få et tilstrækkeligt nøjagtigt billede af spillernes position,. Jo højere samplingsfrekvens, des mere nøjagtig bliver vores beregning, da spillerne ikke flytter sig så meget mellem to samples Boldens bevægelse Ligesom med spillerne har samplingshastigheden af boldens position stor betydning for muligheden for at detektere en offsidesituation. Ved bolden er der to problemer: Ved for lav samplingshastighed er det svært at detektere accelerationen af bolden, og dermed afleveringsøjeblikket, præcist. Dette gør sig specielt gældende ved høj boldhastighed. Ved en høj samplingshastighed er det muligt, at en langsom bold ikke bevæger sig nok til, at det er synligt i form af en ændring i koordinaterne. Derved skal der bruges utroligt mange samples til at detektere en acceleration, hvilket sætter krav til computerens hardware i form af hukommelse og processorkraft til at udføre beregninger på de mange samples. I følgende tabel er angivet, hvor langt bolden bevæger sig mellem to samples, ved forskellige samplingshastigheder. Samplingshastighed [Hz] Tilbagelagt distance [cm] (ved 150 km/t) Tilbagelagt distance [cm] (ved 5 km/t) 5 833,33 27, ,89 4, ,67 0, ,33 0, ,17 0, ,33 0, ,08 0,07 Tabel 4: Tilbagelagt distance ved forskellige samplingshastigheder for bolden. Side 37

39 Som det kan ses i Tabel 4, er det ikke meget bolden bevæger sig fra sample til sample ved 2000 samples og en boldhastighed på 5 km/t. Hvis vi som antaget har en opløsning 1cm på 1 cm, kræver det altså = 14,29 15samples for at detektere en koordinat 0,07cm ændring, forudsat at bolden kun bevæger sig i et plan. For at detektere en acceleration er det nødvendigt at vide, hvordan den helt præcist foregår. Som det kan ses i [Tol, Slim, Soest, & Dijk. s. 2, 2002], er den gennemsnitlige berøringstid ved et spark til en fodbold 10,7 millisekunder (når bolden ligger stille). Derefter accelereres bolden ikke yderligere, da der ikke længere er noget der påvirker den med en positiv kraft i bevægelsesretningen 21. Derfor kan det udledes, at hele accelerationen foregår i de ca. 11 millisekunder, hvor der er kontakt mellem bold og støvle. Valget af samplingsfrekvens for bolden skal altså sætte os i stand til at udregne en acceleration, så hurtigt som muligt, efter at bolden har sluppet støvlen, og helst netop i det øjeblik hvor det sker. Jo længere tid der går før accelerationen bliver opdaget, efter den i realiteten har fundet sted, des større kan afstanden mellem to spillere i bevægelse blive. Ved lave samplingsfrekvenser har vi ikke mulighed for, at detektere accelerationen præcist nok, og dermed bliver usikkerheden på spillernes position for stor til, at vi kan detektere en evt. offside. Ved samplingsfrekvenser på over 100 Hz sørger vi for, at vi kan opdage en evt. acceleration af bolden indenfor 10 millisekunder efter at den har fundet sted. Det giver et lille tidsrum, hvori spillerne kan bevæge sig, og derved bliver kendelsen præcis nok til at være acceptabel nok. Jo højere samplingsfrekvens, des mere nøjagtigt bliver kortlægningen af boldens bevægelse, men som nævnt tidligere stiller det større krav til hardwaren, idet man skal gemme flere samples for at kunne detektere en lille acceleration Afleveringsøjeblikket Da vi har defineret afleveringsøjeblikket som det øjeblik, hvor der ikke længere er kontakt mellem støvle og bold, har det kun betydning hvor meget spillerne bevæger sig mellem to samples i det tilfælde, hvor bolden bliver samplet hurtigere end spillerne. Det betyder, at hvis der detekteres en acceleration af bolden, så findes der ikke spillerkoordinater for det øjeblik. Hvis bold og spillere samples med samme hastighed, vil der ved detektion af en boldacceleration, kunne kigges på spillerkoordinaterne med samme timestamp, og ud fra disse afgøres, om der eksisterer en evt. offsidesituation. Dermed forsvinder problemet med hvor langt spillerne bevæger sig mellem to samples. Omvendt stiller det et krav til, at det er muligt at detektere boldens acceleration, netop i det øjeblik bolden slipper kontakten med støvlen. Ved at analysere en high speed videooptagelse af et spark til en fodbold [Sports], får vi et indblik I, hvordan bolden reagerer i det øjeblik den bliver afleveret. Ud fra den kan det ses, at bolden begynder at bevæge sig samtidig med, at der er kontakt med støvlen/foden. Boldens koordinater vil altså ændre sig allerede i begyndelsen af skudafviklingen, og det vil være muligt, at detektere afleveringen indenfor ganske få samples. 21 Derimod vil bolden langsom blive bremset pga. friktion af græs eller luft. Side 38

40 25 20 s [cm] ,002 0,004 0,006 0,008 0,01 0,012 0,014 t [s] Figur 22: Stedfunktionen for [Sports]. Figur 22 viser hvordan en fodbold bevæger sig ved et spark. Det ses hvordan bolden kun flytter sig ganske lidt lige, idet støvlen får kontakt med den. Dette skyldes at bolden deformeres (op til 40 % [Eskildsen, 2004]) Efter ca. 2 millisekunder stopper deformationen af bolden, og bolden bliver nu flyttet i samme tempo som støvlen. Efter ca. 6 millisekunder bevæger bolden sig med konstant hastighed, da der ikke længere tilføres energi fra støvlen. Der skal tages højde for, at en anden bold, kan have andre fysiske karakteristika (tryk, deformationsevne, størrelse, vægt), og derfor vil opføre sig en smule anderledes. Fodbolden er dog standardiseret [Fodboldloven 2, 2004], og vil derfor ligge indenfor visse grænseværdier. Det kan derfor antages at andre bolde ikke vil afvige meget fra [Sports] mht. deformeringen ved et spark. Acceleration og hastighed vil selvfølgelig afhænge af sparkets kraft og vinkel på bolden. Ved at differentiere stedfunktionen fås hastighedsfunktionen, der med [Sports] som input, får følgende udseende: v [m/s] ,002 0,004 0,006 0,008 0,01 0,012 0,014 t [s] Figur 23: Hastighedsfunktion for [Sports]. Side 39

41 På Figur 23 ses hvordan hastigheden langsomt øges i starten, hvor den overførte energi primært bruges til at deformere bolden. Efter 2 millisekunder, hvor deformationen opnår sit maksimum, øges hastigheden kraftigt indtil det 6. millisekund, hvor der ikke længere overføres energi til bolden. Derefter bevæger bolden sig med konstant hastighed. En aflevering kan ses som en acceleration af bolden - dvs. en ændring af hastighed over tid. Ved at differentiere hastighedsfunktionen fås følgende funktion for accelerationen: a [m/s²] ,002 0,004 0,006 0,008 0,01 0,012 0,014 t [s] Figur 24: Acceleration for [Sports]. Som det kan ses på Figur 24, er der en kraftig acceleration af bolden pga. hastighedsændringen. Ved at udregne accelerationen kontinuerligt, er det altså muligt, at detektere en aflevering. Det antages her, at en aflevering består af et spark til bolden. I realiteten vil en aflevering også blot kunne bestå af en spiller der retter bolden af. Dette ville evt. kunne detekteres ved, at kigge på ændring af boldens retning. Ved at vælge ens samplingsfrekvens for bold og spillere, opnår vi en klar fordel, idet vi i det øjeblik vi detekterer en aflevering, kan sammenligne koordinaterne på spillerne for at detektere en evt. offsidesituation, da de stammer fra samme samplingstidspunkt. Det er altså ikke nødvendigt at gemme tidligere positioner for, at kunne interpolere sig frem til deres nuværende position i de tilfælde, hvor afleveringsøjeblikket ikke passer med, at der er samplet spillerkoordinater i samme øjeblik Synkronisering For at kunne sammenholde de modtagne samples fra bolden med dem fra spillerne, kræver det at der findes en form for synkronisering således, at bold og spillersamples fra samme øjeblik har samme timestamp. Denne synkronisering er nødvendig, for at vi kan detektere en evt. offsidesituation, ved at se på spillerpositionerne i afleveringsøjeblikket. Vi antager at positioneringssystemet sørger for denne synkronisering. Side 40

42 5.3. Valg af samplingsfrekvens Vi har valgt, at sætte samplingsfrekvensen til 1000 Hz for både bold og spiller, ud fra de beregninger vi har foretaget for boldens og spillernes bevægelse ved forskellige samplingsfrekvenser. Desuden har vi også taget hensyn til berøringstiden ved et spark. Ved 1000 Hz modtager vi koordinatet på bolden hvert millisekund. En sekvens af modtagne data, hvori der sker en acceleration, vil da have følgende udseende: n n+1 n+2 n+3 n+4 n+5 n+6 n+7 n+8 n+9 n+10 n+11 n+12 n+13 n+14 t 0 =0 1ms 2sm 3ms 4ms 5ms 6ms 7ms 8ms 9ms 10ms 11ms 12ms 13ms 14ms Aflevering påbegyndt berøring mellem bold og støvle Afleverings øjeblik En acceleration vil altså spænde over ca. 11 samples, hvilket ikke stiller store krav til hukommelsesplads. Samtidig har vi et godt billede af boldens bevægelse fra sample til sample. Ved en samplingsfrekvens på 1000 Hz, vil en spiller maksimalt bevæge sig 1,11 cm mellem to samples. To spillere der bevæger sig i modsat retning af hinanden vil altså maksimalt kunne ændre deres indbyrdes placering med 2,22 cm. Dette er i samme størrelsesorden som unøjagtigheden af positioneringssystemet, og derfor antager vi, at spillerne ikke bevæger sig mellem to samples. Side 41

43 6. Udvikling af prototyper 6.1. Systemoversigt Vi har i dette speciale udviklet 4 prototyper som tilsammen udgør et testsystem (Figur 25) til detektering af offside. Testsystemet består af følgende: ScenarioGenerator (SG): ScenarioSender (SS): DommerStøtteSystem (DSS): Visualizer (VIS): Bruges til at opsætte fodboldscenarier med. Bruges til at sende positioneringsdata med. Bruges til at detektere offside med. Bruges til at vise positionerne på bolden og spillere, samt vise spillere som er offside. Figur 25 viser en oversigt over det samlede testsystem, samt hvorledes SS, DSS og VIS kommunikerer sammen via et Ethernet og SG og SS via en scenario-fil 22. ScenarioGenerator (SG) ScenarioSender (SS) Scenario-fil UDP ETHERNET UDP TCP TCP UDP DommerStøtteSystem (DSS) Figur 25: Systemoversigt af testsystem. Visualizer (VIS) 6.2. Systemovervejelser Forud udviklingen af vores prototyper, har vi haft en del designmæssige overvejelser. Disse overvejelser har blandt andet gået på, hvor meget tid vi skulle bruge på de enkelte prototyper. Herudover har vi haft en del overvejelser omkring de tidskritiske faktorer, såsom kommunikationen imellem prototyperne. 22 Scenario-filen er i prototypen gemt som en fil på harddisken. Side 42

44 Programmeringssprog Vi har udviklet prototyperne SG og VIS i C#. Dette skyldes, at C# er forholdsvis nemt at udvikle grafiske applikationer med, og vi derfor mente, at ville kunne spare tid på udviklingen. Da prototyperne SS og DSS stiller store tidskrav har vi udviklet dem i C++, da dette programmeringssprog har en god performance Kommunikationsprotokoller SS bruger UDP som transportprotokol til at sende pakker med positioneringsdata med. Da pakkerne kun indeholder 119 bytes data, og vi skal kunne sende data hurtigst muligt, er dette den hurtigste protokol at anvende, da UDP er en connectionless packet-oriented transportprotokol. Idet UDP desværre er en upålidelig envejstransportprotokol giver dette dog den ulempe, at vi kan risikere pakketab. Da vi anvender et dedikeret Ethernet som kommunikationsmedie kan vi antage, at et evt. pakketab vil være minimalt. Skulle vi tabe en pakke, vil følgerne dog ikke være fatale, da der imellem to samples går 2 millisekunder. Pga. den høje samplingsfrekvens har det dog ikke nogen reel betydning for nøjagtigheden, idet objekter på banen ikke bevæger sig væsentligt på 2 millisekunder. DSS bruger en TCP-forbindelse til at sende pakker med offsidebeskeder til VIS. Grunden til at vi her bruger en TCP-forbindelse er, at offsidebeskederne har en meget høj prioritet, og vi derfor skal være sikre på, at beskederne kommer frem. Dette sørger TCPforbindelsen for, da dette er en pålidelig transportprotokol. De positioneringsdata som SS sender ud skal modtages af både DSS og VIS, derfor benytter vi os af multicast, hvor SS, DSS og VIS er medlem af samme multicast group Hardware Vi bruger Ethernet som kommunikationsmedie imellem vores prototyper. For at være sikre på, at der ikke er anden trafik, som påvirker hastigheden, hvormed vi sender og modtager data, har vi valgt at gøre dette Ethernet dedikeret. Oprindeligt var det meningen, at DSS skulle afvikles på en SBC Under udviklingen af DSS viste det sig dog hurtigt, at denne type hardware ikke havde tilstrækkelige ressourcer til at kunne bruges i vores system. Dette kom til syne under en test (afsnit 7.1), hvor vi målte hastigheden, hvormed vi kunne sende UDP-pakker til SBC686 en uden pakketab. Testen viste, at SBC686 en ikke var hurtig nok til at behandle de modtagne pakker, hvilket vi tolkede var pga. for lidt processorkraft og evt. ramhastighed (Pentium 133Mhz CPU). Som løsning på dette udskiftede vi SBC686 en med en standard PC (Pentium II 350Mhz), hvilket gjorde, at vi ikke mere oplevede pakketab. 23 En SBC686 er en Single Board Computer med 133 Mhz processor. Side 43

45 6.3. ScenarioGenerator (SG) Da vi som nævnt i afsnit ikke har været i stand til, at skaffe positioneringsdata fra et virkeligt positioneringssystem [Cairos], [LPM], har vi været nødt til selv at skabe nogle. Til dette formål har vi udviklet en prototype ScenarioGenerator (SG), hvori vi kan opsætte fodboldscenarier med bevægelsesmønstre for bolden og spillerne, og ud fra disse genererer positioneringsdata. I en rigtig fodboldkamp vil en spiller eller bold kunne bevæge sig fra punkt A B med enten konstant hastighed, ved at accelerere eller ved at decelerere. Disse egenskaber har vi indbygget i vores prototype, så vi kan skabe så realistiske positioneringsdata som muligt. Følgende diagram (Figur 26) viser de use cases som SG-prototypen indeholder. ScenarioGenerator IndtastScenario GenerérScenario AfspilScenario Operatør GemScenario HentScenario Harddisk IndtastScenario Figur 26: Use case diagram over SG. En operatør indtaster et fodboldscenario ved at indtaste hastighed, acceleration eller deceleration for bolden og alle 22 spillere, samt positionerne (X,Y), hvor bolden og spillerne skal bevæge sig hen imod. GenerérScenario En operatør aktiverer generate, hvorefter prototypen genererer et scenario. Når scenariet er blevet genereret, kan det afspilles eller gemmes. Side 44

46 AfspilScenario En operatør aktiverer play, som afspiller et genereret scenario. Et scenario kan afspilles i enten normal hastighed eller i slowmotion. GemScenario En operatør aktiverer save, hvorefter der åbnes et vindue, hvor der promptes for hvilket navn filen skal gemmes under, og hvor på harddisken den skal gemmes. HentScenario En operatør aktiverer load, hvorefter et gemt scenario kan loades fra harddisken. Følgende viser et forenklet klassediagram over SG. Klassen ScenarioGenerator er selve hovedprogrammet (mainform), som har til ansvar at kunne generere, afspille, gemme og hente et scenario. Klasserne BallForm og PlayerForm har til ansvar, at kunne opstille scenarier for det enkelte objekt på banen. De 3 klasser benytter sig alle af hjælpeklassen ArrayListHelper, som bruges til at oprette MultiDimensionalArrayList s med, hvori scenariodata gemmes. Figur 27: Klassediagram over SG. Side 45

47 Vi har udviklet SG-prototypen, som en applikation med en grafisk brugerflade. Dette gør det nemt og overskueligt at opsætte fodboldscenarier. Den endelige prototype af SG kom til at se ud som vist i Figur 28. Figur 28: ScenarioGenerator (screenshot). Fodboldbanen En fodboldbane skal ifølge [Fodboldloven 1, 2004] være mellem 90 m og 120 m lang og m bred. På baggrund af dette har vi valgt, at fodboldbanen i vores SGprototype er 100 m lang og 75 m bred. Koordinater Koordinatsystemet for fodboldbanen i vores SG kan ses i Figur 29. Vi har valgt at have nulpunkt i øverste venstre hjørne af fodboldbanen. Dette skyldes, at i C# bestemmes alle grafiske objekters koordinater ud fra netop øverste venstre hjørne af det vindue grafikken er i. Side 46

48 Figur 29: Koordinater for fodboldbanen (koordinaterne er i meter). Opsætning af scenario Med SG er det muligt, at opsætte scenarier med en varighed på op til 30 sekunder, hvilket vi mener, er tid nok til at kunne simulerer et fodboldscenario med flere afleveringer og offsidesituationer. For at opsætte et scenario skal man indtaste bevægelsesmønstre for samtlige objekter. Figur 30 viser et eksempel for indtastning af bevægelsesmønstret for bolden. I dette eksempel er startpositionen for bolden (16;42) Scenario Beskrivelse 0 Bolden bevæger sig med 5 sm til positionen (61;52) Bolden accelererer til sluthastigheden 20 1 sm som den når i positionen (61,1;52) 2 Bolden bevæger sig med 20 sm til positionen (78;47) 3 Bolden decelererer til sluthastigheden 0 sm som den når i positionen (88;42) Bolden accelererer til sluthastigheden 20 4 sm som den når i positionen (88,1;42) 5 Bolden bevæger sig med 20 sm til positionen (100;42) Tabel 5: Scenario for bolden. Side 47

49 Figur 30: Indtastning af bevægelsesmønster for bolden. Når scenarier for bolden og alle spillerne er sat op, genereres det komplette scenario ved at trykke på generate. Det komplete scenario kan herefter afspilles i enten normal hastighed eller i slowmotion. Hvis scenariet er tilfredsstillende, kan det gemmes på harddisken ved at vælge Save Scenario i menuen File. Format af gemte data De genererede positioneringsdata bliver gemt i en fil af typen *.sce på harddisken. Filen består af først alle bolddata, derefter alle data for spiller 1 fra hold 1, derefter spiller 2 fra hold 1 etc. Hver linje i filen indeholder et ID på objektet og dets X- og Y-koordinat. Koordinaterne er angivet i cm. Ball Ball Ball Ball Team1Player Team1Player Team1Player Team1Player Team1Player Team1Player Team1Player Figur 31: Eksempel på indhold af fil med et gemt scenario. Side 48

50 6.4. ScenarioSender (SS) For at kunne simulere Cairos-systemet, skal vi kunne sende pakker med positioneringsdata for alle objekter 1000 gange i sekundet til vores DSS. Dvs. vi skal sende alle objekters aktuelle position hvert millisekund. Dette kræver en meget præcis timing, hvilket C# ikke tilbyder. Derfor har vi udviklet et program i C++, som bliver afviklet på en PC (Pentium II 350 MHz) med realtidsoperativsystemet On Time RTOS-32 [On Time]. Følgende diagram (Figur 32) viser de use cases som SS indeholder. ScenarioSender AfspilScenario <<includes>> IndlæsScenario <<includes>> Harddisk Operatør SendUDPPakker <<includes>> TilføjTimestamp AfspilScenario Figur 32: Use case diagram over SS. En operatør indtaster navnet på det scenario der ønskes afspillet. IndlæsScenario Et valgt scenario indlæses fra harddisken og gemmes i nogle buffere i hukommelsen. TilføjTimestamp Et timestamp tilføjes en pakke, før den sendes af sted. Timestampet er et fortløbende nummer, som starter med 0, og så tæller op for hver pakke. SendUDPPakker En UDP-pakke afsendes med aktuelle positioneringsdata. Før pakken sendes bliver den konverteret til bytes og tilføjet et timestamp. Følgende viser et forenklet klassediagram over SS. Hovedklassen i SS er CScenarioThread (aktivt objekt). Denne klasse har til ansvar, at indlæse et valgt scenario og afsende UDP-pakker med aktuelle positioneringsdata hvert millisekund. Hertil bruger CScenarioThread klasserne CFileIO, CUDP, samt Player og Ball som er structs. Klassen CUDP benytter sig endvidere af CByteCalc og CTimestamp. Side 49

51 Figur 33: Klassediagram over SS. Programmet fungerer ved, at det indlæser en fil med scenariodata, som er genereret vha. SG. Vi har defineret et scenario til maksimalt at kunne vare 30 sekunder, hvilket giver op til positioner for hvert objekt. Med 23 objekter giver dette tilsammen positioner. Filen som indeholder disse data kan blive ret stor (op til 16-17Mb). Da læsningen fra filen og den efterfølgende konvertering af data er en proces, som er meget tidskrævende, har vi valgt at læse alle positioner fra filen ind i hukommelsen. Dette forhindrer, at vi ikke ville være i stand til, at kunne overholde en deadline med afsendelse af data for hvert millisekund. Side 50

52 Figur 34: Sekvensdiagram af 1ms loop i SS. For at kunne afsende pakker med positioneringsdata, præcist hvert millisekund, benytter vi os af en cyclic timer. Vha. funktionen RTKDelayUntil kan vi lave et loop (Figur 34 & Figur 35), som tager nøjagtig 1 millisekund for et gennemløb. Forudsætningen for at dette fungerer, er at man er sikker på, at den kode, som skal eksekveres i loopet tager under 1 millisekund at processere. DWORD cntticks = CLKMicroSecsToTicks(1000); RTKTime NextActivation; NextActivation = RTKGetTime(); RTKDelayUntil(NextActivation); while (true) { NextActivation += cntticks;... processering af data... } RTKDelayUntil(NextActivation); Figur 35: Cyclic timer. Dette er ikke noget problem i vores tilfælde, da vi har målt tiden det tager, at behandle den data vi har i loopet til at være 64 mikrosekunder. Side 51

53 6.5. Visualizer (VIS) For at kunne teste, om vores DSS virker, har vi udviklet en prototype til et testprogram Visualizer (VIS). VIS opgave er, visuelt at kunne gengive objekternes position på fodboldbanen. Endvidere skal den visuelt kunne vise, når en spiller er blevet dømt offside (Figur 36) af DSS. Figur 36: Visualizer viser at en spiller er offside. Side 52

54 Følgende diagram (Figur 37) viser de use cases som VIS indeholder. Figur 37: Use case diagram over VIS. ControlVisualizer En operatør aktiverer start, som starter en UDPServer, som lytter på port efter positioneringsdata og en TCPServer, som lytter på port efter offsidebeskeder. VisualizePositionData Opdaterer alle objekters position på banen ud fra modtagne data fra UDPServeren. VisualizeOffside Sætter et flag som angiver, at den spiller som TCPServeren har modtaget data om er offside. Spilleren, som er blevet detekteret til at være offside, vises herefter i 5 sekunder som pink, i stedet for spillerens normale farve. Endvidere indikeres, at spilleren er offside også ved, at der vises teksten offside under spillerens ikon i samme 5 sekunder. Følgende viser et forenklet klassediagram over VIS. Klassen VisualizerForm har til ansvar, at modtage data via en UDPServer og en TCPServer. Ud fra disse data skal den vise bolden og spillernes aktuelle position grafisk, samt indikere, hvis en spiller er offside. VisualizerForm indeholder desuden klassen ServerSettingsForm, som bruges til ændring af indstillinger af IP-adresse og portnummer på UDPServeren. Figur 38: Klassediagram over VIS. Side 53

55 Programmet er udviklet til, at kunne modtage pakker fra SS med boldens og spillerne positioner. VIS viser bolden og spillerne som farvede punkter på en fodboldbane, som opdateres hvert 250 millisekund (pakker modtages ca. hvert millisekund). Figur 39 viser et sekvensdiagram over modtagelse af nye positioneringsdata. I VIS har vi implementeret en UDPServer, som modtager en UDP-pakke med nye positioneringsdata hvert millisekund. Når en pakke modtages, bliver denne dekodet, hvorefter objekternes position bliver opdateret med de modtagne data. Selvom VIS modtager nye positioner hvert millisekund, så bliver objekternes position i VIS kun opdateret hvert 250ms. Dette skyldes, at det tager forholdsvis lang tid, at tegne de grafiske objekter (bolden og spillerne) i vores VIS. For at vi ikke udsulter de tråde, som lytter efter UDPog TCP-pakker, har vi sat opdateringen til 250ms. Dette gør dog, at vi får en forsinkelse på den visuelle indikation af offside. Dog har dette ikke indflydelse på den faktiske tid som vores DSS tager for, at detektere en offsidesituation og viderebringe denne til den person, som skal dømme offsiden. UpdateScreen picturebox_paint <<PositionData>> GetPositionsThread <<active>> 250ms timer Timer event Invalidate() Læser positioner Modtager UDP-pakke Opdaterer Dekoder pakke Socket Opdaterer positioner UDP-pakker modtages hvert 1 millisekund 1 ms interval 250 ms interval Tegner alle objekter på fodboldbanen. Dette sker hver 250 millisekund. Modtager UDP-pakke Dekoder pakke Socket 1 ms interval Opdaterer positioner Figur 39: Sekvensdiagram over modtagelse af positioneringsdata. Endvidere er programmet udviklet til, at modtage pakker med offsidedata som DSS afsender, hvis den har detekteret, at en spiller er offside. Det er yderst vigtigt, at pakker som indeholder offsidebeskeder når frem til VIS. Derfor bruges der en TCP-forbindelse til kommunikationen imellem DSS og VIS. Brugen af TCP som transportprotokol sikrer, at evt. tabte pakker vil blive gensendt. Side 54

56 Følgende diagram (Figur 40) viser et sekvensdiagram over modtagelse af offsidebeskeder og efterfølgende visualisering i VIS. UpdateScreen picturebox_paint <<offsideflags>> OffsideThread <<active>> 250ms timer Timer event Invalidate() Læser flag 250 ms interval Opdaterer Timer event Invalidate() Tegner alle objekter på fodboldbanen. Læser flag Sæt offsideflag Modtager TCP-pakke Dekoder pakke Socket 250 ms interval Opdaterer Et flag sættes til true, hvilket indikere at denne spiller er offside. Tegner alle objekter på fodboldbanen. Nu vil en bestemt spiller være visualiseret som værende offside. Figur 40: Sekvensdiagram over modtagelse af offsidebesked. I VIS har vi implementeret en TCPServer, som lytter efter pakker med offsidebeskeder som DSS afsender, når den har detekteret, at en spiller er offside. Når en pakke modtages bliver denne dekodet, hvorefter ID et på den spiller som er offside, samt et timestamp for offsidehændelsen kendes. Herefter sættes et flag til true som indikerer, at den spiller, som den modtagne pakke indeholdt informationer om, er offside. Side 55

57 6.6. DommerStøtteSystem (DSS) Prototypen af DSS har til formål, at implementere de algoritmer og ideer vi har fundet frem til med henblik på, at programmere en detektering af offside. Den skal modtage positioneringsdata fra SS-prototypen og derefter beregne om der er opstået en evt. offsidesituation. Overordnet set har prototypen følgende use case diagram: DommerStøtteSystem (DSS) Modtag <<includes>> positioneringsdata Udfør offsidedetektion Positioneringssystem <<extends>> <<extends>> Dommer og Linjedommere Gem positioneringsdata Send offside indikation Visualizer (VIS) Persistent medie Figur 41: Use case diagram for DSS. Kort fortalt har de forskellige use cases følgende betydning. Modtag positioneringsdata: Sørger for at modtage positioneringsdata. Positioneringsdata kan komme enten i form af live feed fra et positioneringssystem, der monitorerer en kamp, input fra SS eller gemt data fra en tidligere kamp. Udfør offsidedetektering: Udfører en beregning på de indkomne positioneringsdata for at se, om der eksisterer en offsidesituation. I tilfælde af at der detekteres en offsidesituation, sendes der besked til de interessenter der måtte findes. Data persistering: Gemmer de modtagne data fra positioneringssystemet, så det er muligt senere at gense en sekvens eller en hel kamp. Dette kan bruges i forbindelse med enten analyse af en kamp, eller verifikation af en offsidekendelse. Send offsideindikation: Gør det muligt at sende en indikation til evt. interessenter om en offsidesituation. Interessenterne kunne f.eks. være dommer, linjedommer og VIS. Side 56

58 I modtagelsen af data, skelnes der ikke imellem, om data kommer fra et virkeligt positioneringssystem, fra en SS/SG eller er data, der er blevet gemt ved en tidligere lejlighed. Grunden til at vi ikke skelner mellem de forskellige inputsformer er, at det er formålet, at SG skal producere samme dataformat som et eksisterende positioneringssystem. Derved er der ikke forskel i formatet på de positioneringsdata der kommer ind i DSS fra henholdsvis et positioneringssystem eller fra SG. Da de gemte data enten stammer fra et positioneringssystem eller fra SG, vil de nødvendigvis også have samme format. Denne tilgang kræver dog, at alle positioneringssystemer bruger samme dataformat, hvilket kunne opnås ved at de forskellige udviklere af positioneringssystemer udviklede en fælles protokol. En anden, og nok også mere sandsynlig, metode, er at benytte en component configurator [Schmidt, Stal, Rohnert & Buschmann, 2001], der muliggør tilkobling af forskellige positioneringssystemer ved at tilføje en Dynamic Link Library fil (DLL). Ved at anvende sådan et mønster er det ikke nødvendigt, at rekompilere applikationen for at tilføje mulighed for nye positioneringssystemer, da al information om pakkeformat og deslige fås igennem DLL-filen Design og implementering Da det er vigtigt, at overholde deadlines for udregning af offside, inden næste pakke med positioneringsdata kommer, er DSS-prototypen designet med performance for øje. Vi har valgt at anvende realtidsoperativsystemet On Time RTOS-32 [On Time], da dette giver os god kontrol med tiderne i programmet Overordnet set består DSS-prototypen af to aktive tråde én tråd, der sørger for at modtage positioneringsdata og beregne offside ud fra disse, og én tråd, der sørger for at persistere de indkommende positioneringsdata i en fil. Figur 42 viser et forenklet klassediagram af DSS-prototypen. Figur 42: Forenklet klassediagram over DSS. Side 57

59 Den aktive klasse COffsideRef styrer selve flowet i udregningen af offside, og står for at modtage data og demarshalle disse om til koordinater på bolden og spillerne. COffsideCalc klassen står så for selve beregningen på, om der er offside eller ej. De data som kommer ind, persisteres i CFileIO klassen. For at mindske antallet af skrivninger til disken, gemmes data kun i klumper af 500 samples. Meget forenklet kan forløbet ses som på Figur 43. For et mere uddybende sekvensdiagram henvises til Appendiks Figur 43: Forenklet sekvensdiagram af DSS. Selve udregningen af offside i COffsideCalc foregår ved, at der beregnes på de indkomne data, for at detektere en aflevering. I det tilfælde, hvor en sådan detekteres, skiftes der til at beregne, hvilken spiller, der afleverede bolden. Derefter udregnes spillernes indbyrdes position, for at finde ud af om der skulle stå nogen spillere offside. Hvis en eller flere spillere udregnes til at være offside, sendes der en indikation, indeholdende de pågældende spillere, via TCP til VIS. Hvis ikke der findes nogen spillere der er i en offsideposition, returneres der blot uden at gøre noget. Fremgangsmåden kan beskrives som på Figur 44. Figur 44: Aktivitetsdiagram for DSS. Side 58

60 De algoritmer der sørger for at udregne de forskellige ting, er implementeret ved hjælp af et strategy-pattern [Gamma, Helm, Johnson & Vlissides, 1995]. Det gør det simpelt, at ændre i algoritmerne uden at skulle ændre i selve strukturen af programmet. Virkemåden kan anskues på følgende måde: Figur 45: Strategy-pattern på offsidedetekteringen. Selve styringen med de forskellige udregninger er i COffsideCalc implementeret vha. interne tilstande. Hver tilstand svarer således til en bestemt strategi. Fordelen ved at anvende et strategy-pattern gør, at det er muligt at forbedre en enkelt del af den samlede algoritme uden at skulle ændre i styringen. Endvidere, hvis der tilføjes yderligere beregningstilstande (f.eks. en kontrol for passiv/aktiv) offside, kræver det kun at man tilføjer den tilhørende strategi, da interfacet til de forskellige strategier er ens. Detektering af aflevering Selve udregningen på om bolden er accelereret og dermed afleveret, udføres ved hver indkommende sample, dvs. hvert millisekund. Da boldens bevægelse mellem to samples kan ske ikke at afstedkomme en ændring i koordinater jfr. Tabel 4, har vi valgt at udregne hastigheden af bolden, og dermed indirekte acceleration med 10 samples mellemrum svarende til 10 millisekunder. Måden hvorpå det udføres, er ved at de indkommende positioneringsdata fra bolden gemmes i en cirkulær buffer med 11 pladser, hvorefter hastigheden udregnes som den tilbagelagte afstand delt med den forløbne tid mellem den nye sample og den ældste sample i bufferen. Den udregnede hastighed gemmes som en attribut for den sample, og bruges så til at udregne ændringen i hastighed, hvilket er accelerationen. Vi forudsætter ikke at der altid er 10 millisekunder mellem den nye sample og den ældste da der er risiko for pakketab i systemet. En tabt pakke vil afstedkomme en tidsforskel på 11 millisekunder mellem den nyeste og den ældste sample, men da vi bruger forskellen på de to samples timestamp som mål for den forløbne tid, vil udregningen af hastigheden blive korrekt. Plads Samplingstid t n+8 t n+9 t n+10 t n t n+1 t n+2 t n+3 t n+4 t n+5 t n+6 t n+7 Figur 46: Eksempel på hvordan positioneringsdata ligger i den cirkulære buffer. Side 59

61 Figur 46 viser et eksempel, hvor plads 2 indeholder den nyeste sample og dermed indeholder plads 3 den ældste. Når den næste sample kommer gemmes den så plads 3, der så indeholder den nyeste sample, og den ældste sample er så på plads 4. På denne måde udføres beregningen hvert millisekund, og det er stadig muligt at detektere små hastigheder. Begrundelsen for at vælge en tidsforskel på 10 millisekunder mellem de to samples, der sammenlignes, hænger sammen med den tid, der er berøring mellem støvle og bold ved et spark. I afsnit analyseredes dette fænomen nærmere. Denne metode til at detektere en aflevering med er forholdsvis simpel, og en videreudvikling af afleveringsdetektionen kunne f.eks. inkludere en sammenligning med de spillere, der er tættest på bolden og deres hastighed, for ikke at fejldetektere en dribling som værende en aflevering. Som vi har implementeret den pt. kigger vi kun på en hastighed i X-Y planet. Dvs. at et lob (en såkaldt Michael Laudrup aflevering) måske ikke vil blive detekteret som en aflevering, da den primært har vertikal bevægelse og dermed ikke stor horisontal hastighed og derfor heller ikke stor horisontal acceleration. Detektering af hvem der afleverede bolden Måden hvorpå vi udregner, hvem der har afleveret bolden, er ved at beregne hvilken spiller, der står tættest på bolden i afleveringsøjeblikket. Udregninger er en simpel todimensional afstandsberegning baseret på henholdsvis bolden og spillernes koordinater. Som nævnt i afsnit er det dog en antagelse der kan give anledning til fejlkonklusioner. Detektering af offside Når vi skal detektere, om en eller flere spillere befinder sig i en offsideposition, er det første vi gør at sortere spillerne, således at vi har et billede af deres indbyrdes position på banen. Vi sorterer dem efter x-koordinatet, da vi kun har behov for at vide, om en angriber befinder sig tættere på mållinjen end den næstsidste forsvarsspiller. Efter sorteringen gennemløber vi en række forskellige betingelser, der er baseret på offsidereglen for at detektere en evt. offsidesituation. Fremgangsmåden kan anskueliggøres som på følgende aktivitetsdiagram: Side 60

62 Sorter spillere [onownhalf == true] Lokaliser afleverende spiller [onownhalf == false] [foremostattacker == true] [foremostattacker == false] Sammenlign spillere [Offside == false] [Offside == true] Send offside indikation Figur 47: Aktivitetsdiagram for offsidedetektering. Efter at spillerne er blevet sorteret efter deres x-koordinat, kontrolleres det om den forreste angriber, er over midterlinjen. Hvis han befinder sig på egen banehalvdel, er han ifølge reglerne ikke offside, og da der ikke befinder nogen medspillere foran ham, er der dermed ikke nogen spillere der står offside, og yderligere beregninger er ikke nødvendige. Hvis den forreste angriber derimod befinder sig på modstanderens banehalvdel, er der mulighed for, at han befinder sig i en offsideposition. Vi lokaliserer så den spiller der afleverede bolden, og hvis han samtidig er den forreste spiller kan der ikke være nogen medspillere offside, idet man skal være foran bolden for at være offside 24. Hvis spilleren, der aflevere bolden, ikke er den forreste angriber, betyder det at han har medspillere foran sig, og disse er dermed i risiko for at stå offside. De medspillere, der står foran den afleverende spiller, sammenlignes så med x-koordinatet på den næstsidste forsvarsspiller, for at afgøre om der eksisterer en offsidesituation. Er dette tilfældet, sendes en indikation til VIS om, at der er opstået en offside, samt hvilke spillere der befinder sig i offsideposition. 24 I Appendiks 11.4 er der beskrevet et scenario, hvor denne metodes kendelse kan være ukorrekt. Margenen er dog så lille, at det ikke kan afgøres pga. unøjagtigheden af koordinatet på +/- 3 cm. Side 61

63 Rækkefølgen af de forskellige betingelser er valgt for at kunne afgøre, at der ikke er offside, så tidligt som muligt. Derved spares antallet af udregninger og performance forbedres. En ting vi har valgt ikke at kigge på i denne henseende, er retningen af afleveringen. Normalt vil der ikke være offside, hvis bolden afleveres bagud, da der som oftest afleveres til en spiller bagved bolden. Et unikt tilfælde dog det scenario hvor to angribere f.eks. er alene med målmanden. Angriberen uden bold er forrest og boldføreren ligger så en aflevering bagud som den anden angriber løber tilbage til og sparker ind. Da han befinder sig foran bolden i afleveringsøjeblikket er han dermed offside, selvom bolden afleveres bagud Persistering Da det skal være muligt, at afspille en kamp eller et scenario på et senere tidspunkt, er det nødvendigt at persistere de modtagne positioneringsdata. Vi har i vores nuværende system lagt denne persistering i DSS, da det er her positioneringsdata modtages. I et endeligt system vil det være bedre at have en separat enhed, der står for denne persistering. Den vil i givent fald være tilkoblet samme netværk som DSS, og blot modtage de samme multicast-beskeder, og derfor ikke belaste det samlede system yderligere. Pga. performance har vi valgt, blot at gemme de modtagne binære data i en fil på harddisken. I tilfælde af, at man vil bruge disse senere, er det altså de rå koordinater og ID s på bold og spillere, der er at finde i filen. Et alternativ til at gemme data i en binær fil, er f.eks. at anvende en database. Ved at anvende en database vil data også kunne præsenteres nemmere, og det ville lette arbejdet, hvis der skal afspilles en sekvens fra en hel kamp (f.eks. en verifikation af en offsidekendelse). Da filtilgang ofte kan være ret tidskrævende, afhængig af den anvendte hardware og filsystemet [Caprani, personlig samtale dec. 2004], har vi valgt ikke at gemme de indkommende data fra sample til sample. Vi samler derimod samples i en buffer med 1000 pladser og gemmer disse, når den overstiger 500. Derved mindskes antallet af disktilgange betydeligt, og performance forbedres. Grunden til at vi har 500 ekstra pladser er, at vi opererer med flere tråde i systemet. Da den tråd der står for beregningen (beregningstråden) på bold og spillere har højeste prioritet, vil det nogle gange forekomme, at tråden der står for persisteringen (IO-tråden) ikke får lov at køre færdig, før den har gemt alle data. Vi har testet tiderne for skrivning af data til harddisken i det tilfælde, hvor det kun var IO-tråden der kørte, samt når beregningstråden kørte samtidig og havde højere prioritering end fil tråden. Det gav følgende tider: Gennemsnitlig tid Best case Worst case Kun IO-tråd kørende 3,158 ms 2,593 ms 3,590 ms Både IO-tråd og 61,525 ms 27,626 ms 77,193 ms beregningstråd Tabel 6: Tidsforbrug ved persistering af 500 samples af 119 bytes. Som det kan ses, er der stor forskel på, hvor hurtig det kan gøres, når tråden har eneret på processoren, og når IO-tråden skal dele processoren med en tråd med højere prioritet. Man kunne frygte at når køretiden for IO-tråden overskrider 1 millisekund, er systemet Side 62

64 ikke i stand til at følge med, men da vi kører med preemptiv skedulering, vil IO-tråden blive afbrudt, når beregningstråden skal køre. Beregningstråden vil derfor altid overholde sin deadline. Dette giver nødvendigvis en længere køretid for IO-tråden, hvilket også afspejles på figuren Trådprioriteter Da vi i vores prototype kun har 2 tråde, hvoraf den ene har en hård deadline, og den anden har en blød deadline, er tildelingen af prioriteter ligefrem. Ved at give beregningstråden den højeste prioritet sørger vi for, at den altid kommer til processoren når denne er ledig, og tråden skal køre. Persisteringstråden, der ikke har samme hårde deadline, får den overskydende processortid til at gemme data i, og benytter sig i mellemtiden af en stor buffer til at gemme indkommet data i. Denne form for concurrencystrategi kræver at kernen bruger premptiv skedulering til at tildele processortid med, idet det ellers kan være op til programmøren selv at sørge for, at en tråd frigiver processoren. Hvis DSS i fremtiden, skulle udvides med flere tråde til følge, vil man med fordel kunne anvende Rate Monotonic Analysis (RMA) [Liu & Layland, 1971] til afgøre om en deadline kan nås i en given situation, ved en given køretid for de forskellige tråde. Trådene tildeles i så fald prioritering efter princippet i Rate Monotonic Schedulering Kommunikation med interessenter Hvis DSS detekterer en offsidesituation, vil man i et endeligt system skulle kommunikere dette ud til linjedommeren og måske også dommeren. Ligeledes kan der være andre, der skal have denne information, såsom en VIS eller en kontrollant. For at det ikke skal være muligt at snyde systemet kræves det, at kommunikation fra DSS ud til interessenterne ikke kan saboteres eller efterlignes. Derfor er det nødvendigt med en form for kryptering af signalet, således at en tilskuer ikke kan sende et falsk signal til linjedommeren, så han tror det kommer fra DSS. Det skal ikke være muligt, for en evt. sabotør at lytte sig frem til offsidesignalet. Derfor kan man ikke blot nøjes med, at sende et signal i tilfælde af at en offsidesituation er detekteret. Derved vil dette signal kun kunne tolkes som en offsidepakke. Det er derfor nødvendigt, at have en kontinuerlig strøm af data, således at det ikke er muligt at finde offsidepakken, blot ved at lytte på kommunikationsmediet. Ovennævnte form for kryptering har ydermere den fordel, at den ikke er beregningstung, idet udregningen af de pseudo-randomme tal sker før kampen (og højst sandsynligt på en anden computer). Da alle pakker er kendt på forhånd, er det ligeledes muligt at detektere, hvis en person udefra prøver at sende en falsk besked. Vi har i vores prototype valgt, at implementere kommunikationen fra DSS til VIS ved hjælp af en TCP-forbindelse. Grunden til at bruge TCP i stedet for UDP, som vi ellers bruger, er at vi har brug for en pålidelig kommunikation, så pakken ikke går tabt. Vi har ikke implementeret nogen form for kryptering, da dette ikke er en del af det primære problem. Side 63

65 7. Test og Verifikation For at finde ud af om det er muligt, at detektere en offsidesituation ud fra kontinuerlige koordinater på bold og spillere, har vi testet vores udviklede prototyper. Prototyperne har implementeret de algoritmer og ideer vi er kommet frem til, gennem vores analyse af positioneringssystemer og offsidereglen. De forskellige tests har til formål, at sandsynliggøre at det er muligt at udvikle et DSS, der gør det muligt at detektere en offsidesituation i realtid. Dette gøres ved at evaluere de resultater vi opnår, samt vurdere evt. fejlkilder og mangler ved vores system Pakker pr. sekund Nøjagtigheden af en kendelse afhænger i høj grad af, hvor mange samples der er tilgængelige pr. sekund. Dette er både afhængigt af, hvor mange samples det er muligt at få fra positioneringssystemet pr. sekund, men også hvor mange vores DSS er i stand til at modtage pr. sekund Fremgangsmåde For at finde ud af, hvor mange samples DSS-prototypen kan nå at modtage i sekundet, har vi lavet en simpel test, hvor vi sætter en klient til at overføre UDP-pakker til DSS så hurtigt som muligt. Klienten er en Dell Optiplex GX270, mens DSS er testet på 3 forskellige maskiner. Først en SBC686 med en 133 MHz Pentium processor, dernæst en Dell Optiplex GX1 og til sidst en Dell Optiplex GX270. Yderligere specifikationer for testmaskinerne findes i Appendiks Måden hvorpå vi tester evnen til at modtage pakker, er dels ved at tælle antallet af modtagne pakker og sammenligne det med antallet af sendte pakker, og dels ved at benytte en debugfeature i On Time RTOS-32, der lader os se, hvor mange ledige bufferpladser der minimum har været under testen. Derved kan vi se, om vi har været tæt på at løbe tør for bufferplads, selvom vi har modtaget alle pakker. Udover at give et billede af, hvor mange pakker vi er i stand til at modtage, vil testen også afsløre om vores antagelse med, at pakketabet er minimalt, er korrekt. Dette kan ses ved, at vi ikke modtager alle de afsendte pakker samtidig med, at bufferen ikke har været fyldt på noget tidspunkt. Testopstilling Figur 48: Testopstilling til test af modtagekapaciteten. Side 64

66 Vi har testet performance med to forskellige pakkestørrelser. Først med pakker af 9 bytes data (60 bytes inkl. header), og dernæst med pakker af 119 bytes data (161 bytes inkl. header). Pakkerne med 9 bytes data bruges i det tilfælde, hvor positioneringssystemet sender koordinaterne på bolden og alle spillere individuelt. Det vil altså sige at der sendes 23 pakker pr. timestamp. Pakkerne med 119 bytes data er pakker, der indeholder bolden og samtlige spillere for et enkelt timestamp. Det kræver altså, at positioneringssystemet har samlet samples fra de enkelte sensorer og samlet dem i en pakke Resultat Testen er udført ved at sende UDP-pakker fra klienten til testcomputeren, der agerer server. Vi har defineret evnen til at modtage pakker på, til at bufferen ikke har brugt mere end 15 pladser ud af en samlet bufferstørrelse på 2500 pladser på noget tidspunkt. Derved sikrer vi os imod at en evt. lille forsinkelse i modtagercomputeren forsager pakketab pga. bufferoverflow. Testen gav følgende resultat (Afrundet ned til nærmeste 100): 9 bytes data / pakke 119 bytes data / pakke SBC 3958 (3900) 1628 (1600) Dell OptiPlex GX1 (DSS) (19.200) 6886 (6800) Dell OptiPlex GX (52.000) (34.600) Tabel 7: Maksimale antal pakker pr. sekund, der kan modtages. Tabel 7 viser, ikke overraskende, at det har betydning for performance både hvilken pakkestørrelse der anvendes, og hvilken hardware der sidder i computeren. Selvom der kan overføres flere 9 bytes pakker i sekundet end 119 bytes pakker skal det sammenlignes med, at det kræver 23 pakker med 9 bytes data for at modtage den samme information, som findes i én 119 bytes data pakke. Som nævnt tidligere vil pakker med kun 9 bytes data også skabe et massivt overhead, hvilket sænker den reelle dataoverførselshastighed. Den udførte test har følgende tal, når man kigger på dataoverførsel, overførte bytes i alt og overhead: 9 bytes data / pakke Overført data 9 bytes data / pakke Samlet trafik (data + header) SBC 35,6 kb/s 237,5 kb/s Dell OptiPlex GX1 (DSS) 173,6 kb/s 1157,6 kb/s Dell OptiPlex GX ,7 kb/s 3125,0 kb/s Tabel 8: Data versus overhead ved 9 bytes data pr. pakke. 119 bytes data / pakke Overført data 119 bytes data / pakke Samlet trafik (data + header) SBC 193,7 kb/s 262,1 kb/s Dell OptiPlex GX1 (DSS) 819,4 kb/s 1108,6 kb/s Dell OptiPlex GX ,5 kb/s 5574,8 kb/s Tabel 9: Data versus overhead ved 119 bytes data pr. pakke. Side 65

67 Overhead for de to forskellige pakkestørrelser er henholdsvis 85 % for de 9 bytes data og 26,1 % for 119 bytes data. Og som det kan ses i Tabel 7, kan det højere antal pakker ved 9 bytes ikke opveje det overhead der er i forhold til 119 bytes pr. pakke. Som Tabel 8, viser overføres der minimum 5 gange mere reelt data med 119 bytes data-pakker, end ved 9 bytes data-pakker. Testen viste også, at antagelsen om at pakketabet på netværket er acceptabelt lille, er korrekt. Det maksimale pakketab i et testgennemløb var én pakke ud af og i snit var pakketabet 0,33 pakke. Det giver et pakketab på 0,00033 % i snit. Hvis datamængden fra et eksisterende positioneringssystem skulle vise sig at være større end den vi antager, vil det stadig være muligt for vores prototype at følge med. Som testen også viser, afhænger performance i høj grad af, hvilken hardware programmet afvikles på. Her er der to ting, som er afgørende for mængden af data, det er muligt at modtage, nemlig netkortet og processorhastigheden. Alle tre testcomputere havde et 100 Mbit Ethernet netkort, og derfor kan det antages, at processorhastigheden har stor betydning på hvor hurtigt data, kan fjernes fra inputbufferen. Udover netkort og processor har busarkitektur og mængden af installeret RAM muligvis også en effekt på performance. Den computer hvorpå vi kører DSS-prototypen er en Dell OptiPlex GX1, der har en 350 MHz processor. Ved at benytte en hurtigere processor, vil vi altså kunne modtage en større mængde data indenfor samme tidsrum, som Tabel 8 viser. Ud i fremtiden vil både computere og netværk udvikle sig yderligere, hvilket muliggør transmission af en større datamængde på samme tid Evaluering/Verificering Hvis man sammenholder testdata med den mængde data vi producerer i SG (1000 x 119 bytes data-pakker i sekundet) kan det verificeres, at vores DSS-maskine (Dell OptiPlex GX1) er i stand til at modtage det fornødne antal pakker i sekundet. Derved kan det konkluderes at vores prototype på dette område, lever op til realtidskravene for i sidste ende at kunne beregne offside inden for 1 sekund. Ved at minimere antallet af pakker, belastes netværket samtidigt mindre og da overhead er mindre ved større pakker, bruges der i sidste ende mindre processortid på at modtage den samme mængde data. Om vores prototype ville fungere med et virkeligt positioneringssystem, afhænger i stor grad af i hvilket format vi modtager data. For at undersøge dette vil det kræve, at vi har adgang til eksempler på hvilke data, eksisterende positioneringssystemer stiller til rådighed. Som testen også viste, vil problemer med for stor datamængde, evt. kunne løses i første omgang, ved at benytte en hurtigere processor end den 350 MHz Pentium vi har anvendt Afleveringsdetektion Som nævnt i afsnit har vi defineret afleveringsøjeblikket til at være det øjeblik, hvor der ikke længere er kontakt mellem støvle og bold. Ved at analysere videoen [Sports] har vi fundet frem til, at der er berøring mellem støvle og bold, mens bolden flytter sig 10 cm. Det faktum har vi overført til vores SG, hvor en acceleration af bolden foregår over 10 cm, hvorefter bolden har nået sin angivne hastighed. Vi har så testet om Side 66

68 vores DSS-prototype kan detektere denne aflevering, og i så fald hvornår den gør det i forhold til, hvornår bolden antages at slippe støvlen. Detektionen af afleveringen er nødvendig at præcisere, for at kunne afgøre om en spiller evt. stod offside i det øjeblik Fremgangsmåde For at undersøge om DSS-prototypen er i stand til at detektere en aflevering, har vi testet den ved at afspille to scenarier, hvori en bold bliver afleveret fra henholdsvis stilstand, og med en initial bevægelse. Bolden er i SG defineret til at accelerere fra henholdsvis 0 m/s til 15 m/s og fra 5 m/s til 20 m/s altså en 15 m/s hastighedsændring i begge tilfælde. Detektionen foregår ved en simpel sammenligning med en threshold-værdi. Hvis accelerationen af bolden udregnes til at være større end denne prædeterminerede thresholdværdi, antages det at bolden er blevet afleveret. Som vi har beskrevet tidligere er denne måde på ingen måde fyldestgørende eller omfattende nok til at detektere alle afleveringer i en fodboldkamp. Vi har i denne test sat thresholdværdien til 950 m/s², hvilket svarer til en hastighedsændring på 10 m/s over 10 millisekunder (10 samples). Testopstilling Figur 49: Testopstilling til afleveringsdetektion. I testen holder vi øje med, hvornår DSS-prototypen detekterer afleveringen. Den sample, der giver anledning til detektionen udskrives for at kunne fastslå til, hvilket timestamp afleveringen er udregnet til at være foregået. Dette timestamp sammenlignes så med timestampet på data fra SS for at se om det passer med det tidspunkt, hvor denne har accelereret bolden. Da vi ikke prøver, at detektere en aflevering på andre måder end ved en kraftigt acceleration, har vi ikke testet prototypen for at se, om den kan detektere andre typer afleveringer, såsom en retningsændring af bolden Resultat I de to forskellige tests gav udskriften følgende resultat: Timestamp hvor aflevering detekteres Timestamp hvor spark påbegyndes i SS Antal samples fra afleveringen er påbegyndt til detektion Fra 0 m/s til 15 m/s Fra 5 m/s til 20 m/s Tabel 10: Antal samples fra aflevering til detektion. Side 67

69 Tabel 10 viser, hvor mange samples, der går fra sparket udføres i SS, til DSSprototypen detekterer afleveringen 25. Som det kan ses, er DSS i stand til at detektere en aflevering, både når bolden ligger stille i det øjeblik den bliver afleveret, og når bolden har fart på inden den afleveres (f.eks. en spiller der dribler med bolden). Da der samples hvert millisekund, detekterer vi altså en aflevering i DSS ca. 10 millisekunder efter at SS har udført den. Måden hvorpå SG laver en aflevering er ved at accelerere bolden op til en angivet hastighed indenfor en distance af 10 centimeter Evaluering/Verificering Resultatet af testen viste umiddelbart, at vores DSS-prototype er i stand til at detektere en aflevering. Det er dog med det forbehold, at afleveringen er en hård aflevering, hvor bolden accelereres minimum 10 m/s over 10 samples (afhængigt af threshold-værdi). I et endeligt system er denne metode mangelfuld og en videreudvikling af afleveringsdetektionen vil derfor være nødvendig. Som før nævnt, kunne denne forbedring bestå i, at sammenligne boldens bevægelse, med den boldførende spiller, og på denne måde afgøre om det blot er en dribling, eller om det er en aflevering. I vores prototype er det dog tilfredsstillende at have en simpel form for afleveringsdetektering, for at kunne bruge det til at teste de andre dele af DSS med. Samtidig har vi også fået bekræftet, at det er muligt at detektere en aflevering, ved at se på accelerationen af bolden. Vigtigst af alt detekterer vi afleveringen ca. 10 millisekunder efter den er påbegyndt. Som [Tol, J et al. 2003] har testet, er dette netop den gennemsnitlige tid, der er berøring mellem støvle og bold ved et spark til en fodbold. Vi vil derfor detektere afleveringen netop som bolden forlader støvlen (jfr. Figur 19) ScenarioSender Vi har i forbindelse med udviklingen af SS- og DSS-prototyperne overvejet, hvorvidt vi skulle sende enkelte pakker for hvert objekt eller sende en stor pakke med alle objekter i. Dette skyldes, som vi skriver i afsnit 4.1.1, at der vil komme et overhead på hele 85 procent på trafikken imellem SS og DSS i form af headere på UDP-pakkerne, hvis vi sender enkelte pakker for hvert objekt. Hvis vi derimod sender en pakke med alle objekter i vil dette overhead blive minimeret til 26,1 procent. Ved at sende en pakke med alle objekter i, har vi også sluppet for et problem med manglende regnekraft, da en test viste at processoren på vores test-pc havde svært ved at kunne følge med, når den skulle behandle 23*1000 modtagne pakker i sekundet. Da vi tidligt i udviklingen af SS-prototypen endnu ikke havde besluttet, hvorvidt vi ville sende enkelte pakker eller en stor pakke, lavede vi en test, for at måle om der var forskel på tiden det tog at sende UDP-pakker på de forskellige måder. Som man kan se i Tabel 11 viste vores test, at det tog 93µs at afsende 23 UDP-pakker med 9 bytes data og 64µs for at afsende én pakke med 119 bytes data. 23 UDP-pakker med 9 bytes pr. ms 1 UDP-pakke med 119 bytes pr. ms Tid: 93µs 64µs Tabel 11: Processeringstid for at sende pakker. 25 Timestampet afhænger af hvornår i scenariet bolden afleveres, og det er derfor kun forskellen mellem aflevering og detektering, der er interessant. Side 68

70 Da tidsforskellen for at afsende pakker på de to forskellige måder er relativ lille, vil det være lige meget, hvilken måde vi anvender til at afsende pakker med i SS. Da en senere test af DSS dog viste, at DSS ikke kunne nå at behandle 23*1000 pakker med 9 bytes i sekundet, valgte vi at anvende metoden, hvor vi sender en pakke med alle objekter i Test af DSS med forskellige scenarier For at teste DSS har vi opstillet en række scenarier i SG, som simulerer typiske fodboldscenarier fra den virkelige verden, som tit ender med fejlagtige kendelser. Disse scenarier indeholder situationer, hvor en spiller afleverer bolden til en modstander, som enten er onside, på linje eller offside. I DSS har vi defineret en threshold-værdi på 950 m s 2, der angiver en hastighedsændring, som bolden skal opnå over 10 ms (10 samples), for at DSS antager at en spiller har sparket til bolden Onside Her simulerer vi en situation, hvor en spiller er onside i afleveringstidspunktet, men kort tid efter afleveringen (under et sekund) står offside. Denne situation medfører ofte, at linjedommeren fejlagtigt bedømmer spilleren til at være offside. Dette scenario kan f.eks. opstå på følgende måde (Figur 50): Hold 1 s spiller 3 sparker bolden fra egen målfelt op til en angriber (spiller 10), som befinder sig 20m over midterlinjen. Angriberen står i afleveringsøjeblikket 50 cm onside. Linjedommeren skal følge den anden bagerste spiller fra hold 2, som i dette tilfælde er spiller 4. Da linjedommeren også skal kigge efter bolden hele tiden, har han i dette tilfælde et stort område på banen, som han skal dække med øjnene (det mørkegrønne område). Det er blevet videnskabeligt bevist [ Offside rule, 2000], [ Scientist say, 1998], at en linjedommer i netop dette scenario kan træffe en fejlagtig offsidekendelse, da angriberen i løbet af det splitsekund det tager linjedommeren, at flytte sine øjne fra bolden og tilbage til angriberen vil kunne bevæge sig nok til at stå i offside. Risikoen for at blive fejlagtig dømt offside bliver endvidere forøget, hvis angriberen og modstanderens forsvarsspiller bevæger sig i hver sin retning. Side 69

71 Figur 50: En spiller står onside i afleveringsøjeblikket På linje Dette scenario minder meget om foregående scenario med onside. I denne situation står angriberen dog på linje med forsvarsspilleren i afleveringsøjeblikket. Dette gør, at denne situation er endnu vanskeligere for en linjedommer at dømme korrekt, under de samme forhold, som vi havde i scenariet med onside. Dette skyldes, at angriberen i dette tilfælde i princippet kun skal bevæge sig et par enkelte cm, imens linjedommeren bevæger øjnene, for at stå offside Én spiller offside Dette scenario minder også en del om de andre scenarioer. I denne situation simulerer vi dog, at angriberen står offside i afleveringsøjeblikket. Side 70

72 To spillere offside Her tester vi om DSS kan detektere, at flere spillere står i offside på samme tid. Til dette formål har vi lavet et scenario, hvor to spillere står offside, idet afleveringen fra en medspiller falder Test af scenario hvor en spiller er onside i afleveringsøjeblikket Fremgangsmåde For at teste dette har vi opbygget et scenario i SG, hvori spiller 9 fra hold 1 afleverer bolden til spiller 10 fra samme hold. I afleveringsøjeblikket er spiller 10 fra hold 1 ca. 4m onside, men kort tid efter at afleveringen er faldet, står han offside. Dette er et typisk scenario fra den virkelige fodboldverden (Figur 1), som tit munder ud i en fejlagtig offsidekendelse fra linjedommeren. Scenariet er sat op således, at bolden i afleveringsøjeblikket accelererer stort over en distance på 10 cm, hvilket svarer til den distance vi har fundet frem til i afsnit 5.2.3, at en rigtig bold vil accelerere over, når der sparkes til den. Figur 51: Spiller 10 fra hold 1 er onside, idet spiller 9 fra hold 1 afleverer bolden. Side 71

73 Evaluering Til tiden 290 (timestamp) detekterede DSS en acceleration på 962 m s 2, hvilket den tolkede som en aflevering. Ved dette timestamp beregnede DSS, at ingen spillere stod offside. For at finde DSS responstid fra at have detekteret en acceleration af bolden, og til at have beregnet, om der var nogle spillere offside, udførte vi testen 5 gange. På baggrund af disse tests fandt vi, at den gennemsnitlige responstid for DSS var på 529µs. Test # Timestamp for detektion af acceleration af bolden Boldens acceleration [ m s 2 ] Tid for undersøgelse af om der er spillere offside [µs] Distance imellem næstsidste spiller fra hold 2 og forreste spiller fra hold 1 [cm] Tabel 12: Måledata fra testen Test af scenario hvor spillere er på linje i afleveringsøjeblikket Fremgangsmåde For at teste dette har vi opbygget et scenario i SG, hvori spiller 9 fra hold 1 afleverer bolden til spiller 10 fra samme hold. I afleveringsøjeblikket står spiller 10 fra hold 1 på linje med den anden bagerste spiller fra hold 2. Figur 52: Spiller 10 fra hold 1 står på linje med spiller 2 fra hold 2, idet afleveringen falder. Side 72

74 Evaluering Til tiden 290 (timestamp) detekterede DSS en acceleration på 962 m s 2, hvilket den tolkede som en aflevering. Ved dette timestamp beregnede DSS, at ingen spillere stod offside. For at finde DSS responstid fra at have detekteret en acceleration af bolden, og til at have beregnet om der var nogle spillere offside, udførte vi testen 5 gange. På baggrund af disse tests fandt vi, at den gennemsnitlige responstid for DSS var på 521µs. Test # Timestamp for detektion af acceleration af bolden Boldens acceleration [ m s 2 ] Tid for undersøgelse af om der er spillere offside [µs] Distance imellem næstsidste spiller fra hold 2 og forreste spiller fra hold 1 [cm] Tabel 13: Måledata fra testen Test af scenario hvor én spiller er offside i afleveringsøjeblikket Fremgangsmåde Vi har opbygget et scenario i SG, hvori spiller 9 fra hold 1 afleverer bolden til spiller 10 fra samme hold. I afleveringsøjeblikket står spiller 10 fra hold 1 offside. Figur 53: Spiller 10 fra hold 1 står offside i afleveringsøjeblikket. Side 73

75 Evaluering Til tiden 290 (timestamp) detekterede DSS en acceleration på 962 m s 2, hvilket den tolkede som en aflevering. Ved dette timestamp beregnede DSS, at spiller 9 fra hold 1 lavede en aflevering af bolden, og at hans holdkammerat spiller 10 stod offside. For at finde DSS responstid fra at have detekteret en acceleration af bolden, og til at have beregnet, om der var nogle spillere offside, udførte vi testen 5 gange. På baggrund af disse tests fandt vi, at den gennemsnitlige responstid for DSS var på 604µs. Test # Timestamp for detektion af acceleration af bolden Boldens acceleration [ m s 2 ] Tid for undersøgelse af om der er spillere offside [µs] Distance imellem næstsidste spiller fra hold 2 og forreste spiller fra hold 1 [cm] µs -282cm µs -282cm µs -282cm µs -282cm µs -282cm Tabel 14: Måledata fra testen Test af scenario hvor to spillere er offside i afleveringsøjeblikket Fremgangsmåde Vi har opbygget et scenario i SG, hvori spiller 10 og 11 fra hold 1 står offside, idet spiller 9 fra samme hold afleverer bolden imod dem. Figur 54: Spiller 10 og 11 fra hold 1 er offside i afleveringsøjeblikket. Side 74

76 Evaluering Til tiden 290 (timestamp) detekterede DSS en acceleration på 962 m s 2, hvilket den tolkede som en aflevering. Ved dette timestamp beregnede DSS, at spiller 9 fra hold 1 lavede en aflevering af bolden, og at hans holdkammerater spiller 10 og spiller 11 stod offside. For at finde DSS responstid fra at have detekteret en acceleration af bolden, og til at have beregnet, om der var nogle spillere offside, udførte vi testen 5 gange. På baggrund af disse tests fandt vi, at den gennemsnitlige responstid for DSS var på 630µs. Test # Timestamp for detektion af acceleration af bolden Boldens acceleration [ m s 2 ] Tid for undersøgelse af om der er spillere offside [µs] Distance imellem næstsidste spiller fra hold 2 og forreste spiller fra hold 1 [cm] Tabel 15: Måledata fra testen Testkonklusion Vi har i denne test fået fastslået, at DSS er i stand til at detektere de offsidesituationer vi har opstillet i vores testscenarier. Desuden viser testene, at DSS responstid ved detektering af en aflevering og den efterfølgende beregning på, om der er spillere som står offside, samt evt. afsendelse af offsidebeskeder, er indenfor det tidsinterval vi har sat som mål. Testene viser endvidere, at DSS responstid er ca. 630µs (scenariet med to spillere offside), hvilket vi anser som værende hurtigt nok til, at DSS ville kunne bruges til at detektere offside i realtid, og viderebringe et signal herom til en linjedommer eller en anden interessant. Side 75

77 8. Fremtidigt arbejde For at forbedre systemets evne til, at afgøre om en spiller er offside eller ej, er der flere ting der kan videreudvikles eller tilføjes. Af disse er afleveringsdetektionen den mest iøjefaldende i den måde prototypen fungerer på. Ved at udvide denne til også at sammenligne boldens bevægelse med spillerne i nærheden, ville man bedre kunne skelne imellem, om bolden er blevet afleveret, eller om spilleren blot dribler med bolden. En anden mulighed er, at anskue problemet på en helt anden måde, og derved få en anden løsning på problemet. Det kunne f.eks. være ved at lave en kombination af flere forskellige algoritmer, der arbejder sammen om at detektere en aflevering. Disse forskellige algoritmer kunne overordnet set, styres af en tilstandsmaskine, der beskrev forskellige situationer i spillet som tilstande (f.eks. bold acceleration, bold stoppet osv.) En mere krævende løsning er, at lade systemet sammenligne den aktuelle situation, med forskellige lagrede situationer, og ud fra dem genkende en offsidesituation. På denne måde kunne det også være muligt, at oplære systemet til at skelne mellem forskellige situationer. Vi har i vores DSS-prototype valgt ikke at skelne mellem aktiv eller passiv offside, men valgt blot at detektere, om en spiller står i offsideposition eller ej. Grunden til dette er primært, at afgørelsen i stor grad afhænger af den menneskelige vurdering af situationen. Systemet kan dog komme med et gæt, ved at sammenligne boldens bevægelsesretning med de spillere, der findes i den retning. Hvis der står en medspiller i den pågældende retning, som befinder sig i en offsideposition, kan det med stor sandsynlighed antages, at spilleren befinder sig i en strafbar offside. Vores prototype tager i sin nuværende form ikke højde for stop i spillet eller hvis bolden er ude af spil. For at fjerne fejlagtige offsideindikationer (f.eks. ved et indkast, hvor det ikke er strafbart at stå i offsideposition), vil det derfor kræve en videreudvikling af algoritmerne, hvor man prøver at detektere disse situationer og handle derefter. En metode kunne være at holde øje med, hvornår bolden havde været ude for banen, og dernæst ignorerer den næste aflevering. Her kan der yderligere opstå en vanskelig situation, idet man i nutidens fodbold benytter mange bolde under en kamp. Ryger en bold f.eks. ud til indkast, får spilleren der skal kaste indkastet en ny bold af en bolddreng, for ikke at skulle vente på den bold der røg ud. Det er så op til enten positioneringssystemet eller DSS at detektere, at det nu er en ny bold, der anvendes. Som vores samlede system er bygget op nu, befinder persisteringen af positioneringsdata sig i DSS-prototypen. Da persistering kan være tidskrævende, vil et endeligt system helt klart drage fordel af, at flytte denne del ud i en selvstændig enhed, der er tilkoblet netværket. Derved har DSS fuld processortid til, at beregne på positioneringsdata uden at skulle afsætte tid til persistering af disse. Derved vil der kunne afvikles mere tidskrævende algoritmer, med en større nøjagtighed til følge. Til at indikere om DSS har detekteret en offsidesituation, benytter vi os i prototypen af en simpel TCP-pakke til at kommunikere dette videre til VIS. I et endeligt system er det nødvendigt, at denne information er beskyttet af en form for kryptering, så evt. sabotø- Side 76

78 rer ikke kan lave falske kendelser. Denne kryptering kunne f.eks. foregå som i [Lassen, 2004], hvor det samtidigt er muligt at opdage, hvis nogen forsøger sabotage. Vi har i prototypen viden om, hvem vi skal kommunikere offsidebeskeden ud til, men i et endeligt system kan der være mange interessenter, der ikke er kendt på kompileringstidspunktet. Ved at implementere denne indikation vha. et publish/subscribe mønster [Gamma et al., 1995], er det muligt, at dynamisk abonnere på informationen fra DSS, der derved ikke på forhånd behøver at vide, hvem data skal sendes til. Alt afhængig af hvilken protokol der bruges, kan det dog være nødvendigt at have en begrænsning i antallet af mulige abonnenter for ikke bruge for meget processortid på kommunikationen. For at give dommeren eller linjedommeren besked om kendelsen, kræves der en form for trådløs kommunikation. Dette kunne være Bluetooth eller Wi-Fi, eller en selvudviklet form for radiokommunikation. For at gøre modtageren opmærksom på en offsidekendelse, kunne vedkommende f.eks. have en vibrator på armen, som det er tilfældet med dommere i nutidens fodbold. Her er det muligt for linjedommeren at få dommerens opmærksomhed, ved at benytte en knap i flaget, der så aktiver dommerens vibrator. På sigt vil der blive udviklet flere og flere teknologiske komponenter, der relaterer til fodboldspillet som f.eks. [I-Wear] og [GoalRef]. Dette åbner op for muligheden for at udvikle et DSS-framework, hvori de forskellige komponenter kan tilkobles. Derved kan man udnytte det enkelte systems forcer til en bestemt del af spillet, og derved opnå et meget fleksibelt system. F.eks. har [GoalRef] stor nøjagtighed omkring målstregen, mens [Cairos] dækker resten af banen, men dog med en mindre nøjagtighed. Ligeledes kunne man udvikle andre komponenter som f.eks. statistikkomponenter, der holder styr på spillerne og deres aktioner på banen. Dette vil kunne benyttes af trænere, til at analysere den enkelte spiller og holdet som helhed, mens bettingfirmaer kan bruge informationer som antal boldberøringer i løbet af kampen, til at indgå væddemål med. [I-Wear], som monitorer spillerens fysiske tilstand, vil kunne benyttes af holdets læge til at holde øje med spillernes helbred 26. Et sådant framework vil også kunne benyttes til andre sportsgrene, hvor der er mulighed for at implementere støttesystemer til dommeren (f.eks. ishockey eller basket). Det vil blot kræve en udskiftning af regelbeskrivelsen i DSS. 26 Set i lyset af den seneste tids dødsfald under kampe, vil dette være en sikkerhed for spillerne, da uregelmæssigheder forhåbentlig vil kunne fanges inden det bliver alvorligt. Side 77

79 9. Konklusion Vi har i dette speciale undersøgt, om det er muligt at lave et computerbaseret system, der kan hjælpe dommere og linjedommere i fodbold med at afgøre, om der i en given situation er offside. Til dette formål har vi udviklet en prototype af et DommerStøtteSystem (DSS), der detekterer en evt. offsidesituation ud fra boldens og spillernes koordinater. For at kunne udvikle dette system, har vi indledningsvist undersøgt eksisterende positioneringssystemer for at se, hvilke data disse kan levere om bolden og spillerne under en kamp, med den nuværende teknologi. Derudover har vi undersøgt, om specifikationerne af disse muliggør detektering af offside i realtid. Vi har gennem hele specialet taget udgangspunkt i Cairos eksisterende system [Cairos] og brugt specifikationerne for Cairos til at beskrive et simuleret positioneringssystem. Med udgangspunkt i disse specifikationer, har vi udviklet en prototype til generering af positioneringsdata til at teste vores system med. Vi har pga. hemmeligholdelse af dataformat i de eksisterende positioneringssystemer selv været nødt til, at definere de data som positioneringssystemet sender. Dette kan vise sig, at ligge langt fra virkeligheden og dermed i værste fald umuliggøre et DSS. En videreudvikling af et DSS ville derfor kræve, at man har adgang til eksempler på data fra et positioneringssystem, for at man kan garantere at algoritmerne fungerer som forventet. Ud fra de undersøgelser vi har lavet af eksisterende systemer, mener vi dog, at de data vi selv producerer også er tilgængelige i et virkeligt positioneringssystem. For at detektere en offsidesituation har det været nødvendigt, at analysere offsidereglen, for at kunne beskrive den vha. algoritmer. Målet er, at computeren kan regne på de forskellige koordinater på bolden og spillerne, og ud fra dem komme med en kendelse. Disse algoritmer er baseret på vores egne definitioner af uklarheder i offsidereglen og andre vil derfor måske have en anden mening om hvordan reglerne skal fortolkes. For at teste vores algoritmer mht. både hastighed og præcision, har vi udviklet prototyperne ScenarioGenerator (SG) og ScenarioSender (SS), der tilsammen simulerer et positioneringssystem. Vha. SG-prototypen kan vi opstille realistiske fodboldscenarier, og ud fra disse kreere koordinater på bolden og spillerne, som SS-prototypen kan afspille og derved simulere Cairos positioneringssystem. En ting der er stor usikkerhed ved, er at afgøre hvornår bolden bliver afleveret, samt hvem der afleverer den. Vi har i vores DSS-prototype valgt, at kigge på om bolden udsættes for en kraftig acceleration og ud fra det afgøre om bolden er blevet afleveret. Ved at optimere denne algoritme, vil den bedre være i stand til at skelne mellem driblinger og afleveringer og derved øge systemets brugbarhed. På baggrund af vores test og evaluering af DSS, mener vi det er muligt at detektere offside med en rimelig præcision, inden for et sekund med de systemer og teknologier, der er tilgængelige pt. For at gøre kendelsen helt nøjagtig, kræver det dog en revidering af offsidereglen, hvor der defineres et punkt, hvorved to spillere sammenlignes for at afgøre hvilken spiller, der er tættest på mållinjen. Som reglen er pt., vil det i sidste ende altid Side 78

80 være et skøn fra linjedommeren, der afgør om angriberen er nærmere mållinjen, med en overvejende del af kroppen, end den næstsidste forsvarer. Da flere af de positioneringssystemer [Cairos], [ABATEC], vi har undersøgt i dette speciale er under løbende udvikling, vil der med tiden komme forbedrede udgaver, der er endnu hurtigere og mere præcise dette vil så indirekte kunne forbedre præcisionen i et system som vores. Udviklingen går også i retning af mindre og mindre sensorer og længere batterilevetid og dermed større mulighed for en integration i sportsverdenen. Vores undersøgelse viser, at det er muligt at anvende allerede eksisterende teknologi til, at udvikle et DommerStøtteSystem til detektering af offside i fodbold. Hvis systemet skulle færdigudvikles til brug i rigtige fodboldkampe, kræver det at spillerne påmonteres mere end én sensor, samt at bolden færdigudvikles så den opfylder lovens krav. Et sådant færdigudviklet system vil også kunne overføres til andre sportsgrene, hvor det er vanskeligt at afgøre tvivlsomme situationer pga. spillets hastighed. For at udvikle et endeligt system, hvis afgørelser ikke kan anfægtes, kræver det dog en revidering af offsidereglen, da nutidens regel ikke tager højde for den præcision, man vil kunne opnå med et computerbaseret offsidedetekteringssystem. Side 79

81 10. Litteraturliste [1] ABATEC AG. Local Position Measurement Technology (LPM), [2] Castiglione, A. The History of Offside. Ken Aston Referee Society. ( (2002) [3] Cairos technologies AG. [4] Digital Sports Information, Trakus. [5] Eskildsen, J. En introduktion til mulighederne for GoalRef. Amitec (2004) [Beskyttet af tavshedspligt] [6] Ethereal version (2003) [Applikation] [7] Fodboldloven, 55. udgave, 2004/2005. Dansk Boldspil-Union. [8] Fraunhofer-Instituttet (IIS). [9] Gamma, E. Helm, R. Johnson, R. & Vlissides, J. Design Patterns aka. GOF. Addison-Wesley. (1995). [10] Gammel Roskilde Amts Fodbolddommerklub (GRAF). Ny fortolkning af strafbar offside [11] Garrigues, J. Europæisk patent nr. ES (2001) [12] Goalref. [13] Grant, Wyn. The Political Economy of Football. [14] Grün, Thomas von der. 3D Online Localisation and Tracking System of Players and Ball using Wireless Technologies. Cairos technologies AG. (28 april 2003). [15] Holzer, Christian & Braun, Oliver. A New Age of Soccer Analysis Cairos Tracking System (2004). [16] INMOVE. [17] I-Wear. Forskningsprojekt ved Hummel [personlig samtale, April 2004] [18] Lassen, M. GoalRef sikkerhed ved kommunikation. GoalRef. (2004) Side 80

82 [19] Lamont, M. Algorithms & Data Structures. (2004) [20] Liu, C. L. & Layland, J. W. Scheduling Algorithms for Multiprogramming in a Hard Real-Time Environment. Journal of the ACM. Vol. 20. No.1 (Jan. 1971) side [21] Maruzsi, L. Referee Support System [22] Offside rule impossible to call (2. Marts, 2000). BBC News. [23] Orad. HorseTrack. [24] On Time RTOS [25] Redmond, L. Mc. Offside Detection System in Soccer [26] Schmidt, D. Stal, M. Rohnert, H. & Buschmann.F. Pattern-oriented software architecture volume 2. John Wiley & Sons Ltd. (2001). [27] Scientists say they know why blinking refs get it wrong (23 Januar, 1998). BBC News. [28] Sports Science Lab. High Speed 4500 f/s (in4500.mpg). Fac. of Edu. Yamagata University. [Video] [29] Tol, J. L. Slim, E. van Soest, A. J. & van Dijk, C. N. The relationship of the kicking action in soccer and anterior ankle impingement syndrome: a biomechanical analysis. American Journal of Sports Medicine (Jan-Feb 2002) [30] Ubisense. [31] Xu, Ming, Orwell, James & Jones, Graeme Tracking football players with multiple cameras. Digital Imaging Research Centre. Kingston University. (2004). [32] Yichie, Edo & Schley, Eitan. Automatic recognition of "Offside" situation in soccer game. VISL Israel Institute of Technology (2003). Side 81

83 11. Appendiks Ordliste Transponder: En enhed som både kan modtage og sende signaler. Enheden sender kun data, hvis den modtager et forudbestemt signal. Dette svarer til et Master/Slave system, hvor Masteren poll er Slaven for at hente data. Denne type enhed bruger mere strøm end en transmitter, da modtagerkredsløbet og signalkonverteringen fra analog til digital er en strømkrævende proces. Transpondere findes både i passive og aktive udgaver. De passive udgaver har ingen strømforsyning, hvilket gør at de kun har en rækkevidde på få meter. Transmitter: En enhed som kun kan udsende signaler. Denne type enhed sender vedvarende signaler ud med et forudbestemt interval. Receiver En enhed som kun kan modtage signaler Overhead Figur 55 viser et screenshot fra snifferprogrammet Ethereal [Ethereal]. Med dette program har vi opfanget trafikken på vores dedikerede Ethernet. På figuren ses informationer om en enkelt UDP-pakke, indeholdende 9 bytes data. Den samlede størrelse på den modtagne pakke er 60 bytes. Da payloaden på en Ethernet-pakke minimum skal være 46 bytes og vi kun har 37 bytes at sende (9 bytes data + 8 bytes UDP-header + 20 bytes IP-header), bliver der via byte padding tilføjet 9 bytes ekstra (Figur 56). Det samlede 60 9 overhead bliver således = 85% 60 Figur 55: Screenshot fra Ethereal af en UDP-pakke med 9 bytes data. Side 82

84 9 bytes DATA 8 bytes 9 bytes 20 bytes UDP Header 17 bytes DATA 14 bytes 9 bytes IP Header 37 bytes DATA ETHERNET Header Padding bytes DATA 46 bytes Figur 56: Opbygning af pakke på Ethernet. Figur 57 viser ligeledes et screenshot fra Ethereal. Her vises informationer om en UDPpakke med en payload på 119 bytes. Her ses at størrelsen på den modtagne pakke er bytes. Det samlede overhead er i dette tilfælde således = 26,1% 161 Figur 57: Screenshot fra Ethereal af en UDP-pakke med 119 bytes data. Side 83

85 11.3. Detaljeret sekvensdiagram for DSS Følgende sekvensdiagram viser flowet i DSS-prototypen. Der ses hvordan den indkommende data demarshalles og gemmes i hjælpeklassen CCurrentField. Derefter hentes informationerne om bolden og sendes til COffsideCalc, der beregner om en evt. offsidesituation er tilstede. <<aktiv>> <<aktiv>> COffsideRef CCurrentField COffsideCalc CFileIO UDP pakke med positioneringsdata fromstream() UDP socket getball() CBall UDP pakke med positioneringsdata putball( CBall ) CalcOffside() putcond( Data ) Hvis mailboxen indeholder over 500 data pakker -> gem alle data fromstream() write( Data ) Figur 58: Detaljeret sekvensdiagram for DSS Mulig fejlkendelse Følgende offsidescenario vil ikke blive opdaget af algoritmen, som den er implementeret pt. Figur 59: Risiko for fejlkendelse Da spilleren der afleverer bolden er den forreste angriber, antager vi at der ikke er nogen medspillere der kan stå offside. Reglen siger dog at man skal være foran bolden for at være offside og derfor kan det lade sig gøre at den forreste angriber laver f.eks. en hæ- Side 84

86 laflevering til en spiller, der står lidt bag ham, men stadig foran bolden. Pga. unøjagtigheden af positioneringssystemet samt det faktum at det i virkeligheden ville se ud til at bolden og de to spillere er på linje, har vi valgt at se bort fra dette scenario. Ved at optimere algoritmen kan dette scenario dog også fanges Testsystem Vores testsystem består af følgende: 2 stk Dell Optiplex GX1 350 MHz Pentium II med 128 Mb Ram og 100 Mbit Ethernet NIC 1 stk Dell Optiplex GX270 2,7 Ghz Pentium 4 med 512 Mb Ram og 100 Mbit Ethernet NIC Alle 3 computere er forbundet via et 100 Mbit Ethernet, hvorpå der kun sidder de 3 computere Figur 60: Deployment diagram Side 85

87 11.6. Mails INMOVE From: Orwell, James M [mailto:[email protected]] Sent: 22. november :54 To: Gert Vestergaard Larsen Subject: RE: Accuracy of the INMOVE system? Hello Gert, Soren - sorry for not replying earlier. The accuracy of the system is dependent on a couple of factors: 1) the accuracy of the calibration of the cameras (transformations between the camera and pitch co-ordinate systems). 2) the detection of the full extent of the players (e.g., their hindmost part) is important. in addition, to implement an automatic offside system, 3) the motion of the ball would need to be understood to the extent that the start time of the critical pass (that potentially triggered the offside event) would need to be detected. at present, (1) is accurate to about 1m (worst case). this will be improved to about 10cm in the current system (using pre-match markers in addition to the pitch markings currently used). (2) is accurate to about 30cm. This may improve with more robust motion detection and modelling algorithms. The difficult thing to quantify is (3). It is difficult to estimate the proportion of critical kicks that will be correctly (and fully automatically) detected - I don't have enough data to provide this. at present perhaps 75% of kicks may be detected. There may also be other interpretative factors - e.g. a player "not involved in the play" returning to an on-side position. Rules could be developed for this (e.g. involving position and speed of the player) but it does complicate matters. The most interesting technology I saw for off-side was a system embedded in the poles of the flags held by the refs assistant. He kept a button pressed whenever any player was offside, and a 'fourth referee' pressed a button whenever there was a kick which potentially played someone offside. If the two buttons were pressed at the same time, the whistle was blown. This means that referees don't have to look in two places at once, and it de-personalizes the process. thanks for your interest, regards James James Orwell, PhD Senior Lecturer, Kingston University. [email protected] Side 86

88 Cairos Daer. Mr. Hansen, Thank you for your interest in the Cairos System. Right now, it is not possible for us to support you with positioning samples since we are still developing the system and we do not want to realese any classified data concerning the Cairos System. I hope you can understand this security issue. But I can send you some information concerning the Cairos System. Attached you will find these information. The problem with "Realtime Offside" is: When is a player offside? Is it when his arm is in an offisde position, is it when his whole body is in offside or just a leg?? That is the big point. We could track offside very easy, if the rules would say "the Leg which is closer than..." since our transmitters are integrated in the shinguards. We made some studies and we think that the Cairos System is the only system which can track Offside positions in realtime more accurate than any other system. But it would be great if you could send us your master thesis (when you finished it). Maybe we can learn more about the whole offside issue, if we take a look from your point of view. If you have any further questions, please feel free to contact me at anytime. Best regards, Oliver Braun Head of Marketing & PR Cairos technologies AG Im Stockmädle 18 D Karlsbad " Fidelity in Sports! " Side 87