Patent ID: 12205478

DETAILED DESCRIPTION

This description relates to systems and methods for uploading a mission plan to a deployed remote vehicle, such as an unmanned ariel vehicle (UAV). The mission plan can be uploaded to change/replace a previously loaded mission plan.

The system includes a computing platform (e.g., a server) executing a mission plan module that generates the mission plan for the deployed remote vehicle. The mission plan includes a plurality of commands for the deployed remote vehicle. The plurality of commands are an ordered set. The computing platform also executes a burst upload module that receives the mission plan.

The burst upload module employs burst mode operations to upload the mission plan to the deployed remote vehicle. More particularly, during the upload of the mission plan, the burst upload module selects a first subset of the plurality of commands of the mission plan based on burst mode parameters. The burst mode module transmits the first subset of commands to a data link interface (DLI) module on a first stream of packets of a first protocol (e.g., the user datagram protocol (UDP)).

The DLI module executes on a DLI controller (or other hardware). The DLI module converts the first stream of packets in the first protocol into a second stream of packets in a second protocol (e.g., a protocol defined in the MIL-STD-1553 standard or the Institute of Electrical and Electronics Engineers (IEEE) 1394 standard). The DLI module transmits the second stream of packets to a ground communication element (GCE). The GCE includes an antenna that wirelessly communicates the deployed remote vehicle to send the second stream of packets to the deployed remote vehicle.

The deployed remote vehicle processes each command and either accepts or rejects each command. In response to each such command, the deployed remote vehicle generates a response message that indicates whether a corresponding command has been accepted or rejected. The response messages are provided to the GCE in the second protocol. The GCE forwards the response messages in the second protocol to the DLI module. The DLI module converts the response messages to the first protocol and transmits the response messages in the first protocol to the burst upload module.

The burst mode module receives the response messages generated in response to the first subset of commands. The burst mode module can adjust burst mode parameters, and selects a second (next) set of commands to transmit to the deployed remote vehicle in a similar manner. After each of the commands in of the mission plan has been transmitted to the deployed remote vehicle, the burst upload operation ends.

By employment of the system and method described herein, the burst upload module sends each subset of the command of the mission plan in a burst operation. That is, in contrast to conventional approaches where a system sends individual commands and waits for a response for a given command prior to sending a next command, the burst upload module transmits the subset of commands (indirectly) to the deployed remote vehicle before waiting for the response messages. In this manner, the time needed to upload the mission plan to the deployed remote vehicle is curtailed.

FIG.1illustrates an example of a system100for uploading a mission plan104to a deployed remote vehicle108using burst mode operations. The deployed remote vehicle108can be, for example, a UAV such as a drone. Alternatively, the deployed remote vehicle108can be implemented as a terrestrial vehicle, such as an armored vehicle.

The system100includes a mission plan server112. The mission plan server112is a computing platform (e.g., a computing device). The mission plan server112includes a non-transitory memory116that stores data and machine executable instructions. The non-transitory memory116is implemented as volatile memory (e.g., random access memory) or non-volatile memory, such as a solid state drive, a hard disk drive or a combination thereof. More generally, the non-transitory memory116is a non-transitory machine readable medium that has machine executable instructions. The mission plan server112also includes a processor core120(or multiple processor cores) that accesses the non-transitory memory116and executes the machine executable instructions. The mission plan server112also includes a network interface124(e.g., a network interface card) for accessing a network128. The network128can be implemented as a public network (e.g., the Internet), a private network (e.g., a local area network or a proprietary network) or a combination thereof (e.g., a virtual private network).

The mission plan server112could be implemented in a computing cloud. In such a situation, features of the mission plan server112, such as the processor core120, the network interface124and the non-transitory memory116could be representative of a single instance of hardware or multiple instances of hardware with applications executing across the multiple of instances (e.g., distributed) of hardware (e.g., computers, routers, memory, processors, or a combination thereof). Alternatively, the mission plan server112could be implemented on a single dedicated server.

The mission plan server112can include a mission plan module132that can generate and/or update the mission plan104in response to user input or in response to input from another computing platform (e.g., a computing platform executing an artificial intelligence engine). In some examples, the mission plan module132can include a graphical user interface (GUI) for enabling selection of particular mission parameters.

The system100includes a data link interface (DLI) controller136(alternatively referred to as DLI hardware) that executes a DLI module150. That is, the DLI controller136can execute embedded instructions (e.g., firmware), such as the DLI module150. The DLI controller136is coupled to the network128. The system100further includes a ground communication element (GCE)154that includes an antenna for wirelessly communicating with the deployed remote vehicle108.

Prior to deployment, the remote vehicle108is loaded with an initial mission plan that could have been generated by the mission plan module132. However, upon deployment, during prosecution of the mission plan, it may be desirable to change the initial mission plan for a myriad of reasons. These reasons can include, for example changing weather patterns, awareness of hostile entities, traffic congestion (e.g., particularly with respect to a UAV). Additionally or alternatively, the deployed remote vehicle108can reject a given command if the given command is unrecognized (e.g., in a wrong format or not applicable to the particular model of the deployed remote vehicle108). In any such situations, the mission plan module132is employable to generate a new mission plan or revise the initial mission plan to provide the mission plan104.

The mission plan104is an ordered set of instructions executable by the deployed remote vehicle108. These instructions can include, but are not limited to maneuvering instructions (e.g., yaw, roll and pitch control) operational instructions (e.g., activate camera, lights and/or weapons), etc. In various examples, the ordered set of instructions can range from 2 instructions to 10,000 instructions (or more).

The system100includes a burst upload module152(e.g., a software algorithm) executing on the non-transitory memory116. The burst upload module152receives the mission plan104from the mission plan module132. Responsive to the mission plan104, the burst upload module152initiates an upload procedure for the mission plan104. The upload procedure uploads the mission plan104to the deployed remote vehicle108using burst mode operations. During the upload procedure, the burst upload module152selects a first subset of the commands of the mission plan104based on burst parameters. The first subset of commands is alternatively referred to as a burst count set. Stated differently, the subsets of the commands include a set number of the commands of the mission plan104(in order), and the number of commands within a particular subset are dictated by the burst parameters.

The first subset of commands are encapsulated into packets in a first protocol, such as the user datagram protocol (UDP) and the packets in the first protocol are transmitted to the DLI controller136through the network128in an iterative manner. A delay between each command, referred to as a wait interval, is set by the burst parameters. For instance, suppose that the burst parameters specify that there are 5 commands in each subset of command (each burst count set), and that there are 30 milliseconds between each command (e.g., the wait interval), as specified in the burst parameters. In this situation, the burst upload module152transmits (uploads) the first subset of the commands, namely commands 1-5 of the set of commands in UDP packets and provides the commands 1-5 to the burst upload module152via the network128. The packets are added to (or used to form) a first stream of packets provided from the burst upload module152to the DLI controller136.

Responsive to the first stream of packets that include the first subset of commands, the DLI module150converts the packets in the first protocol to packets in a second protocol, such as a protocol defined in the MIL-STD-1553 standard or the IEEE 1394 standard. These packets in the second protocol encapsulate the first subset of commands (e.g., commands 1-5), and are provided to the GCE154in a second stream of packets. Responsive to the second stream of packets in the second protocol, the GCE154wirelessly transmits the first subset of commands to the deployed remote vehicle108. In some examples, error correction techniques (e.g., parity, forward error correction, etc.) ensure that the deployed remote vehicle108receives the first subset of commands. Stated differently, transmitting the first subset of commands from the burst upload module to the DLI module150causes the DLI module150to transmit the first subset of commands to the deployed remote vehicle108through the GCE154.

The deployed remote vehicle108accesses the packets in the second protocol, and processes the first subset of commands individually. For each such command, the deployed remote vehicle108either accepts the command or rejects the command. Acceptance of a command indicates that the deployed remote vehicle108will execute the command during prosecution of the mission plan. In some situations, a particular command may be rejected because it is impossible to execute. For instance, if the particular command instructs the deployed remote vehicle108to drop to a particular altitude, but that altitude is below ground level, the deployed remote vehicle108may reject the command.

Responsive to each command in the first subset of commands (e.g., commands 1-5 of the mission plan104), the deployed remote vehicle108wirelessly communicates a response message indicating acceptance or rejection of the corresponding message to the GCE154in the second protocol. Each response message corresponds to a particular command in the first subset of commands. However, the order of the response commands may not match the order of the commands in the first subset of commands. In the above example, the first subset of commands provides the commands 1, 2, 3, 4 and 5, in order. In such a situation, the deployed remote vehicle108could provide response messages for the commands in the following order 3, 2, 5, 1 and 4 (as one example). That is, the order of the response messages may be the same or different as the order of the command messages. The GCE154provides the response messages to the DLI module150. Responsive to the response messages, the DLI module150converts the response messages encapsulated in the second protocol into packets in the first protocol. These packets in the first protocol are provided from the DLI module150to the burst upload module152.

The burst upload module152un-encapsulates the packets in the first protocol to reveal the response messages. Each response message is analyzed. If a response message provided by the deployed remote vehicle108for the first subset of commands of the mission plan104is rejected, the burst upload module152terminates the upload of the mission plan104and provides the mission plan module132with an indication that the upload has been terminated. Additionally, in situations where the deployed remote vehicle108did not receive all of the command messages in the first subset of commands of the mission plan104, the deployed remote vehicle108would provide less response messages than command messages in the first subset of commands of the mission plan104. In this situation, the burst upload module152also terminates the upload of the mission plan104and provides the mission plan module132with an indication that the upload has been terminated. In any such situation, a user or an AI engine can evaluate the mission plan104and update or replace the mission plan104and the upload can be retried.

Conversely, if each response message provided by the deployed remote vehicle108for the first subset of commands of the mission plan104is accepted (e.g., indicating that the deployed remote vehicle108is set to execute the command), uploading of the mission plan104continues. To continue the upload of the mission plan104, the burst upload module152determines if the burst parameters are to be adjusted (changed). Adjusting the burst parameters can include increasing or decreasing a number of commands in each subset of the commands of the mission plan104and/or increasing or decreasing the wait interval of the burst parameters. More generally, adjustment of the burst mode parameters increases a number of commands in a next subset of commands of the mission plan104and/or decreases an interval of time between transmission of commands in the next subset of commands. The burst upload module152selects a second (the next) subset of the commands of the mission plan104, as specified by the burst parameters. Each subset of commands, including the first and second subsets of commands are disjoint subsets of the set of commands of the mission plan104. The second subset of commands is transmitted to the deployed remote vehicle108in the same manner as the first subset of commands. In this manner, the second subset of commands is not transmitted to the deployed remote vehicle108until confirmation (the response messages) indicate that the first subset of commands have been accepted by the deployed remote vehicle108. This process continues for the third, fourth, fifth, etc. subsets of commands until the last subset of commands is provided to the deployed remote vehicle108completing the upload process or until the deployed remote vehicle108rejects a command and the upload process is terminated.

In a conventional approach, individual commands of a mission plan are provided to the deployed remote vehicle108. In this situation, after each command is provided to the deployed remote vehicle108, the deployed remote vehicle108generates a response message before a subsequent command is sent. This creates a significant bottleneck that impacts the speed at which the mission plan of the deployed remote vehicle108can be revised. In contrast, the burst upload module152provides an entire burst of commands, namely, one of the subset of commands without waiting for a response. Additionally, the burst upload module152tunes the burst mode parameters after response messages for each subset of commands of the mission plan104are received by the burst upload module152. Thus, the burst upload module152continually tunes the number of commands in a given subset, as well as the wait interval between sending each command in the given subset. In this manner, the overall time needed to upload the mission plan104to the deployed remote vehicle108is curtailed. In particular, this approach, namely, using burst mode to upload subsets of commands and adjusting the burst mode parameters ensure that the available bandwidth between the mission plan server112and the DLI controller136are fully leveraged (or nearly so) during the upload of the mission plan104.

FIGS.2A and2Billustrate a sequence diagram depicting a system200(e.g., the system100) executing a method300to upload a mission plan to a deployed remote vehicle204(e.g., the deployed remote vehicle108ofFIG.1).

The system200includes a mission plan server208(e.g., the mission plan server112ofFIG.1). The mission plan server208executes a mission plan module212(e.g., the mission plan module132ofFIG.1) and a burst upload module216(e.g., the burst upload module152ofFIG.1). The server208communicates with a DLI controller220(e.g., the DLI controller136ofFIG.1) through a network (e.g., the network128ofFIG.1, omitted inFIGS.2A and2B).

The DLI controller220executes a DLI module224(e.g., the DLI module150ofFIG.1). The system200also includes a GCE228that communicates with the DLI module224and the deployed remote vehicle204. More particularly, the GCE228includes an antenna to enable wireless communications between the deployed remote vehicle204and the GCE228.

As illustrated inFIG.2A, at305, the mission plan module212generates (or updates) a mission plan (e.g., the mission plan104ofFIG.1). The mission plan includes a set of ordered commands, such as two or more commands (10,000 or more commands in some examples). At310, the mission plan is provided to the burst upload module216.

Responsive to receipt of the mission plan, the method300proceeds from node A to initiate and upload of the mission plan to the deployed remote vehicle204. At310, the burst upload module216selects a subset of the commands to upload to the deployed remote vehicle204in a burst mode operation. The number of commands in the subset of commands is based on burst mode parameters. In the example illustrated, there are K number of commands in the subset of commands, where K is an integer greater than or equal to one.

At315, the burst upload module216encapsulates the subset of commands into a first protocol, such as UDP. At320, the burst upload module216transmits the K number of commands (labeled CMD 1 . . . . CMD K) in the subset of commands to the DLI module224as a series of packets in the first protocol. A wait time (e.g., a burst rate) is added between each of the K number of commands, and this wait time is specified in the burst mode parameters. That is, there is a wait time between CMD 1 and CMD 2 that is specified by the burst mode parameters. The subset of commands are provided on a first data stream.

The DLI module224executing on the DLI controller220receives the subset of commands. At325, the DLI module224converts the subset of commands encapsulated in the first protocol to a second protocol (e.g., a protocol conforming to the MIL-STD-1553 standard or the IEEE 1394 standard). At330, the DLI module224buffers the subset of commands in packets of the second protocol. At335, the DLI module224transmits the subset of commands in the packets of the second protocol to the GCE228on a second data stream.

Responsive to the subset of commands, at338, the GCE228wirelessly transmits the subset of commands (K number of commands) to the deployed remote vehicle204. Continuing with the method300onFIG.2B, at340, the deployed remote vehicle204processes the commands received from the GCE228. Processing of the commands includes un-encapsulating the commands from the packets of the second protocol, and accepting or rejecting to the commands. Acceptance of a given command indicates that the given command will be executed during prosecution of a mission plan. Rejection of a given command indicates that the command will not be executed, and in fact, the mission plan will not be executed by the deployed remote vehicle204. Additionally, for each command, the deployed remote vehicle204generates a response message, such that there are M number of response messages, where M is less than or equal to K. However, the order of the M number of response messages does not necessarily match the order of the command messages in the subset of commands.

At345, the M number of response messages are encapsulated into packets of the second protocol by the deployed remote vehicle and are wirelessly transmitted to the GCE228. In response, at350, the GCE228forwards the M number of response messages to the DLI module224. At355, in response to the M number of response messages encapsulated in packets of the second protocol, the DLI module224converts the M number of response messages to the first protocol. At360, the DLI module224transmits the M number of response messages to the burst upload module216.

At365, the burst upload module216evaluates each of the M number of response messages to determine if each of the K number of commands in the subset of commands has been accepted. If one or more of the K number of commands has been rejected by the deployed remote vehicle204and/or if there are less response messages than commands in the subset (e.g., M is less than K), indicating that the deployed remote vehicle204did not receive each of the K number of commands in the subset of commands, the burst upload module216terminates the upload of the mission plan and at370, the burst upload module216provides a status indicator to the mission plan module212indicating that the mission plan upload has been terminated.

If each of the M number of response messages indicates that each of the K number of commands has been accepted by the deployed remote vehicle204, at375, the burst upload module216can adjust the burst parameters, such as increasing or decreasing the number of commands in a next subset of commands or increasing or decreasing the burst wait time for the next subset of commands. At380, the method300returns to node A of FIG. B, such that the next subset of commands can be transmitted in a similar manner.

The method300continues until either a command is rejected by the deployed remote vehicle204or until each command in the mission plan has been transmitted and accepted by the deployed remote vehicle204.

In view of the foregoing structural and functional features described above, an example method will be better appreciated with reference toFIG.3. While, for purposes of simplicity of explanation, the example method ofFIG.3is shown and described as executing serially, it is to be understood and appreciated that the present examples are not limited by the illustrated order, as some actions could in other examples occur in different orders, multiple times and/or concurrently from that shown and described herein. Moreover, it is not necessary that all described actions be performed to implement a method.

FIG.3illustrates a flowchart of an example method400for uploading a mission plan to a deployed remote vehicle (e.g., deployed remote vehicle108ofFIG.1) using burst mode operations. The method400can be executed by a burst upload module (e.g., the burst upload module152ofFIG.1and/or the burst upload module216ofFIGS.2A and2B) executing on a computing platform (e.g., the mission plan server112ofFIG.1).

At410, the burst upload module receives the mission plan from a mission plan module (e.g., the mission plan module132ofFIG.1) executing on a computing platform (e.g., the same or a different computing platform). The mission plan includes a plurality of commands for the deployed remote vehicle, which can alternatively be referred to as an order set of commands. At415, the burst mode module selects a next subset of the plurality of commands for the deployed remote vehicle. The number of commands (e.g., 3-10) in the selected subset of commands is based on burst parameters. At420, the burst upload module encapsulates the selected subset of commands into packets of a first protocol (e.g., UDP). At425, the burst mode module transmits the selected subset of commands to a DLI module (e.g., the DLI module150ofFIG.1) operating on a DLI controller (e.g., the DLI controller136ofFIG.1). A delay, namely a burst rate specified in the burst rate parameters is added between the sending of each command in the subset of commands. In response, the DLI module and a GCE (e.g., the GCE154ofFIG.1) operate in concert to provide the deployed remote vehicle with the selected subset of commands in packets in a second protocol (e.g., a protocol conforming to the MIL-STD-1553 standard or the IEEE 1394 standard), in a manner described herein.

The deployed remote vehicle generates a response message for each command in the subset of commands indicating whether the corresponding command has been accepted or rejected. The response messages are processed and routed through the GCE and the DLI module back to the burst upload module in the manner described. There are an equal number of response messages as command messages in the selected subset of messages. At430, the burst upload module receives a given response message (e.g., a next response message) of the response messages. At435, a determination is made by the burst upload module as to whether the given response message indicates that the corresponding command message has been accepted. If the determination at435is negative (e.g., NO), indicating that the corresponding command has been rejected by the deployed remote vehicle, the method400proceeds to440. If the determination at435is positive (e.g., YES), indicating that the corresponding command has been accepted by the deployed remote vehicle, the method400proceeds to445. At440, the method400terminates the upload of the mission plan. In some examples, the burst upload module provides a notification of the termination to the mission plan module.

At445, a determination is made by the burst upload module as to whether the given response message is the each message for the selected subset of commands. Stated differently, at445, the burst upload module determines if the response message has been received for each command in the selected subset of commands. If the determination at445is negative (e.g., NO), the method400proceeds to448. If the determination at445is positive (e.g., YES), the method400proceeds to450.

At448, a determination is made by the burst upload module as to whether a last response message has already been received (e.g., has a timeout for response messages expired without receiving another response message?). If the determination is positive (e.g., YES), the burst mode module determines that at least one command in the given subset of commands has not been received by the deployed remote vehicle, and the method400proceed to440. If the determination at448is negative (e.g., NO), the method400returns to430.

At450, the burst upload module makes a determination as to whether additional commands in the set of command for the mission plan need to be sent to complete the upload of the mission plan to the deployed remote vehicle. If the determination at450is negative (e.g., NO), the method400proceeds to455. If the determination at450is positive (e.g., YES), the method400proceeds to460. At450, the upload of the mission plan is completed, and the method400ends. In some examples, the burst mode module can provide the mission plan module with an indication that the upload of the mission plan has been completed. At460, the burst mode parameters are adjusted based on the response messages, and the method400returns to415.

What have been described above are examples. It is, of course, not possible to describe every conceivable combination of components or methodologies, but one of ordinary skill in the art will recognize that many further combinations and permutations are possible. Accordingly, the disclosure is intended to embrace all such alterations, modifications, and variations that fall within the scope of this application, including the appended claims. As used herein, the term “includes” means includes but not limited to, the term “including” means including but not limited to. The term “based on” means based at least in part on. Additionally, where the disclosure or claims recite “a,” “an,” “a first,” or “another” element, or the equivalent thereof, it should be interpreted to include one or more than one such element, neither requiring nor excluding two or more such elements.