Integrated System Build & Test
Table of Contents
List of Possible SolutionsSolution Tree
Team Vision for Integrated System Build & Test PhaseThe goal of this phase was to build and demonstrate functionality of the integrated system. Unfortunately, our project encountered a problem with generating a useable signal, resulting in one of our major subsystems not working. Therefore, during this phase, the team followed various MSD processes in order to find a solution to the problem:
- Spoke to Dr. Kempski from the ME department, a subject matter expert in strain gauges.
- Spoke to Dr. Wellin from the ME department, a subject matter expert in labview signal processing.
- Met with Mike Walker and John Carr at Gleason Works to see if they can find something that the team is missing. They gave us a few recommendations for experiments to try out that are shown below.
- Spoke to Mr. Slack and Dr. Fuller from the EE department, to see if something can be done on the EE side.
- Met with Paul Baumgartner from Maxwell Bennett Associates, a company that specializes in vibration measurements.
- We are currently in contact with Sharif Gindy of SensorData Technologies. His initial suggestion is that our structure is too rigid.
Throughout this phase, the team made use of the risk management tools and problem tracking tools provided to us. Unfortunately, the team still has no solution to solve the problem.
What was the surprise? During the course of MSD I, we made a major assumption that the strain gauges would be sensitive enough to pick up the strain. Our initial conclusions suggest that this assumption may have been incorrect after carrying out a simple cantilever beam test. After finding high variance of data in our test, we also feel that we may be dealing with high uncertainty due to unknown factors which hinder our results. In regards to the problem being that the structure is too rigid, it will not be feasible for the team to redesign the structure within our given timeframe and budget.
Test Results Summary
Static Load ExperimentStatic Load Experiment
This document discusses how applying a static load to our device should have shown a millivolt output from the Wheatstone Bridges. However, after applying a 25lb (110 Newton) load to the structure, we were still not seeing the desired output. This led us to carry out the torsional load experiment mentioned in the Wheatstone Bridge Validation.
Deflection Analysis TestDeflection validation Experiment
The document discusses our procedure and results for the test we performed in order to validate out simulations on our device. The reasoning for this test was to validate our simulated values and thus the other values produced in the simulation, specifically the strain in our measurement structure.
Torsional Load ExperimentTorsional Load Experiment
This document showcases how we conducted the torsional test as well as summarizes what our observations. In short, the voltage recorded was 1000 times less than we originally expected.
Voltage Drop ValidationVoltage Drop Test
This document gives evidence to validate that the strain gauge wheatstone bridge circuits are wired up correctly, and that no short or open circuit conditions exist within the wheatstone bridge subsystem.
Wheatstone Bridge ValidationWheatstone Validation
This document discusses how the test load case for our structure was validated using theoretical calculations to determine that a bending moment would not excite the bridge, whereas a torsional load would produce an output voltage.
The document also discuss the procedure and results for a simple cantilever beam test that was done to validate that the strain gauges were functioning correctly and would be able to measure the strains our device was expected to see. The test showed that there was a large percent error in change in output voltages between unloaded and loaded conditions when the predicted results were compared with the experimental results. This lack of precision is worrying, but does not explain our inability to obtain a voltage output when testing the full structure.
Risk and Problem Tracking
- Validate all MSD I assumptions - no matter how trivial.
- Do not take customer's word as law.
- Use guide whenever help is needed, and proactively reach out to Subject Matter Experts.
- Don't underestimate the simple parts of a project. Usually the things that aren't thought about can pop up later and cause issues.