Membership Requirements

Attendance Requirement

Every member is expected to attend General Meetings; if you have a recurring conflict, you may be excused from this requirement. According to our constitution,

Failure to attend at least three-fourths of general and subteam meetings may result in loss of active member designation as stated in Article III.

Subteam leads will note attendance at GM and subteam meetings.

Outreach Requirement

Every member is expected to participate in two hours of Outreach per year. Contact the Outreach & Marketing Lead for details; usually signups will be announced on Discord. These are extremely fun and rewarding opportunities to

Documentation Requirement

Every member is expected to make one contribution to project documentation each semester. Contact your subteam documentation liaison for what this entails; contributions range from creating an entire tutorial to fixing minor errors in a GitBook page. Thanks for helping out!

Elections

While not a requirement, active members are invited to participate in subteam and general elections.

Rules are detailed in our constitution, which can be found at the link below--choose the most recent version. The constitution is the only authoritative source for rules concerning elections. That being said, election information will be generally outlined below for your convenience.

We are proud to say that all of our official technical and administrative leadership is elected!

Elections are usually run by the President and Vice President, although there is no constitutional requirement as to the body that must hold the elections or the manner in which they are to be carried out.

Generally (although again not codified), we strive to have elections follow these principles:

• Free and Fair: only eligible members vote, and follow one-person-one-vote. All eligible votes are counted, and a reasonable effort is made to make sure any eligible member can vote if they desire. No eligible member is prevented from running for a position.

• Confidential: use some form of secret / Australian ballot; you have a right to vote without others knowing your choice.

• Transparent: the results and process should remain accountable and subject to re-count.

Rules

Term Length

From the constitution,

Elections will occur towards the end of the spring semester but prior to the last day of the semester. The Executive Board will serve a year-long term starting after the final competition event, even if that competition event is held in summer.

This allows for relatively constant leadership for each project, or each school year in the event that a project lasts for multiple years.

Club-wide Elections

This includes positions like the President, Vice President, Documentation Lead, Logistics Lead, and Business Lead. From the constitution,

Club-wide positions will be elected through a simple majority vote of all active members. If a simple majority has not voted for a single candidate, the two candidates who have received the most votes will enter a runoff election with simple majority vote. A person is allowed to vote if they have been an active member on the team for at least a semester prior to the election.

Active membership is defined in the constitution explicitly, but you can generally take it to mean fulfillment of the Membership Requirements. These elections usually happen during GM near the end of the year.

Subteam Elections

Subteam elections are a little more complicated, taking place in two phases: nomination and confirmation.

Nomination

First, subteams nominate a candidate using a form of ranked-choice voting called Single Transferable Vote (STV):

• The voters rank candidates in their order of preference on their ballots, including a “no confidence” vote indicating that they do not wish to transfer their vote to any subsequent candidates on the list

• In each round of voting, the candidates with the fewest votes are eliminated. Each voter who voted for those candidates transfers their vote to the next candidate on their preference list, leading to the next round of voting with these new tallies

• At the end of this process, the candidate with a majority of available votes wins the nomination.

If you aren't interested in the math behind it, it suffices to say that voters rank their preferences and a winner is chosen that will satisfy people. (If you are interested in the math, check out this!)

Nomination votes usually take place during the normal subteam meeting time.

Confirmation:

This Candidate Subteam Lead will then be confirmed through a simple majority vote of all active members. If a Candidate is rejected, the runner-up of the subteam election will be nominated as the new Candidate.

Usually, Subteam Leads confirmation votes for all subteams occur in a single GM during which the voting for club-wide positions also takes place.

Members: Want to edit the GitBook? Follow this link!

Still don't have edit access or can't access the STAR Internal space? Check out this tutorial.

Welcome!

This is a space for the general public, prospective members, and current members to access all sorts of documentation compiled by our team.

If you're interested in joining, we recommend starting with the FAQ and the Membership section, then moving on to the Intro Projects:

For current members and the general public, here are the major sections of our documentation. Tutorials are for the most part widely applicable to the sort of work we do, but many do pertain specifically to software or processes for STAR members:

Team-specific testing information and test forms can be found in the Testing section:

To contribute to our documentation, see the below page:

Documentation on specific current or past projects can be found at the STAR Internal space, which is restricted to members:

• Rapid design iteration

• Physics, Analysis-oriented testing

• Efficient Cross-Specialty Collaboration

• Development for Reliability, Robustness

• Expand team technicality, individual learning capability

Design & Manufacturing

Aero-Structures Analysis

• Target Apogee, Precision: 2500m, +-10%

• Approx. Vehicle Mass: 40kg dry

• Approx. Thrust Level, Burn Time: 1.80kN, 10sec

Flight Avionics: Stackable Sub-Module Array

Instrumentation Requirements:

Command/Communications Structure

Control State Structure

Specifications

• Dual side dual deployment

• Redundant Altimeters, ejection charges

• Dual-Camera Onboard Monitoring

• GPS real-time telemetry

Requirements

• Drogue Deployment velocity < 50 ft/s

• Main chute deployment velocity < 100 ft/s

• Landing velocity: below 25 ft/s

• Downwind Drift < 1 km

Demonstration Launch 11/2023

MCMC Dispersion Analysis

Development Steps:

1. High-Level Rocket Structure: Thrust Range, Vehicle Mass (+-50%)

2. Conservative(High-Thrust) Thruster / Feed System Design + Review

3. Fluid System Assembly, Testing, Calibration. Instrumentation and Control Development. Flight Structure Design Integration

4. Static Fire Testing. Mass Optimization, Simulation Refinement.

5. Flight Vehicle Integration

Thruster + Injector

Priorities: Stable, Conservative Performance and Efficient Manufacturing/Assembly

• Injector: Unlike-Doublet Impinging, LOX-centered

• Chamber: Ablative + Fuel Jetted Wall-Film. 6061 Aluminum Jacket.

• Nozzle: Graphite Throat, 316L Stainless Steel Expansion

Fluid System (Engine "Feed System")

Fin design discussion:

We designed our fins based on the need of our rocket. Initially, we had fin dimensions that were larger. However, as our rocket design developed we realized that this design was not meeting our apogee and stability needs. Each change would need our fins to be altered which was constant. After our rocket design was set, we began our fin simulations with respect to our motor simulations. We wanted to make sure our fins and motor complimented each other. We did different fin-size simulations for each motor we felt could be used to meet the needs of our rocket. After many fin/motor simulations and utilizing the optimization tool in Open Rocket, we landed on our current fin dimensions.

Fin Semi-span (inches) *

Distance between root cord to tip cord (inches) - Numeric data only

7.4 in

Fin attachment *

Description of the method used for securing the fins to the airframe.

1. Sand areas of connection before applying epoxy. Clean off any fiberglass dust with IPA solution. Spread epoxy(JBweld) all around the bottom of the fin tab and side of fiberglass, so that it is completely coated.

2. Use the fin jigs to place the fins into the fin slots on the booster tube, so that the tabs are touching the motor tube and the aft side of the tab is touching the middle centering ring.

3. Create smooth epoxy fin fillets around each fin. After thoroughly mixing, wear gloves and use your finger to apply a generous amount of epoxy at the seams between the fins and the booster tube.

4. Once all three fins are cured and attached, align the aft centering ring with the rest of the rings, but do not epoxy it in. Keep multiple zip ties wrapped around the ring so that once it is perfectly aligned, it can be pulled out.

5. Epoxy the aft centering ring into the exact position established in the previous step. If it falls out of alignment, use one of the extra aft centering rings and try again, until it is successful. Allow the epoxy to cure for 24 hours.

6. 1. This step will also take place after fin glassing and after the aft rail button is attached.

7. Final details

8. Fin glassing

General Procedure:

1. Roughen surface with 80 grit sandpaper.

2. Clean surface with 50% IPA, 50% water.

3. Cut 3 types of cuts of cloth:

4. 1. First cut of cloth goes over the fillets, goes less than a third of the way up the fin, need 6 of these.

   2. Second cut goes up ~⅔ of fin, and out to the midpoint between the fins on the airframe, need 6 of these.

   3. Third cut goes from tip of one fin to tip of the adjacent fin, need 3 of these.

5. Mix epoxy in ratio given on instructions. Need a 3:1 ratio between epoxy and cloth.

6. Application:

7. 1. Wet surface with epoxy.

   2. Put a cloth layer on top of epoxy; it will soak the epoxy into itself.

   3. Squeegee the excess epoxy and bubbles out of the layup to make it smooth.

   4. Once all three layers are on, apply peel-ply over the layup.

   5. Cure vertically.

8. Vacuum bag the entire fin area to ensure a smooth cured surface. Apply breather cloth to the peel-ply before bagging.

9. Once cured, sand down composite surface.

Fin Flutter Analysis *

Please describe the method and results used to determine the not to exceed flutter velocity or the divergence velocity.

We used the flutter boundary location to determine the rocket’s flutter velocity and ensure that our rocket’s velocity never exceeds this flutter velocity. Assuming our maximum altitude, which is the apogee of 10,000 feet, we were able to derive the estimated air temperature and estimated speed of sound. Finally, we were able to apply our fin geometry to calculate the fin flutter velocity, which is 1682.16 ft/s (1146.9 mph). We confirmed this value using the software FinSim, which combines our fin geometry with more specific rocket data to calculate this same value. Since our rocket’s maximum velocity is predicted to be 972 ft/s, we will not exceed flutter velocity.

Vehicle Weight (pounds) *

All vehicle, electronics, and recovery (pounds) - Numeric data only: NOT including motor case, propellant, or payload weight

48.897 lb

Empty motor case/structure (pounds) *

0.503 lb

Propellent weight (pounds) *

11.7 lb

Payload weight (pounds) *

Must be at least 8.8 lbs per IREC Rules (pounds) - Numeric data only

9.5 lb

Liftoff weight (pounds) *

Vehicle weight + propellant weight + motor case/structure + payload weight (pounds) - Numeric data only

70.6 lb

Center of Pressure (inches) *

The location of the center of pressure measured in inches from the tip of the nose cone. Numeric data only.

91.426 in

Center of Gravity (inches) *

The location of the center of gravity measured in inches from the tip of the nose cone. Numeric data only.

79.264 in

Static Margin *

The distance between the CG and the CP at lift-off is divided by the airframe diameter, measured in calibers. 1.5 is the highly recommended minimum

1.97 cal

Couplers & Airframe joints *

Discuss each airframe joint, including couplers, shoulders, and attachment method(s).

Ref. DTEG 8.5 - Airframe joints that implement “coupling tubes” should be designed such that the coupling tube extends no less than one body tube caliber on either side of the joint – measured from the separation plane. The nose cone is epoxied onto the payload tube. Airbrake coupler attached to airbrakes tube with epoxy. Booster tube coupler is attached to the airbrake tube with #6-32 black-oxide alloy steel screws and to the booster tube with epoxy. Av Bay coupler attached to the main parachute tube with epoxy.

#4-40 nylon screws placed between payload tube and Av Bay coupler.

#4-40 nylon screws placed between Av bay tube and main parachute tube.

Rocket construction narrative/ additional information *

Discussing the construction of your rocket including airframe, couplers, interstage couplers, nose cone, fins, fin attachment, composite materials, and identify commercial or SRAD components.

Booster tube assembly:

https://docs.google.com/document/d/1KZSKXfp3WzLMbTYALbvnvTjxdE30VmkWheWptSs8Wp4/edit?usp=sharing

Recovery Tube Assembly Procedure:

https://docs.google.com/document/d/1zdzwSvZdx3QNCro2Ow7lJZkjrqIrI5-QjmlmlRy3plg/edit?usp=sharing

Avionics Bay Assembly

https://docs.google.com/document/d/11EJxgDgyR533UyZEACwQ8Kov9MOq7I9INR4dPBZpjkk/edit?usp=sharing

Payload/Nosecone Assembly

https://docs.google.com/document/d/1vlngpPR9ITgm7eNp6eLI1-ExmZ_qhbyRcS-wdQqEksM/edit?usp=sharing

GROUND TEST: The following full ground testing procedure was conducted on February 16th, in preparation for a test launch of the vehicle(with a ballast stack no payload) on February 18th.

https://docs.google.com/document/d/123OBOUEgaW2C-NUJAULUbGjeWIXQ4C2dBecxAn0cElw/edit?usp=sharing

Section 7: Propulsion System

Propulsion Type *

Solid

COTS - Commercial Off The Shelve

Propulsion Manufacturer *

Aerotech

COTS Motor - Manufacturers Designation

Aerotech M1939 W-P

Motor Letter Classification *

M

Average Thrust (N) *

1,939.0 N - Avg thrust given by thrustcurve.org/motors/AeroTech/M1939W/

Maximum Thrust (N)

2,429.7 N - Max thrust given by thrustcurve.org/motors/AeroTech/M1939W/

Total Impulse of all Motors (Ns) *

10,481.5 Ns - Total Impulse given by thrustcurve.org/motors/AeroTech/M1939W/

10,369 Ns - Total impulse given by RASP simulator file from thrustcurve.org/motors/AeroTech/M1939W/ ** explanation given in propulsion narrative and additional comments.

Motor Burn Time (s) *

Numeric data only (Seconds)

6.52 s - Motor burn time given by Open Rocket

6.2 s - Motor burn time given by thrustcurve.org/motors/AeroTech/M1939W/

Propulsion Narrative

Due to judges comments from our previous reports, we redid our propulsion simulations through OpenRocket. We used the RASP format simulator file from Thrustcurve.org. However, we wanted to preface a discrepancy between this file and the given information on the Thrustcurve site. For our motor, Aerotech M1939-W the written total impulse is given as 10481.5 Ns. However, the total impulse in the RASP file is 10369 Ns. All our simulations were done with this file, therefore using the impulse value of 10369 Ns.

Sep. 2018 - Sep. 2021, Viability discussion and project proposal

The project originated from "Hot Take," a project proposal that outlined a plan for STAR to explore liquid rocketry.

Sep. 2021 - Feb. 2022, Designing phase

During this phase, the team mainly focused on designing the physical system, as well as manufacturing various parts of the liquid engine, such as the injector and combustion chamber.

Feb. 2022 - Apr. 2022, Integration

Most of the software and electrical development occurred during this phase.

Apr. 16, 2022, Hot-fire Attempt 1

The first attempt did not succeed, but it provided valuable information regarding the flaw in our system.

May 22, 2022, Hot-fire Attempt 2

Successful hot-fire with a burn time of 6 seconds.

STAR's first generation liquid rocket engine

The Experimental Liquid Low Inpulse Engine (ELLIE) is the first time that STAR has attempted to create a bi-propellant rocket engine. Its purpose was to lay the groundwork for a flyable liquid in future iterations.

• Thruster:

  • Radiatively Cooled (Heat Sink) Combustion Chamber / Nozzle

  • Injector: Coaxial Shear element mixes compressible GOX with ethanol. Dampens pressure instability through 30% Combustion Pressure element flow resistance

  • Thrust Measurement: (Target 30lb thrust)

    • Three S-type load cells, together, measure total thrust force

  • Pressure Measurement:

    • Wheatsone Bridge Diaphram Pressure Transducers measure intense distributed forces

• Feed System:

  • Energy Regulation:

    • Spring-Loaded Regulators and Stainless Steel Ball 2/3-way Valves.

    • High-Pressure copper tubing, braided stainless steel flex hoses.

Flow control

Hot-fire sequence design

The team is required to stay in the bunker during a hot fire, so the engine must be controlled remotely. We chose to use two ESP32s, one of which would send commands (COM Board), and the other would report data (DAQ Board). Both devices were constructed as state machines, with COM Board connected to the computer to transmit the data reported by the DAQ Board.

Here is a state machine diagram to visualize the communication:

Code Implementation

//Define communication structure

typedef struct struct_message {
    int messageTime;
     int pt1;
     int pt2;
     int pt3;
     int pt4;
     int lc1;
     int lc2;
     int lc3;
     int fm;
    unsigned char S1;
    unsigned char S2;
        int commandedState = 0;
        int DAQstate=0;

    unsigned char I;
    short int queueSize;
    int Debug;
} struct_message

// Create a struct_message called Readings to recieve sensor readings remotely
struct_message incomingReadings;

// in void setup() we register the for a callback function that will be called when data is received
esp_now_register_recv_cb(OnDataRecv);

void OnDataSent(const uint8_t *mac_addr, esp_now_send_status_t status) {
 // Serial.print("\r\nLast Packet Send Status:\t");
 // Serial.println(status == ESP_NOW_SEND_SUCCESS ? "Delivery Success" : "Delivery Fail");

  if (status == 0){
    success = "Delivery Success :)";
    digitalWrite(INDICATOR2, HIGH);
    receiveTimeDAQ = millis();
  }
  else{
    success = "Delivery Fail :(";
    digitalWrite(INDICATOR2, LOW);
  }

}

// interrupt function, triggered when 
void OnDataRecv(const uint8_t * mac, const uint8_t *incomingData, int len) {
  memcpy(&incomingReadings, incomingData, sizeof(incomingReadings));
  incomingPT1 = incomingReadings.pt1;

     digitalWrite(INDICATOR1,HIGH);

// loading the remote data into local variables
  incomingMessageTime= incomingReadings.messageTime;
  incomingPT2 = incomingReadings.pt2;
  incomingPT3 = incomingReadings.pt3;
  incomingPT4 = incomingReadings.pt4;
  incomingFM = incomingReadings.fm;
  incomingLC1 = incomingReadings.lc1;
  incomingLC2 = incomingReadings.lc2;
  incomingLC3 = incomingReadings.lc3;
  incomingS1 = incomingReadings.S1;
  incomingS2 = incomingReadings.S2;
  queueSize= incomingReadings.queueSize;
  incomingI = incomingReadings.I;
  actualState = incomingReadings.DAQstate;
  incomingDebug= incomingReadings.Debug;

// Rest of code omitted
}

//initialize ESP32
   if (esp_now_init() != ESP_OK) {
  //  Serial.println("Error initializing ESP-NOW");
    return;
  }
   // Once ESPNow is successfully Init, we will register for Send CB to
  // get the status of Trasnmitted packet
  esp_now_register_send_cb(OnDataSent);

  // Register peer/ second ESP 32
  memcpy(peerInfo.peer_addr, broadcastAddress, 6);
  peerInfo.channel = 0;
  peerInfo.encrypt = false;

  // Add peer
  if (esp_now_add_peer(&peerInfo) != ESP_OK){
 //   Serial.println("Failed to add peer");
    return;
  }
  // Register for a callback function that will be called when data is received
  esp_now_register_recv_cb(OnDataRecv);

//State Machine Implementation
case (0): //Default/idle
      idle();
      state=1;  
    break;

  case (1): //Polling
    polling();

    if ((digitalRead(BUTTON2)==1)||(serialState==2)) { state=3; S1=servo1ClosedPosition; S2=servo2ClosedPosition; SendDelay=pollingSendDelay; }
    if (serialState==18) {state=18;} 
    if (serialState==17) {state=17;} 
    if (digitalRead(PRESS_BUTTON)==30) {state=30;}

    break;

  case (2): //Manual Servo Control

 manualControl();
  if ((serialState==40)) { state=0; SendDelay=pollingSendDelay; }

  break;

  case (3): //Armed
    armed();

    //button to ignition 
    if ((digitalRead(BUTTON3)==1)||(serialState==3)) { state=4; S1=servo1ClosedPosition; S2=servo2ClosedPosition; SendDelay=ignitionSendDelay; }
    //RETURN BUTTON
    if ((digitalRead(BUTTON1)==1)||(serialState==1)) { state=1; S1=servo1ClosedPosition; S2=servo2ClosedPosition; SendDelay=pollingSendDelay; }
      
    break;


  case (4): //Ignition

    ignition();
    //HOTFIRE BUTTON
      if ((digitalRead(BUTTON4)==1)||(serialState==4)) state=5; 
      //RETURN BUTTON
      if ((digitalRead(BUTTON1)==1)||(serialState==1)) { state=1; S1=servo1ClosedPosition; S2=servo2ClosedPosition; SendDelay=pollingSendDelay; }
      
    break;
  case (5): //Hotfire stage 1

    hotfire();

    if (actualState==0) state=0;

Data acquisition and processing

Automation in calibration

PinkBeary (SSEP) was launched at FAR on 17 September 2022. The mission of stage separation was successful, but a rapid unscheduled disassembly (RUD) about 1 second after upper stage motor airstart due to improper airframe connection caused a partial mission failure.

A valuable lesson we learned from the previous hot-fire experience is that we cannot rely solely on commercial piping components, such as off-the-shelf valve regulators, to control the engine system accurately. Therefore, the ELLIE team is continuing as a long-term research group, focusing on advanced valve control.

A significant concern has been the droop in the system. It has severely impacted our engine performance, since only a fraction of the GOX flow truly occurred, which resulted in a fuel-rich burn. Here is the visualization of the issues caused by droop, plotted in MATLAB:

PT1 measures the pressure of the combustion chamber downstream, while PT2 measures the pressure of the GOX flow. It appears that the GOX regulator's droop was much higher than what we expected, since we have addressed droop by intentionally setting the regulated pressure higher than the nominal pressure. The result was a low-pressure, low-mass flow burn in the combustion chamber. This conclusion is supported by PT1 data with a high point of about 150 psi, which is 100 psi below the GOX pressure.

The ELLIE team is addressing this issue by designing a self-regulated valve. The valve will be able to adjust the flow rate according to real-time pressure changes to guarantee a desired mass flow rate.

Summary

• Data Analysis (Refer to P&ID on Physical System for instrument locations):

  • Data:

    • Max Thrust: ~32 lbf

    • Combustion Chamber Pressure: ~145psi

    • Upstream GOX Pressure: 250psi

    • Upstream ETH Pressure: 335psi

  • Analysis:

    • Thrust was ~1/3 predicted:

      • GOX feed pressure was very low > sustained a low-pressure reaction in chamber

      • Low Combustion Chamber Pressure + low flowrates > low combustion chamber pressure.

• Long-Term ELLIE system goals:

  • Use existing printed circuit board and fluid system for component testing of LE2

  • Build upon fluid system to test active flow control valves for LE3

Reasoning for Update

One of the recovery subteam’s slowest steps at launch is connecting wires to the altimeters. The spaces that the wires must be fit into are very small, making it difficult to maneuver and secure them. This can lead to delays because connecting the wires is time-consuming and insecure connections can lead to ground test failure. It also cannot be fully-completed ahead of time as the altimeters must be re-wired between ground test and launch.

Previous solutions have involved positioning the altimeters on the sled such that the connections are easier to access and using crimps to speed up the connection process. However, even with good altimeter placement, it can be difficult to position the wires. Recovery also had issues in creating secure connections to the crimps and did not consider them reliable enough for launch.

New solution

Recovery plans to solder short lengths of wire directly into the altimeters at one end and into a crimp at the other. The end with the crimp could then be easily connected to a longer wire for ground test or flight, saving time at launch. Soldering into the crimp should increase the security of the connection, preventing the previous problems associated with crimps.

This solution allows recovery to change the wiring of the altimeters, despite soldering a wire permanently into the altimeter because the long wire going to the other connection point is replaceable. Solutions involving solder were previously not considered because of the requirement of reconfiguring wires at launch.

Schematic

Before PDR

1. Material Choice: Fiberglass (Balsa wood too weak given geometry and speed)

2. Geometry Options

   1. Best Performance: Triangular

      1. Root chord: 8 in.

      2. Tip chord: 0 in.

      3. Height: 5.5 in.

      4. Max rocket speed is 92% max fin flutter speed

      5. Highest apogee: 8460 ft.

   2. Best Choice: Trapezoidal

      1. Root chord: 8 in.

      2. Tip chord: 3 in.

      3. Height: 5.2 in.

      4. Max rocket speed is 65% max fin flutter speed

      5. Highest apogee: 8344 ft.

   3. Viable: Elliptical

      1. Root chord: 8 in.

      2. Height: 5.2 in.

      3. Highest apogee: 8282 ft - consistently outperformed by trapezoidal fins with comparable stability, geometry

3. Thickness Choice: 1/8” (Thinnest option that could withstand max speeds)

4. Stability

   1. Ranges from 1.31 - 1.5 on design view

   2. Consideration of high speeds shift this stability to around 1.8-1.9 according to simulations, so this meets the recommended requirements

   3. For lower stage fins, a range of 1.5 - 2.5 should be used, which of course means a change of geometry

Between PDR and CDR

1. Decided on trapezoidal over elliptical based on OpenRocket data

2. Increased thickness of both sets of fins to 3/16” based on FinSim data because FinSim accounts for fin divergence also

3. 1. Upper Stage

      1. Root Chord: 8”

      2. Tip Chord: 3”

      3. Height: 5.5”

      4. Stability: 1.27 cal

   2. Lower Stage

      1. Root Chord: 10”

      2. Tip Chord: 3.5”

      3. Height: 5.7”

      4. Stability: 2.19 cal

Files Used

The total cost for a 5.5 inch diameter rocket is $680.57.

6 Inch Diameter

The total cost for a 6 inch diameter rocket is $867.05.

Conclusion

We decided that a 5.5 inch diameter rocket would be most beneficial. While this option is not the least expensive, it does allow for future growth. Although a 5.5 inch diameter rocket reaches a lower apogee than a 6 inch rocket and can carry less payload, we decided it is more beneficial for us as a club to understand the process of building and launching a dual stage rocket than it is to overdo our first attempt. A 5.5 inch stage separation rocket is not too risky, but will also allow us to use larger motors and reach higher altitudes in future launches. This rocket will help us gain experience in designing, manufacturing, and launching a dual stage rocket. This will be beneficial overall for the club and our long term goal of achieving a space shot.

See these two documents for our original data and cost comparisons, plus sources and links to purchase the parts.

Perfectflite StratoLoggerCF

This altimeter will be used in both the upper stage main and drogue parachute deployment.

Purpose (Upper Stage Main): Dual Side, Dual Deploy Entails: Pyro leads to main and drogue (redundant), deployment based on elevation and velocity.

Purpose (Lower Stage Main): Single Side, Single Deploy Entails: Pyro leads to main (redundant), deployment based on elevation and velocity.

Specs:

• Works to 100,000 feet MSL, audibly reports peak altitude and maximum velocity after flight.

• Stores 16 flights of 18 minutes each (altitude, temp­erature, and battery voltage at 20 samples per second) for download to a computer with the optional DT4U USB interface. Hi-speed sampling and storage of battery voltage serves as a useful aid in diagnosing intermittent problems with your battery, switch, and wiring. All data are preserved with power off.

• Deploys drogue and main chutes with audible ematch continuity check.

• Outputs capable of 5A current for 1 full second to allow use with nearly any ematch or ematch substitute. Reverse polarity protection prevents spontaneous firing if battery is connected backwards.

• Main chute deployment altitude is adjustable from 100 feet to 9,999 feet in 1 foot increments. 9 presets allow for quick change in the field.

• No mach delay necessary for mach+ flights: Automatic MachLock assures proper operation with any flight.

• Brownout protection will tolerate 2 second power loss in flight – no need for multiple batteries.

• Precision sensor & 24 bit ADC yield superb 0.1% accuracy.

• Built-in voltmeter reports battery voltage on powerup – no more guessing about battery condition.

• Post flight locator siren aids in locating your rocket.

• Confusion-free individual terminal blocks – unreliable multiple wires per terminal are not necessary. Dedicated switch terminal block eliminates the need for splicing switch into battery wire.

• Highly resistant to false trigger from wind gusts; tested in 100+ MPH winds!

• Selectable apogee delay for dual altimeter setups prevents overpressure from simultaneous charge firing.

• Low power design runs for weeks on a standard 9V alkaline battery. Post-flight locator siren will run for months, giving you multiple “second chances” to find a lost rocket.

• Telemetry output for real-time data in flight with your RF link.

• Rugged SMD construction, stringent QC testing, and internal self-diagnostics assure uncompromising reliability.

• Wide operating temperature range of -40F to +185F.

• Measures just 2.0"L x 0.84"W x 0.5"H, fits 24mm tube, weighs just 0.38 oz.

Manual: http://www.perfectflite.com/Downloads/StratoLoggerCF%20manual.pdf

Altus Metrum EasyMega

The Altus unit comes at a hefty cost, but has the advantage of being able to provide angle caculations. using two different altimeters for the same deployment is not advised since it would require two different switches.

Purpose: Lower Stage Parachutes (Drogue and Main, DSDD), Separation Mechanism Entails: 3 additional programmable pyro events for separation mechanism (redundant).

Specs:

• 2.25 x 1.25 inch board designed to fit inside 38mm airframe coupler tube

• Supports dual deployment and 4 additional pyro events.

• Pyro events are configurable and can be based on time and various flight events and status, including angle from vertical (for safety in staging and air start flights).

• Barometric pressure sensor good to 100k feet MSL

• 1-axis 105-g accelerometer for motor characterization

• 3-axis 16-g accelerometer for gyro calibration

• 3-axis 2000 deg/sec gyros

• 3-axis magnetic sensor

• On-board non-volatile memory for flight data storage

• USB for power, configuration, and data recovery

• Integrated support for LiPo rechargeable batteries

• User choice of pyro battery configuration, can use primary LiPo or any customer-chosen separate pyro battery up to 12 volts nominal.

• IMPORTANT! Easy Megas must be wired BACKWARDS (i.e. a custom JST connector must be assembled to plug the negative battery terminal into the "positive" end and vice versa) due to manufacturer decision.

Manual: https://altusmetrum.org/AltOS/doc/altusmetrum.pdf

Eggtimer Quantum

Purpose: Airstart (Motor Ignition)

Entails: Single lead to motor ignitor

Specs:

• 66mm x 25mm, weight ~12 grams

• Dual-ended output - pyro igniter is dead until near deployment for safety

• Records altitude up to 60,000 AGL

• Drogue programmable 0-3 seconds after noseover, main programmable from 100-2000 feet

• Wifi compatible - arm via phone

• Polarity-independent

• Comes in a kit - must be soldered and assembled

An Overview

Pyro Bolts are an effective way of performing stage separation for in flight vehicles and they can be carried out in a number of ways. Our design prides itself on simplicity, cost effectiveness, and reusability (except for the bolts themselves).

We start with two manufactured O-rings that are each epoxied (or fastened otherwise) to our two airframe tubes, these rings will stay attached throughout the entire launch-recovery process. We then take screws and drill them out, fill them with black powder, insert igniters (e-matches, insert 2 for redundancy), then seal the fasteners. This process is detailed in separate sources and in our stage separation testing documents. The screws can be inserted through holes in the both the O-rings and will be fastened with a wing nut located on the other side of the opposite O-ring. When all screws are ignited, they ideally break and there is no longer anything keeping the two stages together. To ensure separation we opt to place springs between the O-rings, around the screws in order to add force for separation. We can then epoxy multiple standoffs between the rings, to ensure all heights and alignments are correct.

Calculations

It is extremely important to perform calculations before all else, both to make sure your design is feasible and so that you can select and reference what parts/materials you are planning to use. The specific calculations will vary for each design, but the quickest way to think about what calculations are needed are to think about the forces placed on each part and on all surfaces that connect parts together. We should also check the calculations for the events that take place (black powder and spring actions). For our design above, our main concerns are:

• Can the black powder we have break the screws?

  • This is dependent on several factors, mainly:

    • mass of BP (depends on volume of drilled hole)

    • shear strength of screw material (accounting for the drilled out hole as well)

• Will the screws be able to handle the stress of launch?

  • Dependent on:

    • stress strength of screws

      • this depends on the material and surface area of your screw so account for the fact that the screws have been drilled out a bit

    • stress strength of nuts

• Do the springs fall within the right window of strength (given a reasonable compressed height)?

  • Depends on

    • Spring strength

    • Height between Rings

    • Friction needed to overcome (you can estimate this, we chose 5 lbf)

  • Make sure you fall within the window, the spring should be strong enough to help separate, but not so strong that it causes unnecessary stress on the O-rings and screws.

• Is the epoxy strong enough to hold the O-rings and the airframe tubes together during launch?

  • It probably is but it's best to check, depends on:

    • Surface area between O-rings and Airframe tubes

    • Strength of epoxy

    • Mass in upper and lower stage

    • Acceleration of rocket during launch

These are some of the important calculations needed, however the more you can think of, the better. Make sure each calculation gives us a reasonable factor of safety (use your good judgement).

Integrating with the Rocket

Sources

The Common Avionics System (CAS) is a system for Avionics hardware development with the primary motives being to reduce hardware development time by better leveraging existing verified designs. CAS achieves this by splitting functionality into separate modules. This allows each module to do one thing and do it well, without having to redo aspects of the system that have already been done. CAS will allow Avionics to more easily support new projects and will reduce risk (in the long-term) by reusing well-tested designs.

CAS Board standards document (describes how to develop modules for CAS):

Terms

Stack: A set of modules placed vertically with standoffs separating them.

Module: A single printed circuit board (.062" thickness) that has the hardware to satisfy a certain function.

Dimensions

A module in the stack

See image below for cross-section of a stack (specifically of a module). The modules are square PCBs with 4 mounting holes in the corners (large filled yellow circles with blue-green halo). The arrays of smaller empty yellow holes are header pins for connection to other modules in the stack.

The side to side distances are 2.5 inches and mounting hole to mounting hole distances are 2.2 inches. The space from the top of a module to the bottom of another module is 0.6 inches.

CAS Bus

The types of pins that appear on the bus are:

• Power

  • +3.3V

  • +5V

  • +BATTERY

  • GND

• I2C0

  • SCL

  • SDA

• I2C1

  • SCL

  • SDA

• SPI High-Speed

  • SCK

  • MISO

  • MOSI

  • SS1, SS2

• SPI0

  • SCK

  • MISO

  • MOSI

  • SS1, SS2, SS3, SS4, SS5, SS6, SS7, SS8

• Interrupt pins

  • INT1, INT2, INT3, INT4, INT5, INT6, INT7, INT8

Power

The entire CAS stack's voltage rails (3.3V and 5V) are powered by a power management unit located on the core board. This power unit on the core board recieves +7.3V DC from an external battery. The entire CAS stack generally draws below 50 mA of current when not doing power-intensive tasks.

Disassembling modules from the stack

To separate modules from each other, use a flat-head screwdriver as a lever, as shown in this picture:

Overview

The Core Module contains the main MCU (an STM32F401RE chip), three sensors (BMP388 altimeter, BNO055 IMU, MAX17049 fuel gauge), an SD card holder for data logging, a UART debugging port, and USB and JTAG connectors. It also provides power for the other modules through the CAS Bus 5V and 3.3V power rails.

The STM32 microcontroller connects to an I2C bus (numbered I2C3) that does not connect to the CAS Bus, bus instead conencts only to the three sensors on the core board itself. The microcontroller also connects to an SPI bus (numbered SPI3) that does not connect to the CAS bus, but instead connects to the SD card holder and the SPI-to-I2C translator. Lastly, note that the I2C2 bus on the CAS bus does not connect directly to the microcontroller, but instead goes to the SPI-to-I2C translator.

The core board also features a "user button" and "user LED" for testing purposes. There is also a RESET button, but this button does not do anything unless there are jumper pins attached to the RESET jumper.

At the time of this writing, none of the three sensors have been soldered onto the board yet because we have been unable to buy them so far (except for the BMP388, which we bought recently but haven't soldered on yet).

Interface

Test Procedure

For testing, assemble the module and plugin a battery supplying 7.3V.

1. Test bus power sources. Make sure the voltage of all power pins match the specification.

2. Check USB. Connect USB to the computer and see if the flasher can recognize it.

3. Run echo and LED test. See if we can flash the chip through the debugger, then check if the user LED is blinking and if the UART outputting the correct message.

4. Run sensor connectivity tests for all onboard sensors. This includes checking if we can read the ID registers of IMU, Altimeter and fuel gauge.

5. Verify the functionality of onboard sensors. Read actual data from the sensors and see if they match expected values.

6. Test bus interrupt pin connections. Connect a jumper from the 3V3 power pin to an interrupt pin and see if we read the correct value. Repeat this for GND and every pin.

7. Check SD card IO. Check if we are able to write data and read back from it.

Overview

The pyro module consists of eight connectors which can each light a blackpowder charge. Each connector is controlled by a mosfet, and if the mosfet allows current to flow through the connector, then the blackpowder charge is ignited.

The core module controls this by sending I2C messages over the I2C0 bus to the I/O expander module. The I/O expander module connects to eight mosfet drivers which drive the mosfets. The I2C messages that come to the I/O expander can tell it to set off certain blackpowder fuses.

The I/O expander also features three address bit jumpers, which can be manually connected or disconnected to change the I2C address of the I/O expander, to avoid I2C address conflicts.

Overview

The Radio module contains an RFM69 radio transciever module (with an attached antenna) whose purpose is to transmit data from the rocket to the ground station in real time. The radio module also contains a SAM_M8Q u-blox GNSS chip which can determine time, latitude, longitude, and altitude. The micocontroller can communicate with the radio through the SPI0 bus, and communicate with the GNSS chip over the I2C1 bus. There are also a couple of optional extra I/O interface pins on the GNSS module that can be connected to external jumper wires.

The radio's output can be sent either to the antenna or to an SMA cable (for testing what data is sent). There are two jumper pins on the board, JP1 and JP2, which control which of the two destinations is connected to the radio's output. JP1 can be used to manually set the radio's output between to the antenna or to the SMA. JP2 can be used to override the selection on JP1 and have the selection be made by the Microcontroller instead. Note that JP1 is on the top of the board and JP2 is on the underside.

The current version of the radio board also has one extra connection made with a white soldered-on wire, which connects the DIO0 pin on the radio transciever to the A20 pin of the CAS Bus (INT 8). This could be used in the future to program the radio transciever to send an interrupt over the DIO0 pin which would reach the Microcontroller at interrupt pin 8.

Normally, the radio should be operated at either 915 MHz or 433 MHz.

The radio-revised board is still in development. The plan for this board is to use an AT86RF215 module as the radio transciever, which can transcieve over two channels independently at different frequencies.The core board will communicate with the AT86RF215 through LVDS signals, which are output by the FPGA on the core-revised board and travel over LVDS pins on the cas-bus.

Most of the design for this module is directly copied from the cariboulite radio board design (which also uses an AT86RF215) here: https://github.com/cariboulabs/cariboulite/blob/main/hardware/rev2/schematics/CaribouLite.PDF

The prop module is currently still in development. The prop module is unique in that it consists of three boards, not one, since the components would not all fit on one board. Also, the prop module requires a separate power supply connector because one of the components (a solenoid) requires a +24V power input, which is greater than the battery can supply.

The current plan for the prop board will include connectors that attach to several sensors and actuators used in the propulsion system. These sensors and actuators are not on the boards themselves, but are instead wired to the connectors on the edges of the boards.

The main specifications for this module are:

• 5 Pressure Transducers

• 3 Load Cells

• 3 Thermocouples

• 3 Servos

• 2 Solenoids (to open valves)

• Oxygen Flow Meter (Not yet decided if we should include this)

The core-revised board is still in development. The plan for this board is to use a raspberry pi compute module 4 ("rpi CM4") as the microcontroller for the board. The board will also have an ICE40 FPGA that serves as an I/O expander, since the rpi CM4 has a limited GPIO pin count.

The specification for this board includes the following components:

• rpi CM4 microcontroller

• ICE40 FPGA

• 2 camera connectors

• 2 HDIMI connectors

• An SD card slot

• A microUSB port (with an ESD protector)

• 3 sensors (the same as on the original core board)

• a PCIe connector (we still haven't fully decided if this should be added or not)

The rpi CM4 has 45 GPIO pins that can be mapped to various functions. See pages 8 and 9 of the rpi CM4 datasheet (https://datasheets.raspberrypi.com/cm4/cm4-datasheet.pdf) for the full list of possible pin assignments. See the "GPIO to CAS Module" google doc (https://docs.google.com/spreadsheets/d/1WoIMGLvNKh1mcGZh1nwG_u1I8tszVKkk_6aB_qJbBj4/edit?usp=sharing) for the list of pin assignments that we decided to implement.

Note that GPIO0 and GPIO1 have three functions--they can be used as either SMA pins to connect to the FPGA, or as GPIO pins to connect to one of the camera connectors, and on top of that, both pins are also used as UART debugging pins.

The rpi CM4 will use the "secondary memory interface (SMI)" to communicate with the FPGA through the pins that have been assigned SMI functionality.

This schematic describes the overall plan for the entire module, which shows how each of the components should communicate:

This core module is largely inspired by the design from the rpi CM4 I/O board, which features many of the same components (HDMI, PCIe, camera connectors, etc) also connected to an rpi CM4. The I/O board design is located here: https://datasheets.raspberrypi.com/cm4io/CM4IO-KiCAD.zip

The symbol and footprint for the rpi cm4 are located here: https://github.com/Kedarius/RPi-CM4-Kicad

Deployment

DAVE deploys just after apogee, or the apex of the rocket's flight. In doing so, it uses its ejection mechanism to leave the payload bay in the launch vehicle's interior and pursue its own free-fall path to the ground. Doing so allows DAVE and its cargo to undertake a longer, more controlled flight separate from the parachute and the rocket fuselage.

Aerostructures

Due to DAVE's full flight structure needing to be contained within a 6" diameter tube, the glider must be collapsable. In particular, both its primary wings (of Rogollo type) and its elevators must be collapsable in some fashion.

Additionally, the manipulation of our weight, lift, and drag force vectors are essential to DAVE having a controllable flight. DAVE currently has no mode for producing thrust, but a thrust-producing cargo may be pursued in the future. Calculations to determine the correct geometries (including wing sizing and placement) are located on the DAVE Trello board under Aerostructures.

Vehicular Control

As we would like to be able to control DAVE's flight from the ground, we will need on-board avionics. These avionics will control two types of control surfaces on DAVE: elevators and rudders. The elevators give DAVE control in the roll and pitch directions, while the rudders give the glider yaw control. Both of these will be located at the rear end of the vehicle - the Rogollo wings will be fixed and uncontrolled.

Experimental Cargo

The grand purpose of DAVE is to carry onboard experiments that benefit from its unique deployment and flight pattern. Although the current designs for cargo carrying are not set, a goal is to have a modular interface, so any cargo concept that matches can go aboard.

Purpose

DAVE is the payload subteam's primary research project intended to be flown on a 6 inch diameter rocket. DAVE is planned to consist of a semi-autonomous, passively stable glider, a mechanism to deploy the glider from the rocket, and associated test platforms.

Is this FAQ a good place for writing technical design decisions?

Heck no! There are other places to do that.

What's the point of DAVE?

Payloads such as the muon detector benefit from extended time in the air. Other potential payloads may benefit from a more gentle descent, or placement in a specific location. Additionally, DAVE-specific payloads may be interesting, such as aerial mapping, rocket-spotting, etc.

Why not just like, build an RC plane?

Getting a conventional UAS to this altitude can actually be quite difficult at this scale. While it is certainly doable, there may be applications for this sort of vehicle in a situation where rapid response and having a presence at these altitudes is important. The autonomous functionality is critical in these scenarios. For example, while fighting a fire, being able to quickly get a picture from the sky may be useful for firefighters on the ground.

I have a cool idea for a payload that should go on DAVE. What should I do?

Write it down on the Trello card and message in #payload-dave! Even if we are actively focusing on IREC payloads, we can always be writing down good and interesting ideas.

Welcome to the IREC 2020 & 2021 Projects page! You can find both technical and non-technical information about our 2020 and 2021 project here.

Initial tasks assigned as follows:

Created Trello board (must log in, message in #payload-dave for access):

MINDI achieved an apogee of 14,325ft, which was the highest apogee reached by any UC Berkeley team at the time.

The goals of the redesign of the avionics sled for the IREC 2020 rocket were the following:

1. Optimize the avionics bay for a 6" rocket

2. Address wiring concerns from AirBears to improve ease-of-use during launch

The new chosen design was an I-beam model, in which the batteries were placed in a center section of the sled and one altimeter was mounted to each side, as shown below. This design somewhat improved the space usage in the vertical direction, but there was significant unused horizontal space. The Recovery subteam selected this design because they felt it was more important to be able to wire the altimeters efficiently at launch than to use the least possible space.

Avionics Sled as viewed from back. Batteries are placed in middle centrals and the second altimeter is in the corresponding position on the other side of the sled.

Overview

Many systems within a rocket are controlled by electronics, such as the parachute deployment systems, the motor ignition systems, and with our latest SSEP project, the stage separation mechanisms. These electronic controls are known as avionics, and they are essential to the function of the rocket, but they can be quite delicate and must be in proximity to the systems they are controlling so they can be wired effectively. The avionics bay houses these avionics in a relatively central location in the rocket and in such a way that the avionics are kept safe throughout the rocket's flight.

Types

We use two main types of avionics bays: axial designs and radial designs. These names refer to how each design is installed into the rocket. Axial av-bays are inserted through the airframe tube along the tube's long axis, and radial av-bays are inserted radially through the side of the airframe tube, through a door in the tube. All radial av-bays have a sled, which houses the avionics and is the actual component to slide in and out of the airframe tube. Some axial av-bays have a sled design so that the avionics can be accessed radially as well, but this is not the case for all axial av-bays.

Full avionics bay for Bear Force One with the radially installed sled highlighted in blue (Right), and sled from avionics bay for Bear Force One with altimeters to control the parachute deployment (Left):

Components

There are two main types of components discussed here: structural components and electronic components. The structural components serve to house the avionics (the sled) and to connect the inner structure to the rocket’s frame (bulkheads, u-bolts, etc.). The electronic components are the avionics themselves, notably the altimeters and CAS, along with their power supplies.

Structural Components

The following outer structural components are found in practically every av-bay, no matter the design:

• Bulkheads: These usually metal plates connect the rest of the avionics bay assembly to the frame of the rocket.

• U-bolts: These u-shaped bolts are fastened to bulkheads and connect the bulkhead, and therefore the avionics bay assembly, to a parachute assembly. Typically there is a fore u-bolt that connects to the drogue chute assembly forward of the av-bay and an aft u-bolt that connects to the main chute assembly aft of the av-bay. However, if there is only one chute assembly connected to the av-bay, as is the case with the lower stage of the SSEP rocket, only one u-bolt is needed.

• Av-bay rods: These rods provide additional structural support for the av-bay and are fastened with wingnuts. They can be seen in the av-bay for Bear Force One as the two vertical rods, shown at the bottom of this section.

Bulkhead + u-bolt assembly from Jay’s CAS-compatible 5.5” av-bay:

Additional outer structural components can be found on some av-bays, depending on their design:

• Additional outer bulkheads: Some av-bays, like the one in Bear Force One, have an additional set of outer bulkheads so that the rods and the u-bolts have four connection points instead of two. These additional outer bulkheads are depicted in the image below of the av-bay in Bear Force One with a slightly blue hue.

• Av-bay door: Any av-bay with a sled needs to have a door to access the sled. By default, any radial av-bay will have an av-bay door. This is one of the drawbacks to a radial av-bay design, as any hole in the airframe, such as an av-bay door, could potentially negatively impact the stability of the airframe.

Av-bay airframe tubes for Bear Force One with cutout for av-bay door:

The following are the main inner structural components of a radial av-bay or an axial av-bay with a sled:

• Sled: This structure houses all the avionics in a radial av-bay and some axial av-bays, and is designed to slide in and out of the av-bay assembly through the av-bay door for easy access to the electronics. It is convenient, but requires an av-bay door.

• Sled housing: This structure houses the sled and essentially gives the sled something to slide into. There are channels cut into the inner edges of the housing that the sled can slide into so that it is held firmly in place.

• Inner bulkheads/sled housing bulkheads: These bulkheads have a large section cut out and the edges of the cutout grooved so that a sled can slide directly into the bulkheads instead of sliding into a housing. These are used in the av-bay for Bear Force One, shown below highlighted in blue.

Sled from Jay’s 5.5” CAS compatible av-bay (Left), and corresponding sled housing from Jay’s av-bay (Right). One can see how the sled could slide into the housing and be held still by the grooves cut into the housing that match the rails on the sled:

Avionics bay for Bear Force One with upper inner bulkheads highlighted blue:

Avionics Components

The following components are the avionics in a typical av-bay along with their associated components:

• Altimeters: These measure the altitude of the rocket during its flight and are used to trigger the parachute deployment.

• 9V batteries: These are used to power the altimeters in flight. They are encased in a housing we have designed.

• 9V battery cases: These cases keep the 9V batteries safe and allow them so be more easily secured to the avionics bay.

• CAS: Our very own modular avionics unit designed by the avionics subteam. It usually has four layers of adaptable circuitry, and is roughly 2”x2”x2” in size. It will hopefully be used in the SSEP rocket to trigger the stage separation mechanism, but for right now we’re just including it in all of our new av-bay designs, as our goal is for it to become a standard part of our avionics system.

• LiPo batteries: These are used to power CAS, and they also have housing units that have been designed for them.

• CAS antenna: This antenna would allow CAS to talk to instruments on the ground, but it still needs to be integrated into the avionics system.

PerfectFlite Stratologger altimeter (first), LiPo battery for CAS (second), and 9V battery inside custom-made casing (with cover removed to view the battery) (third):

CAS stack put together (without antenna):

Other Av-bay Designs

Some av-bays are designed with a specific, unique purpose in mind, so they may have different designs to fit their specifications. For instance, an additional av-bay aft of the main parachute assembly was needed on the SSEP rocket in order to trigger the stage separation system and to ignite the upper stage motors. However, there was not much space to fit this av-bay. So, a small axial av-bay was designed by Hadar to meet these requirements, shown below. Note that it does not have a sled and an access door but instead splits into two accessible parts that are then clamped together when installed into the rocket.

Further improvements will be made relating to the holders to secure them to the bulkhead instead of having them unrestrained during launch

• Sand Paper

• Filers

• Phillips screw driver

• Drill and drill bits

• Respirators (when filing fiberglass)

• Epoxy (JB Weld ColdWeld ™️ Steel Reinforced Epoxy)

• bulkhead jig (designed to correctly place bulkhead and keep level

Procedure

Unfortunately for this assembly/manufacturing process to epoxy the avionics bay into the airframe became more inconvenient due to the need to epoxy the door nuts to the airframe. As a result, we must assemble the av bay in the airframe tube layer by layer. The components once within the av bay will no longer be accessible, apart from the sled and electronics mounted on it.

Prep work

• Confirm you have all required materials including tools

• Sand down the PLA and Wooden bulkheads to allow the them to more easily slide into the tube

• Sand down sled to allow for it to more easily slide into the bulkheads

  • you want only enough clearance to allow for easy removal, while still maintaining enough friction to hold the sled in place securely during flight.

• File down aluminum bulkheads to ensure they can slide down the tube

  • NOTE: Make sure the bulkheads are properly dimensioned before attempting to assemble, or you run the risk of getting them stuck even with filing for 4+ hours

• Sand down the inside of the airframe tube that you will be epoxying to

  • NOTE: sand down enough to remove the first layer but not enough to break down the fibers of the fiberglass

  • Make sure you are wearing a respirator, gloves, and long sleeves

• Using a handsaw or sharp dremel bit, cut the threaded rods to length

  • Note: if using a dremel be aware that the rod can heat up, wear thick gloves on the hand holding down the rod

• Using 5 minute epoxy, glue the PLA bulkhead and wooden bulkhead together for the top and bottom sections of the av bay

  • Allow this to set for at least 10 minutes, you can place a weight on top to hold each subassembly together while it cures.

  • Be sure to prevent any excess epoxy from pooling out from the sides of the seam (this will change the physical outer diameter and make it more difficult to slide into the airframe tubes)

• Drill out the holes of the PLA and Wooden bulkheads once the epoxy has cured to ensure the wires can pass through them easily

• Align the Aluminum Bulkheads with the PLA bulkheads and drill out the holes once again to ensure wires can pass through the assembly easily

Aluminum Bulkhead Manufacturing

• Insert the U Bolts into the Aluminum Bulkhead and attach the nuts on the other side

  • take care to make sure the nuts are level

• Add epoxy to the underside of the bulkhead between the nuts, ubolt, and bulkhead

• Add epoxy to the top of the bulkhead at the interface of the ubolt and the holes

  • allow that to cure

Assemble the AvBay for Test Fit

This is done so that we can be assured of the fit of all components before we assemble the av bay within the tube

• Begin first with the sled and work from the "inside" outwards

• PLA bulkheads around the sled on the top and bottom

  • this is a great time for any final filing to ensure the slide can slide in and out smoothly

• Slide the threaded rod past the first bulkhead, and add 2 nuts

• run the threaded rod past the second bulkhead and add an additional nut on the exterior side of each bulkhead

• adjust the nuts so that the assembly is secure against the surface of each side of the bulkhead (the nuts serve as placeholders)

  • check that you can slide the sled in and out easily and tighten or loosen the nuts as needed

• add an additional nut ~1 inch away from each of the most exterior nuts on the threaded rod

• repeat for the second threaded rod

• add the aluminum bulkheads to each side

• adjust the outer most nuts as needed to ensure the aluminum bulkhead is level! and the ubolt is gently touching the wooden bulkhead

• add the wingnuts to the exterior of the aluminum bulkheads to hold them in place

• make a final check that the sled is still able to slide in and out of the assembly and that all the nuts are properly tightened

  • then you take off the wingnuts and the aluminum bulkhead

  • leave the rest of the assembly together

• Test that you can slide the assembly into the tube and file as needed

• Place the assembly into the tube and mark where the epoxy for the first bulkhead will be placed

Assembly of AvBay within the Tube

Note that this is especially difficult and limited for BFO specifically because of the accessibility and mounting requirements of the av bay

1. Epoxy in the first bulkhead

• Begin epoxying procedure using JB Weld: https://docs.google.com/document/d/1DCgi2xNbCKLSVA-2AojZUtkCFQReliQGcxFavwJx-4g/edit

• The procedure for the first bulkhead is the airframe standard for epoxying bulkheads into the airframe tube

• The first bulkhead (put in place prior to the sled) can be done normally, with two precise fillets on either side done by hand.

  • The specific epoxy will depend on the material of the bulkhead and the material of the airframe.

  • in this case we have a fiberglass airframe and an aluminum bulkhead and are using JB Weld Epoxy

• INSERT SLED INSERTION PROCEDURE

• For the second bulkhead, Make a ring of epoxy on the inside of the airframe, pull the bulkhead past the ring of epoxy to create a fillet on the inaccessible side (recall we are assembling this av-bay layer by layer)

  • After the first fillet has set, on the remaining exposed side make a standard epoxy fillet

  • let set

Background

The Microbial Fuel Cell (MFC) was inspired by NASA Micro-12 studying MFCs for the purpose of wastewater treatment and electricity production. The purpose of our MFC payload is to determine the effects of rocket launch and flight on the performance and health of the MFC.

The first iteration of MFC was designed to to use wild-type Shewanella oneidensis bacteria in a LB broth with platinum electrodes. The bacteria were sourced from Adam Deutschbauer's Lab at LBL. However, due to the difficulty of the project and a fungal infection that wiped out the bacterial culture, we decided to pivot to a more robust and simpler design.

The second iteration of the MFC was designed to use electrogenic soil bacteria from locally sourced soil, mixed with distilled water with graphite electrodes. The maintenance of this iteration of the MFC was much easier and a control MFC of this design was manufactured to gather voltage data over the course of 2 weeks.

Harness Components

1. Quick Links- metal rings that connect the shock cord to the u-bolts and also connect the parachutes to the shock cord.

2. Shock Cord- durable kevlar rope that holds all of the rocket together when parachutes are deployed.

3. Bulkheads- metal cylinders that are important for structural integrity. The u-bolts thread through the bulkheads.

4. U-Bolts- Are connected to the shock chord by a quick link.

5. Swivel?

Fold the Parachutes (Ideally a two person job)

1. Dedicate a 10 by 10 foot area to fold the main chute.

2. Lay out the parachute on its side and gather the shroud lines (the string coming from the edge of the parachute). This means that if the parachute was fully open with the inside facing up and you were standing at the center of the parachute holding all the shroud lines, that you move to the side folding it in half.

3. Make sure the shroud lines are untangled.

4. Examine each section and patch holes

5. Examine each colored section and patch holes.

6. For each section on one half of the parachute, fold the colored section in half do the edges of each section meet.

7. Have the folded half of the parachute on one side and the unfolded half of the parachute other on the other side.

8. Before continuing, only two sections of the parachute should be visible, with half of it folded under one color and the other half unfolded under the other color.

9. Fold the edge of the unfolded half of parachute to the middle and the the other edge to the newly created edge.

10. From the resulting rectangle, bundle the short edge four times until you have a resulting almost square parachute.

If confused watch the video attached.

Ballast

Primary Payload Structure

Tie-down rods

Purpose: To constrain the payload structure along the long axis of the rocket

Important design considerations:

• We used flight data and openrocket simulations to estimate maximum acceleration loads at 16 g's

• Two #4 threaded rods are spec'ed to a FOS of ?????

• @Ritvik something about having two possible orientations to minimize issues in assembly

What we have one:

• Complete test fit of design

What is left to be done:

• Add to launch-day parts list

Lateral support system (i.e. leaf springs)

GPS Mounting

GPS mounting is designed to attach the GPS module on the inside of the nosecone. In the designing process, two important factors were considered, stability, and suitability. Also, there were restrictions which are the GPS mounting can't touch the top metal plate of the structure and the GPS antenna should be mounted straight.

For higher stability of the GPS module, mounting has 6 zip tie holes on the front. There are two ways to fix the battery and GPS module into the mounting. 1) Using zip tie, combine together battery and GPS module. 2) Or, insert the battery and the GPS module into the mounting and tied them up together. The GPS mounting and holes are small, so a tweezer is needed to assemble it.

For the suitability of the mounting, the rear side of the mounting is designed with the same curvature as the inside of the nosecone. Also, the curvature was measured at 10.5 inch far from the top plate of the primary payload structure.

• Payload Structure :

  • 1/16” Steel ballast plates (32)

  • 9” Miniature T-slot rails (8)

  • 4 1/2” Miniature T-slot rails (4)

  • Aluminum leaf springs (4)

  • Top base plate (1)

  • Center base plates (2)

  • Top aluminum bulkhead (1)

  • Bottom aluminum bulkhead

  • Wooden bulkhead spacer (1)

  • Tie down rods (2)

  • M3x35 button head screws (4) (Needs purchasing)

  • M3 hex nuts (44)

  • L brackets (64)

  • MX10101 nut plates (64)

  • MX10101 button head cap screws (64)

  • M3x10 button head screws (24)

  • M3x20 button head screws (8)

  • Adjustable wrench

  • 5/64” allen key

ASSEMBLY

1. Place 4 long t-slot rails on each corner of the top base plate.

2. Attach rails to base plate through 2 L brackets on each corner of base plate.

3. Using 2 M3x10 screws and 2 hex nuts on each corner, fasten each screw with all screw heads facing out of the opposite side of the t-slot rails.

4. Using 2 nut plates and 2 cap screws on each corner, attach other end of L bracket to t-slot rails by connecting nut plate through t-slot rail and screwing through the hole of the L bracket with cap screw.

5. Attach MFC payload in payload structure.

6. Push 4 cap screws through each leaf spring and screw on nut plate to each side of leaf spring.

7. Slide leaf spring through t-slot rails until top of leafspring is 0.9” from top of t-slot rail.

8. Repeat step 7 for each side of structure (4 total).

9. Repeat step 3 and 4 on other end of t-slot rails.

10. Attach center base plate to the top of t-slot rails by placing M3x10 screw through L bracket hole with screw head on same side of t-slot rails and hold.

11. Place L bracket through end of screw with tall end facing corner and tighten with hex nut.

12. Repeat steps 10 and 11 for each L bracket.

13. Repeat steps 1, 2, 3, and 4 with each corner of center base plate.

14. Repeat steps 3 and 4 on top of t-slot rails, instead letting drop to bottom of t-slot rails.

15. Hang 32 ballast plates on the bottom brackets.

16. Push the M3x35 screw through slots of ballast, ensuring the screw heads point towards open end of structure.

17. Secure the ballast by tightening hex nuts on opposite end of each M3x35 screw.

18. Attach Stabilization payload to structure.

19. Repeat steps 3 and 4 on top of t-slot rails.

20. Repeat steps 10, 11, 12, and 13, instead using the shorter t-slot rails.

21. Attach IRIS/Muons payload to structure.

22. Repeat steps 3 and 4 on top t-slot rails.

23. Place top bulkhead on top of t-slot rails.

24. Push M3x20 screws through L brackets with screw heads facing opposite the t-slot rails and fasten with M3 hex nuts.

25. Place wooden spacer on top of top bulkhead.

26. Place bottom bulkhead on top of wooden spacer.

27. Turn entire structure on its side so that t-slot rails are horizontal.

28. Push tie down rod through slit on the top base plate, through entire structure, and stopping once it is through the bottom bulkhead.

29. Repeat step 28 with the other side of the structure.

30. Screw hex nuts onto each end of tie down rods, tightening until the structure has tension.

31. Flip structure so that it is resting on the bottom bulkhead.

This report is intended to be used as a reference for all IREC 2020 payloads, as a preliminary description of all projects.

Excerpt (Abstract):

The Payload subteam of Space Technologies And Rocketry (STAR) at the University of California, Berkeley focuses on launching scientific instruments and experiments to high altitude: we are what makes rockets worth flying. This academic year, the payload projects, all integrated into a 5U CubeSat payload structure, include: onboard cameras, a dual sensor suite and cosmic particle detector, a microbial fuel cell, and an active stabilization system. The overarching mission objective is to record data and test experimental systems in-flight.

Introduction

Main Contributors and General Progress

The IRIS project combines two originally separate projects (IRIS Legacy and Muons) into a 1U CubeSat unit to conserve space in the payload structure.

Rajiv Govindjee, Jason Xu, Bryant La and Ocean Zhou are the main contributors to this project. Rajiv and Jason worked on the first iteration of IRIS while Jason and Ocean worked on the first iteration of Muons. It was decided for the sake of efficiency and adventure that the two detectors should be combined into one complete detector. Jason was heavily responsible for the electrical design of IRIS, in particular the printed circuit boards (PCBs). Bryant and Ocean worked on the mechanical integration of IRIS to the rocket. IRIS is currently in its assembly phase, although with the impacts of the COVID-19 pandemic, the assembly phase has faced delays.

IRIS Overview

IRIS Records Information via Sensors (IRIS) is a sensor suite printed circuit board (PCB), outfitted with an accelerometer, a gyroscope, a magnetometer, a barometric pressure sensor, and a High-G accelerometer. Its function is to record various flight data (acceleration, angular velocity, absolute orientation, barometric pressure/altitude) to assist in developing flight-critical avionics and validating current and future simulation work with respect to flight dynamics.

The IRIS assembly consists of three main PCBs. In order, from bottom to top, the three main PCBs are:

1. a power distribution board (IRIS-Power) connected to a two-cell (2S) 8.4V lithium polymer (LiPo) battery

2. a primary IRIS board (IRIS-Core)

3. an auxillary IRIS board (IRIS-Core)

Inspiration

Optional Sensors (Reserved for Future Use)

In addition to the motion sensors, there are two optional components on IRIS that are currently unpopulated but can be implemented in the future.

GPS

Pitot Tube Sensor

IRIS supports the addition of a differential pressure sensor, for implementing an external pitot tube in the future.

Electrical Hardware Design Overview

The electrical hardware (PCBs) are avaliable on our cadlab:

IRIS-Power

IRIS-Power occupies the bottom most board of the 3 board stack. The primary purpose of IRIS power is to output regulated power from the 2S LiPo, gauge the LiPo's charge with a battery fuel gauge IC, and provide a backup source of power in case the battery fails or is suddenly disconnected. The backup is provided through 2 supercapacitors that can provide several minutes of backup power.

Additonally, the power board has the ability to automatically switch to a connected USB-C power delivery adapter in order to save battery charge during bench-top testing and programming.

IRIS-Power provides 5V for the Teensy 4.1 MCU on IRIS-Core, 3.3V for other extra ICs, and 29.5V for the photo-multipler Muon sensor.

IRIS-Core

IRIS-Core is the primary module of the 3 layer stack. The middle board of the 3-layer stack is a full-fledged IRIS-Core board, while the top board of the 3-layer stack is a partially populated IRIS-Core board.

The full-fledged middle module contains a Teensy 4.1, IMU breakout board, High-G accelerometer breakout board, and a muon sensor.

The partially-populated top module contains a Teensy 4.1 and a muon sensor.

Very Useful Diagrams

For some very useful diagrams detailing the pinouts, peripherals, and power flow connections, see the following pages:

Design Log and Updates

Mechanical Design

(12/06/20): There is no way to fasten a nut on a screw from inside the enclosure. The enclosure will be secured to the T-slotted rails with eight screws going through eight brackets, held in place by having the screws serving as pegs into slots. The screws are at different heights, so interference is not an issue.

Electrical Design

(12/06/20): The backboard support PCB has been replaced with the stack connectors (pin headers) pictured below. This was done for simplicity of design, to reduce the space taken up by the PCBs, and to prevent interference between the vertical threaded rods and the fasteners attaching the enclosure to the T-slotted rails. The enclosure and spacers have been updated to accommodate this change.

Manufacturing

Engineering Drawings

Prototyping Processes

The enclosure measures 7.9 cm x 7.9 cm x 10.635 cm, and can be manufactured via 3D printing with PLA material.

Progress

(12/06/20): The PCBs were ordered and arrived. Bryant La will solder the components on campus with a reflow oven over winter break, with Jason Xu's remote assistance. Boards will be shipped to Jason Xu for him to attempt soldering without a reflow oven, though he does not need to succeed for the project to progress.

The BOM is being finalized and the parts will be ordered soon. Once fully manufactured, the code will be rewritten to interface with the combined IRIS/Muons.

(01/25/21): Both Jason Xu and Bryant La are near campus and will work together to finish manufacturing for this project.

(02/14/21): The power board and one of the sensor boards have been soldered. Jason Xu and Bryant La will need to procure the existing completed Muons boards from the Supernode locker to move their scintillators onto the new IRIS/Muons boards. After soldering of the final board is complete, efforts will be focused on writing the board firmware.

Launch Results

At the time of writing (May 2020), due to power and launch issues, IRIS has been unable to record data during flight for any launch. Data obtained so far has been limited to what IRIS senses during assembly on the ground, which showed little variability as expected; however, the values IRIS reports are accurate (e.g., the barometer shows atmospheric pressure near sea level), which is evidence that the sensor suite functions as it should.

Muons has been launched like IRIS and was able to record data during flight. However, due to the minor detector malfunction, relating to multiple data files being saved for unknown reasons, the data obtained was unable to offer much use; besides total muon count, it was impossible to pinpoint which files corresponded to different points during the flight. Nonetheless, the fact that the detector was able to record muon count and that the muon counts increased over time indicate that the detector is able to function properly during flight.

The previously assembled detectors have been tested twice. The first test was to ensure that the measured voltage signals matched the expected values, in which the detector succeeded. The second test measured how the angle of the scintillator (with θ = 0° being the horizontal orientation) affected muon count measured within an interval of 1 minute. This was done to decide the orientation the detector was to be at inside the rocket. Having the scintillator at a horizontal orientation yields the most counts.

References

Background

The IRIS journey started in 2018; IRIS v1 was conceived of as a project for the Hands-On PCB Engineering (HOPE) DeCal. The board was assembled in Fall 2018 and found to be relatively functional, with difficulties arising mostly due to lack of software libraries for the ICM 20948. IRIS v2 was designed and assembled in early 2019, adding rounded corners, more sensors, options for breakout boards, test points, improved power electronics, and more. IRIS v2 was also more successful on the software front; all sensors tested worked nominally, including the ICM 20948. Code for IRIS v2 can be found at https://github.com/calstar/Payload. While IRIS v2 was intended to fly on Spectre, STAR's ambitious entry for IREC 2019, Spectre was never constructed due to significant engineering challenges.

For a more detailed look at requirements and progression of IRIS v1 and v2, see the IREC 2019 documentation: IRIS

AirBears Test Flight

IRIS v2 was flown on AirBears on 2019-11-16. To prepare for this flight, the casing was significantly re-designed to integrate with the other payload (Muons) on the test flight. Software was completed to allow for continuous recording of IMU data to the on-board SD card on the Teensy.

Unfortunately, as a result of non-comprehensive assembly procedures and some time pressure to assemble the payloads, IRIS was flown while not in a recording state.

The following recommendations were made following this test flight:

• Implement some method for back-up power (capacitor, coin cell battery, etc.). This ensures writes to non-volatile memory have time to safely complete.

• Create robust procedures and test them entirely before launch. This includes all integration needed with other payloads. Add special notes if power may not be disconnected from the payload after a certain point.

• Perform as much assembly as possible beforehand. Ensure that no more than 30 minutes are needed at launch for assembly; time someone actually completing this assembly beforehand.

Current Work

The team is currently working on physical design and manufacturing for IRIS to fly in the IREC 2020 payload suite as one of 5U worth of CubeSats. Work is also underway on a potential IRIS v4 board, although not required for competition readiness. Software is the largest hurdle for the competition; some development may be required to communicate with all sensors on multiple SPI buses at once (effectively).

• PLEASE learn how to solder printed circuit boards. Though it is not hard to pick up, learning understandably still takes time. At Cal, you can either practice soldering in the Chen-Ming Hu Lab in Cory Hall Second Floor (aka SuperNode), or in the Electronics Lab in Jacobs Hall. Here's a tutorial to get you started: https://www.youtube.com/watch?v=Qps9woUGkvI

• Find a way to machine the scintillator if the one you bought is not already machined. The manufacturing drawing is attached below: https://github.com/spenceraxani/CosmicWatch-Desktop-Muon-Detector-v2/blob/master/CAD/Scintillator%20CAD%20file.pdf

• After you purchase the SiPM and it arrives, PLEASE place it somewhere safe and load-free. Do NOT crush the SiPM as it is very delicate (and expensive!)

Assembly Instructions

1. Buy all required electrical components

2. For the Arduino Nano, be sure to upload the coincidence.ino code to it, as this ensures a muon will be counted! Refer to pdf attached below for specific detail.

3. Solder the electrical components onto the 3 PCBs (Main Board, SiPM Board, SD Card Board). Use this as the guide to know where to solder the components: https://github.com/spenceraxani/CosmicWatch-Desktop-Muon-Detector-v2/blob/master/PCB_Files/SMT_reference.pdf

4. Drill 4 mounting holes into SiPM PCB. Polish it afterwards.

5. Wrap the scintillator in reflective foil.

6. Put optical gel on SiPM board and mount it to scintillator using the mounting holes on the SiPM board.

7. Wrap both with electrical tape to make light tight. Important! Carefully wrap or else "light-leak" will occur. This will distort your results!

8. Plug the SiPM PCB into the Main PCB through the header pins.

9. Finally, upload the SDCard.ino code to the Arduino Nano.

10. Plug in a 5V power bank to the detector and make sure that the HV pin on the Main Board delivers 29.5 V.

For greater detail, read the entire instruction manual: https://github.com/spenceraxani/CosmicWatch-Desktop-Muon-Detector-v2/blob/master/Instructions.pdf

(Please Read!) Miscellaneous Files/Instructions

• Please make sure you have access to the STAR GrabCAD! If you do not, you will be unable to locate any of these files*

• Also make sure you have SolidWorks 2019 and Ultimaker Cura 4.4.1!*

• Please also purchase a Makerpass for Jacobs Hall Access. It will make your life so much easier for assembly*

• After you obtain your Makerpass, get training on the Wood Laser Cutters, Ultimaker 3D Printers, Electronics Lab, and FabLight metal laser cutter (this last one isn't really necessary but it's so fun that I think you should still do it!).

• The detector CAD is located in the IREC 2020 GrabCAD under:

  • Upper_Section -> Payload -> Muons_IRIS -> Detector_CADs -> IREC20_PAY_MuonDetector.

• Under the Muons_IRIS folder, the other folder called "STL Files". These are the CAD files in the Detector_CADs folder but translated into .stl files which can be passed in Ultimaker Cura and in turn be 3D printed.

Plan for IREC 2020

While we did collect data from our AirBears launch, it correlated only time with muon count. Furthermore, 4 separate SD files were created, meaning we had no idea at which height did the counts correspond to, making the data not as useful.

To combat this, our beloved payload lead Jason Xu (Woo!) is working to merge IRIS and Muons together as IRIS records height (through pressure) which allows us to see how muon count correlates with other parameters besides time. Excited events to come!

Sources

1. https://www.space.com/32644-cosmic-rays.html

2. https://www.pnnl.gov/main/publications/external/technical_reports/PNNL-20693.pdf

3. https://www.radioactivity.eu.com/site/pages/Cosmic_Muons.ht

Description

The Cameras project uses the Mobius Maxi camera mounted on a custom base plate that is epoxyed on the airframe's exterior with a custom shroud.

Two shrouds shall be mounted. The camera shrouds have been optimized to maximize field of view while minimizing impact to the aerodynamics of the airframe, allowing the cameras to record the flight with as much detail as possible without being a detriment to vehicle performance. The recorded results are retrieved from an in-camera SD card post-landing. The captured footage should theoretically document the rocket in flight even after it escapes visual range from the ground.

System Weights, Measures, and Test Reports

Each Mobius Maxi measures 7.1 cm x 3.5 cm x 1.8 cm and weighs 52 g. Each shroud measures approximately 13.2 cm x 4.1 cm x 3.8 cm and will be manufactured from PLA material using 3D printing.

At the time of writing, no in-air flight recordings have yet been captured. Recording testing has been performed, but the full extent of camera capabilities have not yet been documented. A battery life test has been completed along with a shake test to mimic the turbulance he camera would experience while on the rocket. The Camera was able to record for over 2 continuous hours with minimal quality degrigation as a result of shaking. Worst-case test is planned in the future, with active external heating to mimic launchpad conditions.

CADS

CADs are for the camera's custom shroud.

Hazard Analysis and Risk Assessment

The primary risks and failure modes associated with Cameras are depletion of the battery and structural failure of the shroud during flight. The camera shroud could sheer off from the baseplate, take damage from shaking from not being properly secure in the shroud. Test on different epoxies are being conducted to determine which would best minimize the risk of the camera seperating from the body of the rocket, with the possibility of grooves being put in place to increase surface area contact.

Without power, the Mobius Maxi camera cannot record data. Mitigation strategies include fully charging the camera the night before and setting the video recording settings to their lowest power consumption setting.

Structural failure of the camera shroud would cause parts of the shroud or the entire shroud to shear off of the launch vehicle, potentially even changing the vehicle's trajectory. Mitigation strategies include printing the shroud at higher densities and out of stronger materials, and checking again that the shroud is properly mounted before launch.

Assembly, Pre-flight, and Launch Checklists

Pre-Flight

1. Charge both Mobius Maxi cameras with MicroUSB cable.

2. Place one MicroSD card into each camera.

3. Configure settings on both cameras to be appropriate to flight mission and launch conditions, including recording automatically when power is turned on.

4. Turn cameras off.

5. Place shroud onto the baseplate with lens oriface towards fins and align the two holes on the shroud with the corresponding two holes on the airframe.

6. Secure the lower, fin-most hole with the nut plate on the other side of the airframe wall.

7. Place camera into shroud so the lens faces the fins.

8. Secure the upper hole with the nut plate on the other side of the airframe wall.

9. Secure the shroud cap onto the shroud, ensuring that the locks snap fast onto the side of the shroud. If uncertain, apply adhesive.

10. Remove lens cap from camera.

11. Turn on camera and start recording.

12. Repeat steps 5–11 with second camera on opposite side of launch vehicle.

Post-Launch

1. Retrieve all payload components from the downed rocket.

2. Turn cameras off and stop recording.

3. Disassemble camera assemblies.

4. Read and analyze data from the SD card.

What do we do?

• Make visuals for the club in the form of videos, flyers, and posters.

• STAR Merch?!

General

Who are we?

We are UC Berkeley's competitive high-power rocketry team. We build rockets! Our mission is to enable students from all majors and backgrounds passionate about aerospace to gain hands-on experience through real-world projects. As part of STAR, members can expect to develop a set of valuable engineering skills, including experience with manufacturing, 3D CAD, simulation, project management, and more. For more information, check out our website at https://stars.berkeley.edu/!

What are the subteams?

Hardware Subteams

• Airframe

• Avionics

• Payload

• Propulsion

• Recovery

Non-Hardware Subteams

• Operations

• Simulations

• Systems

• Business/Finance

• Outreach

• Media

Our projects

Ursa Minor: subscale for our entry in NASA Student Launch 2017

Ursa: our entry in NASA Student Launch 2017

Sub-Arktos: subscale for our entry in NASA Student Launch 2018

Arktos: our entry in NASA Student Launch 2018

AirBears: our 4" diameter test rocket, launched in Fall 2019

Bear Force One: 2020 launch vehicle, intended for IREC 2020 (competition cancelled due to COVID-19)

LE-175 "Hot Take": our liquid engine LOX/Kersoene test article

ELLIE: Our GOX/ethanol liquid engine test stand: successfully hotfired in May 2022

SSEP1: UC Berkeley's first stage separation rocket. Successfully launched at the Friends of Amateur Rocketry site in September 2022.

MINDI: UC Berkeley's First minimum diameter vehicle. Successfully launched at the Friends of Amateur rocketry site, smashing the current Cal altitude record at a whopping 14,325 feet!

ALULA: STAR's first flyable liquid engine! Set to hotfire March 2023, and fly soon after!

DAVE: STAR's first glider payload will deploy out of Bear Force One to carry payloads for longer periods of time.

CalVistor: STAR's entry into the IREC 2023 10K competition. Features a 6 inch diameter airframe, dual side dual deploy recovery system, and some epic payloads: muon detectors and a seismograph!

Check the website for more details, as well as our Launch History.

Joining STAR

Is there an application?

No! We do not have an application, and we accept any and all interested members. STAR has championed our no-application policy since our founding in 2016.

Is there a membership fee?

No! STAR is completely free to join, and there is no required membership fee. During a normal semester, many of our members opt to obtain the Jacobs Hall makers pass but this is entirely optional. Expenses made by members for club purposes (ie. buying raw materials and parts for our rockets) are usually reinbursed by the club (subject to subteam lead approval).

Do I need to have any experience to join?

No! A large majority of our members joined with little to no prior experience in rocketry. Yet through our own passion and motivation, we have been able to create fully functioning rockets! While having technical or business experience is nice, we primarily expect from our new members two things: passion and dedication.

Do I need to be an engineering major to join?

No! In addition to some of the non-technical teams mentioned above, one of our primary goals is member development and education. We have had a large number of members in non-technical majors do design, engineering, building, manufacturing, and testing of all different systems. With workshops and a mentorship program, we hope to teach all the tools you’ll need so that anyone who wants to is able to contribute.

Now that I'm interested, how do I join?

You can check out which of the subteams interest you and attend their meetings or talk to the leads in-person or on Discord. Once you have a subteam you're interested in, there is an intro project that you should complete to join the subteam. The intro project is not meant to be a homework assignment or something you have to tackle alone. There will be office hours and workshops to help you complete it, and we encourage collaboration!

You'll find all the practical info you need on the New Members page:

How often do you meet?

Twice per week. General Meetings ("GMs") and subteam meetings are usually two hours each every week. You might also meet outside of regular meetings for build days, design reviews, or other to hang out and gain subteam points! GM's this semester are Thursdays from 8-10 PM in Jacobs Hall and Subteam meetings are Mondays 7-9 PM in Etcherverry Hall!

Subteams

Airframe

What does Airframe do?

• Design and manufacture launch vehicles

  • Includes the structure, materials, aerodynamics, and stability of the rocket

• Help integrate the systems of other subteams

• 3-D model using SolidWorks and OpenRocket

• Perform composite lay-ups to create airframe components.

• Use a CNC tube winder to manufacture tubes and other airframe components

• Mechanical design, systems engineering as needed

What is Airframe doing this year?

We are designing and building the airframe for our 6-inch diameter IREC rocket with a target apogee of 10,000 feet; this includes tubes, fins, the motor mount, couplers, brackets, fasteners, and more.

Avionics

What does Avionics do?

• Make flight electronics systems and corresponding ground systems

• Design custom circuit boards, flight software, ground station software for telemetry and analysis

• Antennas, wiring, and interfacing with other elements of the vehicle

• Electrical and software design, mechanical as needed

What is Avionics doing this semester?

We are designing and assembling the entire system architecture for Spectre. This includes flight computers, telemetry and power control, sensors, and more. The design cycle started with deriving requirements, and selecting key components, and moved into PCB (Printed Circuit Board) design (schematic and layout). Currently, we're working on revising the PCBs and starting to write firmware and software for our platform.

Payload

What does Payload do?

• Develops experiment concepts for payload challenges

• Designs payloads and collaborates on interfaces with other teams including Airframe, Avionics, and Recovery

• Manufactures the payload! Payloads are primarily composed of custom parts made in Jacobs and the Etcheverry Hall machine shop

• Runs through tests to ensure the payload suite meets all specs

• Science, mechanical and electrical design, software as needed

What is a payload?

The payload is what the rocket is carrying, typically a satellite, scientific experiment, or even humans (for larger rockets).

What are some of the previously flown payloads?

• Upright landing and target detection (SAGITTA-VL ... no one knows what this stands for)

• Autonomous rover including mechanisms to separate the airframe (black powder charge) and push out the rover (scissor lift). Rover's mission was to drive 5 feet and deploy a set of folding solar panels.

• Cosmic ray (muon) detector

• Sensor package (pressure, acceleration, orientation, angular velocity, temperature, humidity, etc.)

What is payload doing this year?

We are designing and building a whole suite of science experiments and sensors to fly to a height of 10,000 feet.

Propulsion

What does propulsion do?

• Responsible for putting the rocket in the air

• Building the engine for the rocket

• Combustion, fluids, cryogens, mechanical and some electrical design

• Specifications for software

What is propulsion doing this year?

We are building a prototype liquid bi-propellant engine. Design work in progress includes designing test structures, an integration structure, and improving parts of the engine itself.

Recovery

What does Recovery do?

• Responsible for the entire descent of the launch vehicle, including pyrotechnics and parachute deployment

• Ensuring a safe landing of the vehicle

• "Jack of all trades" subteam with tons of hands-on work

  • Fabrication, Electronics, Physics, CS, Systems

What is Recovery doing this year?

We are developing a novel stage separation mechanism, as well as managing the recovery of all launch vehicles in development.

Operations

What does Operations do?

• Manage and enforce team-wide safety standards

• Handle launch operations, checklists, and integration of the launch vehicle

• Organize and maintain our GitBook!

  • This includes both tutorials and project-specific documentation behind-the-scenes

• Technical design reports for competition

• Launch checklists, procedures, and FMEA

• Manage project-wide testing and verification of parts and systems

• Make sure the inventory is up-to-date and usable

• Manage CAD data

• Look into regulations and law surrounding rocketry

Why should you join Operations?

Having experience working with project documentation is a highly sought-after skill by employers of all kinds. Being able to maintain docs for your project shows that you are organized and capable of communicating your ideas with others. Furthermore, tools like checklists, FMEA/FMECA, and especially unit and integration testing are used heavily in industry, and the Ops team is a great way to get familiar with these early on in your career!

If you're more interested in the safety side of Ops, learning how to work safely with dangerous materials and devices can be a great experience for those looking for or already participating in research or work using lasers, cryogens, high-pressure systems, composites, flammables, etc.

Simulations

What does simulations do?

• Responsible for Design Verification and Concept Check

  • Using ANSYS, SimScale, hand calculations, and other computation software

• Simulating flight trajectories and fluid dynamics

• Stress analysis and hazard identification

• Analysis of sensor data from flights

Some info:

We have a base containing large electronics supporting our servos and arms. Each servo provides rotational motion to one axis with range of +-90 degrees (180 total), with an initial configuration of all axes being orthonormal to each other. The first servo is attached to our base, which controls an arm that our next servo is mounted to. This second servo controls the next arm that our third servo is mounted to. Our last servo, however, does not control an arm, instead it controls a platform, the platform which we would like to stabilize.

Inventory:

Electrical Components

All electrical components below, unless otherwise specified, we have in inventory. For everything without a number or description, assume we have one part in inventory.

• Arduino Nano

  • Connects all components together and provides communications/calculations between components.

• 1S 3.7V Lipo Battery

  • Power source for stabilization.

• Booster Converter (many extra)

  • Need 5V for most (all?) components, and the lipo only provides 3.7V, so we use this to step it up.

• Photo-relay (still needs to be ordered)

  • We don't want to waste any power before launch, so we can use a photo-relay to only allow current to the servos once the MPU's detect launch.

• Resistor (330 Ohms, have extras)

  • We need one resistor to connect to the photo-relay to have it perform to expectations (ideally it would be 336 Ohms).

• MPU's (x2)

  • One MPU is attached to the base of our stabilization unit, this gives us gyroscopic and acceleration data of how the rocket moves through time. This MPU also provides data so that we can provide the adequate torque to our servos to stabilize the platform. Our second MPU is mounted on our platform, this will provide data for how well our platform is being stabilized. We can take both our MPU's data and record it to the SD Card.

• Servos (x3)

  • Provides mechanical control of the three arms (be wary of Gimbal Lock problem).

• MicroSD Card

  • Provides storage for sensor data, which we can analyze after launch.

• MicroSD Card Breakout Board

  • A board which provides us the ability to write to the MicroSD card using the arduino.

• Protoboards (many extra)

  • A board so we can solder some of our components (like the Arduino Nano and Photo-relay) and keep them reasonably secure during launch.

• Wires (stranded, 26 gauge, 50 feet)

  • Electrons

• Servo Extensions (many)

  • The most convenient way to connect our servos to the power and arduino.

• Lipo Connectors (many)

  • The most convenient way to connect our lipo to the converter.

• 1S Lipo USB Charger

  • A convenient way to charge our lipo (before testing and launch, not during).

Mechanical Components

• Servo Bolts

• Servo Nuts

• Sensor Bolts

• Sensor Nuts

• Arduino Bolts

• Arduino Nuts

• Arduino Spacers

• MicroSD Card Breakout Board Bolts

• MicroSD Card Breakout Board Nuts

• Booster Converter Fasteners

• There are many existing tutorials out there on the web that probably will provide a more detailed step-by-step procedure and description on features of Premiere Pro.

• So here, we'll talk about what information you'd want to put in for a club promotional video.

• Promotional Videos

  • Objective

    • Recruitment: to attract audiences/ potential members to our club

    • Crowdfunding: to attract donors/sponsors for financial support ex) Crowdfunding

  • Depending on the objective, what content you want to include in your video will change!

• Recruitment Videos

  • Emphasize the variety of subteams we have (technical AND non-technical)

    • technical subteams: emphasize projects with short descriptions with minimal jargon

    • non-technical subteams: emphasize the impact they have/ the non-trivial role they play in the club

  • present our long term and short term goals so students understand what our team's vision is

  • Photos

    • insert images of social activities we have inside and outside the designated club events (i.e. outside of General Meetings)

    • Clips from our launches are always a crowd pleaser

    • general tips

      • sync the audio and the visuals so that the visuals aid whatever the audio recording talks about

      • transitions look less choppy with 'Cross Dissolve' or fades

• Crowdfunding Videos

  • Emphasize the variety of subteams we have (technical AND non-technical)

    • technical subteams: emphasize the significance and diversity of projects within the club

    • non-technical subteams: always include how we aim to give back to the community through education and outreach (not only because we actually prioritize this, but donors love that ;) )

  • present our long term and short term goals so donors understand what our team's vision is

  • Photos

    • Clips from our launches are always a crowd pleaser

    • As mentioned before, outreach images are also crucial

    • CADs and layouts/schematics of our projects also spotlight the intellectual value in the projects we do and the knowledge we pursuit.

  • Including videos of people talking (i.e. interview clip) always adds a nice humanly touch to the otherwise money-hungry typical crowdfunding video

Starting this year, STAR will be using SolidWorks PDM for version control and file sharing for 3D models. Once everything is set up on the server side, we will update this page on how to access PDM and get it set up!

Installation

SolidWorks Student Edition (2022-2023)

STAR is migrating to the SolidWorks 2023 Student Edition.

• Go to: www.solidworks.com/SEK and complete the form (first name, last name, Berkeley email address, select “student team” on dropdown)

• Under product information

  • Select Yes (I already have a serial number)

  • Choose 2022-2023 version

  • The serial number is listed in the discord server under #info

If presented with the option above in the installer, it is recommended to upgrade rather than create a new installation to save space.

On the summary page of the installer, you can select which products you wish to install. At minimum, you will need the 7.1GB SolidWorks package.

Instructions on downloading and installing SolidWorks Student Edition 2023 can also be found here.

If you need more help, this video can help walk you through the process!

Starting the Online Training Module

Information about the training requirements can be found at the following website, under the section title "Working at the RFS Training Module". Detailed instructions from the page will also be listed below.

1. Go to this link, you will be prompted to login with your Calnet identity: https://jwas.ehs.berkeley.edu/lmsi?deepLinkActivityId=247519

2. If the link above does not immediately work, try this link: https://jwas.ehs.berkeley.edu/lmsi

3. At the UC Learning Center welcome page, navigate to the correct training course by searching for "Richmond Field Station" and selecting the course "EHS 703 Working at the Richmond Field Station".

4. Start the training, if you are prompted for Organization, enter "STAR", or if you are prompted for a Faculty Adviser, "Ömer Savaş".

1. After completing the training, you should have a completion certificate. Take a screenshot of it (instructions to take a screenshot), or save it as a PDF.

What is a reimbursement?

STAR is a Registered Student Organization under the Associated Students of the University of California (ASUC). As such, our funds are stored in their accounts and must be paid out according to their policies. Probably for better documentation and to ensure all money is spent properly, they only disburse funds after we purchase the items. This disbursement is your reimbursement.

How do I submit a reimbursement?

Step 0 - Become a member on our CalLink page

Only members can submit a purchase request. In the eyes of the ASUC, our official membership list is on our CalLink page. The following steps will show you how to get on our CalLink roster.

First, go to our CalLink page here: https://callink.berkeley.edu/organization/star/. Sign into your Berkeley account and click Join to request membership. This is a one-time thing, and will allow you to submit a Stage 1 Purchase Request.

Step 1 - Submitting a Stage 1 Purchase Request

Open the Purchase Request page

Once you have been approved as a member, again, navigate to our CalLink page: https://callink.berkeley.edu/organization/star/. You should see the following page:

Then, click the STAR icon on the left banner. The icon will turn into a gear when the mouse hovers over it. This will open a sidebar. Click the Finance option.

Start a new purchase request

Click the Create New Request button and then Create New Purchase Request from the drop-down options.

Fill out this form as accurately as possible.

For Subject, use the format [full name] - [subteam] - [item description]. For example, this might look like:

Rajiv Govindjee - Propulsion - Test Stand Hardware

The description of items in the Subject should be brief but descriptive; try to use between 2-5 words. You can elaborate below in the Description field as well.

Enter the Requested Amount; this should be the total for the purchase request. Purchase requests (PRs) are usually one item, but you can theoretically put up to six items on a single CalLink PR.

For Categories, chose Reimbursement - Any amount. If you feel like you must use one of the other categories, please reach out to the Business lead.

Refer to the table below for Account:

Fill out the Payee Information completely. If you are getting a check mailed to you, this address is where it will go.

Expenditure Actions

Select an expenditure action

Check out the following chart for more information about three common actions:

Fill out itemized sections

For most cases, you can leave Special Instructions and Event Details blank.

Fill out the required fields for Item #1 (Date, Type, Vendor, Location, Total)

The form asks you to attach receipts: failure to do this will mean the request is rejected. Below is a sample procedure to reliably get your PR approved:

1. Download or scan and upload an invoice or receipt from the vendor. For Amazon, invoices must show the word "Shipped". For McMaster, it's best to concatenate the Receipt and Packing List (shipping confirmation), but you might be able to get away with just the Receipt (as long as it shows shipping cost).

2. Redact the invoice/shipping notification as appropriate.

3. Download a PDF of your credit card / bank statement (and make sure it's not password-protected to edit; you can use "Print to PDF" from your browser if this is an issue).

4. Use a tool like Adobe Acrobat DC (free for students at https://software.berkeley.edu/adobe-creative-cloud) to redact sensitive information like routing numbers, other purchases, balance, etc. (optional, but recommended).

   1. You will need to leave your name, dates, amount of relevant purchases, and the last 4 digits of your card number _unredacted._ The ASUC can and will reject PRs without this information on your statements.

5. Verify the invoice total matches the credit card statement total. If it does not, the ASUC will likely reject your request.

6. Verify the Payee name matches the bank/credit card statement. The ASUC will likely reject your PR if this is not the case. It may be acceptable to have no name on the reciept, but not one that does not match.

7. Use a tool like Adobe Acrobat DC to concatenate the invoice and statement into one file, omitting any irrelevant pages.

8. Upload the file.

Repeat the process for Item #2, ... , 6 if applicable. Most PRs contain only one item.

Verify and submit

Submit the Purchase Request.

Step 2 - Prepare for Stage 2 and beyond

Once you have submitted the PR, your job is complete! STAR's stage-2 financial agents, who are usually in the business subteam, will approve your PR or contact you for further questions! If you realize that you have made a mistake, please inform the agents. You can do that either by direct messaging or sending the message to the Business channel in STAR's Discord Server.

Step 2.5 - Submit proof of payment and wait for confirmation from a STAR representative (Only occasionally applicable when your PR is listed in Stage 3)

Please e-mail proof of payment (credit card statement or bank statement) to asucfinance@berkeley.edu. The email must include:

• The purchase request number in the subject line

• The name of the payee

A finance representative from the team will review your request and elevate it to a Stage 2 request. We will check that the amount requested matches the amount on the proof of purchase, and we will check that you have all required proof of purchases.

Once approved, you will be notified through email or Discord. You can also check status from the Finances page.

If your request does not meet our requirements, it will be rejected. Please check this page to make sure you met all the requirements.

Step 3 - Wait to hear back from the LEAD Center

Wait for approval from the LEAD Center. They may reach out to you for more details. If your PR(s) are listed in Stage 5, that means your reimbursement(s) have been approved.

Index

Navigating the old Callink web page layout

Once you have been approved as a member, again, navigate to our CalLink page: https://callink.berkeley.edu/organization/star/. Click Manage Organization in the upper right corner.

Then, click the expand menu button (three horizontal bars) on the upper left corner . This will open a sidebar.

Click the Finance option.

Click the Create New Request button and then Create New Purchase Request from the drop-down options.

Now you are ready to resume the tutorial above. Click here to return.

Downloading ANSYS

To download ANSYS Student, navigate to . Scroll down and select ANSYS Student, then click on the Download ANSYS Student 19.1 button that appears below.

Installing ANSYS

After the folder finishes downloading, unzip it with your favorite unzipping tool and navigate to the new folder. Then, open a file found inside the new folder labeled Setup.exe. Click the Next arrow in the bottom right corner as you progress through the setup. Once installed, you can open ANSYS by searching "Workbench 19.1" in your computer's start menu.

Known Issues

We have experienced an issue once where the workbench application did not install. In this case, delete the ANSYS program file in your C drive and repeat the process above.

VMware is a software that is free for Berkeley students that allows you to run windows on a non-windows computer which will allow you to install and run SolidWorks. Bootcamp is a program native (already downloaded) on macs that also allows you to run windows on a mac. Both options have some pros and cons which will briefly be detailed below. If you already know what you want to use, skip to the directions. If you have any questions/problems with the directions feel free to contact Ananya Subramani on the STAR Discord.

VMware and Boot Camp Similarities

• Allow you to run the latest version of Windows

• Can run SolidWorks

VMware and Boot Camp Differences

• VMware is easier to start up (like starting up a browser or generally opening up an app)

• Boot Camp requires you to restart your computer whenever you want to run in a windows environment

• Boot Camp requires you to permanently partition your hard drive which cannot easily be changed after it is done.

  • Partitioning your hard drive here means that some amount of your drive will only be accesible to the windows boot and the rest will be accesible normally

  • Main thing here is that you can't get more memory/storage if you need it in the windows portion easily

• VMware does not require a permanent partition so the size can change

• Boot Camp will run SolidWorks more smoothly because all of your RAM can be used

• VMware will be able to run solidworks, but it may not be as smooth because you won't be utilizing all of your RAM

My personal reccomendation is to use Boot Camp if you plan to use solidworks very actively, and VMware if you just want to look at files in more detail than grabcad shows. If you have a lot of RAM though, you could probably just go with VMware and be fine

How do I get Boot Camp/VMware to work?

Step 0- System Pre-requisites

You will need the following things, or the download will probably fail at some point:

• Mac made in 2011 or later

  • exception: 2012 Mac Pro “Quad Core” using the Intel® Xeon® W3565 Processor

• OS X 10.11 El Capitan minimum required

  • You can check this using the "About your Mac" tab in the top left corner apple drop down menu

• >50 GB free storage

Step 2- Get a Windows License

Click on Windows 10 and add it to your cart. If you want to use VMware, go to step 2.5, if you want to use Boot Camp, check out and go to step 3.

Step 2.5- Get VMware

From the same place you should be in step 2, go to the VMware tab and download VMware Fusion 11.x (for Intel-based Macs). You should get to this screen:

Add VMware to your cart and check out.

Step 3- Download Windows Operating System Disk Image

In the details of your purchase that you made in step 2, there should be a windows license number, you will need that.

My screenshot doesn't have a Windows license number because it's been more than one month since I "bought" it but yours should.

Select the proper language, and download the 64-bit version

VMware users, go to step 4, Boot Camp users go to step 5

Step 4- Setting up VMware

Download VMware fusion from the cart and open and install the application. When it asks for a number during the setup process, enter the serial number that I blacked out in my screenshot.

Once you see this screen, drag the windows 10 iso file into the place where it says install from disc/image (the default name for the downloaded file is shown below)

From here, just go through the installation steps and once you have your virtual machine configured and you can access the internet, go back to the solidworks installation guide and follow those steps *in* your virtual machine.

Step 5-Setting up Boot Camp

Using the spotlight search or some other search bar on your mac look up "Boot Camp Assistant" and open the app. You should see the following screen.

From here, hit continue and you should be able to choose your partition size, with the minimum being 42 GB, which should be fine, but if you are willing to dedicate more space to a Windows partition, go for it.

Once you've completed the installation process, you can boot into your windows partition by restarting your mac while pressing the "option" key.

Once you are in your Windows partition, you can go back to the SolidWorks installation guide and download SolidWorks.