Project

General

Profile

System overview » History » Version 7

Pierre Narvor, 2019-10-01 10:07

1 1 Pierre Narvor
h1. LAAS-Nephelae system overview
2
3
This is a functional description of the LAAS-Nephelae software.
4
5
For more detailed description on the code base see "here":https://redmine.laas.fr/projects/nephelae-devel/wiki/Codebase_overview.
6 5 Pierre Narvor
For a tutorial on how to install the various softwares see "here":https://redmine.laas.fr/projects/nephelae/wiki/Installation.
7 1 Pierre Narvor
8
h2. Main features
9
10 7 Pierre Narvor
The goal of this system is to provide a helper "graphical user interface":https://redmine.laas.fr/projects/nephelae/wiki/Graphical_user_interface with the following features:
11 1 Pierre Narvor
12
* **Monitor data acquisition :**
13 4 Pierre Narvor
** Predicted 4D cloud maps (3D + time). See more details on the mapping system "here":https://redmine.laas.fr/projects/nephelae/wiki/Mapping.
14 1 Pierre Narvor
** Various data profiles, including raw data display and vertical atmospheric profiles.
15
%{background:lightgreen}insert images here ?%
16
17
* **Monitor fleet status :**
18
** Current UAV positions on map.
19
** Status updates for each UAVs, including current task, (predicted path ?), flight time, battery voltage and many others.
20
** Dedicated interface for telepilots as a tool to validate generated flight plans (for safety).
21
%{background:lightgreen}insert images here ?%
22
23
* **Generate flight plans :**
24
** 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.
25
%{background:lightgreen}insert images here ?%
26
27
* **Simulation :**
28 4 Pierre Narvor
** 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":https://redmine.laas.fr/projects/nephelae/wiki/Simulation for more details.
29 1 Pierre Narvor
%{background:lightgreen}insert images here ?%
30
31
32
h2. Main software components
33
34
The software is made of several key sub-systems, most of them programmed in **Python 3.5** (NOT compatible with Python 2):
35
36 4 Pierre Narvor
* **Graphical user interface :** Web browser interface (HTML, CSS, JavaScript). Made with the "Django framework":https://www.djangoproject.com to link the web-based front-end with the Python back-end. More details "here":https://redmine.laas.fr/projects/nephelae/wiki/Graphical_user_interface.
37 1 Pierre Narvor
38
* **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":https://redmine.laas.fr/projects/nephelae-devel/wiki/Paparazzi_interface.
39
40
* **Mapping module :** 
41
** Full dense maps of clouds using sparse data generated by the UAVs, with the help of "Gaussian Process Regression":https://scikit-learn.org/stable/modules/gaussian_process.html (GPR).
42
** Higher level functions to estimate some cloud parameters from a dense map (segmentation, area, border, etc...).
43
** 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.
44
45
* **MesoNH interface module :** Provides helper function to read data in a "MesoNH":http://mesonh.aero.obs-mip.fr/mesonh54 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.
46
47
* **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":.
48
49
50
h2. Functional block diagrams
51
52
h3. Full simulation
53
54
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.
55
56 2 Pierre Narvor
!https://redmine.laas.fr/attachments/download/1629/functional_diagram_simulation.svg!
57 1 Pierre Narvor
58
59
h3. Real flight
60
61
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.
62
63 3 Pierre Narvor
!https://redmine.laas.fr/attachments/download/1628/functional_diagram_real_flight.svg!
64 1 Pierre Narvor
65
66
h3. Hybrid
67
68
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.
69
70 2 Pierre Narvor
!https://redmine.laas.fr/attachments/download/1627/functional_diagram_hybrid.svg!