System architecture » History » Revision 14
Revision 13 (Rafael Bailon-Ruiz, 2020-09-10 13:12) → Revision 14/19 (Rafael Bailon-Ruiz, 2020-09-10 13:21)
h1. System architecture
CAMS is a software framework for cloud exploration using fleets of UAVs. The system drives a *fleet of UAVs* inside *clouds* acoording to *user's plans* and *collects sensor data*. Afterwards the information is processed by *dedicated atmosphere analysis algorithms* to produce 4D *cloud maps* that are simultaneously *stored in a database* for future use and *shown to operator* through a *graphical user interface*. This graphical user interface also provides operators the means to *manage the fleet of UAVs* .
!system_overview.png!
h2. Main features
The goal of this system is to provide an easy to use [[Graphical User Interface]] to perform four main features:
* **Monitor data acquisition :**
** Predicted 4D cloud maps (3D + time).
** Various data profiles, including raw data display and vertical atmospheric profiles.
%{background:lightgreen}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).
%{background:lightgreen}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.
%{background:lightgreen}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":https://redmine.laas.fr/projects/nephelae/wiki/Simulation for more details.
%{background:lightgreen}insert images here ?%
h2. Modes of operation
%{background:yellow}TODO: Simpler images%
CAMS designed to work in several modes of operation fulfilling different user use cases:
* Pure simulation
* Mixed-reality
* Field deployment
* Mission replay
h3. Pure simulation
Operation in pure simulated mode uses virtual Paparazzi UAVs flying into synthetic clouds from a MesoNH database.
!CAMS_current_state_simu.png!
!functional_diagram_real_flight.svg!
h3. Mixed-reality
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.
%{background:lightgreen}(Missing picture)%
!functional_diagram_real_flight.svg!
h3. Field deployment
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.
!CAMS_current_state_exp.png! !functional_diagram_real_flight.svg!
h3. Mission replay
!CAMS_current_state_replay.png!
h2. 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":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.
* **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_framework.
* **Mapping module :**
** 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).
** 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":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.
* **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":.
For more information on the codebase see "here":https://redmine.laas.fr/projects/nephelae-devel/wiki.