Cornell Rocketry Team
Cornell Rocketry Team |
---|
Part of the CRT series |
Getting Started |
Enrollment • Expectations • Facilities • Files & Communication • Grading |
NASA USLI Seasons |
2017-2018 • 2016-2017 • 2015-2016 • 2014-2015 |
People |
Professor Douglas MacMartin (Team Advisor) • Daniel Sheerer (Team Mentor) • Yash Sahota (Co-Team Lead) • Matt Schneider (Co-Team Lead) |
Subteams |
Airframe • Business • Communications (Comms) • Electrical and Software (E&S) • Independent Testing and Validation (INTEV) • Payload • Propulsion |
High-Power Rocketry Certification |
Level 1 • Level 2 • Level 3 |
How to & Guides |
Wiki • Documentation • Writing about Safety and Hazards • Style Guide • ShareLaTeX Guide • Technical Writing Guide • Solidworks Training • GitHub • Controls Basics • Altium • 3D Printing • Design Catalog • Acronym Dictionary • ANSYS Guide |
Reference |
Branding and Standards* • Useful Calculations* • Launch Database* |
Miscellaneous |
FAQs • Library of Useful Sources |
*login required |
V • E |
Cornell Rocketry Team (CRT) is a student-led engineering project team at Cornell University. Consisting of students from four different colleges within the university, CRT strives to push the limits on high-power rocketry and build innovative and sustainable payloads. The team is currently competing in the 2017-2018 NASA University Student Launch competition with their rocket, Flammea, and its payload, the Deployable Rover System (DRS).
As part of the team's educational series on high-power rocketry, members build and launch Level 1, Level 2, and Level 3 high-power rockets. Most local launches occur as part of Upstate Research Rocketry Group (URRG), sanctioned as Tripoli Rocketry Association (TRA) Prefecture #139 and National Association of Rocketry (NAR) Section #765.
CRT's faculty advisor is Dr. Daniel Selva and the team's faculty mentor is Daniel Sheerer. The current team leads are Bryan Zheng (AEP '19), Chris Fedors (ECE '18), and Stephanie Chang (CS '20).
Contents
Expectations of Team Members
As a competitive project team, CRT holds its members to high standards. Below are some of the basic expectations of being a CRT member.
General Expectations
All team members must:
- maintain a positive working environment
- meet deadlines assigned to them
- not be on another project team while they are an active member of CRT
- attend the weekly all team meeting unless exempted by the team leads
- work in accordance to the amount of credit hours they have signed up for
- fill out a weekly progress report form
- write about their contributions to the team on the wiki
Communication
- All team members should check their email regularly
- All team members check slack regularly
- Be sure to turn on notifications
- All team slides
- Google Calendar
Team Structure
CRT maintains a functional team structure, consisting of six subteams in addition to the team leads. For more information on each subteam, follow the links below.
- Airframe
- Business
- Communications (Comms)
- Electrical and Software (E&S)
- Independent Testing and Validation (INTEV)
- Payload
Order Form
https://docs.google.com/spreadsheets/d/1PO4vpfnXfCDquNCaI2nS8D_GhVYYGfD2rnUzOQ2xb-4/edit?ts=5ae8ce55
Documentation
For more detail, see Documentation.
New Documentation
With the transition to SA Cup/IREC, CRT's documentation has been drastically revamped to reflect the needs of the team and the competition. There are very few required documents for IREC, which is both good and bad. Good, because it means less writing. Bad, because unfortunately documentation is an extremely critical part of design, so we now need not only to come up with our own documentation, but also provide our own motivation for doing it.
In general, the amount of necessary writing has been greatly reduced. Most of the information is now held in (theoretically) regularly updated wiki pages. Additionally, it is perfectly acceptable in most cases to write in bullet points or short statements, rather than tedious, verbose paragraphs (like this one). A greater emphasis is placed on figures with lots of labels, which are a bit time consuming to make but are far more efficient at conveying information.
Information relevant to multiple systems/subteams, such as integration, testing, and hazards, are still held in ShareLaTeX documents. There are several reasons for this:
- Multiple people can edit at once.
- People can easily leave comments and discuss contentious points.
- Understanding LaTeX is, in fact, a rather useful skill, so everyone on the team should learn.
- We have a sponsorship from them, so we might as well use it.
Additionally, PDR is entirely made through ShareLaTeX. Aside from the reasons listed above, the fact is that PDR is so preliminary that most all of its information will inevitably become outdated. Were it to be hosted on the wiki, these outdated parts would eventually be overwritten and never seen again. This is a problem on multiple fronts:
- Knowing where a design started is very valuable when evaluating how it turned out.
- Some of the design alternatives that were discarded might be used in the future.
- Understanding how to start a design is a rather subtle skill, so it's useful to be able to see how it was done in the past.
Finally, keep in mind that the development of this documentation is an ongoing process. Feel free to give feedback and tell the leads about any ideas that might occur to you. If the currently layout just doesn't work for the information you need to convey, let people know and you can discuss how to tweak it.
Documentation from Previous Years
Documenting our progress throughout the life cycle of each project is a very important part of what CRT does. Every system that CRT develops is has been extensively documented in our documentation that we submit to NASA every year. We use shareLaTeX for writing our technical reports.
One of the best ways to learn how we do documentation is to read some of it!
Guides
- Writing about Safety and Hazards
- Style Guide
- ShareLaTeX Guide
- Technical Writing Guide
- Solidworks Training
- GitHub
- Controls Basics
- Altium
- 3D Printing
- Design Catalog
- Acronym Dictionary