Fly Autonomously!

Smart Traffic Visibility System For Drones (STVS)

UAVs (also referred to as drones) have wide ranging uses in business applications within defined 3D space. This implies that the domain of the operation of the vehicles is a known space such as a large building. Within that defined space, we may have several such vehicles operating and at the same time there may be fixed or non-fixed obstacles. For such vehicles to operate autonomously and safely, it is necessary that a central system provides overall visibility.

The solution described here provides the following capabilities:

• A framework to define the 3D space (Separate patent application … deals with more details of this definition)
• Sample protocol for the UAVs to communicate with the central system

Solution Overview

Several stories in this publication discuss how to define 3D space for a building and how a drone could then determine its position accurately inside that building. This solution assumes that we are operating in such a space and each drone knows its own X,Y, and Z coordinate within an acceptable margin of error.

In addition, we will be able to define obstacles in such a system as well — for example racks in a warehouse. For this we are assuming that they are cubes in 3D space. This indicates that we can define them simply by X1,Y1,Z1 and X2,Y2,Z2. All the space consumed by this region will be deemed an obstacle.

The obstacles can be of varying types — some may strictly be defined for maneuvering around them but some may be defined to indicate landing pods where the UAVs can land.

Terminology

Following terminology will be used within this document:

Understanding the Eco System

The overall eco-system that we will support is that of a large organization that may be operating several buildings within which the UAVs operate. So every one of those buildings will be considered a distinct 3D space.

Such an organization may choose to have a single wife access point name (SSID) in all of its locations to simplify connectivity. This will allow the UAV to be configured once — but it will still need to assess the actual 3D space it is operating in.

Solution Details

Following section describes how the solution will work.

Configure the UAV

During this step the UAV will be configured to set the following items:

• The SSID that it will connect to per the security requirements of the organization.
• The URL of the traffic management system
• Register the MAC address and/or the serial number of the UAV with the organization.
• Assign the specific UAV a unique name.

Initialize the UAV (UAV talks to STVS)

This will be done any time the UAV is turned on. A reset button may also be placed on the UAV. It will invoke a Web-API for “initialize” endpoint at initialize-url and pass in:

• MAC address of the UAV and the Serial number of the UAV. These will be used to uniquely locate the UAV in the system. One of them is enough to identify it.
• The current IPv4 address of the UAV
• The current IPv6 address of the UAV
• The default gateway that the UAV is connected to
• The wifi router’s MAC address
• 3D-Space-DB-Version. This is the current version of the 3D-Space-DB that is in the UAV. If a blank is provided, it means there is no database currently and it needs a new one.
• 3D-Space-Id. The 3D space that it was previously connected to.

The initialize web-API will return following information:

• “3D-Space-Id”. Based on wifi router’s MAC address, the system will look up the building it is located in and that will be termed the 3D-Space-ID.
• “run-url”. This is the URL that the UAV should provide additional information. We are supporting the idea that it may be different from initialize-url. The run-url may be specific to a specific 3D building.
• “report-frequency-inflight”. This is the frequency in milliseconds that the server expects the UAV to report its data. For example, 1000 means that the server expects that the UAV will report about itself every second while in flight.
• “report-frequency-landed”. This is the frequency that the UAV should report when not in flight. This is also in milli-seconds.
• “3D-Space-DB”. If the STVS determines that the version of the database is not current and some data has been updated, the whole database will be provided.

It is recommended that the UAV display the “3D-Space-Id” physically so that the operator can see it as well. At this time the traffic system for this local 3D space will know that the specific UAV has entered it.

Flight Status Update (UAV talks to STVS)

While in flight, the UAV will invoke the “flight-status-update” endpoint on the “run-url”. The frequency is as retuned by the “initialize” call in “report-frequency-inflight”.

Following data will be provided with the update:

• MAC address of the UAV and the Serial number of the UAV. These will be used to uniquely locate the UAV in the system. One of them is enough to identify it.
• “Flight-Position”. The current X,Y,Z of the UAV
• “flight-vector”. Some other X,Y,Z in the same 3D system that would define the direction that the UAV is flying in.
• “flight-speed”. The speed in millimeters/second.
• “flight-status”. This will have inprocess, complete, abort. When a flight plan has been fully executed, it will report that it is complete. Abort means that the UAV for some reason is abandoning the plan and taking a new direction. That could be to deal with an emergency.
• “flight-status-code”. When “abort”, provide a reason code for the reason.
• “battery-life-pct”. Battery life remaining in percent
• “battery-life-ms”. Battery life remaining in milliseconds.
• “Rotor-speed”. If multiple rotors all of them should be reported as a coma-separated list in revolutions/ms
• “other-data”. This is flexible area where name:value pairs can be sent for any other data that UAV wants to provide such as rotor speed etc.

UAV Status Update (UAV talks to STVS)

When not in flight, the UAV should invoke the “uav-status-update” endpoint on the “run-url”. This should be done every “report-frequency-landed” milliseconds (output from the initialize call) — or as needed.

Following data will be provided with the update:

• MAC address of the UAV and the Serial number of the UAV. These will be used to uniquely locate the UAV in the system. One of them is enough to identify it.
• Current Position as X,Y,Z
• “battery-life-pct”. Battery life remaining in percent
• “battery-life-ms”. Battery life remaining in milliseconds.
• “Rotor-speed”. If multiple rotors all of them should be reported as a coma-separated list in revolutions/ms
• “battery-hatch-status”. It will be “closed” (meaning battery is secured). “open” means it is open for replacement.
• “other-data”. This is flexible area where name:value pairs can be sent for any other data that UAV wants to provide such as rotor speed etc.

Set UAV Flight Plan (STVS talks to UAV)

The STVS will communicate with a specific UAV using the communication details provided as part of “initialize” call to set its flight path. Flight path will be provided in terms of the various X,Y,Z waypoints.

The input to the specific UAV will be in the form of a list of waypoints each with X,Y,Z along with a speed suggestion. If there is no speed suggestion, then it is up to the UAV to decide. The UAV is expected to stop at the final waypoint.

The flight path will be passed-in as an array of records with 4 items. Each row of the array will be the waypoint. The recordset will have:

• Type. What is the type of this flight. It may have:

Sortie. A specific flight where at the end an attachment will be operated.

Landing. This flight plan ends in a landing.

Free. Free flight

• X
• Y
• Z
• Speed in millimeters/millisecond. If 0, then it is up to the UAV to decide.

When the UAV receives this, it will fly to each waypoint, stop and orient to next waypoint and then go there.

Note that it will be providing update via “flight status update” Web API and when flight is complete, same API will report completion.

Operate Attachments (STVS talks to UAV)

The UAV may have several attachments, e.g. cameras. This framework simply provides an endpoint to call for the UAV but exact details will be up to the UAV. Following is an example:

Lets say UAV has several cameras. It will declare the name of each camera for the purpose of this API. The call will be something like:

• Attachment_id: <as described by the UAV>
• Setup_instructions: A flexible recordset to provide the data. For a camera it will be the X,Y,Z to orient it.
• Execute_instructions: A flexible recorset. This will come intp play when setup is complete. For a camera it will be to take a snapshot
• Other_data. Any other data.

When this completes, the UAV will return arbitrary data back. For instance in case of a camera, it will be an image

Illustration

Here is an illustration of the discussion.

Summary

Once we have the capability where each UAV knows about its position accurately — it is important to have a central system where we can operate several of these UAVs.

If these UAVs are operating inside buildings, there will be a strong need to manage the traffic effectively. The solution described here provides an approach to manage this information.

See Also