Introduction

Each major project we are tracking will receive a subpage for this cycle. Begins roughly end of May 2024 and ends after AEAC 2025 competition. Philosophy is spawned from AEAC 2024 competition debrief: 2024-06-04 Competition Debrief #2 . We are also considering SUAS 2025 competition as a possible path for this cycle in addition to numerous R&D projects! For a further breakdown after this competition cycle please refer to History .

High Level Competition Direction

• Modularity: focus on common mounting solutions and existing standards for electronics and software so our system can adapt easily to new requirements and objectives.​ i.e. Mounting Hole & Pattern Specifications and Airframe Design.

• Testing: testing new systems early and often has been extremely beneficial for us, let's keep this going for every subsystem! See Iterative Design Process for more details.

• Competition Advantage: programs should be explicitly separated between learning only design projects versus projects we need to put significant resources toward validation on.

• Affordable/Repairable: We will be crashing, let's keep stuff affordable, use budgeting effectively. 

Learning Only Projects

Projects we intend on using at competition require a significant amount of testing and validation. Testing and validation innately requires significant funding as well due to the possibility of failures as well as the time and effort required to integrate systems. For these reasons, what we intend to deliver at competition must be scope locked and heavily scrutineered by the leadership team. These projects will receive a significant amount of collaboration, integration, and project management to ensure delivery is on time and up to quality for our competition objectives.

Newer members often join design teams for resume experience and do not wish to contribute toward testing and validation. These members seek to do exclusively design work but often lack the necessary skills to produce quality work in a timely manner. For this reason we should offer learning centric projects to members who clearly state their learning focused intentions. We must be clear these projects will not receive as much funding and senior member attention as our competition oriented projects. These projects are much better oriented for having a single person contribute to them because they require no integration effort. Hopefully these projects are useful for the individual contributor who gains design experience and the team which may be able to leverage this design in the implementation of a future competition system.

Bootcamps are the biggest example of a learning only project! They receive no funding, minimal hardware allocated (if any), no timeline requirements, are resume viable, and entail some (but not a lot of) input from leadership/management.

Architecture Documents Direction

• Avoid the formality in architecture information to maximize editability and usefulness.

• Subteam leads are expected to guide members through projects, not the architecture documents themselves.

• The target audience and contributors is leadership so no need to go into significant specificity.

  • Only spend your time writing these architecture documents documenting details that need to be present to ensure all of leadership understands our plans.

  • If a detail is obvious to all of leadership then it does not need to be documented. As a lead your time is valuable, spend it leading your subteam, not writing useless documents.

This philosophy toward documenting the system can also be extrapolated to our flight test program for this competition cycle.

Programs