Deliverables

The intent of the podium session is to do a deep dive into a notable part of the rocket. All teams are required to submit material, but only 20-30 are selected to present at the competition.

Extended Abstract

A two-page report, in a similar format to the Project Technical Report, that summarizes the area of focus. This should be a relatively low amount of work; it should be possible to copy and edit down the relevant Project Technical Report section.

Podium Presentation

A 20-minute presentation given to your judges and any other judges or teams who want to be present.

Guidance

This is based on a tiny sample size: Yevgeniy’s opinion of what went well for the 2023 podium session. It should be updated as we attempt more.

This is similar to advice for the project technical report, but this section will be under more scrutiny. You need to emphasize not just what is novel about your system, but why it is better engineering than the alternative.

Backplane example

Let’s examine a potential statement for the backplane podium presentation:

We used Ethernet to connect the modules due to its increased bandwidth and interoperability with common networking hardware.

On its face, this looks motivating; it gives a couple of legimiate reasons to use Ethernet. However, this isn’t enough. It does not explain why we care about those advantages more than the disadvantages (or even what the disadvantages are). One notable disadvantage someone would bring up is Ethernet’s more stringent physical layer requierments; the routing has to be better and the ICs and supporting circuitry are physically larger and more power-hungry. The team’s broader context dictated what we cared about: specifically, that we already had a ground station that used Ethernet, and we cared less about physical layer requirements since we had so many more hardware engineers. The text in the report incorporates this:

Broadly, Ethernet offers greater versatility and easier integration with our existing systems, at the cost of hardware complexity, power usage, and fiscal cost. We intend to use this architecture and the ground station’s for years moving forward, and generally have more hardware design bandwidth than firmware bandwidth, therefore those tradeoffs domianted and we chose Ethernet to connect the modules.

Strain gauge example

At the poster session, we discuss all of our systems, and note the similar missions between the rocket and payload, to measure snatch force. At this point, a judge asks the obvious question: “Why does the rocket use an arrangement of strain gauges and the payload doesn’t?” and almost everyone stands there confused. This is avoided by having a thorough understanding of each system’s context, and why some advantages make more sense than others. Specifically, the big difference is the scale of each system. The rocket’s load measurement system requires a rating on the order of 500-1000lb, but the payload’s only 100lb. Using strain gauges saves the rocket a significant amount of space and cost.

Content Suggestions

• Re-attempt strain gauge (2024) – more design heritage gives more content for the project technical report and presentation; it and the calculation methods remain novel

• Retrospective on NMFC (2023) – describing our change to Zephyr, how well the standards fit our use case (what do they prohibit/allow?), and upgrades (not including basic functionality fixes) to each module

• Upgrade and discuss upgrades to the X-winder

History

2024: Non-invasive bulkhead load measurement system (Not selected)

The team used an arrangement of strain gauges on the fore bulkhead to measure the separation shock and snatch force.

Points for:

• Empirical measurement of the recovery harness loads is extremely uncommon

• Developing our own sensitive analog measurement system is technically challenging

• No team has (been known to) attempt anything like our separation shock calculator

Points against:

• Not enough time to polish the presentation

• Not much emphasis on the separation shock dynamic model

• Not enough words on the slides – normally a good presenter can make it work with few words but the judges don’t see that when selecting

• Another team was selected for a podium session by arranging strain gauges on the fins

2023: A networked modular flight computer architecture (Selected)

The team developed a modular flight computer architecture that used Ethernet. Everyone else used I2C, UART, SPI, or CAN.

Points for:

• First attempt at Ethernet-based architecture

• Emphasis on forward-looking standards development

• Thorough discussions about the tradeoffs in each portion of the standard

• (weak) Flat design looks different from everyone else’s

Points against:

• Yet another modular flight computer

• Did not address time synchronization between modules, network latency, or timing garauntees - all advantages of CAN

• No flight heritage