A few weeks ago, we, three third-year computer science students (Alexander Halfweeg, Tycho van Heems  and  Jael Lopez), joined the Advanced control team in DARE. We will be working on a new version of the ground software for actively stabilised rockets.

The ground software needs a GUI and it also needs to be able to communicate with rockets before they are launched in order to read the state of both the rocket and the sensors.

Besides renewing the previous system, we will be working on creating a clear and well-structured architecture, which is important for when new members want to contribute or expand the system. Then it will be easier to understand what is going on. To make use of certain methods, while trying to achieve this, is very important and it is also a practice that all coders should take advantage of in any project.

Before recreating the functionalities of the previous ground software, all the members had multiple meetings to discuss not only the old features but also the new. The current team leader would like to have new visualisations in the program to clearly see what is going on with the sensors state estimation and the state machine status.

The current team had to do multiple things: First of all, we needed to create an actual GUI to show all the data on. Second, we had to learn how the communication protocol works. This protocol is standard in DARE and it is used for all communication between rockets and other hardware. Creating the GUI is a relatively simple task, so we assigned one person to create it while the other two were to do some research about the communication protocol and multithreading. Furthermore, a big problem in the designing of the software is to find a way to keep it responsive, while also making it receive input and send output at all times. The answer to this is multithreading. Therefore, we decided to split the software into three big parts, each with its own thread. One thread receives messages from the rocket, another sends messages to the rocket and the last observes the GUI. This way, the GUI stays responsive because it doesn’t have to wait for the input/output parts of the program. But even though, these three threads might be the biggest, there are still other threads that keep the application running. These are the threads that are made and destroyed multiple times during runtime, instead of launched at the start of the application and destroyed when the application is closed. These threads are made when the user sends a command, and this can happen multiple times per second and therefore, they are not handled by any of the big threads since they could freeze otherwise.

Thus, we work on the ground software for the team, and this is an application that communicates with the rocket and displays it in a GUI. We will create a new and well-structured application that is code wise easy to understand, even for outsiders, and will use various methods to prevent overloading the application and to keep a high functionality.

Authors: Alexander Halfweeg, Tycho van Heems  and  Jael Lopez