This page is archived material from a previous course. Please check for updated material.

Design Proposals and Reports (2015)

last updated: 2015 May 8.

Jump To

1. Pre-Review Discussion (Week 3 or 4)
1. Overview
2. Expected
3. Outcome
2. Formal Design Proposal – Overview (Week 6)
1. Formal Design Proposal – Specific Sections
2. Letter of Transmittal
3. Executive Summary
4. Preface
5. Overview of Basic Strategy
6. Chassis
7. Drive and Actuator System
8. Electrical Design
9. Strategy, Algorithms and Software
10. Risk Assessment and Contingency Planning
11. Task List, Major Milestones, Team Responsibilities
3. Final Report / Webpage / Video (1 week after competition)

 

---

Pre-Review Discussion (Week 3 or 4)

Overview

• 10-15min discussion with at least 2 course instructors, done during Week 3 or 4 of the course
• Teams are welcome to (and should!) talk to multiple instructors.
• A sign-in form in Hebb 42 will be used to confirm that groups have discussed with at least 2 course instructors or TA’s

Expected

You will be able to discuss your ideas about the general robot function, including general details on the following:

• Mechanical – Printed / hand drawn version of major mechanical components.
• Electronics – Block-diagram of overall system showing major connections, diagrams of wiring connections between PCBs and components, and possible schematics for individual PCB’s.
• Other Resources – Major technical resources required (table of TINAH pin connections, # and type of motors, types of sensors, linear stages/arms, items not supplied in lectures)
• Analysis – Approximate calculations for motors, torques, speeds, results of small-scale tests to verify operation – convince us and yourself that your design will work as specified.
• Risk Assessment – Identification of the biggest risks/obstacles for your design during fabrication and operation.
• A rough draft of all discussion material is adequate, provided that all relevant information is available for discussion, and in preparation for the Formal Design Document.

Emphasize the application of appropriate engineering theory to your design. Show calculations and estimates wherever applicable.

 

Outcome

With the help of TAs/instructors, identify the major problem areas to address for the Design Document.

 

---

Formal Design Proposal – Overview (Week 6)

The document will be assessed separately for both the prototype development and technical communication components of ENPH 253.

 

The most successful design documents provide documentation which is actually used by the team during the robot fabrication and testing stages.   Avoid “filler material” and adding any text which is not necessary in describing these issues.

 

The Technical Report Guide from Monash University is a very good general reference to use for Technical Reports and other forms of Professional and Technical Communication.

 

 

Start with a list of all of the Figures Tables Charts and Calculations to include in the report.    Build your report around those elements – any writing you have in your document should be in support of that information.

 

 

Formal Design Proposal – Specific Sections

 

Suggested length of document – no more than 8 pages of written text (does not include figures, charts, tables)

Suggested maximum length for text in each section   (NOTE: these suggested lengths do not include figures, tables, charts or calculations)

• Letter of Transmittal  (as a separate document)
• Title Page
• Executive Summary (1 pg) 
• Table of Contents, List of Figures and Tables (1 pg)
• Preface (1pg)
• Overview of Basic Strategy (1 pg)
• Chassis (1 pg)
• Drive System (1 pg)
• Sensor System (1 pg)
• Software Code and Algorithms (2 pg)
• Risk Assessment and Contingency Planning (2 pg)
• Major Milestones, Task List, and Team Responsibilities (1 pg)
• References/Appendices  (no limit)

 

Letter of Transmittal

The Letter of Transmittal is used to introduce group to the reader, establishes your credentials for the project, highlight special features of the proposal that the reader, and remind the reader of the reason for the proposal.  

 

 

The Letter of Transmittal is a separate document, and should not be bound or included with the proposal since it is always written to an individual person, whereas the Proposal may be read by several people in order to be evaluated.

 

Executive Summary

The Executive Summary should be a clear summary of the entire document, and should give a clear indication to the reader of the scale and scope of the project.

The Executive Summary:

• Is a self-contained and should require no specific background in order to understand the project.
• Should contain quantitative information (e.g. target performance values, sizes) to give the reader a clear indication of the scale and scope of the project.
• Is normally 1 page in length, and may contain several paragraphs, and should not normally exceed one page.

 

Preface

For ENPH 253, please include a clear statement in the Preface of how the work for the proposal was divided among all team members (section-by-section, or by specific responsibilities, etc.

 

 The Preface often gives the qualifications of the authors and acknowledgement of help received. It is used to outline restrictions or confidentiality of the information in the report, and any other circumstances about the process of producing the document.   The Preface is normally signed by all authors of the report.

 

 

Overview of Basic Strategy

The Overview of Basic Strategy section is a summary of your robot’s proposed operation on the Playing Surface.  The material in this section should give a big-picture view of the robot’s proposed operation and to highlight any key features or design elements to accomplish the tasks for the competition.

 

Chassis

The Chassis section should include information on the physical structure of the robot.   Make ample use of figures and tables to describe this information, while using any text to explain and highlight specific components or specific techniques used by the team.

• Listing of each chassis component
• Areas of chassis design which allow for flexibility during performance (e.g. wheel mounts, wheel diameter size changes, external gearing of motors,sensor remounting, etc)
• Method of fabricating each component
• Method of assembly (i.e .what order to assemble the different components together. Occasionally teams will inadvertantly plan to attach components in a configuration that cannot be accessed by screws or welding electrodes)
• Ease of assembly/dissassembly (TINAH, battery, fasteners)
• Ease of redesign of major components (leave room for modification)
• Estimated mass of system and components.

Some areas to think about as you put together your initial designs:

• Can you re-design your parts to be tolerant of inaccuracies in fabrication? (alignment and precision in machining are always a problem)
• Can you design it to make it easier to get access to parts? (circuits, wiring, motors, differentials)
• Can you minimize for both the fabrication time and the/or the amount of material? (for weight, for wasted material)

 

Drive and Actuator System

The Drive and Actuator System section should include information on the topics listed below:

• Steering method and robot geometry
• Drive mechanism and associated transmission (DC motors / Servos / Gears)
• Transmission calculations – expected performance based on chosen gear ratio, motor torque, mass of robot, wheel size etc.
• Actuator systems for manipulating other components (object handling, structure deployment, etc)
• Motors (type, number, voltage/current/power required for 1 round)
• Wheel size selection (estimate maximum speed, acceleration)

 

Electrical Design

The Electrical Design section should include information on the sensors, TINAH resources, and electrical requirements as listed below.    Similar to the Chassis section, a Table can be used to organize the majority of this information, with the text used to explain and highlight specific components or specific techniques used by the team.

• TINAH Resources (Digital/Analog/Motor control specification) – table should showing all TINAH pins and expected I/O
  • Tape sensors
  • IR sensors
  • Collision detectors / Edge-of-surface detectors / Object detection
  • Sensors for position feedback for different internal components
• Electrical Design – the Electrical Design section should include information on the topics listed below.
  • List of individual PCBs used in design (each PCB is named and/or numbered)
  • Name of PCB
  • Approximate size
  • Number and type of wiring connections to other boards/TINAH.
• Table of Physical Wiring Cables
  • This table should include listings of all wiring harnesses for your robot, and the specific PCBs/TINAH connections for each wiring cable. Having this available allows for modular system design, and cleaner wiring on the robot.
  • It should be clear how the wiring for power, motor control, and sensor input will be organized.
  • Minimize the number of single-pin connections with your these wires (i.e. 1 wire with a single female or male header pin plugged into 1 area on your PCB, as these are not mechanically secure.

 

Strategy, Algorithms and Software

The Strategy, Algorithms and Software section should include information on the topics listed below:

• Overview of functions and control loops used for the robot.
• Flowchart or State Diagrams of individual functions of code
  • Flowcharts – groups often do a poor job of drawing flowcharts. Find resources online to explain rules to follow for a proper sensible flowchart.
  • State Diagrams (aka state transition diagrams or UML diagrams) – these may be a useful tool to help keep track of how your robot is functioning on the playing surface. Descriptions for how to draw state diagrams.
• Error handling algorithms:
  • algorithm when tape is lost / deciding between tape tracks / avoiding falling off the playing surface (edge-sensors)

 

 

Risk Assessment and Contingency Planning

• Risk Assessment
  • Identifying the “riskiest” part of your project allows you to both minimize the risk by doing something different right at the start, and to help develop alternative plans in case something does go wrong along the way. This may include items like:
    • the inability to detect IR in the range from 1foot to 7 feet using one circuit
    • the inability to manipulate/recover objects as required by your design
    • the inability to fabricate one specific key piece for your robot
  • Work to identify these Risks, and work to minimize the risk and their impact on your robot.
• Contingency Planning
  • Contingency planning is not something you improvise entirely along the way, but can be done early on to identify the most likely areas that will cause disruptions in your overall plans. Contingency plans consist of:
    • Identifying the condition which triggers the contingency plan into action
    • Describing the likelihood and impact of the condition being met.
    • Describing the changes which need to be made to the task list.
    • Identifying the date or range of dates at which point this decision will be made one way or the other (your “drop dead” date before going with your contingency plan).
    • Using a table to format this section may help to keep the information together.

Using a table to format this section may help to keep the information together.

Risk Condition	Probability of occurrence	Impact to Project	Change to Work Plan	Expected Date of Risk Decision

 

 

 

Task List, Major Milestones, Team Responsibilities

Use this section to describe your task list, and how tasks are divided among all group members.

• Task List
  • What tasks need to be completed?   Be as specific as you can!
  • What order should the tasks need to be arranged?  (e.g. which circuit is the first one that needs to be completed? what software would be most useful initially?)
  • How to test and verify each stage of the Robot?
  • See if you can place tasks concurrently as much as you can.
  • Use whatever tool is appropriate to organize your tasks.   When planning, writing tasks on post-its is a good way to get a broad view of what needs to be done.   Gantt Charts can be a useful documentation tool, but as a planning tool it often makes it difficult to organizing the order of tasks.
• A note about testing:
  • When you claim to be “testing” something, think specifically about how to test and obtain unambiguous, conclusive, repeatable results.  These might include:
    • Testing your steering mechanism
    • Testing your IR detection to maximize detection at the desired distance.
    • Testing noise in IR system when motors running (e.g. ground loops)
    • Testing identification of key playing surface elements… And have alternative solutions if the system doesn’t work

• Major Milestones (for the 253 Major Milestone Day)
  • Identify 2 or 3 major milestones for your team for the ENPH 253 Milestone Date (see course calendar). This may include items like the following:
    • Chassis, drive motors and wheels mounted
    • Power circuits complete
    • Chassis following tape
    • Pickup mechanism completed
    • Software can be triggered to perform based on manipulating sensor
• Team Responsibilities
  • You may choose to identify specific people for each of the Tasks.
  • You may also choose to appoint specific people to have primary oversight over specific parts of the robot, either by function or expertise (“the robot arm person”, or the “software person”)
  • Note about software: Although the first 80% of the course will involve all areas of the robot, but the final time before competition will likely have a very heavy sensor/algorithm/software development side. You will likely benefit from having most if not all of your people involved in some capacity in the sensor/algorithm/software side for the entire build period.

 

 

 

---

Final Report / Webpage / Video (1 week after competition)

Final report submitted 1 week after the competition. The Final Report is NOT marked, but represents the only document which the group is allowed to take at the completion of the course.

 

Only 1 submission per group is required This is not an individual assignment.

 

There are no formal guidelines given for the final report. It is not a marked document, and is meant for the team to have a record of their work to showcase to prospective employees as a record of your work. We have found that documents with labelled photos and schematics serve this purpose better than excessive writing about the robots.

 

We allow (and encourage) webpages and/or videos in place of a final report document. These can include photos and videos of your robot in construction and on the playing surface. If you do go in this direction, please submit either all of your web documents, or forward a web address where the pages are located.

 

Examples:

• Adiabatmobile (Website, Racing-Robots, 2010)
• Scalar (written report, Climber-Bots, 2011)
• Elvis (video, Racing-Robots, 2010)
• Robo-Racers (2010 team page of videos, reports, webpages)

 

 

 

End of Page.