Dive deeper

Problem statement

Drones will become a standard element in logistics and all kinds of urban services. To ensure a safe usage of the air space it seems inevitable to create special control centers for drones.

The first priority for establishing observational and control functions should be focused on city centers and key locations such as airports, taking into consideration all stakeholders and landscapes.

The challenge encompases many problems, as well as scenarios that we have not foreseen yet. Deck 180 will provide existing software tools, maps and models.

It is necessary for users of drones to be able to reserve their journey from A to B. After their application, they should receive a time slot and a route, considering buildings and other obstacles in the city as well as the hierarchy of passage. Some users will apply for a “fenced” cubic to use their drone for a specific purpose. Authorities will have the possibility to overrule this for urgent missions.

The airports are a special situation. In this case it’s necessary to also take into account the time slots of planes landing and taking off. Next to the visualization of the movements of drones outside and on the premises of the airport, pilots also would like to have insights of drones in their vicinity. Many questions arise when you start thinking about the tools that are required for all these users and situations.

For this challenge we will have a specific prototype focus - using “tiles” (map files) from the Netherlands and test out and ideate on the best way to create a path transition from one tile to another(area A and area B). The chosen tiles will be delivered by Deck 180 (example: RHIA [RotterdamTheHagueAirport] - City Hall The Hague).

Deck 180 aims at developing an aero-space control system for drones (similar to the ones for airplanes)where one controller manages several drone operations at the same time. There is already a base system that needs to be improved and added upon. Currently the path engine system has a drone operation control room, developed with a real time overview of all drone operations without a hierarchical order. They are managed manually by an operator. The system indicates the authorized flight path and the real time behaviour of a drone (altitude and location input).

An addition of hierarchical order and prioritization will be the next key step to achieve a “common information service” to collect data and show flying or non-flying objects and what is their status. They can be analysed based on a list of characteristics (verified, unauthorised, …) which will ultimately assist the algorithm and the operators.

Mapping challenge

How can we help drone airspace control center to provide and monitor the best path possible per drone by creating a smooth link between one map tile to another when a drone has to complete an operation over a bigger distance instead of calculating separate parts of the flight path within each single tile?

Sub-challenge Hierarchy

How can we help drone airspace control center to manage the schedule and prioritize paths of flying objects by creating a list of characteristics on which each drone has to be evaluated (secure, unidentified or dangerous, etc.) when a drone has to go from one tile into another there is a big number of drone requests/flights over an area instead of having a decentralized drone monitoring?

Sub-questions

• How to best approach the dynamic loading of maps (converted lidar to a mathematical 3D model)? Overlapping to calculate the best path is very heavy which perhaps suggests to better take smaller extractions of maps (example: 4 smaller files “tiles” to calculate from) in order to select a path from tile A to tile B (and taking into account any tiles in between).
• Multiple tiles can be used in our system. Which tiles should be chosen if points A and B are on 2 different tiles with additional tiles in between ?
• How to create a smooth link when calculating the path leaving one map area and entering another? (based on triangles - volume and terrains to define speed and 3D models on navigation and traffic scale)
• How to deal best with corridors? Corridors are areas where there is a safe and privacy respectable passage of drones to their final location and back to base station. Establishing such corridors will be the preferred and most likely fastest way to go. A designated x-y-z area for drone flights approved by the city (allowed space or negative areas where drones should not pass through)
• How to identify/keep cross checking with all plans if a detected flying object is registered/approved and if it is following its indicated path in a friendly or hostile behaviour compared to the scheduled flight plan?
• How can we assist in creating the set of rules and preliminary advice for drone usage per city area in the near and far future? Is it enough if the rules are just risk based at first? Based on discussions with municipalities or other stakeholders in the area examining the vulnerable locations (schools, hospitals, roads, etc.) and determining the baseline which can be updated later on from experiences. This can result in different characteristics per area.
• How can define and track reasons or other factors for marking a flight as unsafe? (unregistered, not approved, off path, malicious intent, etc.)

Read the article here

Scenarios:

Option 1

Build an algorithm that connects the ingoing and outgoing location/path of the tiles together.

Option 2

Optimize the algorithm that this situation also works a certain tile contains a restricted area (ex: hospital, school, etc,)

Option 3

The tiles in this case are using corridors, so multiple routes are possible. We have to calculate several routes that at the end 1 are suitable. The actual path in every tile is calculated by the Deck180 system, but we don’t know how we connect them together.

Deliver an algorithm that allows for smooth paths and links between tiles as well as creating a hierarchy by characterizing drones on a list of specifications. This algorithm should work together with the existing system for avoiding obstacles and restricted areas.

Sources for open data

From Deck 180: - tiles

From Cittamap: if necessary the following datasets

1. 3D buildings : vector dataset lighter than the LIDAR dataset for obstacle detection.
2. Public infrastructure such as water ways for obstacle detection.
3. Road network: with the road classification for routing algorithms.
   
   Time slots for airports  or integrating drones into transport infrastructure
4. Transport infrastructure: Warehouses/distribution centres to identify site locations for drone infrastructure deployment.
   
   General
5. Drone zone map with restrictions
6. Places of business i.e shopping districts
7. Socio-economic datasets

Criteria

• Utilizing provided existing software tools, maps (tile files) and models
• Adaptable to multiple future scenarios
• The solution should preferably be targeted at cities and the indicated prototype environment (example: RHIA [RotterdamTheHagueAirport] - City Hall The Hague)
• Allowing for evaluation and characterization of drones based on a set of specifications that can vary per area
• Allow for hierarchical organization of the drones
• Generating a base advice for restrictions in an area that contains for example a hospital, school, street corridor, parks or other edge case environments.
• Cross checking in real time how a drone is behaving based on its path and characteristics
• Act as a single source of truth for all stakeholders
• Sending out a notification or other way of requesting follow up action  to flying objects that are causing a threat
• 24/7 service

Goal of the solution is to lay the foundation for safe and reliable drone services and operations in cities.

This challenge is part of the Hackathon of ATL (airport technology lab). Made possible by EFRO KvW II and EU.