A guided rocket needs a brain. On the model scale, the flight computer has onboard all of the necessary sensors for data collection and guidance, power supply for the motors in the TVC gimbal, and a processor that directs it all.

While commercially-available flight controllers for drones exist, they lack the programmability and specific functionality that TVC necessitates. You may also find model rocket flight computers on many retailors’ websites, but these usually refer to dual-deployment systems (computers that monitor altitude and pull two separate chutes at different heights, allowing for a more precise decent), or telemetry/data logging systems. As far as I know, there do not exist any commercial options for TVC flight computers. The development of such a device is therefore an unavoidable part of any guided rocket project. Today, we will dive into the design and construction process of just such a TVC-capable flight computer.

Basic Design

Sensors

The inertial measurement unit is one of the most critical components of any flight computer, as it allows it to know which way the vehicle is oriented in space. The IMU is usually not one, but a suite of sensors. In the datasheet of all IMUs, you will see a descriptor like “3DoF”, “6DoF”, or “9DoF”. DoF stands for degrees of freedom, but do not be confused: this has nothing to do with the range of the sensor. A 3DoF IMU has one type of sensor on each axis (one gyroscope each on X, Y, and Z, for example); a 6DoF IMU has two types, usually an accelerometer and gyroscope on each axis; and a 9DoF has accelerometers, gyros, and magnetometers. 6DoF will suffice for our purposes, with the three gyroscopes being particularly important.

I mentioned before that the gyroscopes are particularly important. This is because we do not actually use accelerometers to gather orientation data. Accelerometers find pitch and roll by measuring the differing effects of gravity on each axis (when the sensor is not parallel, each axis will experience different vertical components of the gravitational force). This requires them to be calibrated to g, the gravitational field strength at the surface. However, when a rocket launches, it experiences brief but massive amounts of acceleration, completely throwing off the accelerometer during the most crucial moments of guidance. While a complimentary filter or even a Kalman filter may be used to remedy this, it is usually simplest to simply leave out the accelerometer readings. Of course, an accelerometer is still required for detecting liftoff and other inertial cues that trigger flight events, so make sure your IMU is at least 6DoF.

Microcontrollers

The microcontroller is a self contained computer in its own right, with a processor, RAM, onboard ROM for your programs, analog-to-digital converters, and support for communication protocols such as I2C and SPI. It really is very difficult to go wrong here: despite what you may think, TVC does not actually require that much computing power. Any chip/board with capabilities equivalent to that of an Arduino Uno should roughly suffice, so long as they are compact enough and support basic features such as I2C and SPI communication (protocols that allow you to interface with your sensors). My preferred microcontroller in development board form is the Teensy 3.5, as it has a built in micro SD card reader, an ample selection of GPIO pins, a compact footprint, and massively overkill computing power. For those looking to build an SMD style board, a common choice is the chip used on the Teensy 3.2, the MK20DX256VLH7 (rolls off the tongue, does it not?).

Data Logging

As I’ve mentioned, its highly encouraged to have somewhere on your flight computer where data from sensors can be stored so that they may be analyzed after the fact, helping you diagnose a failure, determine performance, compete with your friends over maximum altitude reached. Some of the new-fangled microcontrollers have tremendous amounts of onboard flash memory, which can be written to even after program upload; this could remove the need for additional storage (flash is non-volatile, meaning data is not wiped in the case of a power loss). Microcontrollers like the Teensy 3.5 also have onboard micro SD readers, a more convenient method of data logging. Note however that an SD card requires a physical connection, and in the case that it is disconnected by a violent jolt during liftoff, your data may be lost. Many use them in conjunction with external flash memory chips, to provide a solid-state failsafe in case of “rapid unplanned disassembly”. If you are using a microcontroller like the Nano, without an onboard reader, you can simply install an external breakout board for the SD card.

Power Supply & Pyros

The power supply for the flight computer, while it does not sound as flashy as the other components, is certainly not trivial. Servo motors, of which there must be two in the TVC gimbal (one for each axis of actuation), can draw upwards of 1A of current each depending on the brand. Since they run off ~5V, they usually cannot be powered directly off of the LiPo, which comes in multiples of 3.7V. The power supply of the flight computer, then, has to be able to directly supply the current for at least two servos. There are two primary methods of regulating voltage down: a linear regulator, or a buck converter. The former is simple to design, requiring only two capacitors in its circuit, but dissipates the excess power as heat, potentially creating thermal issues; the latter is far more efficient, but also more complex to design. While buck converters are usually the recommended choice, I’ve used linear regulators in my previous designs without any issue.

Flight computers can also have pyro channels, outputs that can briefly unload a massive amount of current into a pyrotechnic ignitor to ignite rocket engines or ejection charges (small amounts of black powder intended to blow out the nose cone and deploy the parachute). I have never included such circuitry in my computers, as I have no way of acquiring black powder for ejection charges and have to resort to alternative ejection methods. However, if you can acquire an ejection charge, pyrotechnic ejection is usually more mass efficient and reliable. Pyro circuits are usually driven by MOSFETs, a type of transistor that can switch large amounts of current quickly. Designs can be found online, but do be careful: an unreliable pyro channel could be a potential fire-starter (well, a fire-starter in the wrong place; these circuits are by definition fire-starters).

My Iterations:

Throughout my attempts to get one working, I’ve pieced together quite a few flight computers, of varying degrees of functionality.

My first attempt was a prototype on breadboard, using an Arduino Uno. This was an extremely primitive mockup, and did not even include a power supply for servos. I mainly used this contraption to learn the basics of the Arduino environment and how to interface with sensors, as well as to test some early versions of the guidance code.

My next flight computer, the first to be soldered together, has now been stripped for parts (here, it is missing the terminal blocks, and all of its wires). Its current state notwithstanding, it always looked as if it had just been stripped for parts. I essentially plucked components from the breadboard prototype, and transplanted them onto crummy perfboard. As I had just gotten into hobby electronics, the solder joints were… “artistic”, and the board overall resembled a product of malicious kitbashing. Despite being somewhat functional, it was evident that this iteration had no chance of flying.

The next model was far more polished. Still composed of the same components, (a Teensy 3.5 for the MCU, an MPU-6050 as the IMU, and a BMP 280 for the barometer), there was an overall improvement in construction quality. The design was slightly less haphazardly slapped together, and consequently, this board was very likely flightworthy. It was, however, underpowered: I fell into the trap of impatiently building the board around components I had on hand, one of which being 3.7V LiPo batteries. To power the 5V servos, I therefore had to use a boost converter to step up the voltage, limiting the maximum current to 1A as a result of the constraints of this component. While this never significantly impacted performance (servos should not draw their maximum rated current unless they are near stalling), the low current ceiling did not offer much peace of mind.

This next iteration flew. Similar to the previous iteration in design (although now employing a high-current low-dropout linear regulator to drop a 7.4V 2S LiPo battery to 5V), this board was special in that it was the first to be built around a custom PCB. While it did present a very low-risk introduction to PCB design for me, using through-hole (THT) mounted development boards such that I had only to connect them together as the previous models did, the clean construction and reliability of the PCB made it a step forward. This version was well-balanced in its capabilities, featuring a BNO055 IMU, a flash memory chip, and GPIO pins that supported I2C, SPI, and UART comms. We mustn’t forget the most important components, of course, the RGB LED and the buzzer that allow it to beep and light up.

The boards I am currently working on detract significantly from their predecessors in appearance. This is because this iteration uses SMD technology, mounting the ICs and passive components directly to the PCB. Since all the contents previously on pre-assembled breakout boards now have to be incorporated into my design, the production of this board proved far more difficult, but also significantly more rewarding. The Horizon flight computer has a massive amount of GPIO pins, an MK20DX256 processor, a BMI088 IMU, an MS5611 barometer, a micro SD card reader and a flash memory chip, as well as an LED and buzzer. The nature of SMD technology greatly reduces the footprint of this design, making it suitable for my next, compacted rocket design. I will likely be making a dedicated post to the development of the Horizon board.

If you made it this far, thank you! I hope the information presented and the development process shared here were of some use to your own projects.