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
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
Alexander Van Caekenberghe
juni 2011
Botsingen vermijdentussen
autonome voertuigendoor
Tanguy Claeys
Alexander Van Caekenberghe
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 Fysische omschrijving en terminologie 4
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:
1.2 Fysische omschrijving en terminologie 5
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 Fysische omschrijving en terminologie 6
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.
2.1 Horizontaal versus verticaal systeem 9
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 Horizontaal versus verticaal systeem 10
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.1 Horizontaal versus verticaal systeem 11
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).
2.1 Horizontaal versus verticaal systeem 12
• 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 Structuur van het simulatieprogramma 18
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’.
2.3 Structuur van het simulatieprogramma 19
• 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
3.1 Fysieke omkadering 22
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:
3.1 Fysieke omkadering 23
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
case: Baan(0) case: Baan(5/6/7)
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
case: Baan(0) case: Baan(5/6/7)
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.
3.5 Draaimogelijkheid 38
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
3.5 Draaimogelijkheid 39
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.
3.5 Draaimogelijkheid 40
Kruisen banen?*
switch y
Gevarenzone
?**
Bepalen tijden botsing:
(tx & ty)***
|tx − ty| < t
OK=0
Gevarenzone
V=0 ?**OK=0
Gevarenzone
?**
Bepalen tijden botsing:
(tx & ty)***
|tx − ty| < t
OK=0
Gevarenzone
V=0 ?**OK=0
Gevarenzone
?**
Bepalen tijden botsing:
(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:
3.5 Draaimogelijkheid 41
• 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.
x− xi < breedte laan & xi <0
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:
x− xi < breedte laan & xi <0
of
x− xi > -breedte laan & xi >0
3.5 Draaimogelijkheid 42
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
3.5 Draaimogelijkheid 43
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.5 Draaimogelijkheid 44
Start
Kruisen banen?*
switch y
|x− xi|<VZ*****
OK=0
|x− rd − xi|<VZ*****
OK=0
|x+ rd − xi|<VZ*****
OK=0
Einde
y
baan(0)
baan(1,2,5,6,7)
baan(3,4)
y
y
y
n
n
n
nbaan(3,4)
Figuur 3.13: Flowchart draaimogelijkheid: sub: robot in verticale beweging
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?
vertraag en stop indien nodig
x > xi
|y − yi| <BB
vertraag en stop indien nodig
Kruisen banen?
vertraag en stop indien nodig
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:
3.7 Frontale verticale botsing 50
– 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:
De carrier moet stoppen voordat deze de baan betreedt die de
richtingaanwijzer van het obstakel aanduidt.
– Robot richting stack:
Dit deel verloopt analoog aan hogerop besproken onderdeel: indien de
carrier richting kade beweegt. Hieronder zijn achtereenvolgens de beslis-
singsstappen weergegeven:
3.7 Frontale verticale botsing 51
∗ 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:
De carrier moet stoppen voordat deze de baan betreedt die de
richtingaanwijzer van het obstakel aanduidt.
· Tegengestelde richting:
De carrier moet stoppen voordat deze de baan betreedt die de
richtingaanwijzer van het obstakel aanduidt.
• 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.
3.7 Frontale verticale botsing 52
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
4.1 Bespreking van het aantal botsingen en deadlocksituaties 55
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
4.1 Bespreking van het aantal botsingen en deadlocksituaties 56
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
4.2 Bespreking van de verdeling van de lead-time 58
• 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
4.2 Bespreking van de verdeling van de lead-time 59
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
4.2 Bespreking van de verdeling van de lead-time 60
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 Bespreking van de verdeling van de lead-time 61
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.
4.2 Bespreking van de verdeling van de lead-time 62
• β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.
4.2 Bespreking van de verdeling van de lead-time 63
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
4.2 Bespreking van de verdeling van de lead-time 64
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
4.2 Bespreking van de verdeling van de lead-time 65
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.
4.3 Bespreking van de ratio lead-time gedeeld door de afstand in vogelvlucht 67
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.
4.3 Bespreking van de ratio lead-time gedeeld door de afstand in vogelvlucht 68
[ 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:
4.3 Bespreking van de ratio lead-time gedeeld door de afstand in vogelvlucht 69
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
4.4 Bespreking van de kans op deadlock op basis van de partiele carrierdensiteit 71
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).
4.4 Bespreking van de kans op deadlock op basis van de partiele carrierdensiteit 72
• 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.”
4.4 Bespreking van de kans op deadlock op basis van de partiele carrierdensiteit 73
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.
4.4 Bespreking van de kans op deadlock op basis van de partiele carrierdensiteit 74
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