2023-2024 xpa7234@rit.edu
Notes for user (DELETE WHEN DONE)
Anything enclosed in angle brackets <> means you should replace it with the appropriate name:
<PROJECT> becomes e.g. "SAC '24 OMEN"
<SUBSYSTEM> becomes e.g. "Avionics"
Italicized text is a comment/instructions from the template creator(s).
During the project's lifetime, this page should be a useful reference for information. After a project is done, you should be able to send this to someone, and they should not have to ask questions about what the project and each subsystem intended to accomplish and actually accomplished.
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
Goal | Reason |
|---|---|
Utilize a reefed parachute to recover rocket | One main parachute instead of separate drogue and main chutes |
Capture data from environment | Monitor flight performance and capture video |
Deploy smoke flare | Eye tracking |
Post-mortem
When the project is done, go over, according to your judgement, what went right and wrong.
Design overview
Structures
Team members:
Brice Afko, MECE, 2nd year: Subteam lead, Openrocket, CAD, General Design
Reuven Gifeisman, MECE, 2nd year: Openrocket, CAD, General Design
Andrew Hughson, MECE, 1st year: CAD
Quinn Donahue, CPET, 1st year: CDR Prep, CAD
Chimamanda Eze, MECA, 1st year: CDR prep, CAD
Requirements
Mission requirements
Derived from the goals.
Requirement | Reason | Verification |
Apogee under 18000 ft | URRG Range Rule No.9 | Open-Rocket Analysis |
All parts recovered | URRG Range Rule No. 10 | Design |
Stability between 1 and 4 calibers throughout flight. | URRG Range Rule No. 10 | Analysis |
Thrust-to-weight ratio of 5:1 or better | URRG Range Rule No. 10 | Open-Rocket Analysis |
Interface requirements
Requirement | Reason | Verify by |
Vents in payload bay | The smoke is able to escape the rocket | Design |
Avionics bay has visibility to outside | Cameras in avionics bay can view reefing system | Design |
Avionics bay easily separable from recovery and payload bays | Allows flight computer and smoke flare to be easily removed and inserted | Design |
Screw switch and vent holes in avionics bay | Passage of screwdriver to activate switch and equalization of pressure with atmosphere | Design |
Flight computer can be locked in place | Prevents flight computer from sliding or rotating in avionics bay | Design |
Design
General Layout
Specifications:
Mass: 14 pounds
Average thrust to weight ration: 16
Total length: 79 inches
Booster
Section covering - Blue tube
Motor: Cesaroni 2771L990-P
7 plywood centering wings
4 to keep motor centered
3 with slots for fin placement
0.125” thick
24” long
Lower rail button
Thrust plate
Thrust plateAluminum
6 tapped #8-32 holes
Epoxied to the blue tube
Retainer is connected to the thrust plate with machine screws.
Motor Retainer
Aluminum
6 clearance holes for #8 screws
Centering Rings
0.125” Plywood
7 rings total
Fins
4 carbon fibre fins
Root chord: 6”
Tip chord: 3”
Height: 4”
Fin tab height: 0.8”
Thickness: 0.125”
Payload Bay
Section covering - Blue tube
2 bulkheads
One to support smoke flare weight
One as protection from booster
10.625” long
Two holes line up with smoke flare vents
4 clearance holes for screws which will fasten avionics bay
Post-mortem
When the project is done, go over, according to your judgement, what went right and wrong.
<SUBSYSTEM: COPY ALL CONTENTS PER SUBSYSTEM>
<SUBSYSTEM> requirements
Mission requirements
Derived from the goals.
Requirement | Reason | Verification |
|---|---|---|
|
|
|
<EXTERNAL> requirements
Describe what an external organization (probably ESRA, URRG, or EH&S) requires of this one.
Requirement | Reason | Verification |
|---|---|---|
|
|
|
Interface requirements
Describe what other subsystems require of this one.
Source(s) | Requirement | Reason | Verification |
|---|---|---|---|
|
|
|
|
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
When the project is done, go over, according to your judgement, what went right and wrong.
<SUBSYSTEM: COPY ALL CONTENTS PER SUBSYSTEM>
<SUBSYSTEM> requirements
Mission requirements
Derived from the goals.
Requirement | Reason | Verification |
|---|---|---|
|
|
|
<EXTERNAL> requirements
Describe what an external organization (probably ESRA, URRG, or EH&S) requires of this one.
Requirement | Reason | Verification |
|---|---|---|
|
|
|
Interface requirements
Describe what other subsystems require of this one.
Source(s) | Requirement | Reason | Verification |
|---|---|---|---|
|
|
|
|
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
When the project is done, go over, according to your judgement, what went right and wrong.
<SUBSYSTEM: COPY ALL CONTENTS PER SUBSYSTEM>
<SUBSYSTEM> requirements
Mission requirements
Derived from the goals.
Requirement | Reason | Verification |
|---|---|---|
|
|
|
<EXTERNAL> requirements
Describe what an external organization (probably ESRA, URRG, or EH&S) requires of this one.
Requirement | Reason | Verification |
|---|---|---|
|
|
|
Interface requirements
Describe what other subsystems require of this one.
Source(s) | Requirement | Reason | Verification |
|---|---|---|---|
|
|
|
|
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
When the project is done, go over, according to your judgement, what went right and wrong.