TARS MK4 | High Power Rocketry Flight Computer

There's probably enough content here to write a few different articles (Stay tuned!), but for our first one we're going to focus on the creation of our high powered flight computer TARS MK4.

Who are we?

We're a team of about 100 undergraduate engineers from the University of Illinois at Urbana Champaign, and our mission is to be one of the first collegiate teams to design, build, and launch a two stage rocket 100km to the Kármán line. We still have a long way to go, but here's a snapshot into just one of our projects from last year. If you'd like to learn more about our organization the Illinois Space Society or our Spaceshot team checkout our website! https://www.illinoisspacesociety.org/

What's TARS MK4?

TARS MK4 is our premier 4th generation flight computer designed to compete in the 2023 Spaceport America Cup. It's capable of live radio telemetry, GPS tracking, autonomous state estimation, and controlling our rocket's apogee through an air brake mechanism that creates drag to slow down and reach a specific altitude for the competition.

There are quite a bit of parts that went into this project's bill of materials (BOM) so we've decided to link them all in the attached PDFs.

The first step is to connect all the components together with a schematic. We've included all three of our schematics down below if you'd like to read them in full. The image above is a snippet of our sensor suite.

We use KiCAD for all of our projects because it's one of the best free open source electrical design software suites available. If you're ever working with multiple people we've also included our internal guide for collaboratively working on KiCAD projects. We follow a strict set of guidelines to avoid file conflicts that can very easily appear with multiple editors. If you're new to GitHub we also have a GitHub guide down below as well.

• KiCAD Contributing Guide
• GitHub Guide

When designing a new system we often also make block diagrams to get a better understanding of the overall system with our favorite free diagramming tool draw.io.

MCU

When working with schematics we usually start by selecting a microcontroller and then designing around it. For our implementation we chose a Teensy 4.1 because it's Arduino compatible, extremely fast, and has a large set of I/O. We also have an ESP32-S3 and an ATmega328P as axuillary MCU for telemetry and power management.

Sensors

The next step is to decide what type of sensors to use. When choosing a sensor we highly recommend ensuring they have SPI or I2C. These are digital communication protocols and how the sensors can talk to the MCU. We choose to primarily use SPI because it usually has a faster polling rate than I2C. Another benefit of these protocols is that they're busses so they mostly can share the same set of wires helping make routing/assembly easier.

We use a combination of barometers, accelerometers, gyroscopes, and magnetometers to perform state estimation. Depending on your level of complexity you may want to choose multiple a low-g and high-g accelerometer to get better data throughout the regimes of flight.

However, if you're looking for simplicity we recommend the MS5611 barometer, BNO0855 9-DOF IMU, and MAX-M10S GPS. These three sensors should cover most of your basic sensing needs.

Voltage Regulators

To power TARS MK4 we use a 2S3P battery pack which means we have 2 batteries adding voltage in series and then 3 sets of them in parallel. We use standard Adafruit 3.7V 18650s which means our battery pack can range from 6V to 8.4V. Since we only needed at most 6V for our servo we decided to go for step down regulators for their relatively high efficiency.

If you're ever trying to design an embedded regulator we recommend checking out Texas Instruments' Webench Power Designer. It's a great tool for helping beginners easily design voltage regulators. If you're not looking to design your own we've also had great experiences with Pololu voltage regulators. We've used them as emergency backups in the past. It's always good to have at least one when designing embedded voltage regulators because if your design doesn't work you may be able to save the rest of it!

Radio

We opted to use a RFM96 with LoRa, because of it's exceptional range and low power usage. We do sacrifice a bit of our data rate, but we've been able to get about one packet per second which is perfect for our use case. We've ground tested to over 6 miles at -100 RSSI and up to ~30,000 feet with flights at -80 RSSI. (RSSI = Received Signal Strength Indicator. The greater the number the stronger the signal.)

In the future we're hoping to explore satellite transceivers and higher bandwidth radios for live video streaming.

Schematic Conclusion

That's it! Those are all the main components you need to think about when designing a flight computer. Of course there can be many more supporting components but those are the most important ones.

Also attached in this section are the complete TARS MK4 schematics.

After finishing the schematic the next step is to begin routing the printed circuit board (PCB) where you take the electrically defined connections from the schematic and physically map them out. Our boards were all two layer to help reduce costs. The red side is the front copper layer and the green side is back layer. The order of the boards is TELEM, FCB, PMB.

Everyone does it a bit differently but here's generally how we break down the process:

• Define your edge cuts (Board size).
• Place all your connectors (This usually defines how you interact with the board)
• Take special care to place and route your USB, RF, differential pairs, and high speed signals first
• When routing take note of pin assignments on chips that can be shifted to make routing easier

TARS MK4 Design Specifics

The layout for TARS MK4 is a bit unique because we decided to distribute it across three stacked PCBs. This allows us to get more board space for surface mounted devices (SMD), and allow for more people to simultaneously work on them with KiCAD. Here's the general overview of what each board does:

• TELEM (Top): Handles all things radio and communicates with our ground station
• FCB (Middle): Does all the sensor data logging and state estimation
• PMB (Bottom): Provides 3.3V, 5V, and 6V power for all of TARS from the batteries

(Note if you are planning to make multi-board design you will need to make separate KiCAD project files.)

With the routing finished this is the final product ready for assembly. During the routing process it's often helpful to check the 3D model frequently to verify alignment between connectors and other components. These renders were made with Blender, and for the final images we used Canva to add the stylized text and backgrounds. (Canva is a great graphic design tool for creating amazing graphics quickly.)

Once your design is finished it's time to send the PCB for manufacturing. There are quite a few options avaiable, but we've been using JLCPCB for over 6 years and they've been fantastic to work with in terms of turn around time and quality.

When we initially sent TARS MK4 for manufacturing we accidentally added a small global offset to the solder mask which meant the Ground (GND) net from the copper fill zone was exposed around each pad (As seen in the first microsope photo). Every time we soldered a pad if the solder slightly overflowed it would short it to GND. This would've been mostly acceptable however we had many fine pitched parts that we're difficult to solder so we needed to order a new set of boards. With only ~3 weeks till launch we placed the order with JLCPCB and they were able to get our boards within about a week.

(Full disclosure we are sponsored by JLCPCB. However, these are our genuine impressions of working with them.)

Soldering Tips

• Use Kapton tape to protect delicate plastic connectors and hold parts on the bottom side from falling off when heating the top
• Use lots of flux!
• When ordering stencils you can sometimes select a smaller custom stencil size for an added cost. This can actually make shipping cheaper and save you money on the overall cost! (Make sure to pick a size that can fit both sides of the PCB)
• Use thin tweezers or a knife to split solder bridges between pins (With lots of flux)

Photo: TARS MK4's first full stack and battery power up.

Before we got to turn it on we had to complete a board bring up process where we validated there aren't any hardware bugs. Our process is very similar to the fantastic guide linked below, but if we were to add one thing it's be our frequent use of debug pins. We always add test points to our power rails and communication busses at minimum. We also generally try and have test points for every pin on a chip to ensure none of it's adjacent pins are shorted. If you're feeling extra fancy you could add dedicated test points for connecting oscilloscope probes.

https://www.inspectar.com/post/bring-up-the-board

Once you have your board working it's time to start thinking about your software architecture. There are three main aspects of our flight software which is written in C++.

Finite State Machine (FSM)

The FSM is used to track global events during flight and transition the entire software system to different operating states. For example, during boost we data logging and state estimation are happening very frequently but when landing the system can go into a power saving mode where it doesn't need to acquire new data and only transmit a GPS signal every few seconds. The FSM is how you'd enable these functions.

Real Time Operating System (RTOS)

An RTOS is often used in applications where systems need to have a very strict timing such as in the aerospace, telecommunications, and automotive industry. The way an RTOS works is it divides individual functions into different threads where it can then activate or deactive them. This is of course a very simplied description of an RTOS. If you'd like to read more about ChibiOS which is the RTOS we used for TARS MK4. It seems to work well with Teensy4.1 and the Platformio framework that we flash code through VSCode. The great thing is that nearly everything is still compatible with the Arduino framework.

A sample of our a few of the threads include the following:

• GPS
• Sensor logging
• Telemetry
• State Estimation

State Estimation

The final aspect of our software is the state estimation that senses and predicts where the rocket is travels. This is used to control the air brake mechanism when targeting specific altitudes. We use a Kalman filter that's designed to take measurements over time and filter out inaccuracies such as sensor noise or supersonic pressure spikes and then use that refined state estimation to continuously predict where we're going in the future.

GitHub

Here's a link to our TARS Software GitHub repository where developed most of the code for this project.

• ISSUIUC/TARS-Software

Our telemetry thread in flight software sends data to our embedded LoRa radio transceivers which then beams it down to our grand station receiver where it's parsed and then displayed onto our custom ground station software running on the Electron Framework.It's built as a browser based application enabling it to easily be ran locally on a laptop or even hosted on a cloud webpage for people to view on their phones.

The night before and days leading up to a launch are crucial because it's where a majority of the internal avionics integration happens. The more we can integrated before the better, because we can reduce variability in the field and only focus on the things that we can only integrate right before launch like our pyrotechnics.

In the past we've had to use a single bench top power supply and manually set a current and voltage limit. However, with the advent of TARS MK4 we invested in these Adafruit USB LiIon/LiPoly charger - v1.2, and a USB charging hub.

The reason this is gets it's own section is because even though it was a small change it made an absolutely massive improvement in how we integrate and our efficiency during integrations.

When charging any battery never leave it unattended and always store them in a battery safe bag!

You've flown your flight computer now it's time to iterate upon your design and make it better! Engineering is a process defined by testing, analysis, and iteration. TARS MK4 wasn't the first flight computer we've ever built and it definitely won't be the last. The image above shows all the previous iterations of TARS that we've been refining for over 3 years.

Hopefully in a few months time we'll be ready to reveal our next generation flight computer called MIDAS MK1. We're aiming to shrink all of TARS into one board and add pyrotechnic circuitry to be able to initiate inflight events such as parachute recovery. Stay tuned!

Here are a few extra photos from our design process that we wanted to include to show a bit more into the behind the scenes of our documentation process. As a collegiate team every four years you'll have a completely fresh set of faces running the team. This means having proper documentation and onboarding processes is crucial to sustaining any long term momentum between student generations.

We wanted to give a quick thanks to our two largest avionics sponsors. Thank you JLCPCB for providing us the TARS MK4 PCBs, and thank you Molex for the incredible board to board connectors!