Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Current »

Background and Motivation

In 2022 KOTS had some stability and launch rail velocity problems partially caused by not knowing the weight of rocket components until very close to competition (after the fins had been sized). Another cause was uncovering the lack of thrust at the beginning of the Kismet engine burn which decreased off rail velocity by an alarming amount. 

In general, further rocket integration and optimization of flight profile has been identified as an area with good potential for growth in the future. Both to reduce likelihood of integration mishaps as well as to improve overall design consistency and focus effort on high reward projects.

Project Description

This project is to create a cycle where:

  • Subsystems create design concepts and do design work as before

  • Subsystems and engine team estimate length, mass and engine performance at specific check-in dates (most likely providing high, low, and predicted values). Note engine team would be creating RSE files at each cycle.

  • This data is fed into various OpenRocket simulations determining apogee, stability, acceleration (for loads), velocity (off launch rail and throughout flight), and any other flight characteristics of interest.

  • Load simulations run using acceleration data

  • Resulting simulations are used to write a short digestible report about the results and the highest value design focuses to be disseminated throughout the team and the team leads.

  • Subsystems are aware of the rocket as a whole and how any changes impact the overall system.

  • Cycle repeats until design lock with length and mass estimations becoming more and more precise as design is finalized. 

A minimum viable product if time/team cooperation is difficult, is to offer case by case simulations to determine how various design changes already under consideration would affect the rocket. This could also be done at the same time as “cycles” however would not be ideal to do alone as it is likely to miss the larger system. 

  • For sure this will be done for fin sizing as in previous years.

Requirements

  • Must gather information from all rocket subsystems with reasonable confidence that the data is within some accuracy. To ensure this accuracy the method must be easy to understand for both experienced team members and brand new members.

  • OpenRocket/RSE simulations must predict how changes to rocket length, weight, and engine performance affect rocket performance.

  • OpenRocket/RSE simulation process must be streamlined enough to be done regularly. 

  • Loads analysis must be done at each cycle

  • Reports must be written which are extremely digestible and accurately represent the data. (giving effective actionable information to team members)

  • Regularly scheduled cycles must be implemented without significant schedule slip

Minimum scope of this project is to analyze design decisions using OpenRocket and RSE file generation to help inform team members about high value changes

Maximum scope of this project is to create a project management tool/system to consistently check in on overall key integration parameters (mass, length, engine performance) and disseminate actionable, easy to understand information to drive design decisions while also considering case by case changes to the design.

Required Documentation (Insert links when created)

Deliverables Timeline

Startup work: (starting early sept. ending at end of sept.)

  • Create document/system to track mass and length and collect input from the subsystems (Sept. 18 tentative)

  • Get feedback on it and improve it. (until end of sept.)

  • Get input from the subsystems alongside the first length/mass data about what scenarios they would like to see simulated

Cycle 1: Starting 1st week of October Ending end of October

  • Predicted 1.5 weeks to gather data from subsystems (with enough advance warning). Data due entered into spreadsheet by Oct. 12

  • Predicted 1 week to run open rocket simulations.

  • Predicted 1 week to write mini report.

  • Total 3.5 weeks 

  • Results influence the detailed design

Cycle 2:  Starting 1st week of January, ending end of January

  • Same schedule as above

  • Results are used to finalize designs for the CDR, finalize fin size

Fin sizing finalized (Last year January 11th)

Cycle 3: Starting last week of March, ending mid April

  • Should incorporate all final design masses and some fabricated part masses

  • Same schedule as above

  • Results are used for final project report

Cycle 4: Once the rocket has been completed

  • Represents the as-built results with fabricated masses

CDR: Early February

Design Log:

  • 10-13-2022

    • Conversations in slack about changing datums and datum use in general occurred recently. See slack for more details. The short is that we should reconsider the datums before the next cycle.

    • Overall the project is going well. Propulsion didn’t quite meet the deadline for input due to busyness but basically everyone else did. Now on to simulations.

    • Remember to get the lengths of the sections for the deadline.

  • 10-14-2022

    • Almost finalized the spreadsheet just waiting on last lengths to be put in by roman now which changes a few CG values

    • Realizing won’t account for CG changing due to min/max mass scenarios. Determined this should be fine for this cycle.

    • Created list of what we want to simulate, and excel to track data

    • Decided to use RSE files from previous simulations (early KOTS 2023 simulations) as new ones were not created for this yet. Trying 100% thrust, 120% and 150% as decided by Joel and Aaron.

  • 01-28-2023

    • Just realized I haven’t put updates here in forever.

    • We finished cycle 1 essentially on estimated schedule and published the mini report.

    • The cycle 2 data took a little bit longer to gather and be confident in because of a lack of work over the holidays and also due to wanting to be very confident in this data but unfortunately a lot of designs on the rocket are not yet at a place where they can give us good estimations. Also the SF got delayed a week until today.

    • One unfortunate part of this is that the 3d printed metal fill bulkhead design needed to be sent away for printing in January around the 24th. For this they needed fairly good loading calculations so we decided to add a cycle 1.5. This used the data currently gathered alongside some rough estimations of: engine data, airframe weight sections and other sections in general. This was then simulated with two types of fins (clipped delta and trapezoid) based on research about what was the best shapes. This generally showed that clipped delta was better for apogee and also that the fin size of last years rocket is actually a good estimation of what we will need this year. This is new information as previously it was thought it would be able to be smaller than last year. However I think due to a length reduction and possibly other factors the inherent stability of the rocket has decreased. We are currently planning on completing cycle 2 around mid February according to the plan laid out in this document https://docs.google.com/document/d/1JNvpdeczEOeFuUGfQ1QNFMN_b9wIcHwRmjX0BIFrfug/edit#.

    • A weather review of New Mexico conditions was also completed to analyze the conditions we are using in our simulations and for further use as to weather variation in stability. This is located https://docs.google.com/spreadsheets/d/16RH75F2kThyLBTv0jcvQgWOC8h9-sMPgf0onBELOxmY/edit#gid=0

    • Sensitivity analysis was done on various nosecone and boattail shapes to determine if they need to be taken into consideration at this point. Neither significantly changed stability. Nosecone shape can be improved by changing to a power series with 1/2 shape parameter. This would improve apogee by around 400ft however this is most likely not going to be done as remaking nosecone moulds is prohibitive in both team member time and manufacturing time. The boattail various shapes had very little effect on flight with a perfectly square extension of the rocket reducing apogee by around 300ft and various curvatures not making a large impact.

    • A big drop in stability was noticed around the end of the engine burn which makes our lowest stability at a very different time than previously. The cause of this difference is mostly unknown.

  • 02-10-2022

    • Currently sizing fins and thought I would jot down some notes:

      • We discovered we had positioned the RSE file wrong in OpenRocket. There is conversations in slack about this but essentially the RSE file has a value called “len“ which is the distance from the top of the potential fuel volume (tip of the rounded bulkhead) to the end of the fuel grain. This is the distance that OR considers the RSE. Therefore we can align the RSE using the internal top of the fuel bulkhead (farthest fore point on rocket that Nitrous could reach essentially). Decided to set this location as 1 inch fore of the front plane of the Feedsystem section. Pending future analysis by Aaron. This is good for stability as mass shifts forward compared to what we previously thought.

      • Found an error in the cycle 2 spreadsheet where we completely missed a bodytube section weight. This highlights the importance of verification and idiot checks.

      • Determined that boattail length does not need to be decided at this point as it does not affect fin sizing too much but that tapered diameter would be 5.5in in our sims (based on rough guess by Aaron) and length in sims will be same as last year at 4.2 inches to simply things.

      • Had conversations about launch rail length this year summarized by the following:

        • stability is lowest throughout the flight immediately off the launch rail

        • We are currently sizing fins to be as small as possible while having enough stability as this will reduce drag and increase apogee.

        • The longer the launch rail the more stability we have off the rail as we will be going faster when we depart and this effect is noticeable

        • We are in a place still where we still want a wee bit more apogee to be where we want to be.

        • Therefore 40ft should be the launch rail length again this year if it can be done

      • Launch rail length calculation:

        • rail length is 40ft.

        • When first rail button leaves tower it is considered to have left the tower in the DTEG.

        • First rail button is roughly at the fore plane of Feedsystem section 66.39in from nosecone tip. rounding to 66in, rocket is 174in long so 174-66=108in have to be subtracted from the rail length.

        • 40ft = 480in-108in = effective rail length of 372in

          • This is the value inputted into openrocket

          • Discovered some problems with RASAero summarized below:

            • Roman, Ryan and I just had some conversations about an issue we just noticed. Unfortunately we didn't notice how impactful this would be until now but essentially RASAero is not letting us input:

              • how the engine mass changes over time (instead assuming it linearly decreases),

              • how the engine CG changes through the burn (instead assuming it stays still we think)

              • the engine CG in relation to the rest of the rocket (although we have a weird lead on that from a forum that says the engine CG is set to half the engine length which we could mess with).

              Due to this RASAero is not giving us stability values that make sense. Because the engine is a large portion of the rocket mass this is not really something that is easy to guess at or apply a conversion factor to so excepting a major breakthrough we will not be using RASAero for fin sizing which is happening this weekend

  • 02-20-2023

  • No labels