Patent Description:
A vehicle may navigate through an environment along a path from a start point to another point. While navigating along the path, the vehicle may come across obstacles in the environment.

A vehicle may have a flight control computing system to control navigation of the vehicle through an environment from an initial point to a terminal point along a flight path in accordance with model following control laws. As the vehicle traverses the environment, the computing system may receive command signals received from inceptors as directed by an operator to direct the navigation of the vehicle. The command signals may be to set or adjust a velocity (e.g., longitudinal, lateral, and vertical velocities), acceleration (e.g., longitudinal, lateral, and vertical accelerations), and orientation (e.g., roll, pitch, and yaw rates) of the vehicle. In conjunction, the computing system may instrument various sensory data on the components of the vehicle (e.g., the engine, wing, and battery). The computing system may feed the command signals and sensory data to a myriad of models configured to assist in the generation of flight trajectories for a flight path of the vehicle. Using these models, the computing system may generate flight trajectories for the vehicle to navigate through the environment accounting for the operator input through the inceptors. The computing system may feed the command signals calculated by the models to the navigation components to effectuate the flight path through the environment. <CIT> discloses a non-binary collaborative recovery system in which a processor supplies flight commands to a flight control system by selectively blending pilot input with control signals from the autopilot. The processor generates a projected recovery trajectory through successive iterations, each beginning at the current aircraft location and using a recovery constraint selectable by the processor to influence a degree of flight aggressiveness. A detection system identifies and invokes a state of threat existence if a threat exists along the projected recovery trajectory. The processor during threat existence in a first iteration commands an initial soft recovery, with permitted blended pilot input. If the threat exists on subsequent iteration, the processor commands a more aggressive recovery while attenuating blended pilot input. <CIT> discloses a trajectory tracking flight controller (TLC) architecture for a fixed-wing aircraft. The TLC architecture calculates nominal force and moment commands by dynamic inversion of the nonlinear equations of motion. A linear time-varying tracking error regulator provides exponential stability of the tracking error dynamics and robustness to model uncertainty and error. The basic control loop includes a closed-loop, LTV stabilizing controller, a pseudo-inverse plant model, and a nonlinear plant model. Four of the basic control loops are nested to form the TLC architecture. <CIT> discloses a system for controlling an unmanned aerial vehicle (UAV) to switch between different flight modes during operation. The system includes one or more processors configured to determine, based on sensor data received from one or more sensors carried by the UAV, a change in environment of the UAV from a first environment type to a second environment type. In response to determining the change in environment, the one or more processors are configured to switch a flight mode of the UAV from a first flight mode to a second flight mode, and effect operation of the UAV in accordance with a second set of operating rules for operating in the second environment type. <NPL> discloses an all-terrain ground collision avoidance system (GCAS) in conjunction with a maneuvering terrain following (TF) system. A pilot is able to execute high rate turns, evasive maneuvers, and inverted ridge crossings while following the terrain contour. Safety is maintained in day, night, and weather by the ground collision avoidance system.

While the models described above can be used to calculate flight trajectories, one issue with these models may be their computational complexity. For example, an inverse plant function to accept total commanded pitch, roll, and yaw rates, and shape the commanded rates using an inverse model for each axis of aircraft dynamics in full order. In conjunction, a feedback model may also take the total commanded pitch, roll, and yaw rates along with a commanded velocity to calculate velocity error also in full order to maintain velocity. The outputs of these two models may be combined by a mixing model to combine control commands to ensure that the response remains on axes. The computational complexity arising from the numerous steps of calculations with the multitude of variables may lead to latency in calculations of the flight trajectory by the flight control computing system, which may introduce delays in the flight control computing system updating a flight trajectory to avoid an obstacle. These models may thus be unsuitable for generating flight trajectories to avoid terrain obstacles especially when the vehicle is traveling at high speeds, given the short response times in order to prevent collision with such obstacles.

A method and system for controlling an aircraft are provided according to the appended claims. Particularly, to address these and other challenges, the flight control computing system of this technical solution can use a reduced-order closed-loop model to generate flight trajectories for the vehicle. The reduced-order model may approximate the input and output behavior of one or more of the models, such as the inverse plant function, the feedback model, and the mixing model. The reduced-order model may have a lower number in terms of order compared to the models described above. In addition, the computing system may apply a fade function for each command signal. The fade function may apply a weight over a time window relative to a time point at which the command signal was received from the inceptors. Upon the application of the fade function, the computing system may feed the command signals to the reduced-order model. The computing system may use the reduced-order model to process the command signals to generate a flight trajectory with which to navigate the vehicle away from an obstacle.

With the determination, the computing system may determine whether the flight trajectory of the vehicle intersects with an obstacle in the environment. The computing system may detect various obstacles from terrain data regarding the environment. Depending on a speed of the vehicle, the computing system may find a goal point to which to navigate the aircraft to avoid the obstacle upon determining that the flight trajectory intersects with the obstacle. When the vehicle is operating in a low-speed mode (e.g., below a threshold speed), the computing system may identify the location to hover the aircraft relative to the obstacle in the environment. Otherwise, when the vehicle is operating in a high-speed mode (e.g., above a threshold speed), the computing system may identify one or more goal points to navigate the vehicle to evade the obstacle by a clearance distance. The computing system may automatically feed the command signals to the navigation components of the vehicle to avoid the obstacle, without any operator input through the inceptors.

By using the reduced-order closed-loop model, the flight control computing system may be able to more quickly calculate predicted flight trajectories using the command signals inputted by the operator via the inceptors, relative to the full-order model. Furthermore, because the reduced-order model is able to calculate faster, the outputted flight trajectories may be suitable for use for a terrain obstacle avoidance. Using the output and terrain data, the computing system may determine whether the flight trajectory that the vehicle is navigating along intersects with the obstacle in the environment. In this manner, the utility of the flight control computing system may be further expanded to trajectory prediction and the obstacle avoidance, thereby increasing the odds of accomplishing the mission objectives of the flight.

At least one aspect of this technical solution is directed to apparatuses, systems, and methods for controlling an aircraft. A computing system may have one or more processors coupled with memory on an aircraft. The computing system may identify a first plurality of command signals derived from an input received via a flight control at a time point to control navigation of the aircraft through an environment. The computing system may attenuate the first plurality of command signals using a fade function over a time window relative to the time point to generate a second plurality of command signals. The computing system may input the second plurality of command signals to a model to generate one or more predicted paths for the aircraft through the environment over the time window. The computing system may determine that at least one predicted path of the one or more predicted paths intersects with an obstacle in the environment during the time window. The computing system may generate a location to which to navigate the aircraft to avoid the obstacle responsive to determining that the at least one predicted path intersects with the obstacle. The computing system may perform an action to direct the aircraft to the location.

In some embodiments, the model may approximate at least one of an inverse plant model, a corrective feedback model, a control mixing model, or a servos control unit in a flight control system for the aircraft. In some embodiments, the computing system may input the second plurality of command signals to the model, at an interval of time, to generate the one or more predicted paths for the aircraft through the environment.

In some embodiments, the computing system may compare the at least one predicted path for the aircraft with a world model for the environment to determine that the at least one predicted path intersects the obstacle. In some embodiments, the computing system may identify whether the aircraft is operating in at least one of a first mode or a second mode based on a speed of the aircraft, responsive to determining that the at least one predicted path intersects with the obstacle.

In some embodiments, the computing system may generate a potential field map using a world model for the environment. The potential field map may identify whether the environment is occupied or free at an altitude of the aircraft. In some embodiments, the computing system may generate the location to hover the aircraft relative to the obstacle in the environment, responsive to a speed of the aircraft being below a threshold. In some embodiments, the computing system may generate a plurality of waypoints through which to navigate the aircraft to evade the obstacle by at least a clearance distance, responsive to a speed of the aircraft being above a threshold.

In some embodiments, the computing system may provide an output to an operator of the aircraft to navigate the aircraft to the location to avoid the obstacle. The output may include at least one of a visual cue, an audio cue, or a tactile cue. In some embodiments, the computing system may switch, without corrective input to avoid the obstacle from an operator of the aircraft, the aircraft from a manual flight mode to an autonomy flight mode to navigate the aircraft to the location to avoid the obstacle.

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context indicates otherwise.

Referring to <FIG>, among others, depicted is a block diagram of an environment or a system <NUM> for controlling navigation of vehicles. In overview, the system <NUM> may include at least one air vehicle <NUM>. The air vehicle <NUM> may include at least one flight control computing system <NUM> (sometimes herein generally referred to as a computing system), one or more inceptors 115A-N (hereinafter generally referred to as inceptors <NUM>), one or more navigation components 120A-N (hereinafter generally referred to as navigation components <NUM>), and at least one interface <NUM>, among others. The flight control computing system <NUM> may include at least one inceptor processor <NUM>, at least one path predictor <NUM>, at least one collision checker <NUM>, at least one goal selector <NUM>, at least one motion planner <NUM>, at least one component controller <NUM>, at least one path prediction model <NUM>, among others. Various components and modules of the system <NUM>, such as the flight control computing system <NUM>, among others, may be implemented using hardware components or a combination of software and hardware components as detailed herein in <FIG>.

In further detail, the air vehicle <NUM> can include any transport capable of navigating through an environment. The air vehicle <NUM> can be any type of aircraft, such as a fixed-wing aircraft (e.g., with a propeller or jet engine), a rotorcraft (e.g., a helicopter, an autogyro, or a gyrodrone), an aerostat (e.g., an airship or dirigible), or an underwater vehicle (e.g., a submarine, a submersible, or an underwater glider), among others. The air vehicle <NUM> can be manned or unmanned, or any combination thereof. If manned, the navigation of the air vehicle <NUM> can be controlled by an onboard pilot from the cockpit therein. If unmanned, the navigation of the air vehicle <NUM> can be autonomous with no input or remote input (e.g., from a remote terminal) while traveling through the environment. While discussed primarily in terms of an air vehicle, land-bound vehicles (e.g., a sedan car, a truck, a van, or a bus) and seaborne vehicles (e.g., a ship, a frigate, a hydrofoil ship, submarine, or submersible) may be also applicable.

The flight control computing system <NUM> may be used to determine or generate at least one predicted path <NUM> via which the air vehicle <NUM> is to navigate through the environment. In some embodiments, the flight control computing system <NUM> may be housed, disposed, or otherwise situated in the air vehicle <NUM>. The one or more of the components of the flight control computing system <NUM> (e.g., the inceptor processor <NUM>, the path predictor <NUM>, the collision checker <NUM>, the goal selector <NUM>, the motion planner <NUM>, the component controller <NUM>, and the path prediction model <NUM>) may be executable on one or more processors coupled with memory of a computing system. The processors may be housed, disposed, or otherwise situated throughout the air vehicle <NUM>. Details regarding the generation of the predicted path <NUM> will be discussed herein below.

The inceptors <NUM> may retrieve or receive input from an operator for the flight control computing system <NUM> to steer, maneuver, or otherwise control the navigation of the air vehicle <NUM>. In some embodiments, the operator (e.g., a pilot) using the inceptors <NUM> may be physically within the air vehicle <NUM>. In some embodiments, the operator may be remote from the air vehicle <NUM> to control navigation via the inceptors <NUM>. For example, the inceptors <NUM> may be communicatively coupled with a remote computing system used by the operator to maneuver the air vehicle <NUM>. The input received by the inceptors <NUM> may be in any modality, such as tactile input (e.g., acquired via a joystick, pedal, buttons, keyboard, or mouse), voice command (e.g., acquired via a microphone), or visual gesture (e.g., acquired via a camera), among others. The input may define, specify, or identify a velocity (e.g., longitudinal, lateral, and vertical velocities), acceleration (e.g., longitudinal, lateral, and vertical accelerations), and orientation (e.g., roll, pitch, and yaw rates) for the navigation of the air vehicle <NUM>.

The navigation components <NUM> may be used by the air vehicle <NUM> to navigate through the environment. The navigation components <NUM> may be electromechanical parts configured to be set or adjusted to navigate the air vehicle <NUM> in the environment according to the flight trajectory. The navigation components <NUM> may be controlled by the flight control computing system <NUM> in response to an input at one or more of the inceptors <NUM>. The navigation components <NUM> may, for example, include those for propulsion to navigate through the environment, such as a landing gear, fuel tank, batteries, engine, rotor (including main rotor and tail rotor), wing (including slat, flat, spoiler, and aileron), and tail (including stabilizers, elevator, and rudder), among others.

The air vehicle <NUM> may also have other components to facilitate the navigation of the air vehicle <NUM>. The air vehicle <NUM> may have one or more sensors to instrument, measure, or acquire various sensory data associated with the functions of the air vehicle <NUM>, such as the navigation components <NUM>. For example, the sensors may acquire a status, orientation, or position of the rotors, wings (including slat, flat, spoiler, and aileron), and tail (including stabilizers, elevator, and rudder), among others. The sensors may also acquire other metrics associated with the navigation of the air vehicle <NUM> itself, such as fuel level, speed, acceleration, engine thrust, temperature, wind speed (e.g., headwind, crosswind, and tailwind), among others. The sensors may also acquire position data, such as a location (e.g., a global position system (GPS) coordinates) and altitude, among others, of the air vehicle <NUM>. The sensors may also include various devices to acquire data on the environment surrounding the air vehicle <NUM>, such as a LiDAR, RADAR, or camera, among others.

Referring to <FIG>, among others, depicted a block diagram of an architecture <NUM> for the system <NUM> for controlling navigation of vehicles. The architecture <NUM> may specify a flow of data among the components of the system <NUM>, including the flight control computing system <NUM> in the air vehicle <NUM>. The architecture <NUM> may include at least one operator maneuver loop <NUM> and at least one terrain avoidance <NUM> (e.g., as depicted). The operator maneuver loop <NUM> and the terrain avoidance loop <NUM> may form two respective branches of data flow in the architecture <NUM>. The division into the two branches may be dependent on a condition check <NUM>. In general, the operator maneuver loop <NUM> may correspond to operations in the flight control computing system <NUM> to navigate the air vehicle <NUM> using inputs by the operator via the inceptors <NUM> (e.g., in accordance with model following control laws). The terrain avoidance loop <NUM> may corresponds to operations in the flight control computing system <NUM> to perform terrain avoidance measures upon detection of an obstacle in the terrain of the environment.

The inceptor processor <NUM> may retrieve, identify, or otherwise receive a set of command signals from at least one of the inceptors <NUM> to control navigation of the vehicle <NUM> through the environment. In some embodiments, the inceptor processor <NUM> may monitor for the set of command signals from the one or more inceptors <NUM>. The set of command signals may be generated or derived from at least one input acquired via one or more of the inceptors <NUM>. The set of command signals may be generated by the inceptors <NUM> by converting the input received from an operator of the air vehicle <NUM>. Upon generation, the inceptors <NUM> may convey or send the set of commands to the flight control computing system <NUM>, and the inceptor processor <NUM> in turn may detect the set of command signals. The set of command signals may be to set or adjust the velocity (e.g., longitudinal, lateral, and vertical velocities), the acceleration (e.g., longitudinal, lateral, and vertical accelerations), and the orientation (e.g., roll, pitch, and yaw rates) for navigation of the air vehicle <NUM>. The set of commands may include a set of corresponding values to apply to set, configure, or modify the functioning of the navigation components <NUM>.

With the identification, the inceptor processor <NUM> may measure, determine, or otherwise identify a time point at which the set of commands are identified from the input. The time point may define or correspond to a point in time at which the set of commands are generated by the inceptor <NUM> or received at the flight control computing system <NUM>. In some embodiments, the inceptor processor <NUM> may parse the set of commands to extract or identify the time point (e.g., in the form of a timestamp) at which the set of commands were generated by the inceptor <NUM>. In some embodiments, the inceptor processor <NUM> (or the flight control computing system <NUM>) may maintain a timer to keep track of time. Using the timer, the inceptor processor <NUM> may identify the time point at which the set of commands are received from the inceptors <NUM>. In some embodiments, the inceptor processor <NUM> may store and maintain the time point on a storage of the flight control computing system <NUM>.

In some embodiments, the inceptor processor <NUM> may apply one or more filters to the set of command signals derived from the input acquired via the inceptors <NUM>. The filters may be part of pre-processing step applied to the set of commands prior to feeding forward to the remaining components of the flight control computing system <NUM> in accordance with the architecture <NUM>. In some embodiments, the inceptor processor <NUM> may use the filters to shape the overall set of command signals identified from the inceptors <NUM>. For example, the inceptor processor <NUM> may use notch filtering to minimize interaction or interference between the rotorcraft modes, and the cyclic and yaw control commands from the inceptors <NUM>. The inceptor processor <NUM> may also apply rate limiting to the collective set of command signals to suppress any values out-of-bounds from the expected rates. In applying, the inceptor processor <NUM> may feed and process the set of command signals through the filters to produce a filtered set of command signals. The inceptor processor <NUM> may convey, feed forward, or otherwise provide the set of commands signals to the path predictor <NUM>.

With receipt, the path predictor <NUM> may apply, feed, or otherwise input the set of command signals to the path prediction model <NUM> to generate one or more predicted paths <NUM>. In some embodiments, the path predictor <NUM> may input the set of command signals at a time interval to the path prediction model <NUM>. The time interval may specify or define an amount of time between each successive input of the set of command signals into the path prediction model <NUM>. The time interval may be defined in terms of cycles per second (or Hz), and may range between <NUM> to <NUM>.

In some embodiments, the path predictor <NUM> may retrieve, receive, or otherwise identify sensory data from the sensors on the air vehicle <NUM> to input into the path prediction model <NUM>. As discussed above, the sensory data may include, for example, a status, orientation, or position of the navigation components <NUM>. The sensory data may also include metrics associated with the navigation of the air vehicle <NUM> and the location data of the air vehicle <NUM>. With the identification, the path predictor <NUM> may apply, feed, or otherwise input the sensory data into the path prediction model <NUM>. The inputting may also be at the time interval.

The path prediction model <NUM> may include one or more functions for processing one or more of the command signals received from the inceptors <NUM>. In general, each function of the path prediction model <NUM> may have at least one input, one or more operands, and at least one output. Each input and output may correspond to at least one of the command signals. In some embodiments, the input or output may also correspond to at least one of the measurements in the sensory data. The inputs and the outputs for a given function may be related to one another via the operands. The operands may specify or define one or more operations (e.g., addition, subtraction, multiplication, division, integration, or Boolean operators) to be performed on the inputs to produce the outputs. For example, the path prediction model <NUM> may have one function for processing command signals related to acceleration and another function for processing command signals related to velocity. The details of the architecture for the path prediction model <NUM> are discussed herein below in conjunction with <FIG>.

From inputting, the path predictor <NUM> may process the set of command signals (and the sensory data) in accordance with the functions of the path prediction model <NUM> to produce, output, or otherwise generate the one or more predicted paths <NUM> over a time window. Each predicted path <NUM> may specify, define, or otherwise identify a route via which the air vehicle <NUM> is to navigate from a current point to an end point over the time window, given the set of command signals. The time window (sometimes referred herein as a prediction horizon or time horizon) for the predicted path <NUM> may be a relative to the time point at which the set of command signals was generated on the inceptors <NUM> or received at the flight control computing system <NUM>. The time window may range from <NUM> seconds to <NUM> seconds out from the time point at which the set of command signals is identified. The predicted path <NUM> may have a distance corresponding the time window and a current velocity of the air vehicle <NUM>.

The current point may correspond to or identify a present location of the air vehicle <NUM> in the environment. The end point may correspond to or identify a predicted location of the air vehicle <NUM> upon traversing the environment by the time window based on the set of command signals. In some embodiments, the route for the predicted path <NUM> may also include one or more consecutive waypoints from the current point to the end point over the time window. Each of the current point, the waypoints, and the end point may be defined in terms of geographic coordinates (e.g., GPS coordinates) and an altitude relative to the environment in which the air vehicle <NUM> is navigating. The altitude may identify the vertical distance between the air vehicle <NUM> and sea level of the environment. At each point, the predicted path <NUM> may also define or identify a predicted velocity, a predicted angle (e.g., orientation), or a range of predicted velocities or ranges, among parameters, along a pitch axis, a roll axis, or a yaw axis relative to the air vehicle <NUM>.

Referring to <FIG>, among others, depicted is a block diagram of a full-order architecture <NUM> for the path prediction model <NUM> in the system for controlling navigation. Under the full-order architecture <NUM>, the path prediction model <NUM> may include at least one command model <NUM>, at least one Euler transformation function <NUM>, at least one high-speed turn coordination model <NUM>, at least one acceleration model <NUM>, at least one velocity model <NUM>, at least one inverse model <NUM>, at least one feedback handler <NUM>, at least one mixing model <NUM>, at least one servos control unit <NUM>, and at least one vehicle dynamic model <NUM>, among others. The path predictor <NUM> may process the set of command signals generated by the inceptor <NUM> in accordance with the components and interconnections of the path prediction model <NUM> to generate the predicted path <NUM>. The set of commands at various points within the path prediction model <NUM> may, for example, be denoted with the following symbols:.

The command model <NUM> may calculate or generate rate command signals and angular acceleration command signals based on longitudinal cyclic, lateral cyclic, and pedal positions inputted via the inceptors <NUM>. The command model <NUM> may also dynamically shape the set of command signals, and may limit the acceleration command signals to reduce structural loads generated by command inputs. The input of the command model <NUM> may be from the inceptor processor <NUM>. The output of the command model <NUM> may be fed to the Euler transformation function <NUM>.

The Euler transformation function <NUM> may include a thetadot and psidot functions to allow the operator of the air vehicle <NUM> to command Euler rates when the air vehicle <NUM> is near wings level. The calculation of Euler rates may minimize undesirable inter-axis coupling of control inputs when the single axis responses are desirable. The thetadot function may command pitch attitude rate changes with longitudinal cyclic inputs in hover or lower-speed operations within small bank angles. The psidot function may command heading rate changes with pedal inputs within small pitch attitudes and bank angles at all speeds. The output of the Euler transformation function <NUM> may be fed to the high-speed turn coordination model <NUM>, the inverse model <NUM>, and the feedback handler <NUM>.

The high-speed turn coordination model <NUM> may minimize lateral acceleration and may maintain roll and pitch attitudes by commanding rates while in a banked turn at high speeds. The input of the high-speed turn coordination model <NUM> may be the output of the Euler transformation function <NUM>. The output of the high-speed turn coordination model <NUM> may be fed to the inverse model <NUM> and the feedback handler <NUM>.

The acceleration command model <NUM> may generate longitudinal and lateral acceleration command signals with cyclic inputs. The inputs for the acceleration command model <NUM> may be taken from the inceptor processor <NUM>. The outputs from the acceleration command model <NUM> may be passed to the velocity model <NUM>. The velocity model <NUM> may accept the acceleration command signals from the acceleration command model <NUM>, and may integrate the acceleration command signals to calculate the velocity command signals. The velocity model <NUM> may also calculate and provide velocity error as output to the feedback handler <NUM> to maintain the velocity of the air vehicle <NUM>.

The inverse model <NUM> (also referred herein sometimes as an inverse plant function) may accept the total command signals for pitch, roll, and yaw rates as inputs. The inverse model <NUM> may shape the command signals for the rate by a simplified inverse model for each axis of the dynamics of the air vehicle <NUM>. The inverse model <NUM> may calculate command signals for pitch, roll, and yaw rates to feed forward to generate responses approximating the command signals for the rates. The parameters for the inverse model <NUM> may be scheduled with airspeed to match the plant dynamics. The outputs of the inverse model <NUM> may be fed forward to the mixing model <NUM>.

The feedback handler <NUM> may compare the commanded altitude, rate, and acceleration signals in pitch, roll, and yaw axes with the sensed data. The error signals may be converted to control commands. The outputs of the feedback handler <NUM> may be conveyed to the mixing model <NUM>. The mixing model <NUM> (also referred herein sometimes as control mixing) may minimize off-axis cross-coupling. The mixing model <NUM> may combine the control command signals so that the responses remain on axis relative to the air vehicle <NUM>. The output of the mixing model <NUM> may be fed forward to the servos control unit <NUM>.

The servos control unit <NUM> may convert the control command signals calculated by other components in the path prediction model <NUM> to actuation signals to direct navigation components <NUM>. The servos control unit <NUM> may also use feedback from the navigation components <NUM> to set, update, or otherwise adjust the actuation signals to provide back to the navigation components <NUM>. In addition, the vehicle dynamic model <NUM> may keep track of various state variables characterizing the air vehicle <NUM>, such as rotor flapping angles, main rotor inflow, and tail rotor inflow, among others. The vehicle dynamic model <NUM> may adjust the control command signals based on a response of the navigation components <NUM> and other components of the air vehicle <NUM>. The vehicle dynamic model <NUM> may suppress or cancel measured aircraft dynamics (e.g., acquired via sensors onboard) with an inverse of the aircraft dynamics.

Under the full-order architecture <NUM>, the various components of the path prediction model <NUM> may be in total, linear order, including the initially configured inputs, outputs, and operands. At least some of the components in the path prediction model <NUM>, such as the inverse model <NUM>, the feedback handler <NUM>, the mixing model <NUM>, the servos control unit <NUM>, and the vehicle dynamic model <NUM>, among others may be approximated using a reduced order representation. The reduced order representation may lower the computational complexity of the functions specified by the components of the path prediction model <NUM>. Relative to the reduced order representation (e.g., discussed below), the full-order architecture <NUM> may rely on at least an order of magnitude more in the number of inputs to populate and generate the predicted paths <NUM>.

Referring to <FIG>, among others, depicted is a block diagram of a reduced-order architecture <NUM> for the path prediction model <NUM> in the system for controlling navigation. The path prediction model <NUM> under the reduced-order architecture <NUM> may include the components of the path prediction model <NUM> under the full-order architecture <NUM>. The difference from the full-order architecture <NUM> may be that in the reduced-order architecture <NUM>, at least some of the components may be approximated using order reduction. The path prediction model <NUM> may have at least one reduced-order closed-loop model <NUM>. The reduced-order closed-loop model <NUM> may approximate the behavior of at least some of the components of the path prediction model <NUM> under the full-order architecture <NUM>. The reduced-order closed-loop model <NUM> may substitute or replace the components of the path prediction model <NUM> whose behavior are approximate. For example, as depicted, the reduced-order closed-loop model <NUM> may approximate the behavior of the inverse model <NUM>, the feedback handler <NUM>, the mixing model <NUM>, the servos control unit <NUM>, and the vehicle dynamic model <NUM> and may substitute these components in the reduced-order architecture <NUM>.

The reduced-order closed-loop model <NUM> may have the inputs and outputs of the replaced components. For example, the reduced-order closed-loop model <NUM> may have the inputs and outputs of the inverse model <NUM>, the feedback handler <NUM>, the mixing model <NUM>, and the servos control unit <NUM>. The internal operands of the reduced-order closed-loop model <NUM> may be defined or configured using model order reduction (MOR) of the components of the path prediction model <NUM> to be approximate. The MOR techniques may include, for example, decomposition (e.g., proper orthogonal decomposition and proper generalized decomposition), reduced basis, balancing, operational based reduction, non-linear manifold, interpolation (e.g., matrix interpolation, transfer function interpolation, and piecewise interpolation), among others. In some embodiments, the reduced-order closed-loop model <NUM> may approximate the closed-loop dynamics by a set of command filters that have the same time-domain and frequency-domain characteristic (e.g. bandwidth and slew-rate and settling time) as the full order architecture <NUM>. With the reduced-order closed-loop model <NUM>, the computation complexity of the path prediction model <NUM> of the reduced-order architecture <NUM> may be less than the computational complexity of the path prediction model <NUM> of the full-order architecture <NUM>. In addition, the reduced-order architecture <NUM> may perform shaping and integration on acceleration and rate command signals to project or predicted position, velocity, and altitude signals to generate the predicted path <NUM>.

The path predictor <NUM> may process the set of command signals generated by the inceptor <NUM> in accordance with the components and interconnections of the path prediction model <NUM> including the reduced-order closed-loop model <NUM>. By processing with the reduced-order architecture <NUM> for the path prediction model <NUM>, the path predictor <NUM> may generate the predicted path <NUM>. The determination of the predicted path <NUM> using the reduced-order architecture <NUM> may be quicker relative to using the full-order architecture <NUM>, due to the lower computational complexity.

Referring to <FIG>, among others, depicted is a block diagram of an architecture <NUM> of inputs for the reduced-order closed-loop model <NUM> in the system <NUM> for controlling navigation. Under the architecture <NUM>, the path prediction model <NUM> may have one or more fade functions 405A-N (hereinafter generally referred to as fade functions <NUM>), at least one multiplier <NUM>, at least one gain scheduled linear model <NUM>, and at least one combiner <NUM>, among others. Each of the fade functions <NUM>, the multiplier <NUM>, the gain scheduled linear model <NUM>, and the combiner <NUM> may have outputs that are directly or indirectly fed as inputs into the reduced-order closed loop model <NUM> to generate the predicted path <NUM>.

The fade function <NUM> may reduce, lower, or otherwise attenuate the set of command signals to be inputted into the reduced-order closed-loop model <NUM> over the time window relative to the time point at which the set of command signals was generated at the inceptors <NUM>. In general, the attenuation defined by the fade function <NUM> may maintain the values for the set of command signals closer to the time point at which the command signals were received. The attention defined by the fade function <NUM> may gradually lower the values for the set of command signals further away from the time point, and may completely suppress or make null the value of the set of command signals beyond the time window. For example, as depicted, the fade function <NUM> may linearly taper values of the command signals received further away in the future relative to the time point until null at the end of the time window (labeled as "prediction horizon"). In some embodiments, the definition for the fade function <NUM> may differ depending on the type of command signal inputted. The output of the fade functions <NUM> may be fed as inputs to the reduced-order closed-loop model <NUM>.

The multiplier <NUM> may calculate, determine, or generate a product of two or more of the command signals. In some embodiments, the multiplier <NUM> may apply coefficients to the input command signals. The coefficients may differ among the types of command signals. The multiplier <NUM> may perform a time-series multiplication of the values of the inputted command signals. The output resultant generated by the multiplier <NUM> may include a product of the values at each time sample from the two or more command signals. The input to the multiplier <NUM> may include at least a subset of the command signals. The output of the multiplier <NUM> may be fed into the reduced-order closed-loop model <NUM> via one or more other components in the architecture <NUM>, such as at least one of the fade functions <NUM> and the combiner <NUM> as depicted.

The gain scheduled linear model <NUM> may calculate, determine, or otherwise generate at least one resultant based on at least a subset of the command signals. The resultant may define, identify, or include a simulated command signal corresponding to the input command signals. For example, as depicted, the gain scheduled linear model <NUM> may have a change in collective command signal (δcol,cmd) and a longitudinal velocity command signal (vxcmd) as inputs. Using the inputs, the gain scheduled linear model <NUM> may generate a simulated vertical acceleration for the command signal to provide as output. The output of the gain scheduled linear model <NUM> may be fed forward to the reduced-order closed-loop model <NUM>, via one or more other components of the input architecture <NUM>, such as at least one of the fade functions <NUM> and the combiner <NUM> as depicted.

The combiner <NUM> may calculate, determine, or generate a sum of the two or more inputs, such as outputs of other components in the architecture <NUM> (e.g., the multiplier <NUM> and the gain scheduled linear model <NUM> as depicted). In some embodiments, the combiner <NUM> may generated a weighted sum of the inputs. The weight may differ among the inputs. The output resultant generated by the combiner <NUM> may include a sum of the values at each time sample from the two or more command signals. The output of the combiner <NUM> may be fed into the reduced-order closed-loop model <NUM> via one or more other components in the architecture <NUM>, such as at least one of the fade functions <NUM> as depicted.

In feeding the inputs through the path prediction model <NUM>, the path predictor <NUM> may apply the components of the input architecture <NUM> to at least a subset of the command signals. For example, as depicted, the path predictor <NUM> may attenuate a roll rate command signal (Φ́cmd), a yaw rate command signal (φ́cmd), a longitudinal acceleration command signal (axcmd), a lateral acceleration command signal (aycmd), and a vertical acceleration command signal (azcmd) using the corresponding fade functions <NUM>. The output of each fade function <NUM> may include the corresponding command signal with the application of the attenuation over the time window. The path predictor <NUM> may feed forward the outputs from the fade functions <NUM> to the reduced-order closed-loop model <NUM>.

In conjunction, the path predictor <NUM> may apply the pitch rate command signal (θ́cmd) and the longitudinal velocity command signal (vxcmd) to the multiplier <NUM> to output a resultant product. The path predictor <NUM> may feed forward the resultant to the combiner <NUM>. Additionally, the path predictor <NUM> may input a commanded collective command signal (δcol,cmd) and the longitudinal velocity command signal (vxcmd) to the gain scheduled linear model <NUM> to calculate the simulated vertical acceleration for the command signal. The path predictor <NUM> may feed the output from the gain scheduled linear model <NUM> into the combiner <NUM>.

The path predictor <NUM> in turn may use the combiner <NUM> to process the outputs from the multiplier <NUM> and the gain scheduled linear model <NUM> to generate a resultant output. The path predictor <NUM> may feed the output from the combiner <NUM> to a corresponding fade function <NUM>. Concurrently, the path predictor <NUM> may feed the command signal specifying whether the turn coordination mode is enabled or disabled (tceng) directly into the reduced-order closed-loop model <NUM>. By applying the command signals to the path prediction model <NUM> in this manner, the path predictor <NUM> may generate the predicted path <NUM> for the navigation of the air vehicle <NUM>.

Under the reduced-order architecture <NUM>, various outputs can be computed thousands of time per control cycle with various input parameters (e.g., wind magnitude direction). Furthermore, the reduced-order architecture <NUM> may apply command model parameters at various fade rates for the inputs to obtain a set of trajectories satisfying the constraints given the current state of the air vehicle <NUM> and the input from the inceptor <NUM>. In contrast with the full order model <NUM>, the computational complexity may be lower. For example, the full order model <NUM> may rely on a complete vehicle dynamics (e.g., as simulated using the vehicle dynamic model <NUM>) to make various calculations, and may entail initialization in each prediction cycle. But certain state variables (e.g., rotor inflow and flapping angles for a helicopter) may not be measure and initialized at each instance. Due to the computation complexity, it may be difficult to use the full order model <NUM> for path prediction. The reduced-order architecture <NUM>, on the other hand, may be unencumbered by such reliance on complete vehicle dynamics, and may be used to generate the set of trajectories within constraints. In addition, the reduced-order closed-loop model <NUM> can be augmented with a covariance propagation model to determine the variance of the predicted trajectory over time. For example, closer to the air vehicle <NUM>, the variance of the predicted path may become small and the further in time, the covariance may become higher to account for uncertainty.

Referring back to <FIG>, the collision checker <NUM> may identify or determine whether at least one of the predicted paths <NUM> intersects with at least one obstacle in the environment within the time window. The performance of the determination may correspond to the condition check <NUM> within the architecture <NUM> for the flight control computing system <NUM>. In determining, the collision checker <NUM> may access or use a world model <NUM>. The world model <NUM> may define a terrain of the environment through which the air vehicle <NUM> is navigating, in terms of geographic coordinates (e.g., GPS coordinate). At each geographic coordinate, the world model <NUM> may identify various characteristics regarding the terrain, such as elevation (e.g., measured in metric or feet relative to sea level), terrain type (e.g., mountain, plain, river, lake, and sea), and an indication of occupation (e.g., presence of city, building, or other human settlement), among others. In some embodiments, the world model <NUM> may be stored and maintained on the storage of the flight control computing system <NUM>, using one or more data structures (e.g., array, matrix, table, linked list, table, and heap). In some embodiments, the world model <NUM> may be provided by a remote computing system to the flight control computing system <NUM> during the navigation. In some embodiments, the world model <NUM> may be generated by the flight control computing system <NUM> using the data about the environment from the sensors (e.g., LiDAR, RADAR, and camera).

In addition, the collision checker <NUM> may determine or identify the location of the air vehicle <NUM> in the environment from the world model <NUM>. The location of the air vehicle <NUM> may be defined in terms of geographic coordinates. In some embodiments, the collision checker <NUM> may invoke or use a GPS module in the flight control computing system <NUM> to identify the location of the air vehicle <NUM> (e.g., the GPS coordinates). The collision checker <NUM> may also determine or identify the altitude at which the air vehicle <NUM> is navigating from the sensors on the air vehicle <NUM>. At least one of the sensors may measure and provide the altitude of the air vehicle <NUM> within the environment. The altitude may, for example, identify a vertical distance between the air vehicle <NUM> and sea level.

Using the location of the air vehicle <NUM>, the collision checker <NUM> may extract, select, or otherwise identify at least a portion of the environment from the world model <NUM>. The portion may correspond to the environment from the world model <NUM> around the location of the air vehicle <NUM> by at least some distance (e.g., more than the distance of the predicted path <NUM>). The portion may be of any shape, such a rectangle, square, a pentagon, a hexagon, an ellipsis, or a circle, among others. The portion of the terrain of the environment may be used to check whether the predicted path <NUM> intersects with any obstacle in the terrain. In some embodiments, the collision checker <NUM> may otherwise identify the portion of the environment from the world model <NUM> at the altitude of the air vehicle <NUM>. The identified portion of the environment may correspond to the terrain having elevation matching the altitude of the vehicle <NUM>.

To determine, the collision checker <NUM> may check or compare the predicted path <NUM> for the navigation of the air vehicle <NUM> with the world model <NUM>. In comparing, the collision checker <NUM> may identify the points of the predicted path <NUM>. The points of the predicted path <NUM> may include the initial point, waypoints, and terminal point for navigating the air vehicle <NUM>, and may be defined in terms of geographic coordinates and altitude. For each point of the predicted path <NUM>, the collision checker <NUM> may determine or identify the elevation of the terrain at the point from the world model <NUM>. For example, for the geographic coordinates of a given point in the predicted path <NUM>, the collision checker <NUM> may identify the elevation of the terrain at the same geographic coordinates using the world model <NUM>. In some embodiments, the collision checker <NUM> may compare against the elevation of the terrain from the portion previously identified from the world model <NUM>.

With the identifications for each point of the predicted path <NUM>, the collision checker <NUM> may determine whether the altitude at the point of the predicted path <NUM> for the air vehicle <NUM> is less than or equal to the elevation of the terrain at the point. Any part of the terrain having an elevation that is more than or equal to the altitude of the air vehicle <NUM> at the corresponding point on the predicted path <NUM> may correspond an obstacle in the environment. When the altitude is greater than the elevation of the terrain over all the points of the predicted path <NUM>, the collision checker <NUM> may determine that the predicted path <NUM> does not intersect with any obstacles in the environment during the time window. The collision checker <NUM> may also identify the environment as free of obstacles to the air vehicle <NUM> along the predicted path <NUM>. The collision checker <NUM> may also pass, convey, or otherwise provide the set of command signals from the path predictor <NUM> to the component controller <NUM> to continue with the operator maneuver loop <NUM>.

When the altitude is less than or equal to the elevation of the terrain for at least one points, the collision checker <NUM> may determine that the predicted path <NUM> intersects with the obstacle in the environment during the time window for the predicted path <NUM>. The collision checker <NUM> may also identify the point of the predicted path <NUM> that has the altitude less than or equal to the elevation of the terrain. The collision checker <NUM> may identify the corresponding part of the terrain as the obstacle in the environment that intersects with the predicted path <NUM>. In addition, the collision checker <NUM> may also refrain from providing the set of command signals from the path predictor <NUM> to the component controller <NUM>. The collision checker <NUM> invoke the goal selector <NUM> to transition to the terrain avoidance loop <NUM>.

In some embodiments, the collision checker <NUM> may determine whether the altitude at the point is less than or equal to the elevation of the terrain by a clearance margin. The clearance margin may, for example, range between <NUM> to 100ft, between the air vehicle <NUM> and the terrain. When the altitude is greater than the elevation of the terrain over all the points of the predicted path <NUM> by at least the clearance margin, the collision checker <NUM> may determine that the predicted path <NUM> does not intersect with any obstacles in the environment during the time window. The collision checker <NUM> may also identify the environment as free of obstacles to the air vehicle <NUM> along the predicted path <NUM>. In addition, the collision checker <NUM> may also pass, convey, or otherwise provide the set of command signals from the path predictor <NUM> to the component controller <NUM> to continue with the operator maneuver loop <NUM>. In some embodiments, if the predicted path is determined to be free, the commands from the inceptor <NUM> may be fed by the inceptor processor <NUM> to the component controller <NUM>, without any input from the path predictor <NUM> or the collision checker <NUM>. The flight control computing system <NUM> may remain in the original manual flight mode.

On the contrary, when the altitude is less than or equal to the elevation of the terrain within the clearance margin for at least one points, the collision checker <NUM> may determine that the predicted path <NUM> intersects with the obstacle in the environment during the time window for the predicted path <NUM>. The collision checker <NUM> may also identify the point of the predicted path <NUM> that has the altitude less than or equal to the elevation of the terrain. The collision checker <NUM> may identify the corresponding part of the terrain as the obstacle in the environment that intersects with the predicted path <NUM>. The collision checker <NUM> may also refrain from providing the set of command signals from the path predictor <NUM> to the component controller <NUM>. The collision checker <NUM> may invoke the goal selector <NUM> to transition to the terrain avoidance loop <NUM>.

When the predicted path <NUM> is determined to not intersect, the component controller <NUM> may perform an action to direct the air vehicle <NUM> in accordance with the set of command signals. The set of command signals may correspond to command signals inputted via the inceptors <NUM>. The component controller <NUM> may apply the set of command signals to the corresponding navigation components <NUM> to navigate the air vehicle <NUM> along the predicted path <NUM>. In some embodiments, the component controller <NUM> may identify one or more of the navigation components <NUM> to which to apply the set of command signals. In applying, the component controller <NUM> may convert the set of command signals to actuator control signals. For instance, the component controller <NUM> may generate actuator control signals to control or adjust the elevator, rudder, aileron, and throttle in the navigation components <NUM> for the air vehicle <NUM>. The generation of the actuator control signals may be performed via a series of feedback control loops and functions by comparing the signal with the measurements regarding the navigation components <NUM> on the air vehicle <NUM>.

On the other hand, when the predicted path <NUM> is determined to intersect, the goal selector <NUM> may identify, determine, or otherwise generate one or more goal points 225A-N (hereinafter generally referred to goal points <NUM> or locations). The goal points <NUM> may correspond to locations to which to navigate the air vehicle <NUM> to avoid the obstacle in the environment. The generation of goal points <NUM> may factor in the location of the air vehicle <NUM> within the environment and the obstacle in the terrain as identified from the world model <NUM>. The generation of the goal points <NUM> may also depend on a mode of operation for the air vehicle <NUM>. The air vehicle <NUM> may have any number of modes of operation as defined by the speed (or velocity) of the air vehicle <NUM> while navigating through the environment. In some embodiments, the air vehicle <NUM> may have two modes of operation defined by a threshold speed. The threshold speed may delineate, identify, or otherwise define a value of the speed at which the air vehicle <NUM> is operating in one mode or another mode. For example, the air vehicle <NUM> may have a low-speed mode corresponding to when the speed of the air vehicle <NUM> lower than or equal to <NUM> knots and a high-speed mode corresponding to when the speed of the air vehicle <NUM> is greater than <NUM> knots.

In generating, the goal selector <NUM> may identify the mode of operation for the air vehicle <NUM> based on the speed (or velocity) of the air vehicle <NUM>. The goal selector <NUM> may identify the speed from the sensors on the air vehicle <NUM>. The goal selector <NUM> may compare the speed of the air vehicle <NUM> with the threshold speed for the modes of operation. Based on the comparison, the goal selector <NUM> may identify the mode of operation with the definition satisfying the identified speed. When the speed of the air vehicle <NUM> is determined to be greater than or equal to the threshold speed, the goal selector <NUM> may determine that the air vehicle <NUM> is operating in the high-speed mode. Conversely, when the speed of the air vehicle <NUM> is determined to be less than the threshold speed, the goal selector <NUM> may determine that the air vehicle <NUM> is operating in the low-speed mode.

If the air vehicle <NUM> is identified as operating in a high-speed mode, the goal selector <NUM> may generate a set of goal points <NUM> for the air vehicle <NUM> to evade the obstacle in the environment by at least a clearance distance. The clearance distance may correspond to a distance (e.g., vertical or horizontal) between the obstacle and the position of the air vehicle <NUM>, and may differ or be the same in value (e.g., between <NUM> to <NUM> ft) as the clearance margin discussed above. The set of goal points <NUM> may include an initial point, one or more waypoints, and a terminal point for navigating the air vehicle <NUM> to evade or avoid the obstacle by at least the clearance distance. Each of the goal points <NUM> may define or specify geographic coordinates (e.g., GPS coordinates), altitude, speed, acceleration, and orientation for the navigation of the air vehicle <NUM>. The set of goal points <NUM> may be over a time window wider than the time window for the predicted path <NUM>. For example, the time window for the set of goal points <NUM> may be <NUM> to <NUM> times longer than the time window for the predicted path <NUM>. In some embodiments, the goal selector <NUM> may determine each of the goal points <NUM> based on the terrain of the environment from the world model <NUM>. Examples of the set of goal points <NUM> generated when the air vehicle <NUM> is identified as operating in the high-speed mode are described herein below in conjunction with <FIG>.

Referring to <FIG>, among others, depicted is an example of goal point generation 500A for terrain obstacle avoidance under high-speed mode. In the depicted example, the path predictor <NUM> may have generated the predicted path <NUM> with a <NUM> second time window. The collision checker <NUM> may have determined that the predicted path <NUM> intersects with the terrain using data points 505A-N (hereinafter generally referred to as data points <NUM>) of the terrain map from the world model <NUM>. In turn, the goal selector <NUM> may generate the set of goal points <NUM> using an elevation of the highest obstacle <NUM> and a minimum ground clearance 515A (sometimes herein referred to as the clearance distance). The goal selector <NUM> may identify the elevation of the highest obstacle <NUM> from the data points <NUM> of the terrain map. Each of the goal points <NUM> may have a position above the elevation of the highest obstacle <NUM> by at least the minimum ground clearance 515A from the elevation of the highest obstacle <NUM>.

Referring to <FIG>, among others, depicted is an example of goal point generation 500B for terrain obstacle avoidance under high-speed mode. As with the previous example, in the depicted example, the path predictor <NUM> may have generated the predicted path <NUM> with a <NUM> second time window. The collision checker <NUM> may have determined that the predicted path <NUM> intersects with the terrain using data points <NUM> of the terrain map from the world model <NUM>. In turn, the goal selector <NUM> may generate the set of goal points <NUM> based on a current position or altitude of the air vehicle <NUM> and the minimum ground clearance 515B (sometimes herein referred to as the clearance distance). The goal selector <NUM> may identify the current altitude <NUM> of the air vehicle <NUM> from the sensors on board. The goal points <NUM> generated by the goal selector <NUM> may have an altitude of at least the current altitude <NUM>. If the current altitude <NUM> over an elevation of a data point <NUM> of the terrain map is less than the minimum ground clearance 515B, the goal selector <NUM> may set the goal point <NUM> (e.g., the goal point 225B) over the data point <NUM> to be at least the minimum ground clearance 515B over the elevation of the data point <NUM>. The last goal point <NUM> (e.g., the goal point 225C) may have the same altitude as the penultimate goal point <NUM> (e.g., goal point 225B) to minimize altitude changes therefrom.

Referring to <FIG>, among others, depicted is an example of goal point generation 500C for terrain obstacle avoidance under high-speed mode. As with the previous example, in the depicted example, the path predictor <NUM> may have generated the predicted path <NUM> with a <NUM> second time window. The collision checker <NUM> may have determined that the predicted path <NUM> intersects with the terrain using data points <NUM> of the terrain map from the world model <NUM>. In turn, the goal selector <NUM> may generate the set of goal points <NUM> to maintain the air vehicle <NUM> at the current altitude <NUM>. The goal selector <NUM> may identify the current altitude <NUM> of the air vehicle <NUM> from the sensors on board. Each of the goal points <NUM> generated by goal selector <NUM> may have an altitude corresponding to the current altitude of the air vehicle <NUM>. The goal points <NUM> may differ in geographic coordinates to avoid data points <NUM> of the terrain map with higher elevation than the current altitude <NUM>.

In contrast, if the air vehicle <NUM> is identified as operating in a low-speed mode, the goal selector <NUM> may generate at least one goal point <NUM> to hover the air vehicle <NUM> relative to the obstacle in the environment. In some embodiments, the goal selector <NUM> may generate the goal point <NUM> to hold the air vehicle <NUM> over the obstacle by at least a clearance distance. The clearance distance may correspond to a distance (e.g., vertical or horizontal) between the obstacle and the position of the air vehicle <NUM>, and may differ or be the same in value (e.g., between <NUM> to <NUM> ft) as the clearance margin discussed above. The goal point <NUM> may include at least one location (or point) for navigation the air vehicle <NUM> to hover relative to the obstacle in the environment. The goal point <NUM> may define or specify geographic coordinates (e.g., GPS coordinates), altitude, and orientation for the navigation of the air vehicle <NUM>. The goal point <NUM> may be over a time window wider than the time window for the predicted path <NUM>. For example, the time window for the set of goal points <NUM> may be <NUM> to <NUM> times longer than the time window for the predicted path <NUM>. In some embodiments, the goal selector <NUM> may determine the goal point <NUM> based on the terrain of the environment from the world model <NUM>. Examples of the goal points <NUM> generated when the air vehicle <NUM> is identified as operating in the low-speed mode are described herein below in conjunction with <FIG>.

Referring to <FIG>, among others, depicted is an example of goal point generation 600A for terrain obstacle avoidance under low-speed mode. In the depicted example, the path predictor <NUM> may have generated the predicted path <NUM> over a time window. The collision checker <NUM> may have determined that the predicted path <NUM> intersects with a terrain <NUM> at a predicted collision point 610A. The goal selector <NUM> may generate one or more goal points <NUM> to effectuate an avoidance trajectory <NUM>. The goal selector <NUM> may use the elevation of the terrain <NUM> at the predicted collision point 610A to determine the goal points <NUM>. At least one goal point <NUM> may be to hover the air vehicle <NUM> over the terrain <NUM> at the predicted collision point 610A by at least a minimum clearance 615A (sometimes herein referred to as a clearance distance).

Referring to <FIG>, among others, depicted is an example of goal point generation 600B for terrain obstacle avoidance under low-speed mode. In the depicted example, the path predictor <NUM> may have generated the predicted path <NUM> over a time window. The collision checker <NUM> may have determined that the predicted path <NUM> intersects with a terrain <NUM> at a predicted collision point 610B. The goal selector <NUM> in turn can generate the goal point <NUM> to hold the air vehicle <NUM> relative to the terrain <NUM> by at least a minimum clearance 615B (sometimes herein referred to as a clearance distance). The goal selector <NUM> may use the elevation of the terrain <NUM> at the prediction collision point 610B to determine the goal point <NUM> by at least the minimum clearance 615B.

Referring to <FIG>, among others, depicted is an example of goal point generation 600C for terrain obstacle avoidance under low-speed mode. In the depicted example, the path predictor <NUM> may have generated the predicted path <NUM> over a time window. The collision checker <NUM> may have determined that the predicted path <NUM> intersects with a terrain <NUM> at a predicted collision point 610C. The goal selector <NUM> in turn can generate the goal point <NUM> to hold the air vehicle <NUM> relative to the terrain <NUM> at the current location of the air vehicle <NUM>.

In some embodiments, the goal selector <NUM> may determine or generate a potential field map using the world model <NUM> for the environment. In some embodiments, the potential field map may be generated in accordance with a distance transform (e.g., Euclidean distance transformation (EDT)). The potential field map may be used by the goal selector <NUM> to generate the goal points <NUM> for terrain obstacle avoidance. The generation of the potential field map may be based on the identified portion of the environment, the location of the air vehicle <NUM>, and the points of the predicted path <NUM>. The potential field map may be defined in terms of geographic coordinates, and may identify whether the portion of the environment is occupied or free at a particular altitude (e.g., the altitude of the air vehicle <NUM>) along the predicted path <NUM>. The potential field map may identify that a geographic coordinate is occupied when the terrain has the elevation at least within a clearance margin of a particular altitude. To identify, the goal selector <NUM> may convert a distance transformation to the potential field map, and may select goal points <NUM> at local extrema (e.g., minima) of the potential field map. Conversely, the potential field map may identify that a geographic coordinate is free when the terrain has the elevation below the clearance margin of a particular altitude. Examples of the potential field map are shown and described herein on <FIG>.

Referring to <FIG>, depicted is a diagram of a slice of a terrain map <NUM> used in determining terrain obstacle avoidance in the system <NUM> for controlling navigation. The terrain map <NUM> may be generated by the goal selector <NUM> from at least a portion of the terrain from world model <NUM>. The terrain map <NUM> may have at least one free region <NUM> and at least one occupied region <NUM>. The free region <NUM> may correspond to terrain having elevation below the clearance margin of the altitude of the air vehicle <NUM>. The occupied region <NUM> may correspond to terrain having elevation within the clearance margin of the altitude of the air vehicle <NUM>. In some embodiments, the terrain map <NUM> may be two-dimensional (e.g., as depicted) or three-dimensional.

Referring to <FIG>, depicted is a diagram of a potential field map <NUM> used in determining terrain obstacle avoidance in the system <NUM> for controlling navigation. In context, the goal selector <NUM> may generate the potential field map <NUM> using the terrain map <NUM> (e.g., via EDT). The potential field map <NUM> may be generated by the goal selector <NUM> from at least a portion of the terrain from the world model <NUM>. The potential field map <NUM> may be two-dimensional (e.g., as depicted) or three-dimensional. The potential field map <NUM> may have at least one free region <NUM> and at least one occupied region <NUM>. The free region <NUM> may correspond to terrain having elevation below the clearance margin of the altitude of the air vehicle <NUM>. The free region <NUM> may also indicate an amount of difference between the clearance margin of the altitude of the air vehicle <NUM> and the elevation of the terrain in the environment. The occupied region <NUM> may correspond to terrain having elevation within the clearance margin of the altitude of the air vehicle <NUM>. At any given point in that slice of the potential field map <NUM>, the potential field map may indicate distance to the nearest obstacle (e.g., using a gradient map). In the potential field map <NUM>, the darker the area, the closer the obstacle may be, whereas the lighter the area, the farther the obstacle may be. In some embodiments, the goal selector <NUM> may use the potential field map <NUM> to assign the goal points <NUM> over the terrain, and calculate the clearance to obstacles in the terrain.

Using the potential field map (e.g., the potential field map <NUM> or <NUM>), the goal selector <NUM> may generate the goal points <NUM>. From the potential field map, the goal selector <NUM> may identify a free region (e.g., the free region <NUM> or <NUM>) and an occupied region (e.g., the occupied region <NUM> or <NUM>) in the terrain of the environment. The goal selector <NUM> may assign the goal points <NUM> within the free region to avoid the occupied region in the environment. The goal points <NUM> may have geographic coordinates and altitudes as identified by the potential field map. In some embodiments, the goal selector <NUM> may use multiple potential field maps to determine the goal points <NUM>. Each potential field map may be for a corresponding altitude. Within each potential field map, the goal selector <NUM> may identify the free region and the occupied region. The goal selector <NUM> may assign the goal points <NUM> within the free regions to avoid the occupied region at the corresponding altitudes. The set of goal points <NUM> generated by the goal selector <NUM> may have different altitudes.

Referring back to <FIG>, the motion planner <NUM> may determine or generate a set of waypoints to navigate or direct the air vehicle <NUM> along the goal points <NUM> through the environment. The motion planner <NUM> may apply or otherwise use any motion planning algorithm to determine the waypoints. The motion planning algorithm may include, for example, a search-based planner (e.g., A* or D*), a sample-based planner (e.g., a rapidly-exploring random tree (RRT)), or model predictive control (MPC), among others. The waypoints may be along a terrain avoidance trajectory (e.g., as defined by the goal points <NUM>) given the obstacle terrain environment and the constraints on the air vehicle <NUM> (e.g., a maximum turn rate). In some embodiments, the motion planner <NUM> may determine the set of waypoints for the set of goal point <NUM> to direct the air vehicle <NUM> to the goal point <NUM>.

In some embodiments, the motion planner <NUM> may generate a set of command signals to carry out the terrain avoidance trajectory, when operating in an autonomous flight mode. The set of command signals may be to set or adjust the velocity (e.g., longitudinal, lateral, and vertical velocities), the acceleration (e.g., longitudinal, lateral, and vertical accelerations), and the orientation (e.g., roll, pitch, and yaw rates) at each waypoint for navigation of the air vehicle <NUM>. The set of command signals may include a set of corresponding values to apply to set, configure, or modify the functioning of the navigation components <NUM>. In some embodiments, the motion planner <NUM> may proceed to send, convey, or provide the set of command signals to the component controller <NUM>, without any corrective input from the operator of the air vehicle <NUM>. The motion planner <NUM> may switch the air vehicle <NUM> from a manual flight mode to an autonomy mode to the navigate the air vehicle <NUM> along the goal points <NUM>. Under the autonomy mode, the air vehicle <NUM> may be directed along the goal points <NUM> to avoid the obstacle without any additional input from the operator.

In some embodiments, the motion planner <NUM> may present, display, or otherwise provide an output to an operator of the air vehicle <NUM> to navigate the air vehicle <NUM> along the one or more goal points <NUM> to avoid the obstacle in the environment. The motion planner <NUM> may present the output through the inceptors <NUM> or the interface <NUM> (e.g., a visual display in the air vehicle <NUM>). The output may be in any modality, such as a visual cue (e.g., a graphical user interface such as a prompt), an audio cue (e.g., a sound prompting terrain avoidance), or a tactile cue (e.g., haptic feedback prompting terrain avoidance). Upon providing the output, the motion planner <NUM> may monitor for an interaction <NUM> with the inceptors <NUM> or the interface <NUM>. The interaction <NUM> may include tactile input (e.g., acquired via a joystick, pedal, buttons, keyboard, or mouse), voice command (e.g., acquired via a microphone), or visual gesture (e.g., acquired via a camera), among others. The operator may accept or decline to direct the air vehicle <NUM> for an obstacle avoidance measure via the goal points <NUM>, and the interaction <NUM> may indicate one of acceptance or rejection of the obstacle avoidance measure. In some embodiments, the motion planner <NUM> may determine acceptance or declination based on interaction <NUM> inputted via the inceptors <NUM>. For example, when commands inputted via the inceptors <NUM> result in the predicted paths <NUM> that are clear from the terrain for sustained period of time (e.g., <NUM> to <NUM> seconds out), the motion planner <NUM> may determine that the input corresponds to a decline to the measure, without interaction with interface <NUM>.

When the interaction <NUM> indicates that the operator declines the measure, the motion planner <NUM> may pass, convey, or otherwise send the original set of command signals to the component controller <NUM>. By conveying the original set of command signals, the motion planner <NUM> may also invoke the operator maneuver loop <NUM> of the architecture <NUM> for the flight control computing system <NUM>. The operations of the flight control computing system <NUM> may be in accordance with the operator maneuver loop <NUM> as discussed above. Otherwise, when the interaction <NUM> indicates that the operator accepts the measure, the motion planner <NUM> may pass, convey, or otherwise send the set of waypoints for the terrain avoidance trajectory to direct the air vehicle <NUM> along the goal points <NUM> in the environment. The motion planner <NUM> may also continue along the terrain avoidance loop <NUM> of the flight control computing system <NUM>.

The component controller <NUM> may perform an action to direct the air vehicle <NUM> along the one or more goal points <NUM> to avoid the obstacle. The component controller <NUM> may perform the action in accordance with the set of waypoints generated by the motion planner <NUM> to carry out the goal points <NUM>. In some embodiments, the component controller <NUM> may generate a set of command signals (e.g., as discussed above) based on the waypoints generated by the motion planner <NUM> to perform the action in carrying out the goal points <NUM>. The functionality of the component controller <NUM> with respect to the set of command signals for the goal points <NUM> may be similar to the functionality of the component controller <NUM> as with the predicted path <NUM> detailed above. In some embodiments, the component control <NUM> may perform the action to direct the air vehicle <NUM> along the one or more goal points <NUM> avoid the obstacle, upon switching from a manual flight mode (sometimes herein referred to as a hand flying mode) to the autonomy mode. In performing the action, the component controller <NUM> may convert the set of waypoints to actuator control signals to control the navigation components <NUM>.

In this manner, using the reduced-order closed-loop model <NUM>, the flight control computing system <NUM> may be able to more quickly generate predicted paths <NUM> using the command signals inputted via the inceptors <NUM>, relative to the full-order architecture <NUM>. Furthermore, because of this, the outputted predicted paths <NUM> may be suitable for use for a terrain obstacle avoidance. The flight control computing system <NUM> may determine whether the predicted path <NUM> that the air vehicle <NUM> is navigating along intersects with the obstacle in the environment. In this manner, the utility of the flight control computing system <NUM> may be further expanded to trajectory prediction and the obstacle avoidance, thereby increasing the odds of accomplishing the mission objectives of the flight.

<FIG> illustrates a flow diagram of a process <NUM> of controlling navigation. The process <NUM> may be performed by or implemented using any of the components detailed above with respect to FIGs. <NUM>-7C or with the components described in <FIG>. Under the process <NUM>, a computing system may receive pilot inceptor commands (<NUM>). The computing system may perform fly-by-wire using a flight control computer (<NUM>). The computing system may perform trajectory prediction with a <NUM> second time window (<NUM>). The computing system may determine check for a collision against a world model (<NUM>). If there are no predicted collisions with an obstacle occupying the terrain, the computing system may repeat from step (<NUM>). Otherwise, if there is a predicted collision with an obstacle occupying the terrain, the computing system may determine whether the air vehicle is operating in a high-speed mode (<NUM>).

Continuing on, when the air vehicle is determined to be not operating in the high-speed mode, the computing system may use low-speed goal point generation (<NUM>). Conversely, when the air vehicle is determined to be operating in the high-speed mode, the computing system may use high-speed goal point generation (<NUM>). The computing system may invoke a local planner to generate avoidance path to goal points (<NUM>). The computing system may determine whether an acceptance or rejection of the path is indicated via a pilot interface or an interface (<NUM>). If the path is rejected, the computing system may repeat the fly-by-wire controls from step (<NUM>). Otherwise, if the avoidance path is accepted, the computing system may use the local planner command to flight control computer (<NUM>). The computing system may complete or abort the trajectory (<NUM>), and then repeat the fly-by-wire controls from step (<NUM>).

<FIG> illustrates a flow diagram of a method <NUM> of controlling navigation of vehicles. The method <NUM> may be performed by or implemented using any of the components detailed above with respect to FIGs. <NUM>-7C or with the components described in <FIG>. Under the method <NUM>, a computing system (e.g., a flight control computing system <NUM>) may receive command signals from inceptors (e.g., the inceptors <NUM>) (<NUM>). The command signals may be to set or adjust the velocity (e.g., longitudinal, lateral, and vertical velocities), the acceleration (e.g., longitudinal, lateral, and vertical accelerations), and the orientation (e.g., roll, pitch, and yaw rates) for navigation of an aircraft (e.g., the air vehicle <NUM>). The computing system may control navigation components (e.g., the navigation components <NUM>) (<NUM>). The computing system may convert the received command signals to actuate control signals to apply to the navigation components.

The computing system may attenuate command signals using fade function (e.g., the fade function <NUM>) (<NUM>). The fade function may be applied to at least a subset of the command signals, and may reduce a value or amplitude of a corresponding command signal over a prediction horizon relative a time point at which the command signal was received. The computing system may apply the command signals to a model (e.g., the path prediction model <NUM>) to generate a predicted path (e.g., the predicted path <NUM>) (<NUM>). The model may have one or more functions, such as a reduced-order closed loop model (e.g., the reduced-order closed-loop model <NUM>). The predicted path may specify a route via which the aircraft is to navigate from a current location to another point forward in time over the prediction horizon.

The computing system may determine whether the predicted path intersects with an obstacle (<NUM>). To determine, the computing system may compare the predicted path with a terrain map from a world model (e.g., the world model <NUM>). The predicted path may have one or more points defined in terms of geographic coordinates and altitude for the aircraft. For each point in the predicted path, the computing system may check the altitude for the aircraft against the elevation of the terrain at the corresponding geographic coordinate. If the elevation is greater than the altitude, the computing system may determine that the predicted path intersects. Conversely, if the elevation is less than the altitude, the computing system may determine that predicted path does not intersect. If the predicted path is determined to not intersect with the obstacle, the computing system may repeat from step (<NUM>).

Otherwise, if the predicted path is determined to intersect with the obstacle, the computing system may identify a mode of operation (<NUM>). The mode of operation may include a low-speed mode and a high-speed mode. The computing system may identify a speed of the aircraft. The computing system may determine whether the mode of operation is a high-speed mode or a low-speed mode (<NUM>). If the speed is less than a threshold, the computing system may determine that the aircraft is operating in a low-speed mode. Otherwise, the computing system may determine that the aircraft is operating in a high-speed mode.

When in the low-speed mode, the computing system may select a hover point (<NUM>). The computing system may generate a goal point (e.g., the goal point <NUM> from examples 600A-C) to hover the aircraft relative to the obstacle in the terrain by at least a minimum clearance distance (e.g., the minimum clearance 625A or 625B). When in the high-speed mode, the computing system may select an avoidance path (<NUM>). The avoidance path may be formed by a set of goal points (e.g., the goal points <NUM> from examples 500A-C). The path may be to guide the aircraft through the environment to avoid the obstacle.

The computing system may provide output for obstacle avoidance (<NUM>). The output may prompt an operator of the aircraft to accept or reject the obstacle avoidance measure to direct the aircraft. The output may provide terrain rendering and aircraft location for situational awareness. Combining with visual and verbal directional cue, the operator may make decision whether to hand fly the avoidance path or allow the autonomous system to take control. The computing system may determine whether the obstacle avoidance is accepted (<NUM>). The computing system may monitor for operator input indicating acceptance or rejection of the obstacle avoidance measure. When the input indicates acceptance, the computing system may determine that the operator accepts the avoidance measure. Otherwise, when the input indicates rejection, the computing system may determine that the operator has rejected the avoidance measure.

If the avoidance is accepted, the computing system may set the new trajectory (<NUM>). The computing system may generate a new set of command signals to effectuate the terrain obstacle avoidance using the goal points. The computing system may also switch from a manual flight mode to autonomy mode, without any further input from the operator. In contrast, if the avoidance is not accepted, the computing system may maintain the trajectory (<NUM>). The computing system may use the original command signals to direct navigation. The computing system may also keep the aircraft in the manual flight mode.

Referring to <FIG>, depicted is a block diagram of an example computer system <NUM>. The computer system or computing device <NUM> can include or be used to implement the system <NUM>, or its components such as the flight control computing system <NUM> (including the inceptor processor <NUM>, the path predictor <NUM>, the collision checker <NUM>, the goal selector <NUM>, the motion planner <NUM>, the component controller <NUM>, and the path prediction model <NUM>), and the interface <NUM>, among others. The computing system <NUM> includes at least one bus <NUM> or other communication component for communicating information and at least one processor <NUM> or processing circuit coupled to the bus <NUM> for processing information. The computing system <NUM> can also include one or more processors <NUM> or processing circuits coupled to the bus for processing information. The computing system <NUM> also includes at least one main memory <NUM>, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus <NUM> for storing information, and instructions to be executed by the processor <NUM>. The computing system <NUM> may further include at least one read only memory (ROM) <NUM> or other static storage device coupled to the bus <NUM> for storing static information and instructions for the processor <NUM>. A storage device <NUM>, such as a solid state device, magnetic disk or optical disk, can be coupled to the bus <NUM> to persistently store information and instructions.

The computing system <NUM> may be coupled via the bus <NUM> to a display <NUM>, such as a liquid crystal display, or active matrix display, for displaying information to a user such as an administrator of the data processing system. An input device <NUM>, such as a keyboard or voice interface may be coupled to the bus <NUM> for communicating information and commands to the processor <NUM>. The input device <NUM> can include a touch screen display <NUM>. The input device <NUM> can also include a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor <NUM> and for controlling cursor movement on the display <NUM>. The display <NUM> can be part of a component of <FIG>, such as the interface <NUM>.

Some of the description herein emphasizes the structural independence of the aspects of the system components illustrates one grouping of operations and responsibilities of these system components. Other groupings that execute similar overall operations are understood to be within the scope of the present application. Modules can be implemented in hardware or as computer instructions on a non-transient computer readable storage medium, and modules can be distributed across various hardware- or computer-based components.

The systems described above can provide multiple ones of any or each of those components and these components can be provided on either a standalone system or on multiple instantiation in a distributed system. In addition, the systems and methods described above can be provided as one or more computer-readable programs or executable instructions embodied on or in one or more articles of manufacture. The article of manufacture can be cloud storage, a hard disk, a CD-ROM, a flash memory card, a PROM, a RAM, a ROM, or a magnetic tape. In general, the computer-readable programs can be implemented in any programming language, such as LISP, PERL, C, C++, C#, PROLOG, or in any byte code language such as JAVA. The software programs or executable instructions can be stored on or in one or more articles of manufacture as object code.

Example and non-limiting module implementation elements include sensors providing any value determined herein, sensors providing any value that is a precursor to a value determined herein, datalink or network hardware including communication chips, oscillating crystals, communication links, cables, twisted pair wiring, coaxial wiring, shielded wiring, transmitters, receivers, or transceivers, logic circuits, hard-wired logic circuits, reconfigurable logic circuits in a particular non-transient state configured according to the module specification, any actuator including at least an electrical, hydraulic, or pneumatic actuator, a solenoid, an opamp, analog control elements (springs, filters, integrators, adders, dividers, gain elements), or digital control elements.

The subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. The subject matter described in this specification can be implemented as one or more computer programs, e.g., one or more circuits of computer program instructions, encoded on one or more computer storage media for execution by, or to control the operation of, data processing apparatuses. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. While a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate components or media (e.g., multiple CDs, disks, or other storage devices include cloud storage).

The terms "computing device", "component" or "data processing apparatus" or the like encompass various apparatuses, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations of the foregoing. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing infrastructures.

A computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program can correspond to a file in a file system. A computer program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).

The processes and logic flows can also be performed by, and apparatuses can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Devices suitable for storing computer program instructions and data can include non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.

The subject matter described herein can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described in this specification, or a combination of one or more such back end, middleware, or front end components.

Having now described some illustrative implementations, it is apparent that the foregoing is illustrative and not limiting, having been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts and those elements may be combined in other ways to accomplish the same objectives. Acts, elements and features discussed in connection with one implementation are not intended to be excluded from a similar role in other implementations or implementations.

Any implementation disclosed herein may be combined with any other implementation or embodiment, and references to "an implementation," "some implementations," "one implementation" or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the implementation may be included in at least one implementation or embodiment. Such terms as used herein are not necessarily all referring to the same implementation. Any implementation may be combined with any other implementation, inclusively or exclusively, in any manner consistent with the aspects and implementations disclosed herein.

For example, a reference to "at least one of 'A' and 'B‴ can include only 'A', only 'B', as well as both 'A' and 'B'. Such references used in conjunction with "comprising" or other open terminology can include additional items.

Modifications of described elements and acts such as variations in sizes, dimensions, structures, shapes and proportions of the various elements, values of parameters, mounting arrangements, use of materials, colors, orientations can occur without materially departing from the teachings and advantages of the subject matter disclosed herein. For example, elements shown as integrally formed can be constructed of multiple parts or elements, the position of elements can be reversed or otherwise varied, and the nature or number of discrete elements or positions can be altered or varied. Other substitutions, modifications, changes and omissions can also be made in the design, operating conditions and arrangement of the disclosed elements and operations without departing from the scope of the claims.

The systems and methods described herein may be embodied in other specific forms without departing from the scope of the claims. Scope of the systems and methods described herein is thus indicated by the appended claims.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of the claims, but rather as descriptions of features specific to particular embodiments of particular aspects. Certain features described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products.

Claim 1:
A method of controlling an aircraft (<NUM>), comprising:
receiving, by a computing system (<NUM>) on the aircraft, an input at a time point to control navigation of the aircraft (<NUM>) through an environment;
deriving, by the computing system (<NUM>), a first plurality of command signals from the input at the time point to control navigation of the aircraft (<NUM>) through the environment;
characterized by
attenuating, by the computing system (<NUM>), the first plurality of command signals using a fade function (<NUM>) to gradually lower values of the first plurality of command signals further away from the time point over a time window, the time window relative to the time point to generate a second plurality of command signals;
inputting, by the computing system (<NUM>), the second plurality of command signals to a reduced order model (<NUM>) that approximates a full order architecture (<NUM>) to generate one or more predicted paths (<NUM>) for the aircraft (<NUM>) through the environment over the time window;
determining, by the computing system (<NUM>), that at least one predicted path (<NUM>) of the one or more predicted paths intersects with an obstacle in the environment during the time window;
generating, by the computing system (<NUM>), a location to which to navigate the aircraft (<NUM>) to avoid the obstacle responsive to determining that the at least one predicted path (<NUM>) intersects with the obstacle; and
performing, by the computing system (<NUM>), an action to direct the aircraft (<NUM>) to the location.