LAAS-Nephelae system overview¶

This is a functional description of the LAAS-Nephelae software.

For more detailed description on the code base see here.
For a tutorial on how to install the various softwares see here.

Main features¶

The goal of this system is to provide a helper graphical user interface with the following features:

• Monitor data acquisition :
  • Predicted 4D cloud maps (3D + time). See more details on the mapping system here.
  • Various data profiles, including raw data display and vertical atmospheric profiles.
    insert images here ?

• Monitor fleet status :
  • Current UAV positions on map.
  • Status updates for each UAVs, including current task, (predicted path ?), flight time, battery voltage and many others.
  • Dedicated interface for telepilots as a tool to validate generated flight plans (for safety).
    insert images here ?

• Generate flight plans :
  • Depending on current fleet status and map of cloud, the user will be able to require a UAV to execute a specific flight pattern. The interface aims at providing a user-friendly interface to generate complex flight plans.
    insert images here ?

• Simulation :
  • Using the simulation capabilities of the Paparazzi framework and MesoNH atmospheric simulation data, the whole system is able to run entirely on simulation. See here for more details.
    insert images here ?

Main software components¶

The software is made of several key sub-systems, most of them programmed in Python 3.5 (NOT compatible with Python 2):

• Graphical user interface : Web browser interface (HTML, CSS, JavaScript). Made with the Django framework to link the web-based front-end with the Python back-end. More details here.

• Paparazzi interface module : Python interface with Paparazzi system. In charge of communication with UAVs and ground station via the IvyBus. The idea is to abstract the link between Paparazzi and the rest of the LAAS software. More details here.

• Mapping module :
  • Full dense maps of clouds using sparse data generated by the UAVs, with the help of Gaussian Process Regression (GPR).
  • Higher level functions to estimate some cloud parameters from a dense map (segmentation, area, border, etc...).
  • Single map interface, behind which can be a GPR predicted map, or a section of MesoNH data to be used as ground-truth in simulation.

• MesoNH interface module : Provides helper function to read data in a MesoNH atmospheric simulation database. Used to simulate UAV flights in a realistic atmosphere by emulating wind, pressure, liquid water content, and many other variables. Also used to emulate UAV sensor data.

• Data server : Aggregates all data coming down from flying or simulated UAVs (or any other source) into a single server instance. Any module which needs data, like the mapping module or the GUI module must require data from the data server. More details "here":.

Functional block diagrams¶

Full simulation¶

In a simulation scenario, the full stack of LAAS software is used. The simulated UAVs fly into simulated wind and their Liquid Water Content (LWC) sensor is also simulated. Both data come from a MesoNH database.

Real flight¶

In a real flight scenario, none of the MesoNH modules are required. The rest of the modules should work exactly the same thanks to the Paparazzi framework abstraction level.

Hybrid¶

The hybrid scenario is meant to test the adaptive flight patterns without having to fly into a cloud. Real UAV are flying but the LWC data is read from a MesoNH database. It is then sent to the UAVs to emulate the LWC embedded sensor.