botsingen vermijden bij autonome voertuigenlib.ugent.be › fulltxt › rug01 › 001 › 805 ›...

Tanguy Claeys, Alexander Van Caekenberghe

Botsingen vermijden tussen autonome voertuigen

Academiejaar 2010-2011Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Jan MelkebeekVakgroep Elektrische energie, Systemen en Automatisering

Master in de ingenieurswetenschappen: werktuigkunde-elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Begeleider: Nicolae-Emanuel MarinicaPromotor: prof. dr. René Boel

VOORWOORD i

Voorwoord

In de naschokken van de financiele crisis van 2008 lag de financiele wereld in puin en

stond de economie wereldwijd op een laag pitje. Als gevolg hiervan werd er overal

gedesinvesteerd en probeerde de industrie geldbesparende maatregelen te treffen.

Een van die maatregelen was het ontslaan van werknemers, aangezien er toch niet

voldoende werk beschikbaar was. De overheid heeft toen maatregelen getroffen

om jobs te sparen, door bijvoorbeeld de tijdelijke (economische) werkloosheid voor

arbeiders in tijden van crisis toe te staan. In die tijden van economische onzekerheid,

wanneer werknemers eerder een last lijken dan een zegen, komt het indistrualistische

reflex opnieuw naar boven: ”Zou het niet makkelijker zijn om robots in te zetten,

die kunnen in- en uitgeschakeld worden naar believen?”

Het is in deze context dat het concept van deze thesis ontstond. Een bedrijf gelegen

in de haven van Antwerpen onderzocht de mogelijkheid om de vrachtwagenbestuur-

ders, die door middel van hun carriers de containers van het schip naar het contai-

nerpark brachten, te vervangen door een automatische besturing. Om een zekere

tijdsdruk te creeeren, werd dit onderzoek een competitie tussen drie universiteiten.

De aanpak van het probleem vergde een trade-off tussen twee belangrijke aspecten:

veiligheid en stiptheid. In deze scriptie proberen we deze trade-off tot het uiter-

ste te drijven, op de grens van de nodige veiligheid en de hiermee gepaard gaande

stiptheid.

Voor het bedrijf zou dit op korte termijn een investering vergen, doch verdeeld over

de levensduur van het systeem. Deze scriptie bevestigt nog maar eens de trend dat

de wereld zichzelf aan het automatiseren is. De bedrijven zullen steeds meer tot

het besef komen dat de (angstwekkende) investering de stap waard zal zijn, als ze

hun balansen opmaken en de posten ”leningen” en ”afschrijvingen” vergelijken met

de loonkost van het vorige jaar. Door verder doorgedreven automatisering zal de

Belgische industrie efficienter worden en zo weer concurrentieel worden in Europa

en in de wereld.

De productieband heeft een nieuw economisch tijdperk ingeluid. Wij geloven dat

volledig autonome robotten de volgende stap zijn. Maar aangezien dit nog toekomst-

muziek is, zullen we beginnen met dit ’eenvoudiger’ probleem omtrent autonome

voertuigen. Daarom hebben wij dit onderwerp gekozen, omdat wij als regeltechnie-

kers graag ons steentje willen bijdragen aan deze positieve evolutie.

Wij danken onze thesisbegeleider, Ir. N.-E. Marinica, evenals onze promotor, Prof.

Dr. Ir. Boel, voor de hulp en het vertrouwen in ons werk. Graag bedanken we ook

Ir. J. Rogge voor de hulp en opbouwende kritiek bij de tussentijdse evaluaties.

Tanguy Claeys

Alexander Van Caekenberghe

juni 2011

TOELATING TOT BRUIKLEEN iii

Toelating tot bruikleen

“De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen

en delen van de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzon-

der met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het

aanhalen van resultaten uit deze scriptie.”

Tanguy Claeys


juni 2011

Botsingen vermijdentussen

autonome voertuigendoor

Tanguy Claeys


Scriptie ingediend tot het behalen van de academische graad van

Burgerlijk Ingenieur in de werktuigkunde-elektrotechniek

optie automatisering en regeltechniek

Academiejaar 2010–2011

Promotor: Prof. Dr. Ir. R. Boel

Scriptiebegeleider: Ir. N.-E. Marinica

Faculteit Ingenieurswetenschappen

Universiteit Gent

Vakgroep Elektrische Energie, Systemen en Automatisering

Voorzitter: Prof. Dr. Ir. J. Melkebeek

Samenvatting

In dit werk wordt een concept onderzocht omtrent het automatiseren van een kade.Door de beschikbare rijzone te verdelen in horizontale banen en aangepaste ver-keersregels te ontwerpen tracht men botsingen en deadlocksituaties te vermijden.Verder worden methodes gesuggereerd ter vergelijking van verschillende regelsyste-men voor autonome voertuigen. De simulatieresultaten zijn zeer aannemelijk voorkleine kadelengtes en kunnen worden veralgemeend worden naar grotere dimensies,mits toevoeging van een itelligente scheduler die de horizontale verzadiging voor-komt.

Trefwoorden

autonome voertuigen, ontwijken van botsingen, baansysteem, verkeersregels

Avoid collisions between autonomousvehiclesTanguy Claeys

Alexander Van CaekenbergheSupervisor(s): Prof. Dr. Ir. R. Boel, Ir. N.-E. Marinica

Abstract - This article proposes a new con-cept on the automation of a dock. By dividingthe available zone for transportation of contai-ners into lanes, and applying traffic rules for thecarriers, collisions and deadlock seek to be avoi-ded. Furthermore, this article proposes some me-thods to quantify the quality of different systemsfor automated vehicles.

Keywords - Automated vehicles, avoid collisi-ons, lane system, traffic rules

I. DESCRIPTION

The purpose of this article is to design a set of ru-les to automate a dock. The transportation of containersusing carriers is nowadays done manually, whereas an au-tomated system could be more efficient, less dangerousand more lucrative. In order to solve this problem, afew systems have already been designed, but few excelas they have to be reset manually several times a day, orare still in the development phase.

The client has given clear specifications concerningthe configuration of the docking site and the straddlecarriers. In a first phase, the carriers should be alteredas little as possible and the only thing that should be de-veloped is a strategy for the transportation of containersby straddle carriers between the quay and the stack area.

In this abstract, we will first propose a structuredsystem, supposed to have inherently less collisions anddeadlock, with several specifications, such as the quan-tification of the available area, the implementation ofthe applied traffic rules and the necessary hardware. Se-condly, we will elaborate some methods to compare se-veral systems for automated vehicles. As the number ofthose automated systems will surely grow in the comingyears, one will have to choose based upon some criteria.

II. CONCEPT

In a first phase, the important features of ’a’ stra-tegy are defined, being in decreasing importance: thenumber of collisions, the number of deadlock and thesatisfaction of the deadline. The comparison is madebetween a ’direct’ system, where the carrier follows theshortest path to its goal, and a so-called ’indirect’ sy-stem, also called a ’horizontal’ system due to the factthat carriers generally drive in a parallel way as the freezone is divided in lanes. The decision is made to developthe lane strategy with absolute priority for turning mo-vements. An extra argument is given based upon theextent of the risk zone in both strategies, reflected inthe computing power required in the carrier processor.The risk zone is the zone or optical data a carrier has toobserve and process in order to have enough informationto implement the rules. As proved in this paper, the riskzone in the lane system is at all times smaller than theone in the direct system.

In order to prove the effectiveness of the lane stra-tegy, there is a need to simulate real time operations.Therefore the dock environment needs to be modelledin MATLAB®. The two-dimensional system has beengiven two axes to allow positioning, as can be seen onfigure 1.

Fig. 1 :Model of the driving area divided into lanes, with carriers.As can be seen the (unique) driving sense has been chosen to be(starting from the stack): right, right, left, left, right (x3)

One of the (safety) constraints is that the quay lanes(lanes 5, 6 and 7) should be as carrier-free as possible. Wehave therefore 4 remaining lanes allowing high-densitytraffic. Given the direction configuration (1 - right, 2 -right, 3 - left, 4 - left), another choice has to be made asto which lanes should be coupled together. In this sectiona few systems are explored, such as the ’roundabout’ sys-tem (lane 1 and 4 are coupled, so are 2 and 3, resulting inan equal distribution of 50 % of the carriers in each lane-subsystem), the ’eight’ system (same as roundabout, butcoupling of lane 1 and 3), and the ’efficient’ system (thecarrier chooses the lane closest to its destination, butloss of control over carrier density in lane-subsystems).The preference is given to the ’efficient’ system in thispaper. As the entire system is based upon optical detec-tion (due to parasitic reflection of other electromagneticcommunication-waves on the containers), some practicalsolutions are offered, such as discrete-frequency directio-nal indicators.

The structure of the simulation program has beendivided into several layers, reflected in distinct programs:

1. Scheduling (highest) level: random generated se-quence of tasks.

2. Physical surroundings (lowest) level: acts as phy-sical and temporal boundary.

3. Control unit of the carrier (central) level: Theactual set of programs to be implemented, repre-senting the rules and the decision center of eachcarrier. At this level, the control units calculatesits waypoints ( = 3 critical points, rather thana whole reference curve), controls the speed andasks permission to turn.

III. ALGORITHM

The programs are explained one by one, trying togive the reader a complete overview of the variables andthe manipulations on the different objects.

1. Scheduling levelAs the advanced scheduler is not a part of the cen-

tral issue (being the set of rules), the tasks have beenchosen as random generated numbers, representing aplace in the stack or a place on the quay lanes. As thiscommand is extremely short, it has been added to thephysical surrounding algorithm, rather than to have its

own program.

2. Physical surroundingsAs the name transpires, this is the program in which

all the physical variables have to be initialized, and soare the variables concerning the simulation (e.g. thesimulation duration). This programs contains the maintime loop, giving the robots the share of data they wouldbe able to obtain in reality. This is the visual informa-tion within their line of sight. Each (discrete) time step,the robots will move to their next position and the su-pervisor matrix will be updated.

3. Control unitThe control unit is represented by the object Ro-

bot. During the simulation, it memorizes its properties

and manipulates those properties by using predefinedmethods. Among those methods are all other subrou-tines reflecting the chosen set of rules. Those discussedin this paper are:

• Draaimogelijkheid: Gives permission to a carrierto begin its turning movement.

• Vertraag: Given the nearby carriers, corrects thespeed and even performs emergency stops.

• Verplaats: Moves the carrier on the map.

• Frontale-Ybotsing: Avoiding collisions whenboth carriers are in a turning movement, thusboth in a priority position.

• Verplaats: Visualizes the trajectory and updatesthe coordinates.

IV. RESULTS

Simulations have been made of the above-describedsystem and methods have been developed in order to in-terpret those results:

• Based upon the number of deadlocks and collisi-ons:Simulating 15 times 8 hours, the collisions anddeadlock were recorded. It would seem that atmaximum required carrier density no collisionsappeared, although they were present at higherdensities. These could be changed into deadlockby adjusting the risk zone. The simulation gavean average of 1.53 deadlocks for 8 hours. In orderto compare two systems, we introduced a dead-lockparameter, χdeadlock,n.

1 2

3 4

5 6

7 8

910

4060

80100

120140

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

# robots

tijd (sec)

Pro

babili

teit

Fig. 2: Relation between the lead time of the ’pick’assignments and the growing number of carriers (stacklength = 200 m, number of carriers = 1 - 10, numberof simulations = 15, simulation time = 28800 s, fixedtrajectory (pick = (lane 5,80), place = (lane 0,-70))

• Based upon the distribution of the lead-time of

one carrier with a specific trajectory:

This method requires one carrier to have a fixedtrajectory, repeating it over and over again. Du-ring the simulation, the distribution of its lead-time is observed. As the number of carriers canbe raised, the relation between the carrier den-sity and the distribution can also be observed. Inthis article, the obtained β-distribution is charac-terized by its modus and its 95e centile. Thebig amount of information resulting from this issummarized in two parameters, αModus,n,k andγ95,n,k, which can be used to compare differentsystems. Based on the 95e centile, a buffer timeis introduced , to be used by the scheduler.

• Based upon the ratio lead-time divided by the

shortest distance (= corrected average speed): Asthe 95e centile is trajectory-bound (and so re-cording and calculating it would be very work-intensive, requiring a lot of tests) , another me-thod is sought after. The answer is found withthe corrected average speed. The trajectories arebeing divided in groups based upon their geome-tric distances, after which 95e centile from thecorrected average speed is calculated. This me-thod gives a rough estimate of the buffer time,without the necessity of elaborate testing. Asthis parameter is not trajectory-bound, it’s alsoa good quality characteristic.

• Discussion concerning deadlock depending on

partial carrier density: The simulations have al-ways been made on a dock with length 200 me-ters for computing reasons, whilst the results aregeneralized to larger maps with similar carrierdensity. In this paragraph, this assumption ischecked. Several problems seem to appear:

– Horizontal saturation: If the two firstquay lanes are both full of carriers, theones in the stack can’t come out. A solu-tion is proposed in the article.

– Vertical saturation: A high concentrationof carriers can still generate (rare) dead-lock between multiple carriers.

V. CONCLUSIONS

This set of rules, based on lanes, gives satisfactory re-sults with small quay dimensions. Otherwise, the above-mentioned problems occur which are typical for the lanesystem (as the direct system would not have deadlockin the stack). However, the missing, intelligent schedu-ler still has to be designed and could be used to counterthe weak points of this system. This would be a subjectfor further research and development. The main issueagainst this system is the horizontal saturation on thefirst two lanes.

Appendix A: Users manualAppendix B: Quality sheet

INHOUDSOPGAVE vii

Inhoudsopgave

Voorwoord i

Toelating tot bruikleen iii

Overzicht iv

Extended Abstract v

Inhoudsopgave vii

1 Omkadering 11.1 Probleemstelling en doelstelling . . . . . . . . . . . . . . . . . . . . . 11.2 Fysische omschrijving en terminologie . . . . . . . . . . . . . . . . . . 3

1.2.1 Omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.3 Kade- en stackkraan . . . . . . . . . . . . . . . . . . . . . . . 6

2 Concept 72.1 Horizontaal versus verticaal systeem . . . . . . . . . . . . . . . . . . . 7

2.1.1 Vergelijking van de systemen . . . . . . . . . . . . . . . . . . . 72.1.2 Keuze van het systeem . . . . . . . . . . . . . . . . . . . . . . 102.1.3 Risicozone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Modellering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Visualisatie in Matlab . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Indeling en keuze van de banen . . . . . . . . . . . . . . . . . 132.2.3 Fysische aanpassing ten gevolge van de systeemkeuze . . . . . 15

2.3 Structuur van het simulatieprogramma . . . . . . . . . . . . . . . . . 172.3.1 Hoogste niveau : scheduling . . . . . . . . . . . . . . . . . . . 172.3.2 Laagste niveau : fysieke omgeving . . . . . . . . . . . . . . . . 182.3.3 Middelste niveau : besturingsonderdeel van de carrier . . . . . 18

3 Algoritme 203.1 Fysieke omkadering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Fysieke initialisaties . . . . . . . . . . . . . . . . . . . . . . . 213.1.2 Initialisatie van de carriers . . . . . . . . . . . . . . . . . . . . 21

INHOUDSOPGAVE viii

3.1.3 Initialisaties van tools voor simulatiedoeleinden . . . . . . . . 223.1.4 Initialisatie van de kunstmatige sensoren . . . . . . . . . . . . 223.1.5 Initialisatie van de visualisatie . . . . . . . . . . . . . . . . . . 233.1.6 De reele fysieke tijdstap . . . . . . . . . . . . . . . . . . . . . 23

3.2 Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Waypoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.1 waypoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2 updateWaypoint . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4 Verplaats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5 Draaimogelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.6 Vertraag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.7 Frontale verticale botsing . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Resultaten en evaluatie 534.1 Bespreking van het aantal botsingen en deadlocksituaties . . . . . . . 534.2 Bespreking van de verdeling van de lead-time . . . . . . . . . . . . . 57

4.2.1 Resultaat van de simulatie en verschil tussen de pick-opdrachtenen de place-opdrachten . . . . . . . . . . . . . . . . . . . . . . 58

4.2.2 Bespreking van de modus en het gemiddelde . . . . . . . . . . 614.2.3 Bespreking van het 95e percentiel . . . . . . . . . . . . . . . . 63

4.3 Bespreking van de ratio lead-time gedeeld door de afstand in vogelvlucht 664.4 Bespreking van de kans op deadlock op basis van de partiele carrier-

densiteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5 Conclusies en verder onderzoek 755.1 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2 Verder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3 Kwaliteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A Gebruikshandleiding 77

B Karakteristieke fiche 79

Lijst van figuren 80

Lijst van tabellen 82

OMKADERING 1

Hoofdstuk 1

Omkadering

1.1 Probleemstelling en doelstelling

De probleemstelling, zoals door Prof. Dr. Ir. Boel werd geschetst op Plato, wordt

hieronder als volgt samengevat:

”Autonoom aangestuurde voertuigen moeten in een open terrein (waar er

geen obstakels zijn, behalve andere voertuigen) taken uitvoeren, waarbij

elke taak erin bestaat dat een voertuig dat zich in rust bevindt op tijdstip t

in (x,y) tegen het tijdstip t+D de lokatie (xf ,yf) moet bereikt hebben. De

supervisor die de taken toewijst aan individuele voertuigen geeft ook aan

die voertuigen een gesuggereerd referentietrajectorie mee. Maar uiteraard

bestaat er het gevaar dat verschillende referentietrajectorien met elkaar

in conflict zijn, en dat voertuigen zouden botsen als ze zonder meer die

referentietrajectorie zouden volgen. Daarom is elk voertuig uitgerust met

een sensor die in een zeker gebied rondom de huidige positie van het

voertuig obstakels detecteert. Op basis van die informatie moeten de

voertuigen hun trajectorie aanpassen zodat ze veilig en met zo weinig

mogelijk tijdverlies hun bestemming bereiken.”

Verder werden de doelstellingen als volgt voorgesteld, in overeenkomst met de pro-

motor:

”Doel van de scriptie is om een strategie uit te werken die alle voertuigen

zonder botsingen en voor hun deadline t + D naar hun bestemming laat

rijden. Gezien de aanwezigheid van het vele metaal van de containers,

moet er worden opgelet dat er geen ongewenste reflecties van elektro-

magnetische (communicatie)signalen optreden. Bijgevolg bekijken we de

1.1 Probleemstelling en doelstelling 2

situatie waar het radiocommunicatiekanaal faalt. De voertuigen moeten

nu autonoom in staat zijn hun bestemming te bereiken (dit gaat dan om

een soort verkeersregels die ze steeds zullen moeten respecteren als er mi-

nimale communicatie mogelijk blijkt). Doel van het onderzoek is om via

analyse, en via simulatie goede terugkoppelregelaars en dus verkeersregels

te ontwerpen. Verder zal een methode ontworpen worden om de kwaliteit

van een stel regels te quantificeren.”

De voorwaarden worden hieronder als volgt samengevat:

• Set regels: Werk een geheel van verkeersregels uit die een trade-off optima-

liseert tussen

1. Veiligheid: Botsingen zijn onaanvaardbaar, aangezien dit hoge (materiele)

kosten met zich meedraagt.

2. Snelheid: Elke container moet naar de kade gebracht worden in een tijd-

spanne kleiner dan zijn deadline (dit is de vooropgeplande transporttijd

+ buffertijd). Dit betekent dat de lead-time (dit is de tijd vanaf het ver-

laten van de stack, de ’pick’, tot het aankomen op de gewenste plaats, de

’place’) kleiner moet zijn dan de (meegegeven) deadline. Dit is cruciaal

voor het goede verloop van de haven. Een deadlocksituatie (dit is een

situatie waarin er geen voorrang heerst, minstens twee carriers staan dus

stil, en zullen blijven stilstaan) zou een manuele herinitialisatie vergen,

en is dus zeker niet gewenst.

• Afgebakend terrein: Zoals te zien op figuur 1.1, zijn er geen obstakels

aanwezig, dus dient er enkel uitgegeken te worden voor, en te reageren op,

de aanwezigheid van de andere robots.

• Minimale communicatie: Radiocommunicatie is uitgesloten, vandaar dat

een centrale ’scheduler’, die alle informatie van de robots verzamelt en ver-

volgens verspreidt niet van toepassing is. Wat wel toegestaan is, zijn visuele

signalen, waargenomen door te implementeren sensoren.

• Maat voor kwaliteit: Om de verschillende sets te beoordelen en met elkaar

te kunnen vergelijken, zal een methode moeten worden uitgewerkt die de kwa-

liteit kan quantificeren. Een mogelijkheid is het vergelijken van de distributies

van de lead-time, bij identieke transportopdrachten.

1.2 Fysische omschrijving en terminologie 3

Figuur 1.1: Overzicht van het dok

1.2 Fysische omschrijving en terminologie

1.2.1 Omgeving

Op figuur 1.1 zijn volgende zones te onderscheiden:

1. Het vrachtschip: Dit is het vertrekpunt of de bestemming van de containers.

Deze worden door een kraan van de boot gehesen, zie figuur 1.3, en geplaats

op ’de kade’, in afwachting van het ophalen door een vrachtwagen.

2. De stack: Deze stockageplaats voor containers zal in het vervolg van deze

scriptie ’de stack’ genoemd worden. Ook dit is het vertrekpunt of de bestem-

ming van de containers.

3. Zone tussen kade en stack: In deze zone zullen de vrachtwagens (of ’car-

riers’) rondrijden om de containers op te halen, of naar de gewenste plaats te

brengen. In paragraaf 2.1.1 wordt verder ingegaan op de mogelijke indelingen

van deze zone.


1.2.2 Carriers

Figuur 1.2: Een carrier

De bedoeling is om op een strook van 1500 meter een veertigtal carriers te laten

rijden. Elke carrier kan maximaal een container per traject vervoeren. De carriers

zien er uit zoals op figuur 1.2. Op figuur 1.3 is te zien hoe op de kade 3 containers

naast elkaar geplaatst zijn. Indien er onder de kadekraan precies 3 carriers moeten

passen, zullen deze ook een minimale breedte moeten hebben, voor de stabiliteit van

de kadekraan. De minimale breedte van de carrier is gelijk aan de breedte van de

container, dit wil zeggen dat de wielen van de carrier voor en achter de container

zouden staan. Maar deze constructie levert twee problemen op:

1. Te grote doorbuiging van de carrier in de langsrichting ten gevolge van het

gewicht van de container. De steunpunten (wielen) staan te ver uit elkaar.

2. Onder de kadekraan kunnen de carriers niet meer doorrijden. Indien drie

containers naast elkaar staan, en er wordt erop gerekend dat de carriers even

breed zijn als de containers, dan staan die containers letterlijk tegen elkaar en

kunnen de carriers niet meer doorrijden.

Vandaar de voorgestelde constructie, in een omgekeerde U-vorm. De andere belang-

rijke eigenschappen van de carriers zijn samengevat in tabel 1.2.2:


Eigenschap Eenheid

Draagvermogen ton 40

Gewicht ton 43

Draaicirkel (diameter midden) m 7,5

Maximale snelheid (geladen) km/h 30

Motorvermogen kW 272

Tabel 1.1: Eigenschappen van een carrier

Bemerk dat het totaal maximaal gewicht van een geladen carrier 83 ton kan zijn .

Toch gaan we in deze scriptie de inertie verwaarlozen. Indien we dit niet zouden

doen, zou de rekentijd van de simulatie sterk toenemen, aangezien de versnellingen

steeds berekend zouden moeten worden. Daar onze scriptie hoofdzakelijk handelt

over de verkeersregels, en niet zozeer over de exacte fysische simulatie, is dit aan-

vaardbaar.

Verder wordt vermeld dat op de carrier een/verschillende richtingsaanwijzers zullen

bevestigd worden. Deze zullen, zoals in het alledaags verkeer, de gewenste richting

aanduiden. Dit concept wordt verder uitgewerkt in paragraaf 2.2.3.

Zoals eerder vermeld, is er minimale communicatie tussen de carriers gewenst. Dit

is een gevolg van de nefaste reflecties op de grote hoeveelheid ijzer in de stack. Er

wordt in deze scriptie wel van uit gegaan dat de carriers ten allen tijde hun eigen

coordinaten ( x en y, zie paragraaf 2.2.1) kennen. Verder wordt er uitgegaan van

visuele sensoren (camera’s) en een radar, die zowel de (relatieve) positie kan meten

als de (relatieve) snelheden kan berekenen.


1.2.3 Kade- en stackkraan

Figuur 1.3: Kadekraan, carrier met container en stackkraan

Figuur 1.3 geeft weer welke stages de containers doorlopen:

1. De kadekraan: Deze kraan ’hangt’ over het schip en kan tot drie containers

naast elkaar plaatsen op de kade. Dit is de bottleneck van het systeem. Indien

hier vertragingen opgelopen worden, is dit een onherstelbaar verlies aan tijd

en dus geld. Het is dus cruciaal dat er op elk tijdstip maximaal 2 containers

staan op de kade, of anders gezegd, dat de carriers tijdig hun container komen

oppikken.

2. De carriers: Zijn besproken in sectie 1.2.2.

3. De stackkraan: Deze kraan rijdt op rails en ’schuift’ over een rij containers

(maximaal 3 containers hoog).

In deze scriptie beschouwen we enkel het verkeer tussen de kade en de stack. Dit be-

tekent dat de kadekraan en de stackkraan niet tot het bestek van deze uiteenzetting

behoren. Er wordt van uit gegaan dat overal waar een container geplaatst wordt,

de kadekraan hem quasi-onmiddelijk zal oppikken, en zo ook voor de stackkraan.

CONCEPT 7

Hoofdstuk 2

Concept

2.1 Horizontaal versus verticaal systeem

2.1.1 Vergelijking van de systemen

Alvorens een stel regels uit te werken, is het nodig om te conceptualiseren. Elk

systeem moet worden onderworpen aan een beschouwing inzake de risico’s vermeld

in sectie 1. Deze risico’s zijn schematisch voorgesteld in figuur 2.1 en hieronder

opgesomd:

• Botsingen: Hoogste prioriteit inzake risico’s.

• Deadlocksituatie: Tweede prioriteit inzake risico’s.

• Deadline halen: Laagste prioriteit, doch noodzakelijk voor het goede verloop

van de havenactiviteiten, zoals uitgelegd in paragraaf 1.2.2.

Figuur 2.1: Trade-off tussen de verschillende doelstellingen

Twee systemen kunnen bedacht worden:

2.1 Horizontaal versus verticaal systeem 8

1. Verticaal of direct systeem: Het belangrijkste kenmerk hier is het ontbre-

ken van elke quantificering, men deelt de rijzone dus niet op in banen. De

carrier volgt de kortste weg naar zijn doel (pick- of place-opdracht), vandaar

het ’direct’ systeem, zoals afgebeeld in figuur 1.1. De beschouwing van de

risico’s levert:

(a) Relatief gemiddeld risico op botsingen: Aangezien elke vorm van

structuur ontbreekt, zal op elk moment van het traject mogelijks een

botsing kunnen optreden. De mogelijke botsing kan ook van alle kanten

komen, wat betekent dat de risicozone zich 360 graden rond de carrier

zal uitstrekken. Indien er gevaar optreedt, zijn er twee oplossingen: ver-

keersregels (maar zonder structuur; deze regels zullen zowel een frontale

botsing als een zijdelingse botsing als een botsing van 30° tussen beide

banen moeten kunnen voorkomen) of een noodstop, met vervolgens een

ontwarring van de daaropvolgende deadlocksituatie. Dit geeft een rela-

tief hoge dataverwerkingstijd en een relatief moeilijke en uitgebreide set

regels.

(b) Relatief hoog risico op deadlocksituatie: Het is zonder meer gedu-

rende de hele rit mogelijk dat twee carriers frontaal recht tegenover elkaar

komen te staan. Dit kan nog ontward worden door verkeersregels. Maar

indien een derde carrier in hetzelfde risicogebied rondrijdt, kan de situatie

ingewikkelder worden, en kan er zelfs een deadlocksituatie optreden.

(c) Relatief laag risico op deadline missen: Aangezien dit een direct

systeem is, zullen de carriers meestal hun deadline halen. Hun referentie-

traject is het traject in vogelvlucht, dus optimaal indien ze alleen rijden.

De uitzondering is wanneer ze in een deadlocksitutie verstrikt geraken.


Figuur 2.2: Indeling van de rijzone in banen

2. Horizontaal of indirect systeem: Het belangrijkste kenmerk hier is de

quantificering: men deelt de rijzone op in 7 banen, zoals in figuur 2.2. De

carrier kan enkel 3, discrete, bewegingen uitvoeren: horizontaal (op de banen),

een draaibeweging (van 90°) en verticaal (loodrecht op de banen).

(a) Relatief laag risico op botsingen: Aangezien er structuur aan het

probleem is toegebracht, daalt de flexibiliteit van de trajecten. Maar

door deze structuur is er inherent minder kans op botsingen. Aangezien

de banen de ’normale’ trajecten zijn, kunnen de loodrechte stukken en de

draaibewegingen als ’gevaarlijk’ bestempeld worden en een hogere prio-

riteit krijgen. Dit speelt een belangrijke rol bij het voorkomen van een

deadlocksituatie. In het merendeel van de gevallen rijden de carriers ofwel

parallel aan elkaar ofwel op loodrecht kruisende banen.

(b) Relatief gemiddeld risico op een deadlocksituatie: Door de toege-

paste structuur zijn de mogelijke gevallen van deadlock sterk verminderd.

Deze kunnen dan door middel van specifieke regels voorkomen worden of

opgelost worden.

(c) Relatief gemiddeld risico op deadline missen: Aangezien dit sys-

teem inherent nooit de snelste weg neemt (dit is namelijk vogelvlucht, wat

het directe systeem beaamt), is de kans op het missen van de deadline

groter dan in het vorige geval. Dit is nog meer het geval indien gekozen

wordt voor een rotatief systeem waar er het minst mogelijk gestopt wordt

(zie verder).


2.1.2 Keuze van het systeem

Na de opsomming van de kenmerken moet er een keuze gemaakt worden omtrent

het systeem. Samenvattend staan twee systemen tegenover elkaar: een flexibel sys-

teem dat grote stiptheid toelaat, tegenover een minder flexibel, meer gestructureerd

systeem dat inherent minder gevoelig is aan deadlocksituaties en botsingen. Beide

systemen lijken hun sterke en zwakkere punten te hebben. Deze scriptie zal trachten

te bewijzen dat het horizontaal systeem, mits toevoegig van enkele regels een kleine

spreiding kan hebben op de lead-time, zodoende ook aan de stiptheidvoorwaarde te

voldoen, zie figuur 2.3.

Figuur 2.3: Overweging tussen beide systemen

2.1.3 Risicozone

Een bijkomend argument voor het horizontaal systeem is de volgende overweging

inzake het risicogebied. Het risicogebied van een carrier wordt als volgt gedefinieerd:

Algemeen, voor beide systemen: Voor elke carrier is het risicogebied

het gebied waarin een botsing zou kunnen plaatsvinden, en dus waarover

er nauwkeurige informatie nodig is.

Dit risicogebied is het gebied dat de desbetreffende carrier steeds in de gaten moet

houden. Zoals eerder vermeld in paragraaf 2.1.1 is de risicozone in het verticaal

systeem zonder uitzondering de hele zichtcirkel ( = 360 graden, zie figuur 2.4). Zoals

te zien is, kunnen carriers ten allen tijde uit alle hoeken een conflict veroorzaken.

Dit heeft als gevolg dat:

1. de verkeersregels zeer algemeen, doch robuust zullen moeten zijn: ze zullen

voorrang moeten verlenen aan carriers in een hele waaier mogelijke conflicten;


2. de risicozone, en dus de te verwerken data altijd maximaal ( = zichtcirkel) zal

zijn, wat hoge rekentijden zal vergen.

Figuur 2.4: Vergelijking risicozone

Een aangepaste definitie van het risicogebied in het horizontaal systeem wordt als

volgt gegeven (met visualisatie van de risicozone op figuur 2.4, enkel het rode deel

wordt als data verwerkt):

Specifiek voor het horizontaal systeem: Er wordt een onderscheid

gemaakt inzake het risicogebied op basis van de beweging van de carrier:

• Draaiende carrier: Heeft absolute voorrang. Met ’draaiende’ wor-

den alle bewegingen bedoeld die niet op de banen gebeuren. De

risicozone zal enkel het frontale gebied zijn, om mogelijke frontale

botsingen te vermijden (zie figuur 2.4, de carrier in stippellijn).

• Carrier op een baan: Heeft geen enkele voorrang. Afhankelijk van

de baanconfiguratie zal het risicogebied twee of drie kwadranten

bevatten. De carrier moet enkel opletten voor andere, draaiende

carriers (zie figuur 2.4, de carrier in volle lijn).


• Carrier met draaiintentie: Het risicogebied is dan afhankelijk van

de baan en de rijrichtingen van de andere banen. De carrier zal

nog steeds, zoals in het vorige geval, moeten letten op draaiende

carriers, maar zal nu ook moeten onderzoeken of het mogelijk is

de draaibeweging in te zetten. Dit is het gevaarlijkste deel van het

transport. Het risicogebied bevat meestal twee a drie kwadranten

(zie figuur 2.4, de carrier in puntlijn).

Er kan dus besloten worden dat het horizontaal systeem steeds minder dataverwer-

king zal vergen dan het verticaal systeem, aangezien het risicogebied steeds kleiner

is. De rekentijd daalt, en hiermee gepaard, de nodige rekenkracht van de processor,

wat de investering zal verkleinen.

2.2 Modellering 13

2.2 Modellering

2.2.1 Visualisatie in Matlab

In een eerste fase, de ontwerpfase, wordt het systeem uitgewerkt en het concept uit-

gedacht. In een tweede fase moet het voorgestelde systeem en concept opgebouwd

worden. Verder zal in een derde fase, de testfase, de kwaliteit van het systeem be-

paald worden. Voor deze twee laatste fasen zijn simulaties nodig. Dit betekent dat

niet enkel de carriers moeten gesimuleerd worden, maar ook de omgeving gemodel-

leerd moet worden. In deze scriptie werd dit gedaan in MATLAB®.

Figuur 2.5: Model van de map in Matlab

De pijlen in de banen van figuur 2.5 tonen de unieke rijrichting van elke baan. Deze

beslissing wordt verder uitgewerkt in paragraaf 2.2.2. De x-as wordt horizontaal

gelegd met stijgende richting naar links. De y-as wordt hier loodrecht op geplaatst,

met stijgende richting naar beneden.

2.2.2 Indeling en keuze van de banen

Zoals te zien op figuur 2.2, en gezien de breedte van een carrier, is er slechts ruimte

voor 7 parallelle banen. Zoals gesteld in de opgave, moet het gebruik van de ka-

debanen minimaal zijn. Dit komt door het relatief hoger risico op botsingen. Elke

referentietrajectorie zal dus een minimale afstand op de kadebanen nastreven.

Er blijven 4 banen over voor het eigenlijke transport van de containers. Het lijkt

dus een logische keuze om twee banen als rijrichting ’rechts’ te geven, en twee banen

als rijrichting ’links’. In deze scriptie wordt er voor gekozen om deze twee aan

2.2 Modellering 14

twee te kiezen, zoals in figuur 2.5, aangezien dit ons toelaat een rotatief systeem

te gebruiken, waar geprobeerd wordt alle bewegingen op continue wijze te laten

verlopen.

Eenmaal de banen en de richtingen in het horizontaal systeem gekozen zijn, kunnen

nog verschillende configuraties gekozen worden. De eerste 4 banen kunnen name-

lijk op verschillende manieren gekoppeld worden. Volgende mogelijkheden worden

voorgesteld:

1. Systeem met voorkeurbaan, configuratie : 1-4, 2-3: In dit systeem

wordt aan elke carrier een voorkeursbaan meegegeven en wordt op voorhand

beslist om baan 1 en 4 aan elkaar te koppelen, en zo ook voor baan 2 en

3. Dit systeem streeft naar een gelijke verdeling van carriers tussen de twee

subsystemen (1-4, en 2-3). Botsingen en deadlock worden hier vermeden door

geen enkele baan te overladen met carriers (het kan bijvoorbeeld niet dat 95

procent van de carriers op baan 4 rijden). Dit systeem is een soort ’rondpunt’-

systeem: het bestaat uit een binnenste en een buitenste lus.

2. Systeem met voorkeurbaan, configuratie : 1-3, 2-4: Idem aan punt 1,

maar met een andere configuratie.

3. Systeem met efficiente keuze: In deze configuratie proberen de carriers

altijd de baan te nemen die het dichtst aanleunt bij de bestemming. Er is hier

geen evenwichtige verdeling tussen twee lussen, maar aangezien het op cruciale

momenten minder banen moet kruisen, is het efficienter.

Figuur 2.6: Vergelijking tussen de eerste (links) en de derde (rechts) configuratie

2.2 Modellering 15

In figuur 2.6 wordt de vergelijking gevisualiseerd tussen het ’rondpunt’-systeem,

waar een carrier op de buitenste lus rijdt, en het efficiente systeem. De eerste twee

opdrachten resulteren in dezelfde trajectorie, terwijl de twee volgende opdrachten in

een verschillende trajectorie resulteren. In deze scriptie is geopteerd om het efficiente

systeem te implementeren.

2.2.3 Fysische aanpassing ten gevolge van de systeemkeuze

Aangezien er gekozen werd voor een horizontaal systeem dat banen bevat, lijkt het

logisch om deze banen zo uit te rusten met sensoren dat de carriers ’weten’ op welke

baan ze zijn, en of ze er precies op rijden. Dit kan door middel van dure lasers, maar

in deze scriptie werd voor een alternatief gekozen.

Er werd geopteerd voor een goedkopere oplossing. Er zal exact in het midden van

elke baan een kabel ingegraven worden, die door een wisselstroom doorlopen zal

worden. Elke baan zal een eigen discrete frequentie krijgen (stack = 10 Hz, baan

1 = 18 Hz, baan 2 = 26 Hz, baan i = (10 + 8*i) Hz ). Ook zal elke carrier het

positiesysteem ingebouwd krijgen van figuur 2.7. Dit systeem bevat een drietal

voordelen:

• Door het meten en het vergelijken van de impedanties van de twee spoeltak-

ken kan een signaal gestuurd worden naar een regelsysteem dat de wielen kan

bijsturen om weer perfect in het midden van de baan te rijden. In het ide-

ale geval zijn de twee impedanties gelijk aan elkaar. Dit wordt schematisch

weergegeven in figuur 2.7.

• De discrete baanfrequentie kan worden opgemeten door de carrier en kan ter

controle gebruikt worden om de y-positie te bevestigen maar dit is eigenlijk

overbodig.

• Bij het draaien kunnen de carriers nu de richtingsaanwijzers laten oscilleren

met de frequentie van de gewenste, volgende baan. Dit laat de andere carriers

weten dat de carrier wil draaien, en terzelfdertijd ook waar het naartoe wil

draaien. Hierdoor wordt de risicozone beperkt (zie paragraaf 2.1.3).

2.2 Modellering 16

Figuur 2.7: Schema van precisiepositiesysteem

2.3 Structuur van het simulatieprogramma 17

2.3 Structuur van het simulatieprogramma

De structuur van het simulatieprogramma ziet eruit zoals in figuur 2.8. De piramide

stelt de overgang van het lage naar het hoge niveau voor. Naast de piramide staat een

gestructureerd overzicht van de programma’s en interacties die tijdens de simulatie

optreden. Alle programma’s worden later in detail uitgewerkt, maar hier wordt al

een conceptueel overzicht gegeven.

Figuur 2.8: Structuur van het simulatieprogramma

2.3.1 Hoogste niveau : scheduling

Het ’schedulen’ of plannen van de pick en de place gebeurt voor elke carrier af-

zonderlijk. De scheduler of planner geeft aan welke carrier welke container moet

ophalen. Voor deze scriptie is de specifieke volgorde van de containers niet van

belang, aangezien het de bedoeling is om de efficientie van een systeem te bepalen.

Het plannen gebeurt op een toevallige manier. Randomgegenereerde pick- en place-

opdrachten worden doorgestuurd naar het besturingsonderdeel van de carriers. Deze

overdracht wordt gesimuleerd door de subroutine ’Give-task.m’.


2.3.2 Laagste niveau : fysieke omgeving

Dit is de modellering van de rijzone, zoals uitgelegd in paragraaf 2.2.2. Dit is een

algemeen niveau omdat het alle informatie van alle carriers bevat. De subroutine

’Update(Robot)’ beheert de overdracht van visuele gegevens. Enkel de informatie die

zich fysisch in de zichtcirkel an de carrier bevindt, is beschikbaar voor interpretatie

in het besturingsonderdeel.

2.3.3 Middelste niveau : besturingsonderdeel van de carrier

Het middelste niveau is de modellering van het besturingsonderdeel van elke carrier.

Dit wordt samengevat in het object ’Robot.m’. Het besturingsonderdeel krijgt ener-

zijds de visuele informatie en de baaninformatie van de sensoren (waarop de regels

toegepast kunnen worden) en anderzijds instructies van de scheduler krijgt (waar-

mee de scheduler de referentietrajectorie genereert). ’Robot.m’ is het werkelijke

hoofdprogramma dat geımplementeerd zou moeten worden in de boordcomputers

van de carriers.

De regels en de referentietrajectorie zijn sterk verstrengeld en zitten samen vervat

in een aantal subroutines die de verschillende aspecten van de beweging toelichten:

• Waypoints berekenen:

Eenmaal de carrier zijn opdracht gekregen heeft, kan het besturingsonderdeel

een referentietraject voorstellen. Dit is geen referentiekromme, aangezien dit

te veel rekenkracht en rekentijd zou vergen. Er werd een systeem van drie

discrete referentiepunten ontwikkeld, de zogenaamde ’waypoints’.

Van het besturingsonderdeel wordt een minimale kost verwacht (dit bepaalt

mede de investering van het bedrijf) en een optimale respons (anders zou een

goed regelalgoritme zinloos zijn). Dit besturingsalgoritme moet veel informatie

op hetzelfde moment verwerken, gaande van het analyseren van de visuele

informatie, het uitvoeren van de procedures indien een ander carrier in de

risicozone rijdt tot het bijhouden van deze referentietrajectorie. Aangezien de

twee eerste punten cruciaal zijn voor het regelalgoritme, is het de moeite waard

om een alternatief te zoeken voor de klassieke referentiekromme (= duizenden

punten). Dit alternatief zijn de waypoints (= 3 punten), zodat dit systeem

een kleinere rekenkracht en rekentijd vergt. Dit systeem zal in paragraaf 3.3.1

in detail besproken worden, samen met de implementatie, nl. de subroutine

’Waypoints.m’.


• Toestaan van draaibeweging:

De waypoints vatten de referentietrajectorie samen in het geval dat er slechts

een carrier rijdt in de rijzone. Natuurlijk is dit niet het geval tijdens de simula-

ties, en zal de referentietrajectorie veranderd moeten worden in geval van een

mogelijke botsing. Vandaar het draaialgoritme.m, dat bij een mogelijke draai-

beweging een signaal genereert dat de carrier al dan niet toelaat te draaien.

Indien dit algoritme de draaibeweging niet toelaat wordt actie ondernomen

naargelang de baan: indien de carrier rijdt op baan 1, 2, 3 of 4 zullen de

waypoints verplaatst worden in de rijrichting, zodat de carrier de situatie la-

ter kan herevalueren. Indien de carrier stilstaat op baan 0, 5, 6 of 7, en de

draaibeweging geweigerd wordt, zal de carrier het bevel krijgen om te blijven

wachten, tot er geen gevaar meer optreedt, zie 3.5.

• Vertragen in de risicozone:

Om botsingen te voorkomen, vertragen de carriers indien ze in een zeker risi-

cozone terechtkomen. De carriers vertragen in volgende gevallen:

– Net voor het draaien: Vooraleer een carrier draait, zal hij vertragen tot

1/3 van de maximale snelheid. Deze snelheid toont (samen met de rich-

tingaanwijzer) de intentie van het draaien, en maakt de draaisituatie

veiliger.

– In de risicozone: Indien een andere robot de intentie aangeeft te draaien,

en de carrier zelf bevindt zich in de risicozone, dan vertraagt die laatste

tot 2/3 van de maximale snelheid. Dit bevestigt aan de draaiende carrier

dat deze carrier de draaiinttentie opgemerkt heeft en op zijn hoede is.

– Te dicht bij een andere carrier: Indien een carrier vertraagt moet de ach-

terliggende een minimale afstand behouden. Dit impliceert een (stapsge-

wijze) vertraging, tot zelfs een stop indien de eerste carrier stopt.

– Tijdens het draaien: Tijdens het draaien zelf (x- en y-snelheden zijn

niet gelijk aan nul) is de snelheid 1/3 van de maximale snelheid. In

het verticaal stuk dat hierop volgt (enkel een y-snelheid) zal de snelheid

opnieuw 2/3 van de maximale snelheid zal bedragen.

ALGORITME 20

Hoofdstuk 3

Algoritme

Dit hoofdstuk licht de opbouw en werking van het simulatieprogramma toe. De

beste manier om dit hoofdstuk te lezen is simultaan het programma te volgen. Het

programma werd aan het einde van dit werk gehecht aan de achterkaft, op een CD-

ROM die ook het analyseprogramma en een PDF-versie van dit werk bevat. Indien

de lezer niet geınteresseerd is in de (eerder technische) uitwerking van het systeem,

kan onmiddelijk en zonder verlies aan inhoud overgegaan worden naar hoodstuk

4 : Resultaten en evaluatie. Dit hoofdstuk kan echter een belangrijk hulpmiddel

zijn voor personen die een lichte aanpassing willen doorvoeren om mogelijks betere

resultaten te verkrijgen.

3.1 Fysieke omkadering

Zoals in paragraaf 2.3 werd uitgelegd is dit het allerlaagste, meest algemene niveau.

De benaming fysieke omkadering verraadt al veel over de acties op dit niveau:

• Fysieke initialisaties: Allerlei grootheden worden hier gedefinieerd, die ge-

durende de hele simulatie zullen opgeroepen worden, zoals de zichtcirkel van

de carriers en de discrete middens van de banen.

• Initialisatie van de carriers: Keuze van het aantal carriers en hun begin-

posities.

• Initialisaties van tools voor simulatiedoeleinden: Hier worden tools

geınitialiseerd die de algemene parameters in de gaten houden, zoals het aantal

deadlocksituaties, het aantal botsingen en het aantal gevaarlijke situaties.

• Initialisatie van de kunstmatige sensoren: De algemene informatie van

alle carriers wordt in een matrix geplaatst. Men kiest dan op basis van de

3.1 Fysieke omkadering 21

onderlinge afstanden welke informatie fysisch beschikbaar zou moeten zijn

voor welke carrier.

• Initialisatie van de visualisatie: Opbouw van de map waarin de carriers

als nummers zullen gevisualiseerd worden.

• De reele fysieke tijdstap: De hoofdlus van het programma, zie paragraaf

3.1.6.

3.1.1 Fysieke initialisaties

De grootheden die geınitialiseerd worden zijn:

• Simulatietijd, bepaalt de lengte van de simulatie, in seconden.

• Tijdstaplengte, aangezien we met een digitaal programma een analoge toepas-

sing proberen na te bootsen moet deze stap klein genoeg zijn. 0,1 s bleek

aannemelijk. Dit staat in omgekeerde relatie met de fysiek toegepaste sample-

frequentie.

• Banen, enkel de discrete middens van de banen, in meter, en in het voorge-

stelde assenstelsel.

• Zichtcirkel, dit bepaalt welk deel van de informatiematrix beschikbaar zal zijn

voor de carrier. Indien deze straal groter gekozen wordt, zal het programma

trager simuleren, maar zullen de carriers efficienter rijden (aangezien ze de ge-

hele situatie beter kunnen inschatten en voorzien). Aangezien deze zichtcirkel

het bereik van een optische camera voorstelt, nemen we 30 meter als waarde.

• Bereikbare banen, aangezien de pick- of de place-opdracht niet zomaar op elke

baan kunnen geplaatst worden. De bestemming of oorsprong van elke contai-

ner is ofwel de kade (baan 5, 6 en 7) ofwel de stack (baan 0).

• Lengte kade, dit bepaalt de lengte van de kade. Aangezien het volledige sys-

teem ( 1,5 km en 45 carriers) te rekenintensief bleek, en dus de simulatie te

veel vertraagde, werd er een kleiner gedeelte van de kade gesimuleerd met de

zelfde densiteit aan carriers (200 m en 6 carriers, 33,3 meter per carrier).

3.1.2 Initialisatie van de carriers

Hier kan gekozen worden met hoeveel carriers er gesimuleerd wordt en wat hun

beginposities zijn. Dit wordt gedaan door een for-loop (die loopt tot het aantal


opgegeven carriers) waar bij elke iteratie een object gecreeerd wordt, met een begin-

positie die telkens 20 meter in horizontale richting verwijderd ligt van de beginpositie

van de vorige carrier. De carriers beginnen geschrankt op baan 1 (oneven carriers)

of in de stack (even carriers). Bij elke iteratie wordt op basis van het nummer van

de carrier ook een voorkeursbaan toegekend. Voor het ’rondpunt’ systeem is deze

voorkeursbaan vast, wat betekent dat het niet meer verandert gedurende de simu-

latie. Maar indien we het efficient systeem toepassen, verandert dit op basis van de

keuze van de volgende waypoints. Het verschil werd uitgelegd in paragraaf 2.2.2.

3.1.3 Initialisaties van tools voor simulatiedoeleinden

Botsing- en deadlocktellers worden hier geınitialiseerd, alsook een matrix die de

ogenblikkelijk posities registreert bij botsingen en deadlocksituaties. Dit wordt ge-

daan om een beeld te vormen van deze probleemgevallen.

3.1.4 Initialisatie van de kunstmatige sensoren

Dit deel genereert een n x 5 matrix, supervisor info, die alle informatie van de n

carriers verzamelt. Een voorbeeld van deze matrix, voor het geval dat er 5 carriers

aanwezig zijn, wordt gegeven in tabel 3.1.4.

Eigenschap Xpositie Ypositie Xsnelheid Ysnelheid Richtingaanwijzer

Eenheid m m m/s m/s Hz

Carrier1 76,66 32 2,78 0 62

Carrier2 -44 20,394 0 -5,56 18

Carrier3 56 20,06 0 -5,56 18

Carrier4 -1,6 8 -8,33 0 0

Carrier5 25,43 24 2,78 0 10

Tabel 3.1: Voorbeeld van de supervisormatrix

De maximale snelheid is ingesteld (en opgegeven) als 30 km/h, wat overeenkomt

met 8,33 m/s. In dit voorbeeld kan men de voorvermelde regels in verband met de

snelheid, zoals beschreven in het laatste punt van paragraaf 2.3.3, vertaald zien:


Eigenschap Snelheid Deel v.d. Situatie Richting-

max. snelh. aanwijzer

Carrier1 2,78 1/3 Net voor het draaien 62

Carrier2 5,56 2/3 Verticaal stuk tijdens het draaien 18

Carrier3 5,56 2/3 Verticaal stuk tijdens het draaien 18

Carrier4 8,33 1 Normale situatie 0

Carrier5 2,78 1/3 Net voor het draaien 10

Tabel 3.2: Interpretatie van de snelheden d.m.v. de regels

3.1.5 Initialisatie van de visualisatie

Figuur 3.1 stelt de zone tussen de kade en de stack voor. Ook de rijrichtingen zijn

voor de duidelijkheid aangebracht. De carriers, voorgesteld door een getal en hun

zichtcirkel, zullen hierop bewegen tijdens de simulatie.

Figuur 3.1: Model van de map in Matlab

3.1.6 De reele fysieke tijdstap

Deze lus simuleert het tijdsverloop en loopt van nul seconden tot de opgelegde simu-

latietijd. Bij elke iteratie worden een aantal methodes doorlopen die de trajectorie

van de carriers bepalen volgens de opgelegde regels. Ze worden hieronder opgesomd:

• In een eerste dubbel geneste for-loop wordt de supervisormatrix gefilterd tot

de matrix input-individuele-robot. Op basis van de afstanden wordt beslist

of de ide carrier de jde carrier kan zien en indien dit het geval is, wordt de

3.2 Robot 24

overeenkomstige lijn gekopieerd naar de matrix input-individuele-robot. Een-

maal alle andere carriers beschouwd zijn, voert deze lus een update uit van

de huidige carrier (dit wordt later uitgelegd in het pragraaf 3.2.2 , de posities

worden vernieuwd en de visuele info wordt doorgegeven aan de objecten, om

er zo de regels op toe te kunnen passen). Eenmaal de robots geupdatet zijn,

moet de supervisormatrix aangepast worden.

• Indien de carrier op een gegeven moment geen taak heeft zal er hier een taak

gegenereerd worden. Zoals vermeld zijn dit, normaal gezien, de taken opgege-

ven door de scheduler, maar in deze scriptie randomgegenereerde taken.

• Verder wordt ook de visualisatie geupdatet. Om een idee te krijgen van de

toegankelijke informatie per carrier worden ook de zichtcirkels getekend. Deze

worden als tienhoeken getekend in plaats van cirkels, om de rekentijd minimaal

te houden. Om het duidelijker te maken werden de zichtcirkels en carriers in

onderstaande tekening geaccentueerd.

Figuur 3.2: Model van de map in Matlab met carriers

• In de twee laatste lussen wordt een test uitgevoerd om deadlocksituaties waar

te nemen en een test uitgevoerd om botsingen te melden.

3.2 Robot

Vooraleer te beginnen met de inhoud van deze subroutine, moet een kleine bespre-

king gemaakt worden over de structuur van robot.m. In plaats van te werken met een

3.2 Robot 25

gewone array (in dit geval zou dit een soort toestandsmatrix geweest zijn) werd er

geopteerd voor de meer subtiele aanpak via object-georienteerd programmeren. Het

voordeel van de klasse van objecten is dat ze, naast het onthouden van eigenschap-

pen of properties (dit zijn de velden die de data bevatten), ook de operaties bevatten

die we op de data willen uitvoeren, de zogenaamde methods. Dit betekent dat we

elke carrier als object kunnen aanspreken, dat dit object zijn eigen eigenschappen

onthoudt en de zelfgedefinieerde (en identieke) functies op de robot kunnen laten

inwerken. In figuur 3.3 wordt de structuur van de klasse objecten duidelijk gemaakt:

een centraal object, robot.m, dat de klasse definieert, dat voor elk van de carriers

gespecifieerd wordt.

Figuur 3.3: Structuur van de klasse objecten ’robot’

We bespreken respectievelijk de properties en vervolgens de methods.

3.2.1 Properties

Deze worden onderverdeeld in:

1. (Veranderbare) eigenschappen: Dit zijn de data die gedurende de simu-

latie veranderen en die beschikbaar moeten zijn voor externe routines. Dit

kunnen enerzijds routines zijn voor het goede verloop van de simulatie die

toegankelijk zijn voor de carriers (bijvoorbeeld de relatieve posities binnen de

3.2 Robot 26

zichtcirkel) of anderzijds routines die voor simulatiedoeleinden bedoeld zijn

(bijvoorbeeld de tijd onderweg). Deze eigenschappen worden extern opge-

vraagd door middel van het commando (bijvoorbeeld) robot1.Xpositie. De

veranderbare eigenschappen zijn (de meeste eigenschappen spreken voor zich):

• Xpositie

• Ypositie

• Xsnelheid

• Ysnelheid

• Pinker : Stelt de richtingaanwijzer voor, in hertz.

• Due Date : Data die de lead-time, de tijd onderweg, bijhoudt. In secon-

den.

• Pick

• Place

• Geladen : Een boolean die aangeeft of de carrier al dan niet geladen is.

• Idle : Een boolean die aangeeft of de carrier al dan niet een taak heeft.

Deze variabele wordt geınitialiseerd op 1, zodat bij de eerste tijdstap alle

carriers een taak toegewezen krijgen door de functie give task(Robot).

• Snelheid : De huidige snelheid van de carrier. Dit komt overeen met

�obj.Xsnelheid2 + obj.Y snelheid2

• Waypoints : Dit is een array, een 3 x 2 matrix, die de vorige, de huidige

en de volgende waypoint bijhoudt.

2. Verborgen (Hidden) eigenschappen: Dit zijn de zogenaamde verborgen

data, intern toegankelijk, maar extern niet toegankelijk. De verborgen eigen-

schappen zijn:

• fig : hoog indien de gehele trajectorie van een robot gevisualiseerd moet

worden. Wordt geınitialiseerd op nul.

• axes : het bijhorende assenstelsel van de individuele figuur.

• current-objective : komt overeen met de huidige volgende pick (indien de

carrier ongeladen is) of place (indien de carrier geladen is).

• vorige-Xpositie

• vorige-Ypositie

3.2 Robot 27

• Voorkeursbaan : stelt de voorkeursbaan vast, indien gewenst door het

betreffende systeem.

3. Constante (Constant) eigenschappen: Dit zijn de constantes die in het

object robot voorkomen. Dit maakt het ook gemakkelijker om bijvoorbeeld

naar baan 2 te verwijzen: men kan dan obj.Ypositie = 16 vervangen door het

duidelijkere obj.Ypositie = obj.Banen(2). De constante eigenschappen zijn:

• Banen : Dit is een array van de discrete middens van de banen ( 8 16 24

32 44 52 60 ).

• Draaistraal : De gespecifieerde draaistraal voor de carrier is 4 meter.

• Maximale snelheid : Zoals eerder gezegd 30 km/h.

• Lengte kade : Wegens voorvermelde redenen 200 m. Het interval op de

x-as wordt [100 , -100].

3.2.2 Methods

De methods kunnen in grofweg 4 stukken verdeeld worden:

1. Create Robot: Hier worden de objecten geınitialiseerd.

2. Update Robot: De subroutine waarin de regels het duidelijkst verweven zijn.

3. Give Task Robot : Genereert een taak voor de idle carrier.

4. Plot Trajectory Robot : Genereert het nieuwe punt dat de carrier voorstelt,

terwijl het vorige punt verwijderd wordt.

Create Robot

In deze functie wordt een object robot gecreeerd. Bij alle functies moeten argumen-

ten ingevoerd worden bij de definitie:

functionobj = robot(Xpositie, Y positie, V oorkeursbaan)

Deze elementen zijn in paragraaf 3.2.1 verklaard. Verder worden de X- en Yposities,

evenals de vorige-X- en vorige-Ypositie, gelijkgesteld aan de twee eerste argumenten.

De snelheden en de richtingaanwijzer worden op nul geınitialiseerd, terwijl de huidige

posities de eerste waypoint definieren. Uiteindelijk wordt idle-eigenschap op hoog

gezet om aan te tonen dat de carrier geen opdracht heeft.

3.2 Robot 28

Update Robot

Deze lus is het essentiele gedeelte binnen de tijdstap van paragraaf 3.1.6. Een eerste

vertakking gebeurt op basis van het al dan niet idle zijn van de carrier. Indien dit

het geval is, wordt er aan de carrier een taak gegeven. Indien dit niet het geval is,

dus indien obj.idle = 0, dan treden opeenvolgend onderstaande routines op:

1. Regels toepassen: hieronder verstaan we het vertragen (obj.snelheid), het toe-

staan van de (eigen) draaibeweging en het ontwijken van frontale botsingen in

het verticale deel van de draaibeweging.

2. Update fysieke posities na de tijdstap: Door de parameter obj.snelheid te

vermenigvuldigen met de tijdstap zullen de volgende posities berekend worden.

3. Updaten van de waypoints

4. Richtingaanwijzer aanzetten

5. Snelheden aanpassen

Regels toepassen Het eerste dat ’geregeld’ moet worden, is de snelheid. We

passen de subroutine vertragen.m uit, dat uitgelegd is in paragraaf 3.6.

obj = vertragen(obj, input individuele robot)

De argumenten zijn het object en de matrix die de informatie bevat zoals die ver-

krijgbaar is voor de carrier. De uitgang is het object, al dan niet met veranderde

snelheid.

Vervolgens wordt nagegaan of de carrier binnenkort een draaibeweging gepland heeft.

De voorwaarde hiervoor bestaat uit 2 delen:

• obj.waypoints(1, 1) = obj.Xpositie&obj.waypoints(1, 2) = obj.Y positie&

obj.waypoints(1, 2) �= obj.waypoints(2, 2): Dit is het geval waarin de carrier

in de stack staat of stilstaat op baan 5, 6 of 7. Indien de carrier op banen

1,2,3 en 4 rijdt, kan hij ook onder deze beschrijving vallen, indien een van de

discrete simulatiepunten exact samenvallen met de waypoint. Indien dit niet

het geval is, vallen ze onder volgende omschrijving.

• obj.waypoints(2, 2) �= obj.waypoints(3, 2)&abs(obj.Xpositie−obj.waypoints(2, 1)) ≺ (obj.snelheid ∗ deltaT ) : Indien de waypoint niet over-

eenkomt met een van de discrete tijdstappen, dan zou de carrier geen toestem-

ming vragen om te draaien. De carrier zou zonder te kijken afdraaien, indien

3.2 Robot 29

de eerste voorwaarde de enige was. Daarom werd deze tweede voorwaarde

toegevoegd als vangnet, dus voornamelijk voor banen 1, 2, 3 en 4.

Indien aan deze voorwaarde voldaan is (de carrier wil dus draaien), berekent men

het aantal rijen in de matrix die de informatie bevat voor dat object. Indien dit

meer is dan 1, betekent dit dat er een andere carrier in de zichtcirkel rijdt. Nu moet

nagegaan worden indien deze carriers een toekomstig gevaar zouden kunnen vormen

voor de draaiende carrier. Voor elke positie wordt hetzelfde algoritme doorlopen,

namelijk

OK = Draaimogelijkheid(obj, input individuele robot)

Deze functie wordt onderzocht in paragraaf 3.5. Aangezien de gevolgen afhangen

van de huidige positie, is deze lus onderverdeeld op basis van de banen:

1. Baan 0: Indien de draaitoestemmingsvariabele, OK, laag terugkeert blijft de

snelheid, obj.snelheid, op nul.

2. Alle andere banen: Indien OK laag terugkomt, worden de waypoints verplaatst

in de rijrichting, of blijft de snelheid op nul voor banen 5, 6 en 7.

Eenmaal dit gebeurd is, wordt nagegaan of er een (uitzonderlijke) frontale botsing

kan voorkomen in het verticale stuk van de draai (dit is enkel voor draaiende car-

riers). Dit wordt gedaan door middel van de subroutine, die uitgelegd wordt in

paragraaf 3.7:

obj = frontale− Y (obj, input individuele robot)

Draaiende carriers mogen dan wel algemene voorrang hebben, indien ze beide aan

het draaien zijn (en dus voorrang hebben), is dit de oplossing.

Update van de fysieke posities na de tijdstap Er worden vier kleine subrou-

tines doorlopen:

• De posities worden geconverteerd naar de vorige posities.

• De due dates (de tijd dat de robot onderweg is) worden vermeerderd met de

tijdstap.

• Het object wordt geupdatet via de subroutine.

obj = verplaats(deltaT, obj)

• Indien fig hoog staat wordt het volgende punt getekend op de individuele

grafiek.

3.2 Robot 30

Updaten van de waypoints Indien een waypoint bereikt is, wordt de set op-

nieuw aangevuld door

obj = updateWaypoints(obj)

Richtingaanwijzer aanzetten Indien de carrier een draaibeweging wil inzetten

en dit wil aangeven aan de andere robots, moet de richtingaanwijzer aangezet worden

door middel van

obj.P inker = pinker(obj)

Snelheden aanpassen Op basis van de X- en Yposities en de vorige-X- en vorige-

Yposities worden de huidige X- en Ysnelheden berekend, zodat aan onderstaande

identiteit wordt beantwoord:

obj.snelheid =�

(obj.Xpositie−obj.vorigeXpositiedelyaT )2 + (obj.Y positie−obj.vorigeY positie

delyaT )2

Geef een taak

Deze routine laadt een nieuwe taak in het object, indien het geen taken meer heeft.

Dit gebeurt door middel van het commando:

obj = give task(obj, P ick, P lace)

Er is ook een voorwaarde ingevoerd om te voorkomen dat de taak nutteloos is

(bijvoorbeeld een pick- die gelijk is aan de place-opdracht).

3.3 Waypoints 31

3.3 Waypoints

3.3.1 waypoint

Het waypoint algoritme berekent, uit de huidige positie en de bestemming, het korste

pad naar de bestemming. Dit wordt, zoals eerder besproken, niet gegenereerd als

een curve maar als een lijst punten. Aangezien er wordt aangenomen dat de robot

gedurende de normale operatie op een baan beweegt, kan het pad beschreven worden

aan de hand van een lijst met kritieke punten. De lijst met waypoints zijn de punten

waarop de robot een baan verlaat en waar deze terug op de baan komt (punt waarop

draaibeweging start en stopt). Tussen twee sets waypoints beweegt de robot volgens

de richting van de desbetreffende baan. Dit is te zien op figuur 3.4. Daar er met een

banensysteem gewerkt wordt, kan de wenspositie niet volledig vrij gekozen worden,

de carrier kan enkel bewegen tussen de stack en kade. Binnen de lijst met geldige

bestemmingen vallen de posities op banen 5, 6 en 7 (kade) alsook op baan 0 (stack).

Figuur 3.4: Voorbeeld generatie van waypoints

Bij het aanroepen van het waypoint algoritme wordt afhankelijk van de huidige

positie en de wenspositie een beslissing genomen via welke baan deze het snelst

bereikt kan worden. Een grafische weergave van de mogelijke trajectorieen, vertrek-

kende vanuit een willekeurige positie in de stack, is weergeven op figuur 3.5. Het

algoritme is opgebouwd uit een casestructuur, waaruit vooreerst een keuze wordt

gemaakt afhankelijk van de huidige baan (zie figuur 3.6). Vervolgens wordt deze

keuze opgedeeld afhankelijk van de baan waarop de bestemming ligt. Dit zijn dus

vier keuzes: stack (baan 0) en kade (banen 5, 6 of 7). In volgende figuren zijn

banen 5, 6 en 7 samengenomen omdat de beslissingsstructuur analoog is voor de

drie laatste banen. Afhankelijke van de relatieve x afstand wordt nu de beslissing

gemaakt welke baan er opgedraaid moet worden om tot de gewenste bestemming te

komen. Flowcharts van deze beslissingen zijn weergeven in figuren 3.7, 3.8 en 3.9.

Vertrekkende vanuit de stack wordt eveneens een analoge redenering gevolgd als in

vorige figuren.

3.3 Waypoints 32

xStack

wenspositie kade

wenspositie stackStack

Banen 1/2

Banen 3/4

KadeKadexw, kade

xw, stack

range startposities carrier

0 -2r2r

3r r -r

Figuur 3.5: Draaimogelijkheden vanuit baan 0

Ter verduidelijking: de ballon die Case : Baan0 voorstelt komt overeen met de

gehele figuur 3.7, en analoog voor de andere 3. De laatste case werd niet uitgewerkt,

aangezien dit analoog is aan de drie andere.

start

switch y

Baan 0 Baan 1/2 Baan 3/4Baan5/6/7

pos =wenspos

waypoint= positie

return:waypoint

eind

case: Baan(0) case: Baan(1/2) case: Baan(3/4) case: Baan(5/6/7)

y

n

Figuur 3.6: Flowchart waypoint algoritme: overzicht

3.3 Waypoints 33

Deze functie wordt opgeroepen door het commando

[waypoint] = waypoint(positie, wenspositie, banen, draaistraal, voorkeursbaan)

De ingang of argumenten zijn hier de positie, de wenspositie, de draaistraal en de

voorkeursbaan. Op basis van deze gegevens kan dit algoritme de volgende waypoint,

een 1 x 2 array, berekenen, die dan onmiddelijk ook de uitgang vormt.

start

switchywens

xw≥ x+2r

xw≤x–2r

xw<x+2r& xw>x

xw>x–2r& xw<x

naarbaan 3/4

naarbaan 1/2

om viabaan 1/2

om viabaan 3/4

xw>x–3r& xw≤x–r

xw<x+r

xw≥x+r

naar baan5/6/7

naarbaan 1/2

naarbaan 3/4

Einde

case: Baan(0) case: Baan(5/6/7)

y

y

y

y

y

y

y

n

n

Figuur 3.7: Flowchart waypoint algoritme: case 0

3.3 Waypoints 34

start

switchywens

xw< x–r

xw=x–r

xw≥x+r

xw>x–r &xw<x+r

rechtdoor totpunt afdraaiennaar stack

Afraaiennaar stack

afdraaiennaar baan 3/4

rechtdoor,nadien via baan3/4 naar stack

xw<x–2r

xw=x–2r

xw≥x

xw<x &xw>x–2r

rechtdoor,totpunt afdraaien

naar kade

afdraaiennaar kade

via baan 3/4naar kade

rechtdoor,nadien via baan3/4 naar kade

einde


y

y

y

y

y

y

y

y

n n

Figuur 3.8: Flowchart waypoint algoritme: case 1/2

3.3 Waypoints 35

start

Wensbaan?

xw> x+r

xw=x+r

xw<x+r

rechtdoor totpunt afdraaiennaar stack

Afraaiennaar stack

via baan 1/2naak stack

xw>x

xw=x

xw≤x–2r

xw<x &xw>x–2r

rechtdoor,nadienafdraaiennaar kade

afdraaiennaar kade

via baan 1/2naar kade

eerst vooruit,nadien via baan1/2 naar kade

einde


y

y

y

y

y

y

y

n

n

Figuur 3.9: Flowchart waypoint algoritme: case 3/4

3.3.2 updateWaypoint

Dit programma zorgt er voor dat de waypoints op tijd aangevuld worden. Dit

gebeurt door middel van het commando:

[obj] = updateWaypoints(obj)

Het argument is het object, en de uitgang is opnieuw dit object, zij het met al dan

niet veranderde property waypoints. We herinneren de lezer er aan dat de waypoint

array 3 punten bevat, namelijk de vorige, de huidige en de volgende waypoint. Een

eerste situatie waarin de waypoints moeten vernieuwd worden, is de situatie waarin

de huidige waypoint gelijk is aan de huidige positie. In dat geval wordt de huidige de

vorige waypoint en de volgende de huidige. De volgende waypoint wordt vervolgens

berekend via de functie die hierboven uitgelegd werd.

3.4 Verplaats 36

Een tweede mogelijkheid is dat de carrier op zijn bestemming is aangekomen. Indien

het een pick-opdracht is, zal de carrier ook weten waar hij de container moet af-

zetten: de overeenkomstige place wordt de nieuwe current objective, en een aantal

properties worden aangepast:

• De twee eerste waypoints worden gelijkgesteld aan de huidige positie.

• De derde waypoint wordt berekend door middel van de functie waypoint.

• De carrier wordt als geladen bestempeld.

Indien het een place is, zal de carrier geen taak meer hebben, nadat het zijn

container geplaatst heeft. Opnieuw zullen een paar properties veranderd worden:

• De pick, place, current objective en waypointlijst worden leegemaakt.

• De snelheden en de pinker (of richtingaanwijzer) worden aan nul gelijkgesteld.

• De carrier wordt als idle bestempeld.

De carrier zal nu beroep doen op de functie give task(obj, P ick, P lace) om een

nieuwe taak te krijgen.

3.4 Verplaats

Dit onderdeel staat in voor de effectieve verplaatsing van de robot. De waypoints,

die onafhankelijk zijn van de simulatietijd, worden gebruik om de carrier de ge-

wenste taak te laten uitvoeren. Deze routine wordt opgeroepen met het volgende

commando:

obj = verplaats(∆t, obj)

Er treden slechts twee bewegingen op: een rechtlijnige- en een draaibeweging.

Aangezien de versnelling van de carrier verwaarloosd wordt, beperkt deze routine

zich tot het bepalen van een eenparig rechtlijnige beweging of een eenparig cirkelvor-

mige beweging. Met de huidige positie en waypoint wordt bepaald welke beweging

uitgevoerd moet worden. Met de snelheid, afkomstig uit hogerop besproken routines,

en de gewenste tijdstap als ingang wordt nu de nieuwe positie bepaald.

3.5 Draaimogelijkheid 37

3.5 Draaimogelijkheid

Het draaimogelijkheid algoritme onderzoekt de mogelijkheid om af te draaien wan-

neer een carrier zijn waypoint bereikt heeft en dus een draaimanoeuvre wenst te

starten. Afhankelijk van de beslissing van dit algoritme zal de carrier een wachttijd

invoeren, een waypoint verplaatsen of de draaibeweging starten.

In deze paragraaf zal er gesproken worden over de robot en obstakels. Met robot

wordt het huidige object bedoeld dat de beslissing om al dan niet te draaien moet

nemen. Een obstakel is een andere carrier die zich in de zichtcirkel van het huidige

object bevindt. De posities en de snelheden van het obstakel worden aangeduid

met het subscript i; de i duidt op de positie in de lijst input individuele info (xi,

yi, xi, yi). De posities en snelheden van de huidige robot worden aangeduid zonder

subscript (x, y, x, y).

Er wordt steeds gestart met een een variabele OK = waar. Wanneer er een conflict

zou kunnen optreden wordt deze variabele onwaar gemaakt, waardoor de draaibe-

weging uitgesteld wordt. Het algoritme is opgebouwd rond een lus, die alle objecten

in de zichtcirkel een voor een evalueert. Afhankelijk van de posities, snelheden en

richtingaanwijzers van de objecten wordt het OK teken eventueel onwaar gemaakt.

In figuur 3.10 is een overzicht van het beslissingsprocedure geschetst. De beslissing

wordt in vier verschillende delen gesplitst:

• Het obstakel bevindt zich op een van de rijbanen, en beweegt zich ook volgens

de gedefinieerde richting op deze baan.

• Het obstakel heeft in zijn snelheid een x- en y-component. Dit stelt een draai-

beweging voor.

• Het obstakel beweegt enkel langs de y-as. Het is dus niet meer aan het draaien

maar zit tussen twee waypoints in en beweegt loodrecht op de kade.

• Het obstakel staat stil en bevindt zich eventueel in de mogelijke wens-trajectorie

van de robot.

Indien er beslist wordt dat de draaibeweging niet uitgevoerd mag worden omwille

van gevaar voor botsing, wordt deze uitgesteld of gepauzeerd. Afhankelijk van de

vertrekpositie wordt de draaibeweging verplaatst, verder op de huidige baan of wordt

de robot tot stilstand gebracht, totdat de wens-trajectorie beschikbaar is en de

carrier veilig kan afdraaien.


start

t=cte

OK=1

i=0

#robots = aantal robots in zichtcirkel

i≤#robots

xi=baan(1-7)

& yi = 0

xi �=0

& yi �= 0

xi =0

& yi �= 0

xi =0

& yi = 0

Sub: obsta-

kel op baan

Sub: obstakel in

draaibeweging

Sub: obsta-

kel verticale

beweging

Sub: obstakel stil

i=i+1

einde

y

n

n

n

y

y

y

y

n

n

Figuur 3.10: Flowchart draaimogelijkheid: overzicht


In figuur 3.11 is de flowchart voor het eerste deel van de beslissingsprocedure weer-

gegeven: indien het obstakel op een gedefinieerde baan beweegt. Deze is afhankelijk

van de baan waarop de robot vertrekt en meer bepaald van de richting van de baan

(drie verschillende opties): baan 0, banen 3 en 4 of banen 1, 2, 5, 6 en 7.Vervol-

gens wordt bekeken of de robot een gevaar kan opleveren aan de hand van de in

paragraaf 2.1.3 besproken zones. Indien het obstakel zich werkelijk binnen de geva-

renzone bevindt, wordt de afstand die beide robots moeten afleggen tot het kritieke

punt bepaald. Met de snelheid van het obstakel (berekend uit de optische data) en

de verwachte snelheden van de robot gedurende het draaien, kunnen van beide de

tijd tot het verwachte punt van botsing berekend worden. Indien het tijdsverschil

kleiner is dan een vooropgestelde veiligheidstijd, zal de robot zijn draaibeweging

uitstellen door zijn waypoint te verplaatsen of een wachtopdracht uit te voeren.

De tweede subroutine (figuur: 3.12) en derde subroutine (figuur: 3.13) bepalen

veiligheidszones rond het draaiende obstakel. Indien deze een gevaar betekenen

voor de uit te voeren draaibeweging door de robot, wordt de draaibeweging van de

carrier uitgesteld.

Met de laatste subroutine, wanneer het obstakel stilstaat, wordt bepaald of het

obstakel zich op de wenstrajectorie van de robot bevindt. Indien dit het geval is,

is de kans op botsing hoog en kan de draaibeweging niet veilig uitgevoerd worden.

De draaibeweging wordt afgebroken door OK onwaar te maken. Nu wordt door de

hoger beschreven routine bepaald of de robot een wachttijd invoert of de waypoint

verplaatst en de draaibeweging verderop uitvoert.


Kruisen banen?*

switch y

Gevarenzone

?**

Bepalen tijden botsing:

(tx & ty)***

|tx − ty| < t

OK=0

Gevarenzone

V=0 ?**OK=0

Gevarenzone

?**


(tx & ty)***

|tx − ty| < t

OK=0

Gevarenzone

V=0 ?**OK=0

Gevarenzone

?**


(tx & ty)***

|tx − ty| < t

OK=0

Gevarenzone

V=0 ?**OK=0

Einde

y

baan(0)

baan(1,2,5,6,7)

baan(3,4)

y

y

n

y

y

y

n

y

y

y

n

y

n

n

n

n

n

n

n

Figuur 3.11: Flowchart draaimogelijkheid: sub: robot op baan

* Deze beslissing steunt op twee voorwaarden om te bepalen of de baan van de

robot de baan van een andere robot kruist:


• Of de robot bevindt zich dichter bij kade dan het obstakel, de richting-

aanwijzer wijst naar een baan voorbij of gelijk aan deze van het obstakel:

y > yi & RAW-10 ≤ yi

• Of de robot bevindt zich op baan dichter bij stack en de richtingaanwijzer

wijst naar een baan voorbij het obstakel:

y < yi & RAW-10 ≥ yi

** De robot die een draaibeweging wenst te starten zal zijn zichtcirkel beperken.

Hierin worden 3 onderverdelingen gemaakt, afhankelijk van de baan waaruit

de robot de draaibeweging wenst te starten:

• Stack:

Alle robots die bewegen in het eerste en tweede kwadrant volgens richting

van baan 1 en 2 kunnen hier een gevaar opleveren

x− xi < breedte laan & xi <0

of

x− xi > -breedte laan & xi <0

Baan 3, die nog net in de zichtcirkel valt, levert vanuit de starpositie

echter geen nuttige informatie.

• Banen(1, 2, 5, 6 en 7):

Indien de robot uit een van de vooraf gedefinieerde banen vertrekt is het

noodzakelijk het obstakel dat voor de robot gelegen zijn met tegengestelde

y-snelheid en het obstakel dat achter de robot gelegen zijn met een y-

snelheid in zelfde richting te bekijken. Andere obstakels vormen geen

gevaar.


of

x− xi > -breedte laan & xi >0

• Banen(3 en 4):

Wanneer er wordt vertrokken uit baan 3 of 4 zijn de voorwaarden identiek

aan vorige besproken voorwaarden:


of

x− xi > -breedte laan & xi >0


Er volgt een tweede bepaling van gevarenzone: indien het obstakel stilstaat

op een van de voorgenoemde banen. Er wordt nu bepaald op welke x-positie

de robot zich verticaal zal verplaatsen: huidige x-positie indien uit stack ver-

trokken wordt, of x ± draaistraal afhankelijk van de banen(1-7). Rond deze

x-positie wordt een veiligheidszone gedefinieerd. Indien de stilstaande robot

zich in deze zone bevindt, wordt de draaibeweging eveneens uitgesteld:

vb: Banen(3 of 4):

|x− rd − xi| < breedte laan

*** Bepalen tijd botsing:

Om de tijdslengte te kennen tussen de tijdstippen waarop de robot en het

obstakel op een punt passeren, wordt vooreerst de afstand tot dit punt bepaald:

xafstand = |x− xi|yafstand = |y − yi|

Afhankelijk van de baan waaruit vertrokken wordt en de snelheid van het

obstakel, moet de x-afstand gecorrigeerd worden met ± de draaistraal. Met

deze afstand en een meting van de snelheid van het obstakel kunnen de tijden

berekend worden. In het geval dat er vertrokken wordt uit de stack, wordt de

tijd als volgt bepaald:

tx = xafstand

xi

ty =yafstand23Vmax

in de ander gevallen wordt de ty aangepast door de draaibeweging:

ty =(yafstand−rd)

23Vmax

+2πrd

413Vmax


Start

Kruisen banen?*

Opdraaien

baan?****

|x− xi|<r+VZ*****

OK=0

Einde

y

n

y

n

n

y

Figuur 3.12: Flowchart draaimogelijkheid: sub: robot in draaibeweging

**** Hierbij wordt er gekeken of het obstakel de baan niet aan het opdraaien

is. Indien die de baan waaruit vertrokken wordt oprijdt, wordt deze kans op

botsing opgevangen door een ander deel (zie paragraaf: 3.6 ). Indien het een

baan oprijdt die gekruist wordt, zal dat obstakel reeds verwijderd zijn uit de

gevarenzone of wordt er door een van beide voorgang verleend.

***** Indien het obstakel enkel een y-snelheid heeft voert het een verticale bewe-

ging uit. Er wordt nu getest of de x-positie van de verticale beweging van de

robot binnen de veiligheidszone van het obstakel zou vallen.

3.6 Vertraag 45

3.6 Vertraag

Dit algoritme staat in voor het aanpassen van de snelheid van de robot naar de

gewenste waarde zoals besproken in paragraaf 2.3.3.

In figuur 3.14 is een overzicht van het algoritme gegeven. Het bestaat uit twee delen:

een eerste deel voorziet de nodige snelheidsaanpassingen die elke carrier dient door

te voeren. De snelheid wordt bepaald door de richtingaanwijzer en een eventuele

draaibeweging.

Het tweede deel staat in voor het verlenen van voorrang of het vertragen, met stop-

pen indien nodig, wanneer een obstakel te dicht nadert zodat er een kans optreedt

dat een botsing zich voordoet. Dit deel van het algoritme is onderverdeeld in drie

subroutines:

• wanneer de robot zich op een baan bevindt

• wanneer deze een baan aan het opdraaien is

• wanneer deze een baan verlaat

De eerste subroutine (figuur: 3.15) wordt uitgevoerd wanneer de robot zich op

een baan bevindt. Afhankelijk van de baan waarop de robot beweegt, kan er beslist

worden om te vertragen of stoppen indien een robot verderop de baan gelegen te

dicht nadert, zodat het obstakel niet achterwaarts aangereden wordt. Afhankelijk

van de rijrichting van de baan:

x > xi & |y − yi| < breedte laan

of

x < xi & |y − yi| < breedte laan

Vervolgens moet er voorrang verleend worden aan obstakels die reeds een draai-

beweging aan het uitvoeren zijn. Er word getoetst of een draaiend obstakel de

huidige baan kruist (zie paragraaf 3.5) en indien nodig zal de robot vertragen en

stoppen om voorrang te verlenen.

3.6 Vertraag 46

start

RAW aan? xt = xt−1?

snelheid = 23Vmax snelheid = 1

3Vmax

op baan? sub: op baan

opdraaien baan?sub: op-

draaien baan

afdraaien baan?sub: af-

draaien baan

einde

y n

yn

y

y

y

n

n

n

Figuur 3.14: Flowchart vertraag: overzicht

3.6 Vertraag 47

start

i≤ #robots

switch

waypoint(2,2)

x < xi

|y − yi| <BB

vertraag en stop indien nodig

Kruisen banen?


x > xi

|y − yi| <BB


Kruisen banen?


i=i+1

einde

y

banen (1,2,5,6,7)

banen (3,4)

y

y

n

n

n

y

y

n

n

Figuur 3.15: Flowchart vertraag: sub: op baan

Subroutine ’afdraaien baan’ (figuur: 3.16) laat de robot afremmen, indien nodig

stoppen, wanneer een obstakel zijdelings aangereden worden zou. De veiligheidszone

verplaatst zich mee met de robot gedurende de draaibeweging.

3.6 Vertraag 48

start

i≤ #robots

switch

waypoint(2,2)

xi < x &

|wpnt(1, 2)− yi| < BBafstand=

�(x− xi)2 + (y − yi)2

afstand<VZ

snelheid=0

xi > x &

|wpnt(1, 2)− yi| < BBafstand=

�(x− xi)2 + (y − yi)2

afstand<VZ

snelheid=0

i=i+1

einde

y

banen (1,2,5,6,7)

banen (3,4)

y

y

y

y

n

n

n

Figuur 3.16: Flowchart vertraag: sub: afdraaien baan

De laatste subroutine, die uitgevoerd wordt wanneer de robot een baan opdraait,

is een samenvoeging van beide voorgaande subroutines. De carrier moet zowel reke-

ning houden met het verlenen van voorrang, het vertragen voor voorgangers en het

vermijden van een zijdelingse aanrijding met obstakels die zicht reeds op de baan

bevinden.

3.7 Frontale verticale botsing 49

3.7 Frontale verticale botsing

Dit programma behandelt de (uitzonderlijke) situatie waarin twee carriers elkaar

tegenkomen, terwijl ze beide in een voorrangspositie zijn. Beide carriers zijn niet in

hun normale, horizontale beweging, en hebben dus normaal gezien absolute voorrang

op alle andere carriers. Indien ze zich allebei in zo een situatie bevinden moet er een

programma zijn die de situatie ontwart. De situatie werd gevisualiseerd in figuur

3.17.

Figuur 3.17: Voorbeeld van de situatie waar een frontale botsing zou optreden en de

oplossing

Om dit programma op te roepen dient de volgende sequentie ingevoerd te worden:

obj = frontale Y (obj, visual info))

De argumenten zijn het object ter sprake, dus een van de carriers in de boven-

vermelde situatie, en de ermee overeenstemmende matrix die de visuele informatie

bevat. De uitgang is opnieuw een object, maar met verschillende waypoints (om

niet met de andere carrier te botsen).

In dit algoritme zijn twee grote delen te onderscheiden: het eerste deel staat in

voor het aanpassen van de snelheid indien de robot in een verticale beweging is,

het tweede deel staat in om de carrier te laten uitwijken indien een botsing anders

onvermijdelijk zou zijn:

• Vertragen, indien nodig stoppen zodat niet op het obstakel ingere-

den wordt:

Hierbij worden er twee onderverdelingen gemaakt: indien de robot richting

kade beweegt of indien de robot naar de stack gaat:


– Robot richting kade:

Bij het bewegen richting kade worden er drie verschillende gevallen on-

derscheiden, ze worden hieronder elk verder apart uitgewerkt:

∗ Afdraaien baan:

Wanneer de robot een draaibeweging wenst te starten, moet de snel-

heid aangepast worden zodat, door de beweging loodrecht op de kade

(y-as), er geen obstakels op aanliggende banen gehinderd worden.

∗ Verticaal bewegen:

Indien een obstakel op een baan niet tijdig voorrang kan verlenen en

de veiligheidsafstand te klein wordt zal deze doorrijden. De draaiende

robot moet nu vertragen en indien nodig stoppen om het obstakel

voldoende tijd te geven voor het manoeuvre.

∗ Stoppen indien obstakel voor deze wenst af te draaien:

Hierin moet een onderscheid gemaakt worden tussen twee situaties:

carrier en obstakel bewegen in gelijke richting of in tegengestelde

richting (zie figuur: 3.18)

(a) Tegengestelde richting (b) Gelijke richting

Figuur 3.18: Stop om voorrang te verlenen aan robot die wenst af te draaien

· Gelijke richting:

De carrier moet stoppen voordat deze de baan betreedt die de

richtingaanwijzer van het obstakel aanduidt.

· Tegengestelde richting:



– Robot richting stack:

Dit deel verloopt analoog aan hogerop besproken onderdeel: indien de

carrier richting kade beweegt. Hieronder zijn achtereenvolgens de beslis-

singsstappen weergegeven:


∗ Afdraaien baan:

Snelheid aanpassen, zodat obstakels op aanpalende banen geen hin-

der ondervinden van initialiseerde draaibeweging door robot (zie ho-

ger).

∗ Verticaal bewegen:

Snelheid aangepast wijzigen indien obstakel geen voorrang kan ver-

lenen, zodat deze niet aangereden wordt (zie hoger).

∗ Stoppen indien obstakel voor deze wenst af te draaien:

Robot moet stoppen voor wensbaan van andere draaiende robot, zo-

dat deze ongehinderd de wensbaan kan oprijden (zie hoger).

Hierin worden twee onderverdelingen gemaakt: zie figuur 3.18.

· Gelijke richting:



· Tegengestelde richting:



• Baan veranderen om botsing te vermijden:

Robot en obstakel voeren beide een verticale beweging uit. Indien deze elkaar

wensen te kruisen wordt een toekomstige botsing onvermijdelijk. De carrier

past zijn waypoint aan en tracht een baan op te draaien die voor de huidige

positie van het obstakel gelegen is. Vanuit het nieuwe waypoint is het nodig

om opnieuw de waypoints te bereken om op de gewenste positie te geraken.

– Robot richting kade:

∗ Obstakel binnen veiligheidszone & in draaibeweging:

Er wordt bekeken of het obstakel binnen de veiligheidszone (een ver-

tikale strook rond de robot) valt en of het een draaibeweging aan het

uitvoeren is. Wanneer dit het geval is zijn zowel obstakel als robot

in een draaiweging en kan het mogelijk zijn dat de wenstrajectorie

aangepast moet worden.

· Kruisen banen:

Nu wordt getest, aan de hand van richtingaanwijzers en posities

van zowel robot als object, of de banen elkaar effectief moeten

kruisen om beide tot de wenspositie te geraken. Indien dit het

geval is moet de waypoint aangepast worden zodat er voor de

huidige positie van het obstakel een baan opgereden wordt.


Waypoint en richtingaanwijzer (RAW) aanpassen: Het aan-

passen van waypoint en richtingaanwijzer geschiedt aan de

hand van positie en richtingaanwijzers van beide betrokkenen.

Er wordt getracht zo snel mogelijk af te draaien zodat het

obstakel zijn normale baan kan vervolgen. De mogelijkheid

bestaat dat het obstakel nu zal moeten stoppen om de robot

voorrang te verlenen om de nieuwe baan op te draaien, maar

deze zal in dit geval geen ontwijking moeten uitvoeren, wat

neer komt op ongewijzigde rijafstand.

– Robot richting stack:

Het algoritme voor de beweging richting stack gebeurt analoog aan het

voorgaande deel, met als enig verschil dat de robot afkomstig van de

kade eventueel ook op banen (4,5,6) de waypoints kan wijzigen om een

botsing te voorkomen. Hierbij is het mogelijk dat deze ook een van de

onderste banen opdraait. Bij voorkeur wordt er een van de eerste vier

rijstroken opgereden. Wanneer een situatie optreedt waarbij een robot

in de kade (richting stack) en een tegenligger elkaar zouden hinderen

door een frontale beweging, wordt er steeds getracht de robot richting

kade het ontwijkmanoeuvre te laten uitvoeren. Indien er geen andere

optie voorhanden is zal de robot op de onderste drie rijstroken (kade) een

ontwijkmanoeuvre uitvoeren.

RESULTATEN EN EVALUATIE 53

Hoofdstuk 4

Resultaten en evaluatie

Eenmaal het model en het simulatieprogramma helemaal geschreven zijn, kan over-

gegaan worden op de uiteindelijke simulaties. In dit hoofdstuk zal getracht worden

de efficientie van het uitgewerkte systeem te quantificeren. Verschillende methodes

kunnen uitgewerkt worden, waarbij telkens het aantal carriers opgedreven wordt om

te zien waar de grenzen van het aannemelijke liggen:

1. Bespreking van de vooropgestelde richtlijnen in verband met het aantal dead-

locksituaties en botsingen ;

2. Bespreking van de verdeling van de lead-time van een carrier met vaste tra-

jectorie ;

3. Bespreking van de gemiddelde gecorrigeerde snelheid (= transporttijd gedeeld

door de afstand in vogelvlucht) ;

4. Bespreking van de aanname ”partiele carrierdensiteit”.

Er zal gaandeweg getracht worden om de grote hoeveelheid informatie, vervat in

de metingen, samen te vatten in een paar parameters, die dan gebruikt kunnen

worden (onder voorgeschreven omstandigheden) ter vergelijking van de verschillende

systemen.

4.1 Bespreking van het aantal botsingen en dead-

locksituaties

De configuratie uitgelegd in hoofdstuk 2 zal nu kwalitatief beoordeeld worden. Het

systeem, op het huidige niveau van uitwerking, blijkt nog niet helemaal deadlockvrij

4.1 Bespreking van het aantal botsingen en deadlocksituaties 54

noch botsingvrij te zijn. Men kan er van uitgaan dat, door verder onderzoek, het

systeem zeker botsingvrij kan gemaakt worden voor alle carrierdensiteiten en dat

het aantal deadlocksituaties nog sterk gereduceerd kan worden.

Zoals eerder vermeld is de (maximale) gevraagde densiteit 45 carriers per 1500 me-

ter, of 33 meter per carrier. Indien we 45 carriers simuleren zou dit teveel rekentijd

vragen, dus vereenvoudigen we het systeem naar een geschaald systeem met equi-

valente carrierdensiteit. De vraag is natuurlijk of dit geoorloofd is. Op deze vraag

tracht men in paragraaf 4.4 een antwoord te bieden: er wordt onderzocht wat de rol

is van lokale carrierdensiteiten.

Voor de deadlocksituaties laat men het aantal carriers stijgen om een trendlijn te

vinden. De gesimuleerde omstandigheden zijn de volgende:

• Lengte kade: gekozen op 200 meter

• Simulatietijd: 28800 seconden, of 1 werkdag ( = 8 uur)

• Aantal carriers: varierend (van 1 tot 10)

• Aantal simulaties:om een objectief beeld te krijgen van de deadlocksituaties,

worden er 15 simulaties uitgevoerd. Het getal in onderstaande tabel is het

gemiddelde van 15 keer 1 werkdag.

Aantal Carrier- Aantal

carriers densiteit deadlocksituaties

Eenheid meter per deadlocksituaties

carrier per simulatie

2 100 0

3 66.7 0

4 50 0.07

5 40 0.60

6 33.3 1.53

7 28.6 2.93

8 25 5.00

9 22.2 8.87

10 20 11.87

Som 19.13

Tabel 4.1: Uitgemiddeld aantal deadlocksituaties in de 15 simulaties van 28800 seconden,

per carrierdensiteit


Het resultaat van de simulaties is te zien op onderstaande figuur en in tabel 4.1. Er

werd tot een veel hogere carrierdensiteit gesimuleerd om de trend beter in te zien.

Praktisch zal het bereik van 0 tot 6 carriers (op de 200 meter) van toepassing zijn.

1 2 3 4 5 6 7 8 9 10 110

2

4

6

8

10

12

14

16

18

# robots

#k

Figuur 4.1: Uitgemiddeld aantal deadlocksituaties in de 15 simulaties van 28800 secon-

den in functie van aantal carriers

Een deadlocksituatie resulteert in een manuele herinitialisering, en moet ten alle

koste vermeden worden. We definieren de volgende methode voor het vergelijken

van de kwaliteit inzake deadlocksituaties van een voorgesteld systeem:

Deadlockparameter χdeadlock,n:

Dit is de sommatie van het uitgemiddeld aantal opgemeten deadlocks, #opgemeten,

over k simulaties, gaande van 0 tot n carriers, over een vaste kadelengte en een

randomgegenereerde takenverdeling.

#k =1k

�k2 #opgemeten,k

χdeadlock,n,k =�n

0 #k

χdeadlock,n = limk→∞

χdeadlock,n,k

Het systeem met de kleinste χdeadlock,n is het systeem met het minste aantal manuele

herinitialisaties, indien de modale carrierdensiteit voor het gewenste systeem de

voorgeschreven n niet overschrijdt. Dit getal is belangrijk, aangezien het aangeeft in

welke mate het systeem foutloos is. In deze scriptie wordt een onderscheid gemaakt

tussen een fout en een vertraging: een fout is een deadlocksituatie of een botsing en

heeft algemene, verregaande gevolgen voor de hele werking van het dok, terwijl een


vertraging minder verregaande gevolgen heeft, hooguit een tijdelijke vertraging aan

de kadekraan. Dit getal zegt dus niets over de efficientie van het dok, maar enkel

op de kwaliteit inzake fouten.

Voor het systeem dat deze scriptie onderzoekt is de χdeadlock,10,15 = 19.13. Deze

parameter kan enkel vergeleken worden met een χdeadlock,10,15 van een ander systeem,

er kan geen sprake zijn van interpolatie ter vergelijking van bijvoorbeeld χdeadlock,9,15.

Wel mag verwacht worden dat hoe hoger de k, hoe sterker de parameter per systeem

convergeert. Het is dus wel geoorloofd om een χdeadlock,10,20 met een χdeadlock,10,15 te

vergelijken.

Er dient op gewezen te worden dat de waarde van deze parameter zeker nog kan ver-

beterd worden. Door te blijven simuleren, worden nieuwe deadlocksituaties ontdekt,

die vervolgens door kleine aanpassingen en nuances kunnen voorkomen worden. Dit

is echter een tijdsintensieve activiteit, die niet helemaal meer in het bestek van deze

scriptie ligt. Hetzelfde geldt voor de botsingen: er treden er nog een miniem aantal

op ( bijvoorbeeld voor 7 carriers op 200 meter is er 1 in 15 keer 28800 seconden). Een

overzicht van het aantal botsingen en de daarmee gepaard gaande carrierdensiteit

wordt gegeven in tabel 4.1. Ook hier zal praktisch enkel tot 6 carriers op 200 meter

van toepassing zijn. De eerste stap van ontwarring is steeds de conversie van een

botsing naar een deadlocksituatie. Daarna pas wordt er van een deadlocksituatie

naar een helemaal ontwarde situatie gewerkt. Wij geloven er sterk in dat het aan-

tal botsingen helemaal tot nul kan herleid worden en dat de deadlocksituaties nog

verder naar beneden kunnen gedreven worden in het voorgestelde systeem.

Aantal Carrier- Aantal

carriers densiteit botsingen

Eenheid meter/car. -

2 100 0

3 66.7 0

4 50 0

5 40 0

6 33.3 0

7 28.6 1

8 25 1

9 22.2 4

10 20 4

Tabel 4.2: Aantal botsingen gedurende 15 simulaties van 28800 seconden, per carrier-

densiteit

4.2 Bespreking van de verdeling van de lead-time 57

Indien er gevraagd wordt een oordeel te vellen over het systeem, kan volgende con-

clusie gesteld worden:

” Door verder uitwerking kunnen alle botsingen voorkomen worden. Voor

de situatie met de maximale densiteit (33 meter per carrier) werden (voor

de huidige stand van het onderzoek) gemiddeld 1.53 deadlocksituaties per

8 uur gemerkt. ”

4.2 Bespreking van de verdeling van de lead-time

Een tweede quantificatie van de kwaliteit kan gebeuren op basis van de verdeling van

de lead-time van een specifieke carrier. Stel dat een carrier steeds langs dezelfde tra-

jectorie rijdt en men voegt telkens een carrier toe, dan kan men de invloed bekijken

van de (totale) carrierconcentratie op de verdeling. Deze verdeling blijkt een rechts-

scheve β-distributie te zijn. De karakteristieken, die als ’informatief’ bestempeld

worden, zijn:

• De modus: dit is de tijd die gekoppeld is met de grootste kansdichtheid inzake

aankomsttijd. De scheduler gaat er van uit dat elke carrier de grootste kans

heeft om die lead-time te hebben.

• Het gemiddelde: dit is ook een belangrijk gegeven voor de scheduler omdat

dit de verwachte lead-time is, gegeven het aantal carriers op de weg. Indien

een carrier op een gegeven moment op een gegeven plaats moet zijn, zal de

scheduler hier dus rekening mee moeten houden.

• De variantie: zo ook zal de scheduler de mogelijkheid tot vertragingen moeten

afwegen. Er zal met tijdbuffers moeten gewerkt worden en deze zullen afhan-

gen van het aantal carriers. (1 carrier komt overeen met een afwezigheid van

een buffer, 10 carriers betekent al een grotere veiligheidsperiode).

• Het 95e percentiel: aangezien de variantie geen aanschouwelijke betekenis heeft

bij een β-distributie, wordt er eerder het 95e percentiel berekend, als maat van

spreiding. Indien van die lead-time de minimale tijd afgetrokken wordt, dan

kan men inzien hoe die verdeling uitgespreid is.

Deze waarden zijn opnieuw afkomstig van simulaties. De gesimuleerde omstandig-

heden zijn de volgende:

• Lengte kade: gekozen op 200 meter


• Simulatietijd: 28800 seconden, of 1 werkdag ( = 8 uur)

• Aantal carriers: varierend (van 2 tot 10)

• Aantal simulaties: om de trend goed weer te geven wordt er 15 keer gesimu-

leerd

4.2.1 Resultaat van de simulatie en verschil tussen de pick-

opdrachten en de place-opdrachten

In figuur 4.2 zijn de resultaten te zien voor de lead-time van de pick-opdrachten. Men

heeft vanzelfsprekend vanaf twee carriers gesimuleerd. Simuleren met een carrier zou

resulteren in een piek met densiteit 1, aangezien het systeem deterministisch is.

1 2

3 4

5 6

7 8

910

4060

80100

120140

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

# robots

tijd (sec)

Pro

bab

ilite

it

Figuur 4.2: Evolutie van de picktijden in functie van aantal carriers

Op deze figuur ziet men de duidelijke trend van spreiding bij een hoger aantal

carriers. Er moet wel op gewezen worden dat praktisch enkel de eerste 5 verdelingen

van belang zijn. Meerdere zaken vallen op, beginnende met de meest voor de hand

liggende:

• Hoe hoger de carrierdensiteit, hoe hoger de modus (dit is de tijd die hoort

bij de maximale kansdichteheid of de hoogste piek) en het gemiddelde, zie


paragraaf 4.2.2. De tijd die overeenkomt met de 95e percentiel treedt ook pas

later op, zie paragraaf 4.2.3.

• In grafiek 4.2 kan men duidelijk de vorm van een typische β-distributie zien.

Dit kan intuıtief als volgt uitgelegd worden voor het geval met 2 carriers:

In figuur 4.3 kan men de drie mogelijke soorten trajectorien zien, samen met de

relatieve frequentie op de grafiek in de linker onderhoek. Elk soort trajectorie

is vertegenwoordigd door een kleur:

1. Probleemloos, groen: Dit is de eerste en grootstse piek. De carrier

volgt dezelfde trajectorie als in het geval met slechts een carrier. Anders

gezegd verlopen in die tijdspanne de trajectorien van de robots onafhanke-

lijk van elkaar. Na manuele analyse zou deze trajectorie, overeenkomstig

de regels, inderdaad ongeveer 33 seconden moeten duren.

Figuur 4.3: Verschillende mogelijke rajectorien om van de place-opdracht naar de pick-

opdracht te komen

2. Met vertraging, oranje en rood: Dit zijn de opeenvolgende pieken

net na de eerste piek. De carrier volgt nog steeds dezelfde trajectorie

als in het bovenstaande geval, maar blijkt er langer over te doen. De

carrier heeft dus een lagere gemiddelde snelheid, die verklaard kan worden

door de vertragingen ten gevolge van de interactie met de andere carrier.

Het typische geval is een andere carrier die van baan 7 komt en naar


de stack moet. De testcarrier zal deze opmerken, en zijn snelheid met

een derde verlagen indien gesitueerd in de risicozone, of zelfs stoppen

indien de andere carrier te dichtbij is (aangezien de andere carrier een

draaibeweging uitvoert en dus absolute voorrang geniet). Dit resulteert

in een vertraging van 5 a 10 seconden. Een andere mogelijkheid is in het

rood aangegeven: de carrier merkt een andere carrier op die richting de

stack rijdt, en een hindernis vormt bij het draaien. De carrier moet dan

noodgedwongen doorrijden en terugdraaien, zoals aangegeven op figuur

4.3. Analytisch bekomen we voor deze situatie een extra tijdspanne van

15 seconden. Aangezien de combinaties groot zijn, zien we een hele waaier

van uitlopers op de grafiek, die verklaarbaar zijn tot ongeveer 60 seconden.

Analytische berekeningen om inzicht te krijgen in de transporttijd zijn

slechts mogelijk bij een klein aantal carriers (2 a 3) en zullen later slechte

schattingen blijken.

Naarmate het aantal carriers toeneemt worden de situaties veel complexer: het

is dan ook logisch dat de spreiding en het 95e percentiel toenemen.

• Er is een verschil tussen de pickgrafiek 4.2 en de placegrafiek 4.4. Dit merkt

men bijvoorbeeld aan de uitlopers bij 10 carriers. Dit is afhankelijk van de

(horizontale) carrierdensiteit en zal in paragraaf besproken worden.

1 2

3 4

5 6

7 8

91040 50 60 70 80 90 100

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

# robots

tijd (sec)

Pro

ba

bili

teit

Figuur 4.4: Evolutie van de placetijden in functie van aantal carriers


4.2.2 Bespreking van de modus en het gemiddelde

In onderstaande grafiek is de trend getekend van de modus en het gemiddelde bij

stijgend aantal carriers. Zoals verwacht stijgt op grafiek 4.5 het gemiddelde snel-

ler dan de modus. Dit betekent dat de meest verwachte lead-time min of meer

op dezelfde plaats blijft, maar dat de spreiding van de grafiek groter wordt, zoals

intuıtief logisch blijkt en zal aangetoond worden in 4.2.3. Opnieuw is er een verschil

te merken met de trend bij de place-opdrachten: de evolutie van de gemiddelde is

analoog, terwijl de evolutie van de modus verschilt. Bij de place-opdrachten ligt de

modus steeds op 34 seconden, en stijgt hij sterk naarmate het aantal carriers de 7

overstijgt. Bij de pick-opdrachten is dit eerder een trapstructuur. Opnieuw wordt

dit fenomeen geweten aan de (horizontale) carrierdensiteit.

1 2 3 4 5 6 7 8 9 10 11 1232

34

36

38

40

42

44

46

# robots

tijd

(se

c)

gemiddeldemodus

Figuur 4.5: Evolutie van het gemiddelde en de modus van de pick-opdrachten in functie

van aantal carriers

Het is opmerkelijk dat we telkens een soort trajectorie-afhankelijkheid aantreffen.

Indien we dus parameters voor de kwaliteit willen vooropstellen, zal deze trajectorie

ook goed gedefinieerd moeten zijn.

Modusparameter en Meanparameter αModus,n,k en βMean,n,k:

Gegeven een vaste trajectorie (pick, place) en een set regels, over k simulaties,

gaande van 1 tot n carriers, over een vaste kadelengte en een randomgegenereerde

takenverdeling.

• αModus,n,k : wordt gedefinieerd als de som van de modi van de pick-opdrachten

en de place-opdrachten, gesommeerd van 1 tot n carriers.


• βMean,n,k : wordt gedefinieerd als de som van de gemiddelden van de pick-

opdrachten en de place-opdrachten, gesommeerd van 1 tot n carriers.

αModus,n,k =�n

1

�placepick modusi,j

βMean,n,k =�n

1

�placepick µi,j

Aantal Carrier- Mean Modus

carriers densiteit

Eenheid meter/car. s s

1 200 66.9 66.9

2 100 69.0 66.9

3 66.7 71.1 67.9

4 50 73.2 67.9

5 40 75.5 67.9

6 33.3 77.6 67.9

7 28.6 79.7 68.9

8 25 81.9 71.9

9 22.2 84.3 73.9

10 20 86.4 74.9

Som 765.6 695

Tabel 4.3: De opgetelde gemiddelden en modi van de pick-opdrachten en place-

opdrachten, voor 15 simulaties van 28800 seconden, per carrierdensiteit

Voor dit systeem en deze trajectorie (pick = (80,Baan(5), place = (-70, Baan(0)),

zijn deze twee parameters: αModus,10,15 = 695s en βMean,10,15 = 765.6s. Deze waar-

den kunnen vervolgens gebruikt worden ter vergelijking van dezelfde parameters van

een ander systeem. Dit zijn de echte kwaliteitparameters: daar waar de deadlockpa-

rameters een maat voor de fouten was, zijn deze twee parameters een (eerste) maat

voor de vertragingen. Aangezien beide eenzelfde trend vertegenwoordigen zal slechts

een van de twee parameters gebruikt moeten worden. In deze scriptie wordt de mo-

dusparameter voorop geplaatst. Samen met de 95e percentielparameter (de maat

voor de spreiding), kan dan een objectief beeld gegeven worden van de distributies.


1 2 3 4 5 6 7 8 9 10 11 1232

34

36

38

40

42

44

46

48

# robots

tijd

(se

c)

gemiddeldemodus

Figuur 4.6: Evolutie van het gemiddelde en de modus van de place-opdrachten in functie

van aantal carriers

4.2.3 Bespreking van het 95e percentiel

De typische maat voor de spreiding is traditiegetrouw de variantie van de verdeling.

Deze parameter heeft echter slechts een visuele betekenis bij een normale distributie.

Aangezien hier niet gepoogd wordt om het probleem theoretisch te benaderen, maar

eerder van uit een praktische hoek, zal in plaats van de spreiding het 95e percentiel

gebruikt worden. Voor deze tijd is 95 % van de carriers op bestemming aangekomen.

1 2 3 4 5 6 7 8 9 1030

35

40

45

50

55

60

# robots

tijd (

sec)

95e percentiel pick opdrachten

95e percentiel place opdrachten

Figuur 4.7: Evolutie van het 95e percentiel van de pick-opdrachten en de place-

opdrachten in functie van aantal carriers


Aantal Carrier- 95e 95e

carriers densiteit percentiel percentiel

pick-opdacht place-opdacht

Eenheid meter/car. s s

2 100 38.0 39.9

3 66.7 42.0 43.9

4 50 44.0 45.9

5 40 46.0 48.9

6 33.3 49.0 51.9

7 28.6 52.0 52.9

8 25 55.0 54.9

9 22.2 57.0 57.9

10 20 59.0 58.9

Som 442 455.1

Tabel 4.4: Evolutie van het 95e percentiel van de pick-opdrachten en de place-opdrachten

in functie van aantal carriers

Opnieuw kan vastgesteld worden dat deze karakteristiek afhankelijk is van de (ho-

rizontale) carrierdensiteit. Het geeft nochtans een goed beeld van de mogelijke

spreiding op de lead-time. We definieren een parameter voor de spreiding :

95e percentielparameter γ95,k,n:

Gegeven een vaste trajectorie (pick, place) en een set regels, over k simulaties,

gaande van 1 tot n carriers, over een vaste kadelengte en een randomgegenereerde

takenverdeling.

γ95,n,k : wordt gedefinieerd als de som van de 95e percentiel van de pick en de

place, gesommeerd gaande van 1 tot n carriers.

γ95,n,k =�n

1

�placepick [95e%]i,j

Hier is de γ95,n,k gelijk aan 897.1 (s). Gegeven de minimale transporttijd (pick-

opdracht = 33 seconden), en de waarde van het 95e percentiel, kan nu per car-

rierdensiteit een bepaalde buffertijd gedefinieerd worden. De kritische transporttijd

voor het afleveren van de container zal de minimale transporttijd en deze buffertijd


moeten omvatten. Dit wordt geıllustreerd op onderstaande tijdsbalk, en berekend

voor de trajectorie uit het voorbeeld van paragraaf 4.2.1:

Figuur 4.8: Rol buffertijd voor het behalen van de deadline

Volgens deze methode zou de totale transporttijd voor het voorbeeld 42 seconden

moeten zijn. Dit betekent dat de buffertijd ’slechts’ 9 seconden omvat, maar dat in

die tijd 95 % van de opdrachten aangekomen zou zijn. Zoals beredeneerd zou volgens

de analytische schatting (zonder simulatie) de totale transporttijd 60 seconden zijn,

wat een buffertijd levert van 27 seconden. Dit lijkt echter een sterke overschatting

waar te veel aandacht gegeven werd aan zeldzame situaties.

Deze methode levert een hoge precisie, maar vergt dan ook een enomrme hoeveelheid

data: om correcte gegevens te hebben zullen er realtime proeven moeten uitgevoerd

worden voor alle (gediscretiseerde) trajectorien en met alle carrierdensiteiten. De

distributie is namelijk nodig om de 95e percentiel te vinden, waarop de tijdsbuffer

gebaseerd is. De scheduler zal vervolgens moeten interpoleren, gebruik makende van

deze data. Deze tijdsbuffer hangt namelijk van verschillende parameters af:

• De carrierdensiteit en de lengte van de kade: zij definieren de aard van de

toestand.

• De trajectorie: men zal proeven moeten uitvoeren waar de pick en place tel-

kens 10 meter verschoven worden, bij gelijkblijvende andere omstandigheden.

Vervolgens zal de scheduler kunnen interpoleren tussen deze gegevens.

• De aard van de opdracht: naargelang de prioriteiten van de haven, zullen

de pick- of de place-opdrachten een grotere buffertijd krijgen. Daar waar de

bottleneck van het systeem ligt, zal de buffertijd het grootste zijn. Dit is dan

een apparte zekerheidstijdsbuffer.

4.3 Bespreking van de ratio lead-time gedeeld door de afstand in vogelvlucht 66

Er zullen dus vele proeven moeten uitgevoerd worden om deze buffertijd juist in te

schatten voor alle opdrachten. Men kan deze methode van bufferen als bottom-up

bestempelen, aangezien ze uitgaat van proefondervindelijke details om de buffertijd

in te schatten. Een andere methode wordt gegeven in paragraaf 4.3 op basis van

de gemiddelde snelheid, die eerder top-down is: zeer algemene informatie levert een

schatting voor de tijdsbuffer.

4.3 Bespreking van de ratio lead-time gedeeld door

de afstand in vogelvlucht

De werkelijke gemiddelde snelheid van de carriers is eigenlijk onbelangrijk voor het

systeem. Het doel van dit systeem is namelijk het vervoeren van de containers.

Bijgevolg lijkt het interssanter om de gemiddelde snelheid van de container te bere-

kenen. We beschouwen de container namelijk als een black box die niets merkt van

de gekozen trajectorie. De gecorrigeerde gemiddelde snelheid is dan gelijk aan de

afstand in vogelvlucht (tussen pick- en placeopdracht) gedeeld door de transporttijd.

Deze werkwijze levert figuur 4.9. Deze grafiek verschaft veel, doch onnauwkeurige

informatie. Voor een bepaalde carrierdensiteit geeft deze grafiek de gemiddelde

snelheid voor alle opdrachten. Er kan vervolgens opnieuw met het 95e percentiel

gewerkt worden en een buffertijd gevonden worden. Toegepast op het voorbeeld uit

4.2.1 geeft dit het volgende:

• 95e percentiel = 2.9 m/s

• Afstand in vogelvlucht =�

(80 + 70)2 + 522 = 158.8 m

• Geschatte tijd = 54.7 s

• Buffertijd = 54.7 s - 33 s = 21.7 s

De geschatte lead-time is volgens deze methode gelijk aan 54.7 seconden (terwijl

geweten is dat 95 % van de carriers al zijn aangekomen na 42 seconden). Dit betekent

dat deze methode en de daarmee gepaard gaande grafiek 4.9, in haar huidige vorm

geen nauwkeurige schatting geeft van de buffertijd en dus nutteloos is. Een voordeel

is wel dat ze gemakkelijk bekomen wordt: laat alle carriers (randomgegenereerde)

taken uitvoeren, hou hun vogelvlucht afstand en transporttijd bij en zet dit allemaal

uit in een grafiek. Dit betekent dat in deze methode alle carriers informatie leveren,

wat efficienter lijkt dan de methode uitgelegd in paragraaf 4.2, waar slechts een

carrier informatie levert en de andere carriers modaal verkeer simuleren.


2 3

4 5

6 7

8 9

10

0 1 2 3 4 5 6

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

Snelheid (m/sec)Aantal robots

Pro

ba

bili

teit

Figuur 4.9: Histogram van de gecorrigeerde gemiddelde snelheid, zoals gedefinieerd in

paragraaf 4.3, bij stijgend aantal carriers

De oorzaak van de overschatting van de buffertijd is het verschil in lengte van de

trajectories: een korte, eerder verticale beweging zal vooral bestaan uit verticale

stukken (2/3 van de maximale snelheid) en draaibewegingen (1/3 van de maximale

snelheid), terwijl een langere beweging grotendeels bestaat uit een horizontaal stuk

(maximale snelheid). Om dit inzicht te bekrachtigen wordt een simulatie gegene-

reerd van 28800 seconden met 2 carriers. In plaats van alle data samen te verwerken,

vormen we groepen met als karakteristiek de vogelvluchtafstand tussen de pickop-

dracht en de placeopdracht. Per groep wordt dan de distributie van de gecorrigeerde

gemiddelde snelheid berekend, en hiervan de 95e percentiel genomen. Deze werk-

wijze resulteert in onderstaande grafiek. Men ziet een duidelijke trend die aangeeft

dat naarmate de afstand groter wordt de gemiddelde snelheid ook stijgt.


[ 40 50 ][ 50 60 ]

[ 60 70 ][ 70 80 ]

[ 80 90 ][ 90 100]

[100 110][110 120]

[120 130][130 140]

[140 150][150 160]

[160 170][170 180]

[180 190]

11.5

22.5

33.5

44.5

55.5

0

0.1

0.2

0.3

0.4

afstand (m)

Snelheid (m/sec)

Pro

ba

bili

teit

95e percentiel

Figuur 4.10: Histogram van de gemiddelde snelheid per groep, zoals gedefinieerd in 4.3,

bij een carrierdensiteit van 100 m/carrier (2 carriers op 200 meter)

Aangezien de bepaling van een buffertijd, gebaseerd op grafiek 4.9, te onnauwkeurig

was, wordt er gepoogd een betere schatting te maken op basis van grafiek 4.10. De

sommatie van alle groepen in grafiek 4.10 komt overeen met de volledige verdeling

van carrierdensiteit 2 in grafiek 4.9. Passen we deze verfijnde methode toe op het

schatten van een buffertijd op het voorbeeld van 4.2.1, dan bekomen we:

• Afstand in vogelvlucht = 158.8 m

• 95e percentiel voor die groep = 3.9 m/s

• Geschatte tijd = 40.5 s

• Buffertijd = 40.5 s - 33 s = 7.5 s

Dit is een zeer aannemelijk resultaat. De geschatte tijd is net iets minder dan

de schatting op basis van de effectieve 95e percentiel van de aankomsttijden (42

seconden, buffertijd van 9 seconden). Als samenvatting worden de vier besproken

methodes tegen elkaar afgewogen:


Methode Buffer- nauwkeurig- inspanning

tijd heid

Eenheid s - -

Analytisch 27 laag zeer hoog tot

99,9% van de onmogelijk bij

aankomsttijden > 3 carriers

→ overschatting → te arbeidsintensief

95e percentiel 9 zeer hoog zeer hoog

aankomsttijden precies 95% van de 3 dag/traj./carrierdens.

aankomsttijden ∆ bij ∆ kadelengte

1 carrier vaste traj., onbruikbaar

miniem deel info bruikbaar

testtijd: > 1 jaar, intensief

→ perfect → te arbeidsintensief

95e percentiel 21.7 laag laag

gecorrigeerde 98% van de 2 weken/carrierdens.

snelheden aankomsstijden normale taken, alle bruikbaar

testtijd: 6 maanden, monitoring

→ overschatting → aannemelijk

95e percentiel 7.5 zeer (te) hoog laag

gecorrigeerde 91% van de 2 weken/carrierdens.

snelheden aankomsstijden normale taken, alle bruikbaar

in groepen testtijd: 6 maanden, monitoring

→ te scherp → aannemelijk

Tabel 4.5: Vergelijking van de verschillende schattingsmethodes voor de buffertijd

Er kan besloten worden dat de laatste methode een goede en efficiente methode is.

Het enige dat kan opgemerkt worden is dat deze methode een te kleine buffertijd

geeft. Willen we 95 % van de aankomsttijden, dan zal men eerder het 97e percentiel

van de gecorrigeerde gemiddelde snelheid moeten nemen. Wel moet opgemerkt

worden dat deze methode enkel voor het beschouwde systeem goede resultaten geeft:

het is gebaseerd op de opdeling van de rijzone in banen en op het verschil in snelheden

tussen de verticale en horizontale stukken. Een laatste kwalitatieve grafiek wordt

gegeven in figuur 4.11. Het is gebaseerd op figuur 4.9 en geeft een algemeen beeld

van de afleversnelheid van de containers.

4.4 Bespreking van de kans op deadlock op basis van de partiele carrierdensiteit 70

1 2 3 4 5 6 7 8 9 10 11 120

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

aantal robots

Gem

idde

lde/

Varia

ntie

sne

lhei

d

Gemiddelde (m/sec)Variantie (m/sec)2

Figuur 4.11: Karakteristiek van het systeem: de gemiddelde en de variantie van de ge-

corrigeerde snelheid

Ter vergelijking van verschillende systemen wordt nog een laatste kwaliteitskarak-

teristiek ingevoegd. Deze karakteristiek onderscheidt zich van de vier andere door

het ontbreken van de trajectorie-afhankelijkheid.

Gecorrigeerde gemiddelde snelheidskarakteristiek υcorr.gem.snelh.,n:

Deze grafiek bestaat enerzijds uit de rechte of trendlijn die de gecorrigeerde

gemiddelden verbindt, en anderzijds uit de rechte of trendlijn die de varianties op

die snelheden verbindt.

Deze grafiek geeft voor alle carrierdensiteiten aan wat de gemiddelde tijd is voor het

afleveren van een container. Men kan dit interpreteren als de snelheid van het sys-

teem per carrierdensiteit. In deze scriptie wordt dit als een zeer goede karakteristiek

beschouwd, aangezien het niet te veel gespecifieerd is en een goed en volledig beeld

geeft van de belangrijke eigenschappen. Men kan onmiddelijk zien of het systeem

snel en gespreid is, of eerder traag maar stipt.

4.4 Bespreking van de kans op deadlock op basis

van de partiele carrierdensiteit

Het begrip en concept ’carrierdensiteit’ werd al sinds het begin van de resultaten

gebruikt, terwijl er van werd uit gegaan dat dit de determinerende factor was. Zes


carriers op een kade van 200 meter komen overeen met 45 carriers op een kade van

1500 meter, aangezien er in beide gevallen 33 meter per carrier beschikbaar was.

Maar deze hypothese werd tot nu toe nergens verantwoord. Er zal in deze paragraaf

getracht worden om dit inzicht te verbeteren.

Bij een simulatie van 18 carriers op een kade van 600 meter werden de deadlocksi-

tuaties opgemeten en weergegeven in tabel 4.6.

Simulatie 1 Simulatie 2

x-positie (m) y-positie(m) x-positie(m) y-positie(m)

-40 0 180 0

-70 0 40 0

-100 0 100 15

-70 0 -70 0

94 20 -40 0

-50 0 -70 0

82 28 -110 0

80 24 10 0

30 0 -10 0

-70 0 160 0

60 0 -110 0

-20 0 -147 32

-60 0 -138 32

-100 0 -50 0

100 0 -50 0

47 24 -110 0

-100 0 10 0

-120 0

100 0

-50 0

-40 0

-60 0

220 0

Tabel 4.6: Posities waar deadlocksituaties optreden

Verschillende zaken vallen op:

• Het aantal deadlocksituaties (17 en 23) is veel groter dan voorspeld door de

theorie gebaseerd op gelijke carrierdensiteiten (1.53).


• Respectievelijk 13 en 20 deadlocksituaties kwamen voor in de stack, waar de

carrier de stack niet kan verlaten door een lange colonne carriers die voorbij-

rijdt op baan 1 en baan 2.

• De overblijvende 4, respectieveijk 3, deadlocksituaties zijn ’echte’ deadlocksi-

tuaties, wat nog steeds meer is dan voorspeld door de theorie gebaseerd op

gelijke carrierdensiteiten (1.53).

• Alle deadlocksituaties vinden plaats in het interval [100,-100] op een kade die

[300,-300] beslaat.

Bij verdere analyse wordt er vastgesteld dat bij grotere kadelengtes en grotere aan-

tallen carriers 3 soorten deadlocksituaties optreden:

1. Deadlocksituaties ten gevolge van de onmogelijkheid tot het verlaten van de

stack: Tot hier toe werd niet ingegaan op de vraag hoe het simulatieprograma

deadlocksituaties herkent. In pragagraaf werd dit omschreven als ”een situatie

waarin er geen voorrang heerst, minstens twee carriers staan dus stil, en zullen

blijven stilstaan”. In het programma werd dit vervangen door een teller die

nagaat hoe lang een carrier blijft stilstaan. Wordt een limiet overschreden, dan

wordt een deadlock genoteerd en wordt de carrier ”manueel”(in het programma

instantane reınitialisatie) terug naar de oorsprong gebracht. Indien men deze

twee concepten vergelijkt, dan stelt men vast dat de situatie waar de carrier

niet kan vertrekken uit de kade geen deadlocksituatie is. Dit is niettemin een

groot probleem. Samenvattend kan gezegd worden:

”Indien systemen gebruikt worden die gebaseerd zijn op het concept

van ”equivalente carrierdensiteit”, moet bij grote aantallen carriers

gelet worden op de horizontale verzadiging. Dit betekent dat een

lange colonne grecreeerd wordt op een baan. Er werd rekening ge-

houden met het feit dat de carriers de stack nog konden verlaten bij

een horizontaal verzadigde baan. Indien dit gebeurt bij 2 opeenvol-

gende banen, dan wordt het kruisen van deze banen onmogelijk, en

levert dit problemen op.”


Figuur 4.12: Horizontale verzadiging op baan 1 (links) en op baan 1 en baan 2 (rechts).

Verticale verzadiging (onder)

Een eerste oplossing zou het regelen van de horizontale carrierdensiteit kunnen

zijn, door bijvoorbeeld een intelligente scheduler. Indien dit onmogelijk is, kan

een andere oplossing een stapsgewijs invoegmanoeuvre zijn: indien de carrier

naar baan 2 of baan 3 wilt, moet hij eerst een stuk meerijden op baan 1 tot

er een draaimogelijkheid is. Hieruit blijkt dat er regelsystemen zijn die beter

voor lange kades werken, en regelsystemen die beter voor korte kades werken.

Deze benadering levert ook een uitleg betreffende de (kwadratische) trend van

toenemende deadlocksituaties bij stijgende carrierdensiteit.

2. Deadlocksituaties ten gevolge van lokale densiteitspieken: Analoog kan, bij

grotere carrieraantallen, ook lokale verticale verzadiging optreden. Dit is een

gevolg van lokale carrierdensiteitspieken. Opnieuw zijn deze deadlocksituaties

eerder situaties waar de carrier te lang moet wachten en de teller zijn limiet

bereikt. Hieraan kan verholpen worden door het beter verdelen van de carriers

in de verticale zin. Van de opgemeten deadlocksituaties wordt de helft van de

niet-stack deadlocksituaties geweten aan deze verzadiging.

3. Deadlocksituaties ten gevolge van de regels: Zoals gemeld voor de kleine kade,

zijn er nog steeds gemiddeld 1.53 deadlocksituaties voor carrierdensiteit 33

m/carrier.

Samenvattend mogen we stellen dat het besproken systeem, met de huidige regels,

niet overweg kan met de deadlocksituaties in de stack zonder intelligente scheduler.

Het toevoegen van regels kan ook een oplossing bieden. Men kan bijvoorbeeld in

het geval van colonnevorming, bijkomende eisen stellen voor baan 1 en baan 2.


Colonnevorming kan via een kleine berekening waargenomen worden, en er kan

vervolgens een extra subroutine opgestart worden:

• Vergroot de veiligheidsafstand op baan 1

• Meet de afstanden

• Vorm een welbepaald patroon op baan 1 en baan 2

Figuur 4.13: Aanpassing van de configuratie van baan 1 en 2 om de problemen in de

stack op te lossen

Dit vergt een extra subroutine, doch verwijdert het probleem van de deadlocksitu-

aties in de stack. Vervolgens kan men de deadlocks ten gevolge van lokale densi-

teitspieken behandelen, en het systeem optimaliseren. Dit valt echter buiten het

bestek van deze scriptie.

CONCLUSIES EN VERDER ONDERZOEK 75

Hoofdstuk 5

Conclusies en verder onderzoek

5.1 Conclusie

Er kan worden geconcludeerd dat het voorgestelde, horizontale systeem zeker levens-

vatbaar is. Er worden goede resultaten geboekt op een kade van 200 meter met 6

robots. Dit systeem voldoet aan de specificaties voor een kleine kadelengte.

Maar indien de dimensies vergroot worden, treden de volgende problemen op:

• Bij een grotere kadelengte treedt het probleem van het verlaten van de stack

op: de twee eerste banen zijn zo druk bezet dat de carriers niet meer uit de

stack kunnen komen. Mogelijke oplossingen zijn:

– een intelligente scheduler

– toevoegen van de voorgestelde subroutine die de colonnevorming tot een

aannemelijke configuratie omvormt

Wij zijn van oordeel dat verder onderzoek moet worden gevoerd naar de ho-

rizontale verzadiging van de twee eerste banen en een oplossing hiervoor.

• Bij hogere carrierdensiteiten nemen de deadlocksituaties alsmaar sneller toe

(zie figuur 4.1). Dit betekent enerzijds dat men het totaal aantal carriers

binnen de perken moet houden (onder het maximale aantal), maar ook dat

men de lokale carrierdensiteiten in het oog moet houden, zoals uitgelegd in

paragraaf 4.4. Onderzoek moet gevoerd worden naar de verticale verzadiging

veroorzaakt door lokale carrierdensiteitspieken.

Vooral het eerste probleem is typisch voor dit banensysteem. Dit zou niet het geval

zijn voor een direct systeem. Dit is waarschijnlijk het belangrijkste argument tegen

dit systeem.

5.2 Verder onderzoek 76

5.2 Verder onderzoek

De volgende stap in de optimalisatie van het gehele systeem is het ontwikkelen van

een strategie voor een intelligente scheduler. Deze scheduler zou, gegeven de zwakke

punten van het systeem, kunnen inspelen op de begin- en eindpunten van de trajecto-

rieen. Vervolgens zou gestreefd moeten worden naar een perfecte samenwerking van

het besproken systeem met deze scheduler, om zo tot de best mogelijke resultaten

te bekomen.

Eens het volledige systeem (regelsysteem en scheduler) de beoogde efficientie en

performantie bereikt hebben volgens de simulatie, kan de volgende stap gezet worden

in het onderzoek. Men moet de simulatie waarheidsgetrouw maken, wat voor het

simuleren zelf wellicht een paar parallelle computers zal vergen. Er zal dan rekening

moeten gehouden worden met een aantal zaken.

• De inertie van de carriers die in deze context niet verwaarloosbaar is. Versnel-

lingen zullen ook berekend moeten worden.

• De fouten en zwaktes van de optische sensoren. Zo kunnen ruis en metingsfou-

ten leiden tot een slechte positie- of snelheidsbepaling. Door de aangebrachte

structuur kan men deze fouten allicht wegwerken door voorspellingsalgorit-

men. Ook moet rekening gehouden worden met het feit dat een carrier achter

een andere carrier kan staan, en dus niet opgemerkt kan worden.

• In werkelijkheid zal er een aanvullende radiocommunicatie zijn. Dit moet erbij

gemodelleerd worden.

5.3 Kwaliteit

Door middel van de ingevoerde parameters werd een basis gelegd voor de vergelij-

king tussen twee systemen. De kwaliteitsfiche van het besproken systeem werd in

bijlage B toegevoegd, zie figuur B.1. Verder werden verschillende methodes verge-

leken voor het schatten van de benodigde buffertijd. Het is dan ook afwachten tot

andere regelsystemen gemodelleerd en gesimuleerd worden, eer men kan beslissen

welk systeem het beste is. De auteurs van dit werk zijn er wel van overtuigd dat dit

systeem in de realiteit goede resultaten zal leveren.

GEBRUIKSHANDLEIDING 77

Bijlage A

Gebruikshandleiding

De simulatie wordt opgestart via de file Fysische Omkadering.m. De gewenste

simulatie instellingen kunnen aangepast worden in de initialisaties bovenaan het

bestand. De voornaamste zijn:

1. Simulatie tijd: de gewenste simulatietijdsduur

2. Lengte kade: de lengte van de map

3. Aantal robots: het aantal carriers dat men wenst te simuleren

Afhankelijk van de instellingen kunnen verschillende grafieken worden weergeven.

Met de variabele fys plot, kan de fysische map getekend worden. Deze geeft visueel

de posities van de verschillende carriers weer. Onderaan worden de voornaamste

parameters van elke robot opgelijst (zie figuuur: A.1).

Figuur A.1: Weergave tijdsverloop carriers

GEBRUIKSHANDLEIDING 78

Met de variabele trajectoryplot robots(een vector met als lengte het aantal ro-

bots) kan per robot de volledige huidige trajectorie weergegeven worden, zoals te

zien in figuur: A.2

−100−80−60−40−20020406080100

StackBaan1Baan2Baan3Baan4

Baan5Baan6Baan7water

Figuur A.2: Trajectorie per robot

KARAKTERISTIEKE FICHE 79

Bijlage B

Karakteristieke fiche

Mits aanpassing van de veiligheidszone, zodat de botsingen helemaal wegvallen (tot

een aannemelijke carrierdensiteit).

Figuur B.1: Kwaliteitsfiche

LIJST VAN FIGUREN 80

Lijst van figuren

1.1 Overzicht van het dok . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Een carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Kadekraan, carrier met container en stackkraan . . . . . . . . . . . . 6

2.1 Trade-off tussen de verschillende doelstellingen . . . . . . . . . . . . . 7

2.2 Indeling van de rijzone in banen . . . . . . . . . . . . . . . . . . . . . 9

2.3 Overweging tussen beide systemen . . . . . . . . . . . . . . . . . . . . 10

2.4 Vergelijking risicozone . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Model van de map in Matlab . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Vergelijking tussen de eerste (links) en de derde (rechts) configuratie . 14

2.7 Schema van precisiepositiesysteem . . . . . . . . . . . . . . . . . . . . 16

2.8 Structuur van het simulatieprogramma . . . . . . . . . . . . . . . . . 17

3.1 Model van de map in Matlab . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Model van de map in Matlab met carriers . . . . . . . . . . . . . . . 24

3.3 Structuur van de klasse objecten ’robot’ . . . . . . . . . . . . . . . . 25

3.4 Voorbeeld generatie van waypoints . . . . . . . . . . . . . . . . . . . 31

3.5 Draaimogelijkheden vanuit baan 0 . . . . . . . . . . . . . . . . . . . . 32

3.6 Flowchart waypoint algoritme: overzicht . . . . . . . . . . . . . . . . 32

3.7 Flowchart waypoint algoritme: case 0 . . . . . . . . . . . . . . . . . . 33

3.8 Flowchart waypoint algoritme: case 1/2 . . . . . . . . . . . . . . . . . 34

3.9 Flowchart waypoint algoritme: case 3/4 . . . . . . . . . . . . . . . . . 35

3.10 Flowchart draaimogelijkheid: overzicht . . . . . . . . . . . . . . . . . 38

3.11 Flowchart draaimogelijkheid: sub: robot op baan . . . . . . . . . . . 40

3.12 Flowchart draaimogelijkheid: sub: robot in draaibeweging . . . . . . 43

3.13 Flowchart draaimogelijkheid: sub: robot in verticale beweging . . . . 44

3.14 Flowchart vertraag: overzicht . . . . . . . . . . . . . . . . . . . . . . 46

3.15 Flowchart vertraag: sub: op baan . . . . . . . . . . . . . . . . . . . . 47

3.16 Flowchart vertraag: sub: afdraaien baan . . . . . . . . . . . . . . . . 48

3.17 Voorbeeld van de situatie waar een frontale botsing zou optreden en

de oplossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

LIJST VAN FIGUREN 81

3.18 Stop om voorrang te verlenen aan robot die wenst af te draaien . . . 50

4.1 Uitgemiddeld aantal deadlocksituaties in de 15 simulaties van 28800

seconden in functie van aantal carriers . . . . . . . . . . . . . . . . . 55

4.2 Evolutie van de picktijden in functie van aantal carriers . . . . . . . . 58

4.3 Verschillende mogelijke rajectorien om van de place-opdracht naar de

pick-opdracht te komen . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.4 Evolutie van de placetijden in functie van aantal carriers . . . . . . . 60

4.5 Evolutie van het gemiddelde en de modus van de pick-opdrachten in

functie van aantal carriers . . . . . . . . . . . . . . . . . . . . . . . . 61

4.6 Evolutie van het gemiddelde en de modus van de place-opdrachten in

functie van aantal carriers . . . . . . . . . . . . . . . . . . . . . . . . 63

4.7 Evolutie van het 95e percentiel van de pick-opdrachten en de place-

opdrachten in functie van aantal carriers . . . . . . . . . . . . . . . . 63

4.8 Rol buffertijd voor het behalen van de deadline . . . . . . . . . . . . 65

4.9 Histogram van de gecorrigeerde gemiddelde snelheid, zoals gedefini-

eerd in paragraaf 4.3, bij stijgend aantal carriers . . . . . . . . . . . . 67

4.10 Histogram van de gemiddelde snelheid per groep, zoals gedefinieerd

in 4.3, bij een carrierdensiteit van 100 m/carrier (2 carriers op 200

meter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.11 Karakteristiek van het systeem: de gemiddelde en de variantie van de

gecorrigeerde snelheid . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.12 Horizontale verzadiging op baan 1 (links) en op baan 1 en baan 2

(rechts). Verticale verzadiging (onder) . . . . . . . . . . . . . . . . . 73

4.13 Aanpassing van de configuratie van baan 1 en 2 om de problemen in

de stack op te lossen . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.1 Weergave tijdsverloop carriers . . . . . . . . . . . . . . . . . . . . . . 77

A.2 Trajectorie per robot . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

B.1 Kwaliteitsfiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

LIJST VAN TABELLEN 82

Lijst van tabellen

1.1 Eigenschappen van een carrier . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Voorbeeld van de supervisormatrix . . . . . . . . . . . . . . . . . . . 22

3.2 Interpretatie van de snelheden d.m.v. de regels . . . . . . . . . . . . 23

4.1 Uitgemiddeld aantal deadlocksituaties in de 15 simulaties van 28800

seconden, per carrierdensiteit . . . . . . . . . . . . . . . . . . . . . . 54

4.2 Aantal botsingen gedurende 15 simulaties van 28800 seconden, per

carrierdensiteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 De opgetelde gemiddelden en modi van de pick-opdrachten en place-

opdrachten, voor 15 simulaties van 28800 seconden, per carrierdensiteit 62

4.4 Evolutie van het 95e percentiel van de pick-opdrachten en de place-

opdrachten in functie van aantal carriers . . . . . . . . . . . . . . . . 64

4.5 Vergelijking van de verschillende schattingsmethodes voor de buffer-

tijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.6 Posities waar deadlocksituaties optreden . . . . . . . . . . . . . . . . 71

botsingen vermijden bij autonome voertuigenlib.ugent.be › fulltxt › rug01 › 001 › 805 ›...

Documents