Embedded Files
TAMU Sounding Rocketry Team
Testing Operations Engineer
August 2023 - May 2024
The full sensor suite setup that is used during SETs. (Values are randomized for testing purposes, besides the RT AFT TEMP, which has its voltage divider circuitry being tested with a 100 ohm resistor).
During my freshman year at Texas A&M, I was accepted onto the Texas A&M Sounding Rocketry Team (TAMU SRT or just SRT). I joined the Ground Support Testing and Operations subteam (GSTOP), and I immediately found a new passion, Testing Engineering.
If I'm not studying for an upcoming test or doing homework, then I'm working on something for SRT.
During my freshman year, I worked on creating test cases for electronic systems that would be used on the rocket and within the ground support system. That's another topic though.
During my Sophomore year, I started a new project with the goal of improving data acquisition, visualization, and controls during our engine tests at RELLIS.
RELLIS is a secondary Texas A&M campus in College Station, TX, where SRT conducts engine tests and other testing operations.
On GSTOP, I develop and improve our data acquisition systems for gathering data during engine tests by installing new sensor hardware, making hardware updates to our DAQ Box, building the required circuitry (such as voltage dividers for RTDs), and developing new computer applications (a.k.a. GUIs) for DAQ and testing purposes.
The sensors we gather data from include Pressure Transducers, Load Cells, RTDs, Potentiometers, and Thermocouples.
I also make renovations to our Test Cell, as well as preform testing operations as a tech during our engine tests.
The test cell shed, where we place our data acquisition equipment, networking/ comms equipment, nitrous oxide K-bottles, and camera equipment. I also have a little fluids experience working with nitrous systems.
A view of the flame diverter underneath the vertical engine cage in our test cell.
The DAQ Box I work closely with. This picture was taken after installing an analog multiplexer to increase the number of sensors we can measure data from.
The entire GUI is written in Python and uses the Qt framework for graphical elements. With more than 6,000 lines of code, this is the largest project I have ever coded, and the first project I have ever coded in Python.
Everything I needed to learn was self-taught, and I'm not a computer science major, so there was most certainly a learning curve.
I faced a lot of challenges during early development. One major roadblock I encountered was how to record accurate time while also keeping sample rates high. To overcome this, the program updates all GUI elements on the main CPU thread (which is mandatory in all programs with GUI elements), and in parallel, all of the DAQ operations are done on a separate worker thread. This ensures that the data gathering is not held up by the intense process of updating graphical elements.
GUI during early development.
The DAQ Loop inside the code.
The DAQ Loop is the function that is called when the program needs to gather, process, and record data.
This loop is called at an interval specified by the user, known as "sensor sample rate", given in Hz.
The maximum sample rate that the program is currently capable of, with no data load, is 10,000 Hz. That means this loop can be called 10,000 times a second. This is possible because the program uses the Windows system time, which has a very high resolution.
However, in practice, the sample rate is never that high. While using our current ADC, the LabJack T-7, with 13 analog channels being read, the maximum sample rate is about 80 Hz.
I am currently working on getting that number up over 1,000 Hz, which honestly will not be too hard to achieve, as the LabJack T-7 is a very capable device, and my code just requires a few changes to implement the change. The maximum sample rate achievable with our current ADC and sensor setup is theoretically ~7,000 Hz.
Current Features
The GUI is oriented in a Sensor-Device perspective.
The user can define a DAQ Device, which is the conduit where the sensor data comes from, whether it be voltage, digital signals, or ethernet protocol packets, a device needs to be set up to get any use out of the GUI.
Then, the user can define a Sensor, which could be a resistance temperature detector, pressure transducer, thermocouple, potentiometer, etc. Any measurement device that supplies any form of data can be considered a sensor. The data just needs to be able to be read and collected by a DAQ device. The sensor can then be paired to a data stream that comes from a device, which would be, for example, an Ethernet UDP packet, or a LabJack T-7 analog channel.
Currently implemented DAQ Devices are the LabJack T-7, and UDP Ethernet Protocol.
The image on the right shows the analog input configurations for a LabJack T-7 device. A single-ended measurement, a differential measurement, and a measurement with the extended feature circuit 5, which uses a voltage divider to calculate resistance, are shown.
There is also a potentiometer option to measure potentiometer angles. In SRT, we use a potentiometer to measure the angle of our main flow ball valve, which supplies nitrous oxide to our combustion chamber. Something we are trying to achieve this year is active engine throttling.
The analog input configurations for a LabJack T-7 device.
When the user defines a sensor, they can give it a name, select a sensor type, and specify optional fields such as units, manufacturer, model, and serial number.
Optional fields like those are essential for staying organized, as all information regarding sensors and devices is written to a config file at the start of each data collection. No more digging through the documentation before an SET trying to figure out which analog channels use which sensor, or which sensor goes where (all of our sensors are labeled, but sometimes discrepancies occur).
The sensor type controls what kind of additional calculations are done to the data this sensor receives from its connected device's data stream.
Current sensor types include Linear Curve Fit, RTD PT-100, RTD Custom Polynomial Fit, Data Stream, and Data Stream If/Else.
A defined sensor, with the RTD PT-100 calculation option selected.
GIF demonstrating the main display function.
The cool thing about creating a program from scratch, is the fact that you can do whatever you want with it.
Visualized here is the Dashboard, where everything is displayed for the user's benefit. Sensor values on the top left, sensor graphs on the bottom left, a master graph on the bottom right, and a main display diagram on the top right.
The user can upload any image file they want, and then drag display widgets around and move them with the arrow keys to position them anywhere over the image.
Here I am dragging a run tank pressure transducer sensor into the main display, and positioning it over a schematic of our current hybrid engine and fluid panel.
After every data collection, a data file is saved, as well as a config file. The config file records all relevant information about any devices and sensors included in the data collection. The data file records all processed and raw sensor data, at the sample rate the user specified.
Future Plans
Currently, the GUI is in a good functional state. It can gather, visualize, and record sensor data at a decent sample rate. It is also quite modular, many types of sensors can be added, and many types of devices can be added. However, there are many more things I want to add and improve upon.
In addition to improving the sample rate, I want to add outgoing data requests to the Ethernet UDP device, as well as digital signal outputs to the LabJack T-7 device. This is an essential step before attempting automated engine testing, such as automatic fill procedures.
I also want to add a control loop tab, where the user can write a control script, in Python, to control external stimuli such as relays, or servos, based on current sensor data within the application.
Something also important to add, will be a profile save and load feature, where the user can load a profile so they do not have to create all sensors and devices and fill in the respective information.
Lastly, my main goal for this program is to leave a lasting impact on TAMU SRT Ground Support and Testing Operations. Most of my work, in my opinion, will be in vain if future members cannot use my GUI for custom tasks, tailored to what the team needs to get done that year. I plan to create documentation and tutorials that showcase the creation of new sensor types and device types, in addition to showing my current workflow for coding Qt graphical elements. To do this, I need to completely refactor most of the classes in my code, making certain features class-based, and creating wrappers and templates to make new development by future members go as smoothly as possible.
SRT-10 (2022-2023) TOPS Techs. From Left to Right, Alex Futoma, Kempton Burton, Ryan Bowersox.
SRT-11 (2023-2024) Current Testing Setup.
Check back for future updates to see what i'm working on! I'm either studying, or working on something dope for the Texas A&M Sounding Rocketry Team!
Google Sites
Report abuse