System and method for secure communication with one or more unmanned aerial vehicles

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is a continuation of U.S. patent application Ser. No. 16/186,891, filed Nov. 12, 2018, the entire contents of which is hereby incorporated by reference.

FIELD

0002The described embodiments relate to unmanned aerial vehicles and, in particular, to a system and method for secure communication with one or more unmanned aerial vehicles.

INTRODUCTION

0003Unmanned aerial vehicles (UAVs) are being used increasingly for a variety of applications, including, inter alia, for the delivery of articles, parcels, and packages between various parties. In many cases, the in-flight operation of UAVs is controlled through a remote computing system. To this end, the remote computing system may transmit commands, and receive information, from one or more UAVs. An obstacle exists in ensuring that communication between the remote computing system, and the one or more UAVs, occurs in a secure and authenticated manner.

SUMMARY

0004The following introduction is provided to introduce the reader to the more detailed discussion to follow. The introduction is not intended to limit or define any claimed or as yet unclaimed invention. One or more inventions may reside in any combination or sub-combination of the elements or process steps disclosed in any part of this document including its claims and figures.

0005In accordance with one aspect of this disclosure, which may be used alone or in combination with any other aspect, there is provided a system for secure communication with one or more unmanned aerial vehicles, the system comprising: a controller located on an unmanned aerial vehicle (UAV) of the one or more unmanned aerial vehicles, wherein the controller comprises a processor, and a communication module configured to receive and transmit data over a communication network; an autopilot in data communication with the controller, wherein the autopilot is also located on the UAV and is configured to control the UAV; and a flight management system including at least one computing system having a non-transient memory with executable instructions, wherein the flight management system is in data communication with the controller over the communication network.

0006In some embodiments, the at least one computing system is operable with said executable instructions to: receive over the communication network a message generated by the controller of the UAV; extract, from the message, an unmanned aerial vehicle serial number and a secret key; compute a hash of the secret key to generate a first hashed secret key; retrieve, from an internal database located on the non-transient memory, a second hashed secret key associated with the unmanned aerial vehicle serial number; compare the first hashed secret key with the second hashed secret key, wherein the message is determined to be valid if the first hashed secret key agrees with the second hashed secret key.

0007In some embodiments, the message is a hypertext transfer protocol (HTTP) POST message which is transmitted over an HTTP secure channel.

0008In some embodiments, the message is a polling request configured to initiate communication between the UAV and the at least one computing system.

0009In some embodiments, after determining the message to be valid, the computing system is further operable with said instructions to transmit to the controller of the UAV, via the communication network, a first response poll message.

0010In some embodiments, the first response poll message comprises one of a command message, an information request message, and an acknowledgment message.

0011In some embodiments, the first response poll message is a command message, wherein the command message comprises: a payload field defined by an encoded command; and a hash field defined by a first hash of the encoded command.

0012In some embodiments, after receiving the first response poll message, the processor of the controller system is configured to: generate a second hash of the encoded command in the payload field; compare the second hash with the first hash of the encoded command; and based on the compare, transmit to the at least one computing system a second response poll message indicating whether the first hash agrees with the second hash.

0013In some embodiments, the first response poll message is an information request message, and wherein after receiving the first response poll message, the processor for the controller system is configured to: generate a second response poll message, wherein the second response poll message includes the requested information; and transmit the second response poll message to the at least one computing system.

0014In some embodiments, the message comprises an alert message, and wherein the alert message indicates at least one of a failed command execution by the autopilot and a status change in the autopilot.

0015In some embodiments, the message comprises a heartbeat message, wherein the heartbeat message includes information retrieved from at least one of the autopilot and the controller.

0016In some embodiments, the message is a short message service (SMS) message.

0017In some embodiments, the hashing employs an SHA256 hash method.

0018In some embodiments, the at least one computing system is operable with said executable instructions to: receive, over the communication network, a key request message generated by the controller located on the unmanned aerial vehicle (UAV); generate an encryption key and a session identification number in response to the key request message; transmit the encryption key and the session identification number to the controller; receive, from the controller, an encrypted heartbeat message which includes an initialization vector and the session identification number; and de-crypt the encrypted heartbeat message using the initialization vector, the encryption key and the session identification number.

0019In some embodiments, the controller located on the unmanned aerial vehicle (UAV) is configured to: transmit to the flight management system a key request message; receive from the flight management system an encryption key and a session identification number; using the encryption key, encrypt a heartbeat message to generate an encrypted heartbeat message; attach the session identification number to the encrypted heartbeat message; and transmit the encrypted heartbeat message to the flight management system.

0020In some embodiments, the controller is further configured to compress the heartbeat message.

0021In some embodiments, encryption key is an AES-256-encryption key.

0022In some embodiments, the controller is further configured to: generate an initialization vector; and attach the initialization vector to the encrypted heartbeat message.

0023In some embodiments, the encoded command includes a command for one of loading UAV route data and modifying UAV route data.

0024In accordance with one aspect of this disclosure, which may be used alone or in combination with any other aspect, there is provided a method for secure communication with one or more unmanned aerial vehicles, the method comprising: receive, from an unmanned aerial vehicle (UAV) of the one or more unmanned vehicles, a message; extract, from the message, an unmanned aerial vehicle serial number and a secret key; compute a hash of the secret key to generate a first hashed secret key; retrieve, from an internal database located on the non-transient memory, a second hashed secret key associated with the unmanned aerial vehicle serial number; compare the first hashed secret key with the second hashed secret key, wherein the message is determined to be valid if the first hashed secret key agrees with the second hashed secret key.

0025In some embodiments, the message from the UAV is generated by a controller of the UAV.

0026In accordance with one aspect of this disclosure, which may be used alone or in combination with any other aspect, there is provided a controller, for mounting in a UAV to control operation of an autopilot mounted in the UAV, the controller comprising: a processor; a communications module, for communication with a flight management system; executable instructions for communicating with the autopilot.

0027In some embodiments, the controller further comprises a modem for cellular, very high frequency (VHF), ultra-high frequency (UHF), or satellite communication with the flight management system.

0028In some embodiments, the controller further comprises at least one of a polling system, a heartbeat module, an alert module, a compression module, a log-shipping module, and a key-request and encryption module.

0029In some embodiments, the controller further comprises additional executable instructions that extend the function of the autopilot.

0030In some embodiments, the controller further comprises general-purpose input and output ports, for communication with devices of the UAV not controlled and/or not in communication with the autopilot.

0031In some embodiments, the controller further comprises: a serial link between the controller and the autopilot.

0032It will be appreciated by a person skilled in the art that a system or method disclosed herein may embody any one or more of the features contained herein and that the features may be used in any particular combination or sub-combination.

0033These and other aspects and features of various embodiments will be described in greater detail below.

DRAWINGS

A preferred embodiment of the present invention will now be described in detail with reference to the drawings, in which:

<figref idref="DRAWINGS">FIG. <b>1</b>A</figref> is a simplified schematic diagram of a system for secure communication between a flight management system and one or more UAVs;

<figref idref="DRAWINGS">FIG. <b>1</b>B</figref> is a simplified block diagram of a computing device in accordance with at least some embodiments;

<figref idref="DRAWINGS">FIG. <b>2</b>A</figref> is a simplified block diagram of a UAV;

<figref idref="DRAWINGS">FIG. <b>2</b>B</figref> is a simplified block diagram of a UAV autopilot;

<figref idref="DRAWINGS">FIG. <b>2</b>C</figref> is a simplified block diagram of a UAV controller;

<figref idref="DRAWINGS">FIG. <b>3</b>A</figref> is a simplified block diagram of a flight management system, in accordance with at least some embodiments;

<figref idref="DRAWINGS">FIG. <b>3</b>B</figref> is a simplified block diagram of a system for secure communication between the flight management system, the UAV controller, and the UAV autopilot;

<figref idref="DRAWINGS">FIG. <b>4</b>A</figref> is an example structure for an HTTPS message which may be transmitted by the flight management system to the UAV controller;

<figref idref="DRAWINGS">FIG. <b>4</b>B</figref> is an example structure for an HTTPS message which may be transmitted by the UAV controller to the flight management system;

<figref idref="DRAWINGS">FIGS. <b>5</b>A to <b>5</b>D</figref> are example message which may be transmitted between the UAV controller and the flight management system in a polling transaction, according to some embodiments;

<figref idref="DRAWINGS">FIGS. <b>6</b>A to <b>6</b>C</figref> are example message which may be transmitted between the UAV controller and the flight management system in a polling transaction, according to other embodiments;

<figref idref="DRAWINGS">FIGS. <b>7</b>A to <b>7</b>C</figref> are example message which may be transmitted between the UAV controller and the flight management system in a polling transaction, according to still other embodiments;

<figref idref="DRAWINGS">FIGS. <b>8</b>A and <b>8</b>B</figref> are example message which may be transmitted between the UAV controller and the flight management system in a polling transaction, according to yet still other embodiments;

<figref idref="DRAWINGS">FIG. <b>9</b></figref> is an example alert message which may be transmitted by the UAV controller to the flight management system, according to some embodiments;

<figref idref="DRAWINGS">FIG. <b>10</b></figref> is an example heartbeat message which may be transmitted by the UAV controller to the flight management system, according to some embodiments;

<figref idref="DRAWINGS">FIG. <b>11</b></figref> is a process flow diagram for an example method for a control/polling service, according to some embodiments;

<figref idref="DRAWINGS">FIG. <b>12</b>A</figref> is a process flow for an example method for implementing the control/polling service, as viewed from the perspective of the flight management system;

<figref idref="DRAWINGS">FIG. <b>12</b>B</figref> is a process flow for an example method for implementing the polling/control service, as viewed from the perspective of the UAV controller;

<figref idref="DRAWINGS">FIG. <b>13</b></figref> is a process flow for an example method for short message service (SMS) communication between the flight management system and the UAV controller;

<figref idref="DRAWINGS">FIG. <b>14</b></figref> is a process flow for a method for authenticating, by the flight management system, messages received from the UAV controller; and

<figref idref="DRAWINGS">FIG. <b>15</b></figref> is a process flow for a method for transmitting a heartbeat message, according to some embodiments.

DESCRIPTION OF VARIOUS EMBODIMENTS

0056Various systems, apparatuses or methods will be described below to provide an example of an embodiment of each claimed invention. No embodiment described below limits any claimed invention and any claimed invention may cover apparatuses and methods that differ from those described below. The claimed inventions are not limited to systems, apparatuses and methods having all of the features of any one apparatus or method described below, or to features common to multiple or all of the systems, apparatuses or methods described below. It is possible that a system, apparatus or method described below is not an embodiment of any claimed invention. Any invention disclosed in a system, apparatus or method described below that is not claimed in this document may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicant(s), inventor(s) and/or owner(s) do not intend to abandon, disclaim or dedicate to the public any such invention by its disclosure in this document.

0057For simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements or steps. In addition, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments generally described herein. Furthermore, this description is not to be considered as limiting the scope of the embodiments described herein in any way, but rather as merely describing the implementation of various embodiments as described.

0058In many cases, unmanned aerial vehicles (UAVs) are remotely controlled by a UAV operator positioned at, for example, a remote computing device. The UAV operator is able to transmit commands in respect of the operation of the UAVs, as well as receive information therefrom. In many cases, the operator does not effect real time control of the UAV; rather the operator provides the UAV with instructions for a particular flight path, that the UAV then follows autonomously. An obstacle exists in ensuring that communication between the UAV operator and the UAVs occurs in a secure manner.

0059Provided herein is a system and method for secure communication between a remote computing device and one or more unmanned aerial vehicles, and a controller for use in the system and method.

0060In particular, and as described in further detail herein, secure communication is effected by configuring the UAVs to accept only solicited communication or messages. This feature helps to prevent unauthorized access, or unauthorized attacks by third parties on the UAVs (e.g., denial-of-service (DoS) attacks). As also described herein, secure communication is also achieved by using Transport Layer Security (TLS) protocol for communications between the UAVs and the remoting computing device. In particular, TLS protocol can secure communications by preventing man-in-the-middle attacks. In various embodiments, the secure communication is used to transmit or modify route information from a flight management system to one or more UAVs.

0061Referring now to <figref idref="DRAWINGS">FIG. <b>1</b>A</figref>, there is shown is a simplified schematic diagram of a system <b>100</b> for secure communication between one or more UAVs <b>104</b><i>a</i>, <b>104</b><i>b</i>, and <b>104</b><i>c</i>, in accordance with at least some embodiments. The system <b>100</b> provides the environment in which the methods described herein generally operate. Effected

0062As shown, the system <b>100</b> includes a flight management system <b>102</b> which is in data communication with the one or more UAVs <b>104</b><i>a</i>, <b>104</b><i>b</i>, and <b>104</b><i>c</i>. The communication between the flight management system <b>102</b> and the UAVs <b>104</b><i>a </i>to <b>104</b><i>c </i>may occur over a communication network <b>106</b>. Communication network <b>106</b> may be, for example, one or more of a wireless personal area network such as a Bluetooth™ network, a wireless local area network such as the IEEE 802.11 family of networks, a cellular communication network, Ethernet or a satellite communication network.

0063In various embodiments, the UAVs <b>104</b><i>a </i>to <b>104</b><i>c </i>may be used for delivery of articles, parcels, or packages between various locations, or between various parties.

0064Further, while only three UAVs are illustrated in the system <b>100</b>, in other cases, the system <b>100</b> may include any number of UAVs.

0065Generally, the flight management system <b>102</b> may be configured to control the operation of one or more of UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. For example, the flight management system <b>102</b> may be configured to send commands (i.e., including route information), via communication network <b>106</b>, to the UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. The flight management system <b>102</b> may be configured to request and receive information from the UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. The information may be in respect of the status and location of a particular UAV. The flight management system <b>102</b> may be configured to receive “alert” messages from UAVs <b>104</b><i>a </i>to <b>104</b><i>c </i>due to unexpected or spontaneous events.

0066The system <b>100</b> may also include a computing device <b>108</b> and an external server <b>110</b>. In some cases, the computing device <b>108</b> may be operated by, for example, by the UAV operator.

0067In examples provided herein, the flight management system <b>102</b> may be provided, and otherwise operable, on the computing device <b>108</b>. In other embodiments, the flight management system <b>102</b> may be located (or hosted) on the external server <b>110</b>. In these cases, the communication network <b>106</b> can include a wired component which allows for the option of wired communication between the computing device <b>108</b> and the external server <b>110</b>.

0068Referring now to <figref idref="DRAWINGS">FIG. <b>1</b>B</figref>, there is illustrated a schematic block diagram of an example computing device <b>108</b> and/or an example server <b>110</b>. While the remainder of the discussion herein is in reference to the computing device <b>108</b>, it will be understood that the discussion is equally applicable to the server <b>110</b>.

0069As shown, the computing device <b>108</b> may include a processor <b>108</b><i>a </i>in communication with a memory <b>108</b><i>b</i>, a communication interface <b>108</b><i>c</i>, and a user interface <b>108</b><i>d. </i>

0070Processor <b>108</b><i>a </i>may receive information from the various components of the computing device <b>108</b> and may be configured to execute a plurality of instructions using the received information, as described further herein.

0071The memory <b>108</b><i>b </i>may be, for example, a non-volatile read-write memory which stores computer-executable instructions and data, and a volatile read-write memory (e.g., random access memory) that may be used as a working memory by processor <b>108</b><i>a. </i>

0072In various cases provided herein, the executable instructions on memory <b>108</b><i>b </i>include those provided by the flight management system <b>102</b>.

0073Communication interface <b>108</b><i>c </i>may be configured to send and receive data. Communication interface <b>108</b><i>c </i>may, for example, comprise a wireless transmitter or transceiver and antenna. In some embodiments, the communication interface <b>108</b><i>c </i>may receive information and data from one or more of UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. This information and/or data can then be transmitted to the processor <b>108</b><i>c </i>for processing. In other cases, the communication module <b>108</b><i>c </i>can transmit instructions and/or data to one or more UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. Accordingly, communication interface <b>108</b><i>c </i>can be configured to provide duplex communication.

0074User interface <b>108</b><i>d </i>may be one or more devices that allows a user, or operator, to interact with the computing device <b>108</b>. The user interface <b>108</b><i>d </i>may have a keyboard, touchscreen, or other input device that allows a user to input instructions.

0075In at least some embodiments provided herein, a user (i.e. the UAV operator) may insert commands (i.e., in respect of a UAV route), or requests for information, via the user interface <b>108</b><i>d </i>which are to be transmitted to one or more of UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. In other cases, the computing device <b>108</b> or server <b>110</b> may receive information or message from one or more UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. These messages may be decoded by the flight management system <b>102</b> (i.e. according to executable instructions stored, for example, on the memory <b>108</b><i>b</i>). These messages may then be displayed to the user via the user interface <b>108</b><i>d</i>. To this end, the user interface <b>108</b><i>d </i>may include a graphical user interface (GUI) to facilitate use by the computer operator. The user interface may also include a web page located on a web browser.

0076Referring now to <figref idref="DRAWINGS">FIG. <b>2</b>A</figref>, there is illustrated a simplified block diagram of a UAV <b>200</b>. The UAV <b>200</b> may be analogous to one of UAVs <b>104</b><i>a </i>to <b>104</b><i>c </i>of <figref idref="DRAWINGS">FIG. <b>1</b>A</figref>.

0077As shown, the UAV <b>200</b> may include an autopilot <b>202</b> in data communication with a UAV controller <b>204</b>. In various cases, the UAV <b>200</b> may also include a power module <b>208</b> and one or more sensors <b>206</b>.

0078The controller <b>204</b> may be a direct digital control (DDC) controller configured to facilitate communication between the flight management system <b>102</b> and the on-board autopilot <b>202</b>.

0079For example, in at least some cases, the controller <b>204</b> may be configured to receive commands from the flight management system <b>102</b> (operating on the computing device <b>108</b>) via the network <b>106</b>. These commands are then transmitted by the UAV controller <b>204</b> to the autopilot <b>202</b>. In other cases, the controller <b>204</b> may be configured to transmit information to the flight management system <b>102</b> in respect of the operation of the controller <b>204</b> and/or the autopilot <b>202</b>.

0080The UAV autopilot <b>202</b> may be a system for controlling the trajectory and motion of the UAV <b>200</b>. Generally, an autopilot is required to receive a pre-planned route, use sensors to determine position orientation and velocity parameters of the UAV, and to control motors and other control devices on the UAV to control the UAV and cause it to follow the preplanned route. The autopilot should also be capable of receiving and acting on changes to the route, as well as responding to action commands (e.g., landing, hovering, changing altitude, etc.). While some present autopilots may not be capable of autonomously detecting and responding to adverse events, e.g. unexpected weather conditions or obstacle avoidance, that may require changes to the route, it is anticipated that autopilots will increasingly incorporate such capabilities in the future, e.g. with the use of artificial intelligence.

0081In at least some embodiments, the autopilot <b>202</b> controls the UAV <b>200</b> based on action commands received from the flight management system <b>102</b>, via the UAV controller <b>204</b>.

0082Sensors <b>206</b> may be on-board sensors which configured to measure various parameters. By way of non-limiting examples, sensors <b>206</b> may include temperature sensors, current sensors, velocity sensors, airspeed sensors, altitude sensors, and/or inertial measurement units (IMUs) (e.g., which include gyroscopes, magnetometers and accelerometers). In various cases, measurements collected by the sensors <b>206</b> may be transmitted to the UAV controller <b>204</b>. Further, and as described in more detail herein, the UAV controller <b>204</b> may then transmit the sensor measurements as part of “heartbeat” messages transmitted to the flight management system <b>102</b>.

0083A UAV may have a variety of motors, actuators, lights and control devices, and also a variety of sensors, such as those mentioned above. E.g., it may include navigation lights, bay doors and associated motors and avionics. As required, each of these may be connected to one, or possibly both of the controller and the autopilot, for receiving control signals and for transmitting data. While the autopilot may be controlled by the controller, it may receive inputs from sensors directly, and correspondingly may control drive motors, etc. directly.

0084A power module <b>208</b> is also provided to provide power to the various components of the UAV <b>200</b>. The power module <b>208</b> may include, for example, an avionics battery capable of supplying power to the UAV <b>200</b> for a determined period of time, as well as a servo battery that is configured to supply power to the UAV motors.

0085Referring now to <figref idref="DRAWINGS">FIG. <b>2</b>B</figref>, there is illustrated a simplified block diagram of the autopilot <b>202</b>.

0086The autopilot <b>202</b> may include, for example, an input/output module <b>202</b><i>a</i>, a GPS module <b>202</b><i>b</i>, a processor <b>202</b><i>c</i>, and a memory <b>202</b><i>d. </i>

0087The input/output <b>202</b><i>a </i>may be configured to send and receive data to and from the UAV controller <b>204</b>. For example, the input/output module <b>202</b><i>a </i>may be configured to transmit information to the UAV controller <b>204</b>. This may be information requested by the flight management system <b>102</b>. In other cases, the input/output module <b>202</b><i>a </i>may receive commands from the UAV controller <b>204</b> in respect of the operation of the UAV (e.g., take-off, landing, change of route). These may be commands received by the UAV controller <b>204</b> from the flight management system <b>102</b>. In at least some embodiments, the input/output module <b>202</b><i>a </i>may include a serial communication interface to facilitate serial communication with the UAV controller <b>204</b>.

0088The GPS module <b>202</b><i>b </i>is configured to receive GPS data coordinates for the UAV <b>200</b>. In some cases, the GPS data coordinates retrieved by the GPS module <b>202</b><i>c </i>may be communicated to the flight management system <b>102</b> via the UAV controller <b>204</b>.

0089The processor <b>202</b><i>c </i>may receive information from the various components of the autopilot <b>202</b> and may be configured to execute a plurality of instructions using the received information, as described further herein.

0090The memory <b>202</b><i>d </i>may be again, for example, a non-volatile read-write memory which stores computer-executable instructions and data, and a volatile read-write memory (e.g., random access memory) that may be used as a working memory by processor <b>202</b><i>c</i>. In various embodiments, the memory <b>202</b><i>d </i>may store route or pattern information for the UAV <b>200</b>. The route information may have been received, for example, from the flight management system <b>102</b> via the UAV controller <b>204</b> (e.g., using a route file generated by the flight management system <b>102</b>). In other embodiments, the memory <b>202</b><i>d </i>can store various information in respect of various autopilot parameters. The autopilot parameters may be provided to the UAV controller <b>204</b> upon an information request from the flight management system <b>102</b>.

0091A route file typically consists of waypoints (GPS, altitude, speed, climb rate, etc.) and instructions on what to do if the UAV gets into trouble (hover, land, emergency, etc.). The Flight Management System (<b>102</b>, <b>300</b>) creates the routes and ensures they are valid, i.e. route does not move through no fly-zones, does not violate license parameters, contains valid takeoff and landing zones, etc.

0092Different UAVs can have different types of autopilots, which in turn, require different route files. The Flight Management System <b>102</b> keeps track of each UAV and its autopilot and creates route files specifically for each type of autopilot. The Flight Management System <b>102</b> may be designed to accommodate different types of autopilots through firmware versions.

0093Referring now to <figref idref="DRAWINGS">FIG. <b>2</b>C</figref>, there is illustrated a simplified block diagram of the UAV controller <b>204</b>.

0094As shown, the UAV controller <b>204</b> may include a processor <b>204</b><i>a</i>, a communication module <b>204</b><i>b</i>, a memory <b>204</b><i>c</i>, a polling module <b>204</b><i>d</i>, a heartbeat module <b>204</b><i>e</i>, an alert module <b>204</b><i>f</i>, a key-request and encryption module <b>204</b><i>g</i>, a compression module <b>204</b><i>h</i>, a log-shipping module <b>204</b><i>i</i>, one or more GPIO ports <b>204</b><i>j</i>, and an autopilot input/output module <b>204</b><i>k. </i>

0095The processor <b>204</b><i>a </i>may receive information from the various components of the UAV controller <b>204</b>, and may be configured to execute a plurality of instructions using the received information, as described further herein.

0096The memory <b>204</b><i>c </i>may be, for example, a non-volatile read-write memory which stores computer-executable instructions and data, and a volatile read-write memory (e.g., random access memory) that may be used as a working memory by processor <b>204</b><i>a. </i>

0097In various embodiments disclosed herein, the memory <b>204</b><i>c </i>may store commands received from the flight management system <b>102</b> (e.g., action commands). In other embodiments, the memory <b>204</b><i>c </i>may also store information collected by the UAV controller <b>204</b> other devices located on-board the UAV <b>204</b> (e.g., information from sensors <b>206</b>). In still other embodiments, the memory <b>204</b><i>c </i>may store computer-executable programs which facilitates communication between the UAV controller <b>204</b> and the autopilot <b>202</b>. For example, the program can be an autopilot specific software. In yet still other embodiments described herein, the memory <b>204</b><i>c </i>may store software, or processor executable-instructions, in respect of the services provided by the polling module <b>204</b><i>d</i>, the heartbeat module <b>204</b><i>e</i>, and/or the alert module <b>204</b><i>f </i>of the UAV controller <b>204</b>.

0098Communication module <b>204</b><i>b </i>may be configured to send and receive data or information, via network <b>106</b> to and from the flight management system <b>102</b>, operating for example, on the computing device <b>108</b> or server <b>110</b>. Communication module <b>204</b><i>b </i>may, for example, comprise a wireless transmitter or transceiver and antenna, and may further include a modem. In some embodiments, the communication module <b>204</b><i>b </i>may receive information and data from the flight management system <b>102</b> which can then be transmitted to the processor <b>204</b><i>a </i>for processing. In other cases, the communication module <b>204</b><i>b </i>can transmit data to the flight management system <b>102</b> operating on the computing device <b>108</b> or the server <b>110</b>. Accordingly, communication module <b>204</b><i>b </i>can be configured to provide duplex communication

0099In at least some embodiments, the communication module <b>204</b><i>b </i>may be further configured for multiple methods of communication. By way of non-limiting examples, the communication module <b>204</b><i>b </i>may be configured for Ethernet, Wi-Fi, cellular, satellite, Ultra High Frequency (UHF), and/or Very High Frequency (VHF) communication. This ensures that the UAV controller <b>204</b> is in constant communication with the flight management system <b>102</b>.

0100The polling module <b>204</b><i>d</i>, as explained in further detail herein, is associated with the control service of the flight management system <b>102</b>. In particular, the polling module <b>204</b><i>d </i>is operable to generate instructions, executable by the processor <b>204</b><i>a</i>, for transmitting periodic poll requests to the flight management system <b>102</b>. Periodic polling is used to determine whether the flight management system <b>102</b> has instructions in queue for the UAV <b>200</b> (e.g., commands or requests for information).

0101The heartbeat module <b>204</b><i>e </i>is associated with the heartbeat service of the flight management system <b>102</b>. The heartbeat module <b>204</b><i>e </i>is configured to generate instructions to transmit periodic and continuous ‘heartbeat’ messages to the flight management system <b>102</b>. As explained further herein, the heartbeat messages may include information in respect of the status and/or location of the UAV <b>200</b>. For example, the heartbeat messages may include periodic information on the GPS location of the UAV <b>200</b>, as retrieved from the GPS module <b>202</b><i>c </i>of the autopilot <b>202</b>. As explained in further detail herein, heartbeat messages may be transmitted to the flight management system <b>102</b> using User Datagram Protocol (UDP). In these cases, the ‘heartbeat message’ may require encryption and compression to ensure that the message is transmitted securely and occupies minimum transmission bandwidth.

0102The alert module <b>204</b><i>f </i>is associated with the alert service of the flight management system <b>102</b>. The alert module <b>204</b><i>f </i>is configured to generate instructions to transmit unexpected alert messages to the flight management system <b>102</b>. For example, the alert messages may be generated if the autopilot <b>202</b> fails to load a command received from the flight management system <b>102</b> (e.g., failed to execute take-off or landing).

0103In various cases, the polling module <b>204</b><i>d</i>, heartbeat module <b>204</b><i>e</i>, and alert module <b>204</b><i>f </i>are located within the memory <b>204</b><i>c</i>. More particularly, the memory <b>204</b><i>c </i>may store the processor-executable instructions which implement the functionalities of each of the modules <b>204</b><i>d </i>to <b>204</b><i>f. </i>

0104The key-request and encryption module <b>204</b><i>g </i>is configured to request an encryption key from the flight management system <b>102</b>. In some cases, the encryption key request is made at the beginning of a flight session, or otherwise when the controller is first powered-on. The encryption key (i.e., received from the flight management system <b>102</b>) is then used by the module <b>204</b><i>g </i>to encrypt communications from the controller <b>204</b> to the flight management system <b>102</b>. For example, messages generated by the heartbeat module <b>204</b><i>e </i>may be transmitted over a UDP channel and may be encrypted with the encryption key for additional security (i.e., UDP does not include built-in security). This may accordingly enhance the security of communications between the controller <b>204</b> and the flight management system <b>102</b>. In some embodiments described herein, Security may be further enhanced by ensuring that the encryption key is valid (or usable) for only a single flight session.

0105While the key-request and encryption module <b>204</b><i>g </i>has been illustrated in <figref idref="DRAWINGS">FIG. <b>2</b>C</figref> as a single module, in other cases, the key-request and encryption module <b>204</b><i>g </i>may be comprised of two separate modules (e.g., a key-request module, and an encryption module).

0106The compression module <b>204</b><i>h </i>may be used to compress heartbeat messages transmitted by the controller <b>204</b> to the flight management system <b>102</b>. In particular, this is to ensure that the size of the transmission stream is minimized, and accordingly, does not consume unnecessary transmission bandwidth. This feature is useful where transmission occurs over a satellite connection which are typically low bandwidth and high latency.

0107The log-shipping module <b>204</b><i>i </i>may maintain a log of events and actions undertaken by the UAV controller <b>204</b> (e.g., transmitted and received messages, and connection attempts to network <b>106</b>). This log file may be transmitted to the flight management system <b>102</b>.

0108The GPIO ports <b>204</b><i>j </i>are configured to facilitate communication between the UAV controller <b>204</b> and one or more devices on-board the UAV <b>200</b>. For example, the GPIO ports <b>204</b><i>j </i>can connect to one or more sensors <b>206</b>.

0109The autopilot input/output module <b>204</b><i>k </i>is configured to allow for communication between the UAV controller <b>204</b> and the autopilot <b>202</b>. To this end, the module <b>204</b><i>k </i>may be a serial communication interface to facilitate serial communication with the autopilot <b>202</b>.

0110Referring now to <figref idref="DRAWINGS">FIG. <b>3</b>A</figref>, there is illustrated a simplified block diagram of a flight management system <b>300</b> according to an example embodiment. The flight management system <b>300</b> may be analogous to the flight management system <b>102</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>, and in this specification the references <b>102</b> and <b>300</b> are used interchangeably. In various embodiments, the flight management system <b>300</b> may be configured to operate on the computing device <b>108</b>. For example, the various services offered by the flight management system <b>300</b>, as described herein, may be implemented as processor-executable instructions which are stored on the memory <b>108</b><i>b </i>of computing device <b>108</b>.

0111As shown in <figref idref="DRAWINGS">FIG. <b>3</b>A</figref>, the flight management system <b>300</b> may include a control service <b>302</b>, a heartbeat service <b>304</b>, an alert service <b>306</b>, a messaging service <b>308</b>, a translation service <b>310</b>, a key-request service <b>312</b>, and a log-shipping service <b>314</b>.

0112The control service <b>302</b> is a web-based service that is configured to receive polling requests generated by the polling module <b>204</b><i>d </i>of the UAV controller <b>204</b>.

0113As described in further detail herein, the control service <b>302</b> may be operable to receive a polling request from the UAV controller <b>204</b>. In response to the polling request, the control service <b>302</b> may generate commands, or requests for information, to be transmitted back to the UAV controller <b>204</b>. The command messages, and requests for information, may be transmitted to the UAV controller <b>204</b> via the communication interface <b>108</b><i>c </i>of computing device <b>108</b>. In at least some embodiments, the control service <b>302</b> is a REST-based control service.

0114The heartbeat service <b>304</b> is a User Datagram Protocol (UDP) service that is configured to receive and process the periodic and continuous ‘heartbeat’ messages generated by the complementary heartbeat module <b>204</b><i>e </i>of the UAV controller <b>204</b>. To this end, the heartbeat service <b>304</b> is constantly “listening” and receptive to heartbeat communications which originate from the UAV controller <b>204</b>.

0115The alert service <b>306</b> is a web-based service that is configured to receive and process unexpected alert messages generated by the complementary alert module <b>204</b><i>f </i>of the UAV controller <b>204</b>. Similar to the heartbeat service <b>304</b>, the alert service <b>306</b> is always “listening” for unexpected alert messages.

0116The messaging service <b>308</b> is configured to generate short message service (SMS) format messages to the UAV controller <b>204</b>. The SMS messages may include instructions, or information requests. In various cases, the messaging service <b>308</b> is used as an alternative, or a back-up, to the control service <b>302</b>.

0117In at least some embodiments, the messaging service <b>308</b> may also include a queue where messages for each UAV are temporarily stored. In some cases, the messaging service <b>308</b> can re-arrange or replace the queued messages. The messages in the queue may also expire before they are retrieved.

0118The translation service <b>310</b> is configured to receives inputs by a user of the computing device <b>108</b> (e.g., commands for the autopilot <b>202</b>, or general information requests from UAV <b>200</b>), encode these messages, and place the messages in queue for transmission to the UAV controller <b>204</b>. The translation module <b>310</b> is also configured to de-code messages received from the UAV controller <b>204</b> to display to the user of computing device <b>108</b>.

0119The key-request service <b>312</b> is configured to receive encryption key requests from the key-request encryption module <b>204</b><i>g </i>(i.e., of the controller <b>204</b>). In response to a request, the key-request service <b>312</b> generates and transmits to the controller <b>204</b> a new encryption key. In some cases, the encryption key may be valid for at least one flight session. The key-request service <b>312</b> may also be configured to provide a session ID to the controller <b>204</b> which acts as a unique identifier for the UAV.

0120The logging-shipping service <b>214</b> is configured to accept log file archives generated by the logging-shipping module <b>204</b><i>i </i>in the UAV controller <b>204</b>.

0121Accordingly, the flight management system <b>300</b> provides for a number of independent services. According to various embodiments, each service may be configured to accept requests, or messages, from the complementary module in the UAV <b>204</b> at different rates of frequencies. For example, the heartbeat service <b>304</b> may be configured to operate at a high frequency rate (e.g. 5 hertz), while the control service <b>302</b> may be configured to operate at a low frequency rate (e.g. 0.1 hertz). In various cases, the higher frequency rate achieved by the heartbeat service results from the fact that the heartbeat service operates over a UDP channel, while the control service operates over a TCP channel. More specifically, higher frequency transmission rates are achievable over a UDP channel as UDP connections do not require a three-way handshake to transmit data packets, as may otherwise be required for a TCP connection. Other services such as the alert service <b>304</b>, or the key-request service <b>314</b> may only operate when necessary, i.e., rather than operating at a specific frequency.

0122Referring now to <figref idref="DRAWINGS">FIG. <b>3</b>B</figref>, there is shown a simplified block diagram of a system <b>330</b> for secure communication between the flight management system <b>300</b>, the UAV controller <b>204</b>, and the UAV autopilot <b>202</b>.

0123As shown, the system <b>300</b> includes the autopilot <b>202</b> which is provided on-board the UAV <b>200</b>. The autopilot <b>202</b> may include, for example, the autopilot processor <b>202</b><i>c </i>and the GPS module <b>202</b><i>b</i>. The GPS module <b>202</b><i>b </i>may be in data communication with a GPS satellite <b>345</b> to receive GPS information and data coordinates. The autopilot <b>202</b> may also be in communication with the UAV controller <b>204</b> via the autopilot input/output module <b>202</b><i>a</i>. The input/output module <b>202</b><i>a </i>may be a serial interface which is configured to receive a serial link <b>342</b>. To this end, the UAV controller <b>204</b> may also include its own input/output module <b>204</b><i>k </i>which interfaces with the serial link <b>342</b>.

0124As further shown by <figref idref="DRAWINGS">FIG. <b>3</b>B</figref>, an autopilot software API <b>340</b> can be provided on the UAV controller <b>204</b> to act as a bridge between the UAV controller <b>204</b> and the autopilot <b>202</b>. The API <b>304</b> may be included, for example, in the UAV controller's memory <b>204</b><i>c </i>in the form of computer-executable instructions. The UAV controller <b>204</b> also includes the processor <b>204</b><i>a</i>, GPIO ports <b>204</b><i>j</i>, the polling system (or module) <b>204</b><i>d</i>, the key-request and encryption module <b>204</b><i>g </i>(not shown), the heartbeat module <b>204</b><i>e</i>, the alert module <b>204</b><i>f</i>, the log-shipping module <b>204</b><i>i </i>(not shown), and the communication module <b>204</b><i>b</i>. In various embodiments, the communication module <b>204</b><i>b </i>includes a modem (including a cell/satellite modem <b>205</b>), as well as an antenna <b>204</b><i>b′. </i>

0125Custom software, or firmware, <b>335</b> can be provided on the UAV controller <b>204</b> to control at least the operation of the polling module <b>204</b><i>d</i>, the heartbeat module <b>204</b><i>e</i>, the alert module <b>204</b><i>f</i>, the key-request and encryption module <b>204</b><i>g</i>, and the log-shipping module <b>204</b><i>i</i>, as well as communication with the autopilot <b>202</b>. Similar to the API <b>340</b>, the custom firmware <b>335</b> can be included on the UAV controller's memory <b>204</b><i>c </i>as computer-executable instructions.

0126Communication between the UAV controller <b>204</b> and the flight management system <b>300</b> may occur over a wireless data network <b>344</b>. Wireless data network <b>344</b> may be analogous to the network <b>106</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. As explained in further detail herein, the data network <b>344</b> may include one or more “channels” which facilitate communication between the various services on the flight management system <b>300</b> and the corresponding modules in the UAV controller <b>204</b>.

0127The flight management system <b>300</b> includes the control service <b>302</b>, the heartbeat service <b>304</b>, the alert service <b>306</b>, the messaging (or SMS service) <b>308</b>, the key-request service <b>312</b> (not shown), as well as the log-shipping service <b>314</b> (not shown). The translation service <b>310</b>, which is also included in the flight management system <b>300</b>, is configured to receive and de-code messages received from the various services <b>302</b> to <b>314</b>. The de-coded content of these messages may then be used by the flight management system <b>300</b> to control various other peripheral systems connected to the flight management system. For example, in some cases, the messages may be used by the flight management system <b>300</b> to determine that a UAV is approaching a UAV landing spot. The flight management system <b>300</b> can accordingly prepare the UAV landing spot for the approaching UAV by transmitting appropriate messages and/or signals thereto. In other example cases, the de-coded messages can include secret keys, questions, or PINs which are processed by the flight management system <b>300</b> and displayed to, for example, a user of computing device <b>108</b> (e.g., a UAV handler). The UAV handler may then use the secret key or PIN for opening a locked gate for the UAV landing spot. In still other example cases, the messages may prompt various alert signals (e.g., lights or sounds) to be played to a user of computing device <b>108</b>. In at least some embodiments, the translation service <b>310</b> is also used to encode messages (e.g., commands or requests for information) for transmission from the flight management system <b>300</b> to the UAV controller <b>204</b> via the appropriate service.

0128In view of the foregoing, the operation of each of the control service <b>302</b>, heartbeat service <b>304</b>, alert service <b>306</b>, and messaging service <b>308</b> will now be described herein in further detail.

0129(a) Control/Polling Service

0130The control service allows the flight management system to: (a) transmit commands to one or more of UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>, and/or (b) request information from one or more UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>. As explained above, the control service is configured to work concomitantly with the polling module <b>204</b><i>d </i>of the UAV controller <b>204</b>. Accordingly, the control service may be referred to herein interchangeably as the polling service.

0131Referring now to <figref idref="DRAWINGS">FIG. <b>11</b></figref>, there is shown in more detail a process flow diagram for an example method <b>1100</b> for implementing the control/polling service according to an example embodiment. The method <b>1100</b> is carried out by the UAV controller <b>204</b> and the flight management system <b>102</b>, <b>300</b> (e.g., operating on the computing device <b>108</b>).

0132At <b>1102</b>, the UAV controller <b>204</b> may initiate communication with the flight management system <b>102</b> by sending a poll request over network <b>106</b>. In various embodiments disclosed herein, all communication between the UAV controller <b>204</b> and the flight management system <b>102</b> is initiated by the UAV controller <b>204</b>. In other words, the UAV controller <b>204</b> is not configured to accept un-solicited requests and information from the flight management system <b>102</b>.

0133The objective of the poll request is to determine whether the flight management system <b>102</b> has any commands, or information requests, in queue for the UAV <b>200</b>. In various embodiments, the UAV controller may transmit poll requests to the flight management system <b>102</b> at predetermined frequencies to determine whether there are instructions in queue. As described further herein, the polling frequency may be set by commands sent from the flight management system <b>102</b> to the UAV controller <b>204</b>.

0134The poll request may be implemented using a Secure HyperText Transfer Protocol (HTTPS) POST method which is encrypted using Transport Layer Security (TLS). As also explained further herein, this method may ensure that communication between the UAV controller <b>204</b> and the flight management system <b>102</b> is secure (i.e., by preventing man-in-the-middle attacks). In various embodiments, the UAV controller <b>204</b> is configured to direct the poll requests over the internet (i.e. network <b>106</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>) to a location having a known Uniform Resource Locator (URL) identifier which is associated, and accessible, by the control service <b>302</b> of the flight management system <b>300</b>

0135At <b>1104</b>, the flight management system <b>102</b>, operating on the computing device <b>108</b>, may receive the poll request from the UAV controller <b>204</b>.

0136At <b>1106</b>, the flight management system <b>102</b> may respond to the poll request by transmitting an HTTPS response. The HTTPS response may contain one of three messages: (a) an information request message, (b) a command message, or (c) a no-op message.

0137In the case of an information request message, the flight management system <b>102</b> will transmit a response at <b>1106</b><i>c </i>which requests information in respect of the UAV controller <b>204</b>, the autopilot <b>202</b>, and/or various devices located on-board the UAV <b>200</b>. For example, the flight management system <b>102</b> may request information in respect of readings for sensors mounted onto the UAV <b>200</b>.

0138If the UAV controller <b>204</b> receives an information request message, then at <b>1108</b><i>c</i>, the UAV controller <b>204</b> will respond with the requested information.

0139The flight management system <b>102</b> may also transmit command messages to the UAV controller <b>204</b>. For example, the commands may be in respect of a UAV action to be communicated to, and executed by, the autopilot <b>202</b> (e.g., landing, taking-off, or loading route information). In other cases, the command message may be in respect of setting, or defining, a particular controlling parameter (e.g., setting the polling period).

0140If the UAV controller <b>204</b> receives a command message, then at <b>1108</b><i>b</i>, the UAV controller <b>204</b> will respond with a message indicating whether the command was successfully or un-successfully received. An un-successfully received message may result from the command message being garbled, or otherwise corrupted, during transmission. As explained herein, the UAV controller <b>204</b> may determine whether the command message was corrupted during transmission by using a hashing verification method.

0141The flight management system <b>102</b> may also transmit a simple no-op message at <b>1106</b><i>a</i>. A no-op message is a simple acknowledgement by the flight management system <b>102</b> that the poll request was received, but that there is otherwise no commands or information requests in queue to be transmitted.

0142If the UAV controller <b>204</b> receives a no-op message, then the UAV controller <b>204</b> will perform no further action.

0143As explained herein, each of response <b>1108</b><i>a </i>to <b>1108</b><i>c </i>may also be implemented using an HTTPS POST method.

0144Once the UAV controller <b>204</b> has transmitted a response at <b>1108</b>, the method <b>1100</b> will return to <b>1102</b> whereby the UAV controller <b>204</b> will resume its periodic polling of the flight management system <b>102</b>.

0145The loop generated by method <b>1100</b>—i.e., as between the flight management system <b>102</b> and the UAV controller <b>204</b>—can operate using either a persistent or non-persistent HTTPS connections. A persistent connection has the advantage of not requiring a build up and take down of the connection for each poll request at <b>1102</b>. A persistent connection approach, however, has potential downside of additional management overhead on the UAV <b>200</b>, and potentially at the computing device <b>108</b>, when a connection is unexpectedly lost.

0146Referring now to <figref idref="DRAWINGS">FIGS. <b>4</b>A and <b>4</b>B</figref>, there is shown example structures for HTTPS messages generated by the flight management system <b>102</b> and the UAV controller <b>204</b> in the method <b>1100</b>.

0147Referring now first to <figref idref="DRAWINGS">FIG. <b>4</b><i>a</i></figref>, there is shown an example structure for an HTTPS response message <b>400</b>A that is generated by the flight management system <b>102</b> when communicating with the UAV controller <b>204</b>. In particular, the response message format <b>400</b>A is used when the flight management system <b>102</b> responds to poll request by the UAV controller <b>204</b> (i.e. <b>1106</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>)

0148As shown by <figref idref="DRAWINGS">FIG. <b>4</b>A</figref>, the response message <b>400</b>A includes a message identification (ID) field <b>404</b>A, a counter field <b>406</b><i>a</i>, a payload length field <b>408</b><i>a</i>, a payload field <b>410</b><i>a</i>, and a payload hash field <b>418</b><i>a</i>. The contents of the fields <b>404</b><i>a </i>to <b>418</b><i>a </i>may be encoded as hex strings representing byte arrays. In particular, using hex string to represent byte arrays allows for communication messages to be small and precise. This feature is important for bandwidth constrained channels (e.g., satellite channels).

0149The message ID field <b>404</b><i>a </i>identifies the particular contents of the response message <b>400</b>A (i.e. as expressed by the payload <b>410</b><i>a</i>). Table 1 below summarizes various example pre-defined message IDs <b>404</b>A. By way of example, a no-op message (i.e., <b>1106</b><i>a </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>) is expressed as a hex string 0x00. By way of a further example, command messages (i.e. <b>1106</b><i>b </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>), or information requests (i.e., <b>1106</b><i>c </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>) are expressed by message IDs that are unique to the particular command or information request. In various cases, the message ID field <b>404</b><i>a </i>may be expressed by a one byte hex string.

0150<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Message IDs</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry>Message</entry><entry /><entry /><entry /></row><row><entry>ID</entry><entry>Message</entry><entry>Description</entry><entry>Payload</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="center" /><tbody valign="top"><row><entry>No-Op/Routine Poll Messages:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry>0x00</entry><entry>No-op/Routine Poll</entry><entry>No message in queue for</entry><entry>0x00000000</entry></row><row><entry /><entry /><entry>UAV controller from flight</entry><entry /></row><row><entry /><entry /><entry>management system.</entry><entry /></row><row><entry /><entry /><entry>Alternatively, a message ID</entry><entry /></row><row><entry /><entry /><entry>0x00 may be used by the</entry><entry /></row><row><entry /><entry /><entry>UAV controller to indicate a</entry><entry /></row><row><entry /><entry /><entry>routine poll request.</entry><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="center" /><tbody valign="top"><row><entry>Command Messages:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry>0x10</entry><entry>Set polling period</entry><entry>Sets the polling period of</entry><entry>Value in seconds between</entry></row><row><entry /><entry /><entry>the UAV controller.</entry><entry>polling requests e.g. 0x05 -</entry></row><row><entry /><entry /><entry /><entry>initiate polling request every 5</entry></row><row><entry /><entry /><entry /><entry>seconds</entry></row><row><entry>0x11</entry><entry>Set heartbeat period</entry><entry>Sets the heartbeat period</entry><entry>Value in seconds between</entry></row><row><entry /><entry>for the UAV controller.</entry><entry>heartbeats e.g. 0x03 - send</entry><entry /></row><row><entry /><entry /><entry /><entry>heartbeat every 3 seconds</entry></row><row><entry>0x12</entry><entry>Set Parameter value</entry><entry>Sets the value of the</entry><entry>A hex string representation of</entry></row><row><entry /><entry /><entry>specified UAV parameter;</entry><entry>the ASCII encoding of the</entry></row><row><entry /><entry /><entry>uses key value format</entry><entry>following string:</entry></row><row><entry /><entry /><entry /><entry>updtParam|<parameter</entry></row><row><entry /><entry /><entry /><entry>name>|<value></entry></row><row><entry>0x20</entry><entry>Load route data</entry><entry>Load travel points/locations</entry><entry>Payload is a compressed</entry></row><row><entry /><entry /><entry>(waypoints), safe zones,</entry><entry>ASCII-encoded data.</entry></row><row><entry /><entry /><entry>circuits, patterns transmitted</entry><entry /></row><row><entry /><entry /><entry>via a route file</entry><entry /></row><row><entry>0x21</entry><entry>Load route data</entry><entry>Waypoints, safe zones,</entry><entry>Compressed ASCII-encoded</entry></row><row><entry /><entry /><entry>circuits, patterns transmitted</entry><entry>data.</entry></row><row><entry /><entry /><entry>via a route file</entry><entry /></row><row><entry>0x22</entry><entry>Start/stop pattern</entry><entry>Causes autopilot to jump to</entry><entry>A hex string representation of</entry></row><row><entry /><entry /><entry>a pre-configured pattern in</entry><entry>the ASCII encoding of the</entry></row><row><entry /><entry /><entry>the loaded route file (a file</entry><entry>following string:</entry></row><row><entry /><entry /><entry>which includes, but is not</entry><entry>StartPattern|<patternID></entry></row><row><entry /><entry /><entry>limited to, waypoints, flight</entry><entry /></row><row><entry /><entry /><entry>instructions or patterns), or</entry><entry /></row><row><entry /><entry /><entry>exit from a pattern</entry><entry /></row><row><entry>0x23</entry><entry>Unblock running</entry><entry>This function starts a thread</entry><entry>A hex string representation of</entry></row><row><entry /><entry>thread</entry><entry>of execution that has been</entry><entry>the ASCII encoding of the</entry></row><row><entry /><entry /><entry>stopped.</entry><entry>following string:</entry></row><row><entry /><entry /><entry /><entry>F|<threadID></entry></row><row><entry>0x24</entry><entry>Modify waypoint</entry><entry>This function modifies a</entry><entry>A hex string representation of</entry></row><row><entry /><entry /><entry>waypoint in the autopilot's</entry><entry>the ASCII encoding of the</entry></row><row><entry /><entry /><entry>memory buffer. It can</entry><entry>following string:</entry></row><row><entry /><entry /><entry>modify relative waypoints</entry><entry>ModifyWaypoint|2|<latitude</entry></row><row><entry /><entry /><entry>and absolute waypoints.</entry><entry>>|<longitude></entry></row><row><entry>0x25</entry><entry>Update Pattern</entry><entry>Update the GPS</entry><entry>A hex string representation of</entry></row><row><entry /><entry /><entry>coordinates in a pattern</entry><entry>the ASCII encoding of the</entry></row><row><entry /><entry /><entry /><entry>following string:</entry></row><row><entry /><entry /><entry /><entry>updtPattern|<patternIlD>|<</entry></row><row><entry /><entry /><entry /><entry>latitude>|<longitude></entry></row><row><entry>0x30</entry><entry>Set field value</entry><entry>Sets a field's value</entry><entry>A hex string representation of</entry></row><row><entry /><entry /><entry /><entry>the ASCII encoding of the</entry></row><row><entry /><entry /><entry /><entry>following string:</entry></row><row><entry /><entry /><entry /><entry>WriteVar|<fieldID>|<value></entry></row><row><entry>0x70</entry><entry>Cycle avionics power</entry><entry>To reboot the autopilot</entry><entry>0x00000000</entry></row><row><entry>0x71</entry><entry>Power on avionics</entry><entry>Power up the autopilot and</entry><entry>0x00000000</entry></row><row><entry /><entry /><entry>associated avionics</entry><entry /></row><row><entry /><entry /><entry>systems</entry><entry /></row><row><entry>0x72</entry><entry>Power down avionics</entry><entry>Power down the autopilot</entry><entry>0x00000000</entry></row><row><entry /><entry /><entry>and associated avionics</entry><entry /></row><row><entry /><entry /><entry>systems</entry><entry /></row><row><entry>0x73</entry><entry>Power on 900MHz</entry><entry>Power up the 900Mhz</entry><entry>0x00000000</entry></row><row><entry /><entry /><entry>manual control system for</entry><entry /></row><row><entry /><entry /><entry>manual flight control by a</entry><entry /></row><row><entry /><entry /><entry>user</entry><entry /></row><row><entry>0x74</entry><entry>Power down 900Mhz</entry><entry>Power down the 900Mhz</entry><entry>0x00000000</entry></row><row><entry /><entry /><entry>manual control system for</entry><entry /></row><row><entry /><entry /><entry>manual flight control by a</entry><entry /></row><row><entry /><entry /><entry>user.</entry><entry /></row><row><entry>0x75</entry><entry>Turn off main power</entry><entry /><entry>0x00000000</entry></row><row><entry>0x76</entry><entry>Power on visual</entry><entry>Power on the visual object</entry><entry>0x00000000</entry></row><row><entry /><entry>object tracker</entry><entry>tracker system which</entry><entry /></row><row><entry /><entry /><entry>includes RC</entry><entry /></row><row><entry>0x77</entry><entry>Power off visual</entry><entry>Power down the visual</entry><entry>0x00000000</entry></row><row><entry /><entry>object tracker</entry><entry>object tracker system</entry><entry /></row><row><entry>0xFF</entry><entry>Unsolicited, message</entry><entry>Information spontaneously</entry><entry>This can be an alert message</entry></row><row><entry /><entry /><entry>sent, that was not</entry><entry>that the autopilot or controller</entry></row><row><entry /><entry /><entry>requested by the flight</entry><entry>spontaneously sends out.</entry></row><row><entry /><entry /><entry>management system. This</entry><entry>The information is ASCII</entry></row><row><entry /><entry /><entry>message ID is only used in</entry><entry>encoded</entry></row><row><entry /><entry /><entry>the https request.</entry><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294pt" align="center" /><tbody valign="top"><row><entry>Information Requests:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="77pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><colspec colname="4" colwidth="98pt" align="left" /><tbody valign="top"><row><entry>0x40</entry><entry>Get field value</entry><entry>Send a field's value in the</entry><entry>Paylod is a hex string of the</entry></row><row><entry /><entry /><entry>follow-up POST request</entry><entry>following command which is</entry></row><row><entry /><entry /><entry>first ASCII encoded:</entry><entry>ReadVar|fieldID|value</entry></row><row><entry>0x50</entry><entry>Get controller board</entry><entry>Send value in the follow-up</entry><entry>0x00000000</entry></row><row><entry /><entry>firmware revision</entry><entry>POST request</entry><entry /></row><row><entry>0x60</entry><entry>Get sensor</entry><entry>Send temperature values in</entry><entry>0x00000000</entry></row><row><entry /><entry>temperatures</entry><entry>the follow-up POST request</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0151Accordingly, and as described herein, when the UAV controller <b>204</b> receives the message <b>400</b>A from the flight management system <b>102</b>, the controller may refer to the message ID to determine the contents of the message. To this end, the UAV controller <b>204</b> may include an internal database of message IDs, located for example, on the memory <b>204</b><i>c </i>of the UAV controller <b>204</b>. The internal database may be consulted by the UAV controller <b>204</b> to de-code the message ID field <b>404</b><i>a. </i>

0152In various embodiments, the message ID may be determined based on inputs received by the flight management system <b>102</b> from a user of computing device <b>108</b> (e.g., the user may insert commands, or information requests). The flight management system <b>102</b> may encode these commands according to the notation in Table 1 using the translation service, or functionality <b>310</b> of <figref idref="DRAWINGS">FIG. <b>3</b>A</figref>. In other embodiments, the message ID may be determined according to pre-defined instructions which are stored on the memory <b>108</b><i>b </i>of the computing device <b>108</b>. For instance, the flight management system <b>102</b> may be pre-configured to send commands to power-up or power-down subsystems of the UAV controller <b>204</b> at particular pre-defined points in time. Accordingly, in these cases, the flight management system may automatically determine the contents of the message ID field <b>404</b><i>a. </i>

0153The counter field <b>406</b><i>a </i>is a number that the flight management system <b>102</b> generates with each message to the UAV controller <b>204</b>. More particularly, and as described herein, when the UAV controller <b>204</b> responds to the flight management system <b>102</b>, it will reflect back the counter integer. This allows the flight management system <b>102</b> to “pair-up” any response from the UAV controller <b>204</b> with the message <b>400</b>A. This may be helpful where the flight management system <b>102</b> is sending and receiving a plurality of messages to a plurality of UAVs.

0154In various cases, the counter field <b>406</b>A is incremented with every message sent by the flight management system <b>102</b> to the UAV controller <b>204</b>. In at least some cases, the counter field <b>406</b><i>a </i>may be expressed as a two byte unsigned integer hex string.

0155The payload length field <b>408</b><i>a </i>represents the total length of the payload <b>410</b><i>a </i>(i.e. the actual message carried by the message <b>400</b>A). The payload length field <b>408</b><i>a </i>may be expressed as a 4 byte hex string. Where no payload is present (i.e., in a no-op message), the payload length field <b>408</b><i>a </i>is simply expressed as a hex string of zeros (i.e., 00000000).

0156The payload field <b>410</b><i>a </i>includes the actual contents of the response message <b>400</b>A. Table 1 above provides example formats for the payload field <b>410</b> in respect of different example message IDs <b>404</b><i>a. </i>

0157More particularly, and in at least some cases, the payload field <b>410</b><i>a </i>may include pattern instructions, or updates to patterns instructions, for the autopilot <b>202</b> to execute (see e.g., message ID's 0x20 and 0x25 in Table 1, above). These patterns may be in respect of pre-defined flight routes for the UAV <b>200</b>. In these cases, the payload must specify a pattern identification (ID) numbers (i.e., <patternID>), which identifies the nature of the pattern command. Table 2 below provides example Pattern ID commands which can be transmitted by the flight management system <b>102</b> to the UAV controller <b>204</b>:

0158<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Example Pattern Identification (ID) Numbers</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="35pt" align="left" /><colspec colname="4" colwidth="105pt" align="left" /><tbody valign="top"><row><entry>Command</entry><entry>Type</entry><entry>Pattern ID</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Hover here</entry><entry>Pattern</entry><entry><num></entry><entry>UAV will stop whatever it is </entry></row><row><entry /><entry /><entry /><entry>doing and hover at the current </entry></row><row><entry /><entry /><entry /><entry>location indefinitely.</entry></row><row><entry>Fly home</entry><entry>Pattern</entry><entry><num></entry><entry>UAV will change course and fly </entry></row><row><entry /><entry /><entry /><entry>to the home location (where ever </entry></row><row><entry /><entry /><entry /><entry>it took off from). It will then </entry></row><row><entry /><entry /><entry /><entry>hover above the home location </entry></row><row><entry /><entry /><entry /><entry>until another command is </entry></row><row><entry /><entry /><entry /><entry>received.</entry></row><row><entry>Land here</entry><entry>Pattern</entry><entry><num></entry><entry>UAV will stop whatever it is </entry></row><row><entry /><entry /><entry /><entry>doing and land at its current </entry></row><row><entry /><entry /><entry /><entry>location.</entry></row><row><entry>Land at home</entry><entry>Pattern</entry><entry><num></entry><entry>UAV will change course and </entry></row><row><entry /><entry /><entry /><entry>fly to the home location. It will </entry></row><row><entry /><entry /><entry /><entry>then land at the home location.</entry></row><row><entry>Safe zone</entry><entry>Pattern</entry><entry><num></entry><entry>UAV will change course, fly to </entry></row><row><entry /><entry /><entry /><entry>a pre-programmed GPS coordinate </entry></row><row><entry /><entry /><entry /><entry>and land there.</entry></row><row><entry>Exit pattern</entry><entry>Pattern</entry><entry><num></entry><entry>UAV will exit the current pattern </entry></row><row><entry /><entry /><entry /><entry>and return to the main mission.</entry></row><row><entry>GoTo here</entry><entry>Pattern</entry><entry><num></entry><entry>Fly to GPS coordinates in pattern </entry></row><row><entry /><entry /><entry /><entry><num>. Use modify waypoint or </entry></row><row><entry /><entry /><entry /><entry>modify command to first set the </entry></row><row><entry /><entry /><entry /><entry>GPS coordinates in the pattern. </entry></row><row><entry /><entry /><entry /><entry>This way the UAV can be </entry></row><row><entry /><entry /><entry /><entry>commanded to go to a position by </entry></row><row><entry /><entry /><entry /><entry>executing this pattern</entry></row><row><entry>Emergency</entry><entry>Thread</entry><entry><num></entry><entry>UAV will cut power to the motors.</entry></row><row><entry>stop</entry><entry /><entry /><entry /></row><row><entry>Update pattern</entry><entry>N/A</entry><entry>—</entry><entry>Update the GPS location stored in </entry></row><row><entry><num></entry><entry /><entry /><entry>pattern <num> which may be a </entry></row><row><entry /><entry /><entry /><entry>‘Safe-Zone’ pattern</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0159The payload hash field <b>418</b><i>a </i>includes a hash for the payload field <b>410</b><i>a</i>. In various embodiments, the payload hash <b>418</b><i>a </i>is an MD5 hash of the payload, and is expressed as a hex string of 16 bytes. As explained in detail herein, the payload hash <b>418</b><i>a </i>is used by the UAV controller <b>204</b> to determine whether message <b>400</b>A—received from the flight management system <b>102</b>—was corrupted, or garbled, during transmission. If the message is corrupted (or garbled) during transmission, the flight management system <b>102</b> may be configured to re-send the message a pre-defined number of times.

0160Referring now to <figref idref="DRAWINGS">FIG. <b>4</b>B</figref>, there is shown an example structure for an HTTPS message <b>400</b>B which is generated by the UAV controller <b>204</b> when transmitting messages to the flight management system <b>102</b>.

0161The message structure <b>400</b>B is used in at least two situations: (1) in a routine poll generated by the UAV controller <b>204</b> (i.e. <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>), and (2) in a response poll to the flight managing system <b>102</b> (i.e., <b>1108</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>).

0162As shown by <figref idref="DRAWINGS">FIG. <b>4</b>B</figref>, the message <b>400</b>B includes a UAV serial number field <b>402</b><i>b</i>, a message identification (ID) field <b>404</b><i>b</i>, a counter field <b>406</b><i>b</i>, a payload length field <b>408</b><i>b</i>, a payload field <b>410</b><i>b</i>, a cyclic redundancy check (CRC) field <b>412</b><i>b</i>, and a clear text secret key field <b>414</b><i>b</i>. The contents of the fields <b>404</b><i>a </i>to <b>418</b><i>a </i>may be encoded as hex strings representing byte arrays.

0163The UAV serial number field <b>402</b><i>b </i>is populated by a serial number unique to each UAV. In <figref idref="DRAWINGS">FIG. <b>1</b></figref>, for example, each UAV <b>104</b><i>a </i>to <b>104</b><i>c </i>is allocated a unique serial number. This allows the flight management system <b>102</b> to determine, upon receipt of message <b>400</b>B, where message <b>400</b>B is originating from. To this end, the flight management system <b>102</b> maintains an internal database of each UAV serial numbers for each UAV in the system <b>100</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>. This database may be maintained, for example, on the memory <b>108</b><i>b </i>of the computing device <b>108</b>. The UAV serial number may be, in some cases, expressed as a 12 byte hex string.

0164The message ID field <b>404</b><i>b </i>is identical (and often a reflection) of the message ID field <b>404</b><i>a </i>of message <b>400</b>A. That is, the UAV controller <b>204</b> will often reflect back the message ID <b>404</b><i>a </i>received from the flight management system <b>102</b>. By reflecting back the message ID <b>404</b><i>a</i>, the flight management system <b>102</b> is able to pair the message <b>400</b>B with the message <b>400</b>A upon receipt of the message <b>400</b>B (i.e., similar to the function of the counter field <b>406</b><i>a</i>).

0165If the message <b>400</b>B is sent as an initial poll request (i.e. rather than as a response), the message ID field is simply a hex string of zeros (i.e. “00”). In various cases, the message ID is a one byte hex string.

0166The counter field <b>406</b>B, as discussed above, is also a reflection of the message counter field <b>406</b><i>a </i>received in message <b>400</b>A. In various cases, the message counter field <b>406</b><i>b </i>is occupied by a two byte unsigned integer hex string.

0167The payload length field <b>408</b><i>b </i>indicates the length of the payload <b>410</b><i>b </i>in bytes. In various cases, the payload length is expressed as a four byte hex string.

0168The payload field <b>410</b><i>b </i>varies depending on the type of message sent.

0169More particularly, where the message <b>400</b>B is a routine poll request (i.e. <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>), the payload field <b>410</b><i>b </i>is empty, and may include a string of zeroes.

0170Where the UAV controller <b>204</b> is responding to a command message (i.e. <b>1106</b><i>b </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>), the payload will indicate whether or not the command was successfully received. For example, the command may be unsuccessfully received if the message <b>400</b>A was garbled or corrupted during transmission.

0171More particularly, to determine whether the command was successfully received, the UAV controller <b>204</b> will hash the payload <b>410</b><i>a </i>of command message <b>400</b>A. For example, the UAV controller <b>204</b> may perform an MD5 hash of the payload MD5. The UAV controller <b>204</b> will then determine whether the MD5 hash agrees with the payload hash <b>418</b><i>a </i>in message <b>400</b>A. If the hashes agree, then UAV controller <b>204</b> determines the message was received successfully. If the hashes do not agree, the UAV controller <b>204</b> determines the message was received un-successfully.

0172In at least some embodiments, the payload field <b>410</b><i>b </i>may contain a message which includes a string of “AAAAAAAA” indicating that the message was received successfully. Otherwise, the payload may include a string of “FFFFFFFFF” indicating that message was not received successfully. As explained in further detail herein, where the message is not successfully received, the flight management system <b>102</b> can re-transmit the message a configurable number of times.

0173Significantly, the contents of payload field <b>410</b><i>b </i>only indicates whether the message was received uncorrupted. It does not reflect whether the command was successfully executed. The success of the command execution is addressed by the alert service, as discussed below.

0174Conversely, if the UAV controller <b>204</b> is responding to an information request (i.e., <b>1016</b><i>c </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>) rather than a command message, the payload field <b>410</b><i>b </i>will include the requested information. In various embodiments, the first byte of the payload field <b>410</b><i>b </i>may include an ID value of the data that was requested, and the remaining bytes may be ASCII text encoded in hex (i.e., “abc123” is 616263313233). Accordingly, this may allow for free-form text messages to be sent back to the flight management system <b>102</b>.

0175The CRC field <b>412</b><i>b </i>provides a data integrity check for the payload <b>410</b><i>b. </i>

0176The secret key <b>414</b><i>b </i>is a clear text message authentication code (MAC) which allows the flight management system <b>102</b>, upon receipt of message <b>400</b>B, to verify whether message <b>400</b>B originates from a valid, and registered UAV Controller <b>204</b>. In various cases, the clear text secret key in field <b>414</b><i>b </i>is a 128 bit Globally Unique Identifier (GUID).

0177Significantly, the secret key <b>414</b><i>b </i>is an important feature for ensuring authenticated communication between the flight management system <b>102</b> and UAV controller <b>204</b>.

0178Referring now to <figref idref="DRAWINGS">FIG. <b>14</b></figref>, there is shown a process flow for a method <b>1400</b> which allows the flight management system <b>102</b> to authenticate the message <b>400</b>B, upon receipt thereof, using the secret key <b>414</b><i>b</i>. The method <b>1400</b> may be carried out by the processor <b>108</b><i>a </i>of the computing device <b>108</b>.

0179At <b>1402</b>, the flight management system <b>102</b> receives the message <b>400</b>B (i.e. <b>1106</b> in <figref idref="DRAWINGS">FIG. <b>11</b></figref>). At <b>1404</b>, the system <b>102</b> extracts the secret key from the field <b>414</b><i>b</i>. At <b>1406</b>, the system <b>102</b> performs a hash on the secret key. For example, the system may perform a SHA256 hash of the secret key. At <b>1408</b>, the system will locate, on an internal database (i.e. located, for example, on memory <b>108</b><i>b </i>of the computing device <b>108</b>), a stored hash associated with the UAV serial number located in field <b>402</b><i>b</i>. To this end, the system <b>102</b> maintains a database of hashes corresponding to each UAV serial number for each UAV in the system <b>100</b>. At <b>1410</b>, the system <b>102</b> will compare the hash generated at <b>1406</b>, and the hash retrieved at <b>1408</b> to determine if there is a match. If the hashes agree, the message originate from a valid UAV controller <b>204</b>. If the hashes do not match, or if the secret key field <b>414</b><i>b </i>is empty, the system <b>102</b> will either dump the message <b>400</b>B, return an empty response to the UAV controller <b>204</b>, or otherwise close the communication connection. Accordingly, if a single UAV's controller board's secret key is comprised, it will only affect that single UAV. In that case, the affected UAV controller may be allocated a new secret key.

0180Referring now to <figref idref="DRAWINGS">FIGS. <b>5</b>A to <b>5</b>C</figref>, there is shown example messages which may be transmitted between the UAV controller <b>204</b> and the flight management system <b>102</b> in a polling transaction. In particular, in the polling transaction of <figref idref="DRAWINGS">FIGS. <b>5</b>A to <b>5</b>C</figref>, the flight management system <b>102</b> is transmitting a command message to the UAV controller <b>204</b>.

0181Referring now first to <figref idref="DRAWINGS">FIG. <b>5</b>A</figref>, there is shown an example HTTPS routine polling request <b>500</b>A which is transmitted by the UAV controller <b>204</b> to the flight management system <b>102</b> (i.e., <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The polling request <b>500</b>A may be transmitted according to the HTTPS message structure <b>400</b>B of <figref idref="DRAWINGS">FIG. <b>4</b>B</figref> as it is generated by the UAV controller <b>204</b>.

0182As shown in the message <b>500</b>A, the message ID field <b>404</b><i>b </i>is set to 00 as this is a routine polling request. The message counter field is currently set at 0x109c, indicating that 4,252 message have been received thus from the flight management system <b>102</b>. Further, the payload field <b>410</b><i>b </i>is empty as routine poll requests do not include a payload message. A clear text secret key is provided in the MAC field <b>414</b><i>b. </i>

0183Referring now to <figref idref="DRAWINGS">FIG. <b>5</b>B</figref>, there is shown an example response command message <b>500</b>B, transmitted by the flight management system <b>102</b> to the UAV controller <b>102</b> (i.e., <b>1106</b><i>b </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The response command message <b>500</b>B may be transmitted according to the HTTPS message structure <b>400</b>A of <figref idref="DRAWINGS">FIG. <b>4</b>A</figref>, as the message is generated by the flight management system <b>102</b>.

0184As shown in message <b>500</b>B, the message ID field <b>404</b><i>a </i>is populated by a hex string 0x20, which indicates that a command for loading route data will be provided in the payload field <b>410</b><i>a</i>. The message counter field <b>406</b><i>a </i>has been incremented from hex 0x109C to 0x109D (i.e., the counter is incremented by every message transmitted by the flight management system). Moreover, the message <b>500</b>B also includes the payload encoded as a hex string, as well as an MD5 hash of the payload.

0185Referring now to <figref idref="DRAWINGS">FIG. <b>5</b>C</figref>, there is shown an example HTTPS response message <b>500</b>C which is transmitted by the UAV controller <b>204</b> to the flight management system <b>102</b>, in response to message <b>500</b>B (i.e. <b>1108</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The message <b>500</b>C may be transmitted according to the HTTPS message structure <b>400</b>B of <figref idref="DRAWINGS">FIG. <b>4</b>B</figref>.

0186As shown in message <b>500</b>C, the payload field <b>410</b><i>b </i>is a string of hex “A”, which indicates that message <b>500</b>B was successfully received by the UAV controller <b>204</b>. In particular, it indicates that the payload of message <b>500</b>B was received un-corrupted, as determined by an agreement of the MD5 payload hash.

0187Further, as shown, the message <b>500</b>C reflects back both the message ID field <b>404</b><i>b</i>, and the message counter <b>406</b><i>b</i>. This allows the flight management system <b>102</b> to pair the message <b>500</b>C as a response to the message <b>500</b>B.

0188Referring now to <figref idref="DRAWINGS">FIG. <b>5</b>D</figref>, there is shown an alternative example response message <b>500</b>D. In this case, the message <b>500</b>B was not received successfully by the UAV controller <b>204</b>. The payload field <b>410</b><i>b </i>is now populated by a string of hex ‘F’ indicating a payload hash compare failure. As explained herein, in these cases, the flight management system <b>102</b> may re-transmit the message until the UAV indicates the message was successfully received (i.e., the payload field <b>410</b><i>b </i>is a string of hex “A”), or until the flight management system <b>102</b> has exceeded a pre-defined number of re-transmit attempts.

0189Referring now to <figref idref="DRAWINGS">FIGS. <b>6</b>A to <b>6</b>C</figref>, there is shown further example messages which may be transmitted between the UAV controller <b>204</b> and the flight management system <b>102</b> in a polling transaction. In the polling transaction of <figref idref="DRAWINGS">FIGS. <b>6</b>A to <b>6</b>C</figref>, the flight management system <b>102</b> transmits a pattern command to the UAV controller <b>204</b>.

0190Referring now first to <figref idref="DRAWINGS">FIG. <b>6</b>A</figref>, there is shown an example HTTPS routine polling request <b>600</b>A transmitted to the flight management system <b>102</b> (i.e., <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The polling message <b>600</b>A is analogous to the polling message <b>500</b>A of <figref idref="DRAWINGS">FIG. <b>5</b></figref>.

0191Referring now to <figref idref="DRAWINGS">FIG. <b>6</b>B</figref>, there is shown an example response poll message <b>600</b>B, transmitted by the flight management system <b>102</b>, and including the pattern command. The pattern command has a message ID <b>404</b><i>a </i>of hex ‘0x22’. According to Table 2 above, this corresponds to pattern ID “15”, which is a command for the UAV to fly to a particular GPS position.

0192Referring now to <figref idref="DRAWINGS">FIG. <b>6</b>C</figref>, there is shown an example response message <b>500</b>C by the UAV controller <b>204</b>. The payload field <b>410</b><i>b </i>indicates the pattern command message <b>600</b>B was received successfully.

0193Referring now to <figref idref="DRAWINGS">FIGS. <b>7</b>A to <b>7</b>C</figref>, there is shown still further example messages which may be transmitted between the UAV controller <b>204</b> and the flight management system <b>102</b> in a polling transaction. In particular, in the polling transaction shown in <figref idref="DRAWINGS">FIGS. <b>7</b>A to <b>7</b>C</figref>, the flight management system <b>102</b> is making an information request from the UAV controller <b>204</b> (i.e. <b>1106</b><i>c </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>).

0194Referring now first to <figref idref="DRAWINGS">FIG. <b>7</b>A</figref>, there is shown an example routine polling request <b>600</b>A transmitted to the flight management system <b>102</b> (i.e., <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The polling message <b>700</b>A is analogous to both the polling messages <b>500</b>A of <figref idref="DRAWINGS">FIG. <b>5</b>, and <b>600</b>A</figref> of <figref idref="DRAWINGS">FIG. <b>6</b></figref>.

0195Referring now to <figref idref="DRAWINGS">FIG. <b>7</b>B</figref>, there is shown an example response poll message <b>700</b>B, transmitted by the flight management system <b>102</b> with the information request. As shown in the payload field <b>410</b><i>a</i>, the request is with respect to information in a field “1937” of the autopilot <b>202</b>. This field may correspond, for example, to particular data stored in the memory <b>202</b><i>d </i>of the autopilot <b>202</b>.

0196Referring now to <figref idref="DRAWINGS">FIG. <b>7</b>C</figref>, the UAV controller <b>204</b> returns the requested information in the payload field <b>410</b><i>b. </i>

0197Referring now to <figref idref="DRAWINGS">FIGS. <b>8</b>A to <b>8</b>B</figref>, there is shown yet still further example messages which may be transmitted between the UAV controller <b>204</b> and the flight management system <b>102</b> in a polling transaction. In particular, in the polling transaction shown in <figref idref="DRAWINGS">FIGS. <b>8</b>A to <b>8</b>C</figref>, the flight management system <b>102</b> is returning a no-op message to the UAV controller <b>204</b> (i.e. <b>1106</b><i>a </i>of <figref idref="DRAWINGS">FIG. <b>11</b></figref>).

0198Referring now first to <figref idref="DRAWINGS">FIG. <b>8</b>A</figref>, there is shown an example routine polling request <b>800</b>A transmitted to the flight management system <b>102</b> (i.e., <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The polling message <b>800</b>A is analogous to both the polling messages <b>500</b>A of <figref idref="DRAWINGS">FIG. <b>5</b>, <b>600</b>A</figref> of <figref idref="DRAWINGS">FIG. <b>6</b>, and <b>700</b>A</figref> of <figref idref="DRAWINGS">FIG. <b>7</b></figref>.

0199Referring now to <figref idref="DRAWINGS">FIG. <b>8</b>B</figref>, there is shown an example response poll message <b>800</b>B, transmitted by the flight management system <b>102</b>. In particular, the message ID is set to “0x00”, indicating a no-op message. Further, the payload field <b>410</b><i>b </i>is empty.

0200Referring now to <figref idref="DRAWINGS">FIGS. <b>12</b>A and <b>12</b>B</figref>, there is shown a process flow for an example method for implementing the control/polling service as described herein.

0201Referring now first to <figref idref="DRAWINGS">FIG. <b>12</b>A</figref>, there is shown a process flow for an example method <b>1200</b>A for implementing the control/polling service as viewed from the perspective of the flight management system <b>102</b>. The method <b>1200</b>A may be carried out, for example, using the processor <b>108</b><i>a </i>and communication interface <b>108</b><i>c </i>of computing device <b>108</b>.

0202At <b>1202</b><i>a</i>, the flight management system <b>102</b>, operating on the computing device <b>108</b>, receives an HTTPS POST request from the UAV controller <b>204</b> (i.e., <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>). The request may be received by the computing device <b>108</b> via the communication interface <b>108</b><i>c. </i>

0203At <b>1204</b><i>a</i>, the flight management system <b>102</b> decodes the routine poll request (i.e., to determine that the request is in-fact a routine polling request).

0204At <b>1206</b><i>a</i>, the flight management system <b>102</b> determines whether a message is in queue for the UAV controller <b>204</b>. For example, the message in-queue may be a command message, or a request for information.

0205If no message is in que, the flight management system <b>102</b> responds at <b>1208</b><i>a </i>by encoding a no-op acknowledgment message. The no-op message is transmitted to the UAV controller at <b>1216</b><i>a </i>as an HTTPS response.

0206If a message is in queue at <b>1206</b><i>a</i>, the flight management system <b>102</b> determines at <b>1210</b><i>a </i>if the message is a command message.

0207If the message is a command message, the flight management system <b>102</b> encodes the command message, at <b>1212</b><i>a</i>, according to the notations and message structures described above. The flight management system <b>102</b> will then transmit the command message back to the UAV controller <b>204</b> as an HTTPS response at <b>1216</b><i>a. </i>

0208If the message is not a command message, it is determined to be a request for information. Accordingly, the flight management system <b>102</b> will encode the information request at <b>1214</b><i>a </i>according to the methods described above. The management system <b>102</b> will then transmit the information request back to the UAV controller <b>204</b> as an HTTPS response at <b>1216</b><i>a. </i>

0209Referring now to <figref idref="DRAWINGS">FIG. <b>12</b>B</figref>, there is shown a process flow for an example method <b>1200</b>B for implementing the polling/control service as viewed from the perspective of the UAV controller <b>204</b>. The method <b>1200</b>B can be carried out, for example, using the processor <b>204</b><i>a</i>, and communication module <b>204</b><i>b</i>, of the UAV controller <b>204</b>.

0210At <b>1202</b>B, the UAV controller <b>204</b> transmits a routine polling HTTPS POST request to the flight management system <b>102</b> (i.e. <b>1102</b> of <figref idref="DRAWINGS">FIG. <b>11</b></figref>).

0211At <b>1204</b><i>b</i>, the UAV controller <b>204</b> waits for an HTTPS response from the flight management system <b>102</b>.

0212At <b>1206</b><i>b</i>, the UAV controller <b>204</b> receives and de-codes the response to determine the contents of the message contained therein.

0213At <b>1208</b><i>b</i>, the UAV controller <b>204</b> determines whether the response is a simple no-op acknowledgement.

0214If the response is a no-op acknowledgment, the UAV controller waits for the next polling period at <b>1218</b><i>b </i>(as determined by the pre-set polling frequency). The method <b>1200</b>B then returns to <b>1202</b><i>b</i>, whereby the UAV controller <b>204</b> transmit another routine polling request.

0215If the response message is not a no-op acknowledgment, the UAV controller <b>204</b> determines whether the response is an information request at <b>1210</b><i>b. </i>

0216If it is determined that the message is an information request, then at <b>1214</b><i>b</i>, the UAV controller <b>204</b> retrieves the requested information. For example, the requested information may be located on the UAV controller <b>204</b> or the autopilot <b>202</b>. The requested information is then encoded and transmitted to the flight management system <b>102</b> at <b>1216</b><i>b. </i>

0217If the response message at <b>1108</b><i>b </i>is not an information request, then at <b>1212</b><i>b</i>, the UAV controller <b>204</b> determines that the message is a command which requires execution. The UAV controller <b>204</b> will then encode and transmit a message expressing whether the command was received successfully, or un-successfully (i.e. based on payload hash agreement).

0218In various cases, where the flight management system <b>102</b> receives a failed/un-successful message, the flight management system <b>102</b> will keep the message in queue (i.e., at <b>1206</b><i>a </i>in <figref idref="DRAWINGS">FIG. <b>12</b>A</figref>) until a successful message is received back, or until the maximum re-send attempts have been exhausted. If the flight management system <b>102</b> receives back a routine polling request, rather than a success/failure message, the flight management system <b>102</b> will assume the UAV controller <b>204</b> failed to receive the message. Accordingly, in this case, the message will be held in queue by the flight management system <b>102</b> until the maximum amount of re-send attempts have been exhausted.

0219After either <b>1212</b><i>b </i>or <b>1216</b><i>b</i>, as the case may be, the UAV controller waits for the next polling period at <b>1218</b><i>b</i>. The method <b>1200</b>B then returns to <b>1202</b><i>b </i>whereby the UAV controller <b>204</b> continues transmitting routine polling request.

0220(b) Alert Service:

0221The alert service allows the UAV controller <b>204</b> to send unexpected alert messages to the flight management system <b>102</b>.

0222In various embodiments, the alert message may indicate that an autopilot command, transmitted by the flight management system <b>102</b> via the polling/control service, was not properly executed. In other embodiments, the alert message can indicate a ‘status changed’ message from the autopilot <b>202</b> which indicates, for example, that the autopilot GPS module <b>202</b><i>b </i>has lost satellite signal, a servo motor of the UAV has failed, or a fatal error has occurred to the UAV's inertial measurement unit (IMU).

0223To this end, the alert service may be implemented by the alert module <b>204</b><i>f </i>of the UAV controller <b>204</b>, which generates instructions to transmit alerts, as well as the complementary alert module <b>306</b> in the flight management system <b>300</b> of <figref idref="DRAWINGS">FIG. <b>3</b>A</figref>, which has instructions for processing the received alerts.

0224Similar to the polling service, alert messages may be sent as an HTTPS post requests encrypted using transport layer security (TLS). The UAV controller <b>204</b> is configured to direct the alert message over the internet (i.e. network <b>106</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref>) to a location having a known Uniform Resource Locator (URL) identifier which is associated, and accessible, by the alert service <b>306</b> of the flight management system <b>300</b>. The URL for the alert service may be different than the polling/control service.

0225Furthermore, the alert service <b>306</b> in the flight management system <b>300</b> is constantly receptive and “listening” to any alert message that may be transmitted by the UAV controller <b>204</b>.

0226Referring now to <figref idref="DRAWINGS">FIG. <b>9</b></figref>, there is shown an example alert message <b>900</b> that may be transmitted by the UAV controller <b>204</b> to the flight management system <b>102</b>, <b>300</b>.

0227As shown, the structure of alert message <b>900</b> is analogous to the structure of message <b>400</b>B of <figref idref="DRAWINGS">FIG. <b>4</b>B</figref> for messages generated by the UAV controller <b>204</b>.

0228In particular, as shown in message <b>900</b>, the message ID field <b>404</b><i>b </i>is populated by a hex string “FF”, indicating an unexpected/alert message. The payload field <b>412</b><i>b </i>indicates that this is a general alert message.

0229(c) Heartbeat Service:

0230The heartbeat service allows the UAV controller <b>204</b> to periodically transmit ‘heartbeat’ messages to the flight management system <b>102</b>, <b>300</b> when the UAV <b>200</b> is powered on, either in dock, or in flight.

0231The heartbeat messages provide regular data information in respect of the status and location of the UAV <b>200</b>. To this end, the instructions for generating the heartbeat messages may be generated by the heartbeat module <b>204</b><i>e </i>of the UAV controller <b>204</b>. The instructions for processing the received heartbeat messages, at the flight management system <b>102</b>, may be effected by the heartbeat service <b>304</b> of <figref idref="DRAWINGS">FIG. <b>3</b>A</figref>.

0232In various embodiments, the heartbeat messages may be transmitted from the UAV controller <b>204</b> to the flight management system <b>102</b>, <b>300</b> (i.e. operating on computing device <b>108</b>) using a User Datagram Protocol (UDP). To this end, and as explained herein, the heartbeat message may be compressed and encrypted before transmission over UDP.

0233Referring now to <figref idref="DRAWINGS">FIG. <b>15</b></figref> is shown a process flow for a method <b>1500</b> for transmitting a heartbeat message, according to some embodiments.

0234At <b>1502</b>, the UAV controller <b>204</b> will transmit a request to the flight management system <b>102</b> requesting a session ID and an encryption key. This request may be sent when the UAV is first powered-on.

0235At <b>1504</b>, the key-request service <b>312</b>, of the flight management system <b>102</b>, receives the request and transmits back the session ID, the encryption key, as well as an address for the UAV to transmit heartbeat messages (i.e., the address may be a URL, IP and port address). In at least some embodiments, the encryption key is a unique 32-byte AES-256-encryption key. Further, in at least some cases, the key and the session ID may be configured to be valid for only one flight session, and may subsequently expire when the UAV is powered down. As such, a new session ID and key must be requested from the flight management system <b>102</b> with each power cycle. In various cases, the flight management system <b>102</b> stores the session ID and encryption key in order to associate, at a later point, these values with the particular UAV making the request.

0236At <b>1506</b>, the UAV controller <b>204</b> receives the session ID and encryption key and proceeds to compress the heartbeat message. The compression may be performed, for example, using the compression module <b>204</b><i>h</i>. Compressing the heartbeat message may be important where the heartbeat message is transmitted over a satellite connection (i.e., which is conventionally low bandwidth and high latency). In at least some embodiments, the heartbeat message is compressed by a ratio of 50% or greater.

0237At <b>1508</b>, a random initialization vector (IV) is generated by the UAV controller <b>204</b> and the compressed heartbeat message is AES-256 encrypted using the initialization vector. In at least some cases, the initialization vector is 16-bytes in length.

0238At <b>1510</b>, the initialization vector is prepended to the encrypted message to allow the flight management system <b>102</b> to decrypt the heartbeat message.

0239At <b>1512</b>, the session ID is prepended to the heartbeat message to allow the flight management system <b>102</b> to determine which UAV is transmitting the heartbeat message. The heartbeat message is then transmitted to the flight management system <b>102</b> over UDP using to the following format: [4 bytes, Session ID] [16 bytes, IV] [variable length, encrypted, compressed heartbeat data].

0240At <b>1514</b>, the flight management system <b>102</b> receives the heartbeat message and extracts the session ID in order to identify which UAV is transmitting the message. Once the UAV is identified, the flight management system <b>102</b> identifies the corresponding encryption key and proceeds to decrypt the heartbeat message. In this manner, the session ID provides the identity for the UAV (or heartbeat message), and decryption of the heartbeat message allows for message authentication.

0241Once the message is decrypted, the flight management system <b>102</b> may proceed to decompress the message to retrieve its contents.

0242In at least some embodiments, heartbeat messages may be transmitted every five seconds from the UAV controller <b>204</b> to the flight management system <b>102</b>. In various cases, however, the heartbeat period may be adjusted by a command transmitted by the flight management system <b>102</b> to the UAV controller <b>204</b> via a polling transaction.

0243Referring now to <figref idref="DRAWINGS">FIG. <b>10</b></figref>, there is shown an example structure for a heartbeat message <b>1000</b> according to an example embodiment.

0244As shown, in at least some embodiments, the heartbeat message <b>1000</b> may be encoded using JavaScript Object Notation (JSON).

0245Further, as shown in <figref idref="DRAWINGS">FIG. <b>10</b></figref>, the heartbeat message <b>1000</b> may include a UAV serial number identifier <b>1002</b>, as well as a clear text Message Authentication Code (MAC) <b>1004</b> (i.e. secret key). As previously discussed in relation to the polling/control service, the UAV serial number <b>1002</b> and MAC <b>1004</b> may allow the flight management system <b>102</b>, <b>300</b> to authenticate the UAV controller <b>204</b> as a valid controller. In other embodiments, rather than including a serial number identifier <b>1002</b> and a MAC key <b>1004</b>, the UAV identity is provided by the session ID and the authentication is provided by the encryption key generated by the key-request service <b>312</b> (i.e., as described in method <b>1500</b> of <figref idref="DRAWINGS">FIG. <b>15</b></figref>).

0246As further shown by <figref idref="DRAWINGS">FIG. <b>10</b></figref>, the heartbeat message <b>1000</b> may also include a communication link field <b>1005</b>, a counter field <b>1006</b>, a flight identification (ID) number field <b>1008</b>, a status field <b>1010</b>, a bay status field <b>1011</b>, a received signal strength indicator (RSSI) field <b>1012</b>, and a docked field <b>1016</b>.

0247The communication link field <b>1005</b> is an integer which indicates the nature of available communication channels. For example, “00” may indicate no wireless channels available, “01” may indicate only satellite channels are available, “02” may indicate only cellular channels available”, and “03” may indicate cellular and satellite channels are available. In at least some embodiments, the UAV will automatically connect to an ethernet connection where such a connection is made available.

0248The counter field <b>1006</b> is a number which may be increased by the UAV controller <b>204</b> each time a heartbeat message is sent to the flight management system <b>102</b>. In various cases, the counter field <b>1006</b> may include a 16-bit overflow integer.

0249The flight ID field <b>1008</b> is a number which allows the flight management system <b>102</b> to identify heartbeats during the UAV's flight. The flight ID field <b>1008</b> is initially set by the flight management system <b>102</b> at the beginning of each flight session to a non-zero value. In some embodiments, the flight ID <b>1008</b> may be set by the flight management system <b>102</b> to a non-zero value using a polling transaction, as described above. The field ID field <b>1008</b> is then set to zero while the UAV is docked, undergoing maintenance, or at the end of the UAV's flight.

0250The status field <b>1010</b> allows the UAV controller <b>204</b> to transmit data with various pre-defined status indicators. By way of example, Table 3 below summarizes various statuses that may be expressed in the status field <b>1010</b>:

0251<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Examples Predefined Status IDs</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="56pt" align="center" /><colspec colname="3" colwidth="126pt" align="left" /><tbody valign="top"><row><entry>Status ID</entry><entry>Hex String</entry><entry>Status meaning</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry> 0</entry><entry>00</entry><entry>Initializing (not ready for arming)</entry></row><row><entry>16</entry><entry>10</entry><entry>Initialized (Ready for arming)</entry></row><row><entry>32</entry><entry>20</entry><entry>Armed (Ready for Takeoff)</entry></row><row><entry>104 </entry><entry>68</entry><entry>Taking off</entry></row><row><entry>72</entry><entry>48</entry><entry>On route</entry></row><row><entry>74</entry><entry>4A</entry><entry>Landing</entry></row><row><entry>20</entry><entry>14</entry><entry>Landed (can take off - to return home)</entry></row><row><entry> 4</entry><entry> 4</entry><entry>Landed (can't take off - mission complete)</entry></row><row><entry> 1</entry><entry> 1</entry><entry>Fatal Error</entry></row><row><entry>81</entry><entry>51</entry><entry>Manual control - on ground</entry></row><row><entry>82</entry><entry>52</entry><entry>Manual control - in flight</entry></row><row><entry>255 </entry><entry>FF</entry><entry>None of the above</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0252The bay status field <b>1011</b> is an integer which indicates the current status of the UAV doors. For example, in some cases, the UAV may have delivery bay doors (e.g., on the underside of the UAV) which are designed to open automatically when the UAV lands to drop a delivered package. The delivery bay doors will then close automatically when the UAV takes off to fly home. The bay status field <b>1011</b> indicates the status or desired action for the bay doors (e.g., open, closed, jammed, etc.). By way of example, Table 4 below summarizes various bay status field codes that may be used in the bay status field <b>1011</b>:

0253<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 4</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Examples Predefined Bay Status Field IDs</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="84pt" align="left" /><tbody valign="top"><row><entry>Field Value</entry><entry>State</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>0 or No </entry><entry>Do not Open Door</entry><entry>The UAV has not yet </entry></row><row><entry>Connection </entry><entry /><entry>reached a point in the </entry></row><row><entry>to Autopilot</entry><entry /><entry>mission when the door </entry></row><row><entry>Program</entry><entry /><entry>should be opened.</entry></row><row><entry>1</entry><entry>Ready to Open Door</entry><entry>The UAV has landed and </entry></row><row><entry /><entry /><entry>is at a suitable point in the </entry></row><row><entry /><entry /><entry>mission to release the </entry></row><row><entry /><entry /><entry>payload.</entry></row><row><entry>2</entry><entry>Open Door</entry><entry>Command to the controller </entry></row><row><entry /><entry /><entry>to open the door.</entry></row><row><entry>3</entry><entry>Door Opened</entry><entry>Response from the </entry></row><row><entry /><entry /><entry>controller indicating the </entry></row><row><entry /><entry /><entry>door is fully open based on </entry></row><row><entry /><entry /><entry>feedback from the linear </entry></row><row><entry /><entry /><entry>actuators.</entry></row><row><entry>4</entry><entry>Close Door</entry><entry>Command to the controller </entry></row><row><entry /><entry /><entry>to open the door.</entry></row><row><entry>5</entry><entry>Door Closed</entry><entry>Response from the controller</entry></row><row><entry /><entry /><entry>indicating the door is fully </entry></row><row><entry /><entry /><entry>closed based on feedback </entry></row><row><entry /><entry /><entry>from the linear actuators.</entry></row><row><entry>11</entry><entry>Error - Door Will not Open</entry><entry>Error Code - The door will </entry></row><row><entry /><entry /><entry>not open.</entry></row><row><entry>12</entry><entry>Error - Door Will not Close</entry><entry>Error Code - The door will </entry></row><row><entry /><entry /><entry>not close.</entry></row><row><entry>13</entry><entry>Error - Door Opened</entry><entry>Error Code - The door </entry></row><row><entry /><entry /><entry>opened when it was not </entry></row><row><entry /><entry /><entry>supposed to.</entry></row><row><entry>14</entry><entry>Override - Stay Closed</entry><entry>Ignore all commands to open </entry></row><row><entry /><entry /><entry>the door</entry></row><row><entry>15</entry><entry>Override - Stay Open</entry><entry>Say you the door is stuck </entry></row><row><entry /><entry /><entry>open but you want to fly </entry></row><row><entry /><entry /><entry>home anyway</entry></row><row><entry>99</entry><entry>N/A</entry><entry>UAV does not have bay </entry></row><row><entry /><entry /><entry>doors</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0254The RSSI field <b>1012</b> may be an integer value between 0 and 30 which indicates the received signal strength for signals received at the UAV controller <b>204</b> from the flight management system <b>102</b>. The RSSI <b>1012</b> may be an integer 99 when an RSSI reading is unavailable.

0255A visual object tracker field <b>1014</b> may indicate if a visual object tracking system is sending data. In various cases, the visual object tracking system tracks “visual objects” located near or around the UAV. To this end, the tracking system may communicate with a camera (i.e., equipped onto the UAV) that identifies and tracks a “visual object”. For example, the tracking system may track a visual marker at the landing spot for the UAV and the UAV may be precisely controlled to land at the visual marker. This feature is especially useful where the UAV is landing in a small space (e.g., 5 m×5 m), and where GPS coordinates are insufficiently accurate to position the UAV for landing. The visual tracking field may be an integer that is either zero (e.g., visual tracking is not active), or ‘4’ (i.e., visual tracking is active). In <figref idref="DRAWINGS">FIG. <b>10</b></figref>, the visual object tracker field <b>1014</b> is labelled as “Sightline”, which identifies the name of a proprietary commercial product that is specialized for visual object tracking.

0256The docked field <b>1016</b> is an integer field which indicates whether the UAV <b>200</b> is docked. In at least some embodiments, an integer value of ‘0’ indicates that the UAV is not docked, and an integer value of ‘1’ indicates the UAV is docked.

0257The heartbeat message <b>1000</b> can also include a plurality of locational and orientation data fields.

0258For example, in various cases, the heartbeat message <b>1000</b> can include a GPS location field <b>1018</b>, a relative altitude field <b>1020</b>, and an attitude field <b>1022</b>.

0259The GPS location field <b>1018</b> includes the latitude position <b>1018</b><i>a </i>and longitude position <b>1018</b><i>b </i>of the UAV <b>200</b>. In various cases, GPS information is provided by GPS module <b>202</b><i>c </i>of the autopilot <b>202</b>. In at least some cases, the latitude and longitude positions may be expressed to an accuracy of six decimal points.

0260The relative altitude field <b>1020</b> indicates the altitude of the UAV above sea level <b>1020</b>A, and above ground level <b>1020</b>B. The relative altitude may be expressed up to an accuracy of one decimal point. In at least some cases, the values in the relative altitude field <b>1010</b> are expressed according to Equation (1): <br />Relative Altitude above Sea Level, or Ground Level=GPS Altitude (Feet)*−8  (1)

0261The attitude field <b>1022</b> includes information in respect of the bearing <b>1022</b>A, yaw <b>1022</b>B, pitch <b>1022</b>C, roll <b>1022</b>D, and ground speed <b>1022</b>E of the UAV <b>200</b>. These measurements may be determined, for example, based on one or more sensor <b>206</b> on-board the UAV <b>200</b>.

0262The bearing <b>1022</b>A may be expressed in units of degrees between “0” and “360”, where “0” indicates a northward bearing.

0263In at least some cases, each of yaw <b>1022</b>B, pitch <b>1022</b>C, and roll <b>1022</b>D are expressed according to Equation (2):

0264<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><mrow><mi>Yaw</mi><mo>/</mo><mi>Pitch</mi></mrow><mo>/</mo><mi>Roll</mi></mrow><mo>=</mo><mrow><mi>Degrees</mi><mo>⋆</mo><mrow><mn>1</mn><mo>⁢</mo><mrow><mn>7</mn><mo>.</mo><mn>8</mn></mrow><mo>⁢</mo><mn>7</mn><mo>⁢</mo><mn>2</mn><mo>⁢</mo><mn>1</mn><mo>⁢</mo><mn>8</mn></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>2</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US11831783B2_D0001.tif" /><img file="US11831783B2_D0002.tif" /><img file="US11831783B2_D0003.tif" />

0265Wherein the degrees may range from between “−180”* and “180”*.

0266The ground speed <b>1022</b>E can be expressed in units of feet per second, and expressed according to Equation (3):

0267<maths id="MATH-US-00002" num="00002"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><mi>Ground</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mi>Speed</mi></mrow><mo>=</mo><mrow><mrow><mi>Feet</mi><mo>/</mo><mi>second</mi></mrow><mo>*</mo><mn>8</mn></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>3</mn><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US11831783B2_D0004.tif" /><img file="US11831783B2_D0005.tif" /><img file="US11831783B2_D0006.tif" />

0268The measurements in the attitude field <b>1022</b> can be expressed to an accuracy of one decimal point.

0269In at least some embodiments, the heartbeat message <b>1000</b> can also include information in respect of the status of various batteries and sensors located on-board UAV <b>200</b>. In particular, the heartbeat message <b>1000</b> can include battery reading fields <b>1024</b> and <b>1028</b>.

0270The battery reading fields <b>1024</b> and <b>1028</b> can include the statuses of various batteries mounted on-board the UAV <b>200</b>.

0271For example, the battery status field <b>1024</b> can include information in respect of an avionics battery bank (e.g., which includes one or more batteries, such as battery <b>208</b> of <figref idref="DRAWINGS">FIG. <b>2</b></figref>), while battery status field <b>1028</b> can include information in respect of a servo battery bank.

0272In various cases, each of the one or more battery reading fields can include voltage readings <b>1024</b>A, <b>1024</b>B, <b>1034</b>C, and <b>1028</b>A, of each battery in the battery bank The voltages may be expressed in units of Volts, and in various cases, to a precision of one decimal point.

0273In other cases, the heartbeat message <b>1000</b> may also include a sensor status field which includes information in respect of the various sensors located on the UAV <b>200</b>.

0274(d) Short Message Service (SMS) Service:

0275The message service, or the SMS web-service, allows the flight management system <b>102</b> to communicate with the UAV controller <b>204</b> using short message service (SMS).

0276In at least some embodiments, the SMS service can be used as an alternative to polling transactions (i.e., in the polling/control service) to allow the flight management system <b>102</b> to transmit commands, and information request messages, to the UAV controller <b>204</b>.

0277In particular, in an SMS transaction the flight management system <b>102</b> can transmit instructions to the UAV controller <b>204</b> without waiting to be first polled.

0278The SMS service can be used where the network <b>106</b> of <figref idref="DRAWINGS">FIG. <b>1</b></figref> includes, for example, a cellular or a satellite network. The identity of any particular UAV, i.e. UAVs <b>104</b><i>a </i>to <b>104</b><i>c</i>, may be based on a cell modem SIM, located for example, in the communication module <b>204</b><i>b </i>as shown in <figref idref="DRAWINGS">FIG. <b>2</b>C</figref>. To this end, an SMS gateway may be used to facilitate exchange of SMS messages between the UAV controller <b>204</b> and the flight management system <b>102</b>. The SMS gateway includes the SIM for a particular UAV modem and forwards the message to the corresponding UAV modem.

0279In various embodiments, SMS message between UAVs and the flight management system may use the same message formats <b>400</b>A of <figref idref="DRAWINGS">FIG. <b>4</b>A and <b>400</b>B</figref> of <figref idref="DRAWINGS">FIG. <b>4</b>B</figref>, as those used in the polling transactions. A secret key method is still used to authenticate messages from the UAV controller <b>204</b>.

0280Referring now to <figref idref="DRAWINGS">FIG. <b>13</b></figref>, there is shown a process flow for an example method <b>1300</b> for SMS communication between the flight management system <b>102</b> and the UAV controller <b>204</b>.

0281At <b>1302</b>, a user of the computing device <b>108</b> may select a command or message to be sent to the UAV controller <b>204</b>. At <b>1304</b>, the flight management system <b>102</b> may encode the command or message according to, for example, message structure <b>400</b>A of <figref idref="DRAWINGS">FIG. <b>4</b>A</figref>. At <b>1306</b>, the flight management system <b>102</b> may prepend a date and time stamp to the message.

0282At <b>1308</b>, the flight management system <b>102</b> may retrieve the target UAV's hashed secret key. For example, the flight management system <b>102</b> may retrieve the hashed secret key from an internal database located on the memory <b>108</b><i>b </i>of computer <b>108</b>.

0283At <b>1310</b>, the flight management system <b>102</b> may then create a keyed-hash message authentication code (HMAC) code of the date, time and command (i.e., the message generated at <b>1306</b>) using the UAV's hashed secret key as the HMAC secret key. The HMAC secret key may then add the HMAC secret key to the encoded message at <b>1306</b>, as follows:

0284<maths id="MATH-US-00003" num="00003"><math overflow="scroll"><mrow><mrow><mi>Date</mi><mo>/</mo><mi>Time</mi></mrow><mo>⁢</mo><mstyle><mspace width="0.6em" height="0.6ex" /></mstyle><mo>⁢</mo><mrow><mo></mo><mrow><mi>Message</mi><mo>⁢</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo>⁢</mo><mn>400</mn><mo>⁢</mo><mi>A</mi></mrow><mo></mo></mrow><mo>⁢</mo><mi>HMAC</mi></mrow></math></maths><img file="US11831783B2_D0007.tif" /><img file="US11831783B2_D0008.tif" /><img file="US11831783B2_D0009.tif" />

0285At <b>1312</b>, the flight management system <b>102</b> may transmit the encoded message to the target UAV. At <b>1314</b>, the UAV controller <b>204</b> receives the message. At <b>1316</b> the UAV controller may parse the message to ensure that the local time agrees with the time stamp. At <b>1318</b>, if the time stamps agree, the UAV controller <b>204</b> may then prepend its own local time to the message. At <b>1320</b>, the UAV controller <b>204</b> may compute the hash of a locally stored secret key. At <b>1332</b>, the UAV controller <b>204</b> uses the hashed key from <b>1320</b> to create an HMAC using the local date and time stamp, and received command message (i.e. similar to <b>1310</b>). If the HMAC hash generated by the UAV controller <b>204</b> at <b>1322</b> matches the HMAC located in the encoded message at <b>1314</b>, the SMS message is considered valid. Otherwise the message is dropped.

0286The present invention has been described here by way of example only, while numerous specific details are set forth herein in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art these embodiments may, in some cases, be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the description of the embodiments. Various modifications and variations may be made to these exemplary embodiments without departing from the spirit and scope of the invention, which is limited only by the appended claims.