EXPERIENCE AND PROJECTS

Most of the flight dynamics were calculated using the flight simulation application RockSim.  We used RockSim to characterize our rocket designs. Elements like fin and airframe shape, size, and length, as well as mass distribution, changed a lot early on during the development of the rocket.

RockSim helped us narrow down and eliminate designs by determining if our rocket was too heavy or too unstable. It also helped us determine the expected apogee, and range, and simulate those parameters changing based on weather effects. 

We started off with designs purely in RockSim, and, after about three months of development and research, we determined a design that we liked, ordered parts, and started to fabricate the rocket. 

After doing a lot of research, we determined that a stability caliber between 2 and 3 would work best. We also determined that the stability margin would change during flight quite significantly, as for a hybrid engine, the oxidizer weight would be ejected from the middle-end of the rocket, shifting the center of mass, and changing our stability margin. We made sure to keep this in mind during our simulation phase.

The motor we used for Lazarus was a HyperTEK hybrid rocket motor with a 1685 cubic centimeter tank, L550 fuel grain, and the RG L fixed orifice injector bell. This specific motor configuration had an impulse of 3095 Ns, and a burn time of 5.6 seconds.  The oxidizer was nitrous oxide, and the fuel was a thermoplastic.

This specific motor configuration was chosen after running multiple simulations with multiple motor configurations and rocket builds. 

A common trend with the research and design phase of this project was just to try an idea in the RockSim simulation and see if it performed well or not. Do that multiple times while adding new design considerations and refining current ones, and you will eventually get a refined design that performs well and meets your objective. 

While we did not build our rocket motor, we still needed to know how it would perform and change dynamically in flight. In our rocket design, we had to account for things like the changing center of gravity, as the oxidizer was transferred from the tank and ignited in the fuel grain (as previously mentioned a few paragraphs above).

The challenging part of building a transonic hybrid rocket is figuring out what kind of problems you need to solve, and if you are asking the right questions.

How straight do our fins need to be?  Will the airframe survive transonic velocities? How do we know if the avionics bay can survive the stresses during chute opening? 

The key to success in an unfamiliar engineering problem is to approach every element of the problem with a clean mindset and determine a solution, if a solution is even required, with a first-principles mindset. 

For example, I had a pretty eye-opening experience while initially designing the avionics bay. How should I secure the batteries for the flight electronics? Can I just tape them or zip-tie them? I initially thought, "Oh I'm sure tape would work fine", but you have to really make sure, it's a rocket. Approaching the question with a first principles mindset revealed the answer pretty quickly. 

What kind of forces do the batteries experience during launch? Well, from the flight profile and RockSim, about 7g's of acceleration is experienced during launch.  A 9v battery weighs about  40 grams, and using Newton's second law of motion we can easily calculate that the force exerted on the battery would be a small 0.7 lbf. So yes, you probably could tape the batteries in the avionics bay, especially if they were resting on a solid surface. Should you? Probably not (we didn't).

If that 40-gram battery was instead a 450-gram payload resting in the nosecone, above the parachute bay, then you would not be able to use tape to secure it, as it would experience ~7 pounds of force during launch, and would break through the tape and shoot down into the parachute bay, changing the stability of the rocket and making it unstable.  This actually happened on the first rocket that I built during my junior year of high school, and after that, I swore that I would approach every problem with a first-principles mindset. 

The avionics bay was probably the coolest part of the rocket in my opinion. I had a lot of fun building it, and I enjoyed making it robust and functional. Lazarus used two MissleWorks RRC3 flight computers, both with dual deployment capability. They were set up in a redundant dual-deployment configuration. This was the safest way to set up our avionics system, if one computer failed, or if one deployment charge was not enough to deploy the main or drogue parachute, then the second flight computer would handle the error.  We also had a digital camera that wrote to an SD card that recorded the entire launch. 

In addition, there was a steel threaded rod down the middle that was connected to two metal U-bolts on either end of the avionics bay. This steel rod was more than strong enough to take the load of the parachute deployment.

The avionics bay was one of the first main components of the rocket that was constructed, as we had finished the design and knew it would not change. (Unlike the fins, which were created last.) 

After all the parts arrived and we finished fabricating anything we needed to, bulkheads, centering rings, motor casings, and the avionics bay, we decided to fully "assemble" the rocket, without gluing anything, in order to determine the center of gravity to make sure it agreed with the simulation.  We waited to fabricate the fins until we were sure everything was correct. 

The process we used for determining the center of gravity was quite simple. We attempted to balance the rocket horizontally on a fulcrum point, adding any extra weight (in the form of lead weights attached to strings) we needed, such as the fuel mass, glue mass, and fin mass, and once that point was found, we measured the distance to that point from the nosecone. That distance was where the center of gravity was located on our rocket. Once we did this, we found out that our measured center of gravity did not agree with the center of gravity from the RockSim simulation. 

We spent two days trying to figure out the problem. We re-weighed everything, measured every component to make sure it was in the correct position, and even re-created the rocket in a new simulation software. It was only after we calculated the entire center of gravity by hand we realized the simulation was incorrect. There was a mass distribution setting we missed while configuring the body tubes in our simulation, which incorrectly calculated the center of gravity. 

This problem taught me to not blindly assume how a program functions, such as RockSim, and to fully read the documentation and understand what is going on behind the scenes. It also taught me that running hand calculations to check your simulations, in addition to using multiple simulation programs, is important. 

Once we verified our rocket composition with our simulation, we fabricated the fins, cut the fin slots in our outside airframe, and glued all parts together. 

We also tested any system that we could test, such as the redundant dual deployment setup for the altimeters, first using a crude self-made vacuum chamber, as well as simulation software provided by MissleWorks. 

Another system we tested was the parachute system. Below is a video of a parachute packing test my brother and I did. From the video, it does not look like much of a success, but if you look closely, the main parachute comes out of the bag quite easily when it hits the ground. The test we did before used a separate packing method and the entire parachute system became terribly tangled, which is why doing simple tests on these systems is important. 

Launch Day

After months of research, problem solving, development, and fabrication, Lazarus was complete, and launch day came. 

After having our rocket and flight readiness review checked by a range safety officer, we loaded our four parachute deployment charges, and our rocket was taken to the pad for liftoff. 

The launch could have not gone any better. A perfect flight occurred, reaching our objective of transonic velocity, and safely recovering the rocket (in one piece!).

This project taught me a lot about engineering, problem-solving, and leadership, and inspired me to continue to pursue my dreams of working in the aerospace industry as an engineer looking to help increase humanity's presence in space. 

Unfortunately, I cannot go into much detail about what I worked on, and how/ where/ why it is used, but what I can do is show the CAD designs we, as a team of 3, created throughout the design process, as well as talk about what I learned during my first experience working in a professional engineering setting. 

Displayed Below are the designs for the maintenance platform that we researched, designed, and developed over the course of the 10-week internship. 

I did most of the CAD for our team, which gave me a great opportunity to learn SOLIDWORKS in a professional setting. The only other CAD software I had used before the internship was OnShape, to 3D print a bulkhead and two avionic bay caps for the Lazarus Rocket. I was essentially learning on the fly, picking up modeling techniques from other interns and mentors. 

As you can see, our designs changed quite a bit over the course of 10 weeks. This was due to the dynamic environment that our platform would be used in. The platform needed to be big enough and strong enough to support a human and tools, but small enough to fit in some really tight spaces. 

During the first few weeks of the internship, we struggled to get a complete set of project requirements, as the environment in which our project would be used was restricted. We eventually got clearance and went to take field measurements, which helped us strictly define our project constraints. In addition, we spoke with project stakeholders and determined a list of requirements that they would need for the design.

It was at the time of communicating with stakeholders and defining project constraints that I learned the first thing that was different between working in industry and studying in school. I quickly learned that engineering is not only problem-solving and product design, but it also requires streamlined communication with stakeholders. Such communication is vital to defining your problem statement and constraints so you actually solve the problem that needs solving.

After designing a few more designs, we went to take field measurements again a few weeks later and found that our project environment changes quite dynamically, which led to even more complications in the design. 

After a few design reviews, and a critical design review with stakeholders and mentors, we eventually settled on two designs. The Slotting Plastic Platform, and the Two Piece Foam Wedge Platform. 

As a team, we decided to split up between the two designs. For the last three weeks, I designed the Slotting Plastic Platform, and my two other team members designed the Two Piece Foam Wedge Platform.

Slotting Plastic Platform

The idea of the Slotting Plastic Platform, is to have one large platform surface made up of a number of middle platforms, and a male and female end platform. The platform pieces are pulled together by elastic cordage that runs through the four middle tubes.

The slotting feature allows the platform to be as long as you want it to, but also contract to a very small profile so it can fit into really small spaces and maneuver around tight corners. 

During the last week of my internship, we went through a design review and were making plans to order parts to build a prototype. I made sure to document my recommended fabrication process, as well as the CAD as much as possible, as I would not be there to help after I had left. 

The entire CAD assembly reads values from a text document titled "global variables". Any user can go and change the values, which changes the entire design in every part and assembly file. 

I also created a map of each platform type, which depicts every global variable used on the part and what it changes. This makes it so much easier for someone to make a custom dimension change to the entire assembly. It's hard to see here on my website, but the entire map is included in a PDF file, and you can search any global variable name to see how it affects the assembly. 

I also created drawings for each part and assembly, to follow during fabrication. 

Overall, I am very grateful for being able to learn from and work alongside engineers at Stealthwerx and the 509th Bomb Wing, gaining invaluable experience that will undoubtedly open up future opportunities.

I gained my first experience operating in a professional environment, where I communicated with stakeholders, defined product constraints, presented design reviews, and collaborated with other engineers and mentors. 

I also learned a lot about mechanical product design, got a lot of SOLIDWORKS experience, and improved my FEA knowledge. 

The B-2 Spirit is an amazing aircraft, and I strive to become an engineer who helps design aircraft of that magnitude one day. My time working with the B-2 will inspire me for years to come. 

RELLIS is a secondary Texas A&M campus in College Station, TX, where SRT conducts engine tests and other testing operations.  

On GSTOP, I develop and improve our data acquisition systems for gathering data during engine tests by installing new sensor hardware,  making hardware updates to our DAQ Box, building the required circuitry (such as voltage dividers for RTDs), and developing new computer applications (a.k.a. GUIs) for DAQ and testing purposes.  

The sensors we gather data from include Pressure Transducers, Load Cells, RTDs, Potentiometers, and Thermocouples. 

I also make renovations to our Test Cell, as well as preform testing operations as a tech during our engine tests. 

The GUI is oriented in a Sensor-Device perspective. 

The user can define a DAQ Device, which is the conduit where the sensor data comes from, whether it be voltage, digital signals, or ethernet protocol packets, a device needs to be set up to get any use out of the GUI.

Then, the user can define a Sensor, which could be a resistance temperature detector, pressure transducer, thermocouple, potentiometer, etc. Any measurement device that supplies any form of data can be considered a sensor. The data just needs to be able to be read and collected by a DAQ device. The sensor can then be paired to a data stream that comes from a device, which would be, for example, an Ethernet UDP packet, or a LabJack T-7 analog channel. 

Future Plans

Currently, the GUI is in a good functional state. It can gather, visualize, and record sensor data at a decent sample rate. It is also quite modular, many types of sensors can be added, and many types of devices can be added. However, there are many more things I want to add and improve upon. 

In addition to improving the sample rate, I want to add outgoing data requests to the Ethernet UDP device, as well as digital signal outputs to the LabJack T-7 device. This is an essential step before attempting automated engine testing, such as automatic fill procedures. 

I also want to add a control loop tab, where the user can write a control script, in Python, to control external stimuli such as relays, or servos, based on current sensor data within the application. 

Something also important to add, will be a profile save and load feature, where the user can load a profile so they do not have to create all sensors and devices and fill in the respective information. 

Lastly, my main goal for this program is to leave a lasting impact on TAMU SRT Ground Support and Testing Operations. Most of my work, in my opinion, will be in vain if future members cannot use my GUI for custom tasks, tailored to what the team needs to get done that year. I plan to create documentation and tutorials that showcase the creation of new sensor types and device types, in addition to showing my current workflow for coding Qt graphical elements. To do this, I need to completely refactor most of the classes in my code, making certain features class-based, and creating wrappers and templates to make new development by future members go as smoothly as possible.

Check back for future updates to see what i'm working on! I'm either studying, or working on something dope for the Texas A&M Sounding Rocketry Team!