User manual

This manual depicts all the user interaction with the desktop app itself. Manual consists of App installation, Types of windows and all their functionalities and App settings (types of settings and their effects on the application runtime)

Table of contents

  1. App installation

  2. Windows and their functionalities
    1. Main menu

    2. Settings

    3. Controller window

    4. Worker (ATCo) window

  3. Simulation modes

  4. User-manageable JSON configurations

App installation

Note

Currently, project does not have any builds, the main desktop app is now in early development and many features are not done yet. However, you’ll soon be able to see releases at SEDAS github Releases.

List of supported OSes/distros

Name

Status

Note

Ubuntu 24.04

https://img.shields.io/badge/X-red?style=flat-square

Release not available

Ubuntu 22.04

https://img.shields.io/badge/X-red?style=flat-square

Release not available

Arch Linux

https://img.shields.io/badge/X-red?style=flat-square

Release not available

Windows 11

https://img.shields.io/badge/X-red?style=flat-square

Release not available

Windows 10

https://img.shields.io/badge/X-red?style=flat-square

Release not available

MacOS

https://img.shields.io/badge/X-red?style=flat-square

Release not available

  • ok - Working on distro

  • warn - Some issues are present

  • fail - Failing on distro/Not released yet

Note

All the build steps were tested for Linux distros, so the actual build instructions for Windows would probably differ significantly.

Setting up repository

git clone --recursive https://github.com/SEDAS-DevTeam/SEDAS-manager.git
cd SEDAS-manager

Setting up Python virtual environment

I recommend using pyenv for setting up project helper (for managing building, compiling, etc.), but if you are more familiar with conda, there is no problem of using that. All the project helper dependencies are in requirements.txt

pyenv install 3.11 # install python3.11
pyenv virtualenv 3.11 sedas_manager_env
pyenv local sedas_manager_env # Switches to environment
pip install -r requirements.txt # install depedendencies

Note

This local setup created a .python-version file inside your workspace. It helps pyenv determine what virtual environment to activate. So basically you don’t need to do the activation/deactivation.

Setting up Node.js environment

This projects uses nvm (Node Version Manager, installation link) for the Node.js version managing, so that the project could stay mostly up to date. I recommend using this for the standard setup. Currently, the project uses the latest LTS version (v22.14.0), in order to set up environment correctly, you have to take steps below:

nvm install # to install LTS version from .nvmrc file
npm install -g npm@latext # ensure the latest version of npm

The Node.js environment is now set up. The invoke commands will automatically switch to version specified in .nvmrc.

Install npm dependencies

npm install
npm install -g node-gyp # to enable addon compilation

Note

Currently, Ubuntu 24.04 implemented the new AppImage restrictions, so that users cannot run Electron apps sandboxed (github issue). The temporary workaround is below:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 # deactivates the restriction
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1 # activates the restriction

Check any updates from submodules

invoke update # this will also check requirements.txt if any dependency is missing

Compile C++, TS and node-addon-api files

invoke compile

Run app in development mode

invoke devel app # to run the app in development mode
invoke devel install # to run the installer in development mode (for testing, installation is turned off)
invoke devel uninstall # same but for the uninstaller script

Everything should be set up for now :).

Toolkit enables developer to build and publish a binary locally. This feature is only for users who want to contribute and be part of the active development. So there are definitely going to be some changes regarding this part.

invoke build # executes app build
invoke publish # executes app publish to github

Note

Difference between publish and build commands is that publish also publishes the binary to Github. So you dont need to run build before publishing.

Note

The publishing wont work right now. You would need to be authorized and have access to the organisation which is not possible for now because many aspects needs to be tweaked in the future.

This part is entirely optional. It is just here to show people who want to take part of the development how to setup other SEDAS repositories as well.

This module is already being built inside the SEDAS-manager as a submodule. So practically there is no need to build it yourself. But if you want to take a part in the SEDAS-AI-backend development, you can follow these steps:

Setting up the repository

git clone --recursive https://github.com/SEDAS-DevTeam/SEDAS-AI-backend.git
cd SEDAS-AI-backend

Setting up Python virtual environment

pyenv install 3.11 # install python3.11
pyenv virtualenv 3.11 sedas_backend_env
pyenv local sedas_backend_env # Switches to environment
pip install -r requirements.txt # install depedendencies

cd src # switch to working dir (where the tasks.py is located)

Fetching all the ASR/TTS model resources

invoke fetch-resources

Note

Be aware that this would probably take some time. The helper needs to fetch an ATC-whisper binary from huggingface repository and also some TTS binaries from the Piper web resource.

Building whisper.cpp dependency

invoke build-deps

Note

This step would also take some time, the whisper.cpp needs to build a wrapper that will invoke ATC-whisper model at the simulation start. So if you are compiling the CUDA version (that is set by default) this process will probably take some time.

Building the whole project

For testing

# for running a test
invoke build --DTESTING=ON
invoke run test

For the test executable, you can control the ASR and TTS just by using a keyboard invokes (i. e. the a key for the start/stop of recording and q key for killing the entire program).

For integration

# to test the actual executable that is going to be integrated in SEDAS
invoke build --DTESTING=OFF
invoke run main

For the main executable, in order to test the communication, you have to run another script on different terminal window (this is because the integration script communicates using socket communication on a specific port 65 432).

invoke test-main # runs the "commander" script that controls the "main" one

Note

Unfortunately, the main executable currently communicates on a specific port that is not changeable. This will definitely change in future

The test-main script usage:

register  [callsign (string)] [noise-intensity (float)] # registers a pseudopilot to communicate with user (write without brackets)

start-mic # starts mic recording
stop-mic # stops mic recording

#
# Do some communication here using start-mic or stop-mic
#

unregister [callsign (string)] # unregister/terminate a pseudopilot
quit # terminate the main program

Windows and their functionalities

Types of windows

Currently, these types of windows are utilized:

Settings

_images/settings.png

In the settings window, user can set up the basic simulator behavior. The window itself is separated into multiple categories. We have the general settings, which facilitate the general ATC simulator behavior. Then we have the Controller settings (i. e. the behavior of the ATCo windows) and the Simulation settings, which allow user to change some environmental aspects and also AI pseudopilot behavior.

Controller window

This is the most important window in the whole app. It categorizes user actions into multiple tabs (Setup, Simulation, Wiki, Monitors, Plugins) that are explained below. The documentation is formatted into different categories that explain specific window. Category order is similar to the order in Controller window.

_images/controller_setup.png

Controller Setup tab

The SEDAS simulations are divided into two categories: Planned and Unplanned.

Planned simulations

User can set up the planned simulations in the Setup tab, when they select Map (and corresponding scenario), Aircraft preset and Commands preset with aditional tweaks. After that, the simulation engine will determine and setup the simulation accordingly. Variables, that are tweakable by user, are explained below:

  • Map - here, user can select a specific map/airport that will be used in the simulation. Every map has its type according to ATC zone classification (ACC, TWR and APP). They also have designated ICAO airport code (if the map is designated as an airport), Country and City (could be left empty if the simulation doesnt redirect to actual place) and the description (also optional).

  • Scenario - Every map has its own predefined sets of scenarios, that define what plane types are going to be used in the simulation and also other key aspects (time of plane spawning, special situations). Every map has different scenarios.

  • Scenario adjustment - User can adjust selected scenarios. Currently, scenario adjustments just allow to exclude WTC (Wake Turbulence - ULtralight, Light, Medium, Heavy, J - Super) or CAT (aircraft category - AIrplane, HElicopter, GLider, AErostat) categories.

  • Scenario time - User can select the time of scenario (this setting is just aesthetic, so it could be left at random, which generates random time and date)

  • Aircraft preset - Allows user to select specific types of planes (planes from only one manufacturer, etc.). User can inspect the preset before selecting it.

  • Commands preset - Allows user to select specific commands that are going to be allowed in the simulation. Other commands are not going to be accepted by AI pseudopilots.

Note

Currently, the planned simulations are not working yet. This is because the implementation of the simulation setup engine is quite tedious and requires to set up a lot of rules and exceptions when implementing it. It is advised for the user to use Unplanned simulations path.

Unplanned simulations

Every map allows user to set every preset to empty. That means, that the simulation engine will be set to default and zero exceptions will be enforced upon the simulation. The simulation would be empty and only the selected map would be rendered. After that, user can freely spawn planes in the Simulation tab, so the simulation is directed by the user.

Worker (ATCo) window

_images/worker.png

This is the GUI that is visible for the ATCo (Air traffic control officer). The overlay is partly inspired from other simulators as well. On the top is the topnav that contains ATCo actions (microphone output toggle, Date and time of simulation and simulation state switching). Simulator also allows ATCo to exit simulations (so that ATCo doesnt have to drag their mouse to separate window in order to exit app). On the bottom right corner we have the scale, so that ATCo can make some as assumption about the area of the ATM zone. Planes also have dotted paths that indicate their previous location.

Simulation modes

Currently, the app supports two modes of ATC simulations: planned and unplanned simulations. Their purposes and functionalities are explained below.

  • Planned simulations - For the user, these ones are easier to set up. Only thing user needs to do is setting up the simulation in the Controller window (more specificaly, the setup tab). Here, user specifies map, its corresponding scenario, some adjustments, aircraft presets, command presets and scenario time. After user clicks on the Confirm and setup button, the app starts its environment handler which then sets up all the monitors and also the whole ATC environment. After that, user can just click on the START button in the Simulation tab. After that, the simulation is set up and running. (User can then do some small tweaks in the terms of plane handling etc.)

  • Unplanned simulations - Every map supports an empty scenario. When user selects this, while also setting up the rest of presets, and pressing the Confirm and setup button, the app will not start its environment handler, because it detected that there is no scenario available. The only thing it will set up is the map and the rest of presets (aircrafts, commands). So in order to spawn any planes in the user-specified map, user needs to spawn planes manually, which is done in the Simulation tab.

Note

Currently, the app only supports the unplanned simulations scenario, the planned simulation setup mechanism is still in the development.

User-manageable JSON configurations

This is the most used way of changing SEDAS configurations. Fortunately, users do not need to edit the configurations themselves, unless they want a bigger control of the programs behavior. The main app settings could be changed via the graphic interface of the SEDAS settings, that is accessible through the main menu. Still, this chapter lists other configurations and also the settings formatting, so that user can manually intervene into the app functioning.

Note

Modules and Plugins also have their own configs, but their are managed by the module/plugin itself. The whole module/plugin configuration panel will be available in the next SEDAS version.