The ACT has used the same electronics and the same software in all the test launches so far. The first two times the software did what it was supposed to do, but, as we explained in the previous blogpost, due to the physical configuration of the rocket, the roll could not be controlled. On the last launch in May, the rocket did not use canards anymore, but ailerons, little steerable parts at the end of the fins.

Unfortunately, this time, the software crashed. This led to the fins not steering and eventually the parachute not deploying.

Since the software crashed before the take-off, there are no flight data, and so it cannot be verified if this configuration with ailerons works or not. Because of this, the ACT is planning to do the same launch again in September. This time, hopefully, without a crash and with useful data about the rocket performance. To prevent a crash due to the software again, the ACT has decided to throw the old software out the window and start again. The rest of this post will talk about this decision and the plans for the new software.

Due to the fact that the software crashed it is clear that there is something wrong with the software. The fact that we cannot find out how and why it crashed highlights a bigger problem than one bug: nothing that is happening in the software is logged. All the measurement data of the sensors and some derivates of that are logged. We have no idea however what state the software was in, or even around what time it actually stopped working.

Besides this, the software has grown unnecessarily complex for something that is essentially a pretty easy job. It was also almost completely written by one team member that left the team a year ago. He was still active within DARE, so when we could not figure something out, we could always ask him for help. Due to the size and complexity of the project, however, no one wanted to work on it. So, nothing changed, and we kept using the same software. Now, that we have seen that there was a bug, the only logical choice was to start over.

This time we will make sure everyone works and likes working on the project. We recruited two more Computer Science and Engineering students to help out with the quality of the software. Together with the current two CSE students, they bring a lot of knowledge to the team about how to keep software projects organised.

The plan for this time is to make the software running on the flight computer a state machine. It is essentially the same state machine as the SRP [Maybe a link to SRP] software is running. On power-up, the program checks it’s systems. Checks if there is an SD card on the board, checks if there is an SD card in the black-box and checks if the Xsens is attached. If it is all present, the software continues to the next state and from there depending on RBF-pin (Remove before flight) and breakwire insertions and removals end up in the flight state. In this state, the main flight loop is run. This loop continuously reads the sensor output, makes a state estimation based on that, determines what action to take, take that action and then checks if the rocket is at apogee. The loop will stop, obviously, when the apogee detection determines the rocket is at apogee. The state machine will then advance to the parachute deployment state and deploy the parachute.

For both the state machine and the flight loop there are nice graphs. This way, new team members can quickly grasp the broad outline of the software. We will use doxygen to generate documentation, which also forces everyone to document his functions. This will help everyone to keep a good understanding of what is happening, and also ease the process of explaining the software to new members. Lastly, the software will even be tested this time using cmocka.

With this new project setup, the team is confident it will prevent another crash. Now we only need someone to build a rocket for us…