Real-time motion planning with a fixed-wing UAV using an agile maneuver space

Abstract

Small fixed-wing unmanned aerial vehicles (UAVs) are becoming increasingly capable of flying at low altitudes and in constrained environments. This paper addresses the problem of automating the flight of a fixed-wing UAV through highly constrained environments. The main contribution of this paper is the development of a maneuver space, integrating steady and transient agile maneuvers for a class of fixed-wing aircraft. The maneuver space is integrated into the rapidly-exploring random trees (RRT) algorithm. The RRT-based motion planner, together with a flight control system, is demonstrated in simulations and flight tests to efficiently generate and execute a motion plan through highly constrained 3D environments in real-time. The flight experiments—which effectively demonstrated the usage of three highly agile maneuvers—were conducted using only on-board sensing and computing.

Re-planning

This appendix outlines how a re-planning step can be incorporated into the motion planner to eliminate cumulative position errors if and when they grow sufficiently large. The actions of re-planning would neatly fit at the end of Algorithm 3, under a conditional statement that gets added to check for position error against a user-defined constant: $\mathbf if ~e_p > \epsilon$.

Re-planning involves two actions, the first of which is to modify the nodes being sent to the controller during the update, such that they align with the actual position and heading of the aircraft. The motion primitives themselves remain the same, i.e. $\dot{\psi }$, $\dot{z}$, and $\varDelta t$ are known, but the positions and headings of each node must be recalculated. This is done through rearrangement of Eq. 3:

$$\begin{aligned} x_2= & {} x_1 + \Biggl (\frac{V}{\dot{\psi }}\sin (\psi _1 + \dot{\psi }\varDelta t) - \frac{V}{\dot{\psi }}\sin {\psi _1}\cos ({\arcsin {\frac{\dot{z}}{V}})}\Biggr )\nonumber \\ y_2= & {} y_1 + \Biggl (-\frac{V}{\dot{\psi }}\cos (\psi _1 + \dot{\psi }\varDelta t) + \frac{V}{\dot{\psi }}\cos {\psi _1}\cos ({\arcsin {\frac{\dot{z}}{V}})}\Biggr )\nonumber \\ z_2= & {} z_1 + \dot{z}\varDelta t\nonumber \\ \psi _2= & {} \psi _1 + \dot{\psi }\varDelta t \end{aligned}$$

(6)

The other action taken during re-planning is to prune the tree of all nodes other than the ones being sent to the aircraft during the update. While it may seem detrimental to throw away these previously generated nodes, the algorithm is very efficient at building (or re-building) a tree in real-time. The alternative, to keep the tree nodes, would require translating each node and re-checking each primitive for collisions. This is a much more costly process (namely, the collision checking), that would not be of any great benefit given how quickly the tree can be re-built.

Tests were run on the ODROID XU4 to evaluate the practicality of employing the re-planning step. We investigated whether the planner was efficient enough to recover from pruning almost all of the tree nodes in real-time. Using the map of Fig. 13, the motion planning algorithm was run twenty times. The planner was left to run until the Update Tree function had commanded a path that ended in the goal region; as though the aircraft were in flight and the algorithm were running in real-time. Instead of setting up the ODROID in a simulation loop with the aircraft dynamics model, we simply programmed fake position errors into the algorithm such that the re-planning step would be repeatedly triggered; for each run, the re-planning step was triggered twice. Each time the re-planning step occurred, the algorithm was able to rapidly rebuild a new tree. By the next time the Update Tree function was called after re-planning (it is called every half second), the tree would have already grown to hold approximately 1000 new nodes, on average. For reference, the tree rarely ever grew to have many more than 2000 nodes at a time, for the map in question. In the twenty runs, nineteen successfully resulted in a path to the goal region. In the one other case, the planner got stuck and had to send a command to perform the cruise-to-hover maneuver before reaching the goal region. It cannot necessarily be determined that the re-planning step was the cause of this failure. We observed that the number of tree nodes in subsequent calls of the Update Tree function, before and after re-planning, was barely affected, and thus we can at least rule out the notion of the failure being caused by a lack of trajectory options post-tree-pruning.