For the work period of Feb. 4th to the 17th, preparations are underway for validation of the device, the MATLAB application is in the process of being coded, and the physical device has been fixed up a bit.
Instead of being taped together, liquid adhesive has been used to secure the battery case and two pieces of the device’s body together.
On a more substantive note, the MATLAB application is still being programmed. As previously discussed, the application needs to perform the following tasks:
Allow the user to upload files for a baseline audio dataset.
Process the baseline audio dataset to extract signal features therein.
Tabulate these features as a feature matrix, where each row of the matrix is associated with a single tap of the bolt.
Assign labels to the feature matrix based on user input.
Calibrate a machine learning algorithm with this feature matrix and labels.
Take an audio file with unknown properties and categorize it based on the calibrated algorithm.
The application currently allows the user to upload files and it can extract MFCC features from the audio. It can also make the feature matrix. This was the bulk of the programming, as calibration of machine learning algorithms is often only a few lines of code, and the application is expected to be finished within the coming two weeks.
Even with the application currently in progress, some validation tests for the project can be pursued. This includes validating the specifications associated with device sound volume and battery life. This preparation includes purchasing necessary equipment for it, primarily a data logging multimeter to document the device’s electrical behavior.
Near-term work primarily looks at execution of the validation and finishing the MATLAB application. The team can foresee some possible obstacles for the progression of our project. These include the possibility of a lack of response from HYTORC regarding our usage of their calibration bench for validation. The team is working to elicit a response from HYTORC and have investigated the production of our own bolted structures for validation purposes. In addition, it is also a possibility for the validation tests to be delayed due to factors such as shipping times. The team has explored multiple routes of obtaining the equipment needed for such tests.
As of February 17th, a data-logging multimeter has been acquired. However, when the validation of the device’s battery life began, some unforeseen issues were found that hindered the validation process originally described in our design review report.
First, the wires connected to the solenoid and battery pack were starting to overheat faster than we anticipated, which meant that our previous plan of continuously monitoring the battery life proved to be unrealistic. Second, given the size of the multimeter prongs and the positioning of the wires that the prongs needed to be in contact with, keeping the prongs at their ideal position where the voltage could be measured accurately and consistently proved to be a tall task for one singular person as the button to actuate the solenoid also needed to be pushed down while recording data.
To address these issues, the team decided on altering the validation process in a few aspects. First, validation of the battery life will be done in conjunction with percent accuracy validation. This will allow for multiple people to be present during validation which will aid the process of gathering data. Second, the way in which the data will be collected will change from continuously gathering voltage data, to gathering data while the device is in use, then interpolating the time it would take to perform monitoring and to run the battery dry. This will assist in circumventing the overheating issue associated with running the test for too long.
Comments