P20250: Finger Lakes Explorer ROV
/public/

Problem Definition

Table of Contents

Team Vision for Problem Definition Phase

Our team's goal for this phase was to prepare for system and sub-system design in future phases. This included interfacing with the customer to develop a set of customer requirements, and then defining a set of engineering requirements in compliance with those of the customer. Functions of these will be utilized in the design of system and subsystems in the next phase.

Everything that needed to be accomplished this phase was achieved within the desired time frame. These objectives were met by analyzing the Project Readiness Package for customer and engineering requirements, verifying them and receiving more from an interview with the customer, and creating a list of priorities and milestones to reach within this semester. In addition to this, we assessed via DISC and established a team dynamic, as well as assigned roles and a project manager in Lainey Celeste.

Project Summary

Problem Statement: Deliver a Remote Operated Vehicle, operable by a single user, for recreational underwater exploration in the Finger Lakes of Western New York. See the problem summary for additional information.

Primary Stakeholder: Dr. Jason Kolodziej -- Rochester Institute of Technology, Department of Mechanical Engineering

Additional Stakeholder Information

Use Cases

ROV Example Use Case

ROV Example Use Case

Project Goals and Key Deliverables

The following deliverables are required by the end of MSD:
  1. All detailed design documents (analysis, drawings, schematics, BOM, etc.)
  2. A working prototype, capable of being demonstrated on Conesus Lake to our customer
  3. A technical paper
  4. A poster and a presentation to be made to our customer, RIT faculty, and the public

Customer Requirements (Needs)

Purpose

Decompose the Problem Statement into functions of elements needed to satisfy the customer. The scale used to evaluate importance ranges from 1 - 5. For example, an importance of 1 denotes low importance or priority, 3 a medium priority, and 5 a critical project requirement.
Customer Requirements

Customer Requirements

A link to the live document may be found here.

Engineering Requirements (Metrics & Specifications)

Purpose

Create a contract between the engineer and the customer where indisputable satisfaction of the engineering requirements equates to customer satisfaction
Engineering Requirements

Engineering Requirements

  1. References:

https://edge.rit.edu/edge/PTemplate/public/Establish%20Engineering%20Requirements

Constraints

System level factors that limit design space.
Constraint Restriction
Volume 2x2x2 feet
Weight Easily handled by one user
Range Limited to length of the tether
Power Limited to batteries either on board or on launch platform
Budget $1500
Weather Only usable when there is adequate weather and water conditions

Exclusions

Factors regarding the expectations placed on the customer at the conclusion of the project, that the MSD team will not be responsible for.
Exclusion Comments
Maintenance Owner is responsible for system maintenance after final transfer
Additional Materials Storage / transportation materials will not be provided. In the event the control terminal is a non-dedicated device (i.e. Laptop), such device shall not be provided by the team
Usage Intended for freshwater usage only
Liability RIT is not liable for any injuries that occur from ROV use

House of Quality

Purpose

  1. Confirm that satisfaction of the Engineering Requirements implies that all of the Customer Requirements are met.
  2. Facilitate design trade off decisions
House of Quality Relation Matrix

House of Quality Relation Matrix

The above is a screenshot of the House of Quality involving our Customer and Engineering Requirements. The full document can be viewed here.

Team Members

From left to right: Joe Mantione, Scott Couwenhoven, Scott Mann, Trevor Sherrard, Harrison Keats, Lainey Celeste

From left to right: Joe Mantione, Scott Couwenhoven, Scott Mann, Trevor Sherrard, Harrison Keats, Lainey Celeste

Team Values and Norms

Team Values and Norms dictate an agreed upon code of conduct for all team members. Failure to comply with team norms will first prompt a verbal warning, followed by a team meeting to discuss and correct the issue. Guide intervention may be sought if prior methods fail to resolve the issue.

Team Values and Norms: An Agreed Upon Code of Conduct

Team Values and Norms: An Agreed Upon Code of Conduct

Design Review Materials

Please reference our problem definition design review document below:

Plans for next phase

As shown in the Project Plan below, our team has identified the key elements necessary to have a completed detailed design by the end of MSD1.

Project Plan for MSD1

Project Plan for MSD1

Over the next three weeks, our team will do preliminary research and a functional analysis to generate a list of alternatives for our design. Using these alternatives, a hybrid design will be established, leading to our high-level system design. In conjunction, a feasibility analysis will help establish any areas in our design that might require more attention. For individual team allocations, see the Gantt Chart for Phase 2, below.

Gantt Chart for Phase 2: System Design

Gantt Chart for Phase 2: System Design


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