Patent Description:
With the advent of commercially-available unmanned aerial vehicles (UAVs), it is becoming increasingly difficult to prevent collisions between them. While some UAVs, particularly larger or bespoke UAVs, operate under the control of an integrated programmable autopilot, most commercial-off-the-shelf (COTS) UAVs are not readily programmable and take input from a handheld flight controller operated by a user. Even those with an autopilot are not equipped for collision avoidance.

The paper "<NPL> et al. relates to the conceptual definition, simulation and performance analysis of a novel, 3D graph theory based routing algorithm. The proposed router is designed to provide path planning with deconfliction, i.e. collision avoidance with other moving objects, for Unmanned Aerial Vehicles (UAV) applications in general and autonomous UAV missions in particular.

<CIT>" wherein ports each receive signals corresponding to an interface input associated with user physical interaction provided via an interface device in one of disparate input modes. A multi-modal input system maps an interface input associated with one of the ports provided in a given one of the disparate input modes into a computer input command, maps an interface input associated with another of the ports provided in another one of the disparate input modes into another computer input command, and aggregates the computer input commands into a multi-modal event command. A processor executes a single predetermined function associated with the computer system in response to the multi-modal event command. Thus, the processor is configured to execute the single predetermined function associated with the computer system in response to user physical interaction provided in at least two of the plurality of disparate input modes.

It would be advantageous to provide COTS UAVs with an ability to avoid collisions, particularly where a plurality are being controlled by a single user.

According to a first aspect of the present disclosure, there is provided a controller for an unmanned vehicle according to claim <NUM>. According to a second aspect of the present disclosure, there is provided an unmanned vehicle according to claim <NUM>. According to a third aspect of the present disclosure, there is provided a method of controlling an unmanned vehicle according to claim <NUM>.

It will be appreciated that features described in relation to one aspect of the present disclosure can be incorporated into other aspects of the present disclosure. For example, an apparatus of the disclosure can incorporate any of the features described in this disclosure with reference to a method, and vice versa. Moreover, additional embodiments and aspects will be apparent from the following description, drawings, and claims. As can be appreciated from the foregoing and following description, each and every feature described herein, and each and every combination of two or more of such features, and each and every combination of one or more values defining a range, are included within the present disclosure provided that the features included in such a combination are not mutually inconsistent. In addition, any feature or combination of features or any value(s) defining a range may be specifically excluded from any embodiment of the present disclosure.

Embodiments of the disclosure will now be described by way of example only and with reference to the accompanying drawings.

For convenience and economy, the same reference numerals are used in different figures to label identical or similar elements.

Generally, embodiments herein relate to a vehicle controller that can be coupled to an unmanned vehicle, after manufacture, in order to provide the unmanned vehicle with an ability to avoid collisions. Preferably, the vehicle controller receives a route from a server for the unmanned vehicle to follow. The server is provided with software that receives a desired route and uses the position of obstacles, such as other vehicles, to generate a new route free of collisions. The following description will be drawn to unmanned aerial vehicles (otherwise known as drones or UAVs), such as commercial UAVs for delivering packages from distributors.

Unmanned aerial vehicles 20a, 20b (generally <NUM>) having respective individual vehicle controllers 30a, 30b (generally <NUM>) coupled thereto are illustrated in <FIG>. While two UAVs <NUM> are illustrated, this is not intended to be limiting. There may be only one UAV <NUM> in the system, or a plurality of UAVs <NUM> in the system. The unmanned aerial vehicle <NUM> is in the form of a multicopter (e.g. a quadcopter), which is a typical form-factor for COTS UAVs. While the embodiments that follow will refer to flight paths, flight planning and aircraft, it would be understood this is in relation to specific embodiments and not intended to limit the concept to air travel. For example, in other embodiments, the unmanned vehicle may be an unmanned or optionally-manned ground vehicle, spacecraft or watercraft. Throughout, "unmanned" will be assumed to have a broad definition encompassing optionally-manned vehicles not being directly operated by a human (i.e. vehicles having a degree of autonomy).

The unmanned aerial vehicle(s) <NUM> may be controlled in normal, or conventional, operation by a user of a remote controller. The user may be based in a ground station. According to an embodiment, each UAV <NUM> is provided with a vehicle controller <NUM>, which provides the respective UAV <NUM> with the ability to autonomously follow a programmed route. That route is received from a deconfliction engine <NUM> (i.e. server). The route is planned by said deconfliction engine <NUM> such that if a vehicle were to follow it, said vehicle would not collide with any other obstacle. Such obstacles include other aircraft, where their routes have been submitted to the deconfliction engine. Therefore, the route received by the vehicle controller <NUM> is known as the deconflicted route.

The vehicle controller <NUM> may receive the deconflicted route from the deconfliction engine <NUM> by a wireless communications link. The wireless link may be a Bluetooth, WiFi, Tactical Datalink (e.g. Link-<NUM>) or a broadband telecommunications link (such as LTE and <NUM>), for example. Alternatively, the vehicle controller <NUM> may receive the deconflicted route by a wired connection with the deconfliction engine <NUM>, such as an Ethernet or USB link. Finally, the deconflicted route may be transferred from the deconfliction engine <NUM> to the vehicle controller <NUM> using a portable memory device, such as a USB "stick".

The vehicle controller <NUM> is an independent unit attached to the outside of the UAV <NUM>. The vehicle controller <NUM> may be coupled to the UAV <NUM> by any suitable means, such as straps, an adhesive substance, a magnet, hook-and-loop material, a clasp, a bracket, or an elastic band. The vehicle controller <NUM> may alternatively be heat-bonded or chemically bonded to the UAV <NUM>, although it would be preferred for the vehicle controller <NUM> to be detachable such that the UAV <NUM> can return to its original control regime, or so the vehicle controller <NUM> can be swapped for another module or upgraded.

The vehicle controller <NUM> is electrically coupled to the UAV <NUM> by means of an interface. This will be described in more detail with reference to <FIG>. In one embodiment, the vehicle controller <NUM> receives position information from the UAV <NUM>. In another embodiment, the vehicle controller <NUM> is provided with a navigation system for providing position information. The vehicle controller <NUM> compares its current position with the deconflicted route, and in response generates instructions which would move the UAV <NUM> to which it is attached to the next waypoint along the route. For example, at the present time the UAV <NUM> may be at a first waypoint in the deconflicted route, and the vehicle controller <NUM> therefore generates a movement plan that would move the UAV <NUM> from the first waypoint to a second waypoint in the deconflicted route.

The UAV <NUM> may need to arrive at a waypoint at a particular time or within a timeframe in order to avoid a collision. From the desired arrival time and current position relative to the waypoint, the vehicle controller <NUM> can calculate the desired speed of the UAV <NUM> which would allow it to arrive at the waypoint at the specified time. The vehicle controller <NUM> may also, or alternatively, determine a bearing (i.e. heading, direction of movement), orientation, and altitude for the UAV <NUM> that would allow it to arrive at the waypoint or otherwise satisfy the conditions of the deconflicted route. In other embodiments, where the UAV <NUM> is instead a train or car, for example, the vehicle controller <NUM> may determine a track, path or road for the vehicle to follow which would be pre-programmed into the UAV <NUM>.

The determined vehicle control instructions are then transmitted to the UAV <NUM> through the interface. An on-board controller of the UAV <NUM> then uses the vehicle control instruction to determine the necessary flight control inputs and controls flight control surfaces or propulsion systems accordingly to achieve the requested vehicle control instructions. The UAV <NUM> therefore then moves to follow the deconflicted route.

In the illustrated embodiment, a deconfliction engine <NUM> is in wireless communication with the plurality of vehicle controllers <NUM>. The deconfliction engine <NUM> may belong to an entity such as a logistics company, national air traffic service or military organisation, having a plurality of UAVs <NUM> associated with it. In other words, the deconfliction engine <NUM> may be a server that receives route s for UAVs from a wide range of users and entities; an apparatus/server for a single organisation operating a plurality of UAVs <NUM>; or an apparatus for a single user of a UAV <NUM> that is networked with other deconfliction engines or route planners. In the latter case, the deconfliction engine <NUM> may be integrated with the vehicle controller <NUM>. The UAVs <NUM> may be for delivering packages, for example. Alternatively, the UAVs <NUM> may be communication nodes in a military tactical network.

The deconfliction engine <NUM> is in communication with at least one terminal device 10a, 10b (generally, <NUM>). These may be desktop computers, laptops or tablets on the same network (e.g. a LAN) as the deconfliction engine <NUM> for allowing a user to interface with the deconfliction engine <NUM>. Alternatively, the terminal devices <NUM> may include mobile phones comprising a software application for planning a route. Terminal devices <NUM> may communicate with the deconfliction engine <NUM> through the Internet. In other words, the deconfliction engine <NUM> may generate web page/portal which is presented to the user on their terminal device <NUM> in order to input waypoints or plan a desired route.

The deconfliction engine <NUM> may receive a start point (e.g. the current position of the UAV <NUM>) for a route and a desired end point (e.g. where a package needs to be delivered). The deconfliction engine <NUM> may be arranged to plan a route between the two points. The route is planned such that the UAV <NUM> does not collide with any known objects such as vehicles (e.g. UAVs, balloons), terrain (e.g. mountains) or weather patterns (such as storm regions). The objects may be moving; in other words, collisions may be calculated based on route s for objects.

Alternatively, the user may plan a desired route using a terminal device <NUM>. The desired route is then transmitted to the deconfliction engine <NUM>. The deconfliction engine <NUM> modifies the desired route to create a deconflicted route in which collisions with known objects are avoided. A user may be presented with a message on their terminal device <NUM> to approve the modified (i.e. deconflicted) route before it is stored and/or transmitted to the vehicle controller <NUM>. Alternatively, where the object to be avoided is another vehicle, the user may be presented with an interface for re-planning the route for that other vehicle or contact details for the operator of that other vehicle.

In one embodiment, the vehicle controllers <NUM> are arranged to transmit navigation data (e.g. their position, velocity and/or heading) to the deconfliction engine <NUM>. The deconfliction engine <NUM> is arranged to use this navigation data to perform route deconfliction. Route deconfliction may first involve extrapolating a route of each UAV <NUM> using the respective navigation data. For example, if a UAV <NUM> is shown to be at a first location at a first time, and its speed and direction of travel are transmitted to the deconfliction engine <NUM>, the deconfliction engine <NUM> can calculate its position at a second time. Deconfliction may then involve generating new routes for the UAVs <NUM> that prevent their collision if the original routes are shown to intersect. In other words, the "end point" explained above may be a predicted end point. Alternatively, where original routes are shown to intersect and where the deconfliction engine <NUM> is provided with a terminal having a user interface, a user may manually generate a new route for each UAV <NUM> to remove the conflict(s).

In order to perform collision avoidance, the deconfliction engine <NUM> may have the locations or routes of other objects (or, in other words, entities), such as manned aircraft, aerostats, storm fronts or terrain features stored in memory. This data may be received through the internet, via a databus or may be prestored. For example, the deconfliction engine <NUM> may receive map data, such as topography data or architectural data. The map data may indicate the elevation or maximum vertical extent of terrain features (e.g. mountains) or buildings, along with their locations. The map data may be received from a remote server via a communications link, or may be downloaded to a memory on the deconfliction engine <NUM>. The deconfliction engine <NUM> may also have access to national air traffic data systems, other deconfliction engines/route planners, or have an Automatic Dependent Surveillance-Broadcast (ADS-B) input, so that it knows the location and trajectory (or flight paths) of other aircraft. The deconflicted routes may be generated so as to avoid collision between the UAVs <NUM> and these objects (in addition to avoiding collision between the UAVs <NUM> themselves, where one deconfliction engine <NUM> services a plurality of UAVs <NUM>). Alternatively, a user may programme the deconfliction engine <NUM> with the desired routes for each UAV <NUM>. The deconfliction engine <NUM> is provided with a route deconfliction algorithm.

Each deconflicted route is then transmitted back to the vehicle controller <NUM> coupled to the UAV <NUM> associated with the respective route. As illustrated, the route is transmitted to the vehicle controller <NUM> over-the-air. The vehicle controllers <NUM> may be coupled to the deconfliction <NUM> via a network, for example a wide area network (WAN) or local area network (LAN). The deconflicted routes may be installed on the vehicle controllers <NUM> via a wired connection with the deconfliction engine <NUM> or data transfer device prior to flight.

The deconflicted route is a path through a three-dimensional region of airspace, and therefore may indicate a sequential set of coordinates and altitudes. In other words, the deconflicted route is a plan for moving a UAV <NUM> from a start position to a final position. The deconflicted route may be a set of waypoints. There may be conditions attached to those waypoints, such as the UAV <NUM> cannot be orientated in a particular direction for EMCON (emissions control) reasons, or for security reasons where the UAV <NUM> has a camera. The deconflicted route may further include the velocity at which the UAV <NUM> should fly between coordinates or an expected time of arrival at particular coordinates (from which velocity can be calculated by the vehicle controller <NUM>).

Preferably, the vehicle controller <NUM> is reprogrammable to receive alternative deconflicted routes. Preferably, the vehicle controller <NUM> is a "plug and play" device capable of electronic communication with any UAV <NUM> having a corresponding interface, such that it can be used to control alternative UAVs <NUM> to that which it is attached.

In one embodiment, the route deconfliction algorithm defines a three-dimensional region of potential conflict around part of the or each received or generated desired route. The three-dimensional region may be representative both of the uncertainty in the position of the UAV <NUM> and of a region of air exclusion appropriate for the UAV <NUM> or for the respective received route. The three-dimensional region of potential conflict is time-dependent, in that it moves along the route to align with the expected position of the associated UAV <NUM> at that point in time. When it is determined that an object (such as another three-dimensional region of potential conflict for another UAV <NUM>) will enter or intersect the time-dependent three-dimensional region of potential conflict, a conflict is extant. The deconfliction algorithm may then warn a user (for example, with a displayed message) if their desired route has a conflict so they can replan and generate a new deconflicted route having knowledge of the conflict, or the algorithm automatically calculates a deconflicted route to avoid such an event.

Instead of a three-dimensional region, the deconfliction engine may generate a two-dimensional region of potential conflict. This is advantageous when the vehicle controller <NUM> is used to control a ground vehicle or surface vessel, where altitude is not a factor.

In another embodiment, the deconfliction algorithm determines a conflict to exist if an object crosses the desired route at a time the UAV <NUM> is expected to be at that point. In other words, the point of conflict is an infinitesimally small point in time and space, rather than a three-dimensional region.

In some embodiments, the vehicle controller <NUM> comprises at least one sensor for determining live situational awareness data. This situational awareness data, as with the map data, may be used to adapt or determine a route for the UAV <NUM>. Live situational awareness data may indicated the presence of another aircraft or object moving into the path of the UAV <NUM>, for example. The sensor may be an optical camera, radar, sonar, hyperspectral imaging device, infrared camera, etc. The sensor may comprise a laser range finder for determining the distance to a detected object. The sensor may comprise image recognition software to identify clouds and other object types. The situational awareness data may be transmitted to the deconfliction engine <NUM> so that the deconfliction engine <NUM> can modify the determined route. Modifying a route may involve instructing the UAV <NUM> to accelerate, such that the object passes behind the UAV <NUM>; slow down; or change direction. The deconfliction engine <NUM>, or a processor on-board the vehicle controller <NUM>, may calculate the speed and direction of travel of the object and the point of likely intersection with the UAV <NUM> if it remains on the route presently being followed. This may be achieved by monitoring how far the object (or aircraft) travels in a known amount of time. The laser range finder or radar may be used for this purpose. Alternatively to the deconfliction engine <NUM>, the vehicle controller <NUM> itself may be configured to modify the stored route to control the UAV <NUM> to avoid the object (or other aircraft).

An embodiment of a vehicle controller <NUM> coupled to a UAV <NUM> is illustrated in more detail in <FIG>. Here, the vehicle controller <NUM> is for receiving and storing a predetermined route (i.e. a deconflicted route) and generating control signals (i.e. control inputs) for controlling the UAV <NUM> to follow the route. The route is a flight plan. The route is stored in a memory <NUM>. The memory <NUM> may be a non-volatile memory such as read only memory (ROM), a hard disk drive (HDD) or a solid state drive (SSD). The memory <NUM> may include random access memory (RAM). RAM is used by a controller <NUM> of the vehicle controller <NUM> for the temporary storage of data. The memory <NUM>, in alternative embodiments, may comprise a route deconfliction algorithm used by the controller <NUM> in planning a route. In other embodiments, the controller <NUM> is for generating control instructions that, when performed by the UAV <NUM>, move the UAV <NUM> follow the deconflicted route.

In the illustrated embodiment, a route is initially programmed by a user using their mobile device (e.g. mobile phone), which is a terminal device <NUM>. The mobile device uses an application and user interface to receive a desired route from a user. This initial, desired, route is transmitted to and stored on the deconfliction engine <NUM>. The deconfliction engine <NUM> has access to a plurality of other routes each associated with other UAVs <NUM> and/or manned aircraft. These other routes may be received from the same mobile device (i.e. the same user), or a plurality of mobile devices, or are accessible on another server via a network.

The deconfliction engine <NUM> performs route deconfliction on the stored routes to generate a deconflicted route for the UAV <NUM> to follow. The deconflicted route may be the same as the initial route, if there were no conflicts with other UAVs or objects.

This deconflicted route is transmitted to the vehicle controller <NUM> and stored in the memory <NUM>. The memory <NUM> may contain a unique identifier, such as a MAC address, serial number or email address, to set the vehicle controller <NUM> apart from other vehicle controllers with which the deconfliction engine <NUM> is in communication. The deconflicted route is received via a receiver <NUM>. The receiver <NUM> may be a GSM, CDMA, LTE, WiMax, future <NUM> standards or the like within the <NUM>-<NUM> spectrum region receiver. The receiver <NUM> may be a Bluetooth, Zigbee, or Wi-Fi receiver. While the antenna of the receiver <NUM> is illustrated as being located outside the body of the vehicle controller <NUM>, it would be understood that this is for illustrative purposes only and it may instead reside inside the body. The antennas may take any suitable form, such as etched antennas, monopole antennas, dipole antennas, blade antennas or patch antennas.

The receiver <NUM> may instead be a wired interface such as a co-axial port, serial port, USB interface, or Ethernet interface. Transmitting the deconflicted route may comprise connecting the vehicle controller <NUM> to the deconfliction engine <NUM> via the wired interface, or using a port to receive a deconflicted route from a portable storage device.

As explained above, in other embodiments, the vehicle controller <NUM> may determine a route for the UAV <NUM> to follow based on situational awareness data received from sensors. The sensors may be onboard the UAV <NUM> or onboard the vehicle controller <NUM>. Therefore, the vehicle controller <NUM> may include sensors, such as a radar or optical camera, for detecting aerial objects to avoid such as other aircraft or weather patterns. This sensor data may be used as part of the routing process (e.g. by first being transmitted to the server <NUM>), or may be used directly by the vehicle controller <NUM> to deviate from a route where unexpected obstacles arise.

The vehicle controller <NUM> is provided with an electrical coupling <NUM> and the UAV <NUM> is provided with a corresponding electrical coupling <NUM>. The electrical couplings <NUM>, <NUM>, when connected, provide an electrical interface that allows the vehicle controller <NUM> to transmit control instructions to the UAV <NUM>. The electrical interface may be a wired interface, such as an Ethernet, USB or HDMI connection. Alternatively, the vehicle controller <NUM> and the UAV <NUM> may be electrically coupled by a wireless interface.

In one embodiment, the vehicle controller <NUM> comprises a navigation system, such as an inertial navigation system including a gyroscope and/or compass. The navigation system may alternatively or additionally include a satellite navigation system receiver such as GPS or GLONASS. The navigation system generates navigation data such as the location, heading and velocity of the UAV <NUM>. Control instructions are generated by the controller <NUM> by comparing the UAV's current location with the closest waypoint in the deconflicted route, and using an algorithm to determine the most effective way to move the UAV <NUM> from its current position to the waypoint. The algorithm may comprise a cost reduction function. The control instructions contain information such as heading, altitude and velocity. The control instructions may be packaged into a control signal.

In another embodiment, the vehicle controller <NUM> does not comprise a navigation system. Instead, the vehicle controller <NUM> receives the navigation data for generating the control instructions from the UAV <NUM> through the interface (i.e. through the electrical coupling <NUM>).

The controller <NUM> may take any suitable form. For instance, it may be a microcontroller, plural microcontrollers, a processor, or plural processors. The controller <NUM> is arranged to generate control signals for controlling the UAV <NUM> to manoeuvre to follow the deconflicted route stored in the memory <NUM>. A set of control instructions may be generated by the controller <NUM>, whereby each control instruction defines a manoeuvre, which, if all executed by the UAV <NUM>, causes the UAV <NUM> to follow the stored route.

The electrical couplings <NUM> and <NUM> may together also provide a mechanical interface, such as a catch or friction connection, for removably attaching the vehicle controller <NUM> to the UAV <NUM>. Alternatively, the vehicle controller <NUM> may be provided with a separate mechanical attachment means. In preferred embodiments, the mechanical coupling requires no modification of the UAV <NUM> itself to secure the vehicle controller <NUM>. The mechanical attachment means may include any suitable securing means, such as an adhesive layer, magnet or a strap that wraps around the body of the UAV <NUM>. The vehicle controller <NUM> and UAV <NUM> may be provided with a separate mechanical interface such as a clasp, hook and loop material. The vehicle controller <NUM> may be screwed, bolted or clipped to the body of the UAV <NUM>.

In the illustrated embodiment, the UAV <NUM> is a commercial-off-the-shelf (COTS) quadcopter aircraft weighing about <NUM> and having diameter of less than <NUM> metre. However, this is not intended to be limiting, and it would be understood that the vehicle controller <NUM> may be coupled to an unmanned vehicle of any size or configuration to provide that vehicle with the ability to avoid collisions with other objections, including other aircraft.

The UAV <NUM> may be solar-electric powered (where the power source is not shown in the Figure). However, in other embodiments, the primary power source of the UAV <NUM> may be hybrid, battery only, hydrogen, or hydrocarbon based.

The UAV <NUM> comprises a controller <NUM>. The controller <NUM> may take any suitable form. For instance, it may be a microcontroller, plural microcontrollers, a processor, or plural processors. The controller <NUM> is arranged to receive control signals received through the electrical coupling <NUM>. The controller <NUM> decodes the control signals to be able to process the control instructions contained therein. The control signals contain instructions, which, when executed by the controller <NUM>, cause the UAV <NUM> to move according to follow the deconflicted route.

The UAV <NUM> depicted in the Figures is a quadcopter-type unmanned aerial vehicle, with four propulsion units 25a-d that can be adjusted to control pitch/attitude, velocity, orientation, heading and lift of the UAV <NUM>. In other embodiments, the UAV <NUM> may take a different form, such as that of a traditional aeroplane, helicopter, airship, vertical take-off and/or landing aircraft, or balloon. Therefore, in other embodiments, the vehicle may comprise less than or more than four propulsion units 25a-d. In these embodiments, the vehicle comprises flight control surfaces such as rotors, elevators, ailerons, flaps, and propellers. The controller <NUM> may execute the instructions in the control signal by independently controlling each of the propulsion units 25a-d to increase or decrease the velocity of the UAV <NUM>. The controller <NUM> is arranged to generate control instructions to control the propulsion units 25a-d (or other flight control surfaces) to change the heading and/or orientation and/or altitude and/or attitude and/or velocity of the UAV <NUM> such that it follows the route stored in the memory <NUM> of the vehicle controller <NUM>.

The UAV <NUM> may include a sensor. The sensor may be for gathering intelligence (for example, imagery intelligence) along a route, sensing objects to avoid, or for assisting a user when controlling the UAV <NUM> manually using the remote controller. The sensor may be an optical camera, for example. The sensor may additionally or alternatively comprise a radar, LIDAR or a signals intelligence device.

The UAV <NUM> includes a memory <NUM>. The memory <NUM> may be a non-volatile memory such as read only memory (ROM), a hard disk drive (HDD) or a solid state drive (SSD). The memory <NUM> stores, amongst other things, an operating system. The memory <NUM> may include random access memory (RAM). RAM is used by the controller <NUM> for the temporary storage of data. The operating system may contain code which, when executed by the controller <NUM> in conjunction with RAM, controls operation of each of hardware components of the UAV <NUM>.

The UAV <NUM> is provided with a navigation system <NUM>. The navigation system <NUM> generates navigation data which is transmitted to the vehicle controller <NUM>. The navigation data may be packaged into a data signal and transmitted though the electrical couplings <NUM>, <NUM> forming the interface. The navigation data may indicate the current location of the UAV <NUM>. The navigation data may indicate the altitude, orientation and/or heading of the UAV <NUM>. The navigation system may be an inertial navigation system or a satellite navigation receiver. The navigation system may comprise an altimeter. Examples of satellite navigation receivers include Galileo, GLONASS and GPS receivers. Where the vehicle controller <NUM> comprises its own onboard navigation system, the UAV's navigation system <NUM> may not be provided.

A method of controlling an unmanned vehicle, specifically but not exclusively a UAV <NUM>, to follow a route (or in the specific embodiment, a flight plan) and avoid collisions will now be described with reference to <FIG>.

In a first step, S300, a processor of the deconfliction engine <NUM> receives a desired route for a UAV <NUM> to follow. The desired route may be generated by a terminal device <NUM> when a user enters a start and end point for a journey, may be generated by and received from another module of the deconfliction engine <NUM>, or may be entered manually by the user using a using a user interface of the terminal device <NUM>.

At step S301, the deconfliction engine <NUM> determines if the desired route (or an exclusion region around it) is intercepted by the route of an obstacle. The obstacle may be static, such as a mountain (so, in effect, its route is fixed in space and time), or another aircraft. Positional information about these obstacles may be stored in a memory of the deconfliction engine <NUM>, or may be accessed via a network connection.

If there is a conflict present in the desired route, at step S302 the deconfliction engine <NUM> either replans the route to remove the conflict or informs the user so that they can input corrections to the desired route to remove the conflict. This deconflicted route is then stored. Alternatively, where the desired route does not contain any conflicts, this is stored as the deconflicted route. The deconflicted route may be later used when routes for other UAVs <NUM> are planned.

At step S303, the deconflicted route is transmitted to the vehicle controller <NUM>, in this case a flight controller for a UAV <NUM>. The vehicle controller <NUM> is coupled to the UAV <NUM>. The vehicle controller <NUM> may receive the deconflicted route from the deconfliction engine <NUM> by a wired connection, portable storage device, or over a wireless connection. The generated deconflicted route is transmitted to the associated vehicle controller <NUM> using its unique identifier. For example, a message containing the deconflicted route may be transmitted to the vehicle controller <NUM> on a data carrier with a serial number (or IP or MAC address) of the vehicle controller <NUM> contained in a packet header.

At step S304, the vehicle controller <NUM> uses the present known position of the UAV <NUM> to determine a manoeuvre, or set of manoeuvres, which when executed would cause the UAV <NUM> to follow the deconflicted route (i.e. move from one waypoint to the next). The vehicle controller <NUM> generates a control signal having instructions to perform this manoeuvre (or these manoeuvres). The instruction may set out a velocity (airspeed or ground speed), time of arrival, altitude, travel time and/or direction of travel. A new control signal outlining a new manoeuvre may be generated when the waypoint is reached, such as to stop, land, or change direction.

The control signal(s) is/are transmitted to the UAV <NUM> through a communications interface, such as a wired interface.

The UAV <NUM> receives the control signal from the vehicle controller <NUM>. The processor <NUM> of the UAV <NUM> decodes the control signal to determine the manoeuvre instruction. The controller <NUM> then controls flight control surfaces, for example propulsion units 25a-d, to adjust such that the UAV <NUM> performs the instructed manoeuvre in order to follow the deconflicted route.

Claim 1:
A controller (<NUM>) for an unmanned vehicle (<NUM>), the controller (<NUM>) comprising:
a receiver (<NUM>) for receiving a desired route for the unmanned vehicle;
a first communications interface for enabling electrical communication between the controller (<NUM>) and a corresponding communications interface on an unmanned vehicle (<NUM>); and
a processor configured to:
receive the current position of the unmanned vehicle (<NUM>) and receive position information relating to at least one obstacle;
perform route deconfliction on the desired route by determining if a conflict exists whereby the at least one obstacle intercepts the desired route, and generating a deconflicted route not intercepted by the at least one obstacle, wherein the deconflicted route comprises desired arrival times corresponding to each waypoint in a set of waypoints;
generate a vehicle control signal comprising an instruction to perform a manoeuvre which moves the unmanned vehicle (<NUM>) from its current position to each of the waypoints at the corresponding arrival times; and
transmit the vehicle control signal to the unmanned vehicle (<NUM>) through the first communications interface.