Whats new

I’ve finally managed to finish the pcb assembly of the revision 0.3 of the flight computer ! All sensor are working, pyro channels and pyro detection are also ready to be used.

It’s very pleasing to see this project taking the right way and starting to look like more a finished build rather than a mess of trials and errors !

The radio is working this time at 6dBm, and with some new inductances for the pi filter. The one that I used before were not correctly tunned in terms of inductance values for my needs.

I’ve also reimplemented some of the previous kalman filters for the IMU data filtering (pitch and roll angles, plus the vertical acceleration).

The previous flight computer designed used of the shelf MPU6050 and BMP280 modules which were far less precise than the LSM6DSO32TR and the BMP581. This time with the new sensor the readings are better and thus the estimated state too.

The STM32 STM32F401CCU6 used in the flight computer integrate an FPU (floating point unit) which in conjection with the arm_math.h librairy really streamline and speed up the calculation of matrix of floats.

The firmware is also starting to look like something that can be correctly tested and used without the risk of a complete edge case crash mid flight. All core features are organised as services which exposes API for other services and the main loop to use.

Timing of tasks

Timers interrupt are used for regular task scheduling but I think that learning to use FreeRTOS might be the next step. It seems that what scare the most people of the embeded world is the syntax, higher abstraction, the need to better organise the code structure and the concept of shared ressources via semaphores and mutexes.

As it is my main job to work with such topic, it might be ok to take some time learning how to use this tools properly to acheive better control over the timing and precedence of tasks in the system.

Previous challenges

GNSS

I’ve tried to use the UBLOX MAX M10s using UBX proprieraty protocol, without sucess so far. I did not found a way to include a lib to parse NMEA either (which right now writing this lines I think I figured out), so I decided to stop giving time and efforts on this subject for now. It did payoff as I found myself way more confortable writing code for other parts of the firmware, such as interrupt handling and data acquisition for the other sensors.

SD / Logger

The SD Card was easy to use with the FATFS lib, also not that simple to integrate into an existing struct oriented code base (every service has a main struct instance carrying parameters and service wide ressources and variables).

The data format used for the telemetry is reused for the SD logging, wrapped into some delimiters to define start of a new flight log, so that every flight is logged into a single file.

The file is then parsed using a python class reading the file as chunk by chunk in memory insted of the whole file to accomodate large sizes.

What’s next

After some testing and update of the firmware around security features like the ARM header and the state machine, I will conduct tests including pyro one’s to validate basic features good working condition.

Then I’ll proceed to do what I like to call “drone assited testing”, which is acheive by strapping the flight computer to a DJI drone and making it experienced different flight trajectories while recording the data.

The later can be used afterward to better tune the filters and iterate against the state machine algorythm and be prepared for the big day.

V

• Rocket
• Pcb
• Devlog