/public/

Detailed Design

Table of Contents 1 Team Vision for Detailed Design Phase 2 Prototyping, Engineering Analysis, Simulation 2.1 Shell Prototype 2.1.1 Construction 2.1.2 Testing 3 Drawings, Schematics, Flow Charts, Simulations 3.0.1 Mechanical Detailed Design 3.0.2 Electrical Detailed Design 3.0.2.1 Main Board 3.0.2.2 Lights 3.0.3 Software Detailed Design 3.0.3.1 Base Station Domain Software 3.0.3.1.1 Base Station Domain Software Subsystems 3.0.3.2 ROV Domain Software 3.0.3.2.1 ROV Domain Software Subsystems 3.0.3.3 HUD Interface 3.0.3.4 SRS Documentation 4 Bill of Material (BOM) 5 Test Plans 6 Risk Assessment 7 Design Review Materials 8 Plans for next phase

Team Vision for Detailed Design Phase

The end goal for this phase is to generate a plan, covering design and execution, for MSD II. The major team objectives towards completing this goal are to reduce budget overages, and ensure that all design specifications are validated through a series of testing plans.

The team was able to come closer towards meeting the budget through design optimization, extraneous feature trimming, and pursuing academic discounts from vendors. A comprehensive test plan was designed to ensure that every specification will be validated in MSD II. Additional accomplishments included system prototyping and creating sub-system back-up plans for risk mitigation.

Prototyping, Engineering Analysis, Simulation

Shell Prototype

Construction

A hydrodynamic system like the ROV is often difficult to model mathematically. The process can be incredibly labor intensive, relies on empirically determined parameters, and is often case specific. A common solution is to instead use prototyping to predict the behavior of the system.

A major task for the team was to assess the stability of the shell design presented in the preliminary design phase. To do this, the team designed a full-size prototype for use in the College of Applied Science and Technology (CAST) flow chamber. This involved activities that will also prove useful in MSD II such as resource procurement and gaining access to test facilities. The components used were donated by Dr. Cormier, RIT MSD, the RIT Machine Shop, and P20250 team members, and thus did contribute towards the budget.

The components for the prototype were 3D printed. Ideally, they were to all use ABS. In reality, the handle was printed in ABS, the fins in ASA, and the bottom braces in PLA. These materials all have similar properties with respect to the tests being conducted, and didn't make a significant difference. The waterproof chamber was replaced by a 4" diameter schedule 40 PVC pipe, which has similar dimensions (to less than a 1/16") as the actual acrylic test chamber purchased from Blue Robotics. The end caps were fabricated out of black PVC. One was sealed on using PVC cement and the other was fit with a gasket made of caulk and Vaseline and fastened with rubber bands. This allowed for a removable entrance to the ROV chamber which made it possible to adjust ROV mass during buoyancy testing.

This prototype was serviceable for initial testing, but still had a few flaws. Most notably, it lacked waterproofing on the 3D printed parts, which limited the amount of submerged time to work with. There were also extraneous features such as bolts and rubber bands that altered its profile slightly, which could effect drag in the flow chamber.

Testing

Leveraging the CAST flow chamber, the protoype was able to be used for two preliminary tests before the detailed design review. First, the ROV was made neutrally buoyant by adding gravel to the waterproof chamber until it remained stationary in the water. This was difficult because the ROV had limited time in the water due to the lack of 3D printed waterproofing and the precision required to reach an effectively neutrally buoyant state. However, the team was able to determine that an additional 7.07 lbs was needed to make the 5.14 lb ROV shell neutrally buoyant. This is important becuase it provides validitiy to a preliminary calculation that determined we would need around 11 to 12 lbs of total ROV mass depending on the 3D printing fill percentage.

The ROV prototype was also used to conduct a rought stability analysis on the ROV. Stability is defined as the ROV's ability to return to its neutral state given a perturbation. Functionally, the ROV needs to be able to maintain its heading so that the user can reliably move in a desired direction.

To test this, the prototype was attached to a vertical line through an eye-hook drilled into the front centered on the centroid. This allows the flow chamber to simulate motion without adding a significant stablizing force from a teather. Due to flaws in the prototype such as a lack of waterproofing and an inaccurate mass distribution, the tests in the flow chamber were largely inconclusive from a stability perspective. However, this was partially expected due to the expediated nature of the tests. The main objective of assessing neutral buoyancy was achieved.

Flow Chamber Demonstration

Above is a link to a video of the flow chamber at 0.52 ft/s, which demonstrates the test set-up. This video shows the prototype slowly approaching the bottom of the chamber, which is due to a change in weight from water absorption by the 3D printed parts. Other trials showed a variety of results, but due to the inaccurate mass distribution, the tests were unable to demonstrate how mass distribution can be used as a stability control mechanism. As such, a contigency plan was adoped that would implement pitch control through a linear mass acutuator that would move the battery and thus change the center of mass.

Further testing will be required early in MSD II to assess feasibility, but the work done in this experiment will prove valuable as it set in place the resources to conduct such a test and provided key information that will allow us to improve the experiment for prior iterations.

Drawings, Schematics, Flow Charts, Simulations

The detailed design for the ROV is split into three main categories, Mechanical Hardware, Electrical Hardware, and Software. All subsystems are fullfiled by a component in one of these categories.

Mechanical Detailed Design

The primary components of the mechanical design are the ROV shell and the internal electrical mounting board. The shell integrates most of the mechanical subsystems, functioning as a means of protecting the electrical components from the environment, holding the motors in the correct orientation, and providing stability for the ROV as it moves through the water. The primary method of generating these components will be 3D printing in ABS, as such they are stored in a CAD file. The files were originally generated using the CAD program CREO.

Link to the mechanical CAD zip file.

Electrical Detailed Design

Main Board

The Main Board of our project is essentially a breakout board, connecting the Teensy 3.2 microcontroller to all of its associated sensors. The only onboard components are the Teensy, the IMU, the voltage regulator, output connectors, two resistors, and coupling capacitors. The two resistors are pull-up resistors for the Clock and Data lines for I2C communication between the Teensy and the Pressure/Temperature sensor. The majority of sensing is done through PWM signalling, requiring the use of a coupling capacitor to handle noise. A capacitor must be placed at the beginning and end of each PWM line. There are five PWM signals used: two for the motor controller and three to control the lighting system. As a result, ten coupling capacitors are needed. However there is also an array of output pins denoted by J1 that contains extra PWM and I2C pins that can be used in future expansions, such as the addition of a sonar sensor. That way, there are no hardware changes required. In regards to the Main PCB, due to size constraints of the housing used for the ROV, all of the taller components had to be placed in the center to avoid hitting the walls. There is also a large ground plane on the top and bottom in order to disperse any heat, specifically caused by the voltage regulator converting the 15V input to the 5V output used to control the various input voltages of the board.

Lights

For the purpose of saving money, the light system is going to be designed instead of bought. There will be three rows of six LEDs in parallel, so that if one LED breaks, only its respective row fails and there is still lighting. This is taken one step further in the PCB design, where the LEDs are staggered in their rows. Therefore, there is an LED from Row 1 followed by and LED from Row 2, then an LED from Row 3, and the pattern repeats around the board. That way, if one of the LED Rows fail, there is still universal lighting around the camera. Each LED row is controlled by its own optocoupler, where the output current is controlled by a PWM signal. This means that by changing the frequency of the PWM signal, the resulting brightness of the LEDs can be controlled. The original thought was to have all three optocoupler output lines connect to each other so that all three control all of the LEDs, but this was deemed to be potentially dangerous at the high currents desired. As one of the optocouplers change states, the resulting current could feed back to the others and damage them, potentially breaking the optocouplers. In the chosen design, the optocouplers are much safer and the only potential circuit breaking occurs in the LEDs, which are far cheaper parts to replace. The footprint of each LED contains three vias to disperse heat from the top of the board to the bottom of the board, emphasized by there being two large ground planes on the top and bottom to disperse that heat evenly. There will be no ground plane under the camera so that the generated heat does not affect the quality of the images taken (potentially causing sensor blooming since the CCD needs to be kept cool). The camera itself will be mounted to the board through mounting holes, with a larger hole in the bottom corner for a cable to come through and connect to the camera.

Software Detailed Design

Base Station Domain Software

The base station domain software contains all software relevant for maintaining a connection with the ROV via the tether. Also handles creating and updating the HUD screen as well as the archival and retrieval of past mission data. The base station software domain uses robot operating system (ROS) for passing messages between the various software subsystems via the use of rostopics.

Base Station Domain Software Subsystems

The various software subsystems seen in the figure above can be seen in the figures below in greater detail.

ROV Domain Software

The ROV Software Domain contains all software relevant for maintaining a connection with the base station via the tether interface, handeling the collection and tranmssion of mission data, handeling the control of ROV interaction with the enviornment based on user input. The ROV software domain makes use of robot operating system (ROS) for passing messages between the various software subsystems via the use of rostopics.

ROV Domain Software Subsystems

The various software subsystems seen in the figure above can be seen in the figures below in greater detail.

Describe your design in enough detail for someone else to recreate it. Have you included assembly plans and user manuals? Your team may want to create separate nodes and directories within the Detailed Design Documents directory for CAD, schematics, or software

HUD Interface

This section outlines mockups for the overall HUD interface. The HUD interface will be split into three components those being the main control page, a controller command reference page, and a data export page. The overall HUD Interface will be implemented as a react application employing responsive and state full design paradigms. The three corresponding pages can be seen below.

SRS Documentation

A SRS document was generated to serve as the compendium of the software design plan to be implemented in MSDII. The links to the rendered pdf and latex source code can be seen below:

• Rendered PDF Document: SRS Document
• Latex Source Code Link: https://github.com/sherrardTr4129/RIT-MSD-Finger-Lakes-ROV

Bill of Material (BOM)

The Bill of Materials was further developed this phase with the intention of flushing out every individual component required for the final design and eliminating "fluff budget" items. This makes the BOM a much more accurately detailed and useful item for purchasing. While the less definitive "fluffy" BOM line items were removed, it is still the intention that all of the remaining budget should go towards un-predicted costs in prototyping, rework and repurchasing.

The full Bill of Materials is available for review here:Detailed Design Documents/Bill of Materials.xlsx

Test Plans

Test plans are a series of plans set in place to make sure that each engineering requirement, or spec, is satisfied. It is important to consider the method of testing before construction begins to ensure that the specs are testable, and that the design will allow for convenient testing of each spec. All specs are either tested in a plan, or are guaranteed by a component purchased in the bill of materials. All of the test plans are kept in a single excel document which allows for easy navigation, which is linked here. Below are snapshots of the catalog and a selected few test plans. Visit the live document to visit any plans in the catalog that are not detailed in a snapshot.

Live excel document.

Live PDF document

Risk Assessment

Keeping track of risk as the project progresses is critical to ensure that it the project is trending in the right direction. Last phase, the risk was projected to increase slightly, when in fact it actually decreased. This is a good sign, because it indicates that more issues have been solved than were uncovered as the design progressed from its preliminary phase to its detailed phase. The risks are projected to decrease further in phase 5 of MSD II as testing begins and allows the team to better understand the performance of the system in the real world.

As the design is finalized, the total risk to the project has been driven downward. As the design progresses, some risks can be limited through safer design decisions while others have been eliminated all together. Additionally, plans have begun to be put in place to handle certain risks in the event that they occur, which reduces there severity. An example would be ROV stability, which has pitch control through a linear actuator as a back-up plan to passive stability through mass distribution. Another example of a risk reduction is eliminating the need for a sonar senor. While this may increase the likelihood of impact with the bottom, it reduces the risk of running over budget and the need to power and waterproof such a sensor, so there is a net risk reduction.

A link to the live document.

Design Review Materials

links to:

• Pre Read
• Presentation

Plans for next phase

Below is a rough outline for the team-level plan for MSD II. This will be used to ensure that testing and fabrication are on track to deliver a working ROV, a technical paper, a poster, and an Imagine RIT poster by the end of the 2195 semester.

Link to detailed personal commitments for phase 5.

---

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation