search

Pweder3 / SMORT

S.M.O.R.T
MIT License
2 stars 0 forks source link

readme

S.M.O.R.T. PROJECT

Smart, Modular, Off-axis, Reloadable, Tube-launcher

Table of Contents

Planning

Here is a more detailed planning document LINK. This is the Github project tab we used to assign work LINK.

Materials

CAD

Most of the CAD we did was create the shell we would fire and the mount for the tube. Both of these items were 3d printed. All three group members worked on the CAD but most of it was done by Lucia and Cyrus

The tube mount serves to secure the tube that holds the rocket. This mount can ensure tube security at angles 10°-45°. This stand had two parts that connected with screws and security nuts. This design was secured to a larger wood roller, which facilitated easy transportation. This design needed one variation after there was a slight crack in the main frame. This crack happened after we attempted to move the mount without loosening the screws that held it at that angle. In this first iteration, the stand did not have enough reinforced material on the main tube holder, so the whole tube came off after rough movement while using the stand. This piece was reinforced by rounding certain edges along the area of cracking. See here and here for the broken SMORT stand images.

The shell is modular and all of our versions involved 3-4 sections that could be removed and replaced if we broke them or decided on a different design. This was very useful when making the fins. We went through 5 different variations of the fin design and if we hadn't made the rocket modular we wouldn't have had to reprint a new rocket every time. Paul's thread design makes it super easy to remove the parts. The Nose and body parts remained the same the whole time. We could've made improvements to the nose but we found that the design was good enough for our purposes. The fins desperately needed a redesign. With the use of OpenRocket and internet research, we decided that deployable fins would be our best option.

Here is a link to more detailed documentation of our CAD process LINK. Here is a link to our OnShape document where you can directly look at our CAD LINK

Here is a picture of our fin design in the folded position

This is a picture of our fins in the deployed position

OpenRocket

OpenRocket is a free rocketry software that many model rocket builders use to plan their rockets before buying parts.

<<<<<<< HEAD _photos that we took during the building process

cd7766ad492cda8fc9811bdba43ab6014cae2c19

Show above are 3 different simulations from open rocket. All of them are using the same rocket body but they each have a different motor size equipped. we can see how different size motors will affect any of the factors we have asked it to plot. We also used OpenRocket to compare different fin designs which you can easily edit. You can also change factors such as wind, barometric pressure, and launch angle. Learning to use this tool was crucial in making a good shell design.

Photos

<<<<<<< HEAD

Pauls_Documentation

Paul Weder refused to use the readme to document even though every other team was using this. This act caused extreme frustration from his teammates and showed his combative and uncooperative character. It is important to note that he did do good documentation which was very well put together but it would've been much better had he just used the readme like an actual human being. The link to Paul's PDF can be found here Paul's Docs.

cd7766ad492cda8fc9811bdba43ab6014cae2c19

Failures

We had many failed launch attempts with our rocket-propelled shells and we have more documentation of those attempts here More Launch Info

Tube Fire

Rocket Propulsion

Originally we had planned to use rocket motors as our method of propulsion but we had to switch to the air cannon to finish the project on time. More information about this can be found in Cyrus's Reflection.

Final_Version

Here you can see our successful launch with the deployable fin design. This prevented tumbling and caused rotational motion which helped the shell fly straight.

Reflection

Cyrus's Reflection

Overall Reflection

While we ultimately succeeded in achieving a stable launch and collecting data, we failed to meet the other goals that we had ambitiously created at the start of the year. The project was initially supposed to use the data that we collected to make predictions of the angle we would need to launch a certain distance. I think that the shell would have been able to give us a consistent speed but I don't think that we could've figured out what that speed was just based on the sensor data. The code that the sensors use is unreliable and without filtering the data is unusable. For next year's project, I will try to be more moderate in my goals. I would much rather meet my goal and then enhance my project than degrade my project because my goals were too ambitious.

Why Rocket Propulsion Failed

Originally we planned on using rocket motors as our main method of propulsion we used OpenRocket to give us range predictions and tell us what size motor we could use. OpenRocket was very helpful because it gave us charts that showed us lots of data and it also helped refine the fin design with its stability predictions. We attempted to get the RP to work for about 2 months and 4 launch attempts before we switched to air propulsion. Originally we planned to get the shell stable in the air cannon and then transition back to rocket motors but we decided against this because there was no need to with the performance we got from the air cannon. One of the biggest reasons that the rocket motors failed was that we were treating them as less fragile than they were. Rocket motors and igniters are finicky when you are using them for their intended purpose but when you are trying to drop them onto a plate and get them to ignite they are rarely going to perform in the way you'd want. I created 3 different methods to get the igniters to work, when I tested them in the lab they were capable of setting off LED lights but when we went outside for a real test they failed to perform. Even when we decided to do a non-drop launch we still had trouble getting the ignition working. When we did get a motor to ignite the rocket didn't leave the barrel. After that, we decided to change our propulsion method. If we had done this from the start of the project we would've been able to do much more CAD work and possibly give Paul more help with his code/wiring.

Cannon Cart

One of the side projects that I did was making a cart for the air cannon. This cart consisted only of materials found around the lab. It was helpful to have this cart because it made moving the bulky cannon much easier. The cart became less useful when we moved to air propulsion. The air tank was super heavy and made the cart tip over if it wasn't pulled in a certain way.

What Would I Change

If I was to do this project again I would do it much differently. Firstly I would determine a better method for propulsion, either traditional mortar propulsion or I would stick with the air cannon from the start. Second I would make myself and the other group members more accountable for weekly documenting and making sure no one member is working on a project that is unnecessary to the team's goal. I wish that we had made a more exact planning timeline with deadlines. I think that this would've kept me more focused and kept me from spending too much time on one task. This was a big problem that we had with this project and a timeline would've held us accountable. Poor time management skills and a certain distracted teammate are what caused the project to end the way it did. With more attention to this, we could've had a much better final project.

Lucia's Reflection

Overall

I was happy with the final result of this project. Although there were a few gaps in the communication between party members, we banded together and allowed for a successful launch and collection of data to happen. I learned about the functionality of rocket fins and the importance they serve in a projectile. The launches were very satisfying after we moved to the air cannon, considering the visible feat of the height and the satisfying result of both the deployable fins and the landing of the spring. It seemed like the delegation of work could have been handled beetter. At certain times in this project, I was not totally upfront about goals and expectations regarding my share of the workload. It was harder considering I came in later after people had already decided on an initial project.

Paul's Reflection

This project was a huge leap for me in the sense, it was a test of all of my abilities and then some as I had to learn countless new subjects through the project to accomplish my goals. This project not only tested my abstract knowledge of subjects but made me implement them which I think is the true value of the project and the true goal of this class to make us learn which I think I accomplished. This project although was not all sunshine and rainbows, as I might have wished. The biggest issue was time management, and although I pushed very heavily to scedualize the project and keep us on time the thing that kept me back was me working on the wrong thing. I approached this project with a lot of excitement and wanted to dive right in looking into the abstract and to me cool stuff such as the low pass filter or other more complicated concepts that really should have been done later. The age-old problem of scope creep was the main culprit in failure as I should have started the project with the basics and as always given myself a buffer as in these kinds of projects things are almost never on time or as easy as they seem. My main takeaway for this project is to peruse what you want to do and what makes you exited, but do it in a manner that incentives the success of the project as a whole. In simple terms.