Subsystem Build & Test
Table of Contents
Team Vision for Subsystem Level Build & Test PhaseSummarize: This phase, our team intended to have all subsystems built and tested, in preparation for assembly. We also anticipated our risks to drop heavily this phase, as a result of actual construction and testing starting to take place. The electrical engineers worked together to secure all ordered subsystems, acquire necessary test equipment, and do validation testing on those components. The software engineer continued backend software development and hardware integration in preparation for the final assembly. The mechanical engineers secured the printing of the exterior parts, explored sealant options for the exterior, and started the construction of other subassemblies for the motors and handles. A few subsystems are left to be built, but the plan is in place for how to accomplish that and has not yet affected our end delivery date. However, our risks did not significantly decrease as anticipated. This is because most of our risks are still prominent, even with most subassemblies built. We expect a majority of the risks to diminish after this next phase, once the final assembly is complete along with our ER test plans.
Test Results Summary
Summarize test results and assess effectiveness of test plans to unambiguously demonstrate satisfaction of the engineering requirements
The goal of testing is to prove that subsytems will be able to meet engineering specifications. This is a difficult task for this project because most of the subsytems are dependent upon others for their function. Test plans were design to assess aspects of subsytems that could be tested independently.
T1: Motor ThrustThe goal of this test is to assess the maximum thrust provided and current drawn by the propulsion subsystem. The motors were expected to produce 1.5 kgF of thrust each, and were found to produce 1.2 kgF in the forward direction and 0.2 kgF in the reverse direction. These values, while less than expected, were deemed acceptable because the engineering specification of greater than 0.1 m/s for a maximum velocity was met in simulation.
1. Obtain a large tub of water, fill to 50%
2. Place a 1 ohm high power rated resistor across the power supply to the motor controller. Use a voltmeter to read the voltage and convert to current. (Other voltage probes were tried but created circuit issues)
3. Place a motor on a rigid pivot. Attach linear force gauge to the pivot. Fix linear force gauge to a static reference. It should be noted that the specific setup used had a 21" length top arm and a 10" length bottom arm.
4. Use arduino to send command to motor controller, use LabQuest 2 to record the force gauge output and record peak current drawn on the voltmeter.
5. 4 with various commands. The only conditions that are critical to test are maximum forward and backwards thrust.
Testing setup used for reverse direction. Motor is rotated 180 degrees about the z axis for the forward test.
Set up to record the maxium current drawn. A video was taken so that the human eye wasn't used as a measurement tool.
link to video documentation of the forwards thrust test: video documentation
Using a simulation based off a second order ODE, the data was converted from force on the force gauge, to thrust of the motor, and then to projected velocity for the ROV. Below are the results of the simulations:
The maximum thrust in the forward direction was 1.2 kgF per motor, the maximum in the reverse direction was 0.2 kgF.
ConclusionsThe forward thrust was able to meet the 1 - 2 kgF target range defined for this test. The reverse was not, however this is likely due to a directional bias in the shape of the propeller. This was deemed acceptable because the simulations show that the ROV is able to exceed the minimum velocity specification of 0.1 m/s in the worst case scenario.
T4: Tether Data Latency TestThe goal of this test is to make sure that one-way transit time for data packets of various different payload sizes is within an acceptable margin of 2 ms in these cases. The value of 2 ms was chosen as an ideal target as this is the normal data transit time on a standard LAN.
The test procedure can be seen in the flowchart below.
Note the the above procedure outlined within the flowchart assumes that the following hardware setup is present at the testing site.
The ping command reference within the test procedure flowchart is given as: ping -s <packet_size_in_bytes> <eth0 IP of ROV Rpi>. Again, this assumes that the ping command is being issued from the basestation raspberry pi, as referenced in the test procedure flowchart.
A table of the resulting total and one-way transit times for various different data payload sizes can be seen in the table below.
ConclusionsFrom the test results, it can be seen that all one-way transit times obtained from the test procedure are within an acceptable margin of the required 2 ms transit time. This suggests that latency of data sent through the tether and accompanying hardware is similar to that of a standard LAN. Thus, software designed to operate within these networking contraints (such as ROS components) should behave as expected using the ROV and Basestation network link.
T24: Waterproof TestingThe goal of this test is to determine how the 3D printed shell withstands an aquatic environment.
ProcedureFour 1-inch blocks were printed for ASA and PET-G. These blocks were then coated in spar urethane and west system. The two remaining were used for control and as a spare.
1. Coat blocks in corresponding material. Wait for them to properly cure.
2. Completely submerge blocks in water
3. Remove at set points and weigh.
ConclusionBoth materials gained negligible weight when submerged for 24 hours. However, research indicates that long term exposure and/or repeated exposure may lead to degredation in ASA. As a result, the team has conlcuded that west system epoxy will be a decent solution to increase the product durability. It is easy to apply and is resistant to physical damage.
Risk and Problem TrackingAs the project progresses, most risks are mitigated. However, some risks can eventually become problems for which a plan must be enacted to track and deal with them. Below are updated versions of our risk and problem tracking documents. While it was expected that the overall risk would decrease as the project progresses, we have encountered a flatline. This is partially due to the interconnected nature of the project subsystems. Many risks are only mitigated by a combination of subsystems.
Functional Demo MaterialsInclude links to:
Plans for next phase
As a team, we need to have the ROV assembled, and our ER tests complete, including putting this in some controlled underwater environment. We also need to progress in the writing of the paper and creation of the poster. Breaking this up with Spring Break, the electrical components will be prepared for software integration, and the exterior of the ROV will be completed, by Spring Break. After that point, a full system assembly will take place, and the remaining tests will be completed.
To keep track of each individual's responsibilities, we will be using the schedule posted above, as well as frequent communication throughout the phase to ensure all aspects of the required work are being completed.