Rocket Test Stand
Rocket, Rocket Motor, and Rocket Subsystem Testing Platform
|
|
The rocket test stand was designed to be a testing platform for rocket motors, rocket subsystems, and fully integrated rockets; however, the primary configuration was the rocket motor testing configuration. Each subsystem will be listed along with pictures, descriptions, and technical data. Click on the photos to see captioned descriptions.
Test Stand Frame
Description:
The frame of the test stand was made of 2 in. by 2 in. aluminum rods welded together into a cube. The frame was painted with spray paint and heat-resistant painting was applied closer to high-temperature areas.
Engineering Challenges:
Originally, the plan was to use 80/20 aluminum extrusions for the structure. This seemed like a good idea because the extrusions have rails built into them. Therefore, they could've been used to easily change the testing mode / configuration of the test stand. However, they were simply too expensive for the budget of the project.
During the last firing of the test stand, the parachute charge of the hobby model rocket motor ignited, as it had not been taken out. This caused a massive back pressure within the engine holding cavity, causing the crossbar of the test stand to bend under the force (seen in the last picture). The fix for this is to simply remove the parachute charge and any other non-used explosives from the motors.
The frame of the test stand was made of 2 in. by 2 in. aluminum rods welded together into a cube. The frame was painted with spray paint and heat-resistant painting was applied closer to high-temperature areas.
Engineering Challenges:
Originally, the plan was to use 80/20 aluminum extrusions for the structure. This seemed like a good idea because the extrusions have rails built into them. Therefore, they could've been used to easily change the testing mode / configuration of the test stand. However, they were simply too expensive for the budget of the project.
During the last firing of the test stand, the parachute charge of the hobby model rocket motor ignited, as it had not been taken out. This caused a massive back pressure within the engine holding cavity, causing the crossbar of the test stand to bend under the force (seen in the last picture). The fix for this is to simply remove the parachute charge and any other non-used explosives from the motors.
Test Stand Electronics
Description:
The test stand electronics served two purposes: data input / output and motor ignition. The former was achieved by linking Teensy 4.0 I/O terminals to a terminal block and the latter was achieved by two independently controlled MOSFETs. In the rocket motor testing configuration, the Teensy collected data from a load cell and sent it through a long USB wire to a laptop. The laptop then logged the data and sent it to a user interface. The laptop also sent commands to the Teensy to control the MOSFETs.
Engineering Challenges:
This was the first project I had undertaken that included PCB design, therefore, it had a rough start. As seen in the last photo, version one of the PCB had no respect for physical spacing requirements, nor did it have a functional relay system. It also had no "brains", therefore it was just an ignition board. Over the iterations, the electronics gained two relays, which turned into two MOSFETs, and the electronics also gained I/O terminals for the onboard Teensy,
The test stand electronics served two purposes: data input / output and motor ignition. The former was achieved by linking Teensy 4.0 I/O terminals to a terminal block and the latter was achieved by two independently controlled MOSFETs. In the rocket motor testing configuration, the Teensy collected data from a load cell and sent it through a long USB wire to a laptop. The laptop then logged the data and sent it to a user interface. The laptop also sent commands to the Teensy to control the MOSFETs.
Engineering Challenges:
This was the first project I had undertaken that included PCB design, therefore, it had a rough start. As seen in the last photo, version one of the PCB had no respect for physical spacing requirements, nor did it have a functional relay system. It also had no "brains", therefore it was just an ignition board. Over the iterations, the electronics gained two relays, which turned into two MOSFETs, and the electronics also gained I/O terminals for the onboard Teensy,
Graphical User Interface
Description:
The test stand's graphical user interface (GUI) was programmed in Java in the Processing IDE. The Teensy on the test stand electronics sent data through USB to the laptop, which then fed the data into the GUI. The GUI featured date & time, a countdown clock, a thrust graph + thrust data, a system status board, and a control panel. The control panel could turn the ignition system on and off, start and stop data logging, and control the countdown clock. The GUI exported all of the raw data into a CSV file.
Engineering Challenges:
The GUI originally was made using Node-RED, as seen in the second photo. However, this platform lacked the freedom of a freshly-programmed user interface. Python UIs were looked into, however, it simply did not fit the application well. In the end, the Processing IDE was used.
The test stand's graphical user interface (GUI) was programmed in Java in the Processing IDE. The Teensy on the test stand electronics sent data through USB to the laptop, which then fed the data into the GUI. The GUI featured date & time, a countdown clock, a thrust graph + thrust data, a system status board, and a control panel. The control panel could turn the ignition system on and off, start and stop data logging, and control the countdown clock. The GUI exported all of the raw data into a CSV file.
Engineering Challenges:
The GUI originally was made using Node-RED, as seen in the second photo. However, this platform lacked the freedom of a freshly-programmed user interface. Python UIs were looked into, however, it simply did not fit the application well. In the end, the Processing IDE was used.
Test Stand Operations Manual
Description:
The test stand operations manual was created to ensure a repetitive and consistent routine during each firing. This is important to minimize error, increase safety, and minimize variants in results. The operation manual contained a step-by-step guide starting from hardware setup to the hardware takedown. The operations manual proved to be effective when Subtask (2.1) was put into effect. The load cell on the test stand had a wiggle which would largely throw off the results if not fixed pre-firing, therefore the operations manual served to remind me to check it before each firing.
Engineering Challenges:
The operations manual was difficult to create due to the large number of tasks and subsystem checks. This was solved by doing multiple "dry runs" where I created the operations manual as I went along the entire operations process. Doing multiple dry runs helped ensure that all steps were covered and that the entire process would run smoothly.
The test stand operations manual was created to ensure a repetitive and consistent routine during each firing. This is important to minimize error, increase safety, and minimize variants in results. The operation manual contained a step-by-step guide starting from hardware setup to the hardware takedown. The operations manual proved to be effective when Subtask (2.1) was put into effect. The load cell on the test stand had a wiggle which would largely throw off the results if not fixed pre-firing, therefore the operations manual served to remind me to check it before each firing.
Engineering Challenges:
The operations manual was difficult to create due to the large number of tasks and subsystem checks. This was solved by doing multiple "dry runs" where I created the operations manual as I went along the entire operations process. Doing multiple dry runs helped ensure that all steps were covered and that the entire process would run smoothly.
