Vehicle control system including related methods and components

[0001] The present application is based on and claims the benefit of U.S. provisional patent application Ser. No. 60/480,192, filed Jun. 20, 2003, the content of which is hereby incorporated by reference in its entirety.

[0002] The present invention relates to a system utilized to control a vehicle. More particularly, the present invention pertains to a variable autonomy control system that enables a human to manage and operate a vehicle through interaction with a human-system interface.

[0003] Vehicle control systems are well known in the art, one known example being a control system that enables a human operator to remotely manage and control an unmanned vehicle. In one known application, an operator remotely controls an unmanned aerial vehicle (UAV) through a human-system interface. The operator typically controls details related to payload, mission and/or flight characteristics of the unmanned aircraft.

[0004] The development of practical applications for UAV technology has been hindered by an absence of a well-integrated control and guidance system. Potential applications for UAV's include border patrol, traffic monitoring, hazardous area investigation, atmospheric sampling or even motion picture filming. All of these and other UAV applications would benefit from a control system that enables a person with minimal aviation experience or manual skill to operate the vehicle. With presently known systems, the operator is rarely able to focus on payload or mission operation because he or she is consumed with the significant responsibilities associated with aircraft piloting.

[0005] In order to be truly versatile, UAV control systems should be comfortably usable by individuals with training that is focused on the requirements of a given mission or on the usability of a payload, rather than on the aviation of the air vehicle. In many cases, present systems require an individual with pilot training to engage a control system and manage mission, payload, and aviation functions simultaneously. It is not common for known control systems to be configured for the support of intuitive high level commands such as “go left”, “go right”, “take off”, “land”, “climb”, or “dive”. It is instead more typical that known control systems require low-level stick-and-rudder commands from the operator. Thus, there is a need for a control system that supports integration of intuitive, mission-level remote commands into a UAV guidance system, thereby significantly reducing the work load on a human operator as it pertains to vehicle aviation.

[0006] Known control systems are generally not configured to support multiple levels of autonomous operation. In fact, few systems even offer autonomous or semi-autonomous mission capability packaged with an ability to remotely interrupt the mission. Thus, for known systems, the workload of the operator is generally too great to enable him or her to fly multiple UAV's from a single ground control station, which is an appealing possibility. Thus, there is a need for a flexible vehicle control and management concept that will operate even when responding to remote intuitive commands such that one person can operate multiple vehicles from the same control station.

[0007] Known UAV control systems typically offer limited real-time control capability or they require management by rated pilots. It is known for systems to have a capability to automatically follow pre-planned mission routes. However, it is common that real-world missions fail to go exactly as planned. For example, time-critical targets or surveillance objectives can pop up during the mission; traffic conflicts with manned aircraft can occur; clouds can get in the way of sensors (e.g., EO/IR sensors); or intelligent and devious adversaries can make target location and identification difficult. Real-time control is required to deviate from the planned route to find and identify new targets; to maneuver UAV's to avoid traffic; to fly under the weather; or to get better line-of-sight-angles. Skilled pilots can maneuver aircraft, but then an additional operator is typically necessary to manage sensors and/or the dynamic mission.

[0008] While commercialized products such as video games and CAD utilities now provide an excellent model for human interfaces, such interfaces have generally not been completely integrated into an actual vehicle control system. In fact, very few known UAV autopilot systems are readily compatible with known Commercial Off-The-Shelf (COTS) hardware. This is unfortunate because it is not uncommon for non-pilot trained individuals to be pre-equipped with a familiarity with such hardware that includes standard joysticks, track-balls, lap-top computers, virtual reality head mounted displays and glove input devices.

[0009] Known vehicle control systems generally do not include an operational mode that enables an operator to focus his or her attention on a tactical situation display (e.g., images transmitted from an onboard sensor) rather than providing directional commands based primarily on a control interface. Such a control mode has many potential advantageous applications, for example, an operator can command the scope of the vehicle's on-board sensor to survey a battle field (or other topographical region) while the vehicle autonomously commands a flight profile that is slaved to the operator's sensor line-of-sight commands. There is a need for an integrated guidance solution that adapts to such a mode of control.

[0010] Advances in virtual reality simulation graphic display technology have made the concept of a virtual reality interface to real-time systems feasible. Already used by surgeons in the medical community, the use of virtual reality, such as Telepresence or Mixed Reality systems, in the context of UAV control is now feasible but generally unknown. Thus, there is a need for a control system that provides an operator with functionality that takes advantage of this new technology.

[0011] Finally, many known control systems are not adaptable to on-going command-and-control software development efforts. For example, for military applications, it is desirable that a control system be equipped to operate within the advanced Command Control Communication Computers and Intelligence (C4I) infrastructure and interface with associated Common Ground Control Stations such as the Joint STARS Common Ground Station. It is desirable that guidance software have the capability not only to respond to the command interface, but also an ability to be expanded modularly as new capabilities are desired, such that expansions can be accomplished without significant changes in the interface.

[0012] Embodiments of the present invention pertain to a vehicle control system that includes an integrated guidance design and systems engineering approach that enables a system having a modular core structure. The core structure enables the control system to be conveniently upgraded or updated. For example, the control system can be easily extended to accommodate increasing and/or additional guidance, payload or other technology. Further, the core structure enables the system to be efficiently adapted for various manned and/or unmanned vehicles.

[0013] Embodiments of the present invention also pertain to a vehicle control system and related sub-components that together provide an operator with a plurality of specific modes of operation, wherein each mode of operation incorporates a different level of autonomous control. Through a control user interface, an operator can smoothly switch between modes of operation even after vehicle deployment. Specialized autopilot system components and methods are employed to ensure seamless transitions between operational modes. Empowered by the multi-modal control system, an operator can even manage multiple vehicles simultaneously.

[0014] Embodiments of the present invention pertain to a hierarchical control system, user interface system, and control architecture that together incorporate a broad range of user-selectable control modes representing variable levels of autonomy and vehicle control functionality. A unified autopilot is provided to process available modes and mode transitions. An intelligence synthesizer is illustratively provided to assist in resolving functional conflicts and transitioning between control modes, although certain resolutions and transitions can be incorporated directly into the functional sub-components associated with the different control modes. In accordance with one embodiment, all modes and transitions are funneled through an acceleration-based autopilot system. Accordingly, control commands and transitions are generally reduced to an acceleration vector to be processed by a centralized autopilot system.

I. Introductory Comments

[0050] Much of the present invention description will be devoted to describing embodiments in the context of an unmanned aerial vehicle (UAV). However, it is to be understood that the embodiments generally pertain to vehicle control systems and are designed for broad application. The embodiments can be adapted by one skilled in the art to be applied in the context of any of a variety of unmanned vehicles including, but not limited to, airplanes, helicopters, micro air vehicles (MAV's), missiles, submarines, balloons or dirigibles, wheeled road vehicles, tracked ground vehicles (i.e., tanks), and the like. Also, embodiments of the present invention can be adapted by one skilled in the art to be implemented in the context of manned vehicles (e.g., a human passenger operates the control system, or a human remotely operates a control system for a vehicle that transports a passenger, etc). It should be noted that the relatively modular nature of the vehicle control system of the present invention enables the adaptations necessary to accommodate different vehicles to be made in a relatively small period of time.

[0051] Certain embodiments of the present invention pertain to specialized control subsystems that each individually enable a specific control functionality to be accessed through the larger control system. It is to be understood that such subsystems can be adapted and independently deployed even in the context of vehicle control systems other than those specifically described herein. Also, such subsystems can be adapted to support any type of manned or unmanned vehicle including, but not limited to, those specifically listed herein.

II. Overview—Variable Autonomy Control System Architecture

[0052] Embodiments of the present invention generally pertain to a variable autonomy control system (VACS) architecture that enables, among other characteristics, a general simplification of UAV operation and control. The architecture illustratively supports selectable levels of control autonomy from fully autonomous control to simplified manual flight control modes for enhanced real-time control.

[0053] As dependence on UAV's for military operations grows and UAV technology is integrated into the emerging global command and control architecture, the cost and complexity of managing and controlling these assets could easily become substantial. This limitation is brought about by either of two extremes in the vehicle command and flight control philosophy: complete dependence on a human-in-the-loop (fully manual control) or complete exclusion of a human-in-the-loop (fully autonomous control). The former requires a dedicated, highly trained operator whereas the latter provides no mechanism for real-time operator interaction or mission management. The need for a dedicated highly-trained operator drives costs (personnel and training requirements) and severely limits a single operator's flexibility in that he or she is primarily focused on the aviation of the vehicle rather than the higher level mission objectives. On the other hand, the exclusion of the human-in-the-loop drives logistics costs (mission planning and asset allocation) and severely limits the UAV's operational flexibility.

[0054] A control design consistent with embodiments of the present invention exploits existing flight control technologies to arrive at an ideal balance between the two above-described control philosophies. The control design includes a flight control structure that supports variable levels of control autonomy and minimizes personnel and training requirements for vehicle operation. Human factors play a key role in that the vehicle is treated as one of many assets (e.g., including other vehicles) available to an individual operator during the execution of a defined mission. Therefore, the vehicle must be easily controllable. Embodiments of the present invention reflect the philosophical notion that a truly enabled UAV operator should not be required to be a trained aviator but should still retain variable levels of control capability to execute mission objectives that call upon his/her specialized expertise.

[0055] Embodiments of the present invention pertain to a hierarchical flight control structure with varied levels of remote operator input combined with an off-board controller software package and intuitive human system interface. Research of problems related to UAV control has indicated that a good solution lies in the appropriate functional allocation between human and machine. In the context of embodiments of the present invention, this leads to segregation of control into two fundamental categories: flight control and flight management. Flight control associates with the aviation of the aircraft whereas flight management associates with the mission plan (navigation tasking) for the aircraft.

III. Details—VACS Architecture

[0056] FIG. 1 is a schematic block diagram illustrating a VACS architecture 100 in accordance with one aspect of the present invention. Architecture 100 incorporates a hierarchical design that enables an invocation of different control behaviors at various levels in the hierarchy. Primitive control functions are combined with complex autonomous functions to enable a broad range of behaviors. An operator is illustratively able to access and selectively invoke certain of the control behaviors through an intuitive interface, such as an interface made available through a workstation. In accordance with one embodiment, the architecture design enables a single operator to work through the interface to effectively control multiple vehicles simultaneously.

[0057] FIG. 1 includes a spectrum 102 that demonstrates the hierarchical nature of architecture 100. Inputs 106 from human and other external sources are characterized across spectrum 102. At the top of the spectrum is the objective/decision level 104. Level 104 represents the highest end of the control spectrum wherein autonomous control is maximized, and the level of intelligent interaction (e.g., interaction with a human or other systems) consists of higher-level objective-based planning. The lowest level of intelligent autonomy is the execution level 112, in which external command interaction is either directly proportional to the actuation or is minimally compensated.

[0058] In between ends 104 and 112 are mission level 108 and coordination level 110. Levels 108 and 110 are sub-levels of the spectrum and represent varying levels of a blending of external and automated functionality. Mission level 108 is more human-oriented than coordination level 110, which is more human-oriented than execution level 112. Conversely, execution level 112 is more autonomous in nature than coordination level 110, which is more autonomous in nature than mission level 108.

[0059] Architecture 100 includes a plurality of functional sub-components 120-146. With regard to the FIG. 1 depiction, it should be noted that the individual functional sub-components are not necessarily illustrated on the level where they would correspond to the illustrated spectrum 102. Spectrum 102 is provided simply to demonstrate a hierarchical structure underlying architecture 100. Functional sub-components 120-146 represent control behaviors available for invocation either automatically or based on operator selection inputs.

[0060] When the illustrated control system architecture is actually applied, two or more of the illustrated functional sub-components can be applied simultaneously to accomplish a unified control scheme. In addition, in accordance with one embodiment, an operator is provided with the capability to interact through an interface to activate and deactivate certain functional control sub-components in order to activate and deactivate different modes of operator control representing different levels of system autonomy. An intelligence synthesizer 150 is provided to coordinate applicable functional sub-components and resolve conflicts there between. For example, if a vehicle is autonomously tracking a target (sub-component 130) and a new control command is inserted to automatically avoid an air collision (sub-component 122), then it is illustratively up to intelligence synthesizer 150 to determine which control source is to be given priority. Assumedly, collision avoidance will be given priority. Following execution of collision avoidance, intelligence synthesizer 150 is illustratively configured to resume normal operation (e.g., resume target tracking, hold a reasonable heading, etc.). In another example, if an operator interrupts the tracking of a target with an instruction to switch to autonomous route following (sub-component 132), then intelligence synthesizer 150 will ensure that the switch between modes of control is carried out as smoothly and efficiently as possible.

[0061] In accordance with one embodiment, intelligence synthesizer 150 is configured to manage the interfaces between modular autonomous and semi-autonomous functions so that they can be integrated in a ‘plug-n-play’ format. Some functions require de-confliction between competing commands to the airframe, on-board sensors, or outer-loop guidance. The intelligence synthesizer is illustratively configured to determine what functions exist in the configuration, what functions have priority, what functions are dormant, and what functions do not exist in the configuration. The intelligence synthesizer is illustratively further configured to implement the VACS hierarchical architecture to manage which level autonomy is allocated to each function. With reference to the FIG. 1 architecture hierarchy, the lowest level Execution functions are implemented with direct interfaces to the airframe and payload hardware. These functions illustratively include an airframe body-rate stabilization loop, an airframe acceleration command-tracking loop, a bank-angle command tracking loop, and/or a collection of payload management functions (these and other applicable functions are commercially available for integration and/or are described in other sections below as embodiments of the present invention). The higher level functions have interfaces as well, and in some cases will illustratively share responsibility with Coordination Level functions. Examples of such functions include implementation of inertial trajectories, pre-programmed maneuvers such as racetrack loiter patterns, waypoint leg regulation and switching, management of a waypoint list, and management of semi-autonomous control functionality such as sensor slave and remote-directional control (these and other applicable functions are commercially available modules for integration and/or are described in detail below in other sections as embodiments of the present invention).

[0062] The Coordination level functions illustratively share responsibilities with some Mission level functions. Examples of mission-level functions are autonomous route planners, autonomous ground collision avoidance, and autonomous see-and-avoid (these and other applicable functions are commercially available modules for integration and/or are described in detail below in other sections as embodiments of the present invention). Generally speaking, these functions process mission-level requirements and implement them based on vehicle state and mission status information.

[0063] In accordance with one embodiment, autonomous and semi-autonomous functions illustratively communicate and coordinate with each other via intelligence synthesizer 150, which is a pseudo-bus and communications manager. In cases where autonomous commands conflict or interfere with each other, intelligence synthesizer 150 determines how to de-conflict, blend, or prioritize the output commands.

[0064] A payload control functional sub-component 144 is included in order to facilitate transfers of information to and from mission payload 160. Mission payload 160 is illustrated with a variety of payload components 162-176. The illustrated payload components are illustrative only in that other or different components could be included without departing from the scope of the present invention. Some of the payload components are sensors that gather data that is transferred to intelligence synthesizer 150 either for the purpose of serving as a reference to be utilized in a vehicle control scheme or, alternatively, to be collected for some inherent value of the information itself (e.g, collected for a mission-oriented purpose). One illustrative purpose for communication payload component 174 is to facilitate communication between a ground station and a corresponding system implemented on the remote vehicle. Embodiments of the present invention pertain to specific communications components and will be described in greater detail below in other sections. Weapons payload component 176 is an example of an active component that can be triggered (e.g., fired) in response to operator input. Many of the illustrated payload components will be described in greater detail below. Chemical-biological detector component 172 is illustratively a sensor for detecting chemical and/or biological substances, for example for the purpose of identifying areas contaminated by chemical or biological agents. The GPS/IMU component 170 is illustratively a vehicle motion identification component for generating vehicle location information for any purpose such as, but not limited to, vehicle guidance, navigation or to be viewed by the operator (these and other applications of the data provided by sensor 170 will be described below in greater detail). Camera component 164 gathers information for mission purposes and/or for control purposes (the latter purpose being an embodiment of the present invention that will be described in detail below in other sections). Optical tracker 162 is illustratively configured to track an airborne or ground-based object relative to the vehicle for control purposes (e.g., air collision avoidance, ground target tracking, air target tracking, etc.) or mission purposes. Components 166 and 168 support additional mission and/or control functionality. Component 166 facilitates data collection and transfer of information in the nature of radar data, SAR data, ISAR data or the like. Component 168 could be any of a variety of components but illustratively facilitates data collection and transfer of information in the nature of a radar emitting device configured to sense and locate ground objects and the like.

[0065] The VACS architecture 100 illustratively enables a man-in-the-loop (i.e., the operator) to intuitively assign and deploy one or more UAV's in accordance with available control behavior parameters. The architecture supports intuitive control characteristics that are illustratively based on the human learning and decision-making process. Accordingly, the available control behavior parameters are designed to emulate the human learning, decision-making, and action processes. The architecture is distributed by design so that appropriate learning, decision-making and action behaviors are resident onboard the vehicle and supported with autonomous functionality when necessary.

[0066] It should be emphasized that the present invention is not limited to the illustrated sub-components 120-146. In fact, in accordance with one embodiment of the present invention, architecture 100 is designed such that additional sub-components can be modularly plugged into control architecture 100 to extend the system functionality. When a new sub-component is installed, intelligence synthesizer 150 is illustratively configured to recognize and manage the new functionality (e.g., synthesizer 150 is configured to manage conflicts with other sub-components, etc.).

[0067] FIG. 2 is a schematic representation of a human-based command and control loop 200 as is emulated in the VACS architecture 100. For reference purposes, FIG. 2 includes the same intelligent controller hierarchy spectrum 102 that was illustrated in FIG. 1. At the highest end of the spectrum, objectives 202 (e.g., typically human defined such as reconnaissance, surveillance, tracking, monitoring, etc.) provide a fundamental basis for the subsequent support levels. The lower levels of activity will illustratively be influenced by the overarching objectives. For the machine or vehicle, the fundamental equivalent of objectives 202 is machine constraints 204 (e.g., aviation limitations of the vehicle, available payload components, communications limitations such as range, static and dynamic limitations, etc.). The overarching machine constraints illustratively influence the lower levels of activity. In accordance with one aspect of the present invention, a human (i.e., an operator) can utilize a machine (e.g., a UAV) that is equipped with a system implementing the VACS architecture to observe (bubble 206), orient (bubble 208), decide (bubble 210) and take action (bubble 212). The steps of observe, orient, decision and action are hierarchical in nature and reflect a natural human process flow, and notably are reflected in the available coordination of autonomous functionality offered through the VACS architecture.

[0068] FIG. 3, in accordance with one aspect of the present invention, is a diagrammatic block representation of a hierarchical control structure 300. Control structure 300 is illustratively designed to support the VACS architecture 100 described in relation to FIG. 1. Most of the functional sub-components illustrated in FIG. 1 represent a range of potential functional control capabilities incorporating different levels of autonomy. Again, as has been discussed, the architecture is designed to be modularly extendable to even non-illustrated control schemes.

[0069] The highest level of control structure 300 is level 302, which is identified as the trajectory control level. Level 302 represents autonomous flight control modes and functionality that basically incorporate substantially full autonomy requiring practically no operator input. For illustrative purposes, mission control 304 is included on level 302 and represents mission-oriented fully autonomous flight control (e.g., mission is automatically planned and executed).

[0070] The next level of control structure 300 is level 306, which is identified as the inertial guidance level. Level 306 broadly represents autonomous flight control functionality with operator inserted path commands such as, but not limited to, waypoint editing, loiter point editing or real-time route editing. For illustrative purposes, take-off/landing control 308 and path control 310 have been included on level 306 (it is assumed that both are autonomous to some extent but require operator path input). To simplify the diagram, only a few relevant modes and functions are noted in the Figure specifically.

[0071] As is demonstrated on level 306, some sub-components or functions can be configured to work in cooperation with others. For example, take-off and landing components may utilize waypoint component functionality in generation of a flight approach for landing purposes. Such functional interdependence is within the scope of the present invention. Further, it should be noted that FIG. 3 is similar to FIG. 1 in that it is simply intended to demonstrate a hierarchical organization scheme in accordance with one aspect of the present invention. Actual characterization of the different functional components is open to interpretation.

[0072] In accordance with one aspect of the present invention, box 312 represents a specific level 306 autonomous mode of control that is worth previewing as an example. Box 312 represents a line-of-sight slave control mode of operation wherein a payload sensor is integrated into the guidance loop such that the vehicle is slaved to operator commanded sensor-pointing angles. In one embodiment of this control mode, the operator is generally concerned primarily with pointing the sensor with his/her attention focused on sensor imagery. The sensor commands are then blended into the UAV guidance algorithms and airframe stabilization commands are computed to orient the vehicle optimally in the mission environment. This control mode illustratively provides the foundation for a virtual reality human system interface, such as a head mounted display, and facilitates telepresence (the linking of remote sensors in the real world to the senses of a human operator) of surveillance and reconnaissance.

[0073] The next level of control structure 300 is level 316, which is identified as the directional control level. Level 316 broadly represents a hybrid level of autonomous flight control including, in accordance with one aspect of the present invention, as is notably depicted as an insert above block 318, remote directional command (RDC) capability. In accordance with one embodiment of RDC control, an operator can select a preprogrammed vertical profile maneuver (such as max climb or in-route descent) and maintain manual horizontal directional control of the vehicle. The operator can instantaneously transition to a control mode in which he/she has complete directional control (both vertical and horizontal) of the vehicle without being required to stabilize it rotationally. In accordance with one embodiment, the operator's control stick commands are mapped to directional commands (horizontal turn rate and climb/descent rates) that are then transformed into acceleration and bank angle commands prior to being fed into a stabilization autopilot, which is represented on level 320.

[0074] In accordance with one embodiment of the present invention, as is represented by box 318, control commands, regardless of their functional sub-component source, are transformed into acceleration and bank angle commands. These commands are then passed to the next level of the control structure, namely level 320, which is illustratively identified as the disturbance rejection autopilot level. In accordance with one aspect of the present invention, all levels of control utilize the same autopilot for a given vehicle, which in the illustrated case is a body-rate stabilization component 322.

[0075] The lowest level of control structure 300 is level 330, which is illustratively the level wherein actual manipulation of the aircraft's aerodynamic surfaces and thrust control occurs. Control commands after being filtered through autopilot component 322 are executed on level 330. In accordance with one embodiment, as is illustrated on level 330 as an arrow insert, one mode of control involves direct control of the aviation surfaces. Accordingly, such control commands are effectuated at a level below level 320 and are therefore relatively manual in nature.

[0076] In accordance with one embodiment of the present invention, the control modes and functions above box 318 generally do not require the operator to possess particularly specialized skills in aircraft aviation. On top of these control modes and functions, the UAV flight control computer performs higher frequency inner loop stabilization and command tracking (e.g., boxes 318 and 322). To the extent that control conflicts arise wherein multiple sub-components or functions generate conflicting control requests, intelligence synthesizer 150 is illustratively configured to resolve such conflicts prior to generation of acceleration and bank angle commands (box 318).

[0077] In accordance with one aspect of the present invention, the described vehicle control scheme supports transitions between changing control modes and functions. For example, suppose a UAV is flying a set of waypoints and the operator edits the waypoints. A transition must be made from the old waypoints to the new waypoints. In another example, suppose an aircraft flying a set of waypoints is on course to collide with another aircraft. It is within the scope of the present invention that an air collision avoidance sub-component will override the waypoint path and direct the aircraft off of the collision course. In this case, in accordance with one embodiment, the commands generated for level 316 will first correspond to the requested waypoint path, then there will be a transition to a non-collision path, and then there will be a graceful transition back to the waypoint path.

[0078] In accordance with one aspect of the present invention, intelligence synthesizer 150 is customized to support incorporated sub-components and functions and is thereby configured to generate the control commands necessary to transition control between sub-components and/or functions as necessary (e.g., acceleration and bank angle commands are obtained and executed as necessary for transitions). In accordance with another embodiment, information for resolving functional conflicts is embedded directly into a sub-component or function itself. It is also within the scope of the present invention that transitions be handled from both locations (e.g., some transitions are processed by the intelligence synthesizer and others are addressed directly within the sub-components or functions).

[0079] Generally speaking, FIG. 3 represents a top-level flow diagram of how the Mission, Coordination and Execution-Level hierarchical control architecture is organized so that external commands can be easily injected in to the autonomous control structure. The highest-level commands issued by the mission-level functions can be overridden or blended with trajectory edits inserted by a human operator, for example, via a ground control station interface. These commands are sent down to the inertial path regulation control loops, which generate airframe acceleration commands (or flight-path equivalent). If the user injects joystick steering commands, they are translated to the equivalent body acceleration commands, which are gracefully blended into the command chain by the VACS software. The acceleration commands are translated to bank angle and normal acceleration commands, which are articulated by the acceleration tracking and rate stabilization loops. The VACS architecture also provides an insertion point for low-level commands (e.g., stick-and-rudder commands), which correspond to more traditional inputs for piloted aircraft. These commands are directly input to the servos and override all of the other autonomous commands coming into the system.

[0080] FIG. 4 is a simplified diagrammatic representation of a control structure 400 in accordance with one aspect of the present invention. Control structure 400 includes a funnel representation 402 that represents a funneling of sub-component control functions into an acceleration control and bank angle command generator 404. In accordance with one embodiment, the information transferred to component 404 incorporates as necessary resolutions for functional conflicts and transitions between control modes or functions.

[0081] Information received by component 404 is transformed into corresponding acceleration and bank angle commands. These commands are then transferred to autopilot component 406, which in accordance with one embodiment, is configured to make control adjustments as necessary to maintain vehicle stabilization and/or track control commands. Accordingly, all levels of control are filtered through the same autopilot for a given vehicle. In accordance with one embodiment, autopilot component 406 is configured to make adjustments as necessary to maintain stability across control modes. The autopilot functionality is generally fixed and generally does not change regardless of mode selections or changes (e.g., all commands are funneled through the same autopilot). A mode change does not require the autopilot to be reset. Accordingly, the present invention provides continuity at the autopilot level, which is excellent for mode transition. This is an advantage over known systems wherein mode changes are known to cause instability, such as systems that incorporate a different autopilot for different modes.

[0082] As will be discussed in greater detail below, the control system and architecture embodiments of the present invention essentially enable any autopilot design to support control of a vehicle in numerous control modes that are executed with switches between modes during flight. All control modes are supported even in the presence of sensor errors, such as accelerometer and gyro biases. This robustness is at least partially attributable to the fact that the closed-loop system, in all control modes, is essentially slaved to an inertial path and, hence, the sensor biases wash out in the closed loop, assuming the biases are not so grossly large that they induce stability problems in the autopilot system. Furthermore, winds are generally not an issue in the overall control scheme in that the flight control system will regulate to the inertial path, adjusting for winds automatically in the closed loop. Given the precision afforded by inertial navigation aided by GPS technology, inertial path regulation offers a highly effective and robust UAV control approach. Generally speaking, the autopilot system functions such that winds, medium Dryden turbulence levels, sensor errors, airframe aerodynamic and mass model parameter uncertainties, servo non-linearity (slew rate limits, etc.), and various other atmospheric and noise disturbances will non have a critically negative impact on flight path regulation.

[0083] Component 408 receives commands generated by component 404 and filtered by autopilot component 406. The commands received by component 408 are executed to actually manipulate the vehicle's control surfaces. Autopilot component 406 then continues to monitor vehicle stabilization and/or command tracking, making additional commands to component 408 as necessary.

[0084] Generally speaking, relative to the control structures illustrated in FIGS. 3 and 4, known control systems are inflexible. For example, some known systems support little or no control functionality beyond remote stick-and-rudder commands (e.g., direct control of vehicle control surfaces with little or no incorporated automation). To the extent that a known system offers multiple modes of vehicle control, the modes are typically rigid in nature rather than flexible.

[0085] In accordance with one aspect of the present invention, an entire hierarchical spectrum of multi-autonomous control modes are made available to a system operator. The operator is illustratively able to efficiently and smoothly change control modes mid-mission as desired. The operator can do much more than simply change, edit or adjust waypoints on a waypoint-following mission. An operator can interrupt a waypoint-following mission to guide the vehicle manually, or partially manually (e.g., remote directional commands), or based on sensor/remote line-of-sight command control. In accordance with one embodiment, the control system is configured to optionally transition back to an interrupted mission (e.g., back to an original waypoint-following mission). It should be noted that the “operator” is not necessarily human. For example, the operator could be an automated decision-making source, such as a military C4I system.

[0086] The spectrum of control modes available to an operator illustratively corresponds to the particular functional sub-components incorporated into the variable autonomy control system architecture (e.g., architecture 100 in FIG. 1). In accordance with one aspect of the present invention, in addition to numerous specific control modes that will be described within the present description, a spectrum of additional control modes are conceivable. The control systems of the present invention can be easily configured to support (including conflict and transition support that enables the operator to switch back and forth between modes) basically any control mode or module. Examples of such control modes include:

[0087] 1. Operator inputs a planned route and then the control system autonomously chooses a vehicle (e.g., one of several available vehicles) and automatically guides the vehicle along the planned route . . . or operator designates a moving ground target and then the control system autonomously chooses a vehicle and automatically guides the vehicle to track the ground target

[0088] 2. Operator provides a planned route for a specific vehicle before the vehicle is launched . . . the vehicle follows the pre-planned route

[0089] 3. Same as #2 but operator is allowed to change to a different planned route post launch (e.g., ability to change missions)

[0090] 4. Control based on a vector-based decision process (e.g., vehicle will head in a predetermined direction at speed x, altitude y, etc. . . . then turn based on new vector input information

[0091] 5. Remote Directional Control (RDC) control (e.g., flying directionally such as with a multi-directional joystick input mechanism . . . with autonomous safety nets that do not let the operator aerodynamically stall, over-steer, overbank, or otherwise compromise flight of the vehicle)

[0092] 6. Full Manual Control (remote commands which directly reach the control surfaces un-compensated or conditioned)

[0093] Accordingly, the control systems of the present invention enable an operator to move in and out of a range of different control modes selected from a broad control spectrum including everything from automated mission planning to direct control, with many available modes in between. Modes other than the six listed above are certainly within the scope of the present invention.

[0094] In accordance with one embodiment, the control system architecture of the present invention is flexible enough to support implementation of commercial-off-the-shelf (COTS) components to enable additional system sub-components and corresponding control functionality. For example, software products for automatic route planning are commercially available an can be implemented in the context of the described control system and architecture. For example, OR Concepts Applied (ORCA) of Whittier, Calif. provides at least one software product for route planning such as their “ORCA Planning & Utility System” (OPUS). This is but one example of a software component that can be utilized to extend the functionality of the broader control system. In accordance with one embodiment, while programs such as OPUS are configured to generate a route plan, the configuration of the control structure of the present invention (described in relation to FIGS. 3 and 4) will ensure that a generated plan is optimized for the relevant vehicle (e.g., the plan is filtered through command generator 404 and autopilot 406 before vehicle control is directly impacted).

[0095] It should be noted that while FIG. 3 shows manual commands being entered below the autopilot component 322, this is not necessarily the case. With reference to FIG. 4, in accordance with one embodiment of the present invention, when an operator chooses a manual control mode, manual instructions are translated into corresponding acceleration commands. In accordance with one embodiment, the trajectory commands are processed by the autopilot component 406 such that, for example, when the operator lets go of the stick the vehicle will continue on a relatively straight and balanced path.

[0096] The present description, including FIGS. 3 and 4, has been described in the context of a system that incorporates an autopilot component configured to operate in accordance with commands expressed as acceleration-based descriptors of motion. It should be noted that any other commands and corresponding autopilot system can be utilized without departing from the scope of the present invention. For example, component 404 (FIG. 4) can be configured to generate commands in the form of bank-to-turn thrust values, skid-to-turn values, velocity-based values, or any other descriptor of motion. Accordingly, autopilot component 406 is generally a modular component that can be configured to support any of a wide variety of directional command structures and descriptors of motion. Examples of autopilot systems within the scope of the present invention include, but are not limited to, bank-to-turn autopilots, skid-to-turn autopilots, and the like.

[0097] Accordingly, the present invention provides a hierarchical control system and architecture that incorporates a broad range of user-selectable control modes representing variable levels of autonomy. A unified autopilot is provided to process available modes and mode transitions. An intelligence synthesizer is illustratively provided to assist in resolving functional conflicts and transitioning between control modes, although certain resolutions and transitions can be incorporated directly into the functional sub-components associated with the different control modes and functions. In accordance with one embodiment, all modes and transitions are funneled through an acceleration-based autopilot system. Accordingly, control commands and transitions are generally reduced to an acceleration vector to be processed by the centralized autopilot system.

[0098] In accordance with one aspect of the present invention, a translation layer is included to enable specialized control support for a given set of autopilot and vehicle control systems. In other words, the translation layer receives acceleration vectors (or some other output) and translates them into control instructions that are acceptable for a particular vehicle's autopilot and control system. The translation layer essentially enables the control architecture and structures of the present invention to be adapted for any vehicle's autopilot system. For example, in accordance with one embodiment, a vehicle that incorporates a control system that includes flight path angle-based trajectory control can be enhanced with the significant variable autonomy control features of the present invention. The translation layer is configured to receive an input and translate it into whatever commands are necessary to support a given vehicle. It should also be noted it is not required that the translation layer input be in the form of an acceleration vector (e.g., it could be a velocity representation, etc.).

[0099] FIG. 5 is a diagrammatic block representation of a translation layer embodiment of the present invention. As is indicated by block 502, acceleration vectors are passed to a translator 504. Translator 504 translates the acceleration vectors into a format appropriate for a given autopilot system 506. As is indicated by block 508, the translated control instructions are utilized for vehicle control. Without departing from the scope of the present invention, the software support for the translation layer can be implemented in association with a ground station system and/or an on-board vehicle control system.

[0100] In accordance with one embodiment, through implementation of a translation layer, the control systems of the present invention employ a generalized high-bandwidth autopilot interface design that can be applied to a variety of air vehicles from conventional statically stable tail control airframes to high performance, statically unstable, tail-less combat vehicles or neutrally stable cruise missiles.

IV. System Architecture

[0101] In accordance with one aspect of the present invention, the described VACS architecture and associated hierarchical control structure are implemented in the context of two basic facilitating interface components: a ground control station interface and an airborne system interface. FIG. 6 is a schematic representation of top-level hardware and software objects associated with each interface (labeled interface 602 and 604, respectively). Interfaces 602 and 604 are linked to one another by a datalink 605. Datalink 605 is illustratively a communications link that enables remote communication between the ground station interface and the vehicle interface. All known methods for implementing such a datalink are within the scope of the present invention.

[0102] The ground system interface 602 includes a centralized command and control component 606. Component 606 is illustratively configured to provide an operator with a user control interface. Through the interface, with the aid of a video display component 614, component 606 provides the operator with image data that is received by a mission sensor that is part of the vehicle's on-board payload. Through the interface, with the aid of a vehicle status display 616, component 606 provides the operator with control settings, warnings or other relevant vehicle status information. Through the user interface, with the aid of a map display 610, component 606 provides the operator with a real time map display that shows a vehicle's location relative to a map. A mission evaluation component 612 performs mission analysis and influences command and control component 606 as necessary depending on a given implementation. External interface 618 provides a means for communication with external sources such as, but not limited to, maintenance training equipment that provides logistics support for any of a wide variety of maintenance training equipment. Component 606 is illustratively configured to receive and respond to inputs received from the operator through control input devices 608. Component 606 communicates through datalink 605 with an executive component 652 associated with airborne system interface 604. In this way, the operator is able to control the vehicle at least with regard to flight characteristics and payload operations. Also, component 606 receives data from executive component 652 as necessary to support various system functionalities (e.g., component 606 receives navigation data from component 652 for any of a wide variety of functions, for example, for supplying an indication of aircraft location relative to map display 610).

[0103] The executive component 652 is configured at least to process commands and information received from command and control component 606. Several components are configured to support the functionality of executive component 652, particularly with regard to flight control and management. An atmosphere component 656 processes characteristics of the vehicle's surroundings as necessary at least to support the execution of manual and automated flight control decisions. A guidance component 658 processes operator inputs, as well as automated and data inputs, in order to facilitate flight control of the aircraft. A navigation component 662 facilitates the collection and provision of data pertaining to aircraft location. Autopilot component 654 receives flight control commands, processes the commands (e.g., makes adjustments to ensure stable flight patterns), and passes commands to actuator control component 668 and engine control component 666 as necessary for flight control execution. Vehicle management component 660 could have any of a variety of functions but illustratively at least coordinates and organizes flight control sensor inputs. Payload control component 664 manages the vehicle payload and facilitates the execution of payload commands received from the operator.

[0104] FIG. 7 is a schematic diagram illustrating an interface system similar to that illustrated in FIG. 6 but adapted for multiple vehicles. Ground system interface 702 is illustratively the same or similar to interface 602 shown in FIG. 6. In order to simplify the illustration of interface 702, only components 606, 608, 610, 614 and 616 are included. Any of the other components of interface 602 could be included without departing from the scope of the present invention. Other or different components could be included without departing from the scope of the present invention.

[0105] Ground system interface 702 includes one component that interface 602 did not. Interface 702 includes a synthetic visuals component that is configured to provide the operator with a relatively real-time display of a synthetically generated depiction of the vehicle and/or its environment. The concept of synthetic visual display represents an embodiment of the present invention and will be described in greater detail below.

[0106] With further reference to FIG. 7, in accordance with one aspect of the present invention, communication between ground system interface 702 and an airborne system interface 730 is through a communications interface 710 (e.g., a SLIP router) (in place of the simplified “datalink” illustrated in FIG. 6). Router 710 works in conjunction with a radio 712 to transfer commands and flight information in a distributed manner to a plurality of radios 714-718. Each radio 714-718 is associated with a different executive component (e.g., components 720-724) located on board a separate vehicle. Each vehicle's executive component is illustratively configured in a manner that is the same or similar to component. 652 illustrated in FIG. 6. As is shown in FIG. 7, each executive component 720-724 includes components 652, 666, 668, 664, 662, 654 and 658. Other or different components could be included without departing from the scope of the present invention.

[0107] V. Dynamic Control Schemes

[0108] FIG. 8, in accordance with one aspect of the present invention, is a schematic diagram representing a vehicle control scheme that supports implementation in the context of the described VACS architecture and control structure. It should be emphasized that any form of autopilot controller (e.g., classical, optimal, robust, non-linear, or adaptive) can be employed without departing from the scope of the present invention, and without affecting the system architecture or operator control policies.

[0109] In accordance with the illustrated control scheme, operator inputs 802 are provided to vehicle management software 804. Management software 804 is configured to support an illustrative three different classes of control and corresponding operator inputs. The first class is represented by block 806, which is labeled energy optimal trajectory. Control modes of this type involve controlling the vehicle in a substantially automated manner so as to maintain a preferred or designated trajectory while expending a relatively minimized amount of energy (e.g., to conserve potential energy). The second class is represented by block 808, which is labeled autonomous path control. Control modes of this type involve controlling the vehicle in a substantially automated manner so as to maintain a flight control path that is mission oriented and, optionally, selected and/or modified by the operator. The third class is represented by block 810, which is labeled line-of-sight slave commands. As has been described, control modes of this type generally involve controlling the vehicle based primarily on manipulation of a visual sensor. The third class is represented by block 812, which is labeled remote directional commands. Control modes of this type have been previously described herein and generally involve, in one embodiment, controlling the vehicle based on simplified directional commands with reliance on automation to determine appropriate execution parameters.

[0110] A switch 814 represents a selection of one of the different control classes based, for example, on a control mode selection that corresponds to an operator input 802. The switch 814 is notionally represented by a simple switch but is illustratively embedded in the more complex Intelligence Synthesizer processing architecture. Once a connection with a control class/mode has been established, subsequent corresponding vehicle control commands are translated through bank-to-turn and thrust control component 816 (e.g., corresponding acceleration vector commands are generated). Additional data derived from an air-data sensor source 818 and/or software 804 is fed into the control process as necessary. The output of control component 816 is adjusted at component 820 (e.g., autopilot adjustments) in order to compensate for deviations from the original control command. As is illustrated, information from commercial-off-the-shelf integrated components 822 (e.g., coordinate information from GPS/IMU/NAV systems) can be fed into the determination of actual deviations as necessary, and can also be utilized by software 804 for any purpose such as but not limited to route planning. Following adjustments for deviations, box 824 represents adjustments for airframe stabilization (e.g., autopilot adjustments).

[0111] Following the steps associated with boxes 816, 820 and 824, box 826 represents the step wherein control commands are actually executed and vehicle control surfaces and engine dynamics are actually manipulated based on the commands. Following execution of the commands, sensors associated with air-data sensor 818 and integrated components 822 return data to points upstream in the process such that additional adjustments can be made if necessary (e.g., necessary to keep the vehicle on track with a desired route or necessary to keep the vehicle from stalling, crashing, etc.). As is indicated at 830, inertial dynamics are processed following command execution. This information is passed along to camera stabilization and pointing component 840 such that adjustments can be made if necessary to stabilize a camera, such as a gimbal-mounted camera utilized to support line-of-sight slave commands 810. Adjustments can be made to the camera configuration based on relative geometry in order to keep the camera relatively stable. Information input 832 represents an input of target location information that enables the camera to focus on and follow a target.

[0112] There are several features and extensions of the described control approach to highlight:

• [0113] 1. In accordance with one aspect of the present invention, a library of robust mathematical guidance algorithms (examples of which are described later in the present description as embodiments of the present invention) are employed to accommodate remote operator command insertion at every level of flight control to address not just the flight control problem but also flight management. This design approach provides simplified manual control modes that enable a relatively unskilled operator with minimal training to control the vehicle.
• [0114] 2. In accordance with another aspect of the present invention, the payload sensor control is integrated into the guidance loop to provide a control mechanism that shifts the operator's focus from vehicle control to sensor control, without concern of the vehicle flight profile. This control mechanism also facilitates the introduction of a virtual control interface bringing immersive control techniques to the airborne surveillance and reconnaissance arena.
• [0115] 3. An intuitive human-system interface (described in other sections below) offers an interface with which operators can be trained to execute a successful vehicle mission in a matter of hours or days as opposed to weeks, months, or years.
• [0116] 4. An intuitive, real-time mission planning capability is built into the ground control station software to support real-time route editing and vehicle mission retasking.
• [0117] 5. The system enables real-time mission assessment such that the operator can make rapid and precise real-time mission updates, as dictated by higher level operational needs that change continuously within a dynamic environment (e.g., battle environment).

[0118] In accordance with one aspect of the present invention, to enable a simplified manual control concept, the controller structure is implemented such that the operator can have direct control of three outer-loop states: airspeed (u), turn rate ({dot over (ψ)}) and altitude rate ({dot over (h)}). To satisfy the requirements of fully autonomous flight, it is generally desired to close the outer loop around a fixed path that is defined by preprogrammed waypoints. Analysis of the problem shows that both requirements (simplified manual and fully autonomous control) could be satisfied with a single control loop structure.

[0119] In accordance with one aspect of the present invention, an improved control loop structure is provided. FIG. 9 is a control diagram representing a general integrated guidance loop structure. Box 902 represents operator input and box 904 represents gain or mapping from input to autopilot. Together, boxes 902 and 904 represent an operator command insertion point, for example for the simplified manual control mode herein referred to as Remote Directional Response (RDR) or Remote Directional Command (RDC). Box 910 represents a waypoint guidance input. Box 912 represents pre-filtering adjustment to input 910 to maintain a properly conditioned signal with desirable steady-state properties. Box 914 represents a gain adjustment to input 910 to compensate for command error. Box 916 represents a feedback loop providing an adjustment for phugoid dampening. Box 918 represents autopilot controller functionality. Box 920 represents the airframe plant itself (e.g., the vehicle and associated actuators actuated in response to the control input). Finally, box 922 represents integrals of the first dynamic states, thus completing the plant dynamics model.

[0120] A switch 906 is inserted between the autopilot 908 and guidance system thereby enabling the operator to command the autopilot 908 directly. The switch 906 is notionally represented by a simple switch but is illustratively embedded in the more complex Intelligence Synthesizer processing architecture. An example of operator commanded autopilot control is horizontal steering. For horizontal steering, the operator's control stick commands are mapped to horizontal turn rate commands. The guidance software illustratively gains the turn rate command by the current vehicle inertial velocity and feeds this term to the autopilot. In the vertical channel, the operator control stick commands are mapped to an altitude rate. The guidance software converts this command into a flight path angle command and computes a flight path following acceleration command that feeds the autopilot. In accordance with one embodiment, when the operator “lets go of the stick”, the flight software simply commands the vehicle to fly straight and level at the current altitude and current heading.

[0121] As FIG. 9 demonstrates, the general form of the outer loop guidance algorithm is a second order inertial path controller. The corresponding form of the autopilot utilizes an acceleration command input. Thus, the incorporated autopilot structure is an acceleration command autopilot in the pitch and yaw axis and a bank angle command autopilot in the roll axis. It should be noted that other gain scheduling techniques and acceleration autopilots are within the scope of the present invention. Different autonomous vehicles will illustratively incorporate different gain scheduling techniques and autopilots, the VACS architecture and control structures being conveniently adaptable by one skilled in the art to accommodate such variations. A list of autopilot systems that can be accommodated includes, but is not limited to:

• [0122] 1. Linear classical control designs using pole-placement gain scheduling techniques
• [0123] 2. Non-linear control design using dynamic inversion
• [0124] 3. Non-linear adaptive control design
• [0125] 4. LQR (optimal) control design
• [0126] 5. Loop shaping control design

[0127] In one embodiment, as was alluded to in relation to FIG. 5, a translation layer can be implemented to translate a given control output (e.g., an acceleration based command) to an alternative form as necessary to accommodate any of the above five or other autopilot systems.

VI. Coordinate Frame Definitions

[0128] In order to support description of specific control modes and guidance methods, a few different standard coordinate frame definitions and transformations will now be described.

[0129] FIG. 10-1 is a diagrammatic representation of an Earth Centered Earth Fixed (ECEF) coordinate frame definition. The ECEF reference frame is oriented with its origin at the earth's center. The x and y axes lie in the equatorial plane with the x-axis passing through the Greenwich Meridian. The z-axis is normal to the x-y plane and passes through the North Pole.

[0130] FIGS. 10-2 and 10-3 are diagrammatic representations of a Geodetic coordinate frame definition. The geodetic coordinate frame defines the lines of latitude and longitude along the earth's surface. Geodetic latitude is the angle between the equatorial plane and the normal to the surface of the ellipsoid. Geodetic longitude is the angular rotation relative to the ECEF x-axis in the equatorial plane. Geodetic altitude is the elevation above the ellipsoid surface.

[0131] A coordinate reference frame definition that is not illustrated is the local vertical reference frame, which is oriented with its origin at a point along the earth's surface defined by an angular rotation from the ECEF frame (latitude and longitude) and an altitude, h, above the earth's surface. This frame's z-axis is normal to the local tangent of the ellipsoid. The x-y plane lies normal to the z-axis and parallel to the local horizon.

[0132] FIG. 10-4 is a schematic representation of a body reference frame. The body reference frame has its origin at the vehicle center of gravity. The y-axis extends out of the right wing of the vehicle, the x-axis extends out the nose of the vehicle, and the z-axis is positive down passing normal to the x-y plane.

[0133] Certain embodiments of the present invention involve coordinate frame transformations. For example, a function can be applied to transform geodetic coordinates to ECEF coordinates. In accordance with one embodiment of such a transformation, coordinate waypoints are passed into the UAV flight computer in geodetic coordinates (latitude (λ), longitude (l), and altitude (h), Earth semi-major axis (a_E), eccentricity e). These waypoint locations are then transformed to ECEF coordinates utilizing a function such as:

[0134] $\begin{array}{cc}{\stackrel{\_}{P}}_{\mathrm{ECEF}}=\left\{\begin{array}{c}\left(\frac{a_E}{\sqrt{1-e^2{\sin }^2\left(\lambda \right)}}+h\right)\cos \left(\lambda \right)\cos \left(l\right)\\ \left(\frac{a_E}{\sqrt{1-e^2{\sin }^2\left(\lambda \right)}}+h\right)\cos \left(\lambda \right)\sin \left(l\right)\\ \left(\frac{a_E\left(1-e^2\right)}{\sqrt{1-e^2{\sin }^2\left(\lambda \right)}}+h\right)\sin \left(\lambda \right)\end{array}\right\}& \mathrm{Eq}.1\end{array}$

[0135] Similarly, ECEF coordinates can be transformed into local vertical coordinates. In accordance with one embodiment of such a transformation, the guidance error equations are formulated in the ECEF reference frame, then converted to the local vertical reference frame for computation of the guidance commands. The ECEF to local vertical transformation matrix can be defined as:

[0136] $\begin{array}{cc}{T}_E^L=\left[\begin{array}{ccc}-\sin \left(\lambda \right)\cos \left(l\right)& -\sin \left(\lambda \right)\sin \left(l\right)& \cos \left(\lambda \right)\\ -\sin \left(l\right)& \cos \left(l\right)& 0\\ -\cos \left(\lambda \right)\cos \left(l\right)& -\cos \left(\lambda \right)\sin \left(l\right)& -\sin \left(\lambda \right)\end{array}\right]& \mathrm{Eq}.2\end{array}$

[0137] Local vertical guidance commands can then be transformed into the body reference frame for input to the autopilot through the transformation matrix (pitch angle Θ, yaw angle Ψ, roll angle Φ):

[0138] $\begin{array}{cc}{T}_B^L=\left[\begin{array}{ccc}\cos \mathrm{\Psi cos\Theta }& \sin \mathrm{\Psi cos\Theta }& -\sin \Theta \\ \cos \mathrm{\Psi sin\Theta sin\Phi }-\sin \mathrm{\Psi cos\Phi }& \sin \mathrm{\Psi sin\Theta sin\Phi }+\cos \mathrm{\Psi cos\Phi }& \cos \mathrm{\Theta sin\Phi }\\ \cos \mathrm{\Psi sin\Theta cos\Phi }+\sin \mathrm{\Psi sin\Phi }& \sin \mathrm{\Psi sin\Theta cos\Phi }-\cos \mathrm{\Psi sin\Phi }& \cos \mathrm{\Theta cos\Phi }\end{array}\right]& \mathrm{Eq}.3\end{array}$
VII. Navigator

[0139] In another aspect of the present invention, vehicle state information is provided by a component herein referred to as the navigator component. Navigator components are known in the art to provide information such as, but not limited to, position, velocity, acceleration, angular position and/or angular velocity associated with the vehicle. Some known navigator components incorporate sensor devices such as, but not limited to, a three-axis inertial measurement unit, a GPS receiver, and/or strap-down equation software, and Kalman filter used to estimate the IMU sensor error.

[0140] Information output from navigator components is utilized for any of a variety of purposes. For example, the accelerations, angular rates and other similar outputs are illustratively fed into an autopilot system in support of stability-enhancing processes. Position, velocity, angular position and other similar outputs are used by the guidance functionality to aid in decision-making such as, but certainly not limited to, path-regulation.

VIII. Guidance

[0141] In another aspect of the present invention, a guidance function is responsible for generating autopilot commands that, when executed, achieve a particular guidance objective. Guidance objectives are designed to satisfy operator interface and mission control requirements and include functions such as, “regulate to a preprogrammed inertial path,” “go to and monitor a specified target coordinate,” “execute an operator commanded programmed maneuver,” “slave to an operator commanded sensor stare command,” etc.

[0142] FIG. 11, in accordance with one aspect of the present invention, is a schematic block diagram demonstrating a basic flow structure for the various flight mode levels and identifying underlying guidance laws called by the flight management software component. There are an illustrative four levels of operational modes within the vehicle manager: flight mode 1102, flight sub-mode 1104, guidance mode 1106, and guidance sub-mode 1108.

[0143] Flight mode 1102 includes three different functions, namely, take-off 1110, inflight 1112, and landing 1114. For take-off 1110, flight sub-mode 1104 includes four primary functions, namely, taxi 1116, throttle-up 1118, ground roll 1120 and climbout 1122. When these four sub-mode functions have been executed, guidance mode 1124 (fly waypoints) is executed. In that regard, waypoint guidance law 1134 is executed including sub-modes 1126 (waypoint capture) and 1128 (leg regulation).

[0144] When the flight mode is inflight 1112, the operator can select between flight sub-modes 1136 (autonomous control) and 1140 (manual control). One selectable option for autonomous control is the fly waypoints 1124 guidance mode in accordance with waypoint guidance law 1134. Another selectable autonomous control mode is loiter guidance mode 1142, which is executed in accordance with loiter capture guidance sub-mode 1130 and orbit guidance sub-mode 1132 being subcomponents of loiter guidance law 1144.

[0145] Options for manual control 1140 include RDC guidance mode 1146, LOS-slave mode 1148 and hybrid control mode 1150. Each of these manual control modes are related to guidance sub-modes 1152 (command following) and 1154 (reference hold), which are related to flight path guidance law 1156. It should be noted that guidance modes and guidance sub-modes can be combined as indicated to enable a biased pursuit guidance law 1158 in accordance with one aspect of the present invention.

[0146] The library of outer-loop guidance modes support both autonomous control as well as simplified manual control. Guidance laws that are within the scope of the present invention and are exploited by the vehicle manager include, but are not limited to, waypoint guidance, loiter guidance, line-of-sight slave control guidance and remote directional command guidance. Various guidance modes invoke these guidance laws to achieve diverse mission objectives. For example, loiter guidance is a guidance law invoked by several difference guidance modes including, but not limited to, programmed route guidance, park guidance, observation point guidance, and moving target tracking guidance.

[0147] In one embodiment, the operator at any point during a mission can interrupt the vehicle management software component. The component will illustratively process the operator's inputs and perform the appropriate action, which may include entering a manual control mode, entering an operator specified orbit pattern, or updating and executing a planned navigation route.

[0148] The control system design and architecture of the present invention enables a single operator to seamlessly transition between varying levels of control autonomy for an individual vehicle. Such control capability even enables the single operator to effectively manage and control a team of vehicles. In another aspect of the present invention, to support such functionality, a gradient control scheme is provided and utilizes on-board trajectory synthesis techniques to establish an inertial reference trajectory to which a vehicle is regulated. The gradient control approach is predicated on the use of acceleration feedback in the pitch channel autopilot. As has been alluded to, however, the solution is extensible to platforms that do not employ acceleration feedback, for example through implementation of a mathematical translation or transformation from the acceleration command to the native state command accepted by the native autopilot. Hence, an acceleration autopilot is not implicitly required to adequately satisfy the guidance objectives generated by the presently described variable autonomy control algorithms.

[0149] Kinematics provides a motivation for acceleration based vehicle control. Both rectilinear and relative general plane equations of motion relate position and velocity states (translational or angular) to acceleration through mathematically tractable differential equations. The following equations are examples of translational and rotational differential equations formulated as guidance laws for typical navigation and homing guidance:
{right arrow over (a)}cmd=ω²Δ{right arrow over (P)}+2ζωΔ{dot over ({right arrow over (P)}+{right arrow over (g)}  Eq. 4
where

• • [0150] ω=guidance law natural frequency
  • [0151] Δ{right arrow over (P)}=guidance position error
  • [0152] ζ=guidance law damping ratio
  • [0153] Δ{dot over ({right arrow over (P)}=guidance velocity error
  • [0154] {right arrow over (g)}=gravity

[0155] (translational—waypoint guidance)
R{umlaut over (λ)}−2V{dot over (λ)}=−NV{dot over (λ)}≡−a_cmd  Eq. 5
where

• • [0156] R=relative range to target
  • [0157] {umlaut over (λ)}=line-of-sight accleration
  • [0158] V=closing velocity to target
  • [0159] {dot over (λ)}=line-of-sight rate
  • [0160] N=guidance law gain

[0161] (rotational—proportional navigation)

[0162] Such equations are consistent with fundamental principals of autonomous vehicle guidance and control. The theory behind the autonomy control systems of the present invention illustratively capitalizes on the properties of the differential equations that formulate the desired acceleration commands. Given that the underlying equations of motion that describe physical motion of air vehicles are continuous functions operating over a set of real variables from “negative infinity to positive infinity” (no discontinuities in the function), then it serves that the derivatives of these functions are continuous. Hence, rectilinear acceleration commands can be generated to regulate velocity reference trajectories (first order control law—acceleration is the first derivative of velocity) or position reference trajectories (second order control law—acceleration is the second derivative of position). It can therefore be shown that the transition between derivative control modes is stable, assuming the gains for each corresponding control scheme provide a stable response. Closed-loop stability over mode transitions is then eliminated as a concern and, hence, the transition between control modes is essentially seamless. The following equations illustrate this principal:

[0163] $\begin{array}{cc}\mathrm{Gradient}\mathrm{Control}\mathrm{Scheme}\text{:}\text{}\begin{array}{c}R=\mathrm{Input}\left(\mathrm{state}\mathrm{to}\mathrm{be}\mathrm{controlled}\right)\\ U=\mathrm{Control}\mathrm{signal}\\ U=\frac{{\partial }^{″}R}{\partial t^{″}},n\mathrm{is}\mathrm{number}\mathrm{of}\mathrm{derivatives}\mathrm{between}\mathrm{input}\mathrm{and}\\ \mathrm{control}\mathrm{signal}\end{array}& \mathrm{Eq}.6\\ \mathrm{Example}\mathrm{Applications}\text{:}\text{}\mathrm{CASE}1\text{:}\mathrm{SECOND}-\mathrm{ORDER}\begin{array}{c}R=\mathrm{Reference}\mathrm{path}\mathrm{for}\mathrm{waypoint}\mathrm{guidance}\left(P\right)\\ U=\mathrm{Acceleration}\mathrm{command}\left(a\right)\\ a=\frac{{\partial }^{2}P}{\partial t^2}\underset{\mathrm{Laplace}}{=}\left({\mathrm{As}}^2+\mathrm{Bs}+C\right)P\left(s\right)=0\underset{\mathrm{Discrete}}{\Rightarrow }\delta \ddot{P}=a=2\mathrm{\zeta \omega \delta }\stackrel{.}{P}+\\ {\omega }^2\delta P\mathrm{CASE}2\text{:}\mathrm{FIRST}-\mathrm{ORDER}\begin{array}{c}R=\mathrm{Flight}\mathrm{path}\mathrm{velocity}\mathrm{command}(\gamma \approx \frac{V_{\mathrm{up}}}{\stackrel{\_}{V}})\\ U=\mathrm{Acceleration}\mathrm{command}\left(a\right)\\ a=\frac{\stackrel{\_}{V}\partial \gamma }{\partial t}\underset{\mathrm{Laplace}}{=}\stackrel{\_}{V}\left(\mathrm{As}+B\right)\gamma \left(s\right)=0\underset{\mathrm{Discrete}}{\Rightarrow }\stackrel{\_}{V}\stackrel{.}{\lambda }=a=\frac{\stackrel{\_}{V}}{\tau }\mathrm{\delta \gamma }\end{array}\end{array}& \mathrm{Eqs}.7\&8\end{array}$

[0164] The above examples illustrate waypoint guidance (second order) and flight path angle guidance (first order) laws. The guidance laws can regulate to any mathematically tractable reference path from which position and/or velocity and orientation errors between the vehicle and the path are computed. The reference paths can be generated apriori by a mission planner (waypoint route, for example) or synthesized autonomously by on-board flight control software to achieve a high level objective commanded by an operator (autonomous landing terminal trajectory, for example). This approach provides a control scheme in which an operator can issue commands of varying levels of autonomy without regard for the closed-loop vehicle stability during mode transitions. Applying this scheme, in accordance with one embodiment of the present invention, a baseline set of guidance laws alluded to in FIG. 8 (waypoint guidance, flight path angle guidance, line-of-sight rate guidance, and sensor-slave guidance) provide a core guidance law toolbox upon which the variable autonomy control system described herein is built. Higher level software processing functions then interpret operator commands, sensor inputs, and database inputs and translate these inputs into executable guidance laws that the control system then acts on. In another aspect of the present invention, this design enables robust higher level autonomous control functions within the described VACS framework. Such functions illustratively include, but are not limited to, functions for ground collision avoidance, air collision avoidance (“see & avoid”), ground moving target tracking and following, formation flying (multiple vehicles), and autonomous landing. Autonomous guidance algorithms designed to support the system will now be described in greater detail.

[0165] A. Waypoint Guidance

[0166] In accordance with one aspect, as is indicated by block 132 in FIG. 1, one provided control mode enables a waypoint guidance control mode. In one embodiment of waypoint guidance, guidance error computations are performed in the ECEF reference frame then rotated into the local vertical reference frame prior to being addressed in the guidance law. The error computations are illustratively separated between a waypoint leg regulation phase and a waypoint leg transition phase. While inertially guiding to a waypoint leg, the guidance errors are illustratively derived by first forming a vector triangle between the vehicle (i.e., the UAV) and the two waypoints that make up the waypoint leg.

[0167] FIG. 12 is a schematic diagram demonstrating waypoint guidance error calculation in accordance with one embodiment of the present invention. The position error (Δ{right arrow over (P)}) and the velocity error (Δ{right arrow over (V)}) can be computed from the vector triangle shown in the Figure. For example,

[0168] $\begin{array}{cc}\begin{array}{c}\stackrel{\rightharpoonup }{B}={\stackrel{\rightharpoonup }{P}}^{\mathrm{UAV}}-{\stackrel{\rightharpoonup }{P}}^{\mathrm{WP1}}\\ {\stackrel{\rightharpoonup }{R}}_{\mathrm{LEG}}={\stackrel{\rightharpoonup }{P}}^{\mathrm{WP2}}-{\stackrel{\rightharpoonup }{P}}^{\mathrm{WP1}}\\ {\stackrel{\rightharpoonup }{u}}_{\mathrm{LEG}}=\frac{{\stackrel{\rightharpoonup }{R}}_{\mathrm{LEG}}}{{\stackrel{\rightharpoonup }{R}}_{\mathrm{LEG}}}\\ \Delta \stackrel{\rightharpoonup }{P}=\stackrel{\rightharpoonup }{B}-\left(\stackrel{\rightharpoonup }{B}·{\stackrel{\rightharpoonup }{u}}_{\mathrm{LEG}}\right){\stackrel{\rightharpoonup }{u}}_{\mathrm{LEG}}\\ \Delta \stackrel{\rightharpoonup }{\stackrel{.}{P}}={\stackrel{\rightharpoonup }{V}}_1-\left({\stackrel{\rightharpoonup }{V}}_1·{\stackrel{\rightharpoonup }{u}}_{\mathrm{LEG}}\right){\stackrel{\rightharpoonup }{u}}_{\mathrm{LEG}}\end{array}& \mathrm{Eq}.9\end{array}$

[0169] These Eq. 9 calculations provide the solution for horizontal channel guidance errors. A correction must be made, however, to the vertical channel guidance error to account for the earth's curvature.

[0170] FIG. 13 is a schematic diagram demonstrating that considerable altitude errors can be introduced by failing to account for the earth's curvature. Since the guidance errors are ultimately rotated into the local vertical coordinate frame, a simple solution exists to performing the great circular arc correction. Through recognizing the fact that each waypoint altitude is stored as an ellipsoidal altitude and that the current vehicle ellipsoidal altitude is always available from the navigation solution, the curvature problem can be mathematically eliminated from the altitude error calculation with instantaneous ECEF to local vertical transformation. Simply stated, the altitude error is computed as the error between the current vehicle ellipsoidal altitude and the geodesic line connecting the two waypoints. Although the path is a curved path in the ECEF frame, the instantaneous rotation to the local vertical frame linearizes the problem.

[0171] FIG. 14 is a schematic diagram demonstrating altitude error calculation in the form of a curvature correction for the vertical guidance error. Using the nomenclature in FIG. 14, the local vertical altitude error (accounting for the earth's curvature) is illustratively computed as:

[0172] $\begin{array}{cc}\Delta H=H_V-H_1-\frac{x}{R_G}\left(H_2-H_1\right)& \mathrm{Eq}.10\end{array}$

[0173] The local vertical velocity error is calculated as:
Δ{dot over (H)}={dot over (H)}_V−|{right arrow over (V)}₁|sin(γ_D)  Eq. 11

[0174] In accordance with one aspect of the present invention, waypoint leg transition logic is premised on a desire to transition waypoint legs when the horizontal acceleration required to drive the vehicle onto the next waypoint leg heading in the desired waypoint leg direction is a minimum. This requirement is achieved mathematically by transitioning waypoint legs when the dot product of the horizontal position error (relative to the next waypoint leg) and the horizontal acceleration error (relative to the next waypoint leg) is zero. Since it is not guaranteed that this dot product will be identically zero on any given compute cycle, the transition occurs when the sign of this dot product changes from positive to negative.

[0175] FIG. 15 is a schematic diagram demonstrating the waypoint leg transition issue with particular coordinate frames to be utilized in an algorithm designed to address the issue. The waypoint leg transition algorithm begins by computing local vertical guidance errors (position and velocity) and an acceleration command vector relative to the next waypoint leg in the same manner that these errors are computed relative to the current waypoint leg. Next a rotation matrix between the local vertical reference frame (E, N) and the next waypoint leg reference frame (Along, Across) is computed as follows:

[0176] $\begin{array}{cc}\left\{\begin{array}{c}\mathrm{Along}\\ \mathrm{Across}\end{array}\right\}=\left[\begin{array}{cc}\sin \left({\Psi }_{\mathrm{leg}}\right)& \cos \left({\Psi }_{\mathrm{leg}}\right)\\ \cos \left({\Psi }_{\mathrm{leg}}\right)& -\sin \left({\Psi }_{\mathrm{leg}}\right)\end{array}\right]\left\{\begin{array}{c}E\\ N\end{array}\right\}& \mathrm{Eq}.12\end{array}$

[0177] The local vertical to waypoint leg reference frame rotation matrix is illustratively denoted T_L^W. The position and acceleration errors relative to the next waypoint leg are then rotated into the next waypoint leg reference frame:
Δ{right arrow over (P)}_W=T_L^WΔ{right arrow over (P)}_LV  Eq. 13
Δ{right arrow over (a)}_cw=T_L^W{right arrow over (a)}_cLV

[0178] The waypoint leg transition illustratively occurs when ΔP_Acrossa_cAcross≦0.

[0179] In accordance with one aspect of the present invention, an enhanced waypoint guidance algorithm is applied to achieve improved path regulation during 3D waypoint turns. Issues arise when two adjoining waypoint segments have different vertical and horizontal slopes, requiring the vehicle to “turn” in both the horizontal and vertical channels. These two waypoint segments form a plane (‘two intersecting lines form a plane’). In accordance with one embodiment, the parameters for this plane are computed and the vehicle is commanded to perform its turn in that plane.

[0180] FIG. 16 is a schematic diagram demonstrating the concept of commanding the vehicle to perform its turn in the derived plane. In accordance with one embodiment, the control law used during the 3D planar turn is:

[0181] $\begin{array}{cc}{\stackrel{\rightharpoonup }{a}}_{\mathrm{cmd}}=-\frac{V^2}{R}{\stackrel{\rightharpoonup }{U}}_{\mathrm{plane}}+{\omega }^2\Delta \stackrel{\rightharpoonup }{P}+2\mathrm{\xi \omega \Delta }\stackrel{\rightharpoonup }{V}+g\stackrel{\rightharpoonup }{U}p& \mathrm{Eq}.14\end{array}$

[0182] where
Δ{right arrow over (P)}={right arrow over (R)}+R_turn{right arrow over (u)}_plane
Δ{right arrow over (V)}=({right arrow over (V)}·{right arrow over (n)}_plane){right arrow over (n)}_plane+({right arrow over (V)}·{right arrow over (u)}_plane){right arrow over (u)}_plane

[0183] R_turn=Vehicle turn radius

[0184] {right arrow over (R)}=relative distance between vehicle and turn center

[0185] The turn radius is illustratively vehicle dependent and the planar parameters (plane center location, plane normal vector, and plane unit vector) are all illustratively computed using basic analytical geometry. This algorithm is illustratively advantageous at least in that it promotes generality for precision path control across a broad class of UAV's.

[0186] The waypoint guidance system is illustratively organized as a linked list of events augmented with smooth turn and leg propagation logic at each station. An event is illustratively, but not limited to, a way point, an orbit pattern, a payload command (e.g., point camera at location x) or some other event. This provides the capability to easily edit the mission plan from the graphical display both during pre-flight mission planning and while the UAV is in the air. If the operator discovers an unknown hazard in the pre-planned flight-path, then he can either “drag-and-drop” existing events or he can delete and insert new events as necessary.

[0187] For illustrative purposes only, table 1 is provided as a sample collection of event parameters.

[0188]

	TABLE 1
	Event Type	Waypoint, figure 8, racetrack,
		ellipse (circle is racetrack with
		equal length and width)
	Waypoint latitude	Geodetic latitude of waypoint or
		orbit pattern center
	Waypoint longitude	Geodetic latitude of waypoint or
		orbit pattern center
	Waypoint Altitude	Ellipsoidal altitude of waypoint or
		orbit pattern center
	Waypoint Speed	Speed setting at waypoint location
	Orbit pattern	Length of desired orbit pattern
	length
	Orbit pattern width	Width of desired orbit pattern
	Orbit pattern	Rotation angle of orbit pattern
	orientation	(relative to true North)
	Number of orbit	Desired number of orbit laps
	laps
	Time in orbit	Desired time to maintain orbit
		pattern (overrides orbit laps if
		greater than minimum threshold)
	Orbit pattern	Offset vector of orbit pattern
	center offset	center from known target location

[0189] B. Loiter Control

[0190] In accordance with one aspect of the present invention, as is indicated by block 134 in FIG. 1, one provided control mode enables an operator to loiter a vehicle over a given station, for example, to monitor a desired surveillance point. The system illustratively enables the operator to either preprogram a set of orbit patterns embedded within a waypoint route or dynamically insert orbit patterns into an existing route in real-time. The operator can illustratively set loiter parameters such as length, width, and orientation (i.e., heading) of the orbit pattern with a simply controlled input operation (e.g., mouse controlled click-and-drag operation on a 2D map displayed as part of the user interface). In accordance with one embodiment, a set of relief or hand-off park modes is also provided in which the vehicle will automatically enter into a default racetrack, a figure-8, or an elliptical orbit pattern upon command from the operator.

[0191] Accordingly, one embodiment of the present invention pertains to system support for an elliptical orbit pattern. The system illustratively enables the operator to select an oval or a constant radius (circular) loiter pattern. In accordance with one embodiment, along with an operator selectable offset vector for the loiter pattern centroid, the operator is also illustratively provided with the capability to select a loiter pattern “heading” relative to north. For circular patterns this option has little value. For elliptical patterns, however, the latter selection option provides the operator with an ability to adjust a loiter pattern to fit virtually any desired geographic location, such as a country's border or a canyon.

[0192] In accordance with one aspect of the present invention, loiter guidance is achieved through two basic guidance laws: 1) Biased pursuit guidance law used to drive the vehicle onto a desired loiter pattern (illustratively referred to herein as loiter capture); and 2) Elliptical guidance law which serves as an inertial path controller designed to slave the vehicle to an elliptical loiter pattern (illustratively referred to herein as loiter guidance).

[0193] FIG. 17, in accordance with one aspect of the present invention, is a schematic diagram defining parameters and coordinate frames used to construct the elliptical loiter guidance law. The desired surveillance point and ellipse center offset, semi-major axis, and semi-minor axis are either preprogrammed into the UAV flight software or input by the operator real-time during a mission. Once the UAV captures the desired loiter pattern, the loiter guidance law is invoked. The loiter guidance error equations are computed in the ellipse reference frame. This frame is defined as (x_E,y_E) in FIG. 17. The transformation matrix from the local vertical reference frame to the ellipse reference frame (T_LV^E) is computed as:

[0194] $\begin{array}{cc}\left\{\begin{array}{c}{x}_E\\ y_E\\ z_E\end{array}\right\}=\left[\begin{array}{ccc}\cos \left({\Psi }_E\right)& -\sin \left({\Psi }_E\right)& 0\\ \sin \left({\Psi }_E\right)& \cos \left({\Psi }_E\right)& 0\\ 0& 0& 1^{\prime }\end{array}\right]\left\{\begin{array}{c}E\\ N\\ U\end{array}\right\}& \mathrm{Eq}.15\end{array}$

[0195] The transformation matrix from the ECEF frame to the ellipse frame is then computed as:
T_ECEF^E=T_LV^ET_ECEF^LV  Eq. 16

[0196] The position of the vehicle is computed relative to the surveillance point in ellipse coordinates as follows:
{right arrow over (P)}_rel^E=T_ECEF^E({right arrow over (P)}_UAV^ECEF−{right arrow over (P)}_S^ECEF)  Eq. 17
where

• • [0197] {right arrow over (P)}_UAV^ECEF=ECEF UAV position
  • [0198] {right arrow over (P)}_S^ECEF=ECEF surveillance point location

[0199] Consistent with basic analytic geometry, the equation for an ellipse can be written in parametric coordinates:
x_E=x_C+b sin(t); y_E=y_c+a cos(t)  Eq. 18

[0200] Utilizing this relationship and assuming that the vehicle is near the desired ellipse, the instantaneous ellipse parametric angle (t) is computed as

[0201] $\begin{array}{cc}t={\tan }^{-1}\left(\frac{a\left(P_{{\mathrm{rel}}_x}^E-x_c\right)}{b\left(P_{\mathrm{rel}y}^E-y_c\right)}\right)& \mathrm{Eq}.19\end{array}$

[0202] It is important to emphasize the assumption that the vehicle is near the desired loiter pattern. This is the assumption that drives the requirement of a second guidance law (loiter capture) to guide the vehicle onto the ellipse. In accordance with one embodiment, “Near the ellipse” is quantified in terms of relative heading and horizontal ground distance. The guidance software is configured to consider the vehicle to be near the ellipse if the horizontal ground distance between the vehicle and the ellipse surface is less than a predetermined distance threshold (e.g., 0.1 nm) and the relative heading error between the vehicle and the ellipse tangent is less than a predetermined angular threshold (e.g., 10 deg.).

[0203] Having computed the instantaneous parametric angle, the desired vehicle position is computed using the ellipse parametric equations:

[0204] $\begin{array}{cc}{\stackrel{\rightharpoonup }{P}}_D^E=\left\{\begin{array}{c}{x}_c+b\sin \left(t\right)\\ y_c+a\cos \left(t\right)\\ 0\end{array}\right\}& \mathrm{Eq}.20\end{array}$

[0205] The desired heading in ellipse coordinates is then computed as:

[0206] $\begin{array}{cc}{\Psi }_D={\tan }^{-1}\left(\frac{a^2\left(P_{D_x}^E-x_c\right)}{b^2\left(P_{D_y}^E-y_c\right)}\right)-\pi & \mathrm{Eq}.21\end{array}$

[0207] The associated desired inertial velocity vector is then computed:

[0208] $\begin{array}{cc}{\stackrel{\rightharpoonup }{V}}_D^E=T_{\mathrm{LV}}^E\left\{\begin{array}{c}{\stackrel{\rightharpoonup }{V}}_1\sin \left({\Psi }_D\right)\\ {\stackrel{\rightharpoonup }{V}}_1\cos \left({\Psi }_D\right)\\ 0\end{array}\right\}& \mathrm{Eq}.22\end{array}$

[0209] Note that a constant altitude loiter is illustratively assumed. The guidance position and velocity errors in local vertical coordinates are computed as follows:
Δ{right arrow over (P)}^LV=[T_LV^E]T({right arrow over (P)}_rel^E−{right arrow over (P)}_D^E)  Eq. 23
Δ{right arrow over (V)}^LV=[T_LV^E]T({right arrow over (V)}_I^E−{right arrow over (V)}_D^E)
where

• • [0210] {right arrow over (V)}_I^E=Inertial velocity vector in ellipse coordinates

[0211] An instantaneous radius of curvature (ρ) can be computed at each point along the ellipse. This curvature vector is normal to the ellipse tangent, which defines the heading to which the vehicle will align the inertial velocity vector. Because the vehicle is slaved to the ellipse, the instantaneous radius of curvature of the ellipse is identically equal to the instantaneous vehicle horizontal turn radius. Hence the ellipse radius of curvature can be used to augment the guidance law, as it will provide the desired steady-state horizontal centripetal acceleration. The radius of curvature is computed as:

[0212] $\begin{array}{cc}\rho =\frac{{\left[b^2{\cos }^2\left(t\right)+a^2{\sin }^2\left(t\right)\right]}^{\frac{3}{2}}}{\mathrm{ab}}& \mathrm{Eq}.24\end{array}$

[0213] The desired centripetal acceleration command in local vertical coordinates can then be computed as:

[0214] $\begin{array}{cc}{\stackrel{\rightharpoonup }{a}}_{\mathrm{cent}}={\left[T_{\mathrm{LV}}^E\right]}^T\left(\frac{{\stackrel{\rightharpoonup }{V}}_I^2}{\rho }\right)\left\{\begin{array}{c}-\sin \left(\eta \right)\\ -\cos \left(\eta \right)\\ 0\end{array}\right\}& \mathrm{Eq}.25\end{array}$

[0215] The local vertical acceleration command vector is computed as:
{right arrow over (a)}_c^LV={right arrow over (a)}_cent−k_pΔ{right arrow over (P)}^LV−k_vΔ{right arrow over (V)}^LV−{right arrow over (g)}^LV+k_pk_FF2.1{right arrow over (V)}_c
{right arrow over (V)}_c=[0 0 V_c]^T=Airspeed command
[{right arrow over (g)}^LV=[0 0 −9.81]^T

[0216] This acceleration command vector is then processed through a translation layer and/or is delivered to the autopilot system.

[0217] In accordance with one aspect of the present invention, the loiter capture algorithm is designed to drive the vehicle onto the desired loiter pattern from any location outside of the planned pattern. In accordance with one embodiment, the loiter capture algorithm simultaneously drives the vehicle onto the desired ellipse at the desired heading utilizing the biased pursuit guidance law and the ellipse tangent lines.

[0218] FIG. 18, in accordance with one embodiment, is a schematic chart demonstrating that, for any point, P, outside of the ellipse there exist two lines passing tangent to the ellipse and containing the point P. The arrows in the figure indicate a desired direction of travel along the ellipse. Although there are two tangent line solutions, accounting for the desired direction of travel reduces the problem to one solution. Upon entrance into loiter capture, the guidance algorithm illustratively solves for the ellipse tangent line that will bring the vehicle onto the ellipse headed in the desired direction of travel along the ellipse. A biased pursuit guidance law is then illustratively used to control the vehicle along the computed tangent line.

[0219] In accordance with one embodiment, the position of the vehicle is first computed relative to the loiter pattern center in ellipse coordinates as follows:
{right arrow over (P)}_rel^E=T_ECEF^E({right arrow over (P)}_UAV^ECEF−{right arrow over (P)}_S^ECEF) −{right arrow over (P)}_center
where

• • [0220] {right arrow over (P)}_UAV^ECEF=ECEF UAV position
  • [0221] {right arrow over (P)}_S^ECEF=ECEF surveillance point location
  • [0222] {right arrow over (P)}_center=ellipse center location relative to surveillance point in ellipse cooridates
    The tangent point on the ellipse is then computed:

[0223] $\begin{array}{cc}{x}_t=\{\begin{array}{cc}-\frac{b\sqrt{y_v^2-a^2}}{y}& x_v=0\\ -\frac{b^2\left(-1+\frac{1}{2}\frac{y_v\left(2b^2{y}_v+2\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)}{a^2{x}_v^2+b^2{y}_v^2}\right)}{x_v}& x_v>0\\ -\frac{b^2\left(-1+\frac{1}{2}\frac{y_v\left(2b^2{y}_v-2\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)}{a^2{x}_v^2+b^2{y}_v^2}\right)}{x_v}& x_v<0\end{array}{y}_t=\{\begin{array}{cc}\frac{a^2}{y_v}& x_v=0\\ \frac{1}{2}\frac{\left(2b^2{y}_v+2\sqrt{a^2{x}_x^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)a^2}{a^2{x}_v^2+b^2{y}_v^2}& x_v>0\\ \frac{1}{2}\frac{\left(2b^2{y}_v-2\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)a^2}{a^2{x}_v^2+b^2{y}_v^2}& x_v<0\end{array}& \mathrm{Eq}.28\end{array}$
where

• • [0224] x_v=P_relx^E=vehicle x position relative to ellipse center
  • [0225] y_v=P_relx^E=vehicle y position relative to ellipse center

[0226] The desired heading is then computed as:

[0227] $\begin{array}{cc}{\Psi }_D={\tan }^{-1}\left(\frac{a^2{x}_t}{b^2{y}_t}\right)-\pi & \mathrm{Eq}.29\end{array}$

[0228] The horizontal acceleration command is formulated in the ellipse capture bearing reference frame. Hence a transformation matrix from the ellipse reference frame to the capture bearing reference frame (T_E^B) is computed.

[0229] $\begin{array}{cc}{T}_E^B=\left[\begin{array}{ccc}\cos \left({\Psi }_D\right)& -\sin \left({\Psi }_D\right)& 0\\ \sin \left({\Psi }_D\right)& \cos \left({\Psi }_D\right)& 0\\ 0& 0& 1\end{array}\right]& \mathrm{Eq}.30\end{array}$

[0230] The vehicle heading error relative to the ellipse capture bearing is computed as:
ΔΨ=Ψ_D−Ψ₁+Ψ_E  Eq. 31
where

[0231] Ψ₁=vehicle ground track angle

[0232] Ψ_E=ellipse heading relative to north

[0233] The position error relative to the ellipse tangent point is computed in the capture bearing reference frame.

[0234] $\begin{array}{cc}\Delta {\stackrel{\rightharpoonup }{P}}^B=T_E^B\left\{\begin{array}{c}{P}_{{\mathrm{rel}}_x}^E-x_t\\ P_{{\mathrm{rel}}_y}^E-y_t\\ P_{{\mathrm{rel}}_z}^E\end{array}\right\}& \mathrm{Eq}.32\end{array}$

[0235] The horizontal acceleration command is computed using the biased pursuit guidance law:
a_ch=−k_pΔP^B_x+k_v|{right arrow over (V)}₁|ΔΨ  Eq. 33

[0236] The total local vertical acceleration command vector is computed as follows:

[0237] $\begin{array}{cc}{\stackrel{\rightharpoonup }{a}}_c^{\mathrm{LV}}={{\left[T_{\mathrm{LV}}^E\right]}^T\left[T_E^B\right]}^T\left\{\begin{array}{c}{a}_{{}_{c_h}}\\ 0\\ k_p\Delta P_z^B-k_v{V}_{1_z}+g+k_p{k}_{{\mathrm{FF}}_{2.1}}{V}_c\end{array}\right\}& \mathrm{Eq}.34\end{array}$
where

• • [0238] V_c=Airspeed command
  • [0239] |g|=9.81

[0240] This acceleration command vector is then processed through a translation function that generates native vehicle autopilot commands.

[0241] As has been alluded to, the present invention also accommodates racetrack and figure-8 path orbit control. FIG. 19 is a schematic diagram demonstrating various segments of the racetrack and figure-8 patterns.

[0242] In one embodiment, the guidance laws used for racetrack orbit patterns are a combination of the waypoint guidance laws and the ellipse guidance laws. The waypoint guidance law is used during the straight leg segments of the orbit patterns and the ellipse guidance law is used during the turn segments of the orbit patterns. The turn segments are constant radius; therefore the conic equations are simplified over that of the ellipse.

[0243] In one aspect of the present invention, the description will now turn to an explanation of mathematical algorithms (step-by-step) for computing a desired vehicle location along the orbit pattern inertial path. This desired location is illustratively an instantaneous point in three-dimensional space that is used to formulate guidance errors. The guidance algorithms for the racetrack and figure-8 patterns illustratively follow the same processing as the ellipse guidance law with slight computational variations that can be noted in the calculations that follow. These calculations are based on the orbit pattern reference point and orbit pattern size and orientation selected by the operator either graphically during real-time route editing or apriori during mission planning. The vehicle enters and exits an orbit pattern via an entrance path and an exit path, respectively. The entrance path to an orbit pattern and the exit path from the orbit pattern are defined as follows: 1) The path from the waypoint preceeding an orbit pattern to the orbit pattern is defined as the tangent line to the orbit pattern that passes through the waypoint (algorithmic computations defined below); and 2) The path from the orbit pattern to the waypoint proceeding the orbit pattern is defined as the tangent line to the orbit pattern that passes through the waypoint (algorithmic computations defined below). The orbit pattern desired location computations are defined below. The coordinate frame definitions and transformations were previously defined.

[0244] In accordance with one embodiment, the processing steps for orbit pattern desired location computations proceed as follows:

• • [0245] STEP ONE—Compute the ECEF position of the orbit pattern reference point:
    {right arrow over (P)}_ref^ECEF=geo2ecef(λ,l,h)  Eq. 35
    where
  • [0246] {right arrow over (P)}_ref^ECEF=ECEF position vector of reference point
  • [0247] λ=Geodetic latitude of reference point
  • [0248] l=Geodetic longitude of reference point
  • [0249] h=Ellipsoidal altitude of reference point
  • [0250] NOTE: “geo2ecef” represents the coordinate transformation defined herein within the Section entitled “Coordinate Frame Definitions”
  • [0251] STEP TWO—Compute the ECEF position of the orbit pattern centroid using the local vertical offset vector (the vertical component of this offset vector is zero).
    {right arrow over (P)}_C^ECEF={right arrow over (P)}_ref^ECEF+[T_ECEF^LV]^T{right arrow over (P)}_offset  Eq.36
    where
  • [0252] T_ECEF^LV=Local vertical to ECEF transformation matrix
  • [0253] {right arrow over (P)}_offset=Local vertical offset vector (vertical component is zero)
  • [0254] STEP THREE—The (x,y) coordinates of the orbit pattern relative to the orbit pattern centroid at the current angle, t, in the orbit pattern reference frame are computed as follows (the z-component of the vector is zero; a is the orbit pattern semi-major axis length and b is the orbit pattern semi-minor axis lentgh):

[0255] $\begin{array}{cc}\begin{array}{c}\Delta P_x^{\mathrm{ELL}}=b\sin \left(t_i\right)\\ \Delta P_y^{\mathrm{ELL}}=\{\begin{array}{cc}a\cos \left(t_i\right)& \mathrm{ellipse}\\ a-b\left(1-\cos \left(t_i\right)\right)& \left\{\mathrm{racetrack}\&-\frac{\pi }{2}\le t\le \frac{\pi }{2}\right\}\\ -a+b\left(1-\cos \left(t_i\right)\right)& \mathrm{otherwise}\end{array}\\ \mathrm{where}\zeta ={\cos }^{-1}\left(\frac{b}{a-b}\right)\end{array}& \mathrm{Eq}.37\end{array}$

• • [0256] STEP FOUR—Rotate the orbit pattern coordinate into the ECEF reference frame:

[0257] $\begin{array}{cc}{\stackrel{\rightharpoonup }{P}}^{\mathrm{ECEF}}={\stackrel{\rightharpoonup }{P}}_c^{\mathrm{ECEF}}+{\left[T_{\mathrm{ECEF}}^E\right]}^T\Delta {\stackrel{\rightharpoonup }{P}}^{\mathrm{ELL}}\mathrm{where}{\stackrel{\rightharpoonup }{P}}^{\mathrm{ELL}}={\left[\begin{array}{c}\Delta P_x^{\mathrm{ELL}}\\ \Delta P_y^{\mathrm{ELL}}\\ 0\end{array}\right]\left[T_{\mathrm{ECEF}}^E\right]}^T=\text{Transpose of ECEF to ellipse coordinate}\text{trasformation matrix}& \mathrm{Eq}.38\end{array}$

• • [0258] STEP FIVE—Compute the latitude and longitude of the orbit pattern coordinate:
    (λ_i,l_i,h_i)=ecef2geo({right arrow over (P)}^ECEF)  Eq. 39
  • [0259] NOTE: “ecef2geo” represents the inverse of the “geo2ecef” coordinate transformation defined herein within the Section entitled “Coordinate Frame Definitions”
  • [0260] STEP SIX—Pass the computed parameters to the guidance law for computation of the autopilot command inputs (e.g., utilizing the algorithms were defined in the preceeding sections).

[0261] The UAV enters a racetrack orbit pattern along a capture path that passes tangent to the orbit pattern. This is the desired capture path due to the fact that the horizontal acceleration command at the point of the capture will be effectively zero, indicating that the vehicle does not require a correction to establish the orbit course at the time of capture.

[0262] In accordance with one embodiment, the processing steps for waypoint to orbit pattern segment calculation proceed as follows (the following algorithm applies to both the preceeding and proceeding waypoint paths):

• • [0263] STEP ONE—Using the ECEF location of the orbit pattern centroid computed in steps 1 and 2 of the orbit pattern desired location computation algorithm compute the position of the waypoint (either preceeding or proceeding the orbit pattern, whichever the case may be) relative to the orbit pattern centroid in the ellipse reference frame as follows:
    Δ{right arrow over (P)}_v^ELL=T_ECEF^E({right arrow over (P)}_w^ECEF−{right arrow over (P)}_c^ECEF)  Eq. 40
    where
  • [0264] Δ{right arrow over (P)}_v^ELL=waypoint position relative to orbit pattern center in ellipse reference frame
  • [0265] {right arrow over (P)}_w^ECEF=waypoint ECEF position
  • [0266] {right arrow over (P)}_c^ECEF=orbit pattern centroid ECEF position
  • [0267] T_ECEF^E=ECEF to ellipse reference frame coordinate transformation matrix
  • [0268] STEP TWO—Compute the orbit pattern tangent point which lies on the line passing through the waypoint:

[0269] $\begin{array}{cc}{x}_t=\{\begin{array}{cc}-k\frac{b\sqrt{y_v^2-a^2}}{y_v}& x_v=0\\ -\frac{b^2\left(-1+\frac{1}{2}\frac{y_v\left(2b^2{y}_v+2k\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)}{a^2{x}_v^2+b^2{y}_v^2}\right)}{x_v}& x_v>0\\ -\frac{b^2\left(-1+\frac{1}{2}\frac{y_v\left(2b^2{y}_v+2k\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)}{a^2{x}_v^2+b^2{y}_v^2}\right)}{x_v}& x_v<0\end{array}{y}_t=\{\begin{array}{cc}\frac{a^2}{y_v}& x_v=0\\ \frac{1}{2}\frac{\left(2b^2{y}_v+2k\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)a^2}{a^2{x}_v^2+b^2{y}_v^2}+\mathrm{kd}& x_v>0\\ \frac{1}{2}\frac{\left(2b^2{y}_v-2k\sqrt{a^2{x}_v^4-a^2{x}_v^2{b}^2+b^2{y}_v^2{x}_v^2}\right)a^2}{a^2{x}_v^2+b^2{y}_v^2}-\mathrm{kd}& x_v<0\end{array}\begin{array}{cc}\mathrm{where}b=\mathrm{semi}\text{-}\mathrm{minor}\mathrm{axis}\left(\mathrm{half}\mathrm{orbit}\mathrm{region}\mathrm{box}\mathrm{width}\right)& \\ a=\{\begin{array}{cc}\mathrm{semi}\text{-}\mathrm{major}\mathrm{axis}\left(\mathrm{half}\mathrm{orbit}\mathrm{region}\mathrm{box}\mathrm{length}\right)& \mathrm{ellipse}\\ b& \mathrm{racetrack}\end{array}& \end{array}d=\left(\mathrm{half}\mathrm{orbit}\mathrm{region}\mathrm{box}\mathrm{length}\right)\text{-}\left(\mathrm{half}\mathrm{orbit}\mathrm{region}\mathrm{box}\mathrm{width}\right)\text{}k=\{\begin{array}{cc}1& \mathrm{for}\mathrm{preceeding}\mathrm{waypoint}\\ -1& \mathrm{for}\mathrm{proceeding}\mathrm{waypoint}\end{array}{x}_v=\Delta {\stackrel{\rightharpoonup }{P}}_v^{\mathrm{ELL}}\left(x\right)y_v=\{\begin{array}{cc}\Delta {\stackrel{\rightharpoonup }{P}}_v^{\mathrm{ELL}}\left(y\right)& \mathrm{ellipse}\mathrm{or}{x}_v=0\\ \Delta {\stackrel{\rightharpoonup }{P}}_v^{\mathrm{ELL}}\left(y\right)-\mathrm{kd}& \left\{\mathrm{racetrack}\right\}\mathrm{and}{x}_v>0\\ \Delta {\stackrel{\rightharpoonup }{P}}_v^{\mathrm{ELL}}\left(y\right)+\mathrm{kd}& \left\{\mathrm{racetrack}\right\}\mathrm{and}{x}_v<0\end{array}& \mathrm{Eq}.41\end{array}$

• • [0270] STEP THREE—Rotate the orbit pattern tangent point into the ECEF reference frame:

[0271] $\begin{array}{cc}\begin{array}{c}{\stackrel{\rightharpoonup }{P}}_t^{\mathrm{ECEF}}={\stackrel{\rightharpoonup }{P}}_c^{\mathrm{ECEF}}+{\left[T_{\mathrm{ECEF}}^E\right]}^T\Delta {\stackrel{\rightharpoonup }{P}}_t^{\mathrm{ELL}}\\ \mathrm{where}\Delta {\stackrel{\rightharpoonup }{P}}^{\mathrm{ELL}}=\left[\begin{array}{c}{x}_t\\ y_t\\ 0\end{array}\right]\\ {\left[T_{\mathrm{ECEF}}^E\right]}^T=\mathrm{Transpose}\mathrm{of}\mathrm{ECEF}\mathrm{to}\\ \mathrm{ellipse}\mathrm{coordinate}\mathrm{transformation}\mathrm{matrix}\end{array}& \mathrm{Eq}.42\end{array}$

• • [0272] STEP FOUR—Compute the latitude and longitude of the orbit pattern tangent point:
    (λ_t,l_t,h_t)=ecef2geo({right arrow over (P)}_t^ECEF)  Eq. 43
  • [0273] STEP FIVE—Insert a waypoint leg connecting the waypoint and the computed orbit pattern tangent point

[0274] FIG. 20 is a schematic diagram demonstrating an example of a programmed route using the defined loiter algorithms. Within FIG. 20, items 4, 7, and 9 represent orbit patterns and the remaining numbered elements represent waypoints. In accordance with one embodiment, the orbit guidance laws are configured to allow the operator to input either a desired orbit time or a desired number of orbit laps. The UAV will exit the orbit pattern when either the specified orbit time or specified number of orbit laps has been completed.

[0275] An interesting characteristic of the loiter pattern embodiments of the present invention is that one is able to mathematically define a desired location on a path in association with a given point in time. Points can be defined relative to a center point, even relative to a moving center point.

[0276] C. Remote Directional Command Mode

[0277] In accordance with one aspect of the present invention, as is inferred by block 140 in FIG. 1, a remote directional command (RDC) control mode is implemented. The versatility of the overall control system design of the described VACS architecture makes implementation of an RDC control mode relatively straightforward.

[0278] Inertial turn rates are kinematically related to acceleration through multiplication of the inertial velocity magnitude (a=Vω). Hence, in the horizontal channel, an acceleration command can be generated for the autopilot by multiplying a desired or commanded turn rate by the inertial velocity magnitude. To accomplish this guidance law, the operator's horizontal control stick input is linearly mapped to a horizontal turn rate command in which the maximum stick position is equal to the maximum allowable horizontal turn rate.

[0279] The vertical channel manual control mode is a little different. For most UAV applications the vertical stick position will translate into a climb/descent rate command. It is more intuitive for operators to control the vertical channel via climb rate. Hence, in accordance with one embodiment, a look-up table of climb performance as a function of vehicle state (altitude and airspeed) is incorporated into the algorithms (the table is illustratively programmable to accommodate multiple UAV platforms). On each pass through the guidance software, the maximum climb rate is computed. The vertical control stick location is then linearly mapped to this maximum climb rate (center stick=zero climb rate, max stick=max climb rate). This climb rate command is then used to compute a flight path angle (gamma) command, which is fed into a gamma control guidance law (defined later in this section). A combination of control input device rate limiting and guidance command rate limiting illustratively results in a robust design that prevents the operator from being able to overdrive, stall, spin or in any other way crash the vehicle.

[0280] It should be noted that practically any known commercial control input device can be utilized for RDC control without departing from the scope of the present invention. For example, a USB game pad can be utilized thereby providing relative compactness and versatility. In accordance with one embodiment, the game pad utilized has a throttle slide control, a plurality of control buttons, and two thumb control sticks—one of which is used to steer the UAV and the other used to steer the UAV imaging sensor.

[0281] In accordance with one aspect of the present invention, the control system software translates the vehicle control stick motion as follows:

• • [0282] 1. Forward (away from the operator)—descent rate command
  • [0283] 2. Backward (toward the operator)—climb rate command
  • [0284] 3. Left—left turn rate command
  • [0285] 4. Right—right turn rate command
    The raw stick position readings are illustratively calibrated and normalized to range from −1.0 to 1.0 in both channels where (0,0) represents the center (neutral) stick position. When the stick is in the neutral position (0,0), the vehicle flies a straight and level profile. In accordance with one embodiment, the off-board control system software (i.e., the software resident on the ground station) maps the stick range limits as follows:
  • [0286] 1. Maximum horizontal stick position (±1)—max vehicle turn rate
  • [0287] 2. Maximum forward stick position (+1)—max vehicle descent rate
  • [0288] 3. Maximum aft stick position (−1)—max vehicle climb rate

[0289] In one aspect of the present invention, the vehicle max climb rate is a function of altitude and airspeed. The off-board control software illustratively maintains a database of the vehicle max climb rate and interpolates based on current flight conditions to obtain the instantaneous control limit. This methodology will prevent the operator from overdriving the vehicle. A similar methodology is used for descent rate, although the descent rate is not as restrictive as the climb rate and requires a more empirical approach to setting.

[0290] In accordance with one aspect of the present invention, the following equations define the basic simplified manual control approach. The algorithm maintains a set of vertical and horizontal reference conditions that are used to command the vehicle when the operator lets go of the stick. First, the vertical stick position is checked for movement and the associated vertical commands and reference conditions are computed:

[0291] $\begin{array}{cc}\begin{array}{c}\mathrm{if}{\delta }_{v_i}-{\delta }_{v_{i-1}}>\varepsilon \\ H_{\mathrm{ref}}=H\\ R=0\\ \mathrm{else}\\ R_i=R_{i-1}+V_{\mathrm{horz}}\Delta t\\ \mathrm{endif}\\ {\stackrel{.}{H}}_c={\delta }_{v_1}{\stackrel{.}{H}}_{\max }\\ {\gamma }_c={\sin }^{-1}\left(\frac{{\stackrel{.}{H}}_c}{V_1}\right)\\ \mathrm{where}{\delta }_v=\mathrm{vertical}\mathrm{control}\mathrm{stick}\mathrm{position}\\ \varepsilon =\mathrm{control}\mathrm{stick}\mathrm{measurement}\mathrm{noise}\text{/}\mathrm{freeplay}\mathrm{tolerance}\\ H_{\mathrm{ref}}=\mathrm{reference}\mathrm{altitude}\\ H=\mathrm{vehicle}\mathrm{altitude}\\ R=\mathrm{integrated}\mathrm{path}\mathrm{length}\mathrm{during}\mathrm{vertical}\mathrm{maneuver}\\ {\stackrel{.}{H}}_c=\mathrm{climb}\text{/}\mathrm{descent}\mathrm{rate}\mathrm{command}\\ \stackrel{.}{H}=\mathrm{vehicle}\mathrm{altitude}\mathrm{rate}\\ {\gamma }_c=\mathrm{flight}\mathrm{path}\mathrm{angle}\mathrm{command}\\ V_1=\mathrm{vehicle}\mathrm{ineritial}\mathrm{velocity}\mathrm{magnitude}\end{array}& \mathrm{Eq}.44\end{array}$
Next, the horizontal stick is checked for movement and the associated horizontal commands and reference conditions are computed:
if |δ_h|>ε  Eq. 45
{dot over (Ψ)}_c=δ_h{dot over (Ψ)}_max
Ψ_ref=Ψ_t
{right arrow over (P)}_ref^LV={0,0}^T
else
{right arrow over (P)}_refi={right arrow over (P)}_refi−1^LV+{right arrow over (V)}_hΔt
{right arrow over (P)}_ref^W=T_LV^W{right arrow over (P)}_ref^LV
endif
where δ_h=horizontal control stick position

• • [0292] {dot over (Ψ)}_c=horizontal turn rate command
  • [0293] {dot over (Ψ)}=horizontal turn rate
  • [0294] Ψ_ref=reference heading
  • [0295] Ψ_t=vehicle ground track angle
  • [0296] {right arrow over (P)}_ref=reference position

[0297] The above equations illustrate how trajectory synthesis is employed to guide the vehicle on a straight and level path when the control stick is returned to zero. This synthesis technique generates an inertial path to which the vehicle guides, thus ensuring that inertial sensor errors do not cause the vehicle to deviate from the operator's expected course.

[0298] The airspeed command is computed based on the slide control setting:
V_c=V_min+δ_t(V_max−V_min)  Eq. 46
where

• • [0299] δ_t=slide control setting

[0300] Any of a variety of vertical channel control schemes can be implemented without departing from the scope of the present invention, including both position and velocity reference control laws. It is intuitively obvious that when the operator commands a climb or descent via the manual control operation, the only altitude of concern is the altitude at which to level off. Hence, the actual implementation of the control law does not require a position-slave component. This reduces the order of the control law to a first order control law in which the velocity command term is acted upon to generate an acceleration command to the autopilot. In accordance with one embodiment, the following perturbational first-order control law is illustratively used for the altitude rate control:

[0301] $\begin{array}{cc}\begin{array}{c}{a}_{c_{\mathrm{up}}}=\frac{V_1}{\tau }\left(\gamma -{\gamma }_c\right)-g\\ \mathrm{where}\\ a_{c_{\mathrm{up}}}=\mathrm{local}\mathrm{vertical}\mathrm{UP}\mathrm{acceleraion}\mathrm{command}\\ \gamma =\mathrm{flight}\mathrm{path}\mathrm{angle}\\ {\gamma }_c=\mathrm{flight}\mathrm{path}\mathrm{angle}\mathrm{command}={\sin }^{-1}\left(\frac{{\stackrel{.}{h}}_c}{V}\right)\\ {\stackrel{.}{h}}_c=\mathrm{altitude}\mathrm{rate}\mathrm{command}\\ \tau =\mathrm{guidance}\mathrm{law}\mathrm{time}\mathrm{constant}\\ g=\mathrm{acceleration}\mathrm{of}\mathrm{gravity}\\ V_1=\mathrm{inertial}\mathrm{velocity}\mathrm{magnitude}\end{array}& \mathrm{Eq}.47\end{array}$

[0302] In one embodiment, the time constant is a tunable parameter that can be adjusted for specific platforms. For example, the time constant used for a given vehicle might be 0.3 seconds, whereas the time constant used for another vehicle might be 0.1 seconds. The vertical channel guidance generally works in coordination with the automatic speed control loop. In other words, simply commanding a constant throttle setting as opposed to a constant speed setting can easily drive the vehicle into a stall condition when maximum (or near maximum) climb rates are commanded. By including the automatic speed control design and mapping the operator's “throttle” control input to a speed command as opposed to a throttle setting the problem is alleviated.

[0303] In accordance with one embodiment, the horizontal acceleration command is computed as

[0304] $\begin{array}{cc}{a}_{c_h}=\{\begin{array}{cc}-k_p{\stackrel{\rightharpoonup }{P}}_{\mathrm{ref}}^W\left(\mathrm{across}\right)-k_vV_{\mathrm{horz}}\left({\Psi }_t-{\Psi }_{\mathrm{ref}}\right)& {\delta }_h\le \varepsilon \\ V_1{\stackrel{.}{\Psi }}_c& {\delta }_h>\varepsilon \end{array}& \mathrm{Eq}.48\end{array}$

[0305] It should be noted that when the horizontal stick is in the neutral location a biased pursuit guidance law is used to maintain a constant heading. The local vertical acceleration command vector is then illustratively computed as:

[0306] $\begin{array}{cc}{\stackrel{\rightharpoonup }{a}}_c^{\mathrm{LV}}=\left\{\begin{array}{c}{a}_{c_h}\cos \left({\Psi }_t\right)\\ -a_{c_h}\sin \left({\Psi }_t\right)\\ a_{c_{\mathrm{UP}}}\end{array}\right\}& \mathrm{Eq}.49\end{array}$

[0307] This acceleration command vector is then illustratively processed through a translation layer and delivered to the autopilot system.

[0308] An additional aspect of the present invention pertains to control stick command rate limiting. A key desired objective of the simplified manual control modes described herein is that the control modes will resist the operator's ability to overdrive the vehicle. In accordance with one embodiment, a robust, algorithmic approach to aid in the achievement of this objective is to implement a rate limit on the operator's control stick command inputs. A simple rate-limiting algorithm has a dynamic effect similar to passing the commands through a low-pass filter. The rate limiting essentially attenuates high frequency command inputs. The benefit to the controller is that rate limiting the command inputs enables an elimination of high frequency “jerks” from the command stick. Further an avoidance is enabled of inadvertent and unnecessarily large steps and high frequency impulses directed to the controller. This, in turn, minimizes the transient effects of the closed-loop on the human operator's perception of the vehicle response to his/her commands. In other words, with the control stick rate limiting algorithm functioning, the operator always sees the vehicle respond smoothly to the directional commands that he/she is supplying. In accordance with one embodiment, the control stick rate limiting is a tunable parameter within VACS and can be adjusted to satisfy the specific performance desires of a given operator with a given vehicle under VACS control.

[0309] Another aspect of the present invention pertains to an automatic speed control loop. Important to the application of a robust simplified manual control capability is the ability of the embedded controller to maintain speed, even through harsh maneuvering environments. Consider a scenario wherein an operator commands a hard turn, a max climb, or a combined climb and turn maneuver, the VACS controller will rapidly orient the vehicle into the desired maneuver (flight path and turn rate). The maneuver, in turn, will require the vehicle to pull a large angle-of-attack, which results in increased drag, or to fly a glide slope in which the effects of gravity in the axial channel are significant enough to induce a rapid deceleration. To expect the operator to keep up this rapidly changing dynamic environment by manually adjusting the throttle would directly oppose the goal of the simplified manual control design. Hence, in accordance with one embodiment of the present invention, an automatic speed control loop is coupled into the system. A basic implementation allows the operator to enter a preprogrammed speed setting (cruise for best range, cruise for best endurance, cruise at max speed, etc) or a manual speed setting using a typical joystick throttle input. For the manual speed setting, the control stick throttle setting is not mapped to throttle setting, but rather mapped to a speed command that is linearly proportional to the control setting. In other words, the minimum control setting maps to the vehicle minimum control speed and the maximum control setting maps to the vehicle maximum cruise speed. The remaining settings are mapped linearly between the min and max speeds.

[0310] As the vehicle decelerates through commanded maneuvers, the automatic speed loop responds and adjusts the throttle setting to maintain the desired speed programmed by the operator. Even as the operator adjusts his manual speed control, the flight software is simply adjusting the speed command to the autospeed loop, which is always running. The advantage is that the bandwidth of the control system is higher than the bandwidth of a human operator; hence, using VACS, the operator generally cannot command a maneuver that ultimately drives the vehicle to stall—the flight computer is continuously adjusting the throttle to maintain the proper speed setting.

[0311] Another aspect of the present invention pertains to climb gradient limiting. When mapping the vertical control stick command to a climb rate command, the vehicle climb rate performance capability is illustratively taken into account. The maximum climb rate of the vehicle directly corresponds to the maximum vertical control stick deflection. When a combined climb and turn maneuver is commanded, the net reduction in climb rate capability resulting from the out-of-plane acceleration component required to generate the turn rate is accounted for. There is a closed form analytic climb rate reduction that can be computed to account for the turn. In accordance with one embodiment, this reduction in climb rate is computed as:

[0312] $\begin{array}{cc}\begin{array}{c}\Delta \stackrel{.}{h}=-\frac{2\frac{\partial C_D}{\partial \left(C_L^2\right)}{m}^2{\stackrel{.}{\Psi }}^{2}V}{\rho g{S}_{\mathrm{ref}}}\\ \mathrm{where}\\ \frac{\partial C_D}{\partial \left(C_L^2\right)}=\mathrm{vehicle}\mathrm{drag}\mathrm{polar}\mathrm{constant}\left(k\right)\\ m=\mathrm{vehicle}\mathrm{mass}\\ \stackrel{.}{\Psi }=\mathrm{turn}\mathrm{rate}\mathrm{command}\\ V=\mathrm{inertial}\mathrm{velocity}\\ \rho =\mathrm{air}\mathrm{density}\\ g=\mathrm{acceleration}\mathrm{of}\mathrm{gravity}\\ S_{\mathrm{ref}}=\mathrm{aerodynamic}\mathrm{reference}\mathrm{area}\end{array}& \mathrm{Eq}.50\end{array}$

[0313] The maximum climb rate used to generate the flight path reference command during the manual control mode is reduced by the amount computed using the above equation. The combination of this reduction, along with the limiting algorithms and speed control loop discussed in the preceding sections offers a robust manual control system design that prevents the operator from overdriving the UAV.

[0314] D. Line-of-Sight Slave Control Mode

[0315] In accordance with one aspect of the present invention, as is indicated by block 136 in FIG. 1, a line-of-sight (LOS) slave control mode is implemented. The versatility of the overall control system design of the described VACS architecture makes implementation of this control mode relatively straightforward.

[0316] The underlying operational concept of the LOS slave control mode is illustratively defined by the fact that the operator is ultimately interested in the imagery captured and transmitted by the UAV. The goal of the guidance mode therefore becomes to offer the operator the capability to manually slew the UAV sensor while surveying a battlefield or other topological region with complete disregard for the aviation or direction of the UAV. To accomplish this guidance objective, the vehicle is slaved to the sensor line-of-sight. To maximize the operator's probability of visual object recognition, the guidance policy is to align the heading of the UAV to the horizontal sensor line-of-sight. With this policy, the vehicle is always commanding a path toward the desired surveillance area. A simple pursuit guidance law is employed to achieve the stated guidance goal.

[0317] In accordance with one embodiment of LOS slave control, the applicable guidance law commands the nose of the UAV to align with centerline of the gimbaled sensor by issuing the following horizontal acceleration command:

[0318] $\begin{array}{cc}{a}_{c_h}=\{\begin{array}{cc}-k_p{\stackrel{\rightharpoonup }{P}}_{\mathrm{ref}}^W\left(\mathrm{across}\right)-k_vV_{\mathrm{horz}}\left({\Psi }_t-{\Psi }_{\mathrm{ref}}\right)& {\delta }_h\le \varepsilon \\ -K_VV_1\mathrm{\Delta \Psi }& {\delta }_h>\varepsilon \end{array}& \mathrm{Eq}.51\end{array}$
ΔΨ represents the angle between the vehicle centerline and the sensor horizontal line-of-sight angle. The sensor horizontal line-of-sight angle is derived from the platform gimbal angles.

[0319] Generally speaking, the directional-response autopilot, combined with the stabilized platform, allows a single minimally trained operator to easily conduct a UAV surveillance mission. A further level of user simplification is achieved by combining seeker designation command logic with the outer loop guidance. This mixing provides Line-of-Sight Slave mode capability in which the operator's point of reference is the image scene transmitted from the UAV's on-board camera. In this mode the operator does not provide direction commands to the UAV. Instead, the operator focuses his attention on the tactical situation display, commanding the look angle of the UAV's on-board sensor to survey the battlefield (or other topographical region for non-military applications) while the UAV autonomously commands a flight profile which is slaved to the operator's sensor line-of-sight commands. This integration of the camera platform with the guidance provides the following benefits:

• • [0320] 1. Time-on-station loiter control which can be easily selected and designated.
  • [0321] 2. Further reduction of workload on the operator, who can now focus primarily on the surveillance aspects of the mission.
  • [0322] 3. An easily adaptable relative Navigation method.

[0323] FIG. 21 is a diagrammatic illustration demonstrating how LOS slave control is implemented with the ground station display in accordance with one aspect of the present invention. The display is illustratively a top-view with a schematic of the aircraft for easier conceptualization. The outer circle around the aircraft is illustratively a projection of the entire field-of-view onto the ground. The smaller pie-shaped queue is illustratively a ground projection of the current seeker borsight position. These are calculated by the ground station software from the positional information and seeker angle sent across the data-link. The remote operator can illustratively opt to either keep the cursor active as the continual steering point, or he/she can designate a “surveillance-point” by clicking on a desired ground location. In the latter case, the staring point would be captured so the cursor could be moved to a new constant location.

[0324] If the pilot chooses a surveillance location outside the total FOV, then the outer loop guidance will illustratively follow a command-to-LOS mode guide law until the UAV flight path points toward the target. Once the desired staring-point comes within a minimum range threshold, the guidance automatically trips into a loiter pattern (either constant-radius or elliptical) to maintain a station with a single key-click while he/she conducts other activities. FIGS. 22A & 22B together demonstrate the surveillance-point approach scenario.

[0325] If a constant location is selected within the minimum turning radius, then the guidance will fly over the surveillance-point and plan an out-and-back pattern to avoid a singularity in the loiter guide-law. This can be easily achieved by inserting waypoint legs autonomously. If the operator chooses, he/she can select a standoff range (or accept the default range) for surveillance over a hostile target. The line-of-sight commands will also comprehend the offset location to track on the desired location. This is achieved by inserting the offset range vector in the positional component of the loiter guide-law.

[0326] The following simplified equations are used to show the basic structure of the LOS Slave mode guidance:

[0327] $\begin{array}{cc}\mathrm{If}\left(R_{\mathrm{Target}}>\mathrm{Loiter\_Threshold}\right)\mathrm{then}{\stackrel{.}{\psi }}_{\mathrm{Cmd}}=K_{\stackrel{.}{\psi }}\left({\lambda }_{\mathrm{Horiz}}-{\psi }_{\mathrm{Heading}}\right){\stackrel{.}{\gamma }}_{\mathrm{Cmd}}=K_H\left(H_{\mathrm{CMD}}-H\right)+H_{\stackrel{.}{H}}\stackrel{.}{H}+\frac{g}{V}\mathrm{else}{\stackrel{.}{\psi }}_{\mathrm{Cmd}}=K_{\stackrel{.}{\psi }}\Delta \Psi +K_p(P_{\mathrm{Turn}}-{\stackrel{\_}{R}}_{\mathrm{Target}}+{\stackrel{\_}{R}}_{\mathrm{Stand}\text{-}\mathrm{Off}}{\stackrel{.}{\gamma }}_{\mathrm{Cmd}}=K_H\left(H_{\mathrm{CMD}}-H\right)+K_{\stackrel{.}{H}}\stackrel{.}{H}+\frac{g}{v}\mathrm{endif}\mathrm{where}{R}_{\mathrm{Target}}=\mathrm{Horizontal}\mathrm{Range}\text{-}\mathrm{to}\text{-}\mathrm{Target}{\stackrel{.}{\psi }}_{\mathrm{Cmd}}=\mathrm{Horizontal}\mathrm{Turning}\mathrm{Rate}\mathrm{Command}\Delta \Psi =\mathrm{Heading}\mathrm{Error}\mathrm{Relative}\mathrm{To}\mathrm{Loiter}\mathrm{Path}{\lambda }_{\mathrm{Horiz}}=\mathrm{Horizontal}\mathrm{Line}\text{-}\mathrm{of}\text{-}\mathrm{Sight}\mathrm{to}\mathrm{Target}{\stackrel{.}{\gamma }}_{\mathrm{Cmd}}=\mathrm{Vertical}\mathrm{Turning}\mathrm{Rate}\mathrm{Command}{\Psi }_{\mathrm{Heading}}=\mathrm{Heading}\mathrm{Angle}{P}_{\mathrm{Turn}}=\mathrm{Loiter}\mathrm{Turning}\mathrm{Radius}H=\mathrm{Altitude}g=\mathrm{Gravity}\mathrm{Acceleration}\mathrm{Magnitude}V=\mathrm{Vehicle}\mathrm{Inertial}\mathrm{Velocity}\mathrm{Magnitude}& \mathrm{Eq}.52\end{array}$

[0328] The above equations show two active horizontal guidance terms when flying the constant turning radius circle. The first term is the damping term which drives the vehicle to align its ground track with the desired circular loiter pattern and is the dominating term. The second term is a positional term to help maintain the constant arc.

[0329] In accordance with one aspect of the present invention, sensor-slave mode commands are generated by an autonomous line-of-sight driven function, in which the command objectives are generated by the necessities of the function rather than by an operator. For example, a function designed to command a raster-scan of a particular surveillance area, or a function designed to scan a long a roadway could be used to generate sensor slave commands. Another example is a function designed to generate line-of-sight commands for UAV-to-UAV rendezvous formation flying.

[0330] E. Ground Collision Avoidance System (GCAS)

[0331] In accordance with one aspect of the present invention, as is indicated by block 120 in the FIG. 1 architecture, a ground collision avoidance system (GCAS) provides an automated mechanism enabling the control system to avoid terrain without having to task the operator with studying altitude above ground for each vehicle under his or her control. In accordance with one embodiment, the GCAS provides the operator with some form of situational awareness information about an upcoming collision (e.g., a warning signal). If the user does not react to that information, the GCAS will automatically avoid the terrain and let the user know the system is in an auto-avoidance mode. During this mode, the user is illustratively locked out from making flight path changes until the system has cleared the offending terrain.

[0332] In accordance with one embodiment, the operator is provided with a timer display that counts down a time period within which the operator can manually avoid a high potential terrain collision. If the operator does not manually steer off of the collision path during the time period, then the GCAS will initiate the auto-avoidance mode.

[0333] In accordance with one embodiment, an altitude profile sensor is set up to provide data for GCAS purposes. While other known sensors can be utilized without departing from the scope of the present invention, one suitable ground terrain sensor system is the Digital Terrain Elevation Data (DTED) Level 1 database available from the National Imagery and Mapping Agency (NIMA). The spacing for Level 1 DTED is approximately 93 meters, which somewhat limits the amount of surface information the GCAS algorithm uses. However, the GCAS algorithm is illustratively generic and can accept Level 2 DTED for a higher resolution model. It should be noted that it is also within the scope of the present invention to adopt even more advanced terrain description mechanisms to provide terrain topology map information for the ground collision avoidance logic.

[0334] In accordance with one embodiment, a first input to the GCAS is a desired clearance height above terrain for a vehicle to be controlled. Once the desired clearance has been defined, the GCAS algorithm produces a terrain altitude profile. The profile is created from the DTED maps using a scan pattern that accounts for Navigation and DTED errors.

[0335] FIG. 23 is a schematic representation of a top view of a scan pattern within the context of the GCAS. The scan pattern starts at the vehicle position. A horizontal uncertainty box is generated. A maximum terrain altitude is then calculated within the uncertainty box. The uncertainty box is then propagated forward adjusting for heading and any other uncertainty. The algorithm then determines the maximum altitude in the new uncertainty boxes and continues forward an amount to occupy a limited fly-out time (e.g., a 60 second fly-out). The maximum values for these uncertainty boxes are used to feed the terrain profile for the GCAS guidance.

[0336] The philosophy behind the design of the GCAS system is to take the current vehicle position and fly out a medium fidelity simulation as if the operator had commanded a maximum g pull up. While the simulation performs this pull up, the algorithm monitors vehicle altitude and ground altitude and attempts to predict at what point the vehicle will intersect the terrain.

[0337] FIG. 24 is a schematic diagram demonstrating of a sample trajectory. Assuming the vehicle is flying with current velocity V_o, the algorithm starts at the current vehicle position and flies a maximum g pull up trajectory. The maximum g pull up is an acceleration command generated according to the following equation:

[0338] $\begin{array}{cc}{a}_c=\frac{{\mathrm{QSC}}_{L_{\max }}}{m}\mathrm{where}Q=\mathrm{dynamic}\mathrm{pressure}S=\mathrm{vehicle}\mathrm{aerodynamic}\mathrm{reference}\mathrm{area}{C}_{L_{\max }}=\mathrm{vehicle}\mathrm{maximum}\mathrm{lift}\mathrm{coefficient}m=\mathrm{vehicle}\mathrm{mass}& \mathrm{Eq}.53\end{array}$
The algorithm then assumes a constant initial velocity and projects the trajectory along the velocity line to estimate a time to fly up. The time to fly up represents the time to start the maneuver in order to avoid the terrain by an amount equal to the minimum descent altitude. The minimum descent altitude is a constant and represents the minimum height above the terrain for the platform through the terrain avoidance mode.

[0339] After the algorithm finds the minimum altitude above ground through the fly-out trajectory, the closure rate is computed based on the initial velocity and the velocity at the minimum altitude above ground.

[0340] $\begin{array}{cc}{V}_c=\frac{V_{H,0}*V_{U,\mathrm{Min}\mathrm{Agl}}-V_{H,\mathrm{Min}\mathrm{Agl}}*V_{U,0}}{{\overrightarrow{V}}_{\mathrm{Min}\mathrm{Agl}}}& \mathrm{Eq}.54\end{array}$

[0341] Once the closing rate has been computed, the value is limited (e.g., limited to 2 feet/second) to avoid division by zero problems in the time to fly up calculation.
V_c=max(V_c,2.0)  Eq. 55

[0342] Once the closure rate computation is complete, the time to fly up is calculated as:

[0343] $\begin{array}{cc}\mathrm{TTFU}=\frac{\left(H_{\mathrm{Min}\mathrm{Agl}}-\mathrm{MDA}\right)}{V_c}& \mathrm{Eq}.56\end{array}$

[0344] The MDA variable represents the minimum descent altitude, or the minimum altitude the vehicle should attain during the climb out. in accordance with one embodiment, the time to fly up is computed periodically (e.g., every 1 Hz) and reported to the operator station (i.e., the ground control station). Should the time to fly up reduce to zero, the guidance code will perform the maximum g pull up maneuver while ignoring any commands from the operator station. Once the fly out is complete and the time to fly up returns to a predetermined threshold (e.g., greater than 10 seconds), control is relinquished and returned to the operator station.

[0345] In accordance with one embodiment, in order to perform the simulation in faster than real time, the high fidelity simulation is updated for computational simplicity. Accordingly, the design flies a paired down version of the vehicle simulation in a faster than real-time environment to estimate when the vehicle might impact the ground. For example, the baseline simulation can be adapted with the following changes:

• • [0346] Truth Navigation model
  • [0347] Truth actuator models
  • [0348] No wind model
  • [0349] Reduced simulation time step to 16 Hz

[0350] These are examples of changes that can be made to enable performance of a flyout simulation of the vehicle in a faster than real-time environment.

[0351] In accordance with one embodiment, the simulation has the capability to fly out 10 seconds of medium fidelity data and then extrapolate for another 50 seconds of data giving a 1 minute window of simulated data. The data provides time for the max g-pull up maneuver to execute and acquire the desired flight path angle. Once that flight path angle is captured, an inertial propagation for the next 50 seconds provides an accurate assessment of the vehicle motion.

[0352] In accordance with one embodiment, the operator station (e.g., the ground control station including the operator interface) is configured to provide the operator with an opportunity to understand that the vehicle is about to go into a GCAS maneuver. For example, the time to fly up variable from the GCAS simulation is transmitted to the operator station. If the time to fly up value reduces to a value less than or equal to a predetermined value (e.g., 10 seconds), an indicator is provided to the operator (e.g., the vehicle on the display turns yellow) and a counter is added to show the estimated time to fly up. Should that number reduce to zero, an indication is provided (e.g., the vehicle turns red) showing that the operator no longer has control of the vehicle and the ground collision avoidance maneuver is currently being executed.

IX. Translator

[0353] As was described in relation to FIG. 5, a translation layer can be implemented to translate guidance commands into reference commands appropriate for the specific autopilot implementation.

[0354] In accordance with one embodiment, an exemplary translation layer implementation will now be provided. After the guidance algorithms execute, the outputs are translated to the native vehicle autopilot commands. The equations below provide example kinematic translations from the guidance acceleration commands to native vehicle autopilot commands. These equations demonstrate the principal that vehicle motion is activated through acceleration. The methods that various vehicles employ to generate acceleration are numerous (bank angle autopilot, acceleration autopilot, heading control autopilot, altitude control autopilot, etc). Since the control algorithms described herein generate acceleration commands that can be kinematically translated into any of these native autopilot commands, the guidance algorithms truly provide a generalized library of control laws that can control any vehicle through that vehicle's native atomic functions. Ubiquitous acceleration control techniques enable VACS to synthesize control commands for any vehicle, including air, ground, or sea-based.

[0355] $\begin{array}{cc}{a}_v=\mathrm{vertical}\mathrm{plane}\mathrm{acceleration}\mathrm{command}{a}_h=\mathrm{horizontal}\mathrm{plane}\mathrm{acceleration}\mathrm{command}\varphi ={\tan }^{-1}\left(\frac{a_h}{a_v}\right)=\mathrm{bank}\mathrm{angle}\mathrm{command}{a}_T=\sqrt{a_v^2+a_h^2}=\mathrm{total}\mathrm{body}\mathrm{acceleration}\mathrm{command}\stackrel{.}{\psi }=\frac{a_h}{V}=\mathrm{turn}\mathrm{rate}\mathrm{command}{\psi }_i={\psi }_{i-1}+\stackrel{.}{\psi }\Delta t=\mathrm{heading}\mathrm{command}\stackrel{.}{\gamma }=\frac{\left(a_v-g\right)}{V}=\mathrm{flight}\mathrm{path}\mathrm{rate}\mathrm{command}{\gamma }_i={\gamma }_{i-1}+\stackrel{.}{\gamma }\Delta t=\mathrm{flight}\mathrm{path}\mathrm{angle}\mathrm{command}\stackrel{.}{h}=V\sin \left(\gamma \right)=\mathrm{climb}\mathrm{rate}\mathrm{command}{h}_i=h_{i=1}+\stackrel{.}{h}\Delta t=\mathrm{altitude}\mathrm{command}& \mathrm{Eq}.57\end{array}$