Frame
Engineering Challenges
Since Eagle X’s airframe was 3D printed (as opposed to cardboard or plastic tubing), substantial mass reductions were necessary while maintaining sufficient strength to withstand vertical compressive loads, high-speed horizontal impacts (landing), support 25.3N of engine thrust through 4 load-bearing joints, and normal handling loads. The initial iteration encountered issues such as intra-layer separation, thermal deformation, and excessive weight. The subsequent solutions included:
- Airframe Thickness Reduction: 2.1mm —> 0.9mm
- Segment Count Reduced To 2 (To Decrease Weight from Segment Joints, Reduce Points of Failure, and Enhance Manufacturing Efficiency)
- 3D Printer Filament Change: PLA —> ABS —> PLA+ (PLA+ Demonstrated Superior Tensile and Yield Strengths)
- Increased Layer Count to Reduce Aerodynamic Surface Friction, Complementing Adjustments to Printing Temperature, Speed, and Other Parameters.
Electronics
Description
The test stand’s electronics served two primary functions: data input and output, and motor ignition. Data IO was accomplished by connecting Teensy 4.0 I/O terminals to a terminal block, while motor ignition was achieved through the control of two independently regulated MOSFETs. In the rocket motor testing configuration, the Teensy collected data from a load cell and transmitted it via a long USB cable to a laptop. The laptop recorded the data and presented it to a user interface. Additionally, the laptop communicated with the Teensy to control the MOSFETs.
Engineering Challenges
This was my first project that incorporated PCB design, resulting in an initial challenging phase. As evident in the first image, version one of the PCB disregarded physical spacing requirements and lacked a functional relay system. It also lacked a central processing unit, rendering it solely an ignition board. Over the iterations, the electronics were enhanced with two relays, which subsequently transformed into two MOSFETs. Additionally, the electronics were equipped with I/O terminals for the onboard Teensy.
Control Center
void draw() {
if (myPort.available() > 0) {
val = myPort.readStringUntil(separator);
if (val != null) {
background(0);
textSize(30);
text(val, 10, 30);
Description
The graphical user interface (GUI) of the test stand was programmed in Java using the Processing IDE. The Teensy device on the test stand electronics transmitted data via USB to the laptop, which subsequently fed the data into the GUI. The GUI incorporated various functionalities, including a date and time display, a countdown clock, a thrust graph along with thrust data, a system status board, and a control panel. The control panel enabled the user to control the ignition system, initiate and terminate data logging, and manage the countdown clock. Additionally, the control center exported all the raw data into a CSV file.
Engineering Challenges
The graphical user interface (GUI) was initially developed using Node-RED, as depicted in the first image. However, this platform lacked the flexibility of a newly-designed user interface. Python-based UIs were considered, but they did not align well with the application’s requirements. Consequently, the Processing IDE was ultimately selected for its suitability.
Operations Manual
Description
The test stand operations manual was designed to establish a repetitive and consistent routine during each firing. This is crucial to minimize errors, enhance safety, and reduce variations in results. The manual provided a comprehensive step-by-step guide, commencing with hardware setup and concluding with hardware takedown. The manual demonstrated its effectiveness when Subtask (2.1) was implemented. Notably, the test stand load cell exhibited a wobble that could significantly distort the results if not addressed prior to firing. Consequently, the manual served as a reminder to inspect the load cell before each firing.
Engineering Challenges
The creation of the operations manual was arduous due to the extensive number of tasks and sub-system checks involved. This challenge was mitigated by conducting multiple “dry runs,” wherein I simultaneously drafted the operations manual as I progressed through the entire operations process. These iterative attempts ensured that all steps were adequately covered and that the overall process would operate seamlessly.
