Ezekiel Mueller - FSE100 ePortfolio

My Prototype

Design Summary

Experience using CAD

Overall, the software was easy to use and pretty straight forward. I feel the technology benefits the design process by allowing faster and more accurate prototyping and allows for less physical iteratives allowing costs to stay down. It was fairly easy to learn, I use Fusion 360 for personal projects so going from sketch based to object based was interesting and took a second, but it's easy to pick up once I got used to starting with a shape instead of sketch. I used the most of the features in TinkerCAD starting with duplicate the most then grouping, snapping/aligning, and the scaling and typing my sizes and distances in right behind that. It didn't change much the biggest change was just being able to have more accurate measurements to scale better so the model is mor proportionate to what it would be in reality. I was able to depict majority of it in the model the only parts not depicted would be wiring harnesses and the electrical side along with more advanced detailing of specific supports and joints.

Using CAD in the Future

In the future I will use these skills to create more detailed prototypes and iterate on designs faster. I can also use it to create models for 3D printing to create physical prototypes. I will also use it for helping visualize more of my ideas to push them to reality and to be able to share them with others. I can also use it to create more detailed models for presentations and reports to better communicate my ideas and designs.

Gantt Charts

My Gantt Chart

The Gantt chart for this project spans February 17 through April 28, 2026, a 71-day window divided into ten phases. Each phase is anchored to one required deliverable: the seven memos (Problem Definition, Aircraft Purpose and Interior Design, Wing Shape, Wing Structure, UML Automation, Automation Code, and Final Design Description and Drawing), followed by FAT Testing, Financial Analysis for the Aircraft, and the Final Report. Within each phase, four to five specific work tasks break the deliverable down into research, analysis, drafting, and review activities. Each time block represents a single calendar day. A daily resolution was chosen because the deliverable cadence is weekly, making days the natural unit of precision, a weekly resolution would collapse too much detail and make it impossible to see whether preparation starts early in the week or the night before the deadline.
The longest phase by calendar span is Phase 10 (Final Report), which covers the last seven days of the project and requires compiling all prior deliverable content into one cohesive document. In terms of sustained technical effort, Phase 7 (Final Design Description and Drawing) is the most demanding memo phase because it requires integrating all prior subsystem decisions, fuselage layout, wing geometry, structural analysis, and automation architecture, into complete drawings and a unified design narrative. Milestones are marked with a diamond (◆) at the end of each phase and represent the Monday midnight Arizona time deadline for each deliverable. If I fall behind schedule, my plan is to identify which specific task slipped, then either narrow the scope of that memo's analysis sections to focus on the most critical design decisions, or start the following phase's research tasks earlier in the prior week to buy back time without compressing the drafting window.

Potential Risks

Risk 1: Technical Complexity Underestimation

Several later phases, particularly Wing Structure, UML Automation, and Automation Code, require technical depth in structural mechanics, software architecture, and systems modeling that may take significantly longer to research and execute than initially estimated. If the complexity of any of these phases is underestimated, work could spill into the following week's preparation window and create a cascading delay. To mitigate this, I will begin preliminary research for each phase at least two days before the prior deliverable is due. For highly technical phases, I will set a personal rule that a first draft must exist by Friday so Saturday and Sunday are available for revision rather than initial writing. If a topic proves intractable, I will consult course resources early in the week rather than persisting independently past a reasonable threshold.

Risk 2: Competing Academic and Professional Obligations

As a part-time student who also works professionally as a videographer and drone operator, high-demand weeks in courses, major assignments, or large field shoots could compress the available time for project deliverables. Weeks with exam stacks or scheduled large-format drone operations represent a particular concentration of risk. To mitigate this, the Gantt chart has been deliberately front-loaded so that research tasks begin early in each weekly window rather than the day before the deadline. Work on project tasks will be scheduled in my calendar alongside other commitments so that conflicts are visible at least a week in advance, and professional assignments that overlap with milestone weeks will be flagged and adjusted where possible.

Risk 3: Design Iteration Forcing Rework of Prior Deliverables

Aircraft design is iterative. A decision made in the Wing Shape memo could expose a structural incompatibility that requires revisiting the interior layout from the prior phase. Similarly, the automation code phase may reveal that the UML architecture doesn't map cleanly to an implementable system, requiring redesign. Because each memo builds on prior work, a significant design revision discovered late could force rework across multiple already-submitted deliverables and destabilize the schedule. To mitigate this, each memo will include a brief forward-compatibility check at the end of the drafting task, a quick review asking "what does this decision constrain in the next phase?", to catch interdependency conflicts before they are locked into a submission. Design choices will be documented with explicit assumptions so that if a downstream phase forces a change, the scope of rework is clearly bounded.

Use-Case Diagram

Sequence Diagram

Activity Diagram

Reflection on UML Modeling

Summary of automated feature:

My Circuit Design

Circuit input/output summary:

My Automation Code

// Pin definitions
const int TEMP_PIN   = A0;  // TMP36 temperature sensor input
const int ALT_PIN    = A1;  // Potentiometer altitude sensor input
const int YELLOW_LED = 9;   // Yellow warning LED output
const int RED_LED    = 10;  // Red alert LED output
const int BUZZER_PIN = 11;  // Piezo buzzer output

// Threshold constants (integer to match map() output)
const int TEMP_YELLOW   = 200;  // Yellow alert threshold (scaled degrees C)
const int TEMP_RED      = 250;  // Red alert threshold (scaled degrees C)
const int ALT_THRESHOLD = 512;  // Below this raw reading = altitude warning

// Timing constants
const int LOOP_DELAY = 500;  // Polling interval in milliseconds

void setup() {
  // Initialize output pins as outputs
  pinMode(YELLOW_LED, OUTPUT);
  pinMode(RED_LED,    OUTPUT);
  pinMode(BUZZER_PIN, OUTPUT);

  // Initialize all outputs to off state
  digitalWrite(YELLOW_LED, LOW);
  digitalWrite(RED_LED,    LOW);
  noTone(BUZZER_PIN);

  // Start serial monitor — simulates FMS data bus and event log
  Serial.begin(9600);
  Serial.println("WTBDAS system initialized.");
  Serial.println("Monitoring thermal conditions and altitude AGL.");
  Serial.println("---------------------------------------------");
}

void loop() {

  // SENSOR 1: Read TMP36 temperature
  // Raw reading 0-1023 mapped to 0-400 scaled degrees C
  // TMP36 in Tinkercad outputs max raw value of ~357 at 125C
  // Mapping 0-357 to 0-400 exercises full alert threshold range
  int rawTemp = analogRead(TEMP_PIN);
  int tempC   = (int)map(rawTemp, 0, 357, 0, 400);

  // SENSOR 2: Read potentiometer altitude
  // Potentiometer right = low altitude, left = high altitude
  // Raw 1023-0 mapped to 0-1000m AGL
  // ALT_THRESHOLD at raw 512 = 500m AGL boundary
  int altReading = analogRead(ALT_PIN);
  int altMeters  = (int)map(altReading, 1023, 0, 0, 1000);

  // Log current sensor readings to serial monitor
  Serial.print("Temp: ");
  Serial.print(tempC);
  Serial.print("C  |  Alt: ");
  Serial.print(altMeters);
  Serial.print("m AGL  |  Status: ");

  // DECISION 1: Temperature threshold check
  // Three branches: thermal critical, thermal warning, normal
  if (tempC >= TEMP_RED) {
    // Critical — red LED on, continuous alarm, FMS waypoint command
    digitalWrite(YELLOW_LED, LOW);
    digitalWrite(RED_LED,    HIGH);
    tone(BUZZER_PIN, 2000);
    Serial.print("THERMAL CRITICAL");
    Serial.println("  >> FMS CMD: Adjust loiter waypoint");

  } else if (tempC >= TEMP_YELLOW) {
    // Warning — yellow LED on, short beep, no FMS command
    digitalWrite(YELLOW_LED, HIGH);
    digitalWrite(RED_LED,    LOW);
    tone(BUZZER_PIN, 1500, 300);
    Serial.print("THERMAL WARNING");

  } else {
    // Normal — clear thermal outputs
    digitalWrite(YELLOW_LED, LOW);
    noTone(BUZZER_PIN);
    Serial.print("TEMP NORMAL");
  }

  // DECISION 2: Altitude threshold check
  // Runs every loop independently of temperature check
  if (altReading > ALT_THRESHOLD) {
    // Low altitude — red LED on, alarm tone, FMS climb command
    digitalWrite(RED_LED, HIGH);
    tone(BUZZER_PIN, 2500);
    Serial.print("  | ALT WARNING");
    Serial.println("  >> FMS CMD: Climb to min 500m AGL");

  } else {
    // Normal altitude — clear red LED only if temp also not critical
    if (tempC < TEMP_RED) {
      digitalWrite(RED_LED, LOW);
      noTone(BUZZER_PIN);
    }
    Serial.println("  | ALT NORMAL");
  }

  Serial.println("---------------------------------------------");

  // Wait before next polling cycle
  // In real aircraft system this would be hardware interrupt-driven
  delay(LOOP_DELAY);
}

References:

TMP36 wiring and voltage-to-temperature conversion based on Analog Devices TMP36 datasheet (Rev. G). Tinkercad circuit construction referenced the Arduino "Analog Read Serial" example from arduino.cc/en/Tutorial/BuiltInExamples/AnalogReadSerial. LED current-limiting resistor calculation (R = (Vcc - Vf) / If = (5V - 2V) / 0.02A = 150Ω, rounded up to 220Ω for safety margin) follows standard Arduino LED wiring practice as documented at docs.arduino.cc. The TMP36 analog read approach references the voltage conversion formula published by Analog Devices in the TMP36 product datasheet. The map() function usage follows the Arduino reference documentation at arduino.cc/reference/en/language/functions/math/map/.

Code results summary and obstacles:

The final code works as expected across all five system states, thermal critical, thermal warning, temperature normal, altitude warning, and altitude normal, with correct LED, buzzer, and serial monitor behavior confirmed for each state. Three obstacles were encountered during coding and circuit construction. First, the LEDs were wired with reversed polarity after being repositioned on the breadboard multiple times, which prevented them from lighting despite correct code output. This was caught by adding a startup LED test in setup() and fixed by flipping the LED orientation. Second, the potentiometer at maximum rotation produced a raw reading of exactly 1023, which the original code treated as a sensor fault condition and triggered a false alert. This was resolved by removing the extreme-value fault check since all potentiometer positions are valid in the simulation. Third and most significantly, the temperature LED alerts never triggered even though the serial monitor showed temperature readings climbing. The root cause was a type mismatch between the map() function, which returns a long integer, and the float threshold constants used in the comparisons. The TMP36 in Tinkercad also does not reach a raw reading of 1023 at maximum temperature, it caps at approximately 357 counts, so the scaling range had to be corrected from 0-1023 to 0-357 to allow the full slider range to exercise all three alert thresholds.

Coding experience reflection:

I have extensive prior coding experience across multiple languages including JavaScript, Python, and various web frameworks, so the Arduino C++ syntax was familiar and the logic structure came naturally. Compared to higher-level languages I typically work with, Arduino coding felt more constrained in a satisfying way, every decision about memory, types, and timing has a direct physical consequence you can see and hear immediately, which is a tighter feedback loop than most software development. I use programming daily in my work building internal web platforms and in my own business developing web applications, so the skills here are directly applicable, though I would love to apply them to something like automating a field communications node that self-configures based on signal strength readings from connected radios. The one thing I wished I could add but ran out of scope for was the 10-second pilot timeout with automatic FMS command execution, implementing non-blocking delay logic using millis() rather than delay() would have made the system behave exactly as designed in the UML activity diagram, and that is something I plan to explore further on my own with the physical Arduino hardware I have available.

Factory Acceptance Tests

My FAT Procedure

Prerequisites

• DJI Intelligent Flight Battery initial SOC ≤ 10% (1 LED bar or less)
• Manufacturer-rated charger and power cable in known-good condition
• AC power outlet at rated voltage (110–120 V, 60 Hz)
• Ambient temperature verified between 15 °C and 40 °C (thermometer required)
• Timer or stopwatch
• Test log sheet to record observations
• No active loads on the battery during test

Test Steps

Test Results

All 10 steps passed. The battery reached 100% SOC in 74 minutes, 16 minutes under the 90-minute threshold. The requirement proved specific enough that there was no ambiguity during execution. Total test duration including setup was approximately 80 minutes, and the procedure is sufficiently detailed that another person could follow it and reproduce the same result without additional guidance.

Lessons Learned

Writing the Requirement First

The most important discipline this exercise reinforced was that the requirement must exist before the test procedure is written, not after. Attempting to define pass/fail criteria retroactively, after you have already observed the system's behavior, introduces unconscious bias toward whatever outcome actually occurred. Writing REQ-001 first, with a specific SOC range, temperature window, and time limit, forced a level of precision that an informal pre-flight battery check would never require. It also revealed how much vagueness is embedded in everyday language: "the battery charges fine" is not a testable statement, but "reaches 100% SOC within 90 minutes from ≤ 10% SOC at 15–40 °C" is.

Repeatability and Traceability

A formal procedure produces a documented record rather than a memory. During the test, recording T₀ and T₁ as clock times rather than relying on a rough sense of elapsed time meant the result was verifiable and unambiguous. This traceability is directly applicable to drone operations: a pre-flight checklist is a lightweight form of the same concept, and a more rigorous FAT-style acceptance procedure could be applied to battery fleet management, sensor calibration verification, or ground station software updates before a high-stakes shoot. The same structure also applies to web platform development, where a formal acceptance test for a new feature before deployment is far cheaper than diagnosing a production failure after the fact.

Procedure Granularity

The ten-step procedure felt appropriately detailed for this test, but it also highlighted where additional granularity would matter in higher-stakes contexts. For example, Step 2 instructs the tester to press the battery status button and count illuminated LEDs, but it does not specify how long to hold the button or how many seconds to wait for the indicator to stabilize. In a consumer context, this ambiguity is harmless. In a certified aerospace or medical application, that gap in the procedure could produce inconsistent results across testers. Recognizing where your procedure assumes implicit knowledge, and making that knowledge explicit, is a skill that improves with each iteration of the test cycle.