Team 4 Project Technical Report for the 2021 LASC

Raphael Alves Hailer

School of Mechanical Engineering, email: rapha.hailer@gmail.com
Ronaldo Yeung
School of Mechanical Engineering, email: r176987@dac.unicamp.br
Lucca Panice Pedro
School of Mechanical Engineering, email: l182799@dac.unicamp.br
Paulo Yoshio Kuga
School of Mechanical Engineering, email: p204451@dac.unicamp.br
Rafael Arfux Maluf
School of Mechanical Engineering, email: r243364@dac.unicamp.br
Josué Rodrigues de Lima Brito
School of Mechanical Engineering, email: j175446@dac.unicamp.br
Luma Antunes De Oliveira
School of Mechanical Engineering, email: l240601@dac.unicamp.br
Davi De Oliveira Camurça
School of Mechanical Engineering, email: d243225@dac.unicamp.br
Ana Carolina de Araujo dos Santos
School of Electrical Engineering, email: acarolarauj@gmail.com
André Vila Nova Wagner da Costa
Institute of Computing, email: a213081@dac.unicamp.br
Gustavo de Souza dos Reis
Institute of Computing Engineering, email: g217425@dac.unicamp.br
Maurı́cio Santana Silva Guimarães
School of Mechanical Engineering, email: m247296@dac.unicamp.br
Rafael Augusto Braga Cota
1
School of Mechanical Engineering, email: r243366@dac.unicamp.br

October 27, 2021

1
The team would like thank Ronaldo Yeung and former members of Antares Caio Henrique Rufino and Lucas da Silva
Perissinotto during project Aurora.
Contents

1 Introduction 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Aurora’s Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Project planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 System Architecture Overview 4

2.1 Overview of The Integrated System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Propulsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Propellant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Experimental Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Fuselage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Bulkheads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Nose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.4 Fins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.5 External camera support and rail guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.6 Tail Cone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.7 Avionics Bay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.8 Payload Bay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Recovery Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2 Parachute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3 Ejection charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Avionics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.3 Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.4 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Mission Concept of Operations Overview 25

3.1 Assembly phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Pre-Launch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Ignition phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Lift-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Ballistic flight apogee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Rocket Landing Decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Conclusion and Lessons Learned 29

A Weights, Measures and Performance Data 30

B Hazard Analysis 34

C Risk Assessment Appendix 36

D Engineering Drawings Appendix 40
D.0.1 Avionics Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
D.0.2 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.0.3 Fins Bay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
D.0.4 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.0.5 Engine: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.0.6 Other parts: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
List of Tables

2.1 Parameters used in the parachute design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Avionics requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 ESP32 specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 BMP280 specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 NEO6MV2 specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 E32-915T30D specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Payolad specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

A.1 Flight simulation data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.2 Components mass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

C.1 Risk Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

List of Figures

1.1 Aurora’s Project Organization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 project methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Detailed view on the subsystems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Engine lids comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Hyperion’s nozzle threaded to the combustion chamber . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Ablative test Specimen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Ablative Material Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Engine Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Hyperion I machined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Thrust Plate Stress Simulation Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.9 CFD simulation on Aurora’s body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10 Avionics subsystem assembled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.11 Recovery subsystem components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.12 Inscribed polygon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.13 Crimson Powder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.14 Activation circuits (in green) and reading circuits (in orange) of the ignitor. . . . . . . . . . . . . . . . 17
2.15 Another view of the ignitor status reading circuit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.16 Ignitor status reading circuit - Open ignitor case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.17 Circuit for reading the status of the ignitor - Case of the ignitor present. . . . . . . . . . . . . . . . . . 18
2.18 Circuit for reading the status of the ignitor - Case of the active ignitor. . . . . . . . . . . . . . . . . . 19
2.19 Diagram of flight states used in the program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.20 Time graph of vertical speed during the flight of an simulation. . . . . . . . . . . . . . . . . . . . . . . 22
2.21 UML diagram of components and its interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Assembly phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Pre-launch phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 transport phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Ignition phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Lift-off Propulsive-flight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Ballistic flight and apogee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Rocket Landing Decommissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A.1 Estimated Thrust x time curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

A.2 Engine characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3 Open Rocket simulation settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4 Open Rocket simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.5 Open Rocket final diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

D.1 Avionics circuit board tower. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

D.2 Avionics spider connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
D.3 Avionics top bulkhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
D.4 Circuit board vertical support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
D.5 Lower avionics bulkhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
D.6 Mid avionics bulkhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
D.7 Payload Bulkhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
D.8 Symmetrical airfoil fin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
D.9 Fins support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
D.10 Fins support close up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
D.11 Parachute Bulkhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
D.12 Hyperion’s combustion chamber. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
D.13 Hyperion’s nozzle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
D.14 Hyperion’s Thrust Plate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
D.15 Aurora’s fiberglass von kárman nose cone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
D.16 Aurora’s tail cone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
D.17 Aurora’s tail cone locking ring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
D.18 Aurora’s external camera support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
D.19 Aurora’s airfoil rail guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Abstract

Aurora is Antares Aerospace Design Team’s launch vehicle; designed to be presented in the Latin America Space
Challenge 2021 online edition. This rocket will be powered by Hyperion motor, the team’s original designed motor.
Antares will attempt to fly Aurora to an apogee of 1000 meters while carrying a 0.800 kg scientific payload, consisting
of a camera, an avionics subsystem to support it and bring back the recordings to Antares ground station and a
collection of sensors. The fuselage project consists of a carbon fiber body, with a fiberglass section for avionics
designed to transmit data to the ground station, together with 3D printed fins, nose cone and a truncated cone for the
rear end, to improve the rocket’s aerodynamic. In order to recover the rocket, the avionics team at Antares developed
a system that will detect the right moment to send an electrical current to a NiCr wire, by the time of the apogee,
that will ignite a crimson powder package, which will expel the nose and pull with it an octogonal shaped parachute
to safely recover the rocket.

1
Chapter 1

Introduction

This chapter will register all the characteristics of Aurora’s project and expose how the team worked on the project.

1.1 Motivation
1.1.1 Aurora’s Name
After a brief meeting the team made a brainstorming session to discuss the project’s name. The winning name was
Aurora. The name means a new beginning , and that’s exactly what project Aurora represents for Antares, as the
team is pursuing higher apogees and most of the team’s old members have left, since our last rocket project, Anhangá.

1.2 Objectives
The team’s objective with mission Aurora is to build an original fully functional model rocket with expected apogee of
1000 meters. In addition, Antares developed a scientific payload to accompany the rocket in this mission and intends
to acquire data during flight.

1.3 Requirements
The team defined a series of requirements to develop the Aurora rocket, in which are: design a functional model rocket
that to reach an apogee of 1000 meters, develop a safe recovery system and design the rocket to carry a scientific
payload of at least 0.8 kg.

1.4 Subsystems
Right below, a diagram of all the project subsystems is shown.

Figure 1.1: Aurora’s Project Organization.

1.5 Project planning

The first need that the team saw was a design methodology. The simple philosophy of projects was adopted, demon-
strated in Fig. 1.2.

2
 Figure 1.2: project methodology.

This methodology is extremely useful to know the task flow, so that we have a good project progress guide.

3
Chapter 2

System Architecture Overview

This chapter is focused on presenting all the subsystems of Aurora, explain their operation and how the team integrated
everything in the final project, to design a fully operational rocket.

2.1 Overview of The Integrated System

In order to successfully complete the mission, Aurora had to be divided into smaller subsystems that, together, compose
all the functionalities of the rocket. In order to understand the organization of the subsystems, a picture is displayed
under this paragraph to illustrate it. In addition to all the subsystems, the team’s structures and aerodynamic
department worked very hard to optimize the rocket’s performance and select materials, in addition to organizing the
subsystems inside the rocket in a satisfactorily.

Figure 2.1: Detailed view on the subsystems.

2.2 Propulsion
The propulsion subsystem is responsible for generating the thrust force that drives the rocket upward. It is of pivotal
importance to assure that this subsystem will operate safely and generate just enough thrust for the mission objective
apogee.
Since the team had developed a successful engine for the previous rocket project, named Anhangá, the know-how
for building solid propellant rocket engines was already obtained. In order to improve the engine, the team had to
pursue different ways to reduce the stresses caused by the high internal pressures, change the material for a lighter
one, improve on mechanical simulations and find a way to assemble the engine more easily.

4
2.2.1 Propellant
We use a potassium nitrate and sorbitol propellant, because it is know as one of the most commonly used for the
categories we’re aiming at, and also one of the easiest and safest to manufacture. Our propellant uses 65% potassium
nitrate and 35% sorbitol, with our propellant having the bates geometry for its practicality, and being molded inside
the combustion chamber internal insulator, which will be described furthermore.

2.2.2 Engine
Aurora’s engine, Hyperion I, was designed as an evolution from the previous one, Scorpio II. With the previous
experience and knowledge gained by the team, besides being more complex and expensive, it was designed with a
few modifications that would improve its performance, so that Aurora could carry a heavier payload, and reach a
higher apogee. Compared with the Scorpio, Hyperion has four main differences: the number of pieces required to
function, the impulse class (being now a J class motor), the method for assembling the engine and the material for
the combustion chamber.

Hyperion I
Once it was possible to machine more complex geometries, to facilitate the assembly and reduce its mass, the Hyperion
was designed to have only two structural parts, instead of three parts as the Scorpio. This way, combining the lid
and the chamber, there was one less part to machine, and one less joint to be susceptible to failure. Also, the lid
has a semi-spherical geometry, instead of being a flat surface. This way, the tension due to the internal pressure is
distributed more evenly, reducing the stresses, allowing for a lighter engine. Nevertheless, the team still designed a
thrust plate to use on top of the engine, in order to better distribute the thrust force on the fuselage.

(a) Stress simulation on Scorpio I2 lid (b) Hyperion’s lid

Figure 2.2: Engine lids comparison

In contrast with Scorpio, the Hyperion’s nozzle is threaded directly to the combustion chamber, instead of having
radial bolts to fix it. With the bolts, besides being heavier and increasing the number of parts, it also created points
with tension buildup between the screws and the holes which decreases the reliability of the engine. So, to fix this
issue, threading the nozzle directly to the combustion chamber creates a bigger and more uniform area to transfer the
loads from the nozzle to the rocket.

5
 Figure 2.3: Hyperion’s nozzle threaded to the combustion chamber

The material chosen for the Hyperion was the Aluminum alloy 6061-T651, due to its low density and higher yield
strength, compared to other aluminum alloys. But since it is a heat treated material, it has a relative low operation
temperature, compared to the steel SAE 1045 alloy used in Scorpio. So, to avoid overheating the new combustion
chamber, a heat shield using ablative material had to be designed. Based on the Nakka website and other sources
of information, 17 different ablative materials were chosen to be tested, being: Cork, Rubber, Cardboard, Gypsum,
Caulking, Body Filler, Fiberglass Fabric and Mat, Epoxy Resin, Epoxy and Fiberglass Fabric, Epoxy and Quartz
Filler, Epoxy and Talc, Epoxy and Glass Micro-spheres 20% and 50%, Epoxy and Calcite and Epoxy and Magnesium
Sulphate 50% and 75%.

Figure 2.4: Ablative test Specimen

For this test, 18 specimen were were manufactured, composing of a thin aluminum plate, and the ablative material
on top. Also, 2 thermocouples were positioned, one in front of the specimen and the other at the back, in contact
with the aluminum plate and a blowtorch. During the test, the blowtorch would heat the ablative material, and the
temperature from the fire and from the back of the specimen were collected.

6
 Figure 2.5: Ablative Material Test Results

As seen from the results displayed in Fig. 2.5, the best materials were the Epoxy Resin with Magnesium Sulphate
(specimen 16), and the Epoxy with Glass Micro-spheres (specimen 18). With these materials, even though the
temperature of the blowtorch was around 1300 °C, the temperature from the back of the aluminum plate reached only
around 45 °C. Altough the first one had a better performance, it is also three times denser than the last one. So the
chosen material was the Epoxy with the Glass Micro-spheres.
At last, to ensure that Hyperion would be able to handle the stresses from the flight, using the software Ansys,
structural simulations were done. The boundary conditions used were a internal combustion pressure of 35 bar, and
400 N of force at the nozzle. The results can also be seen in the following figures, with the maximum stress being
72 MPa, considering the Al 6061-T651 tensile yield strength being 262 MPa at 100 °C, due to the heat from the
internal combustion process, the safety factor is 3.6. A relative high safety factor, but considering that this is the first
motor designed completely by the team, we decided to guarantee a minimal risk situation. Also, compared to Scorpio,
Hyperion has only around 140% of its predecessor’s mass, but has a specific impulse of around 400% Scorpio’s specific
impulse.

(a) Ansys simulation boundary conditions (b) Hyperion’s assembly simulation results (c) Hyperion’s combustion chamber simula-
tion results

Figure 2.6: Engine Simulation Results

With the design completed, and the project finalized, the engine was machined with the partnership from Meccal
and Magneti Marelli. The nozzle was machined with the steel SAE 1045 alloy and, besides of it being threaded,
its internal geometry followed the same methodology of design that Scorpio’s nozzle followed, by using the Richard
Nakka’s combustion chamber excel spreadsheet, obtained in Richard Nakka’s personal rocketry website [3] (Fig.D.13).

7
 Figure 2.7: Hyperion I machined

2.2.3 Experimental Tests

There are 2 tests planed to occur in November, a hydrostatic test to certificate the structural strength of the engine,
and a static fire to validate its impulse. As far as by now, the team cannot provide any experimental data to validate
the physical model of the engine.

2.3 Structures
The team learned some crucial lessons from the previous 500 meter apogee rocket project. Consequently, a few changes
were implemented. Some solutions were reviewed and worked in order to bring new challenges to our team and obtain
the know-how to work on larger rockets in the future. Therefore, in this section the team is going to explain how
every structural feature was developed.

2.3.1 Fuselage
The fuselage is the main point in the Aurora project. Since the fuselage is responsible for carrying all the thrust
power of the engine, the team took a look over the materials that are resistant and light. This way, carbon fiber is the
main choice for material, because of its high resistance and good cost efficiency. Plus, the team acquired experience
in fuselage manufacturing using fiberglass in the last project, so laminating carbon fiber is something the team can
easily do.
For each fuselage we needed to develop an open rocket model in order to suit the project and determine the
necessary motor class to reach the desired apogee. Adding up with the nose length and the extra length added by the
tail cone, we ended up with a 1417 mm long model rocket for in final state (Fig. A.5).

Manufacturing - Carbon Fiber cloth

Using a PVC pipe as a cylindrical mold, with external diameter of 100 mm, together with a small PVC base with a
central axis for rotation of the mold pipe, we can laminate the carbon fiber cloth around the pipe, using epoxy resin
and hardener. This way, it is possible to obtain a well defined cylinder after letting the cloth dry. The team will
use three layers of carbon fiber, laminated on top of the pipe, which will be covered in wax with plastic wrap and
cardboard. With the experience from previous lamination processes using fiberglass, we estimate that the external
diameter will be 102.2 mm, while the internal diameter of the fuselage will be fixed at 100 mm.
After drying out, a longitudinal cut will be made along the fuselage, where the team plans on uniting the parts
using fiberglass mat. After that, we will sand the body, to reduce surface roughness, and do all the post lamination
operations, such as drilling the holes on the fuselage to attach the bulkheads, rail guides and the external camera
support, and cutting the fuselage to divide it in two sections.
The final stage of the fuselage can be described as two cylinders, one that will contain the recovery subsystem,
with a length of 440 mm, and one that will contain the propulsion and payload subsystems, with a length of 570 mm.
The cylinders will be united by a 280 mm long coupler (internal diameter of 98mm and external of 100mm), which
will made very much in the same way of the fuselage, but using fiberglass, to attach the avionics bulkheads with the
fuselage. The avionics subsystem will be placed between the fuselage sections (inside the coupler), in order to maintain
it the closest possible to the recovery subsystem, since the avionics is responsible for activating the parachute ejection
process via explosive charge ignition.

8
2.3.2 Bulkheads
Bulkheads have internal structural functions in large model rockets. They can be used to couple the avionics cage,
unite fuselage sections, attach the parachute, carry the payload, and more. In Aurora, we decided on using 2 bulkheads
per module, 2 for the avionics, 2 for the payload and one for the parachute. Also, one bulkhead has the function of a
thrust plate, on top of the combustion chamber, to distribute the thrust force along the fuselage and drive the rocket
upward. Furthermore, some bulkheads were design with rips for cable and sensors passing through the rocket.
The bulkheads for the parachute(Fig. D.11), top one of the avionics (Fig. D.3) and the thrust plate (Fig. D.14)
are screwed on the fuselage using 6 symmetrically distributed points (60°between each) and for the payload bulkheads
and the bottom bulkhead for the avionics the team will use three symmetrically distributed screws (120°between each)
to fix them, because of the geometry adopted for those sections.
The thrust plate is designed in two different diameters, the lower one is to fit in the top of the combustion chamber
and the upper one is to be fixed on the fuselage, to transfer the thrust to the rocket body. The team choose aluminum
for the thrust plate material, due to its lightness and mechanical properties. Stress simulations were performed using
the ANSYS software to guarantee that no fractures will occur during flight.

Figure 2.8: Thrust Plate Stress Simulation Result

2.3.3 Nose
Aurora’s nose cone is a Von Kármán nose, 375 mm long, with a base diameter of 100 mm for a tight fit on the rocket
body’s internal diameter. The nose is made out of fiberglass, manufactured utilizing a 3D printed mold (Fig.D.15).
The reason for choosing this geometry is that this is the most aerodynamic nose shape for the velocity reached during
flight [2].

2.3.4 Fins
Aurora’s fins have a symmetric airfoil profile, developed after several aerodynamic simulations using CFD AUTODESK
to make sure that it’ll improve the flight performance. It’ll be made out of plastic ABS, which will be 3D printed,
because of it’s weight and the easy way to manufacture a complex airfoil geometry, improving the manufacturing of
a rocket with new technologies (Fig. D.8).

Fins bay
An improvement for Aurora is the addition of a ABS 3D printed fins support (Fig. D.9), which will be used to fix the
fins in fuselage without necessity of screws. Another feature of the fins support is that it will be used to lock the tail
cone in place, using a disposable ABS 3D printed ring to press the pieces against each other (Fig.D.17). the choice for
ABS is simply for the high cost efficiency of the material, since these pieces are not going to be under high stresses
and can perform satisfactorily way.
In order to use the fins support as a centralizer for the engine, 4 small holes are made to screw M3 sized screws,
that will be in direct contact with the outer surface of the engine. Plus, the fins bay comes with a small rail guide to
slide the tail cone in, in order to lock him in place.

2.3.5 External camera support and rail guides

Two new features the team is working on for project aurora is the development of an external camera support, to
hold the camera lens that will record the flight, and a more aerodynamic rail guide, consisting of an aluminum airfoil

9
shaped piece that is designed to fit in the Latin Ameican Space Challenge 2021 launch rails.

2.3.6 Tail Cone

Another new component for Aurora is the tail cone (Fig. D.16), which will help reduce air drag during flight, by
guiding the air flow in the back of the rocket and avoiding re-circulation of air.
The CFD simulations using Autodesk CFD software are displayed below, with air at 293 K, pressure of 1 atm and
an inlet flow velocity of 147 m/s. The model used excludes the camera support and the rail guides because the main
focus is to exhibit the behavior of the air flow at the rear end of the rocket.

Figure 2.9: CFD simulation on Aurora’s body

2.3.7 Avionics Bay

The avionics bay is located in the middle of the fuselage, inside the coupler. The avionics is 275mm long and has
an outer diameter of 98mm, being responsible for carrying most of the electronic components included in the rocket,
including part of the recovery system (parachute deployment control system and crimson powder ignition system) and
the communication system. The avionics is divided into two main geometries for the subsections: The upper one is
a hexagonal shaped subsection, while the bottom one is a triangular shaped subsection. The first one is to fit some
sensors horizontally and the second one is to fit the rest of the electronics vertically, because if the team were to adopt
only one of the shapes, some of the sensors could not work properly.
The upper subsection has a bulkhead on the top, made out of thick balsa wood that will be screwed in fuselage
with the coupler (Fig. D.3).The reason for choosing balsa wood is that the team wanted to avoid any metallic obstacle
for the communication system, in order to avoid wave reflections, and balsa wood is a reliable light material to choose.
Right below that, there is a star shaped piece designed to adjust the hexagonal printed circuit board shape to the
circular shape of the bulkhead (Fig. D.2). Furthermore, to connect all the circuit boards there is another feature
designed by the team, the ”3D printed circuit board towers”, made out of ABS plastic, with a length of 101 mm and
a diameter of 20 mm (Fig.D.1). There are 6 of these 3D printed towers, which are equally distributed in the upper
subsection. In addition, a cavity in the tower works as a clip, just to maintain the circuit boards fixed in place. All
pieces will be fixed in each other with nuts and bolts.
Between the two parts of the avionics there is a thin balsa wood bulkhead that is designed to unite the two different
geometries (Fig. D.6). This mid bulkhead will lock the bottom of the upper subsection to the rods of the triangular
shaped lower subsection.
The lower subsection is held by a bulkhead in the other end of the coupler (Fig. D.5), with the same function of
the upper avionics bulkhead. This triangular shaped subsection has a length of 120 mm and its main objective is to
fit the communication antenna, which is a major component for aurora, together with other sensors and electronics
components, such as the batteries. A rectangular ABS 3D printed board is placed vertically between the middle and
bottom bulkheads (Fig. D.4), to fix the circuit boards this way. There are 3 steel rods to maintain the structure
static, which are going to be locked in the lower bulkhead.

10
 Figure 2.10: Avionics subsystem assembled

2.3.8 Payload Bay

For the Aurora’s payload, the team decided to bring a scientific payload, that will be described in section 2.6. To
accomplish this, the structural geometry selected for the payload is the same as in the lower section of the avionics
subsystem, since the components are very similar.
It’s a triangular composition with the length of 120 mm, with the same rectangular boards made out of 3D printed
plastic ABS, also held by two equal bulkheads (Fig. D.7), but this time the material selected for the bulkheads is
aluminum with an outer diameter of 98 mm, both integrated with 3 steel rods. The conceptual idea of the payload is
a compact and sturdy structure, since it’s located right after the engine.

2.4 Recovery
The recovery system is responsible for ensuring that the rocket will return with the least amount of damage possible
to the ground. For this purpose, the competition organizers establish that the return speed should not exceed 10 m /
s. Therefore, the recovery system must be able to eject th parachute by exploding an ejection charge moments after
the rocket reaches its peak altitude, opening a parachute capable of cushioning the rocket’s fall within the established
limit. Below are details of the parachute design, details of the ejection charge and operation of the proposed design.

2.4.1 Recovery Operation

The Recovery system works when the rocket reaches its apogee of 1000 meters. When activated, the ejection system
will send a electrical current that will heat a nickel-chromium string, which in turn will heat the explosive charge
until it explodes and liberates energy to eject the nose out of the body. Lastly, the nose will help the parachute to be
expelled through a connection cord between the two elements.

11
 Figure 2.11: Recovery subsystem components

It is important to note that, between the parachute and the explosive charge, there is a fiberglass protection plate
that will not permit any burn damage to the parachute. Basically, the protection plate is a circular plate with a small
hole to attach to the parachute shock cords, in order to recover the plate after the flight.

2.4.2 Parachute
The parachute project was carried out strictly following the procedures described by J.R Brohm: https://www.
rocketshoppe.com/info/The_Mathematics_of_Parachutes.pdf.

Project
The parameters used in the parachute project are listed in Table 2.1. The simulated ambient conditions are close
to the conditions at Tatuı́, São Paulo, where the Latin American Space Challenge 2019 rocket launches occurred .
The terminal speed was chosen to obtain the safety margin, provided arbitrarily. Thus, in order to find the size and
geometry of the parachute, it must first find its minimum area, therefore it is necessary to choose a terminal velocity
present in the equation 2.1, in which Ap is the area of the parachute, vt is the terminal velocity, m is the mass of the
rocket, ρ is the density of the air, g is the acceleration of gravity and Cd is the drag coefficient.
2gm
Ap = (2.1)
ρCdvt2

Table 2.1: Parameters used in the parachute design

Gravity [m/s2 ] 9.81

Rocket’s Dead Mass [kg] 5.382
Air Density [kg/m3 ] 1.225
Terminal Velocity [m/s] 8
Drag Coeficient [-] 0.75

Geometry
Now that we have the parachute area, it becomes necessary to apply this information to useful geometrical shapes, for
reasons of ease of preparation, better sizing and greater availability of knowledge. The chosen geometry was based on
the method of inscribing a n-sided polygon within a circle, so all vertices will be tangent to the circle and the distance
from the center to the vertex will be equivalent to the radius of the circle.

12
 Figure 2.12: Inscribed polygon.

Looking at the figure 2.12 it is possible to notice that the n-sided polygon has n triangular areas present within its
area, so we can match the area Ap previously found with the area present in the polygon, which is equal to n-times
the triangular area At.

Ap = At n (2.2)
Manipulating the equation further, to leave it only in terms of n and d, with d being equal to twice the radius r,
we arrive at the formula:

nd2
 
360°
Ap = ∗ sin (2.3)
8 n
Therefore, we can deduct that the biggest diagonal of our n-sided polygon is found by the equation
s
4mg
d=2 (2.4)
nρCd vt2 sin( 360°
n )

Thus, using the desired terminal velocity value, in case 8 m/s, it was found that an advantageous area / radius
ratio for the rocket occurs when n = 8, so the geometry of the parachute is an octagon and its diameter is should be
grater or equal to approximately 1,45 m. This way, the team decided on using an octogonal shaped parachute with
the biggest diagonal measuring 1800 mm, to assure a safer recovery.

Parachute Material
The fabric chosen for both the parachute and its rope production was rip-stop nylon 45, due to its lightweightness
and good resistance.

Parachute attachment
The parachute will be fixed by connecting its cords to a swivel fixed in an U-bolt, locked in the parachute aluminum
bulkhead, which is locked to the fuselage.

2.4.3 Ejection charge

The explosive ejection charge from the recovery system consists of 7 grams of crimson powder. This choice was based
on studies by Richard Nakka, in which they show that it has lower combustion temperature than black powder, which
minimizes heat damage to the rocket and its more potent.
Crimson powder specifications by Richard nakka [3]: https://www.nakka-rocketry.net/articles/Crimson_
powder_rev.1.4.pdf.

13
 Figure 2.13: Crimson Powder.

2.4.4 Simulations
In order to check if the parachute is safe for recovery, the team decided upon using the Open Rocket software to
approximate the octogonal shaped parachute to a circular canopy and simulate a flight on the software.
We decided to extract the data from the combustion chamber simulations made on Richard Nakka’s spreadsheet
and generate a .eng file on TcTracer. This way, we could import a motor in the Open Rocket software.
After that, we could just set the parachute with the desired drag coefficient (0.75) and the diameter of the round
canopy being 1800 mm. The simulation results can be found in appendix A.

2.5 Avionics
2.5.1 Objectives
The goals of the avionics in the Aurora rocket are:

1. To save flight data to a storage medium so it can be reviewed and submitted to post-flight analysis.
2. To activate the parachute deployment system in due time for a successful recovery process.
3. To receive GPS data and send this to the launch base when the rocket reaches the ground, so it could be
recovered.

4. To have all critical systems in redundancy, to prevent unsuccess due electronic failure

2.5.2 Requirements
In this section, we recall the requirements and verification methods for the avionics hardware. The table 2.2 bellow
summarizes the requirements for the avionics system. Requirements with a code starting with ”F” are functional
requirements.

2.5.3 Hardware Design

In this section, we present the preliminary hardware design for the avionics. We divide it into eight main parts:
• Microcontroller unit
• Sensors
• Data storage devices

• Data transmission devices

• Ignitor activation circuit
• Power sources

• Ground base
• Hardware disposal and cable management

14
 Code Description Verification method
The avionics must be able to ignite
F01 a Crimson Powder charge via a NiCr Ignition test
heating element.
The avionics must be able to gather Electronic design review
F02
and store flight altitude data. + altitude variation test
The avionics must be able to identify Flight simulation test via
F03
the flight apogee in real-time. altitude variation
The avionics must have a source of power
to perform during the whole useful life
F04 Flight simulation test
of the rocket (from pre-flight operations
to rocket ground recovery).
The avionics hardware must fit into the Mechanical design review
F05
avionics bay in the rocket. + Integration phase
The electronics must endure the
F06 Test flight
mechanical loads from flight acceleration.
The avionics must issue a sound alert
F07 when on the ground, for easier Flight simulation test
recovery process.
The avionics must be able to
transmit GPS data to the base Flight simulation test
F08
when on the ground, + Data transmission test
for easier recovery process.
The avionics must identify if the rocket
F09 Flight simulation test
has landed.
The avionics must have all critical
F10 Electronic design review
subsystems in redundancy.

Table 2.2: Avionics requirements.

Microcontroller Unit
In order to satisfy requirements F03 and F09, the avionics needs an onboard processing unit, that will make calculations
in real-time using sensor data to determine the stage of flight the rocket is at, and to decide whether or not to activate
the parachute deployment system.
For such tasks, an ESP32 microcontroller was selected. Besides being space-efficient and COTS, it has enough
processing power to deal with sensor readings and data processing. Its technical specifications follow on the table 2.3.

Characteristic Specification
Supply voltage 4.5 9.0 V
Processor frequency 240MHz
Flash memory 4MB
SRAM 520KB
GPIO pins 38
I2C modules 1
SPI modules 1
UART modules 1
Firmware Language Arduino

Table 2.3: ESP32 specifications.

The use of an Arduino platform also allows for a faster firmware development process, due to the existence of
several ready-made libraries for sensors and other peripherals. These libraries are developed by the online community,
and thus are free and available for use.
The microcontroller activation will be done from an screw switch, in order to be possible to activate it when the
circuits were inside the rocket, by a little hole in the fuselage. Since the ESP32 is the central component of the
electronics, activate it means activate all the hardware

Sensors
In order to satisfy requirement F02 and to acquisition the data needed for compliance with requirements F03 and
F09, the avionics of the Aurora rocket needs altitude sensors.

15
 The most common type of altitude sensors is a barometer, that works by measuring the external atmospheric
pressure. Following the Standard Atmosphere Model, the atmospheric pressure decreases as the rocket goes higher.
Therefore measuring the external pressure is an indirect way to measure the altitude of the rocket.
Several barometric sensors are available on the market, but our team chose the Bosch BMP280 sensor. The
BMP280 technical specifications follow on the table 2.4.

Characteristic Specification
Pressure range 300 → 1100 hPa
Accuracy ±0.12hPa
Digital interfaces I2C, SPI
Current consumption 2.7 mA
Temperature range −40 → +85o C

Table 2.4: BMP280 specifications.

We use redundant barometric sensors to satisfy requirement F10, in case one has a connection failure or malfunc-
tions. To avoid that both sensors stop working due to the same condition during the flight, we use a different module
in the redundant sensor. In this case, we choose the COTS altimeter EggTimer Classic Flight Computer.
To satisfy F08 requirement, the avionics must have an GPS/GPRS sensor, in order to receive satellite data, and
triangulate the position in real time. For this reason, the chosen module is the ne6mv2, which specification can be
found in the table 2.5.
Furthermore, an buzzer is connected to the ESP32, besides some indication LEDs, so the F07 requirement can be
completed, and also to have an debug and test interface.

Characteristic Specification
Power Supply range 3V → 5V
Default Baud Rate 9600 bps
Ceramic antenna size 12 x 12mm

Table 2.5: NEO6MV2 specifications.

Data storage devices

Storing the data in a long-term memory device is needed to comply with requirement F02. Therefore we use an
SD card peripheral to store the flight data into an SD card. To ensure the data acquisition and complete the F10
requirement, we will use two of those modules.

Data transmission devices

The data transmission is a task that belongs to the requirement F08. Beyond the GPS data, we will also transmit the
altimeter readings, so we can have, on the ground, features like height and speed of the rocket, in real time. For that,
we will use an LoRa (Long Range) transmission, that transmit data with a low-power wide-area network, in this case,
with the E32-915T30D module. This module operates at, approximately, 915 MHz, and can transmit/receive data at
8km, maximum. Other features can be found in the following table 2.6.

Characteristic Specification
Frequency band 915 MHz
Max range transmission 8km
Air data rate 0.3kbps → 19.2kbps
Power supply 3.3V → 5.2V

Table 2.6: E32-915T30D specifications.

To complete the data transmission, the LoRa module will count with the TX915-JZ-5 antenna, which uses the 915
Hz frequency for transmission (same as LoRa), and has an 2.0dBi gain.

Ignitor activation circuit

Here, we present the circuit that ignites the Crimson Powder by the NiCr heating element, satisfying the F01 require-
ment. The complete schematic of the power circuit connected to the ignitor is shown in the figure 2.14. In it we see
both the ignitor activation circuit (circulated in green) and the ignitor status reading circuit (circulated in orange).
The ignitor reading circuit can also be seen as illustrated in the figure 2.15 is based on a voltage divider for
measuring three different states that the ignitor can show:
16
 Figure 2.14: Activation circuits (in green) and reading circuits (in orange) of the ignitor.

1. Open Ignitor: No resistance connected to the ignitor terminal.

2. Ignitor present: Resistance of the ignitor connected to the terminal.
3. Active ignition: MOSFET in triode.

Figure 2.15: Another view of the ignitor status reading circuit.

In the first case, with the ignitor open, we will not have any additional resistor attached to terminal J1 in the
circuit of the figure 2.15. Additionally, since the ignitor is not active, we assume that MOSFET does not drive. This
way, the circuit can be reduced to the voltage divisor seen in the figure 2.16. We can then conclude that the tension
measured at the point ”ANALOG READ” is given by:
R1
VAR = VBAT (2.5)
R1 + R2 + R3
In the second case, with the ignitor present, the circuit can be drawn as in the figure 2.17. In this case, we have
the ignitor’s resistance RIGN present in the terminal, in parallel with R3 and the MOSFET in cut-off region. This
17
 Figure 2.16: Ignitor status reading circuit - Open ignitor case.

way, the voltage at the reading point is:

R1
VAR = VBAT ,
R1 + R2 + (R3 || RIGN )

where the parallel resistance between R3 and RIGN can be considered close to RIGN and therefore much lower than
the R1 and R2 resistances. This way, we have approximately
R1
VAR = VBAT , (2.6)
R1 + R2

tension that is necessarily higher than that in the case of the open ignitor (because R3 > 0).

Figure 2.17: Circuit for reading the status of the ignitor - Case of the ignitor present.

In the last case, with the ignitor active, the MOSFET is in triode, which leads us to the circuit of the figure 2.18.
The voltage at point P, forced to zero by MOSFET triode, generates a zero voltage at the analog reading point. Thus,
18
in this case we have:
VAR = 0. (2.7)

Figure 2.18: Circuit for reading the status of the ignitor - Case of the active ignitor.

In this way, we have the theoretical tension expected for each possible state of the ignitor. Now it was necessary
to find the values of the resistors in order to obtain the desired voltage levels for each of these states.
The analog reading voltage levels should all be below 5V, Arduino’s supply voltage. Therefore, it was decided to
leave a large margin between the levels in order to avoid ambiguity in the reading. The reading voltage levels decided
were:
1. Open Ignitor: 1.5 V = V1 ;
2. Ignitor present: 4.5 V = V2 ;
3. Active Ignitor: 0 V (equation 2.7) .
We have then, from the equations 2.5 and 2.7:
R1
V1 = VBAT
R1 + R2 + R3
R1
V2 = VBAT .
R1 + R2
If we simplify by isolating the resistors, we have:
 
VBAT
R1 − 1 − R2 − R3 = 0 (2.8)
V1
 
VBAT
R1 − 1 − R2 = 0. (2.9)
V2
From 2.9, and considering VBAT = 7.5 V, we have the equation:
V2
R1 = R2 = 1.5 ∗ R2 . (2.10)
VBAT − V2
Thus, replacing this relation in the equation 2.8, we obtain:
   
V2 VBAT
R3 = R2 − 1 − 1 = 5 ∗ R2 . (2.11)
VBAT − V2 V1
From these two relationships, it was enough to find resistors of commercial values that fulfill them. Additionally,
it is interesting that the resistors have high resistance (around 100k), to limit consumption while the ignitor is
deactivated. For this reason, the following resistors were chosen:
• R1 = 270 kΩ
• R2 = 180 kΩ
• R3 = 900 kΩ
19
Power Supply
In order to acquire F04 requisite, we will use an power supply that is enough to feed the microcontroller unit, that
will be responsible to control the power in the other elements. We will also need an source with enough current to
trigger the ignitor, For this reasons, we choose to use two of the NCR18650B Li-ion batteries, which has 3.7V and
3000 mAh each.

Ground base
The ground base is necessary to receive the data transmitted. by the LoRa module in the avionics. In other words, it
is part of the F08 requisite. For this reason, the ground base is and microcontroller (ESP32) plus another LoRa and
antenna module, connected in an computer so we can read the data in the serial monitor.

Hardware disposal and cable management

To ensure that the connections will be strong enough during the flight, and to endure the mechanical loads from flight
acceleration (F06 requirement), the components will be divide in PCBs, the connection between boards will be made
with wires using cable terminals, and those will be attached in the circuits by screw connectors. The PCBs will be
designed to be attached to the avionics bay (section 2.3.7), what satisfy the F05 requirement. Also important to
mention that the GPS antenna will be fixed in a way that it will always points upwards, since it’s an patch antenna,
and works ideally in that position. Ideally, it has to be half wave-length (approximately 165 mm) far from any barrier
on the top, but the size limitations of the bay leads it with 35mm , which is enough but not ideal. The LoRa antenna
also have to be attached vertically, since it has an omnidirectional pattern of transmission. The verticals plates in the
bay structure allows that to happens.

2.5.4 Firmware
In this section we present the structure of the firmware project. For this reason, we use UML diagrams to represent
the firmware functionalities of the first version of Aurora’s avionics. The embedded code is written in C++ using
Arduino libraries and runs in the microcontroller.

Objectives and functionalities

The functional objectives of the firmware have been divided into three main branches, and follow below, in descending
order of importance (most important first):

1. Recovery:
(a) Identification of the apogee
(b) Crimson Powder’s (CP) ignition for hood and parachute ejection
2. Navigation:

(a) Altimeters data acquisition

(b) GPS data acquisition
(c) Storage of flight data in flash memory - SD card
(d) Transmission of flight data with Lo-Ra

3. Location:
(a) Identification of arrival on the ground
(b) Turn on sound alarm to help locate the rocket

General description
From the firmware point of view, the peripherals are the only means of exchanging information with the outside world
(More details about the hardware structure are better explained in the section 2.5.3.). In particular, the only useful
elements for navigation are the altimeters. Thus, these are critical for the operation of the program, and so there
must be redundancy in the event of a critical failure (malfunction) of one of them during flight.
This version of the firmware was founded on three main structural elements:
1. State machine: The code was divided into a switch/case structure that led it to respond differently at each
stage of the flight.
2. Classes for data processing: The storage structure and for calculating data obtained in flight was made
based on two classes, implemented in C++, for application in the Arduino IDE.
20
 3. State transition functions: The data obtained by the classes were analyzed in functions responsible for
defining the conditions under which the exchange between flight / program states would occur.
Following this section, we will explain better each of these structural elements.

State machine
The rocket flight has several stages, with specific transitions from one to the other. This can be modeled as a state
machine. We start by identifying the state transitions, which line up with important points during flight:
Release: Motor drive
End of propulsion
Flight Apogee
Landing
Engine failure
We then have 4 main transitions. The states linked to these transitions can be listed:
S1 Startup
S2 Propulsive flight
S3 Ballistic flight
S4 Recovery flight
S5 Ground location
S10 Failure mode
The state machine can then be described by the diagram of the figure 2.19.

Figure 2.19: Diagram of flight states used in the program.

An detailed description of each state follows.

S1
The rocket can be on the ground in two different moments: before the flight starts and when it lands. Since each of
these have different routines, we use the states S1 and S5 to differentiate them. In the S1 state, the rocket perform an
checkout routine, mainly checking if the ignitor is present. If yes, it follows to the blast-off. If not, it release an failure
signal. It also starts the receiving of GPS data and the transmission of the position and height to the ground base.
21
S2 and S3
Once the rocket is in flight, the vertical velocity condition for identify the apogee is zero. It’s enough, but it is not
optimal in terms of parachute ejection, since this process is not instantaneous. In fact, in tests, the act of effective
ejection took up to 5 seconds after executing the ignition command (electrical activation of the ignitor). This time
interval is called ∆T0 , and was acquired experimentally, in the ejection tests.
In this way, it is necessary to foresee the ideal moment of flight in which to execute the ignition command so
that the parachute is ejected exactly at the apogee. This is possible thanks to the flight simulation data, allied to a
constant monitoring of the vertical speed of the rocket during the flight.

Figure 2.20: Time graph of vertical speed during the flight of an simulation.

As we can see, there is a great increase in speed at the beginning of the flight that reaches a maximum, thanks to
propulsion; then a constant drop in speed thanks to the action of gravity, to the point of apogee, where the vertical
speed becomes null, and after that a growing negative speed until the ejection of the parachute, which generates a
decrease in the speed module.
The picture 2.20 shows the firmware points of interest. As we see in the picture 2.20, there are two points that
share the same vertical speed: the blue, which is reached during propulsive flight (S2), and the green, which is reached
during ballistic flight (S3). This would justify the differentiation between S2 and S3 states, whose existence avoids
the activation of the parachute during propulsive flight (at the purple point, to be avoided).

S4
During the recovery flight (S4 state) it can be interesting to turn off the ignitor in case it opens automatically after
activation. Otherwise, the ideal would be to continue activating it until it opens.

S5
Finally, the E5 state is justified by the need of security and location at the time of recovery of the rocket after flight.
It is necessary, on the ground, to activate the buzzer - as an audible alarm for location - as well as to deactivate the
ignitor, to prevent accidents at the time of recovery. These actions are taken after landing.

S10
This state is reached in case of failure before the rocket launch. If the ignitor is not detect when the avionics is turned
on, the state machine comes to S10 and it did not allows any other state to be reached, and starts turn on and off
an buzzer until the system is turned off and the failure is fixed. This is necessary because the ignitor is essential to
release the parachute in the apogee and prevent fall damage.

Components
Since we have an central component, the state machine, we can define other components that represent the general
structure of the firmware. As you can see, this components also represent the hardware interfaces, since the firmware
must made the connection between the electronics. The figure 2.21 shows the diagram and the provided and required
22
interfaces of the components, following the UML pattern. An explanation of each follows.

Figure 2.21: UML diagram of components and its interfaces

State Machine The state machine is the main controller and has already been described before in 2.5.4.
Altimeter The altimeter component treats the pressure read in the BMP280 sensor and provides the rocket height
and velocity, mostly used in the triggers to the state machine transitions.

Ignitor This uses the 2.5.3 circuit to provide the ignitor state, important to the state machine.
Buzzer The buzzer provides the possibility of emitting an sound alert, activating the hardware component with the
same name.
Ground base The ground base is the firmware part that runs outside the rocket, in the solo. It receives the data
transmitted and shows in an console.
LoRa This component receives the data from the flight, encapsulates it, and send via an LoRa system to the ground
base.
Data Storage The function of Data Storage is to gather the flight data and store into an SD card through SD
module
GPS This component uses the GPS Module to receive the position of the rocket and to provide it to the other, more
specifically to the LoRa, that will transmit it.

2.6 Payload
The general idea of the payload project is to obtain flight’s data. Those will be used to further analysis of the rocket’s
performance and to help in future improvements. In order to accomplish this, there is a list of sensors that we are
gonna use and the data that this sensors provide.

Sensor
accelerometer and gyroscope (MPU-6050)
Altimeter (BMP280)
Termocouple (MAX6675)
Strain gauge (HX711 + BF350)
Camera (ArduCAM-Mini-5MP-Plus)
Data
acelleration and gyre in the rocket’s trajectory
Rocket’s altitude and speed
Internal temperature of the rocket
Thrust plate’s deformation
Flight images

Table 2.7: Payolad specifications.

To control all this sensors and to handle the data, we will use an ESP32 microcontroller. As storage device, the
4MD36 SD Module will be used. The power supply will come from two Ncr18650 Li-Ion batteries, that is has capacity

23
to feed the ESP32, and the microcontroller directs the energy to the other components. In order to activate it, we
are gonna use an screw switch, allowing to turn it on inside the rocket trough an tinny hole in the fuselage.
Since the ESP32 is Arduino friendly, the firmware will be developed using C++ in Arduino’s Idle Development
Environment and software libraries made from the community, available for free in the internet. It main objective is
to control the sensors in the data gathering, and save it in the SD Card trough the SD Module.

24
Chapter 3

Mission Concept of Operations Overview

The project overview of mission concepts is an important part of the team organization as it will help visualize all
the steps and procedures required for the mission. It will also allow the team to understand the risks that each
phase can present. all the phases considered are: Assembly, Pre-launch, Transportation, Ignition, Lift-off, Propulsive-
flight,Ballistic-flight, apogee,Rocket landing, decommissioning.

3.1 Assembly phase

In the assembly phase, the structure team as well as the electronics team will check all components to make the
assembly

Figure 3.1: Assembly phase

3.2 Pre-Launch
In the pre-launch phase, the electronics team will check the control station, the avionics and payload will also be
turned on, if they fail, the system will be turned off. The propulsion team will check the ignitions and make the last
checklist before preparing for transportation.

25
 Figure 3.2: Pre-launch phase

3.3 Transport
The transport phase show the step to get the rocket ready for launch

Figure 3.3: transport phase

3.4 Ignition phase

The ignition phase is the responsibility of the electronics and propulsion team. It shows the connection between the
activation of the ignition system and the combustion of the propellant
26
 Figure 3.4: Ignition phase

3.5 Lift-off
The lift-off phase will happen when the combustion gases start to exit the engine. In this phase the avionics will
detect the variation of the altitude and aceleration. It is important for the rocket to exit the rails with a velocity
above 15m/s

Figure 3.5: Lift-off Propulsive-flight

3.6 Ballistic flight apogee

Ballistic flight will begin when the momentum stops, during this phase the avionics will collect data and when the
flight is near the apogee the recovery system must act to expel the parachute during the apogee

27
 Figure 3.6: Ballistic flight and apogee

3.7 Rocket Landing Decommissioning

In the descent phase, the rocket must land with a speed less than 10m/s. At this stage, the gps will be very important
for the recovery of the rocket at the end of the mission.

Figure 3.7: Rocket Landing Decommissioning

28
Chapter 4

Conclusion and Lessons Learned

To conclude, the team had a great experience working on project Aurora and hopes to bring new concepts on future
missions. We are satisfied with the result we could achieve during the COVID-19 Pandemic and very content with
the upgrades that Aurora received, since Antares last rocket project, Anhangá.
Some of the lessons learned along the way includes learning how to properly design an avionics subsystem containing
telemetry, use mechanical stress simulations to improve the projects and learning to deal with different kinds of
materials, such as balsa wood for the avionics bulkheads and aluminum for the engine.
We would like to thank the Latin American Space Challenge organizers, for making this event possible and
for making it possible for aerospace enthusiasts to get together and share projects. Events like this are of pivotal
importance for the aggrandizement of the aerospace sector.

29
Appendix A

Weights, Measures and Performance

Data

30
 In this appendix the team will display figures containing Weights, Measures, and Performance Data for the Open
Rocket simulation.
After designing the engine, the estimated Thrust x time curve is obtained using Richard Nakka’s combustion
chamber spreadsheet.

Figure A.1: Estimated Thrust x time curve

In possession of this data, it is possible to create a .eng file using the TcTracer software, which is a file containing
the data just as a csv file would, and import it on Open Rocket.

Figure A.2: Engine characteristics

Using Open Rocket, the team ran simulations and here are some of the data gathered, to assure a safe flight
expectation. Two important observations are that the launch rail that Antares has is 4.2 meters long, so this is the
launch rod length used in the simulations, and the latitude and longitute used for the simulation are those of the city
of Tatuı́, located in th state of São Paulo, Brazil.

31
Figure A.3: Open Rocket simulation settings

Figure A.4: Open Rocket simulation results

32
 Table A.1: Flight simulation data

Velocity off rod [m/s] 16.7

Apogee [m] 1016
Velocity at deployment [m/s] 17.1
Maximum velocity [m/s] 147
Maximum acceleration [m/s2 ] 51.5
Time to apogee [s] 15.6
Flight time [s] 164
Ground hit velocity [m/s] 6.74
Pre-flight CP location, measured from the nose [mm] 1117.0
Pre-flight CG location, measured from the nose [mm] 938.0
Pre-flight stability margin [-] 1.75

And now, for the estimated mass of the components and subsystems of Aurora:

Table A.2: Components mass

Nose cone [g] 426

Crimson powder ejection charge [g] 7
Upper fuselage [g] 274
Parachute [g] 390
Parachute bulkhead [g] 394
Coupler [g] 160
Lower fuselage [g] 323
Coupler top bulkhead [g] 19
Avionics [g] 825
Payload Electronics [g] 525
Coupler lower bulkhead [g] 17
Payload top bulkhead [g] 215
Payload lower bulkhead [g] 215
Thrust Plate [g] 131
4 fins [g] 123
Fins support [g] 68.3
Propellant [g] 931
Combustion Chamber [g] 453
Nozzle [g] 409
Combustion chamber internal insulator [g] 107
Tail Cone [g] 107
External camera support [g] 27
2 rail guides [g] 31.8
Screws [g] 135.9
Sum of all [g] 6313

The total payload mass (electronics and structure) is 955g. The following picture illustrates the final Open Rocket
diagram.

Figure A.5: Open Rocket final diagram

33
Appendix B

Hazard Analysis

34
 The hazard analysis was a fundamental stage on the team’s project. As a team, as we were studying what and
how we could improve from the previous design to reach the 1km apogee, the scanning of potential risks that the
upgrade could cause and how we could mitigate those problems were one of the team’s firsts concerns.
Similar to our last project Anhangá, the stage of the project that made us the most concerned was the handling of
the propellant material, as well as its storage and transportation. To deal with that, before initiating the process of
the manufacturing of the propellant, we documented the precautions of each phase of the process. About this stage,
our biggest concern was the risk of the propellant being subjected to an unexpected ignition in its manufacturing,
storage or transportation. To reduce the chances of this accident happening, on the confection process the team used
an induction stove to minimize the risk that a direct source of heat, such as a gas stove, would bring to the operation,
that risk being the chance of igniting the material on its making. Additionally, in every step in this process the
operating personnel used EPIs, such as protective glasses and gloves to ensure that the operators were protected in
the event of a disaster.
Another topic that we were cautious about was about the conditions of the place where we would store our grain
of KNSB. In this situation, aside from the chance of the unexpected ignition, the team was also worried about the
humidity that the store unit could transfer to the propellant, because if that happened, the efficiency of its performance
would be deeply affected, at the risk of not being able to even ignite. To mitigate that issue, the alternative the team
encountered was to store the grain in a fresh and dry environment.
At last, the transportation of the propellant didn’t bring a high precaution to the team since it was the stage in
which the chances of self ignition were almost null if we maintained it in a dry and cool ambient, which in our case was
a case of polystyrene. The thing that worried us was the possibility of the grain getting fractured or broken, because
if that happened its performance would be affected due to a variation on its geometry. To solve that problem, the
polystyrene case we put our grain had a shape which inhibited it to move inside of it, preventing it to be subjected
to possible abrupt movements.

35
Appendix C

Risk Assessment Appendix

36
 Table C.1: Risk Matrix

Failure Mode Mission Phase Failure Mishap Critically Team’s Comments

Probabil- Severity Ranking
ity
Ignitor disconected Ignition Phase 2 1 2 The ignitor may be discon-
nected from the ground base,
causing it to not fire when the
trigger is pushed.
Ignitor’s Moisture Ignition Phase 2 1 2 If the ignitor contains much hu-
midity, it is at risk of not work-
ing properly and when acti-
vated, the crimson powder may
not ignite as expected.
Propellant’s Mois- Ignition Phase 1 2 2 If the propellant gets too hu-
ture mid in its manufacture or on its
storage, it may not ignite with
the ignitor.
Accidental Ignition Ignition Phase 1 3 3 Due to temperatures varying or
even an unexpected source of
heat may cause an unexpected
ignition, wich would turn the
rocket a safety hazard.
Combustion Cham- Thrust Phase 1 3 3 The pressure inside the com-
ber Critical Failure bustion chamber may exceed
the limit that it suports, caus-
ing an explosion an loss of the
mission.
Screw Beheading Thrust Phase 1 2 2 A screw of the structure may
be beheaded due to an excess of
stress on it, causing it to frac-
ture and putting the integrity
of the structure at risk.
Structure’s Material Thrust Phase 1 2 2 The more fragile material such
Meltdown by High as the plastic used in the avion-
Temperatures ics of the rocket may melt due
to high temperatures reached
in the thrust phase.

37
Failure Mode Mission Phase Failure Mishap Critically Team’s Comments
Probabil- Severity Ranking
ity
Coupler Disruption Thrust Phase 1 3 3 Again, if the stress on the fuse-
due to Force G lage due to the force G of
the rocket on the thrust phase
gets to a higher value than
programmed, the coupler may
disrupt, discomposing all the
rocket structure.
Nozzle Clogged Up Thrust Phase 1 3 3 The nozzle may get clogged
due to Unexpected up by a particle originated
Particle by an impurity of the propel-
lent, which would cause a peak
of pressure in the combustion
chamber, leading to an explo-
sion.
Internal Insulator Thrust Phase 1 2 2 The burning of the propellant
Melting may reach higher temperatures
than expected, melting the in-
ternal insualtor and causing
damages to the engine.
Parachute getting Apogee Phase 1 2 2 Because of its strings and size,
tangled up when ejected the parachute
may get tangled up and not
open, therefore failing to make
a safe recovery.
Parachute’s Crim- Apogee Phase 1 2 2 Similar to the ignitors mal-
son Powder Mal- function, the crimson powder
function responsible to eject the nose
and the parachute may not
work, impossibilitating the de-
ployment of it.
Fuselage Rupture by Apogee Phase 1 2 2 When the crimson pow-
Crimson Powder’s der explodes to deploy yhe
Explosion parachute, the explosion may
be bigger than expected,
affecting the structure of the
fuselage.

38
Failure Mode Mission Phase Failure Mishap Critically Team’s Comments
Probabil- Severity Ranking
ity
Parachute’s Crim- Apogee Phase 1 3 3 Since the ignitor receives an or-
son Powder Ignitor der to ignite from the avionics
bad contact when it’s close to the apogee,
if there is an bad conection be-
tween those components, the
ignition should fail and the
parachute will not be released.
To prevent this, the conection
is made with screw connectors
and cable terminals.
Altimeter malfunc- Apogee Phase 1 2 2 The sensors that activates the
tion parachute deployment may suf-
fer a malfunction or may be
uncalibrated, making it impos-
sible to detect the moment of
the apogee, making it unable
to eject the parachute, there-
fore failing to make a safe re-
covery.
Loss of communica- Rocket Landing 3 1 3 The comunication uses a LoRa
tion Phase module with an omnidirec-
tional antenna transmit infor-
mation. It works ideally when
the rocket is ”standing”. Since
it lays down on the solo when
reaches the ground, the an-
tenna stops workind ideally,
and there is a loss of commu-
nication
Loss of GPS Signal Rocket Landing 3 1 3 The GPS uses an patch an-
Phase tenna to comunicate with satel-
lites. It works ideally when
the rocket is ”standing”. Since
it lays down on the solo when
reaches the ground, the an-
tenna stops workind ideally,
and there is a loss of signal

39
Appendix D

Engineering Drawings Appendix

40
In this appendix, the team will display the technical drawings for the components in Aurora. All the technical
drawings are drawn in first angle.

D.0.1 Avionics Subsystem

Circuit Board Tower:

Figure D.1: Avionics circuit board tower.

41
Avionics spider connection between upper coupler bulkhead and the upper subsection of the avionics subsystem:

Figure D.2: Avionics spider connection.

42
Avionics subsystem upper bulkhead, to lock with the coupler in the fuselage:

Figure D.3: Avionics top bulkhead.

43
For the triangular shaped subsection in the payload and the avionics, we have the same vertical support plate:

Figure D.4: Circuit board vertical support.

44
 Lower avionics bulkhead:

Figure D.5: Lower avionics bulkhead.

45
 Middle avionics bulkhead:

Figure D.6: Mid avionics bulkhead.

46
 D.0.2 Payload
Other than the three circuit board vertical supports included in the payload structure, the payload bulkheads
(upper and lower bulkheads) are shown below:

Figure D.7: Payload Bulkhead.

47
 D.0.3 Fins Bay
Airfoil Fin (Symmetrical profile):

Figure D.8: Symmetrical airfoil fin.

48
 The Fins support is an exquisite piece of work. The dimensions could not be completely displayed using Creo
Parametric 3D technical drawing software, but in order to explain in details the functionality of this piece, the team
decided to write a few comments in this appendix.

Figure D.9: Fins support.

49
 Figure D.10: Fins support close up.

The functionality of the rail system built on the fins support is to slide the small square part of the tail cone in, like
it is inside a little ”maze”. After locking in place, it would be extremely hard, if not impossible, for the tail cone to
escape the back of the rocket. The dimensions of this small ”maze” really doesn’t matter, so long as the ”maze”
does not interfere with the other parts of the piece. It is important to notice that almost all edges are rounded, in
order to reduce any stress, because this piece cannot be susceptible to any risk of mechanical fracture.

50
 D.0.4 Recovery
Parachute Bulkhead:

Figure D.11: Parachute Bulkhead

51
 D.0.5 Engine:
Combustion Chamber:

Figure D.12: Hyperion’s combustion chamber.

52
 Nozzle:

Figure D.13: Hyperion’s nozzle.

53
 Thrust Plate:

Figure D.14: Hyperion’s Thrust Plate.

54
 D.0.6 Other parts:
Nose Cone:

Figure D.15: Aurora’s fiberglass von kárman nose cone.

55
 Tail Cone:

Figure D.16: Aurora’s tail cone

56
 Tail cone locking ring:

Figure D.17: Aurora’s tail cone locking ring.

57
 External camera support:

Figure D.18: Aurora’s external camera support.

58
 Rail guide:

Figure D.19: Aurora’s airfoil rail guide.

59
Bibliography

[1] J.R. Brohm, The Mathematics of Flat Parachutes

[2] Gary A. Crowell Sr., The Descriptive Geometry of Nose Cones

[3] Richard Nakka, Richard Nakka’s Experimental Rocketry Web Site

60