High Powered Rocket Level-1 (HPR Lvl-1):

Classifying a Rockets according to their total impulse:

• Rockets that goes to moon/mars, or to an earth orbit are called orbital class rockets;
• Those going below 100-250Km are called sounding rockets;
• Below 100Km are called high powered rockets, but they are sub-classified:
  
  • As per NAR(National Associatoin of Rocketry):

High Powered Rocketry in the USA:
FAA governs the US air space and have defined some guidelines:
Amateur Rocketry Guidelines

Software Organization:

Algorithms:

• Noise Filtering:
  • Low pass filter
  • Butterworth filter
• Sensor Fusion:
  • State Estimators
  • Kalman filter

to be completed ...

Design Overview:

to be written ...

Avionics Overview:

Here is a general overview of the different sensor and library files this repository includes. Firstly, what is a library file? A library/header file is a layer where you directly communicate with a given object of some given library class. Each Library has respected high-level functions that communicate with corresponding registers that carry meaningful data that the sensor populates into its memory.

The Communication protocol: Each sensor has a specific communication protocol associated with its header pins, ports that take in/put out some information. Among the three communication protocols, two are mostly used: SPI Serial Peripheral Interface, I2C Inter-Integrated Circuit, and UART Universal Asynchronous Receiver/Transmitter. Each of these has standard header pins to which you can connect wires from your microcontroller.

For SPI each sensor requires a MISO: {Master in Slave out(Data flowing out of the sensor to your parent microcontroller, ex: write2_BMP_regX())}, MOSI: {Master Out Slave In(Data coming out: getData_fromRegisterX)}, a clock pin which matches the signal message rate{baud rate} with the parent microcontroller and a CS {Identifier pin}.

The name Inter-Integrated Circuit comes from the simplicity and pre overhead organization that is done on these communication lines: the I2C automatically has respected MOSI/MISO command specifiers within each byte of information which leads to the need for one communication header pin: SDA and one clock pin-SCL to match the baud rates of the parent and child sensor.

UART uses Wires: 2 — TX (transmit), RX (receive) with no clock due to the asynchronous behavior of these sensors.

Ok, so we went over the different communication protocols of the sensors we will be using, each has it's unique wiring to lead to proper data transmission. Our sensor stack includes a 10DOF IMU {Inertial Measuring Unit} which uses a I2C comm. protocol. these 10DOF are acceleration_x,acceleration_y. acceleration_z. a related magnetic field vector per our sensor frame: Mx, My,Mz. the omega vector {rate of change of our angle}: Omega_x, Omega_y, and Omega_z. and a Pressure sensor which we can read pressure or a converted altitude.

In addition to our IMU we have a GPS that communicates with the Global Navigation Satellite System which gives us a position vector of Px, Py, Pz.

And to store these values we had a SD Card Reader which is initialized with and SPI comm. protocol.

Each of these sensor has it's own respected .hpp files which has a general startup() function that checks to see if proper values are getting received/communication is properly initialized cooresponding to the physically connected wired ports to our ESP32 and a getValue function that returns the data to the main.cpp file where it is read and stored into the SD card.

In the main flight software we are reading files and checking for flight conditions: these flight conditions are as followed: isLaunched, isApogee, isLanded. The logic for finding correct event detection uses the accelerometer and pressure sensor of our tech stack. We collect a N sized array which has a collection of pressure values over some time frame, we divide this array into two sections a prevSubArray and a currSubArray. These arrays will be used to see if our values are consistently changing per some flight condition. We first populate this array and collect the average and variance to help mitigate the inherent noise of our sensors. After this initial population is finished we then start our flightChecks, where at each timestep the main N_sized array is left-shifted adding the pressure value given by our BMP. and we compute the difference of these subArray means to see if pressure is consistently lowering, raising, or static. If the currSubArray is consistently less than our prevSubArray over some threshold value: counter, meaning we are ascending, {pressure decreases the higher alt one goes}: we activate our flight condition boolean isLaunched and start checking for isApogee: (If pressure is continuously raising over a counter threshold.) Finally, after isApogee is true we check for isLanded. The difference between these twoSubArrays are below a threshold over some landingCounter.

Future Experimental Functionalities/Payloads(not relevant to the HPR certifications):

• Custom Radio Communication module
• Reaction Wheel for stabilization of the Roll Axis
• Fin Control/Thrust Vector Control