Drone traffic simulation in urban environment

[mbaena-nommon]

Hello everybody,

BlueSky is being used for drone traffic simulations in urban environments in the USEPE SESAR project. The goal is to assess and propose new methods to ensure the safe separation of drones (from each other, from manned aviation and from other obstacles such as buildings) in the U-space environment, with particular focus on urban environments. For more information on the separation method and the project in general, please visit USEPE D3.1 Concept of Operations Outline.

To that end, we have been developing the following features to incorporate to the BlueSky simulator:

• Module to create a 3D graph of waypoints based on OSM data and 3D data of the buildings in GML format. This allows us to differentiate regions when flying between and above the buildings.
• Module to plot buildings' floor plan, employing the LoD1 open data of Hannover city.
• Module to create sectors in the city area, which have performance properties associated that the drones have to meet to enter.
• Strategic deconfliction module, based on the maximum capacity of the aforementioned sectors.
• Performance based conflict detection module, based on the Aircraft Safety Bounds concept (still under development).
• Module to incorporate a wind field dataset from the PALM simulator (wind has to be precomputed)
• Logger for conflicts and loses of separation between drones

We have encountered some issues in the development:

• The number of waypoints created for the entire city area (around 10x10km²) is large. I am not sure if this can be improved, because at least a point is needed on each crossroad and for curved streets, the path should be smooth to avoid collisions with buildings. Suggestions are welcome.
• For the visualization of the city in BlueSky, we are using the POLY command. We load a scenario file containing one command for each building, but the loading process to plot the buildings is rather slow. We are using Windows 10, finding the following error when loading the polygons: Unable to load numpy_formathandler accelerator from OpenGL_accelerate. Also, a textbox appears when starting BlueSky, saying Warning: An OpenGL Core Profile was requested, but it is not supported on the current platform. Falling back to a non-Core profile. Note that this might cause rendering issues.. Maybe there is a way to load the map of the city as an image (similarly to the world background) to reduce the computational effort. We have seen that in Metropolis 2 SIDs poster presentation. We will appreciate it if you could give us a hint on this topic.

We will be happy to discuss any of the presented topics and collaborate with other developers that are implementing similar modules.

[jooste]

Hi!

Great to hear that USEPE is also using BlueSky. Your project has much in common with Metropolis 2 (obviously), which means that we've faced similar problems.

The first issue you mention we've encountered as well in M2. We've identified two solutions. In the long term the plan is to implement curved leg types, so that curved streets need not be represented by many waypoints anymore. This is currently still a TODO though. The alternative is to pre-process the street data coming out of OSM, and reduce the number of points that define streets based on an error criterion. We've found that we can reduce the number of waypoints by quite a lot without losing too much precision.

For visualisation we also started out using POLYs, but this indeed becomes infeasible when too many polygons need to be defined. The problem is that polygon definition happens on the sim-side, which is then communicated over TCP to the gui-side (they are separate python processes). When thousands of such poly messages are sent in a short period you will notice a visible lag due to the implementation of the update cycles on both sides. We've therefore implemented tile textures for alternative background images (a long-held item on the wish list). If your bluesky is up to date with the master version you can enable this map with the following command: VIS MAP TILEDMAP. The default tile source is opentopomap, but other sources can be configured as well (you can even make your own custom tiles, which we are doing in M2 to also show concept data on the map). Note that when the map is zoomed out the tiled map doesn't match perfectly, because the tiles use a different projection method (web Mercator). When zoomed in to city-level this is not noticeable.

It would be great to learn more about the additions you've made to bluesky. Are all the changes you've mentioned kept up to date on your fork?

[jbueno-nommon]

Hi everyone,

I am also working on the USEPE project. Thanks for the help with the visualization. It’s really great now!

Yes, you can check our developments in our fork, but some work has been done in parallel and it will be finalised in the coming weeks. So far, most of the modules are executed externally, creating BlueSky scenarios. Our idea is to include the developments mentioned as BlueSky plugins in the next 2-3 months. You can check the developments in the user manual we are elaborating, which is included in the documentation of our fork (it is not final, so we will keep updating it with new improvements). Any comments or suggestions from your side are welcome! After assessing that the new plugins work as expected we will create a pull request to merge them with the main BlueSky’s code.

I elaborate a little more on some of the key areas of USEPE that I think may be of interest for future BlueSky developments and include some questions:

• We structure the airspace into segments which have a set of attributes/requirements. First, we compute pre-defined segments based on regions of interest (e.g., natural protection areas that should be avoided, airspace classes, wind hot spots, etc.). After, once the simulation is running these segments will be dynamically updated depending on some real-time data: state of drones, wind data or external events such as emergencies or accidents. The set of methods to dynamically update the segments is still a work in progress, but the idea is to develop a plugin to update the segments using some BlueSky variables and to reroute drones already flying in the simulation.
• We are working on a performance based conflict detection. If we know about the principal geometry of the ownship avoid trajectories, we can pre-simulate the avoidance maneuver for each possible encounter. With that information, the module will be able to decide on the best maneuver and the time to perform it.
• In relation to the previous objective, the USEPE method requires defining a different conflict resolution logic for each pair of drones. So, we are interested in assigning a resolution method for each pair depending on the characteristics of the encounter. For example, two drones flying between buildings cannot perform the same maneuver that two drones flying above buildings. When you use the command RESO in BlueSky, you activate the same resolution method for all drones. Have you faced this issue?
  • In relation to the concept of flying between buildings, in our developments we do not consider geofences for buildings. We only use the graph to define trajectories between buildings. This is enough until we perform a resolution maneuver. At this moment, drones stop flying strictly according to the flight plan and may end up in a collision with a building. Have you made any advances in defining geofences for buildings? We will appreciate it if you could give us a hint on this topic. This is another reason why we are interested in defining a resolution method per aircraft.
• Another important R&D question in USEPE is to understand how turbulent wind affects the flights of drones and its impact on separation. We simulate the turbulent wind field data (consisting of the three Cartesian velocity components) with high spatial resolution (~2m). Two issues come up:
  • We generate a huge amount of data and it can hardly be handled by BlueSky. To solve this, our approach is likely to be to reduce the size of the study zone and do post-processing to increase the granularity. However, we would like to know about your experience with loading wind data in BlueSky. What data have you used in the past?
  • As I mentioned before, we generate data consisting of three Cartesian velocity components, but BlueSky only considers the horizontal components. Have you ever thought of using the vertical component as well?