TDK DOLGOZAT
Csutak Bal´ azs
Komplex ´ utvonaltervez´esi probl´em´ ak anal´ızise ´es megold´ asa t¨ obb ´ agensb˝ ol ´ all´ o
rendszerekre
Analysis and solution of complex route-planning problems for multi-agent systems
Bal´ azs Csutak
Computer Science Engineering BSc
Supervisor:
Prof. G´ abor Szederk´ enyi
P´ azm´ any P´ eter Catholic University
Faculty of Information Technology and Bionics
2019.01.08
Table of contents / Tartalomjegyz´ ek
Contents
Table of contents / Tartalomjegyz´ek 1
Abstract / Tartalmi ¨osszefoglal´o 2
1 Introduction 3
2 Detailed task description 5
3 Dynamic routing 6
3.1 Formal problem statement . . . 6
3.2 Stenzel’s routing algorithm . . . 7
3.3 Resource allocation using time windows . . . 9
3.4 Route computation . . . 10
3.5 Modeling AGV movements and the routing environment . . . 15
3.6 Resolving practical problems . . . 16
3.6.1 Minor disturbances . . . 16
3.6.2 Severe latencies . . . 17
4 Implementation 18 4.1 The MATLAB framework . . . 18
4.1.1 AGV modeling . . . 18
4.1.2 Main simulation loop . . . 19
4.2 Routing algortithm . . . 20
4.2.1 Factory graph . . . 20
4.2.2 Planner graph . . . 20
4.2.3 Resource allocation . . . 21
4.2.4 Route computation . . . 22
4.2.5 Parking places . . . 22
4.2.6 Dispatching . . . 23
4.2.7 Extension to 3D models . . . 23
5 Test cases and simulation results 26 5.1 Test case: the factory cell in Gy˝or . . . 26
5.2 Test case: extended factory cell . . . 28
Summary 30
Acknowledgements 31
References 31
Tartalmi ¨ osszefoglal´ o
A sz´all´ıt´asi ig´enyek alapj´an t¨ort´en˝o (megadott szempontb´ol) optim´alis ´utvonaltervez´es kulcsfontoss´ag´u feladat az automatiz´alt mobilrobotokon alapul´o ipari rendszerek pro- duktivit´as´anak ´es hat´ekonys´ag´anak jav´ıt´as´aban. Az alkalmazott modellekt˝ol ´es felt´e- telez´esekt˝ol f¨ugg˝oen az ilyen feladatok sz´am´ıt´asi komplexit´asa nagyon k¨ul¨onb¨oz˝o lehet.
L´eteznek megk¨ozel´ıt´esek, melyek val´oban megadhatj´ak a ”legjobb” megold´ast, de sz´am´ıt´asi szempontb´ol rosszul sk´al´az´odnak, ha a t´erk´ep m´erete vagy az ´agensek sz´ama n¨ovekszik.
Ebben a munk´aban egy ett˝ol elt´er˝o megk¨ozel´ıt´est mutatok be, melyet egy ´utvonaltervez´esi probl´em´akra szuboptim´alis, ´amde val´os idej˝u megold´ast biztos´ıt´o algoritmus vizsg´alata
´
es implement´al´asa k¨ovet.
A vizsg´alt algoritmus l´enyege, hogy m´ar a tervez´eskor elker¨uli a lehets´eges probl´em´akat, olyan ´utvonalak el˝o´all´ıt´as´aval, melyek fel´ep´ıt´esi m´odjukb´ol ad´od´oan konfliktus-, ¨utk¨oz´es-
´
es elakad´asmentesek. A jelen munka alapj´at k´epez˝o m´odszert ´ugy terveztem ´ujra, hogy lehet˝ov´e tegye t¨obb, k¨ul¨onb¨oz˝o t´ıpus´u (f¨oldi ´es l´egi) j´arm˝u egy rendszerven val´o kezel´es´et, mindezt az el˝oredefini´alt mozg´asprimit´ıvek ´es az ´ujonnan bevezetett tervez´esi gr´af ´altal.
Az algoritmust kieg´esz´ıtettem, hogy k´epes legyen n´eh´any, a nem teljesen realisztikus el˝ofelt´etelekb˝ol ad´od´o gyakorlati probl´ema kezel´es´ere, valamint sz´amos szimul´aci´ot fut- tattam ´es elemeztem a rendszer m˝uk¨od´es´enek ellen˝orz´es´ere. A teszteket a kutat´as r´eszek´ent fejlesztett ´es implement´alt szimul´aci´os keretrendszer seg´ıts´eg´evel v´egeztem.
Abstract
Planning optimal routes for Autonomuos Guided Vehicle transport systems is a crucial task for improving productivity and efficiency in several industrial applications. For such systems, there already exist models based on optimization approaches, which can compute an optimal solution, but become infeasible as the number of agents increases.
In my work, a different approach for such routing environments is presented, followed by the analysis and implementation of an algorithm capable to provide suboptimal solutions for route planning problems in real time.
The key concept in the investigated algorithm is avoiding problems at the time of route planning, by creating a set of routes that are conflict-, collision- and deadlock-free by design. The model, on which this work is based, was modified to support multiple type of agents - including ground and aerial vehicles - in the same environment, by the intro- duction of movement primitives and a three-dimensional planning graph. The algorithm was extended to handle practical problems emerging from unrealistic preconditions, and several experiments were carried out to validate my result. The experiments took place in the simulation system, created as a part of this research.
1 Introduction
Optimal route planning based on transport demands is an intensively investigated topic in several engineering fields. Depending on the applied model and assumptions, the computational complexity of such task moves on a wide scale. Route planning problems are commonly modeled as optimization problems, which can indeed give us an optimal solution, but scale badly as the size of the map or the number of agents increases. This means that the on-line real time operation of such methods is often non-realistic due to the need of re-planning. Based on this, the aim of our research is the investigation and improvement of algorithms, which can eventually give a suboptimal solution, but are computationally more efficient than single-step optimization approaches.
Vehicle routing problems have been extensively studied recently in the past years. There are several works dicussing routing in large networks, where the size of the vehicles is relatively small, and thus relation between them is not taken into account. These papers mainly consider dispatching the transportation requests to vehicles, and do not focus on the route computation itself [9, 10].
In this work, we investigate optimal route planning for multiple types of automated guided vehicles in a microscopic routing environment, where the size of the vehicles in the system is comparable to the size of the underlying network. For this reason, the route planning algorithm should be prepared to avoid collisions and handle congestion and even deadlock problems. This type of vehicle routing has extensive literature, starting from optimization approaches reaching optimal solution in certain cases to suboptimal systems giving real-time solutions.
The authors of [4] model the problem as a mixed integer optimization task, and present a system capable to calculate a set of truely optimal routes. Moreover, they introduce a new Lagrangian coordination and decomposition technique, resolving the problem through disrtibuted calculation and repetitive data exchange between the agents. This way, they use a simple Dijkstra algorithm for individual route planning for the agents, but introduce a more complicated cost function to take into consideration vehicle interdependencies.
In our work, we follow the concept introduced in [1, 2, 3], for resolving conflicts between vehicles at the time of route planning. First mentioned in [3], this approach uses time windows and resource reservation to ensure, that all routes planned are conflict-free by design. The idea is continued in [2], where computational complexity of such solution is examined. It turns out, that this system can resolve route planning for individual agents in polynomial time (regarding the number of time windows), and thus, it is capable of online, real time planning. Moreover, in [1], the system is compared to the results achieved by a static routing algorithm (ie. planning routes without care to vehicle relations, and resolving conflicts as they arise), and turns out to be more efficient than traditional approaches.
The idea of routing based on reservation of resorces appears also in [5], addressing the deadlocks arising in automated shuttle systems, however, they do not propose a method
for vehicles not capable to follow the route initially planned. The concept is further ela- boretad in [7], which introduces a different algorithm readjusting the already computed routes as well. A similar routing strategy is described in [6], however the article mainly focuses on the specific problems of airplane routing on airport taxiways, and thus works with different assumption and optimisation goals.
As for the optimization, we are trying to find a solution for two common optimization tasks: the Online Shortest Dynamic Disjoint Path Problem (OSDDPP), and the Online Quickest Disjoint Path Problem (OQDPP). Basically, in the OSDDPP we are trying to minimize the sum of the time of the vehicles moving along the paths, while in case of OQDPP the algoritm should find the set of dynamic routes resulting in the shortest overall makespan. In practice however, the same suboptimal algorithm turns out to be suitable for both cases.
The research is motivated by its possible applications in Automated Giuded Vehicle (AGV) routing systems. The doctoral thesis, from which my work starts, has the under- lying method implemented in HHLA Container Terminal Altenwerder c, while this work is mostly aimed for industrial application in a research-oriented experimental factory cell in Gyor.
In the first part of the paper overview of the related literature is presented, with emphasis on their suboptimal solutions to online route planning. Next, in section 3 we give a formal, rigorous problem statement, mainly based on the work of Bj¨orn Stenzel [1], followed by a detailed analysis of his solution to the problem.
In section 4, we present the simulation framework used for testing and validating our results. Design and implementation of such system, capable of simultaneously handling computation for multiple vehicle types and three dimensional visualization was an im- portant part of our research, as is planned to be used in our future works as well.
Finally, in section 5 we present our test results regarding the performance of the whole route planning system.
2 Detailed task description
To reach the aims we set in the previos section, the completion of the following tasks was needed.
1. Literature overview:
• Overview of literature related to dynamic route planning
• Overview of literature related to optimalization-based planning 2. Implementation of a simple simulation framework in MATLAB
• Modeling of factory floorplans as a graph
• Creating a simple model of the AGV’s using movement primitives
• Simulating the AGVs’ behavior
• Visualization of the simulated space and vehicles
3. Implementation and performance analysis of the algorithms chosen from literature
• Thorough examination of Stenzel’s algorithm
• Modeling time windows and resource allocations
• Implementation of the route planning algorithm
4. Extension of the simulation framework to handle multiple AGV types
• Introduction of aerial vehicles (modeling new movement primitives) 5. Extension of the model to three dimensional graphs
6. Extension of the simulation framework to support three-dimensional visualization
• Loading and presenting 3D AGV models from .stl files
• Designing factory layouts for demonstration purposes 7. Performance analysis of the algorithms in the 3D environment 8. Documentation and presentation of this work
3 Dynamic routing
3.1 Formal problem statement
To present the problem in a formal, mathematically precise form, following the author of [1], we model the routing environment with a graph G = (V, E) with nodes V = {1,2, ..., N} and edges E = {(v1, v2, l)|1 ≤ v1, v2 ≤ N, l ∈ R}. The graph is directed, and has no multiple or loop edges. The weight of the edges (representing length of this edge) is denoted byl. Agents can have different traversal times, based on their maximal speeds.
Transportation tasks are continuously arriving for the agents, and are assigned to the vehicles by a higher level dispatching system. Although modeling this system is not part of the route planning problem, in the implementation part we present two rather simple solutions for testing purposes. Formally, we define these requests as follows:
Definition 1. Arequest is a tupler = (s, t, θ), where sis the source node (from where the agent should start), t is the target node, andθ is the earliest time, when execution of the requests can begin.
During this work, without loss of generality, we assume, that this request is assigned to a vehicle already in s by the dispathcing system (formally, traversal of the vehicle to the source node of a transportation task can be viewed as a separate request). For this reason, route planning is done between nodes sand t, by using free time windows after time pointθ.
Now, when an agent in s is assigned a request, the aim of the route planning algorithm is finding a dynamic route for it, which fulfills the criteria stated (see definitions below).
Definition 2. A dynamic path in a graphG is defined as a sequence P = (θ0,(v1, θ1), ...,(vk, θk))
of v1, ...vk nodes and θ1, ..., θk timestamps, timestamp θi representing the earliest time when node vi can be entered.
It can be clearly seen, that an agent can follow such path by travelling through the edges between the respective nodes, and waiting on the edge, when they would reach the next node earlier than the timestamp belonging to it. It must be noted, that agents are allowed to wait on edges only (or practically, travel them with a lower speed than the nominal one), but they must leave nodes of the graph immediately as they arrive.
The key point behind this concept is, that collision and deadlock avoidance can be realised centrally, by giving disjoint routes to the different agents, while the task of our algorithm boils down to the computation of a set of such routes.
Definition 3. Considering a dynamic path P in a graph G, the timestamp θi is called
a reservation of node vi, and the interval (θi−1θi) is called a reservation of the edge between vi−1 and vi.
Definition 4. Two dynamic paths are considered disjoint if there are no overlapping time intervals between reservation times of the contained edges. Mathematically,
P1= (θ(1)0 ,(v(1)1 , θ1(1)), ...,(vk(1), θk)(1)) P2 = (θ0(2),(v1(2), θ(2)1 ), ...,(vl(2), θl)(2))
P1 andP2 are disjoint iff ∀i < k, j < l:vi=vj and vi+1=vj+1 ⇒[θi, θi+1]∩[θi, θi+1] =∅ Now, that the proper operation is ensured by creating disjoint routes, we continue with defining the optimization objectives.
Definition 5. The duration of a dynamic path is defined as ∆p=θk−θ0.
The first problem focuses on efficiency of utilizing the agents in the system, that is, minimizing the time they spend (or, the route, they travel) during the completition of a given set of requests. While for a set of requests known prior to the route planning this can be modeled and solved as a mixed integer problem, for requests arriving continuously, it can not be guaranteed, that any algorithm can produce an optimal set of dynamic routes.
Definition 6. TheOnline Shortest Dynamic Disjoint Path Problemis defined as follows:
Being given a sequence of requests (si, ti, θi), i= 1, . . . , kfind a sequence of disjoint paths P1, ..., Pn, for which X
∆pi is minimal.
The second one focuses mainly on the time efficiency of the routing system, having the aim to complete as soon as possible all known requests.
Definition 7. The Online Quickest Disjoint Path Problem is defined as follows:
Being given a sequence of requests (si, ti, θi), i = 1..k find a sequence of disjoint paths P1, ..., Pn with minimal maximum completition time over all paths (so that max
i=1...nθi is minimal)
Again, this optimisation goal cannot be achieved for continuously arriving requests, but the algorithms discussed are able to find a solution close to optimal.
3.2 Stenzel’s routing algorithm
The algorithm itself is kind of a greedy approach. While the task - both in case of OQDPP and OSDDPP - is minimizing the overall cost of the system, the algorithm focuses on minimizing route completition time for the individual agents. As a result, the algorithm boils down to having a number of agents, looking separately for routes optimal for them.
It can be easily seen, that this selfish behavior could potentially lead to countless prob- lems, like deadlocks forming, or agents trying to use the same route at the same time,
resulting in time-consuming waiting. To overcome this issue, the algorithm introduces the concept of time windows, aka reservation of nodes and edges of the graph for given time periods. From this point on, every agent planning a route is obliged to respect former reservations, and calculate their route in a manner that it does not disturb the already calculated routes of fellow agents.
This route planning happens iteratively, in a predefined order. This order can consider priority differences between the requests, might be based on how much time is given for the completition of the requests mapped to the agents, or can be chosen simply the order in which the requests arrived. Whichever strategy is chosen is the responsibility of the higher level management system, the route planning ensuring just collision avoidance and optimal solution for the individual agents.
These individual optimization goals can be formulated as follows:
Definition 8. The Quickest Path Problem with Time Windows is defined as follows:
Being given a graphG= (V, E), a set of time windows for the edges, a requestr= (s, t, θ) and an agent ins, compute a dynamic path with minimal completition timepthat uses the edges of the graph in the free time windows.
As formulated by Stenzel, the iterative algorithm works as follows:
Algorithm 1: Iterative routing scheme
Data: GraphG= (V, E), set of requests R= (si, ti, θi) dispatched to agents Result: Set of dynamic pathsPi serving the requests
1 begin
2 foreachrequest ri ∈R do
/* Compute a dynamic path resolving the Quickest Path with Time
Windows problem */
3 Execute Algorithm 2
4 Pi = Algorithm2(G, ri,F, τ);
/* Modify time windows to include the new reservations */
5 Execute Algorithm 3 for the given dynamic path
6 F = Algorithm3(G, P,F);
7 end
8 end
While not giving an optimal solution, this concept has several advantages. First of all, it is computationally feasible, even for large graphs and numerous agents - for details, see derivation of complexity theorems presented in [1]. Moreover, this ensures continuous online computation - transportation requests for agents can arrive continuously, in a realistic manner - each agent getting a new task when the previous one is finished.
Apart from the time window concept, the algorithm is basically a modified Dijkstra route planning for the individual participants.
3.3 Resource allocation using time windows
To formally describe the algorithm, we define the concept of resources, time windows and labels.
Definition 9. A resource is part of the graph, which can be used simultaneously by only a single agent. This can be a node, an edge, or even a set of both.
Since the graph is directed, a resource typically consists of two edges (back and forth) between the same two nodes. By the introduction of the planner graph in section 3.5 to consider the time required by vehicles to turn in the respective graph nodes, this concept becomes even more complex (for instance, the vitrual edges representing rotation in the same physical node are being treated as a single resource) (detailed description on this follows in 3.5)
Definition 10. A time window on a given resource is defined as a pair of time values (a, b), between which the resource can be freely used by an agent.
It can be easily seen, that a set of time windows completely describes the availability of a resource, while finding whether the resource is free for a particular time interval has logarithmic complexity regarding the number of windows on it. More precisely, we define the reservations of a resource as follows:
Definition 11. The reservation of a resource is given by a set of consecutive time windows:
F ={(ai, bi)|i∈N},where ∀i < j :bi < aj
Note. The bi element of the last time window in the set is always equal to +∞, except the case when an edge is permanently reserved due to operation failure, eg. vehicle breakdown completely blocking the edge.
Now, following this concept, making a new reservation on an edge can be defined:
Definition 12. Making a reservation on a resource for an interval (a, b) means finding a time window (ai, bi)∈ F, for whichai≤aand b≤bi, and modifying it by substracting (a, b):
(ai, bi)−→(ai, a)∪(b, bi)
As the F can contain time intervals only, the new interval is added to the end:
F ={(a1, b1), ...,(ai, a),(ai+1, bi+1), ...,(aN, bN),(b, bi)}
To keep finding an interval computationally easily, in the implementation the elements of the set are rearranged in ascending order regardingai.
As we already stated, the base algorithm itself resembles Dijkstra’s algorithm, which operates by assigning distace values to the edges (the distance from the source node,
known at a certain stage of the algorithm), and updating these values based on the values stored in the neighbour nodes. Now, to implement this behavior, but taking in consideration the arrival time rather than distance, we introduce the concept of labels.
Definition 13. Alabel is defined as a tupleL= (s, t, a, b, p), and means, that the agent for which route planning is done, can reach the tail of edge between nodes s andt in the time interval (a, b). The p value is the identifier of the edge, from where the agent arrives.
First of all, we should note, that the reason why thethead of the edge is part of the label is, that due to the construction of the algorithm, these labels are assigned to edges instead of nodes. Secondly, the presence of bas the last possible time of arrival is necessary, as the agent might be obliged to leave the previous edge from where it would arrive due to a reservation made formerly by another agent to an interval after b.
Another important modification to the Dijkstra algorithm is, that an edge might be assigned not only a single label, but multiple labels as well. This construction is necessary, as contrary to the simple static route planning, when always the route with lowest distance is certainly the best, and discarding the higher values can be done without problem, here we can not define an obvious order between the labels to choose which one to keep. For instance, due to reservations on the edges, it can happen, that a label with highest arrival value will result in a quicker route after reaching the target.
Finally, we define a relation between labels, so that we can discard those, that certainly result in worse routes than an another label already present.
Definition 14. LabelL1 = (s1, t1, a1, b1) dominates a labelL2 = (s2, t2, a2, b2), if it is a subset of it: a1≤a2 and b2≤ b1.
Below, in the discussion of the route calculation, we explain in details how and why this domination can be used to get rid of unnecessary cases.
3.4 Route computation
In this part, we describe the operation of the route-planning algorithm.
The algorithm consists of four important parts: initialization, the main loop iterating over edges and labels, the label actualization step (which is part of the loop), and finally, the computation of a dynamic route from the labels and reserving the resources used in it.
Similarly to Dijkstra, or almost any other path-search algorithm, we use a priority queue to keep track of elements (nodes, or labels in this case), that need to be processed. In the initialization step, we push labels related to the source node in the queue, so that the algorithm can begin. Second, in the main loop, in every iteration, we select and pop one of the elements from this queue, and expand it, which means we update the stored values in the nodes or edges connected to it. The algorithm terminates, when the queue
becomes empty, or when we can decide from the currently expanded element, that the optimal solution is reached - when expanding this element involves label updates based on the label having the target node as its head. Finally, based on the values assigned to the edges of the graph, we calculate a dynamic route and make the reservations needed.
The algorithm can be described by the following pseudo-code, explained below in details.
For the next parts, lets assume we want to plan an optimal route for an agent from node s to nodet, respecting the already present resource reservations.
Initialization
First, we initialize the priority queueHas an empty queue of labels, the ordering relation being the comparison between theavalues of the elements. Similarly, we assign an empty list of labels to all edges, noted by L(e).
Then, we look for edges e having the source node as their tail, and insert label L = (e.tail, e.head, θ,∞, nil) intoH and intoL(e) (θ is the earliest time the agent can start execution of the request, while nilrepresents, that these edges have no predecessor, from where the agent arrived).
Main loop
Now, in every iteration of the main loop, the label L with minimal arrival time a is popped from the queue. The algorithm checks, whether the target is reached (that is, L.s=t), and moves to the computation of the dynamic route if it is (lines 13-15).
If not, similarly to the Dijkstra algorithm, actualization of the consequtive edges takes place. With the loop in lines 16-38, for each empty time window on edge e= (L.s, L.t), traversal possibilities are checked.
If the last possible arrival time to the tail of the edge (L.b) is earlier than the beginning of the time window (a), the agent can not pass the edge using this time window. As time windows are ordered in F(e), no further iteration is required, the algorithm continues by chosing the next label from H. (lines 17-19).
If the first possible arrival time is later than the end of the time window, the agent can not travel the edge using this window. The algorithm is continued with the next time window from F(e). (line 20-22).
If neither of the above conditions broke the execution of this loop, the agent might be able to travel the edge. Based on the current time window and the traversal speed of the agent, first and last possible arrival times to the end are calculated. The first time the agent can begin traversal of the edge is tin = max{a, L.a}: if beginning of the time windowL.ais later than the first possible arrival timea, the agent waits on the previous edge, and enters atL.a only. Consequently, the first possible arrival time to the head of the edge (or, the tail of the next one) istout=tin+τ(e). If the agent can travel the edge until the end of the time window (meaning thattout< b), labels on all edgesf going out
Algorithm 2: Dynamic Route Calculation
Data: Directed graph G= (V, E), source nodes, target node t, release timeθ,
functionτ(e) which gives the time required by the respective AGV to travel the edgee, and a set of time windows F(e) for the edges
Result: A dynamic route P withθk≥θ and solving the Quickest Path Problem with Time Windows
1 begin
2 H=∅;
3 foreache∈E do
4 L(e) =∅
5 end
6 foreache:e.tail=sdo
7 L= (e.tail, e.head, θ,∞, nil);
8 H.insert(L);
9 L(e).insert(L);
10 end
11 whileH 6=∅ do
12 L=H.pop();
13 if L.s=tthen
14 break;
15 end
16 foreachF = [a, b]∈ F(e) do
17 if L.b < a then
18 break;
19 end
20 if b < L.a then
21 continue
22 end
23 tin= max{a, L.a} ; // If L.a < a, the agent must wait until a
24 tout=tin+τ(e) ; // First possible arrival to the end of the edge
25 if tout ¡ L.b then
26 foreachf :f.tail=L.t do
27 L0 = (f.tail, f.head, tout, b, L) ; // This would be the new label
28 foreach Lˆ∈ L(f) do
29 if L0 dominates Lˆ then
30 H.erase( ˆL);
31 L(f).erase( ˆL);
32 else if Lˆ dominates L0 then
33 continue
34 end
35 H.insert(L0);
36 L(f).insert(L0);
37 end
38 end
39 end
40 end
41 Calculate dynamic route based on labels (Algorithm 4).
42 end
from node L.tare actualized based on domination rules (line 25-37).
Label actualization
Actualization of the labels happens by creating the new label based on first and last possible arrival times (L0 = (f.tail, f.head, tout, b, L)), then it is checked whether it is dominated by other labels or contrary, it dominates some others. It can be clearly seen, that if a label is dominated by any other label, we should not take it into consideration any more, as using the label dominant label completely covers the possibilities introduced by the another one.
For this reason, all labels of all successor edges are checked (nested foreach loop pair in lines 26-36. If the new label is dominated by any of the already present ones, it is not inserted in the queue, and no further checks are done: the algorithm continues by examining the next successor edge. Otherwise, the new label is inserted in H and in L(f) as well. During this process, one more check is done: if the new label dominates any of the already present ones, that label is removed from H, and fromL(f) is well, as the new label will completely take its role.
Route calculation
When the algorithm pops a label from H with its tail being equal to the goal node, the algorithm stops. Now, by stepping backwards based on the label, a dynamic route is generated.
Algorithm 4: Calculate dynamic route from labels
Data: Directed graph G= (V, E), starting label L= (s, t, a, b, p), L.s=t Result: Dynamic path P
1 begin
2 k = 1;
/* Compute dynamic route backwards */
3 whileL6=nil do
4 vk=L.t;
5 θk =L.a;
6 L=L.p;k=k+ 1;
7 end
8 reverse(P);
9 θ0 =θ1−τ(s, v1);
10 end
Modifying time windows according to new reservations
Modification of the time windows to include new reservation is quite straightforward, if a properly constructed dynamic path is given. Assuming that a wait operation during a
path is required, agents are instructed to wait at the latest time possible, the time slots for which an agent occupies the edge (vi, vi+1) is exactly [θi, θi+1].
A more interesting question is, however, which set of time windows to modify to avoid collisions indeed. While reservation of the resource belonging to the edge (vi, vi+1) comes naturally, some neghbouring edges might also be affected. To prevent any issue coming from this (like agents arriving from a different direction to a node withεtime difference colliding), we define the concept of conflicting edges. Now, these edges should not be checked to be free in the step of dynamic route calculation, they should be reserved when adjusting the time windows according to the dynamic path though. In our model, when reserving an edge, the set of conflicting edges we reserve are all those connected to vi or vi+1.
Based on this, the implementation of the algorithm can be described by the following pseudo-code:
Algorithm 3: Modifying time windows according to new reservations
Data: Directed graph G= (V, E), dynamic path P = (θ0,(v1, θ1), ...,(vl, θl))}, a set of time windowsF(e) for the edges, set of conflicting edgesconf l(e)∀e∈P Result: A new set of time windows F(e) including the reservations for P
1 begin
2 foreache= (vk, vk+ 1)∈P do
3 foreachf ∈conf l(e) do
4 foreachFi= [ai, bi]∈ F(f) do
5 if θk+1<≤ai then
6 continue
7 end
8 if ai ≤θk and θk+1 ≤θk+1 then
9 for m=end(F(f));m >=i+ 1;m=m−1 do
10 Fm=Fm−1;
11 end
12 Fi= [ai, θk];
13 Fi+1 = [θk+1, bi];
14 end
15 end
16 end
17 end
18 end
In this code, the algorithm iterates through all edges in the dynamic path (loop between lines 2-17), and makes a reservation for all conflicting edges (foreach loop in lines 3-16).
The reservation is made by finding the time window in which the agent travels the edge (line 8) and splitting the respective time window in two parts. To keep the set F(f) ordered, elements of the set are shifted (lines 9-11), and the new window is inserted right after the one being splitted (lines 12-13).
3.5 Modeling AGV movements and the routing environment
As the last part of the dynamic routing algorithm, a model of AGV movements, and the corresponding representation of the environment is presented.
First of all, the factory floorplan is handled as a simple directed graph, with edges representing the paths an agent can follow, and nodes being the intersections between such paths. In the further discussions, this graph is called the factory graph.
However, as real life agents are not capable of arbitrary movements (for instance, can not change their direction in zero time), we use some predifened movement primitives to decribe their behavior. These primitives are GO STRAIGHT, TURN and WAIT, and we assume, that all agents in the system can execute any of them.
Basically, the GO STRAIGHT stands for straight, horizontal movement, in the main trav- elling direction of an agent. The primitive has one parameter, the distance the agent is supposed to travel. To be able to handle aerial vehicles as simple AGVs, an optional second parameter, the vertical movement can be added. This value means, that the AGV (provided it is an aerial vehicle capable to do so) will ascend/descend this distance during the forward movement.
The other movement primitive TURN is rotation in place, i.e changing the forward di- rection with position of the mass point remaining unchanged. This primitive requires a single parameter, an angle (positive or negative value representing left and right turn respectively), that describes how much the agent should turn. We assume, that the agent can not change its height during aTURN operation.
The third movement primitive represents waiting in-place, without changing position or orientation.
Now, while thefactory graph would be enough to compute routes including GO STRAIGHT and WAIT operations, time required for the turning must be somehow included in the weight of the paths. To be able to use the algorithm without modification, a virtual graph calledplanner graph was introduced. For every physical node in the factory graph, we generate a virtual node for every possible direction in which the agent can arrive to or depart from the node. Edges representing rotation are added between neighbouring directions (see fig. 1), edges representing transition are preserved between the virtual nodes having the same direction value.
Figure 1, illustrates the construction of the planner graph as follows. Node 1 has one incoming and zero outgoing edges, thus there is only one direction, in which an agent can get to there: the 45 degree angle, in which it arrives. For this reson, a single virtual node is generated with direction value 45. Node 2 has two outgoing and one incoming edges, meaning that there are three directions which need to be considered: the 45 degree, in which te agent can leave the node for Node 1, the 90 degree in which it arrives from Node 3, and the 270 degree in which it can leave for Node 3. Now, as shown in the figure, three virtual nodes are generated, connected by three virtual edges representing rotation in physical Node 2. Similarly, Node 3 has one incoming and one outgoing edge,
Figure 1: Contruction of a simple 2D planner graph
resulting in two virtual nodes with directions 270 and 90 respectively. Finally, physical edges appear as a virtual edge between the nodes with the same direction value (edge from Node 2 to Node 1 between the virtual nodes with direction 45, and so on).
From this point, running the route planning algorithm on the planning graph would result in dynamic routes, which can be translated directly to a list of movement primitives.
3.6 Resolving practical problems
As our system is aimed to be suitable in a real environment, practical considerations must be made. Due to the nature of such environments, there are several factors that can influence the routes planned, and cause already planned routes to become impossible to complete. In this section, we investigate disturbances caused by late arrival of the vehicles, when an agent cannot leave an edge and free the respective resource until its time window expires.
3.6.1 Minor disturbances
First, minor disturbances, arising randomly during normal vehicle operations are exam- ined. These disturbancies include latencies introduced by the vehicle control system, or by some external events like a human worker or another temporary obstacle in the agent’s way. Such external event can force the agent to slow down, and thus be unable to reach the end of the edge being traversed until it is planned to.
Handling of these cases was treated using a heuristic approach, by adding asafety interval to all reservations. This way, the system operates by working with transition times higher than nominal: looking for a longer time interval than neccessary when expanding a label and when reserving time windows. Due to the modification, time windows on consecutive edges are not exactly one after another, but there is an overlapping time interval between them.
It must be noted, that instead of using a safety interval relative to the length of the edge (as it would be, if assuming a lower than nominal speed), we chose to have this interval fixed for any type of agent. This way, safety times are not summed, but the solution permits a predefined delay time during the whole route. The concept is illustrated in figure 2.
Figure 2: Reservation of resources with safety interval
Each bar represents a resource, with green intervals marking the free time windows, the red ones the reserved time intervals. The red intervals are are extended with a safety interval at
time points 3 and 4.
Reservation of resources and modification of time windows is discussed in details in section 4.2.3.
3.6.2 Severe latencies
While the safety intervals discussed above are able to handle minor time differences, vehicles might arrive to a location with a severe latency due to malfunction or other circumstances blocking normal operation. In our algorithm, such delays are handled by stopping all vehicles at end of the edge being traversed and erasing all reservations, followed by recomputation of all routes from that starting point.
Simple as may sound, this approach faces several challenges. Vehicles stopped in the mid- dle of the graph are formally removed from the system, as the route planning algorithm can not deal with agents waiting on edges without the edge being reserved for them. The solution might be reservation of all the edges where agents resides, the required length of such reservation cannot be computed though.
In my solution, a simple heuristics was applied: for all agents stopped at time T0, a reservation for the interval (T0, T0 + ∆T) was made, and the route planning system assumed, that agents can leave their position in that interval. If due to reservations created beforehand, an agent is unable to leave its location, the problem is handled as another severe latency, causing a repeated recalculation of all routes in the system. Here, the ∆T value is a predefined constant, obtained as the result of simulations in different routing environments.
4 Implementation
In this part we present the implementation of the previously described algorithms, cre- ated for testing and validating their performance. The simulation was realised entirely in MATLAB, and is formed by two main components. First, a general framework was created for simulating AGV movement in a three dimensional coordinate system, where all AGVs act based on predefined task-list, given by the user. This framework provides a simple model for dealing with multiple types of AGV vehicles through the class called AGV, and features a simulation loop, which iteratively computes and shows the AGV movements in our system (the Simulationclass). As there is a possibility to throw and handle events during the simulation (like an AGV reaching its destination and waiting for new tasks to be added), it is completely fesible to simulate route planning algoritms in general.
Next, we moved on to the impementation of Stenzel’s algorithm. A MATLAB model of the graphs (classFGraphfor the factory, classPGraphfor the pllanner) and time windows (Resources class) was introduced, followed by the implementation of the time-window based route planning (Algorithm 2) and route reservation (algorithm 3)algorithms. As all route-planning algorithms investigated assume a high-level dispatching system giving route sources and destinations to the agents, in the test scripts we also created a simple dispatching model (demo gyor.m). We already mentioned, that the algorithm cannot deal with idle AGVs waiting for a new order (for them, without reservations, these agents are formally removed from the network), so introduction of so-called parking places was necessary for the simulations. This way, not sending multiple agents to the same parking place (or workstation) becomes the responsibility of the dispatching system.
Finally, we present the emerging implementation challenges, caused by transition to three dimensional modeling.
4.1 The MATLAB framework
4.1.1 AGV modeling
In this framework, all moving AGV agents are modeled as mass points, moving in a coordinate system, and are displayed as 3D CAD models loaded from .stl files. They all belong to the same AGV.m base class, having the following important properties and functions:
• positionandrotation: a three-element double vector, position of the mass point in the coordinate system and a three by three rotation matrix, describing rotation of the initial 3D model.
• modelVertices: n by three matrix, containing the initial position of the vertices of the loaded 3D CAD model. This is centered to the origin of the coordinate system and normalized (all AGV having size 1 along their longest dimension).
Multiplied elementwise with the rotation matrix, and added to the position vector, this results in a 3D AGV model in the coordinate system with the right position and orientation.
• velocityand angularVelocity: velocity of the agents during straight movement and rotation. As all AGVs modelled are capable of waiting in place, this is assumed to be constant without loss of generality.
• tasklist: LIFO list of movement primitives, with reqiured parameters (discussed above).
• update(dt): calculates the next state of the agent after a dt timestep, based on the properties described above
Now, by modifying the tasklists using the addTaskshelper function, users of the frame- work can assign tasks to the AGVs, identical to the movement primitives assumed above.
This way, any route to be followed can be easily described as a list of these tasks, and simulated by the system.
The most significant part of this modeling being the update function, we discuss that more in details. This function is called periodically by the main simulation loop, and does the following: first, it checks whether the current task (that on the top of the task list) is finished. If not, execution of that is continued, else it pops the next task from the list and begins the execution. As for the execution, the algorithm calculates the next position based on the respective movement primitive, modifies the parameters of the task (to keep track of how much of it is done), and recalculates the position of the model vertices displayed.
4.1.2 Main simulation loop
The simulation is run by the class namedSimulation. This has a list of AGVscontaining the handles of all agents in the system, and a time variable, which contains the time elapsed since the beginning of the simulation. New agents can be added using the function addAGV. The simulaiton can be started by calling the simulation function, which contains the main simulation loop.
The simulation loop is an infinite loop, which first determines the next timestep, and calls the update function of all agents whith that value afterwards. The timestep is obtained by iterating thorugh all agents, and checking how much time their need in order to complete their current task (on the top of their command list). The algorithm chooses the minimum from the set of these values and the default timestep value of 0.04 seconds. This approach ensures, that all AGVs will complete their tasks exactly at the end of a simulation cycle, while also preserving a minimum of 25 updates per second.
All AGVs have the possibility not to return anything, or to throw an event, as the return value of their update function. If such an event is returned, the main simulation loop terminates (all state variables being preserved), and returns control to the caller script.
This way, when for instance an agent finishes all of its tasks, it can request new task from the dispatching system. The simulation can be resumed by calling the simulate function again.
For documentation and visualization purposes, this funciton also handles how graphics is displayed. It takes into consideration the time required for computation, as well as for the draw operations, when choosing the amount of idle time required to provide a constant frame rate for the viewer. The class can also be used for video construction, by simply passing a recorder object to it in the constructor. This way, all frames are put after another in .avi format.
4.2 Routing algortithm
4.2.1 Factory graph
The first step to implement the routing algorithm was finding the right representation for the environment, in which the routing takes place. As it does not has an effect on the efficiency of the algorithm, we chose to model our factory floorplan as a simple directed graph, and store the position of the nodes in an adjacency matric.
In the implemented code, this appears as theFGraphobject. The class has two attributes:
the vertices and theadjmat adjacency matrix. Thevertices is anN ×3 matrix, in which each row contains the (x, y, z) coordinates of a node - thus, the nodes are identified by their index in the row (1,2, ..., N). The adjacency matrix is a N ×N boolean, and aij has value true if there is an edge between the i-th and j-th node. As the graph is assumed to be directed, this matrix is not necessarily symmetric. It was considered to store the weight of the edges in the adjacency matrix as well, however, due to the construction of the planner graph (see below) it is not required.
The matlab class has four methods to support construction of arbitrary graphs, called add vertices, delete vertices,add edges, delete edges, all being able to perform the insert and delete operation without breaking the structure already set. Theadd vertices anddelete vertices change the number of nodes, and thus shifts the identifier of some nodes, though.
4.2.2 Planner graph
The planner graph is represented by the class PGraph, and it is constructed according to the description above (see 3.5). The class has two attributes: the vertices vector and the adjmatadjacency matrix. The verticeshas size N0×3 matrix (N0 being the number of virtual nodes), in which each row contains the number of the corresponding phisical node in the planner graph, and an angle value φ ∈ (−pi, pi] containing the direction which the virtual node stands for.
The adjacency matrix is aN0×N0 (positive) double matrix, andaij contains the weight of the edge between virtual nodes i and j. If these nodes belong to the same physical
node, this weight is the amount of degrees (in radian) the agent has to turn from one to the another; otherwise, the weight is the length of the physical edge.
While using this representation, turning behavior and the time required for an AGV to turn into the required direction is covered for arbitary graphs without additional computations, it introduces difficulties in resource allocation. It must be noted, that these virtual edges, as well as the virtual nodes represent the same physical resource, and must be treated accordingly when reserving a node or an edge for the algorithm.
4.2.3 Resource allocation
As already described above, the route planning algoritm avoids collisions and deadlocks using the concept of resource allocation using time windows, which means, that all physical resources (like a node or an edge) can be reserved by an agent for a given interval of time. Moreover, these phisical resources need to be mapped to the elements of the planner graph, so an algorithm working on that can access reservation data for a virtual edge or node.
To keep the implementation simple, a Resources class was created to store this data.
The class has a property called timeWindows, which is a cell array containing the free time intervals for all resources, and a property resource ids(Nplanner×Nplanner, where Nplanneris the number of nodes in the planner graph), in whichresource idsi,jcontains the index of the resource belonging to the edge from thei-th node to thej-th node (when i6= j) or to the node i (when i=j). If there is no such resource (there exists no edge between iand j, value 0 is stored).
Generation of the resources happens in the following way: first, we assign values from 1 to Nplanner to the main diagonal of the resource idsmatrix. Next, we iterate through all edges in the graph, and calculate how many resources are needed (for instance, bidi- rectional edges, and edges representing rotations share a common one), and insert the values into the matrix.
Finally, we create the timeWindows cell array with R elements (R is the number of resources needed), and initiatetimeW indows ias a 1×2 matrix having values 0 and∞ (which means, that all resources are completely free).
Reservation of resources happens in the following way: when the route planning algo- rithm has to reserve a node or edge, it first looks up the resource id in theresource ids matrix. Next, it iterates through the rows of the matrix stored in the celltimeW indowsid, and checks whether the interval for which the reservation is needed is the subset of one of the stored interval. Finally, if it is, reservation happens by cutting the interval into two parts. The second interval is inserted right after the first one, shifting the rows of the matrix.
TheResourcesclass is also able to create a human readable plot of resource reservation, so working of the algorithm can be visualized in real time. As we can see in figure 3, the resources are represented by horizontal bars, green segments marking the free time
windows (the intervals stored in the matrix), and red segments marking the reservations.
It can be clearly seen, that red marks align obliqely, as an agent moves along a path, and reserves consecutive resources for consecutive time intervals.
0 10 20 30 40 50 60 70 80
0 2 4 6 8 10 12 14 16 18 20
Resource IDs
Time(seconds)
Figure 3: Reservation of resources
4.2.4 Route computation
Following the route planning method described above, the algorithms for route planning and for reservation of the route found are implemented as functions algo2 and algo3 respectively (the naming follows the original names given by Stenzel, the algorithms being almots identical to that described in his paper).
In the initialization part, all edges in the (planner) graph are listed, and a priority queue is created for them, capable of storing labels. For practical reasons, in fact the algorithm creates an array of structures, which contain head and tail info of an edge, as well as the priority queue belonging to it. In the same iteration, if the edges have the starting node as head, a label is added to them, stating that the agent can begin travelling on them at any time beginning with the relase time θ.
4.2.5 Parking places
As the route planning algorithms see the agents only through the reservations made by them, it was necessary to remove the AGVs from the graph when not executing a task.
To resolve this, parking places were introduced, as nodes aligned at the side of the graph.
We assumed, that those parking places are big enough to provide space for any number of agents, or that the dispatching system takes care of not sending too many of them to a particular place.
Now, with this assumption, the only requierment from the dispatching system is, that
only routes from one parking place to the another should be planned. This way, during normal operation (without delay or for instance vehicle breakdown) no agent can remain in the graph without the respective resource it uses being reserved for it.
Regarding the implementation, the introduction of these places does not influence at all the another part of the route planning system.
4.2.6 Dispatching
Although design and implementation of a complex dispatching system was well beyond the scope of this project, creation of a rather simple one for testing purposes was in- evitable. For this reason, at first a zero-logic system was created, which for any AGV finishing its task assigned a random target node from the graph.
However, as described above, proper testing of the algorithm required a system capable of handling the parking places. This system was implemented as well, by keeping a list of parking places, and choosing one randomly based on their status. We decided to use two possible states for the parking place: free or occupied. At first, all places from where agents start are set to occupied, the others are set to free. Next, when route planning for agents begin, a parking place is set to occupied as soon as an agent gets a route planned to there. The place, from where the agent starts is set free at the same time, even though the agent might not be able to leave at that moment. The system assigns only free places as destination (choosing randomly), behavior which ensures, that two agents cannot be routed to the same place, colliding there (outside of the graph).
It has to be noted, that the concept presented is far from being efficient, this is not among its purposes though. In real application, where agents have a specific goal, waiting at the other side of the graph just because an another agent is heading to the same destination, is unacceptable waste of time. For testing the route planning, choosing another random target in such situation is perfectly enough.
4.2.7 Extension to 3D models
Due to practical demands, the next step in our project consisted of extending our model and implementation to support multiple types of vehicles, including quadrotors capable of aerial transport. The modification includes several challenges, starting from three dimensional planner graph generation to providing different weights, and even completely different graphs for the individual AGVs in the system. Moreover, the differences between these graphs (inevitable because not all vehicles are designed to travel along air edges) impose the re-implementation of the resource allocation system. Finally, the presence of AGV’s with different behavior cannot be simulated without slight modifications to the main simulation class, and the graphical interface either.
Three dimensional planner graph
As discussed above, the planner graph - generated based on the factory floorplan - is a virtual graph, where a node represents the actual position of an intersection and the direction of the vehicle as well. Consequently, rotation time of the vehicles can be taken into account as the weight of the virtual edges, connecting these nodes.
During the creation of our three dimensional model, at first usage of solid angles and an even more complex virtual node generation formula was considered. Later, to keep it simple as possible, we came up with a more natural extension, assuming more simple movement primitives for the aerial vehicles (discussed below in details).
In the process of planner graph generation, we project our three dimensional graph to a plane, resulting in a regular floorplan. In the next step, we generate out planner as discussed above, finally, we assign the same altitude value to the virtual nodes, as the corresponding physical node had. Now, the only problem remaining are the completely vertical edges: as the projection of the two nodes fall to the same two-dimensional point, it is unclear to which virtual node (which direction value) should these edges connect.
This case was handled in the following way: every node connected to such an edge was assigned a virtual node with direction value 0, and these nodes were connected by the preserved edge. Naturally, if the two physical nodes had another common directions (which is mostly the case in the graphs used), those were connected as well.
The approach discussed completely fits out applied aerial AGV model, which - compared to the regular AGV - features one more movement primitive: during a straight transition, it can increase/decrease its altitude value as needed. While real-world quadrotors are capable of rotation during a rise/sink operation as well, this behavior was omitted from our system.
Different graphs for vehicles
Introduction of quadrotors in our system was a major modification, as handling of dif- ferent types of vehicles (with edge travelling capabilities moving on a wide scale) became necessary. To address the issue, the AGV model and the route planning algorithm was modified as follows.
First, the AGV model was changed to include the planner graph, on which the respective AGV can travel. This planner graph can be a clone of the original planner generated from the floorplan (which is the case when an AGV can travel along all edges), or a subgraph of it (edges/nodes unreachable for the AGV are omitted, and weights of the preserved edges can be changed based on the vehicle’s properties). Addition of new nodes or graphs is prohibited to ensure consistent resource allocation. As the resources are common for all AGVs, these are generated based on the original planner graph.
The route-planning algorithms underwent a single modification: when expanding an edge label, neighbouring edges and traversal times are queried using the planner model of the
AGV, for which the route planning happens. Nevertheless, resource allocation is done based on the original planner graph.
Simulation class and graphics
While changes to the simulation and graphical system are more of an implementation issue than a research task, these modifications were inevitable to effectively test and validate the algorithm itself in the new situation.
To visualize the AGVs in a three dimensional environment, MATLAB’s built-in graph- ical tools were used. The vehicle shown is a patch object, loaded from an .stl file, containing a well-designed representation of the physical AGV’s and quadrotors used by the MTA-SZTAKI. Moreover, the graph and the factory outlook was also adopted from the institute, so the vehicles are simulated under real conditions.
The simulation cycle was redesigned in an object-oriented approach, using the features offered by MATLAB. This means, that every AGV object (belonging to the AGV base class) can have its very own 3D model, speed, and behavior, while new types can be added without touching the already present ones.
Figure 4: Demonstration of the 3D graphics environment
5 Test cases and simulation results
To extensively test the implemented framework system, and verify the usability of the implemented algorithm in the scenarios needed, an exact model of the factory cell from Gyor was realised in the simulation system. This process involved loading and trans- forming the data acquired from measurements of the place, so that a three dimensional representation of walls and objects would appear. Next, a directed graph based on the loaded floorplan was created, followed by the generation of nodes and edges in the air, suitable for quadrocopters only. Finally, after generating a planner graph and defin- ing some parking places / workstations (nodes, from which and to which transportation requests are arriving), two ground AGVs and two quadcopters were loaded and launched.
The experiment was carried out using MATLAB 2018b, on a Dell Vostro 5471, having processor model Intel Core i7-8550U (4 cores, 8 threads, up to 4GHz) and 8 GB RAM.
5.1 Test case: the factory cell in Gy˝or
Loading the factory floorplan
As a result of measurements and some preporcessing of data, the following layout was obtained in .csv format (figure 5). The file contained a true or afalse value for each coordinate pair (x, y) ∈[−66; +80]×[−74; +55], indicating whether an AGV can go to that place or not.
Figure 5: Floorplan of the factory cell located in Gyor
The file was loaded in MATLAB, and the following representation (a surface in a three dimensional space), including walls and blocking objects (figure 6) was created.
In the next step, we constructed the factory graph containing 18 nodes on the ground, and another 11 ones in the air. By connecting the adjacent noded, a graph with a total number of 50 edges was obtained. There were five workstations added, to physical nodes
(a) Layout from above (b) Layout in perspective
Figure 6: Layout generated by matlab based on the floorplan
1, 9, 16, 18, 20 (marked by the green squares on the floor). The graph with node numbers can be seen on figure 7.
Figure 7: FGraph object of the factory cell
Finally, the planner graph (PGraph object) and the resources (Resources object) were generated. The planner graph resulting from the above factory graph had 158 vertices and 506 edges, while the resources object contains 79 resources (set of time windows).
Loading AGVs and generating requests
The AGVs were loaded to the following positions: two groud AGVs to nodes 9 and 18, and two quadrotors to nodes 1 and 16. In this order, the agents had the targets 18, 16, 9, 20. The route planning took place in order 16, 18, 9, 1 (the numbers being the nodes the agents started from). The routes calculated and followed by the agents can be seen in figure 8. It can be easyly observed, that the agent starting from 18 chose route {18,13,17,14,16} instead of the spatially shorter one {18,13,12,14,16} to aviod
interference with the route starting from 16 planned before. As for the performance of the algorithm, all route planning operations took place in time less than 0.1 seconds, which could be further reduced by further fine-tuning of the implementation.
Figure 8: Routes planned using the algorithm
5.2 Test case: extended factory cell
The algorithm was tested on an extended factory cell, derived from the original one in Gy˝or. In this case, there were 116 physical nodes and 211 physical edges, resulting in a planner graph with 672 nodes and 1307 edges. The resources class contained 327 set of time windows. The simulation was run using 4 ground AGVs and 6 quadrotors, moving between 12 workstations / parking places.
The environment and the agents are shown in figure 9.
Movement of the AGVs can be seen in a demonstration video, available at [12]. The algorithm had a decent performance, computation times remaining under 1 second under any circumstances.
Figure 9: Extended factory cell with 10 agents
Summary
In this work, I have presented the operating principle and implementation of an algo- rithm, capable of providing online disjoint autonomous vehicle route planning for multiple type of AGVs moving in a microscopic routing environment.
First of all, the PhD thesis of Stenzel [1] was read and carefully examined regarding the operation and implementation of the algorithms, including investigation of how realistic the requirements are.
Next, as my contribution to the topic, modeling of the agent behaviors took place:
• Movement primitives: By introducing the movement primitives, that each type of AGV is able to execute, we could create a routing system capable of handling together all agents, and providing route planning for ground and aerial vehicles at the same time.
• Planner graph: A comprehensive environment model was also created by the definition of three dimensional planner graphs, which allowed the algorithm to take into consideration time required for all movement primitives, including turning behavior.
• Handling common practical problems: Moreover, practical problems arising from disturbances in the routing system were examined, and a method for handling minor latencies as well as severe shifts in schedule was proposed and tested.
Second, the initial MATLAB framework provided at the beginning of this work was extended, to include all the features required. Handling of resource allocation, illus- tration of time windows, and new AGV movement primitives were implemented. The framework was extended with completely new 3D visualization system, and the ability to load and simulate three dimensonal AGV models. Generation of the planner graph was reimplemented to include three dimensional factory graphs as well.
In the third step, the algorithm was completely implemented as described in the original paper, and its operation was tested on some factory configurations. To simulate as realistic conditions as possible, a three dimensional model of the factory cell in Gyor was created and loaded, and some test runs were carried out. The algorithm showed excellent performance in all of the studied scenarios.
Summing up, the problem of online disjoint route planning for this factory cell was solved, but this algorithm promises even more interesting possibilities for the future.
Our plans include more subtle resource management and introducing more realistic and efficient algorithms for exceptional cases (like vehicle breakdown). To provide an even more general and formal way for handling these tasks, we are looking forward to the introduction of time-window based temporal logic in the near future.
Acknowledgements
I would like to express my deepest appreciation to all those who provided me the possibil- ity to complete this report. A special gratitude I give to my supervisor, Prof. Szederk´enyi G´abor, whose contribution in stimulating suggestions and encouragement, helped me to coordinate this project.
I would like to thank Dr. P´eni Tam´as at MTA-SZTAKI for his continuos help and support during the work.
This work has been partially supported by the GINOP-2.3.2-15-2016-00002 grant of the Ministry of National Economy of Hungary.
