Project Overview

Briefly describe the project's goals and its context (for Launch, this will be a competition, onboarding, or R&D)

Table of Contents

Pages

Goals

Post-mortem

The Good

All systems of the rocket were finished in time for the launch day, without the need to pull multiple all nighters to get it there.

All portions of the rocket were recovered and fairly well documented.

Division of labor between the various sub teams was fairly even, given the context of what each sub team was working on.

Team leadership felt cohesive and communication between leads was mostly clear and consistent.

The Bad

Following an accidental launch of the rocket by URRG officials, the rocket experienced a RUD, with the rocket separating into 3 sections: nosecone and parachute, upper half of the rocket, and lower half / booster section of the rocket. The parachute and nosecone drifted into the field, the upper half of the rocket fell and landed next to the rail, and the booster section went ballistic, impacting a field ~0.5km away. All sections of the rocket still in existence were recovered. Launch Initiative Members responded quickly to the situation and successfully disarmed the black powder charges in the upper half of the rocket as per SOP. One recovery team collected the parachute and nosecone from where they had drifted in the field, while the other recovery team located and dug out the booster section.

The RUD of the rocket was likely caused by an uneven connection between the booster and polycarb sections of the rocket, and possibly asymmetrical motor burn. The joint between the two aforementioned sections was uneven, and likely caused there to be uneven trust transfer up the rocket, causing the wobble exhibited by the rocket. In the case of asymmetrical motor burn, not much could have been done except perhaps closer inspection of the motor prior to integration with the rocket. There was a series of other structural failures that occurred after the rocket broke into 3 pieces, and while some improvements could have been made during manufacturing it is unclear weather they could have been mitigated (such as snatch cord tearing) given the failure mode of the rocket. More detailed documentation of the various failures of the rocket is available in the team drive.

Overall the main lesson learned is that space race should have more active oversight from more senior members of the club in order to identify and correct potential mistakes during the manufacturing of the rocket. Furthermore, a much more intensive pre-flight check is needed in order to ensure the rocket is flight ready and identify any critical errors the space race team might not notice or otherwise minimize due to an (understandable) desire to get the rocket in the air.

Furthermore, Launch Initiative members need to feel more empowered to push back on directives from URRG officials they find to be unsafe, and it should be stressed that when the igniter is in the rocket engine, it is armed, and should be treated as such due to all the implications of that fact.

Design overview

Payloads

Payload Requirements

Mission requirements

URRG Requirements

Interface Requirements

Design

The Payload of the FLDSMDFR contains several delicate electronic components contained within a polycarbonate section of tube. Going from the bottom up these components are: a speaker, a camera, fairy lights. In between the speaker and cameral there is a centering ring (originally designed to be a bulkhead with a door on it) that does not allow the camera to fall onto the speaker.

Post-mortem

Despite the overall breakup of the rocket, all electronic components of the payload survived the launch. The speaker is heavily damaged and its buttons no longer work as intended, but it is still able to play sound and continues to be able to pull said audio from the SD card inside. The camera has residue on its lens, but is otherwise completely operational. The fairy lights are fully operational. The payload as a whole worked as intended despite a severely off-nominal launch.

Avionics

Avionics Requirements

Mission Requirements

Derived from the goals.

URRG Requirements

Describe what an external organization (probably ESRA, URRG, or EH&S) requires of this one.

Interface Requirements

Describe what other subsystems require of this one.

Design

This should describe high-level distinguishing features of this subsystem. If this project is recurring (Space Race or IREC), focus on the items you judge would be important to tell the next year's team, especially specific improvements over previous years.

The Avionics Bay used 2x Eggtimer Quarks powered by 2x 7.4V 2000mAh Li-ion Batteries. The flight computers were wired entirely independently.

For tracking, the Avionics Bay used 1x Eggfinder Mini TX powered by 1x 7.4V 2000mAh Li-ion Battery to transmit signals from the rocket, and 1x Eggfinder Dongle RX connected to a laptop to recieve signals on the ground.

For Data Logging, the Avionics Bay used 1x Adafruit Feather M0 Adalogger powered by 1x 3.7V 2000mAh Li-ion Battery. The datalogger system utilized two breakout boards, 1x Adafruit BME280 to record temperature and pressure (and thereby altitude) and 1x Adafruit ICM-20948 9-DoF IMU to record acceleration, rotation, and orientation. All data recorded would be written to 1x 4GB microSD Card hot glued into the mainboard.

Post-mortem

Due in part to the catastrophic nature of the rocket’s launch, the only avionics system operating when the rocket was launched was the tracking system.

Despite the unanticipated forces applied to the avionics bay during the flight, the tracking system continued operating through its entirety, eventually successfully reporting the final coordinates of the avionics bay (42.700473°, -77.194522°).

Over the course of the flight the avionics bay experienced multiple structural failures. The most important to note is that several of the battery mounts sheared off such that they no longer constrained the Li-ion batteries. This is potentially due to the orientation of the layer lines in the 3D prints combined with the higher than anticipated forces. It is worth examining layer line orientation in the future to reduce the chances of loose Li-ion batteries in rocket, successful or not. The attachment keeping the avionics bay constrained to the polycarb tube also sheared, though this is likely due primarily to the higher than anticipated forces, and likely could not have been reasonably mitigated.

Aside from flight complications, assembly of the avionics bay should have been given more design considerations. Some screws and nuts were placed in tight spaces, making accessing them for assembly and disassembly difficult, though not impossible.

Additionally, integration of the avionics bay with the rest of the rocket should also have been given more design considerations, as integration while the e-matches were connected was difficult, though again not impossible.

In the future, when evaluating whether or not to turn off avionics systems:

• It must not be done while the igniter is still in the motor.

• The decision should be made in the context of the battery life of the avionics systems contrasted with the expected delay.

Structures

Structures Requirements

Mission Requirements

Derived from the goals.

URRG Requirements

Describe what an external organization (probably ESRA, URRG, or EH&S) requires of this one.

Interface Requirements

Describe what other subsystems require of this one.

Design

This should describe high-level distinguishing features of this subsystem. If this project is recurring (Space Race or IREC), focus on the items you judge would be important to tell the next year's team, especially specific improvements over previous years.

The Structure of FLDSMDFR has various key features. Past years contain a payload section, avionics bay, and recovery section. This year was different from previous years by including a poly carb tube, soda can, and a smoke flare.

The polycarb tube had allowed Payload’s camera get a clear view of flight. It was critical to get a good mount for the polycarb tube to the Blue Tube. We believe that this is where some issues may have arose. There had not been a clean cut on the Blue Tube, leaving a gap between the two sections. Another mistake was with the way we connected the two sections, the Bee Keeper’s had connected the two sections and then drilled the holes, we had drilled the holes then tried to connect them. It would be much easier to do it the same way the Bee Keeper’s had done.

The soda section had been secured using a 3D printed container. On the top it was sealed using a wooden bulkhead and was made sure to be water-tight. This was to prevent any liquid possibly ruining the structure of the Blue Tube.

In our design we needed to be aware of the mass and space that smoke flare would take up. This is important as the extra weight affects the center of gravity along with the fin flutter. Further details of the smoke flare can be found under recovery.

Post-mortem

Looking back, one of our biggest issues was most likely the connection between the polycarb tube and the Blue Tube. Upon analysis after the launch, it was concluded that this maybe the biggest place where we went wrong. This connection maybe what lead to the failure of the rocket. We have discussed that in future years we need to ensure our builds need to be further inspected. Producing a rocket that has parts that are just “okay” is not enough. We need to ensure that our rocket is to the highest factor of safety as we can, to ensure the best results.

Almost all of the rocket was recovered, which in some ways, made it easy to try and analyze what went wrong. Having both the rocket pieces and videos helped this process immensely. We have an intact Payload, had been able to see where/when the parachute had deployed, along with the structural elements of the rocket. As mentioned, we had not been fortunate to get any real data from the avionics bay, as the avionics only had the tracking system working and it landed right next to the pad.

We truly need to have a closer inspection of the rocket before launching. Taking into consideration different components of the rocket and worse case scenarios to have the highest level of safety and produce an overall better rocket.

Recovery

Recovery Requirements

Mission Requirements

Derived from the goals.

URRG Requirements

Describe what an external organization (probably ESRA, URRG, or EH&S) requires of this one.

Interface Requirements

Describe what other subsystems require of this one.

Design

This should describe high-level distinguishing features of this subsystem. If this project is recurring (Space Race or IREC), focus on the items you judge would be important to tell the next year's team, especially specific improvements over previous years.

Post-mortem

In Progress