Patent Description:
Unlike manned aircraft, unmanned aircraft are not afforded the knowledge and skill of on-board pilots to facilitate operation. In some contexts, this may not pose issues, such as where an unmanned aircraft is remotely controlled by a human pilot or is equipped to travel entirely autonomously. A lack of on-board pilots can cause issues in other contexts, however. For example, integrating an autonomous aircraft in contexts where communication with ATC is required, such as in a controlled airspace, remains an unsolved problem due in part to challenges in understanding ATC communications at the autonomous aircraft. A lack of on-board pilots means that the human knowledge and skill required to understand the terminology and overall meaning of ATC communications, and to execute appropriate actions in response, is not present at the autonomous aircraft. The inability to autonomously understand ATC communications exacerbates the already significant challenge of building and deploying autonomous aircraft.

In view of the above, challenges exist in integrating autonomous aircraft in controlled airspaces and other contexts in which communication with ATC occurs.

<CIT>, in accordance with its abstract, states a voice-based method to control unmanned vehicles (UV) or robots that makes use of the UV or robot state and context information to constrain the output of automatic speech recognition (ASR) language models (LM) to improve the ASR accuracy and robustness in controlled and adverse environments.

<CIT>, in accordance with its abstract, states a system and method is provided for controlling an aircraft. At least one transceiver is provided to receive a voice instruction from an air traffic controller, and transmit a voice response to the air traffic controller. A response logic unit can be provided to interpret the received voice instruction from the air traffic controller, determine a response to the interpreted voice instruction, and translate the interpreted voice instruction to a command suitable for input to at least one autopilot unit. An autopilot unit can also be provided to receive the command from the response logic unit, wherein the command is configured to guide the flight of the unmanned aircraft.

A method of and a system for controlling autonomous vehicles according claims <NUM> and <NUM> are provided. Further details are provided in the dependent claims.

The features, functions, and advantages that have been discussed can be achieved independently in various examples or may be combined in yet other examples, further details of which can be seen with reference to the following description and drawings.

In view of the considerations above, methods, systems, and apparatuses are provided that relate to controlling autonomous aircraft based on speech. Briefly, a text string regarding operation of an autonomous aircraft is analyzed via a decoder module to identify one or more linguistic aircraft control components in the text string. As examples, the text string can be derived from communications from an air traffic control (ATC) tower, and the linguistic aircraft control component(s) can include clearances, call signs, destinations, routes, and/or other components. An aircraft-related knowledge base associated with the decoder module is accessed to validate one or more identified linguistic aircraft control components, which can include validating an existence of a component in the knowledge base, determining that a flight path is valid, and/or other operations. Based at least on the identified linguistic aircraft control components, a command for controlling the autonomous aircraft is determined and output for execution by the autonomous aircraft.

The approaches described herein enable an autonomous aircraft, for example, to interpret and respond to communications from ATC and execute appropriate actions. Additionally, the interpretation and action determination can form part of a dialogue system with which an autonomous aircraft responds to ATC via natural language read back messages that can be interpreted by air traffic controllers. With these capabilities, autonomous aircraft can be integrated into controlled airspaces and other scenarios in which communication between aircraft and ATC occurs, greatly expanding the contexts in which autonomous aircraft can be effectively and safely used, and supporting the implementation of fully autonomous aircraft that do not require human oversight during operation. As described in further detail below, actual ATC communications can be crowdsourced and used to train the decoder module to identify linguistic aircraft control components in text strings and thereby enable the autonomous aircraft to interpret ATC communications. This approach provides an efficient mechanism for collecting training data and decoding text strings with high accuracy.

<FIG> depicts an example airdrome <NUM> in which an autonomous aircraft <NUM> receives ATC communications from an ATC tower <NUM>. In this and other examples, ATC tower <NUM> transmits a clearance (indicated at <NUM>) instructing aircraft <NUM> to taxi to a particular runway (runway <NUM>) via a particular route (alpha). Clearance <NUM> is communicated via speech spoken by an air traffic controller located at ATC tower <NUM> via a very high frequency radio link between ATC tower <NUM> and aircraft <NUM> or any other suitable communication mechanism. Further, clearance <NUM> is converted into a text string by performing speech recognition on audio capturing the speech. As described elsewhere, speech recognition can be performed on-board aircraft <NUM> or elsewhere such as at ATC tower <NUM> or other ATC ground station.

Via a decoder module described below, the text string is decoded to identify linguistic aircraft control components in the text string that make up clearance <NUM>. In this and other examples, such components include a callsign (redwood three fifty) assigned to aircraft <NUM>, an operation (taxi), a destination (runway <NUM>), and a route (alpha). Using other modules also described below, one or more of the linguistic aircraft control components are validated, which can include verifying an existence of a control component in an aircraft-related knowledge base, using a mapping service to validate the route, and/or other operations. Based on the identified linguistic aircraft control components, and potentially on other information - such as prior events, prior clearances received from ATC, ground activity, and weather activity - a command for controlling aircraft <NUM> is determined. In this and other examples, execution of the command causes aircraft <NUM> to taxi to the destination (runway <NUM>) via the route (alpha) identified in clearance <NUM>. Aircraft <NUM> can also respond to clearance <NUM> via a natural language message (indicated at <NUM>) acknowledging the clearance <NUM>. Being phrased as a natural language response, message <NUM> can be directly understood by an air traffic controller at ATC tower <NUM>. In some examples, speech conveying message <NUM> can be synthesized and relayed to ATC such that the message <NUM> is received as if ATC were communicating with a piloted aircraft.

While being depicted as an airliner, aircraft <NUM> can assume any form of an autonomous aircraft. Examples include but are not limited to light aircraft, large aircraft, powered aircraft, unpowered aircraft, airplanes, airships, helicopters, and spacecraft. Further, "autonomous aircraft" as used herein can refer to unpiloted aircraft occupied by non-pilot humans (e.g., passengers) and/or unpiloted, unoccupied aircraft. While <FIG> illustrates aircraft-ATC dialogue during taxiing, the approaches described herein for providing an autonomous aircraft that autonomously interprets aircraft control communications and executes corresponding actions apply to phases of flight other than taxiing, including takeoff, climb, cruise, descent, approach, and/or landing.

<FIG> depicts an example dialogue system <NUM> with which an autonomous aircraft and ATC can communicate via speech. As described in further detail below, system <NUM> includes various modules that can be implemented at locations associated with ATC, such as an ATC tower, and/or at an autonomous aircraft. Features of system <NUM> can be implemented to facilitate dialogue between autonomous aircraft <NUM> and ATC tower <NUM>, for example.

In this and other examples, audio <NUM> capturing speech directed to operation of an autonomous aircraft is received at an audio processing module <NUM>. In this and other examples, audio <NUM> is received from ATC tower <NUM>, but can be received from any suitable source including from a pilot on board the autonomous aircraft. Audio processing module <NUM> includes a noise suppression module <NUM> operable to suppress/remove noise in audio <NUM>, where suppression/removal can include filtering the audio and/or any other suitable audio processing. Audio processing module <NUM> further includes a segmentation module <NUM> operable to segment portions of audio <NUM> capturing the speech directed to operation of the autonomous aircraft from other portions of the audio <NUM> that do not capture such speech, such as silence. In some examples, modules <NUM> and <NUM> can be combined to provide noise suppression/removal and segmentation in a common audio processing step. In other examples, audio processing via module <NUM> can be omitted or modified to include any suitable type of audio processing.

Audio <NUM> capturing speech directed to operation of the autonomous aircraft can include aircraft control communications which, as used herein, refers to communications directed to an aircraft including while on the ground and during flight. In some examples, aircraft control communications include one or more ATC clearances. As used herein, an "ATC clearance" refers to an authorization by ATC for an aircraft to proceed. In some examples, an "ATC clearance" as used herein can refer to communications other than an ATC authorization, such as an advisory, weather information, and/or traffic information.

In this and other examples, audio processing module <NUM> outputs processed audio having undergone noise suppression/removal and segmentation. A speech recognition module <NUM> receives the processed audio and performs speech recognition on the audio, which produces a text string that includes the speech recognized in the processed audio. Module <NUM> can employ any suitable mechanisms for recognizing speech, including but not limited to hidden Markov models, dynamic time warping, and neural networks. In some examples, module <NUM> can employ a deep-learning trained recurrent neural network-connectionist temporal classification model to recognize speech.

Dialogue system <NUM> includes a decoder module <NUM> that receives the text string output by speech recognition module <NUM>. Decoder module <NUM> identifies one or more linguistic aircraft control components in the text string. Generally, a linguistic aircraft control component is a word, term, phrase, or other linguistic element in a text string relating to operation of an aircraft. As examples, linguistic aircraft control components can include but are not limited to an ATC clearance, an airport object (e.g., runway, fuel pit, taxiway), a callsign, an operation, and location information (e.g., origin, destination, route, information regarding a flight plan).

<FIG> illustrates an example of identifying linguistic aircraft control components in a text string <NUM> via decoder module <NUM>. Text string <NUM> is derived from ATC clearance <NUM> issued by ATC tower <NUM> in <FIG>. In this and other examples, the linguistic aircraft control components identified in text string <NUM> include an operation (taxi); route information including a name of a route (alpha) and a linguistic indicator (via) of the presence of route information; destination information including a type of the destination (runway), a name of the destination (one), and a direction in which to proceed to the destination (right); and an audience (redwood three fifty) identified by the callsign assigned to autonomous aircraft <NUM>. The identified linguistic aircraft control components can be filled in a template <NUM>, which can include predefined fields and attributes. <FIG> also illustrates other linguistic aircraft control components and their attributes that can be identified in text strings, including a type, direction, and status of a route, a linguistic indicator of the presence of a destination and a status of the destination, a source of the clearance (e.g., the ATC tower from which the clearance originated), and time(s) associated with the clearance. Generally, decoder <NUM> can be configured to identify any suitable linguistic aircraft control components and component attributes in text strings, where such configuring can be part of a training process described below.

Decoder module <NUM> can identify linguistic aircraft control components in any suitable manner. In some examples, decoder module <NUM> identifies boundaries between words or terms in a text string. Further, decoder module <NUM> can apply trie- and/or finite-state transducer-based sequence tagging algorithm(s) to a text string to identify linguistic aircraft control components. As such, <FIG> depicts in the inclusion of a transducer <NUM> (e.g., trie- and/or finite-state transducer) in decoder module <NUM>. However, transducer <NUM> can be implemented at any suitable location. In some examples, decoder module <NUM> can employ natural language processing to tokenize a text string. In such examples, natural language processing can be performed in an aviation-related domain - e.g., to tag or identify linguistic aircraft control components and/or detect events in text strings. Trie- and/or finite state transducer-based sequence tagging can be employed, for example (e.g., via transducer <NUM>). In some examples, decoder module <NUM> can parse a clearance based on a predefined ontology, which can be used to determine semantic attributes that describe the clearance. Decoder module <NUM> can apply any suitable combination of the aforementioned mechanisms to identify linguistic aircraft control components, alternatively or in addition to other suitable mechanism(s).

As mentioned above, decoder module <NUM> can be trained to identify linguistic aircraft control components. In such examples, training data including aircraft control communications (e.g., ATC clearances) can be used to train decoder module <NUM>. The aircraft control communications can be actual aircraft control communications exchanged during aircraft operation, or can be synthesized (e.g., by pilots). In some examples, aircraft control communications can be crowdsourced from pilots via an online tool in which pilots enter (e.g., type or speak) aircraft control communications. In some examples, training data can be labeled to identify the linguistic aircraft control components included therein. Labels can be provided by hand or programmatically determined by decoder module <NUM> in a first pass and subsequently corrected in a second pass, as examples. Further, in some examples the training of decoder module <NUM> can include receiving feedback indicating an accuracy of the output of decoder module <NUM>. For example, pilots can review the output of decoder module <NUM>, providing any suitable feedback including but not limited to a rating of output, a yes/no indication of whether output is correct or incorrect, and corrections of incorrectly identified linguistic components. Thus, decoder module <NUM> can be trained according to an at least partially supervised learning process. In some examples, active learning can be employed to bootstrap additional training data to an initial training data set.

As described above, decoder module <NUM> can employ transducer <NUM> to identify linguistic aircraft control components. Alternatively or additionally, decoder module <NUM> can employ one or more neural networks (e.g., a deep neural network) to identify linguistic aircraft control components. In such examples, decoder module <NUM> can be trained via deep learning methods.

Decoder module <NUM> further validates one or more identified linguistic aircraft control components by accessing an aircraft-related knowledge base <NUM>. Knowledge base <NUM> may include information with which an existence and/or other properties of linguistic aircraft control components can be validated. As examples, knowledge base <NUM> can include information regarding aircraft-related operations, which in some examples can relate to individual phases of flight (e.g., taxiing operations), callsigns such as the callsign of the autonomous aircraft with which dialogue occurs, information relating to the autonomous aircraft (e.g., features, specifications, components), ontological information regarding flight or phases thereof, and/or airdrome objects (e.g., runways, taxiways, fuel pits, gates, parking areas). As such, knowledge base <NUM> can be referred to as an airport-related knowledge base. Alternative or additional examples of information that can be stored in knowledge base <NUM> include operations such as cross, taxi, continue taxiing, proceed, follow, head in a particular direction, descend, land, and maintain altitude; destination indicators such as "to"; location indicators such as "via" and "on"; directions such as straight, left, and right; airline names; and/or airport names.

In some examples, a trie can be constructed based on knowledge base <NUM>, where each leaf node of the trie is assigned a category label. An utterance/clearance/text can then be labeled with categories using the trie to thereby produce labeled linguistic aircraft control components (e.g., that form a decoded text string). Categories can include but are not limited to a callsign, number (e.g., altitude), destination or destination type, audience, operation, route indicator, and token. Labeled linguistic aircraft control components, or tokens, can be used to fill (e.g., via transducer <NUM>) a template such as template <NUM>.

In some examples illustrating the validation of a linguistic aircraft control component, a callsign extracted from an ATC clearance can be validated by accessing knowledge base <NUM> and determining whether the callsign exists in the knowledge base <NUM>. In some examples, knowledge base <NUM> can store variations of a callsign (and potentially other linguistic aircraft control components). Such callsign validation can be used to determine whether a clearance received at autonomous aircraft is directed to that autonomous aircraft or instead is directed to another entity and thus can be ignored. In other examples of validation, a destination identified in an ATC clearance can be validated by determining whether the destination exists in knowledge base <NUM>. Further, decoder module <NUM> can apply transducer <NUM> to knowledge base <NUM> to identify information therein, including but not limited to taxiing operations and operations for other phases of flight, destinations, and routes.

In some examples, decoder module <NUM> can use a mapping service <NUM> to validate a linguistic aircraft control component. For example, mapping service <NUM> can be accessed to validate a linguistic aircraft control component in the form of location information, such as an origin, destination, flight path, flight plan, coordinates (e.g., of an airport object), and/or any other suitable information. Mapping service <NUM> can provide any suitable functionality to service linguistic component validation, including but not limited to satellite or aerial imaging, topological mapping, traffic analysis, and/or route planning. Decoder module <NUM> thus can perform validation potentially in cooperation with other modules.

Decoder module <NUM> produces decoded information as output, which can include but is not limited to validated linguistic aircraft control components and validated, decoded clearances. The decoded information output from decoder module <NUM> is received by a state tracking module <NUM>. State tracking module <NUM> stores an event log that includes communications (e.g., ATC clearances) between ATC and an autonomous aircraft. The event log can be implemented as a time-stamped dynamic queue or in any other suitable manner. Further, the event log can include any other suitable data, including but not limited to decoded ATC clearances and other instructions/commands, information regarding the state of the autonomous aircraft and/components therein, and information regarding the surrounding world (e.g., ground and/or air traffic, weather information, communications with other aircraft). As described below, a command for controlling the autonomous aircraft can be determined in response to a received ATC clearance. Such command can be determined based on data stored in state tracking module <NUM>. In some scenarios, this can include accessing data in the event log corresponding to prior events that occurred before the current time. For example, in determining a command for controlling the autonomous aircraft, the event log can be examined to identify and analyze ATC communications with other aircraft - e.g., to determine whether other aircraft are on the same runway as the autonomous aircraft, to identify a runway closure, or for any other suitable purpose. Such features enable state tracking module <NUM> to provide an autonomous aircraft with situational awareness.

Dialogue system <NUM> further includes a policy module <NUM> that performs decision making based on the output of one or other modules in system <NUM>. For example, policy module <NUM> can determine commands to be sent to an executive module <NUM>, which implements autopilot functionality to autonomously control an autonomous aircraft based on actions determined in dialogue system <NUM>. In some examples, the determination of commands for controlling the autonomous aircraft can be determined cooperatively between decoder module <NUM> and policy module <NUM>, and potentially other modules depicted in <FIG>. Where command determination occurs at least in part at policy module <NUM>, the policy module <NUM> can determine commands for controlling the autonomous aircraft based on one or more of validated, decoded output (e.g., decoded clearances) from decoder module <NUM> and events stored by state tracking module <NUM>. In other examples of potential cooperation between decoder module <NUM> and policy module <NUM>, the policy module <NUM> can request the decoder module <NUM> to correct errors that occur in the course of decoding, such as an inability to decode/understand/identify a destination or other location.

Policy module <NUM> can determine messages to be sent to ATC (e.g., in response to previously received clearances). In some examples, policy module <NUM> can determine different messages depending on whether a clearance is validated and on whether the clearance is directed to the relevant autonomous aircraft. For example, policy module <NUM> can generate a first message in response to validating a clearance, where the first message includes a confirmation read back. Referring to the example depicted in <FIG>, policy module <NUM> can generate the confirmation read back communicated in message <NUM> confirming clearance <NUM> issued from ATC tower <NUM>. Further, policy module <NUM> can generate a second message in response to a failure to validate a clearance, where the second message includes an error message communicating the failed validation. The error message can request that ATC repeat the clearance and/or request further instruction, for example. If instead policy module <NUM> determines that a clearance is not directed to the relevant autonomous aircraft, the policy module <NUM> can forego generating a message.

Messages determined by policy module <NUM> can be relayed to ATC in speech synthesized via a natural language message module <NUM>. Specifically, natural language message module <NUM> can generate a natural language response based on a message received from policy module <NUM>. For example, natural language message module <NUM> can generate a first natural language response for output to an ATC operator in response to validating an identified linguistic aircraft control component, where the response indicates validation. Natural language message module <NUM> can further generate a second natural language response for output to an ATC operator in response to failing to validate an identified linguistic aircraft control component, where the response indicates such failure to validate. <FIG> illustrates the output of a natural language message <NUM> from natural language message module <NUM> to ATC tower <NUM>. Natural language message module <NUM> can implement any suitable method of generating natural language messages, including but not limited to the use of a predefined ruleset.

As mentioned above, decoder module <NUM>, potentially in cooperation with other modules such as policy module <NUM>, can determine a command for controlling an autonomous aircraft based at least on one or more identified linguistic aircraft control components. In some examples, decoder module <NUM> can determine a command for controlling the autonomous aircraft by translating one or more validated clearances into the command. The determination of the command can include labeling linguistic aircraft control components and/or filling a template as described above. In some examples, a template can be filled with labeled linguistic aircraft control components, where the template can include a command in the form of a taxi operation. Decoder module <NUM> can then determine a command based on the taxi operation - e.g., one or more actions that when executed actuate components of an autonomous aircraft to thereby perform the taxi operation.

A command determined via decoder module <NUM> can be issued to an aircraft management module <NUM>, which can package the command in a format that is accepted by executive module <NUM>. Executive module <NUM> then can execute the formatted command and thereby control the autonomous aircraft according to the command. As noted above, executive module <NUM> can implement autopilot functionality to autonomously control the autonomous aircraft based on received commands, where such autonomous control can involve any suitable actions to execute commands, including but not limited to controlling operation of a propulsion system and actuating aircraft components to achieve a flight path.

In some examples, executive module <NUM> can plan a flight path and validate the flight path (e.g., via one or both of knowledge base <NUM> and mapping service <NUM>). If the flight path is validated, executive module <NUM> can send a message indicating validation of the flight path to dialogue system <NUM>, which can be used for subsequent decision making, to relay a message to ATC, and/or for any other suitable purpose. In some examples in which a message indicating flight path validation is sent to ATC, a ground station operator can provide an input in response to the message that causes an autonomous aircraft to proceed along the flight path. Thus, in some examples, "autonomous aircraft" as used herein can refer to a fully autonomous aircraft, or in other examples, to a partially autonomous aircraft whose function is at least in part contingent upon input from a human operator. Generally, in some examples, a command for an autonomous aircraft can be reviewed or modified by air traffic control prior to execution by the autonomous aircraft.

In some examples, operation of dialogue system <NUM> can vary depending on the phase of flight for which communication with ATC is sought. Such adaptation can result from differences in the types of messages, terminology, operations, etc. between different phases of flight. In such examples, knowledge base <NUM> can store different data sets for different phases of flight - e.g., respective data sets for each of taxiing, takeoff, climb, cruise, descent, approach, and landing. Further, respective training data sets can be used to train decoder module <NUM> for each phase of flight. In some examples, different labels and/or templates can be used for different phases of flight.

The modules of dialogue system <NUM>, and the other modules depicted in <FIG>, can be implemented at any suitable location. In some examples, decoder module <NUM>, state tracking module <NUM>, policy module <NUM>, and executive module <NUM> can be implemented at an autonomous aircraft. Other modules, such as audio processing module <NUM> and/or speech recognition module <NUM>, can be implemented at a ground station such as an ATC tower. Further, any suitable collection of modules can be implemented within dialogue system <NUM> or outside of the dialogue system. Still further, any suitable mechanisms can be used to implement one or more modules depicted in <FIG>. In some examples, modules <NUM>, <NUM>, <NUM>, and <NUM> can each be implemented via one or more neural networks.

<FIG> shows a flowchart illustrating a method <NUM> of controlling autonomous aircraft. Method <NUM> can be implemented to control autonomous aircraft <NUM>, for example.

At <NUM>, method <NUM> includes receiving a text string regarding operation of the autonomous aircraft. The text string can be generated by performing speech recognition on audio capturing speech directed to operation of the autonomous aircraft, for example. At <NUM>, method <NUM> includes analyzing the text string via a decoder module to identify one or more linguistic aircraft control components in the text string, the decoder module being trained on data derived from aircraft control communications. The aircraft control communications can include ATC communications, for example. The decoder module can include <NUM> one or more neural networks trained on the data derived from aircraft control communications. Alternatively or additionally, the decoder module can include <NUM> a transducer (e.g., trie- and/or finite-state transducer). The linguistic aircraft control components can include <NUM> one or more of an air traffic control clearance, an airport object, a callsign, and location information, as examples.

At <NUM>, method <NUM> includes storing an event log in a state tracking module, the event log including communications between ATC and the autonomous vehicle. At <NUM>, method <NUM> includes accessing an aircraft-related knowledge base associated with the decoder module to validate one or more identified linguistic aircraft control components. Accessing the aircraft-related knowledge base can include validating <NUM> an existence of each identified linguistic aircraft control component in the aircraft-related knowledge base. Alternatively or additionally, accessing the aircraft-related knowledge base can include using <NUM> a mapping service.

At <NUM>, method <NUM> includes determining whether the validation at <NUM> succeeded. If the validation failed (NO), method <NUM> proceeds to <NUM> where a natural language read back message (e.g., natural language response) is generated in response to failing to validate the identified linguistic aircraft control component(s). The natural language read back message can indicate such failure to validate. If the validation succeeded (YES), method <NUM> proceeds to <NUM>.

At <NUM>, method <NUM> includes, based at least on the identified linguistic aircraft control components, determining a command for controlling the autonomous aircraft. The command can be determined based further on at least a portion <NUM> of the event log. Further, determining the command can include translating one or more (decoded, validated) clearances into the command.

At <NUM>, method <NUM> includes outputting the command for execution by the autonomous aircraft. At <NUM>, method <NUM> includes generating a natural language read back message (e.g., natural language response) in response to validating an identified linguistic aircraft control component. The natural language read back message can indicate that validation succeeded.

The approaches described herein provide a dialogue system with which communication between ATC and autonomous aircraft can be carried out via natural speech. In some examples, the dialogue system can facilitate dialogue throughout all phases of flight to support aircraft autonomy. Moreover, the dialogue system, potentially in concert with other systems, can account for situational and contextual information to support intelligent aircraft autonomy and awareness. These and other features of the disclosed approaches can expand the range of potential applications and uses of autonomous aircraft - e.g., including their use in controlled airspace - while reducing or eliminating human oversight over autonomous aircraft.

In some examples, the methods and processes described herein can be tied to a computing system of one or more computing devices. In particular, such methods and processes can be implemented as a computer-application program or service, an application-programming interface (API), a library, and/or other computer-program product.

<FIG> schematically shows a non-limiting example of a computing system <NUM> that can enact one or more of the methods and processes described above. Computing system <NUM> can take the form of one or more personal computers, server computers, tablet computers, home-entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices.

Computing system <NUM> includes a logic subsystem <NUM> and a storage subsystem <NUM>. Computing system <NUM> can optionally include a display subsystem <NUM>, input subsystem <NUM>, communication subsystem <NUM>, and/or other components not shown in <FIG>.

Logic subsystem <NUM> includes one or more physical devices configured to execute instructions. For example, the logic machine can be configured to execute instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions can be implemented to perform a task, implement a data type, transform the state of one or more components, achieve a technical effect, or otherwise arrive at a desired result.

The logic machine can include one or more processors configured to execute software instructions. Additionally or alternatively, the logic machine can include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. Processors of the logic machine can be single-core or multi-core, and the instructions executed thereon can be configured for sequential, parallel, and/or distributed processing. Individual components of the logic machine optionally can be distributed among two or more separate devices, which can be remotely located and/or configured for coordinated processing. Features of the logic machine can be virtualized and executed by remotely accessible, networked computing devices configured in a cloud-computing configuration.

Storage subsystem <NUM> includes one or more physical devices configured to hold instructions executable by the logic machine to implement the methods and processes described herein. When such methods and processes are implemented, the state of storage subsystem <NUM> can be transformed-e.g., to hold different data.

Storage subsystem <NUM> can include removable and/or built-in devices. Storage subsystem <NUM> can include optical memory (e.g., CD, DVD, HD-DVD, Blu-Ray Disc, etc.), semiconductor memory (e.g., RAM, EPROM, EEPROM, etc.), and/or magnetic memory (e.g., hard-disk drive, floppy-disk drive, tape drive, MRAM, etc.), among others. Storage subsystem <NUM> can include volatile, nonvolatile, dynamic, static, read/write, read-only, random-access, sequential-access, location-addressable, file-addressable, and/or content-addressable devices.

It will be appreciated that storage subsystem <NUM> includes one or more physical devices. However, features of the instructions described herein alternatively can be propagated by a communication medium (e.g., an electromagnetic signal, an optical signal, etc.) that is not held by a physical device for a finite duration.

Features of logic subsystem <NUM> and storage subsystem <NUM> can be integrated together into one or more hardware-logic components. Such hardware-logic components can include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC / ASICs), program- and application-specific standard products (PSSP / ASSPs), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

The terms "module," "program," and "engine" can be used to describe an feature of computing system <NUM> implemented to perform a particular function. In some cases, a module, program, or engine can be instantiated via logic subsystem <NUM> executing instructions held by storage subsystem <NUM>. It will be understood that different modules, programs, and/or engines can be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same module, program, and/or engine can be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module," "program," and "engine" can encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc..

A service can be available to one or more system components, programs, and/or other services. In some examples, a service can run on one or more server-computing devices.

When included, display subsystem <NUM> can be used to present a visual representation of data held by storage subsystem <NUM>. This visual representation can take the form of a graphical user interface (GUI). As the herein described methods and processes change the data held by the storage machine, and thus transform the state of the storage machine, the state of display subsystem <NUM> can likewise be transformed to visually represent changes in the underlying data. Display subsystem <NUM> can include one or more display devices utilizing virtually any type of technology. Such display devices can be combined with logic subsystem <NUM> and/or storage subsystem <NUM> in a shared enclosure, or such display devices can be peripheral display devices.

When included, input subsystem <NUM> can comprise or interface with one or more user-input devices such as a keyboard, mouse, touch screen, or game controller. In some examples, the input subsystem can comprise or interface with selected natural user input (NUI) componentry. Such componentry can be integrated or peripheral, and the transduction and/or processing of input actions can be handled on- or off-board. Example NUI componentry can include a microphone for speech and/or voice recognition; an infrared, color, stereoscopic, and/or depth camera for machine vision and/or gesture recognition; a head tracker, eye tracker, accelerometer, and/or gyroscope for motion detection and/or intent recognition; as well as electric-field sensing componentry for assessing brain activity.

When included, communication subsystem <NUM> can be configured to communicatively couple computing system <NUM> with one or more other computing devices. Communication subsystem <NUM> can include wired and/or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem can be configured for communication via a wireless telephone network, or a wired or wireless local- or wide-area network. In some examples, the communication subsystem can allow computing system <NUM> to send and/or receive messages to and/or from other devices via a network such as the Internet.

Claim 1:
A method (<NUM>) of controlling autonomous aircraft (<NUM>), the method (<NUM>) comprising:
receiving (<NUM>) a text string (<NUM>) regarding operation of an autonomous aircraft (<NUM>);
analyzing (<NUM>) the text string (<NUM>) via a decoder module (<NUM>) to identify one or more linguistic aircraft control components in the text string (<NUM>), the decoder module (<NUM>) being trained on data derived from aircraft control communications;
accessing (<NUM>) an aircraft-related knowledge base (<NUM>) associated with the decoder module (<NUM>) to validate one or more identified linguistic aircraft control components;
based at least on the validated identified linguistic aircraft control components, determining (<NUM>) a command for controlling the autonomous aircraft (<NUM>); and
outputting (<NUM>) the command for execution by the autonomous aircraft (<NUM>).