- A 3D mathematical description of a path — splines or line segments for example.
- The path is matched with time information such as a velocity graph for 4D representation.
- Can be generated by human operator or 4D Autorouter taking other vehicles into account.
- Generates a corresponding Free Flight Corridor defining the safety envelope of the platform.
- Built-in programming language allows the platform to modify its own behavior based on events or parameters it detects from its environment.
Trackpaths are data objects consisting of a number of elements, some necessary, some optional. In its simplest sense, a trackpath is a 4-dimensional object or data structure that combines a mathematical definition of a spline (or line segment) between two points with a velocity curve continuously representing the time between the same two points.
Using splines, splines with velocity information, and splines with velocity and attitude information is really nothing new, it’s been used in 3-D rendering systems for a long time to define the movement of an object in the 3D model or the movement of the camera to define the scene. In this example the camera can be set to move along a spline path at a given velocity and an attitude that points in the direction of what the artist wants to see rendered.
In applications where the trackpaths are generated by an operator – a theme park show designer, for example, we would use the same basic forms and functions so anyone already familiar with such mapping can easily use the software.
Trackpaths can be 6 Degrees of Freedom (DOF) for platforms such as flying, space, and underwater, or 4DOF for surface craft, road, or plant floor platforms.
One important point is that in most circumstances the Trackpath is precomputed for the device. This can be done for any number of platforms and paths at the speed of processing with the advent of the 4D Autorouter. This is a new technology similar to 3D autorouters which are used on a daily basis to design printed circuit boards. The 4D Autorouter calculates at high speed the optimum safe path for a vehicle through all known obstacles, taking all other vehicles into account in both space and time without human participation, but with the ability for oversight. With this information, the system can quickly, safely, and effectively handle the workload of calculating and approving thousands to tens-of-thousands of air traffic requests per hour with no additional personnel requirements.
A TrackPath starts with a 3-dimensional model of the Area of Operation (AO) which includes the source and destination points. This is then overlaid with a 3D grid structure, and the model is intersected with the grid to provide an area of computation that can be easily searched and manipulated in software.
Through varying techniques the accuracy of this model can vary from tens of meters to centimeters depending on the requirements of the search and the density of the AO structure. The key factor is that all known moving elements of the system can be included in this model as well as static obstructions, no fly zones, and citizen overflight restrictions.
It can also consider the capabilities of the drone type and its relative accuracy in following the path (i.e. piloted vs autonomous). It can even “learn” that a particular done is always fast or slow or just has a pilot that needs more room. This is the key to the overall control of thousands of UAS in the AO without human traffic controllers, planners, and technicians to check every flight plan.
Even more importantly the path can take into account the concept of “moral” imperatives and safety metrics such as population density at certain times of day, the probability of injury versus death, lawful or permitted landing zones, etc. For example flying over streets might be discouraged during rush hour, but allowed at other times, or the use of eminent domain routes such as train tracks.
Note in the image above, that a 3-Dimensional representation of the 4D Free Flight Corridor (FFC) at a single point in time is often a sphere, but in a 4D sense it would look like a cylinder. Similarly, this representation can be “stretched” to encompass the confidence or probability of a platform or object moving within the space being within that that sphere at the given time.
For all UAS within the AO, the autorouter also provides a Free Flight Corridor (FFC) 4D structure for autonomous systems, or a detailed Inverse Geofence for piloted platforms.
The FFC depicted left might be used in a block reservation sense for a drone theater at a theme park. At this level of complexity it is not very different from a Geofence, except it keeps the drones In instead of Out.
In the FFC structure below, however, no Geofence could adequately convey the information required
The final, and one might say most important aspect of the Trackpath is its programmability. These platforms often include excellent obstacle avoidance and scene analysis capabilities. The Trackpath is able to tap into the capabilities as part of its operating system behavior, and utilize these to alter the behavior of the platform. This programmability moves the Drobotic platform from the “drone” category into a new classification – computers that move things. This unique capability makes the Drobot a tool instead of a toy.
In this example the desired application is to perform a show utilizing drones in a stadium, or over a lake or lagoon. The 3D geometry of the location is loaded from some known model or approximated with simple geometry. The user then starts creating the Trackpath entries that describe how the platforms will move about the space, synchronizing them via timelines and the velocity graphs. In turn, velocity graphs can be auto calculated from the waypoints – points that define spline start/stop or arbitrary locations – and the timeline. Once the general geometry is worked out additional information such as attitude can be added in and the simplistic auto-generated velocity graphs can be edited to provide more complex movement, such as starting slow, putting on a burst of speed, and then coming to a quick halt. With one track path completed it can then be used as a “copy with offset” operation to create additional formations.
The most interest thing about this method of definition is that it can then be used as input to an actual 3D render program to allow the user to see the show in simulation from the audience (or any other) point of view. When completed the full Trackpath is loaded into the drone once, comprising all events from motor start at the depot, through the performance, and back to the depot and motor off. It then runs the same program show after show based on either a current time + offset calculation or synchronized with a show control system such as a SMPTE time code.
It’s also possible to embed other events, rather like DMX, into the trackpath to turn on/off lights, activate a speaker, play audio, ignite fireworks, launch a missile, etc.
Once the platform picks up the package at the depot, a quick scan tells the plotting computer (not in the drone) which one he has. The computer has pre-compiled the path of the platform considering weather, other platforms in the area, loaded speed, and pre-defined routes of airspace open to the drones approved by the FAA. This creates virtual highways that define the majority of drone routes in a congested or urban area. The Trackpath for this package is loaded to the platform, with a defined starting time, and the platform follows the command (including the return leg) at the given time. This allows the overall plotting system to integrate this platform’s activities with all others it knows about, estimate time of delivery, notify others in the air space, etc. On the return leg the platform may be able to travel significantly faster, and the plot program takes this into account. The plot program has nearly unlimited computational power at its disposal as well as the 3D model of the AO, and makes use of this to simplify what the platform has to do.
The programmability of the Trackpath allows for the storage of multiple trackpaths, for example one to get from the storage yard to the designation pickup location in the depot, one to go from return location to fueling, return to a storage location, etc. Then the control system just tells it to execute each one at a scheduled time or based on other parameters.
There seem to be innumerable patrol applications – patrolling coastline for sharks, border incursions, fire watch, and drones on the top of law enforcement patrol cars. These may have a more general form of the trackpath, and make more use of the ability to perform actions based on a trigger condition. For example on shark watch, the platform first has a predefined trackpath for its normal patrol movement, over a period of time until its fuel runs low, then it switches to a trackpath that takes it back for refueling
Once the vehicle sees a trigger event, for example a shark in shallow water, it can then notify dispatch and run a secondary trackpath. In the event of a shark, it could track the animal, hovering above it, emitting strobe light and a siren. For tracking a person in open country, it could follow and notify dispatch, but remain silent. In the law enforcement scenarios, in one instance the idea is that the drone is stationed on the roof of the cruiser, and the officer has a small remote. As he exits the vehicle for an incident, he turns on the drone which then uses the GPS coordinate of the current location as its base, and the trackpath represents offsets from that point to basically circle the area recording the entire scene. Additionally it could track the officer’s remote, keeping the platform’s camera on the officer even though the platform may be circling. The programming / scene analysis system may take into account the road edge to keep out of traffic areas. Multiple cameras could record the officer and the general area at the same time. This kind of tracking behavior is a step above normal trackpath operations, but is again simplified by the tracking operation itself. The platform isn’t trying to autonomously fly in general, it’s just trying to match its vector against a moving object, and calling on obstacle avoidance to make that happen safely.
Similarly, an automated landing system for a carrier primarily involves matching the platform vector to a moving target in time and space. The final vector approach can take the full 6DOF movement of the carrier into account by analysis of the Fourier transform of the ship’s motion. While much of the wave action around a ship or barge (think SpaceX) is random, the large motions are more regular and lower frequency. The ship’s motion itself is usually predictable from a short analysis of its heading and speed. That allows an approach trackpath to be computed that matches the time of arrival and location against the ship at the exact position and time that is most desirable.
Free Flight Corridor (FFC)
The key to safety of the general public and threat mitigation in the misuse of drones is the Free Flight Corridor. The only way to mitigate the threat of misuse of drones is to keep them to their path, not just keep them away from one someone thinks of as a target. There are an infinite number of targets. That’s easy to explain and understand in concept, but it has some interesting implications. Design of the FFC can be seen as an extension of the 4D application code used to create trackpath itself, but here we’re defining a volumetric object, or a simplification of one. For example, for a land vehicle the FFC might be a 2-dimensional rectangle. For a flying platform it could be a 2-dimensional outline of the lagoon in our lagoon show, and then projected from a base altitude to 200’ in altitude. It could be a 3-dimensional object comprised of a spline or polygon in the X and Y, with a floor at 30’ and a ceiling at 60’. Or it could be a simple sphere. The FFC is actually a 4-dimensional construct, as it can also vary over time. For example the FFC could be a corridor for some period of time and then become a room at the time the platform arrives at that waypoint in the trackpath. In a delivery scenario the FFC could be a tube defining the transport corridor, or a sphere that moves with the platform. One of the most significant principles of the obstacle avoidance system is the avoidance of the FFC.