1 Introduction
Path finding is a vital capability of any intelligent agent operating in real or simulated physical environment. In case this environment is known a priory and remains static, grids are commonly used to explicitly represent it as they are simple yet informative and easytoupdate graph models. Grids appear naturally in game development [11] and are widely used in robotics [4], [12]
. When agent’s environment is represented by a grid, heuristic search algorithms, such as A*
[7] and its modifications, are typically used for path planning. The path planning process is carried out in the statespace, where states are induced by grid elements, and the function of generating successors defines which movements on the grid are allowed or not [15].Numerous works on gridbased path finding allow agent to move only between the cardinally adjacent grid elements, e.g cells or corners (sometimes, diagonal moves are allowed as well), see [6], [1], [10] for example. This often results in finding paths, containing multiple sharp turns (see Figure 1a), which might be undesirable for some applications. To mitigate this issue a few techniques have been proposed. First, smoothing can be carried out as the postprocessing step [1], i.e. when the path has already been planned. Second, smoothing can be interleaved with the statespace exploration resulting in socalled anyangle behavior (see Figure 1b). Originally anyangle algorithms, like Theta* [3], Lazy Theta* [9] were lacking optimality, by recently ANYA* [5] was introduced which guarantees finding shortest anyangle paths between the given grid cells.
Anyangle algorithms allow agent to move in any arbitrary direction, but the resulting paths still might contain sharp turns (see Figure 1b). [13] addresses this issue by keeping the number of turns to a possible minimum. In [8] a modification of Theta* was proposed, that prunes away the nodes that lead to the turns violating the given kinematic constraints of the agent. Finally, in [14] LIAN algorithm was proposed that seeks for the socalled angleconstrained paths, e.g. the paths comprised of line segments (with the endpoints tied to the grid elements), having the property that the angle between any two consecutive segments does not exceed the predefined threshold (see Figure 1c). In this work we focus on these sort of paths, e.g. angleconstrained paths.
Finding angleconstrained paths is a much harder problem to solve compared to finding shortest paths, as the algorithm has to keep numerous nodes corresponding to the same grid element because the latter can be approached from different directions, rather than keeping only one node and rewriting its gvalue (cost of the best path known so far). In order to keep the number of nodes in the search space to a reasonable minimum LIAN considers only states that correspond to the moves of the fixed length, which is the parameter of the algorithm. This, obviously, leads to incompleteness and to the sensitivity of the planner’s performance to the chosen parameter value. In this work, we mitigate this issue by introducing an original technique that adjusts the parameter value onthefly while the algorithm performs the search. This does not make the algorithm complete but significantly increases the chance of finding the solution. As shown experimentally, success rate of the enhanced planner, dubbed eLIAN (enhanced LIAN) exceeds the one of the original algorithm up to 20%. Meanwhile, the solution quality of eLIAN and LIAN is nearly the same.
2 Background
2.0.1 Problem statement
Consider a grid composed of blocked and unblocked cells and a pointagent that is allowed to move from one unblocked cell to the other following the straight line segment connecting the centers of those cells. The move is considered feasible if there exists lineofsight between the endpoints of the move, in other words – if the corresponding segment of the straight line does not intersect any blocked cell. In practice the wellknown in computer graphics algorithm from [2] adopting slight modifications can be used to efficiently perform lineofsight checks.
Consider now a path, , composed of feasible moves, , and the value , where is the angle between two consecutive line segments representing the moves. The task of the planner is formalized as follows. Given the start and the goal cell, as well as the constraint , find a feasible path , connecting them, such that .
2.0.2 LIAN algorithm
LIAN (abbreviation for ”limited angle”) is a heuristic search algorithm that seeks for the angleconstrained path composed of the segments of the fixed length, , which is the input parameter of the algorithm.
LIAN search node s is identified by the tuple , where s is the grid cell and is the backpointer to the predecessor of s, e.g. the node which was used to generate s. The backpointer to the predecessor allows to identify the heading, i.e. the direction of movement of the agent in case if it arrives to from bp(s). Additionally such data as the gvalue – the length of the angleconstrained path from the start node to the current node and the hvalue – approximate length of the path to the goal is also associated with the node.
LIAN explores the searchspace in the same way A* does. On each step it chooses the most promising node, e.g. the one minimizing fvalue () from OPEN (set of previously generated nodes which are the candidates for further processing) and expands it. Expanding includes removing the node from OPEN, adding it to CLOSED (set of already processed nodes), generating valid successors and adding them to OPEN. Generating successors is a multistep procedure including: a
) estimating the cells that lie within
distance, b) pruning away the cells that result in a move violating given angle constraint; c) pruning away the cells that violate lineofsight constraint; d) pruning away the cells that result in generating nodes that have already been visited before. To find the cells lying within distance midpoint circle algorithm is used that builds discrete approximation of a circumference centered in a given cell and of a given radius. Such circumferences are depicted on Figure 2. As one can see, the number of cells that satisfy angleconstraints grows with .Algorithm stops when either the goal node is retrieved from OPEN or the OPEN is exhausted. In the first case the sought angleconstrained path can be reconstructed using the backpointers, in the second one algorithm returns failure to find the path.
For the sake of space LIAN pseudocode is omitted but one can consult eLIAN code given in Algorithm 1 and Algorithm 2. LIAN code is the same stating that for LIAN. Thus, when expanding a node, condition on line 11 is always false for LIAN and lines 1213 are skipped. Condition on line 17 is also always false thus line 18 is skipped as well.
2.0.3 Sensitivity to the input parameter
As mentioned before, in general LIAN provides no guarantees to find a path even though it exists. One can only claim that if the angleconstrained path comprised of segments exists, the algorithm will find it [14]. In practice quite often LIAN fails to find a solution due to inappropriately chosen value.
On Figure 3 two scenarios are depicted when setting the value too low/too high leads to failure. When is low the number of cells lying within distance is also low, thus the number of potential successors that satisfies the predefined angle constraint for each expansion is low. This can lead to the exhaustion of OPEN, like in case depicted on Figure 3 left (here and angle constraint is set to be ). Setting to high values can also result in lowering down the number of successors but now it is mainly due to the violation of lineofsight constraints in certain cases – see Figure 3 right.
3 eLIAN
To mitigate the influence of the parameter on the effectiveness of the algorithm we suggest adjusting the former onthefly thus adapting LIAN behavior to given path finding instance, e.g. to the configuration of the obstacles and to the particular locations of start and goal.
In both cases described above and shown on Figure 3 algorithm would not have failed to find the solution if was either higher (the first case), or lower (the second case). Thus rather than fixing value we suggest setting the upper and the lower limit, and , and allow to take values from the range .
Introducing the range leads to the following questions: a) what is the initial value of from this range; b) what is the procedure of adjusting ; c) how is it embedded to the search algorithm. We suggest the following answers to these questions.
The initial value equals . The rationale behind this is that setting to high values potentially leads to large number of successors, except the cases (discussed above), which are to be handled by the next adjusting procedure.
In case no successors are generated at some step when is in use it should be lowered down by multiplying it by a factor of , which becomes the algorithm’s parameter. Now, in order to keep track of values they should be associated with the search nodes like gvalues and hvalues. We will refer to the exact value of the node as to . After fixing for the current node s, the latter is inserted back to OPEN, thus in case of reexpansion another set of successors will be generated for the node and possibly this set will not be empty. In case it is, is decremented again. Lowering down the value continues up to a point when . If this condition holds, e.g. the value can not be lowered down any more as it goes out of the range, the search node is discarded for good.
To provide additional flexibility to the algorithm we suggest not only decrementing value but also incrementing it after a few consecutive successful attempts of successors’ generation. Number of such attempts can be seen as another input parameter. As a result the algorithm tries to keep value as high as possible and lowers it down only when needed.
We name the resultant algorithm as eLIAN (stands for ”enhanced LIAN”). Pseudocode of eLIAN is presented as Algorithm 1 (main loop) and Algorithm 2 (node expansion). Please note that the code increments value after 2 consecutive successful expansions (see line 17 of the Algorithm 2), but it can be easily modified for another threshold.
An example of eLIAN trace is presented in Figure 4. The initial value is 8 and it is too high for the given task due to rather small passages between the obstacles. Regular LIAN algorithm would have failed to solve this task as it would not be able to generate valid successors that bypass the obstacles. In contrast, eLIAN decreased the value to 4 after two steps and successfully found a sequence of small sections going through the passage. After the obstacle was successfully bypassed value was increased back to 8 leading to more straightforward and rapid movement towards the goal.
The following properties of eLIAN can be inferred.
Property 1. eLIAN is correct, e.g. it terminates after the finite number of steps.
Sketch of proof. Algorithm is performing the search until the OPEN list is empty (or until the goal node is retrieved from it). OPEN contains only elements that correspond to the grid cells the total number of which is finite. As the algorithm operates only by sections the number of potential parents of the cell per each is also finite. eLIAN operates finite number of values in range . Thus the number of all nodes possibly considered by eLIAN is finite.
At the same time when a new node is generated the algorithm checks whether this node (the node defined by the same cell and the same parent) has been processed before already (lines 79 of Algorithm 2). And in case the CLOSED already contains such node it is pruned and is not added to OPEN. Taking into account the fact that on each step an element is removed from OPEN (line 6 of Algorithm 1) and added to CLOSED one can infer that sooner or later either the goal node will be retrieved or there will not be any node that could be added to OPEN and it will become empty. In both cases (lines 7, 11 of Algorithm 1) algorithm terminates.
Property 2. If there exists an angleconstrained path comprised of segments, eLIAN will find a solution.
Sketch of proof. As the path composed of segments exists, eLIAN will always maintain at least one node lying on that path as the first expansion happens with . Thus eLIAN always has an option to expand this node and to generate another one lying on path. Thus, sooner or later either this path will be found or eLIAN will find another path comprised of the segments of alternating lengths (due to the expansions of nodes with different values that have lower fvalues).
4 Experimental evaluation
To empirically evaluate the suggested algorithm, eLIAN, and to compare it with the predecessor, LIAN, we used the wellknown in the community benchmark sets from N. Sturtevant’s collection [11]: Baldur’s Gate (BG) and Warcraft III (WIII). Both collections contain maps used in computer games. BG maps (75 in total) represent mostly indoor environments while WIII maps (36 in total) – imaginary outdoor environments. Benchmark repository contains path finding instances organized into the socalled buckets. Instances belonging to the bucket have nearly the same solution cost (path length as found by A*). We used instances that belong to the most ”tough” buckets, e.g. the instances with the highest A* solution costs. There were taken 14 tasks per map for BG and 30 tasks for WIII to get more than 1000 tasks per each collection. We have also used a collection of maps that represent urban outdoor environment. These maps were retrieved from OpenStreetMaps^{1}^{1}1http://www.openstreetmaps.org/export. 100 maps of 1.2x1.2km fragments were converted to 501x501 grids (thus each grid cells corresponds to 2.7x2.7 area). 10 tasks per map were generated in such a way that a distance between start and goal is greater or equal to 1km (400 cells). An example of a map fragment that was used for the experimental evaluation and the corresponding grid are presented in Figure 5.
Experimental evaluation was carried out on Windows operated PC with Intel Core 2 Duo Q8300 @2.5Ghz processor and 2GB of RAM. For the sake of fair comparison both algorithms were coded from scratch using the same programming techniques and data structures.
It is known from previous research that finding angleconstrained paths might take time, so inflated heuristic was used to speedup the search. Heuristic weight was set to 2. Besides, 5 minutes time limit was introduced. In case the algorithm did not come up with the solution within this time, the result of the run was considered to be failure.
The following algorithms were evaluated: LIAN20, e.g. the original algorithm with ; eLIAN2010, e.g. , ; eLIAN205, e.g. , . For eLIAN we used , e.g. value was cut in half in case no valid successors were generated. This means that value alternated between 10 and 20 for eLIAN2010 and between 5 and 10 and 20 for eLIAN205. The angle constraint was set to be , and .
City Maps  Baldur’s Gate  Warcraft III  

LIAN20  84.2%  89.0%  91.8%  61.24%  71.71%  81.05%  78.33%  82.22%  85.74% 
eLIAN2010  89.5%  93.5%  95.2%  74.38%  84.76%  88.0%  83.98%  88.33%  91.76% 
(+5.3)  (+4.5)  (+3.4)  (+13.14)  (+13.05)  (+6.95)  (+5.65)  (+6.11)  (+6.02)  
eLIAN205  92.4%  95.4%  97.0%  82.38%  88.29%  87.52%  87.5%  92.59%  93.61% 
(+8.2)  (+6.4)  (+5.2)  (+21.14)  (+16.57)  (+6.48)  (+9.17)  (+10.37)  (+7.87) 
City Maps  Baldur’s Gate  Warcraft III  

eLIAN2010  27.8%  35%  37.2%  34.7%  49.1%  44.7%  17.5%  22.6%  32% 
eLIAN205  43.3%  46.7%  60.5%  56.6%  73%  76.7%  34.5%  51.6%  50.5% 
Success rates of the algorithms are reported in Table 1. As one can see eLIAN always solves more tasks that the predecessor, no matter which collection or angle constraint is used. The most notable difference is predictably between LIAN20 and eLIAN205. Suggested technique of dynamic value adjusting leads to solving up to 20% more tasks (see Baldur’s Gate) and thus substantially increases the effectiveness of the algorithm. The normalized number of instances that were not solved by LIAN but solved by eLIAN is presented in Table 2. In absolute numbers LIAN failed to solve 659 tasks for , 451  for and 299  for . Analyzing the figures, one can claim that on average eLIAN is able to successfully handle (within 5 minutes time cap) half of the tasks that LIAN is unable to solve.
To conduct a fair comparison of the efficiency indicators, e.g. the resultant runtimes, we averaged those values across the intstances that were solved by all three algorithms: LIAN20, eLIAN2010 and eLIAN205. Instead of arithmetic mean value, we report the median, since there is a big discrepancy in the algorithms’ runtimes (up to one order of magnitude). The results are depicted on Figure 6. As one might see on City Maps and Warcraft III collections eLIAN works faster than the predecessor, while on Baldur’s Gate eLIAN’s runtime is equal or higher than the one of LIAN. This might be explained by the difference in types of environments. City Maps and Warcraft III collections consist of the maps representing outdoor environments populated with standalone and rather small obstacles, while most maps in Baldur’s Gate collection represent indoor environments with rooms, corridors and walls. Due to the increased branching factor (e.g. reexpnaing the nodes with attempting different values) in case of getting stuck into obstacles represented by walls, eLIAN has to spend more time circumnavigating them in comparison with LIAN.
We have also compared the quality indicators of the solutions, provided by the algorithms. In terms of pathlength, all algorithms with all values of showed very close results, and the difference between them doesn’t exceed a couple of percent. Another quality indicator we were interested in represents the accumulated turning angle that the resulting trajectories contain. The normalized results are depicted on Figure 7. As a baseline we have taken LIAN with 20 angle constraint. The results on all collections show the same trends: increasing the maximum possible turning angle leads to higher values of accumulated angle. Moreover, eLIAN with allowance of making sections with less size finds trajectories with higher values of this indicator as well. This result can be explained by the fact, that the cost function of LIAN and eLIAN is targeted just on minimizing the path length and doesn’t take into account the considered indicator. As a result, the algorithm that has more opportunities to explore the searchspace, e.g. eLIAN, finds paths that contain more turns.
5 Conclusions
We have considered a problem of gridbased angleconstrained path planning and presented a novel technique that significantly boosts the performance of the stateoftheart planner tailored to solve those type of problems. As shown experimentally, success rate of the enhanced algorithm is notably higher (up to 20%) while solution quality is nearly the same. Obvious and appealing direction of future research is elaborating on further enhancements to make the algorithm complete.
6 Acknowledgments
The work was partially supported by the “RUDN University Program 5100” and by the special program of the presidium of Russian Academy of Sciences.
References
 [1] Botea, A., Müller, M., Schaeffer, J.: Near optimal hierarchical pathfinding. Journal of game development 1(1), 7–28 (2004)
 [2] Bresenham, J.E.: Algorithm for computer control of a digital plotter. IBM Systems journal 4(1), 25–30 (1965)

[3]
Daniel, K., Nash, A., Koenig, S., Felner, A.: Theta*: Anyangle path planning on grids. Journal of Artificial Intelligence Research
39, 533–579 (2010)  [4] Elfes, A.: Using occupancy grids for mobile robot perception and navigation. Computer 22(6), 46–57 (1989)
 [5] Harabor, D., Grastien, A., Oz, D., Aksakalli, V.: Optimal anyangle pathfinding in practice. Journal of Artificial Intelligence Research 56, 89–118 (2016)
 [6] Harabor, D.D., Grastien, A.: Online graph pruning for pathfinding on grid maps. In: Proceedings of The 25th AAAI Conference on Artificial Intelligence (AAAI2011). pp. 1114–1119 (2011)
 [7] Hart, P.E., Nilsson, N.J., Raphael, B.: A formal basis for the heuristic determination of minimum cost paths. IEEE transactions on Systems Science and Cybernetics 4(2), 100–107 (1968)
 [8] Kim, H., Kim, D., Shin, J.U., Kim, H., Myung, H.: Angular rateconstrained path planning algorithm for unmanned surface vehicles. Ocean Engineering 84, 37–44 (2014)
 [9] Nash, A., Koenig, S., Tovey, C.: Lazy theta*: anyangle path planning and path length analysis in 3d. In: Proceedings of the 24th AAAI Conference on Artificial Intelligence (AAAI2010). pp. 147–154. AAAI Press (2010)
 [10] Silver, D.: Cooperative pathfinding. In: Proceedings of The 1st Conference on Artificial Intelligence and Interactive Digital Entertainment (AIIDE2005). pp. 117–122 (2005)
 [11] Sturtevant, N.R.: Benchmarks for gridbased pathfinding. IEEE Transactions on Computational Intelligence and AI in Games 4(2), 144–148 (2012)
 [12] Thrun, S.: Learning occupancy grid maps with forward sensor models. Autonomous robots 15(2), 111–127 (2003)
 [13] Xu, H., Shu, L., Huang, M.: Planning paths with fewer turns on grid maps. In: Proceedings of The 6th Annual Symposium on Combinatorial Search (SoCS2013). pp. 193–201 (2013)
 [14] Yakovlev, K., Baskin, E., Hramoin, I.: Gridbased angleconstrained path planning. In: Proceedings of The 38th GermanC onference on Artificial Intelligence (KI2015). pp. 208–221. Springer (2015)
 [15] Yap, P.: Gridbased pathfinding. In: Proceedings of 15th Conference of the Canadian Society for Computational Studies of Intelligence. pp. 44–55. Springer (2002)
Comments
There are no comments yet.