Skip to content

Latest commit

 

History

History
15 lines (10 loc) · 3.39 KB

About This Project.md

File metadata and controls

15 lines (10 loc) · 3.39 KB

TREL, a student-run research laboratory at UT, is currently competing to be the first collegiate rocket team to launch a liquid-propelled, single-stage rocket that reaches the Karman Line (100 kilometers). This rocket, currently in the design phase, is known as Halcyon. I am a member of the Test and Launch Operations (“TLO”) Team, specifically the TLO Hotfire subteam, who is responsible for developing and testing an analog of the rocket engine that will eventually be on Halcyon.

To be successful, an analog of Halcyon’s engine requires a myriad of sensors and valves that feed a constant stream of information about the engine’s state during testing. Although LabVIEW (the software we use for designing and running tests) provides helpful graphs that show a sensor’s or valve’s output in real-time, it does not provide an interface for the data from multiple sensors and valves to be visualized in one combined graph, nor has a "historical data" fucntionality where old data can be graphed. In addition, at the end of tests, LabVIEW stores the test’s data (from all sensors and valves) in a TDMS file, a file format which is difficult to open and use.

Although I had prior experience with dynamic visualization through Space Golf, the data browser challenged my programming and problem solving skills in very different ways. Instead of developing algorithms related to physics and calculus, I was now developing code related to ease of use and customization. These included:

  • Detecting whether a sensor or valve read digital data (only 0s and 1s) or non-digital data, and then, depending on which type of data it was, plotting it on one of two y-axes. Plotting digital data on the non-digital axis would cause 0s and 1s to be practically impossible to distinguish.
  • "Offsetting" digital data readings, so that digital readings would be easier to distinct from one another. This meant slightly adjusting some digital readings to plot on (for example) -0.03 and 1.03 or -0.07 and 1.07 instead of 0 and 1.
  • Detecting if the TDMS data was written as a string or a double. If the data was a string, then they would have to be converted to a double prior to plotting.
  • Allowing the user to customize a plot’s color and shape of data points
  • Ensuring that customizations from the right hand side of the browser translated to revisions in the plot itself (through PyQt5's signals and slots architecture)

Currently, I am working on a data analysis script that would run in conjunction with the data browser to inform the user of relevant characteristics of the test, such as the duration of valve openings and flow coefficients of orifices and venturis.

I found (and continue to find!) being able to harness my programming ability to help a collective group effort extremely rewarding. Although programming is a skill by its intrinsic nature, I believe that it is best harnessed when wielded as a useful tool for a team to strive towards its goal, especially when that goal is not directly related to programming itself. Unlike Space Golf, which did not have any “bigger” purpose than a school project, this data browser genuinely helps the Hotfire subteam and TREL’s development of Halcyon. And, in the future, I hope to continue developing similar programming scripts that are a means to a greater end.