[GSOC2017] Introduction to the generic creation of a ground station using USOC

Introduction

The Universal Space Operations Center, USOC, is an open-source tool that allows a simple and easy creation of a working groundstation to aid (student) space projects.

Due to the fact that the functionality of every experiment should be checked before lift-off, a communication software for up- und downlink is required. USOC follows a generic approach and offers the possibility to write this software automatically using a configuration file. The program structure is divided into three main components:

  1. Communication software
  2. Graphical user interface (GUI)
  3. Controller for interaction between communication software and graphical user interface

Based on the input of the user in the configuration file, the GUI and partially also the controllers can be written automatically. In this matter, USOC generates appropriate functionalities within the controllers for individual GUI contents, which can then be adapted manually. Changes in the configuration file are detected, localized and the corresponding GUI structures and controller functionalities are regenerated. If these are manually written functionalities, they are recognized and not overwritten. USOC also brings pre-coded functions, such as communication via serial ports and/or the Iridium satellite network, as well as a three-dimensional visualization of GNSS data. For further details of these functions, I would like to refer to the GSoC2017 project of Valentin Starlinger, whose blog post can be reached here.

In this way, essential parts of a ground segment software can be created quickly and easily. Because of the wide diversity concerning the experiments in the space sector, people from all over the world can use USOC and add functionalities for their individual project to develop and extend the Universal Space Operations Center.

Development Process

USOC has been programmed in Java using the Netbeans IDE. Instead of Java Swing, which is the library used for the MIRKA2-RX ground segment software, JavaFX was used for the GUI as it provides advantages such as the separation of application logic and application design and the support of Cascading Style Sheets (CSS) for easy-to-handle and individual design adjustments.
JavaFX provides two different ways of creating GUI’s:

  1. The GUI can be created in just one single file using JavaFX. Application design and application logic are merged.
  2. With FXML JavaFX introduces an XML-based language that provides the structure in order to build a user interface separate from the application logic of the code. This structure can be coded manually or by using the GUI builder ‘Scene Builder’.

Due to the separation of application design and application logic, the code is easier to maintain. Therefore, a JavaFX FXML application has been preferred for this project. In addition, the hierarchical markup language FXML is very suitable for the generic approach.

At the beginning of the project, thoughts about a general, reasonable structure of the ground station were made. This was subsequently implemented. By introducing a Java Properties file as the configuration file with an associated syntax for specifying the GUI content, it was then possible to generically create first parts of the interface. This approach was continued until all desired functionalities were implemented in a generic manner.

Then a Java Properties comparison file was created and the Java class ConfigHandler was coded. The comparison file contains all the keywords and corresponding values ​​of the configuration file. In this way, changes can be detected. The ConfigHandler communicates with the configuration file. It controls the syntax of the entered values, detects and locates changes and forwards them to the GuiBuilder class. Afterwards the GuiBiulder was coded, which writes the FXML structures as well as the corresponding controllers automatically based on the user’s input.

The last step consisted of merging the progress of Valentin Starlingers project with mine.

User Manual

USOC Files

Since an overview of the code is relevant for the use of USOC, the most important files for the arrangement of the graphical user interface seen in the figure below are briefly presented in the following.

FXML Files

These files are all generated automatically based on the configuration file. Manual changes are not provided.

MainFrame.fxml

The MainFrame is the main window of the ground station. It is divided into the MainPanel, the LogPanel and, if specified in the configuration file, the StatePanel.

MainFrame with keyword statePanel set to true:
MainFrame with keyword statePanel set to false:

MainPanel.fxml

The MainPanel is the dynamic central window of the MainFrame. The diagrams are shown here. When configured in the configuration file, the three-dimensional visualization of GNSS data can be accessed via the „GNSS 3D View“ tab in the MainPanel.

LogPanel.fxml

The LogPanel is located on the right side of the MainFrame. Various communication paths are displayed here. Communication via the serial port and via the Iridium satellite network are already pre-coded. Individual tabs can be created via the configuration file.

StatePanel.fxml

The StatePanel is located on the left side of the MainFrame. Various parameters such as current modes can be displayed here.

iridiumpanel.fxml

The IridiumPanel.fxml file contains the FXML structure of the Iridium tab in the LogPanel.

serialpanel.fxml

The SerialPanel.fxml file contains the FXML structure of the Serial tab in the LogPanel.

Configuration Files

config.properties

The config.properties file contains all necessary information to set up the graphical user interface of the ground station.

configMod.properties

The configmod.properties file serves as a comparison file to detect changes within configuration file. It contains all keywords and associated values ​​of the config.properties file. During each program run, it is matched with the config.properties file and updated afterwards. Manual changes are not provided.

GUI Controller

These files are all generated automatically based on the configuration file. Manual changes are not provided. The generated dummy methods, which are marked by the comment ‚//Automatically generated method dummyMethod()‘, can be filled in manually. If the files are regenerated due to changes in the configuration file, the manually entered method contents are recognized and not overwritten.

MainPanelController.java

The MainPanelController is a class whose methods ensure the functionality of the MainPanel. The charts are declared and records are assigned.

LogPanelController.java

The LogPanelController provides the functionality of the LogPanel. Apart from pre-coded methods for the SerialLog and IridiumLog, a dummy method is written for each button of the individually designed tabs. These methods can be supplemented manually. Those method contents are recognized and will not be lost if the button label has been changed. Then the corresponding FXML structure and controller are regenerated.

StatePanelcontroller.java

The StatePanelController contains a method for setting and updating the labels in the StatePanel. A label is automatically set for every entered keyword.

GuiBuilder.java

The GuiBuilder.java class includes methods for regenerating individual FXML structures. Manually added method contents are recognized at specified points in order to ensure these when changes are made to corresponding GUI elements. The GuiBuilder includes the following methods:

  • setExperimentName():
    The title of the generated ground station is updated and resetted.
  • getGridPosition():
    In the MainPanel, as well as in the LogPanel and StatePanel, the elements of the content are filled in a two-column grid. For this purpose, the number of the element from the configuration file must be transformed into a two-dimensional array with line and column specification.
  • writeLicence():
    This Method writes the MIT licence into the automatically generated files depending on the target file type.
  • writeMethod():
    This method recognizes manually added method contents concerning additional tabs in the LogPanel or items of the StatePanel, to prevent their overwriting when the configuration file is changed.
  • mainFrameBuilder():
    The MainFrame.fxml file is regenerated according to the settings of the configuration file when the method is called.
  • mainPanelBuilder():
    The MainPanel.fxml file is regenerated according to the settings of the configuration file when the method is called.
  • mainPanelControlBuilder():
    The MainPanelController.java file is regenerated according to the settings of the configuration file when the method is called.
  • logPanelBuilder():
    The LogPanel.fxml file is regenerated according to the settings of the configuration file. The method builds the FXML structure generically in a TabPane with an optional number of additional tabs.
  • logPanelControlBuilder():
    The LogPanelController.java file is regenerated according to the settings of the configuration file when the method is called.
  • statePanelBuilder():
    The StatePanel.fxml file is regenerated according to the settings of the configuration file. The method builds the FXML structure of the generically in a ScrollPane with an optional number of vertically stacked segments.
  • statePanelControlBuilder():

    The StatePanelController.java file is regenerated according to the settings of the configuration file when the method is called.

    ConfigHandler.java

    The ConfigHandler.java class communicates with the configuration file config.properties. Changes and additions are recognized and corresponding methods of the GuiBuilder.java class are called. The ConfigHandler contains methods, which offer the possibility of recognizing and passing on individual changes, as well as controlling the syntax of the configuration file by calling the method rebuildGui(). The ConfigHandler includes the following methods:

    • countItems():
      The number of elements of the transmitted keyword is counted according to the USOC syntax in the associated .properties file and is returned as an integer.
    • getAllValues():
      All values ​​of the configuration file are read out and returned as a Java Properties structure.
    • updateConfigMod():
      The values ​​of the comparison file for detecting changes, configMod.properties, are overwritten with the current values ​​of the configuration file, config.properties. This method is performed after each program call.
    • valueMod():
      It is checked whether the passed keyword has been changed since the last compilation. For this purpose, the configuration file config.properties is compared to the comparison file configMod.properties.
    • experimentNameMod():
      It is checked whether the keyword experimentName has been changed in the configuration file since the last compilation. A corresponding boolean is returned.
    • mainPanelMod():
      It is checked whether changes to the configuration file have been made to the MainPanel since the last compilation. A corresponding boolean is returned.
    • logPanelMod():
      It is checked whether changes in the configuration file have been made to the LogPanel since the last compilation. A corresponding boolean is returned.
    • statePanelMod():
      It is checked whether changes in the configuration file have been made to the StatePanel since the last compilation. A corresponding boolean is returned.
    • fileMod():
      It is checked whether the configuration file has been changed at any point since the last compilation. A corresponding boolean is returned.
    • syntaxCheck():
      The syntax of the information in the configuration file is checked for accuracy. A corresponding boolean is returned.
    • rebuildGui():
      This method controls the syntax of the configuration file and executes the corresponding GuiBuilder methods depending on the change. Finally, the updateConfigMod()-method is called.

Configuration File

Settings

The following parameters determining the GUI content must be specified with the following syntax:

RESET

This option can be used to regenerate the entire GUI code. It is a mandatory setting that has to be specified. The expected input is the data type boolean (true, false). The following files will be updated if RESET is set to true:
FXML Files
– MainFrame.fxml
– MainPanel.fxml
– LogPanel.fxml
– StatePanel.fxml
Controller
– MainPanelController.java
– LogPanelController.java
– StatePanelController.java

statePanel

The StatePanel serves as a status display. Here, different modes of the experiment and/or other individual states can be displayed and monitored. To set the StatePanel, the keyword statePanel has to be set on true as it is shown below. It is a mandatory setting that has to be specified. USOC expects the data type boolean (true, false) as input.

GNSS3dView

Another pre-coded function of USOC is the three-dimensional visualization of GNSS (Global Navigation Satellite System) data. To set the „GNSS 3D View“ tab in the MainPanel, the keyword GNSS3dView has to be set on true as it is shown below. It is a mandatory setting that has to be specified. USOC expects the data type boolean (truefalse) as input.

experimentname

The experimentName – keyword sets the title of the ground station. It is a mandatory setting that has to be specified. Expected input is the data type String.

Chart Properties

About

Charts are defined by the three keywords chartTitle[], x[] and y[]. The square brackets include the diagram index, which is incremented starting with 1. The charts are arranged in rows in a two column grid pane in the following schema:

chartTitle[ ], x[ ], y[ ]

A chart can only be generated successfully if all three elements are specified in the configuration file with the matching index.

example

Chart properties in config.properties file:

FXML code generated by input in config.properties file:

Final representation of the chart in the graphical user interface:

Log Properties

about

The LogPanel is used to communicate with the experiment. Messages and data can be sent and received over various ways. The communication paths via the serial port and via the iridium satellite network are pre-coded and can be enabled in the configuration file. The different paths are available as tabs in the LogPanel. Individual tabs can be configured in the configuration file.

SerialPaneL

The SerialPanel provides the capability to connect to serial ports and send commands.

  

iridiumPanel

The IridiumPanel provides information about the received messages.

tabTitle[ ], textArea[ ], control[ ][ ]

Additional tabs can be customized individually. All control items are again arranged in rows in a two column grid pane in the following schema:

Mandatory inputs are the tab title and the setting whether a TextArea is needed. Afterwards control items can be added to the tab by using the control[][] keyword. The square brackets include the indices, which are incremented starting with 1. The first index refers to the number of tab and the second index to the control items of the respective tab.
Implemented so far are the following control items including the corresponding setting:

  1. Button:
    control[i][j]               =   button
    bText[i][j]              =   individual content
  2. Label:
    control[i][j]                =   label
    lText[i][j]               =   individual content
  3. Textfield:
    control[i][j]                =   textField
    promptText[i][j]    =   individual content

with j = {1,2,3,…} as number of control item in tab and i = {1,2,3,…} as number of additional tab.

Example

LogPanel properties in config.properties file:

FXML code generated by input in config.properties file:

Final representation of the LogPanel in the graphical user interface: 

 

State Properties

about

The StatePanel is specified by the statePanel – keyword in the config.properties file. The content is divided into segments, which are initialized by the keyword boxTitle[] and titled by the appropriate value. The contents of the segments are set by the keyword keyword[][]. The square brackets include the indices, which are incremented starting with 1. The first index refers to the number of segment and the second index to the content of the respective segment.

segmentTitle[ ], keyword[ ][ ]

example

StatePanel properties in config.properties file:

FXML code generated by input in config.properties file:

Final representation of the StatePanel in the graphical user interface:

Example

The following video shows the use of USOC with the example of ROACH – Robotic in-Orbit Analysis of Cover Hulls, a project by KSat e.V. (Small Satellite Student Society at the University of Stuttgart).

ROACH is the current REXUS project by KSat e.V.. REXUS/BEXUS (Rocket Experiments for University Students / Balloon Experiments for University Students) is an european program for student experiments on rockets and balloons. The program uses sounding rockets and balloons launched from Esrange in northern Sweden. It first took place in 2007 and has reached a total amount of more than 95 experiments until 2016 with 15 – 20 experiments launched every year. It is constantly growing and getting an integral and outstanding opportunity for students to gain experience in hands-on space projects.

The experiment ROACH is motivated by threats posed by space debris damages, micrometeoride impacts and structural fatigue of space structures. Space itself, with vacuum and thermal cycles, is a demanding environment for satellites and space stations. Thus, periodical monitoring of the outer hull of these spacecrafts is advisable.  Regular monitoring and small repairs allow a less conservative and more cost effective design approach for future space structures. Instead of EVAs or photo-optical inspections, small rovers, which travel on the surface and search for potential damages, are a fascinating new idea.
The ROACH rover utilises electro-adhesive tracks to move on a REXUS rocket. It will be equipped with sensors which examine the module structure. The rover itself will be secured with an umbilical to the module, which also supplies power and the communication link to the on-board computer. The goal of the ROACH project is to develop, build and fly this experiment.

An introduction video will be uploaded soon.

Future work

  • Further expand of the JUnit test scenarios
  • The StatePanelController still needs to be assigned
  • Introduction of a MenuBar and shifting some functions into this
  • Implementation of a Forward Error Correction (FEC)

Personal Information and Links

Personal Information:

Name:        Victor Hertel
E-Mail:      hertel@ksat-stuttgart.de

The following links lead to the GSoC GitHub repo, my commits and the USOC user manual:

GSoC GitHub repo: link
My commits: link
User Manual: (no link yet)

Schreibe einen Kommentar