As discussed in the previous blog post, we plan on looking at issues concerning bolt monitoring, and most of our reasoning in terms of pursuing a solution, though it has been refined. In the absence of methods of inspecting bolt looseness for 1” and larger commercial bolts, we’re pursuing a method that uses audio analysis and supervised machine learning algorithms to determine if bolts are loose or tight. A concise description of the problem is as follows:
Bolts become loose over time, and current methods and tools for monitoring bolt tightness are primarily aimed at smaller bolts. Among methods of monitoring larger bolts, most tools can cost thousands of dollars and only monitor one type of structure each. Additionally, while it’s theoretically possible for companies to just torque every single bolt up to a set tightness without monitoring, this process can be very physically strenuous.
Our team is going to use a percussion method to inspect bolt torque. Through tapping on a bolt, it is possible to determine whether it’s currently at a target torque. The general process is shown in the following figure.
Applying this to the solution, however, would look closer to something in the following figure. A handheld device that taps on the bolts and records the audio data would store the data locally before the files are uploaded to a separate application, likely on a laptop. A laptop or computer being needed to use this device should not be a concern given that most companies already use such devices for other tasks, such as organizing other data.
Ultimately, auser of our solution would tap on a set of bolts, record the audio, upload the audio files from the device to a laptop, and use the audio files in a MATLAB application that processes the audioand sorts the bolt data intotwo different categories: Torqued and Loose. We’ve outlined a few constraints that’re physically important to the design below.
Constraint | Associated Specifications |
Bolt Assessment Accuracy | 85% Accuracy in testing and validation. |
Ease of Use | 80% of users should be able to use the device on a single bolt after given an hour with the manual and the device. |
Use Life Duration | 4 hours of life before needing power maintenance. |
Financial Accessibility | Below $500 to manufacture solution. |
Portability | Fits within 1.0’ x 1.0’ x 1.0’ cube. Weighs less than 5 lbs. |
Processing Time | Takes less than 10 seconds per bolt being analyzed. |
Bolt assessment accuracy is likely the most obvious among physical constraints for the solution. For the device to work, it will obviously need to accurately assess the torque state of the bolts. “Torque state” here refers solely to whether the bolt being analyzed is at a target torque or if it’s below that. Use life duration is another physical constraint under consideration here. The handheld part of the device will need to last a given number of hours without needing to charge or have batteries replaced. We decided on four hours due to that being half the duration of the average workday.
The physical constraints under consideration are portability and financial cost. Portability manifests itself as fitting within a one-foot cube and weighing less than five pounds. After all, given that this device is meant to be easier than just tightening all the bolts regularly, it will require less physical strain to use than doing that. Additionally, with the goal of being cheaper than other methods in mind, the device should take less than $500 to manufacture, thus increasing accessibility of the solution.
As far as technical analysis is concerned, the most important one concerning this solution will involve signal processing. This mainly affects the application developed along with the physical device, where it would be tested to correctly identify a bolt as either tight or loose. In the determination of tools to use for tapping on bolts, different devices will be tested, and the audio data gathered therein will be examined. Ideally, the best device will have the most noticeably different audio between tight bolts and loose ones. Additionally, FEA will be performed to simulate the stress experienced by the device during tapping, which will help in choosing a cost-effective material for a device case along with its optimal design. This will help with the bolt accuracy and financial constraints.
Additionally, to help satisfy the use life constraint, two things will be considered: manufacturer specifications of device components and circuit analysis. Regarding the circuit analysis, use life will be determined most likely by using a data logging multimeter to examine voltage and current data as a circuit continuously runs over time. When voltage or current goes below a certain value, thereby making the device not as effective, the time up to that point would be considered as its optimal battery life. This particular analysis will only be needed if part of the device requires construction of a circuit, particularly if our tapping method needs it. The below figure shows what such a circuit might look like.
On top of this, a big part of our design depends on securing the connection between our application and our physical device. For our prototype, we intend on purchasing an audio recording device that will store data locally. This will likely take the form of a data storage unit like an SD card or a USB drive. Since we are working with MATLAB, we will work to ensure that the device saves the audio data in a format compatible with MATLAB, such as .wav. This will involve looking at a number of manufacturer specifications. Nonetheless, it is possible to use MATLAB commands to convert file formats, so other parts of manufacturer specifications will be prioritized, such as use life.
It’s crucial to us that our device possessed the capability to capture and retain the vibrations generated by tapping on the bolt, enabling us to accurately determine whether the bolt has been properly torqued. To achieve this in our final design, our team will begin by meticulously outlining a set of clear-cut requirements and objectives for our application. These well-defined benchmarks will serve as our guide, ensuring that we remain steadfastly aligned with the core purpose of application. The physical device should feature data transfer capabilities in some form. The transferred data should also be in a format that the application is able to utilize for its bolt analysis.
In terms of soft challenges, we need to make a design that is easy to use for people that are weak. In recent talks with our professors, we found that we needed a reason for our solution to be better than just torquing every bolt to be safe. This was easy to remedy, given that torquing every bolt both takes a lot of time and takes a lot of physical strength, so a device like the one we’re making would allow inspection positions for commercial bolts to weaker individuals. This comes with some soft challenges outside of just size and weight.
For example, the application associated with our solution must be intuitive. Our design team identified areas for enhancement in our ease-of-use validation process. Originally, we relied on a somewhat flawed criterion, where achieving a 7/10 average on an ease-of-use scale, a survey that our team would provide was the benchmark for success. However, during the pitch idea presentation, it became apparent that there was a considerable degree of confusion regarding this validation process. This prompted us to recognize how our current validation method was subjective.
Subsequently, we began working on a new validation process for the ease-of-use constraint. The conclusion we came to was that our new validation process would involve having a group of users spend an hour navigating through a manual created by us. We would then test their ability to operate the device seamlessly after the brief familiarization period. This promises a more concrete and tangible evaluation of ease-of-use, aligning with our commitment to delivering an exceptionally user-friendly product. It’s hard to associate any physical constraints to this, but to make sure the solution is easy to use, navigating the application we make shouldn’t be confusing. Most of the functions associated with the application will be uploading audio files, so communication on which files to use on which part of the application will be of utmost importance that will be included in the manual.
Another soft challenge has to do with processing time. We want data associated with one bolt to take about ten seconds to process. This is mostly going to be affected by how the previously mentioned application uses the data. It will have to give all associated data to a machine learning algorithm, so optimizing processing speed vs amount of data needed for accurate readings will influence the solution’s design.
Fabricating a device that is able to address and adhere to both the physical constraints presented and the soft challenges will definitely prove to be challenging. However, we are confident that we will be able to come up with a solution that will be intuitive enough for the untrained user while also being physically non-demanding to operate so that any and every user can use our device efficiently.
Comentários