ENGR 100-600 | University of Michigan

ROV Deliverables

This document describes all of the assignments that are directly connected to the ROV project. If you have any questions, about anything at all, please post them to Piazza or ask them in class. We want this document to be as clear as possible!

All of these assignments serve two purposes. There’s an educational purpose, since this is a course in which you are supposed to be learning stuff about engineering. There’s also a real-world purpose, since we’re also trying to frame this course as an experience that you might have at an internship in real life. We hope that you find value in both purposes for each assignment.

General Quality Checks for Deliverables

We expect that the overall quality of your work will improve as we go through the semester: that’s what all this practice is for! However, there are some basic quality checks that we’re looking for in each one of your deliverables. Follow the quality checks listed below to help you (and your team!) produce excellent technical communication.

Quality of Presentations

At a minimum, we expect that every presentation will meet these quality checks:

• Title slide is present with all team members’ names spelled correctly
• Team members are introduced by name
• Slide design does not detract from the information on the slides
• Organization of information aligns with the expectations of the presentation
• Figures
  • Figures are clear / minimum size of 0.5 x size of slide
  • Labels are large and easy to read from across the room
  • Figures serve to convey specific information and are not there just to take up space
• Tables
  • Tables are clear / not too busy
  • Tables are used to convey more than one line of data but no more than ~10 lines of data
  • Data is able to be read from across the room
• General Styling
  • Headings are used appropriately
  • Fonts are consistent and thoughtfully to help viewers understand information
  • Spacing between items on slides is balanced (items aren’t too close together or too far apart)
  • Equations are rendered correctly using an equation plug-in or LaTeX/MathJax/etc program

Quality of Written Reports

At a minimum, we expect that every written report will meet these quality checks:

• Correct template is used
• Sections are complete and correct
• Figures
  • Figures are introduced in text first
  • Figures are numbered
  • Figures have detailed captions
  • Figures are clear / minimum size of 0.6 x page width
• Tables
  • Tables are introduced in text first
  • Tables are numbered
  • Tables have detailed captions
  • Tables are clear / not too busy / separated visually from text before/after
• General Styling
  • Headings are used appropriately
  • Headings have text between them (no headings back to back)
  • Fonts are consistent, preferably a serif font (e.g. Cambria or Times New Roman)
  • Spacing is consistent and correct
  • Equations are numbered and centered

 

---

Individual Design Proposal

Purpose of the Assignment

This assignment’s educational purpose is to give you a chance to practice interpreting a genre (something called a quad chart) and with writing an informal report (in this case a memo). You may or may not ever create these specific types of documents once you leave U-M, and that’s okay. We just need technical communication genres that have specific characteristics. For the memo, we wanted a documentation type that has the basic components of an informal report:

• Who the report is to and who it is from
• Why you’re sending the report
• A summary of what’s in the report
• The report itself, including clear and concise text, good visuals with labels and descriptive captions, and documentation of your research.

This assignment’s real-world purpose is to give everyone on your forthcoming ROV team a chance to think about and document their ideas for the ROV. Brainstorming ideas, sometimes called idea generation, is a crucial part of design, but not everyone thinks of ideas “in the moment”. Sometimes those good ideas come to you later on… on a walk, or in the shower, or thinking about something else entirely. Some people can quickly draw a diagram of their idea or explain it clearly in words as they are coming up with the idea, but that’s not most people. Most people need at least a little bit of time to figure out how to convey the idea they have in their head to other people so that the other people can clearly understand their idea.

This individual design proposal gives everyone a chance to think about an ROV design and to have some time to document that design in text, bullet points, diagrams, and whatever else you can think of. This way, when your ROV team meets for the first time, you already have many interesting starting points on your ROV design, and everyone has something to talk about!

Background

GFL has contracted with LakePowerGen for a wireless, easily transportable ROV for rapid deployment in offshore situations. As you know, GFL has the resources to produce an outstanding prototype, including in-lab materials, a testing facility, and machines for customizing parts; however, time is short for a complex project like this. Therefore, we are requesting individuals to propose ROV designs that a team could build and test (and present to LakePowerGen). The goal is to excel in this lucrative contract, though establishing a relationship with this company and breaking into the offshore wind farm industry with an ROV inspection system are also important.

You will submit an individual ROV design proposal, including sketches of the design and spelling out the rationale behind your design decisions, to your Division Head. You will want to base your design on the research you conduct so that your Division Head knows that you know what you’re talking about. You should know about ROVs “in the real world” and how your design will be similar and/or different, and why.

Requirements

This individual design proposal will be submitted using the memo format.

Here are the requirements for the individual desing proposal memo:

• Frontmatter
  • GFL name, logo, address
  • People information
    • To: your IA
    • From: you
    • Subject: description of your ROV proposal
    • Date: date submitted
    • Distr: Laura, Robin, Lee
  • Foreword
    • Problem statement
    • Task(s) you were asked to do
    • Purpose of this document
  • Summary
    • One sentence describing your overall goals for your ROV design
    • Describe what was found/done for each task listed in the foreword
    • Any other high level information you think is critical to relay
• Proposed ROV Design
  • Brief problem overview / context for why you’re designing an ROV
  • Brief overview of vehicle design
    • 1-2 sentences describing the goals for the design (maneuverability, transportability, sustainability, durability, aesthetic qualities, ease of building,…) and argue for respective importance.
    • Figure of the whole ROV vehicle including labels for:
      • Frame, including tether attachment point on frame
      • Thrusters
      • Payload canisters (electronics canister and battery canister)
      • Camera
      • Source(s) of buoyancy and or weight
  • Vehicle Subsystems
    • Frame - describe rationale, including tether attachment
    • Thruster placement - describe rationale
    • Payload canisters - describe rationale
    • Camera placement - describe rationale
    • Buoyancy and weight - describe rationale, must relate back to hydrostatic stability
  • Controller
    • 1-2 sentences describing the goals for the design (maneuverability, sustainability, durability, aesthetic qualities, ease of building, ease of use…) and argue for respective importance.
    • Figure of the whole controller including labels for:
      • All switches and buttons and what thrusters they control or what motion they are intended to create (e.g. surge, pitch)
      • Video display
      • Antenna
      • LCD screen
    • Rationale for controller design
  • Custom Part
    • 1-2 sentences describing the purpose of the custom part
    • Figure of the whole custom part including labels for the part and the vehicle or controller parts around it
    • Rationale for custom part and design
  • Potential Drawbacks
    • Paragraph describing the limitations inherent in this design and any foreseen challenges in building the vehicle and controller
• Conclusions
  • Summarize your work
  • Include any recommendations that you think should be made
  • Include wrap up sentence with email contact
• Appendix
  • Quad chart
    • MUST use template; cannot resize boxes
      • Across the top: Short description of your ROV, your name and title, date of submission, logo (optional)
      • Top left quadrant: Picture of proposed ROV with labels
      • Bottom left quadrant: Timeline of major milestones for ROV project
      • Upper right quadrant: Objective description of ROV (in bulleted form)
      • Bottom right quadrant: Rationale for your design (in bulleted form, cite sources as appropriate)

This might look like a LOT of stuff you have to write: we promise it’s not actually that bad! The absolute best thing about technical communication is that it almost writes itself! Once you have a really good outline, like the one above, you just need to go and “fill in all the blanks”. If you look at the template for the Individual Design Proposal, you’ll see that a lot of the set up work has been done for you. We want you to focus on creating your design, making some really good visuals to show your design, and writing down your justification for your design. And, of course, in practicing using a template!

Advice From Your Instructors

The overall purpose of the individual proposal is to clearly present a well-thought-out idea for an ROV, to your “boss” and team, for feedback and consideration. To do a good job with that, you need to do a few things:

• You should start by considering the problem carefully. Do you understand what the client wants to use this for, and why? What is the client’s actual need? How will the ROV be used, and what does this mean about it (size, speed, maneuvering, etc. needs). Read through the Statement of Work – multiple times – and ask questions of your instructors.

• You need to have a clear prototype concept in your mind, and you have to have considered it deeply. You shouldn’t focus on just a subsystem. You should be able to justify every single decision. That is – why are your thrusters where they are, rather than 3 inches forward or backward? Basically, what change in design does it enable? You should have thought about how the ROV will be driven/ what will be required of a driver.

• You need to describe the design itself well. Because you’re describing a physical prototype, you should probably include a few figures. Laura does a really good job with this, and the Technical Content and ROV Background Info documents are good examples. If you talk about a nose cone, we should be able to see it in your images – maybe even in its own blown up image in that section. We should understand not just that you’re proposing to include one, but the image should give us a sense of its size, and you should be able to address how you think this choice will affect the ROV’s coefficient of drag (basically, justify the decision to include it).

• You need to include clear visuals– and that’s not trivial. Some of you may choose to CAD your proposal, but that’s not necessary. If you don’t know CAD, don’t try to learn it for this assignment. That said – expect that you need to put in the same time that a teammate who does CAD the picture does. Creating a good, clear visual is not as simple as sketching something on looseleaf, taking a picture, and inserting it into the paper. You should be careful about size of items, doing things to scale when possible and describing in a caption when it isn’t. You should add labels, so that each part is clear to your readers. You should make sure visuals are clear: doing a “cartoon” in PowerPoint or writing in black marker on plain white paper are both much better than pencil on lined paper.

• You need to use those visuals to make your design plan clear. You should introduce all figures, and you should include numbers and descriptive captions so that anyone skimming through the document would understand what they should see in each image. You should include images of subsystems in addition to the entire system sketch. For example – to show us a nose cone, you might focus in on that part of the design, or you might make other parts partly transparent to show it better.

• You need to use the memo format correctly and effectively. Remember that an audience might read just the front page. The Foreword needs to remind them of why you’re creating a prototype proposal – and it’s not really because LakePowerGen needs this thing, it’s because your more immediate supervisor wanted this at the concept generation stage. You need to summarize the proposal effectively as well (which means you need to spell out your design and a justification of it). It’s common to refer to a figure in this section.

• Put the visual that includes your whole ROV near the beginning of the memo, before you start talking about any details. This way, your reader knows what you are talking about!

Submission

Please submit your individual proposal (no more than five pages of design description and rationale, but including a quad chart as an appendix) as a memo addressed to your Division Head (Lyn, Jack, Ian, or Molly) in .pdf format. We expect that your entire file will be about 6-7 pages long:

• 1 page – memo frontmatter
• 4-5 pages – design description and rationale (including figures)
• 1 page – quad chart in an appendix

You will present your plan to your peer team in class, so you have multiple audiences you should consider as you write this proposal.

 

---

Preliminary Design Review

Purpose of the Assignment

This assignment’s educational purpose is to serve as the first thing your team creates together so that your team has a reason to meet early in the project and start to communicate with each other. It’s also the beginning of documenting your team’s work. Throughout the semester, you will see how each assignment “evolves” from one level to the next.

This assignment’s real-world purpose is to mimic the type of weekly check-in meeting that a team would have with their project manager/supervisor. A good project manager gives a team time and space to develop their ideas and, you know, actually get work done. But a good project manager also checks in with their teams on a regular basis, both to stay up-to-date on the progress of the project and to give the team a chance to get advice and feedback on their ideas, issues, and plans.

Background

GFL has requested that each of their internal design teams create a prototype ROV for LakePowerGen. This is an informal, early stage meeting where you and your team can present the two or three designs that you are considering for your ROV. It is also an opportunity for you to meet with GFL’s partners to ask questions and get feedback on your team’s ideas for your ROV.

Requirements

This preliminary design review is a very informal presentation with an extensive question and answer period. Here are the requirements for the PDR presentation:

Presentation Duration: 5-6 minutes

• Title slide with team name and team members’ names
• 2-3 slides of preliminary ROV designs
  • One design per slide
  • Lots of labels to explain the design
  • Designs CANNOT be someone’s design from their Individual Design Proposal
• Decision matrix that highlights 4-10 objectives/constraints and weights them, along with scores for the 2+ designs
  • Be able to justify objectives/constraints and weighting, and reasonable scores/ explanations of scores assigned to designs
• List of “open questions” on which you hope to receive feedback

Advice From Your Instructors

We’re not looking for your team to present the “best” designs from your various individual design proposals; that’s not the point of this project. We expect that your team will have looked at all the different individually proposed designs, and any ideas that people have thought of in the meantime, and come up with 2-3 new designs that seem like they will be successful in completing the tasks required for the riser inspection simulation.

This meeting will be most useful to you if you come with specific questions about the designs you are considering. We will do our best to give helpful feedback, but now is your chance to ask us exactly what you want to know!

Submission

There is no formal submission of any materials for this meeting. Your team should be ready with your slides before the start of your lab so that you are ready to have a productive meeting with the instructors.

 

---

Detailed Design Review

Purpose of the Assignment

This assignment’s educational purpose is to give your team the opportunity to put together your first true presentation that documents your ROV design. We want to give you lots of practice with creating presentations because this is a very common genre in engineering, and let’s face it, there are a lot of bad presentations out there. We don’t want that to be you!

This assignment’s real-world purpose is pretty much what the name of the assignment is. Any project will have many internal design reviews. This detailed design review is the time when your team presents a complete design proposal for feedback. By complete we don’t mean the ROV is actually done. Complete in this sense means that your team has a complete plan: you’ve come to a consensus on the entire ROV design, including all subsystems, and the general timeline of the project’s ultimate completion. Now you’re ready to get feedback on this plan: Does the design seem feasible? Does the timeline seem reasonable? Have you forgotten anything? It’s a lot easier to make adjustments to your design and timeline now than it will be later in the project timeline.

Background

The standard GFL project progression includes a Detailed Design Review (DDR) once a team comes to consensus on their design. This DDR provides the team with the opportunity to present their design to one or more experienced engineers, designers, project managers, fabricators, etc. to get initial feedback on their proposed design. The team presents their design in enough detail that their audience can provide useful advice on the challenging parts of the design and/or any design considerations that the team hasn’t yet addressed. The DDR is meant to help the team strengthen their design and should result in a more efficient, robust, and cost effective prototype ROV.

Requirements

This detailed design review is a formal presentation given to a varied audience. This presentation introduces your team’s ROV design for the first time. Here are the requirements for the DDR presentation:

Presentation Duration: 15 minutes

• Title slide with team name and team members’ names
• Introduction
  • Problem overview / context for why you’re designing an ROV
• Prototype ROV Overview
  • Design goals/rationale
    • Highlight “risky”/interesting choices you’re making
  • Vehicle
    • Picture of up-to-date 3D model of vehicle (or picture, if completed); must include labels for:
      • Overall dimensions
      • Frame
      • Payload canisters
      • Camera
      • Thrusters
      • Buoyancy material (if used)
      • Ballast material (if used)
      • Tether attachment to frame
    • Description of vehicle subsystems
      • Include pictures of 3D model as needed
  • Controller
    • Picture of up-to-date 3D model of controller (or picture, if completed); must include labels for:
      • Toggle switches/push buttons
      • Antenna
      • Video display
      • LCD display
      • All other parts
    • Description of controller
  • Custom Part
    • Description of problem/challenge the part solves and/or the novel approach the part brings
    • Picture of up-to-date 3D model of custom part (or picture, if completed); must include labels for the parts of the ROV system that the part interacts with (e.g. mounting points)
  • Cost
    • State anticipated total cost
    • Chart showing simplified cost breakdown
• Hydrostatic Stability Analysis
  • CG/CB from OnShape
    • Must be measured from the (back, right, bottom) corner of ROV
    • Figure showing location of centers on CAD model
• Performance Prediction
  • Surge
    • Principal particulars estimation/calculation, including justification for:
      • Estimated $C_D$, including rationale
      • Estimated cross-sectional area, $A$, including rationale
      • Estimated velocity, $V$, using estimated $C_D$ and assumed thrust, $T$; assume each thruster provides 5.56 N of thrust in the “on” position and 4.45 N of thrust in the “reverse” position
      • Brake power, $P_B$
      • Predicted efficiency, $\eta$, based on above items
  • Heave
    • Principal particulars estimation/calculation, including justification for:
      • Estimated $C_D$, including rationale
      • Estimated cross-sectional area, $A$, including rationale
      • Estimated velocity, $V$, using estimated $C_D$ and assumed thrust, $T$; assume each thruster provides 5.56 N of thrust in the “on” position and 4.45 N of thrust in the “reverse” position
      • Brake power, $P_B$
      • Predicted efficiency, $\eta$, based on above items
  • Anticipated hydrodynamic stability and maneuverability
• Confidences and concerns for the design of this ROV system
  • Include questions that you specifically want feedback from your audience on, especially for any “risky” ideas that you want to try
• Conclusions and Recommendations

Advice From Your Instructors

This presentation is meant to encourage an honest discussion with the experts that you talk to during the Detailed Design Review. Therefore, you want to include as much detail as you can on your ROV design. If there are still a few small, open questions, that’s okay! Just make sure that you make it obvious that those decisions will be made in, say, the next week.

The hard part about having an honest discussion about your design is that people will ask you direct questions about your design: Why did you put the thruster here instead of here? Why didn’t you put the payload here? That coefficient of drag doesn’t seem right… These types of questions can (and often do) feel like personal attacks, even though they are not intended to be! You’ve spent a lot of time and effort coming up with this ROV design, and when we spend a lot of time on something, we really want everyone to tell us how wonderful and amazing and perfect that thing is. But we also need to make sure this design is the best that it can be, and no design is perfect in the beginning.

To prepare yourself for both the presentation and the Q&A session afterwards, remind yourself that the goal is to have a better, more feasible ROV design on the other side of this Detailed Design Review. Keep these things in mind:

• You know more about your design than your reviewers do. Be able to talk through your design rationale to support your decisions. Your reviewer might have just misunderstood you!
• But keep an open mind: Your reviewers may have thought of something that you didn’t.
• Try to set yourself, as a person, aside from your ROV design. This can be hard to do (trust us, we know!!), but it really helps you to be in a more receptive state of mind for feedback.
• Remember that you want your reviewers to “find holes in your plan” – meaning, if there’s something not good about your ROV or your plan to build the ROV, it is much better to know now when it is easier to fix!
• You’re looking for constructive feedback from your reviewers. Have specific questions ready for them (like you did with the Preliminary Design Review with your instructors) so that you can guide your reviewer towards giving you the most useful feedback. This also helps set your expectations with the reviewers about the kinds of feedback that you are looking for. Otherwise, they might start commenting on things that you don’t care about or have no control over.
• You can also call attention to the concerns your team has or decisions your team feels conflicted about. This is an opportunity to get expert opinions on what you are doing, and your team can use this additional information to either make a new plan or to feel more assured about a choice going forward.
• Make sure to leave at least 1-2 minutes of Q&A time to ask your reviewer about anything else they want to bring up, though! Remember that they may have spotted something problematic that you don’t know about yet.
• Don’t be afraid to push back on the reviewers if you need to. You know the timeline for this project (it’s only a few weeks, really). If they want you to do something that you don’t think you have time for, bring this up and ask them whether they still recommend doing the thing even though the timeline is short.

Your design reviewers are not mean people! We promise. But they may get excited. And high emotions like excitement may come off strangely sometimes. If you’re not sure what your reviewers are talking, ask them questions! They are all very happy to be coming to class and seeing what you have planned!

Submission

Your team should submit a .pdf copy of your DDR slides to Canvas. Only one person needs to submit the .pdf, but everyone is responsible for making sure that the file is submitted on time! After someone submits the file, everyone else should make sure that the file uploaded correctly. You will receive feedback during the DDR itself, but you will also get feedback in Canvas about your ROV design and on the quality of the presentation slides themselves.

 

---

Critical Design Review: Presentation

Purpose of the Assignment

This assignment’s educational purpose is for your team to practice giving a presentation in which you are beginning to be the expert: this is your design and you know it best. It’s time to describe where you’re at in building the ROV and that you are going to be ready for the performance review.

This assignment’s real-world purpose is somewhat similar. You will, at times, be required to give a formal presentation to a group of people as part of various types of “update” meetings: quarterly reviews, end-of-the-month meetings, critical design reviews, and so on. A Critical Design Review (CDR) is real thing. Different companies may interpret the CDR in slightly different ways, but the focus is always about presenting the final version of the design and showing that it can be completed to the required specifications, on time, and on budget.

Background

The standard GFL project progression includes a Critical Design Review (CDR) before a team is allowed to continue with the project. The CDR is partly to keep the design team on track for successful completion – we all do better when we have some internal deadlines before the Real Actual Deadline. The CDR is also partly to protect GFL’s investment – if a team is sufficiently behind schedule, then it would make sense for the GFL partners to step in at that point and either redirect the team’s resources to something else or to perhaps take more extreme measures. The CDR presentation is your team’s chance to present your work thus far to your supervisors and to talk with them in-person.

Requirements

This critical design review is a somewhat formal presentation given to your “bosses” to update them on the progress of your project. Here are the requirements for the CDR presentation:

Presentation Duration: 15 minutes

• Title slide with team name and team members’ names
• Introduction
  • Problem overview / context for why you’re designing an ROV
• Prototype ROV Overview
  • Design goals/rationale
  • Vehicle
    • Picture of up-to-date 3D model of vehicle (or picture, if completed); must include labels for:
      • Overall dimensions
      • Frame
      • Payload canisters
      • Camera
      • Thrusters
      • Buoyancy material (if used)
      • Ballast material (if used)
      • Tether attachment to frame
    • Description of vehicle subsystems
      • Include pictures and/or 3D models as needed
  • Controller
    • Picture of up-to-date 3D model of controller (or picture, if completed); must include labels for:
      • Toggle switches/push buttons
      • Antenna
      • Video display
      • LCD display
      • All other parts
    • Description of controller
  • Custom Part
    • Description of problem/challenge the part solves and/or the novel approach the part brings
    • Picture of up-to-date 3D model of custom part (or picture, if completed); must include labels for the parts of the ROV system that the part interacts with (e.g. mounting points)
  • Cost
    • State anticipated total cost
    • Chart showing simplified cost breakdown
• Hydrostatic Stability Analysis
  • CG/CB from OnShape
    • Must be measured from the (back, right, bottom) corner of ROV
    • Figure showing location of centers on CAD model
• Performance Prediction
  • Thrust measurements
  • Surge
    • Principal particulars estimation/calculation, including justification for:
      • Estimated $C_D$, including rationale
      • Estimated cross-sectional area, $A$, including rationale
      • Estimated velocity, $V$, using estimated $C_D$ and measured thrust, $T$
      • Brake power, $P_B$
      • Predicted efficiency, $\eta$, based on above items
  • Heave
    • Principal particulars estimation/calculation, including justification for:
      • Estimated $C_D$, including rationale
      • Estimated cross-sectional area, $A$, including rationale
      • Estimated velocity, $V$, using estimated $C_D$ and measured thrust, $T$
      • Brake power, $P_B$
      • Predicted efficiency, $\eta$, based on above items
  • Experimental observations of hydrodynamic stability and maneuvering, if available; otherwise, discuss anticpated maneuverability
• Construction Update
  • Pictures of components built-to-date
  • Updated project timeline
    • Include distribution of team responsibilities, including assigned leads for major tasks and deliverables
  • Confidences and concerns for system completion and testing
• Conclusions and Recommendations

Advice From Your Instructors

You should be able to evolve your slides from the DDR presentation here, but you will have a lot of updating to do! Your ROV should be nearly complete by the time of this presentation, so you should be able to have some pictures of at least some of the components (frame, controller, etc.). You should also update your 3D model so that it matches what you actually built, since you likely made some changes as you started to build your ROV.

We strongly recommend that you try to do a really good job on this presentation because it will give you a better starting point to then evolve the slides again into your final presentation, the Final Presentation to Client. Yes, apparently design review presentations are Pokémon.

Submission

Your team should submit a .pdf copy of your CDR slides to Canvas. Only one person needs to submit the .pdf, but everyone is responsible for making sure that the file is submitted on time! After someone submits the file, everyone else should make sure that the file uploaded correctly. You will receive feedback in Canvas about your CDR presentation.

 

---

Critical Design Review: Report

Purpose of the Assignment

This assignment’s educational purpose is to assess your skill in writing a collaborative, comprehensive informal report. The format of this informal report is a memo for this course, so that’s what we will use. Remember that informal does not mean incomplete! We expect that all parts of this report will be completed and polished.

This assignment’s real-world purpose is to parallel the type of internal report writing that you will do in a future job. A lot of companies, especially larger companies, require a level of reporting that isn’t quite as formal as a client-facing report (such as what you will do later in the course), but is still a well-written and complete report. This type of assignment will give you practice in this kind of technical communication.

Background

The Critical Design Review (CDR) report is a companion piece to the Critical Design Review presentation. The presentation is wonderful for its in-person interaction, but the limited amount of time per presentation means that your team will necessarily need to leave out some of details of your design and the work/testing that has been completed to date. The CDR report is where your team presents its full design in detail along with all documentation of testing, calculations, and performance predictions.

Requirements

This CDR report will be submitted using the memo format.

The CDR report template is not as detailed as the IDP template was; that’s on purpose so that you can get more experience with setting up your own outline of sections and section headers. Here are the requirements for the CDR report:

• Frontmatter
  • GFL name, logo, address
  • People information
    • To: your IA
    • From: you
    • Subject: description of your ROV proposal
    • Date: date submitted
    • Distr: Laura, Robin, Lee
  • Foreword
    • Problem statement
    • Task(s) you were asked to do
    • Purpose of this document
  • Summary
    • One sentence describing your overall goals for your ROV design
    • Describe what was found/done for each task listed in the foreword
    • Any other high level information you think is critical to relay
• Introduction
  • Problem overview / context for why you’re designing an ROV
• Prototype ROV Overview
  • Design goals/rationale
  • Vehicle
    • Picture of up-to-date 3D model of vehicle (or picture, if completed); must include labels for:
      • Overall dimensions
      • Frame
      • Payload canisters
      • Camera
      • Thrusters
      • Buoyancy material (if used)
      • Ballast material (if used)
      • Tether attachment to frame
    • Description of vehicle subsystems
      • Include pictures and/or 3D models as needed
  • Controller
    • Picture of up-to-date 3D model of controller (or picture, if completed); must include labels for:
      • Toggle switches/push buttons
      • Antenna
      • Video display
      • LCD display
      • All other parts
    • Description of controller
  • Custom Part
    • Description of problem/challenge the part solves and/or the novel approach the part brings
    • Picture of up-to-date 3D model of custom part (or picture, if completed); must include labels for the parts of the ROV system that the part interacts with (e.g. mounting points)
  • Cost
    • State anticipated total cost
    • Chart showing simplified cost breakdown
    • Link to appendix with detailed cost breakdown (also functions as the bill of materials)
• Hydrostatic Stability Analysis
  • CG/CB from OnShape
    • Must be measured from the (back, right, bottom) corner of ROV
    • Figure showing location of centers on CAD model
• Performance Prediction
  • Thrust measurements
  • Surge
    • Principal particulars estimation/calculation, including justification for:
      • Estimated $C_D$, including rationale
      • Estimated cross-sectional area, $A$, including rationale
      • Estimated velocity, $V$, using estimated $C_D$ and measured thrust, $T$
      • Brake power, $P_B$
      • Predicted efficiency, $\eta$, based on above items
  • Heave
    • Principal particulars estimation/calculation, including justification for:
      • Estimated $C_D$, including rationale
      • Estimated cross-sectional area, $A$, including rationale
      • Estimated velocity, $V$, using estimated $C_D$ and measured thrust, $T$
      • Brake power, $P_B$
      • Predicted efficiency, $\eta$, based on above items
  • Experimental observations of hydrodynamic stability and maneuvering, if available; otherwise, discuss anticpated maneuverability
• Construction Update
  • Pictures of components built-to-date
  • Updated project timeline
    • Include distribution of team responsibilities, including assigned leads for major tasks and deliverables
  • Confidences and concerns for system completion and testing
• Full Scale ROV
  • Description of operating conditions
  • Analysis of the horizontal velocity criteria from the Statement of Work
    • State which buoy was used and how you calculated the required velocity
  • Full scale dimensions
  • Description of choice in scaling thrust, velocity, or power
  • Surge Speed
    • Principal particulars estimation/calculation, including table to summarize
    • Commentary on whether this speed meets the requirements
  • Heave Speed
    • Principal particulars estimation/calculation, including table to summarize
    • Commentary on whether this speed meets the requirements
• Conclusions and Recommendations
• References
• Appendices
  • Detailed Cost Breakdown
    • Effectively includes a bill of materials
  • Anything else you want to include that doesn’t make sense to have in the main body of the report

Advice From Your Instructors

If you do a good job on this report, your team will be able to re-use a lot of the content for your final report, the Final Report to Executive Team. Re-using your content, which is totally fine since your team wrote it all, will make writing the final report a lot easier and less time-consuming. The end of the semester is usually even more crazy than when you’re writing this Critical Design Report, so put in the time now so that you and your team will have an easier time later at the end of the semester.

Your instructors truly and deeply want you to get a good grade on this assignment! We also hate grading but absolutely love giving feedback before the deadline. So, if you share your drafts with us and ask us to look at specific things, we will be super excited to look at what you have and tell you what we think. Then, you can address the feedback before you submit your report and get a better grade! Please remember that we are very busy, so if you want useful feedback, ask specific questions! Here are some examples of good questions to tag us with in comments:

• Here’s what we have for labels on our ROV 3D model. Can you read these okay? Is the font size all right?
• This is our rationale for our coefficient of drag. Does this make sense to you?
• This sentence in our summary seems… awkward. But we can’t think of a better way to phrase this. Any ideas?
• This is our backup plan for if our custom part fails. Does this have enough detail?

These are specific items we can jump into your report, take a look, and give you quick feedback on. If you ask us, “can u pls read our report”, we will probably ignore that request. :)

Submission

Your team should submit a .pdf copy of your CDR report to Canvas. Only one person needs to submit the .pdf, but everyone is responsible for making sure that the file is submitted on time! After someone submits the file, everyone else should make sure that the file uploaded correctly. You will receive feedback in Canvas about your CDR report.

 

---

Final Presentation to Client

Purpose of the Assignment

This assignment’s educational purpose is the summative assessment of your team’s skills in giving a presentation, including the design and execution of the slides and your delivery of the presentation itself. Your team will be evaluated on its skills in giving a formal presentation to a large audience. Most people would consider a large audience to be around 50 people or so; in this case, it will be a presentation you give in front of our entire class in lecture. Giving a formal presentation is different than giving an informal presentation, and engineers need to be familiar with both styles of presenting.

This assignment’s real-world purpose is to give you experience in presenting to a mixed audience, including peers, experts, and external audience member who you do not know well, such as an industry sponsor or client of the company. It’s one thing to present to your teammates and project manager, who you presumably know well and feel comfortable with. It’s another thing to talk about the work that you being paid to do by a client,and who might cancel the contract if you’re not doing the work well! A good presentation gives your client confidence in your ability to satisfactorily complete the project.

Background

GFL has arranged for all of the teams to present their work to the company and invited guests. This will be a formal presentation. The audience will consist of at least one of the GFL partners, invited guests, and one other ROV team. There will be approximately 10 people in the audience.

Requirements

This final presentation is a formal presentation given to your “bosses” as well as your client. Here are the requirements for the final presentation:

Presentation Duration: 15 minutes

• Title slide with team name and team members’ names
• Introduction
  • Problem overview / context for why you’re designing an ROV
• Prototype ROV Overview
  • Design goals/rationale
  • Vehicle
    • Picture of actual, finished ROV; must include labels for:
      • Overall dimensions
      • Frame
      • Payload canisters
      • Camera
      • Thrusters
      • Buoyancy material (if used)
      • Ballast material (if used)
      • Tether attachment to frame
    • Description of vehicle subsystems
      • Include pictures and/or 3D models as needed
  • Controller
    • Picture of actual, finished controller; must include labels for:
      • Toggle switches/push buttons
      • Antenna
      • Video display
      • LCD display
      • All other parts
    • Description of controller
  • Custom Part
    • Description of problem/challenge the part solves and/or the novel approach the part brings
    • Picture of actual, finished custom part; must include labels for the parts of the ROV system that the part interacts with (e.g. mounting points)
  • Cost
    • State anticipated total cost
    • Chart showing simplified cost breakdown
• Hydrostatic Stability Analysis
  • CG/CB from OnShape
    • Must be measured from the (back, right, bottom) corner of ROV
  • CG/CB from swinging the vehicle
    • Description of swinging the vehicle
    • Calculations for CG
  • Figure showing comparison of centers (probably on CAD model, but might be on picture of actual ROV)
  • Experimental validation / observations on validity of the centers
• Performance Evaluation
  • GFL Testing
    • Thrust measurements
    • Experimental observations of hydrodynamic stability and maneuvering
  • MHL Testing
    • Procedures, including diagrams
    • Surge
      • Speed Calculations
      • Principal particulars calculation, including justification for:
        • Calculated $C_D$, using calculated $V$ and measured thrust, $T$
        • Estimated cross-sectional area, $A$, including rationale
        • Calculated velocity, $V$
        • Brake power, $P_B$
        • Calculated efficiency, $\eta$, based on above items
    • Heave
      • Speed Calculations
      • Principal particulars calculation, including justification for:
        • Calculated $C_D$, using calculated $V$ and measured thrust, $T$
        • Estimated cross-sectional area, $A$, including rationale
        • Calculated velocity, $V$
        • Brake power, $P_B$
        • Calculated efficiency, $\eta$, based on above items
    • Experimental observations of hydrodynamic stability and maneuvering
  • Riser Inspection Simulation
    • Description of procedures, including diagrams
    • Report of riser inspection simulation
  • Overall evaluation of the prototype ROV
    • Observations on using the vehicle and controller including:
      • Hydrodynamic stability
      • Maneuvering
      • Ease of driving
      • Effectiveness of the custom part
• Full Scale ROV
  • Description of operating conditions
  • Analysis of the horizontal velocity criteria from the Statement of Work
    • State which buoy was used and how you calculated the required velocity
  • Full scale dimensions
  • Description of choice in scaling thrust, velocity, or power
  • Surge Speed
    • Principal particulars calculation, including table to summarize
    • Commentary on whether this speed meets the requirements
  • Heave Speed
    • Principal particulars calculation, including table to summarize
    • Commentary on whether this speed meets the requirements
• Conclusions and Recommendations

Advice From Your Instructors

You should be able to adapt a lot of your slides from your CDR presentation for this presentation. However! Make sure that you fully update all the slides with the latest versions of:

• Your 3D model
• Pictures of the completed ROV
• Results of performance evaluation at the MHL
• Updated performance evaluation

These sections will be new:

• Description of custom part and preliminary results on effectiveness
• Full-scale ROV recommendations

You will have feedback from us on your CDR presentation in Canvas. Make sure to address all this feedback as you evolve your CDR slides to this final presentation to the client.

Presenting in front of a large audience can be scary! Presenting as a team, with multiple people doing the talking, can also be nerve-wracking. The best thing you can do to prepare is to rehearse your presentation several times before you actually give it. This means completing your slides ahead of time and then meeting as a group several times so that you can practice the presentation, including timing and hand-offs (when one person stops talking and another person takes over).

You will do a dress rehearsal of this presentation during lab so that your team has at least one chance to rehearse the presentation before you give it to the whole class. You can do additional rehearsals on your own and with your IA and/or peer mentor. All of these people will be excited to help you rehearse and revise your presentation so that you will be as comfortable as you can when you give the presentation to the class!

Submission

Your team should submit a .pdf copy of your Final Presentation to Client slides to Canvas. Only one person needs to submit the .pdf, but everyone is responsible for making sure that the file is submitted on time! After someone submits the file, everyone else should make sure that the file uploaded correctly. You will receive feedback in Canvas about your presentation.

 

---

Innovation Video

Purpose of the Assignment

This assignment’s educational purpose is to assess your skill in communicating clearly and concisely about an individual part of your overall design. You should be able to connect the individual part to the ROV as a whole but keep the focus on the individual part. It’s easy to talk for 20 minutes about something you did; it’s a lot harder to talk for only 2 minutes!

This assignment’s real-world purpose is to give you practice in applying your technical communication skills to a different genre than presentations and reports. Technical communication is truly about communicating and there are many ways to communicate. Real-world communication happens in many different ways! You may also find yourself in a situation where you, or your company, are looking for investment/funding for a new product or service. Videos, “elevator pitches”, and all forms of engaging content are often how new companies get started.

There’s also a third purpose to this assignment. We wanted a fun and unique way to end the semester and celebrate all of the teams’ hard work and ingenuity this semester. Watching the innovation videos on the last day of class is truly the highlight of the entire semester for your instructors, and we hope you will enjoy the videos as well!

Background

Your team must make a video that details your ROV’s custom part and its role in your ROV system, with particular focus on the improvement it makes to performance. Your goals are to:

1. Describe your custom part clearly in terms that your audience will understand and
2. Convince your audience that the labor and expense involved in producing the custom part is worthwhile.

At the end of the semester, we’ll all put on our “angel investor” hats. We’ll watch the videos and vote with our pretend money.

Each video must include a list of credits at the end and must be accompanied by supplemental production materials (details below).

You have access to the Personal Studio through Groundworks in the Duderstadt Center, which also includes tools for editing. You are not required to use the Personal Studio, but it may make collaboration easier and the process more intuitive for those of you who don’t have any previous experience making and editing videos. If you want to make a different style of video, there are also a million apps for that. Besides iMovie (which also comes in a mobile version that’s easier to use, but only applies to iOS users), some alternatives are Splice, Magisto, and Stikbot for stop-motion videos. Don’t underestimate Instagram for time-lapse videos!

You can also refer to Ryan Wilcox’s Pocket Production YouTube series for advice on framing shots, lighting, sound recording, and a bunch of other things.

For this assignment, think something like a Kickstarter introduction video. Note that these took a lot of money and a lot of time to produce; we’re not expecting you to have this level of sophistication. We do think it’s useful, though, to think about the sorts of design decisions made here. Here are a variety of examples:

• Coolest Cooler
• Clinch Electric Extension Cord
• The Micro: First Consumer 3D Printer
• Next Generation 3D Printer Extruders

Important! This is not to suggest that these videos are all perfect!

Your group will make your own decisions about the tone and styling. Whether you use text, music, actors, or multiple camera angles is up to you. We just want to see you being really intentional about how you want to present your group and your group’s custom part (think ethos and logos).

Use the medium to your advantage. What will a video detailing your custom part allow you to do that a slide presentation doesn’t?

Requirements

This innovation video is much more open-ended than the presentations or reports in terms of a format/template. We strongly encourage teams to be creative in their innovation videos! Here are the general requirements for the innovation video:

• Length
• No minimum length
• Your video should be as long as it takes to describe your custom part clearly and persuasively, but it needs to be brief
• Maximum length of 5 minutes
• Production Quality
• This is not a video production class, so we are not formally grading you on film principles like lighting and blocking.
• However, this video should appear polished and purposeful.
• We want to see you using the medium for a communication purpose, as noted above, and we don't want to be distracted by things like people randomly wandering in and out of the frame or lighting so dim we can't see your custom part clearly.
• Sound is very important -- make sure that we can clearly understand people speaking (both volume and clarity)
• AI generated content is not allowed -- we want to see your work!
• If you are doing a parody of an existing work, you must follow the U.S. rules for parody, fair use, etc. regarding the use of video and audio of the original work in your new work.
• Supplemental Materials
• We need to see evidence of pre-planning and post-review. In addition to including the credits at the end of your video -- that is, a list of the names of everyone involved and what their jobs were -- choose two of the following to turn in:
• Audience analysis
• Script
• Storyboard (find templates here, here, and a million other places)
• Shot list (find templates here, here, etc.)
• Post-production notes or edit history log
• Some other planning you did that isn't listed here (get approval first!)
• Technical Specifications
• Imagine your video as a tiny “design pitch” for the custom hardware and/or software your team designed. Your video should therefore address the following:
• Problem statement: Why were existing solutions inadequate?
• Careful description of the innovation
• Careful description of the benefits of the innovation: what is improved with the use of your custom part/component? To the extent that you can provide evidence — especially if you can quantify anything — it's more compelling. (For example: perhaps you can now have three thrusters in two different directions, you can quantify the increase in surge, heave speed. Perhaps you built something to replace hose clamps, you can then quantify a reduction in cost.)
• Acknowledgment of any issues: What are the trade-offs, and how are the benefits bigger? (Make sure to address any possible concerns the audience has. Consider performance of ROV, robustness of ROV, cost/sustainability of ROV, ease of use of ROV)
• Comment on full-scale implications of this custom part. Will it be custom made for full scale ROV as well? If so, what will that mean for manufacturing? If not, talk about what the plan will be.
• Rhetorical Considerations
• This is a pitch.
• Your goal is to convince us that your custom part is awesome and that you're awesome to work with (not necessarily in that order).
• Remember that the beginning and end of this video (and any communication) are critical, so pay particular attention to those.
• Consider what sort of evidence you can use to persuade us.

Advice From Your Instructors

Sometimes, a well-conceived and well-edited video is shorter than a bumbling single take; that’s okay. But nor do we want you to spend hours and hours with your editing; that’s not the point of this assignment. We’re looking for you to find a nice balance between “let’s edit out this out-of-focus part of the video” and “eh, that’s good enough!” If you have any questions at all just ask!!

There are many good ways to go about this innovation video. Some teams have done videos similar to what you might see on reality shows where people pitch their ideas to investors to try to win money. Some teams have done documentary-style videos with serious voice-overs. Some teams have done parodies of movies and tv shows. It’s completely up to you and your team! The presentations and reports that we do in this class are pretty formal with a good amount of rules to them; that’s just how it’s gotta be. For this assignment, we really want you to let your creativity shine! If you’re stuck on what kind of video to do, ask us and we can help you figure something out!

Submission

Have someone on your team upload your innovation video to YouTube and set it to be “unlisted”. We recommend disabling comments, but you can leave them enabled if you really want to. Everyone on your team should have access to YouTube via your U-M google account. Setting the video to be “unlisted” means that we (your instructors) will be able to view it for grading and showing in class, but it will not be publicly available. Do not mark the video as “for kids” because then we can’t add it to a playlist for the last day of class.

Create a document with the following:

• Your team name and the names of all team members
• The link to your innovation video on YouTube.
• The two (or more) items of Supplementary Material that you are including.

There is no particular format for this document, just make sure we can understand all the different parts. Save this document as a .pdf (making sure the link to your video works or that we have the full URL).

Your team should submit this .pdf to Canvas. Only one person needs to submit the .pdf, but everyone is responsible for making sure that the file is submitted on time! After someone submits the file, everyone else should make sure that the file uploaded correctly. You will receive feedback in Canvas about your innovation video and supplementary materials.

 

---

Final Report to Executive Team

Purpose of the Assignment

This assignment’s educational purpose is the summative assessement of your team’s skills in producing a final report, including the organization of the report, the quality of the writing and visuals, and the quality of the calculations and rationale.

This assignment’s real-world purpose is to give you experience in creating a formal report. Different companies use different formats for reports, but the ability to formally document your work in a written document is crucial for any engineer. If you do a good job with this report, you can use it as “evidence” of your communication skills when interviewing for internships!

Background

GFL is wrapping up the contract with LakePowerGen to produce ROV prototypes for their anticipated new ventures with Lake Michigan-based offshore wind farms. The final deliverable in the Statement of Work is a final report, to be delivered to the client, documenting the ROV prototype and evaluting its performance in testing and at the ROV Showcase. This will be a full, formal final report.

Requirements

This final report will be submitted using the formal report format.

Here are the requirements for the final report:

• Title page
  • Descriptive title of report
  • Team name
  • Team members’ names
  • Date of submission
• Table of contents (must be autogenerated by headings)
• Executive Summary
• Introduction
  • Problem overview / context for why you’re designing an ROV
• Prototype ROV Overview
  • Design goals/rationale
  • Vehicle
    • Picture of actual, finished ROV; must include labels for:
      • Overall dimensions
      • Frame
      • Payload canisters
      • Camera
      • Thrusters
      • Buoyancy material (if used)
      • Ballast material (if used)
      • Tether attachment to frame
    • Description of vehicle subsystems
      • Include pictures and/or 3D models as needed
  • Controller
    • Picture of actual, finished controller; must include labels for:
      • Toggle switches/push buttons
      • Antenna
      • Video display
      • LCD display
      • All other parts
    • Description of controller
  • Custom Part
    • Description of problem/challenge the part solves and/or the novel approach the part brings
    • Picture of actual, finished custom part; must include labels for the parts of the ROV system that the part interacts with (e.g. mounting points)
  • Cost
    • State total cost
    • Chart showing simplified cost breakdown
    • Link to appendix with detailed cost breakdown (also functions as the bill of materials)
• Hydrostatic Stability Analysis
  • CG/CB from OnShape
    • Must be measured from the (back, right, bottom) corner of ROV
  • CG/CB from swinging the vehicle
    • Description of swinging the vehicle
    • Calculations for CG
  • Figure showing comparison of centers (probably on CAD model, but might be on picture of actual ROV)
  • Experimental validation / observations on validity of the centers
• Performance Evaluation
  • GFL Testing
    • Thrust measurements
    • Experimental observations of hydrodynamic stability and maneuvering
  • MHL Testing
    • Surge
      • Speed Calculations
      • Principal particulars calculation, including justification for:
        • Calculated $C_D$, using calculated $V$ and measured thrust, $T$
        • Estimated cross-sectional area, $A$, including rationale
        • Calculated velocity, $V$
        • Brake power, $P_B$
        • Calculated efficiency, $\eta$, based on above items
    • Heave
      • Speed Calculations
      • Principal particulars calculation, including justification for:
        • Calculated $C_D$, using calculated $V$ and measured thrust, $T$
        • Estimated cross-sectional area, $A$, including rationale
        • Calculated velocity, $V$
        • Brake power, $P_B$
        • Calculated efficiency, $\eta$, based on above items
    • Experimental observations of hydrodynamic stability and maneuvering
  • Riser Inspection Simulation
    • Description of procedures, including diagrams
    • Report of riser inspection simulation
  • Overall evaluation of the prototype ROV
    • Observations on using the vehicle and controller including:
      • Hydrodynamic stability
      • Maneuvering
      • Ease of driving
      • Effectiveness of the custom part
• Full Scale ROV
  • Description of operating conditions
  • Analysis of the horizontal velocity criteria from the Statement of Work
    • State which buoy was used and how you calculated the required velocity
  • Full scale dimensions
  • Description of choice in scaling thrust, velocity, or power
  • Surge Speed
    • Principal particulars calculation, including table to summarize
    • Commentary on whether this speed meets the requirements
  • Heave Speed
    • Principal particulars calculation, including table to summarize
    • Commentary on whether this speed meets the requirements
• Conclusions and Recommendations
• References
• Appendices
  • Detailed Cost Breakdown
    • Effectively includes a bill of materials
  • Anything else you want to include that doesn’t make sense to have in the main body of the report

Advice From Your Instructors

This is going to be a fairly in-depth report that will take the combined effort of everyone on your team to complete. We recommend that your team get a full and complete draft done well before the deadline so that you can get feedback on your report from your peer mentor, IA, and the instructors.

Remember, we hate grading, and we love to give feedback before deadlines! We’ll have some work time during lecture where your team can work on this report before it’s due. It’s easy to ask us questions during this time!

Submission

Your team should submit a .pdf copy of your Final Report to Executive Team to Canvas. Only one person needs to submit the .pdf, but everyone is responsible for making sure that the file is submitted on time! After someone submits the file, everyone else should make sure that the file uploaded correctly. You will receive feedback in Canvas about your report.