Second Test Flight Report

By

Avionics report

As we are the brains of the rocket we have some tasks we want to achieve at the end of each launch:

- Log flight data

- Transmit flight data

- Check for apogee

- Fire parachute

- Build the flight computer

1. Log flight data

We were not able to equip the rocket with an SD card is it was throwing some errors just before flight. We had tested it and it worked previously. So we didn't want to take more time debugging the problem as we had a backup for that. If we could be able to transmit the data well and good. As we would be able to log the data on the ground station.

Recommendations

- Test the SD card and make sure it is working prior to launch

- Figure out a way to write to the internal flash system of the rocket


2. Transmit flight data

We were able to transmit flight data from the rocket to the ground station. We used the Lora module and we were able to send a packet back to the base station

Recommendations

- Beef up the base station as to not rely on Putty and borrow Propulsion flight logging

- Reduce payload size for transmission

- Handle queue properly. This is due to the fact that tasks in core 0 run 4 times faster than tasks in core 1, which is sending data over Lora. We would need the Lora task to send all the 4 data points pushed to the queue as the current implementation only sent one and read the other 3 out of the queue. This was to remove queue full error

- Change the packet type to binary as some of the text was not UTF-8 encoded. Also, we need to do a parity check to ensure what we are sending is what we are receiving. This would necessitate an encoder and decoder algorithm

- Our last packet sent was in flight. We don't know why it didn't send up to the time we had an impact


{"counter":1074283032,"sensor altitude":1704.048,"ax":0.269,"ay":-1.459,"az":-10.051,"gx":-0.155,"gy":-5.172,"gz":-0.117,"filtered s":1711.125,"filtered v":-176.426,"filtered a":-41.354,"state":0,"gps altitude"n\BA

7\A52\C8\E4\ED\A2S\F4\FC\BE\98\98vsU̬\BC\C9\00'\81\CB,\FE<\CD\95\EF\AA\iü


3. Check for apogee

We were not able to detect apogee as our last packet still read we were on state 0. This was due to a few errors on the check state as we were to require burnout time from the propulsion team.

Recommendations

- Analyse the check state

- Implement a reverse shell to initiate the firing of the parachute as a backup

- Not rely on time but on altitude, velocity and acceleration from our sensors


4. Fire parachute

When we did a partial inspection of the avionics system. We saw the ejection charge had been fired. This doesn't correspond to our telemetry data. We will investigate why the two have disparities and try to correct them. The ejection was fired but the parachute wasn't ejected. This might be attributed to the fact that the parachute provided more force hence the ejection charge ejected towards the avionics bay.

Recommendations

- Test the parachute ejection continuously before launch

- Introduce a redundancy mechanism e.g watchdog timer


5. Build the flight computer

We were able to build the flight computer. The one from gearbox was poorly done so we resorted to using etching to fabricate one. Unfortunately, we still had the problems of wires creeping over.


This is the Fabricated PCB



This is the assembled PCB



Avionics bay assembly









Recommendations

- try and build the computer days before launch so as to run as many as possible tests on it.


Flight data

Filtered altitude from the Kalman filter



The actual sensor readings from BMP



Altitude velocity and acceleration data




From this data, we were to have a high chance of detecting apogee as the velocity curve moves from the +ve region to the -ve region nicely. We are using velocity to detect apogee and we have given it a buffer of +1 to -1.


Airframe report

As we are the fuselage of the rocket we aim to achieve the following tasks before launch:

- Build the fuselage of the rocket

- Integrate all subsystems

- Do recovery mechanisms


1. Build the fuselage of the rocket

We were able to build the fuselage of the rocket. We build the body tube attached the fins using glass fibre and also attach the nose cone.

Recommendations

- Secure the nose cone properly to avoid entry into the rocket. As we landed the nose cone went inside the body tube pressing onto the components inside


2. Integrate all subsystems

We were able to integrate all the subsystems of the rocket. We used PVC tubing to secure the avionics and flight control components to the rocket. 

Recommendations

- Add a way in which avionics can power their board before entry into the fuselage

- Assemble components one day to launch



3. Do recovery mechanisms

We were not able to recover the rocket after apogee. This might be due to the fact that the parachute exerted more force hence the explosion didn't let the parachute out. The rocket dug into the ground at impact.

Recommendations

- Test the recovery system days before launch

- Think of a new way to recover the rocket


General

- We were able to integrate all the subsystems better than on the first test flight.

- We were not keen on timing and we ended up launching in the evening.

- We took wind measurements before and the FC gave permission to go for launch

- We didn't do an openrocket final simulation before launch.

- We had a checklist for each subdivision and every subdivision passed the checklist

- We were not able to arm the rocket we flight control as we haven't integrated the flight control code into the avionics code.

- We observed the launch sequence to the latter

- The RSO ensured that all people were at a safe distance of 50m from the launch site

- Ignition worked well but we aim for remote ignition

- We achieved an apogee of 280m from the launch.

- We were not able to deploy the parachute hence we didn't have good recovery means

- Flight commander will give more details on what went through the launch.


Data

1. Filtered data points

2. Raw data points


Gallery









Comments

Post a Comment

Popular posts from this blog

USING NEO-6M GPS MODULE AND INTERFACING IT WITH ESP32

By
Image
  This tutorial will cover NEO-6M GPS Module and how to interface it with ESP32. 1.1 The NEO-6M GPS module The NEO-6M GPS module is a type of GPS receiver that utilizes the u-blox 6 positioning engine to provide location and timing information. Many GPS-based projects, including tracking gadgets and navigation systems, frequently employ this module. It supports the GPS, GLONASS, Galileo, and QZSS satellite systems and has a very sensitive receiver that can track satellites in difficult terrain. The module is a popular option for a variety of applications due to its small form size, compact form factor, low power consumption, and multiple communication interfaces. NEO-6M GPS module can track 22 satellites and identify locations anywhere in the world. Some of its specifications are: ·        GPS chipset: u-blox NEO-6M ·        GPS module frequency: L1, 1575.42 MHz ·        C/A code: 1.023 MHz chip rate ·        Channels: 50 channels, GPS L1(1575.42Mhz) ·        Track
Read more

PCB ETCHING PROCESS

By
Image
 Are you tired of having to use a bread board for your projects? Do you get tired of all the wires that you use and the hustle of remembering which wire goes to which hole on the bread board😕? Well look no further, you are in the right place😌. This is a simple guide to being able to design and fabricate your own PCB at home for either a personal project of a school project. At the Nakuja project we design our PCB's for avionics and flight control systems using design software such as EasyEDA, print the designs, etch the PCB and do our own soldering of the components onto the PCB.  This blog is designed to give you a step by step guide of the etching process. I hope you enjoy making your PCB!! Materials required Board design (after using EasyEDA, Eagle, etc. to design it) clothes iron copper clad board sand paper cupric chloride water plastic dish or basin PCB drill soldering iron solder wire NOTE: the etching solution is CORROSIVE and toxic hence should be handled with care and
Read more

LOG SENSOR DATA FROM ESP32 TO AT24C256 I2C EEPROM

By
Image
In this tutorial, you will learn how to log sensor data from several sensors -MPU6050 and BMP 180- to an EEPROM module from an ESP32 module This tutorial assumes prior working knowledge with Arduino IDE or Platform IO 1.1 Introducing EEPROM EEPROM (Electrically Erasable Programmable Read Only Memory) is a Electrically Erasable Programmable Read-Only Memory (EEPROM) is a steady, non-volatile memory storage scheme that is used for storing minimal data quantities in computer and electronic systems and devices, such as circuit boards. By applying a higher-than-normal voltage, data can be erased and be reprogrammed to it.  Electrically Erasable Programmable Read Only Memory (EEPROM) is a type of user modifiable ROM that  can be erased and reprogrammed (written to) repeatedly by applying an electrical voltage that is higher than normal. It enables individual bytes of data to be erased and reprogrammed.  EEPROM need not be taken out of the computer or electronic device of which it is part whe
Read more