We are a student association located in Zurich called ARIS (Akademische Raumfahrt Initiative Schweiz – Academic Spaceflight Initiative Switzerland). We built our first rocket “Tell” back in 2017 and have grown considerably over the last couple of years. Each year a new team of motivated students from different universities across Switzerland comes together to improve upon our previous work and construct a more powerful rocket. The goal is to participate in the Spaceport America Cup, a student competition that gathers hundreds of rocket teams from all over the world.
Competition in Portugal
Sadly, this year’s competition in the United States was canceled, but we will participate in the newly established European rocketry competition in Portugal this October.
This year’s project is called “Euler” and our primary aim is to fly ARIS’ first supersonic rocket. The maximum expected acceleration is 14 g and we want to achieve an altitude of 30’000 feet or 9’144 meters as accurately as possible by utilizing a sophisticated altitude braking system.
Correspondingly, our flight computer has to manage a considerable number of tasks: we need reliable communication with the ground station, accurate state estimation, control of the braking mechanism, as well as logging, sensor readout, and battery management.
Logging used half of the available CPU time
Our avionics flight computer utilizes a STM32H7 Arm microprocessor and for the handling of different tasks we use FreeRTOS 10.2.1. After our maiden flight in June, during which we successfully validated our state estimation algorithm and the braking system, we wanted to improve our software further. However, it was necessary to first understand all details of our system. With around a dozen FreeRTOS tasks and numerous communication channels between them, it was quite complicated to understand what exactly happens at the lower level and which improvements we should prioritize. Our goal was to increase the frequency of the state estimation algorithm from 100 Hz to 1 kHz. In order to do that, we explored various profiling tools.
That is how we discovered Tracealyzer. As soon as we integrated it with our software and recorded the first trace, we immediately gained more insight than we had done in months. Our logging task used almost half of our processing power, and in another task that used 10% of the CPU time we were mistakenly calling a blocking SPI connection. We were able to figure this out in just a couple of hours thanks to the Tracealyzer software.
Our system was significantly improved by just using this single piece of information, and there were a lot of other small enhancements that we made with the help of Tracealyzer’s traces. These improvements have already allowed us to double our state estimation frequency!
We are currently working on redesigning the logging architecture and adding more features to our system. These tasks have been made vastly easier by Tracealyzer since we can evaluate the performance of the software after every change we make.
Lastly, we are planning to replicate our state machine in Tracealyzer and assess the performance of our system in each of the flight phases, thereby making sure that our software will behave as expected during upcoming flights.
By Jonas Binz, ARIS Electrical Hardware Engineer, and Nemanja Stojoski, ARIS Embedded Software Engineer