Year-leading-up

Read the (entire) template in the beginning of the year and the Rules and Requiremetns section pertaining to the tech report’s sections. They aren’t very long. Throughout the year, you should be thinking of:

• The tradeoffs you considered,

• A neat diagram to explain something,

• A comprehensive test to demonstrate the system works,

with the technical report in mind. No decison should be left without motivation and no requirement should be left unverified. Typically, designs change at least a little bit as the team begins testing, so the report can’t be fully done in advance. However, you can include specific things well in advance:

• (PDR) Detailed document structure (headings, subheadings)

• (PDR) Flight graphics

• (PDR) Team structure (Intro sectoin)

• (CDR) Missions and summaries

• (CDR) Requirements tables

• (CDR) CONOPS

• (CDR) Nominal values for Appendix A

  • Motor selection

  • Rocket dimensions

  • CAD renders

• (FDR) Planned subsystem tests

• (FDR) Assembly checklists

If you ever have “nothing to do” in the middle of the year, chances are you can work on one of these things.

Forgotten Deliverables

You will spend almost as much time on the appendicies as on the text. Make sure you

• Write up tables of basic data (lengths, weights, battery capacities, sensor rates, etc.)

• Write (can be brief) test descriptions and reports

• Write your subsystem’s part of the flight risk assessment

Writing guidance

According to ESRA, this is how you should write a report:

Open

Section layout

Organize your text so that at every point, every decision made has motivation.

1. Objectives and requirements

   • Ultimately, what do you need to get out of this subsystem?

   • Bullet list for objectives

   • Tables for subsystem, ESRA, and interface requirements

   • If these are really long, the Appendix may be a good place

2. Concept of Operations

   • To meet your end-to-end requirements, what is the system doing?

   • Table, possibly also diagram(s)

3. Major design decisions, one per section

   • Describe the trade space (decision matrix)

   • If a mechanism has multiple steps, make a diagram

   • Include pictures (figures), but only ones that are worth a thousand words

This order, in a logical manner, begins with the highest-level goals and gradually becomes lower-level, setting up the next section. Objectives and Requirements sets up what the system needs to do (and why, given the team’s broader context). Concept of Operations summarizes the system’s operation, i.e. how it meets its requirements, and each decision, given all of the motivation beforehand about what the system needs to do, at this point has a reason behind it.

Motivating design decisions (WIP)

Use of lists

If you find yourself listing in a paragraph, don’t be afraid to use a numbered or bulleted list. This is a technical report, not a novel. Lists are clearer. Moreover, a numbered list’s \items can be \labeled for later cross-reference.

Use of diagrams

Don’t describe a mechanism using just words. Draw a picture of a system in each physical state and diagram the changes that matter the most in each.

Use of plots

• Import all data into MATLAB to plot it. This lets us create scripts around consistent-looking visualization of data (also Excel’s plots just look awful).

• If you are comparing two datasets, overlay them - side-by-side subplots are difficult to compare on the horizontal axis, top-bottom suplots are difficult to compare along the vertical axis

• If you want to talk about specific periods or points in time, mark them. Another reason to use MATLAB for plotting is the easy support for (x/y)lineand (x/y)region to mark up the plot for better readability.

The LaTeX template

During normal writing, the authors will

• Write normal and formatted paragraph text

• Create lists

• Create and cross-reference figures and tables

• Cite external sources

The template provides examples for all of these items under examples.tex ~ if that is too much effort, “how to do X in LaTeX” is usually well-answered by an Overleaf article.

Remember: If you find yourself numbering, referencing, or formatting manually, you’re doing it wrong!

Common LaTeX goofs

• Whitespace and paragraph breaks: LaTeX does not count single new-lines (<Enter>) as paragraph breaks; it just treats them like spaces. Multiple consecutive spaces or tabs are also just treated as one space. To create wider spaces, use operators like \,, \>, or \quad. To create a newline without a pragraph break, use \\. To create a paragraph break, leave a blank line in the source between the paragraphs or use the \par operator.

• Special characters: & is a special character for field separation in tables, and % is the comment chartacter. To use either of these, escape them with \, so that \& prints a “&” into the text, and \% prints a “%” into the text.

For administrators

The overleaf project template is on Launch’s Overleaf account and GitHub. Its functionality is documented in the GitHub repository’s README. If you make a significant change to the template that you think is reusable, commit that change to the repository.

1. Using Launch’s Overleaf account, copy the template and rename to the current year

2. Copy and save editing and viewing links

3. Immediately log out of Launch’s Overleaf account and into your own

4. Populate the basic information (number, year, authors, …)