Introduction

The S.I.R.I.U.S. flight computer is the next generation of the N.E.B.U.L.A. flight computer. Designed for the 2020 IREC competition in New Mexico, S.I.R.I.U.S. has many similarities to N.E.B.U.L.A. from a functional standpoint but learning from last year’s challenges, the board has been physically redesigned to fit a smaller form-factor for easier testing. The board also has many features to make it far more user-friendly and more effective as a whole. Read on for those details.

Issues with N.E.B.U.L.A. and their solutions

From a operator standpoint, N.E.B.U.L.A. was missing some very useful (bordering on essential) features (again 20/20 hindsight). The biggest flaw I found in N.E.B.U.L.A. from a functional perspective was the requirement for external connections to use the MOLEX connectors. I really like these connectors and they were chosen because they are small locking connectors, but they clearly are overkill during testing. I was consistently crimping and fitting wires into the male end of the connector just to feed signals into the board. To resolve this issue, all incoming and outgoing signals and power now have 0.1″ (2.54mm) header pins right behind their respective connectors, allowing significantly easier hookups during testing and debugging. One specific example that comes to mind is the SWITCH Molex Connector. This SWITCH connector is in series with the battery’s connection to ground and is used to prevent continuity from the battery’s positive and negative terminals until an external switch (generally a key switch flush with the outside of the rocket) has continuity. I would always need a MOLEX connector with the two ports shorted for the board to work. At IREC, I just soldered them together with a really ugly and bare wire. Now, I have the ability to just put a 0.1″ jumper on a very user-friendly two-pin 0.1″ header. Furthermore, if I want to feed power into the board, I can just hook up some jumper cables to the headers instead of going through the MOLEX connectors.

Though not a huge inconvenience, I really wanted a way to isolate the GPS and XBee UART from the Teensy’s pins. On N.E.B.U.L.A., these pins went straight to the board and isolation was not possible. Now, in series with the UARTs (both RX and TX), are 0.1″ jumpers. This allows me to disconnect the GPS and XBee from the Teensy by removing the jumpers and I can strap and FTDI UART to USB device onto the now open male header pins–super easy.

Other minor issues I found with N.E.B.U.L.A. include no indicator leds, no user input, and little ability to test deployment channels. These issues are solved with a “kill three birds with one stone approach.” For starters, five LEDs and five momentary push buttons are on the S.I.R.I.U.S. board. One of the LEDs is connected though a resistor to 5V to indicate power is present in the board and the other four are connected to pins on the Teensy. The intended goal is for these LEDs to indicate the continuity status of the four deployment channels (see ElectricalXXX for more details). These LEDS are reconfigurable, however, as they are tied to Teensy pins. The buttons take care of user input and the ability to test deployment. Four of the buttons represent the four deployment channels and will be used for test-firing charges (see ElectricalXXX) and the last button is intended to send a test message over the XBee for testing communications. These buttons are configured as INPUT_PULLUP in the Arduino IDE and are reconfigurable.

Electrical

S.I.R.I.U.S. is an all-encompassing flight computer measuring altitude, acceleration, pitch, roll, yaw, magnetic fields, and GPS location with the ability to send this data over radio as well as save to an onboard MicroSD card. This flight computer features redundant altimeters (MS5607 and MPL3115A2) with a max measurable altitude of 120,000 feet, one high-g accelerometer (ADXL377), and a low-g accelerometer in a 9 Degree of Freedom IMU (LSM9DS1). For GPS tracking, the flight computer communicates over UART with the Adafruit Ultimate GPS Module with the ability to add an external antenna. Also using UART is the XBee Pro SX 900MHz transceiver, with a maximum LOS range of 60 miles (according to the datasheet). S.I.R.I.U.S. boasts four MOSFET deployment channels capable of handling 18V as well as two PWM outputs for servo operation (with the ability to use the regulated 5V output included in the board). Coinciding the four deployment channels are four LEDs that, by default, indicate continuity of charges using a voltage divider network connected to the analog inputs of the Teensy. These four LEDs are programmable to fit the user’s needs. The flight computer also has five buttons connected to the Teensy for user input. Buttons 1-4 default to a custom sequence for testing deployment channels 1-4, respectively, while the fifth button defaults to sending a test message over the XBee UART. The LSM9DS1 Inertial Measurement Unit (IMU) communicates over I2C to deliver acceleration readings up to 16g, angular rate readings up to 2000dps, and magnetic readings up to 16 gauss. Pitch, roll, and yaw will be determined using the readings from the IMU.

• (1) – Teensy 3.6 Microcontroller
• (1) – MS5607 Altimeter
• (1) – MPL3115A2 Altimeter
• (1) – ADXL377 200g Accelerometer
• (1) – LSM9DS1 16g Accelerometer, Gyroscope, Magnetometer
• (4) – A04320 Deployment MOSFETs
• (5) – Indicator LEDs
• (1) – TPS54527 Switching Voltage Regulator (5V)
• (1) – LT3080 LDO (3.3V)
• (1) – Adafruit Ultimate GPS
• (1) – XBee Pro SX or XBee SX 900MHz Transceiver

Goals for S.I.R.I.U.S.

One specific goal I have for S.I.R.I.U.S. is the ability to determine apogee. So far I have looked at altitude, acceleration, and a combination of both for apogee detection. Altimeters are challenging to use for apogee detection specifically because the rocket likely hits mach. In practice, one would constantly read the altimeter going up, and once it is going down for enough samples, you have reached apogee. I know little to nothing about fluid mechanics, but I know pressure is dramatically influenced near mach so the barometric altimeters used would be unreliable if not ineffective. Another approach for apogee detection is the integration of acceleration to find zero velocity. I am doubtful of this method because the two accelerometers on the board measure 16g and 200g, respectively. I am fairly certain the rocket experiences over 16g of acceleration, meaning the low-g accelerometer readings would “clip.” On the other end of the spectrum, I do not think the high-g accelerometer has a granular enough resolution for measuring lower g-forces.

The most simple approach I have looked at is detection of nose-over (when the rocket starts turning upside down). To detect nose-over it should be as simple as seeing when the vertical component of acceleration hits zero and another dimension increases. My hesitation from this method comes from the intense vibrations the rocket experiences. I do not want some vibrational “noise” to trick the accelerometer.

The method for apogee detection I am most interested in is the Kalman Filter. From Wikipedia, a Kalman Filter is “an algorithm that uses a series of measurements observed over time, containing statistical noise and other inaccuracies, and produces estimates of unknown variables that tend to be more accurate than those based on a single measurement alone.” In my head, the Kalman Filter takes a series of variables and makes predictions based on previous data. Then, the filter compares the next set of acquired data with the expected and carries on. The Kalman Filter is frequently used in vehicle guidance, specifically with aircraft and spacecraft (hence why I am trying to work with it).

Structures