Software
Last updated
Last updated
The team is required to stay in the bunker during a hot fire, so the engine must be controlled remotely. We chose to use two ESP32s, one of which would send commands (), and the other would report data (DAQ Board). Both devices were constructed as state machines, with COM Board connected to the computer to transmit the data reported by the DAQ Board.
Here is a state machine diagram to visualize the communication:
Since the bunkers and the launch pad are approximately 100 ft apart, using a wired cable between the ESP32s, although reliable and still popular in collegiate teams, was not economically efficient. Instead, we established a wireless connection between the COM and DAQ boards, with an information queue that can hold data while transmitting.
The "pts" are the pressure transducers we implemented throughout the engine system, while the "lcs" are load cells for measuring the engine thrust, and fm is the flow meter measurement. For both sending and receiving data, functions and interrupts are set up to handle.
Establishing the data structure for communications:
In setup(), we need to call the following commands to get everything working:
The following code is the implementation of the state machine. State cases such as -1, 30, etc. are ommited since they are only for testing and debugging purposes. Those states are not a part of the main hot-fire sequence.
To measure the thrust force and monitor the internal conditions of the hot-fire system, we needed to collect pressure, flow rate, and force data at various points. Therefore, pressure transducers (PTs), load cells (LCs), and flow meters (FMs) were to be present throughout the engine system. In the first iteration of our liquid engine, we implemented 4 PTs, 3 LCs, and 1 FM. However, those sensors are not plug-and-play devices; they must be calibrated.
In the past, STAR has done the calibration manually, meaning that we would measure the data using a pressure gauge and weight scale, write it down on a piece of paper (along with the output of the sensors from the electronics), and input the data point to an excel sheet to generate slopes. The slopes, which can be characterized by y = ax+b relationships, would combine with raw data input from the sensors to produce the correct output. This manual process eventually became unsustainable due to two reasons:
Time efficiency. Writing down data, inputting it into an excel sheet, and customizing graphs for different data sets take significant time. Moreover, If the slopes generated do not reflect a linear relationship, as described by the manufacturer, we would have to start the process all over. It delayed our work efficiency, as we could only perform engine tests after all sensors were correctly calibrated.
Labor efficiency: manual calibration usually requires two or more people to be present, since the tedious process could easily confuse the operators and result in incorrect inputs. Having an extra pair of eyes would considerably decrease the error rate, but it would take away available members, decreasing the overall work efficiency. In addition, since this process was confusing, it was usually performed by experienced members, who already had numerous other tasks at hand.
The solution was to create an automated process that could replace most of the human labor, especially the data logging part where things can easily go wrong. MATLAB was chosen to be the agent responsible for logging data, calculating relationships, and reflecting them on a graph. This program has an exceptional advantage in matrix operations and data visualization.
The following is an up-shot of how the new process work:
Hook up all the sensors correctly (PTs connected to the same source, LCs experience the same load) and tweak several settings in the MATLAB program if needed. Then flash the Arduino file into the microcontroller for data output.
Once the correct data stream from the microcontroller is confirmed, start the MATLAB program, wait for several seconds, then click stop.
To verify whether the output is correct, use the serial monitor in the Arduino IDE. However, don't forget to close the monitor, since it will occupy the serial connection channel, denying MATLAB's access.
MATLAB prompts for human input, which is the reading on a pressure gauge or weight scale. After human input, it immediately saves all data, and plots it by the number of devices we wish to calibrate.
If any data point appears to be a measurement mistake, the operator can open the saved .xls file and delete the corresponding row. However, given that only one human input is prompted each time, all devices must share the same number of data points. Therefore, cell deletion is not allowed; deletion should occur across rows.
Repeat steps 2 and 3 until desired relationships are acquired.
Open the .xls file automatically generated by the program, and locate the first two rows. Each column represents a device. Row 1 is a, and Row 2 is b, assuming y = ax+b.
Plug the constants back into the main code to get the correct data output.
There are two parts to the automation: the .ino file for the microcontroller to output data in the correct format, and the .m file running on the computer that does everything else. Here is the code base:
Note: There isn't a single .m file. Sometimes we wish to calculate more complicated constants, so variations are necessary.
Note: There isn't a single .m file. Sometimes we wish to calculate more complicated constants, so variations are necessary.
The same principle applies to the .ino files. Here are some of the variations:
