eLIAN: Enhanced Algorithm for Angle-Constrained Path Finding

Abstract

Problem of finding 2D paths of special shape, e.g. paths comprised of line segments having the property that the angle between any two consecutive segments does not exceed the predefined threshold, is considered in the paper. This problem is harder to solve than the one when shortest paths of any shape are sought, since the planer’s search space is substantially bigger as multiple search nodes corresponding to the same location need to be considered. One way to reduce the search effort is to fix the length of the path’s segment and to prune the nodes that violate the imposed constraint. This leads to incompleteness and to the sensitivity of the’s performance to chosen parameter value. In this work we introduce a novel technique that reduces this sensitivity by automatically adjusting the length of the path’s segment on-the-fly, e.g. during the search. Embedding this technique into the known grid-based angle-constrained path finding algorithm LIAN, leads to notable increase of the planner’s effectiveness, e.g. success rate, while keeping efficiency, e.g. runtime, overhead at reasonable level. Experimental evaluation shows that LIAN with the suggested enhancements, dubbed eLIAN, solves up to 20% of tasks more compared to the predecessor. Meanwhile, the solution quality of eLIAN is nearly the same as the one of LIAN.

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 easy-to-update 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 state-space, 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 grid-based 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 [1, 6, 10] for example. This often results in finding paths, containing multiple sharp turns (see Fig. 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 post-processing step [1], i.e. when the path has already been planned. Second, smoothing can be interleaved with the state-space exploration resulting in so-called any-angle behavior (see Fig. 1b). Originally any-angle algorithms, like Theta* [3], Lazy Theta* [9] were lacking optimality, by recently ANYA* [5] was introduced which guarantees finding shortest any-angle paths between the given grid cells.

Any-angle algorithms allow agent to move in any arbitrary direction, but the resulting paths still might contain sharp turns (see Fig. 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 so-called angle-constrained 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 Fig. 1c). In this work we focus on these sort of paths, e.g. angle-constrained paths.

Fig. 1.

Different types of grid paths. (a) A*-path composed of the moves between cardinally adjacent cells; (b) any-angle path; (c) angle-constrained path

Finding angle-constrained 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 re-writing its g-value (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 on-the-fly 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

Problem Statement. Consider a grid composed of blocked and unblocked cells and a point-agent 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 line-of-sight 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 well-known in computer graphics algorithm from [2] adopting slight modifications can be used to efficiently perform line-of-sight checks.

Consider now a path, $\pi$, composed of feasible moves, $e_i$, and the value $\alpha _m(\pi ) = max (|\alpha (e_1, e_2)|, |\alpha (e_2, e_3)|, \ldots , |\alpha (e_{v-1}, e_v)|)$, where $\alpha (e_j, e_{j+1})$ 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 $\alpha _{MAX} \in [0^\circ ; 180^\circ ]$, find a feasible path $\pi$, connecting them, such that $\alpha _m(\pi ) \le \alpha _{MAX}$.

LIAN Algorithm. LIAN (abbreviation for “limited angle”) is a heuristic search algorithm that seeks for the angle-constrained path composed of the segments of the fixed length, $\varDelta$, which is the input parameter of the algorithm.

LIAN search node $\mathbf s$ is identified by the tuple $[\textit{s}, {\varvec{bp}}(\mathbf s )]$, where $\textit{s}$ is the grid cell and ${\varvec{bp}}(\mathbf s )$ is the back-pointer to the predecessor of $\mathbf s$, e.g. the node which was used to generate $\mathbf s$. The back-pointer to the predecessor allows to identify the heading, i.e. the direction of movement of the agent in case if it arrives to s from bp(s). Additionally such data as the g-value – the length of the angle-constrained path from the start node to the current node and the h-value – approximate length of the path to the goal is also associated with the node.

LIAN explores the search-space in the same way A* does. On each step it chooses the most promising node, e.g. the one minimizing f-value ($f({\varvec{s}})=g({\varvec{s}})+h({\varvec{s}})$) 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 multi-step procedure including: (a) estimating the cells that lie within $\varDelta$-distance, (b) pruning away the cells that result in a move violating given angle constraint; (c) pruning away the cells that violate line-of-sight constraint; (d) pruning away the cells that result in generating nodes that have already been visited before. To find the cells lying within $\varDelta$-distance midpoint circle algorithm is used that builds discrete approximation of a circumference centered in a given cell and of a given $\varDelta$-radius. Such circumferences are depicted on Fig. 2. As one can see, the number of cells that satisfy angle-constraints grows with $\varDelta$.

Fig. 2.

The process of generating successors. The cells identified by midpoint circle algorithm are marked by light-gray. Among them only those cells are considered that satisfy the angle constraint (marked by dark-gray).

Algorithm stops when either the goal node is retrieved from OPEN or the OPEN is exhausted. In the first case the sought angle-constrained path can be re-constructed using the back-pointers, 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 $\varDelta _{max} = \varDelta _{min} = \varDelta$ for LIAN. Thus, when expanding a node, condition on line 11 is always false for LIAN and lines 12–13 are skipped. Condition on line 17 is also always false thus line 18 is skipped as well.

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 angle-constrained path comprised of $\varDelta$-segments exists, the algorithm will find it [14]. In practice quite often LIAN fails to find a solution due to inappropriately chosen $\varDelta$-value.

Fig. 3.

Inappropriate $\varDelta$-value for LIAN. Left: $\varDelta$-value is set too low, thus the number of successors on each step is limited, thus the obstacle can not be circumnavigated. Right: $\varDelta$-value is set too high, line-of-sight constraint is consequently breached as a result no valid successors are generated to continue the search.

On Fig. 3 two scenarios are depicted when setting the $\varDelta$-value too low/too high leads to failure. When $\varDelta$ is low the number of cells lying within $\varDelta$-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 Fig. 3 left (here $\varDelta =3$ and angle constraint is set to be $25^{\circ }$). Setting $\varDelta$ to high values can also result in lowering down the number of successors but now it is mainly due to the violation of line-of-sight constraints in certain cases – see Fig. 3 right.

3 eLIAN

To mitigate the influence of the parameter $\varDelta$ on the effectiveness of the algorithm we suggest adjusting the former on-the-fly 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 Fig. 3 algorithm would not have failed to find the solution if $\varDelta$ was either higher (the first case), or lower (the second case). Thus rather than fixing $\varDelta$-value we suggest setting the upper and the lower limit, $\varDelta _{max}$ and $\varDelta _{min}$, and allow $\varDelta$ to take values from the range $[\varDelta _{min}, \varDelta _{max}]$.

Introducing the $\varDelta$ range leads to the following questions: (a) what is the initial value of $\varDelta$ from this range; (b) what is the procedure of adjusting $\varDelta$; (c) how is it embedded to the search algorithm. We suggest the following answers to these questions.

The initial value equals $\varDelta _{max}$. The rationale behind this is that setting $\varDelta$ 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 $\varDelta _{max}$ is in use it should be lowered down by multiplying it by a factor of $k \in (0; 1)$, which becomes the algorithm’s parameter. Now, in order to keep track of $\varDelta$-values they should be associated with the search nodes like g-values and h-values. We will refer to the exact $\varDelta$-value of the node as to $\varDelta (\mathbf s )$. After fixing $\varDelta (\mathbf s )$ for the current node $\mathbf s$, the latter is inserted back to OPEN, thus in case of re-expansion another set of successors will be generated for the node and possibly this set will not be empty. In case it is, $\varDelta (\mathbf s )$ is decremented again. Lowering down the $\varDelta$-value continues up to a point when $k \cdot \varDelta (\mathbf s ) < \varDelta _{min}$. If this condition holds, e.g. the $\varDelta$-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 $\varDelta$-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 $\varDelta$-value as high as possible and lowers it down only when needed.

Fig. 4.

An example of how eLIAN works. Possible $\varDelta$-values are 8 and 4. Angle constraint is $\alpha =35^\circ$

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 $\varDelta$-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 Fig. 4. The initial $\varDelta$-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 $\varDelta$-value to 4 after two steps and successfully found a sequence of small sections going through the passage. After the obstacle was successfully bypassed $\varDelta$-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 $\varDelta$-sections the number of potential parents of the cell per each $\varDelta$ is also finite. eLIAN operates finite number of $\varDelta$-values in range $[\varDelta _{min};\varDelta _{max}]$. 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 7–9 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 angle-constrained path comprised of $\varDelta _{max}$-segments, eLIAN will find a solution.

Sketch of proof. As the path composed of $\varDelta _{max}$-segments exists, eLIAN will always maintain at least one node lying on that path as the first expansion happens with $\varDelta _{max}$. Thus eLIAN always has an option to expand this node and to generate another one lying on $\varDelta _{max}$-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 $\varDelta$-values that have lower f-values).

4 Experimental Evaluation

To empirically evaluate the suggested algorithm, eLIAN, and to compare it with the predecessor, LIAN, we used the well-known 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 so-called 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¹. 100 maps of 1.2$\,\times \,$1.2 km fragments were converted to 501$\,\times \,$501 grids (thus each grid cells corresponds to 2.7$\,\times \,$2.7 area). 10 tasks per map were generated in such a way that a distance between start and goal is greater or equal to 1 km (400 cells). An example of a map fragment that was used for the experimental evaluation and the corresponding grid are presented in Fig. 5.

Fig. 5.

Left: Map fragment of an urban environment retrieved from OpenStreetMaps. Right: An example of a task, solved by eLIAN on the corresponding grid.

Table 1. Success rate of LIAN and eLIAN

Experimental evaluation was carried out on Windows operated PC with Intel Core 2 Duo Q8300 @2.5 Ghz processor and 2 GB 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 angle-constrained paths might take time, so inflated heuristic was used to speed-up the search. Heuristic weight was set to 2. Besides, 5 min 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: LIAN-20, e.g. the original algorithm with $\varDelta =20$; eLIAN-20-10, e.g. $\varDelta _{max}=20$, $\varDelta _{min}=10$; eLIAN-20-5, e.g. $\varDelta _{max}=20$, $\varDelta _{min}=5$. For eLIAN we used $k=0.5$, e.g. $\varDelta$-value was cut in half in case no valid successors were generated. This means that $\varDelta$-value alternated between 10 and 20 for eLIAN-20-10 and between 5 and 10 and 20 for eLIAN-20-5. The angle constraint was set to be $20^{\circ }$, $25^{\circ }$ and $30^{\circ }$.

Table 2. Normalized number of tasks that were not solved by LIAN but solved with eLIAN

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 LIAN-20 and eLIAN-20-5. Suggested technique of dynamic $\varDelta$-value adjusting leads to solving up to 20% more tasks (see Baldur’s Gate-$20^\circ$) 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 $\varDelta =20^\circ$, 451 - for $\varDelta =25^\circ$ and 299 - for $\varDelta =30^\circ$. Analyzing the figures, one can claim that on average eLIAN is able to successfully handle (within 5 min time cap) half of the tasks that LIAN is unable to solve.

Fig. 6.

Averaged runtime of LIAN and eLIAN

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: LIAN-20, eLIAN-20-10 and eLIAN-20-5. 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 Fig. 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 stand-alone 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. re-expnaing the nodes with attempting different Delta-values) in case of getting stuck into obstacles represented by walls, eLIAN has to spend more time circumnavigating them in comparison with LIAN.

Fig. 7.

Normalized accumulated turning angle

We have also compared the quality indicators of the solutions, provided by the algorithms. In terms of pathlength, all algorithms with all values of $\varDelta$ 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 Fig. 7. As a baseline we have taken LIAN with 20$^\circ$- 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 search-space, e.g. eLIAN, finds paths that contain more turns.

5 Conclusions

We have considered a problem of grid-based angle-constrained path planning and presented a novel technique that significantly boosts the performance of the state-of-the-art 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.