Nicolas Soete

toepassingenGebruik van Augmented Reality voor SCADA

Academiejaar 2013-2014Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. Kurt StockmanVakgroep Industrieel Systeem- en Productontwerp

Master of Science in de industriële wetenschappen: elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Promotoren: prof. Johannes Cottyn, dhr. Ben Mahy

Nicolas Soete

toepassingenGebruik van Augmented Reality voor SCADA

Academiejaar 2013-2014Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. Kurt StockmanVakgroep Industrieel Systeem- en Productontwerp

Master of Science in de industriële wetenschappen: elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Promotoren: prof. Johannes Cottyn, dhr. Ben Mahy

Voorwoord

Graagwil ik het voorwoord gebruiken om een aantal personen te bedanken. Bijzondere dank gaat uit naarmijn ex-terne promotor Ben Mahy en interne promotor Johannes Co yn. Ben hee mij de kans gegeven om een boeiendonderwerp te verkennen en ik zal zijn enthousiasme niet gauw vergeten. Ik hoop dat onze wegen elkaar in detoekomst nog zullen kruisen. Johannes stond al jd paraat om mij te helpen en ik kon al jd op hem rekenen omalles in goede banen te leiden.

Verder wens ik de mensen die meegeholpen hebben aan het project van harte te bedanken. Dank aan WimHellinck en Pieter Schroé om mij wegwijs te maken in Experior. Verder wens ik Dieter Vandenhoeke te bedankenvoor de hulp om de opstelling in orde te krijgen. Laatste dank gaat uit naar Thibaut Demasure die het LES pro-gramma geschreven hee .

i

Abstract

The purpose of this thesis is to explore the opportuni es of augmented reality (AR) in combina onwith SCADA andto demonstrate the added value on a setup in the lab automa on. The project has been developed in collabora onwith the firm Sagility which is ac ve in the field of Virtual Commissioning for automated logis cs systems. Thesofware Experior is used to simulate material handling processes in a 3D virtual environment and to validate thePLC logic before going live. The goal of the thesis is to use Experior as SCADA for process monitoring and to coupleit with a vision system. The vision system uses a webcam to acquire a live feed of the setup.

Augmented Reality (AR) is part of a broader concept called mixed reality (MR) which refers in a general way tothe merging of real and virtual worlds. In the context of the thesis, Experior can be considered as the virtualenvironment while vision captures and displays the real-world. The defini on of AR is the enhancement of thereal-world environment with virtual elements. Besides AR, MR also encompasses augmented virtuality (AV). AVis used whenever the virtual environment is dominant with respect to the real-world elements. The aim of thethesis is to demonstrate both cases of MR.

In the first case, vision provides extra real-world informa on to the SCADA applica onwhich is used to improve thequality of the process visualisa on. A drawback of tradi onal SCADA applica ons, is that the process monitoringrelies on informa on received by input sensors. This results in a poor visualisa on where the object jumps fromone sensor to the other. The user is unaware of the state of the object between two sensors. To solve this problem,vision implements a tracking algorithm which sends the posi on of the tracked objects to Experior. Experior usesthis informa on to route and display the objects in themodel. This translates into a real- me process visualisa onwhere the state of the objects is known at all mes.

In the second part of the thesis, AR is used as a support tool on theworkfloor. Three case scenarios are elaborated:guidance in maintenance tasks, logis cs support and process monitoring. The applica on is interac ve so that theuser can select a par cular object in the live feed. Based on the user login, vision will send an informa on requestto Experior concerning the selected object. Experior returns the desired informa on, which is displayed as AR inthe live feed.

The thesis serves as a proof of concept to explore basic concepts of augmented reality and the integra on in aexis ng setup in close collabora on with SCADA systems. The next logical step would be to export the acquiredinsights to mobile devices. This would increase the prac cal relevance of AR on the workfloor. Even though ARhas not yet made a breakthrough in the industry, it offers very interes ng opportuni es to support the view ofthe operator on the long run.

ii

Inhoudsopgave

1 Inleiding 11.1 Bedrijfsvoorstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Projectaanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1 Produc eso ware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4.2 Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.3 Experior model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.4 Het visie systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Literatuurstudie 82.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Camerakalibra e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Kleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Randen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Objectdetec e en -opvolging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.1 Camshi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2 Achtergrondsubtrac e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.3 Karakteris eke beschrijving van punten . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5 Augmented Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.1 Defini e Augmented Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.3 Het Augmented Reality proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.4 IAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Uitgevoerde werk en resultaten 253.1 Overzicht van het uitgevoerde werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 De opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 De Beckhoff iPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Het LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Visie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.2 Camerakalibra e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.3 Markerdetec e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.4 CamShi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.5 Achtergrondsubtrac e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.6 AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.4.7 Overzicht visie applica e met TCP/IP interface . . . . . . . . . . . . . . . . . . . . . . . 41

3.5 Het Experior model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5.2 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Conclusies 51

iii

Lijst met a or ngen

A

ADS Automa on Device Specifica onAGV Automated Guided VehicleAPI Applica on Programming InterfaceAR Augmented RealityAV Augmented Virtuality

B

BGS BackGround Subtrac on

C

CAD Computer Aided DesignCIM Computer Integrated ManufacturingCPU Central Processor Unit

G

GPS Global Posi oning SystemGSD General Sta on Descrip onGUI Graphical User Interface

H

HSV Hue Satura on Value

I

IAR Industrial Augmented RealityIEEE Ins tute of Electrical and Electronics EngineersiPC Industrial Personal Computer

iv

IR Infrarood

K

KPI Key Performance Indicator

L

LED Light-Emi ng DiodeLES Logis cs Execu on System

M

MES Manufacturing Execu on SystemMoG Mixture of GaussiansMR Mixed Reality

N

NC Numeric Control

O

OEE Overall Equipment Effec venessOPC OLE for Process Control

P

PID Propor oneel-Integrerend-Differen ërendPLC Programmable Logic Controller

R

RFID Radio-Frequency Iden fica onRGB Red Green Blue

v

S

SCADA Supervisory Control And Data Acquisi on

T

TCP/IP Transmission Control Protocol/Internet ProtocolTwinCAT The Windows Control and Automa on Technology

W

WMS Warehouse Management System

X

XML eXtensible Markup Language

vi

Lijst van figuren

1.1 Virtual Commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Reality-Virtuality-con nuüm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Integra e van de doelstellingen in het project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 de CIM piramide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Schema sch overzicht van de opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Pinhole Camera Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Foto's onder diverse belich ngsomstandigheden . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Een vergelijking van kleursystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Back projec on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Meanshi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Meanshi probabiliteitsdistribu e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Binaire output achtergrondsubtrac e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 Stepflow achtergrondsubtrac e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.9 Morfologische bewerkingen openen en dichten . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.10 Toelich ng van MoG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.11 Objectdetec e SURF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.12 Hardware evolu e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.13 Schema AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.14 Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.15 Gescha e inkomsten van AR in mobiele applica es . . . . . . . . . . . . . . . . . . . . . . . . . 232.16 Remote maintenance mbv augmented reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.17 Overzicht van de toestanden van IAR applica es . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 De onderdelen van het uitgevoerde werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 eXtended Automa on Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 De TwinCAT omgeving in Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 Veldbussen en I/O aanslui ng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 Elektronisch circuit van het IR systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6 De gebruikersinterface van LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.7 Stap 1: Cameramatrix en distor ecoefficiënten . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.8 Stap 2: Rota e- en transla ematrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.9 Markerdetec e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.10 Camshi op basis van de Hue waarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.11 Camshi op basis van de gefilterde Hue waarde . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.12 Achtergrondsubtrac e overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.13 Verwijderen van schaduw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.14 Post-processing analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.15 Mask Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.16 A andeling Experior bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.17 Trein opvolging en balk projec e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.18 AR scenario technieker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.19 AR scenario logis eke operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.20 Flowchart visie systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.21 Experior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

vii

3.22 Communica e Experior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.23 Control paneel Experior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.24 Laden controller script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.25 Laden controller script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.26 Routering treinen script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.27 Overzicht werking controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

viii

1 Inleiding

1.1 Bedrijfsvoorstelling

Sagility BVBAmet hoofdzetel in Zwijnaarde, werd in 2008 opgericht door ir. BenMahy en ir. Wim Hellinck. Sagilitybiedt via de so ware Experior een 3D pla orm waarin geautoma seerde logis eke processen in een virtueleomgeving gesimuleerd kunnen worden. Daar de mogelijkheid bestaat om een Programmable Logic Controller(PLC) te koppelen aan het so warepakket kan de werking van een PLC programma virtueel getest worden. In ditgeval wordt er gesproken van virtuele emula e of Virtual Commissioning. Het principe van Virtual Commissioningen de func onaliteiten van Experior worden geïllustreerd in figuur 1.1.

Figuur 1.1: Virtual Commissioning

Virtual Commissioning biedt opportuniteiten naar ondersteuning en op malisa e gedurende de volledige levens-cyclus van het geautoma seerd systeem. Tijdens de ontwerpfase wordt het systeem virtueel geconstrueerd engeëmuleerd wat toelaat om fouten vroeg jdig te detecteren. In vele gevallen kan het PLC programma laa jdig inde implementa efase van het systeem goedgekeurd worden. Er gaat dus onvermijdelijk jd verloren in het tes-ten van het systeem om logische fouten en bugs op te sporen. De duur van de implementa efase kan aanzienlijkverkort worden door de testen in een virtuele omgeving te laten plaatsvinden. Het voorgaande geldt ook voor detraining van het personeel met bijkomende jdsbesparingen als gevolg.

Tijdens de opera onele fase kan het virtueel model als management tool gebruikt worden. Het gaat hier voor-namelijk om het emuleren van op maliseringsac es. Het resultaat kan onmiddellijk beoordeeld worden en ver-schillende scenario’s kunnen vergeleken worden. Experior zou echter op andere vlakken kunnen ingezet wordenjdens de opera onele fase namelijk op het gebied van monitoring. De focus van de masterproef situeert zich

binnen deze context en wordt in detail besproken in punt 1.2 en 1.3.

1.2 Probleemstelling

Om de probleemstelling duidelijk te formuleren, is het nodig om een aantal begrippen toe te lichten. Zoals inhet voorgaande punt beschreven, bestaat Virtual Commissioning uit het valideren van de werking van een PLC

1

door het geautoma seerde produc eproces in een virtuele context te emuleren. De PLC is het enige fysischeelement uit de werkelijke wereld terwijl het gedrag van de sensoren en de actoren van een produc esysteem ineen virtuele omgeving nagebootst wordt.

Het verenigen van virtuele enwerkelijke elementenwordt omschreven alsMixed Reality. Het spectrum vanMixedReality wordt voorgesteld in het Reality-Virtuality-con nuüm (figuur 1.2). Aan de uiteinden van het con nuümbevinden zich enerzijds de werkelijke wereld en anderzijds de virtuele omgeving. In de virtuele omgeving staatde gebruiker los van reële elementen, de omgeving is volledig virtueel opgebouwd. Tussen beide uiteinden vanhet con nuüm wordt er gesproken van AR indien de werkelijke wereld dominant is en verrijkt wordt met virtueleelementen. In het omgekeerde geval wordt er gesproken van Augmented Virtuality (AV). In de literatuur wordtdit onderscheid niet nauwkeurig gevolgd en wordt de defini e AR algemeen toegepast. In het vervolg van demasterproef wordt AR algemeen toegepast als de interac e tussen de werkelijke en de virtuele wereld.

Figuur 1.2: Reality-Virtuality-con nuüm

Naast AR, is Supervisory Control And Data Acquisi on (SCADA) het tweede sleutelbegrip van de probleemstel-ling. Het monitoren van processen behoort in de automa seringswereld tot het domein van de SCADA systemen.SCADA systemen verwerken gegevens van de PLC om een visuele weergave van het proces aan de gebruiker tepresenteren. Een groot deel van deze gegevens worden door de PLC verkregen uit klassieke I/O sensorenmet eenaantal nadelen als gevolg. Ten eerste is er geen informa e beschikbaar over de werkelijke posi e van het objecttussen twee detec esensoren. Zo kan een object bijvoorbeeld geblokkeerd zijn op een lijn zonder dat de gebruikerer weet van hee . Ten tweede resulteert dit in een gebruiksonvriendelijke visualisa e waarbij het object springtvan de ene posi e naar de andere. Een gebruiker zal waakzaam moeten afwachten tot een nieuwe sensor hetobject detecteert om zich te verzekeren van een toestandsverandering.

Opbasis vande toegelichte begrippen is er eenduidelijke probleemstelling omschreven. Sagilitywenst Experior alsSCADA systeem in te ze en om logis eke processen temonitoren. De uitgebreidemogelijkheden van de grafischeinterface in Experior gecombineerd met de PLC koppeling bieden het ondersteunende raamwerk om de SCADAfunc onaliteiten in te voeren. De monitoring moet resulteren in een vlo e visualisa e van het proces die deopgesomde problemen van klassieke SCADA systemen verhelpt.

Het tweede luik van de probleemstelling is gericht op de rol en de meerwaarde van AR in samenwerking metSCADA. Beide kanten van het con nuüm in figuur 1.2 moeten onderzocht worden. Aan de ene kant betekent ditde verrijking van het Experiormodelmet informa e uit dewerkelijkewereld, zoals posi e informa e omeen vlo evisualisa e te bereiken. Aan de andere kant biedt AR, gedefinieerd als de verrijking van de werkelijke omgevingmet virtuele elementen, interessante opportuniteiten om processen rechtstreeks te monitoren op de werkvloer.De masterproef moet de meerwaarde van AR in kaart brengen en er moet een applica e uitgewerkt worden dieop het logis ek proces getest kan worden. De probleemstelling wordt vertaald naar concrete doelstellingen inpunt 1.3.

2

1.3 Doelstellingen

De hoofddoelstelling is om Experior als een SCADA systeem in te ze en en te koppelen aan een visie applica e.De monitoring van het logis eke proces moet ten opzichte van klassieke SCADA systemen resulteren in een vlo evisualisa e voor de gebruiker door de objecten op de lijn real- me te volgen. Om dit te realiseren, is ervoorgekozen om de objecten te detecteren in 2D camerabeelden. Met het gebruik van een 2D camera wordt deinvestering in dure 3D technologie vermeden. Bovendien zijn 2D camera's ruim verspreid waardoor de prak scherelevan e van de masterproef toeneemt.

Er zal dus een applica e ontwikkeld worden om via beeldanalyse de objecten op de lijn te traceren. Het visie sys-teem moet een real- me verwerking zoveel mogelijk benaderen. De posi es van de objecten op de lijn moetenvervolgens in het Experior model geïmporteerd worden. Op deze manier wordt een waarheidsgetrouwe weer-gave van het logis eke proces gerealiseerd en wordt het virtueel model verrijkt met bijkomende informa e uit dewerkelijke wereld.

De tweede doelstelling van de masterproef bestaat erin de werking van het visie systeem te valideren en indiennodig te ondersteunen. Het valida e procesmaakt gebruik van de input van de induc esensoren omde posi ebe-paling verkregen uit de beeldanalyse goed te keuren of te verwerpen. Naast de valida emoet onderzocht wordenof eventuele gebreken van de visie applica e, kunnen opgevangen worden met informa e die beschikbaar is inhet Experior model.

De laatste doelstelling is om de mogelijkheden van AR in samenwerking met SCADA te onderzoeken. Door de ca-merabeelden te verrijken met produc e informa e vanuit Experior, kan AR een handige tool zijn om aanvullendeSCADA func onaliteiten te implementeren die het zicht van de operator op termijn ondersteunen. De master-proef moet een eerste aanzet zijn om de opportuniteiten van AR te verkennen door verschillende scenario's uitte werken die de relevan e van AR aantonen. Het achterliggende idee is om de verworven inzichten in verderonderzoek uit te breiden naar mobiele toepassingen.

De opgesomde doelstellingen worden geïmplementeerd op de opstelling met LEGO treinen in het lab automa -sering. De opstelling dient om logis eke processen te simuleren en is ideaal om een demo uit te werken. Figuur1.3 toont het principeschema om de verschillende doelstellingen in de demo te integreren. Het principeschemaresulteert in vier belangrijke modules die zich van elkaar onderscheiden. De scheidingslijnen in de figuur wordengebruikt om de modules in een industriële context te situeren op basis van de Computer Integrated Manufactu-ring (CIM) piramide.

Figuur 1.3: Integra e van de doelstellingen in het project

De CIM piramide 1.4 beschrij de integra e over alle func onele afdelingen in een bedrijf om tot schijnbaar één

3

groot bedrijfs-IT systeem te komen [1]. Het businessmanagement niveau is het hoogste niveau in de CIMpiramideen is onder andere verantwoordelijk voor het opstellen van de lange termijn planning en voor het uits ppelenvan de produc e strategieën van het bedrijf. Het onderste niveau in de CIM piramide stelt het produc e controleniveau voor. Dit niveau bestaat uit de controle systemen (SCADA en PLC) die de sensoren en actoren (klassiekeI/O of via veldbussen) op de werkvloer aansturen.

Het produc e management niveau, voorgesteld door de middelste laag van de CIM piramide, hee als doel omhet bovenste niveau met het onderste niveau te verbinden. Het produc e management niveau bestaat uit eenverzameling van systemen zoals het Manufacturing Execu on System (MES) voor de ondersteuning van produc-e, het Warehouse Management System (WMS) voor de ondersteuning van het magazijnbeheer en het Logis cs

Execu on System (LES) voor de ondersteuning van logis eke processen. Deze laag zorgt voor het verdelen vangedetailleerde planningen en instruc es naar de produc emiddelen. In omgekeerde rich ng zorgt het voor deverwerking van produc egegevens uit de onderste laag tot betekenisvolle informa e in de vorm van Key Perfor-mance Indicator (KPI)'s. De systemen van de middelste laag worden algemeen vernoemd als produc eso ware.Demasterproef situeert zich in de twee onderste lagen van de CIM piramidemet de nadruk op het laagste niveau.

Figuur 1.4: de CIM piramide

De volle lijn in het principeschema (figuur 1.3) bakent het produc e management niveau af van het produc econtrole niveau. Tot het produc e management niveau behoort de produc eso ware die een link hee metExperior en de PLC. Het produc e niveau wordt onderverdeeld in drie modules: de opstelling, Experior en hetvisie gedeelte. De s ppellijn onderscheidt de controle systemen van de fysische sensoren en actoren. De eerstecomponent betre de fysische opstelling in het lab automa sering met PLC sturing. Het tweede luik omvat hetmodel in Experior dat een virtuele kopie is van het systeem. Het laatste deel behandelt het visie systeem metde herkenning van de objecten op de lijn en de verrijking van de camerabeelden met AR. De webcam die opeen vaste posi e gemonteerd wordt, filmt de opstelling en stuurt de posi es van de objecten door naar Experior.Het Experior model is het centrale element dat de gegevens van de PLC en de webcam verwerkt om het procesreal- me te monitoren en op een vlo e manier te visualiseren.

In de projectaanpak onder punt 1.4 wordt elk luik verder onderzocht. De analyse moet de taken van elke moduleéénduidig vastleggen en een aantal pistes en aandachtspunten definiëren omde gevraagde resultaten te bereiken.

1.4 Projectaanpak

1.4.1 Produc eso ware

De focus van de masterproef ligt op de visualisa e van het proces en niet zozeer op de logica die erachter schuilt.Er zal een rela ef eenvoudige logis eke case geïmplementeerdwordenwaarvan de logica geprogrammeerdwordtin een bovenliggende applica e. Het beheer van logis eke processen valt onder de verantwoordelijkheid van het

4

LES. Om de werking van een LES te simuleren, moet een programma geschreven worden dat twee basisfunc o-naliteiten implementeert. In eerste instan e levert het LES de instruc es voor het aansturen van de opstelling enhet routen van de treinen. Ten tweede houdt het LES produc e relevante data bij die door het SCADA systeemgeraadpleegd kan worden voor visualisa e doeleinden.

1.4.2 Opstelling

De opstelling bestaat uit een logis ek traject waarop de treinen voortbewegen. De sporen stellen een logis ekeroute voor terwijl de treinen Automated Guided Vehicle (AGV)'s simuleren. De spoorwissels worden pneuma schaangestuurd door ze aan te sluiten op ven eleilanden. De eilanden zelf worden verbonden op een veldbus waar-mee de wissels vanuit de PLC aangestuurd worden. Om de treinen in de opstelling te detecteren, zijn er bij despoorwissels induc eve sensoren voorzien. De sensoren worden in een afzonderlijke schakelkast bekabeld op deI/O kaarten van een veldbuskop die de koppeling maakt met de PLC. De treinen zijn uitgerust met een infraroodantenne en worden standaard geleverd met een afstandsbediening van LEGO waarmee een persoon de snelheidvan de treinen kan aansturen. Naast het bekabelingswerk dat nog uitgevoerd moet worden, moet er dus eensysteem bedacht worden om de aansturing van de treinen onder controle te krijgen van de PLC. De besprekingvan het uitgevoerde werk rond de opstelling is te vinden in punt 3.2.

Figuur 1.5: Schema sch overzicht van de opstelling

1.4.3 Experior model

Experior hee verschillende modellen om logis eke processen te modelleren. Naargelang het gekozen modelworden bepaalde func onaliteiten beschikbaar. Anderzijds hee elk model zijn beperkingen. Binnen Experiorbestaat er geen kant en klare oplossing om AGV's te simuleren. Er moet dus gezocht worden naar een methodedie alle func onaliteiten implementeert die vereist zijn om het proces na te bootsen. Experior gee de gebruikerde mogelijkheid zelf programmacode te schrijven om zo ontbrekende func onaliteiten aan te vullen.

Naast het model moet een interface voorzien worden om de gegevensoverdracht vanuit het visie systeem te rea-liseren. Gezien het real- me karakter van de toepassing is de communica esnelheid een belangrijke parameter.Hiervoor moet de gegevenshoeveelheid tot een minimum herleid worden en moet het communica eprotocoleen snelle en betrouwbare uitwisseling garanderen. De hoeveelheid gegevens is beperkt daar er enkel posi ecoördinaten teruggekoppeld worden naar Experior.

Naast het visie systeem, moet er een koppeling gemaakt worden met de PLC. Experior biedt voor een aantal PLCreeksen een geïntegreerde interface aan om de onderlinge communica e tot stand te brengen. PLC’s waarvoor

5

deze func onaliteit niet in Experior opgenomen is, kunnen communiceren via een OPC server. Via de interfacekunnen de ac es van de PLC en de status van de sensoren in het model opgenomen worden.

Als laatste stap wordt een algoritme ontwikkeld om het proces vloeiend te visualiseren in Experior. Het algoritmestaat in voor de analyse en de correcte interpreta e van de posi e coördinaten die de webcam doorstuurt. De re-denering hierachter is dat er een aannemelijke kans bestaat dat een geïmporteerde posi e coördinaat niet perfectpast op een route van het model en dus gecorrigeerd moet worden. De onderliggende oorzaken van dit probleemzijn veelzijdig. Ten eerste zorgen vereenvoudigingen in het model ervoor dat er nooit een perfecte overeenkomstbestaat met de fysische opstelling waardoor een correcte posi ebepaling naast een route kan vallen. Ten tweedegaat de robuustheid van de objectdetec e, zoals in de literatuurstudie besproken zal worden, onvermijdelijk ge-paardmet een zekere foutenmarge. De laatste oorzaak is de codering van de routes in Experior diemoeilijk toelaatom met absolute coördinaten te werken. Een route bestaat uit een beginpunt en een eindpunt en de posi e opeen route wordt aangegeven door de afstand ten opzichte van het beginpunt.

Zoals er in de doelstelling 1.3 gesteld is, moet Experior de posi ebepaling van het visie systeem valideren. Deaccuraatheid van de objectdetec e kan getoetst worden aan de hand van de klassieke induc esensoren in deopstelling. Bij het hoog worden van een sensor kan Experior de vergelijking maken tussen de werkelijke posi een de posi e van het object in het model.

De integra e van de logica in Experior kan op verschillende manieren gebeuren.

• Cataloog: Experior.Catalog.<class name>.dll

• Controller: Experior.Controller.<class name>.dll

Ten eerste bestaat er de mogelijkheid om een controllerscript te schrijven en in het project te laden. Dit scriptkan reageren op events in het model, de componenten van de assembly aanspreken en het model aansturen. Eenandere op e is om cataloog te maken waaruit een gebruiker onderdelen kan slepen in de assembly. Een deel vande logica kan binnen de cataloog klasse geprogrammeerd worden.

1.4.4 Het visie systeem

De webcam stelt camerabeelden ter beschikking die via beeldanalyse verwerkt worden om de posi e van de ver-schillende objecten te detecteren. Vervolgens worden de camerabeelden verrijkt via AR om produc e informa ete tonen aan de gebruiker. De aanpak gebeurt in drie stappen:

• Camerakalibra e om de overeenkomst te vinden tussen een pixel en een 3D wereldcoördinaat.

• Objectdetec e om de objecten te volgen.

• Verrijking met AR.

De laatste decennia is er uitvoerig onderzoek verricht naar objectopvolging met verschillende modellen en algo-ritmes tot gevolg. De theore sche principes van objectdetec e worden in de literatuurstudie besproken. In dezesec e wordt de opstelling geanalyseerd om de elementen te bepalen die moeten leiden tot de keuze van eengepast detec ealgoritme.

In eerste instan e moet de opstelling zelf geanalyseerd worden.

• De webcam wordt op een vaste posi e gemonteerd waardoor de achtergrond sta sch is ten opzichte vande bewegende objecten.

• De omgevingscondi es worden als rela ef stabiel verondersteld zonder dras sche schommelingen in om-gevingslicht.

6

• De te volgen objecten, de treinen, nemen een klein veld in beslag in het camerabeeld waardoor het aantalbeschikbare pixels van de objecten laag is.

• Verschillende objecten moeten gelijk jdig gevolgd worden.

• De snelheid van de verschillende objecten is rela ef klein.

Naast de opstelling zijn er een aantal andere aandachtspunten die in beschouwing genomen moeten worden. Dewebcam neemt de beelden op aan een snelheid van 30 beelden per seconde. Real- me analyse betekent duseen verwerkingssnelheid van ongeveer 33 milliseconden per frame. Er zijn verschillende factoren die de verwer-kingssnelheid beïnvloeden zoals de resolu e van het beeld, het toegepaste detec ealgoritme en de beschikbarerekenkracht. Naast de rekensnelheid moet het systeem voldoende robuust zijn om zich aan te passen aan veran-deringen in de omgeving en om te ini aliseren zondermenselijke interven e. Om deze doelstellingen te bereiken,worden verschillende basisalgoritmes uitgetest. Vervolgens wordt een keuze gemaakt en wordt het algoritme opeen itera eve manier uitgebreid naar de noden van de toepassing.

De laatste beslissing die genomen moet worden in verband met objectdetec e is de keuze van de so ware voorde beeldanalyse. Door de groeiende populariteit van beeldverwerking bestaan er verschillende opensource plat-formen op het internet. De bekendste is ongetwijfeld OpenCV die uitgebreide bibliotheken ter beschikking stelt.OpenCV bestrijkt een breed domein en biedt func onaliteiten voor objectherkenning en camerakalibra e. Pro-jecten die gebruik maken van OpenCV worden geschreven in C of C++. Om hogere programmeertalen toe telaten zoals C# en VB.net bestaat er Emgu CV die een .NET wrapper is van de OpenCV bibliotheken. Het nadeelvan Emgu CV is een vertraging van de verwerking en onvolledige toegang tot de OpenCV func onaliteiten. NaastOpenCV wint Matlab aan populariteit. Matlab hee uitgebreide en gebruiksvriendelijke func onaliteiten voorbeeldanalyse.

Op het vlak van AR wordt een demo uitgewerkt die de opportuniteiten van AR in een industrieel kader in kaartbrengt. Het weergeven van AR kan op verschillende manieren gebeuren zoals het a eelden van teks nforma e,een video afspelen op een deel van het beeld of het renderen van 3D objecten. De nadruk ligt op de relevan e vande informa e enminder op het visuele effect. In de literatuurstudiewordt er bekeken in hoever AR doorgedrongenis op de produc evloer en welke concepten en realisa es in de vakliteratuur te vinden zijn.

De keuze van de so ware om AR te realiseren, zal a angen van de integra emogelijkheden met het so warepakket van objectdetec e. Voor het renderen van virtuele objecten wordt typisch gewerkt met bibliotheken dieonderliggend gebruik maken van OpenGL func es. Low-level bibliotheken zijn onder andere GLUT, GLFW,.. envoorbeelden van high-level bibliotheken zijn OpenSG, OGRE, ARtoolKit,...

7

2 Literatuurstudie

2.1 Inleiding

De literatuurstudie concentreert zich op de onderwerpen die nodig zijn om de doelstellingen opgesomd in 1.3te behalen. In eerste instan e wordt de camerakalibra e besproken die nodig is om de posi e van een objectin het camerabeeld te vertalen naar 3D wereldcoördinaten. Vervolgens komt de beeldanalyse aan bod. Punt2.3 richt zich op de features aanwezig in het camerabeeld. De extrac e van de features is een belangrijke stapvan de detec e algoritmes besproken in punt 2.4. De bespreking van de aangehaalde punten hee niet tot doelom een exhaus eve opsomming te geven van beeldanalyse technieken, maar eerder om de lezer te helpen dooreen theore sche onderbouwing te geven aan de gebruikte methodes. Het laatste punt introduceert het conceptvan AR of de manier waarop het beeld verrijkt kan worden met nu ge informa e voor de gebruiker. Er wordts lgestaan bij het gebruik van AR in de industrie en meer specifiek bij de rol van AR als aanvulling op SCADAtoepassingen.

2.2 Camerakalibra e

Om de posi e van een object te bepalen moet er naast het detecteren van het object, een correcte omrekeninggebeuren van de 2D beeldcoördinaten naar de werkelijke 3D wereldcoördinaten. De omrekening gebeurt meteen cameramodel waarin de intrinsieke en extrinsieke parameters van de camera opgenomen zijn. De intrinsiekeparameters beschrijven de eigenschappen van de camera, zoals brandpuntafstand en de vervormingsparametersvan de lens. De extrinsieke parameters slaan op de posi e en oriënta e van de camera ten opzichte van een vastwereldcoördinatenstelsel [2].

Het cameramodel vertrekt van het pinhole camera model afgebeeld in figuur 2.1. In de figuur resulteert de pro-jec e van een wereldcoördinaat P op het beeldvlak in het punt p. Het beeldvlak staat op de focale lengte f vanhet op sche centrum C.

Figuur 2.1: Pinhole Camera Model

In een eerste stap worden de lensvervormingen in rekening genomen. Lensvervormingen bestaan uit radiale entangen ële vervormingen. Er wordt niet dieper ingegaan op deze onderwerpen, de lezer moet er enkel rekening

8

mee houden dat de beeldcoördinaat p = (x, y) in het vervolg van deze paragraaf de correc e van de lensvervor-ming inhoudt.

Vergelijking 2.1 is de wiskundige vertaling van het cameramodel en bepaalt de omze ng van een 3D coördinaat ineen 2D coördinaat (in homogene coördinaten). De eerste tweematrices stellen de intrinsieke parameters voor vande camera. De eerstematrix zorgt voor de gewenste verschaling via px en py bijvoorbeeld inmeters of millimetersen legt de coördinaat van het op sche centrum vast (cx, cy). De tweedematrix brengt de focale lengte f in kaart.De focale lengte verandert bij het in- en uitzoomen. De derde matrix omvat de extrinsieke parameters waarbij deelementen r11, r12, ... deel uitmaken van de 3× 3 rota ematrixR en de elementen t1,2,3 van de transla evectorT .

x

y

1

=

1px

0 cx

0 1py

cy

0 0 1

×

f 0 0

0 f 0

0 0 1

×

r11 r12 r13 t1

r21 r22 r23 t2

r31 r32 r33 t3

×

X

Y

Z

1

(2.1)

2.3 Features

Om nu ge informa e uit het beeld te halen, wordt er in het beeld gezocht naar kenmerken. Deze kenmerkenof features zoals vernoemd in de Engelse vakliteratuur, zijn het startpunt van de beeldverwerkingsalgoritmes.Typische features zijn kleur, randen, hoekpunten, textuur en mo on features zoals op cal flow [3]. Textuur iseen visueel patroon dat periodiek of stochas sch wordt herhaald in het beeld. Een voorbeeld hiervan is eengeweven tapijt. Textuur en op cal flow zijn minder toegepaste technieken die niet in aanmerking komen voor demasterproef. De features kleur en randen worden in de volgende punten 2.3.1 en 2.3.2 verder uitgediept.

De beeldanalyse steunt op één of op een combina e van deze eigenschappen. De features kunnen op pixelniveaubepaald worden of kunnen betrekking hebben op een cluster van pixels. De extrac e van deze kenmerken iseen belangrijke stap in object herkenning en verschillende parameters moeten in beschouwing genomen wordenom de juiste set van kenmerken te kiezen. De features moeten enerzijds summier, compleet en invariant zijnen anderzijds een hoge discrimina egraad bezi en. Invarian e en selec viteit zijn tegenstrijdige eigenschappenwaardoor een juiste balans gezocht moet worden [4]. De geëxtraheerde feature set wordt de karakteris ekebeschrijving genoemd en wordt voorgesteld in een vectorruimte, een sta s sch of logisch model.

2.3.1 Kleur

De meest gebruikte en voor de hand liggende feature is ongetwijfeld kleur. Kleur is het waargenomen effect vanzichtbaar licht en wordt gekenmerkt door de verschillende golflengtes waaruit dat licht is samengesteld. Kleur kanop verschillendemanieren geïnterpreteerd en gemodelleerdwordenmaar geen enkel model is universeel [5]. Eenmodel stelt een kleurenruimte voor waarbinnen elke kleur als een vector gepresenteerd kan worden.

Een bekendmodel is het RedGreen Blue (RGB)model dat een kleur uitdrukt in func e van 3 primaire kleuren Rood,Groen en Blauw. Aangezien dit model nauw aansluit bij de menselijke percep e wordt het als een standaard ge-bruikt in display toepassingen. In beeldverwerking krijgt het genormaliseerd RGBmodel dikwijls de voorkeur overhet klassieke RGB model om redenen van lineariteit en van robuustheid tegenover wisselende omgevingscondi-es.

In de beeldanalyse wordt het RGB beeld dikwijls omgevormd naar de Hue Satura on Value (HSV) kleurenruimte.HSV bestaat uit drie waarden, namelijk de hue (= nt of kleurtoon), de satura on (=verzadiging of de hoeveel-heid/felheid van een kleur) en de value of brightness (=intensiteit of lichtheid van de kleur). De voordelen vanhet HSV systeem worden geïllustreerd in figuur 2.2 [6]. Hoewel de kleur van de wagen niet verandert, wordt het

9

visuele aspect sterk beïnvloed door de verschillende belich ngsomstandigheden. De analyse van de HSV waar-den toont aan dat de schommeling in de hue waarde 3,5% is en in de brightness 55%. Bijgevolg beschikt de HSVkleurenruimte over een groot onderscheidingsvermogen om een kleur te herkennen in wisselende belich ngsom-standigheden. Veel toepassingen maken van deze eigenschap gebruik door enkel de hue waarde in het algoritmete betrekken waardoor de presta e verbetert [7].

Figuur 2.2: Foto's onder diverse belich ngsomstandigheden

De vraag over welke kleurenruimte het meest aangewezen is, hangt af van de toepassing. Hiervoor zijn verschil-lende criteria gedefinieerd die dienen om de verschillende kleursystemen te evalueren [4]. De belangrijkste ervanzijn:

• Belich ngsinvarian e

• Gezichtspunt ona ankelijkheid, dit betekent ona ankelijk van de oriënta e van het object ten opzichtevan de camera.

• Ona ankelijkheid van de vorm van het object.

• Lineariteit van het kleursysteem.

In figuur 2.3 wordt een overzicht gegeven van bekende kleursystemen.

Figuur 2.3: Een vergelijking van kleursystemen

2.3.2 Randen

De grenzen van een object leiden dikwijls tot een duidelijk gradiënt verschil in intensiteit tussen naburige pixelsin het beeld. De belangrijkste eigenschap van randen is dat ze minder gevoelig zijn voor belich ngswijzigingendan kleur. De Canny rand detector is de meest gebruikte techniek omwille van zijn eenvoud en precisie. Hetprincipe berust op de eerste orde afgeleiden van de intensiteit van een pixel in horizontale en ver cale rich ng. Bijdifferen a e technieken moet ruis onderdrukt worden. In het Canny algoritme wordt dit bereikt door convolu emet een gaussfilter in een eerste stap. Uit dit afgevlakte beeld worden de eerste afgeleiden berekend. Hieruitkunnende amplitude ende rich ng van de gradiënt bepaaldworden. De rich ngwordt uitgedrukt als een hoek tenopzichte van de horizontale as. De naburige pixels in deze rich ng worden vergeleken op basis van de amplitudevan hun gradiënt. Enkel de pixel met de grootste gradiënt is een kandidaat randpixel. Dit is het proces van nietmaximale suppressie. Om te bepalen of de kandidaat pixel effec ef een randpixel is, wordt een drempelmethodemet hysteresis toegepast. Pixels boven de bovengrens worden toegelaten en pixels onder de ondergrens wordenverworpen [8].

10

De Gaussfilter in de eerste stap speelt een belangrijke rol in het uiteindelijke resultaat. Door een filter te nemenmet een grotere standaarddevia e worden ruiselementen beter gefilterdmaar zullen zwakke randen door de toe-genomen afvlakking uiteindelijk niet meer herkend worden. De Gaussverdeling is eigenlijk een laagdoorlaa iltervan spa ale frequen es. Laag spa ale frequen es representeren grote overgangen tussen licht en donker enverstrekken informa e over de globale vorm, propor es en contouren van objecten in de omgeving. Hoog spa-ale frequen es (HSF) representeren abrupte, kleine intensiteitsveranderingen, ofwel fijne details uit de visuele

omgeving.

2.4 Objectdetec e en -opvolging

Er bestaat tegenwoordig een bredewaaier aan technieken om een object te detecteren in het beeld. De keuze vaneen gepast algoritme hangt in grote mate af van de features die uit het beeld geëxtraheerd moeten worden. Deefficiën e van een algoritme is bijgevolg toepassingsa ankelijk. Hierna volgt een bespreking van de algoritmesdie relevant zijn voor deze masterproef en die de laatste decennia uitgegroeid zijn tot populaire methodes inobjectdetec e.

2.4.1 Camshi

Camshi is een verbeterde versie van het Meanshi algoritme waarvan de grondslag gelegd is door Bradsky [9].De bespreking van het algoritme gebeurt in drie stappen:

• Back projec on

• Meanshi

• Camshi

De input van het Camshi algoritme is een beeld in grijs nten dat de back projec on genoemd wordt. Om deback projec on te berekenen, wordt een kleur histogram gemaakt van het te volgen object. Meestal wordt hetRGB beeld in de HSV kleurenruimte omgezet en wordt er vervolgens enkel met de hue waarde gewerkt om deefficiën e van het algoritme te verbeteren (zie punt 2.3.1).

Het principe van back projec on wordt het best uitgelegd aan de hand van een voorbeeld zoals weergegeven infiguur 2.4. Er worden 3 stappen doorlopen om de back projec on te berekenen:

• Ten eerste wordt het object geselecteerd in het beeld. Het geselecteerde gebied is aangeduid met de roderechthoek.

• Er wordt vervolgens een kleur histogram opgemaakt van de pixels in de rechthoek. De hue waarde van eenpixel ligt tussen 0 en 180. De balken in het kleur histogram worden bins genoemd. De breedte van eenbin stelt een kleurbereik voor, terwijl de hoogte van een bin het aantal pixels in dat kleurbereik voorstelt.In figuur 2.5 hee het histogram 15 bins. De eerste bin toont dus het aantal pixels met een hue waardetussen 0 en 12, de tweede bin het aantal tussen 13 en 24,... en de laatste bin het aantal tussen 169 en 180.Vervolgens worden de waardes van de bins genormaliseerd tussen 0 en 255. Dit betekent dat de hoogstebin de waarde 255 krijgt. Alle andere bins worden verhoudingsgewijs geschaald. Uiteindelijk wordt eenhistogram verkregen waarvan de hoogtes van de bins gelegen zijn tussen 0 en 255.

• In de laatste stap gebeurt er een omze ng van de pixels in het originele beeld. Aan de hand van de huewaarde van elke pixel, wordt er gezocht naar de corresponderende bin in het histogram. Vervolgens wordtde pixelwaarde in het beeld vervangen door de waarde van de bin. Aangezien de bin waardes genormali-seerd zijn tussen 0 en 255, is het eindresultaat een grijsbeeld dat de back projec on genoemd wordt (ziefiguur 2.4). In een grijsbeeld hebben wi e pixels de waarde 255 terwijl zwarte pixels de waarde 0 hebben.

11

Tussenliggende pixels zijn donkergrijs als ze dicht bij 0 liggen en worden wi er naarmate ze 255 naderen. Inde figuur is het object voorgesteld door wi e(re) pixels terwijl de achtergrond bijna volledig zwart is. Sta-s sch gezien, kan de back projec on geïnterpreteerd worden als de waarschijnlijkheid van elke pixel om

tot het object te behoren.

Figuur 2.4: Back projec on

Nu het begrip 'back projec on' verduidelijkt is, kan het Meanshi algoritme onder de loep genomen worden. Hetmeanshi algoritme maakt gebruik van een zoekvenster en verwacht een aantal input parameters waaronder degroo e van het zoekvenster en de ini ële loca e van het zoekvenster. Met deze parameters kan het algoritmevan start gaan:

• De ini ële loca e dient om het centrum van het zoekvenster te posi oneren in de back projec on.

• Van de pixels in het zoekvenster worden een aantal parameters berekend die momenten genoemd worden(I(x, y) stelt de grijswaarde voor van een pixel op rij x en kolom y):

M00 =∑x

∑y

I(x, y) (2.2)

M10 =∑x

∑y

xI(x, y)

M01 =∑x

∑y

yI(x, y)

• De berekende momenten worden gebruikt om xc en yc af te leiden:

xc =M10

M00(2.3)

yc =M01

M00

(xc, yc) is een posi ecoördinaat die qua interpreta e analoog is aan het zwaartepunt van een massa in defysica. In de Engelse vakliteratuur wordt deze stap de 'Mean calcula on' genoemd.

• Vervolgens wordt (xc, yc) vergeleken met het centrum van het zoekvenster. Als beide posi es overeen-komen springt het algoritme naar de laatste stap. In het tegenovergestelde geval wordt het centrum vanhet zoekvenster verschoven naar het zwaartepunt (uitgedrukt als Mean shi in het Engels). Met de nieuweloca e van het zoekvenster keert het algoritme terug naar stap 1. Deze cyclus wordt herhaald tot er con-vergen e bereikt is.

• In deze laatste stap wordt het centrum van het zoekvenster geretourneerd. Het centrum van het zoekven-ster wordt de ini ële loca e van het zoekvenster in de volgende frame.

Het Meanshi algoritme is een itera ef proces dat al jd naar convergen e zal leiden. Een visuele voorstelling vanhet algoritme wordt gegeven in figuur 2.5. De inpu rame stelt een gezicht voor die verschoven is ten opzichte

12

van de vorige frame. Op basis van het kleur histogram van de huid wordt een back projec on gemaakt. Deopeenvolgende itera es worden duidelijk geïllustreerd in de figuur. In de vierde itera e is convergen e bereikten zoals in de laatste stap te zien is, hee het algoritme de verplaatsing van het gezicht kunnen volgen.

Figuur 2.5: Meanshi

Het Meanshi algoritme zal in de prak jk meestal falen om een object te volgen. Dit hee te maken met devaste groo e van het zoekvenster. Een object zal naarmate het verder verwijderd is van de camera als een kleineen teit op het camerabeeld verschijnen. Het venster is in dit geval dispropor oneel groot ten opzichte van hetobject waardoor achtergrondpixels met eenzelfde kleurendistribu e in het venster kunnen verschijnen die hetalgoritme op een zijspoor brengen. Omgekeerd zal het zoekvenster te klein zijn als het object de camera nadert.Aangezien er slechts een klein deel van het object in het zoekvenster aanwezig is, kan het algoritme mogelijksconvergeren naar een vals lokaal maximum.

Dit probleem wordt duidelijk gemaakt in figuur 2.6. In de figuur zijn twee lokale maxima te zien van de back pro-jec on. Convergen e betekent dat de hoogste piek bereikt is. Als het zoekvenster te klein is, kan het algoritmeconvergeren naar de kleinste piek. Het algoritme zit vervolgens vast in vals lokaal maximum. De ini ële loca-e van het zoekvenster is voor de volgende videoframes niet meer op maal waardoor het algoritme het object

uiteindelijk zal kwijtspelen.

Figuur 2.6: Meanshi probabiliteitsdistribu e

Het Camshi algoritme omzeilt de opgesomde problemen door een zoekvenster te retourneren waarvan de af-me ngen zich dynamisch aanpassen aan de groo e van het object. Het Camshi algoritme is bovendien in staatom een hoek te berekenen die de rich ng van het object aangee . De formules zijn te vinden in [9].

Het Camshi algoritme is robuust en efficiënt maar hee een aantal belangrijke tekortkomingen:

13

• Manuele ini alisa e door een rechthoek te trekken rond het object. Dit is eventueel te verbeteren met eenbijkomende detec e algoritme zoals achtergrondsubtrac e of SURF/SIFT.

• Eenmaal het object verloren is, is er geen herstel mogelijk. Eventueel aanvullen met een bijkomende de-tec e algoritme zoals een Kalman filter.

• Een klein object met hoge snelheid is moeilijk te volgen.

• Eenmaal het kleur histogram bepaald is, kan het niet meer aangepast worden. Een object moet bijgevolgvanuit verschillende perspec even een homogene kleurendistribu e bezi en.

Om af te sluiten is het interessant om te vermelden dat het histogram mul dimensionaal kan zijn. Dit betekentdat het algoritme niet noodzakelijker wijze beperkt is tot één dimensie (bijvoorbeeld de hue waarde). Er bestaantegenwoordig applica es gebaseerd op het camshi algoritme die naast kleur bijkomende features zoals textuurin het algoritme incorporeren en indrukwekkende resultaten boeken [10].

2.4.2 Achtergrondsubtrac e

Achtergrondsubtrac e begint met een model van de achtergrond. Elke afwijking in het beeld ten opzichte van deachtergrond bakent één of meerdere deelgebieden af. Deze deelgebieden vormen de voorgrond en stellen de tedetecteren objecten voor. Het resultaat is een binair beeld waarbij de voorgrond bestaat uit wi e pixels en deachtergrond uit zwarte pixels. Dit proces wordt beschreven als de segmenta e van het beeld waaruit een aantalblobs resulteren. De eenvoudigste vorm van segmenta e is drempelen. Uitgaande van een drempelwaardewordteen pixel als voorgrond of achtergrond geclassificeerd (figuur 2.7).

Figuur 2.7: Binaire output achtergrondsubtrac e

Hoewel het achterliggende principe triviaal is, is de implementa e van een gepast achtergrondmodel niet evident.De achtergrond is zelden sta sch van aard omdat het onderhevig is aan wisselende invloeden zoals fluctua es inlichtomgeving, schaduwen, bewegende achtergrond,… Indien de achtergrond teveel afwijkt van het gememori-seerde model kunnen allerlei elementen van de achtergrond als voorgrondobject gedetecteerd worden.

Om het probleem van wisselende invloeden op te vangen worden dynamische achtergrondmodellen toegepast.Dit betekent dat het achtergrondmodel in staat is om zich aan te passen aan de wisselende invloeden. Een bij-komend voordeel van de dynamische achtergrondmodellen is dat er geen ini alisa e hoe te gebeuren van deachtergrond. Het nadeel is dat s lstaande objecten na verloop van jd in de achtergrond opgenomen worden.Indien het gewenst is om deze objecten bij te houden moet het algoritme aangevuld worden met post-processinglogica.

14

Achtergrondsubtrac e met dynamische modellen wordt gekenmerkt door een aantal stappen [11] die weergege-ven zijn in figuur 2.8. De stappen pre-processing en post-processing hoeven niet noodzakelijk geïmplementeerdte worden.

Figuur 2.8: Stepflow achtergrondsubtrac e

• Pre-processing slaat op voorbewerkingstechnieken zoals het filteren van ruis.

• De technieken van achtergrondmodellering kunnen in twee groepen onderverdeeld worden [11]:

– Niet-recursieve technieken slaan de meest recente frames op in een buffer van vaste groo e. Opdeze manier wordt er voor elke pixel een jdshistoriek bijgehouden waarmee het achtergrondmodelopgebouwd wordt:

Bt(x, y) = F (It−1(x, y), ..., It−n(x, y)) (2.4)

met

Bt(x, y) = Achtergrondmodel van pixel(x,y) op jds p t

It−n(x, y) = Waarde van pixel(x,y) op jds p t-n

De func eF in formule 2.4 kent een verschillende invulling naargelang de gebruiktemethodologie. Debekendste zijn de Frame Differencing, de Median Filter en de Linear Predic ve Filter. Het nadeel vanniet-recursieve technieken is de geheugenruimte die voorzienmoet worden omde frames te bufferen.Hoe kleiner de buffer, hoe sneller het model zich aanpast aan nieuwe omstandigheden. Anderzijdsmoet de buffer voldoende groot zijn om te voorkomen dat traag bewegende objecten te snel in deachtergrond opgenomen worden.

– Recursieve technieken houden geen buffer bij van voorgaande frames. Elke nieuwe input frame zorgtvoor een recursieve update van het achtergrondmodel. Hierdoor kunnen frames uit een ver verle-den nog steeds invloed uitoefenen op het achtergrondmodel. De meeste methoden maken echtergebruik van weegcoëfficiënten gekoppeld aan nega eve exponen ële func es om de invloed van ou-dere frames te beperken. De bekendste recursieve technieken zijn de Kalman filter en de Mixture ofGaussians (MoG). De MoG speelt een belangrijke rol in het verdere verloop van deze masterproef enwordt verder in deze sec e meer in detail besproken.

• Post-processing wordt toegepast om fouten in de binaire segmenta e op te vangen:

– Wegwerken van fout-posi even en fout-nega even doormorfologische bewerkingen zoals het dichtenvan gaten of het openen van objecten (figuur 2.9). Fout-posi even zijn gedetecteerde voorgrondpixelsdie eigenlijk tot de achtergrond behoren en fout-nega even zijn gedetecteerde achtergrondpixels dietot de voorgrond behoren.

15

Figuur 2.9: Morfologische bewerkingen openen en dichten

– Ruis filteren met een mediaan- of gaussfilter.

– Schaduw verwijderen door post-processing algoritmes zoals Cucchiara [12].

Het principe van de MoG kreeg stevige voet aan de grond dankzij het werk van Stauffer en Grimson [13]. Hethoofdprincipe is om elke pixel in het beeld te beschrijven als een som van gaussverdelingen. De achterliggenderedeneringwordt toegelicht aan de hand van figuur 2.10. Een pixel gelegen aan hetwateroppervlaktewordt onderde loep genomen. De pixelwaarde van het rode en groene kanaal in de RGB kleurenruimte, wordt over meerdereframes geregistreerd en uitgezet in het diagram. Door het rimpeleffect van het water ontstaan er twee clusters inhet jdsdiagram. Elke cluster kan voorgesteld worden als een gaussverdeling met een gemiddelde waarde en eenvarian e.

Figuur 2.10: Toelich ng van MoG

In het voorbeeld is het duidelijk dat de achtergrond niet met één enkele verdeling gemodelleerd kan worden. Xt

stelt de RGB waarde voor van een pixel op jds p t. De kans omXt waar te nemen, wordt gemodelleerd als eensom van gaussverdelingen:

P (Xt) =K∑i=1

ωi,t ∗ η(Xt;µi,t, σ2i I) (2.5)

met

ωi,t = weegcoëfficiënt van de ide gaussverdeling op jds p t

η(Xt;µi,t, σ2i I) = i

de gaussverdeling

µi,t = gemiddelde van de ide gaussverdeling op jds p t

σ2i I = covarian ematrix van de ide gaussverdeling op jds p t

Elke verdeling krijgt een weegcoëfficiënt ωi,t toegewezen om het belang van de verdeling aan te duiden. Hoegroter ωi,t, hoe groter de kans dat de pixel door deze verdeling wordt voorgesteld. De covarian ematrix wordtgelijkgesteld aan σ2

i I (éénheidsmatrix x varian e). Dit impliceert onderlinge ona ankelijkheid van de kleurka-nalen en dezelfde varian e voor alle kleurkanalen. Hoewel dit in de werkelijkheid niet het geval is, wordt deze

16

veronderstelling aangenomen om de computa onele efficiën e te bevorderen. Het aantal verdelingenK wordtwillekeurig gekozen, meestal tussen 3 en 5.

Als er een nieuwe frame verwerkt wordt, zal elke pixelwaardeXt getoetst worden aan de bijhorende verdelingen.Er wordt een overeenkomst gevonden met een verdeling als (Xt − µi,t−1) ≤ 2.5σi. In dit geval worden deweegcoëfficiënten van de verdelingen horende bijXt aangepast volgens:

ωi,t = (1− α)ωi,t−1 + α(Mi,t) (2.6)

α is de update coëfficiënt. Voor de verdeling waarmee een overeenkomst gevonden is, wordtMi,t = 1waardoorde weegcoëfficiënt van de verdeling toeneemt en voor de andere verdelingen wordtMi,t = 0waardoor de weeg-coëfficiënt voor deze verdelingen afneemt. Indien geen enkele van deK verdelingen een overeenkomst toontmetXt, wordt de verdeling met de laagste weegcoëfficiënt vervangen door een nieuwe verdeling met µi,t = Xt. Denieuwe verdeling wordt ingevoerd met een grote varian e en een kleine weegcoëfficiënt.

De volgende stap is om de parameters van de distribu es waarvoor een overeenkomst gevonden is, aan te passenvolgens:

µt = (1− ρ)µt−1 + ρXt (2.7)

σ2t = (1− ρ)σ2

t−1 + ρ(Xt − µt)T (Xt − µt)

met

ρ = αη(Xt|µi, σi)

= leerfactor

De distribu es van het model liggen dus niet vast en de informa e die een nieuwe pixelwaarde bevat, wordtbenut omhetmodel te updaten. Op dezemanierworden trage omgevingsveranderingen in het achtergrondmodelopgevangen [14]. De leerfactor in formule 2.7 speelt een belangrijke rol om de snelheid aan te passen waarmeehet achtergrondmodel geüpdatet wordt.

Tot zover is er een model opgebouwd met een vast aantal verdelingen die geüpdatet worden indien er een over-eenkomst gevonden is met de nieuwe pixelwaarde Xt of uiteindelijk vervangen worden indien ze niet meer bij-dragen tot het model. Het model zal naast de achtergrond mogelijks ook voorgrond objecten beva en. De vraagis welke verdelingen de achtergrond voorstellen en welke de voorgrond. Een pixel waarvan de waarde Xt overeen rela ef grote jdsverloop weinig schommelt, zal aanleiding geven tot een distribu e met een grote weeg-coëfficiënt en een lage varian e waardoor de ra o µ/σ groot zal zijn. Het is intuï ef aan te voelen dat het stabielekarakter van deze verdeling eerder een achtergrondpixel voorstelt dan een pixel van een bewegende object op devoorgrond. Op basis van dit principe, worden de verdelingen gesorteerd volgens aflopende µ/σ ra o's en wordter een drempelwaarde T bepaald. De eersteB verdelingen worden gekozen als achtergrond en de overblijvendeverdelingen als voorgrond.

B = argminb(b∑

k=1

ωk > T ) (2.8)

Op deze manier gebeurt de classifica e van een pixel. Als een nieuwe pixel een overeenkomst hee met eenachtergronddistribu e wordt het als achtergrondpixel geclasseerd en vice versa.

Hoewel het werk van Stauffer en Grimson aanzien wordt als een doorbraak, hee het originele model een aantaltekortkomingen. De grootste tekortkomingen zijn de ini alisa e van het model, de onderliggende assump e vangaussverdelingen, het gebruik van RGB waarden die in grote mate gecorreleerd zijn, de bepaling van de leerfactoren het vaste aantal distribu es per pixel. Voornamelijk het laatste punt kan leiden tot teveel fout-posi evenen fout-nega even. Dikwijls kan het voldoende zijn om de achtergrond van een pixel te beschrijven met éénverdeling. Door bijkomende verdelingen nu eloos op te leggen, kan een pixel in de staart van een verdeling

17

(met een afstand ≥ 2.5σi) toegeschreven worden aan een andere verdeling die zich nauw in de buurt bevindt.Bovendien zorgen de overbodige distribu es ervoor dat de computa onele rekenkracht niet efficiënt benutwordt.

Een oplossing voor het probleem van vaste distribu es wordt gegeven door Zivkovic [15]. Zivkovic stelt een onlinealgoritme voor die een scha ng maakt van de parameters van de MoG. Het aantal gaussverdelingen per pixelwordt geselecteerd op basis van een Dirichlet prior. Binnen een jdsinterval T wordt er voor elke distribu e bij-gehouden hoeveel keer de distribu e aangepast geweest is. Distribu es die weinig worden aangepast gedurendehet jdsinterval worden verondersteld geen bijdrage te leveren en worden uit het model gefilterd zonder vervan-gen te worden. Dit leidt tot een verbeterde detec e van voorgrond- en achtergrondpixels. Deze resultaten zijnbeves gd in het werk van Brutzer [12].

2.4.3 Karakteris eke beschrijving van punten

Dezemethode is gebaseerd op uitgesproken features in het beeld. Het algoritme doorloopt verschillende stappen[16]:

• Er wordt eerst een beeld genomen van het te detecteren object en het algoritme gaat op zoek naar karak-teris eke punten in het beeld. Dit zijn punten met een unieke geometrie.

• Vervolgens wordt er voor alle karakteris eke punten een karakteris eke beschrijving opgemaakt die dedescriptor genoemd wordt. De descriptor bestaat uit 128 bytes die het punt en zijn context coderen.

• Na het leerproces van de eerste twee stappen kan het object worden gezocht in een beeld met een achter-grond. Alle pixels in het beeld worden overlopen en vergeleken met de karakteris eke beschrijvingen.

• De zoekac e levert een aantal corresponden es tussen punten in het beeld en punten van het object. Eenobject wordt herkend als er voldoende punten gevonden zijn en als de onderlinge posi es van de puntenovereenkomt. In figuur 2.11 wordt het resultaat getoond van een geslaagde objectdetec e.

Figuur 2.11: Objectdetec e SURF

De twee bekendste toepassingen zijn de Scale-invariant feature transform (SIFT) en de Speeded Up Robust Featu-res (SURF). Ze verschillen in de karakteris eke punten en beschrijvingen die ze uit het beeld halen, maar verlopengrotendeels iden ek. Uit testen blijkt dat SURF duidelijk sneller is maarminder robuust dan SIFT. Het voordeel vandeze aanpak is invarian e voor belich ng, schaal en standpunt van de camera. Bovendien is het leerproces be-perkt want er is slechts één beeld nodig van het object. Het nadeel is dat er voldoende punten gevonden moetenworden. Kleine objecten zullen via deze methoden moeilijk gedetecteerd worden.

18

2.5 Augmented Reality

2.5.1 Defini e Augmented Reality

Het doel van Augmented Reality (AR) is om de menselijke percep e van de werkelijke wereld te verrijken met vir-tuele elementen die ogenschijnlijk co-existeren in de reële omgeving. De virtuele objecten verschaffen informa edie de gebruiker niet rechtstreeks kanwaarnemenmet zijn zintuigen. De informa e is bestemd omde gebruiker teassisteren in het uitvoeren van taken in de reële wereld. Een AR toepassing voldoet aan de kenmerken vastgelegddoor Azuma [17]:

• Combina e van reële en virtuele elementen in een reële omgeving.

• Interac ef in real- me.

• Percep e in 3D.

In de probleemstelling (punt 1.2) werd het Reality-Virtuality-con nuüm geïntroduceerd. De defini e van Azuma[17] omvat dus enkel toepassingen aan de linkerkant van het spectrum.

2.5.2 Hardware

De hardware bestaat uit 3 basiscomponenten:

• De camera die de werkelijkheid registreert. De camera kan enerzijds sta sch opgesteld zijn zoals in de laboopstelling. Bij mobiele toepassingen verplaatst de gebruiker zich in de omgeving met de camera. Mobieletoepassingen gebeuren typisch met een smartphone, tablet of een camera gemonteerd op een hoofdbe-ves ging.

• De display is de gebruikersinterface en presenteert het eindresultaat. De display vervult een belangrijke rolin de AR belevenis van de gebruiker. De AR belevenis zal uiteindelijk bepalen of de gebruiker het systeemaccepteert of verwerpt. Displays worden in de literatuur in twee categorieën onderbracht:

– Video displays: Schermen zoals een monitor of een tablet. Google is met Project Tango volop bezigmet de ontwikkeling van de volgende genera e tablets [18]. Via de integra e van een 3D cameraworden nieuwe mogelijkheden van AR voor mobiele toepassingen geopend.

– Op cal see-through displays: De gebruiker hee een rechtstreekse kijk op dewerkelijkheid. Voorbeel-den zijn de Google Glass [19] of het vizier van een straaljagerpiloot. Op sche technieken zorgen vooreen projec e van de virtuele elementen op de display. Dit hee een aantal voordelen:

* De toepassing is ontlast van de weergave van de video stream.

* Op gebied van resolu e kan geen enkel scherm de resolu e van het menselijk oog evenaren.

* Bij het uitvallen van het systeem, kan de gebruiker de werkelijkheid nog steeds waarnemen.

• Een processoreenheid die computa onele taken kan uitvoeren.

De hardware is een belangrijke factor in de kwaliteit van het AR resultaat en de evolu e van de hardware zal eenbelangrijke rol spelen in de ontwikkeling en verspreiding van AR applica es. Figuur 2.12 toont de evolu e van dehardware. De impact op het gebruiksgemak hoe weinig uitleg.

19

Figuur 2.12: Hardware evolu e

2.5.3 Het Augmented Reality proces

Alle AR systemen hebben een gemeenschappelijke onderbouwing [20] zoals weergegeven in figuur 2.13.

Figuur 2.13: Schema AR

De input bestaat uit camerabeelden eventueel gecombineerd met aanvullende sensor informa e. Sensoren wor-den soms ingezet om het traceerproces in de volgende stap te ondersteunen. Deze sensoren kunnen uit ver-schillende technologieën voortkomen zoals [21]: Global Posi oning System (GPS), Radio-Frequency Iden fica-on (RFID), … Meer en meer wordt er afgestapt van dergelijke sensoren omdat de complexiteit van het systeem

verhoogt, de investeringskosten toenemen, de herbruikbaarheid in bepaalde gevallen beperkt is en de nauwkeu-righeid dikwijls niet voldoet aan de posi e vereisten opgelegd in het traceerproces. Het virtueel model is nodigals input van de render-module.

Het traceren is het belangrijkste proces in de AR verwerking. Deze stap wordt in de literatuur soms vermeld als'Registra on' of 'Pose Es ma on'. Het betre het aligneren van de virtuele elementen op de reële objecten [17].Deze stap vormt de grootste uitdaging en is momenteel de beperkende factor voor de ontwikkeling van AR ap-plica es. De input van deze stap zijn zoals vermeld camerabeelden. De beelden worden met visie techniekenverwerkt om de omgeving te interpreteren en om de posi e en de oriënta e van de camera in het wereldcoör-dinatenstelsel te bepalen. De technieken die van toepassing zijn, steunen op dezelfde principes als besprokenin punt 2.2, 2.3 en 2.4. De verworven inzichten in de opgenoemde punten, helpen om de uitdagingen van hettraceerproces beter in te scha en. Het traceerproces kan op twee manieren gebeuren [22]:

• Met markers: Het detecteren van markers gebeurt dikwijls via een contour analyse. De contour analysehaalt randen features uit het beeld die vervolgens geanalyseerdworden. Door de vervorming van demarkeren de posi e van bepaalde elementen in de marker kan de posi e ten opzichte van de camera bepaaldworden en kan het 3D wereldcoördinatenstelsel opgebouwd worden. Het principe van markerdetec e enoriënta e wordt geïllustreerd in 2.14:

20

Figuur 2.14: Marker

• Zonder marker. Dit proces gaat onvermijdelijk gepaard met een leerproces. Het leerproces kan bestaan uithet trekken van foto's van de omgeving en om ze vervolgens in een bibliotheek onder te brengen. De came-rabeelden worden getoetst aan deze bibliotheek om de omgeving te herkennen. Methodes die hiervoor inaanmerking komen zijn SIFT/SURF zoals besproken in 2.4.3. Het nadeel van SURF en SIFT is dat de ze reedsmoeilijk real- me te implementeren zijn zonder een bibliotheek te moeten raadplegen.

Tot nu toe is ervan uitgegaan dat de camerabeelden in 2D zijn. Een 3D wereld opbouwen vanaf een 2Dperspec ef brengt beperkingen met zich mee (zie punt 2.2). De laatste jaren zijn toestellen op de marktverschenen die uitgerust zijnmet een diepte camera om3Dbeelden op te nemen, zoals de KINECT. Hetzelfdeeffect kan bekomen wordenmet stereoscopie technieken gebaseerd op twee 2D camera's. De input van 3Dbeelden opent nieuwe mogelijkheden op het gebied van visie technieken zoals de puntenwolken analyse.De puntenwolken analyse laat toe om de vorm van een 3D object te herkennen. Dit zal in de toekomstongetwijfeld leiden tot een efficiëntere herkenning van de omgeving en de intensievere integra e van 3DComputer Aided Design (CAD) modellen [23].

De moeilijkheid van het traceerproces is gelinkt aan de strenge eisen die aan de beeldanalyse opgelegd worden.Als gevolg kunnen verschillende fouten ontstaan die onderverdeeld worden in systema sche en dynamische fou-ten. De sta sche fouten vloeien deels uit de camera eigenschappen maar voornamelijk uit de nauwkeurigheids-vereisten van de posi ebepaling die niet gehaald worden. Een kleine afwijking in posi e zorgt voor een verkeerdealignering van het virtuele element waardoor het AR systeem kan falen. De dynamische fouten slaan eerder opde real- me eisen die door het systeem niet gehaald worden. Voor een gedetailleerde opsomming van de foutenwordt verwezen naar de literatuur [17].

Eenmaal het traceren uitgevoerd is, kunnen de virtuele elementen in het beeld geposi oneerd worden. Het ren-deren is het genereren van het virtueel element uit eenmodel. Het model bevat informa e over de geometrie, debelich ng, de schaduw en de eigenschappen van de objecten. In figuur 2.13 is bij de render-module 'tekstannota-e' vermeld wat op zich weinig te maken hee met het renderen van virtuele elementen in 3D. Hiermee wordt er

aangegeven dat het primaire doel van een AR applica e bestaat uit informa everrijking die nu g is voor de eind-gebruiker. In bepaalde gevallen is er geen enkele posi e informa e vereist om dit doel te bereiken (bijvoorbeeldhet melden van de luchtvoch gheidsgraad aan de gebruiker). In andere gevallen moeten bepaalde elementen inhet beeld gedetecteerd worden zonder dat de noodzaak bestaat om het virtuele element correct te aligneren in3D (bijvoorbeeld het omcirkelen van een bout op een werkstuk). Door deze stelling aan te nemen, wordt er deelsafgestapt van de strikte defini e in punt 2.5.1.

2.5.4 Industrial Augmented Reality (IAR)

Deze sec e hee tot doel om de opportuniteiten van AR in de industrie te bekijken. Om zich een idee te vormenvan het nut van AR toepassingen worden een aantal concepten besproken die in de literatuur verschenen zijn. Bij

21

de bespreking wordt er op zoek gegaan naar toepassingen die een aanvulling kunnen geven aan SCADA toepas-singen. Dit zijn AR concepten die betrokken zijn bij het monitoren van processen en het weergeven van produc einforma e. Aansluitend op deze bespreking wordt er bekeken in hoever AR doorgedrongen is in het bedrijfsleven.Tenslo e worden een aantal conclusies getrokken.

Vooraleer AR specifiek binnen de industrie te bekijken, wordt er s lgestaan bij de domeinen waarin AR het meestvernoemd wordt. Azuma [17] definieerde een aantal toepassingsdomeinen voor AR waaronder de medische sec-tor, de industrie, entertainment en militaire applica es. In een vervolgstudie [24] werden twee domeinen toege-voegd: mobiele AR en collabora eve AR. De meeste ontwikkeling wordt toegepast in de medische sector.

De term IAR slaat op AR concepten of toepassingen die specifiek ontwikkeld zijn vanuit de behoe en in de in-dustrie. Een recente studie gerealiseerd door Fite-Georgel schetst een totaalbeeld van de huidige toestand vanIAR [25]. De auteur ging op zoek naar alle wetenschappelijke publica es omtrent het onderwerp gaande van con-cepten tot prototypes tot uiteindelijke realisa es en stelde de vraag welke concepten effec ef uitgegroeid zijn totvolwassen applica es. Er worden concepten besproken uit elke fase van de productlevenscyclus:

ProductontwerpAR kan op tal van vlakken ingezet worden jdens het productontwerp. Een eerste voorstel betre een toepas-sing in de auto industrie. Het instrumentenbord van een wagen moet zodanig ontworpen zijn dat de gebruikeralle instrumenten vlot kan bedienen. Om het instrumentenbord te op maliseren en te valideren kan het als eenvirtueel element geposi oneerd worden in dat geraamte van een wagen. Een ander voorbeeld is het gebruik vanAR om te verifiëren dat een vervaardigd stuk niet afwijkt van het CAD model. AR kan ook ingezet worden om deefficiën e van een productontwerp te beoordelen. Zo kunnen luchtstromen geproduceerd door het ven la esys-teem in een vliegtuigcabine gevisualiseerd worden als AR en kan het ontwerp aangepast worden voor een grotercomfort van de passagiers.

Produc eIn het kader van deze masterproef is produc e het belangrijkste punt. AR kan ondersteuning bieden bij de assem-blage, bij het uitvoeren van delicate produc e stappen of bij de training van operatoren.

Een eerste toepassing illustreert de voordelen van AR bij de assemblage in de bouwsector. Bij de opbouw vanelektrische installa es worden soms schuimborden op ware groo e gebruikt. De schuimborden zijn voorzien vangroeven die als een kaart dienen om de kabels te groeperen tot kabelbundels. Het idee bestond erin de schuim-borden te vervangen door een AR applica e om zo de kost van de fabricage en de stockage van de schuimbordente elimineren. De toepassing slaagde in het opzet en hielp bovendien om de assemblage op een snelleremanier telaten verlopen. Een ander voorbeeld is terug te vinden in de logis ek als pick-by-vision. Bij manuele order pickingkrijgt de operator een picklijst met informa e over het aantal te picken producten en de pickloca es. Pick-by-vision voorziet deze informa e op een brilglas waardoor het zoekwerk in de rekken uitgespaard wordt. Idealiterkrijgt de operator informa e over het kortste traject om de pickopdracht uit te voeren [26]. Het vervangen vanassemblage richtlijnen op papier door AR toepassingen zou veralgemeend kunnenworden naar ander assemblagetaken. De meeste voordelen kunnen gehaald worden waar er een hoge graad van productdifferen a e aanwezigis. De voordelen zouden zich vertalen in jdswinst en een verlaagd foutenpercentage.

Bij kri sche produc eprocessen is het gebruikelijk dat sommige parameters zoals toerental, krachten en tempe-ratuur nauwle end opgevolgd moeten worden om niet buiten de opgelegde marges te vallen. Tegelijker jd is hetbest mogelijk dat de aandacht van de operator op andere handelingen gericht is. Een duidelijk voorbeeld waarbijAR ondersteuning kan bieden, is het lasproces. Het lasproces wordt door de lasser niet meer gezien doorheeneen donkere vizier maar wordt opgenomen door een camera. Het beeld wordt aangevuld met informa e om-trent bepaalde lasparameters zoals spanning en stroom. De lasser kan zich volop richten op het lassen en kan deparameters in één oogopslag verifiëren. Dit biedt bovendien de mogelijkheid om het proces op te slaan. In het

22

geval van een perfecte las kan het proces opnieuw gevisualiseerd worden met alle parameters die van toepassingwaren. Dit is een ideale leerbasis om een nieuwe operator te trainen.

Het aangehaalde voorbeeld is het concept dat het meest leunt bij de SCADA toepassingen. De operator kan hetproces real- me monitoren terwijl hij de werkelijkheid niet uit het oog verliest. 'Corporate Siemens Research'is bijzonder ac ef op het vlak van IAR. Overlay van real- me procesparameters voor controle en monitoring vangeautoma seerde systemen behoort tot de hoofddoelstellingen van het onderzoek van Siemens [23]. Tot opheden zijn er echter nog geen echte ontwikkelingen gerealiseerd.

CommissioningNa de produc e en vóór de ingebruikname moet het product geverifieerd en gedocumenteerd worden. Dezestap in de productlevenscyclus wordt commissioning genoemd. De voorbeelden die in de literatuur in deze stapvernoemdworden zijn bijzonder specifiek en bieden geen nieuwe inzichten op. De bespreking van deze stapwordtachterwege gelaten.

Onderhoud en herstelDe principes die hier van toepassing zijn, vertonen veel gelijkenissen met de methodes in de assemblage stap. Detechniekerwordt stap voor stap begeleid doorheen de onderhoudsprocedure. Figuur 2.15 toont een aantal framesuit de onderhoudsprocedure van een printer [27]. Het belang van het traceerproces om de virtuele elementencorrect te aligneren zoals besproken in 2.5.3 komt duidelijk naar voren.

Figuur 2.15: Gescha e inkomsten van AR in mobiele applica es

In het kader van onderhoud en herstel kan de interven e van een technieker op afstand vereenvoudigd wordenmet behulp van AR technieken. Dringende interven es gebeuren dikwijls telefonisch waarbij de operator terplaatste de instruc es van de technieker moet uitvoeren. Problemen die kunnen optreden zijn een onduidelijkeprobleemomschrijving van de operator of het meedelen van instruc es die de operator niet begrijpt. AR kansoelaas bieden met behulp van een video feed waarbij de technieker informa e op het scherm kan aanbrengen.Dit wordt weergegeven in figuur 2.16. De annota e blij correct geposi oneerd als de operator zich verplaatst.Het samenwerken van personen door middel van AR wordt aangeduid met de engelse term collabora ve AR.

23

Figuur 2.16: Remote maintenance mbv augmented reality

De opgesomde concepten geven een idee van de opportuniteiten gekoppeld aan IAR en de pistes die in de vol-gende jaren gevolgd zullen worden. Hierbovenwerden een aantal voorbeelden geselecteerd die de kernideeën zogoedmogelijk weergeven. In het vervolg van de studie [25] wordt op basis van een brede lijst concepten nagegaanin welke ontwikkelingsfase ze zich bevinden. De toewijzing van een concept in een bepaalde categorie gebeurt opbasis van verschillende criteria:

• Workflow integra e: De mate waarin het concept in een industriële workflow geïntegreerd kan worden.

• Herbruikbaarheid: Dematewaarin het concept in andere toepassingen gebruikt kanworden dan dezewaar-voor het oorspronkelijk ontwikkeld is.

• Kosten baten analyse: De vraag of de invoer van een AR applica e een financieel voordeel biedt.

• Betrokkenheid van de industrie: Er wordt gekeken of de vraag naar een applica e vanuit de industrie komt.

• 'Out of the lab': De vraag of het concept in een reële situa e getest geweest is of enkel in een laboratoriumomgeving.

Het resultaat van de studie is afgebeeld in figuur 2.17. De conclusie is duidelijk, IAR staat in zijn kinderschoenen.Een kleine meerderheid van de projecten zijn gestart vanuit de vraag van de industrie. Een kosten baten analysegebeurt slechts in 25% van de projecten wat nogmaals aanwijst dat het voornamelijk gaat over proofs of concept.Bovendien is het herbruikbaarheidscriterium in andere omgevingen bijna nihil en een groot deel van de conceptenworden of kunnen niet in reële situa es toegepast worden. Hoewel er duidelijke opportuniteiten weggelegdzijn voor IAR, moeten een aantal technologische uitdagingen opgelost worden vooraleer IAR wortel krijgt op deproduc evloer.

Figuur 2.17: Overzicht van de toestanden van IAR applica es

24

3 Uitgevoerde werk en resultaten

3.1 Overzicht van het uitgevoerde werk

Figuur 3.1 dient als leidraad voor de bespreking van het uitgevoerde werk. De figuur is de invulling en uitbrei-ding van het principeschema dat in de doelstellingen geïntroduceerd werd (figuur 1.3 in punt 1.3). De informa estromen, voorgesteld door groene pijlen, zijn gebaseerd op het Automa on Device Specifica on (ADS) protocolen garanderen een real- me gedrag. De gele stromen zijn gebaseerd op Transmission Control Protocol/InternetProtocol (TCP/IP) en bezi en geen determinis sch karakter. In sec es 3.2 tot 3.5 wordt het uitgevoerde werk metbetrekking op de verschillende de onderdelen in figuur 3.1 in detail toegelicht.

Figuur 3.1: De onderdelen van het uitgevoerde werk

3.2 De opstelling

3.2.1 De Beckhoff Industrial Personal Computer (iPC)

De so PLC

De besturing van de opstelling gebeurt met een iPC CX2020 van Beckhoff. Beckhoff implementeert automa se-ringssystemen gebaseerd op PC-compa bele besturingstechnologie. De klassieke hardware PLC is vervangen dooreen so PLC geïntegreerd in de TwinCAT automa seringsso ware. Een PLC werkt cyclisch: de ingangen wordeneerst ingelezen, vervolgens wordt het programma uitgevoerd en als laatste worden de uitgangen aangestuurd.Het uitvoeren van de programma's in een so PLC gebeurt iden ek. Real me taken kunnen worden toegewezenaan verschillende cores met eigen cyclus jden [28].

Versie 3 van TwinCAT is volledig geïntegreerd in één ontwikkelomgeving, namelijk Microso Visual Studio. Hetintegra econcept is weergegeven in figuur 3.2. De System Manager behandelt:

• De configura e van de so PLC en rechtstreeks aangesloten I/O kaarten. Er kunnen tot 4 so PLC's op 1 iPCdraaien.

• De integra e van veldbussen. Er bestaan buskoppelmodules voor diverse veldbussen zoals Profibus, Can-Open, Modbus, RS 485,...

25

• De configura e van Numeric Control (NC) voor de besturing van meerassige posi oneertoepassingen.

Wat betre de programmeeromgeving kunnen Beckhoff controllers geprogrammeerd worden overeenkoms gde IEC 61131-3 programmeerstandaard in talen zoals Structured Text, Ladder Logic Diagram,.. De TwinCAT auto-ma seringsso ware laat bovendien toe om real- me applica es te schrijven in C/C++. Hiervoor zijn uitgebreidebibliotheken beschikbaar. Niet real- me applica es die met de PLC communiceren kunnen in de solu on geïnte-greerd worden. Dergelijke applica es kunnen geschreven worden in C#/.NET.

Figuur 3.2: eXtended Automa on Engineering

Real- me so ware modules, zoals een PLC of NC controller, worden geladen in de TwinCAT 3 Run me omgeving.In de run me wordt er voor elke ingeladen so ware module een run me module gecreëerd. De transportlaagdie de communica e realiseert tussen deze modules, is gebaseerd op het ADS protocol. ADS verscha real- metoegang tot I/O data. De ADS architectuur steunt op het client/server principe. Een run me module wordt in-gesteld als server. Clients kunnen vervolgens een verbinding opze en met de server en toegang krijgen tot degegevens. Het ADS verkeer wordt door de Message Router op de iPC afgehandeld. Een voordeel van ADS is datremote applica es zich als client kunnen aanmelden en dus toegang hebben tot I/O gegevens. Beckhoff stelt bibli-otheken ter beschikking om ADS func es, zoals het lezen en schrijven van I/O gegevens, in een externe applica ete implementeren. Een remote applica e kan via een ethernet netwerk verbinden met een server omdat het ADSprotocol voortbouwt op het TCP/IP protocol.

ADS zal in de TCP/IP dataframe een eigen header plaatsen. De twee belangrijkste velden van de header zijn hetAdsAmsNetId waarmee een device binnen het ADS netwerk geïden ficeerd kan worden en het ADS-poortadreswaarmee een Run me module op de iPC benaderd kan worden. Voor de eerste PLC run me module in TwinCAT3 is dit poortadres 851. Het laatste element dat nodig is om een specifieke input of output te benaderen, iseen symboolnaam. Symboolnamen worden gedefinieerd in de globale variabelenlijst horende bij de so PLC.Vervolgens worden de symbolen gelinkt aan de register adressen van de fysische inputs en outputs. De situeringin Visual Studio van besproken punten zoals de system manager en het ADS adres, wordt geïllustreerd in figuur3.3.

Voor een volledig overzicht van de configura e, wordt verwezen naar de TwinCAT solu on in de bijlagen. Om afte sluiten, is het belangrijk te vermelden dat er geen logica geïmplementeerd is in de so PLC. Een task wordtaangemaakt in de systemmanager om de so PLC als master in te stellen op het netwerk. Demaster is nodig voorhet pollen van de veldbussen waarop de I/O aangesloten zijn. Het programma gelinkt aan de task is leeg omdatalle logica in het LES geïmplementeerd is.

26

Figuur 3.3: De TwinCAT omgeving in Visual Studio

De veldbussen en I/O

In figuur 3.4 wordt een schema sch overzicht gegeven van de veldbus aanslui ngen. De induc eve sensorenworden bekabeld op I/O kaarten in een aparte schakelkast. Deze I/O kaarten worden aangesloten op een EK1100EtherCAT buskoppelmodule die de verbinding maakt met de iPC. De perslucht cilinders van de spoorwissels zijngekoppeld op ven eleilanden van Festo.

De opstelling in het labo was in september nog deels in opbouw. Een groot deel van de bekabeling van zowel desensoren als van de wissels, moest nog gebeuren. De aanslui ng van de ven eleilanden op Profibus hee redelijkwat diagnose gevraagd. Uiteindelijk bleek een eiland defect te zijn waardoor niet alle wissels bedienbaar zijn.

Figuur 3.4: Veldbussen en I/O aanslui ng

De configura e van de veldbussen in TwinCAT is rela ef éénvoudig. Met een rechtermuisknopklik op de I/O tag inde boomstructuur (figuur 3.3), is een func e beschikbaar voor het scannen van het netwerk. Aangezien EtherCATde veldbus is van Beckhoff, zijn er uitgebreide bibliotheken geïnstalleerd in TwinCAT waardoor de EtherCAT bus-koppelmodule automa sch herkend wordt. Voor de Festo eilanden moet een General Sta on Descrip on (GSD)bestand op website van festo afgehaald worden. Door het GSD bestand in TwinCAT te laden, worden de profielenvan het toestel beschikbaar. Meer details omtrent de configura e van de veldbussen kan in de TwinCAT solu onin de bijlagen gevonden worden.

27

3.2.2 Microcontroller

De LEGO treinen worden aangedreven door een ingebouwde elektrische motor op ba erijen en zijn uitgerustmet een infrarood ontvanger. De meegeleverde afstandsbediening zorgt voor de snelheidssturing van de treinenin discrete stappen. De uitdaging bestond erin de sturing van de treinen onder controle te brengen van de PLC ofhet LES. Een medestudent kwam met het idee om een eigen Infrarood (IR) zender te ontwikkelen gebaseerd ophet IR protocol van LEGO dat openlijk vrijgegeven is. Door het IR systeem te koppelen aan een digitale uitgang vande PLC, zou het sturen van de treinen in het project geïntegreerd kunnen worden.

De analyse van het IR protocol toonde aan dat er een schakelfrequen e van 38kHz vereist is. De schakelperiodeschommelt dus rond 26 µs. Deze cyclus jd kan op een digitale uitgang van de PLC niet gehaald worden, maarwel op een uitgang van een microcontroller. Er werd beslist om een microcontroller van Arduino in het projectte integreren die via TCP/IP de instruc es van het besturingssysteem uitvoert. Aangezien de instruc es vanuithet LES origineren en er geen veldbus protocol van toepassing is, communiceert het LES rechtstreeks met demicrocontroller zonder tussenkomst van de PLC (figuur 3.1). Het zou interessant zijn om in verder onderzoekde integra e mogelijkheden van de microcontroller op EtherCAT te bestuderen. Het systeem zou hiermee eendeterminis sch gedrag vertonen en de bedrijfszekerheid zou toenemen. Het LES zou de snelheidssturing via ADSkunnen aanspreken, zoals het gebruikelijk is om I/O te benaderen die onder controle vallen van de PLC. Via ADSkunnen deze gegevens gemakkelijk opgevraagd worden door SCADA toepassingen.

De dimensionering en de keuze van de juiste componenten van het IR systeem hee enig zoekwerk gevraagd.Het principeschema van de schakeling is te zien in figuur 3.5. In totaal zijn er 40 IR Light-Emi ng Diode (LED)'s (4kringen van 10 LED's) aan het plafond beves gd, om het IR dekkingsgebied zo goed mogelijk te garanderen. Detoepassing laat toe om tot maximaal 8 treinen te besturen.

Figuur 3.5: Elektronisch circuit van het IR systeem

3.3 Het LES

Zoals in punt 3.1 vermeld is, wordt er gebruik gemaakt van een VB.NET programma dat twee basisfunc onalitei-ten van het LES simuleert: het aansturen van de treinen en het bijhouden van informa e over de treinen. Dezefunc onaliteiten zijn nodig om de doelstellingen van de masterproef op de opstelling te kunnen demonstreren.De logica achter het systeem valt buiten het bestek van deze masterproef. De bespreking beperkt zich tot de mo-gelijkheden van de gebruikersinterface (figuur 3.6). Het programma is geschreven door een projectmedewerkervan UGent.

In eerste instan e moet de gebruiker verbinden met de microcontroller. Bij een geslaagde verbinding, wordt eenecho verzonden van het bericht. De interface laat toe om de snelheid van vier treinen aan te sturen (RED1,...,RED4). Een traject instellen kan manueel of automa sch gebeuren. Bij de manuele instelling moet de gebruiker

28

de routes aanklikken die vervolgens in het geel op het scherm verschijnen. Bij de automa sche mode moet hetbegin- en eindpunt gegeven worden en het programma berekent zelf de kortste route. Indien de volgende spoorop de route van een trein bezet is, zal de trein wachten tot het spoor vrij is om zijn traject te vervolgen.

Figuur 3.6: De gebruikersinterface van LES

3.4 Visie

3.4.1 Situering

In deze sec e worden de keuzes van de hardware en de so ware van het visiesysteem gemo veerd. De doelstel-lingen van het visie systeem zijn gericht op een betrouwbare objectopvolging, een nauwkeurige posi ebepalingen verrijking met AR. Bovendien moet het geheel real- me afgehandeld kunnen worden (zie punt 1.3 en 1.4). Omde kansen tot slagen van deze doelstellingen te maximaliseren, zijn een aantal afspraken gemaakt, zoals een vastecamera opstelling, geen te zware beperking van processorkracht en de vrije keuze in het gebruik van so warebibliotheken.

Met de eventuele toekoms ge uitbreidingen in het achterhoofd, werd oorspronkelijk gedacht om de camera vaneen iPad te gebruiken om de opstelling te filmen. Na onderzoek bleek er geen mogelijkheid te bestaan om decamera feed van de iPad real- me te streamen op een Windows laptop. Het gebruik van de iPad leidde onver-mijdelijk tot de ontwikkeling van een applica e op het mobiele besturingssysteem iOS. Omwille van de beperkteprocessorkracht en de beperkte beschikbaarheid van ondersteunende visie bibliotheken werd er beslist om eenwebcammet USB aanslui ng te gebruiken. Het gekozenmodel is de Logitech C270 webcam, een goedkoopmodeluit het gamma (+/- €30).

Mogelijke keuzes van so ware zijn opgesomd in de projectaanpak onder punt 1.4.4. Er werd beslist om eenapplica e te ontwikkelen op basis van OpenCV. Zoals de naam het zegt, is de so ware open source waardoordure licen e kosten vermeden worden, zoals het geval is bij Matlab. OpenCV wordt aanzien als de referen e vanbeeldverwerking en hee een uitgebreide documenta e. Er verschijnen regelma g updates en de bibliothekenzijn ontwikkeld met het oog op presta e op malisa e. De C++ interface is de meest uitgebreide interface en laattoe om applica es te ontwikkelen in Visual Studio. OpenCV werkt voornamelijk op de centrale Central ProcessorUnit (CPU) en hee als nadeel dat de mogelijkheden op het gebied van de Graphical User Interface (GUI) beperktzijn. Voor het renderen van complexe 3D objecten, moeten bijkomende bibliotheken op basis vanOpenGL func esin het project geïmporteerd worden. Dergelijke bibliotheken werken rechtstreeks op de grafische kaart.

Op internet zijn er tal van bibliotheken te vinden die het resultaat zijn van het werk van onderzoeksgroepen (ViSP,

29

Scene,...) en specifieke algoritmes implementeren. Er zijn verschillende bibliotheken getest die weinig vruchtenafgeworpen hebben. De redenen hiervoor zijn uiteenlopend: specifieke interfaces die moeilijk of niet te com-bineren zijn met andere bibliotheken, compileerfouten of het gebrek aan documenta e. Om de scope van hetuitgevoerde werk in de volgende punten te beperken, gaat de aandacht uit naar de methodes die wel resultaatopgeleverd hebben. De bespreking is gelijklopend aan de indeling van de literatuurstudie.

3.4.2 Camerakalibra e

De camerakalibra e is nodig om de wereldcoördinaten van de treinen te bepalen. Hoe de transforma e vanpixelcoördinaten naar wereldcoördinaten gebeurt, staat beschreven in de literatuurstudie onder punt 2.2. Hetproces wordt onderverdeeld in verschillende stappen:

Stap 1: Cameramatrix en distor ecoefficiënten In eerste instan e worden de eigenschappen van de webcamvastgelegd in de cameramatrix en de distor ecoefficiënten. Het bepalen van deze matrices gebeurt dooreen schaakbordpatroon onder verschillende hoeken te filmen. OpenCV verwacht een aantal inputparame-ters, zoals het aantal rijen en kolommen van het patroon en de afme ngen van de vierkanten. Vervolgenszal OpenCV het patroon in de beelden (linkse beeld in figuur 3.7) herkennen en zal in combina e met deinputparameters de cameramatrix en de distor ecoefficiënten berekenen. Aan de hand van de distor e-coefficiënten kunnen de lenscorrec es doorgevoerd worden (rechtse beeld in figuur 3.7). Zoals te zien is,zijn de lenscorrec es minimaal en zijn ze vooral merkbaar in de hoeken van het beeld. Dit proces hoe vooreen camera slechts éénmalig te gebeuren.

Figuur 3.7: Stap 1: Cameramatrix en distor ecoefficiënten

Stap 2: Rota e- en transla ematrix Omde rota e- en transla ematrix te bepalen, worden vier pixelcoördinatengekozen en in een array opgeslagen. De pixels stellen punten voor in het beeld waarvan de wereldcoördi-naten gekend zijn. De overeenkoms ge wereldcoördinaten worden in een afzonderelijke array opgesla-gen. Momenteel zijn de pixelcoördinaten hard gecodeerd wat niet gewenst is. In de volgende sec e 3.4.3wordt het gebruik van markerdetec e toegelicht om punten in het beeld automa sch te herkennen. Dearray's van pixel- en wereldcoördinaten vormen samen met de cameramatrix en de distor ecoëfficiënten,de inputparameters van de OpenCV func e cv :: solvePnP . De output van de func e is de rota e- entransla ematrix.//pixelcoordinaten linken aan wereldcoordinaten//Output van solvePnp = rotatie- en translatiematrixcv::solvePnP(worldCoordinates, pixelCoordinates, cameraMatrix, distCoeffs, rotMatrix, transMatrix);

Stap 3: Omze ng wereldcoördinaten in pixelcoördinaten en omgekeerd Op dit punt zijn alle matrices bekendomwereldcoördinaten te vertalen naar pixelcöordinaten (zie formule 2.1). De projec e van 3D wereldcoör-dinaten in het beeld gebeurt met de func e cv :: projectPoints:

30

//worldCoorinates = array van de te positioneren punten//output van projectPoints = projectedPoints(posities van de 3D punten geprojecteerd in het beeld)cv::projectPoints(worldCoordinates,rotMatrix,transMatrix,cameraMatrix,distCoeffs,projectedPoints);

Figuur 3.8 illustreert het gebruik van cv :: projectPoints. Het wereldcoördinatenstelsel wordt in het beeldgeprojecteerd. De lengte van elke as is 1000 mm (= de lengte van 1 zijde van een wi e tegel). Aan dehand van de wi e tegels kan de posi oneernauwkeurigheid gemakkelijk beoordeeld worden. Bijkomendwordt er gevraagd om 2 punten correct te posi oneren in het beeld. Het punt met x-coördinaat 1000mm(=1 tegel in x-rich ng), y-coördinaat 3000mm (=3 tegels in y-rich ng) en z-coördinaat 0 wordt als voorbeeldgenomen. In de figuur is duidelijk te zien dat het punt nauwkeurig geposi oneerd is.

Figuur 3.8: Stap 2: Rota e- en transla ematrix

In objectherkenning moet de omgekeerde weg gevolgd worden. De pixelcoördinaten van een gedetec-teerde trein moeten omgezet worden in wereldcoördinaten. Dit wilt zeggen dat formule 2.1 aangepastmoet worden om de wereldcoördinaat (X,Y, Z) aan de linkerkant van de vergelijking te krijgen en depixelcoördinaat aan de rechterkant (x, y) rekening houdende met de regels van matrixvermenigvuldiging.Om de vergelijking te kunnen oplossen moet één variabeleX ,Y of Z vastgelegd worden anders is de ver-gelijking onbepaald. Dit betekent eigenlijk dat er een vlak vastgelegd wordt. Voor de toepassing is de keuzeevident, namelijk het vlak waarin de sporen ligt. Indien het assenstelsel in figuur 3.8 als referen e genomenwordt, moetZ nul zijn. OpenCV biedt geen func es om deze berekeningen uit voeren, waardoor er zelf eenfunc e geschreven is die de wereldcoördinaten retourneert://input x en y = pixelcoordinaten//input TransfData: object van het type TransformData (klasse met distortiecoefficienten , ←↩

cameramatrix, rotatie- en translatiematrix)cv::Point3f util_PixelToWorldCoord(float x, float y, TransformData TransfData)

3.4.3 Markerdetec e

Deze sec e is een aanvulling op stap 2 die in de vorige sec e 3.4.2 besproken is. Het gebruik van markers laattoe om punten in het beeld automa sch te herkennen. Door het hard coderen te vermijden, kan het wereldcoör-dinatenstelsel correct geposi oneerd worden ook al is de camera bewogen. Markers zijn nog steeds de meesttoegepaste techniek in mobiele AR toepassingen (zie punt 2.5.3). In onze toepassing worden markers herkend bijde opstart van het systeem. Na de opstart wordt er verondersteld dat de camera niet meer beweegt.

Hoewel er op internet verschillende bibliotheken te vinden zijn om markers te detecteren, zijn de Applica onProgramming Interface (API)'s dikwijls niet voorzien om in een OpenCV applica e geïntegreerd te worden. En als

31

de integra e lukt, gaat het dikwijls ten koste van de verwerkingssnelheid. Bovendien worden er dikwijls complexemarkers gebruikt die in de toepassing niet herkend worden omdat ze zich te ver van de camera bevinden. Er isdaarom beslist om zelf de markerdetec e te implementeren op basis van OpenCV func es.

De markerdetec e gebeurt door een contour analyse uit te voeren in het beeld met de OpenCV func e cv ::

findContours. De func e steunt op het Canny algoritme om randen features uit het beeld te extraheren (ziepunt 2.3.2). De gedetecteerde randenworden in een object contours opgeslagen. Een contour kan zowel open alsgesloten zijn en elke contour krijgt een ID toegewezen. OpenCV zal een hiërarchie opmaken van de contouren opbasis van een 'Parent-Child' indeling. Een contour is een child als het zich in een gesloten parent contour bevindt.De ID's van de contouren krijgen op deze manier een plaats toegewezen in het object hierarchy.//Zoek de contouren in het beeld //Output: contours, hierarchycv::findContours(gsFrame,contours,hierarchy, CV_RETR_CCOMP,CV_CHAIN_APPROX_SIMPLE);//Zoek naar de polygoon die de contour het best omsluitcv::approxPolyDP(contours[i],poly,3,1);

Het volledig proces van markerdetec e is weergegeven in figuur 3.9. Het camerabeeld wordt omgevormd in eengrijsbeeld waarin een filter toegepast wordt om de randen te accentueren. De markers bestaan uit een rechthoekin een ander rechthoek en zijn visueel gemakkelijk te herkennen in de figuur. Het volgende beeld stelt de con-touren voor die door cv :: findContours gevonden zijn. Vervolgens wordt er voor elke gesloten contour via defunc e cv :: approxPolyDP de polygoon gezocht die de contour het best omsluit. Indien de polygoon 4-zijdigis, wordt er binnen de hiërachie gezocht naar de child contouren. Als er een child contour aanwezig is waarvande polygoon eveneens 4-zijdig is, wordt een marker herkend. De pixelcoördinaat van het centrum van de markerwordt berekend en kan vervolgens gelinkt worden aan een wereldcoördinaat. De output van de markerdetec emet pixelcoördinaten is te zien in het rechtse beeld.

Figuur 3.9: Markerdetec e

3.4.4 CamShi

Zoals in de literatuurstudie beschreven onder punt 2.4.1, wordt er een histogram gemaakt van het te detecterenobject. Aan de hand van het histogram wordt de back projec on berekend die als input dient van het Camshialgoritme. OpenCV biedt de nodige func onaliteiten om de stappen te implementeren://BEREKEN HET HISTOGRAM

//Input: geselecteerde gebied (roi), dimensies van het histogram //Output: histogramcv::calcHist(&roi, 1, channels, noArray(), histogram, 3, histSize, ranges);//BEREKEN DE BACK PROJECTION

//Input: histogram //Output: backprojectioncv::calcBackProject(&image, 1, channels, histogram, backprojection, ranges);//VOLG HET OBJECT MET CAMSHIFT

//Input-Output: zoekvenster //Output:trackboxtrackBox = cv::CamShift(backprojection, zoekvenster, TermCriteria);

Om een object te traceren, moet de gebruiker met de muis een rechthoek trekken rond het object. Het nutvan de rechthoek is tweeledig. Ten eerste dient het om het histogram te berekenen. Ten tweede bepaalt derechthoek de ini ële posi e van het zoekvenster in het Camshi algoritme. Vervolgens wordt het zoekvenster

32

door het algoritme geüpdatet (zie punt 2.4.1). De func e CamShift retourneert bijkomend een trackbox. Dit iseen geroteerde rechthoek die het object nauwkeurig omsluit.

De eerste versie van het algoritme is, zoals gebruikelijk, getest met een histogram van de huewaarde. De output iste zien in fig 3.10. Het zoekvenster is voorgesteld door de groene rechthoek en de trackbox door de roze rechthoek.In de back projec on is te zien dat de treinen ietswi er uitstekendande achtergrond. Nochtans faalt het algoritmeomdeobjecten te volgen. Dit hee temakenmet de grote hoeveelheid grijze pixels in de back projec onwaardoorhet camshi algoritme naar een verkeerd lokaalmaximum itereert. Het gevolg is dat het zoekvenster steeds groterwordt.

Figuur 3.10: Camshi op basis van de Hue waarde

Om de back projec on te op maliseren, wordt een filter toegepast. Er wordt enkel rekening gehoudenmet pixelswaarvan de brightness en de satura on in een opgelegd interval liggen. De pixels in het interval hebben eenstabielere huewaarde. De output isweergegeven in figuur 3.11. In de back projec on is het onderscheid tussen detreinen en de achtegrond veel duidelijker. De gebruiker hee demogelijkheid om te sleutelen aan de filterwaardenvia de trackbars. Zoals in de figuur te zien, worden de geselecteerde treinen correct getraceerd. De pijl getekendin de back projec on, duidt een kri sch punt aan waar het algoritme soms de trein verliest. Door de afstanden de posi e van de trein ten opzichte van de camera, zijn er maar weinig pixels ter beschikking. Bovendien isvoornamelijk de achterkant van de trein zichtbaar terwijl het histogram berekend is op de zijkant van de trein. Hetalgoritme is bijzonder snel (+/- 20 ms per frame) waardoor de de treinen in real- me opgevolgd worden. Anderevoordelen zijn: de schaduwen van de treinen spelen geen rol en het object wordt zowel in beweging als in s lstandgetraceerd.

Figuur 3.11: Camshi op basis van de gefilterde Hue waarde

33

Het grote nadeel van het algoritme is de manuele interven e van de gebruiker. Dit zou eventueel omzeild kun-nen worden door het histogram hard te coderen en een contour analyse uit te voeren van de blobs in de backprojec on. Het probleem is dat de robuustheid van de applica e in het gedrang komt. Bij variërende omgevings-licht kan het histogram niet meer voldoen. Bovendien neemt de complexiteit en de onderhoudbaarheid van hetprogramma snel toe wanneer de objecten verschillende kleuren hebben.

3.4.5 Achtergrondsubtrac e

Het achtergrondmodel

De principes van achtergrondsubtrac e zijn uiteengezet in de literatuurstudie onder punt 2.4.2. Uitvoerig onder-zoek op gebied van achtergrondsubtrac e, hee geleid tot een ruime keuze aan modellen. De resultaten vanverschillende modellen kunnen sterk van elkaar verschillen (figuur 3.12). De figuur is een uitstekend vertrekpuntom de keuze van het geselecteerde model te mo veren. De criteria van een robuust model zijn:

• Dynamische achtergrond: de modellen moeten omgevingsveranderingen in de achtergrond kunnen opne-men.

• Duidelijke blobs in het binaire beeld. Ruis moet zo beperkt mogelijk zijn en schaduweffecten mogen niet teuitgesproken aanwezig zijn.

• Real- me: Om een vlo e visualisa e te realiseren in Experior mogen niet teveel frames overgeslagen wor-den.

Model (h) is gebaseerd op een sta sch model waarbij de achtergrond uitsluitend door de eerste frame bepaaldwordt. Het is duidelijk te zien dat hetmodel niet voldoet. Een lichte beweging van de camera hee ervoor gezorgddat het model niet meer bruikbaar is. Modellen (d), (e) en (f) voldoen niet aan de tweede voorwaarde. Er wordenteveel pixels als fout-nega ef gedetecteerdwaardoor delen van de treinen in de achtergrond opgenomenworden.De verste trein is nauwelijks herkenbaar en gaat soms volledig verloren. Model (g) is een voorbeeld van eenovermaat aan fout-posi evenwaardoor delen van de achtergrond tot de voorgrondworden gerekend (langewi estaart achter de treinen). Model (i) is het model dat in OpenCV gebruikt wordt en is de implementa e van hetklassieke MoG model. Zoals beschreven in punt 2.4.2 leidt het zuivere MoG model tot een te grote detec e vanfout-posi even en fout-nega even. De modellen die de beste resultaten produceren zijn (b) van Zivkovic en (c).Het model van Zivkovic onderscheidt zich van model (c) omwille van de efficiëntere verwerkings jd.

34

Figuur 3.12: Achtergrondsubtrac e overzicht

De voorbeelden in figuur 3.12 zijn het resultaat van de opensource bibliotheek bgslibrary. De bgslibrary is geba-seerd op het C++ interface van OpenCV waardoor het model éénvoudig in onze visie applica e geïntegreerd kanworden. Naast de bgslibrary hee Zivkovic zelf code vrijgegeven (zie licen evoorwaarden in de bijlagen) geba-seerd op een gelijkaardige API als de bgslibrary. Om van het model gebruik te maken zijn er slechts 3 lijnen codenodig://instantieren van het modelCvPixelBackgroundGMM* pGMM=0;pGMM=cvCreatePixelBackgroundGMM(img_input.cols,img_input.rows);//img_input = input frame //img_mask = output achtergrondmodelcvUpdatePixelBackgroundGMM(pGMM,img_input.ptr(),img_mask.ptr());

De code van Zivkovic resulteert in een snellere verwerkings jd en beschikt over een op e om de schaduw van detreinen te verwijderen. Zoals in figuur 3.13 te zien is, kunnen schaduweffecten een correcte object segmenta eerns g verstoren.

Figuur 3.13: Verwijderen van schaduw

De gebruiker is vrij om in de broncode te sleutelen aan de parameters van het model. Een belangrijke parameteris de leerfactor of de snelheid waarmee het achtergrondmodel geüpdatet wordt (formule 2.7). Een trein die lang

35

hee s lgestaan is door het dynamisch model in de achtergrond opgenomen. Als de trein opnieuw in bewegingkomt, zal niet enkel de bewegende trein als een voorgrond object gedetecteerd worden maar er verschijnt eenbijkomende blob op de plaats waar de trein hee s lgestaan. Hetmodel hee immers een bepaalde jd nodig omde nieuwe achtergrondinforma e te verwerken. Door de leerfactor aan te passen, kan deze jd tot een minimumherleid worden.

Post-processing

Dankzij de code van Zivkovic kan het achtergrondmodel éénvoudig en snel berekend worden. Hoewel hiermeeeen belangrijke stap gezet is, moeten de blobs in het achtergrondmodel nog vertaald worden in nu ge posi-e informa e. Vanaf hier begint de post-processing analyse (zie punt 2.4.2). De verschillende stappen worden

toegelicht aan de hand van figuur 3.14. Om de figuur duidelijk te houden, wordt er enkel naar één trein gekeken.

Figuur 3.14: Post-processing analyse

Stap 1: Morfologische bewerkingen Deze bewerkingen dienen om ruis uit het model te filteren en gaten in deblobs zo goed mogelijk te dichten.

Stap 2: Overlap tussen sporen en blobs De bewerkte blobs kunnen in principe rechtstreeks naar de contouranalyse gestuurd werden. De contour analyse zal typisch het middelpunt van de blobs berekenen. Zoals in punt3.4.2 aangehaald is, moet minstens één van de X,Y, Z variabelen gekend zijn om een pixelcoördinaat te linkenaan een 3Dwereldcoördinaat. Met de gepresenteerde blobs, kan geen enkele variabele met zekerheid vastgelegdworden, hoewel het vastleggen van Z op de halve hoogte van een trein waarschijnlijk een goede benadering is.Maar als de treinen in het beeld verschillende hoogtes hebben, is er een duidelijk probleem. Bovendien liggensommige sporen in de opstelling heel dicht bij elkaar en de camera bestrijkt een grote oppervlakte. Geringeonnauwkeurigheden kunnen voldoende zijn om de treinen in Experior op een verkeerd spoor te posi oneren enom het traceerproces van de AR verrijking teniet te doen (zie punt 2.5.3). De correcte berekening van de hoek vande treinen in hetXY vlak, wordt door de voorafgaandemorfologische bewerkingen van de blob bijna onmogelijkgemaakt. Hoewel de bewerkingen erop gericht zijn de gaten in de contour te dichten, wordt de vorm van de blobop een onvoorspelbare manier gewijzigd. Aangezien de vorm van de blob bepalend is voor de berekening van dehoek, kunnen fouten ontstaan die moeilijk op te vangen zijn.

De opgesomde problemen worden verholpen door nieuwe blobs te creëren als zijnde het raakvlak tussen desporen en de treinen. De Z variabele ligt vast op nul en zowel het centerpunt als de hoek in het XY vlak kannauwkeurig bepaald worden. Het binaire beeld van de sporen moet éénmalig gemaakt worden. Het linkse beeldin figuur 3.9 is het vertrekpunt om het beeld te fotoshoppen tot het resultaat in figuur 3.15. De sporen wordenvia de markerdetec e correct in het beeld geposi oneerd.

36

Figuur 3.15: Mask Tracks

Stap 3: Contour analyse De contour analyse gebruikt dezelfde OpenCV func es die van toepassing zijn voor demarkerdetec e in punt 3.4.2. Van elke contour kan een geroteerde rechthoek verkregenworden die de blob nauwomsluit (zie figuur 3.14). Aan de hand van de geroteerde rechthoekworden het centerpunt inXY -vlak en de hoekten opzichte van de Z-as berekend. Het kan soms gebeuren dat de trein een bijkomend raakvlak hee met eenander spoor waardoor één of meerdere valse blobs gecreëerd worden. De grote rechthoek rond de geroteerderechthoek, zal als filter dienen om de valse blobs te elimineren. De valse blobs die door de trein veroorzaakt zijn,hebben ook een rechthoek die met zekerheid de rechthoek van de trein zal snijden. Hiermee wordt het signaalgegeven dat er een valse blob aanwezig is en uit de contour analyse verwijderd moet worden. Het centerpunt ende hoek van de gedetecteerde blobs, dient vervolgens als input van de blob analyse.

Blob analyse

De blob analyse hee als taak om de verschillende blobs die uit de contour analyse resulteren, te linken aan detreinen op het logis eke traject. De analyse zorgt voor de tracering en het ID beheer van de treinen. Om een ideete geven van de rol en de complexiteit van de blob analyse worden een aantal scenario's opgesomd die kunnenvoorkomen:

• Een nieuwe trein verschijnt in het gezichtsveld van de camera of een bestaande trein verlaat het gezichtsveldvan de camera.

• Een bewegende trein moet tussen de verschillende frames correct getraceerd en geïden ficeerd worden.

• Een trein komt tot s lstaand. Als de trein lang genoeg s lstaat, zal het in de achtergrond opgenomenwordenwaardoor de bijhorende blob verdwijnt.

• Een s lstaande trein waarvan de blob verdwenen is, komt terug in beweging. Zoals eerder vermeld in debespreking van het achtergrondmodel, vormt dit geval het zwakke punt van de dynamische achtergrond-subtrac e. Naast de bewegende trein, wordt ook de lege ruimte die de trein achterlaat door het modelgeïnterpreteerd als een verandering van de achtergrond en bijgevolg als een voorgrond object. Zolang debewegende trein deels overlapt met de plaats waarop het eerder s lstond, wordt een lange uitgerekte blobgecreëerd. Tijdens deze fase zijn het centerpunt en de hoek van de blob niet betrouwbaar. Eenmaal debewegende trein geen raakpunt meer hee met de plaats van s lstaand, wordt de uitgerekte blob gesplitstin twee blobs waarvan de ene blob de bewegende trein voorstelt, terwijl de andere blob de oorspronkelijkeplaats van s lstaand representeert. Na enige jd zal deze valse blob in de achtergrond opgenomen wordenen uiteindelijk verdwijnen. Het kan echter gebeuren dat een blob horende bij een andere bewegende trein,in contact komt met de valse blob vooraleer het verdwenen is.

• Hoewel dit eerder uitzonderlijk is, is het mogelijk dat visie een bewegende trein verliest. De trein kan op-nieuw gedetecteerd worden als de blob terug in het beeld verschijnt.

De implementa e van een logica die alle mogelijke gevallen met elkaar verzoent en correct a andelt, is nietvanzelfsprekend. De logica vertrekt van een aantal veronderstellingen over het gedrag van het systeem, maar

37

naargelang het scenario kunnen sommige veronderstellingen elkaar tegenspreken. Er wordt niet dieper ingegaanop deze problema ek, maar dit punt wordt aangehaald om te vermelden dat een sluitende logica zonder de hulpvan Experior moeilijk te implementeren zou zijn.

De logica is gebaseerd op drie verschillende statussen die toegekend worden aan de gedetecteerde treinen invisie. De communica e met Experior speelt hierin een centrale rol. Het kernprincipe is dat de aanwezigheidvan een trein in visie door Experior beves gd moet worden. In visie wordt er voor elke blob een object clsTrainaangemaakt en alle treinen worden in een lijst bijgehouden. Zolang een trein door Experior niet gevalideerd is,wordt de status UNKNOWN aan de trein toegekend. Treinen die deze status bezi en, krijgen een jdelijke visie IDtoebedeeld. De beves ging van een trein door Experior gebeurt op basis van de informa e van de input sensoren.Van zodra een sensor hoog wordt, zal Experior de posi e en de systeem ID van de betreffende trein doorspelennaar visie. Visie zal in de lijst van treinen op zoek gaan naar de overeenkoms ge match. Hoe dit precies gebeurt,wordt geïllustreerd in figuur 3.16.

Figuur 3.16: A andeling Experior bericht

Zoals in figuur 3.16 te zien is, resulteert de a andeling van het Experior bericht in een aanpassing van status enID. Als de overeenkoms ge trein de status UNKNOWN hee , wordt de visie ID vervangen door een systeem IDvan Experior. De status UNKNOWN wordt aangepast naar status ID_MOVE (prioriteit 1 of 2) indien er in de lijstvan treinen een match gevonden wordt. Indien dit niet het geval, wordt een nieuwe trein gecreëerd met statusID_NO_MOVE (prioriteit 3). Van zodra een trein een systeem ID hee , zal visie na de beeldverwerking van elkenieuwe framedeposi e coördinaten doorsturen naar Experior. Experior kan vervolgens de coördinaten verwerkenom een vlo e visualisa e van het proces te realiseren.

Ona ankelijk van Experior, moet visie in staat zijn om de objecten zelfstandig te traceren tussen opeenvolgendeframes. Hiervoor wordt de veronderstelling gemaakt dat een trein tussen elke frame niet meer dan eenmaximaleafstand kan afleggen, vastgelegd op basis van de maximale snelheid van de trein. Er kan dus voor elke trein eenzone afgebakend worden waarbinnen een blob verwacht wordt in de volgende frame. Indien er in deze zone

38

effec ef een blob gevonden wordt, zal het centerpunt van de blob dienen om de posi e coördinaten van de treinaan te passen. Er kunnen een aantal gevallen voorkomen, waarbij de status van een trein aangepast wordt:

• Trein komt tot s lstand en de bijhorende blob verdwijnt:

– Vorige status ID_MOVE⇒ nieuwe status wordt ID_NO_MOVE

– Vorige status UNKOWN⇒ trein wordt uit de lijst verwijderd

• S lstaande trein met status ID_NO_MOVE komt terug in beweging: nieuwe status wordt UNKNOWN (erwordt dus later een nieuwe beves ging van Experior verwacht).

Tenslo e is er nog een failsafe geïmplementeerd om storingen door valse blobs op te vangen. Op basis van deroutering van de treinen door het LES is het quasi onmogelijk dat de gereserveerde zones van de treinen metelkaar overlappen. De zones zijn zodanig klein dat een overlapping als een botsing geïnterpreteerd kan worden,hetgeen niet toegelaten is door het LES. Indien er toch een overlapping is, kan er van uitgegaan worden dat éénvan de twee treinen, een valse blob is. Om de valse blob te detecteren, wordt er een prioriteit toegekend aande verschillende ID's. Status UNKNOWN zal al jd het onderspit delven en status ID_NO_MOVE zal verliezen vanstatus ID_MOVE. De verliezende trein wordt vervolgens uit de lijst van treinen verwijderd.

3.4.6 AR

Zoals in de projectaanpak onder punt 1.4.4 aangehaald is, bestaan er verschillende bibliotheken om virtuele ele-menten in 3D te renderen. Omdat het grafische aspect minder van belang is in het project, is ervoor gekozen omAR te implementeren op basis van de (weliswaar beperktere) GUI mogelijkheden van OpenCV. Het gebruik vanAR gebeurt op verschillende manieren.

De eerste manier dient om een voorbeeld te geven van het traceerproces dat in punt 2.5.3 besproken is. Hettraceerproces is de stap waarbij het virtuele element op het object gealigneerd wordt en is de meest delicate stapin het AR proces. Het objectdetec e algoritme retourneert de posi e in hetXY -vlak en de rota ehoek rond deZ-as. Deze informa e wordt gebruikt om een doorzich ge balk te projecteren op de gedetecteerde treinen (ziefiguur 3.17). De balk is gecodeerd aan de hand van de lengte, breedte en hoogte van de trein in reële dimensies.De posi onering van de balk op de trein gee een idee van de nauwkeurigheid van de objectdetec e en van decamera matrices.

In de toepassing dienen de balken om de gebruiker te informeren over de statussen van de gedetecteerde trei-nen. Zoals in de figuur te zien is, worden treinen die nog niet beves gd zijn door Experior (status UNKNOWN),voorgesteld met een rode balk en de visie ID. Anderzijds worden de beves gde treinen afgebeeld met de systeemID. Op de s lstaande treinen (status ID_NO_MOVE) wordt een blauwe balk geprojecteerd en op de bewegendetreinen (status ID_MOVE) een groene balk.

Figuur 3.17: Trein opvolging en balk projec e

39

In de literatuurstudie onder punt 2.5.4, is een overzicht te vinden van industriële concepten rond AR. Op ba-sis hiervan, is er inspira e geput om een aantal scenario's te ontwikkelen die het nut van AR aantonen. De ARscenario's zijn voor drie doelgroepen bestemd: onderhoudstechniekers, logis eke operatoren en produc e ver-antwoordelijken. Om te weten tot welke doelgroep een gebruiker behoort, moet de gebruiker zich via een loginaanmelden. Vervolgens kan de gebruiker een trein selecteren en wordt de informa e van de gewenste trein viaAR in het beeld gepresenteerd. Aangezien het visie systeem de informa e aan Experior vraagt, kunnen enkel detreinen geselecteerd worden die over een systeem ID beschikken.

De eerste doelgroep is de groep van de onderhoudstechniekers. Figuur 3.18 toont het resultaat nadat een tech-nieker een trein geselecteerd hee . Er wordt verondersteld dat de trein een AGV simuleert en onderaan hetbeeld wordt er technische informa e getoond, zoals motor temperatuur, aantal dagen tot de volgende onder-houdsbeurt,... De technieker hee de mogelijkheid om op het icoon rechts onderaan te klikken. Hiermee wordteen video in een tweede venster afgespeeld die de technieker begeleid doorheen de verschillende stappen vaneen technische interven e.

Figuur 3.18: AR scenario technieker

De tweede doelgroep betre de logis eke operatoren. De logis eke operator is geïnteresseerd in het vertrekpunten voornamelijk het doelpunt van de AGV. Het doelpunt kan bijvoorbeeld een magazijnloca e zijn of een werk-post op de produc evloer. Om de operator te informeren over het traject van de trein, worden de sporen diegevolgd zullen worden om de eindbestemming te bereiken, in overlay in het beeld geprojecteerd. Het resultaat isweergegeven in figuur 3.19.

Figuur 3.19: AR scenario logis eke operator

40

Tot de laatste groep behoort de produc e verantwoordelijke. In dit geval, bestaat de informa e uit het product-type, klantnummer en de Overall Equipment Effec veness (OEE) van de AGV.

3.4.7 Overzicht visie applica e met TCP/IP interface

Om de bespreking van het deel over visie af te sluiten, wordt in figuur 3.20 de flowchart getoond van de gereali-seerde applica e. De flowchart integreert de besproken technieken van markerdetec e en van de omze ng vande beeldcoördinaten naar wereldcoördinaten. Wegens de robuustheid van het model, is er beslist om het mo-del van achtergrondsubtrac e de voorkeur te geven over Camshi . Het nadeel van het model is dat s lstaandetreinen in de achtergrond opgenomen worden. Om dit probleem op te lossen, zou Camshi eventueel als onder-steunend algoritme kunnen geïmplementeerd worden. Om redenen van efficiën e, wordt ervoor gekozen om deinforma e uit Experior te gebruiken in plaats van Camshi in de applica e te betrekken.

Zoals in de flowchart te zien is, gebeurt de communica emet Experior via het TCP/IP protocol. De a andeling vanschrijf- of leesopdrachten gebeurt in een afzonderlijke thread, om geen vertraging te creëren in de beeldanalyse.Er zijn tweemodules die gebruikmaken van de TCP/IP interface. De eerstemodule zorgt voor de logica van de blobanalyse zoals besproken in punt 3.4.5. De tweede logische module zorgt voor de a andeling van de aanvragenvan de gebruiker om het AR scenario af te spelen (zie punt 3.4.6). De module vraagt de gewenste informa eaan Experior en zorgt ervoor dat het correcte AR scenario afgespeeld wordt. Gezien het intensieve verkeer en deverscheidenheid aan uitgewisselde informa e tussen Experior en het visie systeem, wordt er gebruik gemaakt vaneen flexibele berichtstructuur op basis van tags volgens de eXtensible Markup Language (XML) structuur.

41

Figuur 3.20: Flowchart visie systeem

3.5 Het Experior model

Het uitgevoerde werk in Experior kan in twee delen opgesplitst worden. Het eerste deel betre de GUI waarin hetmodel opgebouwd wordt. Het tweede deel richt zich op de logica die het model beheert via een controller script.

3.5.1 GUI

In de inleiding onder punt 1.1 werd Experior geïntroduceerd als een so ware pakket voor Virtual Commissioning.Aangezien het model de werking van een logis ek proces moet nabootsen, biedt Experior uitgebreide catalogus-sen en verschillende ondersteunende func onaliteiten. In het vervolg van de bespreking, zal de aandacht uitgaannaar de func onaliteiten die toegepast zijn in het kader van het uitgevoerde werk.

42

Het model

De eerste stap bestaat erin het model, ook assembly genoemd, op te bouwen. Het resultaat is weergegeven infiguur 3.21. Het centrale deel wordt de werkvloer genoemd. In de linker paneel zijn de verschillende catalogussenterug te vinden met componenten die op de werkvloer gesleept kunnen worden. In het model worden tweecomponenten van de catalogussen gebruikt: straight tracks en sphere sensoren. De straight tracks stellen desporen voor en de sphere sensoren visualiseren de ligging van de induc eve sensoren. Door een componentin de assembly te selecteren, worden in het rechter paneel eigenschappen van de component aan de gebruikergepresenteerd. Ter voorbeeld is er in de figuur een track geselecteerd. De gebruiker is vrij om de naam, de kleuren de ligging van de track via het proper es paneel te wijzigen.

De treinen op de sporenworden niet in de GUI gecreëerd. Het beheer van de treinen valt onder de verantwoorde-lijkheid van de controller (zie punt 3.5.2). In de figuur is een oranje lijn getrokken om aan te duiden welk deel vanhet traject in het gezichtsveld van de camera ligt. In het bovenste deel van het model wordt een vlo e visualisa ebekomen via de terugkoppeling van de posi e coördinaten vanuit visie. In het onderste deel springt de trein vande ene sensor naar de andere.

Figuur 3.21: Experior

Configura e communica e interfaces

In het overzicht van het uitgevoerde werk (punt 3.1), werd figuur 3.1 geïntroduceerd om de centrale rol van Ex-perior in het communica e verkeer tussen de verschillende modules van het project te tonen. Experior commu-niceert met de PLC, het LES en het visie systeem. De verschillende communica e interfaces kunnen in Experiorop een gebruiksvriendelijke manier opgezet worden. Zoals er een paneel bestaat om componenten in de catalo-gussen te selecteren, hee Experior een afzonderlijke communica e paneel zoals weergegeven in figuur 3.22. Deinterfaces met de verschillende modules van het project zijn in de figuur duidelijk te zien.

De verbinding met visie en het LES zijn gebaseerd op TCP/IP. STX/ETX betekent dat het bericht moeten beginnenmet het STX karakter en eindigen met het ETX karakter. Experior is geconfigureerd om als client te connecterenmet het LES en verwacht dus het IP adres en het poort nummer. Het LES draait op een server in het automa -seringsnetwerk van het lab. De communica e met visie gebeurt op een gelijkaardige manier. De verbinding metde PLC gebeurt via het ADS protocol dat uitgebreid beschreven is in punt 3.2.1. In Experior moet enkel het AMS

43

adres en het poort nummer opgegeven worden. Zoals in figuur 3.22 geïllustreerd wordt, biedt Experior diversemogelijkheden om interfaces te realiseren met bijvoorbeeld Siemens, Modbus, OLE for Process Control (OPC),seriële communica e,...

Figuur 3.22: Communica e Experior

I/O

Aangezien Experior als Virtual Commissioning tool dient, worden de I/O signalen van en naar de PLC typisch doorde componenten op de werkvloer gegenereerd of verwerkt. Een virtuele sensor zal een input bit hoog plaatsenals de sensor in het model getriggerd wordt. Anderzijds kan de PLC via een output bit bijvoorbeeld de motor vaneen virtuele transportband starten. Voor onze toepassing wordt Experior als SCADA ingezet. Het model wordtbijgevolg niet gebruikt omhet proces virtueel te simuleren, maar omhet fysische proces temonitoren aan de handvan de werkelijke I/O statussen van de PLC. Om het proces te monitoren, moeten de statussen van de induc evesensoren en de stand van de wissels gekend zijn. Om de I/O van de PLC binnen te nemen zonder ze te linken aaneen component op de werkvloer, wordt er gebruik gemaakt van het control paneel (figuur 3.23).

Figuur 3.23: Control paneel Experior

44

In figuur 3.23, wordt ter illustra e getoond hoe de stand van de wissels in de opstelling wordt binnen gelezen. DestatuslampW1 is via de ADS verbinding gelinkt aan de symboolnaam uit de globale variabelen lijst (zie punt 3.2.1).Op deze manier, wordt de stand van elke wissel in de opstelling in Experior beschikbaar. Naast de lampen zijn erdrukknoppen voorzien die aan dezelfde variabelen gelinkt zijn. De drukknoppen bieden de mogelijkheid om dewissels vanuit Experior te sturen. Als de opstelling onder controle is van het LES, is er eigenlijk geen noodzaakaan drukknoppen omdat het LES de wissels aanstuurt. In het kader van SCADA toepassingen is dit echter eeninteressante func e, aangezien het de mogelijkheid biedt om het traject van de treinen in freerun aan te sturenindien er geen LES beschikbaar is of om te controleren dat er geen wissels geblokkeerd zijn.

Laden van de controller

Indien de noodzaak bestaat om bijkomende logica te implementeren om het model aan te sturen, kan er vooréénvoudige applica es rechtstreeks in de GUI een script geschreven worden. Voor meer complexe scenario'sbiedt Experior de mogelijkheid om een dll bestand te schrijven en te compileren in Visual Studio die vervolgensin het model geladen kan worden. Voor onze toepassing wordt er gebruik gemaakt van deze mogelijkheid. Delogica van de controller wordt in de volgende sec e 3.5.2 uitvoerig besproken. In figuur 3.24 wordt getoond hoede controller dll in het model geladen wordt.

Figuur 3.24: Laden controller script

3.5.2 Controller

Het Visual Studio project dat de logica van de controller inhoudt, is rela ef uitgebreid en bestaat uit meer dan eenental klassen. Een volledig overzicht van het project met klassendiagram kan gevonden worden in de bijlagen.

In de volgende punten, worden de basisprincipes van het project toegelicht. Het maken van de controller dll iséénvoudig. De solu on moet ten eerste referen es beva en naar andere dll bestanden van Experior. Vervolgenswordt er een klasse gemaakt die overer van de basisklasse Experior.Core.logic. In de laatste stap wordt desolu on als een dll bestand gecompileerd en kan de controller dll in het project geladen worden.

Ini alisa e

Om het model te sturen, is het nodig dat de controller de verschillende componenten in de GUI kan aanspreken.In eerste instan e worden de routes uit de assembly gehaald. Elke track in het model (zie punt 3.5.1) beschiktover een object van het type Experior.Core.Routes.Route. Routes worden in Experior gebruikt om goederen,ook loads genoemd, op de tracks te transporteren. De treinen, zoals in figuur 3.21 voorgesteld, zijn dus nietsanders dan loads die zich op de verschillende routes in het model verplaatsen. De manier waarop de routes uitde assembly gehaald worden en toegevoegd worden in een lijst, wordt in de code hieronder verduidelijkt.//The routesList<Experior.Core.Routes.Route> lstRoutes = new List<Route>();//Get Routes in Assembly

45

//----------------------foreach (KeyValuePair<string, Experior.Core.Assemblies.Assembly> kvp in Experior.Catalog.Logistic.Track.←↩

Collection.Items){//Routes are encapsulated in BaseTrack object: cast items of Track.Collection.Items to BaseTrackExperior.Catalog.Logistic.Track.BaseTrack basis = kvp.Value as Experior.Catalog.Logistic.Track.BaseTrack;

if (basis != null){

basis.TransportSection.Route.Name = basis.Name;lstRoutes.Add(basis.TransportSection.Route);

}}

De controller moet ook de status van de I/O in de opstelling kennen. De stand van de wissels is nodig om detreinen op het goeie traject te routeren en de controller moet kunnen reageren als een induc eve sensor hoogof laag wordt. Experior biedt hiervoor verschillende events waarop geregistreerd kan worden. Zoals in de codehieronder te zien is, wordt er geregistreerd op de events on en off . Event on wordt getriggerd als een sensorhoog wordt en event off als de sensor laag wordt.//I/OList<Core.Communication.PLC.Input> lstInductionSensors = new List<Core.Communication.PLC.Input>();List<Core.Communication.PLC.Input> lstTrackSwitchDirection = new List<Core.Communication.PLC.Input>();//Get ADS PLC connection inputs (induction sensors and track switches direction) in assembly//-----------------------------------------------------------------------------------------foreach (Experior.Core.Communication.PLC.Input y in Core.Communication.PLC.Connection.Inputs.Items){

if (y.ID.Contains("ADS") && y.Symbol.Contains("Spoor")){

y.On += new Core.Communication.PLC.Input.OnEvent(inputHigh); //event input gets highty.Off += new Core.Communication.PLC.Input.OffEvent(inputLow); //event input gets lowlstInductionSensors.Add(y);

}else if (y.ID.Contains("ADS") && y.Symbol.Contains("Wissel")){

lstTrackSwitchDirection.Add(y);}

}

De laatste elementen die nodig zijn om van start te kunnen gaan, zijn de verbinding met het LES en met visie.De controller moet berichten kunnen sturen en moet geïnformeerd worden als er nieuwe berichten ontvangenzijn. Door in te tekenen op de events OnTelegramReceived wordt de controller op de hoogte gebracht als eenbericht toegekomen is.//STX/ETX communication with LES and visionExperior.Core.Communication.TCPIP.STXETX VisionCom;Experior.Core.Communication.TCPIP.STXETX LESCom;//Events message received//--------------------------------------VisionCom.OnTelegramReceived += new Communication.TCPIP.Connection.TelegramReceivedEvent(TgrVISReceived);LESCom.OnTelegramReceived += new Communication.TCPIP.Connection.TelegramReceivedEvent(TgrLESReceived);

De treinen

De controller is verantwoordelijk voor het beheer van de treinen. In het programma worden treinen als objectenvan de klasse clsTrain of van de klasse clsTrainLES geïnstan eerd. In figuur 3.25 wordt het klassendiagramvoorgesteld. De klasse clsTrainLES wordt gebruikt om treinen te instan eren die met een vast traject in hetLES zijn ingesteld. Treinen van de klasse clsTrain kunnen beschouwd worden als freerun treinen. Dit betekentdat de snelheidssturing vanuit het LES gebeurt, maar dat de treinen niet gebonden zijn aan een vast traject. Hettraject kan bepaaldworden via de drukknoppen in hetmodelwaarmee dewissels in de opstelling gestuurd kunnenworden (zie punt 3.5.1 I/O). De klasse clsTrainLES er over van de klasse clsTrain, omdat de treinenmet eenvast traject een aantal bijkomende func onaliteiten en a ributen bezi en ten opzichte van de freerun treinen. Inhet vervolg van de bespreking worden treinen van het type clsTrainLES vernoemd als LES treinen en treinenvan het type clsTrain als freerun treinen.

46

Figuur 3.25: Laden controller script

Aan de hand van figuur 3.25 worden een aantal a ributen toegelicht die helpen om de werking van de controllerte verduidelijken:

• De systeem ID laat toe om de treinen op een unieke manier te iden ficeren. Wanneer de controller metvisie communiceert om de aanwezigheid van een trein te beves gen, wordt deze ID meegegeven en in hetbeeld aan de gebruiker gepresenteerd (zie punt 3.4.5 Blob Analyse).

• Eerder in deze sec e werd vermeld dat een trein in het Experior model wordt voorgesteld als een objectvan het type load. Het object van type load is terug te vinden onder het a ribuut trainMesh. De variabelenxCoord en yCoord worden gebruikt om de posi e coördinaten die door visie verstuurd zijn, op te slaan.

• Het a ribuut ac f gee aan of de trein ac ef is of niet. Aangezien de treinen AGV's voorstellen, wordt erverondersteld dat het aantal AGV's vastligt. In de constructor van de controller worden vier feerun treinenaangemaakt en vier LES treinen. Als een trein op onac ef staat, betekent dat het in het depot staat tewachten. Van zodra een trein geac veerd wordt, verschijnt de trein in het Experior model. LES treinenworden geac veerd door een bericht van het LES. Het bericht bevat de systeem ID en het traject dat detrein zal volgen. De ac vering van de freerun treinen gebeurt op basis van de induc eve sensoren. Demanier waarop dit gebeurt, wordt verduidelijkt bij de bespreking van de routering van de treinen.

• In de figuur zijn er a ributen te zien in een oranje kader. Deze a ributen houden de gegevens bij die doorhet visie systeem opgevraagd kunnen worden als een gebruiker een trein selecteert (zie punt 3.4.6). Elketrein beschikt over een object van het type clsTrainInfoData. Deze klasse omvat alle gegevens zoalsklantnummer, motortemperatuur,... Momenteel zijn alle variabelen hard gecodeerd, maar de code zouuitgebreid kunnen worden om bijvoorbeeld de gegevens te raadplegen in een database van het LES. DeLES treinen hebben een woordenboek als extra a ribuut. Het woordenboek wordt gebruikt wanneer eenlogis eke operator het traject van de trein in AR in het beeld wilt zien. Het woordenboek houdt van elkesensor op het traject bij welke routes er nog zullen afgelegd worden.

47

• De a ributen in blauwe kaders worden gebruikt om de treinen correct te routeren in het model. De LEStreinen beschikken over een lijst NextSensors. Deze lijst wordt ingevuld bij de ac vering van de LES treinenop basis van het traject in het LES bericht. De lijst houdt alle sensoren bij die op het traject staan.

Routering

Om de routering van de treinen in Experior in goede banen te leiden, wordt er met twee types routeringstabel-len gewerkt. Het eerste type routeringstabel wordt gebruikt om de treinen op de juiste routes in het model teposi oneren. Dit wordt uitgelegd aan de hand van figuur 3.26 die de verplaatsing van een trein voorstelt op drieverschillende jds ppen. Om de duidelijkheid te bevorderen, wordt er abstrac e gemaakt van de mesh en wordtde posi e van de trein aangeduid met een oranje cirkel. Elke route hee een begin- en een eindpunt. Het begin-punt is te herkennen door een rode blok, terwijl het eindpunt door een blauwe blok wordt voorgesteld. Een treinkan nooit achterwaarts rijden, maar naargelang het ingestelde traject kan een trein een route langs beide kantenbetreden. Als een trein zich verplaatst van het beginpunt naar het eindpunt, wordt het a ribuut TrainDirec on alsforward ingesteld en in het omgekeerde geval als backward. De rich ng van de trein is belangrijk om de correcterouteringstabel aan te spreken.

Figuur 3.26: Routering treinen script

Op jds p t1 bevindt de trein zich op de horizontale route. TrainDirec on werd eerder als forward ingesteld,aangezien de trein zich naar het eindpunt van de route verplaatst. Op jds p t2 stuurt visie een nieuwe posi ecoördinaat voorgesteld door het zwarte kruisje. De controller vergelijkt eerst de systeem ID van de trein met desysteem ID in het bericht. Indien de ID's overeenkomen, wordt de kortste afstand berekend van de posi e coör-dinaat tot de route van de trein (voorgesteld door de zwarte lijn die het kruisje verbindt met de oranje cirkel). Ditlevert een nieuw punt op de route waarvan de afstand berekend wordt tot aan het begin van de route (voorge-steld door de bruine pijl). Deze afstand is nodig om de load (=trainMesh) te verplaatsen op de route volgens deExperior func e Load.Switch:void Load.Switch(Experior.Core.Routes.Route route, float distance)

Op jds p t3 gebeurt dezelfde berekening ten opzichte van de horizontale route als op t2. De kortste afstand totde route, resulteert in het eindpunt van de route. De afstand tot het beginpunt van de route is in dit geval gelijkaan de lengte van de horizontale route. Hiermee wordt het signaal gegeven dat de routeringstabel geraadpleegdmoet worden om de volgende route te bepalen. Aangezien trainDirec on op forward ingesteld staat, wordt denieuwe route in de voorwaartse routeringstabel opgezocht. De routeringstabel houdt rekeningmet dewisselstandom de volgende route te retourneren. Vervolgens gebeurt de berekening van de visie coördinaten opnieuw maarditmaal ten opzichte van de nieuwe route. De trein wordt geposi oneerd op de berekende afstand ten opzichte

48

van het beginpunt van de nieuwe route. Het geheel resulteert in een vlo e overgang van ene route naar deandere. Het is interessant om op te merken dat de trein de nieuwe route in achterwaartse rich ng binnentreedt(de trein verplaatst zich volgens de rich ng van de rode pijl). Het a ribuut trainDirec on verandert bijgevolg naarbackward. Naarmate de trein zich op de route verplaatst, zal de afstand tot het beginpunt kleiner worden omuiteindelijk tot nul herleid te worden. Als de afstand nul wordt, is het teken om de routeringstabel aan te sprekenom de volgende route te bepalen. Ditmaal zal de achterwaartse routeringstabel aangesproken worden omdattrainDirec on op Backward staat.

Naast de routeringstabellen om de volgende route te bepalen, bestaan er gelijkaardige routeringstabellen om devolgende sensor van een trein te bepalen. De volgende sensor van een trein wordt bijgehouden in het a ribuutNextSensorName. De routeringstabellen die de volgende sensor vastleggen, gelden enkel voor de freerun trei-nen. Voor de LES treinen wordt de volgende sensor bepaald uit de lijst NextSensors waarin alle sensoren vantraject opgenomen zijn. Als een sensor hoog wordt, zal de controller de volgende sensor van alle ac eve treinenoverlopen. Indien er geen match gevonden wordt, zal de controller ervan uitgaan dat er een nieuwe freerun treinaanwezig is. Bijgevolg wordt er door de controller een nieuwe freerun trein geac veerd.

Het gebruik van gesplitste routeringstabellen voor zowel de routes als voor de sensoren kan op het eerste zichtoverbodig lijken. Ze zijn echter noodzakelijk om onnauwkeurigheden in het model en de foutenmarge op deposi e coördinaten bepaald door visie, op te vangen. Aangezien de sensoren dicht bij het begin en het einde vande route geposi oneerd zijn, is het mogelijk dat de sensor op de volgende route reeds hoog wordt terwijl de treinzich nog op de vorige route bevindt. Hierdoor kunnen allerlei problemen optreden indien de routeringstabellenvan de routes en de sensoren niet gesplitst zijn.

Wat betre de routering van de treinen, zijn er een aantal beschouwingen over de opstelling die in rekeninggenomen moeten worden. Ten eerste zijn niet alle sporen voorzien van twee sensoren. Als er maar één sensoraanwezig is, zal het LES de volgende wissel mogelijks schakelen als de sensor hoog wordt. Aangezien de controllerop dezelfde input reageert om de volgende sensor van een freerun trein vast te leggen, bestaat het gevaar dat dewisselstand in de routeringstabel niet jdig aangepast is. Om dit probleem te verhelpen, wordt er gewerkt metde nega eve flank van de sensor input om in de routeringstabel te kijken. Op deze manier wordt er voldoendejd ingebouwd om zich te verzekeren van een correcte wisselstand.

Een ander probleem dat zich kan voordoen, hee te maken met het fenomeen van dender op de sensoren. Alseen trein op een sensor passeert, kan de sensor meerdere malen aan- en uitgaan. In het geval van freerun treinkan dit problemen veroorzaken. Wanneer de sensor hoog wordt, zal het a ribuut NextSensorName van de treinworden vastgelegd als de volgende sensor die in de routeringstabel gevonden wordt. Indien dezelfde sensoromwille van dender opnieuw hoog wordt, zal de controller de lijst van ac eve treinen aflopen om te zoeken welketrein de sensor als NextSensorName hee staan. Aangezien het a ribuut bij de eerst posi eve flank gewijzigd is,zal de controller geen match vinden en zal er verkeerdelijk van uitgaan dat er een nieuwe trein in de opstellinggeac veerd moet worden. Om dit probleem te verhelpen, wordt er slechts rekening gehouden met de eersteposi eve flank en wordt er vervolgens niet meer gereageerd op een posi eve flank van de sensor tot wanneer detrein de volgende sensor bereikt hee . Vooraleer dit gebeurt, is de sensor onbruikbaar voor andere treinen. Inde toepassing vormt dit geen probleem omdat het LES slechts één trein per spoor toelaat.

Om de discussie rond de routering af te ronden, wordt de aandacht op een laatste punt getrokken. Als de treinenzich uit het gezichtsveld van de camera bevinden, gebeurt de verplaatsing van de treinen in het Experior model opbasis van de induc eve sensoren. Wanneer de treinen in visie gedetecteerd zijn, gebeurt de verplaatsing in hetmodel uitsluitend op basis van de posi e informa e van visie. De posi e van een trein wordt bijgevolg niet gecor-rigeerd of bijgestuurd wanneer het op een sensor passeert. Dit hee opnieuw temakenmet onnauwkeurighedenin het model en de foutenmarge op de posi e coördinaten van visie. Indien er een bijsturing zou gebeuren, zouer visuele hinder ontstaan door schokkerige bewegingen. Het nadeel is echter dat er niets mis mag lopen in visie,anders blij de trein op een route geblokkeerd staan.

49

Overzicht van de controller

In figuur 3.27 wordt een flowchart weergegeven die een overzicht gee van de besproken punten in deze sec e.De flowchart toont dat de controller in drie gevallen ac es onderneemt: een statusverandering van een induc evesensor, een LES bericht of een bericht van visie. In de flowchart is duidelijk te zien hoe de treinen geac veerdworden, hoe de routering gebeurt en welke berichten met de verschillende modules uitgewisseld worden.

Figuur 3.27: Overzicht werking controller

50

4 Conclusies

De masterproef hee tot doel om het gebruik van AR in combina e met SCADA te demonstreren op een demoopstelling. De opstelling is PLC gestuurd en simuleert een logis ek proces. Om het proces te monitoren, wordtExperior als SCADA toepassing gebruikt en gekoppeld aan een visie systeem. Het visie systeem filmt de opstellingvia een webcam die op een vaste posi e gemonteerd is. Op basis van de wisselwerking tussen Experior en visiezijn een aantal concrete doelstellingen uitgewerkt.

De eerste doelstelling is de implementa e van een objectdetec e algoritme in het visie systeem en de terugkop-peling van de posi es van de treinen naar Experior. Op deze manier wordt het virtuele model in Experior verrijktmet informa e uit de reële wereld en is het SCADA systeem niet enkel meer a ankelijk van klassieke inputsen-soren om toestandsveranderingen te registreren. Het resultaat is een vlo e, real- me visualisa e van het proceswaarbij de gebruiker steeds op de hoogte is van de toestand van het object.

Demoeilijkheid van de objectdetec e schuilt in de beperkte hoeveelheid beschikbare pixels van de objectenwaar-door het aantal te extraheren features gelimiteerd is. Het uitgewerkte algoritme is gebaseerd op dynamischeachtergrondsubtrac e. Het model is bijgevolg in staat om zich aan te passen aan wisselende omgevingsomstan-digheden en om te ini aliseren zondermanuele tussenkomst. Het nadeel van hetmodel is dat s lstaande objectenna verloop van jd in de achtergrond opgenomenworden. Om dit probleem op te vangen, wordt gebruik gemaaktvan informa e die in het Experior model aanwezig is.

Naast objectdetec e, is het visie systeem voorzien van markerdetec e en logica. De markerdetec e laat toe omeen 3D wereldcoördinatenstelsel te definiëren. Hiermee kunnen de pixelcoördinaten van gedetecteerde objec-ten vertaald worden naar de corresponderende wereldcoördinaten. Omgekeerd kunnen virtuele 3D elementencorrect in het beeld geposi oneerd worden. De logica zorgt voor de analyse van de blobs die het resultaat zijnvan de achtergrondsubtrac e en verzorgt de communica e met het Experior model. Experior verwerkt de posi einforma e in het model en valideert de nauwkeurigheid ervan door de vergelijking te maken met de informa evan de inputsensoren in de opstelling.

De tweede doelstelling van de masterproef bestaat uit de verrijking van de camerabeelden met produc e rele-vante informa e via AR. AR biedt interessante opportuniteiten om processen rechtstreeks te monitoren op dewerkvloer en om de operator in het uitvoeren van zijn taken te ondersteunen. In de literatuurstudie wordt eenoverzicht gegeven van industriële concepten en ontwikkelingen die te vinden zijn in de vakliteratuur. Op basishiervan zijn een aantal scenario's uitgewerkt om het nut van AR te tonen op het vlak van onderhoud, proces mo-nitoring en logis ek. Visie verwerkt de informa e verkregen van Experior en presenteert de informa e als AR ophet camerabeeld. Het systeem is interac ef waardoor de gebruiker het gewenste object kan selecteren. Naarge-lang de login van de gebruiker wordt de relevante informa e in het beeld geprojecteerd. Het visie systeem is instaat om alle taken real- me af te handelen.

De masterproef dient als aanzet om de verworven inzichten te exporteren naar mobiele toepassingen zoals deuitbreiding naar een tablet. Tablet's zijn tegenwoordig ruim verspreid en zijn de volgende logische stap om hetonderzoek verder te ze en. In de literatuurstudie is gebleken dat er weinig AR concepten uitgegroeid zijn tot vol-waardige applica es in de industrie. De belangrijkste redenen zijn ongetwijfeld terug te vinden in de huidige be-perkingen van de beeldanalyse op het gebied van de real- me verwerking en van de herkenning van de omgeving.De meeste realisa es steunen nog steeds op de detec e van markers waardoor de algemene toepasbaarheid enherbruikbaarheid van applica es sterk beperkt wordt. De kans is groot dat de intrede van nieuwe technologieënzoals Google Glass en Google Project Tango in combina e met de constante evolu e van beeldanalyse technie-ken, uiteindelijk de doorstoot van AR op de werkvloer zal betekenen. Door het zicht van de operator op termijn

51

te ondersteunen zijn de opportuniteiten van AR op vlak produc e efficiën e en kwaliteit onbetwist.

52

Literatuurlijst

[1] J. Co yn, ``Produc eso ware.'' Cursus TPA, 2014.

[2] K. Vandormael, ``Mo on Capturing,'' Master's thesis, Transna onale Universiteit Limburg, 2006.

[3] T. Bouwmans, F. E. Baf, and B. Vachon, ``Background Modeling using Mixture of Gaussians for ForegroundDetec on - A Survey,'' Recent Patents on Computer Science, vol. 1, pp. 219--237, November 2008.

[4] T. Gevers and A. Smeulders, ``Image search engines: An overview,'' June 2013. Faculty of Science Universityof Amsterdam.

[5] S. Srivastava and P. Raviraj, ``A Survey and Compara ve Analysis of Moving Object Detec on and Tracking,''Interna onal Journal of Electronics and Communica on Engineering (IJECE), vol. 2, pp. 59--68, 2013.

[6] J. Dours, ``Camera volgsysteem voor monitoring van pa ënten,'' Master's thesis, Hogeschool voor Weten-schap & Kunst vzww, 2010.

[7] Z. Wei, L. Zhang, H. Kim, Y. Kim, and J. Kim, ``An improved object tracking algorithm based on camshi com-bined with ac ve contour and kalman filter,'' Journal of Informa on and Computa onal Science, vol. 11:6,pp. 1753--1764, 2014.

[8] J. Canny, ``A computa onal approach to edge detec on,'' IEEE Transac ons on Pa ern Analysis andMachineIntelligence, vol. PAMI-8, pp. 679--698, November 1986.

[9] G. Bradsky, ``Computer vision face tracking as a component of a perceptual user interface,'' Proc. of the IEEEWorkshop on Applica ons of Comp. Vision, pp. 214--219, 1998.

[10] W. Robins, ``Robust video tracking through mul ple occlusions,'' 2009.

[11] S.-C. Cheung and C. Kamath, ``Robust background subtrac on with foreground valida on for urban trafficvideo,'' Eurasip Journal on Applied Signal Processing, vol. 14, 2004.

[12] B. Brutzer, B. Hoferlin, and G. Heidemann, ``Evalua on of background subtrac on techniques for video sur-veillance,'' Computer Vision and Pa ern Recogni on (CVPR), IEEE conference on, pp. 1937--1944, 2011.

[13] C. Stauffer andW.Grimson, ``Adap ve backgroundmixturemodels for real- me tracking,'' in IEEE Conferenceon Computer Vision and Pa ern Recogni on (CVPR 1999), pp. 246--252, 1999.

[14] P. Belet, ``Analyse van videobeelden in transpor oepassingen,'' Master's thesis, Universiteit Gent, 2011.

[15] Z. Zivkovic and F. van der Heijden, ``Efficient adap ve density es ma on per image pixel for the task ofbackground subtrac on,'' Pa ern Recogni on Le ers, pp. 773--780, 2006.

[16] TNO, ``Herkenning van digitale informa e.'' TNO-rapport, 2010.

[17] R. Azuma, ``A survey of augmented reality,'' Presence: Teleoperators and Virtual Environments, pp. 355--385,1997.

[18] ``Project tango.'' h ps://www.google.com/atap/projec ango/project (datum van opzoeking 10/08/14).

[19] ``Google glass.'' h p://www.google.com/glass/start/ (datum van opzoeking 28/07/14).

[20] M. Desmet, ``Augmented reality toepassingen in architectuur en construc e,'' Master's thesis, UniversiteitGent, 2013.

53

[21] G. Murru, ``Augmented reality framework for the 3d interac ve mobile representa on of the ancient forumof nerva,'' Master's thesis, Universita di Roma, 2012.

[22] A. O. Alkhamisi and M. M. Monowar, ``Rise of augmented reality: Current and future applica on areas,''Interna onal Journal of Internet and Distributed Systems, vol. 1, pp. 25--34, 2013.

[23] N. Navab, ``Industrial augmented reality (iar): Challenges in design and commercializa on of killer apps,'' inProceedings of the Second IEEE and ACM Interna onal Symposium onMixed and Augmented Reality (ISMAR2003), 2003.

[24] R. Azuma, Y. Baillot, R. Behringer, and S. Feiner, ``Recent advances in augmented reality,'' IEEE ComputerGraphics and, vol. 21, pp. 34--47, 2001.

[25] P. Fite-Georgel, ``Is there a reality in industrial augmented reality?,'' inMixed andAugmented Reality (ISMAR),2011 10th IEEE Interna onal Symposium on, 2011.

[26] M. Rakyta, P. Bubenik, and F. Horak, ``Use of augmented reality in produc on system,'' in 7th Annual Inter-na onal conference 2013 Manufacturaing Systems Today and Tomorrow, 2013.

[27] G. Klein, Visual Tracking for Augmented Reality. PhD thesis, University of Cambridge, Department of Engi-neering, 2006.

[28] ``Bechhoff.nl.'' h p://www.beckhoff.nl/ (datum van opzoeking 15/07/14).

54