Swiss rocket team leverages visual trace diagnostics to smooth the trajectory of its autonomous rocket recovery system
We are a student team from ETH Zurich participating in the Swiss Space Initiative ARIS (Akademische Raumfahrt Initiative Schweiz). You might have already heard about us – last year we wrote about our experiences using Tracealyzer in building a sounding rocket. This year, our subteam of eight people tackled another challenge: Guided recovery of a rocket after separation at apogee, which means having the system autonomously recover from its highest point in flight to a predefined location. Although we were primarily aiming on building a technology demonstrator, next year’s teams will already integrate this system into a full-scale rocket!
Our autonomous recovery system consists of a rocket-shaped tube of about 6 feet (or 1.8m) and a ram-air parachute with an area of 135 square feet (approximately 13m2). We guide this parachute by pulling at its steering lines, deflecting the canopy and making turns that way. Guidance happens autonomously, i.e., the trajectory is computed online, taking estimated wind speeds, the current position and the target position into account.
How we leveraged the visual trace diagnostics functionality of Tracealyzer
An overview of our system
The main microcontroller of our guided rocket recovery system is an STM32F4 Arm-based microcontroller running FreeRTOS 10.3.11. We also have two microcontroller-equipped sensor boards inside the canopy, with their own small batteries and WiFi modules2.
The main microcontroller runs a variety of tasks: sampling a bunch of sensors over I2C, logging to the SD card memory, communicating with our ground station via a LoRa shield, and also running state estimation, guidance and the controllers, including instructing the brushless DC motor controller on how much line should be pulled.
From last year’s teams we already heard about Tracealyzer and how this debugging tool had helped them to spot and shave considerable time off certain logging tasks. So we were eager to use the tool to look at how our RTOS design worked out. Of the many things we learned these two stand out:
Control Loop Performance
Control of parachute-payload systems depends on having a good model that accurately captures the relevant aerodynamic effects, the dynamics between parachute and payload, and the influence of wind. Our control engineers designed an extensive model and state estimation in MATLAB, which we transferred onto our microcontroller by generating C code from it. We aimed at a frequency of 20 Hz for our control loop, but initially, we were far from that. Our state estimation used up all the CPU power we had, resulting in about 4–5 Hz of sampling frequency. This had to be improved!
First, we (embarrassingly) noticed that floating-point unit support wasn’t activated in our FreeRTOS configuration; activating it immediately boosted the performance. After that, using Tracealyzer allowed us to do “rapid prototyping” on the generated code to quantify what exact effect different generation options had on the code’s performance. In the end, we could narrow down the tradeoff between RAM usage and performance to a configuration that was optimal for our purposes, and achieve our desired sampling rate.
Delays in the motor controller
Another thing we noticed was that after putting all the components together in the final assembly, our motors weren’t running as quickly as before. This was definitely strange and unintended. But looking at the Trace View in Tracealyzer immediately revealed what the issue was: The tail end of our control chain was sending the reference position to an external motor controller over UART. Increased noise from other components made the STM32F4 unable to recognize the response and it was timing out on the UART transmission, delaying our control loop! With this knowledge, we lowered the timeout such that all deadlines could still be met, and also fixed the noise issues by altering our electrical design.
Tracealyzer showed us that our control loop task was running very unevenly (left). After making some changes, we could confirm that it was steady (right).
Swiss Army steps in to test the prototype
This spring, we’ve been on a testing campaign, where we drop the system from a helicopter at heights of 800 to 1500 m above ground in cooperation with the Swiss Armed Forces. You can see a fish-eye view of our system flying in the Swiss Alps above.
We were all very excited to see our system in action, which also has come to life thanks to the help of Percepio’s Tracealyzer, so a special thank you goes out to Percepio for their continued sponsorship of ARIS and giving us such valuable insight into the performance of our RTOS!
Lukas Vogel, Software & Electronics Engineer at ARIS
Dieser Artikel ist auch in Deutsch verfügbar (PDF), via Swiss magazine Polyscope.
[1] Already an upgrade on last year’s rocket team using 10.2.1 🙂
[2] We used ESP32 microcontrollers for this purpose. We’re especially excited by Percepio’s announcement that Tracealyzer support is coming for ESP32, something future ARIS projects will be able to benefit from.