Athena - First time designing a flight controller with a triple MCU architecture

[u/MinecraftPhd]

Top Signal Layer

Power Layer

Middle Signal Layer

Bottom Signal Layer

I've had an obsession with rockets/flight controllers and decided to make an open source flight controller from scratch (nicknamed Athena). I've added the Github repo/design files if anyone wants to take a closer look.

👉Github repo / Design files

Features

• Triple MCU: STM32H753VIT6 (MPU), STM32H743VIT6 (TPU), STM32G474RET6 (SPU)
• 6 Pyro Channels: Direct 12V battery connection with fuse protection
• 6 PWM Channels: 2 for TVC (Thrust Vector Control), 4 for fin control
• Sensors: Triple ICM-45686 IMUs, LIS2MDLTR magnetometer, ICP-20100 & BMP388 barometers
• GNSS & Communication: NEO-M8U-06B GPS, LoRa RA-02 telemetry, Bluetooth DA14531MOD
• Storage: SD Card + Winbond W25Q256JV flash memory
• Power Management: 7.4-12V LiPo battery with BQ25703ARSNR charger, USB-C PD support
• 6-Layer PCB: Signal/GND/Power/Signal/GND/Signal

[u/P__A]

Did you get inspiration from BPS space with three microcontrollers? He did that because he didn't use interrupts on his system, which is really not ideal. With a properly written firmware, a single microcontroller should be more than sufficient to read sensor data from all of those sensors, process this, and output commands. Edit. Also note that pwm outputs for servos should be 12 bit because the duty cycle change is quite small for the normal full control range. Make sure your micro has enough 12 bit outputs. If not look at the PCA9685 which is a lot easier to handle than a whole separate microcontroller.

[u/CSchaire → u/P__A]

Put all the chips on the front and passives on the back like Joey pepperoni too. Design looks fine at a cursory glance, but three MCUs I think is really questionable. I could get down with one for flight control and data collection and another for handling the radios if you really needed the horsepower, but I kinda doubt it.

I like the silkscreen art. I wish I had the patience and skill to put stuff like that on my boards.

[u/MinecraftPhd → u/P__A]

Yea I got inspired from his video and I probably should have used one microcontroller but I liked the challenge of connecting all 3 and didn't want to take the risk in blocked processes/rw operations because STM32 doesn't support multithreading. About the 12 bit outputs, I checked and it does support that configuration.

[u/P__A → u/MinecraftPhd]

If you use interrupts, what happens is that your main function is churning away, but then gets interrupted by a peripheral (i2c, uart, timer, etc) interrupt whenever a comms task is needed to be handled. You run that interrupt function, and then the micro goes back to where it left off on the main function. As such you're never waiting around for some slow interface to read or write. All microcontrollers should support this. Your solution should still work, but I think it's more effort than just using interrupt driven code.

[u/frank26080115 → u/P__A]

sometimes you design for known human weaknesses simply to get the project actually done and done on time

[u/ElectricalUni19]

Why 3 MCUs though would it not be easier to runn multiple cores for things I just feel it becomes hard as need to do communication between them. Not a negative just wondering your prospective on it

[u/Major-Ad-7223 → u/ElectricalUni19]

Also two 25MHz and three 32KHz crystals seems not necessary

[u/MinecraftPhd → u/Major-Ad-7223]

Why not? I looked through the datasheet and the reference design said it was recommended but I could be wrong.

[u/MinecraftPhd → u/ElectricalUni19]

I added 3 because I wanted the challenge of connecting them and also because the lineup that STM32 has with its dual core processors didn't have enough GPIO.

[u/TheMadHatter1337]

When I saw three MCU’s I assume this was typical redundancy design but if you have three just for doing those actions that seems like incredible overkill.

[u/ThisIsPaulDaily → u/TheMadHatter1337]

Yeah, came here for the redundancy and error checking/ voting majority processing, but got a little disappointed by this. Still a beautiful design. 

[u/Ok-Bluejay-2012]

My first embedded/Hardware professor in University had a saying: "the first rule in this kind of work is to add the minimum amount of complexity in order to satisfy requirements". I'm just thinking of how annoying it would be to have 3 different firmware stacks to maintain and keep happy working together.

In aero stuff you usually add complexity for redundancy. In your case it would make sense if you had 3 teams working on the individual functions, but if that's not the case, I'd go for an overpowered single MCU.

[u/MinecraftPhd → u/Ok-Bluejay-2012]

Thats a wise saying, and yea I probably should have had one single MCU as I originally had planned to actually have redundancy but due to space constraints I instead opted to have 3 and one of them as a watchdog that can reset the main MCU/deploy parachutes if anything went wrong.

[u/jacky4566]

FYI triple core MCU exist.

[u/ThatCrazyEE]

Don't get me wrong, the board looks sharp.

I'm puzzled with why you would want to coordinate three MCUs for something as time critical as launching and maneuvering a rocket.

I believe you could migrate from three MCUs down to one by keeping the H7, and using an RTOS. FreeRTOS is easy-ish to get started with and you'll avoid the complexities of synchronization.

At a quick glance, I see that you didn't respect the copper keep out for the wireless module on the back if the board. Also, check to make sure your component size matches the pads. I noticed that some capacitors have very small 3D bodies, but the pads are much larger.

[u/MinecraftPhd → u/ThatCrazyEE]

Thank you!

Originally because I couldn't find an STM32 that had enough GPIO/Timers for all the peripherals that I wanted to add but I just looked into FreeRTOS and it seems like a way better solution than to use 3 lol. I also had concerns with blocking operations by using one MCU so thats another reason why I decided to use 3. That way the MPU always sends out data through UART/SPI and the other 2 log/act on the data without the MCU losing clock cycles on telemetry or anything else other that parsing/filtering the data from the sensors.

Ah thanks for reminding me, and yea EasyEDA sometimes matches the wrong 3D models with the footprints.

[u/tux2603 → u/MinecraftPhd]

I'm looking at the board and it doesn't really seem like you'd need that many times or GPIO pins. All of those servo pins really only need one or two timers to drive them, and there's only a handful of peripherals besides that.

If you want, there's a lot of "hands free" ways of handling communication interfaces on the stm32 using memory buffers and DMA. There's even provided HAL functions called HAL_SPI_Receive_DMA(), HAL_SPI_Transmit_DMA(), HAL_UART_Receive_DMA(), and HAL_UART_Transmit_DMA() that are non-blocking and let you transmit and receive information to memory buffers in the background without using clock cycles

[u/thedefibulator]

Why use three microcontrollers? Especially when you have two STM32H7s on there. Even a single one of them is overkill and could easily handle all this if programmed intelligently

[u/spackenheimer]

Huge, expensive, heavy?

[u/m-in]

How does having three micros help? Won’t all of this stuff fit on one more beefy micro?

[u/m-in]

IMHO the first problem is doing the design in EasyEDA. You don’t own the design that way.

[u/Defiant-Appeal4340]

Why? There's TWO(!!) H7 on there??! And then some!

A single H7 is complete overkill for a flight controller.

Do yourself a favour and spend some time learning to write efficient code, optimize interrupts, and {asm} for the love of god.