Newbs in another forum I participate in are often counseled to read more and post less in the beginning, because you don't know what you don't know.
Another example from my student days:
At one of my summer jobs, another engineering student intern was hired to work on a project to build an R/C aircraft that would perform to a specific, unconventional flight envelope as a proof of concept. Dude worked all summer: custom designed and fabricated airframe with unusual powerplant that was a learning process all on its own to get to run right (with probably the most knowledgeable bunch of people who ran more normal powerplants all the time that you could ask for around to help). Got it running, got it flying, and the thing failed to meet the performance targets. Not long after, a more experienced tech (not an engineer) who was very familiar with the technology space went and bought an almost-ready-to-fly model and off-the-shelf, ordinary powerplant. About as cheap and simple as you could possibly get. Threw it together in a few hours one evening and went out and nailed the performance targets the next day.
Another engineer in the same shop who built really cool stuff on his own time said, "I'd never build anything if I can just go buy it." The point being, a factory that's set up to churn stuff out in volume will be many times more efficient and can reasonably be expected to produce higher quality at lower cost. Consider the classic essay, "I, Pencil."
https://fee.org/media/14940/read-i-pencil.pdf My point is not to indoctrinate you in free market libertarianism, but to point out that a vast swath of engineering and manufacturing turns out to be just figuring out what to buy, and where and how to buy it.
Another example: At a previous job, we wanted a piece of hardware that was similar to, but not quite the same, as one we already had in inventory. Engineering created a print and sent it over to production. It turned out that an $1800 lathe attachment with no other use in our operations was required to convert the existing parts into the new parts. And the labor costs per part were high. Total cost ended up being several dollars each, after weeks of delay getting it all up and running. When I found out about that whole situation, I took some photos and made some notes on the desired part. Had the purchasing manager reach out to her suppliers. One of them came back and said, "I have 100 here. They're 35 cents each. How many do you want now, and what do you forecast for the future?"
If you want to do stuff that hasn't been done before, make sure you have a good idea what's already been done, so you don't waste your time doing it over again, and poorly.
My advice is to spend a bunch of time reading. Learn all you can about what has already been done. Come up to speed on the technology space. Figure out who the vendors are, what products are available, what technology solutions are out there as plug-and-play and as people DIYing. There are thousands of people doing things like you're trying to do, and thousands of people together are probably smarter than the few people on your team. Unquestionably, they must have more experience, and you can profit by that. It's likely that there's an off-the-shelf kit that comes close to being able to do what you need, and is designed by someone with many years of experience. It may be that enough modifications would be required that you'd be better off buying materials and components and building from scratch, but getting really familiar with what is already proven is a good place to start. You'll save more time and money than you can imagine.
My start with OR was buying an Estes Hi-Flier for $6.99 from Hobby Lobby and building it in OR. Got out simple measuring tools and a milligram scale and looked up a lot of specs for the standard components like tubing. I just wanted to understand the model and why it was what it was. Do the work to build the whole thing with every component included. You'll have to figure out all the basics, and then you'll be able to make changes and see the results in your sim. Play with all the parameters. Develop sweep matrices for sims, where as you sweep one parameter from high to low, you simultaneously sweep another that trades off against it, and see where the optimum overall solution lies. You probably won't need to fill the entire x*y grid, but you'll see how the optimal region is shaped and hopefully find the global maximum. An example is main body tube length versus weight required to achieve a stability target.
The classic manuals on rocketry that have been recommended are worthwhile. Much of them may not seem relevant, but they will bring you wisdom and perspective that will serve you well. After three decades in my field, I still learn new things that have me wondering why something so basic wasn't in the first book I read.
What is the plan for every person on the team to become L2 certified? My understanding is every person being certified has to build their own rocket. How many rockets is that? Do they come out of the $3500 budget? Is everyone paying for their own? It would be good experience for everyone. On the other hand, most of the Formula SAE teams I know about have division of labor. There are people doing software and electronics, people doing powertrain, people doing suspension, someone driving, etc.
In the automotive world, being able to go fast is a relatively small part of knowing how to race.
The biggest weakness I see on most FSAE teams is program management: Someone herding all the cats to ensure that all aspects of the project are done well enough and on time. Someone needs to develop an overall plan, working backward from launch, including testing so that everyone has a high confidence level based on prior performance when you get to the big show that the bird will fly as expected. Figure out who's doing what, when, and then have your smaller do-or-die thrashes along the way to stay on schedule, rather than letting it all build up until the end and crash and burn with a rocket that's not ready and proven. Include test motors and travel in your budget.
The bottom line is, you probably aren't going to have to invent anything. This is established territory. You just have to integrate a bunch of stuff that's already out there into a system that works efficiently and reliably as a whole.
Apply functional requirements trees. You have an overall goal. Break it down into functions and subfunctions that the rocket must perform to achieve that goal. Then explore all the established solutions you can find for each of those functions and subfunctions. Look at weight, cost, packaging. This automatically provides a structure for division of labor: you can have an airframe team, a fin can team, a motors team, a nose cone team, a recovery team, an electronics team. Each team does a deep dive in its area, starting off just being an information sponge.
You could work up presentations of your findings for each other, so the whole group can be up to speed and understand how each area fits in with the whole, and have a chance to propose possibly helpful ideas and ask helpful questions due to a different perspective. You will probably be expected to produce a final presentation, so these small internal presentations will be good practice, as well as generating and tuning up most of the needed material. The not-so-public speaking is also awesome experience for when you start real work.
Some functional areas will be obviously related, such as recovery and electronics, and recovery and airframe. Some functional areas will compete with other functional areas, and you may have to balance performance between them rather than it being possible to optimize everything. You should end up with a vast amount of information about things you didn't do. Come together as a group often. Many of the best ideas seem to happen when you have a bunch of competent people just sitting around bouncing ideas off each other.
Good luck!
